How we implemented the second SIEM in the cyber attack monitoring and response center

One head is good, but two are not beautiful ... So we thought while living in a wonderful time, when there was only one SIEM platform in our center for monitoring and responding to cyber attacks. It's no secret that this was HP ArcSight, which turned out to be the only finisher of a long marathon through thorns of demands, wishes and ambitious plans to build the heart of SOC.



And nothing seemed to bode well, but at some point, thoughts about the need to work with an alternative platform appeared and became more and more insistent. And the main locomotive here was the active development of GosSOPKA centers. In order to become one of these centers, we had to use the software that is provided"Guarantee and technical support by Russian organizations that are not under the direct or indirect control of foreign individuals and (or) legal entities" (Order of the FSB dated 06.05.2019 No. 196, clause 3.4). How we suffered all this went through and what happened in the end, we tell below.





Shot from the animated series "Catdog"



We have heard that there are SOCs who profess polygamy, multi-vendor and say (and this type of activity, as we remember, is very different from bag unloading) that they are ready to work with any SIEM solution widespread on the market. Why it is impossible to implement such an approach qualitatively, you will understand from the description below. We became so attached to ArcSight and managed to build a whole ecosystem of solutions and processes around it that embedding an alien SIEM into it became a real challenge and posed a number of difficult questions for us:

1. Which solution to choose?
2. How to integrate the new SIEM system into TIER1 operation?
3. How can all the many internal integrations that ArcSight currently have to be transferred to the new platform?
4. How to synchronize the SIEM content development ideology and provide symmetric sets of detection rules?

Choosing a solution was not an easy task. Everywhere we had to dive into a whirlpool, the depth of which we had nothing to estimate. As a result, we decided to make a choice in a different way - to use SIEM from the vendor, who promised us a high priority of improvements according to our requirements and in whose promises we believed. Thus, a technological partnership with Positive Technologies was born and MaxPatrol SIEM appeared in the funnel of our SIEMs.

Ok, we have a new platform. But who will work with her?

To be honest, at first we had a feeling that we could not do without a second team working in parallel with the new toolkit. This feeling was reinforced by the fact that even the senior analyst lines who participated in testing the second SIEM found it difficult to accept. Therefore, at first, the concept was drawn as follows: two TIER1 lines, each sharpened with its own instrument, and the multi-platform TIER2. With the multiplatform readiness factor as a growth factor for a specialist from T1 to T2.



It was around this time that we accumulated enough reasons to split our 1st lane into TIER1 and TIER2 (more on this in another series of articles). And since in the initial concept T2 should work with both platforms, we turned all MP SIEM incidents into the 2nd lane, formed from the most experienced 1st fighters who were immersed in the new SIEM. Looking ahead, I will say that the engineers of the 2nd line perceived the MP SIEM more positively than their senior colleagues-analysts - this gave us hope that the platform could be landed fully and on the 1st line, and not fence several specialized ones.



The issue of integration into a single ecosystem was also not as painful as we expected - perhaps it was helped by the fact that flexibility and configuration redundancy were initially included in the developed integration mechanisms. There were no particularly great victories that I would like to boast about. We quickly incorporated the new system into the ecosystem and investigation processes, and now the processing of incidents from various SIEMs differs for the guys only in the interface of the SIEM itself. All routing and prioritization mechanisms, all enriching decision-making information, all notification templates are identical and are in the same familiar places.

What about content?

You can't go far with an “empty” SIEM without content (rules for correlating information security events and identifying incidents) and you won't reveal many threats (we don't use boxed content), so the task of promptly developing correlation rules on a new platform for existing JSOC scenarios arose. At first, we decided to get by with a little blood and transfer the rules from ArcSight with copying the implementation logic, but this turned out to be a mistake on which we seriously burned ourselves: a completely different product architecture required "its own" approach to development. I had to form this approach, and at an accelerated pace. Close interaction with the vendor helped a lot, who advised on emerging issues, took into the implementation of our requests to refine existing and create new chips in the functionality.The flip side of the coin is that we regularly had to rewrite the content for it to work correctly on this newest functionality. But, as they say, change or die, so we didn't complain (well, except perhaps inside the team over a glass of tea).



At the initial stage, only experienced 4th line analysts, who ate the dog while working with ArcSight, were engaged in the development of content for the new SIEM. Curiously, some guys had already undergone a professional deformation by that time and had formed a "dependence" on a specific SIEM with its high level of maturity. Switching to a new platform was difficult for them both psychologically and technically. Later, the development team was significantly expanded with new members, incl. guys from the 3rd line, and just for them this topic took off much easier and often even more productive.



Despite the cross-cutting list of scenarios for both SIEMs, their implementation can seriously differ, mainly due to limitations in the architecture and functionality of different platforms. For example, in ArcSight, in the correlation rule, it is impossible to specify a check for the existence of a record in the active sheet by non-strict match, but in MP SIEM, it is possible. On the other hand, MP SIEM does not generate internal events for adding or removing a record from the table list, and ArcSight can do this, and in a number of scenarios this feature is used. I had to live with a split personality to introduce "dual-line" in our knowledge base on JSOC scripts and describe the nuances of the implementation, as well as their own investigation tools for each platform.



At the same time, it was very important to convey to the 1st line that the logic of incident investigation does not depend on which SIEM they are generated on, and that the new SIEM is a new tool for solving all the same tasks. It has its own characteristics that must be studied, but nothing radically changes.

And the work on the 1st line began to boil

TIER1's immersion in working with MP SIEM proceeded gradually and according to the process, debugged with the introduction of new employees. The criteria for incidents were determined, which are not very scary to give into the analysis of the 1st line, which does not yet have much experience with MP SIEM:

• low critical incident details (uncategorized hosts / networks and accounts);
• long SLA timings;
• low labor intensity of the incident (we have accumulated statistics while processing incidents at TIER2);
• not very furious correlation rules (yes, you need to look there for the first line).

The scenarios in accordance with these criteria were divided into several stages and were handed over to TIER1 engineers one by one - after passing the "credits" and gaining access to the solution of the pool of incidents.



As a result, we have in our portfolio of tools two SIEMs, on which scenarios that are absolutely identical in essence and processing logic are launched.



Alexey Krivonogov, Deputy Director of Solar JSOC for Regional Network Development