the tale of the three heroes in a new way

Hi all! My name is Andrey Skripkin. Even when I was a student, I realized that I wanted to work in information security – my brother got me into it. More than 15 years have already passed, and interest in the profession is only growing. And even when it seemed that, having worked in various information security integrators and tried myself as an engineer, designer, architect, leader of teams of engineers and designers, I had already seen everything, the world of information security throws up something new and gives the opportunity to study further and discover something new. Now I have been working at Positive Technologies in the engineering department for two years: I am implementing projects based on PT products. And this, on the one hand, is similar to my previous experience working in integrators, and on the other hand, this is new experience, new approaches to project management and a new level of expertise.

Perhaps the most important thing I understood about projects during my work is that the most important thing is people. People who implement the project. And the success of the entire project depends on how these people interact with each other. A good engineer will always “tame” any technology and overcome any problems with software – and a good manager will always find a compromise in controversial situations.

In this article I want to share my experience: tell you how to implement projects productively and build relationships between project participants – customer, integrator and vendor.

Project participants

Always plays a key role in any project customer. And the most important thing for the customer himself is that he needs this project, so that the people responsible for the project understand why they are doing this and what problems the project must solve. The goal of the project is not to “do it for show,” but to get real benefit from the result.

I very often encountered situations where, after completing commissioning and acceptance tests, the system either turned off altogether or was not used. And then everyone was surprised: why did the incident happen, and most importantly, what to do now? I also came across situations where the software was purchased, but the implementation was not carried out. And then an incident occurred, and we had to disconnect the entire IT infrastructure from the Internet and urgently look for someone who could implement the system in one day. As a performer, I'm always sad when this happens.

But in most projects, I saw how the eyes of the manager, who himself decided to work with the DLP system, sparkle, and how the IT service, which found the miner on the network with its help, respected the SIEM system. I saw the joy of the information security specialists who were able to prevent the incident.

Use security systems. Don't put them on a shelf.

In addition, a team consisting of different people from different departments is always involved in the implementation of the project on the part of the customer. These include managers, IT specialists, and the information security department. And success will come when each of them understands why the project is needed and what their role is in it. It often happens that IT and information security services do not get along with each other – here it is important to look for a compromise and the overall benefit of the project so that each participant is interested in its implementation.

Integrator is a formed expert team. It should include the project manager, information security consultants, architects, designers and engineers.

The entire organizational part depends on the project manager: plan, schedules, meeting deadlines, solving administrative issues. The project manager must be a task manager for engineers and designers, otherwise the work will be drawn out and not done very well.

The remaining tasks are distributed as follows:

• Information security consultants analyze processes in the customer’s organization, model threats to information security, and develop organizational protection measures (policies, regulations, standards, information security regulations).

• Architects or designers develop design documentation and determine technical protection measures.

• Engineers carry out commissioning work.

This division of roles, in my experience, is the most balanced (it must be taken into account that designers and engineers must have experience working with the products on which the protection system is based).

Project managers on the part of the integrator and the customer must agree on all organizational issues at the start of the project: develop a schedule and resource plan to determine how much work will be carried out by the integrator and what by the customer. When there is a schedule, the project becomes structured and manageable. In addition, at the start of the project, methods of interaction (through video conferencing or with visits to the site) between performers on the integrator’s side and performers on the customer’s side should be determined. All this helps to plan resources and project implementation time in advance.

Vendor – a project participant who primarily supplies a software or hardware-software solution on the basis of which the future system will be built during the implementation of the project. Also, the vendor always has technical support, and you need to use it. If an integrator or customer encounters a problem at any stage of the project or during operation, he can contact the vendor and ask for help.

In some cases, the vendor may be the executor or co-executor of the project – and provide its architects, designers and engineers. Positive Technologies has an engineering department for such tasks, where architects, designers and engineers work. Services are provided within the framework of various interaction models: this includes consulting, contract work, and professional services (under a certificate).

