Beating the Cost, Time, and Quality Equation With OWASP ZAP Automation

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!

The project management triangle has been around since at least the 1950s and represents the idea that quality is the result of three elements:

• Budget (cost): What resources do you have to build the product?

• Deadlines (time): When does the product need to go to market?

• Scope: What are all the required features?

It's a way of showing that changes in any fundamental element will directly impact the resulting quality for better or worse. The triangle shows the trade-offs that can result in the same quality with different elements... like more money, more time, or fewer features.

The relationship between the contributing factors of the triangle explains why tools like Jira, Crucible, Jenkins, Ansible, and other various forms of automation are so valuable. Each one of these tools provides a modifier to the elements of the triangle that then alter the quality equation for more time, lower costs, or faster completion, and result in higher quality.

Security Is Treated as a Second-Class Citizen

Traditionally, security isn't considered outside of the most basic of requirements unless you have a product specifically geared towards it, yet any modern developer will laugh if you say you don't expect unit tests to be part of their development cycle.

Kent Beck stated, "Make it work, make it right, make it fast," which has been both the basis for development of many fine software projects and the subject of much conjecture as to the interpretation of "make it right" and "make it fast," as there is no explicit "make is secure" step.

If you ask the development group to ensure there is a secure review of their code, first, they will raise eyebrows; then, they will likely pushback and assume it costs too much. So, let's take a look at why that's simply not true.

"They are going to get in — get over it." — Michael Hayden, former head of the NSA

Nearly daily, we see breaches impacting companies from identity loss to potentially altering world democratic elections. Memorablebreaches from 2017 include:

The list continues to grow. Given the impact breaches have on public and corporate trust, we must determine if anything can be reasonably done to prevent these issues.

In most cases, there is. Equifax had a terrible password and access policies as well as unpatched software; Verizon and RNC had misconfigured AWS issues. Other exploits included misconfigured email servers and other common hacks.

There are plenty of ingenious hacks out there that are very hard to protect against and take serious consideration... but largely, the biggest hacks seem to fall into the same categories of known and preventable threats.

Public applications will suffer attacks. The resulting costs of a successful exploit can be reputation or cost or can extend into ramifications that ripple through the organization. We must consider the costs imposed on the quality triangle. Saying it's too expensive isn't realistic anymore. Therefore, in today's environment, the definition of "make it right" is simply not satisfied without a security audit.

The triangle can identify the consequences to the project, but to identify where to invest resources, we need to quantify the threats. Identifying which threats to address requires establishing a method to quantify the risk consequence versus the cost to implement it.

Quantify the Cost to the Quality Triangle

Consider two potential public applications with external APIs. The first is a public WordPress server providing a blog of recipes online. The second is a fitness app with medical history, as well as access to medical records that would make it trivial to impersonate a user's identity.

The fitness app will require extensive security testing, including all the bare minimum requirements for PCI and HIPAA compliance. The recipe blog would only require a solid assurance that the data is not lost or corrupted.

Identifying the relevant threats to the application is the first step. There are a few databases that collect various types of risks, including a database that is specifically geared towards web applications called the OWASP Top 10.

The OWASP itself is a worldwide not-for-profit charitable organization focused on improving the security of software. Their mission is making software security visible so that individuals and organizations are able to make informed decisions.

The importance of protecting each risk can be derived by identifying the cost of resources by using the Top 10 list to identify the top vulnerabilities and then quantifying the impact of the quality triangle.

For each threat:

risk value = threat * vulnerability * consequence (ref).

A simple example using the Top 10 list applied to the above examples of the medical records database server vs. the public recipe database gives an idea of how the value of risk changes with the formula.

Medical records database:

Breaking down the risks and consequences show there is an obvious first place to fix: the unlogged breach. The consequences could result in a possible loss of all records, each of which carries a required fine for loss. The other threats are at least more limited — not to mention the loss of consumer confidence when the press asks how the breach occurred and you shrug and say, "Dunno, sorry."

Let's take a look at the same exploits against the recipe database.

Obviously, the consequences are far less severe. The log system would still be very high on the to-do list but the severity of the consequences is substantially lower. In fact, injection or blocking buffer overflows might even be deemed more pertinent, as recipes showing up with small changes or something like wrong ingredients would be far more damaging to the site's brand and value. Prevention versus mitigation.

In the example of the recipe database, understanding the risk/consequence relationship might allow the mitigation of sufficient risk by simply setting up a solid remote backup system — whereas, with the medical records database, each risk is attached directly to a real dollar value (fines) and therefore each potential threat will need to be identified and quantified.

