Digital Security Architecture

The approach for a digital security architecture. Guest article written by Jimmy Heschl, Head of Digital Security at Red Bull.

logo ×
Home Features Services Resources Blog Contact FAQ   de
  3. Our Business Blog
  5. Digital Security Architecture

Digital Security Architecture

This guest article was written by Jimmy Heschl, Head of Digital Security at Red Bull.

If I Knew - The Need for a Security Architecture

IT professionals, also security professionals still tend to have a high focus on tools and technology while some have an additional focus on processes, organizational units and tasks, or some on policies; some even just put a single focus to fulfil a particular requirement, often driven by compliance requirements. All in all, a bunch of different areas need to work together and fit to the enterprise’s needs. But there is no overarching model to allow steering of adequate capabilities.

Digital security (1) - as all information and technology related activities – is highly driven by technology vendors and their market amplifiers like Gartner or Forrester and the vital market of consultants and value adding resellers. On the other hand, there’s the bad guys (including state-driven activists and other actors) who have a vital interest in insecure systems and technology environments.

But some questions remain for security professionals and their stakeholders: Are we doing enough? Should we do more or do we follow a hype? Can the resources be used more effectively? Should these be bundled, restructured to achieve a higher value?

There will never be enough capabilities that address all expectations of a security geek. In particular if the CISO wants to satisfy all the vendors, consultants and others on this vital market or if the security professional is extending professional skepticism to paranoia. It is common sense that there will never be 100% security; the likelihood will always be higher than 0.0 and the impact higher than 0. Consequently, security professionals need to aim for a certain level of business resilience towards security issues and attacks.

We as security professionals have to do our homework. As responsible business (beyond the glossy corporate responsibility reports), as a responsible CISO who earns a monthly salary and maybe a bonus: We are accountable to manage the required capabilities to protect from bad things, to detect issues if something goes wrong, to respond professionally and timely, and to recover systems and services.

But what are those required capabilities and when do we have enough? This article provides an overview on the Digital Security Architecture that supports security professionals in keeping an oversight over these capabilities. The architecture does not reflect aspects of a single system or a particular service’s technical architecture but aims to have a comprehensive view on all capabilities and components required to keep the security ship on course without overspending or taking undue risks (or even being unaware of the icebergs).

What is Driving Security Management?

Different drivers for digital security stem from different design factors: good practice, standards or compliance requirements; vendors and their offerings; information from industry peers; risks catalogues and issues identified etc. All these include diamonds and rust. On the other hand, there are limiting factors as budget or resource constraints or dependencies from legacy environment. As a security professional, there’s the need to find the right priorities and feed those into a security management system (2). An architecture helps to identify blind spots (or areas for improvement) as it provides a comprehensive and digestible oversight of the components required to manage security.

There are several components in the management system that need to be identified, prioritized, realized, operated and overseen in a smart way. These components can be policies, tools, skill and other types of capabilities. These components of the security management systems aren’t silos. Systems analyzing incoming emails to identify spam and malicious mails, those working on endpoints to identify suspicious behavior and the network controls to identify communication with sinkholes can be seen as different tools but they should work together; not only in prevention and detection but also in response and in on-going improvement of control. Same goes for components as the business entities and functions accountable for these issues. It’s not just an isolated SOC, there’s also Service Owners, a Service Desk and - not to forget - end users involved in preventing (or acting on) security issues. And there is a dependency and relationship between principles, policies, guidelines as well as the processes and procedures. All these components have an interdependency that can be taken as given or that can be addressed and improved as components of a professional management system. They need to work hand in glove in order to properly address security risks, threats and vulnerabilities that the organization faces. But it is not the objective to address risks, threats and vulnerabilities; the underlying goal is to foster resilience against these to allow the business to focus on the relevant business goals as satisfied customers, profitability, growth, innovation or a solid ecosystem.

The Approach for a Digital Security Architecture

There is a long list of core drivers for a sound approach towards security but what can be done to have all the required components?

The approach I propose for the security architecture is a combination of

  1. a security process,
  2. layers of technology, and
  3. components for a management system.

The Architecture Model

