The usefulness of IT systems in the work of an IS analyst

Eva Belyaeva, Security Vision

This is the second article in the series ‘Interaction of IT and IS’. The first article can be read here: https://www.securityvision.ru/blog/vzaimodeystvie-it-i-ib-sredstva-zashchity/

Why do IS people need IT systems?

It is not uncommon for an analyst to face the dreaded beast of enrichment and the search for additional information when dealing with incidents. Any clues, leads and minutiae can help both in advancing the investigation and in deciding on actions - to execute or not, whether the outcome is worth the risk and so on.

What often happens is that IT and IS departments share similar tools in terms of IT systems. And sometimes not just similar, but the same. As a result, irreconcilable contradictions and unceasing disputes can arise, often ending up in a kind of cold war between departments.

Why you can't just share

There was a case in my work when a customer came in with a request for a large asset monitoring system. It took a very long time to discuss all the details, dashboards and integration settings with representatives of the IS department - when, how and for whom it would be updated, what processes it would be built into, and so on. In the end, a huge analytical work was done, which satisfied our team up to one interesting moment: right behind the wall of the IS department there was ironically hanging on the wall a video panel with exactly the same system, almost identical TOR settings, only.... only it belonged to the IT department, and it was in no way allowed to go there and look at it.

Access restriction is usually introduced not on a whim and not out of bad mood: the tasks of departments can be really different, and the stumbling block according to the classics is data consistency - there is little chance that any department will decide to change the data model, add new contexts or get rid of the usual IT fields altogether.

After the first case, the following cases were no longer surprising - for example, another customer, choosing the same CMDB, warned us in advance that another request and another system would come from IT, because the data in the IT department need to be reference, without unnecessary links and involvement in incidents, and the process of asset management is not only loosely connected with the process of incident management - these processes go in parallel, not overlapping in working life.

The same can be said about the monitoring of both defence equipment and infrastructure - it is often the domain of IT alone, except for the very vivid cases of monitoring of machines by the SOC team itself.

But the biggest part of the debate has been and will be in the area of competences and rights for proactive actions during incident response. There are the familiar four ways and their combinations:

- the automation system itself manages the protection systems and workstations;

- only the analyst and IS employee can perform actions on endpoint devices;

- the analyst decides on the action, but the IT department handles the execution through the request system;

- the analyst is authorised only to create requests, only IT takes and executes the action.

Of which the second two are the most common in practice. It turns out that in general, the powers are divided in such a way that sometimes someone can peek at something and that's the end of it? Not quite.

In spite of contradictions

In fact, in the real situation, things are not so polarised. When teams start to really work with each other and think about how processes can be improved rather than slowed down, positive metamorphoses can happen.

From virtualisation systems, which can be protected by IS in exchange for the ability to administer these very systems in order to obtain the necessary statistics and develop recommendations - for example, for the company's web server. And ending with separate admin rights, albeit read-only, for an automation system or an IS analyst in the process of obtaining host casts, saving data on their states and performance.

After all, convenient and secure storage and database protection solutions could not be implemented at the same level if the IS department knew nothing about the infrastructure.

Finally, when it comes to CII, there is no way to do without sharing asset management and common context.

Sharing information about processes is more beneficial than detrimental, and the value of this assistance is far greater than the perceived problems.