With the increased complexity of the organization infrastructure, it becomes more and more difficult for CISOs and security architects to present a high-level view of the current cybersecurity controls, let alone the proposed roadmap. The cybersecurity roadmap diagram below attempts to capture the typical security controls and their current and future deployment in each part of the network infrastructure. Inspired by Microsoft’s Cybersecurity Reference Architecture, it represents the main components of a typical IT infrastructure (endpoints, on-premises extranet and intranet servers, infrastructure hosted at 3rd parties and/or private cloud, public cloud deployments as well as SaaS applications) and the type of security controls deployed at each location.
The controls are also listed grouped by their NIST Cybersecurity Framework role for a quick understanding of their purpose. The functions of the typical Information Security Office are shown separately as they transcend all types of infrastructure. The increased role of Managed Security Services Providers (MSSP) is highlighted by a separate section capturing their services.
The security controls are color-coded based on their position on the implementation roadmap, allowing a quick understanding of the projected progress in covering the current gaps. Version 2.0 includes additional security controls as well as a more coherent color scheme and organizations of controls:
Links to higher resolution images: PDF, Vector Image (SVG), Visio. These documents are offered under MIT License.
In practice, the diagram above can be modified to describe the specific vendors for each security control, add additional sites that may not have the same type of controls deployed and add any particular items that make each organization unique. The list of NIST functions and types of security controls may be removed if the intended audience is already familiar with it.
Some analysts may question the need to list the security controls that are not on the roadmap. The reason for it is that the architect may want to make the audience aware that there are additional security controls available but the business took an informed decision for not implementing them. The architect may describe the reason and that could be that they are not applicable (i.e. if an organization does not develop custom applications, there is no need for code analysis), may not justify the investment or may impede the business productivity (i.e. whitelisting). It all depends on organization’s risk appetite and their overall cybersecurity policies.
See below an example of customized diagram (fictitious) for an organization with two locations (Toronto HQ and Montreal Office), servers hosted on TELUS private cloud, applications deployed using Microsoft Azure cloud service as well as SaaP applications such as Office 365. Each security control has the vendor specified. As a feedback for the previous version, one architect mentioned that he likes to add the vendor logo as well.
Using PowerPoint animations, the diagram can provide a certain level of interactivity, showing the gradual deployment of each type of control, based on the organization’s cybersecurity roadmap. The locations and the Information Security Office functions can also be gradually added, allowing the presenter to “build” the cybersecurity architecture until it reaches to full picture. It all depends on the audience and the level of detail the presenter is willing to go into.