Difference between revisions of "EUTour2013 Cambridge Agenda"

Tour Home Page
Tour Scheadule
Tour Organizers Resources
Mailing List

OWASP Europe Tour - Cambridge 2013

Monday 13th May (Conference)

• Apart from OWASP's Top 10, most OWASP Projects are not widely used and understood. In most cases this is not due to lack of quality and usefulness of those Document & Tool projects, but due to a lack of understanding of where they fit in an Enterprise's security ecosystem or in the Web Application Development Life-cycle.

• This event aims to change that by providing a selection of mature and enterprise ready projects together with practical examples of how to use them.

Become an OWASP member by clicking here

Venue Address: East Road, Cambridge, CB1 1PT
Venue Map: Anglia Ruskin University - Getting to Cambridge

Registration Link to the Europe Tour: [TBD REGISTER HERE!]

Schedule for the Day

directly.

As part of the overall Mobile Project , the Top 10 Mobile Risks include

M1: Insecure Data Storage M2: Weak Server Side Controls M3: Insufficient Transport Layer Protection M4: Client Side Injection M5: Poor Authorization and Authentication M6: Improper Session Handling M7: Security Decisions Via Untrusted Inputs M8: Side Channel Data Leakage M9: Broken Cryptography M10: Sensitive Information Disclosure

"Insanity is doing the same thing over and over and expecting different results." - Albert Einstein

We continue to rely on a “pentest” to secure our applications. Why do we think it is acceptable to perform a time-limited test of an application to help ensure security when a determined attacker may spend 10-100 times longer attempting to find a suitable vulnerability? Our testing methodologies are non-consistent and rely on the individual and the tools they use. Currently we treat vulnerabilities like XSS and SQLI as different issues but the root causes it the same. – it’s all code injection theory!! Why do we do this and make security bugs over complex?

Why are we still happy with “Testing security out” rather than the more superior “building security in”?

Is "red" much worse than "orange", and why is "yellow" used instead of "green"?

Just what is a "critical" vulnerability? Is "critical" the same as "very high"?

How do PCI DSS "level 4 and 5" security scanning vulnerabilities relate to application weaknesses?

Does a "tick" mean you passed? Are you using CWE and CVSS? Is a "medium" network vulnerability as dangerous as a "medium" application vulnerability? Can CWSS help?

What is FIPS PUB 199? Does risk ranking equate to prioritisation? What is "one" vulnerability?

Are you drowning in a mess of unrelated, classifications, terminology and abbreviations? If you are a security verifier and want to know more about ranking your findings more meaningfully, or receive test reports and want to better understand the results, or are just new to ranking weaknesses/vulnerabilities and want an overview, come along to this presentation. It will also explain why the unranked information-only ("grey" or "blue"?) findings might contain some of the best value information.

While it is true that 'good security' should be embedded into the design, there are a couple of steps a developer can take which lead to a more secure application. In this presentation we will go to the basics of secure application development and demonstrate these principles which help you build security into your application.