Many organizations are realizing the importance of application security, given that 73% of organizations have been hacked at least once in the past two years through insecure Web applications, but introducing an application security program to larger organizations can still be very challenging. However, there are key factors to the success of any application security programs that makes the task less daunting, We at Software Secured experience this challenge first hand as we try to implement application security programs in software organizations and federal departments. However, there are key factors to the success of any application security program that make the task less daunting.
A Federal Department enlisted our help to introduce a Software Security Program into their Software Development Lifecycle a few months ago. Walking into the Federal Department for the first time, we instantly felt we were in a different culture. The posters on the walls near the elevator were filled with internal language and keywords that reflect the business of this specific department. After several conversations, we could see that this department had a strong software architecture background. Software architects were empowered to make decisions: they could change the internal development guidelines and the internal software development lifecycle.
Understanding the internal culture was the key to implementing this whole program. Anchoring on the uniqueness of the internal culture improved the odds of success and encouraged the developers to jump on the wagon instead of holding things back. A major factor that helped in understanding the internal development culture was our assessment of some of the critical code that ran the organization’s business. Two or three applications later, we started seeing vulnerability patterns repeated in all the applications reviewed – common libraries and usagage patterns of these libraries. This discovery led to the creation of customized secure code-writing guidelines that targeted the insecure architecture patterns and insecure source code patterns found in the code.
We believe that developers are smart people who want to do the right thing. However, with deadlines, bugs, and the many meetings they have to go to, developers must prioritize to actually get things done. Buy-in from top management is key for the success of the implementation of a whole security program. Until security becomes mainstream, software developers will not apply security principles until they are asked to by top management.
Getting management’s buy-in is simple but not easy. Management understands only one language and this language contains one acronym: ROI (return on investment). While it might be challenging to show proactive ROI for software security (spend x and you will get 3x in return), it is definitely easier to prove a reactive ROI (you don’t spend x and you will lose 5x guaranteed).
Simplifying application security for top management and explaining how easy it is to solve several security issues is vital to having them on board. Point out that changing one line of code mitigates some of the most critical application vulnerabilities and you’ll have them convinced.
An organization with more than 400 developers can’t be altered by sudden and sweeping changes. The organization spends a great deal of money, effort, and time to streamline processes, empower individuals to get things done, and perform as a well-oiled machine. Introducing heavyweight security activities will send shockwaves into the organization and the program could be killed before it even starts. We used OpenSAMM, a model from the Open Web Application Security Project (OWASP), to introduce lightweight activities into the internal software development lifecycle. We also brought in sample templates of these activities, checklists, and guidelines for developers on how to do the activities, where to find help, and what activities look like when they’re finished.
When people listen to your presentation about what needs to be done in order to introduce application security to an organization, their first reaction will be to ask:
“How is this program going to affect my budget and my deadlines?”
“How much security do we need? Which security issues should I fix now?”
You need to be prepared for these questions and other similar ones. We even developed a simple tool that calculates the risk for each application type based on the organization’s risk profile so a project manager could instantly tell how long and how much effort would be needed to fix a certain vulnerability.
A very famous mistake people fall into is implementing security for the sake of security. At the end of the day, security is there to protect the business and not the other way around. Developers achieve business goals by writing code, and a successful program should make it as easy for developers to write secure code. Developers need to understand and have examples of what to do at each stage. Providing dead-simple tools to use and links for those who want to read more is a must for easy implementation of the security program.
Finally, organizations that are about to implement application security programs are up for a challenging task. However, understanding the internal culture, getting key leaders on board, providing nonintrusive ways to introduce application security into the organizations, and keeping software developers focused on achieving business goals is vital to the success of the program.