As a security application development lifecycle is constantly changing, developers will be called on to work with new tools to reduce flaws in their code that could make their programs vulnerable to attack by threat actors. Those tools, though, can come with costs that aren't immediately apparent.
For example, detection-based tools can distract developers from their primary tasks and lead to costly losses in productivity and increases in overhead expenses. Absorbing the cost of a breach is inherently more financially disruptive than paying for cyber security that prevents breaches, but the hidden costs can cause a budget to increase significantly. In this post, we will cover the cost of security tools, varying from human capital to analysis tools and how to navigate each roadblock.
On the balance sheet, these tools can appear as advanced threat detection applications, detonation environments, antivirus programs and white and blacklisting, etc. But the costs don't stop there. There are human capital costs.
On average, organizations spend an average of $79.61 per user each year for ATP tools.
For an average 2,000-person organization, this equates to an annual spend of $159,220
Meanwhile, SOC teams triage 796 alerts per week, taking an average of 10 hours per alert—that’s 413,920 hours across the year. When you consider that the average hourly rate for a cybersecurity professional is $39.24, that’s an annual average cost of more than $16 million each year.
Depending on how fine an organization sets the sensitivity of such tools, they can create an avalanche of alerts—as many as a million a year—for a security team or developers to triage. What's worse, most of those alerts—75 percent by some estimates—are false positives.
Organizations are spending money and time to manage these alerts,
triage security events, rebuild compromised machines, and patch on the fly.
Excluding the cost of using third parties or overtime, each year the cost of developers and IT teams working time equates to:
■ $16,242,220 to triage threats
■ $96,059 to rebuild compromised devices
■ $30,607 to issues emergency patches
That’s a total spend of $16,368,886 every year.
Static code analysis tools that identify security flaws can perform automated scans during the software development life-cycle. However, some of these tools can slow down the process and add time to when an application is delivered.
It's also important to be aware of the limitations of SAST tools. A study by the National Institute of Standards and Technology's SOMATE Project found that static tools were able to find "simple" bugs in code but failed to find vulnerabilities that require a deep understanding of code or design.
For example, when a SAST tool was used to scan the popular open source software Tomcat, warnings were generated for only four of 26 Common Vulnerability & Exposure entries. In other words, if an organization produced an application like Tomcat and it depended on a SAST tool as its primary application security application, its software would be delivered with 22 of 26 vulnerabilities intact.
Open source tools have steadily gained popularity among security practitioners for a number of reasons. They can be customized to fit an organization's needs. They offer a way to avoid software licensing or subscription headaches, as well as vendor lock-in. And because they're distributed without charge, they sometimes can save a business money.
If an organization's security tools are friendly to DevOps, most security tasks will be performed automatically in the same pipeline as the one used for producing the app. Only security issues that require human intervention will be flagged for developer action.
Tools and agility alone, though, don't make DevOps and DevSecOps work, Laine noted. "It's those things, plus a culture of respect and culture of collaboration," he said.
There are also hidden costs connected to these tools.
Open source software doesn't always have intuitive interfaces so it can be difficult to learn. That means training may be necessary and reduced productivity can be expected as users advance up the learning curve.
That's especially true when developers are asked to perform security tasks earlier in the application development lifecycle. Many developers have limited experience writing secure code. In addition, creating consistent, repeatable processes that enable developers with a variety of skill sets to find and fix security flaws can be challenging.
If the interface for the tool has to be redesigned, that's another expense that has to be taken into account depending on the software.
The tools can also be challenging to install. If an organization has a strong IT department, that might not be a problem. If it doesn't, outside help may be necessary. That kind of help can be expensive, and varies considering the current IT team infrastructure and available tools.
Even with a strong IT presence, open source tools can require large time commitments from an enterprise.
The same is true for customization. If an organization has the IT chops to fiddle with an application, an open source tool may be able to meet its needs. If not, it may find itself buying add-ons to get a job done or worse, upgrading to a "premium" version of the tool, which comes with much of the baggage—and expense—of a commercial solution.
Support, too, can be a problem. Unlike commercial software, help isn't a phone call away. If something doesn't work or breaks and a shop doesn't have an IT department or in-house tech guru, more expenses will be incurred.
Granted, the idea behind open source software is its community provides the support that in the commercial world is found on a helpline. Not all open source projects have large communities, though. Even for those that do, finding information can be challenging. It may require combing through thousands of postings written in forums over years.
What's more, the quality of the postings can vary. They are written by people with a variety of experience and knowledge of a tool. Some may even know less about an application than the person seeking information about it.
Remember, too, that the costs of an open source solution are ongoing. Resources have to be continually dedicated to updates, patches, maintenance and training existing and new users. Failure to do so can have disastrous consequences, as Equifax found out when it failed to keep its Apache Struts web framework up to date.
As organizations try to get greater developer participation in securing their applications, they'll need to provide those developers with tools that are intuitive to use or better yet, integrated into the life-cycle process itself where a minimum of human intervention is necessary. That way many of the hidden costs associated with existing tools can be avoided.
During the development process CISOs and COs need to be asking questions that uncover the hidden costs, such as:
Asking these questions can lead to a better understanding of hidden costs, and how to mitigate them when implementing new security solutions.