Published 28 October 2022

Abstract

In our research reports, events, and consulting engagements, TechVision emphasizes that organizations must transform themselves into Digital Enterprises. In the wake of the pandemic, becoming a secure Digital Enterprise has morphed from being a “nice to have” to a matter of survival. It demands organizations develop agile and adaptive security programs and technology capabilities well-aligned to business and IT. Only though these capabilities can Digital Enterprises safely optimize responses to business opportunities, regulatory requirements, and changing IT environments or threat landscapes in today’s environment.

This report provides a Multicloud Cybersecurity Reference Architecture and guidance for digital enterprises. It contains business and technical views that security teams can customize to fit their specific needs. It describes high-level functional components and capabilities, maps them to industry-standard control frameworks, and identifies the business stakeholders to align with for the purpose of adapting to local conditions. This report can be used by security/risk teams and executive leadership to get a logical understanding of security capabilities, enable cross-functional alignment of security projects or activities, measure their effectiveness, facilitate compliance towards securely supporting the digital transformation of an organization.

 

Authors:

Dan Blum Principal Consulting Analyst [email protected]

 

 

Executive Summary

The TechVision Research Security Reference Architecture provides guidance on identifying the business security context for an organization, and for selecting and prioritizing security-related processes and functional or technical capabilities for the IT environment. It also maps the capabilities to NIST Cybersecurity Framework (CSF) controls for convenient linkage to IT Governance, Risk, and Compliance (IT GRC) and solution architecture management tools.

The Security Reference Architecture models both security-related processes and security technologies across digital enterprises’ multi-cloud and edge system IT environments. It identifies capabilities required to support distributed security systems; enterprise security operations and services; customers, partners, and suppliers; and the enterprise IT/OT environment.

The Business View of the Security Reference Architecture depicts the business context for the security program, security controls, and enterprise security infrastructure required for a Digital Enterprise.

The Functional View maps security-related technologies into those required for security management and control systems, security monitoring, incident response, vulnerability and configuration management, network security, identity and access management, and information protection. This view also shows the linkages to security-related processes, IT service management, and the enterprise IT/OT environment.

Clients can use the Reference Architecture to get a logical understanding of security capabilities, enable cross-functional alignment of security projects or activities, measure their effectiveness, and facilitate compliance as well as digital transformation of the business.

Introduction

Digital transformation is accelerating, demanding better security. The global response to the COVID-19 pandemic forced most businesses to send their staff home to “shelter in place” or shut down in-person operations such as malls, movie theaters, or manufacturing plants entirely. A great many of the business processes that continued operating did so only through digital processes and telecommuting. As CEO Satya Nadella famously said: “Microsoft has seen two years’ worth of digital transformation in just two months of its third quarter (January-March period).”

Digital transformation and remote work or digital delivery models demand more cybersecurity, not just because they mean “more IT” but also “riskier IT.” Technologies like mobile devices, social networks, cloud computing, artificial intelligence (AI), and the Internet of Things (IOT) have often emerged without adequate security built in. They disrupt existing security models built for older generations of technology. And as we rely more heavily on digital capabilities, this virtual world blends with physical and social realms into something new that raises risks. Just imagine digital outages or cyberattacks stopping elevators, crashing vehicles, starting fires, exploding pipelines, or turning off medical devices.

Digital transformation depends on maintaining a security program across all lines of business. The stakes have never been higher. For enterprises, cybersecurity is a fundamental requirement to realize the full benefits of cloud computing, mobility, and the Internet of Things (IoT).

In many of our research reports and events, we have described the compelling need for businesses to transform into Digital Enterprises. Being a Digital Enterprise emphasizes the requirement to be adaptive to the marketplace with enterprise-wide agility that optimizes responses to events, and opportunities. Business buyers and consumers are becoming adept at finding exactly what they want, and enterprises must become equally adept in finding, and aligning the people, knowledge and operating assets to match.

The digital transformation introduces an increasing number of cloud and device-based applications and services requiring both localized and edge computing environments in addition to large scale centralized IT infrastructure. IoT adoption creates a massively distributed and hyper-connected population of endpoints supporting interactive ‘read and respond’ smart services. Added to this mix are workplace changes from Collaboration and Social Tools and Drag and Drop composition of low-code and no-code localized business infrastructure by Line of Business managers all leading to an increasingly distributed enterprise.

This granular, orchestrated approach to providing enterprise IT resources requires carefully constructed risk management and IT governance capabilities. It also shifts the focus of protection from the data center perimeter to the individual resources themselves – no matter where they are located. These key trends will not apply evenly to every organization but can be a starting point to consider in assessing your requirements and future state architecture. Digital enterprises must be guided by the following principles for security programs:

1. Strategic alignment with business: Although executive decisions on business initiatives affecting IT in any way are driving information risks, cybersecurity still isn’t always considered strategic or well understood at the Executive and Board Levels. The Digital Enterprise requires security to be fully aligned with the business and IT culture, governance, and risk management processes through instrumented, quantified risk management programs.
2. Low friction security controls: Security programs must protect digital enterprise users, devices, and IT systems throughout the global multi-cloud and edge environment and provide a low friction user experience for end users, developers, and administrators. Key user-facing controls are transparent endpoint security and access through adaptive (aka zero trust) authentication and modern identity and access management (IAM) protocols.
3. Automated, intelligent security services: API’s and microservices are critical to developing and adapting the tools of the Digital Enterprise. Security services must be built into DevSecOps Continuous Integration / Continuous Delivery (CI/CD) pipelines through automated processes. Security practitioners must integrate their control architecture with distributed IT environments using standard interfaces/protocols and artificial intelligence and machine learning (AI/ML) capabilities. Pervasive AI/ML can support automation and control, not just for security analytics, but also for functions such as access certification, multi-factor authentication (MFA), micro-segmentation, and more.
4. Compliance-ready: Continuous compliance with evolving privacy and safety regulations within the businesses’ international and industry sector commercial and regulatory context.
5. Cloud-ready or cloud-native: With the digital transformation driving accelerated cloud migration, IT and security architectures must exhibit the five A’s: agentless and scalable, API-driven, platform-agnostic, automated, and accurate.
6. Cyber-resilient: Lay the groundwork for sustaining a robust security program in the face of business disruption through contingency planning, incident response, and business continuity / disaster recovery (BC/DR) programs. Anticipate and detect threats or risks and respond or recover from cyberattacks with advanced security monitoring and operations.

What are Reference Architectures?

