Embracing Security as a Business (part 2 of 2)

In part 1 of Embracing Security as a Business, I described why Krescendo adopted CLASP as our security development lifecycle and how it helps us:

• Address security compliance requirements.
• Build software that is more secure.

Here, I will describe how CLASP works in practice for different roles and the software tools Krescendo uses.

CLASP

Role	Activities	Tools
Project Manager	Promote awareness Monitor and define metrics	Application vulnerability audit dataset in LiveDataset
Architect	Check software up-to-date Check jars1 up-to-date Verify jars1 Network security Verify security aspects before adopting new technologies or tools	Jenkins continuous integration reports2
Implementer	Understand vulnerabilities and how to address them Track vulnerabilities	OWASP Top Ten Remediation procedures Jenkins continuous integration reports2 Application vulnerability audit dataset in LiveDataset
Security Auditor	Review code between releases White-box testing Black-box testing Promote awareness	OWASP Dependency-Check FindBugs OWASP ZAP Burp Suite

1. These jars are Java libraries and modules developed by third parties including open source software.
2. Jenkins jobs are configured to automatically run FindBugs and OWASP Dependency-Check and report warnings. They are configured to run periodically and on demand.

The Implementer

The implementer, typically a software developer, reviews the OWASP Top Ten checklist before committing code to the repository.

The implementer uses Jenkins to run the security tools. The implementer carefully reviews the warnings and decides whether they are:

False positives	Due to the nature of security scanners, false positives are inevitable. The implementer tries to avoid these being flagged as warnings by adjusting the code or configuring the security scanner to not flag this specific instance again.
Easily addressable vulnerabilities	Implementer makes required changes and re-commits within current sprint.
Other vulnerabilities	Implementer records the vulnerability in the Application Vulnerability Audit dataset if it cannot be easily addressed before the next production release.

Application Vulnerability Audit

Of course, to manage all the information and processes around vulnerabilities Krescendo uses a dataset in LiveDataset.

In this dataset, the classification and severity are recorded for every vulnerability. And each vulnerability is assigned to a person responsible for resolving. This applies equally to vulnerabilities identified during the development of new code and scheduled checks of existing code.

Classification

Confidentiality	Protecting the information from disclosure to unauthorized parties.
Integrity	Protecting information from being modified by unauthorized parties.
Availability	Ensuring that authorized parties are able to access the information when needed.

Severity

High	Exploitation could result in data loss or downtime or elevated privileges. This requires immediate attention and should be fixed within current sprint.
Medium	Vulnerabilities that require user privileges for successful exploitation. This should be fixed in the next sprint.
Low	Impact is very minimal. Only Krescendo members can access and should be fixed in the next two sprints.

While our official deadline is that all medium and high vulnerabilities must be resolved within 120 days, in practice they are resolved much sooner — typically within 20 days.

The Security Auditor

The security auditor checks committed code between releases. They use the same security scanners as the implementer:

• FindBugs
• OWASP Dependency-Check

They carefully review the warnings. When a vulnerability is identified, the security auditor records it in the application vulnerability audit dataset, categorizes it and assigns it to an implementer.

In addition, the security auditor for each application runs a full black-box web scan every six months using either:

• OWASP ZAP
• Burp Suite

FindBugs

FindBugs looks for bugs in Java programs using static analysis to inspect Java bytecode for occurrences of bug patterns. This means that FindBugs can find bugs in Java software by simply inspecting a program’s code. It does not need to execute the program or have access to the source code.

As Krescendo applications are written in Java, FindBugs is a great security tool for us. It is very easy to use. In general, one should be able to use it to look for bugs in code within a few minutes of downloading it.

A FindBugs report classifies the bugs in categories, including

• Bad practice
• Correctness
• Malicious code
• Performance
• Security
• Style
• …

When a security auditor examines a FindBugs report like the one below, they focus on any bugs that relate to malicious code or security.

FindBugs works by analyzing Java bytecode (compiled class files) therefore its analysis is sometimes imprecise and can report false positives. There are warnings that do not indicate real errors. The security auditor or implementer must assess these cases and ensure comments are in place so that the same false positive bugs are not reviewed every time.

OWASP Dependency Checker

Dependency-Check is a flagship OWASP project that identifies project dependencies (third party jars for Java project) and checks for any publicly disclosed vulnerabilities on the U.S. national vulnerability database (NVD).

Dependency-Check reports like the one below contain a list of the identified vulnerable components. Clicking on a CVE link (common vulnerability and exposure) gives useful information on the vulnerability and how to fix it. Typically, this means upgrading to a newer version of the Java library.

Due to the way Dependency-Check works, the report may contain some false positives. Where the implementer or security auditor have determined a warning is a false positive, they should use the suppression feature to generate a suppression XML file that can be used on future scans.

OWASP ZAP

OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free web app scanner tools and is actively maintained by hundreds of international volunteers. It can help testers (security auditors) find security vulnerabilities while testing web applications.

At its core, ZAP is what is known as a “man-in-the-middle proxy.” It stands between the tester’s browser and the web application so that it can intercept and inspect messages sent between browser and web application, modify the contents if needed, and then forward those packets on to the destination.

There are two ways to use ZAP: automated spiders or manual exploration.

Using automated spiders, the tester simply provides the URL of the application and ZAP will crawl the web application by scanning each page it finds.

While spiders are a great way to explore a basic site, they should be combined with manual exploration where the tester interacts with all the relevant pages of the site that are recorded by ZAP.

Eventually the tester can run the attack mode and ZAP will use the active scanner to attack all the discovered pages, functionality, and parameters. Then it records the requests and responses sent to each page and creates a report like the one below.

By clicking on one of the alerts on the side menu, details are shown on how the attack was performed, what vulnerability was found and a possible solution.

Burp Suite

Krescendo also use Burp Suite, which is another popular web app security scanner, however it requires a commercial license. The reason for using another tool is that each tool has different strengths therefore by using two scanners different type of vulnerabilities may be found.

It’s All Worth It

Initially the process can seem daunting. In practice it is strict and requires discipline, however over the years this has become an integral part of our business. Security checks no longer seem like a burden or an additional overhead but more a part of the routine for every implementer and security auditor.

Occasionally, our security checks mean that a release or feature must be delayed as result of finding a vulnerability, but our clients understand the benefit of doing this.

As well as Krescendo running our own security checks, periodically the applications are also externally audited by clients and third-party security companies to:

• Confirm that our adopted process and tools are working well.
• Confirm no medium/high vulnerabilities are exposed to end users.

LiveDataset has been externally scanned by two well-known accredited security firms in the last 2 years.

Both reported zero medium/high vulnerabilities.