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.

What makes  a SIEM solution good

In one sentence, an effective SIEM is dynamic and scalable. An ever-changing environment and exposure require coherent baselining. In this entry- and in all this kind- I will go through how different models of code and network activity materialize on Security Information and Event Management systems.

TOR

The initial goal of The Onion Router (TOR) is to allow free, anonymous online communication. There’s nothing wrong with that. The problem arises when such user activity is reflected in the systems that monitor it and might even overload the SIEM collectors.

In a production environment, this type of user behaviour can be very disruptive and unnecessarily increases organizational traffic and activity noise. Even from the user’s point of view- if he/she is not a malicious actor- there is absolutely no point of it as thanks to the ingress authentication there is no anonimity whatsoever.

The procedure

The engineer who analyses the alert must be 100% sure that it comes from a legit person, who works for the company. He/she has to review the user’s authentication history for the past few weeks to identify any other suspicious activity. It is also critical to communicate with the user preferably via an independent channel (e.g. messaging apps) to verify if the TOR Project is knowingly used when accessing organizational resources. The account must be locked if required (force logout) and the user must be instructed to change his/her password. This is the default protocol under such circumstances. In addition, as much information as possible should be collected on the incident to update the incident inventory, if applicable.

If the system does not require two-factor authentication, consider adding it to prevent brute-force and simple phishing attacks.

When all done, the ticket can be closed. Also, consider implementing as much automation as possible to relieve employee burden.

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