How to Raise the Level of AppSec Competency in Your Organization

Every organization needs someone with the authority to set up governance over data and the software portfolio. That person would also have a defined seat at the executive table, contributing to the discussion around organizational risk.

It may be up to IT and software engineering teams to create infrastructure, set access controls, create custom applications, and configure environments to be resilient to attack and protect data, but it's problematic to have those groups decide what "security”"means, how to do it, and whether they're accomplishing it. The bar for "how secure" must come from someone who stands for the business—and the CISO is an excellent choice.

Getting the right person in place and equipping him or her to be successful is the first step in raising the level of software security competence.

Understanding all the components of production software, including components brought in at build time, also is a foundational part of software security competence. So is having:

Hundreds of organizations now have formal software security initiatives (SSIs) that have taken them from a "penetrate and patch" mentality to a proactive approach. Raising the level of software security competency won't happen overnight, but it's not complicated, either.

Traditionally, software security teams implemented time-consuming testing, and engineering's waterfall and agile-fall processes mostly allowed time for it. The two teams usually coordinated well enough for each to do their job sufficiently, if not efficiently. Software security competency often focused on how many bugs the testing processes could find. That worked for those chartered with governance and risk reduction, but as software engineering began to rapidly evolve into agile processes, continuous integration/continuous delivery (CI/CD) toolchains, and a DevOps culture, that slow, bug-finding-at-the-end approach created unacceptable friction for the engineering group chartered with feature velocity.

In today's CI/CD and DevOps world, raising organizational software security competency doesn't mean using legacy security testing tools alongside engineering's new processes. It means integrating tightly with engineering to provide cadence-friendly CI/CD tooling and culture-friendly DevOps processes. It means taking all that "sec" the SSI learned over the years and making it fit in CI/CD and DevOps to create your organization's version of DevSecOps.

Of course, the SSI will still need solid fundamentals. Remember that software inventory? Does your inventory process still work when orchestration is bringing up and tearing down containers and virtual machines based with infrastructure-as-code automation? What about detecting in the SDLC whether required frameworks and APIs are being used correctly? There's no point in doing penetration testing on software we already know is broken because it was designed or built poorly; that can be detected and resolved very early in software development.

In a CI/CD and DevOps world, every organization must build good "observability," which is how well we can infer internal states of a system or process given its status or outputs. Good sensors tuned in accordance with nonfunctional security requirements and release acceptance criteria will tell everyone when the software is misbehaving, and the right people can immediately determine whether it's a defect, an attack, or something else.

If CISOs don't take the initiative now, their organizations will likely get into a variety of unproductive behaviors. Shadow IT groups will be doing cloud plumbing, shadow development groups will be creating glue code to make CI/CD tools talk to each other, shadow architecture groups will be making cloud blueprints that work but not securely, and so on. Once fielded, it may not be possible to unwind functioning, revenue-generating applications just because they didn't go through any security gates.

Every firm needs assurance that the CISO is enabling the rapid deployment of acceptably secure software, regardless of whether she can watch every part of every SDLC every minute of the day. "I need assurance that my software portfolio is appropriately secure at any given time" is a significantly more mature management proposition than "I must run this test on that software when it gets to the end of that process."

All stakeholders partnering so that everyone stays in cadence and improve together may be the greatest competency of all.

Related Content:

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.