edgescan 2014 vulnerability stats report december 2014 owasp version)

edgescan™ 2014 Vulnerability Stats Report

Eoin KearyCTO with BCC Risk Advisorywww.bccriskadvisory.com

OWASP Global Board Member & Global Vice Chair

OWASP Testing GuideOWASP Code Review GuideOWASP Irish chapter founderOWASP SAMM

Application Developer & Application Security: 14 Years

Rahim JinaDirector with BCC Risk Advisorywww.bccriskadvisory.com

OWASP Leader

OWASP Code Review GuideOWASP Ex-Irish chapter leaderOWASP SAMM

Application Security &Application Developer : 9 Years

Why“You cant measure what you cant improve”

What is most effective at reducing Risk?

What is the major Root Cause?

Are most Risks at the Application layer?

Are most Risks at the Server Layer*?

Quick wins to be more secure?

Average time to fix a high risk?

What does improvement look like?

* “Server Layer” is also software!!

How?

edgescan analytics and metrics

Track improvement

Delta Analysis

Continuous/Unlimited Assessments

Layer 7 and below – WebApps and Servers

Manual Verification of all discovered vulnerabilities

Sample Space

The vulnerability statistics shown are the result of the last 12 months (November 2014): • Assessing 000’s of web applications and

hosting environments across the globe (assets)

• Various industry verticals from media to finance to software development to pharmaceuticals and medical research.

2014 - year in review

• Many large breaches:

“Cyberdemics” – (another word to hate!!)

Security by Numbers

⅓• The most common root cause of vulnerabilities – poor patching /

maintenance!!

FULL-STACK!

• 34% of the vulnerabilities could have been avoided• This included many vulnerability types:

– SQLI, CMDI, BuffOverFl, XSS, PrivEscl, DoS– Over 20% of the vulnerabilities were Critical

• Patching vulnerabilities were in relation to both operating system and software frameworks such as:

• OpenSSL, PHP, Spring, Struts, Apache Server, MySQL, Linux, Windows etc

The Year of Crappy Crypto – 2014

• The most common vulnerability on hosting servers (Layer 6 and below) was in relation to SSL/Crypto, protection of data in transit.

CVE-2014-3568CVE-2014-3567CVE-2014-3513CVE-2014-3566CVE-2014-3511CVE-2014-5139CVE-2014-3512CVE-2014-3510CVE-2014-3509CVE-2014-3508

1 in 10

• 10% of all vulnerabilities discovered in 2014 are deemed high/critical risk.

– Easily exploitable– Remote– #PCIFail– Application and Network Layers combined.

WebApps• 59% of the vulnerabilities discovered are application layer

– Mobile– Sites– Web applications– Web services

Old Reliable

• The king of application layer vulnerabilities is our dear old friend Cross-Site-Scripting (XSS) with every application assessed by edgescan having an average XSS density of 2.4 per application.

The Most vulnerable application had

220 instances of XSS

Lets Talk about XSS

Afraid of Needles?

• A surprising metric from 2014 – frequency of occurrence Remote code Execution,

SQL Injection, Buffer Overflow, Command Injection vulnerabilities discovered.

– On average: for every 2 assets (applications or hosting servers) assessed 1 such vulnerability was discovered.

HTTP Security Headers

• Lack of Security headers is interesting given how easy they are to implement.

• Circa 16% of application layer vulnerabilities discovered (including some SSL issues) could have been mitigated / risk reduced by using HTTP Security headers.

• Only 1% of HTTP systems assessed by edgescan had at least one HTTP Security header.

Remember – Headers, Headers, remember

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

WHAT ARE HTTP RESPONSE HEADERS?

HTTP headers are components of the message header of HTTP Responses.

HTTP headers define different aspects of an HTTP transaction.

HTTP headers are colon-separated name-value pairs in clear-text string format, terminated by a carriage return (\r) and line feed (\n) character sequence.

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

HTTP RESPONSE SECURITYHEADERS SUMMARY

