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.

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”.

• Publisher organization: Speed-e-Devs,
• Link to organization: Not applicable,
• Product trade name: Speed-e-Blog,
• Reviewed version number: Speed-e-Blog version 2.0,
• Product Category: Miscellaneous.

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.

Arguments

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:

• Privately, only members of the community have access to the application. Speed-e-Blog thus facilitates the sharing and saving of articles related to the activity of the community.
• In a public way, any Internet user can access the content, Speed-e-Blog then facilitates marketing communication by informing the public or creating a community of fans.

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.

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

• The IT infrastructure (networks, servers and third-party software) is secured in accordance with section 2.1 of the “guidelines for securing websites” ANSSI, official document,
• The application was installed according to the instructions provided in the product documentation.

Physical Security

• Computer equipment (web server and database) must be located in secure premises, access to which is controlled and restricted to administrators.

Organizational Security

• Administrators are considered trusted, and trained in good practices in computer 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:

• Authentication,
• Access control,
• Storage,
• Input filtering.

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.

Hardware

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).

System

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

Software

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:

• A1 - The articles published by the editors, protected for integrity.
• A2 - The name of the editors used to identify themselves, protected for integrity.
• A3 - The web browser used by readers and editors, protected for confidentiality and integrity.

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:

• A4 - Passwords used by editors to authenticate themselves, protected for confidentiality and integrity.
• A5 - The configuration files used by the application for its configuration, protected for confidentiality and integrity.
• A6 - The source code used by the application for operation, protected by integrity.
• A7 - The servers used for the operation of the application, protected for confidentiality and integrity.

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°.

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

Threat

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:

• Malicious readers wishing to divert the use of the application,
• Malicious writers also wishing to hijack the use of the application.

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:

• T1 - Fraudulent modification An attacker manages to modify the content of an article by another writer.
• T2 - Execution on the browser An attacker manages to send code and have it executed on the reader’s computer.
• T3 - Fraudulent deletion An attacker manages to delete the data (articles and writers accounts)
• T4 - Impersonation An attacker manages to impersonate a writer and publishes articles in his name.
• T5 - Password theft An attacker manages to read an writer’s password.
• T6 - Theft of an account An attacker manages to change a writer’s password.
• T7 - Fraudulent access to files An attacker obtains read access to file system and configuration files.
• T8 - Modification of files An attacker manages to modify the source code and the files of the application.
• T9 - Execution on the server An attacker hijacks the application to make it execute arbitrary code, he thus obtains control over the server and the files located there.

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.

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

• F1 - Authentication: Users are identified by their pseudonym and authenticated by a password, known only to them.
• F2 - Access control: Access to the functionalities of the application, in particular the deletion of an article, is restricted to authenticated and authorized users only (e.g. only the author of an article can delete it).
• F3 - Password Storage: The storage of passwords in the database uses a secure cryptographic process.
• F4 - Input filtering: the data received by the application is filtered to prevent any injection and/or hijacking of the application.

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.

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.

Algorithms

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:

• Password storage: using Vernam cipher.

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.

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…