30 Days of Security Testing – Day Twelve

The challenge for Day Twelve is – Read about security testing and discuss where it best fits in an SDLC.

This was an interesting challenge, as most people will agree that it’s important to perform security tests over an application, but when is the “best” time to test?

To dig deeper we will need to briefly compare some different Software Development Life Cycles:

Waterfall

In traditional waterfall models, testing often happens after all development has been completed and just prior to release.

This can prove to be a costly exercise if a serious flaw has been found.  It requires testers to climb through the entire application from top to bottom, then report their findings to the developers to rework.  This can cause a perceived bottleneck and be a source of friction within a team – not to mention push up the development hours for re-work and push up the cost of the build.

Agile

In agile, we break up the development into smaller chunks called sprints (usually 2 weeks to a month long) and the general idea is to release a small piece of functionality every sprint.

This allows testers to pick issues up early, and developers to remedy these issues rapidly.  Having a smaller target to test means tests can generally be completed faster, and (in my opinion) more accurately than taking on the entire application at once.

Confucius says “the man who moves a mountain begins by carrying away small stones” 

Wow, didn’t expect philosophy in a software testing blog did you?


 

So when should we test for security?

One relevant catch cry from my time with the NZ Navy was that “security is everyone’s responsibility” – when a development team adopts this approach from initial customer contact right through to release and ongoing support then the whole team “owns” security and makes it a priority rather than an afterthought.

Since starting my career in testing, I’ve only ever worked in Agile (scrum in particular) so I can only really comment on that flavour of SDLC.

Security needs to be considered right from the very start when discussing requirements with the customer.

Dissect what implications the design will have on security.

  • Who is accessing the application, how are they using it, and for what purpose?
  • Will users require different access levels/privileges?  How is this assigned and protected?
  • What data will the user be required to upload or download?  How and where is this stored?  How is it transported?
  • Is the software subject to compliance?  How does this affect the security requirements?

This will help guide what needs testing later on in development, and help to advise the developers to design the software with security in mind.

Once security concerns have been identified at the requirements phase, these items can be hunted down as soon as new code hits the floor.  Source code analysis, pair reviewing, and UI testing are good options here.

It’s important to check these prior to release and again after release.  Ideally your application will be released to a development environment which is a clone of the live environment, that way you can identify problems before they have a chance to roam free in the wild.

Some Continuous Integration / Continuous Development pipelines (like Jenkins or TeamCity) will allow automated checks to be included in the release, this is a good opportunity to run some automated security tests/scans for known vulnerabilities – but don’t rely on them to catch everything.

Another important point to consider is that security testing can’t necessarily be done in isolation.  If another application interacts with your application, how does this affect the security of your application.  Whenever a change is introduced, or something new added, the application’s security implications should be tested.

To sum up, security testing should be considered:

  • When defining requirements
  • When code is written and committed
  • Post and Prior release
  • When any changes or additions are made

…so basically all the time.


I found some good articles on the topic including this one from Sarah Vonnegut of Checkmarx,  and OWASP do a great concise run down of secure code review in waterfall and agile SDLCs

 


 

Thanks for reading my post and following my progress through the 30 Days of Security Testing.

For more on Security Testing please visit here  or any of my other ramblings visit here

Feel like joining in? Sign into the WeTest Slack group and get involved!

Advertisements

One thought on “30 Days of Security Testing – Day Twelve

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: