Cybersecurity: peace of mind with the POST SOC

Using a Security Operations Centre (SOC) allows organisations to constantly monitor activity on their IT systems so as to take quick and effective action in the event of an attack or anomaly. This article explores what it’s like to be a POST SOC beneficiary so you can see the advantages for yourself.

A Security Operations Centre (SOC) is a valuable tool in ensuring the security of an organisation and its IT systems in particular. The basic principle behind a SOC is to identify anomalies or even attacks by analysing various logs (i.e. actions taken via IT systems). These logs track all activity taking place on servers, databases, applications, firewalls and many other devices. This information is fed into the SOC, which conducts 24/7 surveillance. Analysing logs using set rules means that alerts can be triggered and procedures launched, ensuring a rapid response if an issue arises. This offers peace of mind for the SOC customer, since there’s always somebody keeping watch over their most precious digital assets.

A bespoke rollout process

Conducting optimal surveillance of IT systems, however, requires understanding the organisation’s context, activities, geolocation, suppliers, needs and risks ahead of time. POST SOC operators will therefore learn everything they can about the customer’s activities, especially with a view to establishing what constitutes normal activity on the IT systems.

It is also important to determine the scope of the SOC’s surveillance to identify the logs available and the best logs to process for ensuring high-quality surveillance. A SOC is able to monitor firewalls, servers, laptops, databases, anti-virus systems, IDS, IPS, VPN and more. In other words, it can monitor any equipment capable of sending logs by IP. The customer’s scope and budget will determine the number of datasets to monitor and the volume of logs to analyse.

Establishing surveillance rules

Once these steps are complete, the most important thing to do is establish surveillance rules. For example, there could be a rule that triggers an alert if a log meets one or more specific conditions.

POST’s SOC proposes a set of generic rules that apply by default to its customers’ technologies and allow for monitoring of risks common to all players. Other rules must be set up to reflect the company’s circumstances.

Setting up alerts and conducting investigations as quickly as possible

A distinction can be drawn between the various types of rule.

All rules trigger alerts, but only some will lead to a ticket being generated and a real-time investigation.

Other rules mainly ensure that reporting is in place to meet any internal or external audit requests. A correlation strategy specific to POST’s SOC can be used to monitor all alerts, even where there is no real-time investigation.

When an alert requiring real-time investigation is triggered, the level one team will be able to:

• Conduct initial investigations;
• Categorise the alert as a false positive and close the incident ticket;
• Contact the teams responsible for managing the IT systems for additional context or a justification;
• Contact the customer and provide them with all the necessary information;
• Mobilise the level two team within the SOC when a more in-depth investigation is required.

Having useful indicators for security management

Other rules, for instances not requiring real-time investigation, are used to compile reports and dashboards to monitor activity after the fact or with a view to an audit. This data helps users gain a better understanding of activity on the system in order to, for example, adjust the rules in place.

Testing and adjusting rules in real time

Before it goes live, each rule must be tested to ensure that the results are as expected. Rules must be fine-tuned through ongoing adjustments, especially to limit false positives, such as alerts being triggered when they’re not needed.

Working with the customer to ensure constant improvements

In addition to conducting operational supervision, the SOC team will schedule regular meetings with the customer to take stock of the situation, plan for the monitoring of new vulnerabilities and review alerts to determine any adjustments that need to be made. These meetings, which may take place every week during the SOC implementation phase at the start of the relationship and then be spaced out at intervals of at least a month once everything is in place, are an opportunity to discuss new needs, ongoing changes for the customer, any new indicators that are required, and changes to the reports or dashboard. The aim is to avoid the solution seeming like a ‘black box’, and these regular meetings offer a chance to discuss all past events with the customer.

Keeping the lines of communication open is a way for the POST SOC to strive for constant improvements, ensure optimal security for the customer and go above and beyond in terms of service quality.