Discovery Security Concerns

kurtdean
Kilo Contributor

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

9 REPLIES 9

bernyalvarado
Mega Sage

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


bernyalvarado
Mega Sage

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


Jeff Boltz1
Mega Guru

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


7 - For ssh credentials, use private key credentials rather than password.