Undocumented Processes Result in Tribal Knowledge Dependency

Processes are developed within an organization to include practices and activities to meet objectives through the creation of multiple outputs. Some organizations operate with processes that are either ill defined or undocumented, resulting in inconsistent activities performed and different outputs of differing quality, depending on the individual performing the process. For example, if cyber vulnerabilities are scanned monthly using tool A by employee A and the highly critical vulnerabilities are patched, or fixed, within 7 days, this will provide different results than the employee B using tool B and fixing all vulnerabilities found within 60 days. It would be difficult to be able to articulate the risk posture of the organization if multiple approaches are implemented, as it would be dependent on the individual performing the work. The act of documenting the processes would uncover the use of Tools A and B in use as well and raise the question, “Why are we using two tools, training, and the need for integration to perform the same function?” The different results that come from multiple processes create different outcomes and increase risk.

Undocumented cybersecurity processes create an efficiency and effectiveness issue, as (1) it is assumed that everyone is doing the same thing each time, (2) the processes cannot be universally improved upon, (3) time is wasted communicating processes, (4) junior team members do not have the ability to learn from more senior knowledge of “best practices,” and (5) the wheel is reinvented again and again. The lack of documented cybersecurity processes and charts depicting who is responsible, accountable, consulted, and informed (RACI charts) lead to processes being missed, assumptions that processes are being executed when they are not, and uncertainty as to who owns the process and is accountable when the process fails.

Having well-defined processes is important for any business process, so why the particular attention on processes with respect to cybersecurity? The answer is simple: even the slightest failure in one of these processes can cause issues with confidential disclosure, availability, or data integrity of the systems in place to support the mission. In the above example (of not having a consistent vulnerability and patch management process), this could result in critical security vulnerabilities existing on the system that could be exploited by external hackers or insiders, or through carelessness. Executive leadership may assume that the processes are in place and they are being executed on a consistent basis, only to find out that the process was never implemented, the tool was removed, or the individual performing that task was pulled onto another project and no one was informed that the process was no longer being executed. Unnecessary duplication of software application tools and training costs also results.

Move Routine Actions to Operations

Information security personnel are more expensive resources relative to the computer operations areas that have been optimized for efficiency. Thus, these resources should be leveraged to design the most appropriate processes, with the view of moving these processes to a production operation as soon as possible, executed by less expensive resources. In the preceding vulnerability management example, most of the running of the vulnerability reports could be run by an external security operations center (SOC), or a managed security services provider (MSSP) that operates the process and patches the vulnerabilities according to the risk acceptance level and the priority established by the cybersecurity team designing the process.

This frees up the cybersecurity professional to focus on other high-value efforts versus spending time managing the “routine” operational work. The cybersecurity team could be focused on the exception reports or those cybersecurity items that need further analysis and other potential technology tools to mitigate effectively.

Components of the Cybersecurity Processes

Each of the cybersecurity processes has a life cycle by which the process is defined, created, monitored, updated, and subsequently retired. New technologies are introduced that may negate the need for a process or significantly alter the process. For example, a cybersecurity policy in the past may have required that sensitive files be placed on a network server and not on the laptop or desktop. A change to the process, by moving to a cloud storage provider with contractual backups or implementing laptops with encryption and backup software, may remove the need to store information on a central network server to ensure the contents are appropriately backed up on a regular schedule.

The cybersecurity process components would include the process description; identification of stakeholders (internal and external), goals, life cycle, and good practices (i.e., process practices, activities, work product inputs and outputs); as well as including metrics for achieving and monitoring the goals and ensuring the stakeholder needs are met.

Cybersecurity Practices and Activities

Enabling processes are developed from practices, activities, and creating detailed activities through increasing levels of detail. Practices are statements of action that develop benefits, provide the appropriate level of risk, and manage the appropriate level of resources to meet the business objectives.

An example of a security-specific practice to support the Manage Security Services process would be Manage Endpoint Security. This practice would ensure that endpoints (laptop, desktop, server, and other mobile and network devices or software) are secured at a level that is equal to or greater than the defined security requirements of the information processed, stored, or transmitted. Inputs to the process could include the information security architecture, service-level agreements, physical inventory audits, or reports of violations of security of these devices. These practices are somewhat generic and may be adapted for the needs of each enterprise. The organization also decides, through the governing bodies, which practices would apply, the frequency of the practice execution, how the practice is applied (manual or through automated means), and the acceptance of the risk if the practice is not implemented.