Reference architectures are standardized frameworks or technology models for a domain, sector, or field of interest. Reference models or architectures provide a common vocabulary, reusable designs, and industry best practices. They are not solution designs and as such are not meant to be implemented directly. Rather, they are used to guide more concrete efforts. Typically, a reference architecture includes common architecture principles, patterns, building blocks and standards.

Intended Audience and Title: This Security Reference Architecture is intended for security architects and security leaders. Its formal title is the Multicloud Cybersecurity Reference Architecture, and we also describe it as a Business-Driven Security Reference Architecture. It can be used to create business views of architecture and selected artifacts from a customer’s work with it – such as a high level “target state” diagram – can be presented to business leaders. However, this document itself is not intended for direct consumption by a business-level audience.

Scope, or Level of Abstraction: Considering the broad scope of security programs and the technologies supporting them, we can understand reference architectures as tools to help develop the “Contextual”, “Conceptual”, and (in some cases) “Logical” levels of a full enterprise security architecture per Figure 1. It provides a very broad and comprehensive view of “how the pieces fit together” in security architecture. Those “pieces” aren’t just technology capabilities but also people and process ones. Thus, it depicts how the security program will work at a high level. It indicates what technology components are to be used. But you’ll have to go a level deeper in logical or solution diagrams to fully map out the implementation phase.

Figure 1: A Simplified View of Enterprise Security Architecture

Source: The four levels of enterprise security architecture are derived from Enterprise (EA) models and the Sherwood Applied Business Security Architecture (SABSA). ^[1]

Five Reasons to Use a Security Reference Architecture.

Why would you want to use a reference architecture? Here are five reasons why adopting a security reference architecture is a good thing.

1. It helps you to get a logical understanding of security programs and technologies. It provides a structure for taking your architecture governance model to the next level of detail regarding security. And it empowers customers with a vendor-neutral way of describing and specifying their security requirements.
2. It supports digital transformation. For many enterprises, transformation means their value chain is being redistributed among partners, service providers, and customers. If all parties speak the same language, use similar architecture frameworks or standards, and recognize the same boundaries between functions, processes and/or services, it will be much easier to relate or recombine their elements in new ways.
3. It encourages cross-functional alignment. It does this by enabling security teams to agree with business and IT stakeholders on the business risk justification and functional requirements for a future state capability, its interfaces, and concept of operations in advance. The architecture or design of any controls can also be tuned to meet all stakeholders’ assurance, compliance, usability or productivity, market, and customer needs.
4. It facilitates measurement. Often, the differences between companies or lines of business (LOB) are not in the design of their security-related processes, but in the execution. Using reference designs makes it much easier for customers to define for themselves “what good looks like,” and to compare progress and execution results with others.
5. It is important for regulatory compliance. Often, reference architectures are prescribed (or at least strongly recommended) by regulators. For example, in the EU General Data Protection Regulation (GDPR) privacy protection principles, practices and processes are standardized and mandated. This leads to audit requirements and business reporting standards that are supported by a proper reference architecture.

The Multicloud Cybersecurity Reference Architecture

The reference architecture models the security-related processes and technical capabilities needed to meet current and future state business and IT requirements. It provides a high-level business view of the capabilities as well as more detailed functional views. Within these views it embeds additional views that show the high-level relationship between cybersecurity and the:

• Business and regulatory context
• Information technology (IT) capabilities
• Security programs and technologies

 

The reference architecture describes security people, process, and technology capabilities in terms of control domains that are mapped to the NIST Cybersecurity Framework. Also, we provide a Business Alignment Framework to associate capabilities or controls with security-related business roles and responsibilities within an organization. Figure 2 illustrates the overall structure of the reference architecture.

Figure 2: Overview of the Multicloud Cybersecurity Reference Architecture

A Business-Driven IT and Security Reference Architecture

Figure 3 illustrates how the business context relates to the IT and security program capabilities required for a Digital Enterprise. This includes:

• The business strategy, regulatory, risk, and capabilities context within which the organization’s IT environment exists, and the security program operates.
• The enterprise executive, governance, administrative functions that control the security program, or with which the security program must align.
• Defined and authorized security program, governance, and risk management processes overseeing security policy, controls, and awareness.
• The global, multi-cloud and edge IT presence that provides all business IT capabilities for workforce users, business processes, customers, suppliers, partners, and the enterprise IT/OT resources.
• Distributed security capabilities (represented by the dark green squares in Figure 3) indicate the logical location of security controls through the hybrid multi-cloud stack (aka “digital estate.”)
• The enterprise security operations and services as well as security control systems needed to provide centralized, or logically consistent, management over the distributed security capabilities.

Figure 3: Business-Driven IT and Security Reference Architecture

Business Context

An organization’s IT environment and security program always operate within a business context. Context can differ across vertical industries, national cultures, and it changes with business strategies and capabilities. For example, a traditional bank in a developing country operates very differently from a fast-growing retailer in the same country, and both bear scant resemblance to a large or mid-sized business or IT service provider in the U.S. Yet all have the same kinds of security objectives related to maintaining availability, confidentiality, integrity, privacy, and safety.

Enterprise Executive, Governance, Administrative Functions

These functions control the security program and/or the security program must align with them. For example, the Chief Counsel’s Legal organization typically sets the direction on privacy law compliance programs which can have significant impact on security policy and operations. Business and IT governance or administration functions control Enterprise Architecture and the Software Development Life Cycle (SDLC). They also should influence and be aligned with enterprise security policy and architecture.

Security Program – Methods of Control

Security programs exist to manage risk in large part through people, process, and technology controls. Figure 3 identifies:

• Technical control, including the ability to actively control the operation of IT resources
• Monitoring (detection only) controls
• Data level controls: Controls on the data itself
• Awareness and training controls: Controls or programs to influence people’s security-related behavior
• Contractual controls on employees, contractors, third parties, and other stakeholders

External Users and Devices

Includes partners’ users and their devices, customers and their devices, and Internet of Things (IoT) devices that the enterprise interacts with but doesn’t employ, sell, own, or manage.

Global Multicloud and Edge IT Presence

Provides all business IT capabilities for workforce users, business processes, customers, suppliers, partners, and the enterprise IT/OT resources. Consists of:

• Workforce users and devices (some managed, others unmanaged bring-your-own-device (BYOD) equipment)
• Enterprise applications and collaboration systems
• Enterprise Data Centers containing physical and virtual servers and networks as well as storage and data
• Public cloud services from cloud service providers (CSPs)
  • Infrastructure-as-a-service (IaaS) environments
  • Platform-as-a-service (PaaS) environments
  • Software-as-a-service (SaaS) applications
  • Note: Business Process-as-a-Service (BPaaS) and other AASs such as identity-as-a-service (IDaaS) aren’t shown, but are important variants or specialties of the main three CSP delivery formats
