• Home
• /
• Categories
• /
• Compliance
• /
• The Dichotomy of Compliance & Security

The Dichotomy of Compliance & Security

By Chad Thiemann & Becki Memmer, Dallas Baptist University, Adjunct Professors of Cybersecurity

In the ever-changing world of cybersecurity, one constant remains – that Compliance does not equate to Security.  Unfortunately, in many organizations today, compliance will often take priority over security, under the misguided perception that they are one in the same.  Simply put, maintaining compliance with any of the prevailing cybersecurity frameworks, control standards, or regulations alone (i.e., HIPAA, NIST, ISO 27000, PCI-DSS, HiTRUST, or others) is materially different than having an effective cybersecurity program. To examine this in greater depth, let us look at two examples where compliance failed at delivering the intended goal.  The first example takes us back to a cold dark evening on April 15, 1912, in the North Atlantic Ocean.  When the RMS Titanic sank, killing over 1500 of the 2224 passengers, people inquired as to why the ship only had 20 lifeboats capable of holding 1178 passengers.  The answer was quite simple, 20 lifeboats were what was required to be compliant with British Board of Trade requirements at the time.[1]   This example demonstrates how compliance does not equate to safety or security and how dated regulations often fail to keep pace with emerging threats and vulnerabilities. The second example where compliance failed to ensure security is the Target data breach.  In this case, in September of 2013, Target was found to be compliant with the PCI-DSS (Payment Card Industry Data Security Standard) roughly 6 weeks before the breach occurred.  Various cybersecurity researchers have garnered that with the Target incident there were several contributing factors that led to the breach and resultant data loss:  3^rd party vendor subjected to phishing attacks; lack of network segmentation; point of sales system was vulnerable to memory scraping malware, and SOC detection capabilities failed.  Ultimately, Target lost sensitive data on roughly 70 million customers and suffered considerable financial and reputational implications.[2]  The Target compromise demonstrates that cybercriminals can conduct operations that, “involve intrusion, lateral movement, and data exfiltration in complex retail networks that are designed to meet PCI-DSS compliance obligations.”[3]This is the epitome of being compliant, but not secure. It also demonstrates that compliance is a measure of adherence to a standard or framework for a given point in time. What these two examples highlight is that compliance efforts (as they pertain to cybersecurity) and their related frameworks, standards or regulations are often too rigid, overly generic, and merely serve as a minimum set of controls.  Compliance related standards are static, lag years behind technology innovations, fail to keep up with rapidly evolving threats, and are blind to the unique security risks and objectives of a given organization.  For example, the lineage of the ISO 27001/27002 Framework averaged roughly 7.5 years between updates.  Conversely, CVEs, (short for Common Vulnerabilities and Exposures) have grown year-over-year at an alarming rate (1974%) in the same period as evidenced by the chart below. Many compliance requirements are also simply too vague and often implemented in insecure ways.  For example, HIPAA recommends covered entities and business associates encrypt protected health information (PHI) at rest.  But what good is implementing encryption of data at rest if you also store the encryption keys on the same server as the data?   This is where compliance requirements often lack value and security processes, such as an encryption key management process – alongside encryption of data at rest, can better secure and protect assets. While compliance efforts, such as SOC 2 attestations or ISO certifications are part of doing business, they must not be the lone indicator of cybersecurity, as certifications (i.e., compliance alone) will not prevent the risk of a cyberattack.[4]  An effective cybersecurity program should be capable of assimilating real-time requirements, address ever-evolving threats and vulnerabilities, and determine or apply mitigations while priorities and resources are constantly in flux. Building a proper cyber-security program, however, does not mean that it is mutually exclusive from compliance. A strong program can leverage compliance requirements as an opportunity to showcase your overall maturity. For example, if GDPR or HIPPA compliance is a requirement for your organization then use this exercise to document and understand the data that needs to be protected for the entire organization not just those associated with a compliance initiative. By going beyond the compliance scope and addressing data security you can select the appropriate tools or technologies that not only meet those needs of compliance but could ensure that your data is also encrypted or otherwise protected against other types of threats or vulnerabilities which are a component of your cyber program. As cyber-security programs do their best to prevent attacks and breaches, the expenses to the organization increase exponentially. While some organizations choose not to fully fund these programs because they don’t see the value, others like small-medium size businesses may not have the overall budget to implement the solutions needed for a best-in-class cyber-security program. When forced to decide between compliance and security, compliance will often win, which leaves the organization vulnerable to inevitable breach or attack that may have been prevented with a proper focus on security. By taking advantage of opportunities to combine these efforts, when possible, organizations can ensure that compliance and security are both equally important. [1]"The Titanic: Lifeboats" History on the Net. 2000-2022, Salem Media. February 14, 2022. <https://www.historyonthenet.com/the-titanic-lifeboats> [2]Radichel, Teri. “Case Study: Critical Controls That Could Have Prevented Target Breach.”  SAN GIAC Certification White Paper, 2014, pp.2-4. [3]Jarvis, David & Milletary, Jason.  “Inside a Targeted Point-of-Sale Data Breach.”  Dell SecureWorks Counter Threat Unit - Threat ID: 773, 2014, pg 15. [4]Goldman, Jim.  “Why Cyber Compliance And Cybersecurity Are Not The Same.”  Forbes Technology Council - Innovation.  October 2021, pgs 2-3.