www.counciltoreduceknowncybervulnerabilities.org
[email protected]
An Exploration of Strategies to
Mitigate Cyber Risk
at
#ThreatMarket and DarkNetLab
September 27, 2016
Thank you for your time
A Call For Change…
This is a story (series of interviews) published on PBS discussing the growing issue of
known software vulnerabilities
http://www.pbs.org/wgbh/pages/frontline/shows/cyberwar/vulnerable/software.html
Published April 24, 2003 (Yes, 12+ years ago !)
Just to be clear, to include a Known
Vulnerability in Code:
You must
ignore the
fixed
component
and use the
vulnerable
one instead.
10 Vulnerabilities Account For Nearly
97% Of All Exploits
Of known
vulnerabilities 8
out of 10 are
over 12 years
old !!!
“Advanced Persistent Threat”
From the 2014 Verizon
report: "Ten CVEs
account for almost
97% of the exploits
observed.”
From the 2015 Verizon
Report: “97 percent
of breaches came
from known
vulnerabilities.”
By Scott Robichaux: Manages the ExxonMobil Information
Technology Cyber Security Center of Expertise
"3. Encourage improvements in all technologies to ensure security is thoughtfully built
into vendor provided products from the beginning and managed throughout the entire
product lifecycle.
a. Products should be fully tested for vulnerabilities by independent experts. It should
be completely unacceptable for a product to enter the industrial environment that
contains known vulnerabilities. Such cases result in unnecessary resources expended in
efforts to mitigate these vulnerabilities after-the-fact.
b. Vulnerabilities should be required to be quickly patched when public safety is at
stake. When new vulnerabilities are discovered, patch development and delivery
should be given a high priority and rapidly deployed. Products should include
processes to perform regular patches to address newly discovered vulnerabilities.”
"I’m Scott Robichaux and I manage the ExxonMobil Information Technology Cyber Security Center of Expertise. My teamis composed
of information security experts around the globe, responsible for Incident Management, Investigation, Threat Intelligence, User
Awareness and Vulnerability Testing regarding Cyber security across the IT environment.”
page 34 for quote:
http://www.nist.gov/cybercommission/upload/July14_Panelist_Statements.pdf
Unique Vulnerabilities Graph Over
Time
• Huge increase in
number of
vulnerabilities
entering NIST CVE
database in the
last 3 years
• Massive spike
since 2013 for
common
software
components
(such as Java,
OpenSSL)
Vulnerabilities in
package combination of
increase in discovered
vulnerabilities and
addition of new
features
Over 1000% increase in
CVEs between 2012
Version Releases
release and 2014
release
Increase In malware attacks On
Industrial Control Systems
3500%
3000%
2866%
2500%
2000%
1500%
1000%
704%
500%
100%
0%
2012
2013
2014
source: Kaspersky Labs
9
1200
As of 2015-02-15 total of 1094 unique CVEs
Graph Of Vulnerabilities In
Affected this software via now 30 vulnerable
Hospital Monitoring System Over Time components. That is about 0.8 new CVEs / day .
1000
Newest component on software
was compiled in Nov 2012. This indicates
That it was released with at least 509
unique CVEs affecting 24 components
around end of 2012 or early 2013.
800
600
400
200
0
3/15/2002
Oldest compiled component
on the software image was from
Dec 2001
3/15/2003
3/15/2004
3/15/2005
3/15/2006
3/15/2007
3/15/2008
3/15/2009
3/15/2010
3/15/2011
3/15/2012
3/15/2013
3/15/2014
Code decay over time – router
800
Product
Released / compiled
( 2014-01-17)
289 new unique
CVEs affecting the
product during first
12 months of operations
(approx 0.78 new CVEs per day
during first 6 months)
700
600
48 new unique
CVEs affecting the
product 12
months before
release
500
Date of the oldest
component found in the
software (2009-01-13)
400
300
600% Increase In Unique
Vulnerabilities Discovered In Last
Year
200
689 unique
CVEs as of
2015-01-26
Released with
total of
400 unique
CVEs
100
12/31/2014
10/31/2014
8/31/2014
6/30/2014
4/30/2014
2/28/2014
12/31/2013
10/31/2013
8/31/2013
6/30/2013
4/30/2013
2/28/2013
12/31/2012
10/31/2012
8/31/2012
6/30/2012
4/30/2012
2/29/2012
12/31/2011
10/31/2011
8/31/2011
6/30/2011
4/30/2011
2/28/2011
12/31/2010
8/31/2010
10/31/2010
6/30/2010
4/30/2010
2/28/2010
12/31/2009
8/31/2009
10/31/2009
6/30/2009
4/30/2009
2/28/2009
12/28/2008
8/28/2008
10/28/2008
6/28/2008
4/28/2008
2/28/2008
0
SMART TV SET
700
Last firmware / SW update:
Mar 2013 (*Approx. 178 unique CVEs
affecting product at the
moment of SW EoL)
600
Today. March 1, 2015.
584 unique CVEs in 23
components
500
300
2012 Smart TV lineup
launched:
Nov/Dec 2011
200
One year product cycle
100
Estimated
2065 CVEs
affecting Product
by Nov 2022 based
on historic 0.58 CWEs
per day
One year standard
warranty for parts
and labor from the
date of purchase
Approx. 0.58 new CVEs / day
over the course of 23 months
Nov 2014: security update to
patch curl, openssl, flash_player,
ffmpeg , libpng and freetype
400
Nov 2022. End of 100.000 hours
average lifespan of LCD TV screen.
7 more years of expected
operation of the LCD TV
( based on 100,000 hours average lifespan )
0
(* date may not be fully accurate, as e.g. partial OTA updates may have been delivered after this date as well ( see sec. update on Nov 2014)
11/1/2022
7 years
Information Workflow
FED Database
(420 Known Vulnerabilities)
The
Cloud
HIE Database
(420 Known Vulnerabilities)
Hospital
Bank (HSC)
EHR Database
(420 Known Vulnerabilities)
Customer Database
(420 Known
Vulnerabilities)
Backup Server
(30 Known Vulnerabilities)
Patient Monitoring System
(1580 Known Vulnerabilities)
Cash
Router/Firewall
(689 Known
Vulnerabilities)
Infusion Pump
(41 Known Vulnerabilities)
Patient
Router/Firewall
(689 Known
Vulnerabilities)
Data Analysis System
(231 Known Vulnerabilities)
ATTACKER WORKFLOW
I’m Mad as Hell
“It is not rational behavior
that businesses buy a
defective piece of
software, transfer all legal
risk of failure to itself
through a EULA, then try
to insure itself against the
risks of defects in a
product they did not
build, but rely on.”
Manufactures Blame the Pilots,
Pilots Blame the Plane,
Public is Confused
Post NTSB
After Chicago Burned Down
the First Time
The city had a fire
alarm on every block,
many, many fire
stations and fire men.
Fire alarms were
sounded in time,
firemen arrived
quickly.
It made no difference.
China Took the Crown Jewels
Does Industry Get a Gold Star if
they have No Vulnerabilities?
Car Safety for Crash Test Dummies
“Insurance Institute for Highway
Safety and the Highway Loss Data
Institute were formed in response to
demand by the public about the
safety of every make and model of
car sold in the United States. The
fact that every vehicle sold has a
safety test rating, which is
based on repeated tests and
scientific data, contributes greatly
to the improving safety of every
vehicle.” (Emphasis added.)
Letter to the National Association of Insurance Commissioners
from the Council to Reduce Known Cyber Vulnerabilities, March
23, 2015
There are No Crash Test Dummies
No industry
tells consumers
which software
is the safest and
most secure.
It’s the Vendors, Stupid: Known Vulnerabilities
Must be Stopped at the Headwaters
Where have all the cowboys gone?
They just said:
No.
Enhanced Mayo Procurement
Language
Call it the Regulatory EULA: Federal Regulators are
holding banks responsible and they need an industry
standard.
Financial Services Sector Coordinating Council for
Critical Infrastructure and Homeland Security
published the “Mayo” Procurement language.
Key Parts of the Enhanced Mayo
Procurement Language
• Communication
Robustness – Fuzz Testing
• Code Analysis (CWE Top
25, OWASP Top 10)
• Static Source Code
Analysis (CVEs, Known
vulnerabilities)
• Dynamic Runtime
Analysis
• Penetration
• Known Malware Analysis
• Bill of Materials
Key Parts of the Enhanced Mayo
Procurement Language
• Validation of
security measures
designed into the
device
Key Parts of the Enhanced Mayo
Procurement Language - Governance
Business relationships
between entities that have
electronic access to the
others systems should define
their relationship and
responsibilities, to create
accountability and
responsibilities for each
party, as well as limit liability
via written agreements.
Key Parts of the Enhanced Mayo
Procurement Language
Further, such
relationships should agree
upon a defined level of
cyber security for them all,
and a trusted third party
to inspect and audit each
connected entity for the
good of all contracted and
connected parties.
Mayo Demands a Software Ingredient List
(Bill of Materials)
Simply knowing software “ingredients” or “code
genetics” arms a user with an enormous resource for
determining risk.
Procurement Language:
Setting Expectations In The Supply Chain
Supply Chain Cyber Assurance – Supplier Requirements
• Give the supplier a list
of cyber security
requirements to follow
• Verify that what is
delivered meets the
requirements
• This needs to be
achievable, consistent,
and based on standards
• Must be a continual
work in progress that is
flexible enough to
change over time.
Introduction
This document serves as a minimal set of requirements for any supplier providing network-connectable
software, systems, or devices as part of a contractual bid to Fiat Chrysler Automobiles (hereinafter
referred to as FCA). A description of the required methods by which features and functions of networkconnectable devices are expected to be evaluated at the product level and tested for known
vulnerabilities and software security weaknesses while also establishing a minimum set of verification
activities intended to reduce the likelihood of exploitable weaknesses that could be vectors of zero-day
exploits that may affect the device are articulated throughout this document. While this document
serves as a minimal set of requirements, FCA expects that suppliers will remain conscious of the dynamic
nature of cybersecurity and provide incremental improvements as needed, which FCA shall consider for
inclusion in future versions of this document. Suppliers shall be required to provide FCA with any and all
requested artifacts as evidence that the supplier is in compliance with stated requirements.
Scope
These requirements applies to (but is not limited to) the following :
Application software
Embedded software
Firmware
Drivers
Middleware
Operating Systems
The requirements in this document are derived from various industry standards, guidelines, and other
documents including, but not limited to:
IEC 62443
ISO 27001
NIST SP 800-53
NIST SP 800-82
DHS Cyber Security Procurement Language for Control Systems
ISA EDSA
FIPS 140-2
Common Criteria Smartcard IC Platform Protection Profile
Mayo Clinic Technology and Security Requirements Procurement Language
UL 2900
The requirements in this document apply to devices, software or software services that will be referred
to as “product” throughout this document. The product can be connected to a network (public or private)
and may be used as part of a system. These requirements are applicable to products that contain Do we
really need to have this here
American Banking Associon (ABA) and FSSCC Cyber Insurance
Purchasing Guide
• Regulators now hold banks and
FIs accountable for third party
cyber failure.
– Regulators and Financial
Institutions (Fis) have no
mechanism to manage or
measure third party cyber risk.
– This procurement language
creates such a mechanism for
both regulators and banks.
• Procurement language helps them
be better manage risk.
Underwriters Laboratory Cyber
Assurance Program (CAP)
This is historically significant.
This has historic precedence.
This is politically relevant.
This has the promise to inform
consumers.
• This has the promise to create
insurance policies based on
frequency and severity
underwriting data.
• This will force change on the
software industry.
•
•
•
•
US DHS CIO Enterprise Services reported:
33
• 92% of vulnerabilities are in application layer not in networks
(NIST)
• Over 70 % of security breaches happen at the Application
(Gartner)
• Insufficient Application Security testing
– Often only done at the end of all development; security is
often, at best, ‘bolted on’ not ‘built in’
– Most developers lack sufficient security training
• If only 50% of software vulnerabilities were removed prior to
production, costs would be reduced by 75 % (Gartner)
• Data breaches exploit vulnerabilities in applications with root
causes in unsecure software
Source: US Department of Homeland Security “CARWASH” program
presentation to interagency Software & Supply Chain Assurance Forum,
Dec 2014
Expectations for 2016
• Major breaches will be enabled by unpatched
known vulnerabilities over 2 years old;
• Many vulnerabilities will be exploited in devices
and systems that cannot be patched;
• Most software will be composed third party & open
source (often unchecked) components;
o Primary causes of exploited vulnerabilities will be known software defects,
bugs, & logic flaws;
o Application logic errors will become more frequent and critical;
• Mobile apps will constitute a growing source of
attack vectors, especially since many (in rush to
release) won’t be adequately tested for known
vulnerabilities prior to use;
Get the Op-Ed Version of this Deck
Google: “new
cyber narrative”
and my article
in The Hill will
be the first
search result.
Act in Your Own Self Interest
“It is not rational behavior
that businesses buy a
defective piece of software,
transfer all legal risk of
failure to itself through a
EULA, then try to insure
itself against the risks of
defects in a product they
did not build, but rely
on.”
www.counciltoreduceknowncybervulnerabilities.org
[email protected]