20061018

SPICON: Opening Session

Brian Cohen, President & CEO SPI Dynamics
The Latest Trends in Application Vulnerability Testing Across the Lifecycle

  • Gartner - 75% of hacks happen at the application layer.
  • CERT - 11 of 13 top issues are app layer
  • Gartner - if we fixed half the problems early, we'd fix 75% of our problems.
  • It's about fixing the application layer, and earlier in the lifecycle.
  • Microsoft - 64% of developers aren't confident in their ability to develop secure apps.
  • Hacking is about money.
When SPI started, they started with WebInspect. Now, SPI is trying to penetrate the whole lifecycle - development, QA, Production.

First to:
  • Support entire development lifecycle
  • Introduce a scalable platform (AMP)
  • Introduce Hybrid Analysis
  • Introduce Intelligent Engines
Secure Software Forum - develop more interest in software security.
http://www.securesoftwareforum.com
Findings - everybody's interested in security, but nobody's done anything about it. Regulatory compliance is a driver for security.
PCI is the one of most concern - section 6.5 has exact requirements for what needs to be checked in web applications.

To reduce false positive rates:
Intelligent Engines. Logically mimics the behavior a professional pen tester would perform (not much detail there yet think that'll be covered in a later session.)
Gartner predicts that source code review and pen testing tools will merge. (note: it's already happening - see Wathcfire/Fortify).

DevInspect - SecureObjects automagically remediates software defects (in .NET).

Stop talking about vulnerabilities - talk about application defects (right on! MANY semantic vulnerabilites are a result of a semantic code defect - lack of output filtering, dynamic SQL, etc.)

Joseph Feiman, Vice President and Research Director, Gartner Inc.

Joseph used to have a really nice laser pointer, but it was taken at the airport since it could be used as a weapon.

  • Firewalls, IDS, VPN's, SSL, and auth are not sufficient for application protection
  • Security is not a synonym of quality (QA is not the only place to do the work)
  • Security testing is not just assuring that the application is doing what it is supposed to do (we have to see what happens when we do counter-intuitive behaviors to the app)
  • Vulnerabilities don't only exist in production (they get introduced all through the lifecycle)
  • SOA does not necessarily make software more secure (we could be re-using insecure code)
  • You cannot make chaos secure (you have to build processes that include security)
  • You cannot secure a system that that you don't understand. The key to legacy security is legacy understanding. (With SOA, we're a lot of times web-enabling existing really old insecure code - even without the source code)
Key Issues:
  1. Hou should the SDLC change to make more seucre?
  2. Which methodologies will improve security
  3. What tools?
Application security - system for protecting the application against unforseen actions (intentional or unintentional) that cause its cease of function or exploitation
It's a set of means for protecting application quality under attack
It should provide assurance throught detection, prevention, and correction.

There's a new miscommunication - where on and off-site people miscommunicate. This is in addition to the existing miscommunication between steps in the process with the organization itself. (Example, a tester changes test scenarios to where they don't match the use cases - so they're testing for something that never existed).
Most CMM Level 5's are consultancies and off-shore development.

Vulnerabilities are introduced at all phases, including analysis and design, so security must be included at all phases.

Gartner Hype Cycle:
Technology Trigger
Peak of inflated Expectations
Trough of Disillusionment
Slope of Enlightenment
Plateau of Productivity (the productivity is never as high as the peak of expectations).

Blackbox testing tools - whatever tools are available from whitehat vendors are also available to attackers, open source, highly-available, just not as user friendly. Since good and bad guys both have access to the same tools - get there before the bad guys.

We lack security professionals IN the development groups, so we need tools that integrate with what the developers are using so they don't have to learn another tool.

Merging black-box and white-box testing to correllate discovered semantic vulnerabilites to actual vulnerabilities real-time in black box. (I tend to disagree to a point - even if it's not exploitable, if you're writing crummy code, it needs to be fixed. Just because my tool didn't find XSS doesn't mean you oughtn't perform output filtering. However, fixing the exploitable ones ought to be the priority.)

Gartner predicts that WASVS and SCSVS will start to combine features. Further, Software Lifecycle (SLC) vendors will begin to integrate WASVS and SCSVS into their tools. By 2009, 40% of organziations will use a single vendor to provide both features. By 2009, 60% of IT organization swill make security vulnerability detection an integral part of the SLC.

Business criteria for selecting WASVS:
  • Product/Services
  • Overall financial viability
  • Market understanding
  • Innovation
How much security is enough? Determining impact based on vulnerabilities and threats that would exploit those (including insider threats). Determine probabilithy.

Our biggest problem today is that developers live in denial - they don't take responsibility for the security of the application because their primary concern is functionality. There's a huge gap between developers and security specialists (hence my call for more security engineers - not just specialists).

Q/A:
Q: Will slides be available
A: Yes

Q: We see stats, they come from Gartner. Where do you get your stats?
A: Carnegie-Melon, and CMM

Q: Application firewalls
A: They do some menaingful jobs, but quite limitied. Not nearly as practical as software scanning.

Q: Why don't tools prevent us from writing insecure code?
A: Stopping doing naughty stuff is a methodology, not a function call. Integration between systems only further complicates things.

Q: SOA. Not necessarily individual compents are vulnerable, how do we test the interactivity?
A: Creating a service out of insecure components makes an insecure service. Short answer: Not sure how to do that well.


Q: Communications problem between what customer wants and Q/A approves are different. Is anything improving some of these miscommunications, or are we just adding layers to bad communication?
A: The communication problem is really serious. Outsourcing was due to simple mathematics. We don't save as much as we thought because the miscommunication actually makes the benefit ratio go down.

0 comments: