Information system mapping: building it step by step

Information system mapping is the representation of an organisation's information system and its links with the outside world: an inventory of its components and a set of views, from business processes down to equipment. ANSSI, the French national cybersecurity agency, devotes a guide to it, with six views and a five-step approach. It is the starting point of any serious risk analysis, and an invaluable tool on the day of an incident.

In November 2018, ANSSI published the guide “Mapping the information system, how-to guide in 5 steps”. Written first for operators of vital importance, it is meant to be usable by any organisation. It defines the map as a representation of the information system and its connections with the outside world, combining two things:

• an inventory, the detailed list of the system's components: applications, servers, networks, accounts, suppliers;
• views, partial representations of the system, each from a specific angle.

The guide links mapping to four stakes. Control of the system: knowing what exists and who is responsible for it. Protection: choosing controls where they matter. Defence: quickly understanding the scope of an attack. Resilience: knowing in which order to rebuild. An organisation that discovers its dependencies during a crisis loses precious hours, as our article on the business continuity plan points out.

Beware of a common confusion: an information system map describes what exists; it does not assess risks. A risk map, built on top of it, rates what could go wrong. The first is the foundation of the second.

The guide proposes six views, grouped into three visions, to move gradually from business to technology.

• Ecosystem view (business vision): internal or external entities that interact with the system, such as customers, suppliers and partners, with their relationships and security contacts.
• Business view of the IS (business vision): the organisation's processes, activities and tasks, the people who perform them and the information they handle.
• Application view (application vision): application blocks, applications, services, databases and the flows between them.
• Administration view (application vision): administration zones and means, directories and domains (Active Directory, LDAP) and privilege levels.
• Logical infrastructure view (infrastructure vision): networks, subnets, VLANs, address ranges, gateways, security devices, DNS and DHCP servers.
• Physical infrastructure view (infrastructure vision): sites, buildings, rooms, racks, servers, workstations, storage and physical links.

What gives the whole its value are pivot objects: elements that appear in two views and let you move between them. An application shows up in the business view, because it supports an activity, and in the logical view, because it runs in a network zone. Following these objects, you can go up from a server to the activities it keeps running, or down from a process to the room that hosts it. Try it in the diagram below: Active Directory, for instance, supports two activities on its own.

ANSSI's guide organises the approach around five questions: how to get started, which model to adopt, which tools to use, how to build the map and how to keep it alive.

The guide distinguishes three levels, so you do not have to do everything at once.

• Level 1: a security-oriented map limited to essential elements and a few views. It is an intermediate step.
• Level 2: a security-oriented map covering all views. This is the minimum expected for critical information systems of operators of vital importance.
• Level 3: an exhaustive and detailed map, as part of a broader approach that goes beyond security.

For an SME or a local authority just starting out, aiming for level 1 on a limited scope is realistic: the ecosystem and business views, plus the applications and administration of critical activities. The ecosystem view is also the starting point for third-party risk management, since it lists the suppliers you depend on.

An information system map is also a treasure map for an attacker: it shows where the servers, admin accounts and flows are. ANSSI's guide draws several rules from this.

• Give it a protection marking, such as “company confidential” or “restricted”; for critical information systems of operators of vital importance, it is at least marked restricted.
• Limit access on a need-to-know basis: the business view can be widely shared, the infrastructure views stay with IT. The CISO and the incident response team must always have access.
• Do not store it on the system it describes, and keep secure backups, down to a paper copy, so that it can still be consulted if the network is down.

This last point is often forgotten: the day ransomware encrypts the file server, a map stored on it is of no use.

The EBIOS Risk Manager method starts with a scoping workshop in which you identify business assets, what really matters to the organisation, and the supporting assets they rely on. ANSSI's mapping guide makes the link: objects in the business view correspond to business assets, technical objects to supporting assets. For its part, the EBIOS RM guide cites the information system map as the basis for identifying supporting assets.

The first EBIOS RM workshop recommends sticking to a limited number of business assets, around five to ten, and one to three supporting assets for each to begin with. A well-built level 1 map provides exactly that. It also helps express the security needs of each business asset, for example with the DICP criteria, then carry out the risk analysis and track residual risk once controls are applied.

The guide mentions other uses: the record of processing activities required by the General Data Protection Regulation (GDPR), for example, benefits from the business view, which already describes which information each activity handles.

• Start from the business. A map that starts with the network often ends up as an architect's diagram that management never reads.
• Appoint owners. Each process has a business owner, each application a technical owner: they are the ones who approve updates.
• Tie updates to projects. A new supplier, a cloud migration or a new application should change the map before going live.
• Spot concentration points. An object that several critical activities depend on (a directory, a hosting provider, a network link) is a candidate for stronger protection.
• Test its availability. During a crisis exercise, check that the map can be consulted without the information system.

The business and supporting assets drawn from the map are the starting point of EBIOS RM analyses. To see how they connect with the following workshops, see our risk analysis module.