Security Assessments within DevSecOps

Modern DevSecOps enables rapid and frequent changes to the codebase and documentation using modern tools. Security tooling cannot rely upon manual office product-based processes and must adopt these same modern tools to utilize documents and Infrastructure as Code.

Introduction

Finding the location of an answer and determining context is often more time-consuming than reading it once found. The validation of a system's policy and procedures by a third-party validator needs the data and the context or reasoning for the expected results. Tagging content with the CCI occurs in many places (PDFs, .docx, etc.) today to provide search targets or, in some extremes, the full CCI as a stated "requirement." These are useful but time-consuming and problematic. Any changes to the document require reviews of an external CCI to ensure the changes do not alter compliance, and the latter case results in "compliance" documents too cluttered by CCI and security content to be used as instructions for the operators of the system.

Motivation

The processes are tedious to review, like finding a particular needle in haystacks of documents spread throughout a system lifecycle. Additionally, the validation and test results must be passed from the validator to others in the approval chain while ensuring context is maintained. The validators also need to perform evaluations for each security control. Comprehensive test results will reduce the likelihood of conflicts in interpretation by the applicable SCA or AO and limit the likelihood of incurring costly rework.

Solution

Documents as Code (DaC) moves the policy, processes, and procedures into the version-controlled codebase of the system, or our haystacks. It also allows programmatic creation, review, and search functions through proper formatting and rules. The DaC must focus on providing clear guidance to the developers, operators, and users of the system while tracking against the security requirements for that system.

This isn't a new problem. Software development has facilitated providing multiple developers context for the code since it's inception through the use of comments. In some languages the comments within the software are used to automatically create documentation for the software.

We'll do the same by adding Control Correlation Identifiers within Documents and Infrastructure as Code for security compliance by adopting formatting rules to facilitate automatic use of those comments.

Git storage

The capabilities of git version control and workflows can bring order to the chaos within the sprawl of documents for programs. The processes for versioning, comments, reviews, ticketing, and actions can resolve the overhead of document handling, storage, and creation in the same location as the programs code is a given. Properly configured, git would require reviews by designated people and acceptance before merging changes. Tool and process changes will require training, but the risk is marginal as the outcome is already proven in the commercial space.
The git documents are normally extended with other capabilities to publish documents to web pages and, if necessary, artifacts when other systems require a copy be submitted (eMASS).

CCI Formatting

Documents as Code should focus on the intent of the document (e.g., account management, backups, configuration management, etc.) in a way that provides clear and concise instructions or operational guidance to the reader. Within that guidance, properly formatted code comments will identify the CCI definition and the test result for the CCI. Comprehensive test results will reduce the likelihood of conflicts in interpretation by the applicable SCA or AO and limit the likelihood of incurring costly rework.

Rules

• CCI Definitions shall be annotated as comments with the format of
  • CCI-000000: Definition
• CCI Test Results shall be annotated as comments with the format of
  • TR-CCI-000000: Test result

Placing the CCI and test result near the code or statements allows editors of the code or statements to be aware of the requirements and adjust the test results. Given the markdown example below, if a change is made to allow "emergency accounts", then the need to have the replacement text meet the CCIs to remove or disable emergency accounts after a time period is known and a response can be created.

Examples

Markdown

- Group\Shared Accounts:  Accounts with shared passwords for user login are not authorized.
<!-- CCI-002140: Defines the conditions for establishing shared/group accounts. --> 
<!-- TR-CCI-002140: Program Policy states Group\Shared Accounts:  Accounts with shared passwords for user login are not authorized. --> 
<!-- CCI-002141: Defines the requirements of creating a shared/group account. -->
<!-- TR-CCI-002141: Program Policy states Group\Shared Accounts:  Accounts with shared passwords for user login are not authorized. --> 
<!-- CCI-002129: A process for reissuing shared/group account credentials when individuals are removed from the group is not required -->
<!-- TR-CCI-002129: Program Policy states Group\Shared Accounts:  Accounts with shared passwords for user login are not authorized. --> 
<!-- CCI-002142: technical:The information system terminates shared/group account credentials when members leave the group. 800-53r4:AC-2 (10) -->
<!-- TR-CCI-002142: Program Policy states Group\Shared Accounts:  Accounts with shared passwords for user login are not authorized.--> 

