Policy Analytics for Cybersecurity of Cyber-Physical Systems: July 2021 (Y4, Q1)

Funding Type: Full proposal
Start Date: March 01, 2018
Expected Completion Date: April 30, 2020
Principal Investigator: Nazli Choucri
Public View

Accomplishments

Accomplishments during this reporting period: April 2021 - July 2021 (Year 4: Quarter 1) are summarized in this report.

Table of Contents

1. Project Objectives

1.1 Critical Principles

1.2 Research Design -- Reminder

2. NIST as "Laboratory"

2.1 Test-Bed

2.2 "Raw Data" -- Review

3. Practical Uses

3.1 Data Linkages

3.2 Metrics & Measures

3.3 Models & Network Analysis

4. Operational Disruption

4.1 "Re-Do" & Results

4.2 On "Reversing the Arrows"

5. Transcending Constraints -- Year 4, Quarter 1

5.1 "Two Parts" of Policy Analytics

6. Outreach

Tables & Figures

Table 1. Project Overview -- Reminder

Figure 1. Overall Project Design -- Simplified View

Figure 2. Smart Grid Cybersecurity Policy Directives

Figure 3. Method for Data Linkages

1. Project Objectives

The hard problem addressed in this Project is policy governed secure collaboration. This Quarterly Report for Year 4, Quarter 1 can best be understood in the context of the overall project objectives - problems and purpose. Table 1 shows, again, an overview of the project. It is the context for the overall project design.

Previous quarterly reports focused specifically on accomplishments for the reporting period. In addition to that, this Report addresses issues that had not been noted earlier. Among these are:

(1) Our principles as responsible researchers and implications for the Project;

(2) Some examples of practical uses of our investigations; and

(3) Data-related operational disruption that required major "re-do" efforts.

As expected, we also report on accomplishments during this reporting period.

1.1 Critical Principles

To date we have not reported on the basic principles we have adopted in the conduct of each phase of research throughout the Project. Here, we identify, for the first time, the three basic principles that create confidence in both process and product. These also serve as an "insurance policy" to ensure effective use of time, resources, and skills.

One: to pre-test the method employed at every step, in order to identify problems, unanticipated barriers, miscalculations, or errors in the research design - and resolve these in advance.

Two: to post-test each step after completion, as relevant, by reversing the process (We return to this issue later in this Quarterly Report).

Three: to demonstrate portability, by applying the core methods to issues, challenges, or cases beyond or outside the focus, framework, or purpose of this Project to determine stand-alone robustness.

These are principles of choice - for purposes of assuring quality of research. They are not set into our formal obligations.

1.2 Research Design -- Reminder

The research design is:

1. Modular in structure, and
2. Anchored in a model of properties for complex cyber-physical systems.

In earlier Quarterly Reports we reported on the details to this point. The design and analyses are designed to be generic. This means that they are relevant to, and provide insights for, cybersecurity of diverse complex cyber-physical systems. The analytics developed are not idiosyncratic to the test-bed we have employed.

Figure 1 presents a simplified view of the research design, and assists in situating this Quarterly Report.

Every phase of the design is based on the research and results of previous phases. But it is not linear in the sense that there is embedded feedback in structure and process. We replicate all tasks that involve direct human intervention.

This modular and cumulative approach assumes a degree of sustained validity in the database, both "raw" and "derived." If this assumption does not hold, or if there is any disruption in the validity of previous phases, then a "re-do" is required - as relevant.

2. NIST as "Laboratory"

Our first-order applications of method-development and testing concentrate on one complex pervasive cyber-physical system, namely, the smart grid for electric power systems. However, the problems addressed are generic in form, and the methods we have developed have wide-ranging applications.

2.1 Test-Bed

The focus is on analytics of cybersecurity for smart grid as a test-bed for this Project. It draws entirely on the "raw" reference model developed by NIST and on related NIST directives and documents. This test-bed is selected because of:

(a) smart grid salience throughout the industry and society,

(b) its complexity as a cyber-physical system, and the opportunity to build on the extensive work done by NIST,

(c) its excellence as a domain of research on analytics for cybersecurity policy of cyber-physical systems, and

(d) its importance to "NIST as a Laboratory."

As highlighted in the previous Quarterly Report, the policy complex is the Cyber Security Framework (CSF), including its directives and uses. CSF is mandatory in the public sector and greatly encouraged for the private sector. CSF directives provide tools to enable policy implementation.

However, the mission-specific or industry-specific application is left to the user - with only general guidance provided by CSF directives.

NIST as "Laboratory" enables us to:

(a) develop analytics for cybersecurity policies and guidelines,

(b) assist in understanding the full implications of the guidelines, and

(c) provide methods to facilitate use of CSF in diverse contexts and applications.

In addition to Project analytics, there is a practical use for making it easier to use CSF.

2.1 "Raw Data" - Review

Figure 2 notes again the policy document ecology of "raw data" for the test-bed. Here we ask the reader to pay attention to the details of document content. CSF policy directives and guidelines are put forth in different documents. Note the status of the individual document, the function it serves, and the brief summary of content.

Most important in Figure 2 is that each document is autonomous on a standalone basis. However, depending on the particular needs of the user - in terms of mission, industry, or other - relying on other documents is a necessity, not a choice.

This means that effective use of CSF requires that users:

1. Extract knowledge and guidelines embedded in diverse policy documents;
2. Explore the full implications of policy directives for cybersecurity of cyber-physical systems;
3. Identify the CSF directives relevant to their "case," and locate the operational documents to guide implementation.

