Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

The Pros and Cons of DIY Application Security

Technology is pervasive in everyone's lives these days and that only serves to further fuel “The Application Economy”. A typical enterprise company has around 3,000 applications that they have delivered in-house over time, and given the statistic that there will be an additional 111 billion lines of new code written this year, one can expect that application catalog number to increase.

According to Gartner, 70% of all security vulnerabilities are in applications, and the recent mega breaches have proven this to be true. Despite the expansion of the application attack vector, the portion of the total security budget dedicated to trying to prevent such breaches remains at only one percent. 

Do-It-Yourself Approach
The most common approach to security tends to be a “DIY” (Do It Yourself) one, but there can be some challenges around this. Given the vast array of security product/tool choices, many CIOs and CISOs that I have spoken with find themselves in a situation where they have purchased a wide array of point solutions and tools, which in turn lend to more tactical initiatives around application security.

The challenge is that most of these current security products, whether commercial or open source, are extremely targeted in what they do and deliver a myopic view into the overall security posture. The result of this solution sprawl is that the tools and approaches need to be integrated. The conversation then shifts to one around “build versus buy” and the associated pros and cons of each approach.

Given enough resources, many code and application security solutions can be built in-house, and often the approach is overly focused on tactically “stitching” the disparate tools together in what I’ve often described as a “Franken-platform”. And, despite that seemingly derogatory description, many of these projects work initially and are viewed as a success. The ongoing challenge, however, and one of the topics that I’ve discussed with CxOs, is maintaining the domain expertise as well as the interoperability of all of the security tools and API integrations. 

To address the first challenge, it begs the question—do you really want part of your overburdened and often understaffed security team spending cycles on operating the DIY solution, as well as keeping all of the integrated tools and API versions up-to-date?

There is also a good chance that the domain experts who built and operate this platform haven’t completely documented it, and given the constant race for security talent, if that person or team leaves, so does the expertise.

On top of that, this approach typically requires some level of manual intervention. As a result, the reliance on manual efforts and stitching together disparate tools often pegs the developer tasked with maintaining the Frankenstein platform as the single point-of-failure. 

Moving from DIY to Automation 
In order to reach and maintain requisite levels of security hygiene, the strategic approach and solution needs to be automated and continuous. Security tests should be executed at every stage in the software assembly line so that defects and vulnerabilities can be remediated early in the life cycle in order to deliver a higher degree of security assurance.

Cyber teams need to “shift left” and seamlessly integrate into the applications’ CI/CD pipelines and direct their time and efforts at collaborating with software developers instead of maintaining a suite of disparate tools and homegrown approaches to stitching them together.

The effectiveness of the approach needs to be measured with the goal of continuously improving the overall resiliency of the application. Some key metrics to consider are: Internal Rate of Detection (IRD) or how early and fast are you detecting vulnerabilities, and Internal Rate of Remediation (IRR)—how long does it take to fix what is found. Resiliency is increased by having those two be as close to each other in time as possible.

To conclude, I’d like to reiterate that as you evolve your security strategy, consider thinking strategically about an approach that will help to improve your resiliency and overall security hygiene. Assess what you are building and if it will scale with your strategy as your people, environment and business goals change overtime.

Application security, done right, is continuous, integrated and scalable. A DIY approach is unique, possibly useful in the short term but fragile overtime. Leveraging a platform to execute your strategy optimizes security and development time and the tools you are already invested in.

What’s Hot on Infosecurity Magazine?