Developer Security Awareness: How To Measure

In the previous post (What Topics To Cover), we laid the foundation for your developer security awareness-training program. Now let’s talk about the metrics we can collect to help improve our program.

It’s all about the metrics

As we previously mentioned, establishing a common baseline for the entire development team would be helpful. A comprehensive application security assessment should be performed before awareness training begins. For example, the SANS Software Security team has a free web based security assessment knowledge check: A knowledge check such as this allows you to create a baseline, establish core strengths and weaknesses, and steer the types of training to be provided.

As the awareness training takes place, knowledge checks are helpful at the end of each module along the way. These short quizzes ensure each student understands the topic that was presented and provides immediate feedback with any problem areas. The organization can use these metrics to track each team member’s progress and understanding along the way. Reports can be generated from this data to show how things are moving along, and even used for employee reviews.

The final step is to repeat the comprehensive security assessment again. This time use a similar exam with different questions covering the same topics. Ideally, the results will show improvement from the original baseline. Doing so will prove the effectiveness of our developer awareness program, and guarantee our funding as we onboard additional team members. Most importantly, the knowledge gained from the training program will help protect your organization with secure software moving forward.

We hope this series has helped form a vision for your developer security training. For more information, check out the SANS Securing The Human Developer program:

About The Author

Eric Johnson (@emjohn20) is a Senior Security Consultant at Cypress Data Defense and the Application Security Curriculum Product Manager at SANS. He is the lead author and instructor for DEV544 Secure Coding in .NET, as well as an instructor for DEV541 Secure Coding in Java/JEE. Eric serves on the advisory board for the SANS Securing the Human Developer awareness training program and is a contributing author for the developer security awareness modules. His experience includes web and mobile application penetration testing, secure code review, risk assessment, static source code analysis, security research, and developing security tools. He completed a bachelor of science in computer engineering and a master of science in information assurance at Iowa State University, and currently holds the CISSP, GWAPT, GSSP-.NET, and GSSP-Java certifications.

Developer Security Awareness: What Topics To Cover

In our last post (Is Security Your Top Priority), we discussed improving the security of our organizations with security awareness training for development teams. Now let’s talk about the security training we should provide.

What Topics To Cover

All team members have different knowledge levels of the various threats facing our applications. Some have received little or no application security training. Some may have taken a few courses in college that mentioned some common security issues. A few may have received in-depth application security training from a previous employer. The only way to guarantee everyone is on the same page is to establish a common baseline for all team members.

The first step is covering the fundamental aspects of application security. In this phase, introduce all team members to the attacker. Explaining who will be attacking their applications, along with their motivations, and introducing the attack methodology and the steps an attacker will take to compromise their applications will help them understand why security is important. By the end of this topic, everyone will understand the role they play in protecting the company’s assets.

Next, cover the secure software development lifecycle. This is where security is integrated into the daily tasks handled by the development team. Introduce the development team to secure design techniques. Show them how integrating and automating security during construction and deployment will help secure their applications.

When everyone has a fundamental understanding of application security, focus on the different types of applications each team is responsible for. Ensure groups responsible for web applications understand the OWASP Top 10. Anyone working on mobile applications must take mobile security training. Be aware of emerging technologies, such as Cloud and HTML5, and ensure they are being adequately covered.

Finally, narrow the scope even further. Introduce the development team to platform-specific secure coding training. If mobile applications are being written using iOS and Android, make sure the development team understands how to use the security features provided in those frameworks. Address the other development teams supporting web sites using other platforms, such as Cold Fusion or PHP, in a separate training effort. This phase is best received if the platforms being covered are relevant to the audience.

This is a lot to cover, but no one said application security is easy. Taking the time and effort to cover these topics is the first step towards building secure software! In our final section, we will take a look at the different types of metrics that we can collect, and how they can help steer our security program.

Developer Security Awareness: Is Security Your Top Priority?

In the last post (Developer Security Awareness: Why Do We Care?), we discussed what we should take away from publicized security events. Let’s discuss why we are failing, and what we can do to make it better.

Why are we failing?

Software has become a requirement across all industries in today’s world. Every market is included, from finance to travel, industrial, healthcare, retail, entertainment, and many more. Everyone is realizing the benefit of automating tasks and accessing information using laptops and mobile devices from home, the office, or virtually anywhere.

The teams working on these applications are given rigid deadlines and are working long hours to meet the demands of their stakeholders. During these times, security vulnerabilities are accidentally introduced as changes are rushed through the pipeline to provide that next groundbreaking feature to the customer.

Many years as an application security consultant have allowed me to see firsthand how often these vulnerabilities exist in high profile applications. The same high-risk vulnerabilities continue to show up year after year and application after application. The types of vulnerabilities that open the door for attackers to breach our organizations are accessible to anyone that registers for an account in a web site. In many cases, the vulnerabilities are buried in application code that hasn’t been modified for years, and often only require a few minutes to fix.

Unfortunately, prioritizing enhancements and feature releases over security continues to allow these vulnerabilities to be deployed and lie dormant until it is too late. As long as organizations continue to accept bolting on security features post-deployment, project and development teams will continue to view security as a low priority.

How can we improve?

The first step in changing the security culture of an organization starts at the highest level of management. To quote Bill Gates, the co-founder and former CEO of Microsoft:

“When we face a choice between adding features and resolving security issues, we need to choose security.”

This quote provides a perfect example of an organization dedicated to changing its security culture to be the top priority.

The second step requires the organization to provide all employees with the resources they need to create secure software. To build their security knowledge, project and development teams should be required to take security awareness training that illustrates the hostile environment their applications will be exposed to after deployment to production. Upon completion, everyone involved will understand why security is important and remain engaged as security discussions occur.

In the next section, we will explore the types of developer security awareness training that should be provided.

Developer Security Awareness: Why Do We Care?

Laying a foundation for developer security training is not an easy task. Those of us that have worked in the information security world long enough have seen the roadblocks:

  • Development teams do not have enough time
  • The project does not provide enough funding
  • The organization does not have the expertise to create a training program
  • It’s more important to release new features.

Anyone reading this post has likely heard reasons similar to this for not taking action. In this multi-part blog post, we will show you how to get started and what developer security awareness training could look like inside your organization.

What have we learned from the past?

The headlines from the past year alone should be more than enough ammo to convince anyone in your organization that you NEED an application security program.

  •  The Heartbleed OpenSSL bug affected web traffic for millions of applications, devices, and operating systems. Many security experts classified the zero-day vulnerability as the most catastrophic software bug known to date. Within a few months, Heartbleed was used to attack a private healthcare network and extract millions of patient records.
  •  Travel industry web sites were targeted, resulting in major casino and online travel agencies being breached. Attackers were able to steal employee information along with millions of credit card numbers, email addresses, and password hashes.
  • Social media also took a massive hit as hundreds of celebrity accounts were compromised and hundreds of thousands of “deleted” pictures were posted online.
  • Point of sale systems continued to be successfully breached, resulting in millions of consumer credit card numbers being stolen from several different companies.
  • To close out the year, we saw malware take over large corporate networks, extract gigabytes of information, and hold entire companies ransom.

The above examples are only a small sample of the information security specific incidents that seemed to make the headlines every week last year. While the attacks, motivations, and methods vary, I think the one thing we can all agree on is this:

Security is everyone’s job.

The number of security incidents will continue to rise until we properly train our employees, raise awareness, and understand what is at risk. In the next post, we will look at why we are failing as an industry, and how we can improve.