How can Security Governance provide a strong baseline for managing Security Risk and Compliance?

Compliance does not equal Security. We hear this phrase often. Is it true? In fact, most companies have Security, Assurance, Risk, and Compliance as siloed functions that are disconnected from each other. They operate at different frequencies and on different metrics. However, if you were to report on the overall Security posture, or monitor for Compliance (I prefer to use “Assurance”), you would quickly realize that the governing principles for managing security risks are pretty much the same. Then why the heck do we not achieve synergies between the Security, Risk, and Compliance teams? Therein lies the conundrum.

• The Security team is in constant firefighting mode. With significantly shortening production releases and a widening surface area of attacks. They are forced to focus on specific security domains such as vulnerability management and endpoint protection, and in most cases don’t have time to continuously manage the overall security hygiene. Also, given the high signal-to-noise ratio on software vulnerabilities, they seem to almost exclusively focus on APT threats and coordinating vulnerability remediation.
• On the other hand, the Security Assurance/Compliance teams, which perform an audit and assurance function for IT and Security, suffer from an absolute lack of care and feeding. They are seen as necessary evils in most organizations. I once met with the CTO of a business unit in Prudential Financial. At that time, she also had the responsibility for security compliance of her product lines. She said; “(security) Compliance is a thankless job. We may not get a pat on the back for doing a fantastic job but we will surely get fired if we screw up”. However, most security assurance teams are highly knowledgeable, specialized, and acutely understand the security and the risk contexts of the organization. These teams have the capability but just need the right tools to collaborate and automate to operate at the speed of development and security teams.

Security leaders managing both these functions within their organization have a tough job. They will need to balance developer productivity and innovation with protection. As Assaf Keren put it, they will need to model and promote security and risk into the daily lifestyles of everyone involved in the company. DevOps and Cloud (and in particular, Kubernetes) provide a solid base to effectively solve this problem. We see that Security Engineering and Operations have shifted left and SecDevOps is real with most companies. However, that solves only one half (the bigger half!) of the problem. It is important that we also shift Security Governance, Risk, and Compliance left.

The key building blocks required to shift Security GRC left are a) programmable GRC, b) deep integration with collaboration tools, c) a declarative approach to policy management, and d) distributed, scalable, and easy-to-use rules/policy x-code engine. Please check out our manifesto for further explanation of these aspects.

In addition, everything must be measurable, quantifiable, and comparable through the normalization of the measurement domains to address the issues holistically. Most Compliance and Risk frameworks are a nested hierarchy of controls. In the case of PCI-DSS 3.2.1, it is organized across 6 broad principles and 12 requirements and a total of 235 controls (sub-requirements and testing procedures). MiTRE ATT&CK v2 is organized across 12 tactics and 330 techniques (and further sub-techniques). CSA CCM v4.0 across 17 security domains and 260 controls. Each of these frameworks brings a specific focus to the nature of security, data protection, data privacy, containing systems, and process controls. Many of these process controls tend to be manual, based on how the organization has implemented them. For those controls that are automatable, through automated data collection and workflow techniques, normalizing them across systems and frameworks makes everything comparable with context resulting in the following:

• A compliance-agnostic governance and security and data posture management structure that is closer to security engineering and operations
• Avoidance of repetitive and redundant control testing across multiple compliance regimes. Execute once and use across multiple controls.
• Inheritance and extension of data models across different control objectives. For example, enumerated RBAC access and reviews (6.8) in CIS Controls V8 can map to separation of duties (6.1) in PCI-DSS 3.2.1
• Improvement of security operations and management by providing signals and heuristics of systems configuration from the controls data. For example, we can link vulnerability gaps of VMs and containers, say, Qualys, tenable or aqua with file integrity monitoring gaps discovered in systems using os-query or from source control git repos. These signals enrich security operations by combining in-line admission policies with out-of-band control data heuristics

In conclusion, to draw an analogy, If Security = OLTP, transaction processing, then Governance = OLAP, batch processing. While Security operates ad-hoc at network speed, Governance operates post-hoc to provide enriched results. However, this is only possible through context-sensitive automation and analytics for Security GRC.

In the future, we will dive deeper into each of our domains. In the meantime, please feel free to reach out with any questions.