Make a new year’s resolution to get serious about software security
Resolutions are nice, but if want to get serious about software security, you can follow some basic steps on to turn your resolution into reality.
The original version of this post was published on SecurityWeek.
The beginning of any new year is a time for examination and setting new goals and objectives. Many of you understand that addressing the vulnerabilities in your software is something you can no longer ignore, and are ready to get serious about software security. Resolutions are nice, but if you are serious there are some basic steps on how to turn your resolution into reality.
Put someone in charge of software security
Pithy statements like, “Software security is everyone’s job,” may look great on a poster, but for real progress in software security, someone needs to be accountable and make it their mandate to create and drive a software security initiative (SSI). One sure sign an organization is committed to software security is the existence of a software security group (SSG) headed by someone who answers to management about how the organization is addressing software risk.
Making someone accountable brings several key elements to the process:
Drives activity. IT security is an extremely reactive endeavor. If someone in IT security has software security as a partial responsibility, just how much time do you think they will spend on that task once they are through with their firefighting duties? A dedicated resource will give software security their full attention, and will drive the activity needed to advance the cause.
Raises awareness to the next level. Headcount is a precious commodity in IT security. Committing one or more headcount to any area of focus immediately brings visibility. In some organizations, regulatory compliance requirements raise the visibility of software security to the next level. Regardless of how management gets software security religion, this awareness needs to be cultivated to ensure the SSI gets the support it needs to succeed.
Creates budget. Formalizing an SSI, creating an SSG, and raising awareness to the next level leaves management no choice but to fund the process. Having budget creates the opportunity to provision tools and services to meet the goals of the SSI. Once budget is provided and success can be demonstrated, more budget will be found.
Leave behind the “box checker” mentality
Many organizations run application security tests to fulfill a management mandate or to comply with some regulatory requirement. Once a test is run, the box is checked and it’s onto the next test. There is no attempt to review the findings, much less fix the key vulnerabilities identified.
The only way for your organization to address the risks created by the vulnerabilities in the software is to pass the results to development so they can apply the appropriate fixes. This may be a significant change in organizational culture as the IT security folks and the developers may not have a working relationship. Building the bridge is critical to making real change.
Challenge your application security testing (AST) vendor
Many organizations have been using the same AST vendor for a very long time. Many of you may have inherited long-term contracts that were signed by a predecessor. The reason for choosing your vendor has long been forgotten, and you have accepted, in the words of Pink Floyd, “cold comfort for change.” You continue to run the same tests at the same level and at the same frequency.
If you are going to get serious about software security you need to be sure that your vendors are going to be serious along with you. Challenge your vendors. Force them to become your partner in success rather than someone who simply runs tests. Actively question the status quo. If you don’t see results, try another partner.
This is especially true for organizations who are upgrading from “box checker” mode. Don’t think for a moment that application security testing vendors don’t understand the “box checker” mentality. They are more than happy to have you continue to run tests and not use the results, because checking the box does not put pressure on the vendor to produce accurate, actionable results.
