Standard Categories for Your Cyber Policy Artifact

(I have been getting a lot of requests for help in this area…I plan to get more updates out soonest) -Mark

The basis of the concept of the NIST 800 term of “adequate security” is delineated to the following three major documents:

• A System Security Plan (SSP)
• A Plan of Action and Milestones
• An agency/company Cybersecurity Policy

These requirements are demonstrated by alignment with NIST security controls based upon the framework selected. These include:

• NIST 800-54 rev. 4 (soon to be revision 5)–“Security and Privacy Controls for Federal Information Systems and Organizations”
• NIST 800-171, revision 1, “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations”
• The Cybersecurity Framework (CSF), version 1.1

Control implementation is shown through documentation.  Another term that is used is an artifact.  An artifact is any representation to a Contract Office, independent third-party assessor, etc., that shows compliance with specific security controls.  It is a major part of the proof that a system owner (company, agency, etc.) would provide to the government or higher headquarters.

The common term for the collection of all applications and supporting artifacts is the Body of Evidence (BOE).  The major items required for the BOE includes the Company Policy or Procedure. For our purposes, these terms are used interchangeably for simplicity, and do have more specific meanings not necessary for this discussion.  A Cybersecurity Policy document provides cybersecurity measures affecting the people, processes (most specifically), and technologies ensuring the protection and misuse of data.

A policy is any direction provided to internal employees, subcontractors, third-party providers, managed service providers, etc., that are enforceable under US labor laws and Human Resource (HR) direction, OR by contract.

It is HIGHLY recommended that such a policy or procedure artifact be a singular collection of how the organization addresses each of the security controls.

The 8 Elements

1. TITLE
2. REFERENCES
3. PURPOSE
4. SCOPE
5. RESPONSIBILITIES
6. CHANGE SUMMARY
7. PREVIOUS POLICY/POLICIES CANCELLATION
8. PROCEDURES

TITLE: Have a title that describes the area that requires a control-oriented policy/procedure. These may include incident response, patch management, supply chain risk management, etc. EXAMPLE: “Network Operations and Maintenance Procedures.”

REFERENCES: What are the applicable laws (MOST IMPORTANT), regulations, policies, and directives that already exist to address a control. A common reference would require “Two-Factor Authentication” or “Data at Rest” policies. Also, if there is a higher headquarters directive you can use that policy as a start point, but remember, you will need to better refine the procedures when you get to ITEM 8 (Procedures) of the policy document.

PURPOSE: The purpose should always be about protecting the data, privacy, and intellectual property as appropriate. This should be a short paragraph focusing on the title. EXAMPLE: “To ensure the Confidentiality, Integrity, and Availability of Network data from unauthorized access, disclosure, or destruction….”

SCOPE: Consider the Authority to Operate (ATO) security boundary as a guide. Scope should confine the policy to only what is necessary–not over-scoped, and not ignore controls critical to the protection of data and privacy–under-scoped. “Define your left and right boundaries” in your policy document based upon your local and external boundaries–don’t forget if using cloud capabilities or services, they too must be part of an effective policy.

RESPONSIBILITIES: Identifies all the key personnel involved in the cybersecurity protection efforts. This should begin with higher headquarters/commands, members of the IT staff to include the CIO, CISO, IT Program managers, etc. Other key personnel, as described under NIST should always include:

• Authorizing Official (AO)-Senior leadership representative responsible for accepting any RISK, residual or other.
• System Owner (SO)-This person should have direct resource authority for the care and maintenance of the system

BEST PRACTICE

Names should never be used in any policy artifact; titles/positions only

CHANGE SUMMARY: High-level descriptions of changes from previous policy documents should be added as necessary. EXAMPLE: “This XXX policy update requires both Data in Transit (DIT) AND Data at Rest (DAR) encryption requirements mandating a minimum of AES-256 encryption use by all departments.”

CANCELLATION OF PREVIOUS: This is only required if a new policy with new naming convention, serialization, etc., has changed from the original policy. EXAMPLE: “Cyber-policy ABC-0001 is cancelled and replaced with no substantive changes to the document and is heretofore designated as XYZQ-002.”

PROCEDURES: This describes the “how” an aspect of cybersecurity will be implemented by the company/agency. (This is a more in-depth topic for future discussion. I offer the following example as just a start point…)

The above is a typical approach to creating procedures using a decision-tree. In this example, a CHANGE REQUEST is submitted for the IT environment. A determination needs to always be made (under NIST guidance) that a Risk Assessment is conducted. If the change in minor, for example, updating a security patch, then a full ATO effort is not required. If you add a new component, such as a new firewall, Intrusion Device, etc., a determination needs to be made whether it introduces no, marginal, or substantial risk to the security posture of the overall system.

The PROCEDURE section is the most detailed and difficult. Always try to leverage higher headquarters direction/guidance and identify “best practices” that are meaningful to the policy. MORE TO FOLLOW 🙂

Dr. Mark Russo

Dr. Russo is currently the Senior Data Scientist with Cybersenetinel AI in Washington, DC. He is a former Senior Information Security Engineer within the Department of Defense’s (DOD) F-35 Joint Strike Fighter program. He has an extensive background in cybersecurity and is an expert in the Risk Management Framework (RMF) and DOD Instruction 8510, which implement RMF throughout the DOD and the federal government.  He holds a Certified Information Systems Security Professional (CISSP) certification and a CISSP in information security architecture (ISSAP).  He has a 2017 Chief Information Security Officer (CISO) certification from the National Defense University, Washington, DC. Dr. Russo retired from the US Army Reserves in 2012 as a Senior Intelligence Officer.