Are you the Achilles heel to your team’s software security efforts?
Think about it for a moment.
Many of the software exploits we hear about in the news can be traced back to security breaches and issues caused by poorly developed and designed software.
In 2020 I think it's going to be crucial to develop the right mindset as it relates to security in software development.
Be honest; if you’re like me you’re probably hoping there’ll be an automated tool that can help with this big problem.
But what if it’s not a technical problem, but a people problem instead?
So how can you get your company to care about security testing?
Let’s dive into why shift-left security testing is so important with security expert Kevin E. Greene.
Security Testing in 2020
The goal is to get the entire team to think about ways in which hackers can attack your software.
It's essential to start thinking about formal threat modeling, misuse, and abuse cases, and to get developers and architects to carefully consider the design decisions they make upfront.
Kevin E. Greene believes that security requirements need to be part of the acquisition strategy or solution.
Try to codify those aspects of security all the way left into acquisitions and requirements so that when you do develop or procure a system, you can test for those requirements that have already been built-in. This will help reduce risk, as well as reduce the attack surface that is known to be associated with software development application security.
Whole Team Security Testing Effort
The most critical aspect is to get the entire team talking about the product as a whole.
This “whole team” approach should include product owners, product managers, developers, engineers, testers—you want everyone to be thinking about security. This will ensure that everyone is sharing responsibility regarding how to improve security.
See the difference?
And it's not just the security organization or team's job to do security for everyone. It's collectively thinking about security and building the right mindset. The technology stuff is secondary.
Having this type of “security” mindset is important because you can't build security. Similarly, you can’t build testability into a system that wasn’t designed to be testable from the outset.
The goal is to have appropriately formulated security requirements that are tied to sound design principles, and to use those design principles to develop an architecture or system design.
Developers Code for Security
Developers must be aware of security and design principles so that when they are coding, they’ll understand the impact of their coding or refactoring on their daily activities.
Also, don't forget about developer training around defensive security programming, and understand ways in which attackers are trying to attack a particular application or system.
You want your developers to really understand secure coding principles.
Most development nowadays isn't so much about hardcore coding as it is about gluing things together.
Let's be honest: there's not a lot of software development going on.
It's more about mixing and matching existing open-source components and frameworks to develop and engineer a system.
Security Hygiene
As a result, it's essential to understand the hygiene of a component.
This includes understanding how those components can potentially expose an attack vector or surface that could lead to a security breach.
Your development team needs to understand how to start with a good component in terms of having good hygiene.
Typically, folks have based hygiene on Common Vulnerabilities and Exposures (CVE) scores or reported entries to the national vulnerability database.
But Kevin recommends taking it a step further by trying to emphasize the need for developers and organizations to focus on the defect and attack rates of those components and software.
You can get a component that has pretty decent hygiene or track record in terms of the number of issues and vulnerabilities associated with it, but that doesn’t necessarily that means that over the next six months it will maintain that level of hygiene.
It's essential to have an idea of what will happen if you choose this component. What will be the overall, upper-level effort to maintain it over the course of the system lifecycle?
It's important to keep these things in mind as you develop software.
Don't Be Your Teams Achilles Heel
Sounds easy enough, but sadly, folks can become their own roadblocks in moving things forward when addressing security.
Our team members can become liabilities in our own security development process, because they're resisting change. They're not, by and large, doing the right things to ensure that we develop good practices, and good systems that people can trust and rely on.
Think I’m exaggerating?
Look at it this way.
What happens if someone on your team invades your customer’s privacy?
Or provides a backdoor or other low-hanging fruit that an attacker can use to compromise your system?
We’ve got to get away from being our own Achilles heel to software security engineering.
Shift Security To the Left in Your SDLC
Kevin’s final piece of advice is that we should all develop the mindset of what it means to shift security to the left.
In shift-left, we have to move way past continuous integration all the way into acquisition.
While many consider shift-left as simply a catchy phrase, I believe it's a mindset that emphasizes the need to think about security in all phases of a software development lifecycle.
For example, are you working with acquisitions to get the right language into the contract? Are you ensuring that when awards are made, you’re getting good suppliers who have a track record of producing good systems that have quality and security as part of it?
You should be building the requirements and turning those requirements into a good design. You should then take that design and implement the design correctly writing secure code.
Fortunately, you have tools that you can model to help your team look for those issues that matter the most.
Following this approach will help your team to deliver secure software at speed.
This is a way to accomplish that, while not clogging up the CI/CD pipeline to the point where people won't even test their software.
This is an incentive to really get people thinking about security at all phases, as early as possible in the software development lifecycle.
Shifting left has to evolve into something more than just a catchphrase.
It needs to be the mindset of the entire product team; everyone should be thinking about possible ways in which software can be attacked, misused or abused.
If you do that, you can be on your way to improving the overall hygiene and health of the software that is powering every aspect of our lives—our cars, hospitals, banks—you name it.
Let that sink in.
It’s our duty to look out for and test security and other issues that could potentially impact the world if we don’t take our software development seriously.
If we can shift left with the right mindset, I believe we’ll see significant improvements in terms of the overall confidence in the use of software, along with the numerous other side benefits that will be created.
Stay Up to Speed with Security Testing in 2020
Make sure your development team doesn't fall behind in their security testing efforts in 2020. Make sure to register to the new TestGuild Security Testing podcast:
Or register for the next SecureGuild online conference dedicated 100% to helping you succeed with all your security testing efforts.
