Continuous Deployment / Delivery and Security

Question

I know this is a vague question, but I'm looking for blogs or information on how teams integrate continuous delivery / deployment security. We deploy to AWS several times a day, and I'm looking for some ways that teams add thread safety.

I saw one presentation in which the team used a cucumber to conduct some nmap testing, this is not quite what I am looking for, but maybe some kind of automatic testing of application nodes when they were deployed before they enter the load balancer reception traffic.

Answer 1

Perhaps this is not what you are looking for, but the key to effective security testing is to create it in the product during development, implementation, etc. Coding security tests is the same as you would do unit tests at all expression levels. Using this approach, security testing is no different from testing a common application.

Pre-packaged security tests are good and you should use them (most organizations do this just before QA testing), but they are not as effective as your built-in tests. This is because no one knows the security of the “danger zones” like your developers (or at least they should. If they don’t read the book, for web applications I highly recommend the “Hacker Guide for Web Applications” , " and for other applications that I recommend: Robert Sickford's Safe C and C ++ Encoding , even if you don't do C / C ++. There 2nd Edition of Seacord book comes out in April if you can wait) .

Security will never be effective unless you consider it during development. If you've already screwed this up, try integrating security tests into your regular application tests.

EDIT:

Some great preconfigured scanners (some free as in speech, others free-in-beer, and others not free at all) to work against your web application (in a specific order). They will find common and existing vulnerabilities, but they will not find unique vulvos for your web application:

• Nessus
• Openvas
• Nikto
• Acunetix
• Burp suite
• W3af
• Retina
• Nexpose

Answer 2

At my last LMAX company, we looked at security features such as any other and automatic acceptance tests for these 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 conditions of the system work properly.

Thus, one test will claim that if the login was successful, other functions of the system were available. Another would argue that if the login to the system was unsuccessful, you would not be able to access the protected functions - just really.

The trick is to have your acceptance tests interact with the system through the same communication channels as real users, or as close to them as possible, no special tricks or back doors to the main logic of the application - especially there are no tricks or back doors that allow bypass protective functions; -)

Logging into the system is a trivial example, but this approach is applicable to any security function at the user level - virtually any function.

Of course, there are other security classes that check for buffer overflows, SQL injection, and so on. Many of them relate to keeping your application secure - a clear separation of duties, such as overlaying your application.

You can also include tests for these classes of security requirements in your acceptance tests, if necessary for your application, or perhaps add an additional step in the deployment pipeline to run tests for these types of impacts. It depends on the nature of your application, I will probably add to the acceptance tests for most applications, and take a dedicated approach at the development stage for applications where I could auto-generate test files to make injections - for example, search for a web application for all fields input and attempts to insert garbage?

Answer 3

We approach this at Mozilla to proxy our (functional) regression tests through OWASP ZAP, and then use the ZAP spider, active and passive scanners that can be controlled using the REST API.

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

This approach allows the security tool (in this case, ZAP) to “learn” how the application should be “used” and, as a rule, more efficiently than just spidering.

Of course, automatic scanning will always find a subset of potential vulnerabilities, but this means that security people can focus on more "interesting" problems :)

Answer 4

There are two things you can do as part of your continuous integration: one is the analysis of static code for security failures with tools such as check marx, as well as integration with runtime vulnerability assessment tools such as WAPiti. In this case, you are constantly faced with security problems. From time to time, you may conduct safety assessments of heavy mass by third parties.

Essentially doing this on a change (or as often as possible) than doing it the last step before releasing.

We do this for daily builds.