Every day we are barraged with commercials and news reports about cybersecurity. But what does this buzzword really mean in 2017? I asked my retired neighbor what he thought when he heard the word, “cybersecurity” and he immediately said, “the Russians.” This, of course is coming from his daily dose of national news, and probably what crosses many minds these days as the word is tossed around. My wife uses a slightly different term when her computer comes off the slightest bit slow. She loudly proclaims, “I’ve been cyber-hacked!” This, naturally, is not the case at all, but she likes the word.
In talking about cybersecurity, let’s first take a look back though history to what seems like the Stone Age, and see just how the term came about. The classic case study is to follow how it all played out in the Department of Defense (DoD). The Morris worm in 1988 was the first recognized cybersecurity effect in the early days of the Internet. The mandate from the DoD to discover and respond to those early cybersecurity issues led to an ever-evolving strategy that extends to all aspects of private business and commercial enterprises in this decade. What, however, is really good cybersecurity? How do we get there today?
The template that the DoD continued to push for and refine led to the Defense Information Assurance Certification and Accreditation Process in 2006. This was a formal and standard set of activities, general tasks, and management structure process for the certification and accreditation of their information systems. This process in turn maintained the information assurance posture throughout a system’s life cycle. Still evolving in their approach to cyber in 2014, the DoD began establishing and transitioning to what is called the Risk Management Framework (RMF) for information technology and cybersecurity policies. This framework leverages a number of other documents for execution, like the National Security Systems Instruction and the National Institute of Standards and Technology (NIST).
The implementation of the Risk Management Framework is a decided shift in cybersecurity policy. RMF enables NIST along with its multiple special publications to provide a “high-level taxonomy of cybersecurity outcomes and a methodology to assess and manage those outcomes.” Federal information systems use the RMF process, but I would emphasize this tool is applicable to the broader commercial market intent on protecting itself from cybersecurity threats.
To comply with RMF/NIST guidance, organizations are required to conduct an analysis with the objective of identifying the type of information the system will process or produce. The analysis results provide provisional impact values which address confidentiality, integrity, availability of the system, and the system’s risk impact level rated as low, medium, or high. The risk impact values will delineate the controls required. To better apply controls to a system design, organizations have the ability to transform the controls to requirements. This transformation enables cybersecurity requirements to be integrated into the system requirements early in the design process. The key word here is “early”—so that key components of cybersecurity are not an afterthought, creating endless redesign and accompanying problems.
The systems engineering process and that crucial component called “requirements development” can use the transformed NIST controls as security requirements and integrate those with the system requirements. The model-Based System Engineering (MBSE) process promotes integration by tracking multiple relationships in the design phase. It can be accomplished by implementing Vitech’s CORE or GENESYS model-based systems engineering development environment.
To reiterate, while the tradition has been to bolt on these cyber aspects near the end of the project, the ability to see, understand and integrate these requirements in the beginning leads a program to identify cybersecurity exposure early in the design phase, allowing maximum flexibility in assessment of alternatives. Additionally, designing for the RMF from program inception prevents significant and costly redesign. These requirements can further be refined to determine the type of requirement to be applied- technical, procedural or physical. The cybersecurity requirements in the form of individual “shall statements,” can be integrated and validated up front in the design process making them ready for any testing. Think of CORE and GENESYS as your prime tool to bridge the gap between the old bolt-on process and taking care of cybersecurity in the beginning where it belongs.
I will close with an example and I invite comments and questions:
| IA-2 | IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) |
| ASSESSMENT OBJECTIVE:
Determine if the information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). |
|
| POTENTIAL ASSESSMENT METHODS AND OBJECTS:
Examine: [SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; information system design documentation; information system configuration settings and associated documentation; information system audit records; list of information system accounts; other relevant documents or records]. Interview: [SELECT FROM: Organizational personnel with information system operations responsibilities; organizational personnel with information security responsibilities; system/network administrators; organizational personnel with account management responsibilities; system developers]. Test: [SELECT FROM: Organizational processes for uniquely identifying and authenticating users; automated mechanisms supporting and/or implementing identification and authentication capability]. |
|
| P1 | LOW IA-2 (1) MOD IA-2 (1) (2) (3) (8) HIGH IA-2 (1) (2) (3) (4) (8) (9) |
This is how IA-2 appears in the NIST 800-53 Assessing Security and Privacy Controls in Federal Information Systems and Organizations. It is laid out as follows:
Security controls are designated by families, Information Assurance is one of the eighteen families of the controls. You will find the Privacy Control name at the beginning of each control.
The ASSESSMENT OBJECTIVE section states the actual security control. It defines what needs to be done to enable the implementation of this control.
The POTENTIAL ASSESSMENT METHODS AND OBJECTS section contains a supplemental guidance section generally describing the security control but does not contain any requirements. It describes the control in more detail. In reviewing the controls the team should also determine the type of requirement the control will produce be they technical, procedural or physical.
Requirements derived from the Assessment Objective would look like this:
- The PROGRAM shall uniquely identify organizational users requiring access to the information system.
- The PROGRAM shall uniquely identify organizational processes acting on behalf of organizational users requiring access to the information system.
- The PROGRAM shall ensure the information system requires organizational uses to be uniquely identified.
- The PROGRAM shall ensure that the information system uniquely authenticate organizational processes acting on behalf of organizational users.
These requirements would be integrated into the system requirements and tracked as cybersecurity requirements. Using CORE and GENESYS provides insight early in the design process and allows the engineers to allocate these cybersecurity requirements into multiple functional and physical areas with one instantiation of the requirements.
