I recently found myself explaining how to take the first steps in an application security program to a good friend of mine who works at a mid-sized telecommunications software firm. For a small or medium-sized business, with highly-skilled technical staff, it can be difficult to dive in and immediately grasp the value of implementing a secure software development life cycle (SSDLC).
Critiquing the work of developers and architects can be a touchy matter. Approach the topic acknowledging that they’re busy people—busy people who will benefit from a helping hand to ensure that the software they’re creating is built securely. Let’s look at seven fundamentals of application security to help make that happen!
Discover the 10 reasons for a software security program, get a blueprint to build one, and receive a sample roadmap to kickstart the process.
I’m a firm believer that if you want something as critical as security done well, it needs to be somebody’s job to do it. All of the participating BSIMM firms have a specialist or specialized team responsible for application security. Depending on the size of the organization and the budget available, this could be anything from a part-time role to several specialized teams.
This may sound contradictory, but both are important. It’s all about planning for both the short and long-term. Don’t try to boil the whole ocean immediately—prioritize your applications (working through the highly critical applications first), set some measurable goals, and pilot some real activities to generate real results. This will showcase the value of application security, demonstrating a return on investment early and helping with future stakeholder buy-in.
Worthy goals involve reducing risk. It’s not enough to simply find some vulnerabilities. In order to show real improvement, they also need to be remediated. However, it’s also essential to keep in mind that taking steps to secure one application probably isn’t enough. In the long run, you’ll need a risk-based approach to your entire application portfolio. Anything too labor intensive won’t scale well, so keep an eye out for areas to automate and be realistic about the level of detail included.
Good application security is a holistic property of the application. There is no magic tool that can do it all for you. Much like other areas of quality assurance, the best approach is to combine different activities at different stages of the software development life cycle (SDLC). The areas to consider first are:
It’s generally easier to identify issues later in the SDLC (via activities such as penetration testing), but bear in mind that the cost associated with fixing them later in the SDLC is also higher.
Aim to identify issues at the earliest opportunity. Earlier detection will reduce the cost to fix the issue, and will reduce the time pressure on the developers and other implementing teams (not to mention that this could also avoid bad PR for the application security process). One of the most satisfying parts of my job is finding issues before they even become issues (perhaps in a conversation with the architect before they have even put pen to paper).
There is no one correct way to build an application security program. The most efficient way is to leverage existing processes and capabilities in your organization as much as possible. Does your organization have strongly enforced SDLC quality gates? Add some application security activities to them. Does development revolve around the CI toolset? Integrate some security tooling into it. Does your development team manage their time via JIRA tickets? Make sure you raise JIRA tickets for security bugs.
Application security is interesting! Take as many opportunities as you can to ‘spread the good word.’ It’s important to educate your stakeholders, but if you really grab their interest they might start to educate themselves and truly embrace your ideas. It’s great to show off any vulnerabilities you find in your applications, just be careful not to bruise any egos in the process.
Application security needs to be seen in a positive light. Don’t just highlight problems, propose solutions! If you know your organization and/or coding languages and frameworks well, you might know a better way to do things that will save time for the implementing teams. Educate your stakeholders as you go. Make sure they know how to avoid similar issues in future, encouraging a more efficient and effective process.
Sometimes a compromise is required when conflicts arise. Avoid allowing application security to gain the reputation of ‘blocker’ or to cry wolf at any opportunity. That’s a sure fire way to make people avoid it!
There will be many interesting bugs and flaws along the way, and you are likely to encounter some of them more than once. Once you’ve fixed something, keep a record so it can be fixed more easily next time. If you spend a lot of time getting an authentication system right, encourage its reuse within the organization. If you find a great resource online, bookmark it in a shared location so that others can read it too.
Growing an application security program is an interesting challenge; one that, with some careful planning and a bit of hard work, can achieve valuable results. Once you overcome the initial hurdle of making it somebody’s job, it can be built up step-by-step to become a valuable capability—potentially even a differentiator to your competitors.
Discover the 10 reasons for a software security program, get a blueprint to build one, and receive a sample roadmap to kickstart the process.