Is Your Security Team an Enabler or a Disabler?

By | 2019-01-14T10:55:25+00:00 January 22nd, 2019|

What is the purpose of sending your children to school? Apart form compliance with truancy laws, you want your children to learn what is required to become productive members of society. Challenges will come up in this process. It’s how you meet these challenges that has a large impact on the end result when your child graduates.

What do you think is the best way for parents to help children become ready for the real world? And what does this have to do with helping software developers build secure software? Let’s find out.

Disabling Growth By Working Against Each Other

Let’s get one thing out of the way. In the school metaphor, the developers are not the children. Please no angry comments about security professionals thinking they’re better than developers. Instead, the best choice for the role of the child in this metaphor is the software itself. Both the parents (developers) and the teachers (for arguments’ sake, the security team) want what’s best for the student. At least, they should.

If the parents or teachers of a student don’t feel responsible for the desired outcome (a productive member of society), the student is the one who suffers. When development and security teams don’t feel responsible for delivering secure software, the code suffers.

Some developers think security is someone else’s job. They write the code and the security team needs to check it and tell them if something is wrong. Unfortunately, this actually perpetuates a “code cop” mentality in security. They come into your codebase to inspect your code like border patrol and tell you what you did wrong. Then they leave the developers to fix it.

When a child is not doing well, a parent should be notified. However, the teacher is the expert and should have a plan in place to help the child get back on track. If a teacher just says, “Your child is not doing well and needs to get better at math” and then hangs up the phone, you’d be pretty upset.

Similarly, developers are frustrated and slowed down by security teams that only drop 10-page pdfs full of vulnerabilities that need to be prioritized and fixed. Even automated scanners incorporated into the build pipeline can create loads of noise for developers. If developers are drowning in notifications in their email or are viewing false positives along with real vulnerabilities, frustration will soon follow. After that comes disengagement, and then the code suffers.

Training is another way security teams can slow down developers. You can either send them to boring classroom or computer-based training courses all of the time, which can be seen as annoying when done too often (not to mention expensive), or give them training once a year for compliance reasons and don’t bother otherwise. There’s a better way to do training that does enable your developers without getting in the way.

What is required is a desire on both sides to work together.

Enabling Growth By Working With Each Other

It’s important for parents and teachers to actively work together as a team to make sure the student learns what is required and pushes past challenges that may seem daunting. This encourages growth and success.

Your security team can either help developers to deliver secure software or impede them. Security teams need to work together with development teams and give them the tools necessary to deliver secure software.

Developers should care about security and should be held responsible for it. However, security teams can help developers to become more engaged by working with them and giving them the tools they need to deliver secure software.

Service-focused security teams create an ideal environment for developers. As more companies adopt agile and DevOps practices, it’s becoming more and more important to allow developers to write and deliver code with as few interruptions as possible.  When security teams focus on delivering services to development teams, they’re better able to scale with the growing number of applications and deliver predictable results. Some examples of security services are design reviews, security testing, and threat modeling.

Service-based teams and security tool automation contributes to the developer’s ability to deliver software without friction. But the best way to stay out of the development team’s way is to give them the tools to prevent vulnerabilities from happening in the first place.

Interactive Training – The Tool for Enabling Developers

Developers will learn best by applying what they learn, not reading slides or learning only high-level concepts. The best way to learn is to let the developers “get their hands dirty.” Cloud and container technologies have opened up an exciting new world for training. Security teams can use this new world to enable development teams to build secure software without security teams interrupting their work.

Containers allow an entire realistic programming environment to be spun up in a matter of seconds. In these environments, developers can be presented with realistic problems to solve and vulnerabilities to exploit. The developer first learns how to exploit vulnerabilities, then learns how to fix them. Now, when confronted with security problems in their day-to-day work, developers know how to handle them.

When a parent and teacher work together, the child can be helped to become a productive member of society. Behavior problems or problems with grades are not fixed after the events occur. Rather, the parent and teacher work together to find the root cause of issues and to help the student overcome them. The goal is to prevent behavior problems.

Similarly, when security teams and developers work together, we can get to the root cause of security vulnerabilities. Developers need to be engaged with security and helped to keep it in mind while they’re writing the code. If the code is written in a secure manner from the start, it won’t be treated as high risk with strict measures taken to inspect it before release (measures that get in the way of delivery). The goal is to prevent vulnerabilities.

It doesn’t happen overnight. There will be adjustments in workflow and culture to truly help teams work together. However, it is possible for security teams to enable developers by giving them the tools they need to write secure software from the start.

  • Give your developer realistic scenarios
  • Train your developers using the languages and frameworks they use in their day-to-day work
  • Customize training to prevent those nasty vulnerabilities that keep coming up
  • Establish a secure coding baseline for new hires to prepare them to write secure software

Make sure your security team is a team of enablers, not disablers.

Sign Up for Updates