CONSIDER: Introducing “SPITS” as an Agile Cyber-Solution Framework

We consider the following mini-framework

This is a discussion on an emerging cybersecurity tactical approach to inject an even lower level Risk Assessment (RA) process into existing NIST-based frameworks.  It has not yet been formally adopted.  The intent for this concept is to begin a discussion.  The desire is to further create more agile tools, methodologies and solutions that afford IT developers greater and more secure systems.

The SPecialized Information Technology System (SPITS) is designed to afford additional agile-like solutions for singular purposed IT systems.  These would include “plug-and-play” systems running on some form of computer architecture with some form of Operating System (OS) or even firmware.  This could also include Systems on a Chip (SOC) such as Field Programmable Gate Arrays (FPGA) and Application Specific Integrated Circuits (ASIC).  Examples would include test systems to determine calibration levels of other devices and sensors on a Major IT System (MITS)[1], administrative consoles to collect audit logs for analysis and forensic activities, add-on modules such Global Positioning Systems (GPS) to provide location information to a major IT system.

Such systems may be further integrated with the major IT system or connect on an intermittent basis—the longer-term connections would require future updates to the major systems overall architecture and require updates to the System Security Plan (SSP) at a minimum.

Examples may include:

• “Plug and play” or applique IT solutions intended to increase the functionality of the overall system
• Test devices and tools
• Administrative and maintenance computers (consoles)

SPITS would also include operating software, applications, etc., and their associated hardware to include embedded computer systems which enable that system to perform their interactive tasks with MITS [2].   It may also be a special-purpose components, to include systems and their associated hardware, software and firmware; this could include, for example, onboard video collection devices or other single-purpose IT system which provides specialized processing activities within the MITS’s security boundary; it is not necessary to provide security controls to a device/module provided from a “trusted” source with requisite certification(s) affirming it has been processed through an approved security process, e.g., National Information Assurance Partnership (NIAP). See its website to review current systems at https://www.niap-ccevs.org/ .

            For the purposes of SPITS use, we have further leveraged the NIST 800-53 revision 4, “Security and Privacy Controls for Federal Information Systems and Organization”[3] cybersecurity directive for federal organizations.  We have done this because it provides a much finer listing of technical controls required to make these single function systems “cyber-secure.”  We have chosen controls at the software coding review and assessment levels and above as defined within NIST 800-53. 

The proposed controls are currently restricted to 9 controls.  This defined number of controls further support an agile-like mechanism to assist in secure system development.  These controls are under consideration by many cybersecurity professionals within the Cybersecurity Community, but there has been no formal adoption as a matter of standard.

The listing below provides the beginnings of a mini-framework, ideal for IT sub-system cybersecurity protections:

1. RA-3: Risk Assessment
2. RA-5: Vulnerability Scanning
3. CM-6: Document Configuration Settings
4. SA-11: Security Testing and Evaluation
5. SA-12 Supply Chain Protection
6. SI-2: Flaw Remediation
7. SI-11 Error Handling
8. SI-16 Memory Protection
9. SC-8 Transmission Confidentiality and Integrity

SPITS Categorization

            SPITS has three (3) major categories of sub-system and is based upon the physical location and permanence (temporal relationship) to a MITS.  They are:

1. CATEGORY 1: INTEGRATED/EMBEDDED SUB-SYSTEM
   • Description: This is an IT-based subsystem providing additional functionality or capabilities to the MITS. It becomes part of the designated security boundary once approved by the System Owner/Authorizing Official. There is no intent to remove except under extreme circumstances or upon identification of a major security vulnerability that cannot be addressed.
   • Permanence: Permanent
   • Examples: Video collection/capture device; GPS; anti-tamper monitoring device; additional firewalls; “black box” archival device.
     
     
2. CATEGORY 2: APPLIQUE SUB-SYSTEM
   • Description: This is an IT device physically connecting to external ports of the MITS.  It becomes part of the security boundary once approved by the SO/AO.
   • Permanence: May be permanent or non-permanent based upon mission needs and requirements.
   • Examples: “Strap-on” guidance system to a “dumb bomb;” digital radio; externally mounted camera.

• CATEGORY 3: INTERMITTENT (TEMPORARY) SUB-SYSTEM
  • Description: This is an IT device that only touches the security boundary for a limited period. It is not intended to be a permanent connection to the MITS.
  • Permanence: Non-permanent.
  • Examples: maintenance or audit (forensic) collection computer; calibration device; test device to ascertain functionality, accuracy, reliability, etc.

Let us keep the discussion going….

Footnotes

[1] A MITS is defined as the main system providing security controls inherited by other “tethered” IT systems to include SPITS that are typically of a singular functional purpose, e.g., full-motion camera, GPS, etc.

[2] It is expected numerous controls will be inherited from the MITS allowing for agile integration and adequate security control implementation.

[3] A DRAFT NIST 800-53 revision 5 was released in August 2017; its authorized implementation for the federal government has yet to be announced.

The Agile/Security Development Lifecycle (A/SDLC)

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.