authentication

All posts tagged authentication

Strictly Theoretical – Multiple Country Ingress Authentications

Posted by d3nni5 on 10/05/2021
Posted in: Blue. Tagged: , , .

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.

Some pros and cons of cloud security

Cloud security companies offer a great range of cyber security solutions. One of the core products of these enterprises is access control through their numerous web gateways. This is great in general as loads of potential attack vectors can be blocked in this way, but what if other security related systems are in place as well. If these screening tools are not fully aligned or are in the baselining phase, they may work against each other increasing the level of noise.

User authenticates from different geolocations

If a user’s location is close to a number of gateways of the applied cloud security tool, a case might occur when the tool would try to authenticate the user via different gateways in a short period of time. There might be several reason for this like load balancing, the user’s personal VPN or other routing issues. In a situation like this screening tools would start clamouring as the timeframe is just too narrow for a real life journey for the user to travel between these geographical locations hence, this is suspicious.

After the confirmation of the circumstances with even potentially with the user as well, there is nothing else to do is just noting up the alert and potentially fine-tuning the workflow automation for such an alerts. The most important data to identify in these alerts is the “organization”. If it is matches with the name of the cloud security tool hopefully there is not much to worry about.

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

Strictly Theoretical – Tor Exit Node

Posted by d3nni5 on 09/05/2021
Posted in: Blue. Tagged: , , .

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.