SwA isn’t a new concept; applications have been evaluated for their security posture through manual and automated methods for quite some time. Unfortunately, the bad guys have been more efficient at finding and exploiting vulnerabilities than the good guys have been at finding and fixing them.
Worse still is that when the good guys find vulnerabilities, this doesn’t always translate into effective remediation or prevent the propagation of similar vulnerabilities in future releases of the same or different applications.
And these concerns apply to all applications. While Web applications have received most of the recent attention where vulnerabilities are concerned, SwA plays a critical role in mature development processes regardless of an application’s operating environment.
There are two fundamental concepts of software assurance that must be embraced before you have a chance in the wild against determined attackers: (1) thorough and effective analysis and testing of the application and (2) SwA-savvy developers who either avoid introducing the vulnerabilities to begin with or effectively remediate them once found. I don’t mean to oversimplify SwA, but this really is the bare minimum to get you started.
Notice that I mentioned analysis before testing? SwA analysis doesn’t begin and end with scan results. In fact, it’s estimated that more than 50% of application vulnerabilities are not even detectable with the automated scanning tools currently on the market. Design and architecture are big culprits here. Another significant portion of SwA vulnerabilities can be attributed to the development environments and data handling practices, which also aren’t testable.
Now we’re getting to the crux of the SwA problems facing the world today. This cannot and will not, in the foreseeable future, be solved purely with tools. I wish it were that easy. It would be so nice to be able to run static and/or dynamic scans that provide a definitive assessment of the application’s security posture. But many applications are far too complex for fully automating security assessments.
Software security as a software quality issue.
To think about this in a simpler context, consider it a code quality issue. Bug tracking, bug fixing, regression testing, and user acceptance testing are all critical aspects of mature development processes, and are all significant components of the software development lifecycle (SDLC). So why do SwA practices rarely appear in the SDLC, and when they do, are given much less focus than other areas?
It is significantly less costly to fix or prevent security defects as early in the SDLC as possible rather than waiting until the application is nearly complete to discover and address these problems. In fact, if you begin SwA with the design and architectural phases, the cost is relatively small. Once you look at the QA, testing, and operational phases, the repair costs can become crippling.
Makes sense, right? If you spend a year developing an application that relies on insecure code or an architecture that is inherently insecure, you’re likely to have a very big problem on your hands once you or a third party performs a thorough security assessment.
Here’s another way of thinking about this: Vulnerabilities are essentially defects in the application, but can have much more dire consequences. Vulnerabilities are defects that can sink a company, compromise missions, or endanger a warfighter.
Software assurance starts with software developers.
There are a lot of talented developers out there that translate concepts into applications within very strict constraints of cost, performance, and user experience. They can do this because that’s what they’ve been trained to do.
What they haven’t necessarily been trained to do is to accomplish these same goals in a more secure manner. That needs to change. Developers need to be fully versed in software assurance. The people that write the code should fully understand the security implications that come with their code.
It really is that simple. We can either train developers to write secure code and provide them with the necessary tools and processes to do so, or we can scan their applications and hand them a report that might as well be written in Hackistanese and walk away. If the latter, I can assure you that we’ve wasted their time and ours.
I’m not pointing a finger at the development community for the world’s IT security issues. However, software vulnerabilities are a huge problem and the only people that can address their root cause just happen to be the same people that spend their day developing the applications that connect and automate the world. The vast majority of them have never been introduced to, let alone trained in, SwA. It’s time to start introducing and training them.
(Some detractors still believe that coders should just write code while security folk worry about security. This approach is what has led us to where we are today. If the developers aren’t trained to write secure applications, we’ll never have applications that have security built in.)
Developers are a smart lot. If we present them with a fair challenge, they will prevail. If we’re to ever get ahead of the game in securing applications, we must educate and challenge the development community to only write secure applications.
Software assurance is and will be mandated, but compliance can only ever be achieved by the people who write the code – by building their applications secure to begin with. As it happens, that’s also the most cost-effective approach to securing applications.