- Temporary Accounts: Temporary accounts are not authorized.
<!-- CCI-000016: The information system automatically removes or disables temporary accounts after an organization-defined time period for each type of account -->
<!-- TR-CCI-000016: Program Policy states Temporary accounts are not authorized. --> 
<!-- CCI-001361: policy:Defines a time period after which temporary accounts are automatically terminated. 800-53r4:AC-2 (2) -->
<!-- TR-CCI-001361: Program Policy states Temporary accounts are not authorized. --> 
- Emergency Accounts: Emergency accounts are not authorized.
<!-- CCI-001682: technical:Automatically removes or disables emergency accounts after an organization-defined time period for each type of account. 800-53r4:AC-2 (2) -->
<!-- TR-CCI-001682: Program Policy states Emergency accounts are not authorized.--> 
<!-- policy:Defines a time period after which emergency accounts are automatically terminated. 800-53r4:AC-2 (2), DoD has defined the time period as never. -->
<!-- CCI-001365: TR-CCI-001365: Program Policy states Emergency accounts are not authorized.--> 

Terraform

The tags within terraform use a brief description of the CCI and are located near the implementation of the CCI. The CCI formatted as CCI-000000 and test results as TR-CCI-000000.

# CCI-000018: The information system automatically audits account creation actions
# TR-CCI-000018: The program configures AWS with terraform to monitor account creation actions.
resource "aws_cloudwatch_query_definition" "event_4754" {
  name = "Security/Windows/account_groups_change/Group create (universal)"
  log_group_names = [
    "/dev/windows/eventlog/security",
    "/test/windows/eventlog/security",
    "/prod/windows/eventlog/security",
  ]
  query_string = <<EOF
filter @message like "<EventID>4754</EventID>"|sort @timestamp desc 
EOF
}
# CCI-001403: The information system automatically audits account modification actions.
# TR-CCI-001403: The program configures AWS with terraform to monitor account modification actions.
resource "aws_cloudwatch_query_definition" "event_4756" {
  name = "Security/Windows/account_groups_change/User added to universal group"
  log_group_names = [
    "/dev/windows/eventlog/security",
    "/test/windows/eventlog/security",
    "/prod/windows/eventlog/security",
  ]
  query_string = <<EOF
filter @message like "<EventID>4756</EventID>"|sort @timestamp desc 
EOF
}

Parsing

Embedding the CCI and the test result comments within markdown and code allows their retrieval and aggregation when they meet the formatting criteria. The search process would begin by cloning the relevant git repositories for code defining the system and its Documents as Code (DaC) and then parsing the content using a search pattern. The search patterns would include the CCI and code formatting to produce data of the CCI, test result, URL to the file location, and source paragraph checksum. This data file would reside within git and be version controlled.

Results

Once a baseline of the parsed data is established several review and configuration management functions can be converted or enhanced.

Detection of Security Assessment Procedure Impacts

The lifecycle of a system will include numerous changes to documents, process, and diagrams as it adjusts and updates. This is a natural process of system health. One of the complexities of change within a system is detecting the consequences of the change. A configuration management process includes reviews of changes for the security impact that can require knowledge of the impacts and connections.

It would be possible to tie the pull requests of file changes to the hashes in the Assessment Results (above) and then add a step to review the results to determine which Assessment Procedures are impacted. This produces a revalidation of the procedure(s) for that change before the pull request is approved. Precise locations would allow the security team to review the changes to the code and ensure the test result is properly updated. Connected to a ticketing system, the URLs would allow rapidly moving to the location of the change within growing code bases.

eMASS Assessment Procedures (APs) linked to the evidence of their implementation

Without context, the typical assessment process begins with generic assessment procedures provided as prompts to an assessor that might need to research the implementation. As systems embrace Documents as Code and CCI tagging, they'll have the ability to quickly tie the AP to the locations the APs are implemented. In the table above, CCI-001403 would link to the Terraform file that contains the implementations. An assessment procedure test response could include the Test Result, URL, and Checksum for each assessment procedure.

Assessment Result Evidence Hashes

The system specific test results contain a link to and the hash of the evidence. Using that hash identifies changes since the test result was input. This is useful during initial and recurring inspections for clear comparison of the specific document section (hashes of document subsections) that will reduce errors and identify the changes.

Feeding the Beast

The implementation of Documents and Infrastructure as Code facilitates clear web-based documentation for the users and operators of the system. eMASS is inaccessible to the vast majority of system users and operators but requires "hard PDF" or evidence to be provided instead of links to the documentation routinely updated in the DevSecOps process.

To meet this requirement, the Documentation as Code of the policies and procedures would be converted to PDFs and uploaded to eMASS. If the requirement persists, automation can be implemented to generate the PDFs as a component of the configuration management approval processes and uploaded to eMASS along with the updates to the assessment procedure test results.

Conclusion

Adopting Control Correlation Identifiers within Documents and Infrastructure as Code has an initial cost to migrate to those documents but the long-term benefit of allowing them to be treated and managed as data instead of documents. The next blog will address the reuse of Documents as Code content and templates containing the CCI requirement and blank TR-CCI prompts to guide the engineering as a system is developed.