The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.

Cyber Vulnerability Disclosure Policies for the Smart Grid Adam Hahn Department of Electrical and Computer Engineering Iowa State University Ames, IA 50011

Discover the best professional documents and content resources in AnyFlip Document Base.
Search
Published by , 2016-02-25 00:39:03

Cyber Vulnerability Disclosure Policies for the Smart Grid

Cyber Vulnerability Disclosure Policies for the Smart Grid Adam Hahn Department of Electrical and Computer Engineering Iowa State University Ames, IA 50011

Cyber Vulnerability Disclosure Policies for the
Smart Grid

Adam Hahn Manimaran Govindarasu
Department of Electrical and Department of Electrical and

Computer Engineering Computer Engineering
Iowa State University Iowa State University

Ames, IA 50011 Ames, IA 50011
Email: [email protected] Email: [email protected]

Abstract—As smart grid technologies become more widely full disclosure, limited disclosure, and non-disclosure policies
deployed, an increasing number of cyber vulnerabilities will be [1]. Both positive and negative effects of these disclosure
approaches are addressed. Specific examples of current organi-
found throughout the supporting systems. While the traditional zational policies are compared along with those of disclosure
coordination agencies, such as CERT/CC and ICS-CERT.
IT industry has a long history of dealing with vulnerability Finally, domain-specific characteristics are identified along
with their potential to provide improved disclosure methods.
disclosures, however, recent discoveries within control system
II. VULNERABILITY DISCLOSURE ATTRIBUTES
software have shown the power industry still lacks sufficient po-
The “Vulnerability Disclosure Framework” developed by
lices and approaches. This paper introduces current vulnerability the National Infrastructure Advisory Council (NIAC) iden-
disclosure methods, including full disclosure, limited disclosure, tifies guideline for all stakeholders within the vulnerability
and non-disclosure. It then provides a comparison of disclosure disclosure process [13]. Specific suggestions for vendors are
policies by both vendors and disclosure coordinators. Finally, provided to ensure vulnerability discoverers have adequate
resources and venues to provide findings and gain acknowl-
it addresses industry specific characteristics which may impact edgement of their assistance. Identified suggestions include the
following:
domain-specific disclosure policies and identifies requirements for
1) Public vulnerability management pages on their website.
improving disclosure methods. 2) Mechanisms to support vulnerability reports (such as a

I. INTRODUCTION email address or web form).
3) A defined time frame for acknowledging the received
Cybersecurity concerns within the electric grid have gained
increased focus in past years. More prevalent smart grid report.
technologies increase the dependency on cyber resources. 4) A public security advisory notification method.
Unfortunately, difficulties in the design and development of se-
cure software results in a large number of remotely attackable A. Vulnerability Disclosure Timespan
vulnerabilities. Government sponsored research has identified
a substantial number of vulnerabilities and weakness in the Fig. 1 identifies the steps involved in the vulnerability dis-
software, networks, and configurations of the grid’s cyber closure process and highlights times when the vulnerability is
assets [9], [8]. Often these systems were designed to operate both unpatched and disclosed to the public, thereby increasing
on segregated networks and were not engineered to be resilient risk to the utlity. The steps in this process are identified below.
against cyber attacks [10]. Many products do not undergo the
rigorous security analysis found in more popular IT products. 1) Creation - The point of time when the vulnerability first
As smart grid technologies proliferate, these systems will occurred in the software.
become more open and accessible, therefore requiring greater
security analysis by vendors, third parties, customers, and 2) Discover - When the vulnerability was first identified as
public experts. a security concern.

Recent concerns for the cybersecurity of control system 3) Notification - The point when the vendor was notified
software has attracted additional public security analysis. The of the vulnerability.
resulting disclosures have raised numerous concerns including
irresponsible disclosures by the vulnerability discoverer and 4) Mitigation Release - The time when the vendor released
lack of vendor acknowledgement of vulnerability significance. a patch or other mitigation.
These situation create hostility between vendors, discoverers,
and customers; which negatively impacts the development of 5) Mitigation Applied - Time when the consumer applied
timely mitigation strategies. the vendor-specified mitigation.

This paper provides an analysis of current vulnerability
disclosure strategies used within the IT domain, specifically

This work was funded by the National Science Foundation (Grant: CNS
0915945).

978-1-4673-2729-9/12/$31.00 ©2012 IEEE

Fig. 1. Vulnerability lifespan and disclosure policies B. Non-Disclosure

