Adding Continuous Security Validation to NIST 800-53
Language is proposed that would add continuous security validation (aka Breach and Attack Simulation) to NIST 800-53.

Adding Continuous Security Validation to NIST 800-53

Continuous security validation (CSV) provides assurance that security controls are operating as expected. Because existing security compliance frameworks do not reference CSV, organizations miss its unique advantages in their compliance work. To address this gap, CSV-related language is proposed here by Edward Amoroso of TAG Cyber and Chris Kennedy of AttackIQ to augment the NIST Special Publication 800-53 Rev 5.

Introduction

Cyber risk management frameworks have a significant influence on protection decisions in the enterprise. Such frameworks, such as the NIST 800-53, help organizations define how cyber security controls should be applied in practice. What they cannot do, however, is show organizations how to deploy and operate the actual systems that implement these controls. To do this properly, security teams must truly understand their business.

Unfortunately, many teams do not understand their business well enough to deploy controls with comprehensive coverage. In fact, this may be the toughest challenge in enterprise security today – namely, the connecting of security systems to the correct business functions to protect the right assets. Enterprise security is thus a complicated task, and requires the best available support mechanisms to optimize information risk management.

An additional consideration is that security is often presumed to be continuous. A firewall, for example, is expected to work post-deployment with no gaps. This is partially true for controls like scanning, but not true for periodic validation controls such as testing or simulation. These are typically not done continuously, which can reduce their effectiveness, especially given the rapidly changing operating dynamics of modern enterprise.

To address these challenges, most organizations have two teams: One focused on compliance and another focused on security. In the worst case, these teams work separately with little coordination. In the best case, the compliance provides a check on the operational security ecosystem. In all cases, the control checking should be continuous – but nearly all modern compliance programs include only periodic tasks, sometimes with annual gaps in coverage.

It is imperative that security teams close such gaps with mechanisms that complement control checking by compliance teams, and which can validate that security operations functions are working as expected. A new mechanism known as continuous security validation (CSV) provides precisely this support. Designed to address the weaknesses of point-in-time security, CSV is a new branch of cyber security with great promise.

CSV ensures that enterprise security organizations do not assume operating risk through relaxation of preventive security functions. Using on-going monitoring, teams can ensure that controls are being properly facilitated by security operations. The greatest advantage of CSV is that security teams will know quickly if the effectiveness of a given security control has failed, and this can help throughout all relevant lifecycles, including the SDLC.

In this note, we recommend adding CSV requirements to security frameworks, and NIST 800-53, in particular. Such improvement is intended to help bridge the control validation gap between security and compliance teams through more common review goals, and through improved assurance that security mechanisms are working properly. We include language consistent with the NIST approach so that cut-and-paste enhancement is possible.

Continuous Security Validation Overview

Implementation of CSV requires a platform that continually simulates, tests, and validates security functions in the enterprise. This is best done in the context of an adversarial threat model (the MITRE ATT&ACK Framework is representative). The enterprise benefits from such on-going assessment with respect to a known, relevant attack model. This results in an improved understanding of which security techniques are most relevant to the organization.

In contrast to CSV, point-in-time approaches include maturity assessments, independent audits, penetration tests, bug bounty programs, and functional testing. While these are important, they exhibit the core weakness that any instantaneous validation test would exhibit. That is, once any test has been completed, it validates a given property at that time and limited only to the scope of the test. Subsequent changes might easily invalidate the test.

CSV addresses this weakness by reducing the interval between simulations. If implemented well, attack emulations (on-premise, across virtual clouds, and over multi-clouds) can provide assurance about control correctness (or incorrectness). Once CSV has been integrated into the enterprise, its results can be combined with risk governance, operational change management, software lifecycles, and other enterprise business processes.

No alt text provided for this image

One obvious advantage of CSV is this reduction in time gaps between subsequent security validations. The comparison in Figure 1 shows the typical durations that exist between subsequent penetration tests, compliance reviews, vulnerability scans, and third-party assessments. Because CSV includes automated testing, adversarial emulation, and stressing of the applicable controls, it closes these gaps and provides a superior form of assurance.

An additional important advantage of CSV for the enterprise is its function in providing assurance that existing controls, including ones demanded by compliance frameworks, are operating as expected. Without this type of continuous assurance, it is likely that despite the effort to demonstrate compliance with NIST or similar frameworks, the required protections might be operating in a degraded manner. CSV addresses this potential weakness.

Adding CSV to Security Frameworks

Security frameworks offer an incentive for organizations to perform security properly. Unfortunately, the temporal requirements that address audits, sampling, and periodic tests fail to provide sufficient periodicity and efficacy. A lot can change in an enterprise between audits and tests, and CSV directly addresses this gap. It is therefore valuable to include continuous and improved efficacy constructs in compliance frameworks.

Because CSV is a new form of assurance, the most popular security frameworks do not include direct mention of this functionality. Certainly, the use of CSV will directly or indirectly touch on many applicable controls one is likely to find in a given framework. The Risk Assessment (RA) and System and Information Integrity (SII) families of NIST 800-53 include many requirements that are adjacent to the activities involved in CSV.

