Discovery Security Concerns
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2017 09:03 AM
Hi All,
Some of my business units are concerned that allowing authenticated discovery will create a massive vulnerability in the following scenario:
- A malicious user gains access to our instance with an administrative or other powerful role
- A custom probe is created containing dangerous code that can be executed on one or more hosts. It could delete everything on a file system, or steal data, or anything you can imagine doing with malicious code.
- The discovery is kicked off by this user and the code executes, causing mayhem and world war three.
My answer to this risk includes mitigating controls:
- Access to our SN instance requires MFA, reducing the likelihood of an outside attack.
- Administrative roles able to create and execute discovery are limited, and actions are logged.
- Accounts used for discovery should be limited in what they are able to do. Sudo is required to return many useful results, but accounts can be limited to running specific commands.
I'm sure we can lock it down further by only providing the service account during discovery, and removing it or changing the password each time, but this will add overhead to the process.
My questions:
- Is the scenario above realistic?
- Are there other approaches to mitigate this risk not mentioned?
- Is there a comprehensive guide to creating hardened service accounts for discovery that we can reference?
Thanks!
Kurt
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2017 10:24 AM
Hi Kurt,
All the points that you mention are valid.
Is the scenario realistic? Indeed it is. I haven't heard yet of an event where the risk has become a problem perhaps primarily because of how the risk is mitigated. On all honesty, very few should have access to admin accounts and it's traceable who is doing what.
Are there other approaches to mitigate this risk? Perhaps...
a) lock your instance so that it's only accessible from a whitelist of IPs (ranges).
b) don't discover areas/devices that hold extremely sensitive information
c) hold indicators / audits within your instance that shows activity around discovery and changes to its behaviors
d) get professional assistance (hopefully third party)
Thanks,
Berny
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2017 10:25 AM
This is a great question and in general a great topic!
Feel free to contact me at balvarado@volteo.com if you will like to talk more about it.
Thanks,
Berny
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2017 10:34 AM
All the previous suggestions are great.
I would add:
1. Use External Credential Storage (ECS) https://docs.servicenow.com/bundle/istanbul-it-operations-management/page/product/discovery/concept/...
2. See if your ECS solution can change the password after usage
3. Use complex, long passwords
4. Discovery performed via RFC (maybe routine change)/allowed window. Monitor/alert for interactions outside of that time-frame
5. Limit who has access to ECC queue/Discovery setup/MID server
6. Only allow CI sign on with the ID from your MID server only
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2017 12:01 PM
7 - For ssh credentials, use private key credentials rather than password.