[WEB SECURITY] Security test case automation

Stephen de Vries stephendv at gmail.com
Thu Jan 23 05:26:38 EST 2014


On 23 Jan 2014, at 11:04, Ward, Allan <WardA at DNB.com> wrote:
> 
> Remember, the earlier you build security into your lifecycle the lower the cost to remediate, so secure requirements, and threat / attack modelling should be done before coding starts to identify the exposures, software flaws etc.

This is where the power of automated tests and BDD shine through (OK I’m a little biased ;) ).  If the developers are using agile methods like Test Driven Development or Behaviour Driven Development, then those tests are written _up front_ before the code is written.  So the power of including security tests there is that developers know what they’re meant to be building before they start writing code.  The tests effectively serve as the security requirements, and those requirements including both functional and non-functional security requirements.

The magic of BDD (hey I already said I was biased) is that those requirements can be written in English so that everyone understands them (Business, Security, Dev and QA) and not just the developers.  E.g.:

Scenario: Authentication credentials should be transmitted over SSL  

Given a browser configured to use an intercepting proxy
And the proxy logs are cleared
And the default user logs in with credentials from: users.table
And the HTTP request-response containing the default credentials is inspected
Then the protocol should be HTTPS

The blindspot for both SAST and DAST scanners is that they only find security bugs, not architectural flaws or functional security flaws.  For those you need humans, but with a human-only approach you lose scalability and repeatability (and it costs a fortune).  Humans + automation of the human’s findings gives you a tasty sweet spot of coverage and repeatability.  
Depending on how test orientated the development team is, I would even suggest wrapping the SAST and DAST tools with tests so that developers only deal with one kind of “stuff”: Tests.

Q: What security features do I need to build into the app?
A: Check the tests
Q: Have I implemented all the required security features? 
A: Check the tests
Q: Has my code introduced security bugs?
A: Check the tests
Q: Has a new change I made to old code introduced new security bugs, or broken a previously working security feature?
A: Check the tests


E.g. BDD-Security wraps OWASP ZAP scanning like so:

Scenario: The application should not contain SQL injection vulnerabilities

Given a fresh scanner with all policies disabled
And the scannable methods of the application are navigated through the proxy
And the SQL-Injection policy is enabled
And the MySQL-SQL-Injection policy is enabled
And the Hypersonic-SQL-Injection policy is enabled
And the Oracle-SQL-Injection policy is enabled
And the PostgreSQL-SQL-Injection policy is enabled
When the scanner is run
And false positives described in: tables/false_positives.table are removed
Then no Medium or higher risk vulnerabilities should be present





>  
> From: websecurity [mailto:websecurity-bounces at lists.webappsec.org] On Behalf Of Stephen de Vries
> Sent: 23 January 2014 09:50
> To: Paul Johnston
> Cc: websecurity at lists.webappsec.org
> Subject: Re: [WEB SECURITY] Security test case automation
>  
>  
> On 23 Jan 2014, at 10:44, Paul Johnston <paul.johnston at pentest.co.uk> wrote:
> 
> What you cannot automate is the mindset of a hacker. Security is not just about checking for a known set of issues. It is about using creativity and intuition to think up new ways of attacking a particular application. So while doing your own QA using DAST/SAST is good, you should also include some manual penetration testing in your security programme.
>  
> …and once you’ve found vulnerabilities through a manual test you can record and automate those findings with a testing framework.  Then you can re-run those same tests on your application periodically or even continuously to ensure that code changes to the app don’t introduce security regressions.
>  
> Stephen
>  
>  
>  
>  
>  
>  
> 
> On 23/01/2014 04:30, vedantam sekhar wrote:
> Hi group,
> 
> Need your help here. as part of QA team, we will be writing security test cases and also executing them manually using OWASP standard. However, i have been given task to see the possibility to automate these test cases. are there any tools/frameworks available for us to achieve this?
> 
> Thanks and Regards,
> 
> sekhar
> 
> 
> 
> 
> _______________________________________________
> The Web Security Mailing List
>  
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>  
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>  
> WASC on Twitter
> http://twitter.com/wascupdates
>  
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>  
> --
> Pentest - The Application Security Specialists
> 
> Paul Johnston - IT Security Consultant / Tiger SST
> Office: +44 (0) 161 233 0100
> Mobile: +44 (0) 7817 219 072
> 
> We're exhibiting at Infosecurity Europe!
> Stand K97, Earl's Court London - 29th April - 1st May
> <logos-dl-infosec-withoutdates.png>
> 
> Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
> Registered Number: 4217114 England & Wales
> Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK
> Accreditations: ISO 9001 (44/100/107029) / ISO 27001 (IS 558982) / Tiger Scheme
> 
> _______________________________________________
> The Web Security Mailing List
> 
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> 
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 
> WASC on Twitter
> http://twitter.com/wascupdates
> 
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140123/f5b412bf/attachment-0003.html>


More information about the websecurity mailing list