ANSSI policy for sharing and handling its operational information

Version 1 (16/11/2022)

As the French national cybersecurity agency, ANSSI has to share operational information with a number of different communities and entities. Sometimes this operational information must be used with caution.

Taking this into account, setting up rules specifying how such information (whether it is of a technical nature or not) should be shared and handled participates in strengthening trust within the cybersecurity community.

Beyond the question of sharing, the way shared operational information such as, for instance, indicators of compromise, is handled may inform an external observer about the knowledge and operational capabilities of an organization.

As a result, agreeing on a clear and intelligible marking policy can help normalizing exchanges of information without compromising operational efficiency. It also facilitates harmonization of practices by contributing to a homogeneous handling of the information.

In order to answer those needs, ANSSI applies a double marking on its operational information:

TLP (Traffic Light Protocol) marking, for sharing information;
PAP (Permissible Actions Protocol) marking, for handling information.

By combining these two internationally known marking conventions, the objective is to offer sufficient granularity to cover for both sharing and handling constraints in most use cases.

NB : these operational markings are no substitute for protection markings (such as Restricted) or for classified information markings (such as Secret or Top Secret) and for the associated rules provided for by relevant national regulations (such as IGI 1300 in France).

The marking used by ANSSI, the different sharing policies it applies and recommended associated security measures are described further herunder. In order to facilitate the understanding of these policies, use cases and a FAQ are also available.

1. TLP marking for sharing

Initiated by FIRST (Forum of Incident Response and Security Teams) which shares a standardized definition of it, the Traffic Light Protocol (TLP) is a convention widely used by incident response professionals.

With a scale on which each level is associated with a color, TLP provides a way to indicate how a given information can be shared.

In coherence with its operational needs, and for each TLP level, ANSSI details hereunder the operational interpretation applicable to the information that it produces and shares.

Operational interpretation of the different TLP levels applicable to operational information shared by ANSSI
TLP:RED	Limited sharing within a legal entity, with need-to-know principle applying. For instance: a constituent can share the operational information with part or all of a clearly identified internal team, on a need-to-know basis; sharing beyond the legal entity is forbidden; as the case may be, a constituent can share the operational information with embedded contractors on a need-to-know basis.
TLP:AMBER	*Sharing limited to identified entities bound by a commitment with the issuer (e.g. a closed community).* For instance: a constituent can share the operational information with both its embedded and external contractors, its subsidiaries and its group; a contractor can share the operational information with its clients or use it for the benefit of its clients.
TLP:GREEN	Free sharing within a clearly identified community (open or closed), further sharing allowed within these communities (contractors included). For instance: a constituent can share the operational information with its contractors, its group, its subsidiaries, its partners and peers within the community; however it cannot share this information publicly; a contractor can share the operational information with its clients, its group, its subsidiaries and peers within its community; however it cannot share this information publicly.
TLP:CLEAR	Public sharing, without restriction. Free sharing between communities, including on the Internet.

A community is a set of actors who share interests, constraints or even common rules in order to solve a problem or deliver a service. It is open if its members are informally linked together and when membership is generally implicit. It is closed if its members are officially linked together (via charter, contract, law…) and when membership is necessarily explicit.

NB: in version 1.0 of TLP, the TLP:CLEAR tagging was called TLP:WHITE; older publications may still contain this tag, which has the same definition.

2. PAP marking for handling

The Permissible Action Protocol (PAP) was introduced in 2016 in the taxonomies of MISP (Malware Information Sharing Platform), which is maintained and developed by the CIRCL.

PAP specifies how far a given information may be exposed. The idea is to define a set of possible actions taking into account the information it may reveal to a malicious actor. Like TLP, PAP has four different levels, with an identical color code.

ANSSI details hereunder the operational interpretation applicable to each PAP level.

Operational interpretation of the different PAP levels applicable to operational information shared by ANSSI
PAP:RED	Handling limited to infrastructures dedicated to investigation and detection: these infrastructures are accessible on a need-to-know basis only; these infrastructures are protected from public networks (eg. Internet) and from the shared infrastructures of the entity’s information system (hereafter « IS »); so as not to reveal anything about detection capabilities, only actions that are not visible from a potential threat actor are allowed, such as, for instance, searches, on a non production environment, on previously collected logs; direct or indirect interactions with third party services, as well as requests to such services, are not allowed. For instance: after collecting network/system/events elements, uploaded on a controlled and isolated network from which a constituent can monitor its infrastructures in order to either confirm the absence, or detect the appearance, of a specific threat; a contractor may use the information on an investigation or detection IS for the benefit ot its clients (this requires the information to be exported from the client IS to the contractor’s dedicated IS). The use of specialised IaaS/SaaS services is allowed if their contract guarantees the confidentiality of the handled data.
PAP:AMBER	Handling limited to a passive exploitation of data, ie. only to actions which are not visible by malicious sources. For instance: a constituent can make an open source search or query a knowledge base online in order to better qualify the information; a constituent can use the information within a compromised infrastructure in order to identify a malicious element (e.g.: detecting the presence of a malicious code during a hunting) Interactions, even indirect, with the system or infrastructure of the threat actor are forbidden.
PAP:GREEN	Controlled handling, allowing for non intrusive interactions with malicious sources. For instance: a constituent can block, at firewall level, incoming malicious traffic from a given IP address; a constituent can block, at a proxy server level, outgoing malicious traffic to a given web address.
PAP:CLEAR	Free handling in compliance with law and licences, no constraints relating to exploitation or handling of the information.

