2

We intend to use McAfee ESM Nitro (SIEM) for security monitoring of our infrastructure servers. To bring automation in system administration of our servers, we have developed some applications in-house.

For instance, we are using a 3rd party tool for automated system automation which is Ansible and we have an in-house application that controls which of our server remains in production or whom to send out of production.

We now intend to integrate McAfee ESM Nitro with these two applications. So that whenever any threat alert is generated through Nitro, it should use Ansible or our in-house built application to run the remediation steps or locking out the system from our production environment.

The Nitro provides two options for such actions to be triggered against any alert. Either to remotely connecting to a server using SSH and run any script residing over that server or running the script through any URL over HTTPS. Please find the snapshot attached for both the options.

I have read the thread over this website where the comparison between SSH and HTTPs is discussed (What is the difference between SSL vs SSH? Which is more secure?)

I would request for your professional advice as to which option to adapt for and which is more secure.

Thanks, Fahad.SIEM background URL option

SIEM SSH option

Community
  • 1
user29752
  • 21
  • 1

2 Answers2

1

It depends a lot of how your infrastructure looks like and how much time and money you want to invest (or already have invested) in your security infrastructure.

On one hand, SSH is easy to deploy, require authentication by default (so less room for error) and can be made quite secure very easily. The downside is that the security aspect doesn't scale too well: key management in larger environment is complicated and the default fall-back (accept any key from server) is insecure. Client key management is also an issue.

On the other hand, you need a more effort to deploy HTTPS securely and have the same level of security that what you'd obtain from SSH (Assuming you're using key-based authentication). The advantage is that it's easier to scale: you can use a private PKI for managing keys easily and, once you have a working configuration, it is very, very easy to securely replicate it across as many systems as you want.

Stephane
  • 18,557
  • 3
  • 61
  • 70
1

I would personally go with HTTPS (TLS) for the following reasons:

  1. An alert/message based system is much more suitable for a protocol such as HTTP.
  2. You can set up a certificate authority (PKI) to handle authentication as a required feature of TLS.
  3. You can use self-signed certificates for security equivalent to SSH, which can be later upgraded to a legitimate PKI system.
  4. You can use a pre-existing, extremely powerful web-based technology, Node.js, to directly handle the incoming communications and perform any necessary internal operations. It can act as both a server and as a client via HTTPS.
  5. SSH connections usually end up giving more access to the target computer than is required in order to accomplish a task, because the applications that implement SSH are usually capable of performing a broad set of tasks. Creating a custom SSH server is not as easy as it is to create a custom HTTP server with the same restricted level of permissions available to the connecting application.
Jonathan Gray
  • 1,036
  • 7
  • 11