Image may be NSFW.
Clik here to view.
Every year the world seems to grow a little more regulated – and punitive. We’re now seeing banks suing retailers and compliance management firms over PCI assessments. And the recent breach in question appears to be related to insufficient controls around third-party suppliers.
According to the Verizon PCI Compliance Report, 84% of organizations that suffered a data breach were out of compliance with application-layer security controls (Requirement 6) — compared to an average of only 47% of all organizations assessed by Verizon QSAs in 2013. This suggests a strong correlation between the likelihood of suffering a data breach and non-compliance with application-layer security.
Security and regulation are inextricably linked – and will continue to be so. A recent survey of security executives conducted by 451 Research showed that the #1 driver for security budgets is compliance – with 38% of respondents saying their budgets increased specifically to address regulatory or legal compliance requirements.
So does compliance actually strengthen security – or does it simply create the illusion of security?
On the one hand, security programs structured solely to meet compliance and audit requirements tend to be implemented as annual “point-in-time” projects. These programs are really once-a-year sprints to appease auditors who are often more “checkbox-oriented” and may not spend the time required to uncover weaknesses in how controls are actually implemented and monitored.
This typically leads companies down the path of doing just enough to comply – in other words, actually lowering enterprise risk may not be the primary goal of these projects.
On the other hand, many enterprises have implemented effective security programs which are structured to implement, improve and mature security practices. Unlike unstructured, ad hoc approaches to enterprise security, these programs are – well – programmatic.
Programmatic approaches are focused on managing risk, accelerating adoption of best practices and using automation to simplify, centralize and standardize controls where possible. In these programs, compliance is merely the reporting output of an ongoing effort, rather than an isolated project.
One interesting thing we’ve seen is that effective, enterprise-wide risk reduction programs often begin as compliance-funded projects.
This is one of the topics our experts will be exploring in next week’s PCI 3.0 webinar – how we’ve seen our customers use existing PCI projects as a springboard for building more structured application security programs with automated testing and centralized policies, metrics and reporting.
Image may be NSFW.
Clik here to view.
PCI 3.0 focuses on third-party software risk for the first time, adding guidance on “custom software developed by a third party.” Similarly, the OWASP Top 10 now includes a requirement to check third-party components and libraries for vulnerabilities, and PCI 3.0 recommends using the OWASP Top 10 guidelines as a best practice.
All of which may now expand the scope of compliance efforts to include controlling risk from third-party software such as packaged and outsourced applications, third-party frameworks and components, and open source code.
If more of your budget increases will be driven by compliance, isn’t it better to spend it on a program that actually reduces your enterprise risk?