NB: to be consistent with the relabelling of TLP:WHITE into TLP:CLEAR, ANSSI has decided to use the PAP:CLEAR label.

3. Sharing policies used by ANSSI

By combining the sharing (TLP) and handling (PAP) marking described above, it becomes possible to define several policies that have enough granularity to cover the most common operational situations. Nevertheless, some TLP/PAP combinations are deliberately not applicable (N/A):

	PAP:RED	PAP:AMBER	PAP:GREEN	PAP:CLEAR
TLP:RED	P1	P2	N/A	N/A
TLP:AMBER	P3	P4	P5	N/A
TLP:GREEN	N/A	P6	P7	NA
TLP:CLEAR	N/A	N/A	N/A	P8

Only eight consistent TLP/PAP combinations have been selected by ANSSI; they are detailed in the tables hereunder. For each of them, examples of situations where they should apply are given.

P1 : TLP:RED/PAP:RED (click here for a detailed description)

P1 TLP:RED PAP:RED	This policy is for instance appropriate when the malicious source must not suspect it has been identified, in order to enable effective protection from it in the future.
Sharing	Sharing limited within the internal perimeter of an entity, on a need-to-know basis; this may apply to one or more clearly identified individuals, or one or more individuals within an organisational unit or project team, including embedded contractors who operate on the perimeter of the infrastructure in question. No further sharing is possible.
Handling	Handling limited to infrastructures dedicated to investigation and detection: these infrastructures are accessible on a need-to-know basis only; these infrastructures are protected from public networks (eg. Internet) and from the shared infrastructures of the entity’s information system (hereafter « IS »); so as not to reveal anything about detection capabilities, only actions that are not visible from a potential threat actor are allowed, such as, for instance, searches, on a non production environment, on previously collected logs; direct or indirect interactions with third party services, as well as requests to such services, are not allowed.

P2 : TLP:RED/PAP:AMBER (click here for a detailed description)

P2 TLP:RED PAP:AMBER	This policy is for instance appropriate in the case of an intervention on a potentially compromised network.
Sharing	Sharing limited within the internal perimeter of an entity, on a need-to-know basis; this may apply to one or more clearly identified individuals, or one or more individuals within an organisational unit or project team, including embedded contractors who operate on the perimeter of the infrastructure in question. No further sharing is possible.
Handling	Passive and not directly visible from malicious sources (if the latter make an effort to find out more). Use for detection, qualification, search campaigns, server log searches, etc. if necessary on a compromised infrastructure. Potentially open source search insofar as the malicous source would not be able to observe such search.

P3 : TLP:AMBER/PAP:RED (click here for a detailed description)

P3 TLP:AMBER PAP:RED	This policy is appropriate for needs similar to the P1 policy (the malicious source must not suspect it has been identified) but for a wider sharing perimeter, which means it is relevant in cases where the need for protection concerns several entities, or a community subset.
Sharing	One or several well identified legal entities (which may belong to distinct closed communities), with which they have a contractual (or more generally a formal) link, with no possibility of further sharing on their part.
Handling	Handling limited to infrastructures dedicated to investigation and detection: these infrastructures are accessible on a need-to-know basis only; these infrastructures are protected from public networks (eg. Internet) and from the shared infrastructures of the entity’s information system (hereafter « IS »); so as not to reveal anything about detection capabilities, only actions that are not visible from a potential threat actor are allowed, such as, for instance, searches, on a non production environment, on previously collected logs; direct or indirect interactions with third party services, as well as requests to such services, are not allowed.

P4 : TLP:AMBER/PAP:AMBER (click here for a detailed description)

P4 TLP:AMBER PAP:AMBER	This policy is for instance appropriate in cases where one wants to reach entities which are under a particular threat or are the subject of a malicious campaign. As the case may be, entities receiving the information may be directly concerned or may be contractors acting for the benefit of their clients: – in the former case, targeting is limited and the perimeter of recipients is known; – in the latter case, contractors are autonomous in identifying the entities likely to be affected.
Sharing	One or several well identified legal entities (which may belong to distinct closed communities), with which they have a contractual (or more generally a formal) link, with no possibility of further sharing on their part.
Handling	Passive and not directly visible from malicious sources (if the latter make an effort to find out more). Use for detection, qualification, search campaigns, server log searches, etc. if necessary on a compromised infrastructure. Potentially open source search insofar as the malicous source would not be able to observe such search.

P5 : TLP:AMBER/PAP:GREEN (click here for a detailed description)

