Showing posts with label Research. Show all posts
Showing posts with label Research. Show all posts

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.

Sunday, October 28, 2012

DHS S&T Awards Cybersecurity Research Contracts


There is an interesting article over on HSToday.US that looks at an overview of 34 R&D contracts ($40 million) recently awarded by the DHS S&T Directorate to look at a variety of areas of cybersecurity research. The 34 contracts have been awarded to 29 research organizations including national laboratories, universities and private organizations. The research will address issues in 14 technical topics.

Anthony Kimery’s article looks at the broad picture of this research but doesn’t address how this might impact the industrial control system (ICS) community. That isn’t unexpected since the document that forms the basis for the research proposals being funded, the Cyber Security Research and Development Broad Agency Announcement (BAA) BAA 11-02, doesn’t mention control systems in its 82 pages and only mentions Stuxnet once (in an inappropriate manner at that).

Research Areas


Having said that, it is safe to assume that at least some of the research will result in information that will be useful to the ICS security community. Since we don’t have access to the specific research proposals we have to look at the technical topics listed in the BAA that the folks at S&T wanted the research community to address. Those technical topics areas (TTAs) are:

• TTA #1: Software Assurance;

• TTA #2: Enterprise-Level Security Metrics;

• TTA #3: Usable Security;

• TTA #4: Insider Threat;

• TTA #5: Resilient Systems and Networks;

• TTA #6: Modeling of Internet Attacks;

• TTA #7: Network Mapping and Measurement;

• TTA #8: Incident Response Communities;

• TTA #9: Digital Provenance;

• TTA #10: Hardware-Enabled Trust;

• TTA #11: Moving Target Defense;

• TTA #12: Nature-Inspired Cyber Health; and

• TTA #13: Software Assurance MarketPlace

ICS Security Excluded


The definition of three of these TTAs (#2, #4 and #12) specifically limits the research to areas affecting information technology. It is conceivable that results may have applications for ICS security, but the specific targeting of IT systems makes it unlikely that results will be easily transferable to the industrial control system setting.

TTA #7 looks at too large a scale to be of immediate usefulness in protecting control systems as it looks at the geographic and topological mapping of Internet hosts and routers.

ICS Systems


TTA #5 doesn’t mention control systems specifically but the description of targeted systems seems directly applicable to ICS; it targets ‘time-critical’ systems. It defines these as “a system for which faster-than-human reaction [emphasis added] is required to avoid adverse mission consequences and/or system instability in the presence of attacks, failures, or accidents” (pg 46). Interestingly this TTA suggests that researchers look at both security and resilience. Recognizing that malware is part of the cyber-environment the folks at S&T suggest that operation in the presence of malware is a key to security and resilience. They propose that researchers look at technology that enables (pg 47):

• Tolerating malware (for example, safely doing a trusted transaction from a potentially untrusted system);

• Investigating "safe sandbox" techniques for critical transactions; and

• Tolerating a residual level of ongoing compromise within components and subsystems of a larger system.

TTA #6 concerns the modeling of Internet attacks and this is where the folks at S&T mentioned Stuxnet (pg 49):

“Malware and botnet activity in recent months and years has intensified across the Internet and other critical infrastructures, with recent events, such as Conficker and Stuxnet, demonstrating the clear and present threat posed that is intelligent, adaptive, and effective at scale over increasingly shorter time periods.”

While Stuxnet certainly targeted control systems and did spread via the internet to non-target systems, the Internet was not used in spreading the malware to the targeted computers in Iran. Beyond this apparent misunderstanding, however, this TTA is at least partially addressed to research on control system security. The BAA makes this clear when it requires that:

“Technologies developed under this topic must perform their functions within legal and ethical boundaries. It is expected that the resultant tools would be commercialized and made available to critical infrastructure providers [emphasis added] in addition to government network operations.”

Limited ICS Applicability


The definitions of the remaining TTAs all could have some applicability to ICS security, but they are still basically addressing IT security issues. Depending on how the research proposals are structured will determine how much use they will be to the ICS community. Having said that, there are some parts of the TTAs that appear to be the most interesting from the view point of control system security.

TTA #1 looks at software assurance and calls for the development of new tools that will allow for the analysis of existing software, “discovering vulnerabilities, defects, and other types of weaknesses” (pg 36) as well as tools for runtime monitoring of software. The first will help identify potential security holes and second will help to identify attacks in progress. Both will be of great help in protecting any cyber-system from attack.

TTA #3 is very broadly defined, maybe too broadly defined to be of practical use but it does raise the issue of the inherent conflict between security procedures and ease of use. It note that (pg 42):

“Security must be usable by non-technical users, experts, and system administrators. Put another way, systems must be usable while maintaining security. In the absence of usable security, there is ultimately no effective security. The need for usable security is increasingly being recognized, as is the fact that usable security is a challenging problem.”

TTA #8 introduces a new term in cybersecurity response; the CSIRT – the Cyber Security Incident Response Team. This is a sociological research requirement designed to determine “the characteristics that make an excellent CSIR individual, team, and community, and how these capabilities are identified and enhanced” (pg 54). While this might be helpful in the long run it isn’t going to make any immediate change in the funding and manning of such organizations.

TTA #9 is a socio-economic look at cyber-attacks. It is a one-dimensional analysis of the problem of cybersecurity that asks researchers to look at the economic motivation of attackers. It completely ignores the political aspects of attackers; there is no acknowledgement of the problem of cyber-terrorism or nation-state directed attacks.

TTA #10 asks researchers to look at the importance of digital provenance; “the chain of successive custody, including sources and operations, of computer-related resources such as hardware, software, documents, databases, data, and other entities” (pg 61). Digital provenance is going to be increasingly important as more and more counterfeit components and software make their way into the control system supply chain.

TTA #11 addresses the concept of hardware security as opposed to ensuring security through software and firm ware. S&T asks researchers to look at “new technologies will ensure that hardware will not inadvertently leak secrets or execute malware (even if penetrated by malware), and it will execute security-critical tasks even if partially compromised” (pg 64). It certainly sounds like a worthwhile goal, but it would seem to limit some of the current functionality found in systems where firmware or software allows for expansion of capabilities.

TTA #13 introduces a novel idea, building into cyber-systems something akin to the biological response to infections. The BBA notes:

“In the future, network components must have heightened ability to observe and record what is happening to and around them. With this new awareness of the system health and safety, these “self-aware systems” enjoy a range of options: these system may take preventative measures, rejecting requests which do not fit the profile of what is good, a priori, for the network; these systems can build immunological responses to the malicious agents which they sense in real time; these systems may refine the evidence they capture for the pathologist, as a diagnosis of last resort, or to support the development of new prevention methods. In the future, system owners should be able to monitor and control such dynamic cyber environments.”

TTA #14 ties back into TTA#1. It asks for the establishment of (pg 75): “a software assurance facility and the associated services that will be made available to both software analysis researchers and software developers, both open source and proprietary. Software analysis researchers will have access to services allowing them to test new algorithms for static, dynamic, and binary analysis against a variety of software in a multi-platform environment.” The value of such a facility is obvious, but it requires the successful implementation of TTA #1 to provide the tools of the facility.

Results Are What Counts


The awarding of these contracts is an important step, but the amount involved is a relatively small investment in cybersecurity. And it must be remembered that the investment in research does not always (or even often) produce the desired results. Still it is an important step being taken by DHS and some of these programs should start paying off in the next year or so.
 
/* Use this with templates/template-twocol.html */