I'm always amazed by the various ways that security deficiencies find their way to the top of the ocean -- you know, that ocean we're all trying to boil.
Last week, one of the managers in our sales department discovered a security lapse by chance. He had terminated one of his sales associates and wanted to review that person's email for correspondence related to outstanding sales deals. We give such managers access to their reports' Exchange mail for just this sort of situation.
The manager was typing in the person's name, and it auto-filled before he could finish. So he clicked OK and started looking around. But hold on -- the inbox seemed to belong to one of our executives, not the terminated sales associate. Auto-fill had provided the name of the executive, and the sales manager hadn't noticed. That wasn't a problem -- but how was it that he had then been able to open the inbox?
Fortunately, the manager called the CIO to explain what had happened. Naturally, the CIO then called me.
I found out that the executive's email was configured to give any employee in the company access. Of course, we immediately dialed that back so that the executive's admin was the only person with access other than the executive herself. Then I called together my incident response team: one of my security analysts, the lead Exchange administrator, the manager of the help desk and a few other IT folks. We began investigating and brainstorming likely scenarios.
First, we checked logs to see who had configured access for that inbox and who had accessed it -- or we set out to do that, but there were no logs enabled for either the executive's desktop or the Exchange server. Seems we hadn't enabled these types of logs because they consume a lot of disk space and cause performance issues.
I then had my security analyst search our security incident and event management (SIEM) tool for any sign that the executive's PC had been afflicted by malware. I also had him ensure that no resident malware was running on it.
Next, I reviewed help desk tickets. Sure enough, a ticket had been opened about four months earlier to configure access to the executive's calendar. The technician who had completed the ticket assured me that he had delegated access only to the executive's admin.
I wondered whether other users' inboxes might be similarly exposed, so I had one of the Exchange administrators generate a report to tell us if any mailboxes were configured for global access. Sure enough, several more executives had improperly configured mailboxes, along with about 40 other employees.
Interestingly, the help desk tickets showed that the same technician who had been responsible for the original executive's Exchange configuration had also configured the delegated access for the other executives with wide-open inboxes. Logic suggested we had found the root of the problem.
The technician's manager and I decided to hold a training session for the help desk on the proper configuration of delegated access to Exchange inboxes. And who better to conduct this training, we figured, than the very help desk technician who seemed to have been doing things wrong. No finger-pointing, but this approach should ensure that the person most in need of the training really got the lesson.
We are also working to make logging possible on the Exchange server and to direct the logs to our SIEM tool. And we are investigating ways to keep people from enabling delegated access without first opening a help desk ticket. If that doesn't work, we'll have to ensure all employees are trained on the proper use of this configuration.
And now I have an additional audit to add to my list of regular activities.
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.
Join in the discussions about security!