For the past few years, a number of us in the security space have been talking about (1) the criticality of building secure applications; and (2) the importance of auditing open source components for security flaws. If you have not been following along, applications deployed over the Internet are a leading target, if not the leading target for sophisticated attackers. This Secodis blog entry cites the Verizon 2017 Data Breach Report indicating that 29.5% of breaches where caused by web application attacks, and the Sonatype 2017 State of Software Supply Chain Report, indicating that 80 – 90% of an applications are built from 3rd party components that often contain critical vulnerabilities.
While this could be construed as bad news, there is some goodness there too. Increasingly, the problems are getting documented, and solutions are being developed. In 99% of cases, the purpose of an attack is for the attacker to ultimately gain access to high value information that can be extracted and then leveraged or sold for money. We believe that effectively defending data starts at the database and works outwards, where the next level of defense needs to be applied to the applications that talk to the data.
The proliferation of data sources and data repositories and the classes of code used to do something with that data can be mind boggling. Applications that collect data entered in forms now account for a relatively small amount of the data that organizations collect. In addition to mobile communications devices, there are massive numbers of autonomous and semi-autonomous devices coming on line to collect data that are either statically positioned or mobile either by virtue of being attached to something that moves or having their own source of propulsion. This data is being transmitted and collected in large databases, data warehouses and data lakes, and being processed in a variety of ways by code that has wildly variant security characteristics.
From an engineering standpoint, this becomes a classic case of break the problem into pieces, rank the pieces from a risk perspective and address them in order of risk, high to low. In the realm of what can we control, I would start with the observation that most applications your developers build contain vulnerable third party components. An analysis by Fortify reported in the Microfocus Fortify 2018 Application Security Research Update identified “434 CVEs reported across the 293 external libraries which affected the 651 applications” analyzed in 2017.
Unfortunately, you are likely to have an installed based problem, like Equifax did. When you have large systems dependent on shared components, it can be frightening, not to mention costly, to consider upgrading those components to patched versions (when, indeed, there are patched versions). As we have seen, it can be more costly not to do so.
From a software and systems architecture standpoint, this argues for initiatives that break large systems into smaller components that are invoked via standardized APIs. This is what “microservices” are all about. There are a number of ways to identify components in your system that contain vulnerable components (for instance, WhiteSource, Black Duck by Synopsys, Sonatype and Contrast all provide such capabilities). It is much easier to upgrade those components in microservices, where you can “simply” replace the entire microservice with an updated version that contains current components.
The next area you want to attack is developer education. If you look at the Veracode State of Security Focus on Application Development, point four in the Executive Summary is “eLearning has a big impact on remediation”. They qualify their assertion with “this may be correlative rather than causative”, and I agree. I believe the causative factor is management promotion of secure development strategies, which includes tying vulnerability bug counts to compensation and encouraging developers to learn about application security. An organization that promotes security as an important “feature” of its products, and structures processes to make those products more secure is going to be more successful in that regard. It seems obvious, yes?
An important resource in this area is the Open Web Application Security Project (OWASP). OWASP provides a large number of free resources as well as myriad opportunities for developer education and interaction. If you look at their projects page, you will see 133 subprojects. Not all of them are active, but many are and they suggest the breadth of inquiry in the application security field.
Earlier I suggested that moving to a microservices based architecture can be an important step in improving your application security profile. This may be controversial recommendation, given that a number of vulnerabilities have been associated with containers.
Sysdig has published a really good article (actually a longish blog post) in this regard. As the man says “there is no magic bullet here other than keeping up with the state-of-the-art Docker security practices, but there are a few container-specific security tools that can help giving battle to all these Docker vulnerabilities and threats”. Look, the benefits of containerizing infrastructure are so compelling that significant players are doing it, and they are developing practices and tools to address the issues. Vendors see this, and they are developing products to support these initiatives. We need to follow along and make some selective choices about tools and wise investments. This is an area where we can help.
I run into a lot of people who tell me that their company has security covered because they use a pen(etration) testing service. It has always seemed that that is the cart before the horse approach to application security. If I want to pen test and find vulnerabilities, I can. However, I’m not going to get the coverage that I need, nor is pen testing based on any kind of a risk analysis, which is the key to getting a decent ROI of any security effort.
In any case, it looks like while mobile application security is another huge area of challenge, I’ll need to address it in a separate post.
In closing I’d say that it is possible to create applications that are reasonably secure, but you need to make it a priority from the outset. Like any kind of quality, you can’t test security into your applications, it needs to be baked in from the outset, and considered throughout the product lifecycle. We can help with training, best practices, tool selection, and custom secure development. Contact us for a free assessment of your current state.