III. DISCLOSURE STRATEGIES Non-disclosure includes methods that only disclose vulner-
ability information to the product vendors. This disclosure
While various approaches can be taken to disclose cyber approach is generally used with privatized assessment efforts
vulnerabilities to vendors, generally these can be categorized where the vulnerability information is directly conveyed to the
into three methods. Full Disclosure results in the immediate vendor. Examples of private-disclosure may include product
public notification of all vulnerability details. Limited disclo- certifications, such as Common Criteria [12]. Another example
sure only immediate disclosures vulnerability information to would be government sponsored efforts to enhance the security
the product vendor and usually some coordinating organization of critical software platforms, including research performed by
(e.g. CERT) until a patch can be made publicly available. Non- national laboratories [9].
disclosure limits the disclosure to only the product vendor,
without addressing the general public. The remainder of this The primary advantage of non-disclosure methods is that
section will address each strategy in greater detail. vulnerability information is never released directly to the
public. Since vulnerability is never directly released, attackers
A. Full Disclosure can only infer vulnerability information through analysis of
software patches [2] or version differences. Therefore, it is
Within the full disclosure strategy, all vulnerability related unlikely that the vulnerability will be used to attack the system
information is released to the public upon the vulnerability dis- before it is appropriately mitigated.
covery. This information will likely include affected products,
technical details, and even potential exploit code. Information Private disclosure methods also have disadvantages. First,
is often posted to one of many Internet security news feeds, the lack of disclosure to public sources will decrease the
such as mailing lists or security-focused web sites. demand for an appropriate response. When vulnerability is
publicly disclosed it gains significant public awareness which
The most obvious concern from full disclosure is that creates demand for an timely vendor response. In fact, em-
vulnerability information and potential exploits are released pirical evidence has shown that disclosed vulnerability infor-
without an appropriate mitigation strategy. This situation will mation tends to negatively impact stock prices [18]. Secondly,
leave many systems unpatched and unprotected, therefore, without sufficient disclosure, product consumers are not able
substantially increasing the likelihood of a successful cyber to implement their own tailored defense mechanisms, such as
attacks. creating new intrusion detection system (IDS) rules.

Although full disclosure methods provide additional risk C. Limited Disclosure
from attack, there are also identified advantages. First, the
information’s open accessibility to the public creates an im- While full disclosure and non-disclosure methods provide
mediate demand for an adequate vendor response. Second, contradictory approaches, limited disclosure attempts to pro-
the openness of the vulnerability information also provides vide a hybrid approach which combines advantages features.
consumers with the ability to provide tailored mitigation Limited disclosure, often referred to as responsible disclosure,
strategies. typically requires that vulnerability information is provided
to the vendor before being disclosed publicly. This strategy
intends to provide the vendor with adequate time to create an
effective mitigation or patch before the information is publicly
released.

Limited disclosure methods commonly leverage the use
of a trusted third party to help manage and coordinate the
disclosure. Often government sponsored Computer Emergency
Response Teams (CERTs) maintain a responsibility to perform
this trusted third party role. The coordinator will generally
create a pragmatic response time for the vendor to provide
a fix before the public release. Additionally, the coordinator
publishes and publicly releases their own reports once the
response time has passed. Therefore, the development of a
limited disclosure policy attempts to ensure that vendor’s dili-
gently address the vulnerability while assuring the information
release does not introduce excessive risks.

D. Current Strategies

This section identifies currently implemented disclosure
strategies. The discussed strategies include both full and
limited disclosures used by popular software vendors, open-
source projects, and coordinating agencies. Table I provides a

Coordinators IT Vendors Industry Vendors Open Source
SEL
CERT/CC ICS-CERT Microsoft Google Document Ubuntu FreeBSD

Policy Location Webpage Webpage Webpage Webpage Webpage Webpage
Preferred Dis-
closure Method Limited Limited Limited Limited Limited Full Limited
Vulnerability
Mgmt. Page Yes Yes Yes Yes No Yes Yes
Delay
Reporting 45 days Variable Variable 60 days Variable Variable Variable
Mechanism
Security Advi- Web Form Email/Phone Email Email Email Email Email
sory
Technical Technical Security Blog Service Webpage, Security
Alerts, Alerts, Bulletin, Bulletins, Email list Advisories
Vulnerability Vulnerability Advisory Release Notes
Notes, NVD Notes, NVD

TABLE I
COMPARISON OF CURRENT DISCLOSURE PRACTICES

