At some point, your company is going to get the security wake-up call. Whether it’s a breach or an inquiry from an important customer that triggers it, your executives are going to call you one morning, demanding you focus on security in the development of your product.
The goal is simple enough – fewer vulnerabilities and agility in responding to issues – but the development of a Secure Software Development Life Cycle (SSDLC) is not an overnight kind of thing. Think about what it takes to be consistently developing bulletproof products and turning around fixes on a dime.
We’re talking knowledgeable, trained staff. We’re talking automation. We’re talking penetration tests and time allocated to respond to them.
Given all of the investment required, the natural question is, “Where do I start?” Most likely, your first impulse is to go after training – after all, you can’t write secure software without engineers who know how to write secure software, right?
Sure – training is never a bad idea, and there are certainly options out there, both online and live, but it comes with many challenges:
- Acquiring training outside of your company is can be a hit-and-miss and expensive. Did you get a good instructor? Did you pick the right course? Are you willing to pay thousands of dollars to give it a shot?
- Building it inside your company might be more expensive. What’s the actual cost of having your senior engineer produce a training course on cross-site-scripting? What about the opportunity costs?
- If your engineers don’t use the information, they won’t retain the information. Remember all of those history classes you took in college? Yeah – neither do I. How are you going to make sure the information sticks?
Rather than beginning with the training, start with the doing. While it certainly isn’t true for all engineers, it is often true that engineers learn by doing. Why not focus on applied activities that force awareness and drive your engineers to seek training where necessary? Here are a few suggestions:
Your developers consider themselves professionals, so what do professional developers do? They design! Threat modeling is an avenue of design that is centered around security. Developers are asked to think about the system and draw it out with respect, not to functionality or scale, but with respect to avenues of potential attack.
By asking your developers to design to prevent attacks, you are essentially asking them to learn about those attacks and best practices for mitigation. This challenges them to learn and seek security information in order to solve a problem, which is what developers enjoy doing. If you’re successful, you won’t have to force training down their throats – they’ll identify what they need and bring it to you.
Identification (and Testing) of Security Mechanisms
This activity is aimed squarely at your quality assurance (QA) organization and represents a subtle change in the way that requirements are defined. By requiring the identification of security mechanisms, you’re shifting from a common way of creating requirements – “we need users to authenticate using Lightweight Directory Access Protocol (LDAP)” – to a manner that recognizes the actual security goals – “we need to prevent unauthorized users from accessing sensitive data, and the mechanism we will use is LDAP.”
The result is that your testers are driven to no longer think about “security testing” functional mechanisms, which will lead to nebulous results at best. They’re led to think about functionally testing security mechanisms – and functional testing against known requirements is something every tester knows how to do. It will also encourage research and training to ensure that the goal is actually being met with the mechanisms in place – is that data really inaccessible?
Requiring the identification of security mechanisms plays nicely into the Threat Modeling exercise. As your team identifies potential threats, they will need to identify the mechanisms to mitigate the threats and the behavior of those mechanisms. Having QA in the room for those discussions can be invaluable.
I know. I know. Testing security into your product will never work. By the time your product has hit the pen testers it is already ridiculously vulnerable. You need to have the development practices built-in ahead of time.
But then again… when your developers get overrun with issues from a competent pen testing group, they’re going to learn a lot about security in a big hurry. The training program you sent them to might have shown them how to make an alert box appear inside a website vulnerable to an XSS attack, but the pen testers just owned their application using the same mechanism. Which is going to get their attention?
Testing in this way is not cheap but if you have the budget to provide this kind of wake-up call to your developers, it’s not a bad way to start.
Starting with any of these activities sends the message of, “I’m going to expect you to apply this. Tell me what you need to know in order to do so.” For many engineers, the doing is what makes it stick.
- Are You Threatening Me? A Tutorial on Threat Modeling
- The Ever Expanding Trust Boundary: To Infinity and Beyond
- Is Third-Party Risk Software Worth It?
- Threat Mitigation and the 20 Critical Security Controls
Check out Tripwire SecureScan™, a free, cloud-based vulnerability management service for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology – and it detects the ShellShock and Heartbleed vulnerabilities.
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Image courtesy of ShutterStock