It can take a bit of luck sometimes to find out about a security problem. A recent incident illustrates this and the need to do more to eliminate luck from the matter.
At issue: There's no reliable way to know when someone is doing excessive downloading of intellectual property.
Action plan: Find a cost-effective alternative to the leading event management tool.
I've talked before about how protective my company must be of its intellectual property, including service manuals for the equipment we sell, which can cost millions of dollars. We have a homegrown Web app that lets our field service engineers find and download service documentation, and last week the manager who administers that app asked me to stop by his office. The app creates a log entry whenever a service engineer clicks on a document for download. Normally, an engineer might download one or two documents a week. But while troubleshooting a user issue, the manager noticed that one IP address had logged an excessive number of downloads.
He determined that the IP address was in use by an engineer who had just resigned with the intention of going to work for a competitor. Needless to say, it all looked quite suspicious.
I immediately informed the HR department, and then I told the engineer's manager that I would want a forensic image of the employee's laptop. I wanted to know what he did with the 400 documents he downloaded. Unfortunately, the results were inconclusive. We couldn't be sure that he had copied the documents to external media or forwarded them to an outside e-mail account. If he had done either of those things from his laptop at home, we would have no way of finding out; our data leak protection tool catches such activity only when it occurs on our network.
True, the documents did reside on his company PC, but that is not a crime or grounds for termination. Nonetheless, we read him the riot act, telling him that if we found out that he had taken intellectual property, we would pursue both criminal and civil charges, and his eight-year employment record would be marked "not eligible for rehire." But with no noncompete clause in his contract, we could do no more.
SIEMs Like Old Times
This was all unsatisfactory except as a lesson for the future. It got me thinking about all the other data repositories that we have spun up to provide easy access to critical information, and about data correlation and security information event management (SIEM). Many years ago, my predecessor had bought a SIEM product, but that initiative was doomed by the complexity in our environment and by a lack of sufficient human resources. In another job, I had seen what successful SIEM deployment looks like; we used ArcSight, which I consider the Cadillac of SIEM. But I know that success requires a lot of money and people, both of which I am critically short on these days.
But if ArcSight is out of reach, I still feel I can get a limited amount of functionality, which may be enough to detect suspicious download behavior. I want to be able to show success in small increments and then use those successes to justify a more robust SIEM environment. I'll begin researching some of the smaller log management companies to see whether they can provide functionality such as analysis of Web, FTP and other application logs associated with our most sensitive data repositories. I want to be alerted when excessive downloading at a single IP address takes place. I want the tool to tell me the username or machine name with that IP address.
I'm not asking for much, just an automated approach to some basic log management and data correlation functionality. I know I can't be the first person to look for such tools and would encourage you to share your experiences in this area.
And who knows, perhaps this time next year, ArcSight will be within reach.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.