It is sad that many security discussions are so binary: that is, if you’re not wildly for something then you must be wildly against it. One specific, often stated, sentiment that irks me in particular is: “compliance is not security”. This isn’t actually true. Much of what you might consider a compliance approach can actually foster good security - it is just not enough in all cases. In other words, compliance is a necessary but not sufficient condition. Even inside your own organization you probably run a compliance regime of policies, standards, and controls assurance. Just because those policies and standards don't cover all possible risk circumstances for all time doesn't mean you don't get substantial protection from assuring that baseline. But for now, let's focus on externally created compliance regimes.
First, let’s define compliance as some scheme or rule set to assure a system of governance, risk mitigation and controls that you are operating in evidenced conformance to. This rule set can come from a published specification set by some legislative, regulatory or self-regulatory organization.
There may be aspects of that rule set that correspond to good risk mitigation but maybe some that do not, there may even be some that actively work against good risk mitigation.
It is worth remembering in any critical industry, where there can be material impact from incidents, that regulations to protect customers are vital. Writing good regulation is hard, especially when you have to balance standards that can be measured (but can be out-dated quickly) vs. principles to follow (that can create some degree of enforcement ambiguity). There are many great professionals in regulatory bodies who perform their role in a spirit of public service but, because they are not immersed in the day to day operations of organizations, it can be challenging to stay precisely up to date. Also, the necessary comment periods for regulatory changes preclude rapid adjustment.
We need to keep working to make regulation more closely correspond to risk - to drive the circles closer together. However, given the constant changing nature of risk, the best we can often hope for is regulation to be constantly chasing this - getting closer but never fully overlapping. Somewhat cynically, it might even be a victory to just have them not get further apart given the dynamics of many rule-setting environments.
Now, this can be even more problematic as many organizations have to deal with multiple domestic and international legislative and regulatory codes. That can look something like this:
Compliance regimes for various aspects of security are not only necessary but are actually important (for example: PCI is often criticized as not setting a standard to assure mitigation of all risks, but it is hard to argue that PCI standards have not in any way improved the protection of cardholder information across a range of sectors). Given such regimes will be ever present it is on all of us to improve what constitutes compliance and how it can be efficiently enforced. In doing so we can preserve sufficient resources to mitigate the other risks we should be concerned about, not just those stipulated in compliance rules. There are 7 focus areas to do this: 1.Efficiency. Adopt compliance rules as a key part of continuous control monitoring and baseline configurations - compliance by design. This is especially important for topics like privacy where there might be multiple regimes. Adopting a universal baseline for your organization that can be efficiently enforced, but which maps to those specific laws and regulations (for the most part) will be important. Efficient and effective compliance can be a competitive differentiator in most industries, not just to avoid issues but to exert less overall cost and effort on maintaining adherence. 2. Partnership. Partner with regulators or rule-setters to make the rules better. Regulators are usually well intentioned and professional people who are trying to make what they define as close as possible to the risks which need mitigating. For most rule-setting schemes there are processes to request changes, improve new versions and coordinate public comment on new rules. Work with the process. 3. Seek Opportunity. Make compliance monitoring and conformance a living process and look at areas of non-compliance as a symptom of a deeper problem. This could be a failure of compliance by design manifested as an efficiency issue. A signal given off by some specific lack of compliance could also point, indirectly, to an issue that represents other risk. 4. Necessary but not Sufficient. Do not equate compliance with being enough to mitigate your risks. Educate your Board and leadership that compliance is a minimum baseline. 5. Drive Harmonization. Actively work with your industry peers, domestically and internationally, in each sector you operate in to harmonize rules and/or create frameworks that map across multiple regulations. A good example of this is the financial sector’s Cyber Risk Institute approach which consolidates 2,300+ regulations into 277 diagnostic statements. 6. Take a Broad View. Look out for regulations, especially during comment periods, that might not ostensibly be about security, privacy or resilience but could in any case have significant impact on these as a second order effect. 7. Transitive Compliance. Watch out for (this can sometimes be a positive effect) compliance expectations that confer obligations to uphold other rule-sets you might not have considered in scope. Bottom line: just because compliance doesn’t assure all security needs are met doesn’t mean it is bad - it just means you have to do more. Good compliance is a useful baseline, but not sufficient to mitigate all risk. Get over it, and if you’re a security person that lauds one compliance regime for someone else (e.g. environmental protection) then think hard if you don’t also laud similar approaches for security to be applied to you. The key thing is to accept it is never going to be perfect and to work hard in partnership to continuously improve the rule set.
Comments