Making Application Security More Than A Novelty

Talk to most people and they’ll say that appsec is about scanning. Yes, scanning applications for vulnerabilities is an activity that is related to application security. That said, from a program perspective, appsec scans may or may be achieving anything but, as a relatively new area of cyber security, those scans can be viewed as a cool novelty or a shiny penny by your cyber team or external stakeholders like application development teams or the compliance organization.

That said, a shiny penny is only shiny while it pushes forward your overall cyber security program. To keep appsec shiny, we need to move and mature into a program which is something beyond just an activity.

Pro Tip: Activity isn’t always “cyber security”…even when there is a lot of it.

When you formalize an activity such as application security into a set of measurable goals with a roadmap, current snapshot, resources, and gaps, now you have a basics of a viable program. And programs, not simple activity, push your cyber security program forward in a tangible, formalized way.

This may surprise you: an application security program involves (or should involve) a lot more than just scanning code for vulnerabilities.

So, if the most common application security activity is scanning, how do we think more broadly about appsec to formalize an application security program?

Remember The People: You may think that the foundations of a great appsec program arein its controls, coverage, and analysis. But appsec is really a people issue, not a scanning issue. This includes the people on your appsec team as well as the developers, architects, and testers that you will be influencing.

You’ll miss foundational program elements if the scope and analysis of an appsec program is limited to functionality contained within your code scanning tools. It’s the quality of the team members, its leadership, and their ability to influence other people that separates great application security teams from run-of-the-mill teams. The analysis, technical depth, and negotiation skills of the team supporting an appsec program focused on influencing external app development teams will ultimately determine the quality of your appsec program.

Take the time to hire right. Don’t settle here.

Assemble The High Level Program Elements: You’ll need the ability to scan but you’ll also need application security standards, risk identification, and controls around the key elements of the software development process — intake, build, QA, deployment, and production. All roll into an executve story of goals, roadmap, resources and gaps.

Tell that story as often as possible to anyone in the enterprise who’ll listen.

Engage Business Process Owners: While seemingly a technical issue that can be owned by the appsec team, the business process of application development has process owners outside of the cyber security team. This means that the day-to-day decisons that drive application security into the organization’s DNA are made by those process owners. Only the most egregious scan resulst might result in temporary action by the dev teams. For sustained change, you’ll need frequent engagement around the high level program and its current state before your activity and program outputs begn to influence the behavior that you’ll need from the app development process owners.

Understand What Needs To Be Secured: Besides the tools selection process, you’ll need to unravel a range of issues and controls unique to your organization. These issues might be technical or non-technical.

That previously mentioned great team will be on point to think through the the meat of your work….weaving their set of disparate activities (which are far broader than scanning) into an appsec that adds value to executves and process owners.

Some of those inputs may include the following:

• Source management organization and optimization for scanning
• Balance of CI/CD velocity vs. security capability velocity
• Developer security education and awareness
• Development of security specific epics and stories
• Review of functional stories at intake that potentially need additional security controls
• Other compensating controls for production hosted apps
• Program level metrics and additional reporting for OWASP, APIs, and beyond
• Sensitive data handling and risks by in-house applications
• Answering the executive question, “are the apps we build secure?”

and all sorts of other such things.

Be Tenacious While Remaining Collaborative: Nothing about governing previously ungoverned development teams is easy. Nothing. Then there is just plain normal resistance from often grumpy senior developers. They tend not to like shiny pennies unless they are their own. Embrace their sage wisdom and feedback. Plan for the pushback.

You can move beyond the novelty, pick up the shiny penny, and really make your application security program a broader security value-add.

That’s my two cents. What are yours?

For more insights into how cyber leaders can best enable the business and build rock solid cyber programs, please follow me on Twitter at @opinionatedsec1