Securing SCOM in a Privilege Tiered Access Model–Part 2
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.
Previously, I discussed basic security posture and what is needed to secure a SCOM installation. The post can be found here. In summary, we discussed risks associated with malicious management packs and the use of a service account for agent action instead of the local system. This discussion will focus a bit deeper on account management.
Carefully plan Run-As account distribution
In my opinion, poor run as account distribution practices poses the greatest risk to your environment, as a poorly distributed account could potentially give an attacker the keys to your environment. The first thing worth noting about run as accounts is that they need to be able to logon locally. This effectively means that the account’s credentials are sitting in memory on any server that it was distributed to. I demonstrated this particular risk in this piece, and I recommend reading it before planning a SCOM installation. Server 2016 has mitigated many risks associated with pass the hash, but older operating systems do not have the same mitigations in place, and as such, they are exposed. Keep in mind that it only takes one compromised server to compromise a tier. If you have a super account running on Server 2008, I can collect that hash and still use it to access a more secure 2016 system. The OS mitigations in place will prevent me from collecting additional hashes off that system, but once I’m on it, I can still do whatever I want with the system.
In the tiered structure, you don’t want Tier 0 accounts being used on Tier 1. In short, this means no Domain Admins logging on to anything that is not a domain controller. That’s simple enough. The AD MP doesn’t need a DA run as account anyways, so the only issue at hand is finding a method to patch/upgrade the agent on a domain controllers.
Tier 1, however is a bit more complicated. This is your server tier. Many organizations (and I’ve been guilty of this in the past as well) have a handful of super accounts that are local admins on every server in the environment. If any of those accounts are used as a run as account and distributed anywhere, this means that this account could potentially be harvested. All an attacker needs is local admin rights on one server that has this type of account running and your entire tier 1 environment is compromised. This is, as far as I’m concerned, just as bad as compromising tier 0. The attacker effectively has all of your data and access to any server in your environment. Even without domain admin rights, they will be able go about their business. In the tiered model, there should be very few of these types of accounts, and their use should be restricted from the management network (aka Red Forest). Other accounts in Tier 1 need to be restricted to only the machines that they need to run on.
As such, my general opinion is to stay as far away from using run as accounts as possible. For most of our management packs, this is not an issue. However, some MPs (SQL and SharePoint for instance), need them, and SharePoint does not even have an option for least privilege. The first thing I’d recommend is using NT Service SIDS in their place. I know this works for SQL, as Kevin Holman has a great article on how to do this (though I highly recommend using the least privilege configuration and not SA rights) . The Health Service SID effectively gives the local system’s health service the minimum permissions needed to monitor a SQL environment. The health service, given that it is not a user account, is not able to be mined by an attacker. I’m of the opinion that all management pack authoring needs to move in this type of direction, and if I were calling the shots, solutions such as Kevin’s solution for SQL would be integrated into every one of our MPs. Unfortunately, as of this writing, this is not the case.
Where run as accounts are required, an organization needs to put some intelligent controls in place.
- Ensure this account can only log on to the machines that SCOM distributes it to.
- NEVER use the less secure distribution option. I personally would argue that this feature should be removed from the product, as it makes it way too easy to expose yourself to massive amounts of risk.
- Ensure the run-as account is not a high value account.
- Strictly control the administration of SCOM as SCOM admins are the ones who can create and distribute them.
- Train SCOM admins so that they understand this vulnerability.
- Regularly audit run as account configuration and distribution.
Least privilege service accounts
This one speaks for itself, though I’ve seen plenty of organizations that assign way too many rights to a SCOM service account because it’s easy. You can find official requirements here, but as you can see, several of these accounts need local admin rights (note that’s admin rights on the management servers themselves, not everywhere… and most definitely NOT domain admins). I would further add that because of this, these accounts run in resident memory on the management servers. It would be wise to ensure they have no privileges elsewhere.
Some organizations will make the management server action account a server admin to facilitate agent deployment and upgrade. I would argue that this too is a bad practice. The account won’t sit in resident memory on agents (except when in use), but it does sit in resident memory on management servers, so by compromising a management server, you could potentially compromise this account as well, giving an attacker admin across the org. Restricting the Management Server Action Account does have a small pain point in that you need to manually enter account credentials for agent deployment and update if you’re using the SCOM console, but to me, that’s a worthwhile trade. To be fair, managing software deployment accounts is a challenge for all organizations, though again this is where a Red Forest/Privilege Access Workstations come into play as these accounts can be restricted via IPSEC to only run from specific locations. Personally, I’m prefer to outsource agent deployments and updates to SCCM anyways. It’s not hard to change the IsManuallyInstalled flag in the SQL DB, and it allows for an automated solution to deploying agents and patching.
Turn on Agent Proxy only as required
I’ll admit to not really knowing the risk here, but enabling agent proxy is off by default for security reasons. For the record, agent proxy is required for a lot of management packs, and turning it on effectively allows an agent to submit discovery records on behalf of other systems. My understanding is that there are no known exploits related to this, and if I were to speculate, an attacker could use it to spoof discovery data. As such, the risk to turning it on is fairly minimal. That said, it’s good practice to turn it on only as needed.
SCOM port considerations
Microsoft publishes SCOM’s port requirements here (see the “supported firewall scenarios” section). Note that this document is applicable for both SCOM 2016 and SCOM 2012 R2. I think most of what I have to say is common sense, so I won’t elaborate, but it’s definitely worth opening ports only as described in this document.
This concludes the potential security risks to consider when deploying SCOM. The next piece will cover how to architect an Operations Manager environment using Microsoft’s Tiered account structure.
Summary
- Securing Privilege Access (AD Security) paper.
- Carefully Manage RunAs Accounts
- Avoid less secure distribution
- Avoid using powerful accounts
- Use IPSec to restrict RunAs accounts to only systems that need them.
- Restrict privileges of SCOM accounts.
- Turn on Agent Proxy only as needed