Identifying every possible threat, especially in a large organization, is a daunting task. There are more granular methods of identifying specific risk and criticality, which might be relevant depending on the application. Formulas for identifying attack costs as well as the likelihood vectors are available which focus more closely on things like attack trees, fuzzy logic, CVSS (common vulnerability scoring system), and organizationally dependent impact. Realistically, this job is getting more complex every day.

It's Clear "Why," and now the "What" Has Been Established, but There Is Also a Better "How"

Tools like Jenkins and Ansible make it possible to maintain or lower the cost of portions of the quality triangle by automating repeatable tasks. Many languages are developing along a similar paradigm, such as PHP with composer or Node with npm, by providing systems that leverage the effort of multitudes of developers to make it easy to create, review, and implement new functionality.

Low-code platforms (like the one I work on) can extend this paradigm to generate full source code, instead of just libraries, and can in some cases be built using the common interface of a web-based IDE. Cool!

These tools and mechanisms are all rooted in the quality triangle, enhancing the quality equation by modifying one or more of the contributing factors to creating a better product faster and more feature-rich for a lower overall cost. It should come as no surprise that tools are evolving in the security space to provide the same benefits.

The same organization that provides the top ten threat list project (OWASP) also provides a project called the ZAP (Zed Attack Proxy) server. Among other things, ZAP provides the means to test for these top ten threats, as well as many others. ZAP also creates a vector that can be included in the automated components, such as Jenkins, of your development cycle.

By applying the open-source principle to security and automation, everyone benefits. (Expressed as Linus Law by Eric Raymond as, "Given enough eyeballs, all bugs are shallow.") Exploits will be exposed and fixes can be automated into tools that help everyone learn how to protect against them.

ZAP then provides the ability to apply the same benefits Jenkins or Ansible does to the development process to the security aspects of the quality triangle, automating the regular testing of numerous vectors of exploits with little cost to the development team. It's higher-quality and comes at the same cost, and is arguably even cheaper due to less after-the-fact mitigation.

ZAP has a number of modes to run in, including as a desktop utility or a server, and also supports a robust scripting mechanism that includes support for any scripting language that supports JSR 223such as Python, JavaScript, or Groovy. This makes ZAP perfect for doing everything from lightweight passive scanning to granularly defined scripted testing.

The ZAP server can also run active or passive scans. This provides the ability to test your site without actively attacking it, which is important if you do not own the website in question. This also makes it possible to integrate multiple environments, from dev to staging, before reaching production on machines and makes it easy tore-provision to ensure the active scans won't do any serious damage(though it would still be better to be found before someone else does).

A Really Good Tool Isn't Just a Tester, but Also a Teacher

Tools, such as Findbugs, Sonar, and PMD, help teach developers by exposing bad patterns in design, logic, or structure. This is important as on-the-job training for developers that actually evolves as it is being used (assuming it is continually updated). The ZAP server fulfills this requirement as it gives details about what happened and helps developers recognize what types of activity will cause a potential threat.

In summary, security needs to be a first-tier concern, and if we leverage automation tools and risk assessment practices that are already established, we can develop a strategy to provide for the new requirements with minimal impact to the end quality of the project while managing reasonable costs and scope. Additionally, we can provide ongoing training in the clearly growing and important area of security with minimal overhead.

That Is How We Zap the Triangle

There are many other tools worth investigating based on your application's needs. For example, there are more ways of assessing risks that provide a much more granular level of risk assessment. One such list worth investing some time into is the CVSS, which provides tools and a training system for managing assessments. Keep in mind that there is no "silver bullet," and we need to be able to learn and adapt. The universe of development is one that has just undergone its "big bang" relatively recently and is rapidly expanding.

Resources

• fortune.com/2016/05/14/cybersecurity-risk-calculation

• azquotes.com/author/31849-Kent_Beck

• isaca.org/Journal/archives/2014/Volume-4/Pages/JOnline-AnEnhanced-Risk-Formula-for-Software-Security-Vulnerabilities

• checkmarx.com/2017/12/31/recap-biggest-data-breaches-2017

• owasp.org

• owasp.org/index.php/ZAPpingTheTop10• jcp.org/en/jsr/detail?id=223

• owasp.org/index.php/Category:OWASP_Top_Ten_Project• Startup Security 101

• Improving Build Times With Jenkins Pipelines

• Ethereum Scripting – The Future of the Web (new.0)

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!