To Process or not to Process

There is a fine balance of people, process and technology when it comes to well rounded security programs. Have you stopped to think about the processes you use, the inputs and outputs and how they align properly to the people, teams and technologies? As the graphic shows processes drive every area of your program and describe the needed activities management approves of to accomplish business goals and objectives. People develop and follow processes along with create, implement and use technologies. Without each there is no balance and limited success usually. This is part 2 of 3 articles I'll publish with the follow up article named, "Technology - A Friend and Foe" and the previous published article, "The Human Psyche of Security".

I'll focus on the enterprise documentation lifecycle in this article. For the context of this article I'm going to differentiate between process and procedure. A process is an over arching high level workflow showing the interactions of people, process and technology whereas procedures are individualized "howtos" and step by step instruction sets that align to a process but by design accomplish one or more very specific tasks within a complete process.

Processes can show the workflow using a myriad of symbols (start, stop, decision etc.) and swim lanes to depict the teams performing the workflow along with more thorough descriptions of what, who, where, why and when its' performed. A procedure focuses more on how tasks are performed. Breaking this down further a process would articulate workflow for vulnerability management (what), the team performing the work (who) scanning performed daily (what & when), within the vulnerability scanning tools (where) to identify, triage, track, remediate and report on vulnerabilities (why). Within a single procedure to support the process it may define how to login to the tool, define a scan or what assets to include. A procedure can even define the entire end-to-end procedure to accomplish a scan from start to finish (how). Don't confuse a procedure for the documents your vendor provides though. A procedure can include, point to or reference vendor documents, however, a procedure is more specific to your environment to include your people, process and technology.

Since security touches all areas where data and information is processed within an organization you'll most likely have a good number of stakeholders and teams outside of security performing and accomplishing a complete workflow. This is where the complexity comes in play. Being Six-Sigma and CI trained along with building many security programs out I've seen many organizations fail to successfully link the inputs and outputs from one team to another.

The way I describe it is the teams who are responsible for their work stream own their part of the process and supporting procedure(s). What needs to be determined between stakeholders depicted in swim lanes is where the "DMZ" is and the manner in which xyz is delivered and handed off, what format is used and when it happens. In the cases were many stakeholders and teams are involved the process needs to be owned by their leadership. In most cases a final vetting and sign-off step is needed for leader awareness and buy-in.

As with many things in security there is a chicken/egg scenario and dilemma that comes into play. In this case, a well vetted over arching end-to-end enterprise process for developing processes is needed along with it's supporting procedures. This is the very first process in any organization that should be created and have executive buy-in since its the foundation of creating the complete SOP (standard operating procedure) stack for the entire organization. The questions to ask yourself are how agile can I be as I create the stack and what is my end capability and maturity levels I want to obtain and over what period of time.

If your organization desires to be in the 3 - 4 level range using the CMMI scoring method then it will be a larger project and take a longer period to accomplish and depending on the current level may take several years to fully accomplish. In these scenarios I recommend taking a risk based approach on determining the overall highest priority of processed to build out that minimize the highest and most important risk exposure. This approach would mean the second process to build out is risk management to include how risk assessments are performed. Once those are baked in then a risk priority list associated with the organization can be determined, prioritized and worked on with the appropriate teams.

So why even focus on process creation at all? There are many reasons beyond regulations, laws and best practices that warrant it. Companies spend millions of dollars on tacit and explicit knowledge, however, they don't always focus on turning tacit knowledge which is what's in someone’s head into explicit knowledge which is recording it in a manner where it can be shared. Implementing a knowledge management processes will help determine how this is accomplished, however, this is an entire topic on it's own. For now we'll just say part of the documented process method should clearly outline a central repository where the enterprise knowledge (explicit) is stored.

This is more than a file share or website and involves a good bit of thought around taxonomy, appropriate permissions, data requirements, searching capabilities, versioning control, vetting, how approvals are gained and tracked and finally a cadence for reviews for continuous improvement. Part of the review and continuous improvement should include testing procedures (auditing) of how supporting procedures are effective in accomplishing the defined processes and/or if improvements are needed for adaptability of changes in people, process and technology.

Here lies the main reason to create a well defined processes for process creation. The knowledge created is essential for sustainable, repeatable and adaptable processing of an organizations data and information to meet business goals and objects throughout the years. As this knowledge is handed down to teams from year to year a company must continue to improve their capabilities and maturity to stay relevant and profitable with decent ROI. If the history and knowledge of previous work can't be referenced, understood and leveraged easily and quickly the knowledge the process may be started over from scratch increasing the ROI and potentially creating confusion in the end result. This is why an organization should focus on ensuring tacit knowledge becomes explicit knowledge so supporting their intellectual property associated with all inventions, software, solutions, proprietary methods etc is retained and accessible.

So in closing the enterprise documentation lifecycle should include a well defined and managed end-to-end process for how process and procedures are created, vetted, approved, reviewed, stored and continuously improved on. A well documented process of processes will guide an organization throughout the years and the feedback loop will help ensure growth and opportunity for success over the years.