Welcome back. In the following post, I'll continue to list another 5 events to monitor on the trail of stolen passwords...
You can see the first 5 in my post from the 10th, here: Top 10 Events to Monitor for Stolen Passwords, Part 1
The last 5 events fall into the following categories.
Unusual User Activity
Identify some key areas of segmentation you can take advantage of. Examples: sales people are in a common AD group and expected only to log on locally or via RDP to laptops in the laptops OU or group; developers are segmented to a certain part of the network and expected only to log on from those IPs or a corporate VPN.
- Successful or failed logon activity outside the norm by normal users. Eat the elephant one bite at a time, identifying any of those common patterns you can, and identifying logon or failure activity that falls outside of it. Sales person attempting to log on to developer workstation - even if they succeed? Developer not joined to the domain and attempting to log on to domain resources? Any of these patterns could be mistakes, but they are commonly at least policy violations, if not security issues. Start conservatively and confidently.
- Interactive logons (local or remote) to multiple machines simultaneously. You'll have to set up some thresholds here that make sense, like 3 different machines within 30 minutes of each other. If you're a computer lab, this won't work, but most businesses aren't using shared machines, or if they are, a situation like this would indicate either a technical issue or a security issue.
Privilege Use Gone Wild
There's mixed messages about abuse of privileged access to resources causing breaches – there are horror stories like the guy from San Francisco that made it impossible to access network devices after getting fired, and there are some breach reports that show insider threats to still be a significant issue – but it's common sense to know what your most trusted users are doing. After all, those most privileged users are also going to have the most access and be the highest value target. Think beyond just IT administrators here and identify other high visibility targets, too, like your CEO (probably has access to lots of data), financial officers (them too!), development operations staff (can make changes, may have access to databases and resources where passwords or critical data exists), and anyone with named access to visible resources.
- IT Administrators doing "maintenance" outside of normal business hours. Yes, they could just be doing their jobs during an outage, but this shouldn't be commonplace (if it is, you should implement others on this list first). If you've got multiple departments across the world, create different "normal" situations for each of them and look for the abnormal.
- Failed access to IT administrator accounts and computers. Set up thresholds that make sense here, you probably don't want to know every time I've forgotten my coffee, but you do want to know when it's probably not me, and if it continues after my account locks (if you've got lockout policies). Consider limiting this to interactive logons (local or remote) so you don't get a bunch of emails when someone changes their password and their mobile device starts failing to log in.
- Successful or failed access to network device administration. In most environments this would have a capital period at the end of it. Control where you access network devices from and watch for attempts outside of that norm. Logons to the router from a sales laptop? Nope.
Monitoring for these events will help your organization remain secure and not become the next victim of a security breach.