Shared Ecosystem Push From Evolving Standards

Author: KATHLEEN MORIARTY
September 2019

Information security is in a transformational period. We have the opportunity to embrace change that could result in an overall improved security posture for both large and small organization to improve the overall security posture of Internet connected systems.  New threat models and advanced attacker techniques point to the need for a shared ecosystem model with holistic automated control management.  Let’s dive into the standards evolution that is unfolding to counter these threats and providing opportunity for change and advancement. 

Transport Security

Over the last twenty years, standards have evolved to focus on improving transport encryption security, with a recent (since 2013) increased focus on options for strong transport encryption that is easily deployed.  Transport Layer Security version 1.3 (TLSv1.3) and related protocols like QUIC that leverage TLSv1.3 are provably secure (under reasonable assumptions)(https://eprint.iacr.org/2015/582.pdf), provide forward secrecy, and not only reduce the exposed meta data on the wire, but also prevent passive monitoring that was possible in earlier versions of TLS through the use of static keys.   The recent efforts to automate certificate management (Let’s Encrypt) via the Internet Engineering Task Force’s (IETF) Automated Certificate Management Environment (ACME) protocol has eased deployment and management of certificates and can be tied to an increase in deployed web (HTTPS) encryption from about 30% to over 80% (https://letsencrypt.org/stats/). 

Ultimately, the security gains of TLSv1.3 will improve the overall security posture; however, for organizations using primarily passive monitoring techniques to reduce threats on their networks or to perform troubleshooting, this trend towards stronger encryption that can’t be passively intercepted is disruptive. To realize gain in security posture, alternate controls must be established to detect and prevent threats. Additionally, threat actor techniques are evolving.  Threat actors are working hard to ensure that indicators of compromise used in one attack do not match the attack vectors or indicators in the next attack by recompiling code and altering techniques (https://www.forbes.com/sites/samcurry/2019/06/27/indicators-of-behavior-the-new-telemetry-to-find-advanced-cyber-attackers/#10668218193e).  While in the past interception techniques have been somewhat effective, secure coding practices to prevent exploitation and security control monitoring for system and network changes may be more effective at countering these new threats longer term.  Establishing a monitored baseline of controls that are actively monitored may be the best way to detect threats early in the kill chain[Lockheed reference].

Endpoint Security and Automated Control Assessments

As we know, attackers will find the easiest point of entry and then use both privilege escalation as well as lateral movement techniques to attain their desired goal in an attack.  Maneuvering also enables the adversary to change goals, while establishing persistence, to take advantage of previously unknown targets of opportunity. With secure on-the-wire encryption being ubiquitously deployed, endpoints (https://datatracker.ietf.org/meeting/105/materials/minutes-105-saag-00) — including applications, devices, and systems—are the easiest targets.  Standards have existed for some time to aid in the management and monitoring of security controls at endpoints, but with the exception of network based controls, they have not been universally deployed or easy to manage without the purchase of additional point products.

The Security Content Automation Protocols (SCAP) from NIST and the endpoint work from Trusted Network Connect (TNC) were good starting points in the previous ecosystem where add on security was accepted as the norm.  SCAPv2.0 (https://csrc.nist.gov/Projects/Security-Content-Automation-Protocol/SCAP-2-0) recognizes that deficit and is working to shift the model to embedded security at the endpoint, from the OS or application vendor that is measurable (automated control monitoring).  The automated control assessments are through universal controls accessed via standards based protocols to a shared repository.  Any evaluation system may access the repository control assessment results information for reporting and detecting changes in the network if authorized.

Automated control management is essential towards easing the costs of managing the security of an organization against a holistic security control framework.  Cost and ease of deployment are critical considerations to achieving a shared ecosystem model where small and large organizations can practically deploy secure systems that are cost effective to manage and monitor. Scale is essential in this new ecosystem model.  By setting security control policies with expected results, an organization is better able to detect unexpected changes and thus have early warnings of possible infiltrations or simply infractions to established policies and procedures.

The standards evolution is driving the need to view security control management as a shared ecosystem with responsibility shifting to points of control that scale better not only for management, but for organizations of all sizes.  Security control management tied to a security control framework (NIST 800-53, ISO27001, or top X controls such as those from CIS) are difficult to attain when resources are limited for information security.  Automation, originating from the supporting vendor, is necessary to overcome this hurdle.  Automation is best supported when it is built into the system, indicating that we should remove add on point products and in-line services in favor of built in security with the ability to easily monitor for changes.

In addition to work on security control automation, both at NIST in the SCAPv2 effort and the IETF’s Security Automation and Control Management (SACM) (https://datatracker.ietf.org/wg/sacm/about/) working group (which overlap for several standards), there is additional standards development efforts that may aid in achieving higher levels of security while offering opportunities to reduce resources necessary for security management, called attestation. 

Attestation Standards

In attestation, simply stated, a module would be chained using digital signatures from modules required for its support, along with claims about the security posture that may be tied to a hardware root of trust.  There is attestation work happening in several standards bodies, with an effort to coordinate work across these efforts.  The IETF’s Remote ATtestation procedureS (RATS) (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2) is defining formats for signatures with claims using a shared architectural vision from the Trusted Computing Group (TCG) (https://tools.ietf.org/html/draft-fedorkow-rats-network-device-attestation-00).  While this attestation work is further off, it could be very helpful in a move towards more secure systems in a shared ecosystem.  How so?

Attestations come from the creator of software who is responsible for vetting their software prior to signing it and providing claims about that software.  The software creators link their attestations to software in which their software or module rely and presumably have performed adequate testing, including for security vulnerabilities prior to providing the attestation.  This shifts the responsibility back to the software creator for the security of their product, which is a better fit for the evolving ecosystem that cannot rely upon point products in the middle to detect and thwart threats.  Shifting the responsibility back to the creator also reduces the demand on security professionals as the work to secure applications and software rests with the producer as opposed to every consumer being responsible in models that support the need for point products treated separately from the vulnerable systems and applications.

Security Control Automation and the Cloud

Microarchitectures or software modules in serverless architectures will also greatly benefit from automated security control management to detect any variances from policy that may indicate exploitation of a security vulnerability for early detection.  Chained attestations provide an assurance of trust that software has not been altered from a known state that will in the future fold into automated security control management baseline expectations.  These should be expected security controls in serverless architectures of the not too distant future.  Any changes detected in software or monitored security controls that signal a deviance from policies should trigger an alert.  The alert would ideally be communicated between various vendor independent products using an open standard such as OpenC2 (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2) providing notice of an alteration from expected security controls or other anomaly.  Automated communications on detected threats or variances from expected controls, can enable rapid investigation and thwart attacks early in the kill chain.

While secure transport encryption with strong authentication is changing architectures and supporting connections across networks (multi-cloud) and between modules or applications help achieve ‘zero trust models’, more is needed to support a shared ecosystem that is borderless.  The full supply chain needs to be considered and this means manageable security that scales for organizations of all sizes.  Chained attestations of secure software that provides assurance that software has not been altered should be one of many security controls monitored.  Detecting or preventing compromises early through automated security control management with responsibility placed with the providing vendor may be one of the best methods to improve the overall security posture at scale going forward.  Open standards are shaping a path forward, that if embraced, could result in an overall improved security posture requiring fewer resources to manage as a result in a shift of responsibility to inherently provide security.