Tag Archives: malware

Lost in Escalation, What I learnt from Target Data Breach

Amidst the news of Target’s CEO stepping down due to the breach last year,  you might have also read about this: Missed Alarms & 40 Million Credit card numbers stolen. It appears from the news report that their infosec team in Bangalore had notified about malicious traffic in the network to their counterparts in US but unfortunately no action was taken. This is disturbing! If a InfoSec team notices a malicious behavior, why aren’t they not authorized to act upon? Even as they escalated the matters, looks like no action or follow up were made to neutralize the threat.  Acting upon the received alert could have prevent the breach and also save millions of dollars for the company and ofcourse a lost job for the CEO! It is also reported that the active feature in the tool which would have blocked the malicious traffic was turned off and only notification was enabled! Perhaps it was not tuned properly. This is a good lesson to all those investing in Security Tools and applications but not configuring them properly.

This incident reminded me of my own experiences. At my previous company working in a Global IT Risk Management team, we had the freedom and responsibility to take off any system in the network that showed malicious behavior. There were no exceptions to it, even if it were a CEO’s system or a critical server and if they posed a threat to our networks, off they were going. This was not an easy task as Security intelligence from multiple sources were to be collated and correlated.  These included reports from Network IDS, Firewall logs, AV threat summary, Compliance checks and etc and then finding the owner of a system among tens of thousands of systems needed a herculean effort. Many a time, if we made the contact with the owner, we would give him time just enough to take it offline, repair/clean/reformat and then we would validate it before putting it back on the network.

But before doing that we had to ensure it was not a false positive, quantify the threat and then instruct the network team to pull the plug in case there were no identifiable owner. We made those final call of pushing a system off the net and there was no escalation involved.

Ofcourse,  knowing  when to press the dreaded kill-switch is something that we got to learn with time, experience and mentoring. Innumerable concalls, followups, understanding network architecture spread over different geographies, different work culture are all part of the job, but worthwhile.

So if you are responsible for data security at your organisation, ensure your team has the skills and freedom to act upon the information and not just wait for the people on the top to give a go ahead.