• Enterprise IoT resources such as industrial, medical, or transportation devices; remotely managed devices sold to customers; and office devices such as printers or projectors.

Distributed Security Capabilities

The small green squares within Figure 3’s global multicloud and edge IT presence box denote the logical location of security controls throughout the digital estate. Such controls may take the form of agent software, plug-ins, or shims but can also be provided by instrumentation built in at the native solution layer. For example, APIs or standard interfaces can expose native security functionality at the OS, application, or cloud solution layer for enterprise security control. This enterprise security control of the distributed security capabilities comes from the big green boxes, or the enterprise security operations and services described next.

Enterprise Security Operations and Services

Includes security teams, processes, and equipment as well as security management and control systems that provide centralized, or logically consistent, management over the distributed security capabilities in the global multi-cloud and edge IT presence. Some of the major security management and control systems at the business level include:

• IT Governance risk and compliance (IT GRC) and Security Information and Event Management (SIEM) through which the business obtains risk, compliance, incident, and situation reporting that can translate security policy into operation and deployment.
• System, vulnerability, and configuration management controls that protect endpoint devices, business applications, and compute infrastructure.
• Identity and access management (IAM) and directory services that control accounts, credentials, security-related roles, and permissions or privileges through the digital estate.
• Cloud networking and data center perimeter security that demarcates logical or physical boundaries for enterprise resources, and controls and monitors network traffic flows.

Security Architecture and Control Frameworks

It is important for any Security Reference Architecture – which operates at the conceptual or logical level – to align with industry standard risk management and control frameworks. Because IT GRC tools also reference these frameworks, the frameworks can serve as linkage, or integration points between the Security Reference Architecture and security solution level architectures such as Active Directory domain designs, Splunk log collection and normalization schemas, Kubernetes and Docker container deployment patterns, etc.

Figure 4 identifies 20 functional control domains used in the Security Reference Architecture and maps them to the NIST CSF control categories. The NIST CSF in turn maps these domains to the ISO 27001^[2] and 27002^[3] standards as well as to NIST’s own drill down on control standards (NIST 800-53)^[4] and ISACA’s COBIT.^[5]

TechVision Research customers using any of these control frameworks can in turn map from the Security Reference Architecture to their IT GRC tools (from RSA, IBM, SAP, ServiceNow, MetricStream, etc.) or solution architecture management tools such as PlanView or Flexera.

Figure 4: Security Reference Architecture Functional Domains

Source: Adapted from Figure 7-1 in “Rational Cybersecurity for Business” (available for complimentary download)^[6]Chapter 6, “Establish a Control Baseline” explores a similar control model from the business alignment perspective in detail.

Selecting and Aligning Controls

Table 1 maps selected business-level capabilities to functional security domains and the high-level NIST CSF controls. Additional business level capabilities are described as security-related processes in a subsequent section. Note that each NIST CSF control is tagged with the following category coding from the CSF model: ID (identify), PR (protect), DE (detect), RS (respond), RC (recover). Also, because aligning security controls with the business at the governance level is just as critical as getting the technology right,  Table 8 in the Business Alignment Framework section provides a detailed mapping from key business stakeholders to each functional control domain. TechVision Research clients can work with the Reference Architecture and Table 8 to make the connection from architecture to operations.

Business-Level Capability	Functional Domains	NIST CSF Controls
Interpreting the business regulatory and risk context	Security governance, risk management	·      ID.GOV: All 4 controls ·      ID.BE: Business environment ·      ID.RA: Risk assessment ·      ID.RM: Risk management ·      ID.SC: Supply chain risk
Organizational policies	Security policy and awareness	·      ID.GV-1: Organizational policy ·      PR.AT: all 5 Awareness and training controls
Contractual control	Third party (vendor and supplier) management, Secure HR practices	·      ID.SC: Supply chain risk ·      PR.IP-11: Cybersecurity included in HR practices

Table 1: Business-Level Security Controls Mapping to NIST CSF

The next level of the Security Reference Architecture shows security-related process and technology capabilities in greater detail as illustrated in Figure 5 and 6.

Security Related Processes

Security programs must be provided through security-related processes and coordinated through their own Security Program Management process and tools. Figure 5 diagrams key security processes that support or drive the technologies shown later, in Figure 6. These processes are highly inter-related. For example, Risk Management assesses some of the business’s top risks by analyzing risks to its most critical assets as identified in a Business Control Management (BCM) Business Impact Assessment’s (BIA) inter-dependency analysis. The BIA sub-process, in turn, cannot be performed without obtaining input from the Asset Management process or system.

Figure 5: Security-Related Processes View

To make the linkage between security-related processes, functional control domains, controls, and stakeholders:

• Table 8 in the Business Alignment Framework section maps each functional control domain to the types of business stakeholders that, in many organizations, must be engaged in planning and delivering the required capabilities.
• Table 9 in the Business Alignment Framework section maps the security-related processes into functional control domains.
• The subsequent section – Functional View of Technologies and Capabilities – map the functional control domains to NIST CSF controls.

Functional View of Technologies and Capabilities

Figure 6 provides a functional view of security-related technologies or capabilities. This view is similar to a Technical Reference Model in an EA framework.

Figure 6: Security Reference Architecture Technology View

From this level, practitioners can navigate deeper into the functional requirements for:

• Distributed security controls throughout the multi-cloud environment
• Enterprise security operations and services
• Security management and control systems for
  • IT risk and security service management
  • Real-time threat, anomaly, and control deficiency monitoring and analytics
  • Host security, vulnerability, and configuration management
  • Risk, compliance, and incident reporting
  • Network and data center protection
  • Application security
  • Information protection
  • Identity and access management (IAM)

Distributed Security Controls throughout the Multicloud Environment

Distributed security controls are required to protect the multi-cloud environment at all points. They are managed by third party service providers, decentralized IT teams, business units, or users but can also be inventoried, monitored, or even directly controlled through local APIs or interfaces from the enterprise level.

Digital enterprises must make architectural decisions about when to insert enterprise-level controls into the multi-cloud environment and/or how to manage or instrument native cloud and OS-level security controls.

The families of distributed security controls used throughout the digital estate include:

• Unified endpoint management and security
• Compute infrastructure security
• Enterprise application and collaboration system security
• Information and storage level security
• Enterprise IOT security

Unified Endpoint Management (UEM) and Security

