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.
Comprehensive, Lightweight Application Security Process (CLASP) is a role based and activity driven set of best practice for building security in the existing software development lifecycle. The primary goal of CLASP is to support the construction of software in which security takes a central role.
- These jars are Java libraries and modules developed by third parties including open source software.
- 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, 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.
|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.|
|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:
- 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 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
- Malicious code
The full list of bug patterns that FindBugs can detect is available at findbugs.sourceforge.net/bugDescriptions.html
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 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.
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.
IMPORTANT: testers should only use app security scanners to attack an application they have permission to test with an active attack. Because this is a simulation that acts like a real attack, actual damage can be done to a site’s functionality, data, etc. This is why Krescendo has created some segregated environments specifically for penetration testing.
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.