2

• Introduction

• The need for Application Security

• Overview of Security Testing Tools

© Shelde Pty Ltd – Not for commercial reuse

3

• Joanne Pizzato – Application Security Consultant at Shelde

– Currently working on Application Security Program at a major organisation

– 8 years experience in the IT industry

– Prior to Shelde • Application Developer at two major financial organisations

• Developer Security Champion to integrate static code analysis for technical and programme level

© Shelde Pty Ltd – Not for commercial reuse

4

• Recent online attacks have targeted online web applications – JPMorgan Hackers came in through the front door http://www.bloomberg.com/news/2014-08-29/jpmorgan-hack-said-to-span-months-via-multiple-flaws.html

– Sony Hacked again http://www.cnet.com/au/news/sony-hacked-again-this-time-the-playstation-store/

– Commandeer any Facebook account from a mobile phone http://www.scmagazine.com/researcher-finds-way-to-commandeer-any-facebook-account-from-his-mobile-phone/article/300599/#

– Yahoo and SQL injection attack http://www.imperva.com/docs/HII_Lessons_Learned_From_the_Yahoo_Hack.pdf

– LinkedIn passwords hacked http://arstechnica.com/security/2012/06/8-million-leaked-passwords-connected-to-linkedin

– Thousands of Australians exposed – Credit card and passwords published

http://www.scmagazine.com.au/News/285548,stratfor-subscriber-base-posted-to-the-web.aspx

© Shelde Pty Ltd – Not for commercial reuse

• Not all code examples are secure!

– Often code samples and working code are “Googled” and contain vulnerabilities (2 out of top 3 hits in this example)

– Even previously used code within the application may be vulnerable. Did your colleague know what they were doing?

• Solution

– Internal Coding Guidelines

– Known good code examples

– Tools for detecting vulnerabilities

© Shelde Pty Ltd – Not for commercial reuse

6

“Let’s arrange some security testing just before we go-live”

– Pen Testers / Ethical Hackers conduct security testing and issue a report before each release.

© Shelde Pty Ltd – Not for commercial reuse

7

However, consider what happens when:

– Frequency of releases increases

• Does your company release once a quarter, once a month, once a week, or once a day..?

– Number of supported apps and number of developers and complexity of changes increases over time

– Limited money in the project/overall IT budget to support additional security testing activities

© Shelde Pty Ltd – Not for commercial reuse

8

“Let’s create faster feedback loops for the developer so they can detect and correct flaws

while they code”

This approach already happens for functional testing, and should apply to security testing as well

http://www.charteris.com/business-blog/2013/06/improving-the-feedback-loop-between-business-and-developer-teams/

© Shelde Pty Ltd – Not for commercial reuse

9

Different flavours of Security Tools: – Static AST

• White-box testing – examines the source code

– Dynamic AST • Black-box testing – examines the behaviour of the

running app to various inputs

– Interactive AST • Hybrid of static and dynamic. Like a debugger that

hooks into the running application and examines the source code that is executed.

© Shelde Pty Ltd – Not for commercial reuse

10

© Shelde Pty Ltd – Not for commercial reuse

Source: http://techbeacon.com/magic-quadrant-application-security-testing-gartner

11

OWASP top 10 (2010)

A-1 Injection

A-2 Cross Site Scripting (XSS)

A-3 Broken Authentication and Session Management

A-4 Insecure Direct Object References

A-5 Cross Site Request Forgery (CSRF)

A-6 Security Misconfiguration

A-7 Failure to Restrict URL Access

A-8 Unvalidated Redirects and Forwards

A-9 Insecure Cryptographic Storage

A-10 Insufficient Transport Layer Protection

OWASP top 10 (2007)

A-1 Cross Site Scripting (XSS)

A-2 Injection Flaws

A-3 Malicious File Execution

A-4 Insecure Direct Object References

A-5 Cross Site Request Forgery (CSRF)

A-6 Information Leakage and Improper Error Handling

A-7 Broken Authentication and Session Management

A-8 Insecure Cryptographic Storage

A-9 Insecure Communications

A-10 Failure to Restrict URL Access

OWASP top 10 (2013)

A-1 Injection

A-2 Broken Authentication and Session Management

A-3 Cross Site Scripting (XSS)

A-4 Insecure Direct Object References

A-5 Security Misconfiguration

A-6 Sensitive Data Exposure

A-7 Missing Function Level Access Control

A-8 Cross Site Request Forgery (CSRF)

A-9 Using Components with Known Vulnerabilities

A-10 Unvalidated Redirects and Forwards

Source: https://www.owasp.org

12

Criteria Using Traditional Approach Using Automated Approach

Able to test early in the release cycle

No - requires a Prod-like environment, so usually occurs late in the cycle

Yes - Can identify technical security flaws upfront

Can integrated into build process

No - Security specialists use manual Effort to test (although they do use of automated scripts)

Yes - Developers get faster feedback while they code, they can review the results and then remediate

Can support frequent rapid releases

No – One round of testing might take 1-5 days to complete

Yes - Can run as many scans as required. Less reliance on ethical hacking / security testing

Is cost-effective $$$ - Security specialists charge for every engagement and is labour intensive

Varies: Cost for installation of tool + license, onboarding of each app, plus regular tool software and vulnerability updates

© Shelde Pty Ltd – Not for commercial reuse

13

• 2015 Gartner Magic Quadrant for Application Security Testing

http://techbeacon.com/magic-quadrant-application-security-testing-gartner

• OWASP Top Ten (2013) https://www.owasp.org/index.php/Top_10_2013-Top_10