Application development has been witnessing a steady churn of change over the past decade. Today DevOps has enabled product teams to deploy applications at a rapid pace and scale.
With that being said, compliance standards, more often than not act as a ‘ball & chain’ for agile product teams, hampering the speed of application delivery. Although, one of the primary drivers for organizations to get ‘certified’ is the reassurance that the standards offer to customers and end users, practically speaking it is of little use as many compliance standards still have not come out of their waterfall shell.
Hence adherence to compliance mandates becomes a once-in-a-blue-moon activity that product teams are forced to take up to ensure that they stay ‘certified’. The results of such a perception towards standards are evident in recent breaches such as Equifax, Whole Foods, Yahoo, or the Aadhar EPFO breach that happened in March of this year.
However, all hope is not lost. Certification bodies such as PCI, HIPAA and GDPR have updated their standards to the emerging shift in application development practices. They mandate product teams to implement a framework for continuous assessment and building application security by design.
Let’s take look at few of the clauses from PCI, HIPAA and GDPR that have a strong resonance to Continuous Security Automation. (You can access the official documentation for these standards by clicking on their respective headers below)
One of the most popular & robust compliance standards, PCI – DSS clause ‘6.3.2’ mandates code reviews based on secure coding guidelines prior to production release. Clause ‘6.6’ mandates that application assessments are conducted on an ongoing basis to ensure that new threats and vulnerabilities are addressed. For instance, consider an organization that develops a popular payment wallet which has millions of users, having to release new features and scale their application real-time to keep up with growing demand. For such an organization to adhere to the above clauses without adversely affecting continuous application delivery, security automation is the only viable option available. By imbibing automation to perform security assessments to be part of the application development cycle, you can ensure that product teams are able to address vulnerabilities early in the pipeline and thereby release a secure application to production.
The healthcare sector standard presses upon the need for periodic security assessments. Security Rule ‘164.308(a)(8)’ mandates organizations to perform security assessments in response to environmental or operational changes affecting the electronic protected health information. Also, security rule ‘164.308(a)(A) establishes as part of risk analysis, product teams should conduct an assessment of potential vulnerabilities that could compromise the confidentiality, integrity or availability of the electronic protected health information. This necessitates iterative threat modelling to be an indispensable part of the product development lifecycle.
GDPR
The new privacy-centric standard which is set to come into effect on May 24th. Per the standard, Article 25 mandates data protection implemented by ‘Design and by Default’. In order to be compliant, organizations will have to start implementing security practices right from the white-boarding stage. This would include security architecture reviews, threat modelling for iterative app releases, and implementing security assessments as part of the CI pipeline. Only by conducting these activities consistently, can organizations hope to comply with GDPR’s requirement of privacy & security by ‘Design & Default'
Rather than organizations looking to get certified with one or more compliance standards, for the sake of getting certified, they should look at building a comprehensive set of controls, which incorporates the best practices of leading compliance standards (PCI/SOC2/HIPAA/ISO/GDPR).
In addition, product teams can also perform pre-commit code scans through SAST tools running as part of the pipeline helps product teams to identify security vulnerabilities for every code change that the application goes through. For deployment processes, using open source tools such as Ansible Lint and InSpec, that would check deployment cookbooks on whether they contain the necessary hardening checks prior to production deployment. This allows product teams to scale their applications safely while maintaining a minimum threshold before moving from development to production.
By unifying your compliance objectives, drawing the best practices of the standards mentioned above, organizations will be able to push for a cultural shift towards DevSecOps, resulting in an overall maturity of their application security practices.