Workforce users and devices comprise the population of technical endpoints serving the people and needs of the organization. At the business level, organizations must clearly define the scope of endpoints to be managed (i.e., PCs, Macs, smartphones, tablets, virtual desktops), acceptable use policies, BYOD policies, and a user awareness program.

Figure 7: Security-Related Processes and Technologies for Workforce Users and Devices

The core technology capabilities required to deliver UEM and security include “UEM suites” and/or point products in the endpoint protection platform (EPP), endpoint detection and threat response (EDTR), mobile device management (MDM), mobile application management (MAM), and virtual workspace management categories. System, vulnerability, and configuration management solutions provide host security posture discovery, validation, and updating via agents or remote interfaces. Enterprise security operations continually monitor for threats on endpoints, and when they locate one that can’t be routinely controlled through EPP or EDTR services, manage the remediation via incident response.

To manage risks from endpoints to the resources they access, endpoint security capabilities must integrate with IAM solutions to enforce access controls throughout distributed environments (aka zero trust). To enable user productivity in a growing number of remote working use cases, they must field management and security tools with a low friction user experience. They must also support an expanding scope of devices, including many in the IOT environment.

Compute Infrastructure Security

Digital enterprise compute infrastructure security must span enterprise datacenters and public cloud IaaS environments. At the business and IT level, organizations must define compute infrastructure policies, standards for the scope of supported operating systems and infrastructure platforms; services to be provided; the operations reporting structures, processes, and procedures; and the high-level environment definitions (i.e., production, quality assurance, test, development, and environment separation requirements).

Figure 8: Security-Related Processes and Technologies for Compute Infrastructure

The core technology capabilities required to deliver compute infrastructure management and security include virtual machine and container workload orchestration, perimeter micro-segmentation and secure data center networking, service account discovery and authentication (secrets management), and privileged account management (PAM).

Digital enterprise compute security in the cloud era must be modeled on the DevSecOps paradigm where lean DevOps teams utilize security tests and reporting or protection tools that are “baked in” to orchestration capabilities and agile processes. It must also take DevSecOps into increasingly serverless and model-driven hybrid IaaS/PaaS compute platforms as well address increasingly diverse software supply chains and open-source software delivery.

Enterprise Application and Collaboration System Security

Enterprise application and collaboration security capabilities for workforce end users must align closely with UEM and workspace management solutions. They must be delivered using the same or similar tools and also provide zero trust access and low-friction operation. Collaboration security capabilities must be compatible with the organization’s Secure Web Gateways (SWGs) and Secure Email Gateways (SEGs).

Figure 9: Security-Related Processes and Technologies for Applications

At the business and IT level, organizations must define enterprise application and collaboration requirements, policies, vendor management processes, architecture, and interface standards for commercial off-the-shelf (COTS) and SaaS applications serving the scope of supported users (i.e., workforce, consumers, business customers and suppliers, and external service endpoints). If the business also develops complex applications, it must define software and security development life cycle management (SDLC) standards for them and tie them in with DevSecOps processes discussed for compute infrastructure security.

Organizations should also instrument applications for security monitoring and for vulnerability and configuration discovery, management, and updates to control software defects and keep the applications aligned with enterprise application security standards, such as those requiring use of Transport Layer Security (TLS) 1.3, Secure Hash Algorithm 3 (SHA-3), or OAUTH 2.0 standards and any related profiles. Use component life cycle management (LCM) processes and software bill of materials (SBOM) tools to automate configuration management and discovery without unduly impeding agile development processes. Use DevSecOps processes and tools for Static and Dynamic Application Security Testing (SAST/DAST). Conduct periodic penetration testing. When application environments still have known weaknesses or can be made available with limited exposure, use secure API gateways and Web Application Firewalls (WAFs) as compensating controls.

Data and Storage Level Security

Digital enterprises have massive quantities of data and storage. Some of it is provided as a shared resource available to all authorized enterprise users, systems, or applications, and some is embedded in local systems, such as a local hard drive or an AWS instance’s elastic block storage. Security capabilities can be provided from or instrumented into systems for both shared and embedded storage.

Figure 10: Security-Related Processes and Technologies for Storage

At the business level, organizations must determine the availability, integrity, confidentiality, privacy, and safety requirements for their data and the systems, applications, and services hosting it. Business continuity and disaster recovery (BC/DR) requirements can specify high availability solution patterns (e.g., add on load balancers and backup systems) or hardware specifications for systems hosting data and dedicated storage systems or services.

Additional core technology capabilities are required to deliver data confidentiality, integrity, and privacy. These include cryptographic capabilities in the dedicated storage systems and services and/or applications and systems with embedded storage. These capabilities can be instrumented through information protection solutions such as enterprise key management. Tokenization provides an alternative to encryption for confidentiality.

Enterprise IT/OT Security

Increasingly, businesses in many vertical industries use, sell, or service intelligent devices (“things”) that need to be monitored and controlled just as much as users’ endpoints or ITs’ servers. Examples include factory, power plant, mining, or transportation controllers and sensors; medical devices; and office devices such as printers or copiers and all manner of consumer devices.

Figure 11: Security-Related Processes and Technologies for IT/OT

At the business and IT level, organizations must define enterprise requirements, policies, supplier management processes, architecture, and interface standards for enterprise IOT devices. If the business also sells or services consumer devices and/or specialized devices or office devices, it must provide IOT licensing, tracking, monitoring, and support capabilities as well.

Required technology capabilities include device-level security software, firmware, or interfaces for discovery, tracking, log collection, secure networking, local account management, and/or data encryption. These controls can be similar to those aboard general-purpose computers (i.e., for IOT devices built on Linux, Windows, or Android) or may be unique to more specialized devices. Often its desirable to push security capabilities for a type of IOT device into a local IOT gateway, or to register devices with a specialized security service in the cloud, rather than adding to the architectural complexity, power consumption, or servicing requirements of the devices themselves.

Selecting and Aligning Controls

Distributed security capabilities require various controls in each layer of the stack. Many of these controls overlap or coordinate with the enterprise-level security controls. For example, networks, devices, servers, and applications have IDs and credentials which may controlled from Enterprise IAM, or just synchronized to it. Also, Security Operations groups often rely on, or oversee, IT Operations groups. Table 2 identifies the high level NIST CSF controls for security operations and services from the technology perspective, and Table 8 also provides a detailed mapping from each functional control domain to the key business and IT stakeholders involved.

