Cybersecurity Executive Order – 5-12-21

Today President Biden published an Executive Order on Improving the Nation’s Cybersecurity on the White House web site. The time clock on the deadlines set forth in the EO will start when the official copy of the EO (probably as EO #14027 [actually EO #14028]) is published in the Federal Register, probably later this week. According to a White House Fact Sheet, the purpose of this long awaited EO is to “improve the nation’s cybersecurity and protect federal government networks.”

Federal Cybersecurity Leadership

The EO is targeted at protecting federal networks, it does not set any cybersecurity requirements for critical infrastructure to implement. Rather, Biden expects that, since the federal government is a major consumer of network devices and services, the requirements set forth will trickle down to the private sector as minimum best practices and thus raise the level of cybersecurity across the country.

Setting Standards

The order does not directly establish any standards. Instead, it directs various federal agencies (including, CISA, NIST, and OMB) a large number of standards that will be incorporated in federal acquisition and DOD acquisition regulations. There is, however, a rather high-level of technical requirements in the EO that the President expects to see implemented. This can be seen in the definition of ‘Software Bill of Materials’ found in §10(j):

“(j) the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software.  Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product.  It is analogous to a list of ingredients on food packaging.  An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software.  Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities.  Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product.  Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.   A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration.  The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems.  Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.”

Goals for the EO

According to the Fact Sheet, the EO will:

• Remove barriers to threat information sharing between government and the private sector,

• Modernize and implement stronger cybersecurity standards in the federal government,

• Improve software supply chain security,

• Establish a cybersecurity safety review board,

• Create a standard playbook for responding to cyber incidents,

• Improve detection of cybersecurity incidents on federal government networks, and

• Improve investigative and remediation capabilities.

Improving Investigation and Remediation

A quick look at the requirements within this section of the Order will provide some level of insight into how the order attempts to accomplish the overall goals. I will be doing a similar analysis for the remaining requirements in subsequent blog posts.

Section 8 of the EO addresses the standards needed for network and systems logs on Federal Information Systems. Paragraph (a) establishes that it “is essential that agencies and their IT service providers collect and maintain such data and, when necessary to address a cyber incident on FCEB Information Systems, provide them upon request to the Secretary of Homeland Security through the Director of CISA and to the FBI, consistent with applicable law.”

Paragraph (b) gives DHS (in consultation with DOJ and OMB) 14-days to provide OMB with “recommendations on requirements for logging events and retaining other relevant data within an agency’s systems and networks.” Those recommendations will include:

• The types of logs to be maintained,

• The time periods to retain the logs and other relevant data,

• The time periods for agencies to enable recommended logging and security requirements,

• How to protect logs, and

• Requirements to ensure that, upon request, agencies provide logs to the Secretary of Homeland Security through the Director of CISA and to the FBI, consistent with applicable law [this last is found in §8(e)].

Paragraph (c) gives OMB (in consultation with DOC and DHS) 90-days from receipt of the recommendations above to “formulate policies for agencies to establish requirements for logging, log retention, and log management, which shall ensure centralized access and visibility for the highest level security operations center of each agency.”

Cybersecurity Framework Comments – 12-28-13

This is the last in a series of posts about public comments submitted in response to the publication of the NIST Preliminary Cybersecurity Framework (PCSF). The earlier posts are listed below.

Cybersecurity Framework Update – 11-23-13

Cybersecurity Framework Comments – 11-30-13

Cybersecurity Framework Comments – 12-07-13

Cybersecurity Framework Comments – 12-14-13

Cybersecurity Framework Comments – 12-21-13

There were no new comments posted to the PCSF comment web site this week. I suspect that this means that all of the comments that were received in time (or even reasonably close to ‘in time’) have been posted. With the short time frame that NIST has in publishing the CSF I would not blame them for refusing to accept any additional comments.

I am still surprised by the relative lack of comments from the standard corporate commenters, especially from the chemical community. The ACC (part 1 and part 2) and Merc (part 1 and part 2) were the only two chemical commenters. This is kind of surprising because the chemical industry (under CFATS) and the pharmaceutical industry have some of the highest potential of seeing the CSF merged into current regulatory frameworks under EO 13636 §8(b).

DHS Announces NIAC Meeting – 11-21-13

The DHS National Protection and Programs Administration (NPPD) published a meeting notice in today’s Federal Register (78 FR 65657-65676) for a meeting of the National Infrastructure Advisory Council (NIAC) on November 11^th, 2013. The public meeting will be held in Washington, DC.

Two working group presentations will be made updating the Council on progress being made by the Regional Resilience Working Group and the EO-PPD Working Group. The Council will discuss both reports. Topics that will be addressed will include:

• Final recommendations to be included in the Regional Resilience Study;

• The role and impact of critical infrastructure in regional resilience;

• The working groups recommendations on the implementation of EO 13636 (cybersecurity);

Public comments are being solicited on both reports (which will be available, according to the notice, at least one week before the meeting on the Council’s web site. Limited opportunities (3 minutes each no more than 15 total) will be made available after each of the working group presentations for oral comments by the public (advanced registration to comment required). Written comments may be submitted by email (NIAC@hq.dhs.gov).

NIST Publishes Draft Agenda for 5th Cybersecurity Workshop

Along with publishing the Preliminary Cybersecurity Framework this week NIST published a draft agenda for the 5^th Cybersecurity Workshop to be held in Raleigh, NC on November 14^th and 15^th. The web page for this workshop notes that:

“At this workshop, NIST will continue discussions on the implementation and future governance of the Cybersecurity Framework.”

Keeping in mind that this is just a draft agenda, presumably subject to change, it looks like there will be a fundamental shift in this workshop, more towards selling the Framework than in developing the framework. This is not unexpected since the Preliminary Cybersecurity Framework is now open for public comments.

The heart of this Workshop will be two sets of working sessions. The first set will run from 1:30 to 2:45 pm and the second from 3:15 to 4:45. The same six topics will be discussed in both sessions; it is not clear if this was set up to be a total of 2-hrs and 45-minutes of work on the topics, or if it was designed to give participants a chance to take part in two different discussions. The current proposed topics are:

• Small and Medium Business Considerations;

• How to Use the Framework;

• Voluntary Critical Infrastructure Cybersecurity Program;

• Research and Development; and

• Framework Ecosystem Development.

Additionally there will be presentations and panel discussions on topics including:

• Preliminary Cybersecurity Overview;

• Adoption Considerations;

• Industry Perspectives Panel; and

• Privacy and Civil Liberties.

Looking at these topics it is not clear why NIST claims that the target audience is:

“Critical Infrastructure Owners and Operators and cybersecurity staff. Specifically those who have operational, managerial and policy experience and responsibilities for cybersecurity, technology and/or standards development for Critical Infrastructure companies.”

It would seem that with the apparent focus on selling the Framework, it would be more beneficial to draw participants that have the ability to persuade owners of the utility of adopting and implementing the Framework. It would seem that a more appropriate target audience would be industry association representatives, industry publications and bloggers.

Perhaps we will have a better understanding of the purpose of this Workshop when the final agenda is published, probably early next month.

DHS Announces CIPAC Meeting – 11-5-13

The DHS National Protection and Programs Directorate (NPPD) published a meeting notice in today’s Federal Register (78 FR 57644) for a meeting of the Critical Infrastructure Partnership Advisory Council (CIPAC) in Washington, DC on November 5^th, 2013. The meeting will be open to the public.

The notice provides only a very sketchy agenda, noting that CIPAC topics will include:

• Executive Order for Improving Critical Infrastructure Cybersecurity;

• Presidential Policy Directive 21—Critical Infrastructure Security and Resilience; and

• Critical Infrastructure Program Updates

Public participation is being solicited by DHS. There will be a limited period for oral comments from the public at the end of the meeting. Such comments will be limited to matters involving critical infrastructure security and resiliency. The limited comment time will require first come first serve registration at the meeting site. Written comments will be accepted and should be received by CIPAC by September 24^th. Written comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2103-0050).

BTW: Once again DHS fails to provide web coverage of a public advisory committee meeting.

Cybersecurity EO and FAR Incentives

The General Services Administration (GSA), in conjunction with the Department of Defense (DOD) published a request for information (RFI) in Monday’s Federal Register (78 FR 27966-27968) concerning the “feasibility, security benefits, and relative merits of incorporating security standards into acquisition planning and contract administration and address what steps can be taken to harmonize, and make consistent, existing procurement requirements related to cybersecurity”.

JWGICRA

The RFI announces the formation of the Joint Working Group on Improving Cybersecurity and Resilience through Acquisition (JWGICRA). The working group, under the leadership of the GSA, consists of members selected from the DoD, GSA, the Department of Homeland Security (DHS), the Office of Federal Procurement Policy (OFPP), and the National Institute of Standards and Technology (NIST).

The JWGICRA was formed to fulfill the 120-day reporting requirement of §8(e) of the President’s cybersecurity executive order (EO 13636). That report is supposed to address the “feasibility, security benefits, and relative merits of incorporating security standards into acquisition planning and contract administration”.

Definition of ‘Cybersecurity’

The RFI notes that the lack of a common lexicon is a “ is one of the critical gaps in harmonizing federal acquisition requirements related to cybersecurity”. For the purposes of this notice GSA is using the following definition of cybersecurity:

“(T)he term “cybersecurity” is given a broad meaning that includes information security and related areas, like supply chain risk management, information assurance, and software assurance, as well as other efforts to address threats or vulnerabilities flowing from or enabled by connection to digital infrastructure.”

Given this definition it is clear that industrial control systems (ICS) are included, but mainly as an afterthought.

Information Requested

This GSA RFI is looking for answers to a number of questions in a number of general categories. Those categories include:

• The feasibility of incorporating cybersecurity standards into federal acquisitions;

• Information about commercial procurement practices related to cybersecurity; and

• Information about any conflicts in statutes, regulations, policies, practices, contractual terms and conditions, or acquisition processes affecting federal acquisition requirements related to cybersecurity.

Public Comments

The GSA, on behalf of the JWGICRA, is soliciting public input in this RFI. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # Notice-OERR-2013). Comments must be submitted by June 12, 2013.

Commentary

This is a very late solicitation of information. The government has used up 90-days of the 120-day reporting limit working out the details of how the JWGICRA is going to operate. The NIST RFI was published within days of the President’s EO; they only had themselves to work with. The NTA-NIST RFI was almost a month in the making, they both worked for the Secretary of Commerce. Here the GSA was supposed to coordinate actions of the representatives of DOD and DHS in the area of acquisitions. I’m surprised that this was done as soon as it was.

The deadline for submitting comments is the same day that the GSA report is due to the President. Either the GSA is going to be late, ignore the public inputs solicited in this RFA, or is going to have a super human team of bureaucrats read, correlate, digest, compile and prepare a report in less than 24 hours.

I will prophesize that the report will be late and the President won’t even notice. I will assume that the public inputs will be generally ignored. And I will flatly state that making the time limit is bureaucratically impossible. Of course, I was saying this well before the EO was even published.

Really Late NIAC Meeting Notice

DHS NPPD is posting a meeting notice (78 FR 20934) in Monday’s Federal Register (available on line today) for a meeting Monday of the National Infrastructure Advisory Council (NIAC); so much for the required 15-day notice.

Tardy Excuse Rejected

This is not the first time that the NIAC meeting notice has been well short of the ‘timely notice’ requirement of 5 USC §10(a)(2). And what was the excuse this time?

“The Federal Advisory Committee Act requires that notices of meetings of advisory committees be announced in the Federal Register 15 days prior to the meeting date. However, this notice of the NIAC meeting is being published in the Federal Register on April 8, 2013, zero days prior to the meeting due to an immediate need by DHS to receive advice on the new implementation of Executive Order 13636 and Presidential Policy Directive 21. Both mandate comprehensive consultation with stakeholders in very short time lines for implementation. Although the meeting notice was published in the Federal Register late, the date of the meeting has been posted on the Council's public Web site on www.dhs.gov since January 2013. Additional outreach will be accomplished through trade and professional associations.”

So the meeting has been planned since January, but the DFO can’t get a notice into the Federal Register until the day of the meeting; that is really sad or should I say incompetent? I can’t even buy the EO/PPD excuse since those have been out for over a month. Even if a month were not enough time for NPPD to realize that NIAC might need a briefing on the topic, the meeting notice should have already been published and this would be an addition to the agenda.

Fortunately for NIAC there is no one that enforces this particular federal law, so they can give notice, or late notice, or probably no notice at all and nothing would happen. It just does not inspire confidence in the leadership at NPPD or DHS.

Agenda

The meeting notice provides the following agenda list for this meeting:

• NIAC Presentation on Regional Resilience Working Group

• Public Comment: Discussion Limited to Meeting Agenda Items and Previous NIAC Studies

• Regional Resilience Working Group Discussion

• Briefing and Discussion on Executive Order 13636 and Presidential Policy Directive 21 by the Department of Homeland Security

• Identification of Potential Areas to Recommend for Next NIAC Study

I would guess that the ‘potential area’ for the next NIAC study will be something to do with EO 13636 even though NIAC was not mentioned in the EO (the Critical Infrastructure Partnership Advisory Council was - §6 - though but we all know that there is no room for petty institutional jealousy in the federal government).

Copies of the EO Brief and the Regional Resilience WG presentation are available on the NIAC web site.

Public Comments

Public comments are being solicited, kind of. There will be time after the Working Group presentation for oral comments from the public, but the notice states: “We request that comments be limited to the issues listed in the meeting agenda and previous NIAC studies.” Written comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2013-0004), but they must be submitted by noon on Monday.

 OOPS, there is no such docket number on www.Regulations.gov as of 7:00 am CDT, 4-6-13; maybe they don’t really want your comments after all. Maybe you should try email ( NIAC@hq.dhs.gov) or fax {(703) 603-5098} and there is even a snail mail address given (yep, that will get there by noon on Monday).

