Recommended
More Related Content
Similar to Upskilling your engineers in Cyber security while they WFH
Similar to Upskilling your engineers in Cyber security while they WFH (20)
Recently uploaded
Recently uploaded (20)
Upskilling your engineers in Cyber security while they WFH
- 2. Upskilling engineers in cybersecurity Aditya Kakrania akakrania@securityinnovation.com linkedin.com/in/adityakakrania 8 Apr 2020
- 3. Aditya Kakrania • Held most roles in SDLC • Information security since 2002 • Delivered talks and taught classes at Fortune-100 companies • Created a lot of learning content for SDLC security • Lately doing SDLC Gap Analysis: • Upskilling is part of improvement roadmap • Created upskilling programs for many orgs About me
- 4. Upskilling Core steps DETERMINE LEVEL of security know-how Know where to start Avoid making engineers repeat content GENERATE INTEREST in security No learning happens without interest Reward learners MANAGE LEARNING to improve level of security know-how Learning platform should retain interest Platform should support scoring Progress should be trackable
- 5. Upskilling Webinar Agenda 1. Understanding how attackers “audit” your products • What can be learned from them 2. Leveraging CaptureTheFlag (CTF) solutions • Engineers will understand attack vectors • Engineers will understand weaknesses • You identify strengths and weaknesses of team 3. Enabling Effective Learning • Map CTF evaluation to online training courses • Track progress and scores GENERATE INTEREST GENERATE INTEREST DETERMINE LEVEL MANAGE LEARNING MANAGE LEARNING DETERMINE LEVEL
- 6. How attackers ‘audit’ Attackers are people too Turn Use-cases into Abuse-cases •Leverage tools and scripts •View software differently •Speculate code & design behind features •Observe and take great notes
- 7. How attackers ‘audit’ From Use to Abuse Observe & Note Make/Refine Attack Vector Execute Attack Vector Use Case Abuse Case
- 8. How attackers ‘audit’ • Mindset of turning use-cases into abuse-cases • How to disable abuse cases in code and design • Common attack vectors • How to mitigate them • Observational skills – what cues do attackers look for • Curtail those cues as much as possible • Understanding the tools attackers use • What information is available to them • How tools can manipulate software What can be learned from them
- 9. Leveraging CTF Events • CTF platform should have 50%+ vulnerabilities that are easy to find • Participants are not hackers, point is to learn • Group activity with small teams • Good to have multiple roles in a team (Ex: Architect + Dev + QA) • Great team building exercise • One physical location preferred, remote works • Cross learning through interaction • Helps in maintaining interest • Track progress and scores • Common scoreboard promotes friendly competition • Award participants • Participation/Rank certificates, Gifts How-To
- 10. Leveraging CTF Events • Commercial: • Security Innovation’s Cyber Range: securityinnovation.com/training • Free: • Security Scenario Generator: github.com/cliffe/SecGen • Google Gruyere: google-gruyere.appspot.com • CTF Learn: ctflearn.com • OWASP Juice Shop: owasp.org/www-project-juice-shop Options
- 11. Managed Learning • Rank group CTF performance on available learning topics • Database security: Low • Injection attacks: Medium • Cryptography attacks: Low • Map to learning content based on • SDLC role • Content difficulty level • Offer support • Have quiz and exams at end of courses • Enable tracking course progress at individual level • Offer learning support based on progress tracking and score data • learning platform, security champion, email group etc. How-To
- 12. Managed Learning • Commercial • Security Innovation Courses: securityinnovation.com/training • SANS Online Cyber Security Training: sans.org/online- security-training • Free • Web Security Academy: portswigger.net/web-security • John Hammond’s videos: youtube.com/user/RootOfTheNull Options
- 13. Upskilling engineers in cybersecurity • CTFs and Training can help create a culture of security • Not security experts, but security conscious engineers • Designers will be aware of insecure mechanisms and patterns • Developers will recognize bad practices, fewer defects in code • Testers will know how to find security defects • Expect incremental improvement • Not everyone will learn improve right away • Continuous cycles of CTFs + Training • Create security champions in each team Finally
- 14. The Security Innovation Difference • Blended Learning → Attack & Defend • Attack: Hands-on simulation with CMD+CTRL • Real, purposely vulnerable applications for hands-on learning • Discover team capabilities and kindle interest in security • Defend: Progressive computer-based training • Role-based training for Architects, Developers, QA, Operations, IT, and Analysts • Modular courses provides a clear path that grows with leaners • Quarterly releases ensure content addresses current technologies and attack vectors • Rich Reporting • Real-time assessment of your team’s capabilities • Quarterly program analysis to adjust learning paths, cadence, and metrics
- 15. community.securityinnovation.com Training videos Hacking practice Career planning Security tools
Editor's Notes
- Been involved in most aspects of product development and been active in the info security since 2002. I have delivered many talks at conferences and taught classes at Fortune 100 companies worldwide. I have developed a lot of learning content for SDLC security and currently like to perform security gap analysis of product teams and create a roadmaps for security improvement over time. Have performed security gap analysis for large international airlines and financial companies. All of these aspects of my experience enable me to talk at some length on upskilling in security. Also, specially because a large part of the roadmap creation in SDLC Gap Analysis - which I have been doing for the last few years - deals with upskilling the engineers in security and today I’d like to present what I have learned in that area.
- Core steps organizations need to take for upskilling. If you remove security references from this, these steps apply to all upskilling. Most organizations have some sort of a learning program; whether it is managed well or useful or not – it’s at least there; and that’s a start. So what I have seen is that most orgs are skipping two very important things: (1) Understanding or determining how much their engineers already know. Without knowing this you don’t knwo where to what level to start training programs at. I have seen many assumptions about teams turn out to be completely wrong and what happens is that we end up with an ineffective learning program. Either because we have started at a level that is too high or very often a level that is too low – which results in engineers having to repeat what they already know. (2) The second step that most orgs miss, is to make the engineers WANT TO go through the learning program. You will all agree that no one learns anything unless they have some real interest in the topic. So I will talk about things that we have done at orgs to motivate and even incentivize engineers so that they themselves start caring about security. The final core step for upskilling which, as I said, most companies try and do is have a learning program. However, two key aspects of running a learning program so that it is well managed and effective are: (1) have content that is interactive and retains interest – you don’t want the learner skipping the content, so have quizzes in between; provide super relevant examples that they can relate to; make them interact with the platform so that they are not just sitting and staring at a screen. (2) We’ve also found it useful to include quizzes and short exams at the end of learning modules; it helps in measuring skill at the individual level. (3) The learning program should track the progress of individual learners. This is very important to help you gauge the actual usage of the program – I’ve seen many learning programs that only exist – but are almost never used. Lack of usage is a good indicator that we got something terribly wrong in the first two core steps that I’ve just described.
- So now we come to the agenda of this webinar in which I will present the lessons I have learned. Today, I will talk about how we have used CTFs to generate interest and also gauge the level of security knowledge for individuals. For those of you how are not familiar with CTFs; they are software products that purposely have security defects in them so that participants can try to find them and learn in the process. I will next talk about some lessons I have learned in creating effective learning programs. In which I will talk about the importance of using the determined level of individuals to create a learning path for them so that the content is both interesting and relevant to them; and also about tracking progress and scores for other management activities. Now, before we begin to discuss upskilling our teams, we have to first upskill ourselves a bit about the methods that I am proposing today – so we will start with quickly understanding how attackers attack our products and what our teams can learn and adopt from them.
- Attackers don’t have any kind of superpowers; but they do behave differently and in these three slides we will see what we can learn from them. So how to attackers behave differently;. The main thing attackers do differently is that they turn Use-cases into Abuse-cases –this is the fun part, where you can let your imagination run wild and explore the features of a software and dream up various ways in which you can abuse those features. In order to do this they: Leverage tools –but anyone can get those tools; what else: They view software differently – it takes a different mindset, is only partly as glamorous as movies will have you believe. Attackers know that nothing is unbreakable, everything has an attack vector, with varying degrees of complexity and challenges. This is something that we will want our engineers to understand. Speculate code & design behind features – it helps to be able to speculate on the decisions made by the developer, what common mistakes might they have made, what software design flaw made by the architect are we observing in this particular feature. This is something that our engineers do not need to do since they are aware of the design and code of the product. Observe software & take great notes – this is the laborious part, you never see attackers in movies making observations and taking notes – because it may appear to be boring. Attackers do this on repeat really. They spend 90% of their time making observations and taking notes.
- This graphic here; this is what attackers are doing 90% of the time. They are taking a feature, a use case, of your product and trying to turn it into an abuse case; An abuse case which harms your company and your customers and is also usually beneficial for the attacker. An attacker generally pick a use case on which they have speculated that you have made a mistake in either code or design. They will then execute that Use case and make observations about the environment and the outputs of the software. Next step is to modify the aspects of the use case, generally by tweaking data sent from the attacker to your software, and then executing that modified use case. Again, observing the output and environment to see if it had the desired effect; if not, they will refine their attack parameters and try again....and again and again...until they succeed. And upon success they will have turned a use case into an abuse case. This is what we need our engineers to understand; not necessarily how to go throught he entire process and become hackers themselves; but understand what the attackers go through. Once that is done, the engineers will themselves be able to code and design products that can make it much harder for attackers to convert use cases to abuse cases. If we have time at the end, I can show you some examples of this on a vulnerability database: http://vuldb.com
- ...Now that we’ve upskilled ourselves about this. Let us see how CTFs and Courses can help achieve these goals!
- We’ve found the best way for our engineers to understand the points in the previous slide is to occasionally put on their hacker hats on and participate in a CTF program. CTFs are great because they can be a team activity where many teams in your company are competing with each other. I also recommend making up mall teams which cover different roles in a product team. For example Architect + Dev + Tester This helps them together realize the different aspects of the product that can be attacked. Now let’s look at some key lessons learned from my experience:
- SecGen: Create randomly insecure virtual machines, lab environments, and hacking challenges, so students can learn security penetration testing techniques.
- Premium Customer Success Program Shifts the burden of program rollout and optimization onto us Role-based learning paths