SOT

SOT

SOAR
Security Orchestration, Automation and Response

Automation of response to information security incidents using dynamic playbooks and information security tools, building an attack chain and with an object-oriented approach

NG SOAR
Next Generation SOAR

Automation of response to information security incidents with built-in basic correlation (SIEM), vulnerability Scanner (VS), collection of raw events directly from information security tools, dynamic playbooks, building an attack chain and an object-oriented approach. AM and VM are included

AM
Asset Management

Description of the IT landscape, detection of new objects on the network, categorization of assets, inventory, life cycle management of equipment and software on automated workstations and servers of organizations

VS
Vulnerability Scanner

Scanning information assets with enrichment from any external services (additional scanners, The Data Security Threats Database and other analytical databases) to analyze the security of the infrastructure.

VM
Vulnerability Management

Building a process for detecting and eliminating technical vulnerabilities, collecting information from existing security scanners, update management platforms, expert external services and other solutions

FinCERT
Financial Computer Emergency Response Team

Bilateral interaction with the Central Bank, namely the transfer of information about incidents and receipt of prompt notifications/bulletins from the regulator

GovCERT
Government Computer Emergency Response Team

Bilateral interaction with the state coordination center for computer incidents, namely the transfer of information about incidents and receipt of prompt notifications/bulletins from the regulator

Mail us to sales@securityvision.ru or get demo presentation

Features of strategic and operational thinking

Features of strategic and operational thinking
13.11.2025

Eva Belyaeva, Security Vision


Introduction


We have already told you how difficult it is to make friends with developers and AppSec, security guards and colleagues from IT. This time, let's look at what difficulties can arise within a company when people with different approaches to work interact: strategic and operational.


To simplify, we will reduce the analysis to the analysis of the main conflict within any project activity – between those who set tasks and those who implement them. Simply put, between management and subordinates.


Such things happen in companies of any orientation and size, and judging by what colleagues from other organizations tell me, the situation is systemic.


Why is this a problem


Very often, when setting a task and discussing the result, there is a discrepancy between what is desired and what is actual, and both sides of the dialogue cannot hear and understand each other.


Perhaps if one of the opposing sides can put himself in the other's place, then the intensity and degree of negativity will decrease slightly, and it will be possible to better understand the interlocutor and adjust his work in a more productive way.


After all, when we talk about strategy, we mean far–reaching plans, promises and money. Global goals, without which the company cannot just develop and grow, but in general, exist and maintain staff.


The operating system is somewhere lower, where a seemingly simple task becomes overgrown with the tinsel of smaller tasks and decomposes into smaller subtasks, each of which can stall the entire process.


Let's look at examples of how such situations arise and what can be done.


Work conflicts


If you have ever attended a meeting with acceptance and delivery of work, you have definitely come across what happens after: subordinates, in case of failure, leave upset and continue to wind themselves up in the smoking room and in the kitchens.: How come we spent hours, weeks, and days overworking, exhausted, and all for nothing? At the same time, at the meeting itself, the management openly expressed their attitude to the problem: you had the main task, you spent a lot of time and for some reason you did two others instead, what's wrong with you?


As a result, everyone suffers: those who waited for the agreements to be fulfilled on time, wonder what went wrong and why these performers fail their tasks over and over again, while those on the other side burn out and either give up trying, or put more and more effort into it. where, in their opinion, they are most needed (but, unfortunately, not where they are expected to go).


Yes, all problems most often arise from a lack of communication. But the fact is that not everything can be said every time; sometimes people rely on the so-called implied domain: what by default should already be accepted by both sides. For example, a supervisor thinks that the following is obvious: if he has assigned a special priority to a task, it should be put first and the contractor should promptly report any problems. The employee has a different idea: for example, in no case should you make it clear to the top that something is going wrong.


Despite my position, I often find myself inside the same routine and operating system – when you and your team are trying, but up there they don't understand why it's so slow or why it's so bad. But due to the specifics of the job, it is often possible to look at the situation from the outside and understand where you are wrong. Sometimes it turns out to see these moments of our own failure and broadcast it to the team, bringing it back to reality: we really screwed up and that's why we are misunderstood. Let's take a closer look at such misconceptions.


Common mistakes


The problems of performers can be divided into two main vectors: when they overdid it and when they underestimated it. Often, a conflict develops when the behavior was built on two of them at once.


For example, a performer has a big and difficult task. Yes, he had just been told that this task had the highest priority. At the same time, there are three more tasks in his backlog for this sprint, but simpler and with a lower priority. How does the problem start? The performer starts with a big task and realizes that he is at a dead end. For some reason, he is ashamed to say this, but responsibility does not allow him to sit idly by. What does the supervisor think this performer should do by default? Of course, escalate the problem higher and signal that he needs help. But the performer is afraid to let down the management, he worries about his position in the company... and so he takes on three other tasks in order to get at least some result. As a result, the performer is calm inside himself: although he did not complete the first task, he is still competent and was able to complete as many as three others in such a short time! And he doesn't understand why people are unhappy with him. Yes, the task was important and he was told about it, but aren't they all important?


Another problem may arise when the performer really focuses on the main task, but to solve it he needs to cope with a dozen side tasks: for example, request the necessary access or debug one place in the code that cannot pass unit tests. Yes, he usually spent less time on such tasks, but now something went wrong. It can be anything, and it's not always a problem with the competence of a particular performer – perhaps the task was not properly structured or its real scope was not taken into account when setting it. It may also be that the performance of this particular task clings to several previous ones, and if they were poorly done, then you will have to spend time refactoring everything there, and only then return to reality. What happens when you turn it in? The manager will hear that "the task is not ready again," and for him it is absolutely not transparent and not completely clear – they promised to complete the task, everyone agreed on the deadlines, but at best I will present him with half, and even that is not working. And a lot of time was spent, and for what? Not even for other tasks. At the same time, the performers are exhausted, overloaded, and over and over again they discuss among themselves and cannot understand why they are not understood. Why can't they see their load? And they continue to demand more and more from them, not seeing how hard it is for them.


