While assessing software systems of all types a few common mistakes regularly come up. These aren’t mistakes that lead directly to vulnerabilities, but mistakes in how some software companies think about security, that can lead to invalid assumptions, and ultimately which can allow real security vulnerabilities to slip through the cracks.
No two assessments or clients are exactly the same, but by being aware of some common mistakes that continually crop up over time we can start to move software security forward by understanding how to properly frame security issues.
I’ll dive into each of these issues shortly but the three most common mistakes I see in software are:
· Failing to understand the real attack surface of their application. We tend to be reactive to security as an industry. We patch the holes of our sinking ship as the water gets in, but lack the understanding to assess the entire hull or frame to address the deep issues that may crop up in the future.
· Using a static or dynamic automated tool as the sole security assessment. Automated tooling is an important part of a complete security process, but these tools need to be constantly tended to, and they can miss a large number of issues. Augmenting tooling with manual penetration testing and code review is critical for shipping and launching a secure product.
· Involving an external security company too late in the product cycle. Security should be an “early and often” process. This allows threats to be addressed before they become vulnerabilities, which reduces time and cost needed to integrate security into the product. This also builds a more secure product that will be able to withstand future attacks through defense in depth.
Steps to Overcome These Mistakes
It’s easy to point out mistakes and oversights, but there are a few ways I’ll point out that companies can start to remediate each of the mistakes above.
Understanding the real attack surface of an application is a critical step of building a secure system. Often our clients will understand that some data must be protected, but will not understand every way of accessing that data. After a burglary a family may go to the hardware store and buy the best locks for their front and back doors, but not think to lock their windows.
Similarly, companies may protect the avenues of attack they understand – or the most common ones, but attackers will often find new ways of accessing assets; bypassing the common entry points of the application and thereby bypassing the security controls in place.
Additionally, conducting a comprehensive threat modeling exercise is a key process that will help build security into the software development process, helping companies to better understand their attack surface. Threat modeling is a critical security process that helps organizations identify potential threats to a particular application or set of applications, understand what an attacker’s goals might be, and to ultimately validate and mitigate those threats. Threat modeling helps organizations build out scenarios for how an attacker might go about gaining access to sensitive information through your software.
Getting other perspectives on security is also a good way to understand the attack surface. Each new person involved will come with their own, different assumptions that may help identify new interesting avenues of attack.
The second common mistake can be mitigated by understanding the strengths and weaknesses of automated tooling. At Security Innovation we commonly use automated tooling to identify “hot spots” or areas of concern that we want to take a closer look at. We also use the tools to help get a cursory breadth of testing across the entire application. Understanding when to use these tools and what to expect from the results can make them an effective piece of an overall security strategy.
Automated tooling does take some time to get up and running, it’s important to spend time with the tools to help get the best results possible and to train them to reduce the likelihood of false positives. Likewise, once the tool has produced a final report it is important to validate each finding to ensure time isn’t wasted fixing or addressing issues that are not valid.
It is important to understand that a clean bill of health is a good indicator of an effective piece of the security process, just like a compilation completing without warnings, but it does not mean the application is free of security vulnerabilities.
Finally, we are often brought in at the end of the product cycle to “sanity check” the software and make sure there are no vulnerabilities present before the application ships. Unfortunately, there are almost always security vulnerabilities in the software, many of which are critical, ship-stopping issues that must be remediated before the application can go to market.
A team of security experts can always provide benefit to the overall security of the system, no matter what phase of the development lifecycle we’re brought in on, but the earlier and the more often the better. We can review requirements, specifications, and design documents to quickly identify areas that may need more security focus, areas that should follow best practices or areas that can be bypassed via alternate entry points or routes. These insights can be invaluable in the long term when creating a system that is secure from the inside out.
Often a component can be architected in a way that may mitigate major classes of security vulnerabilities. Understanding the threats against the system early may identify key architecture choices that can be made, which can drastically reduce the attack surface later. Alternately, waiting until the product is fully developed may miss these architecture choices, which may result in the need to re-architect the system – a costly and time consuming process that can force the application to slip launch dates and likely frustrate development teams.
If you can prioritize security from the start of the development process, it can have an enormously successful impact on the overall development, test and delivery of that application. That doesn’t necessarily mean conducting a ‘one-and-done’ assessment, but rather building security into and throughout the process along with a comprehensive and timely security assessment.
Summary
Again, no two software security engagements are ever exactly the same, but by identifying some common issues we can more effectively and reliably build more secure software. Once we understand the real attack surface of the application, we can proactively secure the application against current and even unknown vulnerabilities that may come up in the future.
Additionally, it’s important to understand the real benefit of automated tooling to make sure the tools we have are used effectively, and not relied upon as a single point of validation for security. Finally, and most critically, work with a third-party security vendor early on, to review design and architecture documentation and provide critical insight around your application’s security posture.
If you can use a few tips from this article as a set of preventative measures in avoiding common mistakes and oversights, you will be able to better leverage a full application assessment and streamline the expert recommendations that come as part of that process. This will help you reduce short-term and long-term risk, and in taking a proactive approach to building security into your overall software development process, you will improve your company’s security profile and avoid common application security mistakes that can impact accuracy of scan results, software delivery, and having a false sense of security.
Joe Basirico heads up Security Innovation’s security engineering team. The team performs high-level, comprehensive software assessments for Fortune 1000 organizations and large government agencies. Joe can be reached at jbasirico@securityinnovation.com and is on Twitter as @joespikey.
