Web security – application security roads to software security nirvana iisf version
Download as PPTX, PDF0 likes10,204 views
The document discusses the critical issues in application security and the growing impact of cybercrime on businesses, highlighting significant financial losses and the increasing sophistication of attacks. It emphasizes the inadequacies of traditional penetration testing and the necessity for continuous security assessments, better risk management, and prioritization of vulnerabilities in the software development lifecycle. Additionally, it advocates for clear communication of security concepts to developers to enhance understanding and security practices.
![We know they are bad for us, but who cares, right?
If we eat too many we may get a heart attack? …sound familiar
We also write [in]secure code until we get hacked
The Cheeseburger approach: “Cheeseburger risk’ is the kind of risk you
deliberately take even knowing the consequences, until those consequences
actually come to pass.”
Cheeseburger Security](https://image.slidesharecdn.com/websecurityapplicationsecurityroadstosoftwaresecuritynirvana-iisfversion-160105161840/85/Web-security-application-security-roads-to-software-security-nirvana-iisf-version-15-320.jpg)
![XSS causes the browser to execute user
supplied input as code. The input breaks out of
the "Data" context and becomes execution
context.
SQLI causes the database or source code
calling the database to confuse data [context]
and ANSI SQL [ execution context].
Command injection mixes up data [context]
and the command [context].](https://image.slidesharecdn.com/websecurityapplicationsecurityroadstosoftwaresecuritynirvana-iisfversion-160105161840/85/Web-security-application-security-roads-to-software-security-nirvana-iisf-version-39-320.jpg)
Web security – application security roads to software security nirvana iisf version
- 1. Application Security: Roads to Software Security Nirvana
- 2. Eoin Keary • CTO BCCRISKADVISORY.COM • OWASP GLOBAL BOARD MEMBER • edgescan.com
- 4. 4© 2012 WhiteHat Security, Inc. HACKED
- 5. “(Cyber crime is the) second cause of economic crime experienced by the financial services sector” – PwC 2012 Cyber Crime • US $20.7 billion in direct losses • Global $110 billion in direct losses • Global $338 billion + downtime “556 million adults across the world have first-hand experience of cybercrime -- more than the entire population of the European Union.” Globally, every second, 18 adults become victims of cybercrime - Symantec “The loss of industrial information and intellectual property through cyber espionage constitutes the greatest transfer of wealth in history” - Keith Alexander Almost 1 trillion USD was spent in 2012 protecting against cybercrime Jimmy, I didn’t click it – My Grandma “One hundred BILLION dollars” - Dr Evil
- 6. Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. -Helen Keller
- 7. Its (not) the $$$$ Information security spend Security incidents (business impact)
- 8. But we are approaching this problem completely wrong and have been for years…..
- 9. Problem # 1 Asymmetric Arms Race
- 10. A traditional end of cycle / Annual penetration testing only gives minimal security…..
- 11. There are too many variables and too little time to ensure “real security”. • Code changes - possible introduction of vulnerabilities • Framework vulnerabilities are discovered all the time • Server/Hosting changes may give rise to a vulnerability • Patching - vulnerability • Logical/Business logic vulnerability - from new features
- 12. An inconvenient truth Two weeks of ethical hacking Ten man-years of development Business Logic Flaws Code Flaws Security Errors
- 13. Attacks Shift Towards Application Layer V
- 14. "Risk comes from not knowing what you're doing." - Warren Buffet
- 15. We know they are bad for us, but who cares, right? If we eat too many we may get a heart attack? …sound familiar We also write [in]secure code until we get hacked The Cheeseburger approach: “Cheeseburger risk’ is the kind of risk you deliberately take even knowing the consequences, until those consequences actually come to pass.” Cheeseburger Security
- 16. In two weeks: Consultant “tune tools” Use multiple tools – verify issues Customize Attack Vectors to technology stack Achieve 80-90 application functionality coverage How experienced is the consultant? Are they as good as the bad guys? They certainly need to be, they only have 2 weeks, right!!? Code may be pushed to live soon after the test. Potential window of Exploitation could be until the next pen test. 6 mths, 9 mths, 1 year? Automated Review A fool with a tool, is still a fool”…..?
- 17. “We need an Onion” SDL – Design review Threat Modeling Code review/SAST Negative use/abuse cases/Fuzzing/DAST Live/Ongoing - Continuous/Frequent monitoring / Testing Manual Validation Vulnerability management & Priority Dependency Management …. We need more than a Penetration test.
- 18. Large Trend towards services based Security & Vulnerability Management All vulnerabilities are not equal: Fixing “the right” vulns not all vulns SDLC integration: Prevent Vs React – Cheese Burger Security
- 19. Security is changing…. From – Securing mission critical assets – Point in time Assessments – Appliances/Software licenses and staff to manage perimeter To – Securing all assets – Frequent scheduled assessment of all assets – SaaS Security – Superior Accuracy. Expert validation. Fatal Flaw: “We only need to “do” security on important sites”
- 20. Make this more difficult: Lets change the application code once a month.
- 21. Continuous Security Assessment Approach time
- 22. Problem # 2 You are what you eat
- 23. Software food chain 23 Application Code COTS (Commercial off the shelf Outsourced development Sub- Contractors Bespoke outsourced development Bespoke Internal development Third Party API’s Third Party Components & Systems Degrees of trust You may not let some of the people who have developed your code into your offices!! More Less
- 24. 2012- Study of 31 popular open source libraries. - 19.8 million (26%) of the library downloads have known vulnerabilities. - Today's applications may use up to 30 or more libraries - 80% of the codebase
- 25. Spring - application development framework : downloaded 18 million times by over 43,000 organizations in the last year. – Vulnerability: Information leakage CVE-2011-2730 http://support.springsource.com/security/cve-2011-2730 In Apache CXF– application framework: 4.2 million downloads.- Vulnerability: high risk CVE- 2010-2076 & CVE 2012-0803 http://svn.apache.org/repos/asf/cxf/trunk/security/CVE-2010-2076.pdf http://cxf.apache.org/cve-2012-0803.html
- 26. Problem # 3 Bite off more than we chew
- 27. How can we manage vulnerabilities on a large scale….
- 29. “We can’t improve what we can’t measure”
- 30. Say 300 web applications: 300 Annual Penetration tests 10’s of different penetration testers? 300 reports How do we consume this Data?
- 31. Enterprise Security Intelligence: Consolidation of vulnerability data. Continuous active monitoring Vulnerability Management solutions
- 32. Metrics: We can measure what problems we have Measure: We cant improve what we cant measure Priority: If we can measure we can prioritise Delta: If we can measure we can detect change Apply: We can apply our (small) budget on the right things Improve: We can improve where it matters…… Value: Demonstrate value to our business Answer the question: “Are we secure?” < a little better?
- 33. Problem # 4 Information flooding (Melting a developers brain, White noise and “compliance”)
- 34. Doing things right != Doing the right things. “Not all bugs/vulnerabilities are equal” (is HttpOnly important if there is no XSS?) Contextualize Risk (is XSS /SQLi always High Risk?) Do developers need to fix everything? - Limited time - Finite Resources - Task Priority - Pass internal audit? White Noise
- 35. Compliance There’s Compliance: EU directive: http://register.consilium.europa.eu/pdf/en/12/st05/st05853. en12.pdf Article 23,24 & 79, - Administrative sanctions “The supervisory authority shall impose a fine up to 250 000 EUR, or in case of an enterprise up to 0.5 % of its annual worldwide turnover, to anyone who, intentionally or negligently does not protect personal data”
- 36. Clear and Present Danger!! …and there’s Compliance
- 37. Problem Explain issues in “Developer speak” (AKA English)
- 38. Is Cross-Site Scripting the same as SQL injection? Both are injection attacks -> code and data being confused by system. LDAP Injection, Command Injection, Log Injection, XSS, SQLI etc etc Think old phone systems, Captain Crunch (John Draper). Signaling data and voice data on same logical connection – Phone Phreaking
- 39. XSS causes the browser to execute user supplied input as code. The input breaks out of the "Data" context and becomes execution context. SQLI causes the database or source code calling the database to confuse data [context] and ANSI SQL [ execution context]. Command injection mixes up data [context] and the command [context].
- 40. So…. We need to understand what we are protecting against. We need to understand that secure applications are in the hands of developers You can only improve what you can measure Not all bugs are created equal. Bugs are Bugs. Explain security issues to developers in “Dev speak”
- 41. www.bccriskadvisory.com © BCC Risk Advisory Ltd 2013 .. All rights reserved. Thanks for Listening @eoinkeary [email protected]