Well, the third type of conflict is when the position of "do well" begins to argue with the position of "just do it." Let's assume that both previous mistakes were made: at first, less important tasks were done instead of the main task, and when the big task was started, it turned out that everything was not so simple, and instead of a week, it stretched over two months, with overwork. The head, for his part, changes the introductory ones: you do not need to have time to complete the task in its original scope and formulation, the deadlines will soon burn out completely, and you need to close the task somehow. The performer, who is used to rigid and detailed acceptance, is perplexed and sees some kind of trick in this: he thinks that if he does not do the task perfectly, it will not count, the new statement can be ignored and continue to do the old way. After all, he wants to do his job efficiently, even to the detriment of deadlines, because he considered it more important.: How can we ship something of insufficient quality? The conflict is growing. The management softens the requirements, but still does not get results. The performer is exhausted, but he can not deliver his work in any way. In the end, everyone is unhappy.


We facilitate and communicate


As can be understood from the examples, often a "bad" or "wrong" result, paradoxically, can be caused by a desire to do the best. And if you get into the operating system and look at tasks that way, then you can even agree with this.


But if you look a little higher, it becomes clear that this activity did not take into account the global goals and even the roadmap of the company: without a strategy, it is not clear why this task is important, and this one is not very important. Why can this part of the time checks be neglected, why would some task not need to be processed at all if you didn't do something "wrong"?


Increasingly, when we see such conflicts at the start, before they flare up to a fire, we try to convey the importance and exclusivity of the task as clearly as possible; at each stage we try to help those who are afraid or shy – and help to monitor the situation, to find out if help is needed and if there is a problem that we They didn't take it into account. Moreover, it is interesting that it is not necessarily the young and inexperienced who are afraid to talk about the problem – those whose results could previously be unconditionally relied upon and know that a person is reliable and consistent can behave in this way.


It works both ways – if you don't tell the management exactly why it was hard and difficult, they won't understand it. In our company, every employee, to a greater or lesser extent, still works with his hands, despite the position. This allows you to understand for yourself why the process works the way it does, and what went wrong with the subordinate – you yourself step on the same rake or see flaws in communication or task setting. This experience provides an opportunity to speak the same language and add a little practice to the strategy.


Conclusions


There are situations at work when we unknowingly set each other up for the best of intentions. The first step to avoiding this is to imagine ourselves in the other person's shoes and see what the real purpose of our tasks is. The second step is to make the interlocutor understand the subtleties of his work and motivation as transparently as possible.


If you talk about problems as soon as they arise, do not be afraid to report difficulties – over time you will be able to find a common language and become more productive without having to recycle and burn out.

Recommended

Incident investigation and use of specialised tools
Incident investigation and use of specialised tools
How Zeek and Malcolm help you not only passively analyse network traffic, but also respond to threats in a timely manner
How Zeek and Malcolm help you not only passively analyse network traffic, but also respond to threats in a timely manner
What is SSO
What is SSO
eBPF Through the eyes of a hacker. Part 2
eBPF Through the eyes of a hacker. Part 2
CyBok. Chapter 3. Laws and regulations. Part 2
CyBok. Chapter 3. Laws and regulations. Part 2
ARP spoofing (ARP spoofing, ARP poisoning): what it is
ARP spoofing (ARP spoofing, ARP poisoning): what it is
How regreSSHion opened a new chapter in old OpenSSH attacks
How regreSSHion opened a new chapter in old OpenSSH attacks
Configuration-as-Code
Configuration-as-Code
The process of finding, analysing and assessing vulnerabilities
The process of finding, analysing and assessing vulnerabilities
CyBOK. Chapter 2. Risk management and information security management. Part 2
CyBOK. Chapter 2. Risk management and information security management. Part 2
How Network scanning works
How Network scanning works
How hardening works and how it is integrated into information security processes
How hardening works and how it is integrated into information security processes

Recommended

Incident investigation and use of specialised tools
Incident investigation and use of specialised tools
How Zeek and Malcolm help you not only passively analyse network traffic, but also respond to threats in a timely manner
How Zeek and Malcolm help you not only passively analyse network traffic, but also respond to threats in a timely manner
What is SSO
What is SSO
eBPF Through the eyes of a hacker. Part 2
eBPF Through the eyes of a hacker. Part 2
CyBok. Chapter 3. Laws and regulations. Part 2
CyBok. Chapter 3. Laws and regulations. Part 2
ARP spoofing (ARP spoofing, ARP poisoning): what it is
ARP spoofing (ARP spoofing, ARP poisoning): what it is
How regreSSHion opened a new chapter in old OpenSSH attacks
How regreSSHion opened a new chapter in old OpenSSH attacks
Configuration-as-Code
Configuration-as-Code
The process of finding, analysing and assessing vulnerabilities
The process of finding, analysing and assessing vulnerabilities
CyBOK. Chapter 2. Risk management and information security management. Part 2
CyBOK. Chapter 2. Risk management and information security management. Part 2
How Network scanning works
How Network scanning works
How hardening works and how it is integrated into information security processes
How hardening works and how it is integrated into information security processes