Image source: Blog.e360.pk
The data protection landscape has grown increasingly complex in recent years. This transition was kicked off with the passage and enactment of the European Union’s (EU’s) General Data Protection Regulation (GDPR).
The GDPR dramatically expanded the protections provided to consumers’ data and the penalties and fines for non-compliance. Its rules also spurred the passage of a number of other data protection regulations since an organization is not permitted to process EU citizen data without either operating in a country with equivalent protections or implementing those protections in-house.
This flood of new data protection regulations has a significant impact on DevOps as the software being developed as part of the DevOps process is designed to have access to and process data protected under the regulations. New laws mean new requirements that need to be integrated into DevOps in an intentional way in order to be effective, compliant, and sustainable.
With new regulations come new security control requirements; however, some existing laws already require certain technology to be in place for compliance. For example, the Payment Card Industry Data Security Standard (PCI DSS) explicitly calls out the need for a web application firewall as one of the two options for achieving compliance with a core requirement for DevOps environments.
PCI DSS 6.6: Exploring the Options
PCI DSS Requirement 6.6 is designed to ensure the security of web applications against common types of threats. These threats include cross-site scripting (XSS), injection attacks, and other common vulnerabilities listed on the OWASP Top Ten and similar lists.
To achieve and maintain compliance with PCI DSS Requirement 6.6, an organization has two main options: application code review or deploying a WAF. Since the choice of option to put in place has a significant impact on the workflows and productivity of a DevOps team, it is important to understand the regulations and options for compliance in order to make an informed decision.
- Application Code Review
The first options for achieving compliance with PCI DSS Requirement 6.6 is performing manual code review to identify and correct any vulnerabilities in application code. The regulation allows this test to be performed manually (by a qualified reviewer with an understanding of the application and potential vulnerabilities) or with the use of automated tools designed to identify and correct these common vulnerabilities.
One thing that the regulation makes extremely clear is that the code review cannot be performed by the development team itself. Organizations are permitted to bring in a third-party contractor or use an “organizationally separate” team to perform the code review. The developers of the application are not permitted to review it and deem it secure in order to satisfy the regulation.
This need to bring in a third party (outside of the development team) can make this option a challenging one for many organizations. With rapid development cycles in Agile or DevOps environments, this requirement means that the third-party reviewer would need to be constantly on-hand and that the organization must have the resources to either support a completely distinct quality assurance and testing team or have a third-party reviewer on retainer for code reviews. This reviewer, regardless of affiliation, must have a complete understanding of the application and its purpose, adding to the overhead associated with the review.
It is also important to consider that an application’s attack surface is not limited to the code written in-house. On average, a web application includes 1,000 dependencies, each of which have an additional 80 dependencies of their own. Since an application can inherit vulnerabilities from its dependencies, this means that steps must be taken to either perform code reviews on all dependencies (including reviews of each update) or to ensure that code takes steps to protect itself from exploitation via integrated third-party code.
- Web Application Firewall
The other option for achieving compliance with PCI DSS Regulation 6.6 is to deploy a web application firewall. This web application firewall should monitor all traffic flowing to and from a potentially vulnerable web application and should be capable of identifying and blocking attempted exploitation of common vulnerabilities.
Deployment of a WAF does not eliminate an organization’s responsibility to perform security testing on their applications. However, using one to protect code developed in-house dramatically decreases the probability that an organization’s security controls for web applications will be found non-compliant. Additionally, a WAF provides protection of cardholder data against vulnerabilities in third-party applications that an organization may use, decreasing the probability of an expensive and damaging data breach.
Deploying Compliant Web Application Security
Regulatory compliance is a growing concern for all organizations. New data protection regulations like the GDPR or the California Consumer Privacy Act (CCPA) require more stringent protection of customer data and raise the ceiling for fines in an organization is found to be out of compliance or failing to properly protect customer data. These new regulations are layered on top of existing ones like PCI DSS, further increasing the complexity of the regulatory landscape.
Maintaining compliance with a growing number of regulations requires an intentional and informed approach to implementing required security controls. This especially applies to development teams who create the software responsible for processing and securing this sensitive information. In many cases, deploying the right security solution, like a strong WAF, can help to plug any security gaps created by inadequate (or nonexistent) code review processes.