To build secure software, integrate secure development practices into your existing software development lifecycle.
This article covers four general lifecycle areas: design, construction, test and vulnerability response. Developing secure software is complicated, but when broken down phase by phase, actionable plans can be created.
Design
Studies show that the cost of bugs increases drastically as the bugs progress through the lifecycle. This is especially true of security issues, which can be extremely expensive. Design-time security reviews, including threat modeling, can be very effective. Start simple. Identify assets. Identify the threats against these assets, then find mitigations against the threats. For example, configuration data is an asset. Loss of confidentiality or integrity of that data is a threat. The threat can be mitigated by using TLS to protect the data. Engineers and QA engineers should be involved and security test cases should be written based on the threats identified.
Construction
The design may be airtight, but the implementation may be poor. Use appropriate and effective tools during construction; peer review, unit testing, static code analysis, binary analysis, and enabling security features of the operating system (ASLR, stack protection).
Test
Consider each of the mitigations from the design review and write test cases that ensure design principles are not violated. Run one or more fuzz testing tools. Run any available security test tools against the software. Nothing is more embarrassing than a customer scanning their shiny new software and finding glaring security holes. Finally, consider running external penetration tests. Be sure to feed any vulnerabilities back into the lifecycle.
Vulnerability Response
This final phase is very important and cannot be overlooked. See my earlier article on vulnerability tracking. Define severity and policy in advance. Internal communication and external communication about vulnerabilities must be timely and correct.
A lifecycle is part of every development shop. Integrating security into each phase of the lifecycle will create a secure development lifecycle and greatly improve the security of the software.
Links to other articles in this series:
Jeff - Again, great article and your part about Vulnerability Response is spot-on and indicates the necessity I mentioned in my comment to your first posting...done by defining severity and policy in advance, which must be supported by 'the business' and upper management.
ReplyDeleteHopefully 2015 will be the year of Serious Software Security Assurance (SSSA). :)
Happy New Year!
Jeff, nice article, thank you. I agree that fuzzing tools are extremely useful and must be used. Though often the question is not just if such tools are used but if they are used sufficiently. In other words, how does one know if they fuzzed their software enough so that it would withstand some amount of abuse by attackers? Do you know of some methodologies for answering such practical questions?
ReplyDeleteBest regards, Apostol
I'm not an expert in fuzzing strategies.
DeleteFrom a practical standpoint, I just need to run more fuzzers than my attackers, but that's not generally achievable.
My personal theory is that rather than running one fuzz test suite for 100 hours, you should run 2 competing fuzzers for 50 hours or 3 for 33 hours (assuming you only have 100 hours to test, which is not a good way to test).
The theory is that different fuzzers will operate differently and catch different errors.
I'll write a future article on fuzzers. If I run across any good papers on fuzzing, I'll post them.
Thanks for the comment, Apostol.
Great, I am looking forward to it.
Delete