Cybersecurity Incentives – Notice of Inquiry

Today the National Institute of Standards and Technology (NIST) and the National Telecommunications and Information Administration (NTIA) co-published a notice of inquiry in the Federal Register (78 FR 18954-18955) looking for information to support the development of incentives to adopt the improved cybersecurity practices to be developed by NIST as part of the President’s Cybersecurity Executive Order (EO 13636).

According to the notice summary the inquiry is designed to support the Department of Commerce’s incentives effort in three ways:

• Analysis of the benefits and relative effectiveness of such incentive;

• Whether the incentives would require legislation or can be provided under existing law, and

• Whether the incentives could be applied to US industry as a whole.

The Department asked a similar set of questions in 2010 (75 FR 44216) and plans to incorporate the results of that request into their report to the President which will be submitted no later than June 12^th, 2013. In this inquiry NIST/NTIA would like respondents to the earlier request to comment on whether or not their earlier comments are still applicable.

The notice also provides a lengthy list of questions to which it would like all interested parties to respond. Those responses may be sent to NTIA (cyberincentives@ntia.doc.gov) and must be received by April 29^th, 2013. The short response time is necessitated by the deadline for having a report to the President. Comments will be made available on the Internet Policy Task Force web page. 

Cybersecurity EO – NIST RFI Questions