Deciding on project participants is usually not difficult. As for the process of project implementation itself, I am a supporter of decomposition: the project is divided into stages, the stages into substages, and the substages into tasks. This way it becomes clear what to tackle and in what order: the mammoth is eaten in parts.

Stages

Stage 0. Piloting

I indicated this stage as number 0, since this is not a full-fledged stage of the project, it is more like a pre-sale. And in my opinion – not the most effective. Many people will disagree with me, and when I gave a talk at Positive Hack Days Fest, this topic received the most questions. When I worked for an integrator, I had practically no pilots – this was unprofitable for the integrator. While working at Positive Technologies, I took part in a large number of pilots and often came across a situation where a pilot is carried out “for show” – but not for the sake of sales. At the same time, there are also projects where the pilot cannot be avoided: its implementation may be prescribed in the customer’s internal regulations.

When conducting a pilot, its goals and objectives must be clearly defined: this is the only way to understand whether it is needed at all. In addition, you need to understand that a pilot is a time (and therefore monetary) cost not only for the integrator and vendor, but also for the customer. And perhaps it would be more effective to conduct a demonstration (including at a stand), offer training, or organize a “reference” visit to a company where the product is already used.

Stage 1. Development of technical specifications

This stage is performed first of all by the customer, formulating a request and determining what he wants. This is one of the most important stages: in addition to the fact that the procurement procedure and subsequent acceptance of the system into operation will be carried out based on the document drawn up, a correctly formulated task and clearly defined requirements are half the success of any project.

Well, it is desirable that the requirements are feasible. Therefore, before starting a project, it is important to study the capabilities of the products and understand which one suits you best and what requirements to specify. But if you really need some functionality that is not implemented in the product, you can try to request it: in my practice, there have been cases when either the vendor modified the product, or the integrator came up with work around (“crutches”) to implement a specific need.

In general, teams that implement projects are usually very inventive and sometimes do brilliant things. As a rule, these are scripts, non-standard integrations of various products, code modification (if the product is open source). But after testing, it turns out that there is no one to accompany such “crutches” and no one is ready to take them for support. An ingenious solution dies; at best, it ends up in the vendor’s development backlog with the prospect of someday appearing in a product.

When the technical specifications are prepared, a competitive procedure is carried out, and the winner is determined – the integrator. The integrator gets to work and begins with an examination.

Stage 2. Examination

The customer and the contractor participate in this stage (can be either an integrator or a vendor, if the implementation is carried out by the vendor’s team). It is important here that the contractor identifies as fully as possible the information that will be needed within the framework of the project, and the customer provides it as completely and honestly as possible.

To save time for all participants, I always try to ask most of the questions in questionnaires. First, a general questionnaire is compiled to get a general idea of ​​the IT and information security infrastructure in the customer’s organization, then, based on the information received, clarifying questionnaires are prepared for each area. And if some information could not be obtained using questionnaires, you need to move on to interviewing. This scheme has never failed, but it can take varying amounts of time, depending on the customer’s readiness for questions.

For me, the most important thing in a survey is to receive a network diagram from the customer. When you have a picture before your eyes, often the only questions left are clarifying ones. But I often encountered the fact that the customer did not have a ready-made diagram or its detail was insufficient. In this case, the most effective thing is to sit down with an IT or information security specialist next to you and together draw a diagram on a piece of paper, and then convert it into digital format and agree with the customer.

I will dwell on one more important point. It often happens that the contractor takes a standard questionnaire and sends it to the customer – without analyzing his request and without personalization. And then he is surprised that the customer does not understand why they are asking him for router models if an antivirus is being implemented. All questionnaires must be adapted to a specific project and a specific customer. It is necessary to respect the customer’s time, then the customer will provide more accurate and complete information.

After the survey, new input always appears, which radically affects the implementation of the project. And after the examination, as a rule, it is necessary to draw up another technical specification, which specifies the requirements specified by the customer in the technical specification at stage 1.

Stage 3. Adaptation of technical specifications

This stage is primarily the work of the integrator. Based on the survey, the integrator classifies the customer’s information systems, identifies current threats to information security and specifies the requirements specified in the original technical specifications.

