CSPN by example, Security Target

Spoiler: In France, the CSPN approach is a bit of a must for any security solution editor. The documentation is freely accessible but can sometimes confuse the neophyte. To find the north, we offer you today a commented example of Security Target, one of the two pillars of the approach.

Since 2008, security software editors wishing to certify the effectiveness of their products can look at the First Level Security Certification (Certification de Sécurité de Premier Nieveau, CSPN in short), a more affordable alternative implementation byt ANSSI of the Common Criteria (CC).

Where the Common Criteria are intended to be exhaustive, the CSPN favors costs and deadlines. Thus, rather than a global assessment that can last as long as it takes, the CSPN takes place in time and resource constraints.

Basic, 25 man-days, increased to 35 if cryptographic mechanisms are included. To be exhaustive, the ANSSI may ask to reduce or increase slightly depending on the situation, but in the end, it must remain between 15 and 50.

Certification Logo

In a CSPN (but also CC) approach, the first step is to write the security target. Often overlooked, it is nevertheless the most important document in the certification since it sets its scope: what it includes (security functions) and what it excludes (hypotheses).

If you want to write a security target, ANSSI provides a complete documentary repository concerning certification and methodology, but these documents may seem obscure to a neophyte. An example of target with netfilter is also provided but as it is not commented, it doesn’t help so much.

All the targets of certified products are available and therefore usable to get an idea of the content. Except i-Suite 5.5.5, don’t ask me why.

Even if the CESTIs (assessment centers) can write the security target for you before doing the evaluation, it’s always a good idea to understand what this document is about or better, provide them with a first draft to work on.

It is in this perspective of demystification that I present to you today my example of Security Target, which will use, for the cause, the blog developed for our exams (i.e. 2019). From this line, the body of the text constitutes the target, my comments will be in quotation.

Product identification

A Security Certification, CSPN, CC or whatever, is granted only for a specific product in a specific version. The purpose of this section is therefore to enable “unambiguous identification of the product”.

ANSSI has defined an official list of product categories that may be subject to a CSPN (section B2 of the accreditation procedure). They all have in common that they are products whose purpose is to provide a security function (i.e. intrusion detection, anti-virus, firewall, secure communication, etc.). blogs are not on the list. So, I chose the “Miscellaneous” category.


The target is intended to be communicated to customers, so that they measure the scope of the certification but also the interest of the product in terms of security. The purpose of the arguments is precisely to describe the product, its usefulness, how to use it as well as any constraints related to its use.

Product Description

Speed-e-Blog a piece of software that let you creat a website based on the blog principle. Each writer can publish articles (or blog posts) on the website where they will be listed and made available to the public.

In a philosophy of “Keep it Simple”, Speed-e-Dev wants to be easy to install, use and minimalist in its functionalities to focus on its mission: to facilitate communication between Internet users.

Product Usage

This section is not about how to use the product but rather about what use case and the problem the product is made for (for firewall or intrusion detectors, one may list the way the product can be deployed).

Speed-e-Blog, as a content management system allows a community to communicate:

Runtime Environment

This section complements the previous one to describe how the product fits into the existing infrastructure and interacts with other customer components.

Speed-e-Blog is a on the shelf web application that can be installed on a web server connected to the rest of your network. Readers and writers using their browser to read, add and delete articles.

The private or public use of the blog is done by restricting network access to the server hosting the application. A public blog that should be accessible from any Internet connection. A private blog that can be hosted inside the community’s computer system (or accessed through virtual private networks).

Typical Users

This section is sometimes missing from security targets but I find its content interesting. Even if it may seem redundant, it makes it possible to formally identify the categories of actors who can interact with the target as well as the typical actions, which will then facilitate the enumeration of assets and threats concerning the product.

You can think of this section as the “Use Case Diagram” or at least a simplified version listing the actors.

Speed-e-Blog can be used by two non-exclusive categories of users:

  1. The readers, simple visitors to the website who will consult the list of articles and read some of them,
  2. Editors, privileged users who can also add and delete their own articles.
