How to build a process around an application security tool

How do you ensure your application security tools are enablers rather than hurdles? By building application security processes around the tools you deploy.

October is Cybersecurity Awareness Month, with the theme “Own IT. Secure IT. Protect IT.” All month we’ll be publishing articles to help you integrate security into your organization and your development processes.

When is a tool not just a tool? When it becomes a roadblock. Every day, organizations roll out application security tools when they should be rolling out application security processes. By building a process around a tool, organizations are more likely to integrate the spirit of the process into their culture. After all, security tools should be security enablers instead of a hurdle to overcome on the way to release.

Find the leader

Big Corp’s new application security lead is Alice, who was formerly with Bob and Alice’s Crypto Solutions. After settling into her new position, she identifies a gap in Big Corp’s defect discovery capabilities and timeline. To fill this gap, Alice decides to procure and roll out a static application security testing (SAST) tool for teams to integrate into their build pipelines to better find security defects as the source code is being built.

However, instead of just rolling out a tool, Alice knows the 6 P’s of management: Proper Process Planning Prevents Poor Performance. Instead of simply airdropping the tool onto the dev teams, Alice sets aside some time to plan this application security process properly.

Scoping

The first stop Alice makes in her planning process is the application portfolio. Fortunately, Big Corp has a comprehensive application portfolio that ranks each application by risk ranking and other factors. The portfolio also includes helpful information about each application’s architecture, programming language, and team lead. From this, Alice can come up with a list of coverage requirements that the tool will have to meet.

In addition to budget information, which may include developer headcount and team count, Alice makes a note of the following items:

• External regulatory and internal business requirements that this application security process will satisfy
• Internal reference documents such as policies, standards, guidelines, and gaps or required updates that she will have to make to roll out this process
• Gap coverage for teams that may not be able to use the tool for technical reasons

Now that Alice has an idea of the size of the problem, she has a good idea of what the solution will have to cover.

Planning

Rather than letting teams feel out ways to use the tool (or ignore it) on their own, Alice takes some time to build guidelines around the tool. The guidelines cover:

• How often is the tool run? What triggers the tool?
• What artifacts will teams be expected to generate from the application security process?
• What other processes, tools, and security gates will consume the output from this tool?
• Which non-application security personnel will be needed to help with the tool’s rollout and maintenance?
• How will the developers be notified of this tool? What socialization channels will be used? These can include internal blog and newsletter articles, emails to distributions lists, presentations, and slide decks.
• What checklists or runbooks need to be created? What will they cover?
• What alternative processes are available for teams that aren’t able to use this tool?
• What metrics need to be recorded, and what should they say if the tool is meeting its intended goals?

In addition, Alice takes some time to draft updates to Big Corp’s governance to account for the tool. She also references the training plan to see if additional computer-based training or instructor-led training is needed before teams can use the tool and its results properly. Finally, she drafts a timeline and deployment plan for the tool.

Piloting

Now that Alice has a plan of attack for who will use the application security process and tool, she reaches out to teams that are representative of the organization at large. She meets with the team leads and explains the goals of the tool, the needs it will fill, and any requirements placed on the team by the tool. From there, she works with the team to roll out and run the process and solicits feedback on any shortcomings or gaps.

During piloting, Alice looks for the following from the teams:

• Feedback on how well the tool meets expectations
• Friction points that cause undue stress in the development process and suggestions on how to reduce friction
• Gaps and unanswered questions in the proposed documentation

Based on the pilot team’s input, Alice can finalize the guidance surrounding the tool and submit the required updates to Big Corp’s policy.

Deployment

During deployment of any new tool or process, Alice knows that she has to clear her schedule as much as possible. During this time, she works closely with team and project leaders to deploy the tool and respond to any growing pains. For teams that are less enthusiastic about application security processes, Alice works with leadership to set a compliance deadline and help guide teams toward meeting it.

Due to all the planning, during this phase, Alice:

• Socializes the process to senior leadership, management, and the development community
• Ensures that the updated governance and guidance is available to all who need it
• Helps teams meet the compliance deadline
• Is on hand to answer any questions and aid in resolving technical issues

Maturing

The best application security leads know that security is an ever-changing field. Alice is no exception and routinely reviews her entire program and the metrics it generates to ensure that her deployed processes and tools are continuing to meet their goals.

On a regular basis, Alice:

• Incorporates any changes that may be driven by corporate and regulatory requirements and standards
• Reviews documents to prevent them from becoming outdated as new versions of tools are released and used
• Solicits and incorporates feedback from the community
• Reviews both metrics and the sources of those metrics to ensure the tool continues to meet its goals

Conclusion

Simply purchasing and deploying an application security tool is not enough to ensure security. The most security-conscious organizations plan for success by building a process around a tool and deploying it in a way that best suits their environment. Processes help tools to be enablers and not roadblocks.