CODEWITHSUNDEEP
securitycontinuous-integrationcontinuous-deploymentcontinuous-delivery
Brian Carpio
Brian Carpio

Reputation: 491

Continuous Deployment / Delivery And Security

I know this is vague question but I'm looking for blogs or information regarding how teams are integrating security with continuous delivery / deployment. We are deploying to AWS multiple times per day and I am looking for some ways teams are adding security to the flow.

I've seen one presentation where a team used cucumber to do some nmap testing, that isn't exactly what I am looking for but maybe some automated testing of app nodes once they have been deployed before they go into the load balancer accepting traffic.

Upvotes: 4

Views: 733

Answers (4)

Prasanna
Prasanna

Reputation: 29

There are two things that can be done as part of your continuous integration - one is static code analysis for security glitches through tools like check marx and also integrate into run time vulnerability assessment tools like WAPiti. In such a case, you are constantly on top of security issues. Once in a while you can run heavy weight security assessments by third-party.

Essentially do it on change (or as frequently as possible) than making this the last step before release.

We do these for our daily builds.

Upvotes: 0

Simon Bennetts
Simon Bennetts

Reputation: 6236

The way we are approaching this in Mozilla is to proxy our (functional) regression tests through OWASP ZAP and then using the ZAP spider, active and passive scanners which can all be controlled via a REST API.

I've recorded a video about this process: http://www.youtube.com/watch?v=ZWSLFHpg1So and theres more details on the ZAP wiki: http://code.google.com/p/zaproxy/wiki/SecRegTests

This approach allows the security tool (ZAP in this case) to 'learn' how an application 'should' be used, and is generally more effective than just spidering.

Of course automated scanning will only ever find a subset of potential vulnerabilities, but it does mean that security folk can concentrate on the more 'interesting' issues :)

Upvotes: 0

Dave Farley
Dave Farley

Reputation: 11

At my last company, LMAX, we treated security features like any other and automated acceptance tests for those features.

We wrote acceptance tests that interacted with the system through the same channels as any other user of the system and proved that the security provisions of the system worked as expected.

So one test would assert that if logon was successful, other features of the system were available. Another would assert that if logon was unsuccessful you couldn't access any secured features - simple really.

The trick is to ensure that your acceptance tests interact with the system through the same communications channels as real users, or as close as you can get, no special tricks or back-doors into the main logic of the application - particularly no tricks or back-doors that allow you to bypass the security features ;-)

Logon is a trivial example, but this approach is applicable to any user-level security feature - actually any feature.

There are other classes of security problem of course, checking for buffer-overflows, sql injection and so on. A lot of this is about architecting your application to be secure - clear separation of responsibilities by layering you application for example.

You can include tests for these classes of security requirements in your acceptance testing too, if appropriate to your application, or perhaps add an additional step in your deployment pipeline to run tests for these kinds of exposure. This depends on the nature of your application, I would probably add to acceptance tests for most apps, and take the dedicated pipeline stage approach for apps where I could autogenerate test-cases to attempt injections - e.g. searching a web-app for all input fields and trying to inject garbage?

Upvotes: 1

Freedom_Ben
Freedom_Ben

Reputation: 11953

This may not be what you're looking for, but the key to effective security testing is building it into the product at design time, implementation, etc. Coding security tests just like you would unit tests, at all levels of the application. Using this approach, security testing is no different than general application testing.

The pre-packaged security tests are good, and you should use them (most orgs do this just before the QA check), but they are not as effective as your built-in tests. This is because no one knows the security "danger-zones" like your developers (or at least they should. If they don't have them read a book. For web apps I highly recommend "The Web Application Hacker's Handbook," and for other apps I recommend "Secure Coding in C and C++" by Robert Seacord, even if you don't do C/C++. There's a 2nd Edition of Seacord's book coming out in April if you can wait).

Security will never be effective unless considered at design time. If you've screwed that up already, try to get security tests integrated into your regular app tests.

EDIT:

Some great pre-canned scanners (some free-as-in-speech, others free-as-in-beer, and others not free at all) to run against your web app (in no particular order). These will find common and existing vulnerabilities, but will not find unique vulns to your web app:

  1. Nessus
  2. OpenVAS
  3. Nikto
  4. Acunetix
  5. Burp Suite
  6. W3af
  7. Retina
  8. Nexpose

Upvotes: 1

Related Questions