Use case diagram (facultative)

By extension, even if they do not use the product, the following actors are also considered:

  1. System and network administrators, in charge of installing the product and keeping the IT infrastructure running smoothly.

Hypothesis about the environment

Hidden in the description section, it is however a very important section because it determines the scope of responsibilities between the product editor and his client. There are two pitfalls to avoid here:

  1. Making too many hypothesis, security relies more on the customer than the product (which in some case contribute to nothing). In this case, ANSSI may refuse the security target (and therefore a certification) because the target would be considered misleading.
  2. Not making enough hypothesis, the security then relies only on the product (and the editor). The risk here is related to the size of the attack surface of the product; the larger it is, the more vulnerabilities evaluators will be able to find.

The middle ground is to list here the realistic, customer-responsible security mechanisms necessary for the product to operate in an “honest environment”. If some seem obvious to you, remember that some products are precisely designed to operate in hostile environments and the threats that come with them.

Logical Security

Physical Security

Organizational Security

Scope of the assessment

This section determines the set of security features that will be evaluated and certified. For (too) large projects that fulfill several fundamentally different functions, some parts can be deliberately left out, hence the interest of this section.

To make the security target globally consistent, if one remove a portion of the product from this scope here, he will have to also remove it from subsequent sections (assets, threats & functions). In that sense, I see this section as a kind of summary of the security features that will be listed later.

The security target and product evaluation will relate to the following features:

Technical environment

This section aims to clearly establish the dependencies or the product. Where the “Runtime environment” section gave the main lines concerning the contexts of use, here the goal is to formally list all the technical prerequisites for the product to work. Sort of like “system configuration” on the back of video game boxes. There are generally three scenarios:

  1. On the shelf and mainstream products that can be installed in almost any condition. There are some constraints but they are easily respected.
  2. Niche products that are only installed in very specific environments. The constraints are then numerous and the editor will surely have to help the evaluators for the installation of a test platform.
  3. Specific all-inclusive products that carry their dependencies with them. The constraints are then very reduced since the editor provides everything necessary (sometimes going so far as to provide the equipment).

As the evaluation can only be done on a single test platform, it is sometimes impossible to test all the compatible combinations. The evaluator will then choose one that seems to him the most suitable (or the cheaper) and will carry out his work there.

You could of course constrain the evaluator to the platform of your choice by being very restrictive in this section, but be aware that the certification will then only concern this specific environment. The choice is thus also a question of marketing.


The hardware that can be used are those compatible with the selected operating systems and for use as a web server (equipped with at least one network card).


The application has been designed to work on any operating system allowing the installation of the software necessary for the operation of the product.


The application is compatible with any web application server as long as it meets the following two constraints:

  1. It has a PHP interpreter in version 5 or higher,
  2. It has a connection to a mySQL database server.

Assets to be protected

The notion of “assets” corresponds to the resources of the application (e.g. these can be data but also functionalities) and which it is wise to protect.

“Protection” of those assets means a security property that we wish to maintain. Here is the list of the three main ones (and still very classic):

  1. Confidentiality: only authorized entities have access to the resource,
  2. Integrity: only authorized entities modify the resource,
  3. Availability: the resource is accessible to authorized entities.

Although it is not mandatory, I find it more readable and more practical for the redaction of a security target to separate the assets into two categories: business and supports. Even if the terminologies will vary from one security target to another, the idea will remain the same.

Business Assets

Business assets correspond to the resources that the product provides or handles on behalf of users. These are in a way everything that is directly related to the expected functionalities of the product and that can be identified quite easily.

It is customary to number assets (but also to number threats and functions). Without going into the psychoanalytical considerations of obsessional neuroses, it is indeed useful in tables when there is not much space to write the items in full.

As part of its use, Speed-e-Dev protects the following assets:

Support assets

Support assets correspond to the resources that the product handles on its own account in order to guarantee its proper functioning. The fact of inserting a dedicated section makes it possible to think about it and to identify resources that we could have forgotten otherwise (i.e. event logs or cryptographic keys for internal use).