detailed comparison of the strategies, while the remainder of policies, including web pages containing specific reporting
this section will present a more thorough overview. requirement. The FreeBSD page suggests a limited disclosure
strategy, including a reasonable delay before public disclosure
1) Vendor Approaches: Analysis of vendor approaches will [19]. However, the Ubuntu strategy suggests that disclosures
address efforts both traditional IT vendors and industry specific are submitted through publicly available bug reports, which
vendors. Due to the large number of vendors, only a small more closely resembles a full disclosure policy [3].
sample with well established policies are addressed.
3) Disclosure Coordinators: The Computer Emergency Re-
Microsoft: The Coordinated Vulnerability Disclosure (CVD) sponse Team Coordination Center (CERT/CC) was the first
policy has been published by Microsoft to address continual organization to perform coordination activities and maintains
demands to mitigate vulnerabilities within their own software a vulnerability disclosure policy on their web page which
and report vulnerabilities within other vendor’s products [11]. encourages a limited disclosure approach [17]. This policy
The policy emphasizes limited disclosure methods and ac- identifies a 45 wait period until the vulnerability information
knowledges the benefit of trusted coordinator role. The policy is disclosed, regardless of whether an appropriate vendor mit-
does not specify disclosure time frame, instead suggesting that igation is available. Disclosure is performed through posting
the vulnerability finder allows the “opportunity to diagnose on the CERT/CC page, US-CERT postings, and entries in the
and offer fully tested updates, workarounds, or other corrective Nation Vulnerability Database (NVD) [5].
measures”.
The Industrial Control Systems Cyber Emergency Response
Google: The policy, which is posted on their web site, Team (ICS-CERT) is a DHS-funded organization which specif-
suggests limited disclosure and identifies 60 days as a rea- ically focuses on control systems and other critical infras-
sonable bound for addressing critical vulnerabilities [6], [7]. tructures. Information on ICS-CERT’s disclosure policy is
The policy states the vulnerability discoverers will be provided documented on their website [4]. The policy specifies that all
with a tracking number so they can follow Google’s mitigation vulnerabilities will be coordinated with the vendor, although
efforts. Additionally, Google provides a financial incentive for the specific time frame for disclosure is dependent on numer-
discoverers that follow their limited disclosure policy. ous factors including severity, potential impact, vendor patch-
ing feasibility, and availability of other mitigations. Severe
Schweitzer Engineering Laboratories (SEL): Five random vulnerabilities are disclosed through the release of US-CERT
power industry vendors were reviewed for documented vul- Technical Alerts and US-CERT Vulnerability Notes.
nerability disclosure policies. However, the only vendor to
provide a formal vendor policy was SEL. The policy, titled IV. WHAT IS NEEDED
“The SEL Process for Disclosing Security Vulnerabilities”,
specifically addresses SEL’s responsibility in the vulnerability The development of adequate disclosure policies will be-
mitigation process [16]. It provides contact information for coming increasingly important as the grid becomes more
reporting concerns and states where the company will docu- dependent on cyber assets. However, critical differences exists
ment vulnerability information. However, the policy does not between this domain and traditional IT environments. This
address how it will work with vendors or suggest mitigation section will introduce some of these environmental specific
time frames. attributes and then leverage these characteristics to identify
potential future directions.
2) Open Source Projects: In addition to industry-specific
and IT vendors, open source projects were also reviewed A. Analysis of Domain-specific Disclosure Policies
as they are frequently used to support many applications.
Specifically, two operating systems were addressed, FreeBSD The cyber resources within the electric power grid maintain
and Ubuntu Linux. Both projects maintain similar disclosure many unique characteristics which may impact the devel-

Fig. 2. Combination of traditional and industry specific technology address both the vendor’s acknowledgement of the vulnerabil-
ity and responsibility to address it in a timely manner. This
opment of an optimal disclosure policy. The following list should provide increased public confidence in the vendor and
identifies these domain-specific characteristics: encourage increased utilization of limited disclosure practices.

1) Combination of industry-specific and IT systems: As 2) Leverage regulatory agencies: Within the power system
displayed in Fig. 2 the electric grid systems often uses a domain, critical vulnerabilities receive less attention due to
combination of specialized software products (e.g. SCADA smaller customer bases. However, the presence of regulatory
servers, historians, EMS, RTUs) and traditional IT platforms agencies could help to ensure vulnerabilities are adequately
(e.g. operating systems, databases, web servers). This com- addressed. For example, NERC already implements Critical
bination will likely provide variations in the disclosure ap- Infrastructure Protection (CIP) requirements to ensure utilities
proaches adopted by the different domains. implement adequate cyber security protections [15]. Incorpo-
rating standards to address vulnerability mitigation require-
2) Longer patch deployment cycle: Vulnerability mitiga- ments could be used to formalize vendor responses to critical
tions, such as software patches, generally require additional issues.
testing by the vendor before they are released to the customer
[10]. This is to ensure changes to the operating system or 3) Specialized disclosure channels: The availability of a
supporting services do not negatively impact the operation of private communication medium, such as NERC Alerts, could
the power-specific applications. This additional testing length- assist the development of limited disclosure policies. Technical
ens the patch deployment cycle and creates additional time details about undisclosed vulnerabilities could be limited to
between the vulnerability discovery and when the mitigation utilities to increase awareness. Public disclosure could then
can be applied. occur after an an appropriate mitigation strategy has been
released.
3) Availability of non-public disclosure channels: Because
software consumers within this domain are generally limited to 4) Incorporation of traditional IT and industry specific
power system utilities, there exists a more formal relationship software: The power industry must also assume vulnerability
between vendors and customer which enables more focused disclosures will originate from both traditional IT and industry
disclosure. Additionally, utilities have access to the NERC specific vendors. This may limit any consistency about vendor
Alerts site which can be used to disclose critical information approaches for handling disclosure and requires adaptability to
about threats and vulnerabilities [14]. all possible methods.