Distributed Security Functional Control Domains	NIST CSF Controls
Asset management	·      ID.AM-2: (Discoverable for) Asset inventory ·      ID.AM 1-6: Physical systems, software, applications, data discovered and assigned resource owners ·      ID.RA-1: Identity asset vulnerabilities ·      PR.DS-3: Assets managed
Network security	·      PR.AC-5: Network segregation ·      PR.AC-7: Device authentication
Authentication, user account management	·      PR.AC-1: Manage ids, credentials ·      PR.AC-7: User authentication
Data protection	·      PR.DS-1: Data-at-rest protected ·      PR.DS-2: Data-in-transit protected ·      PR.DS-4: Adequate capacity
Application security	·      PR.AC-5: Network segregation ·      PR.AC-4: Access control (for applications) ·      PR.DS-7: Separate development from production ·      PR.IP-2: Implement secure SDLC
Real time threat detection (endpoints, servers)	·      DE.CM-1, 4, 5, 7: Detect malware, unauthorized mobile code, suspicious network activity ·      DE.CM-6: Monitor external services
Logging and log review	·      PR.PT-1: Logging and log review (review or collect logs for all resources)
User account monitoring	·      PR.AC 1, 4, 6, 7: Capture user and access management events ·      PR.PT-1: Audit logs collected per policy
Backup and data recovery	·      PR.IP-4: Backups ·      RC.RP-1: Recovery plan executed

Table 2: Distributed Security Capabilities Controls Mapping to NIST CSF

Enterprise Security Operations and Services

Digital enterprises must provide security operations and services across the distributed multi-cloud security fabric:

• Security, risk, and compliance monitoring
• IT Service and change management
• Incident response

Figure 12: Security-Related Processes and Technologies for Operations and Services

Security, Risk, and Compliance Monitoring

These security reference architecture capabilities include

• IT Governance Risk and Compliance (GRC), also known as Integrated Risk Management (IRM)
• Security Information and Event Management (SIEM), Managed Security Service Providers (MSSPs), and Security Orchestration, Automation, and Response (SOAR)
• Interface to security monitoring capabilities in other functional domains such as automated vulnerability risk assessment tools, network traffic analysis, Data Leakage Protection (DLP), and user or entity behavior analytics (UEBA) or other identity monitoring solutions.

IT GRC or IRM provide strategic or operational risk registers which can be instrumented to send and receive information to and from vulnerability management and other processes, compliance reporting, and third-party risk management. Third party risk management should also provide a global representation of the shared responsibility models between security operations, business units, CSPs, and other third parties.

SIEM systems comprise the nerve center for the security operations center (SOC), which may also leverage MSSPs. They can use artificial intelligence (AI) and machine learning (ML) capabilities in security analytics and send and receive information to and from security monitoring and response capabilities such as adaptive user authentication, PAM, DLP, and incident case management.

IT Service and Change Management

IT Service and Change Management includes capabilities for IT service management and change management requests, tickets, and workflows. It also includes asset discovery, asset inventory, and asset management. The Configuration management database systems (CMDBs) can serve as a source of truth for IT assets. It should have strong integration points with risk management via asset risk profiles and associated workflows as well as with incident case management.

Incident Response

Incident Response provides the ability to respond and recover from detected cyberattacks and other abuses of IT systems and information. It uses incident case management systems to manage incidents according to contingency plans, response plans, or incident playbooks. It coordinates closely with security monitoring, can use SOAR capabilities for automated responses, and may perform threat intelligence sharing to obtain or provide support from vendors, industry sector communities, or law enforcement.

Disruptive trends: Digital enterprises face continued challenges building visibility and control points into the multi-cloud environment including mobile devices, enterprise IT resources, CSP management consoles, and distributed security capabilities. They must also:

• Instrument integrated risk management (IRM) tools and processes into the security monitoring, asset management, and other IT and security functional domains so as to have enough real time data for quantified risk scenario analyses and to inform the operation of risk-based controls.
• Use AI/ML-enabled and/or anomaly detection capabilities that cross functional boundaries between the SIEM, SOAR, threat hunting, and incident case management; organizations are being forced in this direction by cyberattackers’ increased productivity, in some cases using cyberattackers’ own AI/ML capabilities.
• Threat intel sharing and AI/ML integration with third party security service providers, and distributed capabilities in the hybrid multi-cloud environment will also become an imperative.
• Use IAM and information protection controls to address data nationalism and data sovereignty constraints on security monitoring and the collection of personal information.

Selecting and aligning controls: Enterprise security operations and services comprises a broad variety of controls. Many of these controls overlap with the ones in subordinate functional domains such as Network Security and IAM. Also, the actual security operations groups often rely on, or oversee, IT Operation groups’ security work. Table 3 identifies the high level NIST CSF controls for security operations and services from the technology perspective, and Table 8 also provides a detailed mapping from each functional control domain to key business and IT stakeholders involved.

Security Operations and Services Functional Control Domains	NIST CSF Controls
Security governance	·      ID.GV-4: Govern cybersecurity risk
Risk management	·      ID.RA: All risk assessment controls ·      ID.RM: All risk management controls
Asset management	·      ID.AM: All asset management controls (coordinated with IT) ·      ID.RA-1: Identify asset vulnerabilities ·      PR.DS-3: Assets managed
Third party management	·      ID.SC: Supply chain risk ·      DE.CM-6: Monitor external services
Real time threat detection	·      DE.CM-1, 4, 5, 7: Detect malware, unauthorized mobile code, suspicious network activity ·      DE.AE-4,5: Understand, process alerts ·      DE.DP: Detection processes (all controls)
Logging and log review	·      PR.PT-1: Audit logs collected per policy ·      DE.AE-1, 2: Analyze logs to baseline normal activity and attacks ·      DE.AE-3: Collect and correlate log data from multiple sources ·      See User Account Monitoring, under IAM Functional Capability
Incident response	·      RS.RP-1: Response planning ·      RS.CO (communication): All controls ·      RS.AN (analysis): All controls ·      RS.MI (mitigation): All controls ·      RS.IM (improvement): All controls
Backup and data recovery	·      PR.IP-4: Backups

Table 3: Security Operations and Services Controls Mapping to NIST CSF

System, Vulnerability, and Configuration Management

Digital enterprises must maintain IT endpoint devices, systems, application assets, and distributed security controls throughout the hybrid multi-cloud environment at an acceptable security posture. They must keep systems free of high-risk vulnerabilities and configuration settings and update software or configuration items as needed, maintain access controls, and monitor security-related events.

