Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
I wanted to take a few minutes and discuss current plans for upcoming changes in the security MP. I’d also like to use this space as an open forum for feature requests. While I’m not expecting tons of requests, it is worth noting that I do have a few criteria for any change I make.
- It needs to be something that should not generate a lot of noise when enabled. More than anything, that means I’ll need to have a unique way of identifying the issue in question. Several (not all) of my PtH rules are off by default for precisely that reason, they aren’t unique to PtH related events.
- For Operational Threats, I’d prefer to be tracking items that are currently in use or increasingly being used by the bad guys.
- Obviously, I need to stay within the limits of what the SCOM libraries can provide. Event log and registry key analysis are pretty easy. I’d note that anything that can be scripted in PowerShell should be relatively easy as well.
That said, feel free to drop a comment here for any ideas. You can also hit me up on linked in.
These are my current plans for updates:
- I want to rewrite the scheduled task rule to allow for overrides for specific applications. Unfortunately, this one is noisy as way too many commercial applications create their own scheduled tasks in task scheduler. This would allow users to override for specific applications in their environment.
- Similarly, I’d like to rewrite the service created on DC rule to do the same thing. In general, services should not be created on domain controllers fairly often, so this is worth monitoring for potential threats. However, it seems that some applications do occasionally create a service on a domain controller. This would allow a user to override for that specific service.
- I did find some false positives with local account creation, as those events can be generated on domain controllers. I didn’t see this in testing, but I did observe this at a customer recently. I’ve written in an override for the next release to turn this off on domain controllers.
- I would like to remove alerting for batch logons and put this in as a report. It’s worth noting that batch logons are very insecure, but this also is generating a lot of noise. The nice thing about a report is that you can see where these logons are occurring and update your applications accordingly…. at the very least, these machines could be segregated in your environment as to make it harder for an attacker to access the machine and steal credentials.
- I would like to write a collection rule/report for TLS 1.0 and 1.1 authentications. These too are insecure protocols and should be shut off in an organization. The idea behind this would be similar to the NTLM/LanMan/Wdigest/SMB1 reports. It should be able to tell a user where this authentication is happening in an environment so as to fix any applications that are using it and allow an organization to shut it off. I don’t know how easy this will be. My initial research (though to be fair I haven’t spent more than a few minutes looking into this) didn’t find an easy way to detect this. I’ll probably also need some beta-testers here as I doubt I have these protocols running in my lab.
Beyond that, I don’t have too much in the way of changes scheduled. I’d definitely like to hear more from the community as to what they would like to see. I think we’ve hit most of the low hanging fruit, which is good, but that also means it will take a lot more effort for additional features.