This is the second in a series of posts about the Cybersecurity Framework being developed by the Director of the National Institute of Standards and Technology (NIST). This post looks at some of the questions NIST is including in their Request for Information that will be published in the Federal Register in the hopefully not too distant future.

Earlier blog posts include:

Cybersecurity EO – Developing the Cybersecurity Framework

As I noted in the earlier post, the Director has posted on the NIST web site a draft of the request for information (RFI) that he intends on publishing in the Federal Register as part of the collaborative effort to develop a consensus supported Cybersecurity Framework as part of President Obama’s Executive Order “Improving Critical Infrastructure Cybersecurity” (EO 13636). Under the terms of that EO the Director of NIST is supposed to publish a preliminary Framework by October 17^th, 2013.

The draft RFI addresses three main areas that it wishes the critical infrastructure community to address in providing information to support the development of the Cybersecurity Framework. They are:

• Current Risk Management Practices (pg 4);

• Use of Frameworks, Standards, Guidelines, and Best Practices (pg 5); and

• Specific Industry Practices (pg 6).

Current Risk Management Practices

There are twelve general questions listed in this section that NIST would like the critical infrastructure (CI) community to answer. The first two are sort of generic questions dealing with the challenges associated with cybersecurity; specifically with improving CI cybersecurity practices and with developing a cross-sector, standards based Framework. The remaining questions deal more specifically with how CI organizations are currently dealing with cybersecurity management issues.

