Cybersecurity bosses are often overwhelmed by the expectations of myriad stakeholders. A set of fundamental security services and supporting processes is essential to enable Security & Risk Management (SRM) leaders to prioritize and meet the demands of stakeholders.
Key aspects
The requirements and expectations of a security program, including increased regulatory requirements, are continually evolving, forcing a more dynamic approach to security to keep pace with the changes.
SRM leaders struggle to identify the key processes and services needed to be able to demonstrate and communicate a minimum standard of due care to customers, regulators, auditors and senior management.
There is increasing pressure to demonstrate and communicate the value, efficiency and maturity of risk management leaders’ security programs, due to factors outside of their control, including economic factors, the expanding cost of security and risk programs.
Fundamentals of a modern security program
Security and risk management (SRM) leaders are under pressure to not only reduce risk in complex environments, but also increasingly to demonstrate and communicate the value, efficiency and maturity of their security program to a broad range of stakeholders with differing and evolving expectations.
A set of fundamental security services and supporting processes is essential to enable SRM leaders to meet a minimum standard of due care and balance the demands of their stakeholders, including the increasing expectations from customers, auditors, regulators and senior management. These processes and security services are the foundational components for the long-term success of the security program.
Why You Must Get These Processes and Services Right
The effectiveness of a security program can no longer be measured solely by the security controls implemented and its compliance with regulatory requirements. A modern security program must demonstrate a reduction of inherent risk. The expectations of stakeholders are pressuring the SRM leader to also demonstrate and communicate the effectiveness, efficiency and value of the program (see Figure 1). The program must be able to continuously improve, as well as rapidly adapt to changes in the business, technology and threat environments. This is made more difficult by increasingly dynamic regulatory and audit requirements, and adoption of modern IT delivery methods.
The Processes and Security Services Fundamental to the Success of a Modern Security Program
Figure 1. The Processes and Security Services Fundamental to the Success of a Modern Security Program
An SRM leader must be able to demonstrate an ability to assess, prioritize and implement a reasonable standard of due care to meet the divergent and evolving expectations of customers, regulators, auditors and senior management. This is made more difficult by evolving customer expectations (particularly around privacy and security of their personal information), increased regulatory requirements and ongoing upliftment in benchmarks of best practice.
There are certain processes and/or security services that are expected of all security programs by customers, regulators, auditors and senior management. These processes and/or security services are expected regardless of the industry, maturity of the organization or generally accepted standards and framework followed. The processes and/or security services discussed in this research are the most basic security practices that every organization must get right. They are included in all generally accepted standards and frameworks (see Appendix). Organizations that do not yet have these processes and security services documented and implemented will struggle to convince anyone that they are taking security seriously and that they have a mature security program regardless of their other capabilities.
This is not the full set of processes and security services required for a comprehensive and mature security program. However, they are the foundations that must be in place to meet even a rudimentary standard of due care. In other words, these are necessary but not enough for success.
The formalization of these processes and security services is also a prerequisite for effective security organization design. Many SRM leaders wrongly want to know what the “perfect” organization chart looks like, without first considering the processes and security services needed to reduce risk, demonstrate business value and meet the regulatory requirements specific to their organization. An understanding of the processes and security services required will provide invaluable insight into the organizational interrelationships that influence (and are influenced by) the security organization design. SRM leaders should focus on processes and security service maturity first, and only then focus on determining an organizational model in which those processes can drive greater benefits.
1. Implement Appropriate Governance to Ensure That the Expectations of Stakeholders Are Balanced Against Each Other
Security governance ensures appropriate decision rights that balance the diverging expectations of the security program’s stakeholders, including customers, regulators, auditors and senior management. Governance also substantiates the answer to this important question from stakeholders: “Is the enterprise doing enough?”
Security Governance
Governance is the most important element of a modern security program. Effective security governance ensures that the security program adequately addresses the expectations of customers, regulators, auditors and senior management while balancing the broader needs of the business within a finite set of resources. The other processes execute security, but governance ensures that the execution is successful and relevant. In simple terms, successful security governance is measured in terms of the effectiveness and efficiency of security in delivering business value and the defensibility of the program.
Inputs to the governance process consist largely of the outputs of other security processes and security services. The outputs of the governance process provide the authority (i.e., decision rights) inherent in other processes. This process requires effective collaboration between the security team and the lines of business to review these inputs, to assess business goals and risks, and to drive the direction of security accordingly. The outputs are the outcomes of governance meetings, such as key decisions, mandates, endorsements and commitments to provide resources to initiatives and issues that are tabled.
2. Define, Document and Deliver the Set of Core Security Processes and/or Services Expected of Every Security Program
Certain processes are core to the security of the enterprise. They are typically owned by the security and risk management leader. Some components of these processes may be performed outside the security team; however, this should be carefully governed and monitored by the security and risk management leader. All decisions regarding the effectiveness of these processes should be made by the security and risk management leader or a delegate in conjunction with the relevant stakeholders.
Any issues arising from flaws in these processes or their execution will rest with the security and risk management leader.
Security Policy Management
Security policies define and document the enterprise’s established position about the security risks that must be controlled to meet the risk appetite of the business, which will ultimately fund security controls and bear any residual risk. The fundamental purpose of security policy is to encourage positive behavior and discourage negative behavior. It is the first thing that an auditor, client and even regulator would request when conducting an assessment.
Successful policy outcomes almost always require a process of consultation and iteration before a final, sustainable policy position is drafted.
Effective security policy management requires the active participation of a broad range of stakeholders, including senior management, operational risk managers, line-of-business owners and security professionals (for example, via the governance process). The policy management process must incorporate development, approval, awareness, acknowledgment (for example, by users), compliance verification and exception management. If an organization has an existing policy management process, then the IT security policy and the information security policy may each be a discrete example of that process.
Awareness and Education
The security and risk management leader runs the risk of all other processes being ineffective, unless there is an effective awareness and education program. Enlightened awareness is achieved in part through education and aids in reshaping enterprise cultures that do not fully understand or appreciate the impact that inadequate security can have on all other IT and business processes.
Enterprises that conduct their security awareness activities as a process with behavioral change metrics are most likely to derive demonstrable value from them. This process is concerned with delivering knowledge to defined, targeted audiences to raise awareness of risks and to influence behavior and outcomes so that the likelihood of those risks being realized is minimized. The material must be specific to the outcomes that the enterprise requires, and it must be communicated in a form that is appropriate to the target audience. The outcomes can be measured through year-over-year scores — if the training content includes an assessment component — and by using behavioral metrics from other security controls, such as per-user event counts from data loss prevention (DLP) platforms, virus outbreaks, and records of lost USB devices and policy breaches.
Identity and Access Management
IAM encompasses the tools and best practices to manage identities and access across an organization to manage risk, reduce fraud and other losses and enable business imperatives. It is necessary to ensure that, among other things, each identity (including user and machine identities) has the minimum level of access to the resources that it needs (i.e., the principle of least privilege). IAM can also be used by the business to enforce and identify breaches of segregation of duties.
IAM is really a set of services: identity governance and administration (IGA), access management, privileged access management, authentication and authorization, and intelligence (i.e., audit and analytics). In many instances, operational elements of the IAM process may be performed outside the security and risk management leader’s team; however, governance and, therefore, ultimate ownership of the process may rest with the security and risk management leader, which is consistent with the broader security governance process discussed earlier.
Vulnerability Management
This is the process of identifying, assessing and resolving security weaknesses in the enterprise. Often, the focus is on the organization’s technical infrastructure; however, the security and risk management leader must also be alert to vulnerabilities in process weaknesses and other common staff practices.
With respect to infrastructure-related weaknesses, identification and, to some extent, assessment come from activities such as vulnerability scanning and penetration testing. Assessment requires knowledge of the technical implications of the security weakness and also of the business implications of exploitation of the weakness. The risk owner must then make a decision on how best to treat the risk.
The identification phase should occur during the architecture and design phase (for example, via security signoff criteria in project gateways), immediately prior to the equipment becoming operational (for example, as a step in the release management process), and at regular intervals throughout the operational life of the infrastructure.
Remedial action may range from detailed technical measures — such as the application of patches, or changes to the configuration of firewalls or other network-based vulnerability protection infrastructure — through changes to custom-made applications, and right up to very high-level measures, such as changes to processes or new awareness campaigns. This is an example of the interaction of multiple processes because technical measures taken to directly fix the weakness are likely to draw on the change management process.
Reporting metrics should include on-time frequency of identification exercises (for example, penetration test pipeline reports) and results from identification and assessment, including the number of issues and accumulated risks, and the tracking of remedial actions.
Security Monitoring
SRM leaders are responsible for ensuring the effectiveness of a significant number of security controls, with a large volume of data being generated from each control. It is critical to implement some form of security monitoring of these outputs, or else incidents will not be detected and remediated.
A fully developed security operations center (SOC) is not necessary for all organizations, and is out of the reach of many. However, basic security monitoring should be in place to get best effect from the controls implemented. For example, security monitoring should include at a minimum:
Basic log management — Organizations should implement a central repository for log retention to meet investigative and legal requirements and support some sort of reporting or analysis.
Security operations resourcing — At a minimum, organizations require a human resource be available to review and act on the information generated for security tools. Outsourcing is an option, and for organizations starting the security journey, a limited security service such as MSSP and MDR from a provider can provide a very useful way of uplifting some security capabilities quickly and simply.
Operating metrics — Targets, key performance indicators (KPIs) and metrics to measure and monitor how installed security controls are performing are essential to demonstrating the effectiveness of security controls.
Incident Response
Many enterprises will experience security breaches even if they have sound security practices. The extent of the damage from an incident largely depends on the quality of the response. It is, therefore, critical for the security organization to have a well-documented incident response process that has been successfully (and, if possible, repeatedly) exercised prior to an actual incident. There should also be defined and documented criteria for escalating the incident to crisis status, if the event presents a credible threat to the enterprise’s existence.
A quality incident response typically includes the following steps to successfully manage an incident: preparation, detection and analysis, response, and post-incident activities:
1. Preparation is crucial to effective incident response, but it is also extremely difficult, especially in complex, distributed enterprises. Adequate preparation means that:
You have already determined what your most critical assets are.
You are able to detect that an incident has occurred or is occurring.
You have a procedure in place to resolve the incident and manage the consequences.
The people involved know what their role will be.
2. Detection and analysis may occur via any number of means, such as unusual activity detected by a security operations center monitoring a security information and event management or DLP platform, or an unauthorized change to a device detected by a secure configuration scanning activity.
3. During the response phase, it is critical to decide on a strategy for containing the incident, eradicating the issue and recovering normal operations. The activities may involve disciplines outside the security and technical realms, such as line-of-business managers and risk, legal, media and contract management specialists. Roles and decision authorities must be clearly defined prior to an incident.
4. Post-incident activities and particularly learning from incidents are often neglected, but this is a serious mistake. Conducting a post-incident review to examine root causes, quality of response and a remedial action plan is essential.
Organizational Resilience: Business Continuity Management and Disaster Recovery Management
The ultimate goal for every organization should be to resist, absorb, recover and adapt to business disruption (whether security-related or otherwise) in an ever-changing and increasingly complex environment to enable it to deliver its objectives, and rebound and prosper.
Business continuity management and disaster recovery management are the essential building blocks to build this organizational resilience. These are separate but related processes. Many enterprises consider them to be separate from the security program, but they are essential to the security program.
Their purpose is to ensure that, in the event of a serious disruption to the enterprise, business operations can continue, and systems and processes can recover in a considered and orderly manner.
3. Ensure Security Is Embedded in All Processes Responsible for Implementing Change Within the Organization
Security and risk management leaders do not typically control the processes for implementing change within most organizations. However, the organization’s security posture is heavily dependent on effective change management processes to effectively manage risk from change. The risks to be managed include the risk introduced as a result of any changes and the risk of unnecessary rework and waste due to inefficient processes used to address risk early.
SRM leaders must ensure that security is efficiently and effectively involved in all the processes that typically introduce and implement change within organizations — especially since any failures that occur will reflect poorly on the SRM leader.
Change and Release Management
Documented and repeatable change and release management processes are critical to the enterprise’s ability to execute changes in a controlled and auditable manner. The processes are likely to be owned and run by the IT operations organization or increasingly the digital organization responsible for DevOps, but the security organization must be involved collaboratively. For example, the change and release management processes should:
Include security resources on change management boards and as mandatory change reviewers to ensure the security risks of changes are considered.
Prioritize changes to remediate risk and security concerns such as critical patches.
Include mandatory rollback plans and procedures to revert unsuccessful changes. Where possible, embed security tools in a modern, integrated toolchain to ensure that the security impacts of changes are assessed and remediated by default.
Provide the SRM leader with the authority in extreme cases to stop changes that would introduce unacceptable security risks to the enterprise.
Another example of the role that the security team may take is to validate change control or change activity by using configuration auditing or assessment tools to track changes and compare them with change requests.
IT Asset Management
IT asset management (ITAM) has evolved into a formal practice governing technology asset throughout the organization, and consists of the processes for tracking and governing changes in those assets.
At a minimum, an SRM leader requires IT asset management to be able to provide an accurate and up-to-date account of the technology assets in scope of the security program.
ITAM can also provide SRM leaders with an increased understanding of the business value and risks associated with technology assets. The growth of digital business and its plethora of component assets (e.g., Internet of Things [IoT]), emerging technologies (e.g., artificial intelligence [AI], automated tools) and delivery models (cloud, as a service) are forcing organizations to evolve existing ITAM practices to more effectively and proactively manage dynamic, hybrid technology environments and their rapidly expanding volumes and types of technology assets.
Project Life Cycle Management
Most enterprises have a standard project methodology in place, consisting of phase gates through which each project must pass on the path to completion. These techniques can be effective for risk management, but they can be perceived to slow down projects and programs. In contrast, agile teams use frequent customer feedback, received at regular intervals, to recalibrate teams and products.
To avoid introducing serious, expensive and possibly immutable security risks into the enterprise, it is critical to ensure that security resources are embedded in the project methodology adopted by your organization based on the risk and criticality of the project.
For example, the phase gate reviews may include the following (as deemed relevant to the project): formal security review of project documentation, formal security testing and signoff approvals from the security organization regarding the architecture, design and any other relevant artifacts, such as postoperational plans. In contrast, in agile methodologies, these artifacts and requirements will be reviewed and iterated throughout the project life cycle.
Procurement and Vendor Management
These processes may also fall under other various names, such as sourcing or supply chain management. Regardless of the name, the intent of the processes is to manage the procurement or sourcing of products and services from outside the organization itself and the ongoing management of the services from selected service providers (vendors) thereafter.
It is critical to ensure that security requirements are included in the procurement or sourcing process — particularly for technology products and software. These requirements could include broad compliance requirements like SOX, HIPAA and PCI DSS, but should be tailored to the products being sourced. In addition, most organizations now outsource at least some of their processes, and outsourcing inevitably results in the ceding of some security control to a service provider (vendor) and the introduction of supply chain risk. Cloud computing services are an example of this. The vendor’s processes must incorporate the enterprise client’s security requirements in a way that extends beyond unrealistic promises from the vendor, which amount to little action and less visibility. For example, the procurement and vendor management process for outsourced services should:
Conduct appropriate due diligence to assess the security posture and suitability of the vendor to securely provide contracted services.
Allow the client to assess the state of security based on reports that are delivered on time and in a format that provides transparency.
Compel the vendor to cooperatively take part in security assessment and testing exercises, such as penetration tests and incident response drills.
Compel the vendor to accept changes to client requirements, and to implement them in an agreed-on manner.
4. Use Risk Management and IT Score to Plan for Further Improvement
Effective security is a moving target. Modern security programs must be geared toward anticipating and reacting to frequent, unexpected changes in the business, technology and operating environments, and driving continuous improvement in the effectiveness and efficiency of security controls.
Organizations should also expect increased scrutiny from both regulators and auditors. Those organizations that do not yet have plans for ongoing improvement to their security programs struggle to convince regulators and auditors that they are taking security seriously and have a mature security program. As a result, they are exposed to a higher likelihood of censure.
Risk Management
Much of this research discusses the basic building blocks of a security program without the need for a risk management process; however, this approach will not be sufficient in the long term. It is incredibly important to establish at least a basic risk management process as early as possible. Getting the basic risk management process in place provides the foundation upon which prioritized improvements can be made. It also provides a structure to support change management and to track, document and respond to issues, such as the output of an after-action review.
A number of frameworks provide accessible risk management processes that can be easily implemented within an organization. These frameworks include NIST Special Publication (SP) 800-30, ISO 31000, ISACA COBIT and OCTAVE Allegro. See Figure 2 for an example process taken from ISO 31000.
ISO 31000 Risk Management Process
Figure 2. ISO 31000 Risk Management Process
There are three key activities within the risk management process that must be included as a basic starting point: context, assessment and treatment:
Establishing context is the most important step in the process. It involves understanding the business and identifying key processes, key systems and data sources, key personnel, and sensitivity to loss and exposure. Without context-setting, all additional steps lack the necessary foundation to be meaningful.
Once context is established, your process can then move to assessment. Risk assessment aims to understand the risk, its causes, its potential impacts, its level of acceptability and the possible options for managing it. Documenting these issues allows organizations to make decisions in the short term while establishing a long-term “memory” for ongoing risk management.
Finally, a treatment (or remediation) decision must be made, even if that decision is “do nothing.” A key consideration for risk treatment is ensuring that the risk assessment findings have been properly communicated to decision makers. See “Top Tips for Communicating Security and Risk to Business Stakeholders” for guidance on how to communicate risk and security issues more effectively. All outcomes must be recorded and tracked through a risk register, which can take many forms, from a spreadsheet to a full SaaS-based risk management tool.