The aim is to combine good practice from the key guiding standard shaping cyber security: NIST Cybersecurity Framework and the management and governance framework COBIT.

Other standards of good practice as ISO27k, TOGAF or ITIL can be seen as additional points of reference to ensure a completeness of components when seeing its content as process, tool, guidance or other component type. There is no contradiction in the standards and different mapping exercises can prove that there is no substantial difference in the standards other than issuing sources and evangelists’ personal views.

Components of a Governance and Management System

The leading source for governance and management over IT is COBIT. COBIT 2019 matured the concept of enablers introduced in COBIT 5 and these components can be seen as different types of levers to address a focus area as cyber security. For an architectural perspective it makes sense to look at the world through these different lenses and differentiate the following components:

  • GUIDANCE: policies, standards, frameworks and other instructions.
  • TOOLS: systems, services and other IT infrastructure in place.
  • ORGANIZATION: internal and external units or individuals.
  • INFORMATION: repositories, reports, templates and alike.
  • PROCESS: defined and implemented workflows and procedures.
  • SKILLS: available knowhow.
  • CULTURE: approaches and ethics in place.

Security Process

The NIST Cybersecurity Framework outlines five key functions: Identify, Protect, Detect, Respond, and Recover. This groundbreaking work from NIST (3) was used as a basis for the security process:

  • MANAGE: Organizational understanding to manage security risk to systems, assets, data, and capabilities. The activities are foundational for the others and help understanding the business context and the resources that support critical functions by anticipating threats and vulnerabilities. Examples include: Asset Management, planning guidance, resilience etc.
  • PREVENT: Safeguards to ensure the security (availability, integrity, confidentiality) of services. The activities limit or contain the impact of a potential security event. Examples include: Access Control; Awareness and Training; Data Security; Information Protection Processes and Procedures; Maintenance; and Protective Technology.
  • DETECT: Activities to identify the occurrence of a security event. The function enables timely discovery of security events. Examples include: Anomalies and Events; Security Continuous Monitoring; and Detection Processes.
  • RESPOND: Activities to take action regarding a detected security event and to contain the impact. Examples include: Response Planning; Communications; Analysis; Mitigation; and Improvements like enhanced protection on other components to deter further incidents.
  • RECOVER: Activities to restore any capabilities or services that were impaired due to a security event. They support timely recovery to normal operations to reduce the impact from a security event. Examples include: Recovery Planning; Recovery Testing; and Communications.

When applying the structure, it turned out that the two last functions, respond and recover, are highly overlapping. Hence these were combined in Respond & Recover.

Layers of Security

Information technology can – as Zachman showed successfully in his architecture framework or ISO in the OSI model – shown as different layers. I have decided to use the following layers to look at:

  • USER: internal or external users, business processes, roles, accounts and rights, admins, service accounts, physical access etc.
  • CLIENT: standard or individual client PC / Mac, mobile device or removable media.
  • APPLICATION: business and web applications and alike.
  • INFORMATION: digital information in any form (files, mail, collaboration etc.)
  • INFRASTRUCTURE: technical infrastructure (server, network, databases)
  • SERVICE PROVIDER: service provider / cloud & data center

The process, the layers and the components are the three core dimensions of the security architecture. The first two can be shown as a matrix where the process steps form the columns and the layers build the rows. The matrices’ fields – or boxes – can be filled with the components (e.g., Which component do I use to prevent security issues on clients?). In practice it makes sense to differentiate between the different types of components and have a separate matrix – or Architecture View – of tools, one for organization etc.

Objects and Their Attributes

The objects (e.g., tools or organizational units) can be assigned to one or more boxes in the matrix. In many cases it will make sense to assign more than one field; it is not mandatory to aim for a 1:1 relationship; reality is complex but it should not be complicated. The objects can be equipped with different attributes that help further identification or filtering. Attributes can include owners (e.g., Service Owners for Tools or responsible roles for maintenance of policies), costs, maturity and various other attributes that can help to differentiate different types of objects. An easy way to differentiate the objects is by adding colors or symbols. There is, however, a trade-off between the number of attributes, the effort to maintain and the value add of insight. This should be selected carefully and can be expanded over time.

Risks, Threats and Vulnerabilities

