Web Application Security Checklists as Code

Web Application Security Checklists as Code

THE PROBLEM

‍
Imagine ACME Web Development Company performs several tens, hundreds or even thousands of Web Application deployments a year and it has a typically small Application Security Team compared to the development and QA teams.

• How does ACME ensure that those applications have included a reasonable set of security countermeasures?
• How does ACME verify that those countermeasures have been properly implemented?
• How does ACME verity that changes to the applications have not introduced security regressions (security flaws or a weakening of the existing countermeasures)

This is quite an extensive topic and a thorough analysis should cover securing each application from the Design Phase all the way through to the Maintenance Cycles, but we will focus on how we could automate several checks during the delivery process in this post.

To achieve a reliable and repeatable degree of test coverage, a sensible approach is the use of checklists. ACME could use either an existing checklist as, for example, the checklists created by the SANS institute or the one included in the OWASP Testing Project, or its own internal version.

For the purposes of this post, let’s assume that the security team at ACME has built a tailored Web Application Security Checklist based on several public lists, and they want to ensure the checks on SQL Injection, XSS and HTTPS are fully covered for each deployment. These checks say the application must be scanned for SQL Injection, Cross Site Scripting (XSS) vulnerabilities and HTTPS must be enforced on the servers. Obviously, ACME has several other requirements on the checklist but let’s focus on these for the time being. The more ACME can rely on automation to deliver these tests across their hundreds of applications, the lower their cost and the higher their return on security investment.
‍

‍
ACME DECIDES TO FOLLOW A 5-STEP APPROACH TO AUTOMATE THIS:

1- Identify the applicability of the checklist

This needs to be defined beforehand and we need to make sure the verification requirements make sense within the specific application context. If there is no database on the application’s architecture, there is no need to check for SQL Injection, if the Web Application does not have a front-end (i.e. is a REST-based API) we probably don’t need to check for XSS. So the applicability of the checklist should be clearly defined before launching into the testing activities.

Let’s assume that ACME CMS application consists of a database, a web front-end and it is accesible from the Internet.

2- Add automated tests as part of the Continuous

Integration/Continuous Delivery Pipeline
ACME CMS application is released twice a day. The development and QA teams have a good Continuous Integration and Delivery Pipeline, they use an internal GitLab repository to manage the code and use several frameworks that allows them to avoid boilerplate code and follow a Test Driven Development Approach. On its side, the QA team has a SonarQube server to test code quality, a Jenkins server to drive the deployments and an EggPlant toolset to do functional and performance testing. ACME is a quite mature and agile development company and they’ve been working hard to change their culture to adopt DevOps practices, with an emphasis on automation and cross functional teams.
But Security Testing is still missing from the process so they are adopting BDD-Security to complete their Pipeline, which will look as follows:

BDD Security to complete Pipeline

All the pipeline actions are automated and if any of the steps within the Pipeline fail, the build also fails and the process is blocked. The whole process is driven by Jenkins which orchestrates the interaction with all the other tools. Pushing new code to the code repository would automatically trigger the whole build, test and deployment process.

3- Automate the applicable checklist items, translate each verification item executable tests

As a pre-condition we would identify and translate the checklist into tests; in the example cases above the verification items would be:

• SQL Injection: an active scan with OWASP ZAP using a SQL injection policy;
• XSS: an active scan with OWASP ZAP using a XSS policy;
• HTTPS: this verification step implies, testing that:
  - The server is only listening on port 443.
  - The CMS Application sets the HSTS header.
  - The TLS implementation is not vulnerable to known attacks and supports strong cryptographic ciphers.

ACME will use BDD-Security to test this, specifically the stories with tags @iriusrisk-cwe-89 (SQL Injection) and @iriusrisk-cwe-79 (XSS) during the build phase as part of the “SecurityTests_BDD_Security” Jenkins job and the @iriusrisk-open_ports, @ssl and @iriusrisk-cwe-693-strict-transport-security stories during the Staging phase as part of the “SecurityTests_staging_BDD_Security” job. We can configure BDD-Security to execute these tests.


4- Integrate the remediation process in the development process

Identifying security issues or doing automated security testing is half of the story, correcting the identified issues is the other half, otherwise ACME will run into the “Security-as-a-blocker” problem that they aim to avoid (they want to be good DevOps practitioners after all!)

ACME, has a process in place to turn identified security issues into tickets on an issue tracker and to prioritize them, fortunately, there is no difference within this process for functional or non-functional problems, if they break the build, they are all high priority.

5- Refine the automated results and think about the next steps.

Once this process has been deployed and is in use, it soon becomes apparent to ACME that there are three problem areas that can be addressed as part of their Continuous Improvement culture:

1. The results they get from the automated tools are often not accurate, there are false positives that should be filtered out to avoid noise in the tests and in the issue tracker. They can address these with the help of the Security Team using BDD-Security as it allows removing recurrent false-positives.
2. There are vulnerabilities that automated tools just cannot identify (i.e. Business Logic vulnerabilities, chained vulnerabilities or technically complex ones) so they will need to add a new step to automatically test for fixes which come from other sources (External Penetration Tests, Bug Bounty Reports, Pair Reviews, etc.) and extend the BDD-Security usage to include those tests.
3. The Security Testing has no risk context. In other words an SQL injection vulnerability detected in a database storing public information or in an internal database which holds credit card Primary Account Numbers (PANs) – is given the same priority and risk rating. ACME can write scripts to adjust the risk ratings produced by the testing tools based on the risk context or they could use IriusRisk which was designed to automatically perform this task.

Going forward ACME’s Security Team aims to keep pace with their development teams and this inevitably means automating manual and repetitive processes. This means that instead of being the bad guys slowing down the development process, they can play the role of enablers, allowing development teams to deploy faster and with greater confidence.

‍