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