Most organizations have a specific risk model or list of risks. A valuable resource for risks can be found in COBIT for Risk where ~100 different risk scenarios (and references to management and governance practices) are elaborated in detail. I use a selection of relevant risks, threats or vulnerabilities (RTV) (4). There are RTVs with a direct impact to security management or information and those with an impact on security of services. All of them further sum up to issues outside a typical security area (e.g., risks as impact on safety, impact on product quality, business process efficiency, reputation or compliance risks beyond information-related topics). An overview of prioritized risks for security management can be found in annex 1.

Applying the Model

Architecture Views

Understanding issues and weaknesses is often achieved by a simplified view of a complex environment. The Views show a simplified illustration of process and layers and puts a focus on a single component. This is shown in the chart below and the view will used to further populate the process and the layers with the objects supporting those.

Architecture View structure

Figure 1: Architecture View structure.

This Architecture View can be used to

  • summarize common or good practice in order to provide a common understanding of applicable capabilities,
  • consolidate the current state of coverage, and to
  • identify areas for improvement.

To keep a view as digestible as possible they are showing one component type only. As an example the view below only shows the component type “Tools” populated with the common practice toolsets as objects. Note that these objects show generic types of tools but – for a specific organization – it makes sense to make a reference to the specific solutions, applications and products.

Excerpt of Architecture View 'Tools'

Figure 2: Excerpt of Architecture View “Tools”.

Other Architecture Views (matrices) can contain objects for the processes, information, guidance etc.

Assessing the completeness and adequacy of the current capabilities in place can be done easier and – in particular – it is primarily driven by the own demand to address certain aspects rather than being driven by products and the vital security market.

A recommended way to assess the adequacy is to use the general good practices for a certain component in a single box (e.g., prevent and client) and check, if the tools in place address the generic practices listed in the model and capture options for improvement. Discussion with peers and stakeholders helps but most important driver is the professional judgement of the CISO. Don’t think twice, it’s all right. Seeing a gap can aid professionals in identifying, addressing and closing the issue. So the CISO can be fully under control again and complete his/her job in a responsible and diligent way.

Another View On Components – The RTVs.

All components address one or more risks, threats or vulnerabilities and one example is provided in Figure 3. The chart can, of course, include other components as guidance, processes etc. but was limited throughout this article to a selected view.

Objects related to a single RTV

Figure 3: Objects related to a single RTV.

As all generic objects are linked with RTVs on the one hand and – as they appear on certain boxes in the Architecture View on the other hand – it is rather easy to take the perspective from a single RTV and assess it’s coverage. The views allow a straightaway overview on which components (here: tools) are in place to mitigate the risk. Hence, it is rather easy to assess the capabilities in place across all layers as well as the process stages. Consequently, an assessment can be done easily to clarify, which components are addressing the RTV on which layer(s) and at which process stag(es). Again, for the example of Credentials, this would be the corresponding Architecture View on the tools:

Architecture View for a selected RTV

Figure 4: Architecture View for a selected RTV.

This overview provides a straightforward assessment of adequate coverage of RTVs and an oversight on the capabilities in place. Of course, a closer look is beneficial to finalize the assessment. A fool with a tool is still a fool. But an expert supported by a tool can be smarter. Smarter in identifying areas that need further improvement and also areas where adequate capabilities are in place.

The Times They Are a-Changin

As the architecture evolves over time, it is imperative to keep the model forever young and use it as a methodology to keep track of progress, manage the pace of addressing improvements, and also communicate the status of current and future coverage and plans to stakeholders.

A Note on Tool Support

Software tools to handle the inherent complexity are of course beneficial. I use a tool,, that extends Microsoft Visio’s graphical front end with customization of object data and a database link that manages the various relationships between objects when they are assigned to one or more boxes in the Architecture View. And it also handles – graphically – the relations between RTVs and the objects. A generic reference model as used in this article will be included soon that can be adapted and adopted to individual needs.