While I have mentioned an apparent information technology focus of the EO and the RFI, that focus is much less noticeable here. None of the questions actually mentions IT and they all could clearly include policies and procedures dealing with control system issues. I do think that the vast majority of the responses that NIST will receive for these questions will be IT focused. That realistically reflects the fact that the IT portion of the cyber-community is much larger and has been focusing on cybersecurity issues longer.

Having said that, and given the fact that control system security issues are more likely to lead to catastrophic effects, I would like to suggest that NIST add two control-system specific questions to the mix about current risk management practices:

• Does the organization maintain separate security programs for control systems and information systems or are they combined under a single manager?

• Are there significant differences in the ways in which the security programs for IT and control systems manage the risks associated with those systems?

Use of Frameworks, Standards, Guidelines, and Best Practices

Since the President’s guidance for the development of the Cybersecurity Framework emphasizes the maximum possible use of existing consensus standards this second set of questions will be very important in gathering the data necessary for that development.

Again, the questions in this section are generic enough that they could address both IT and control system security issues. Unfortunately, given the relative size of the IT security and control system security communities within most organizations, I’m afraid that the control-system security side of the problem will not receive the same level of attention in the responses to these questions.

To ensure that the control-system side receives adequate attention I would like to see one question added to this section:

• Does the organization utilize different standards, guidelines and/or best practices in establishing the security requirements for their IT systems and control systems?

