WhiteHat Security Presentation

Editor's Notes

• #3: So lets take a look at how these attacks work. This is a normal web page and how a user looks at it. You have a login form, where you can enter your username and password. There is a register now functionality if you don’t have an account. You can go to forgot password if you forgot your password. You can also contact them with your feedback, etc
• #4: We saw how a normal user looks at a web page. This is how a hacker looks at your webpage. A user looks at a functionality whereas a hacker looks at an opportunity. So as you can see, he is trying to figure out where he can perform what kind of attack. There is an opportunity to guess password by brute force attack, he can do denial of service or byapss login using SQL injection. He can go to register now functionality and enumerate registered users for that website. He could do XSS or session hijacking and parameter manipulation. So as you can see hacker looks at an opportunity and he only needs one. View web applications through a magnifying lens. This is what you should be able to do once the class is over: Spot opportunity where none is visible to the untrained eye.
• #6: 4 stages: * Discover assets * Build a risk profile * Select service level that gives appropriate visibility * Report and communicate those findings, provide flexibility to remediate them in the code, with a WAF, or IDS
• #7: Goal: Select a service level that provides the proper visibility for the asset’s risk level.
• #8: Before we drill down into the methodology of the Sentinel Service, I’d like to spend a couple minutes discussing the WASC 24 because this is an integral and very key component of our assessment process. To help ensure the Sentinel Service is thorough, WhiteHat relies on the WASC 26 classes of attacks as a reference point against which we test for website vulnerabilities - in case you aren’t familiar with the WASC it stands for Web Application Security Consortium and the WASC 26 has been adopted as a global standard by the security community as a way to measure the level of security associated with any specific web application. Many of you are probably more familiar w/ the OWASP Top 10 – and while the OWASP Top 10 is also an important criteria, it’s a essentially a subset of the WASC 26 – in short, the WASC 26 is WAY more comprehensive as a checklist for assessing web applications which is why we use it as our standard. At WH, we’ve incorporated these 26 classes of attacks into our internal assessment process to enforce consistency, reliability, and thoroughness each time the Sentinel Service is delivered - we’re not just taking rifle shots at customer websites HOPING we get lucky and uncover website security holes. The vulnerabilities on the left column of this slide are those that require human expertise to uncover, and those on the right can be discovered if you know how to effectively customize automated scanning technology and in fact, the legacy scanning tools are pretty good at finding these types of vulnerabilities. The important takeaway here is that when we say that automation can identify roughly ½ of all web application vulnerabilities, this is what we mean – automation has the capability to identify those 13 classes of attacks listed on the right hand column that we refer to as being technical vulnerabilities, ones that can be found syntactically. And while these vulnerabilities represent roughly 75% of ALL vulnerabilities found according to our trending statistics, the business logic flaws – the other 25% or so listed in green - are often the ones that are the most egregious and REQUIRE human intervention to uncover. Bottom line – being thorough in the assessment process is critical and using the WASC 26 as a measuring stick is one important way in which comprehensiveness and consistency is enforced within WhiteHat’s assessment process.
• #9: All Service levels share these features. Most important: SaaS, repeatable assessments, production safe, verified results
• #10: Step 1: Customer provides urls, logins, & schedule Step 2: Initial testing includes a lot of up-front configuration work (2-3 weeks), but we are delivering results immediately as we progress through the site Step 3: Results are up to date and complete after initial configuration is done, and now detailed, repeatable assessments occur on a continual/scheduled basis Step 4: Results made available through website.  API integrates with everything (WAFs, IDS, bug tracking).
• #11: Goal: provide flexibility in remediating vulnerabilities through the code, WAFs, IDS, or Security Training for your developers.
• #19: We are here because we are concerned about these people
• #20: We are here because we are concerned about these people