At the business and IT level system, vulnerability, and configuration management solutions must be able to define what is an “acceptable security posture” in terms of risk. They must concern themselves with “high risk vulnerabilities” rather than “critical vulnerabilities” (as assessed by a vulnerability scanning tool) for a reason: not all “critical vulnerabilities” are created equal. For example, a vulnerability categorized as “critical” by a vendor might only be considered a “high-risk” vulnerability by the customer if it was found on an Internet-exposed, high value asset. We can use the same logic for configuration weaknesses, software defects, or other system level deficiencies. We call the risks to those systems “high” only to say that the quantified value of the risk exceeds some defined business risk appetite.

Core technology requirements: This functional domain must discover endpoints, virtual machines, containers, servers, network or IOT devices, and applications throughout the hybrid multi-cloud environment. It must ensure distributed security controls operate correctly, scan for vulnerabilities, assess configurations against configuration baselines for the systems, and be able to apply updates or fixes. It must have interfaces to integrated risk management systems and IT service management (ITSM) so as to be able to manage scanning and remediation in accordance with risk appetites and IT operations ticketing workflows and procedures in cases where automatic updates can’t be applied.

Figure 13: Security-Related Processes and Technologies for Configuration and Vuln. MGT

Table 4 identifies the high level NIST CSF controls for systems, vulnerability, and configuration management. Table 8 provides a detailed mapping from these functional control domains to the key business and IT stakeholders involved.

Systems, Configuration, and Vulnerability Functional Control Domains	NIST CSF Controls
Risk management	·      ID.RA-5: Assess vulnerability and configuration risks
Asset management	·      ID.RA-1: Identify asset vulnerabilities ·      PR.DS-3: Assets managed
Vulnerability and configuration management	·      PR.IP-12: Vulnerability management plan ·      PR.IP-1: Secure baseline configuration ·      DE.CM-8: Vulnerability scans ·      RS.AN-5: Vulnerability disclosures ·      RS.MI-3: Vulnerability mitigation ·      PR.MA-2: Remote maintenance ·      PR.PT-3: Least functionality ·      PR.DS-6: Integrity checking

Table 4: Systems, Configuration, and Vulnerability Controls Mapping to NIST CSF

Network Security

Digital enterprises must protect their private data center networks and virtual networks in their IaaS environments. They must offer IT applications and services via zero trust, low friction access for authorized customers and partners as well as workforce users and devices. At the business and IT level, network security must ensure that traffic to, from, and across the cloud is properly protected and provided with adequate bandwidth capacity and availability. Needs to segment or segregate resources must be balanced against needs for speed, access, and always-on availability.

Core technology requirements: Protect network traffic from eavesdropping, denial of service, and unauthorized traffic modification. Provide network segmentation or segregation using firewalls and other devices, and network security gateways to protect web, email, and cloud traffic. Prevent distributed denial of service attacks from disrupting network resources and use network traffic analysis to detect attacks over the network. Network security systems must also meet new requirements for secure public networking across cloud services (i.e., secure access, secure edge (SASE)) and geofencing for privacy regulation compliance. Do not rely only on network segmentation for protection, but also observe Zero Trust Architecture wherever possible, authenticating all users or systems appropriately to identity, access, and risk context.

Figure 14: Security-Related Processes and Technologies for Network Security

Table 5 identifies the high level NIST CSF controls for network security. Table 8 provides a detailed mapping from this functional control domain to the key business and IT stakeholders involved.

Network SecurityFunctional Domain	NIST CSF Control
Network security	·      PR.AC-5: Network segregation ·      PR.AC-7: Device authentication ·      PR-PT-4: Protect control networks ·      DE.AE-1: Network security baseline ·      DE.CM-1: Network security monitoring

Table 5: Network Security Controls Mapping to NIST CSF

Identity and Access Management (IAM)

IAM is one of the most complex control families in the security landscape. Unlike many security capabilities that enable the business by protecting assets in the background, IAM often enables business directly. As explained in our IAM Reference Architecture, to drive positive sales, reputation, and customer satisfaction Digital Enterprises must be adaptive to the marketplace through agile, optimized responses to events and opportunities: “Business buyers and consumers are becoming adept at finding exactly what they want, and enterprises have to become equally adept in finding, and aligning the people, knowledge and operating assets to match.”

At the business and IT level, IAM solutions must manage identity information about workforce users, customers, partners, suppliers, services, and devices (aka identity “subjects”). They must provide authentication and authorization to enable access for the subjects and comply with all regulations covering privacy, internal controls, and other issues. Much of the identity and privilege management process has to be delegated down to the business and IT users themselves, and IAM must be managed consistently across multiple systems including corporate administration, enterprise applications, and IT systems in order to promote productivity and operational efficiency.

Core Technology requirements: A Digital Enterprise needs IAM to provide zero trust authentication at low friction and with a high enough level of assurance for a variety of use cases. Single sign-on (SSO) to the many resources in the hybrid multi-cloud infrastructure is highly desirable, along with granular attribute-based access control (ABAC), or authorization to use those resources. Directory services serve as a single source of truth for identity attributes and permissions. Identity governance and administration (IGA) solutions provision identity information as needed to multiple applications or platforms and enable access certification reports for compliance.

Figure 15: Security-Related Processes and Technologies for IAM

Disruptive trends: With the recent increase in demand for work-from-home and remote access solutions, the need for zero trust access has also risen. It is imperative to support multi-factor authentication – ideally with a passwordless option – and the ability to continuously verify the risk tolerance for ongoing sessions.

Navigating amidst regulatory flashpoints such as GDPR and the California Consumer Privacy Act (CCPA) increasingly requires IAM solutions with built-in Privacy-by-Design features such as consent management, granular attribute-based authorization, and in some cases, support for decentralized identity models. IAM must also be well-integrated with network security capabilities such as SASE, CASB, and geofencing as well as information protection capabilities such as data tokenization.

Table 6 identifies the high level NIST CSF controls for IAM. Table 8 provides a detailed mapping from these functional control domains to the key business and IT stakeholders involved.

IAM Functional Domains	NIST CSF Control
Authentication and User Account Management	·      PR.AC-1: Manage ids, credentials ·      PR.AC-6: Identity proofing ·      PR.AC-7: User authentication
Access Management and Authorization	·      PR.AC-2: Physical access control ·      PR.AC-3: Remote access ·      PR-AC-4: Authorization ·      PR-AC-5: Network access ·      PR.PT-3: Least functionality
User Account Monitoring	·      PR.AC 1, 4, 6, 7: Capture user and access management events ·      PR.PT-1: Audit logs collected per policy ·      DE.AE-1: Baseline normal account activity ·      DE.AE-3: Collect and correlate log data ·      DE.CM-1, 3, 7: Monitor networks, devices, personnel activity

