pci and vulnerability assessments - what’s missing?
TRANSCRIPT
© 2015 Black Duck Software, Inc. All Rights Reserved.
PCI & VULNERABILITY ASSESSMENTS
WHAT’S MISSING?
2 CONFIDENTIAL
REGULATORY LANDSCAPE IS EXPANDING AND
OVERLAPPING
Increasing regulatory scrutiny
• Force of law and penalties
• Expanding and overlapping
Common Goals
• Focus on protecting
sensitive information
• Documented
responsibilities and
processes
• Require visibility to risks
(e.g. vulnerability
assessments)
GLBA
Sarbanes - Oxley
3 CONFIDENTIAL
WHERE DO RISKS APPEAR?
PCI-DSS
Build and Maintain a Secure Network and Systems • Requirement 1 – Configure firewalls and routers to protect against unauthorized access to cardholder data
• Requirement 2 – Don’t use vendor supplied default passwords and configurations
Protect Cardholder Data • Requirement 3: Protect stored cardholder data, and don’t store what you don’t need
• Requirement 4: Use strong crypto and protocols
Maintain a Vulnerability Management Program • Requirement 5: Use anti-virus
• Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures • Requirement 7: Limit access on a need-to-know basis
• Requirement 8: Use and maintain identity management tools correctly
• Requirement 9: Physical security
Regularly Monitor and Test Networks • Requirement 10: Log and audit all activity
• Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy • Requirement 12: Train your people
4 CONFIDENTIAL
Source: The State of Risk-Based Security
Management, Research Study by Ponemon
Institute, 2013
INVESTMENT PRIORITY –
WHERE ARE YOUR “SECURITY RISKS” VS. YOUR “SPEND”
MANY CLIENTS DO NOT PRIORITIZE APPLICATION SECURITY IN THEIR ENVIRONMENTS
35%
30%
25%
20%
15%
10%
5%
APPLICATION
LAYER
DATA
LAYER
NETWORK
LAYER
HUMAN
LAYER
HOST
LAYER
PHYSICAL
LAYER
SECURITY RISK
SPENDING
SPENDING DOES
NOT EQUAL RISK
Source: The State of Risk-Based Security Management, Research Study by Ponemon Institute, 2013
5 CONFIDENTIAL
MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM
• Requires identification of
vulnerabilities in custom
code and all installed
software
• Requires independent risk
rating of vulnerabilities
• Requires monitoring for new
vulnerabilities, and applying
patches as available
6.2 Ensure that all system components and software are
protected from known vulnerabilities by installing applicable
vendor-supplied security patches. Install critical security
patches within one month of release.
<snip>
This requirement applies to applicable patches for all
installed software.
<snip>
Without the inclusion of security during the requirements
definition, design, analysis, and testing phases of software
development, security vulnerabilities can be inadvertently or
maliciously introduced into the production environment.
6.3.2 Review custom code prior to release to production or
customers in order to identify any potential coding
vulnerability…
6.1 Establish a process to identify security vulnerabilities, using
reputable outside sources for security vulnerability
information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
<snip>
This is not achieved by an ASV scan or internal vulnerability
scan, rather this requires a process to actively monitor industry
sources for vulnerability information.
6 CONFIDENTIAL
REGULARLY MONITOR AND TEST NETWORKS
Vulnerability assessments • Quarterly requirement
• Ad hoc internal assessments
• “Continuous monitoring” (daily scans)
Vulnerability assessment (VA) tools focus on • Network security
• System configurations
• Operating systems (including Linux)
• Commercial applications (Office, Adobe, Oracle, etc.)
PCI-DSS 11.2
“Run internal and external network vulnerability scans at least quarterly and
after any significant change in the network
(such as new system component
installations, changes in network topology,
firewall rule modifications, product
upgrades).”
8 CONFIDENTIAL
WHAT’S MISSING?
1 – VA tools don’t know about your custom applications
• No visibility to open source you use, or to
vulnerabilities in those components
2 – VA tools provide a point in time snapshot • They must scan your entire system and applications for each new
update or vulnerability
• Do not maintain an inventory of your applications
• Each new issue must be searched for independently
9 © 2015 Black Duck Software, Inc. All Rights Reserved.
VULNERABILITY MANAGEMENT
PROGRAMS IN THE AGE OF
OPEN SOURCE
10 CONFIDENTIAL
OPEN SOURCE IS CHANGING THE WORLD
By 2016, Open Source Software will be included
in mission-critical
applications within 99%
of Global 2000
enterprises.
0,0
0,5
1,0
1,5
2,0
2007 2009 2011 2013 2015
millions
Growth of open source
projects is accelerating.
Will face problems because
of no policy.
50%
11 CONFIDENTIAL
OPEN SOURCE DEVELOPMENT CONTINUES TO GROW
Open Source is growing in use
• Needed functionality w/o acquisition
costs
• Faster time to market
• Lower development costs
• Support from broad communities
Black Duck On Demand results
• >98% of applications tested used open
source projects
• 95% of reviews find unknown open
source
• On average, clients were aware of < 50%
of the open source used
Custom Code
Open Source
12 CONFIDENTIAL
HOW ARE VULNERABILITIES FOUND AND
DISCLOSED?
Over 6,000 new vulnerabilities in open source since 2014 Over 76,000 total vulnerabilities in NVD, only 63 reference automated tools • 50 of those are for
vulnerabilities reported in the tools
• 13 are for vulnerabilities that could be identified by a fuzzer
0
200
400
600
800
1.000
1.200
2010
- A
pr
2010
- D
ec
2010
- J
an
2010
- J
un
2010
- M
ay
2010
- O
ct
2011
- A
pr
2011
- D
ec
2011
- J
an
2011
- J
un
2011
- M
ay
2011
- O
ct
2012
- A
pr
2012
- D
ec
2012
- J
an
2012
- J
un
2012
- M
ay
2012
- O
ct
2013
- A
pr
2013
- D
ec
2013
- J
an
2013
- J
un
2013
- M
ay
2013
- O
ct
2014
- A
pr
2014
- D
ec
2014
- J
an
2014
- J
un
2014
- M
ay
2014
- O
ct
2015
- A
pr
2015
- D
ec
2015
- J
an
2015
- J
un
2015
- M
ay
2015
- O
ct
2016
- A
pr
2016
- J
an
NVD Open Source Vulnerability Disclosures by Month
Heartbleed
Disclosure
13 CONFIDENTIAL
WE HAVE LITTLE CONTROL OVER HOW OPEN
SOURCE ENTERS THE CODE BASE
Open Source
Community
Internally
Developed
Code
Outsourced
Code
Legacy
Code
Reused Code
Supply
Chain
Code
Third
Party
Code
Delivered Code
Open source code introduced
i a y ways…
…a d absorbed i to final code.
14 CONFIDENTIAL
OPEN SOURCE: EASY TARGETS
Used everywhere Easy access to code
Vulnerabilities are
publicized
Exploits readily available
15 CONFIDENTIAL
WHO’S RESPONSIBLE FOR SECURITY?
Commercial Code Open Source Code
• Dedicated security researchers
• Alerting and notification infrastructure
• Regular patch updates
• Dedicated support team with SLA
• “community”-based code analysis
• Monitor newsfeeds yourself
• No standard patching mechanism
• Ultimately, you are responsible
17 CONFIDENTIAL
WHAT IF THE AUTOMOTIVE MARKET TREATED
RECALLS LIKE THE OPEN SOURCE MARKET?
Known and Quantified Known and Unquantified
18 CONFIDENTIAL
A SOFTWARE BILL OF MATERIALS SOLVES THE
PROBLEM
• Components and serial numbers
• Unique to each vehicle VIN
• Complete analysis of open source components*
• Unique to each project or application
• Security, license, and operational risk surfaced
19 CONFIDENTIAL
HOW ARE COMPANIES ADDRESSING THIS TODAY?
NOT WELL.
Manual tabulation
• Architectural Review Board
• End of SDLC • High effort and low accuracy
• No controls
Spreadsheet-based inventory
• Dependent on developer best
effort or memory • Difficult maintenance
• Not source of truth
Tracking vulnerabilities
• No single responsible entity
• Manual effort and labor intensive • Unmanageable (11/day)
• Match applications, versions,
components, vulnerabilities
Vulnerability detection
• Run monthly/quarterly
vulnerability assessment
tools (e.g., Nessus, Nexpose)
against all applications to
identify exploitable instances
20 CONFIDENTIAL
A SOLUTION TO SOLVING THIS PROBLEM WOULD
INCLUDE THESE COMPONENTS
Choose Open
Source
Inventory
Open Source
Map Existing
Vulnerabilities Track New
Vulnerabilities
Maintain accurate list of
open source
components throughout
the SDL
Identify
vulnerabilities during
development Alert on new
vulnerabilities and
map to applications
Proactively choose
secure, supported
open source
GUIDE VERIFY/ENFORCE MONITOR
21 CONFIDENTIAL
WHAT CAN YOU DO TOMORROW?
Speak with your head of application
development and find out:
• What policies exist?
• Is there a list of components?
• How are they creating the list?
• What controls do they have to ensure
nothing gets through?
• How are they tracking vulnerabilities
for all components over time?
24 CONFIDENTIAL
7 of the top 10 Software companies,
and 44 of the top 100
6 of the top 8 Mobile handset vendors
6 of the top 10 Investment Banks
24 Countries
230 Employees
1,600 Customers
27 of the Fortune 100
ABOUT BLACK DUCK
Award for
Innovation Four Years in the “Software
500” Largest Software Companies
Six Years in a row
for Innovation
Gartner Group
“Cool Vendor” “Top Place to Work,” The Boston Globe
2014