Strategic Elements

  1. Scope of the ISMS
  2. Strategic issues and directions
  3. Legal and regulatory aspects
  4. Needs scale
  5. Security needs
  6. Sources of threats

1) Security Rules#

1. Organization#

  1. Security policy
  2. Security organization
  3. Information‑security risk management
  4. Security and lifecycle management
  5. Assurance and certification

2. Implementation#

  1. Human aspects
  2. Business continuity planning
  3. Incident management
  4. Awareness and training
  5. Operations
  6. Physical and environmental aspects

3. Technical#

  1. Identification / authentication
  2. Logical access control
  3. Logging

2) Action Plan#

  1. Business Continuity Plan / Disaster Recovery Plan (BCP/DRP)
  2. Monitoring and alerting
  3. Backups and environment management
  4. Equipment management
  5. Flow isolation
  6. Access management
  7. Antivirus policy
  8. Supplier management and IT charter
  9. Roadmap

==Strategic Elements==

This section of the plan defines the scope of your ISMS. In it you will specify:

  • The assets involved – both hardware (servers, workstations, network equipment, etc.) and intangible assets (data, software, procedures, etc.).
  • The human resources that will take part in implementing the policy.
  • The objectives of the initiative, together with the constraints (budget, legal requirements, timelines, etc.).

Next, you must create a needs scale ranging from 1 to 4, evaluated against three fundamental criteria: Confidentiality, Availability, and Integrity. This scoring will determine the required security level, i.e., the relationship between the PSSI’s scope and the previously defined scale.

For example, the table below illustrates how a score can be assigned to each domain:

Domain Confidentiality Disponibility Integrity
Servers 4 4 4
Networks 4 4 4
Terminals 3 2 2
… … … …

Finally, you will identify the origins of the relevant threats to your activity. Your ISMS, for example, may consider natural disasters a credible threat, just as it would regard staff whose contracts are ending or who seek revenge.

==Organisation==

You must specify in this section the individuals who will take part in drafting your ISMS, as well as the methods for distributing and adopting the document. For example, you could decide to incorporate the ISMS into the company’s internal regulations or reference it in employment contracts. You will also outline the sanctions that apply in case of non‑compliance with the ISMS.

==Implementation==

This section lists the essential elements for securing the information system, typically derived from an operational audit. It specifically defines:

  • User awareness measures—such as organizing interactive workshops;
  • Operational policies for the information system—like procedures for controlling remote‑maintenance activities;
  • Physical protection safeguards for equipment and facilities.

==Technical==

Finally, the last section of this chapter will cover the IT techniques that must be implemented to ensure compliance with the previously defined items. It will discuss authentication mechanisms (passwords, certificates, etc.), access controls (VLANs, 802.1X, session locking, …), as well as logging and tracing of user activities.

==Action Plan==

The example ISMS plan presented here includes an action plan that will likely differ from yours. Indeed, your action plan will stem from the preceding chapter and therefore be unique to each organization. Nevertheless, this plan covers the most common items involved in implementing an ISMS: Business Continuity/Disaster Recovery (BC/DR), monitoring, backups, management of assets, data flows and access rights, antivirus solutions, and the IT charter (both internal and dedicated to service providers).

For each project you will specify the selected solutions and tools required to carry out its implementation, and organize everything into a timeline. You may also attach a budget estimate for each resulting project. In this way, your ISMS will be ready for approval by the governing bodies defined in the “Organization” section.

Another consideration regarding the straightforward development of an ISMS, taken from a document translated from French (author: Giles Carré – CISO, INSA Toulouse).

==Resume==

When asked “Do you have an ISMS?” every CISO should be able to answer, “Yes, of course!” Unfortunately, that is far from always the case. Many CISOs, like the author of this article, work only part‑time in the role (officially 10 % in this instance). In such a situation the CISO’s activity is essentially operational and rarely organizational.

So how can an ISMS be developed under these difficult working conditions, and where should one start? Existing methods—plenty of them—talk about consultations, risk analyses, support, etc., but the task feels overwhelming when you think you have to start from scratch. In reality we rarely start from nothing because we already have a set of formal or informal foundations: mission statement, IT charter, internal regulations, master plan, management of IT accounts, procedures, best practices, and so on. Some of these documents are even approved by the board or another committee, giving them immediate authority. Together they constitute—albeit imperfectly—a de‑facto ISMS.

By aggregating all those documents and structuring them properly, it is possible to create an initial, implicitly validated ISMS. From there it becomes much easier, within a few months, to develop a new, more comprehensive ISMS that aligns closely with guidelines such as the ANSSI’s version 6.

This article aims to answer a few basic questions and outlines the steps for building an ISMS. It does not propose a formal methodology but rather shares a practical experience from a medium‑sized organization. Hopefully it will provide some ideas for those still stuck at the starting line.