Table 6: IAM Controls Mapping to NIST CSF

Information Protection

These capabilities protect the information itself. At the business and IT level, organizations must quantify the risk and value of the information they create, process, or handle. They must develop policies and procedures for data governance closely aligned to asset risk profiling, risk management, and access management as well as deploy technical capabilities to protect information.

Businesses should fully advance data governance (and access governance, or IGA) if they have many types of sensitive data, high regulatory or legal pressure, and/or complex compliance requirements such as avoiding conflict of interest or maintaining information barriers (e.g., for internal controls, or to avoid conflicts of interest). Otherwise, basic data and access governance processes with simplified data stewardship (e.g., maintain GDPR Data Protection Officer role) for the most critical information only should suffice. However, many organizations still seem to find even basic information classification, information handling, and sensitive data discovery capabilities burdensome, and need to make considerable improvements.

Core Technology Requirements: These include automated data classification, discovery, and labeling; data retention for legal e-discovery purposes; and data leakage protection (DLP). Encryption is required for data-in-transit and for data-at-rest at the disk or device level, file and folder level, or application and database level. Tokenization and digital rights management (DRM) may provide alternatives to encryption. Key management for both data encryption and subject authentication is required across the hybrid cloud environment and can be provided through a mix of enterprise controlled and CSP controlled systems.

Figure 16: Security-Related Processes and Technologies for Information Protection

Disruptive trends: Multiple “bleeding edge” or still-anticipated information protection technologies are poised to disrupt current state security programs and/or create new opportunities for security capabilities that enable business advancement. These include quantum cryptography, specialized homomorphic encryption, zero knowledge proofs, and the application of privacy-by-design principles or capabilities to AI/ML systems that process personal data for marketing, business intelligence, or security monitoring purposes.

Table 7 identifies the high level NIST CSF controls for Information Protection. Table 8 provides a detailed mapping from these functional control domains to the key business and IT stakeholders involved.

Information ProtectionFunctional Control Domain	NIST CSF Control
Data Protection	·      ID.AM-3: Organizational communication and data flows are mapped ·      PR.DS-1: Data-at-rest protected ·      PR.DS-2: Data-in-transit protected ·      PR.DS-3: Assets are formally managed through removal, transfers, and dispositions ·      PR.DS-4: Adequate capacity ·      PR.DS-5: Data leak protection

Table 7: Information Protection Controls Mapping to NIST CSF

The Business Alignment Framework

Earlier, Figure 2 illustrated the overall structure of the reference architecture. Therein, a Business Alignment Framework drives the Functional Process and Technology Views. Next, Figure 3 – the Business, IT, and Security Program Architecture Landscape – depicts the components and capabilities of the Business, Process, and Technology Views at a high level.

The Business View

Figure 17 – the Business View – expands the Business Risk and Regulatory Context from Figures 2 and 3 into an actionable framework. Business analysts and security architects can develop this context by understanding or modeling the business’s geographical footprint; its culture, organization structure, and relationships; industry and business drivers for IT; its risk factors; and how critical processes such as sales, marketing, accounting, manufacturing, etc. operate.

Figure 17: The Business View

Through business analysis, the architecture team can enumerate business requirements (such as the need to support sites or comply with regulations in different jurisdictions) as well as critical business outcomes for the companies IT systems and security program. To understand business requirements in detail, the architecture team should identify and gain a basic understanding of each of the following components from Figure 17:

• Business Geography and Culture: What is the business’s geographical footprint? Where are its major sites, subsidiaries, and target markets? The location of all these business components implies what cultural customs the people in the business will tend to follow, and what laws or regulations apply.
• Business and Industry Drivers for IT: What are the key technology trends for businesses in your organization’s vertical industry and how is the IT strategy addressing them? For example, financial services in Europe are restructuring IT and security system to comply with Open Banking regulations. What are the time dependencies for the business strategy to address these, or other, business initiatives and opportunities?
• Organizations and Relationships: What are the major business departments? These can include centralized or regional HR, sales, marketing, accounting organizations as well as Line of Business (LOB) units such as manufacturing, retail, insurance, etc. What types of customers do they serve? Who are the largest customers? Which are the most important supply chain partners?
• Business Process Models: What are the major processes supporting the organizations of the business and how are they inter-connected?
• Business Risk Model: How does the business manage all risks (e.g., competitive, financial, physical, legal, and IT risks)? How are risks tracked?

A short cut to getting some of this information may be to engage the business’s Enterprise Architecture team, or other groups that set the IT strategy. After studying all available material, however, it is important to engage the business stakeholders responsible for business sites, processes, organizations, risk management, etc. By understanding or modeling the business view components, architecture can derive a reasonably comprehensive set of business requirements. Be sure to prioritize these requirements so that you can understand which are related to critical business outcomes – such as completing Phase 3 of a clinical trial for a pharmaceutical company’s coronavirus vaccine projected to generate 25% of business revenues in future years – and therefore of greater importance.

Aligning Business Stakeholders and Roles to Functional Control Domains

It is imperative to work with business and IT stakeholders throughout the architecture development and life cycle management process to ensure security capabilities align with the business drivers, requirements, policies, culture, and other constraints. Therefore, Table 8 maps types of business stakeholders and their roles to the functional control domains in the reference architecture. Be sure to consult Table 8 when developing your own organizational instance of the reference architecture, as it will help you involve the right people.

Stakeholder or Roles	Applicable Control Domains
Executives	Security governance, risk management, security policy and awareness, incident response
LOB executives, leaders	Security governance, risk management, risk management, security policy and awareness, asset management, third party management, incident response, backup and data recovery, business continuity
IT leaders or teams	Security governance, security policy and awareness, asset management, security zoning, authentication and user account management, access management and authorization, configuration and change management, vulnerability management, endpoint security, information protection, logging and log review, incident response, backup and data recovery, business continuity
CTO and/or Development leaders or teams	Security governance, security policy and awareness, asset management, network security, authentication and user account management, access management and authorization, information protection, secure software development, vulnerability management, configuration and change management, logging and log review, incident response, backup and data recovery, business continuity
Business continuity team	Backup and data recovery, business continuity
Compliance and audit	Risk management, network security, authentication and user account management, access management, configuration and change management, information protection, vulnerability management, logging and log review, incident response, business continuity
Endpoint or mobile device management team	Network security, real-time threat detection, endpoint security
Enterprise risk management	Risk management
Facilities	Physical security, business continuity
Human resources	Secure HR practices, user account monitoring, incident response
Internal marketing	Security policy and awareness
IAM team	Identity and Access Management
IT asset management	Asset management
Legal team	Secure HR practices, logging and log review, user account monitoring, incident response, business continuity
Network management team	Network security
Procurement and/or vendor management	Third party management, network security, access management and authorization, data protection, incident response, backup and data recovery
Public relations	Incident response
User awareness team	Security policy and awareness

