безопасность информационных систем

5 stages of inevitability to accept ISO/IEC 27001 certification. Bargaining.

5 stages of inevitability to accept ISO/IEC 27001 certification. Bargaining.

PUBLICATIONS \ 18.03.2020

The third stage of the emotional response to changes is bargaining. After dealing with our anger and emotional component, we began to think about what is really necessary to be done to make everything work for us. It was time to study the standard in more detail, apply it to our current situation and adapt its requirements to our company. Here it was important while meeting the requirements of the standard to “cut losses”. Any changes had to be adequate – i.e., commensurate with the corresponding risk. The expenses for protection should not exceed the possible damage from the materialization of risk.

Along the way, we had to solve many issues that we had never encountered before:

The choice of a tool for working on the policies library

The first (seemingly very simple) question we encountered was where to create and how to store all the necessary documents of the information security management system? It was extremely important for us to maintain the version control of the documents and to be able to “roll back ” the policy version by several editions. After studying the offers on the market, we decided on the Confluence wiki system and use it to this day.

We could use “git” as a version control system, but for the convenience of users, we chose a portal solution (Confluence). We managed to be limited with the free version (up to 10 authorized users): we didn’t need any more, since unauthorized users could view the library.

Preparing an implementation plan

We didn’t use any creative methods here – we just requested our consultant for a list of necessary policies, appoint those responsible for writing and approving them, set key dates, and made it all out in the form of a Gantt chart (which was also uploaded to Confluence).

Company risk assessment

Obviously, in order to choose the means of protection, we had to assess the risks (to spend resources only where it is really necessary). To do this, we created a list of the company’s assets that we plan to protect – it included both physical assets (workstations, servers, paper documents, etc.) and intangible assets (client information in electronic form, passwords, etc.).

With the help of an expert group, each asset was assigned a certain value. Then, we linked each asset to one or more risks that this asset may be exposed to (for example, paper documents may be stolen, destroyed, etc.). After that we assessed the significance of each risk as the product of two parameters: the probability of the risk and the significance of the consequences of the materialization of risk. After the risks were sorted into groups, we realized which ones we should work with firstly:

  1. Gaps in employees’ knowledge

The most common risk was the human factor. Moreover, we underwent certification for the first time, therefore we had a question of learning the fundamentals of information security. Having already developed the program, we encountered a problem of automating this process and controlling retained knowledge. As a result, we started using a test system that we built into our corporate portal.

2. Lack of backup computation power

This problem required vast financial and human resources, therefore it was wrong to keep it for later. We selected a platform for backing our key services: at the initial stage, we used IaaS (infrastructure as a service), which allowed us to quickly and cost-effectively set up a backup of the company’s key services; later, we purchased additional equipment and set up a backup in a separate data processing centre (co-location). Some time later, we withdrawn from the “cloud” solution in favour of the data processing centre owing to the large volume of data.

3. Control over “super-users”, as well as over those who work with “sensitive” data

In other words, it was necessary to establish control over users who have extensive access to confidential information. We solved this problem using the DLP system. We chose home-produced StaffCop software owing to the reasonable price and good technical support. 

Writing policies

Here we have involved all possible resources:

 – used policies of other companies that were freely accessible;

 – requested examples of policies from our consultant on the implementation;

 – wrote texts of the policies independently, based on the requirements of the standard.

In the end, it was the third (the most challenging way) that worked best. It was quite a long time, but at the end of this process we obtained well-compiled documents – precisely for our company. Thus, we have 36 main policies of the Information Security Management System (hereinafter referred to as ISMS).

Distribution of roles

Obviously, not all of these policies were really necessary for our employees in their daily work. In order not to force them to read too much, we did the following: we assigned each employee one or more roles in the ISMS (there were 5 of them in total – user, Head of the division, employee of the IT Department, employee of the Information Security Department, executive management). Absolutely all employees had at least one role – “user”.

In the datasheet for each role, we stipulated the corresponding obligations in the field of information security, attaching a list of policies that an employee who has a particular role should observe. Also, for the convenience, we have made a graphical organizational structure of the company specifying the roles of each employee on it.

Involvement of colleagues

Apart from the Project Manager and the Head of IT/Information Security Department, the company’s Chief Operating Officer was involved in risk assessment and description of the requirements of stakeholders. The Head of HR Department also had to be significantly involved – she had to describe the full employee life-cycle in the policy: from the application for a vacant job to the period after his or her dismissal. Fortunately, all our colleagues understood the importance of certification and met us halfway.

Technical aspects

During the preparation process, we realized that to meet the requirements of the standard, we will need at least the following:

  • Move servers to an external data centre;
  • To equip all offices with the ACS (access control systems).

Later, a considerable number of other things were added to these two items: the implementation of a DLP system, the launch of a backup data centre, the introduction of two-factor authentication, etc.

Therefore, to adapt the requirements of the standard to our company, we had to do quite a significant amount of work.