In short, the above i - iii are necessary in order to capture and enhance the benefits of CSF.

Finally, a specific number precedes the name of each autonomous directive in Figure 2. This serves as an identifier of data used in different phases of the Project.

3. Practical Uses

Here we signal four practical uses of research and results so far.

3.1 Data Linkages

One: The full value of CSF is difficult to capture given the set of intervening tasks required and the distributed nature of the database. CSF points to what has to be done and why, but not how. It is up to the user to work through the process outlined by CSF. Pointers to steer users to other (different) documents are provided in order for users to take next steps.

In this case, the practical use is created by providing a method to streamline access to, and use of, essential data required to implement the security-related actions required by CSF. Because CSF points to a number of individual documents hosting different directives, the users' task is to identify and make connections among them as needed.

Moreover, modifications and updates by NIST on the content of key intervening documents require users, in turn, to identify the updates and determine requirements for change.

3.2 Metrics & Measures

Two: Given that policy documents and directives are conveyed in text form - in linear and sequential order - it is common practice to retain information in that form. We developed a method to transform text into metrics to deal with numerals, not letters (See example in Figure 6).

The practical use is compelling: metrics and measures enable more precision, with more flexibility in scale and scope of analysis, than can ever be done with the text form. This in itself takes away much of the built-in ambiguity of policy documents. Since the method is portable, it can be applied to all forms of policy texts - irrespective of issue area or domain.

3.3 Models & Network Analysis

Three: In a previous report we presented the base network model of the reference system for the NIST Smart Grid as a cyber-physical system. This model is derived from the metrics and measures embedded in the Design Structure Matrix representation of the descriptive text for the NIST Conceptual of Reference Model of the smart grid (See Figure 7 as an example). Diverse modelling approaches would also work.

4. Operational Disruption

Operational disruption refers to unexpected and exogenous changes in data-at-the-source that requires us to "re-do" research steps previously completed. We have encountered a major structural and operational challenge, noted in the previous Quarterly Report. By necessity, an accommodation and adjustment was required.

When NIST issued a fifth revision (Rev. 5) of its document 800:53, it resulted in a major disruption of "sustained validity" for our use of this document. Its importance lies in the fact that it provided the formal connections, or interfaces, between multiple sources of "raw" data for this project. It also coupled very closely the controls and control families to security and privacy. Rev. 5 also raised serious questions about the implications of this new version of 800:53, in terms of current NIST perspectives and priorities pertaining to security.

4.1 "Re-Do" & Results

As stated in the previous Quarterly Report, the fourth Quarter of Year 3 was devoted to the "re-do" (such that we remain on schedule to this point, as well as to delineating and understanding the implications of the "entanglements" of security and privacy controls for the policy implementation of the Cyber Security Framework, or for any issues for which the use of 800:53 Rev. 5 is called upon or required.

Rev. 5 affected all earlier work in this Project with respect to:

• Data Linkage Process
• Information pertaining to security controls and control families

In addition, Rev. 5 demonstrates:

• An unexpected entanglement between the Security and Privacy controls, and control families, thereby creating new ambiguities

And creates:

• Data-based signals that, for security and privacy purposes, everything is related to everything else

We noted earlier that the "re-do" created some delays in the completion of several research items that were additions to the original proposal and workplan. These additions were identified in terms of:

(a) providing added validation to the process,

(b) expanding the domain uses of our research, and

(c) creating value-added for the use of the Cyber Security Framework (CSF).

4.2 On "Reversing the Arrows"

As noted, the "re-do" addressed serious impediments to the "reversing the arrows" principle and to the validation strategy for our research design and results throughout Year 3, Q1-Q3. In practice, this meant "reversing the arrow" in Figure 3.

The most notable impediments pertain to the completion of item (a) above. This means to go from the user final-requirement "back" up the chain of sequence to the "system as is." This requires use of 800:53 Rev. 5 adapted to the sequence for analysis of the "reversal" in Figure 3, that is, from item 6 back to item 1.

5. Transcending Constraints - Year 4, Quarter 1

Table 1 and Figure 1 present the project overview and the research design. These remain the basic context for the entire research agenda. At the same time, however, the modularity noted earlier obscures an important aspect of the design that requires clarification at this point.

5.1 "Two Parts" of Policy Analytics

It should be evident by now that one part of the research design focuses on analytics for the cyber-physical system itself. The other part is on analytics for cybersecurity policies and directives.

Years 1 and 2 addressed and completed the first part, that is, focusing on the system "as is." Years 3 and parts of Year 4 are expected to focus on the second part, linking CSF directives to system state for implementation.

Both "parts" share a common process that must be applied to each side separately because the data are separate. Presented earlier in some detail, here we simplify the process in terms of:

• Text to Data
• Data to Metrics
• Metrics to Model

Part I is completed with the smart grid network model. This generates and identifies the nodes and the logical interfaces. Earlier we focused on task testing for Part II and identified empirically the logical interfaces for the system "as is" that connect to CSF directives.

The validated "re-do" shows an unexpected result, noted earlier in this Report, namely that privacy and security controls are heavily dependent on each other, thus creating "noise" in a focused analysis of security controls.

6. Outreach

As a part of our outreach, the team focused on the matter of practical use of the methods developed in this Project, especially with respect to:

• Complexity of Temporality
• AI-based adversarial interactions
• Who Gets What, When, Where, and How?

These are the three "hard problems" noted in the previous Quarterly Report.