This is another short piece of the “Strictly Theoretical” mini series in which I put insensible historical incident management and suspicious behaviour patterns under the microscope reflecting on how the “inner” and “outer” world continuously interact with each other forming the everyday life of the production environment.

Third Party Alerts

Many times SIEM solution tools can integrate with third party vendors in order to generate alerts. This could be important if the organization is on a tighter budget, so with a more robust library of third-party integrations all the alerts from endpoints, networks and users can be channelled into a single platform, facilitating easier surveillance and analysis. The obvious drawback of this is having even more  un-prioritized alerts.

We can see that there was a moderately high number of login attempts.

This is why it’s important to keep fine-tuning new and existing rules to effectively draw attention to only the more relevant threat vectors.

What next

Well, there are usually two main groups of tasks after attacks like this. First, it is clear that immediate remediation by the third party is critical. It could mean the blocking of source IP-address for at least 24 hours, password changes, whitelist adjustements etc. However from the point of view of our SIEM the alert should also be treated as per our needs, prioritized, suppressed etc. to reduce the number of alerts or to make it more prosilient in the future.

Thanks for reading and as always, any feedback is most welcome.