Finding Nirvana: Preventing Threats vs Disrupting Business
As Benjamin Franklin once said, “An ounce of prevention is worth a pound of cure.” As Enterprises continue to build out and reinforce their IT security strategy, a keen eye is being put toward “preventative” solutions. With the rise in insider threats and compromised credentials, this is no surprise.
However, as security professionals dig in further, they can’t help but have concerns about the risk and possible inconvenience that prevention solutions can introduce. For example: how can a system actively enable security, without harming the organization’s continuous operations? Suppose that the system is highly confident that an activity is carried out illegitimately. The probability of error is low. However, what is the risk of blocking that action in the small chance of error?
At best? An employee becomes annoyed when they can’t perform a task which is part of his job.
At worst? The CEO can’t access their mailbox to write a crucial email at 4 AM, or an IT admin can’t run a crucial maintenance script because it traverses the entire network.
For security teams, achieving the two goals of enabling security (preventing threats) and keeping the business process from being disrupted is nirvana. The challenge is much lacking the security resources or tools to be able to achieve them both and finding the balance is tricky.
I believe in the importance of guarding the network actively, but there are more delicate approaches of doing it that can get organizations closer to nirvana.
One basic approach is using multi-factor authentication (MFA). When a system detects a suspicious event in the traffic, it does not have to decide to allow or block it. Instead, it can take the way of extra verification. It can require the user behind the triggering account to provide a second authentication, be it Duo or SMS. This way, in case the suspicious activity is, in fact, legitimate, it will not be blocked – as the user will validate himself using a second factor.
Now suppose the user is in the middle of a batch of unusual activities because he was required to perform an unusual task. In order to avoid prompting the user with MFA over and over again, a grace period will be granted. MFA not only mitigates the risk of blocking a legitimate action – it also allows to set the thresholds for triggering security policies lower, and take the safe road in borderline situations – because the price of error has gone down considerably.
However, despite its merits, MFA can still be disruptive and get in the way of a legitimate user’s regular workflows. Being professionals in the 21st century, we know that distractions could impact efficiency. Therefore, an organization could look at a looser method of verification.
Another option could be to use MFA to confirm the action separate from the workflow through a notification. In this scenario, suspicious activity is detected, yet the user is allowed to proceed.and an Incident is generated for the security team. At the same time, a notification will be sent to the user via an out-of-band channel (for the sake of the example, let’s say it is a mobile phone). This notification could present the users with the same options as the regular MFA – approve (“it was me”) or reject (“it wasn’t me”). However, the effect is post priori.
In this case, approval received within a set period of time could automatically resolve the Incident, without involving security personnel. A rejection would raise the Incident’s severity to critical. This allows the user to continue with their activity, even though it looked anomalous, without interruption and they confirm their action later at their leisure.
But what happens if the activity really came from a malicious source abusing stolen credentials?
Unfortunately, in this case, the attacker could have been let through. However, because there is still a trigger to the real user to confirm/reject the action (or alternatively, the warning’s time-to-live will pass) when the verification is rejected, the threat severity will be elevated to critical, prompting the security personnel to take immediate action. Furthermore, in this case, we can assume that blocking the account is safe, at least until the investigation is concluded. Doing so will prevent a verified threat from doing any further damage. Grievous as it sounds (and it does), research from studied breaches has found that attackers normally stay in the network for 256 days before leaving/being spotted. It is still likely that they could be caught before they did any real damage.
So, while MFA can have some perceived downsides from a productivity perspective, the flexibility of how it can be used may provide the stepping stone an organization needs to take on more preventive solutions and have more balance in enabling security vs disrupting the business process. And at the same time, it adds more bite to their threat detection strategy.
Posted by Roman Blachman on September 15, 2016 11:41 AM