MID Server in DMZ - What could an attacker do with the MID Server (java service) if they were able to compromise it?

[cynlink1]

I recently proposed adding a MID server to our DMZ to discover a server we want to include in an application (service) map. My security team had multiple questions, but I was hoping to get feedback from the community on the following:

• What could an attacker do with the MID Server (java service) if they were able to compromise it?
• What are ServiceNow's recommendations related to MID servers to mitigate the risk(s)?

Thanks in advance,

-Cyn

[Allen Andreas]

Hi,

In this edge case scenario where you're interested in just one configuration item, you'd want to truly evaluate the need for a MID Server in the first place as well as the need for that CI in your system that's in the cloud outside of your DMZ.

You may want to manually create this entry or use a small export of data to help build it, instead.

Just throwing that out there. Obviously, having regular updates and all that is nice, but they have it behind the line, so to speak, for a reason and now you're proposing to expose some of that information.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[cynlink1]

Allen,

We are just getting started on our Service Mapping journey. This is the first CI that we have encountered while service mapping that is located in the DMZ. I suspect there will be additional business cases. However, I agree that manually creating the CI is the most secure option, and we will likely opt for the manual entry. However, I wanted to be able to answer the Security team's questions either way.

Thanks,

-Cyn

[Hitoshi Ozawa]

Placing a MID Server is DMZ isn't a good idea if using Discovery. Discovery communicates with network and servers to gather data. This requires allowing opening up ports between MID Servers and all the servers that are to be discovered to be opened up between MID Server and the servers. If DZM is compromised, this will imply outside users will be able to get access to the internal servers.

The recommendation is to place MID Servers in the internal network and to restrict ip address/ports between MID servers and ServiceNow to only allow required packets to go through.

Manually entering and updating CI is not a good option. We've tried it and it's just taking too much time and effort to enter and keep these CI updated. Without the updates, CI becomes meaningless and we just end up using spreadsheets instead of using ServiceNow. It's just amazing how much information Discovery is able to collect.

It's just not about collecting data but knowing where to save them. Discovery will save the collected information in CMDB database tables. When manually entering them, it's necessary to know which tables to save the data.

Furthermore, Discovery is not just about saving CI but their relationships with each other. These relationship is what makes CI useful. For example, there is a relationship between server as a hardware and applications and processes that are running on these servers. Without these relationships, it would be difficult to know what is running on a server or to know which server an application is running on.

For example, following video shows how to detect which servers may have log4j vulnerability. If the CIs and their relationships are updated to the current status, it would be difficult to detect such vulnerability quickly.

https://www.youtube.com/watch?v=kmaPzGW79EI

Lastly, I do have to admit Discovery is kind of expensive.

[doug_schulze]

Midservers communicate outbound only to your instance and dont require inbound connections so it would act as near any other server in your environment. So if they were to compromise the host somehow then your entire DMZ would already be compromised.

One important thing I always suggest that if you were to move forward with this is to dedicate your DMZ credentials to only the DMZ midserver and no more. This way that mid only has the 'keys' to the environment itself and not your internal lan.

Also look into the options you have with the Agent Client Collector. As Allen mentions if you are only looking to gather one host a manual creation would be much less of a headache, so I'm a +1 on that.

Finally if you want some good in-depth info, talk to your account team and they can put you in touch with Field Security that can give your teams some great information to help gain more confidence in the mid and the technology/encryption methods we use.