Making security 'baked in' as opposed to 'bolted on' is critical for any company developing products whether for internal use or for profit - but many web developers are not aware of good security practices when coding. What are some considerations security awareness programs should include when addressing the developers within their orgs? Join us as we speak with Arthur Kay who is a 20-year veteran in software engineering and who is passionate about web application security.
the mixed bag of security for developers
Although web developers are a very technically minded crowd when it comes to information and resources around security education there are not many formal avenues for pursuing such knowledge. There is a slow shift happening specifically in the area of the cloud with certifications for AWS or Microsoft Azure but typically there is very little available for general security-specific content geared to the web developer crowd; or the information is very scattered.
The nonprofit foundation known as the Open Web Application Security Project (OWASP) has been working to change that. However, the problem still exists that even with developers who are familiar with OWASP and its Top 10 recommendations for more secure coding, according to Art most developers are "unable to speak very deliberately about any specific attack vector or specific things they might do to mitigate those attacks. So it really is a mixed bag in terms of who knows what; and where do you go to find those resources and are they even relevant to what it is you're doing day to day".
go deep instead of broad
In terms of raising awareness around security for teams of developers, Art recommends to select one area relevant to the OWASP Top 10 and deep dive into that subject. From his experience working in the developer community for two decades, he finds that "engineers are much more interested in going deep on one thing rather than going very shallow on a lot of things." He goes on to suggest taking a particular focus on applying it to your company's specific environment to play out different scenarios and see what might work. This helps teams get their 'hands dirty' with real-life applications while building a stronger understanding on a particular point of security.
Securing an organization involves layering defenses and starting with one aspect to build on over time is definitely a solid part of the security puzzle.
For security awareness managers, Art encouraged them to consider programs geared toward dev teams that focused on just one deep-dive each quarter around the OWASP Top 10, perhaps in an extended lunch-n-learn session, to provide more robust insights and opportunities for learning.
Going on the offensive
In addition to helping dev teams learn to explore more in-depth the topics addressed in the OWASP Top 10, Art also recommends to broaden developers' understanding of security by teaching them a little of the offensive side of the dev coin. Currently, he feels there is not enough conversation happening to help developers understand why certain coding scenarios are a problem, or how they can become a problem. Exploring the 'red team' aspect of different situations and introducing them to applications such as Hack the Box can provide a deeper awareness of the 'why' and 'how' around various security issues developers need to keep in mind when coding.
"So the OWASP Ten is all about the defensive side. This is what you should do to prevent that - but there's not always a lot of conversation about, why is this a problem? How does it become a problem?
And so you start learning the offensive side. Maybe the things that your pen testers would do or an auditor of some sort where you can actually sit an engineer down and explain to them well. [Say to them] 'Here are some of the tools and here are some of the tactics that an adversary is going to be using against you. And let's see if we can't break that access control and gain access to another user's data.'
Those sorts of exercises, I feel like, are very interesting to the engineering crowd. They're really quite eye opening, I think, because people just don't think in terms of offensive security when writing code.
This isn't to say the goal is to make every developer an expert in pen testing and the like, but rather introduce them to the world of red teaming to give them a broader perspective how to think critically for developing more secure code. As a manager, it's important to let your team know these resources exist.
Art teaches such a course that gives a holistic understanding of security from both the defensive and offensive angles as applicable to web and application developers. His course came about after an cursory exploration into security and the realization his understanding of the concepts outlined in the OWASP Top 10 were quite basic. From there he pushed himself to do Hack the Box and in doing so gained a much different perspective on the importance of developing code in a more secure fashion.
To quote Wizer's founder, Gabriel Friedlander, "Secure code is quality code." - and who doesn't want to create more quality code, right? Other resources Art mentioned that can be helpful in introducing developers to the offensive side of the conversation include AWSGOAT, OWASP Juice Shop, Hack the Box and Try Hack Me.This is a way of thinking about software that most of us who are building the software never had to think about.
Cyber Security Awareness training for the dev team
In creating cyber security awareness training specific to the dev team, like most any answer in security, it depends on context and culture. First, consider their environment and what they are building for - for Art he works on building websites and web applications, not embedded software.
Also, consider the code being utilized and craft training that is relevant to that team's particular needs. While there does exist good off-the-shelf content for many, a more custom approach might be the most beneficial. Speak with the leaders of the teams and consider bringing in an expert who can do a deep dive on a particular, relevant topic. It doesn't have to be a paid speaker, it may be as simple as tapping into the security team at your own company and inviting a Red Teamer to walk you through a simulated attack on some of the code similar to the software the team is working on.
Alternatively, if the company participates in a Bug Bounty program invite the researcher who discovered a bug to walk through why they were able to find a particular issue. According to Art, who's a developer himself, these sorts of learning activities are way more impactful than just sitting through a standard awareness tutorial.
One point to keep in mind while inviting these experts in, emphasize to them as they walk through the training to connect it back to the basics around the OWASP Top 10 to better solidify the application of those concepts.
Also, you don't have to think of training in-depth to be just a set moment. Record the session and break it into short, focused clips that you then repurpose as micro-content to reference throughout the year.
"One of the things that I personally learned while I was leading a team a number of years ago was that as a manager of a group of engineers, you have to decide whether or not the professional education of your team members is their responsibility or is that your responsibility as their manager? And I always felt like it was imperative for me as the manager to say to my team, 'These are the things you need to learn' and then also work them them to develop what it is they want to learn."
For those teams who feel short on time, Art suggested integrating simply 5 minutes of a weekly stand up to spark conversation on a particular topic or issue. If it's based on a actual piece of content, give the team a heads up what the content is and that you want to discuss it at the next call. Then set aside just five minutes getting a reaction from the team and walking through the importance of it in relation to your coding environment. Doing this regularly will create a culture where the team feels like this type of security awareness is a priority and they'll begin to actively notice other instances to share with the team.
What about kPIs for security awareness for developers?
Measuring the effectiveness of any training is an important aspect to understand how successful a program is. For a typical security awareness training, many look at the number of phishing reports submitted and what that trend is. However, that's not so easy to do in this specialized environment.
Art recommended one interesting KPI to consider would be to look at the number of bugs being reported by either the users of the application or wherever bugs might be coming from.
"In the context of a program like this, because quality and security are very tightly intertwined, that would be a good KPI to keep an eye on...You'll probably have to get creative to find some of these KPIs [however]. It's definitely not as straightforward as phishing reports or pre-canned content that's in the learning management tool your company chose. It's not going to be as straightforward as that, but I also think your developers will be a lot happier."
It's one of those things where you know it's improving because it's working...if it's working like it should, then you've done a good job."
Connect with Arthur Kay on LinkedIn and while you're there check out our Security Awareness Manager community.
Resources Recommended by Art Kay:
Course: Intro to Hacking Web Applications
Free Chrome Extensions to Improve Web App Security (A LinkedIn post resource)
Other Resources:
October's Security Awareness Month Toolkit
