Managing Security in LeanIX, an enterprise architecture tool

Mature digital companies already invested in Enterprise Architecture tooling, like LeanIX. EA tool is then used to describe the current landscape but also to study asset-based target transformation scenarios. The scenario track changes continuously and could be updated by all involved stakeholders (see this article I wrote for more information).

Enterprise Architecture tools are morphing into digital transformation cockpits, where : Business strategy, business architecture (bus. process, bus. capabilities), software and technical architecture, data architecture are described and more importantly, related each other’s. If you look at LeanIX product map, you can see the evolution, especially with their new “intelligence” products (Cloud, Microservice and SaaS intelligence) integrated with their EA Suite.

Unfortunately, very often, security assets are often managed apart, and not integrated in this common vision (and cockpit). This is mainly due to segregation of duty where security teams are using their own tools and framework, and protect them from outside views. It is also because dedicated security tools exist, leveraging domain specific framework and reporting capabilities enabling easy auditability from compliance stakeholders.

What if we could manage security in an enterprise architecture tool like LeanIX? How then to describe and integrate key security concerns?

This post is a short presentation of a Proof of Concept made to answers these questions, created with the support of LeanIX engineers.

In search of the right security framework

Several security frameworks exist, depending on the industry, business domain (Finance, Retail, etc.) or even the type of risks you want to assess. So the first question to ask yourself is which one is the right for you?

We decided to use both NIST and ECSO taxonomy.

NIST

The most known is NIST framework (see here) and consists of standards, guidelines, and practices to promote the protection of critical infrastructure.

NIST is based on five core functions defined below:

• Identify — Understanding the business context, the resources that support critical functions, and the related security risks enables an organization to focus and prioritize its efforts, consistent with its risk management strategy and business needs
• Protect — Develop and implement appropriate safeguards to ensure delivery of critical services. Examples of outcome Categories within this Function include: Identity Management and Access Control; Awareness and Training; Data Security; Information Protection Processes and Procedures; Maintenance; and Protective Technology.
• Detect — Develop and implement appropriate activities to identify the occurrence of a security event. Examples of outcome Categories within this Function include: Anomalies and Events; Security Continuous Monitoring; and Detection Processes.
• Respond — Develop and implement appropriate activities to take action regarding a detected security incident. Examples of outcome Categories within this Function include: Response Planning; Communications; Analysis; Mitigation; and Improvements.
• Recover — Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a security incident. Examples of outcome Categories within this Function include: Recovery Planning; Improvements; and Communications.

Without entering into the intricacies of the framework, let’s say that for assessing each function, you will have to deep-dive into categories and look at a set of “controls” (see excel file here).

ECSO

The European Cyber Security Organization (ECSO) is a fully self-financed non-for-profit organization under the Belgian law, established in June 2016. ECSO is considered as the privileged partner of the European Commission for the implementation of the Cybersecurity Public-Private Partnership.

In order to help suppliers and customers arrive at a common understanding of the cybersecurity value chain, ECSO elaborated a clear and common description of cybersecurity products and services in the form of a taxonomy. We used this ECSO Taxonomy for the cybersecurity market to create the hierarchy of controls of this POC (see an extract of this taxonomy below).

Implementing security “control” in LeanIX

LeanIX comes with a pre-defined “metamodel”, not enabling natively to manage the notion of security controls. To create this POC, without altering LeanIX metamodel, we decided to reuse the LeanIX “business process” object and to rename it “Control”.

A control is then represented by this minimum set of information:

• A name,
• The standard it relates to (named category)
• An internal alias if needed
• A description of the control

Below you can fin an example of a NIST 800–53 security control

In order to stay “flexible”, it is also possible to use LeanIX tags to add more information for each control that could be use for extra-classification or reporting

Relating “control” to other LeanIX assets

The control object being created, the next step was to define how to connect it to the rest of the metamodel (e.g., which LeanIX objects?). Since security is a holistic view, we can relate “controls” to: Business process, Business capability, Application, interface, Data object, IT component, etc.

For this POC, we decided to connect control to applications (for application security compliance assessment) and “user group” (aka organizations, for enabling auditability for a dedicated organization and capability).

In the following screenshot, you can see that 4 “controls” are associated to a fictitious CRM application based on Salesforce.

The four controls are described below

It is then possible to assess CRM application and to set each control status (control checked, not checked, etc.). Thus controls and their hierarchy can be created once and applied to multiple LeanIX Factsheets.

Control Reporting

One of the key need for security team is audit and risk analysis. Since controls are hierarchical by nature, and organized following the ECSO hierarchy, they can be shown using the standard dynamic reporting views of LeanIX,

We can always reuse this dynamic report to create heatmaps. Below, we show which control is verified and which one is not for the fictitious CRM application.

Security Dashboard

LeanIX enables also to create dashboards by composing existing report and views of LeanIX.

Below we show an example of a very basic one, to prove how easy it will be to get security information on one page.

Credits

Big up to:

• Oliver Klein (Global Strategic Alliance Executive) who listened to me, challenged my idea and accepted to support me for this POC in LeanIX
• LeanIX engineers for their technical support for building this POC