Is it possible for enterprises to consistently build secure applications? That was the overarching question during a recent dinner among some application-security-minded friends.
Some at the table didn’t think so. While I disagree, I do agree it’s not easy. And while most at the table focused on tools and processes (yes, those are important), I often argue that the most important aspect of building a development organization that has security adequately integrated into its processes is the business leadership being there to see that it is done. Only IT and business management have the ability to mandate that applications be built securely, to ensure that software vulnerabilities are handled like an application defect, and to fight for the proper resources.
That’s the only way business objectives, developers, security, and QA teams can all be managed to be on the same page. And this isn’t something development teams can do on their own.
Only then, after leadership is set, can the right processes be put into place and the secure application tool sets be put to full use. There is a lot of great material on the subject. Some places to look include IBM’s Secure Engineering Framework, Microsoft’s Secure Development Lifecycle, and the Open Web Application Security Project (OWASP), among others. eWeek also covered some of this subject in its recent feature, Secure by Design: Developing Apps Without Flaws Takes the Right Tools.
Here are the processes, based on many of these frameworks, that should be part of any secure application initiative:
The requirements and design phases. Before there is any coding it’s important to determine the security, regulatory, and privacy implications of the application. Will the app manage sensitive or regulated data? When that’s the case, the security stakes are certainly higher - and security needs be be part of the requirements. During technical design it’s important for teams to determine ways the app can be potentially abused or misused. For instance, if the app is connected to a database that contains sensitive information - that database and service will need to be looked at and potentially hardened - even if the app itself won’t be handling or displaying that information.
The building and coding phases. During coding, developers need to build as cleanly as they can, and avoid the mistakes that make invalid inputs, bad crypto implementations, and other defects and misconfigurations. Once again, OWASP is an ideal resource with the OWASP Top 10. During this phase, code should be regularly checked for functional and security defects. The work of developers also needs to be checked during the QA phase.
Application assessments. Ideally there are final checks before the app is sent to production. There are automated tools that help with these assessments, but they still should be performed by someone knowledgeable in application security.
Ongoing, continuous assessments. After the application is running live, it’s important that it - as well as all associated apps and infrastructure - is periodically vetted for security flaws. As applications and their supporting systems are updated, flaws have a tendency to creep in. This is another area where automated tools can help.
If you have a story on how your organization improved app security, we’d appreciate hearing from you.