Security Requirements Vision and Strategic Security Architecture Principles

Before starting any security architecture work, defining security requirements is essential. These requirements should be influenced by business context and the overarching requirements vision document. The diagram below shows security requirements as part of the business context in the enterprise information security architecture.

Figure 1

The Security Requirements Vision (SRV) helps link security solutions to defined business needs. It supports traceability between business strategy and security decisions.

SRV typically includes:

A list of relevant environmental trends and business strategies that affect the Enterprise Information Security Architecture (EISA).

A list of relevant security technology trends (STT) and best practices that influence security solution design.

A clear statement of changes, technologies, and information requirements derived from environmental trends, business strategy, technology trends, and best practices.

Security Solution Requirements (SSR) derived from the statements of changes, information, and technology requirements.

A matrix mapping the interrelationships between business strategies and environmental trends, as well as between business strategies and changes, information, technology, and solution requirements.

Strategic Security Architecture Principles

Strategic security architecture principles guide decisions made during architecture development, design, and implementation. These principles steer a security architecture strategy that moves from disparate security activities to a consistent future state by:

Aligning with business goals and risks.

Using a common set of controls to satisfy multiple requirements.

Providing a common reporting infrastructure for a single source of truth (agreed controls, policies, processes, and technologies).

Being as non‑intrusive as possible and employing automated controls rather than manual testing and measurement.

Clearly defining roles, responsibilities, and accountabilities.

Security Governance, Management and Operations

Security governance, management, and operations have very different functions.

Security governance exists to ensure that business strategic needs are defined and that security programs adequately meet those needs, which may involve discussing and judging business requirements in complex situations.

Security management builds and runs security programs to satisfy these strategic business needs, encompassing various security functions, processes, and policies that constitute the security program.

Security operations execute day‑to‑day security‑related processes associated with the current infrastructure.

This is the relationship among the three.

Figure 2

Getting the Right Security Processes

Chief Information Security Officers (CISOs) constantly face pressure to deliver consistent, demonstrable, and cost‑effective security in complex environments. A catalog of key security processes, defined and prioritized, enables CISOs to meet the demands of customers, partners, suppliers, auditors, and regulators. It also lays the foundation for a chargeable security service catalog under a formal service model, preparing the organization for new IT delivery approaches.

Certain processes are essential for effective security management and should be defined in the process catalog. Although these processes are often defined separately, they rarely operate in isolation; most of the time, inter‑dependencies exist among them.

Organizations that have made progress in strategic security planning will need a more comprehensive portfolio (see figure). This portfolio can describe two types of processes – strategic processes (those that support the relationship between the security team and the business) and protective processes (more directly aimed at maintaining enterprise security).

Figure 3

Formalizing the Security Process

For a given process, the first step is to assign (or verify) process ownership, then begin documenting the individual process. At a high level, a formal process definition should include the following components:

Process description – an overview of the process objectives and scope, possibly including brief identification of sub‑processes and activities.

Flowchart – a visual representation of the flow between sub‑processes and activities that make up the process.

Integration matrix – a table showing integration points and interrelationships with other security, operations, and service management processes, indicating other processes that are part of this process.

Skills and staffing requirements – indicating the quantity and nature of direct and indirect human resources needed for the process.

Role and responsibility definitions – identifying the specific organizational functions that contribute to the process and their responsibilities, often realized through a RACI matrix.

Automation opportunities – identifying process components that could be automated through technology; at this level the purpose is not product‑ or technology‑specific but merely to point out components that may aid automation.