Security Awareness? How do you keep your staff safe?
If you’ve been following recent diaries from my fellow handlers Brad and Manuel, they peel the covers back on a couple current malicious emails campaigns. Many of the readers of the Storm Center diaries will be use to the ebb and flow of these stories. Here in Australia there’s a speeding fine scam email [1] that’s been running for the last few weeks, and there’s no indication it will drop off any time soon.
There is plenty of training, education and horror stories out on the Internet about malicious email, so why is it a recurring problem? One suggestion has been that it plays on human emotions. Threatening or enticing emails are designed to draw in the unsuspecting and then there are those users that will go to significant lengths to bypass security controls just to see the dancing cat/chicken/Hans Solo.
So providing useful and meaningful security awareness isn’t easy and has to be made relevant to individual audiences, even within the same organization. Providing the same training education to senior management and then a development group will probably miss the mark for both groups and result in a “Meh, I won’t fall for that”. Sadly generic security training often results in a trained staff member that still falls victim to a relatively convincing scam.
At this point you’d be expecting some wondrous solution. Sorry, not today. I will say this is something that takes constant revising, effort and innovative thinking to engage your staff. I’ve mentioned before that SANS has some nifty resources [2], but I really love finding how people try to instill security in their organizations. A security engineer from Riot Games posted how his security team took a different approach to getting in the hearts and minds of their staff about thinking about security as a whole [3]. This goes back to build a story about being security minded that your audience understands, hopefully cares about, and starts to adopt in their working practices and lives.
Will it stop everyone clicking links or opening random email attachments? I doubt it, but flipping a person from an attack vector to an attack alerter is a worthy goal.
If you have any other examples of innovative ways at getting people to care about good, basic security approaches, please add a comment or drop us a line [4]
[1] https://www.service.nsw.gov.au/news/afp-warns-public-email-traffic-infringement-scam
[2] http://www.securingthehuman.org/resources/
[3] http://blog.markofu.com/2015/01/socialising-security-riot.html
[4] https://isc.sans.edu/contact.html
Chris Mohan --- Internet Storm Center Handler on Duty
The Art of Logging
[This is a Guest Diary by Xavier Mertens]
Handling log files is not a new topic. For a long time, people should know that taking care of your logs is a must have. They are very valuable when you need to investigate an incident. But, if collecting events and storing them for later processing is one point, events must be properly generated to be able to investigate suspicious activities! Let's take by example a firewall... Logging all the accepted traffic is one step but what's really important is to log all the rejected traffic. Most of the modern security devices (IDS, firewalls, web application firewalls, ...) can integrate dynamic blocklists maintained by external organizations. They are plenty of useful blocklists on the internet with IP addresses, domain names, etc... It's quite easy to add a rule on top of your security policy which says:
if (source_ip in blocklist):
drop_traffic()
With the "blocklist" table being populated by an external process. Usually, this rule is defined at the beginning of the security policy for performance reason. Very efficient, but is it the right place?
Let's assume a web application firewall which has this kind of feature. It will drop all connections from a (reported as) suspicious IP address from the beginning without more details. Let's put the blocklist rule at the end of the policy of our WAF. We have now something like this:
if (detected_attack(pattern1)):
drop_traffic()
elif (detected_attack(pattern2)):
drop_traffic()
elif (detected_attack(pattern3)):
drop_traffic()
elif (source_ip in blocklist):
drop_traffic()
If we block the malicious IP addresses at the beginning of the policy, we'll never know which kind of attack has been tried. By blocking our malicious IP addresses at the end, we know that if one IP is blocked, our policy was not effective enough to block the attack! Maybe a new type of attack was tried and we need to add a new pattern. Blocking attackers is good but it's more valuable to know why they were blocked…
Comments
www
Nov 17th 2022
6 months ago
EEW
Nov 17th 2022
6 months ago
qwq
Nov 17th 2022
6 months ago
mashood
Nov 17th 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
5 months ago
isc.sans.edu
Dec 26th 2022
5 months ago