Open Source Security Tools for the Pipeline

Editor's Notes

• #2: I’m going to talk about getting some open source security tools into your pipeline, but it isn’t really so much about the tools as it is about the process- looking for places and opportunities to do security testing. Remember that security isn’t about compliance rules, but about trying to be more secure.
• #3: As we build out our pipeline, we want to do just enough of each type of testing to know if further testing is worthwhile. So we want to do the easy stuff first, the tests that are going to catch the most. That goes for whether we are doing quality checks or for security checks.
• #4: So start with your source code. Reduce your code footprint. Make your attack surface smaller. Dependency management tools like Apache Maven can identify libraries you are including but aren’t actually using.
• #5: Once you get rid of the excess, use OWASP Dependency Check to see if the remaining libraries have known vulnerabilities. Update any libraries that do. It works for a bunch of different languages.
• #6: Use static analysis to keep your code clean. Part of security is understanding code behaviors, inputs and outputs, and that is easier to do with clean code. High quality code is easier to secure than poor quality code.
• #7: Also, make sure your code is tested. Not just “did the code run while I was running the unit tests,” but actually tested. Mutation testing tools can tell you if your unit tests are valuable and if any tests you should be doing are missing.
• #8: Functional test tools like Selenium can help with security testing, looking for things that users cannot do or should not be able to do. I should be able to see my account info, but not see theirs. An admin should see this menu, a regular user shouldn’t.
• #9: And run those tests through a passive proxy like OWASP ZAP. You get some extra security testing for almost no effort while you are running functional and regression tests to pump traffic the scanner.
• #10: Make sure you have repeatable, reliable deployments. Chef, Ansible, Puppet. Whatever tool you are using to automate your deployments. That way you know the environment faithfully represents production.
• #11: Also, Chef InSpec can do your audits, regardless the CM tool you are using. It might not replace your “official” audit, but it can be used so that you have confidence that the “official” audit won’t bring up any surprises when it is too late to do anything about them.
• #12: OpenSCAP. Scan your baselines before your deploys so you know you aren’t building on an insecure foundation. And scan after your deployments so you know you haven’t introduced any new problems yourself.
• #13: Make sure that your web server or an application server configured correctly and securely. Nikto2 can scan your web server to make sure it isn’t leaking information, directories are locked down against enumeration attacks, best practices like that.
• #14: Of course scan the web app itself. Even if the security team is going to do a scan right before release with an expensive tool that you don’t have access to doesn’t mean you shouldn’t take the time to do your own scan to avoid any late surprises.
• #15: Once the system is all set up, don’t forget about the database. Sqlmap can look for injection problems through the web front end to see if an end user could exploit the database without ever getting command-line access to the system.
• #16: Keep your system packages up-to-date, just like you keep your libraries up-to-date. These aren’t strictly open source, but they are important. And consider subscribing to the US-CERT Weekly Vulnerability Summary, so you can stay informed.
• #17: Scan all the systems even infrastructure like your CI server, source code repo, issue tracking systems. Use a vulnerability scanner like OpenVAS, the open-source fork of Nessus. And you can look for unexpected open ports or unrecognized systems on you network with a tool like Nmap.
• #18: Things will break. You’ll never recover gracefully from a system crash if the first time you try is with users screaming and management crying, or vice-versa. Practice recovering from failures so that it becomes second nature using a tool like Chaos Monkey from the Netflix Simian Army.
• #19: There is no such thing in the cloud as “just a development server” that doesn’t need to be secured. Secure everything. Use Fail2Ban to protect against brute force attacks. Aide is a file integrity monitor like Tripwire so you can see if anything on your system has been altered without your knowledge.
• #20: Continuously improve. Don’t expect to ever be 100% secure. Always look for new opportunities to add more security testing to the pipeline. A little better is still better.
• #21: And if you are looking for inspiration for more tools to use, think about downloading Kali Linux. Hundreds of security tools, all preinstalled and cataloged for you to experiment with. Thank you.