aka Compliance-based Security in an Enterprise environment
First off, I’d like to preface this with a disclaimer, in the hopes of calming down those who are already angry simply from the title of this post, and won’t read any further before responding: I DO NOT BELIEVE COMPLIANCE = SECURITY.
However this is not something I see talked about very often, and from the few discussions I have had with people around this topic, I believe it to be more widespread than many would expect given how little it is openly discussed.
For the purposes of this argument, I will narrowly define “real” security as focusing on the larger, more in-depth frameworks (things like ISO27001, NIST Cybersecurity Framework, NIST 800-53, FedRAMP, FISMA). Companies that do things like threat detection, invest in their security team, build out their own SOC. You know, “security in depth”. Often it is larger companies that post about how they do this – Google, Amazon, Facebook – the ones that have the financial backing to pour money into the Security cost-center. A lot of smaller companies can struggle with this. Simply put – Security is Expensive. Whether it is hiring in highly experienced staff, building and training a team from scratch, building out your security toolkit and purchasing the technology to do so, or outsourcing to the many vendors that offer these services (AlienVault, Rapid7, AlertLogic, Splunk, etc). For those companies willing to invest in Security, selling these technologies and cultures, along with the associated costs, is relatively easy. Often it is not necessary to provide a direct link between the costs and the increase in revenue.
With that out of the way, one thing I have learnt over my time in the industry is that when it comes to security – and more specifically, getting budget for security – a lot of executives are not interested in “real” security. They have compliance goals in mind, and get a lot of pressure from customers, usually via the sales team, and from the board/shareholders to meet these compliance requirements.
This is not to say all companies are like this, or all executives are like this. Not even that this is limited to a certain size of company. My experience so far has been mixed with regards to this, both large, small & mid-size companies, with everything from extremely security-minded executives through to compliance-oriented and also some completely non-caring executives.
Depending on the corporate culture, and I suspect the market vertical (I have been largely within the software market for most of my career), the success and tenure of the security-minded executives can often be frustrating and short-lived.
Before moving on, a little about me, because I rarely post anything more than vague tweets. While my focus has long been on security, I am within the Operations organization within my company. DevOps, SysOps, DevSecOps, is there such a thing as ComplianceOps? I seem to have a varied role currently. I’m privileged enough to have been with my current company long enough that I am one of the longest-tenured employees at present. This has given me the ability to be a little more outspoken within the organization than I likely would be at my level in another organization. As we are a relatively small to mid-size organization I am often brought into many discussions and decision making processes that would normally be made at a upper management level, which makes for some interesting learning opportunities. I am currently working to extract myself somewhat from the day-to-day operations side, and move into a more dedicated Security & Compliance role.
I spend a lot of time reading what others in the industry write, and try to absorb the learnings so as to try to avoid causing similar issues. One side effect of that is that I get a lot of ‘i-told-you-so’ moments, as new management rotate in to the company, and don’t listen to things I say that seem obvious to me (having been there as long as I have). While complex, the enterprise information security industry doesn’t seem to be rocket surgery for the most part, as long as you pay attention to what is going on, both within and outside your organization, and can get some reasonable level of visibility into the workings of your organization, a lot of decisions seem to make themselves, or at the very least narrow the number of choices you need to make.
Some of the above will no doubt trigger some “exciting” feedback. Be respectful please, but I welcome it. I am definitely still learning, and have a lot of likely-incorrect opinions about things still. I feel like I’m now approaching the point where I know just enough to know I don’t know much.
Back to the story though.
One of the things that has slowly been building up in my mind is the difference in how a Security team must operate in organizations with a Compliance = Security culture, versus companies that believe in “real” information security.
However you want to name the Security organization within your company – Security, Information Security, IT Security, whatever – the fact remains that it is, from a financial viewpoint, a cost-center. At best it is a form of insurance. The Information Security organization is there to identify the risks to the company from a technical standpoint. Often this will go so far as physical security for the company, but I’ve found this often falls to “IT” or property services type organizations, depending on the size of the company.
As a member of your company’s Security organization, it is your job to identify and surface these risks, and determine the threat vectors, the likelihood of exploitation, and (usually, but not always) the potential financial impact were one of these risk to be exploited.
When it comes to a company that does “real” security this is often relatively straightforward. For a company that believes Compliance=Security (or Compliance over Security) this is significantly more complex.
When it comes to Compliance-based organizations (I’ve worked, or am currently working through: PCI-DSS, HIPAA, GDPR), there is often a mandate to tie the “security” costs back to increased revenue. This really comes in the form of Compliance attestations the sales team can put in front of customers to sell your products, or Compliance concerns that potential customers have surfaced as show-stoppers as they come down the sales pipeline.
This means things like FIM, IDS/IPS, vulnerability scanning, penetration testing are easier to sell to the organization. You can directly tie these back to PCI (PCI Section 11). Data flow diagrams, PII protections (encryption, obfuscation, pseudonymization) can be tied back to GDPR requirements. Official security policies and security training for staff can be tied back to all of these.
However once you start looking at more in-depth defenses, it gets harder to justify the costs to the company, as technically you likely have already “ticked the box” for the compliance target.
Things like building out a SOC to fully monitor your security & vulnerabilty alerting can be super expensive, and even outsourcing this is often more than a company that is purely Compliance-focused is willing to accept.
Even “basic” things like fully encrypting all devices, particularly if it hasn’t been done consistently in the past, can be hard to do. The impact to staff can be intolerable, especially if your company has a lot of remote employees. Even things like SDLC, while definitely a compliance requirement, often only get enough company/culture buy-in to pass the lowest possible bar required for compliance.
One thing that seems to come up in non-cloud-native companies, or those with a mixed environment, is that some of the basic security and compliance requirements often require ensuring your hardware and software is reasonably modern. Once you have a significant legacy codebase this becomes a lot of work, especially if your codebase ties in to hooks for specific Operating Systems that may have changed over the years. I’ve come to realize that a lot of organizations only spend enough to stay online, and focus the spending on the next shiny new feature they can sell. This results in aging infrastructure and unmaintained codebases that may suddenly have compliance requirements thrust upon them, and it almost always falls to the Security team to drive the fixes.
Cloud native companies often find the costs for keeping up with compliance requirements to be lower as a lot of the heavy lifting is done by the cloud provider. Also most (I hope) cloud native companies were built with security in mind, as they have grown up in the relatively recent past, with better security being more widely discussed, and (perhaps I’m being too naive here) something that should be considered table-stakes these days.
The result of this can be that the Security team gains a reputation as “those people” that “block development” or “make us do things we don’t want to do”. I understand no-one wants to be the one who has to go back and decipher undocumented, or, arguably worse, incorrectly documented code and systems, however this is not just a Software Engineering problem. It falls to the Systems Engineers as well – to make sure everything is brought up to scratch. Both teams need to work together.
I certainly struggle with the Compliance=Security mindset and how to sell “real” security to Compliance-oriented executives to meet their compliance mandate while still providing the best security posture possible for the company. This is something I’m actively working on, and welcome any feedback or reading recommendations.
While Security should be everyone’s concern, generally the Security team (and, to go a little further, the InfoSec community at large) need to be aware that “educating the user” will only take us so far, and it’s is up to the community to drive the improvements in any way possible, without relying on blaming the end-user for security concerns.
This is starting to ramble on, so I’ll end with one last thought that has been developing more in my head over the last few weeks:
Compliance requirements do not stem from a company’s Security team. They are business requirements that stem from the company executive strategy. If this is not clearly communicated by the executive team to the organization as a whole, the Security team will have massive resistance to overcome driving the necessary changes, and will become the sacrifical lamb if the compliance requirements are not met.
A few relevant references (no doubt there are better ones, these are just one’s I already have handy):
https://www.pcisecuritystandards.org/document_library