What is missing, however – and what would be particularly helpful to compliance managers, enterprise security professionals, regulators, and other stakeholders in enterprise information security – is compliance framework language that can be directly appended to the existing control language. In the section below, we provide just that: We write CSV requirements in the language and format of NIST 800-53.

Our presumption is that teams might use this compliance requirement to augment their existing framework. They might also use our language to future-proof their existing compliance program, since it seem inevitable that CSV will be added eventually to most frameworks. In addition, we hope this proposed addition is considered by the purveyors of popular security frameworks. We believe CSV language would be a valuable addition.

Regulators, in particular, should consider amending or augmenting their security risk management frameworks to include CSV. The goal should be a more continuous and comprehensive approach to control validation and reporting with outcomes tested in an on-going feedback loop. Recommendations can be included as to how and where such control validation is done, perhaps with higher assets being tested more frequently.

NIST Requirement for CSV

For NIST 800-53 (currently working toward revision 5), the proposal is that a new control CA-10 be defined called Continuous Simulation and Validation. This new entry can be included in the “Security Controls to Achieve Enhanced Assurance,” and complements existing framework controls. It also provides support for a new breach and simulation function that is not required currently in the criteria. Below is the proposed draft write-up:

CA 10  CONTINUOUS SIMULATION AND VALIDATION

Control: The organization assigns [Assignment: organization-defined personnel or roles] responsibility to deploy and manage a continuous simulation and validation tool that

a.    Provides on-going validation of effectiveness of the deployed security functions and controls in the organizational security architecture;

b.    Performs on-going automated simulation of attacks based on an [Assignment: organization-defined breach and attack framework];

c.     Minimizes frequency of continuous validation to [Assignment: organization-defined frequency of validation]. 

Supplemental Guidance: This control is based on an enterprise cyber security method known as breach and attack simulation (BAS) where automation is used to simulate, test, and validate the effectiveness of deployed control. Such automation is typically driven by a comprehensive breach framework that includes a meaningful taxonomy of attacks based on practical observation of cyber threats. The MITRE ATT&CK taxonomy is an example of such a framework.

Control Enhancements: None.

References: NIST Special Publications 800-12, 800-100

Priority and Baseline Allocation:

No alt text provided for this image

 

 

Roy Wang

Cybersecurity Leader

4 年

Thanks, for the great insight and mitigated the Gap. My problem is how do we continually perform the?automated simulation of attacks. Where I can get the latest feeds of the TTPs? Because of THE ?TTPs of MITRE ATT&ck all based on the observed and known attacks which probably are now not latest TTPs?

Jorge Ivan Marmolejo Cardona

Information Risk Advisor | 27001 Consultant | CCSK Contributor | CertiProf ISO 27001:2022 Lead Auditor | CS-900 Security, Compliance, and Identity Fundamentals | ISACA CSX-Cybersecurity Practitioner

4 年

First Thks.? The cibersecurity is a continual process

Automation of security test against controls is a missing gap in the security industry. We are proposing an open source initiative mirroring Snort, YARA or Sigma: SUSTO (Systematic Universal Security Testing Orchestration)?https://globalappsecamsterdam2019.sched.com/event/UBOv/susto-systematic-universal-security-testing-orchestration More focused on build-time (pre-flight tests) but open to be used in (production) run-time (on-flight tests). The idea is to develop both an orchestration tool and related syntax and an open community set of rules (like Snort, YARA or Sigma). Agnostic of the above tools (GRC, Thread Modelling,...) and the underlying testing SW ranging from existing commercial SAST to small scripts to check configurations Thoughts?

Edward Amoroso, thank you for the wonderful article.? I have written in the past about this hole (continuous vs point in time) and my take was slightly different.? You focused on attack vectors (via MITRE ATT&CK framework).? My problem with that approach is two-fold.? 1) It is limited to the human-biased identification and tracking within the ATT&CK framework as the only possible approaches in your CSV and 2) it's focus is on what you think is an attack versus what should be the protection.? This is most important.? Our concept at Eigenspace was that you should understand each security control.? Each security control has attributes you should understand.? Each security control has related security controls.? From these two views (attributes and related SC) you can create a mosaic.? Take a look at a spider web, let's suppose each control is a spider web.? Each control that is related has spider web 1 connected to spider web 2, etc. etc. etc.? Now, if a spiderweb WAY over there vibrates, that means something happened to violate that control.? I now know that the attack is coming and how it is coming and how they are trying to ingress.? That control should tell me the related controls and now I know where my instant monitoring from a SOC perspective should focus.? So, in reality, CSV should be about monitoring the control implementation and how they relate to my security posture, not the attack method.? It seems similar but is really the opposite side of the coin in my opinion.? Would love your thoughts on this.? Regarding SP 800-53rev5, it has been hung up for ages.? I know that rev5 changes everything in USG and there are literally 100s of security control changes.? Hopefully, they have heard this CSV argument and are including it in the final release.? We'll see. Thanks again!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了