P5 TLP:AMBER PAP:GREEN	This policy is for instance appropriate, in cases where one wants to allow clearly identified entities to take a proactive stance against a threat, such as blocking traffic from a malicious source.
Sharing	One or several well identified legal entities (which may belong to distinct closed communities), with which they have a contractual (or more generally a formal) link, with no possibility of further sharing on their part.
Handling	Potentially active and visible from the malicious source as long as it is not intrusive, which can include blocking the source of the malicious traffic.

P6 : TLP:GREEN/PAP:AMBER (click here for a detailed description)

P6 TLP:GREEN PAP:AMBER	This policy is appropriate for needs similar to the P4 policy but for a wider sharing perimeter, thus reaching an entire community. It will most probably be an entire sector and this may lead to a very wide sharing, but nonetheless not public. Unlike the P4 policy, the community will be able to exchange more freely between its members (typically through a user club), as the TLP:GREEN level favors intra-community exchanges. It will more probably be a community of constituents which will use the information to protect its own infrastructures (using their service providers where necessary).
Sharing	One or several well identified open communities.
Handling	Passive and not directly visible from malicious sources (if the latter make an effort to find out more). Use for detection, qualification, search campaigns, server log searches, etc. if necessary on a compromised infrastructure. Potentially open source search insofar as the malicous source would not be able to observe such search.

P7 : TLP:GREEN/PAP:GREEN (click here for a detailed description)

P7 TLP:GREEN PAP:GREEN	This policy is appropriate for sharing widely an information that may be used directly.
Sharing	One or several well identified open communities.
Handling	Potentially active and visible from the malicious source as long as it is not intrusive, which can include blocking the source of the malicious traffic.

P8 : TLP:CLEAR/PAP:CLEAR (click here for a detailed description)

P8 TLP:CLEAR PAP:CLEAR	This policy is appropriate for the public sharing of an operational information.
Sharing	Public sharing.
Handling	Free handling in compliance with law and licences.

OutsideTLP:GREEN and TLP:CLEAR, it is not possible for a third party who has indirectly received an information originating from ANSSI to share this information in turn.

In case of need such a recipient should contact ANSSI along with the initial recipient; ANSSI will then formaly authorise further sharing or will take upon itself to share this information with a new contact.

4. Security measures

This sharing and handling policy is not intended to impose a set of rules for information protection.

However, givent TLP and PAP marking, it is highly recommended to apply the measures described in the table hereunder. As the case may be, these measures can be further detailed in a contractual framework.

	TLP:RED PAP:RED	TLP:RED PAP:AMBER	TLP:AMBER PAP:RED	TLP:AMBER PAP:AMBER	TLP:AMBER PAP:GREEN	TLP:GREEN PAP:AMBER	TLP:GREEN PAP:GREEN	TLP:CLEAR PAP:CLEAR
Setting up an exchange framework	✔	✔	✔	✔	✔	No specific measures for these combinations. However, it is worth paying attention to the sharing and handling terms of the shared information.
Encrypting data in transit	✔	✔	✔	✔	✔
Ensuring transfer traceability	✔	✔	✔	✔	✔
Controlling access to stored data	✔	✔	✔	✔	✔
Ensuring access traceability	✔	✔

The table below details the security measures listed hereabove; these are deliberately generic and must be adpated or supplemented according to the specific situations considered.

	Associated security measures
Setting up an exchange framework	Transferof data must be formally agreed upon beforehand. E.g.: general terms and conditions of use, Open Licence, existing contract with additional clauses, if necessary.
Encrypting data in transit	The confidentiality of data in transit over an uncontrolled infrastructure must be ensured. E.g.: encryption of links (ex. : TLS, SSH, SFTP, IPSec) or data encryption (e.g.: Zed!, S/MIME, PGP, encrypted Zip file, use of a cryptographic library).
Ensuring transfer traceability	The transfer of data must be traceable: it must be possible to determine the source organisation and the recipient organisation as well as when the transfer was made. E.g.: email archiving, technical or functional logs, use of PGP or of X.509 certificates (mutual authentication), minutes or report of a meeting.
Controlling access to stored data	Data and its backups must be stored in such a way as to preserve confidentiality (vis-à-vis other internal teams or third parties). E.g.: encryption of storage spaces, nominative access control, use of a dedicated infrastructure.
Ensuring access traceability	Access to data must be traced (who, when, why) and records must be maintained over time, in accordance with applicable regulatory requirements. E.g.: functional and technical access control logs (given level, application or system), minutes or report of a meeting.

It is the stakeholders’ responsibility to implement the appropriate security measures taking into account the expectations expressed by the policies defined above. They should be implemented consistently throughout the information life cycle.

Information which is no longer used must be destroyed if ANSSI expressly requires it. Otherwise they are meant to be archived, in accordance with the constraints associated with their marking.

The recipient of the information may contact ANSSI in order to confirm the level of marking or in order to adapt the measures relating to archiving. It is also free to delete the information when it considers it is no longer relevant (at the end of the interest period for instance).

FAQ AND USE CASES