Why develop an ISMS?

Before embarking on the creation of an Information Systems Security Policy (ISMS), we must first convince ourselves of its usefulness. Public institutions are required to have an ISMS. This requirement is reiterated in the State’s ISMS (PSSIE) 6, in the instructions for protecting sensitive information systems (Interministerial Instruction II 901) 6—especially in a Restricted‑Regime Zone¹ (ZRR)—and in the General Security Framework (RGS) 6.

But that is not the only reason; the most important one is very concrete. Benoît  Moreau, Security Officer (FSSI) at the Ministry of Higher Education, Research and Innovation (MESRI), said during his presentation on security at the JRES 2015 conference  6:

“Information systems are becoming colossal e‑structures built on fragile foundations; repeated shocks and major incidents will inevitably occur. We must now plan and organise appropriate measures to increase robustness and ensure resilience. […] Without an ISMS, you won’t succeed.”

Clearly, we must view an ISMS not as a burden or merely as a response to yet another statutory requirement, but as a working tool without which a purely technical response would remain ineffective.

What should be included in this ISMS?
A web search yields various published ISMS documents from both public institutions and private companies, and their content varies widely. We encounter:

  • Very legalistic ISMS that resemble terms and conditions—those unreadable twenty‑page documents we must accept when buying something online before proceeding. Their drafting was likely driven by lawyers, primarily to protect the organization rather than to serve operational needs.

  • Highly technical ISMS that sometimes disclose too many details about the measures implemented or the institution’s internal organization.

  • Documents of vastly differing length, with the longest ones occasionally feeling like filler intended to impress.

These observations are not criticisms; they are simply factors to keep in mind. Since we do not yet have our own ISMS, it would be inappropriate to mock these efforts, which address specific needs and represent legitimate responses from different perspectives.

The National Agency for the Security of Information Systems (ANSSI) publishes an excellent guide for developing Information Systems Security Policies  6, which addresses both the content and the methodology for creating and revising an ISMS. Its main components are:

  • Formulating strategic directions that reflect the organization’s leadership vision for information security; these directions must be consistent with the overall IT strategy, which may be expressed in an IT master plan and, depending on the type of strategic alignment, in the organization’s policy.
  • A risk‑analysis‑based approach.
  • Project‑mode operation.

The guide presents an ideal methodology, and it will certainly be useful to rely on it. The difficulty, however, lies in securing the resources needed to launch such a project, even when external assistance is enlisted.

2.1 Content

Our goal is to start with a simple ISMS and produce a document that is useful on a day‑to‑day basis for the operational management of information security in our institution. This initial ISMS will serve as the foundation for a more elaborate ISMS that will evolve over time. Therefore, we aim to “keep control” of the content to obtain an operational ISMS that can be applied directly. In this initial ISMS we will avoid any elements that are not immediately useful.

2.2 Recipients
As the ANSSI guide notes 6, the ISMS is a tool for raising awareness of information‑security risks. It must be widely distributed to users, staff, and partners, so it must not contain confidential details or information that could facilitate attacks. One way to simplify the selection process is to follow the Traffic Light Protocol (TLP) 6 and retain only “WHITE”‑classified information, i.e., material suitable for unrestricted dissemination. If we want the ISMS to be broadly shared outside our organization, even “GREEN”‑level information should be excluded.

2.3 Format
We should not fear being brief. The ISMS is an evolving document built step by step. If we lack material for a given section, we should note it for a later stage, but we must avoid the trap of padding. Padding would be counter‑productive, producing a heavy, tedious, and ultimately useless document. For this initial ISMS we will keep it short and will not be afraid of gaps, because the absence of an ISMS that follows a method such as ANSSI’s does not mean we are not managing our information security: we are applying state‑of‑the‑art practices, but—as Benoît Moreau warned—we know that without an ISMS it will be insufficient.

3. Guiding principles for our initial ISMS
All the fundamentals have now been laid out. To make our initial ISMS successful, we must:

  • Treat it as a daily‑working document;
  • Write a readable, concrete, and as‑short‑as‑possible document;
  • Target it to users, staff, and partners;
  • Avoid revealing technical or organisational details that could aid attacks.

4. How do we develop our ISMS?

We have a general sense of where we want to go, but now we must avoid being overwhelmed by the amount of work required. Moreover, the fact that we do not yet have an ISMS indicates that the ideal construction approach has never been feasible with our internal resources. Of course, we could enlist external assistance, but from our perspective this would present two major drawbacks given our starting point:

  • As we have already stated, we want to retain control over the content and make it a daily‑working tool. Therefore, we must design the ISMS accordingly and keep ownership of its development. In other words, this initial ISMS will be a directly applicable policy created by the IT staff responsible for system security and intended for users, employees, and partners.

  • Because of our limited experience with ISMS matters, it would be difficult for us to manage an external consultancy that follows a textbook methodology but may not fit our specific context.