X-Frame-OptionsX-Xss-ProtectionX-Content-Type-Options Content Security PolicyAccess-Control-Allow-OriginHTTPS Strict Transport

SecurityCache-Control / Pragma

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

HTTP RESPONSE SECURITY HEADERSX-Frame-Options Set to "SAMEORIGIN" to allow framing on same

domain. Set to "DENY" to deny framing at all Set to "ALLOWALL" if you want to allow framing for all

websiteX-XSS-Protection Set to "1; mode=block" to use XSS Auditor and block

page if XSS attack is detected. Set to "0;" if you want to switch XSS Auditor off. This

is useful if response contents scripts from request parameters

X-Content-Type-Options

Set to "nosniff" to stop the browser from guessing the MIME type of a file.

X-Content-Security-Policy

A powerful mechanism for controlling which sites certain content types can be loaded from

Access-Control-Allow-Origin

Used to control which sites are allowed to bypass same origin policies and send cross-origin requests.

Strict-Transport-Security

Used to control if the browser is allowed to only access a site over a secure connection

Cache-Control Used to control mandatory content caching rules

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

HTTP RESPONSE HEADER:X-Frame-Options

Protects you from most classes of Clickjacking

X-Frame-Options: DENYX-Frame-Options:

SAMEORIGINX-Frame-Options: ALLOW

FROM example.com

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

HTTP RESPONSE HEADER:X-Xss-Protection

X-Xss-Protection: 0;

Use the browser’s built-in XSS auditor:

X-Xss-Protection: 1; mode=block

Disable the browser’s built-in XSS auditor:

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

CONTENT SECURITY POLICY

Move all inline script and style into separate files

Add the X-Content-Security-Policy response header to instruct the browser that CSP is in use

Define a policy for the site regarding loading of content Anti-XSS W3C standard

http://www.w3.org/TR/CSP/

CSP Support Statisticshttp://caniuse.com/

#feat=contentsecuritypolicy

CSP Example Usagehttp://content-security-policy.com/

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved. 2424

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

HTTP RESPONSE HEADER:Strict-Transport-Security

Forces your browser to always use HTTPS

Strict-transport-security: max-age=10000000; includeSubdomains

Base case:

Strict-transport-security: max-age=10000000

Do all of your subdomains support SSL?

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

DISABLING THE BROWSER CACHE

Add the following as part of your HTTP Response:

Cache-Control: no-store, no-cache, must-revalidateExpires: -1

Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.

APPLY ALL THE HEADERS!

strict-transport-security: max-age=631138519\r\nversion: HTTP/1.1\r\nx-frame-options: SAMEORIGIN\r\nx-gitsha: d814fdf74482e7b82c1d9f0344a59dd1d6a700a6\r\nx-rack-cache: miss\r\nx-request-id: 746d48ca76dc0766ac24e74fa905be11\r\nx-runtime: 0.023473\r\nx-ua-compatible: IE=Edge,chrome=1\r\nx-webkit-csp-report-only: default-src 'none'; script-src 'self'; connect-src 'self';

img-src 'self'; style-src 'self’\r\ncontent-security-policy-report-only: default-src 'none'; script-src 'self';

connect-src 'self'; img-src 'self'; style-src 'self’\r\nx-content-security-policy-report-only: default-src 'none'; script-src 'self';

connect-src 'self'; img-src 'self'; style-src 'self’\r\n

Continuous Threat

• continuous assessment• continuous maintenance• continuous patching• continuous monitoringOR• continuous #FAIL

Conclusion

• There will always be bugs!• Full-Stack Patching! (not just OS)• 2014 – “Crypto’mageddon” --- • Metrics• Security needs to be more than point-in-time• Vuln Management is one (large) piece of the

puzzle

www.bccriskadvisory.com

© BCC Risk Advisory Ltd 2014. All rights reserved.

Thanks

eoin@bccriskadvisory.comrahim@bccriskadvisory.com

edgescan™ 2014 Vulnerability Stats Report:

http://www.bccriskadvisory.com/wp-content/uploads/Edgescan-Stats-Report.pdf