Cybersecurity-specific activities provide guidance to achieve the practices. Activities are, in short, the primary actions taken to operate the process. Each of the practices will have a set of either COBIT 5 activities or cybersecurity-specific activities to achieve the operation of the practice. Continuing the Manage Endpoint Security practice example, some of the cybersecurity activities may be to configure the endpoints in a secure manner, categorize the types of endpoints and the control needs, identify potential entry point targets of the endpoints, analyze the target attractiveness for each endpoint, implement network monitoring on devices, dispose of endpoints securely, and examine the history of attacks and compare against the current endpoint population.

These activities would be based on generally accepted and good practices. These provide a sufficient level of detail to achieve the cybersecurity-specific practice, would support definition of clear organizational responsibilities (i.e., RACI charts, governance structures), and support the development of more detailed procedures. Some processes may need to be more detailed than others depending on the criticality of the activity and the experience level of the group performing the task.

Different Types of Cybersecurity Processes Work Together

The processes need the input from other enablers to be effective. For example, processes need information as input and also provide information as output to other processes and enablers. The five domains of processes are (1) evaluate, direct, and monitor (EDM); (2) align, plan, and organize (APO); (3) build, acquire, and implement (BAI); (4) deliver, service, and support (DSS); and (5) monitor, evaluate, and assess (MEA).

Why Use a COBIT 5 Process Enabler Approach?

There are other approaches available for specifying cybersecurity control environments, such as NIST Special Publication 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations. The purpose of Special Publication 800-53 is to provide guidelines for selecting and specifying security controls for information systems supporting executive agencies of the federal government. The NIST model, in contrast to the COBIT 5 model, is very prescriptive in nature and may be overwhelming to many organizations. These are very detailed definitions and may be best used to compliment and help develop the organization-specific detailed activities to perform the COBIT 5 practices, which in turn, as indicated in the previous section, support the overarching cybersecurity process.

The Center for Internet Security (CIS) and the Centre for the Protection of National Infrastructure (CPNI) promote the Top 20 Critical Controls to provide a prioritized set of cybersecurity practices to reduce the risk of cyber attack. These are technical-based controls such as ensuring that accurate inventories of authorized and unauthorized devices are available, secure configurations are created, vulnerabilities are assessed and remediated, administrative privileges are controlled, and so forth, prioritized with increased level-of-control importance. The idea is that by mitigating these cybersecurity gaps the bar is raised for the external hacker to gain access. The controls are important, and this process differs from the COBIT 5 approach as there is less focus on development of processes to support the business objectives and the primary focus is on the technical controls that need to be implemented. These controls, as with the NIST 800-53 controls, are useful in building the detailed activities to support the processes and practices needed; however, the COBIT 5 process enablers are necessary to ensure the right cybersecurity activities are performed efficiently and effectively. These constructs are not readily apparent by using solely the Top 20 critical controls.

The ISO/IEC 27001 security techniques for Information Security Management Systems (ISMS) and the Information Security Forum Standard of Good Practice for Information Security can be used to supplement the processes of the five domains of the COBIT 5 for Information Security framework. The relevant guidance in these standards, along with the NIST 800-53 controls, has been mapped to the COBIT 5 Framework in the COBIT 5 for Information Security Appendices. Using the COBIT 5 framework and the associated processes provides the overarching governance and management assurance that adequate cybersecurity coverage exists from the governance and planning of cybersecurity activities through to the ongoing operation and measurement of the program.

So What Does CEO Tom Get Out of the Process Enablers?

Using the COBIT 5 process enablers provides a very holistic set of cybersecurity processes to manage the cyber risk management system. Once Tom has implemented these processes, it will be clear who in the organization is accountable and responsible for each of the governance and management practices supporting cybersecurity treatment processes, and who else needs to be involved to change or implement the process by being informed or consulted. Tom will have a clear definition of the cybersecurity governance and management practices necessary to achieve each of the cybersecurity processes that make up the cybersecurity program. Tom will also have assurance that the detailed activities are defined and based on good practices, leveraging those technical definitions defined by other standards built on good practices at that level. He will also have the comfort that processes are in place to ensure that the risks inherent in implementing technology have associated processes to mitigate the risk.

Moreover, Tom will have assurance that resources spent on executing processes will add value to the organization by creating cybersecurity- specific outputs used as inputs to follow-on processes, which, taken together, holistically support the business objectives of Tom’s organization. Continual review of the processes aids in making clear decisions on the cybersecurity priorities and those processes that need additional investment, or those that can be discontinued or moved to a lower cost of support. Tom will have an integrated program covering multiple processes to support the organization, people, and technology with metrics to measure the effectiveness and efficiency of the cybersecurity program.