4.1 First Version of the ISMS

As mentioned in the introduction, we are not starting from scratch. First, like many organizations, we already have an operational information‑security program. It follows best‑practice standards, and we have never experienced a visible major incident. One might think we are already effective, but that is insufficient (see 6):

  • We expend a great deal of energy managing this security program on a daily basis;
  • We cannot guarantee that our protection is exhaustive.

Nevertheless, we do have several concrete assets that can serve as a foundation:

  • The IT Master Plan (SDSI) 2011‑2015, approved by the institution’s Board of Directors;
  • The Digital Master Plan (SDN), which will replace the SDSI and is currently being developed with external support;
  • ISO 9000 certification for the Information‑System process;
  • Decision records from the Boards of the Digital Services Center (CSN);
  • Decision records from the Users and Stakeholders Committees for the IS;
  • The lifecycle management policy for IT accounts, approved by the Board of Directors;
  • The IT Usage Charter, approved by the Board of Directors;
  • The co‑administration contract for a workstation;
  • The CISO’s letter of mandate signed by Management;
  • Internal written documentation produced by the IT department;
  • Written documentation intended for users, staff, or partners;
  • Established procedures and practices that are already considered de‑facto.

Our first task is to gather all existing material, extract the parts that pertain to information‑security, and consolidate the result into a single document:

  • Retaining only the elements that relate to information security and are of interest (objectives, means, rights and obligations of users, staff, CSN members, partners, etc.);
  • Keeping only information that can be disseminated widely (“TLP White”).
    • and, very importantly, include a reference to the original source for each statement.
  • The aggregation must be organized.

To structure the first document we could follow the division into 16 domains grouped into three sections from the security‑principles framework presented in the ANSSI guide 6:

  • Organizational principles;
  • Implementation principles;
  • Technical principles.

However, at first we chose to structure our initial security policy according to the 13 main chapters of rules in the PSSIE 6 in order to more easily meet two objectives:

  • Identify the points where we are not compliant with the PSSIE;
  • Better respond to the annual compliance questionnaire.

The file is assembled through several iterations:

  • Drafting by the CISO;
  • Consultation with the team responsible for information security;
  • Consultation with all CSN staff;
  • Consultation with the Defense Security Officer (FSD).

The document constituting ISMS version 1.0 is then presented to Management:

  • Presentation of the overall approach (initial ISMS and its evolution);
  • Formal endorsement of the approach and of the first version;
  • Consideration of comments for future revisions.

This endorsement is obtained for the format because ISMS 1.0 reflects the current state of affairs and is indisputable; therefore its approval is requested on that basis. Consequently, everything presented in it must reference the existing validated documents. Likewise, any potentially controversial topics should be removed before submission (better to keep them for a later phase) to avoid rejection, which would undermine the whole simplicity‑driven approach.

Finally, communication at each stage should be handled carefully (consulting colleagues, consulting management):

  • Announce well in advance that a PSSI is being drafted;
  • Clearly convey the importance of the PSSI;
  • Explain the objectives and the step‑by‑step methodology;
  • Emphasize that this is a locally initiated, simple, low‑cost effort;
  • Choose the appropriate first approver for submission (for us, the Director General of Services). After completing those steps, we have an official document that we can put to use.

4.2 Second version of the ISMS
During the preparation of version 1.0 of the ISMS, gaps were identified and comments were made. We need to incorporate those items into the second version, ISMS 1.1, which requires making trade‑offs and conducting technical studies. The goal of this new phase is to produce a published ISMS. Accordingly, we must have it approved by Management and then by the institution’s Board of Directors. At the time of writing this article, we are at that stage. We will probably have to wait for the conclusions of the new Digital Master Plan before we have a definitive deliverable.

4.3 Evolution
We have produced version 1 (1.0 and 1.1) of our ISMS based on our history and the expertise of all stakeholders. Nothing guarantees, however, that we have not overlooked important points 6. Therefore, it would be advisable to implement a project‑based approach to continue building and evolving our ISMS, following a more formal method such as the one proposed by ANSSI 6.

5 Conclusion
We now have an ISMS. But we must remember that it is an initial ISMS that will need to evolve. To do so, we can either follow a fully standardized method (risk assessment, project management, etc.) or, perhaps, engage external assistance that we will now be better equipped to manage. This initial ISMS already allows us to articulate our security policy and position ourselves on a daily basis. We will thus have a guide that respects the rules; and, in spirit, we must not forget that information‑security is not an end in itself but a means to enable the institution and its users to carry out their missions under the best possible conditions.

¹ A ZRR is a regulated‑access location subject to the Protection of the Nation’s Scientific and Technical Potential (PPST). Its information system is classified according to sensitivity levels defined in II 901, with the default level being Restricted Dissemination (DR), which is extremely restrictive.