The importance of adopting a security-first mindset and why compliance is a bad substitute for security
How security is different from compliance, why and how a compliance-first mindset hurts security, and more
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
A few weeks ago, I saw a great post on social media, attempting to help companies choose the right infosec framework. The post itself was done quite well but because it was focused on compliance, it got me thinking about how much effort organizations put into security vs compliance, and what that leads to. In this article, I will look into the reasons why compliance efforts often hurt security and how to implement compliance in a way that strengthens it instead, among several other things.
The lost intent of compliance
The intent of implementing compliance requirements is typically to promote security. Regulators, be it government institutions, trade associations, or Information Sharing and Analysis Centers (ISACs), are hoping that by enforcing standards and establishing infrastructure for assessing whether or not organizations adhere to these standards, they can make companies more secure.
While the idea and the motivations deserve our gratitude, the outcomes of compliance initiatives have been rather sub-optimal. Among many reasons why that is the case, two stand out the most:
Because many if not most companies learn about cybersecurity measures in the context of compliance, they naturally draw the sign equal between the two, assuming that compliant is the same as secure.
Because there is typically an external party whose role is to assess if the organization in question is compliant, instead of encouraging organizations to think about security, compliance turns into ticking boxes.
Security and compliance are not the same
Compliant companies may or may not be secure
Here is a simple way to illustrate that security is not compliance. I’ve looked at the list of data breaches that have happened in 2022 and 2023 so far and randomly picked a few known brands. Then, I checked to see how many of them have some kind of security certification, framework, or similar listed on their public site. A very dirty and quick comparison yet no surprise - all the randomly picked companies that were recently breached are ticking the compliance boxes.
Now, don’t take me wrong: all these companies have talented and well-qualified security teams - security engineers, architects, analysts, and the like doing their jobs 24/7. These firms most certainly are in the top percentile of companies that do think security-first, not compliance-first; and yet, even they have gaps. It is easy to see that compliance is not the same as security.
Secure companies may or may not be compliant
A secure company may or may not be compliant. Let’s say a security startup only hires cybersecurity practitioners - engineers, architects, SOC analysts, and so on. While they may do security for a living, they would still be required to complete bi-annual or quarterly training that explains what is phishing and why they shouldn’t be clicking on suspicious links. This is a simplistic example but it is perfect to illustrate the point that compliance is something that needs to be implanted on top; it is not a default state achieved when a company is secure.
Some of the core differences between security and compliance
Security and compliance have different goals and interested parties
Compliance assesses an organization against a list of requirements to ensure that these requirements are met. Parties interested in the company’s compliance are the leadership, customers, and regulatory bodies. Typically compliance designations are achieved to signal trust and tick the boxes for legal, compliance, and procurement teams of the government or the enterprise. In some cases, meeting the requirements of a certain framework is mandatory to operate in an industry.
Security strives to ensure the confidentiality, integrity, and availability of information. Security teams are looking to understand the threats the organization is facing, put measures in place to reduce the probability of breaches, reduce the magnitude of the impact of cyber breaches when they happen, respond to attacks, and recover the affected assets. To accomplish this, a mature security team will seek to gain visibility into the company’s environment, implement detection logic tailored to the organizations to detect bad behavior, conduct proactive threat-hunting activities, and the like.
Clarity of the rules of the game
In compliance, the rules of the engagement are clear and established in advance. There is a well-documented list of principles and requirements, organizations are given a fair warning when they will be assessed against these requirements, who will be doing the assessment, and so on. The boundaries of the interactions are well-defined: depending on the standard in question and auditing firms, it may or may not engage with employees, gain access to information not specifically provided to it by the company, etc.
Security, on the other hand, does not have the same luxury. An attacker may show up at any time (in fact, there is a continuous stream of them working 24/7), will look anywhere it can reach, and seek creative ways to break any previously known rules. Malicious actors will look at every gap, every corner, every vulnerability, in the hope to find the smallest clue for how they can get in.
Motivations of the opponents
Companies engaging auditors are paying to get a certificate of compliance, hence they are incentivized to twist the reality in such a way that gets them the desired outcome (a positive auditor’s report). Compliance assessors typically get paid regardless of their findings, but they know that if the final report will be too negative, the customer will churn and not come back next year. Their goal is to find some minor gaps so that their final report looks more or less objective, but do so without going too far and upsetting the customer with an outright negative finding.
Attackers will only get paid if they are successful in achieving their mission. Their incentives are plain and simple: get what they came for, get as deep as they can, and take as much as they can carry.
The ability to engage in a discourse
Compliance is binary: a measure in question either meets the requirement or doesn’t. However, because there isn’t a scientific way to say to what degree a specific requirement is satisfied, there is a lot of room for creative discourse. Here is an example: a compliance requirement states that “everyone must use a password manager”. A company may implement a “SOC 2 Type 2 compliant” password manager that gets breached every three months, its advisors might not be using any password manager at all, while the CEO could store the master password on a sticky note. If advisors are not company employees, auditors can be convinced that “this is not a big deal”, and if nobody accidentally stumbles upon the CEO’s sticky (why would an auditor be looking for that anyway?), that won’t be mentioned as a violation either. As anyone who has ever been a part of an audit can attest, the process is after all a conversation between two parties, with a lot of negotiation, discussions, and cover-ups.
Attackers have neither time nor desire to engage in a discourse. They are not trying to disprove anybody’s convictions about their security (except the activist hackers but that’s a different story altogether). Bad actors have a job to do, and if they find a gap - they will exploit it. They don’t care if Josh is new and hasn’t completed his security training yet, or if Maria really needs access to her accounting system when traveling abroad. There is no discussion to be had: if the attacker can find and take advantage of a security gap, the game is over.
Level of detail involved
Compliance is interested in a high-level picture. Is there a training program for employees? Yes or no. Is there an appropriate patch management program in place? Yes or no. Is there a vulnerability disclosure program in place? Yes or no.
Security is concerned with tactical details. How can we reduce the chances that employees click on a phishing link? Once someone inevitably clicks on that link - how do we reduce the magnitude of the damage this can cause? How do we test and apply software updates? How often? How do we know that all workstations have been patched? How about servers and other critical machines? What happens after a vulnerability is found? How do we get our customers to patch the product once an update is released?
The importance of prioritization
Compliance is about satisfying a laundry list of requirements that are all of equal importance. If there are 150 checkboxes required, it means that to get a positive auditor review, all 150 need to be ticked as “complete”.
Security, on the other hand, is about ruthless, context-based prioritization. There is always more that can be done, the question a security team must answer every single day is about what it should be focusing on to make the most difference given the threats it is facing. Getting everyone to enable and always use a strong MFA may be much more important than patching an old computer in the warehouse used to print assembly instructions for bar stools and not connected to any other system. The 150 compliance boxes may have the same weight for meeting compliance requirements, but they are not nearly of the same importance for security.
The frequency of changes
Compliance is static as it assumes that an auditor’s review and a penetration test completed once or twice a year are reflective of an organization’s ability to defend its data at any given time during that year. This is not to mention that any compliance audit is accompanied by a few months of internal preparation so that everything “is ready” and looks good for the auditors.
Unfortunately, this is not how security works. Every second, new containers are being spun up and down, new users log in, new lines of code are released to production, new threat actors enter the space with new goals, skills, and tools to pursue their goals, and so on. The organization’s environment and its risk profile are incredibly dynamic, and even if there was a way to assess its security posture with certainty (which there isn’t), the results of the assessment would be outdated a second later.
The role of context
Let’s say a compliance requirement suggests that to be considered healthy, one “must ensure to get a sufficient level of vitamins and micronutrients through healthy eating. For example, peanuts and other types of nuts are a great source of vitamin D, while drinking milk is a great way to get enough Calcium”. For an average person, that might be great advice, but the same recommendation can kill someone with a severe allergy to peanuts and greatly inconvenience those with lactose intolerance. In compliance, context doesn’t matter as much as companies that are put into certain buckets, need to “comply” with all requirements applicable to that bucket.
The opposite is true in security where context is everything: the slightest variation in how an organization operates, what it does, what technology it uses, or where employees are expected to access their devices, can mean completely different security measures that need to be put in place. Compliance ignores all these variations. It’s worth noting that while many compliance standards are not prescriptive, companies that equate compliance to security do not typically have the expertise to tailor the coverage to their unique needs, and therefore end up implementing boilerplate recommendations that make them compliant without making them secure.
A brief look at governance, security frameworks, and maturity models
It is all too common to see things like SOC 2, NIST, PCI, ISO, HIPAA, UL, CSA CSM, CIS, and OWASP all lumped together into one list, even though they are not all the same.
Governance concerns establishing policies and procedures within an organization to establish rules such as the frequency of patching software, getting a sign-off for accessing sensitive data, training new employees about handling customer information, and the like. Although governance policies and compliance requirements commonly overlap, they are not the same. Unlike compliance which is driven by external parties and their requirements, governance is inwardly-focused. An example is an HR policy: a good policy is actionable and helpful in guiding the employees about how to do their jobs. Similar to compliance requirements, governance policies become less than useful as soon as the systems and processes they describe diverge from the organization’s reality. In organizations concerned with being compliant, compliance requirements are typically input into governance. Whenever it happens, the chances that governance policies will become detailed, unnecessarily wordy, and detached from real life go up dramatically.
Security frameworks offer guidance about best practices and approaches that have proven to be useful for different types of organizations. Similar to compliance standards, these are developed, maintained, and updated by external bodies, but unlike compliance requirements, adherence to security frameworks is completely voluntary. Frameworks are developed by experienced leaders and practitioners and provided as a resource so that companies and organizations can learn what measures, practices, and approaches have worked, and where to get started when looking to strengthen an organization’s security posture. Many frameworks focus on offering an angle from which an organization’s security team can tackle its work. A good example of a security framework that has proven to be incredibly useful is Cyber Defense Matrix developed by Sounil Yu.
Security maturity models are ways in which organizations can assess their security measures to see how their level of maturity compares to those of other organizations. Maturity models are a good tool for benchmarking and analyzing what steps an organization needs to take to continue improving its security posture. A good example of maturity models is The Detection Engineering Maturity Matrix developed by Kyle Bailey.
Security frameworks and maturity models can be useful resources for security teams to assess, plan, and prioritize their work so that they can continuously improve their security levels. Governance policies are typically the result of using all the available tools and incorporating compliance measures. On their own, governance policies are both useful and important, but when infused with excessive legalese to make an organization compliant with some standards, they become long, unnecessarily complex, impossible to use in daily work, and therefore ignored. Most importantly, security leaders must not get overly focused on models, be mindful of their limitations, and be proactive in avoiding common security framework traps. At the end of the day, it’s the practical implementation of security measures that matters, not what framework they came from.
Difference between security-first and compliance-first mindsets
Both compliance and security are important. Security is necessary to protect the organization against bad actors looking to cause harm. Compliance, on the other hand, is something that is needed to successfully compete in the market. Since few people can tell from the outside how secure a given company is, they are looking for some proxy, and the closest one, whether we like it or not, is compliance. Although as I have explained the two are quite different, in real life companies that are not compliant are unlikely to be secure (the opposite is equally rare).
I have observed that companies with high maturity in their security operations see compliance as a necessity. This is especially the case in cybersecurity where trust plays a critical role in customer acquisition: if you want to sell to the enterprise, you need SOC 2; to work with the US government, you have to meet the requirements of FedRAMP; to process payment cards, you need to adhere to PCI DSS.
Treating compliance as a necessity means layering it on top of security that functions independently, and that seeks to protect the organization, its assets, and continuity. After a security team has done what it needs to do to address the risks, the compliance department can do the review, see what parts of frameworks and requirements are already addressed, identify those that aren’t, and bring them to the security team’s attention. Ideally, an organization would not be implementing anything just to “tick the box”, but if it must, it can do so in a way that strengthens its security posture, instead of just checking the compliance box.
The path I am describing is called a security-first mindset: security walks ahead and works to secure the organization, while compliance documents what is done, and explains how what’s being done makes it compliant.
Unfortunately, what we tend to see is that many organizations adopt the opposite, the compliance-first mindset. A compliance-first mindset means that instead of starting by gaining full visibility into the company’s security posture and implementing security measures to protect the crown jewels of the business, the organization begins by pulling the hundreds of pages of “compliance standards” and starting to implement processes it deems necessary to convince auditors that it is compliant.
Unfortunately, despite the best efforts, a compliance-first mindset helps defend against auditors, not attackers. No framework, however “comprehensive” it may be, leads to security. Moreover, adopting a compliance mindset can greatly hurt an organization’s security efforts.
Why and how a compliance-first mindset hurts security
Compliance certifications lead to a false sense of security
Security is hard, and it is constantly evolving. Knowing that no matter what you do and how well you do it it may not be enough is scary, overwhelming, and demotivating. It is understandable why it might be tempting to retreat to the certainty offered by compliance. Unfortunately, that is generally a bad idea.
Compliance certifications can lead to a false sense of security. The leadership of an organization that was just assessed by a third party and deemed as meeting or exceeding requirements may assume that they are doing a “great job” with security when that may not necessarily be the case. Some might go as far as to suggest that the security team is asking to make unnecessary investments when everything appears to be “good enough”. This behavior can hurt security efforts and stifle the adoption of measures that need to be put in place.
It is all too common for companies to make claims that are entirely disconnected from their real-life practices. “We patch all of our systems on time”, “all our employees are using the password manager”, and “we regularly test our backups” - all these and many other claims are almost always untrue. The problem is that because that’s what the compliance department and the auditor’s report say the company does, it blindsides the leadership and makes them live in a world that doesn’t exist; a world that is shattered as soon as the actual attack happens.
Compliance requirements are outdated the day they are released
Similar to university textbooks about security, compliance requirements are outdated the same day they are published. The threat landscape is incredibly dynamic, and something that is agreed on by many people as a result of consensus and updated every few years or every year at best cannot keep up with new developments. Between the time bad actors discover and exploit new attack vectors, or the time threat researchers identify new risks, the time a framework is updated with these findings, and the time organizations are required to upgrade their measures to remain “current” with the framework can be many months and years - too long for effective cyber defense.
A case in point is ISO 27001: the first version of ISO 27001 was released in 2005 (ISO/IEC 27001:2005), the second version in 2013, and the current version in October 2022. It took eight years between the first and the second version, and another nine years before the current one was published. In other words, as of September 2022, companies were using a standard developed 7 years before the global pandemic, two years before Amazon released Amazon Echo and the Alexa ecosystem, a full year before the launch of Slack, and a year before USB-C became a thing. Putting it into perspective really changes how we view the frameworks and standards and makes it clear that those who rely on frameworks and compliance for their security are at best a decade behind where they should be. This is akin to trying to ride a horse on a high-speed highway: conceptually, it should work, but there is no universe in which it wouldn’t endanger lives and lead to issues.
In a fight between compliance and security, compliance wins most of the time
In theory, the goal of security and compliance should be the same: to protect an organization against bad actors with security responsible for implementing the protection measures, and compliance verifying that these measures are in place. Unfortunately, not only as we’ve already seen their aims are different, but compliance often leads to implementing bad security practices.
In most organizations, whenever a security measure conflicts with a compliance requirement, compliance will win the battle. Company executives are comparing two potential outcomes: a highly likely negative line in the auditor report, and a potential security issue of unknown likelihood. Given the common perception that “if a compliance body says something, it must be working”, it is no surprise that security teams often lose against compliance requirements.
Compliance-first mindset makes it hard to retain top security talent
Talented security practitioners get severely discouraged every time a sound security measure is sacrificed just to tick a compliance checkbox, and rightfully so. Security teams are hired to protect their organization’s environment, proactively hunt for attackers, and reduce the impact of a cyber breach when it inevitably happens. When compliance gets in the way of what is right for strengthening security, it undermines their ability to do what security teams are hired to do, yet they are expected to still own the problem when the security event occurs.
Compliance-first mindset leads to poor morale, and subsequently - to issues with hiring and retaining top security talent. Given that it is already hard to attract and keep senior security practitioners, high churn rates can be a disaster for the company and its ability to defend itself from attackers.
Compliance-first and compliance-only mindset makes the job of an attacker easier
When companies sacrifice their security for compliance or only implement whatever is mandated by a certain framework or regulation, not only do they fail to establish a strong security posture, but also they make the job of an attacker easier.
Organizations that embrace compliance-first or worse yet, compliance-only mindset, provide a guideline for cybercriminals where to look for. Adversaries have access to the same frameworks, and sometimes they can even obtain SOC 2 reports and the like which they can study to find exploitable gaps and loopholes.
It’s hard to blame organizations for adopting a compliance-first mindset
Compliance-first mindset is one of the factors that can be blamed for the ever-growing number of cyber breaches. It is not, however, fair to cast the blame on organizations mistaking compliance for security. To an untrained eye, the two can indeed look the same: they use similar vocabulary, they talk about similar controls, and they are commonly sold in the same package. Many companies mistakenly believe that there is a strong correlation between compliance and security and that checking a compliance box is a good way to “do their best”.
Not only we must not judge the unsuspecting customers for not being able to see the difference between security and compliance, but we as the industry should be taking ownership of perpetuating this confusion. There is an ever-growing number of companies promoting compliance and selling it as all-in-one security. They don’t shy away from making statements such as “secure your business by getting SOC 2 certified” and the like - messages that are not just untrue but incredibly damaging to the customers.
Choosing a security-first mindset and extracting benefits from compliance as a necessity
Embracing a security-first mindset means that a company does not start implementing its security measures by looking at compliance requirements. Instead, it asks some fundamental questions including:
What business are we in?
What are we trying to protect? How should we go about doing it?
How do we know what is happening in our environment?
What behaviors can be seen as potential signs of bad actors in our environment? How can we detect them?
Once a certain behavior is detected, how are we responding?
How do we know if the measures we put in place are working?
SOC 2, ISO 27001, PCI-DSS, and other frameworks and standards do not have answers to these questions. I have previously talked about the move from promise-based security to evidence-based security and it is worth mentioning it here as promise-based security is commonly accompanied by and implemented because of the compliance-first mindset.
“The best way to build a security posture is to build it on top of controls and infrastructure that can be observed, tested, and enhanced. It is not built on promises from vendors that must be taken at face value. This means that the exact set of malicious activity and behavior you’re protected from should be known and you should be able to test and prove this.” - Source: Venture in Security
Compliance is a necessity that should be layered on top of the security measures the organization has in place. This does not, however, mean that compliance is useless for security. On the contrary, when used the right way, compliance standards such as PCI and SOC 2 can be great sources of information. They are all incredibly comprehensive guides that draw attention to large areas which may need additional effort. By treating compliance requirements as questions to think about as opposed to compliance boxes to check off, companies can prioritize the right things. Mature security teams should also look for ways to maximize the value of compliance audits. While most companies just want to get a passing grade quickly and embrace an attitude that they “need to get through an audit”, there is value in analyzing and acting on any feedback about the organization’s security measures, regardless of the source of this feedback.
Closing thoughts
There is a lot of noise in cybersecurity about the value of security frameworks, certifications, and standards. It is understandable as many security leaders and practitioners are actively contributing to their development. While security frameworks, best practices, standards, and the like are certainly useful, the value comes from having the security team use them as tools to better do their work, not as to-do lists. If relied upon as a sole source of security measures with no critical analysis and consideration of the organization’s context, compliance requirements can harm organizations more than help.
In discussions about standards and compliance requirements, we can’t lose sight of what we are up against: a well-motivated, well-funded, and technically-savvy adversary. Bad actors don’t care if we are SOC 2 Type 2, PCI DSS, or FedRAMP certified, and if we have implemented the latest version of the NIST framework. They are looking for gaps in our security, not in our compliance. Every day, the offense is learning new tech and new ways to break into the organizations to accomplish their goals. Therefore, organizations of all sizes must invest in their security first, and treat compliance as a second-class citizen that, while necessary, cannot define how the company chooses to secure itself.
My mind goes back to the quote I read a few weeks ago: "Do you want to mitigate against an auditor, or an attacker?" (Author Unknown). It sounds provocative yet profound: by choosing to mitigate against auditors, we are creating a world where everyone is secure on paper but incredibly vulnerable in reality. Attackers who know what they are doing see frameworks and tools not as obstacles but as potential gaps that can be exploited.
Companies and organizations of all sizes should be striving to adopt a security-first mindset, and continuously look for ways to improve their security posture, regardless of compliance requirements. Defense in depth, zero trust (as an approach, not a “product”), continuous testing of the organization’s security measures, developing custom detections coverage tailored to the company environment and the way it conducts business instead of relying solely on security vendors, and other approaches will help security teams defend their organizations better than auditor’s reports. Furthermore, companies must hire practitioners who understand technology at multiple levels - starting with the code, and assembly language, and up to protocols, frameworks, and integrations. Without a solid understanding of how the technology is built and how the code can be subverted to do what it wasn’t designed to do, it is not possible to build effective defenses. Someone with their hands on the keyboard and experience programming and creating software we use cannot be stopped by generic detection logic and an inexperienced analyst.
Security is a fight where smart people go head to head with other smart people. That is why skilled security practitioners, not compliance frameworks, are the right way to achieve an advantage over the adversary.
Excellent content explaining in-depth the realities of the whole issue around audit vs real security mindset. OWASP compliance isn't a thing though despite companies out there still trying to claim that.
What an amazing approach! Been questioning myself many many times. A challenging question though is which mindset to choose when compliance with a standard is not just a requirement or nice to have but an absolute business enabler. In other words, if you ate not compliant with standard X, you cannot sell to anyone. Is a balance achievable in that case, especially when the standard is old-fashioned?