Showing posts with label Framework. Show all posts
Showing posts with label Framework. Show all posts

Thursday, September 5, 2013

Cybersecurity Framework Update – Conformity Assessment

This is part of a detailed look at the recently published Discussion Draft of the Preliminary Cybersecurity Framework (PCF). The NIST Information Technology Laboratory (ITL) published this and supporting documentation to their web site during the week of August 28th in order to allow for public comments and preparatory work for the 4th Cybersecurity Framework Workshop in Dallas, TX next week. The other posts in the series are:


Section 4 of the Discussion Draft addresses a number of issues for future action in support of the requirements set forth in §7(b) of Executive Order 13656. The Draft identifies the following areas “that should be addressed through future collaboration with particular sectors and 353 standards-developing organizations” (pg 11):

• Authentication
• Automated Indicator Sharing;
• Conformity Assessment;
• Data Analytics;
• International Aspects, Impacts, and Alignment;
• Privacy; and
• Supply Chains and Interdependencies

Since the third item appears to be related to something akin to regulations, a major concern of industry, I would like to use this post to address ‘Conformity Assessment’.
Private Sector Assessments

The discussion in §4.3 (pg 12) makes it clear that NIST is not referring to government assessments as part of a regulatory scheme. It starts the discussion off with the following statement:

“Industry has a long history of developing conformity assessment programs to meet society’s needs.”

And it closes the discussion with the following statement:

“Critical infrastructure’s evolving implementation of Framework profiles should drive the identification of private sector conformity assessment activities that address the confidence and information needs of stakeholders.”

Programs like the ISO 9000 quality assessment or The American Chemistry Council’s Responsible Care chemical safety program are the types of assessments to which the Discussion Draft is referring as examples of private sector assessment programs.

Conformance vs Security Debate

There has been a long standing debate in the security community about the differences between conformance to standards and actually instituting adequate security. There is a belief common in security professionals that conformance standards promote a culture of check lists and doing just what is necessary to get ‘approval’. I don’t know that anyone has ever done a real study on the relationship between standards conformance and whether or not an organization takes additional security (safety, quality, whatever) measures not required by the standards organization.

The other side of that is that even if there is a tendency to resort to check list security as a result of establishing a cybersecurity assessment program will that improve the general level of cybersecurity in an industry? Will organizations that do not currently have an effective (or any) cybersecurity program make real improvements (if perhaps less than optimal improvements) to their cybersecurity posture as a result of trying to achieve a minimum level of cybersecurity certification?

Right now the answers to these types of questions will largely be apocryphal. The only real user level cybersecurity standard (with assessment) that I know of is the NERC CIP program and I haven’t heard of anyone doing any real studies of the efficacy of that assessment process. It would be interesting to have either NIST or NSF conduct such a study.

Assessment as an Incentive

The reason that most organizations take part in voluntary assessment programs is that it is good for business. Initial organizations that join these standards assessments do so to differentiate themselves from their competition. As more organizations join the programs it becomes a defensive measure as customers begin to ask why a vendor doesn’t take part in the programs with the unasked question; what are you hiding?

Since the Cybersecurity Framework is specifically targeted at high-risk critical infrastructure organizations and facilities people are, over time, going to expect some sort of statement of compliance from such organizations. This will, of course be limited to some extent since DHS is not expected to announce what organizations are going to be targeted by this program. Even so, there will be some obvious facilities and organizations that will be assumed to be on the List (even if they may not be) so there will be an expectation of a need to comply with the Framework.

As cybersecurity becomes more of an obvious need (almost certainly after a publicly successful attack on an industrial control system) more organizations will be expected by the business community to need to comply with the Framework. The best way to gain recognition for compliance will be through one of these compliance assessment programs.

Moving Forward


As the Framework advances (and I still have some doubts about the completion of this process) I think that we will start to see industry organizations developing assessment programs to support facilities that will be expected to comply. I would not be surprised to see the American Petroleum Institute or ACC be among the early implementers. And NERC might be expected to adapt their CIP assessment process to more nearly include the Framework.

Tuesday, July 30, 2013

S 1353 Introduced – Cybersecurity

As I noted last week, Sen. Rockefeller (D,WV) introduced S 1353, the Cybersecurity Act of 2013. This bill has received a lot of attention in the main stream press as a bill that would formally implement the cybersecurity framework initiated by the Obama Cybersecurity Executive Order (EO 13636), but there is very little linkage, if any, between the two.

The bill is organized into three Titles:

