By Dan Cornell
Development teams are going to have to pay attention to security; this is unavoidable. Regulations and compliance demand it and customers themselves are increasingly asking for evidence that the software they are consuming is safe. That means development managers are going to have to weave security into their development practices. Managers – if you haven’t been visited by security yet you should know that the day is coming. And when it does, nothing erodes confidence more than a blank stare, shrugged shoulders and a mumbled excuse of “I thought you guys handled that at the firewall…”
Good security teams act as advisers and enablers for their development teams. Bad security teams show up with a bunch of accusations and a checklist of TODOs for development teams. If you want to get the conversation off in the right direction you don’t want to be caught flat-footed. Here are five things you can do to demonstate that you aren’t starting from zero:
1. Have at least one developer on the team able to speak in depth about security. Send them to an OWASP conference or at least have them read up on the OWASP site as well as other materials available online and in books. This shouldn’t be a hard sell for your developers – security is an interesting discipline and a growing concern – talented developers interested in advancing their careers know that this is a hot area and will dive in to learn more.
2. Run all developers through some form of awareness training. Not every developer is going to be an expert in security, but all of them need to at least know the fundamentals. There are classes and eLearning available to teach these fundamentals, but even having some informal lunch and learn sessions is better than nothing. Keep track of the attendees for these events – this is valuable because you can prove that your team is not completely in the dark with regard to security.
3. Make a list of your applications and some of their characteristics. Which are the important ones? What technologies are in use? What sort of data do they store and manipulate? How many page or lines of code do they have? Down the road you will likely have to provide much more information about your applications, but this is a starting point and you can use it to provide evidence that you have thought about your application portfolio.
4. Pull down one of the freely-available web proxies or scanners and either have your or your security maven take a run at one or two of your applications. At this stage your efforts will probably be ad hoc and, quite frankly, amateurish. This is fine – consult to OWASP Tesing Guide for guidance but set reasonable expectations. Is this the “right” way to incorporate security scanning into your development process? No. Is it comprehensive? No. Will you learn some things about your application and start to get an appreciation for how this activity will ultimately fit into your software security program? Yes. Also – save the results of your testing. You can offer these up to the security folks as evidence of your fledging efforts. See the Appendix for links to some freely-available tools.
5. Just as you did for the proxy tool or scanner – download a freely-available code scanning (static analysis) tool and run it against your codebase(s). You should expect to see some false positives as well as results that might be hard to interpret. As we saw above: Right way? No. Comprehensive? No. Valuable for seeing how this class of tool fits into your environment? Yes. As with the dynamic testing – save the results. For extra credit you can integrate code scanning into your daily build. Again – there is a list of some freely-available tools in the Appendix below.
Going though these basic steps is a great way to indicate to the security folks that a) you understand security is an important concern and that b) you are willing to work with them to improve your security. Having these in place should make initial conversations much more friendly and productive when the security folks track you down.
Or better yet – reach out to them.
Contact us for more information about getting security teams and development teams to work together.
--Dan
dan _at_ denimgroup.com
Appendix: Freely-Available Application Security Testing Tools
Dynamic testing tools:
· WebScarab (proxy)
· Paros (proxy)
· w3af (scanner)
Static analysis tools:
· FindBugs (Java)
· PMD (Java)
· Orizon (Java)
· FxCop (.NET)
Note: As mentioned above, firing off a couple of automated scans or doing some light penetration testing is not a “software security program” But getting comfortable with the tools and the process of using them will pay off later on when you look to incororporate these technologies into a more structured program. Keep an open mind.
Comments