By Dan Cornell
[This is an expansion on a previous blog post titled 5 Things Every Development Manager Should Do Before the Security Team Shows Up.]
The following list represents a list of best practices that Denim Group has observed in innovative client environments where software development teams have collaborated effectively with their security counterparts:
1. Have at least one developer on the team who is able to speak in depth about security. Hire someone specifically for this purpose, or grow someone within the team. 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 this is a hot area and will dive in to learn more.
2. Run all developers through some form of security 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 with some of their characteristics, and share this list with your security team. 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 security teams with 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. Use one of the freely available web proxies or application scanners to test one or two of your applications. At this stage efforts will be ad hoc. This is fine – consult the OWASP Testing Guide for guidance and set reasonable expectations. This should not be mistaken for a comprehensive application testing program, but will provide some insight on how this activity can be incorporated into development processes. Also – save the results of your testing. You can offer these up to the security folks as evidence of your fledging efforts.
5. Download an easily attainable source code scanning tool, and run it against your code. You should expect to see some false positives as well as results that might be hard to interpret. Again – this is not a substitute for a comprehensive security code review program but should provide some insights. As with the dynamic testing – save the results.
6. Benchmark your team against a software security maturity model, such as OpenSAMM. These models provide a comprehensive view of how security can be integrated into the software development lifecycle and can provide structure for prioritizing activities. Perform an informal assessment of your practices and save the results.
7. Reach out to your security team with the results of your initial efforts. Take the initiative in order to encourage activity on your schedule. Discuss the results of any code or application scanning as well as your informal maturity model assessment. This helps to demonstrate that you take their concerns seriously and helps allow you to control the conversation.
8. Move any vulnerabilities that have been identified into your defect tracking system so they can be prioritized and systematically addressed. Translating security vulnerabilities into software defects is an important step when integrating security into the development lifecycle.
9. Fix some of the vulnerabilities identified in your applications. Prove you are taking security seriously by picking a handful of the most critical vulnerabilities and fixing them. This is often the best way to demonstrate to security teams that you have heard their concerns and are willing to work to address them. Work with security to determine the most serious vulnerabilities to address first as well as what changes should be made in order to successfully address the issues.
10. Ask for input from the security team at the beginning of a new project or development effort. As with software defects, security vulnerabilities – especially those that stem from poor architecture or design – are much cheaper and easier to address if caught earlier in the development effort. Proactively requesting some guidance on threat modeling and coding standards can help avoid frustrating and costly late-project hassles.
Security teams need to know that developers have a lot of work to do and not all of it involves security. Conversely, development teams need to understand that the applications they build affect the security of their customers and organizations.
Contact us for help getting your develment and security teams working together.
--Dan
dan _at_ denimgroup.com
Comments