cyber security testing in an agile environment
TRANSCRIPT
Arthur DonkersSecurity Officer
Interested in infosec, technology, organization and combining these all into one solution. Critical Security Architect Trainer for PECB (ISO27001, 27005, 31000) Convinced that Infosec is a means to an end, not a purpose in itself.
Contact Information
+ 31-6-53315102
www.1secure.nl
nl.linkedin.com/in/arthurdonkers
Cyber Security Testing
How to align security testing to your agile cyber strategy
Agenda
What is this all about?
Who am I?
Out with the old!
In with the new!
Securitytesting in Cyber space
Does classical penetration testing still fit in the rapidly moving cyberspace?Or do we need a new approach?
Who am I?
Arthur DonkersIndependent security consultantSecurity tester for mobile, IoT and hardwareTrainer for PECB (ISO27001, 27005, 31000)
These are my opinions
This presentation is based on MY personal experiences with MY clients and MY projects.
Your mileage may vary, I just want to make you think about your current security testing strategy.
… one more thing ...
I’m not a big fan of the term cyber, I think it is an empty term…
Classic testing strategies
Classic security testing follows the waterfall project delivery model:
SECURITY TEST
Classic testing strategies
this means:- Test after delivery of product (but hopefully
before actual deployment);- Within a set scope (only the product);- Within a limited timeframe (before release
date);- With limited resources (people and money)
Classic testing strategies
which leads to:- time crunch (prioritizing individual tests, features
left untested);- limited security assessment (product is not
assessed in its final environment);- Too little time to test (time crunch);- No testers available due to time shift (limited
resource);- No time to fix things (no feedback).
Classic testing strategies
Trying to swim upstream…
Classic testing strategies
Same issues apply to regular testing as well, this is often part of a (mandatory) compliance program:- Limit scope (don’t test the scary stuff);- Limit time (need to be recertified yesterday);- Don’t care about the actual execution (having
ANY test executed often considered sufficient).
Classic testing strategies
Tick in the box exercise!
So now what?
Modern development of products needs to adapt quickly and follow a risk based approach.
This is often referred to as Agile Development
Agile testing strategy
Security testing needs to be integrated into the incremental and continuous delivery cycle
Agile testing strategy
Security testing is not a separate step anymore:- follow at least the risks identified in the agile
cycle (and any additional risks identified);- embed security testers in project (secure
development);- focus and prioritize (there is no 100%)- automate and tool up
Agile testing strategy
Supporting environment (just an example):
Agile security management
For your regular testing you should:- employ a red team (for continuous testing);- don’t limit the scope (let them think and work
like a hacker);- actively and continuously manage the
vulnerabilities and associated risks.
Agile security management
What is ‘red team’ exactly?
“Penetration testers assess organization security, often unbeknownst to client staff. This type of Red Team provides a more realistic picture of the security readiness than exercises, role playing, or announced assessments. The Red Team may trigger active controls and countermeasures within a given operational environment.” (Wikipedia)
Agile security management
So it is a simulated attack, without the limitations of a regular penetration test to yield better and more complete results:
A simulated hacker attack
Agile security management
Continuous security testing uses the same approach, but in a continuous flow instead of an exercise.
Agile security management
• Continuous security testing becomes part of your operational security process (vulnerability management) and gives you a realtime and continuous view on your current security posture.
• This helps you to prioritize risk mitigation and resource allocation (put $$$ where it has the most effect).
• And it fits very well into the continuous improvent which is part of ISO27001
But wait! There’s more!
What then?
All organizations have limited resources (people, time, money).Leverage the hacker community via a bugbounty program.
Bug bounty program
Reward hackers for reporting bugs to you’They’ have the time and dedication to look for bugs.You must set the right terms and conditions.And make sure you can handle the bug reports that will be pouring in (both in volume and quality!).If done properly, this could be an addition to your continuous testing team!
Bug bounty program
Make sure you have at least:
- set up a (responsible) disclosure policy;- set up a reward system (separate the wheat
from the chaff);- set up an incident handling process (things
may/will go wrong and/or trigger alarms).
Responsible disclosure
Allow for people to report bugs and vulnerabilities to you:- without ‘punishing’ the reporter;- in a safe (and sometime anonymous) way;- using clear communication protocols.
So you can resolve these bugs and vulnerabilities before they bite you!
Bug bounty program
You can run your own bug bounty program,Or have a specialized company do it for you, like
Incident handling process
In a continuous security testing strategy, the incident handling is necessary to catch all things that slip through the cracks.This is not an omission, but a result of the fact that you cannot test and secure everything.But you should prepare yourself!
Incident handling process
Wrapping up
Old skool testing does not fit the bill anymore!
Perform continuous testing;Think like a hacker using red team approach;Leverage the hacker community through bug bounty program;Prepare for incidents.
More info at:
www.agilesecurity.nl