4) Centralized Regulation: The North American electric V. CONCLUSIONS
grid is currently monitored by regulatory authorities such
as NERC to ensure it meets required reliability standards. Current vulnerability assessment results have identified nu-
Centralized regulation provides possible avenues to create merous security concerns within the electric grid, specifically
vulnerability management policies for vendors and utilities. poor software quality. This has led to recent conflicts between
software vendors, security researchers, and concerned public
B. Future Directions over acceptable approaches for addressing and mitigating
vulnerabilities. As smart grid initiatives expand, increased
Based on these previously identified characteristics, this awareness and acceptance of vulnerabilities must be exhibited
section proposes future efforts to help improve the efficiency by all involved stakeholders. Since many critical vulnerabili-
of the vulnerability disclosure process. ties are discovered by individuals without direct connections to
the software vendors, methods and policies to disclosure this
1) Adopt disclosure policies: Similar to many IT companies information to both the vendor and public are required. This
and suggestions in the NIAC report, the adoption of vendor paper identifies various disclosure methods and analyzes their
vulnerability disclosure policies will specify their commitment strengths and weaknesses. A survey of disclosure policies are
to developing and maintaining secure products. Policies should then compared between general IT vendors, industry-specific
vendors, open source projects, and disclosure coordinators.
Finally, domain specific characteristics affecting the disclosure
process are identified and future directions are presented based
on these characteristics.

REFERENCES

[1] A. Arora, R. Krishnan, R. Telang, and Y. Yang. Impact of vulnerability
disclosure and patch availability - an empirical analysis. In In Third
Workshop on the Economics of Information Security, 2004.

[2] D. Brumley, P. Poosankam, D. Song, and J. Zheng. Automatic patch-
based exploit generation is possible: Techniques and implications. In
Security and Privacy, 2008. SP 2008. IEEE Symposium on, pages 143
–157, may 2008.

[3] Canonical Ltd. Ubuntu Security Notices. http://www.ubuntu.com/usn/.

[4] Department of Homeland Security (DHS), Control Systems Security
Program (CSSP). ICS-CERT Vulnerability Disclosure Policy. http:
//www.us-cert.gov/control systems/ics-cert/disclosure.html.

[5] DHS, National Cyber Security Division, and NIST. National Vulnera-
bility Database (NVD). http://nvd.nist.gov/.

[6] Google Inc. Google Security and Product Safety. http://www.google.
com/about/corporate/company/security.html.

[7] Google Inc. Rebooting responsible disclosure: a focus on pro-
tecting end users. http://googleonlinesecurity.blogspot.com/2010/07/
rebooting-responsible-disclosure-focus.html.

[8] Idaho National Laboratory (INL). Common Cyber Security Vulnerabili-
ties Observed in Control System Assessments by the INL NSTB Program,
November 2008.

[9] Idaho National Laboratory (INL). NSTB Assessments Summary Report:
Common Industrial Control System Cyber Security Weaknesses, May
2010.

[10] Keith Stouffer, Joe Falco, Karen Scarfone. NIST SP 800-82: Guide to
Industrial Control Systems (ICS) Security. Technical report, National
Institute of Standards and Technology, September 2008.

[11] Microsoft Corporation. Coordinated Vulnerability Disclosure at Mi-
crosoft. http://go.microsoft.com/?linkid=9770197, 2011.

[12] National Information Assurance Partnership (NIAP). Common Criterial
Evaluation and Validation Scheme (CCEVS). http://www.niap-ccevs.
org/.

[13] National Infrastructure Advisory Council (NIAC). Vulnerability disclo-
sure framework, Jan. 2004.

[14] North American Electric Reliability Corporation. About NERC Alerts.
http://www.nerc.com/page.php?cid=5|63|253.

[15] North American Electric Reliability Corporation. NERC Criticial
Infrastructure Protection (CIP) Reliability Standards, 2009.

[16] Schweitzer Engineering Laboratories, Inc. The SEL Process for Dis-
closing Security Vulnerabilities.

[17] Software Engineering Institute (SEI), Carnegie Mellon. CERT/CC Vul-
nerability Disclosure Policy. http://www.cert.org/kb/vul disclosure.html.

[18] R. Telang and S. Wattal. Impact of Software Vulnerability An-
nouncements on the Market Value of Software Vendors an Empirical
Investigation, Feb. 2005.

[19] The FreeBSD Project. FreeBSD: Information Handling Policies. http:
//security.freebsd.org/.


Click to View FlipBook Version