A framework to vet security processes for human execution

Humans are simultaneously the biggest source of strength and the perennial weak point in any security program. The leadership of security includes things like awareness campaigns, advising and training in the wake of incidents, and doing user experience reviews on things like phishing tools to reduce the threat to the company.

For all of that, sometimes the tools and processes that we surround our teams and our organization with can be difficult to operate. The same security engineers and architects who often drive fantastic threat reduction may struggle to effectively adopt the end-user perspective as the products and technical flows or integrations are realized. Often, it is not until something triggers a security review in the business that these fracturing points surface.

Vet processes for human execution

Completing a security review for a business can have a lot of drivers. A technology or operations review could be driven by an internal or external audit. A supplier review could drive a fresh look for whether a new burden or commitment from the business or from the security team is created.

At Avanade, I had the chance to lead a multi-level team across multiple continents to serve customers around the globe. During a season where the team was handling multiple audits for one of our customer-facing commitments, we came to an abrupt realization: For some reason, my team was only capturing formally some of those reviews we were involved in at the company.

For some reviews, documentation was airtight and could be easily referenced. The feedback emails were in the hands of upstream teams, and the risk readiness was excellent and part of the next scheduled business discussion.

In other cases, stakeholders were languishing, and the clock was ticking on business related deliverables that needed security insight to determine whether to agree to a contract or add new controls in the business to compensate for new risk. When we surveyed business partners involved in these reviews, we often found a common thread: The people involved didn’t know either how to execute the process or how to complete the outcome documents/communications involved with their part of security reviews.

We realized as a team that even as our business’s next generation of alignment and support for global teams, and our customers lie in machine learning or artificial intelligence, the business is still operated by people. We had missed the human communication/experience audit to ensure that the humans could reliably participate in review.

Six Sigma to the rescue?

The security team must vet processes for human execution. Does the team know which conditions trigger the process? Are there processes that have a different start and can ‘fall back to’ or ‘get escalated to’ this process? What goes in? What comes out?

Originating in the manufacturing space, the Six Sigma methodology provides tools to improve the capability of business processes. Early applications of process defects in the 1920s by Walter Shewhart demonstrated that processes can function within a certain amount of variation but on average there was only about three standard deviations from the “ideal state” to the upper and lower bounds of what could be acceptable – at that point the process requires correction. Later refinements by Bill Smith at Motorola in the 1980s gave rise to the methods that we are more familiar with today to create high-reliability processes and remove defects.

In real-world day-to-day business, we must balance methods to manage quality with the real-world impact of doing checks, documenting outcomes, using that documentation, etc. Not to mention it’s often difficult to document in a dynamic fast-paced environment the specific statistics for how our security processes are operating, to define what the bounds of acceptable become.

As a result, Six Sigma tools are often perceived as overbuilt for security teams operating in a lean oriented environment, yet the lessons and specific tools from six sigma disciplines can offer a guide to improving broken processes. In our case, we realized that a building a review tool — like a SIPOC diagram — could be adapted to help look at individual processes. The benefit is that building such a diagram not only validates that the process is likely to work, the documentation created also provides a common reference for how to run parts of the security team that interact with outside organizations.

What is SIPOC?

SIPOC is an acronym that represents the key elements to help analyze the security process.

IDG

As a security design tool, helping teams think through the rigor of incident response processes, and sub processes using SIPOC ensured we had planned for how different processes interact. We knew what we needed from incident teams, we could ask the business to bring certain things to the table for an architecture review, or an incident report, or whatever other kind of process we needed to build.

As we built more experience with the tool, we realized that we needed to capture the inventory of communications that we expect during the process or at the process’s start and end. We might also need a list of assets that had to be built or exist to make repeatably delivering the security process possible. We also needed to build that into a common way of depicting this information on a single slide.

In our simplistic example below, we used the making of tea, but with a little imagination, any security leader can see the clarity this kind of tool has the potential to generate. What needs to be ready for a crisis response call? What gets generated? What are the triggers? Who consumes the data that comes out of it? Who needs to be a part of it? With really low effort, the team can check the process viability and have a shared view of what such key security processes require to be completed reliably in the business.

IDG

Building consistency doesn’t have to be hard

Frameworks abound in information security and the larger IT disciplines. Attempting to implement them completely, tools like Six Sigma can become overwhelming and drive just as much distraction as they build value. As a key maturity accelerator, security leaders can borrow individual assets such as SIPOC to enhance communication, speed reliability, and support the humans in the business, without committing to adopting every possible element of the discipline.

Building consistency and quality does not have to be hard or expensive. However, today’s leader has to ensure that the security interlock with the people executing the business is as clear as possible. Sometimes that means reaching outside the security discipline to tools which will enhance the risk management outcomes.