O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

00. introduction to app sec v3

Próximos SlideShares
Reducing Your Attack Surface
Reducing Your Attack Surface
Carregando em…3

Confira estes a seguir

1 de 33 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (16)


Semelhante a 00. introduction to app sec v3 (20)

Mais de Eoin Keary (20)


Mais recentes (20)

00. introduction to app sec v3

  1. 1. Introduction to Application Security Eoin Keary CTO BCC Risk Advisory / edgescan www.edgescan.com
  2. 2. Where are we going? Web Security and HTTP Basics What is Web Application Security? HTTP GET/POST HTTP Security Response Headers Sensitive data in transit stuff More stuff
  3. 3. We Use Network Vulnerability Scanners Neglect the security of the software on the network/web server Today’s State: "Our Website Is Safe" We Have Firewalls and IPS in Place Port 80 & 443 are open for the right reasons We Audit It Once a Quarter with Pen Testers Applications are constantly changing We Use SSL Encryption Only protects data between site and user not the web application itself We Outsource
  4. 4. •Asymmetric Arms Race
  5. 5. • A traditional end of cycle / Annual pentest only gives minimal security….. • There are too many variables and too little time to ensure “real security”.
  6. 6. Two weeks of ethical hacking Ten man-years of development
  7. 7. Make this more difficult: Lets change the application code once a month.
  8. 8. “We need an Onion” SDL Design review Threat Modeling Code review/SAST Pentesting/DAST Live/Ongoing Continuous/Frequent monitoring/Testing Manual Validation Vulnerability management & Priority Dependency Management …. Hungry?
  9. 9. You are what you eat
  10. 10. 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
  11. 11. “We can’t improve what we can’t measure”
  12. 12. Information flooding (Melting a developers brain, White noise and “compliance”)
  13. 13. Doing things right != Doing the right things “Not all bugs/vulnerabilities are equal” 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 Where do we go now?
  14. 14. Ideal world Information security spend Security incidents (business impact)
  15. 15. Real world Information security spend Security incidents (business impact)
  16. 16. Application Vulnerabilities Overview • Application security vulnerabilities can be roughly broken down into 4 categories. • Application Infrastructure • Application infrastructure misconfigured • Data passed between browser and server not secured • Application Controller/Server Tier not coded Securely • Broken Authentication and Session Management • Business object references (identifiers) not properly secured • Failure to Restrict URLs Properly • Unvalidated Redirects and Forwards • Vulnerabilities at the Browser Level • Unvalidated data becomes a script executed on the browser • Logged in user's session is able to be forged • Vulnerabilities at the Persistence Tier • Database access not properly written to use SQL securely • Data not stored in a cryptographically secure way
  17. 17. Developer Security? Developers rarely get application security training in school The protocols we use for web development are insecure The languages we use for web development are insecure The frameworks we use for web development are insecure Developers rarely get prescriptive security requirements at work Developers rarely get good assessment technology to verify if they are writing secure code and applications Recipe for Disaster!
  18. 18. Secure Application Design Principles Practice least privilege Employ secure defaults Validate data from all sources Fail to a secure mode Prevent information leakage Practice defense in depth Secure the weakest link Escape/Encode Applications should execute with the Least Privilege required to perform a job Choose appropriate features for users and ensure that these features are secure Always assume that data from any source is malicious and validate it before use Design applications to fail to a secure state and never disclose confidential data or provide elevated privledges An unintentional revelation of information about the way an application works Use multiple layers of security instead of a single mechanism Secure your application to prevent it from being the "weakest" link Convert data that is used by parsers into non-executing context
  19. 19. Web application security risks Blurring traditional boundaries Organizations are exposing internal data and critical functionality to the public Internet through web application deployments Data privacy Weak security controls may be exploited by skilled attackers to access sensitive information or perform unauthorized activities on your organizations' systems Impact of a security breach Loss of customer confidence and reputational damage via the negative publicity associated with a security breach
  20. 20. Web Application Security Host Apps Firewall Host Apps Database Host Web server App server DB server Securing the application Input validation Session mgmt Authentication Authorization Config mgmt Error handling Secure storage Auditing/logging XSS Defense Securing the network Router Firewall Switch Securing the host Patches/updates Accounts Ports Services Files/directories Registry Protocols Shares Auditing/logging Firewall
  21. 21. ocedure sendBit2(dim b as boolean) if (b) then gpio.2 = 1 delay_us(1125) gpio.2 = 0 delay_us(375) else = 1 delay_us(375) gpio.2 = 0 delay_us(1125) end if end sub sub procedure sendPair(dim b as boolean) t(false) sendBit(b) end sub sub procedure sendPair2(dim b as boolean) sendBit2(false) sendBit2(b) end sub sub procedure switchcode2(dim b as boolean) '// house code 1 = B sendPair2(true) sendPair2(false) sendPair2(false) sendPair2(false) '// unit code 2 sendPair2(true) sendPair2(false) sendPair2(false) sendPair2(false) '// on = 14 sendPair2(false) sendPair2(true) sendPair2(true) sendPair2(b) sendBit2(false) end sub sub procedure switchcode(dim b as boolean) '// house code 1 = B sendPair(true) sendPair(false) sendPair(false) sendPair(false) '// unit code 2 HACKING HACKING HACKING HACKING HACKING HACKING 1. Injection 2. Cross-site scripting 3. Broken authentication/session management 4. Insecure direct object references 5. Cross site request forgery 6. Security misconfiguration 7. Insecure cryptographic storage 8. Failure to restrict URL access 9. Insufficient transport layer security 10. Un-validated redirects and forwards
  22. 22. DYNAMIC LandscapeNEW Challenges
  23. 23. 2010 2015 2020 More DEVICES Than 50 Billion 25 Billion 12.5 Billion CONNECTED DEVICES
  24. 24. PEOPLEEmployees, Contractors Costumers & Partners THE NETWORK IS NO LONGER THE POINT OF CONTROL DEVICESPhones, Servers, Laptops, Tablets DATAUnstructured & Structured THE NEW
  25. 25. • The network has become the battlefield • Forcing defense of the entire network • Low situational awareness on the network • Who, What, When, Why ? • Low awareness increases vulnerability DEFENDS EVERYTHING DEFEND THE CORE
  26. 26. Secure by Default Designed Securely Developed Securely SECURITY SOFTWARE ASSURANCE ASSURANCE IS THE SOLUTION
  27. 27. CRITICAL PATCH Security focused priority Most critical patches first Dynamic schedule Predictable Scheduled a year ahead Quarterly patches Cumulative Incremental Patches
  28. 28. API Security?
  29. 29. Identity and Access Management Device User Service App MW Database OS Virtual Machine Servers Storage End User Level Operator Level Secure data across all tiers of storage Monitor and configure securely Complete Database protection Secure user access to data and transactions Security without a performance penalty. Secure container for applications Security built into the infrastructure Service Level Identity propagation & consistent access policies
  30. 30. DON’T SECURE YOURSELF OUT OF BUSINESS • You can’t defend everything • Assume you are already breached • Protect your most valuable assets • Have a plan and execute the plan
  31. 31. US Interstate Highway System Initial cost vs. maintenance cost http://cdmsmith.com/en-US/Insights/Funding-Future-Mobility/Exit-6- Aging-Interstates.aspx Interstate-related expenditures during the next 50 years will likely reach $2.5 trillion. The interstate system is anything but “paid for" - http:/cdmsmith.com
  32. 32. Gratuitous slide to distract you so you can blame your insecure code on me Baseball + Bat = $1.10 How much is the Bat if it costs $1.00 more than the ball?
  33. 33. Answer: • Although $1.00 + $0.10 does equal $1.10 • $1.00 – $0.10 you get $0.90, • The problem requires that the bat costs $1 more than the ball.1 • The ball must cost $0.05, and the bat must cost $1.05 since $1.105 + $0.05 = $1.10 33

Notas do Editor

  • 1
  • Every company and customer that we meet tells us the same story. You might agree that this is where you are…you’ve invested a lot of money in your firewalls and network vulnerability scanners and you’re using pen testers…is that the case?…but each time we show the following slide, everyone has a different perspective.
  • The most common way that web applications are verified for security is to hire a security professional to conduct to penetration test.
  • Software Food Chain
  • http://readwrite.com/2013/02/21/tesla-and-the-fallacy-of-data-driven-decisions Telsa and the fallacy of data driven decision, I’m going to bring this up
  • Note that security is often begun in the network and host boxes, but application security requires work at the top box (application layer)