Specific Industry Practices

The last set of questions deal with 9 specific areas dealing with current industry practices concerning cybersecurity. Those areas are:

• Separation of business from operational systems;

• Use of encryption and key management;

• Identification and authorization of users accessing systems;

• Asset identification and management;

• Monitoring and incident detection tools and capabilities;

• Incident handling policies and procedures;

• Mission/system resiliency practices;

• Security engineering practices; and

• Privacy and civil liberties protection.

Reading the questions for this section it is clear that NIST considers these 9 areas to be the core practices that will be included in the framework. This makes the inclusion of the first area very important. I would, however, like to suggest that one key area is missing from this list, a personnel surety program though I suppose that could be shoe-horned into the identification and authorization of users.

The IT-centric nature of the program does raise its head unnecessarily in Questions 7 in this section. That question reads:

Do organizations have a methodology in place for the proper allocation of business resources to invest in, create, and maintain IT standards?

Substitute ‘cybersecurity’ for ‘IT’ in that question and I think that you have a more appropriate question for both sides of the cyber house.

Moving Forward

It was encouraging to see that NIST was so far ahead of the game with their development of the draft RFI before the ink was dry on Obama’s signature on the EO. Of course they were well aware of the Cybersecurity Framework requirements, probably back in November, or maybe even before. The delay in getting the RFI published in the Federal Register, however, points to the political wrangling that will inevitably make it difficult for NIST to meet their October 17^th deadline for the publishing of the preliminary Framework.

And remember, there are other deadlines that will have an impact on the timeliness of NIST’s work. I’ll look at those in some detail in future blogs in this series.

Cybersecurity EO – Developing the Cybersecurity Framework

It has been almost a week since President Obama’s Executive Order on critical infrastructure cybersecurity (EO 13636) was officially published in the Federal Register (78 FR 11737-11744). There are a number of important deadlines provided in the EO but one of the most critical is the requirement for NIST to publish a “preliminary version of the Cybersecurity Framework” {§7(e)} within 240 days of the publication of the EO (deadline – 10-17-13).

Consultative Process