To ensure its proper functioning, Speed-e-Dev also protects the following assets:

Security properties

I always find it more readable to add this kind of table to summarize the relationship between assets and security properties. It is also an opportunity to check what is expected by customers and what the product really offers. You can no longer cheat with language effects.

ANSSI can also refuse a security target if it considers that the list of assets and properties is incomplete.

The following table summarizes the sensitive assets to be protected with respect to the security properties to be guaranteed. For simplicity, properties are abbreviated with their first letter.

Or rather for convenience so that it is displayed well on the small screens of our visitors who come to read the arsouyes website with a smartphone. In real life, put the titles of the columns in full and if it’s long, turn them by 90°.

Biens sensibles C I A
A1 - Articles
A2 - Usernames
A3 - Web browsers
A4 - Passwords
A5 - Fichiers de configuration
A6 - Configuration files
A7 - Servers

You can note that no asset is protected for availability. I will return to this point later in this article.


Threats are in a way the hinge between the security functions implemented by the product and the sensitive assets that these functions protect. Indeed, without threat to property, no need for protection. It is a principle and a method that underlies the Common Criteria approach and therefore the CSPN but also the other methods proposed by ANSSI (i.e. the EBIOS RM Method).

Threat Agents

This section is actually optional as long as the threats that will follow are properly characterized. I still find it relevant because it gives an idea of the sources of security problems and it is educational for the reader.

In the case of our blog, it will not be useful, but as I wanted to make an exhaustive example of the contents encountered in a target, here it is.

As part of this assessment, the following agents are considered:

As discussed in the assumptions, system and network administrators are considered trusted.

Some targets may introduce “mishandling” as well. Or other unintentional accidents. It only makes sense if the agent in question is not considered malicious (e.g. our nice administrators). If the agent may be malicious, adding inadvertent errors will be redundant and useless.

Attack Scenarios

An attack scenario does not need to be very elaborate nor precise. To be characterized, it must simply mention the actor, the action and the property impacted.

For the more technical among you, dear readers, we are not talking here about vulnerabilities (e.g. command injections). The difference is simple: a scenario is implemented by the exploitation of a vulnerability. So we will rather list what the attacker would like to do without trying to say how he would do it for real, and this for (among others) the following two reasons:

  1. We consider all means to achieve the same goal, we are not restricted to certain specific vulnerabilities.
  2. This leaves more freedom to the evaluator when testing the compliance and robustness of the product’s protection mechanisms.

You can still list the vulnerabilities for yourself (i.e. TOP 10 OWASP) and see if they fit into the scenarios, if not, you can add a new threats.

The following attack scenarios have been selected:

Threat and Asset Coverage

This is again a summary table, optional and therefore essential, relating the sensitive assets to be protected and the threats to them.

The following table summarizes the coverage of assets (which we will use the number followed by the letter of the security property) by the threats.

Menaces A1 I A2 I A3 C A3 I A4 C A4 I A5 C A5 I A6 I A7 C A7 I
T1 - Modification
T2 - Execution, browser
T3 - Deletion
T4 - Impersonation
T5 - Password theft
T6 - Account theft
T7 - File access
T8 - File changes
T9 - Execution, server

I really like these types of tables because they allow easy, fast and rather effective quality checks when it comes to security target consistency by answering two essential questions:

  1. All assets are covered, each column has a tick. If an asset does not have one, you have two options: add a new thread (if the asset is essential, you are able to explain why) or remove the security property on the asset (it may be less important than you thought).
  2. All threats make sense, each line has a check mark. If a threat doesn’t have one, you have two options: add an asset or a property (if the threat is important, you can explain why) or remove the thread (it may relate to unimportant things).

Security functions

Security functions include all the mechanisms put in place by the product to protect assets against identified threats. This is in a way the conclusion of our mini risk analysis and the implementation of security.

List of functions

Feature coverage of threats