Table 8: Master Table for Aligning Business Stakeholders to Functional Control Domains

Source: Adapted from Table 6-3 in “Rational Cybersecurity for Business” (available for complimentary download).^[7]Chapter 6, “Establish a Control Baseline” explores a similar control model from the business alignment perspective in detail.

Mapping Security-Related Processes to Functional Control Domains

Table 9 maps the processes identified in the Security-Related Processes section to the functional domains covered in this reference architecture.

Security-Related Process		Functional Control Domain
Asset Management IT Service and Change Management Configuration Management Vulnerability Management	Asset Management Configuration and Change Management Vulnerability Management
Risk Management	Risk Management (Table 1)
Security Monitoring	Real-time Threat Detection Logging and Log Review User account monitoring
Incident Response	Incident Response
Business Continuity Management	Backup and data recovery Business continuity
Vendor and Supplier Management	Third Party Management
Desktop Management Mobile Device Management	Endpoint Security
Application Portfolio Management Application Security Testing and QA DevSecOps Software Development Life Cycle Management (SDLC) Management	Application Security Secure Software Development
IT Operations Management and Testing Storage and Backup Management	Asset Management Configuration and Change Management Vulnerability Management
Facilities Management	Physical Security
Network Management Network Security Testing	Network Security
User Life Cycle Management Access Management	Identity and Access Management
Data Governance Information Classification E-Discovery	Information Protection
Compliance, Assurance, and Audit MGT	Security Governance, Risk Management

Table 9: Master Table for Aligning Security-Related Processes to Functional Control Domains

Next Steps and Conclusion

In working with the Security Reference Architecture’s Business View, clients should discover and document:

• Business strategies, capabilities, and regulatory requirements
• Security program mission and mandate
• Top business risks, and enterprise information risks
• Business impact analysis of critical business processes and applications
• Security policy
• Security governance model
• Security funding sources, or budget

 

This business information should be used to select and prioritize functional requirements as clients work with the Security Reference Architecture Functional Views. For example, the security program mission and mandate should provide a clear definition of security objectives that fits the business, and it should designate the lines of authority and decision rights. With such a definition, the security organization knows its protection targets, which may (or may not) include some or all of the lines of business, physical security, the IT/OT environment, customer-facing web sites, and the software development process.

In addition to the business context, definition of security, and other context from the Business per the Business Alignment Framework, identify the types of stakeholders who can help you select and prioritize the required functional capabilities for a well-aligned security plan. Use the ISO Plan-Do-Check-Act framework for this model as shown in Figure 18 and move forward.

Figure 18: Plan-Do-Check-Act Template for Implementing Security Based on the Reference Architecture

Organizations need tools to identity their business security context, select and prioritize security-related processes and functional or technical capabilities, and put them into operation. The TechVision Research Security Reference Architecture identifies many security-related processes and technology capabilities, puts them into a business and IT context, maps them to industry-standard control frameworks, and provides high level implementation guidance.

About TechVision

World-class research requires world-class consulting analysts, and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Dan Blum, Principal Consulting Analyst at TechVision Research, is an internationally recognized strategist in cybersecurity and risk management with over 30 years of experience in IT, security, risk, and privacy. His book “Rational Cybersecurity for Business” is a Security Leaders’ Guide to Business Alignment. He was a Golden Quill Award winning VP and Distinguished Analyst at Gartner, Inc., has served as the security leader at several startups and consulting companies, and has advised 100s of large corporations, universities and government organizations. Mr. Blum is a frequent speaker at industry events and participates in industry groups such as ISACA, FAIR Institute, IDPro, ISSA, CSA, and the Kantara Initiative.

A Founding Member of the Kantara Initiative’s IDPro group and honored as a “Privacy by Design Ambassador”, Mr. Blum has also authored two books, written for numerous publications, and participated in standards or industry groups such as ISACA, the FAIR Institute, IDPro, CSA, OASIS, Open ID Foundation, and others.

Mr. Blum’s career has encompassed a wide gamut of experience. He has written countless research reports and has led consulting projects in North America and Europe, spanning Financial Services, Insurance and Manufacturing, Health Care, Higher Education, and the Public Sector.

During his tenure at Gartner, Mr. Blum held VP positions as a Distinguished Analyst and Agenda Manager with the Security and Risk Management Strategies analyst team. He led the effort to enhance and improve the Security Reference Architecture acquired from Burton Group. He managed successive cloud security track programs at the Gartner Catalyst conferences and spoke at Gartner Security Summit and other events. He also served as the Cloud Security Research lead at Gartner for Technical Professionals.

At Burton Group, Mr. Blum filled multiple roles over a 10-year period, initially serving as Senior VP and Consulting Practice Manager, then as Research Director for the Identity and Privacy Strategies team. He authored, co-authored, or directed all the initial identity Reference Architecture content and also co-founded the Burton Group’s Security and Risk Management Strategies research service beginning in 2004.

[1] “Enterprise Security Architecture: A Business-Driven Approach,” John Sherwood, Andrew Clark, David Lynas, CMP Books, 2005

[2] International Standard ISO/IEC 27001:2013 — Information technology — Security techniques — Information security management systems — Requirements (second edition), ISO/IEC, 2013

[3] International Standard ISO/IEC 27002:2013 — Information technology — Security

techniques — Code of practice for information security controls, ISO/IEC, 2013

[4] “NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations, NIST, April 16, 2018. Accessed at http://dx.doi.org/10.6028/NIST.SP.800-53r4, April 2013

[5] “COBIT 5: A Business Framework for the Governance and Management of Enterprise IT”, ISACA, 2012.  accessed at http://www.isaca.org/cobit/Pages/CobitFramework.aspx

[6] “Rational Cybersecurity for Business: The Security Leaders’ Guide to Business Alignment,” by Dan Blum, 2020, published by Apress, available at: https://www.apress.com/gp/book/9781484259511

[7] “Rational Cybersecurity for Business: The Security Leaders’ Guide to Business Alignment,” by Dan Blum, 2020, published by Apress, available at: https://www.apress.com/gp/book/9781484259511