I have not had a single project where this stage was not needed. Threat surveys and modeling always make adjustments to the project.

Stage 4. Design and development of organizational and administrative documentation

When all the requirements are defined and recorded, it is necessary to prepare all the documentation for the project. How quickly and efficiently the implementation will be carried out depends on how well the project documentation is written.

In discussing the documentation, I would like to return once again to the stage of developing the technical specifications (stage 1). There is no need to include in the technical specifications the entire set of documents in accordance with GOST for the development of automated systems or for the development of automated systems in a secure design. When drawing up technical specifications, it is important to understand which documents are really needed and will be useful. It is very strange to sometimes see in the technical specifications for a protection system the document “List of input and output signals”, which is in no way applicable to the system being created.

The most important documents, in my opinion, are various diagrams reflecting technical protection measures: specification (or list of purchased products), explanatory note, test program and methodology, as well as working documentation reflecting the parameters and placement of the system being created.

It is very important to have a set of project documentation and keep it up to date, so that when you change IS specialists or teams, it doesn’t turn out that no one knows what has been implemented, why and how it works.

Well, we should never forget that security is a set of technical and organizational protection measures. Organizational and administrative documentation needs to be developed not only when required by a specific Federal Law or FSTEC order, but in any other cases. Regulations and orders are all effective tools of an information security specialist.

Stage 5. Supply of software and hardware

At this stage, the contractor supplies software and hardware developed by the vendor, and the customer puts them on the balance sheet.

I highlighted delivery as a separate stage because it always needs to be taken into account when planning work. In some cases, delivery may take six months, and the composition of the supplied funds must be determined as early as possible, but not to the detriment of the quality of the project. Typically, the purchasing specification can be prepared early in the design phase (Stage 4).

Once the delivery of software and hardware is completed, implementation can begin.

Stage 6. Implementation

When I just started working as a designer, my boss (in the design department) said at some general meeting of the information security department that implementation engineers are the most important people on the project. There are mistakes in surveys, there are mistakes in design, but there can be no mistakes in implementation. Engineers are always at the forefront.

I have not had a single project in which I did not have to make changes based on the results of implementation. And this is actually a normal story, because at the implementation stage pitfalls are always discovered: all infrastructures are different and it is impossible to take everything into account.

Engineers must be valued, protected and respected – both from the customer and from the contractor. The success of the project primarily depends on their coordinated work.

The completion of any implementation is:

1. Preliminary tests — checking the system for correct functioning in the customer’s infrastructure.

2. Trial operation — checking the operation of the system before accepting it into permanent operation.

3. Acceptance tests — checking for compliance with the requirements of the technical specifications or the requirements of the test methodology (checklist indicating “passed” or “failed the test”); can also be conducted in the format of cyber exercises (a team of red hackers comes and tries to break you, this is a fairly effective testing method).

4. Certification tests — checking the system for compliance with the requirements of regulatory documents, if this is provided for in the technical specifications.

Stage 7. Operation

The customer is never left alone with the product: he always has technical support from the vendor. Therefore, although operation is no longer part of the project, I have identified it as a separate stage in the existence of the system.

A system is a living organism, so it need to operate, constantly upgrade, and timely purchase equipment and update software.

And a short summary in conclusion

For me, the most important thing in any project is the people who take part in it, as well as their ability to understand each other, complement each other, and ability to work in a team. It often happens that after a big project, people who did not know each other before become good friends and continue to communicate outside the project. Any project encounters technical, organizational, and political difficulties, but the ability to negotiate solves any of these problems.

Thus, the main stages of the project:

1. Often the pilot is superfluous.

2. System requirements must be feasible.

3. After the survey, the requirements must be adapted to the customer's system.

4. System documentation must be kept up to date.

5. Consider delivery times during the planning stage.

6. Don't put the system on a shelf, use it.

7. The system must be alive and constantly improving.

Andrey Skripkin

Chief architect of complex projects, Positive Technologies