Several new Cloud-Email security vendors are coming out with no ability to block bad email before it reaches the inbox. Instead, they allow the email to be delivered and then if found malicious, in either seconds (as they claim) or minutes (as customers report), they pull the email out of the inbox.
There’s the obvious caveats—it's a bad user experience with flickering messages and obviously the chance the end-user would click that bad link or download that malicious attachment. How significant this is is a little hard to evaluate, and it has to do with how quickly end-users respond to a new email.
But there’s also a hidden problem, a problem that results from the most basic conditioning of us security professionals—when we see smoke, we must verify there is no fire.
In a post-delivery system, when the alert is sent to the SOC it does not tell the Security Professionals that everything is fine and the attack was evaded. On the contrary, it tells them that their end-user was exposed to an attack and they need to investigate whether the end-user fell victim to that attack.
In some cases, it’s actually the end-user that reports the issue to the SOC. In one of our customers that had us replace their CESS, an end-user received a phishing email from “IT”, and like most, got a new email notification to his phone. Although the email was quarantined, the notification was not (and cannot). Aside from the bad user experience, that end-user reached out to IT support and asked to send it again because he couldn’t find it. IT responded they did not send anything, assumed it was phishing and asked the end-user if he clicked the link. This was 24 hours after the email was delivered— the end-user could not remember what he did, and the IT, as good security professionals should, reset his password just in case. It’s a story of everyone doing their job and acting responsibly. Well, everyone but the email security solution that should have blocked it before the inbox and save everyone’s time.
In fact, in the Avanan UI, when our customer is in inline mode, we show all the events as remediated. Otherwise, those attacks show up as pending, because we expect the sysadmin to verify them.
Customer in non-inline mode: Events are pending
Customer in inline mode: All events remediated
So the hidden problem is simple: a list of findings from a non-inline system is your SOCs todo list, things to investigate to make sure have not compromised your environment. The list of findings in an inline system are the things you don’t need to worry about. All you need is the all-green “100% Remediated”.
In a time where we all sometimes feel like in an all-out cyber war, no one has too many resources to spare and Security Professionals should be able to spend their time on the things machines cannot do, not on things machines should have blocked.