Annex 1 – List of Risks, Threats and Vulnerabilities


  1. lack of awareness: Risk of little or no awareness on security-related risk and threats to the enterprise operations.
  2. lack of transparency: Risk of little or no transparency the organization’s exposure to security threats and risks.
  3. lack of priority: Risk of having little focus on security in system/service development and operation.
  4. lack of resources: Risk of lack of resources to address security and to put adequate capabilities in place to manage, identify, respond to & recover from security issues.
  5. lack of control: Risk of lack of oversight and steering on capability’s adequacy, effectiveness and effectiveness.
  6. lack of flexibility: Risk of lack of flexibility in applying or adapting security controls (e.g. legacy technology, vendor buy-in).

Information Security

  1. impact on confidentiality: Risk that information is made available or disclosed to unauthorized individuals, entities, or processes.
  2. impact on integrity: Risk to accuracy and completeness of data over its entire lifecycle (i.e., no unauthorized modification).
  3. impact on availability: Risk that information (or underlying services or systems) is not available when needed.

Further risks (or merely threats and vulnerabilities that might end up as a risk) stem from information and technology areas:

  • Application Vulnerabilities: insufficient logging, input validation, application / API abuse, insecure development, lack of authorization, inadequate availability, access to configuration, logic error, session management, lack of access control, weak encryption, exception handling, memory / garbage collection, technical vulnerability (OS, DB, …), zero-day exploit, buffer overflow
  • Websites: Defacement, Cross-Site-Scripting, Injection, Denial-of-Service, Domain-Grabbing / Spoofing
  • Compliance: regulatory or contractual risk of processing, data leakage, inability to inform, correct, delete, transfer,
  • Malware & Devices: malware, unwanted application, key logging, screen capturing, device theft / loss / destruction, …
  • Communications: spam, blacklisting, malicious weblink, surf-by, mail bomb, instant messages
  • Credential: brute force attack, account spoofing, hijacking, certificate issue, privileged account misuse, hor. or vertical escalation
  • Social Engineering: reconnaissance, scouting / water holing, personal (HR infiltration), shoulder surfing, piggybacking
  • Operations: human error, malicious intent, equipment theft / misuse, unhardened service, system / DB failure, inadequate backup, loss of backup data / media, lack of capacity, lack of logging information
  • Network: sniffing / wiretapping, man-in-the-middle, DDoS
  • Facilities: physical access, fire, water, acts of nature, data center equipment / network connection, sabotage
  • Partners & Service Providers: disgruntled partner, bad cloud service, unaccepted network access
  • Advanced Persistent Threats: targeted attack, blackmailing, espionage


  1. The term Digital Security was selected to reflect a focus on digital information (cf Information Security) and broaden cyber security with the perspective of internal information processing as not only issues from cyberspace should be addressed. The terms can be interchanged when needed.
  2. Note that the security management system is not to be mixed-up by an application fostering a checklist-approach or even a certificate that can be achieved. The management system is considered as the appropriate combination of capabilities that supports the security governance duties (evaluate, direct and monitor) related to the governance objectives (value realization, risk optimization and resource optimization) for the focus area of cyber security.
  3. In this definition, the functions Identify is called MANAGE as it better summarizes the planning and oversight of implementation and operation of required capabilities; similarly the term PREVENT is used in line with common language of controls in the auditor’s universe and protect has a connotation of a military, not a business approach.
  4. I do not necessarily differentiate between those types as it is not important if one is a threat or a vulnerability or if it can be shown as a risk. (i.e., hard to have a valid model for a quantified risk when considering likelihood, ease of exploitation, direct and indirect impact etc. in assessing inherent or residual risk for a vulnerability). All three types simply mean: There is something to do.

In category: Use Case  | Tags: eam, it-security
Share this article: 

Related Articles

Corporate documentation based on the Industry Reference Process Model

Published on 17.07.2019 | Read in about 7 min

A tool to quickly document the processes in your company based on established methos and best practices.

  Read more

Integrating ISO 9001:2015 into models

Published on 08.04.2019 | Read in about 5 min

ISO 9001:2015 defines requirements for a quality management system and can be mapped in as a tool for implementation and certification.

  Read more

Examples of Corporate Documentation

Purchase Requisitions

Type: RACI

Category: BPM

  Show Content

Company Org Chart

Type: Org Chart

Category: Organisation

  Show Content

  Stay in Touch