Title I — Public-Private Collaboration on Cybersecurity
Title II — Cybersecurity Research and Development
Title III — Education and Workforce Development

The last two titles are little more than rehashes of R&D and education programs outlined in other legislation and share the same short comings. No new funds are identified for the new and or repurposed programs so they will either have to steal funds from other worthwhile programs without Congress accepting responsibility for that reprograming or the new programs will die still born due to the lack of funds.

The meat of the bill is found in Title I, but even that suffers from the lack of specific funding authority for the executive actions that are directed to be accomplished by that title.

Definitions

Before we actually get to Title I we need to first glance through Sections 2 and 3. Section 2 of the bill defines three terms to be used in this bill:

• Cybersecurity mission;
• Information infrastructure; and
• Information system.

The first is a very expansive term that describes a wide range of activities that includes such things as threat reduction, international engagement, resiliency (which is not an activity the last time I looked) and incident response to name a few. It also ropes in some aspects of even more disparate activities such as law enforcement, diplomacy, military and intelligence missions where they relate to the security and stability of cyberspace.

The second term, ‘information infrastructure’, means “the underlying framework that information systems and assets rely on to process, transmit, receive, or store information electronically” {§2(b)}. Interestingly the definition specifically includes “communications networks, and industrial or supervisory control systems [emphasis added] and any associated hardware, software, or data”.

Before anyone gets too excited about the specific of control systems, it needs to be made clear that the construction of the second and third definitions limits those control systems to those that directly support information systems. The definition of that term comes from 44 USC 3502(8) where it is defined as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information”. So we can forget this bill covering security for any control system that manufactures, controls or moves anything besides information.

One last thing that we need to look at before we get to Title I is §3 of the bill. It specifically and unequivocally states:

“Nothing in this Act shall be construed to confer any regulatory authority on any Federal, State, tribal, or local department or agency.”

Public-Private Collaboration - NIST

Section 101(a) starts out by modifying the list of activities that the Secretary of the Department of Commerce is allowed (not required) to perform through the Director of the National Institute of Standards and Technology (NIST) under 15 USC 272(c) by adding sub-paragraph (15) that would allow “on an ongoing basis, [to] facilitate and support the development of a voluntary, industry-led set of standards, guidelines, best practices, methodologies, procedures, and processes to reduce cyber risks to critical infrastructure”.

If the drafters of this bill had really wanted NIST to undertake a proactive cybersecurity development program they would have listed this program in §272(b) under the mandated functions of the Institute rather than under the allowed activities in §272(c). This is especially true since §272(c)(13) and (c)(14) already provide wide latitude to study computer controls and information systems.

Section 101(b) goes on to add another paragraph to 15 USC 272. Section 272(e) provides additional details about how the Director is to go about executing his newly allowed activities. There is a lot of coordinating and consulting mentioned before one gets to the meat in §272(e)(1)(A)(iii) that outlines a mandate (in an allowed, not required activity) to “identify a prioritized, flexible, repeatable, performance-based, and cost-effective approach” that can be voluntarily adopted “owners and operators of critical infrastructure to help them identify, assess, and manage cyber risks”.

Section 272(e) goes on to require that the approach would

• Mitigate impacts on business confidentiality {§272(e)(1)(A)(iv)(I)};
• Protect individual privacy and civil liberties {§272(e)(1)(A)(iv)(II)};
• Incorporate voluntary consensus standards and industry best practices {§272(e)(1)(A)(v)};
• Align with international standards ‘to the fullest extent possible’ {§272(e)(1)(A)(vi)}; and
• Prevent conflict with regulatory requirements, mandatory standards and related processes {§272(e)(1)(A)(vii)}.

Section 272(e)(2) provides limited protection of information shared with or provided to the Director of NIST in support of §272(c)(15). It specifically states that the information “shall not be used by any Federal, State, tribal, or local department or agency to regulate the activity of any entity”. The bill does not, however, provide any protection against public disclosure of that information or use of that information in civil actions by those other than the government. Nor are there any provision to protect against anti-trust actions based upon the sharing of standards, best practices or security practices.

There are also no provisions in this bill for protected information sharing about specific intelligence or threat information. To be fair, one would not expect that in an NIST activity as it is not part of the intelligence community, but the sharing of threat intelligence will almost certainly have a major impact on the development of best practices, methodologies and procedures. Without open and effective threat information sharing the effectiveness of any such developments will be stunted to say the least.

EO Lite