Complicating the meeting of this deadline are the requirements of §7(d) that describe the development requirements that must be met. The first is that the Director of NIST will “engage in an open public review and comment process”. Principally this is going to require that at the end of initial process the preliminary Framework will be published in the Federal Register and there will be a public comment period provided. Since this is the end product of the 240 day deadline. That does not seem to be a cause for potential delay except that the document has to be submitted to OMB for review/approval before that publication takes place. That review process can take anywhere from a couple of weeks to years.

The Director is also required to consult with a variety of government agencies in the development process. The EO states that the Director will consult with “the [DHS} Secretary, the National Security Agency, Sector-Specific Agencies and other interested agencies including OMB”. The Director of NIST does not have the same political weight as the Secretary, the Director of NSA or OMB, so that ‘consultative’ process will probably be done in more of a directed fashion. That will be further complicated by the fact that those three agencies have frequently conflictive objectives. Of course, no one expects that there will be any petty political foot dragging because NIST got to develop the Framework and not DHS or NSA (just a tiny bit of political sarcasm here).

Other ‘lesser’ government agencies are also to be consulted in the framework development process. They include:

• Other relevant agencies;

• Independent regulatory agencies; and

• State, local, territorial, and tribal governments.

A number of ‘other’ federal agencies have some measure of cybersecurity oversight responsibility that will have to be consulted so that their toes won’t get stepped upon. The real sensitive toes will be found in the ‘independent’ regulatory agencies who have some active current cybersecurity programs in place, including FERC, NRC and SEC to mention a few.

There are also requirements to consult with the private sector. These are more clearly identified in §6 of the EO and include the:

• Critical Infrastructure Partnership Advisory Council;

• Sector Coordinating Councils;

• Critical infrastructure owners and operators;

• Universities; and

• Outside experts.

Since the Secretary has 150 days to identify specific critical infrastructure at ‘Greatest Risk’ this could be a special delaying factor in the consultative process. It looks, however, like the Director has found a way to shortcut this problem and to expansively engage the potentially affected private sector communities. There is going to be a Request for Information (RFI) published in the near future in the Federal Register asking for general and some specific information that will be used to develop the preliminary Framework. In effect, if not de jure, this will be an advance notice of propose rulemaking (ANPRM).

Draft RFI

It certainly seems like the Director intends to meet the 240 day deadline set by the President. A draft copy of the RFI was produced (apparently from the file name) on February 12^th the day before the President released the EO. I have been waiting expectantly all week for it to appear in the Federal Register, but it appears that we may have already hit the first OMB delay.

The NIST draft RFI document (page 1) proposed three goals for the Framework development process:

• To identify existing cybersecurity standards, guidelines, frameworks, and best practices that are applicable to increase the security of critical infrastructure sectors and other interested entities;

• To specify high-priority gaps for which new or revised standards are needed; and

• To collaboratively develop action plans by which these gaps can be addressed.

NIST goes on to explain (page 2) that in order to be effective the Framework should provide:

• A consultative process to assess the cybersecurity-related risks to organizational missions and business functions;

• A menu of management, operational, and technical security controls, including policies and processes, available to address a range of threats and protect privacy and civil liberties;

• A consultative process to identify the security controls that would adequately address risks that have been assessed and to protect data and information being processed, stored, and transmitted by organizational information systems;

• Metrics, methods, and procedures that can be used to assess and monitor, on an ongoing or continuous basis, the effectiveness of security controls that are selected and deployed in organizational information systems and environments in which those systems operate and available processes that can be used to facilitate continuous improvement in such controls;

• A comprehensive risk management approach that provides the ability to assess, respond to, and monitor information security-related risks and provide senior leaders/executives with the kinds of necessary information sets that help them to make ongoing risk-based decisions;

• A menu of privacy controls necessary to protect privacy and civil liberties.

Control System Coverage

A close reading of the guidelines explicated above shows that the NIST appears to be information focused. This is made clear by the introductory sentence that precedes the list above. It states:

“In order to be effective in protecting the information and information systems [emphasis added] that are a part of the U.S. critical infrastructure, NIST believes the Framework should have a number of general properties or characteristics.”

Reading through the remainder of the document there are a few mentions of control system issues but the vast bulk of this document focuses on information systems. I’ll look at the information requirements, and their relationship to control system security issues, of the RFI in future blog posts.