ANSSI imposes to make the link between the security functions and the threats they prevent. We can do it directly when listing the threats but it is generally more ergonomic with a coverage matrix.

T1 T2 T3 T4 T5 T6 T7 T8 T9
F1 - Authentication
F2 - Access control
F3 - Storage
F4 - Filtering

As before, this table allows us to perform our quality check on the consistency of the target by answering the two new essential questions:

All threats are covered if there is a tick in each column, otherwise you have two options: 1. The threat is significant and you can argue it. Your product should therefore have mechanisms to counter it and you can list them. 2. The threat is not considered sufficient to require a specific defense, so the threat must be removed. Note that threat coverage of assets will therefore change and assets may need to be adjusted accordingly.

All functions make sense if there is a checkmark in each line. Otherwise, you have two options: 1. The function nevertheless seems important to you. You are therefore able to explain why, among other things by identifying the problem it solves, (this is your threat). Note that adding a threat will modify the coverage of assets by threats and you may need to adapt them. 2. The function seems superfluous to you, in this case, you can remove it.

Going back to the “availability” property which was dropped earlier, you can now understand the reasoning:

  1. If we retain availability, we need a threat, it’s quite easy, an attacker launches a denial of service on the application.
  2. If we retain this threat, we need a security function… we can imagine a redundancy of the application servers, a CDN, and a whole bunch of other things like that.
  3. We realize that these functions are not implemented in the product (it is a damn small PHP application) and are outside the scope of the product anyway.
  4. The function being absent, the threat is removed, and therefore the security property.

Cryptographic mechanisms

This section is “required” for all products implementing cryptographic processes. In fact, some targets rather refer to another specific document in the appendix. For the others, which contain this section, the form is rather free.

I propose here a structure directly inspired by the official criteria for CSPN certification, the best way to not forget anything.


The goal here is to list the cryptological functions offered by the product as well as the references to the algorithms used. The justification is simple, ANSSI can refuse a security target (and product certification) if the algorithms are “homemade”. or unfit for the purpose intended by the product (and we can understand them).

Password storage involves the following cryptographic process:

This method is not good practice because one-way functions are generally preferred. The certification of the blog will then be refused at the time one read the security target (for good reason) but I kept this algorithm because it let me complete the following sections.

Key management

Modern cryptography is largely based on the security of the keys used and therefore it is necessary to pay particular attention to their management: size, distribution, generation, storage and transmission.

Vernam encryption: The storage of each password involves a unique key, the same size as the password and generated randomly. These are stored in protected configuration files. It is neither distributed nor transmitted.

Those who have read the source code have seen that all this is not implemented. But if I had written the truth, this target would not have passed the ANSSI filters because it is far too coarse. So I documented something “cleaner” and it will be the job of the evaluators to show that the product is not compliant.

Data processing

The purpose of this section is to inform ANSSI and evaluators about additional processing of data that is subject to a cryptographic process, before and after processing (compression, encoding, headers).

Password storage: Before applying the cryptographic process, passwords are salted by adding a randomly generated prefix.

Ditto, that’s not true, but that’s for example… It would be less interesting if all the sections were “not applicable”.

Random number generator

This section aims to reassure on the generation of random numbers, by describing the methods used and showing that this generation is efficient.

System random generator The application uses cryptographic random number generators provided by the system and considered safe.

This way, I don’t need to dwell on how it works. In fact, this section is especially useful when you use your own random number generator (it is sometimes justified for certain products).

And after ?

With this target, you have now formally established what your product is for, what assets you consider important (and why), what you protect them against and how you do it. The target will surely go back and forth with the ANSSI, which will ensure its consistency before validating it, but you get the idea.

Et Voilà ! nickgesell @ pixabay

The product can then enter its evaluation phase. The purpose of which will be to check that the product complies with the claims of the target (the functions are present and resistant to attacks). It is only after this evaluation that ANSSI will certify the product (or not).

While waiting for the Technical Evaluation Report which will complete this example, you can always go and see the blog code