Three Product Security Takeaways from QUEST 2018

As it does every year, QUEST Conference brought together leaders in software testing technologies to educate and present on the latest topics and challenges facing the industry. Given recent data breaches and issues at such high-profile companies as Equifax, Target and Facebook, it makes sense that security was one of the most-discussed topics in a wide variety of sessions.

Back in the office, here are three topics which are remaining in my focus as I look to incorporate what I learned:

The Internet of Things is an Ever-Growing Concern

The idea of a hacker going after a desktop or a mainframe system over the internet is considered outdated by the security community. It’s the cutting edge technology that’s the most vulnerable. Six to eight years ago, this meant smartphones. Today, it’s IoT devices. There is such a huge rush to get products to market that security concerns in design and implementation are being overlooked. In a recent Barr Group survey, over half of the engineer respondents say their IoT projects are vulnerable to product tampering. The risk for Theft of Data and Theft of Intellectual Property each approach 40 percent.

Testers must consider security at the start of every project. When we think about a software system from its inception, consideration for potential vulnerabilities within each interface must be included as part of each requirement or user story. An IoT device is entirely about the interfaces it can have to other devices and applications. If you are not using one of the many testing products that support the ITU-T library of Common Vulnerabilities and Exposures (CVE) & Common Weaknesses and Exposures (CWE), you are risking catastrophic issues down the road.

The Testing Approach Doesn’t Have to Cost a Lot of Money

The Open Web Application Security Project (OWASP) has existed for more than 15 years as an open source project to share information to help organizations learn how to make their applications more secure. In addition to maintaining a comprehensive database of security vulnerabilities and weaknesses based on the ITU-T lists, each year OWASP identifies its “Top 10” consensus of critical security risks to Web-based software. Included with the Top 10 is a set of “What’s Next” section of topics that guide developers, testers, organizations and application managers into how to use this information. The What’s Next list for testers, for example, looks like this:

Understand the Threat Model

Before you start testing, be sure you understand what’s important to spend time on. Priorities come from the threat model, so if you don’t have one, you need to create one before testing. Consider using OWASP ASVS and the OWASP Testing Guide as an input and don’t rely on tool vendors to decide what’s important for your business.

Understand Your SDLC

Your approach to application security testing must be highly compatible with the people, processes, and tools you use in your software development lifecycle (SDLC). Attempts to force extra steps, gates, and reviews are likely to cause friction, get bypassed, and struggle to scale. Look for natural opportunities to gather security information and feed it back into your process.

Testing Strategies

Choose the simplest, fastest, most accurate technique to verify each requirement. The OWASP Security Knowledge Framework and OWASP Application Security Verification Standard can be great sources of functional and nonfunctional security requirements in your unit and integration testing. Be sure to consider the human resources required to deal with false positives from the use of automated tooling, as well as the serious dangers of false negatives.

Achieving Coverage and Accuracy

You don’t have to start out testing everything. Focus on what’s important and expand your verification program over time. That means expanding the set of security defenses and risks that are being automatically verified, as well as expanding the set of applications and APIs being covered. The goal is to achieve a state where the essential security of all your applications and APIs is verified continuously.

Clearly Communicate Findings

No matter how good you are at testing, it won’t make any difference unless you communicate it effectively. Build trust by showing you understand how the application works. Describe clearly how it can be abused without “lingo” and include an attack scenario to make it real. Make a realistic estimation of how hard the vulnerability is to discover and exploit, and how bad that would be. Finally, deliver findings in the tools development teams are already using, not PDF files.

Automation is within Your Grasp

As testers, when you learn and develop some understanding of CVE/CWE and how OWASP documents them, the next step is to incorporate a tool such as the Zed Attack Proxy (ZAP). ZAP is an open-source penetration testing library based on the OWASP Top 10, with a robust documentation set and community to support anyone looking to learn. ZAP coordinates “man in the middle” attacks using its own proxy server for testing to mimic what a real security attack may look like.

ZAP comes with its own application to manually configure the session properties for the various attacks it supports. ZAP also provides API libraries written in most popular languages (Java, JavaScript, C#/.NET, Python, etc.) to incorporate into any automation framework.

Whether run manually or via automation, the results of the security test are compiled by ZAP in summary and detailed alert reports. The issues documented in these reports should be monitored and resolved via the same triage process as any other software defects in the software development lifecycle. In addition to defect management, however, it should be understood by the project team the impact security defects can have if made known to the public. Security testing results should be secured and kept confidential outside of the project team.

A typical defect might mean that if a user stumbles across it, a form won’t render on the application screen or the user experience might be less than satisfactory. Hackers aren’t stumbling across security defects. They are actively seeking them out, and the results of their discovery can be a disaster which can cripple a company’s business or reputation. Awareness of an application’s vulnerability and weaknesses, and how to test for them, needs to be approached with the same effort and diligence as any other test cycle.