How much training should staff have on cyber security? · How much training should staff have on cyber security? ... give opportunity to think, ... Can't switch on/switch off secure
21
How much training should staff have on cyber security?
How much training should staff have on cyber security?
Agenda
• General security awareness training • Setting up a strawman • Defeating the strawman (hopefully)
• Security training for software development • Really good news
Presenter
Presentation Notes
Well, not really a strawman, as Bruce Schneier is behind it
Arguments against training
• Some training just teaches you to pass a test • It will never be 100% successful, some attacks will get
through • We need designs that prevent attacks, not training
Presenter
Presentation Notes
http://www.csoonline.com/article/2131941/security-awareness/why-you-shouldn-t-train-employees-for-security-awareness.html http://www.darkreading.com/risk/on-security-awareness-training/d/d-id/1139381? From various sources, between 5 to 20% will get through even after very good training
Some training is bad
Yes, we need better training • Relevant • Interactive • Entertaining • Repeatable yet up-to-date • Respectful
Presenter
Presentation Notes
Relevant to technology and work function, better yet – relevant to the organisation Interactive – small bites, immediate feedback Entertaining – story based, variety of media, concept with examples Repeatable – we learn with repetition. But security landscape changes, so must update the training constantly Respectful – don’t treat your staff like idiots. Let them do it at their own pace, give opportunity to think, and give concepts, not just procedures. Give pointers to additional reading. Research about doctors – surgeons grow better with experience, radiologists don’t – training that simulates immediate feedback based on practical cases Good training: http://www.csoonline.com/article/2131688/security-awareness/ten-commandments-for-effective-security-training.html
Training is not bullet-proof
Neither are bullet-proof vests! And bad guy can aim for your head
Presenter
Presentation Notes
Is it a reason not to wear one to a gun fight?
Insider threat
• Malicious actions • Innocent mistakes
The second case is much more common
Designs vs training: unfair risk transfer?
• Car safety improves every year, yet so does our behaviour • Standard of fire safety in modern buildings is the highest
ever, yet drills still save lives • Medical equipment
Presenter
Presentation Notes
So the argument is that users should not be trained as it makes them responsible for security problems, designs should prevent a possibility of mistake. I say it’s unfair dichotomy, false choice. Cars: if you watch 60th movies, not much seatbelts, everyone is drinking
Bad vs really bad
In the 60s, Marvin Minsky assigned a couple of undergrads to spend the summer programming a computer to use a camera to identify objects in a scene. He figured they'd have the problem solved by the end of the summer. Half a century later, we're still working on it.
Presenter
Presentation Notes
Chess – computers are just computationally not quite there yet, conceptually it’s the same as tick-tack-toe Recognising sketch cat, cartoon cat and real cat – it’s a completely different level of “bad”.
Lets use it to our advantage
Presenter
Presentation Notes
If we can recognise an abstract “cat”, can we recognise an abstract attack? Example of phishing email from Shaun’s presentation. It’s impossible to create a computer filter that will recognise all the variations of this attack, with all the possible domain trickery and all the variations in text, and not prohibitive false positive rate. However, we can teach humans – every time you are asked through email to put your credentials on some website, it’s an attack. Don’t do it even if it’s accompanied by a phone call from “IT”. We will never legitimately ask you to do that. It will cover all 4 cases we’ve discussed in the previous trust forum. For maintenance, for disk quota, for any reason phishers haven’t invented yet.
It’s not either/or
• Updates, AV, web and mail filtering, firewalls • App whitelisting, proxy and traffic monitoring • Security awareness training • Phishing and social engineering assessments • Internal awards program
Presenter
Presentation Notes
To reiterate: we need both technical solutions and awareness
Presenter
Presentation Notes
From http://csrc.nist.gov/publications/nistpubs/800-50/NIST-SP800-50.pdf Hopefully you are convinced about awareness. Now let’s look at the next level of security competency pyramid: specialized training for secure software development Education is the process that fills minds with knowledge and expands one's ability to reason about the issues faced. For each stage of SDLC, by training your staff in good secure development practices you improve the overall engineering standards
Either introduce bug management tool, or improve the value you get out of it Learn to write SMART requirements outside of security Quality gates will catch functional bugs as well Learn to write use cases – one of the most efficient requirements tools, improved communication between product management and dev Better understanding of your software, knowledge sharing Better deploys
Design and Architecture
• Attack surface analysis / reduction • Threat modeling • Architecture and design reviews • Principles of secure design also make more maintainable
code
Presenter
Presentation Notes
You get knowledge sharing, documentation Simplified design and smaller codebase => less functional bugs
Whitelist vs blacklist
DWORD dwRet = IsAccessAllowed(...);
if (dwRet == ERROR_ACCESS_DENIED)
{ // Security check failed.
// Inform user that access is denied.
}
else
{ // Security check OK. }
DWORD dwRet = IsAccessAllowed(...); if (dwRet == NO_ERROR) { // Security check OK. // Perform task. } else { // Inform user that access is denied. }
Presenter
Presentation Notes
We usually think about it in the context of input validation, but it’s more widely applicable than that. List of error codes returned by function, class, module, library can change. Explicitly list what’s allowed, and reject everything else This principle improves code quality even if the function called is not security sensitive
Development
• Source control discipline • Code review • Static analysis • Approved builds • Automation on check-in / integration • Code and packages tracing
Presenter
Presentation Notes
Code review will catch bugs beyond security Approved builds – standardization, better transition between dev/staging/production environment Automation will deliver massive benefits, unit test culture Improved source control practices + code tracing => you’ll be able to respond to customer requests for hotfixes in a much easier way
Testing/Validation
• Security testing • Know your 3rd party components • Fuzzing • Dynamic analysis
Presenter
Presentation Notes
Security testing raises skills of testers and gives them career path To do fuzzing and dynamic analysis properly will require improvements in automation Dynamic analysis – even if they are not exploitable, crashes and memory leaks won’t make you popular with your users Culture of striving for code coverage – better tests all around
Ability to connect bug number to commit to build number in all the directions. Easily and automatically, not “our oldest developer will have to meditate on this for couple of hours”. Documented host environment => Smoother deploys Better communication between dev and ops
Secure development benefits
• Drives automation in development/testing/release • Drives better requirements • Knowledge sharing, documented designs • Test coverage • Better integration practices, can help on your road to
continuous integration/continuous delivery • Better all around code quality
When to apply these techniques
Always! Good habits trump good principles
Presenter
Presentation Notes
I’ve tried to avoid black and white answers, but this one I’m really sure about. Have to be really careful about prototypes, or lean startup environments. Best training is through practicing. Can't switch on/switch off secure thinking at will.
