Security automation for posture assessment has been difficult to achieve, even though many standards-based and proprietary solutions have been developed.
The primary problem is the complexity of solutions requiring customization by each enterprise. Additionally, some solutions work best in a homogeneous environment and are more complex when the environment is heterogeneous. This environmental overhead limits posture assessment to organizations with the resources to manage complex solutions, or those who outsource to managed security service providers.
The importance of posture assessment to trusted assurance
Posture assessment is the process of evaluating organizational or system security by examining the respective components. Posture assessment aids in an overall understanding of the security posture of a network. It is also an important input to comprehensive Governance, Risk, and Compliance (GRC) solutions.
By understanding an organization’s current security posture, business risk decisions can be more easily made. An organization can then establish and maintain security, privacy, safety, IT, compliance, and legal controls. This can be done even as changes emerge with new vulnerabilities, protocols, or other adaptations required.
How do we eliminate the requirement for customization at each location to close this gap? Secure products, out-of-the-box, that provide an automated posture assessment capability for system and application security at the time of deployment, centralizes the security policy establishment to a small group of experts. This eliminates the need for distributed expertise, lessening the burden by using an architectural pattern for security management that scales.
Attestation from a root of trust
Posture assessment requires periodic comparisons of current controls to expected values. Having posture assessment as part of products when deployed is possible, but it will take some time until the industry can provide these capabilities.
Attestations, described simply, are signed objects that contain evidence. Attestation from a root of trust holds promise as a scalable solution to assure system and application-level security. Attestation at boot and runtime assures that the individual hardware and software components are as expected (verified) and therefore are trusted.
Read: Where does zero trust begin and why is it important?
The attestation is provided as part of security solutions that build in controls to, not only assess hardware and firmware, but also to remediate on a granular component level. A root of trust may be hardware-based (such as TPM, AWS Nitro, or OpenTitan) or virtual, where attestations may be created or verified in a trusted execution environment (TEE) for instance.
Support for attestations to assess system policy or measurements is beginning to move up the stack (line 201).
We are starting to see progress with work using attestations. The evidence may be generated on boot or runtime from hardware or software, then compared to a set of established policies or measurements. The policies or measurements may be provided by the manufacturer or other authoritative entity such as a trusted integrator or managed service provider. The policies and measurements must also be protected to ensure verification is trusted.
Reference integrity measurements
The measurements and policies may be implemented as described in ‘Reference Integrity Measurements,’ used locally on the system for remediation or a management system via remote attestation. This topic will be covered in the next blog in this series.
For measurements at boot, components rely on dependent component measurements meeting expected values or remediation actions may be triggered. Measurements on firmware or software might include hashes of the binary, side-channel information, or other observable pieces of information. The policies may even be provided in levels depending on the expected business or application requirements. The administrator may select which pre-configured security level is desired for their application and business needs.
While the boot processes and runtime measurements may be the same — independent of the security policy — other settings that may be attested to could vary, such as the use of encryption, algorithms selected, key sizes, or password strength. Those responsible for managing systems may select from vendor-established policy levels, easing the need for customization, while allowing for the flexibility often required to make business risk-based decisions.
In a model where policies and measurements for automated verification are vendor-provided, this technology assures transparency in the logs and evidence created. Technical analysts at an organization can inspect the attestation verification results using log files, while at the same time enabling organizations that lack resources to have fully automated assessments to expected assurance levels. While on-site resources may not inspect the attestation results, auditors may inspect all or a sample of gathered and assessed attestations.
How transparency helps to build trusted assurance
Transparent verification of controls to meet trusted assurance levels aids in building trust in the provider of the software or hardware. Transparency of key performance indicators, telemetry, and controls, bolsters trust in infrastructure, applications, and data.
Read: Transforming information security to secure businesses.
Attestation can shift the responsibility of establishing posture assessment automation for data, application, and system assurance to the vendor, closing the gap in the number of information security professionals required.
Vendors should base their attestations on trusted controls, such as the CIS Benchmarks, CIS Controls, NIST Special Publications (such as NIST SP 800-193, NIST SP 800-53), or the Trusted Computing Group’s Reference Integrity Measurements. This reliance on controls and benchmarks established by a trusted set of experts, in a formal process, aids in customer adoption.
Kathleen Moriarty is Chief Technology Officer at Center for Internet Security and former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
This post was first published on the Center for Internet Security Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.