Because the crafters of this bill limited Title I of the bill to just activities at NIST, this bill only supports just the barest number of supports for the Cybersecurity Framework currently be  developed by NIST in support of the President’s EO. Without the activities outlined for agencies in DHS, DOD, Justice and GSA in the EO, the most effective parts of the Framework are either not present or not supported by this flimsy legislative structure.

The biggest shortcoming of this bill in this regards is the complete lack of any indication that one of the largest portions of the cybersecurity threat currently facing this country is not information related (though that is certainly an important area of concern) but rather the vulnerability of physical control systems to manipulations that could cause  widespread physical damage, mass casualties or the destruction of infrastructure that would reverberate throughout our economy through cascading supply chain damage.

Moving Forward


This bill will likely move through markup today without discussion. The big question will be if, after the summer recess, it will have any chance of making it to the floor of the Senate. A lot of that will depend on the competing bills that are crafted between now and then. This is a bland enough bill that it would probably pass, both here and in the House if it were to make it a vote.

Monday, July 29, 2013

Senate Cybersecurity Markup

The Senate Commerce, Science and Transportation Committee announced today that they will be conducting a markup hearing of S 1353, the Cybersecurity Act of 2103 tomorrow. This will have to be one of the fastest rubber-stamp hearings on record as the Committee will also be considering 11 other Senate bills, one resolution, eight nominations and the Coast Guard promotion list. I’ll be very surprised if there is much discussion about this bill.


The copy of the bill just became public this afternoon. I’ll have a report on it before morning.

Wednesday, March 6, 2013

NIST-NPPD Cybersecurity MOU


Thanks to a note from Bob Radvanovksy over on SCADASEC-L mailing list, I found a copy of the memorandum of understanding (MOU) between NIST and DHS NPPD about the cooperation between the two organizations in the development and implementation of the Cybersecurity Framework. It was signed the responsible Under Secretaries from DHS and Commerce the day the President publicly released his executive order.

The details of who provides assistance to whom are pretty straightforward, even couched in bureaucratese. Both will provide a person to work in the other’s office to act as a coordinator. There will be all sorts of consulting and coordinating going on. If you’re interested in how these two agencies are going to be working together to get the EO in actual operation, this is worth the read.

Handoff of Develop to Implement

One of the things that is hopeful here is that there seems to be a clear understanding that there is a difference between developing the Framework and implementing it. I was more than a little concerned that two different organizations from different bureaucratic cultures would be handling the two side of this program; particularly since the first common point in their respective chains-of-command is the President.

NIST promises to provide “technical expertise ot NPPD regarding the application of NIST-developed standards, guidelines, and frameworks; detection and handling of information security incidents, development of cybersecurity vulnerability assessments; and security automation” (pg 2).

NPPD’s side of the hand off is covered in two separate will consults;

• [O]n the production of bulletins or memoranda pertaining to implementation of standards, guidelines, frameworks or other applicable cybersecurity policies”; and

• [O]n the development of metrics that will be used by Departments and Agencies to measure the effectiveness of cybersecurity programs or identify optimal security solutions”.

One Small Red Flag

There is potential for problems in one of the areas where NPPD outlines its support responsibilities for the development of the Framework. At the bottom of page 2 NPPD promises to:

“Provide relevant information, including analyses, priorities, sector specific plans, vulnerability assessments, and reports on operational aspects of Federal agency cybersecurity, consistent with NPPD information sharing policies [emphasis added], to assist NIST in the development of information security standards, guidelines, and frameworks.”

I know that politicians are constitutionally incapable of committing to anything without caveats and exemptions and this MOU is no exception. But, having said that, the development of the Framework is such an important part of this program that the holding back of information because of intra-governmental information sharing policies could kill the effectiveness of the EO.

Timing Coincidence

One last thing; I do find it very interesting that the MOU between the main players in the President’s new cybersecurity executive order signed this document on the day the President publicly released the EO. Since the drafts that have been circulating since November were almost identical to the finished product, one wonders why the delay in publishing this signature document.

I suspect that it was to allow time for these two agencies to work out their differences and find a way to work together to get the project going in the right direction. If that is the case, this took quite a while for a relatively uncomplicated document. How much time is it going to take to iron out their differences on something like the Framework?

Moving Forward

I’m starting to feel a little better about the ability of NIST to get their preliminary Framework, published, though I am far from confident. The little red flag here still show that they have a number of bureaucratic hurdles to overcome while they are working on a technologically complex task. Few organizations are well suited to handle both.

BTW: The new Cybersecurity Executive Order is never mentioned in this MOU.
 
/* Use this with templates/template-twocol.html */