Compliance vs Security: Are They the Same?

Earlier this year I had the pleasure of speaking alongside my colleague, Haya Ahmed, at the Executive Women’s Forum conference. Our presentation discussed the intersection of compliance and security. It’s difficult to have one without the other, but the order in which the focus is placed is important! Here is a quick recap and some useful resources to help boost your compliance and security posture. 

Compliance Vs. Security

Compliance and security are not the same thing. Security is the implementation of technical controls, cultural norms, and procedures that protect digital assets from threats - security helps you manage risk. Compliance is meeting requirements of a third party for business or legal reasons. There are two kinds of compliance - Regulatory compliance and framework compliance. Regulatory compliance is meeting compliance requirements just for the sake of “being compliant”. Framework compliance is the use of a framework to help bolster your security program. 

Why Compliance Shouldn’t Be the Only Goal

It’s important to ensure the focus is on creating a security first culture. There are a number of reasons why relying only on compliance can be problematic. 

• Compliance controls are not always comprehensive or clear. Frequently, controls within compliance frameworks aren’t prescriptive and can be interpreted in many different ways, leading to ambiguity. 
• Most compliance requirements are a point-in-time snapshot of your environment. Just because all requirements are being met at that time doesn’t mean they always will be. 
• Compliance frameworks don’t cover all possible vectors of attacks. This allows for significant gaps if not accompanied by a security based culture. 
• Compliance Frameworks are not always up-to-date. Before this year, the last updates to HIPAA and FedRamp were in 2013 and 2014, respectively. 

Now, this is not to say that compliance is bad. However, the way that it is obtained and the reason behind it truly are important. Compliance does not result in good security but good security often results in compliance.

Frameworks as a Starting Point

For companies that don’t have a mature cybersecurity program, frameworks provide a starting point and a roadmap to help define your cybersecurity strategy. They can also be a useful tool to measure the improvement of your security posture over time. Cybersecurity frameworks tend to be more holistic than regulatory compliance frameworks. Although cybersecurity frameworks may not be strictly speaking “required” from a regulatory perspective, they are incredibly useful tools to augment both compliance and security. Here are a few common frameworks:

• ISO 27001: The ISO 27001 is both a framework and an accreditation. It’s an internationally recognized standard, and is rigorous to obtain. For some large, multinational companies ISO 27001 may be a requirement to do business.
• NIST: The NIST family of frameworks such as NIST 800-53 and NIST Cybersecurity Frameworks are a set of standards developed by the federal government, but can be applied to any company. These are commonly seen in larger US-based companies.
• CIS Controls and Benchmarks: CIS Controls are consensus-driven, easily readable, prioritized and action-based set of controls. This is useful for smaller companies that are starting out their security programs, They also complement broader frameworks like NIST and ISO. Related to CIS Controls are CIS Benchmarks, which update every year and have platform-specific security best-practices (for example, AWS, GCP, and Kubernetes). 
  
  

Moving Beyond Frameworks

Frameworks are an excellent place to start, but security needs to be integrated into every aspect of a company and its culture. This integration is sometimes called “shifting-left”. This means:

• Building security into your development and migration process as early as possible. This means involving security engineers, architects, and possibly consultants into projects right from the start of the project
• Integrating secure best practices throughout the development process of your applications. An example is designing applications starting from least privilege when it comes to IAM.
• Using preventative guardrails to prevent the creation of misconfigured resources. 
• Leveraging automation as much as possible. This should be integrated into various levels of the security workflow to improve consistency and scalability, reduce human error, and increases response times
  
  

Going Above and Beyond Compliant

Let’s discuss how you can build security and compliance into your processes.

9 Steps To Become Compliant and Secure

1. Cultural Shift: Start with a top-down cultural shift, emphasizing security from the CEO to junior employees.
2. Communication: Foster communication through regular security awareness training and embed security responsibility in all roles. 
3. Preventative Guardrails: Leverage automation and the "shift-left" philosophy with tools like Open Policy Agent, Google Cloud Organizational Policies, and AWS Service Control Policies.
4. CI/CD Pipeline Security: Implement security checks within the CI/CD pipeline using industry-standard tools like GitHub Actions. Include basic checks such as branch protection and prevention of accidental exposure of secret credentials.
5. Infastructure-as-Code (IaC): Use IaC tools like Terraform for rapid and secure resource deployment. Provide pre-configured secure-by-design infrastructure modules for developers.
6. Continuous Monitory and Logging: Implement continuous monitoring, logging, and detection. Use a Security Information and Event Management (SIEM) tool like Splunk for effective incident response.
7. Compliance Frameworks: Align with regulatory compliance frameworks such as PCI. Optimize logging and detection capabilities to meet specific compliance requirements.
8. Automated Alerts: Set up automated alerts for high-priority incidents or highly privileged activities to ensure a timely response.
9. Cloud Native Tools: Leverage Cloud Native tools, such as AWS Audit Manager and AWS Config, for assessments against compliance frameworks. Consider tools like GCP Security Command Center for specific compliance assessments, though AWS offerings are more extensive.

To begin with, security starts from the top down. This must be a cultural shift of your organization to place a focus on security from the CEO to its most junior level employees. To do this, communication is key. Hold regular security awareness trainings and embed the responsibility for security into all roles across the organization. Encourage cross team communication and provide support for a partnership between the GRC and Security teams.

One of the most powerful ways to leverage automation and the “shift-left” philosophy is to implement preventative guardrails. Examples of tools that can help with this are Policy-as-Code tools such as Open Policy Agent. There are also Cloud-Native services that can serve as preventative guardrails.  For example, Organizational Policies in Google Cloud and Service Control Policies in AWS. These are exceptionally powerful tools because they can prevent a wide variety of security misconfigurations from occurring in the first place.

Another great component is security checks within the CICD pipeline. Github and CICD tools such as Github Actions are industry standards. Basic checks such as branch protection so things aren’t pushed to production without review, and tools to ensure secret credentials aren’t accidentally committed to a repository, should always be included. 

In the cloud, the deployment of resources happens rapidly, and Infrastructure-as-Code tools such as Terraform are instrumental in facilitating this, both from a business and security perspective. Having pre-configured secure-by-design infrastructure-as-code modules that developers can use is a key component of secure-by-design. 

Implementing continuous monitoring, logging, detection, and using a SIEM such as Splunk, to aid in incident response is also key. Regulatory compliance frameworks, such as PCI, may have specific requirements on the types of logs that should be generated. Many frameworks, both regulatory and cybersecurity, specifically call out having an incident response plan, but the ability to respond to an incident depends on the detection capabilities that are in place. Optimizing your logging, detection, and SIEM capabilities is imperative. This also means at the very minimum, having automated alerts sent to relevant teams for high-priority incidents or highly-privileged activities.

Finally, there are various Cloud Native tools that can help. AWS is particularly robust in providing tools to automate aspects of compliance. AWS Audit Manager can assess your environment and provide reports on how your environment fares against various compliance frameworks. AWS Config can be used to detect both security misconfigurations and configurations that break compliance requirements. AWS Config comes with starter packs of Config rules mapping to dozens of frameworks. These AWS detection rules can also periodically scan your AWS environment, providing a continuous assessment of your compliance posture. GCP has Security Command center that can assess a small number of compliance frameworks, such as PCI or NIST. However, their offerings are not as extensive as AWS.