pci and vulnerability assessments - what’s missing
TRANSCRIPT
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)
Regulatory Landscape is Expanding and Overlapping
GLBA Sarbanes - Oxley
Is This a Network Security Problem?
Perimeter Defense
• Since the PII is stored in a database, initial focus was on network security
• Firewalls, virus scan and good network configuration keep us secure
• Encryption of data at rest
Approach Matches Industry ”Spend” v. Actual Risk
MANY CLIENTS DO NOT PRIORITIZE APPLICATION SECURITY IN THEIR ENVIRONMENTS
35%
30%
25%
20%
15%
10%
5%
APPLICATIONLAYER
DATALAYER
NETWORKLAYER
HUMANLAYER
HOSTLAYER
PHYSICALLAYER
SECURITY RISK
SPENDINGSPENDING DOES NOT EQUAL RISK
Source: The State of Risk-Based Security Management, Research Study by Ponemon Institute, 2013
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
Where Does Application Security Apply?
Requires independent risk rating of vulnerabilities
Requires monitoring for new vulnerabilities, and applying patches as available
Maintain a Vulnerability Management Program
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.
• Requires security patches for critical vulnerabilities to be implemented within 30 days of release (disclosure)
• Requires identification of vulnerabilities in custom code and all installed software
• Requires review of custom code to identify vulnerabilities
Maintain a Vulnerability Management Program 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.
6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability…
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.
Regularly Monitor and Test Networks
Vulnerability assessments • Quarterly requirement• Ad hoc internal assessments• “Continuous monitoring” (daily scans)
Vulnerability assessment (VA) tools focus on: • 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).”
What’s Missing?
1 – VA tools provide no visibility to custom applications• Focus on commercial products and OSS applications• No visibility to open source components you use• No visibility to vulnerabilities in those components
2 – VA tools are reactive• You 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
How Well Do VA Tools Cover Open Source?
2015 - 3,000 vulnerabilities disclosed in open sourceNessus 2015 - Roughly 500 plug-ins generatedFocus on major components and OS
• 34 rules for Poodle
• 14 for Freak• 205 for Linux• 35 for Red Hat• 42 for SuSE
• 25 for Ubuntu• 33 for Fedora• 28 for Debian• 14 for CentOS• 11 for Mandriva
What if the Automotive Market Treated Recalls Like Open Source Users Treat Vulnerabilities?
Known and Quantified Known and Unquantified
Automotive• Regimented processes (JIT)• Specificity in roles• QA at each step
Software• Developer independence• Broader functional roles• QA for builds
How Is Software “Manufacturing” Different?
OpenSourceCommunity
InternallyDeveloped
Code
OutsourcedCode
LegacyCode
ReusedCode
SupplyChainCode
ThirdPartyCode
DeliveredCode
Opensourcecodeintroduced inmanyways…
…andabsorbedintofinalcode.
Automotive• Faulty part is disclosed• Recall is issued• OEM notify specific vehicle owners
Software• Vulnerable component is disclosed• Some users learn of vulnerability• Hilarity ensues
How Is “Incident Response” Different?
Who’s Responsible for Monitoring Component 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
Is This a Big Deal?
Over 7,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
-Fe
b
2010
-Ju
n
2010
-N
ov
2011
-A
pr
2011
-Fe
b
2011
-Ju
n
2011
-N
ov
2012
-A
pr
2012
-Fe
b
2012
-Ju
n
2012
-N
ov
2013
-A
pr
2013
-Fe
b
2013
-Ju
n
2013
-N
ov
2014
-A
pr
2014
-Fe
b
2014
-Ju
n
2014
-N
ov
2015
-A
pr
2015
-Fe
b
2015
-Ju
n
2015
-N
ov
2016
-A
pr
2016
-M
ar
NVDOpen Source Vulnerability Disclosures by
Month
Heartbleed Disclosure
Open Source: Attackers Have Quotas Too
Easy access to code
Vulnerabilities are publicized Exploits readily available
Used everywhere
A Software Bill of Materials Solves the Problem
• Componentsandserialnumbers• UniquetoeachvehicleVIN
• Completeanalysisofopensourcecomponents*• Uniquetoeachprojectorapplication• Security,license,andoperationalrisksurfaced
Continuous Monitoring for New Issues
Monitoring of risk to in-scope, production systems• New vulnerabilities not detected by VA tools• Monitoring for risk in custom applications• Does not require re-scanning
Key Takeaways
PCI (and most regulatory standards) covers “all installed software”
Vulnerability Assessment tools are valuable, but• Don’t cover custom software• Don’t maintain knowledge of components
You Bill of Materials solves the issue of visibility, but updating the components remains a requirement