It’s an unpopular topic for sure – letting people go from your organization. Firing, downsizing, “rightsizing”, whatever you want to call it, it’s an unpleasant experience for everyone involved. For security folks, however, there’s a lot we need to be aware of prior to, and during, layoffs in our organization; when people lose their jobs, or suspect that they soon will, they can do some not-so-ethical things. People may steal sensitive data, sabotage people, projects, and assets, or log back in with their old credentials to just “snoop around”. Whatever the case may be, here’s a list of things we need to do and think about from a security perspective:
- Monitor logs: We should already be doing this as a security best practice (or perhaps because we want that coveted compliance checkbox). However, within the realm of log monitoring, we can shift our focus to events of a particular nature for short periods of time, and this is the case during layoffs. For example, you may want to start logging successful logon events to critical or sensitive resources (many don’t due to the volume of alerts). This can help you observe the patterns of access to the data – are people accessing the data more than normal? Are their access times a little peculiar?
- Watch the back door: Keep an eye on VPN and other remote access methods. Much like log monitoring, you’re probably doing this already – however, you can shift more of your attention to watching events on these devices and monitor users coming into the network this way to see if they’re doing anything a bit out-of-the-ordinary.
- Monitor physical access: Get the physical access logs of the buildings where soon-to-be-unemployed people work. Again, you’re just paying a little closer attention to patterns of behavior than normal. People coming in on weekends or after normal hours, staying late, etc.
- Institute strict change monitoring of code and files: The recent case of the Fannie May contractor who implanted a logic bomb in a program should give us all pause. Although full-blown sabotage is fairly rare, it definitely happens. Any folks with access to code should get extra attention, and so should their code. In fact, I want a daily list of changes in their code, and you should seriously consider implementing a two- or three-tiered QA and analysis program for a short time to ensure no malicious code is inserted. Is this tedious? Hell yes. Could it save your ass? Same answer.
- Revocation of access to resources: This is the classic problem with people let go from organizations. We need to disable or terminate their accounts and access to resources, and we’re often left to absolutely archaic methods to keep up with what they had access to in the first place. Things like spreadsheets. Emaiil distro lists. Real CUTTING EDGE technology like that. Or even worse, our own flawed memories. If you have a user provisioning or IAM system in place, this gets a lot easier.
- Reclaiming corporate computing assets: Getting laptops, PDAs, 2-factor tokens, and the like back in the organization’s possession is also something security should be involved in.
- Forensics: Depending on the circumstances, you may need/want to perform a drive duplication and/or forensic analysis of aforementioned computing assets. Usually, this is the case when someone is terminated for cause, and the company’s CYA instincts kick in for self-preservation in a court case or prosecution.
I’m probably missing a few considerations, and any comments are welcome. One thing to note here – some of these items implies that security teams have prior knowledge of the layoffs or terminations. In WAY too many organizations, HR teams don’t share this info and work side-by-side with security to do this effectively. If you’re in one of these organizations, you should lobby HARD to change this behavior. After all, our job is to identify, manage, and monitor ongoing risk. The risk-o-meter goes way up during layoffs and terminations, and given that we can do so much to prevent mishaps, we really should.