How do you plan for a security review for infrastructure monitoring software?

As with any software that is deployed within any organisation, security must be built-in from the ground up. When it comes to Infrastructure Monitoring Software, the problem has and additional dimension - that of the underlying protocols used in the core work of gethering data. These protocols are typically outside of the control of the software developer themselves. So I would certainly incude "How the software vendor responds to 3rd party vulnerabilities". And there are potentially many areas where such vulberabilities can exist. For instance SNMP is pretty standard for collecting metrics and intercepting SNMP "traps". But what if there is an issues with SNMP itself?  (I won't go into SNMPv1, v2 and v3 here) How does your vendor respond and mitigate against issues with underlying protocols. I've mentioned SNMP, but what SSH (or the numerous implementations of SSH), WMI. sFlow etc etc. This is my first layer. Security of the PROTOCOL.

The next thing is the communication of the monitoring data. Each of the above protocols need a TCP/IP port to be open. That means putting holes in your firewall. And for me that's the only downside of "agentless" monitoring tools. Don't get me wrong, agentless is great for ease of deployment and ease of management in a closed network. For anything that goes over a wider network or Internet, then it's agent-based management for me. Why, well typically because it should be more secure. The agent should communicate data to the management server over a single port in an encrypted for. The agent should also be configured to only respond to data requests from a VERY limited number of servers. So that's the second layer, the security of the AGENT.

Moving up our IT monitoring ladder, we have the security of the MANAGEMENT ARCHITECTURE. Is all data encrypted in transit? Is it encrypted at rest (i.e. in the database). Is access to the database limited to only the management software? Is all other access simply REad-Only (e.g. for 3rd party reporting tools). There's also the security of the entire network within which the management software is operating - but that comes under the remit of wider network security. Most IT Infrastructure Monitoring software these days is web-based. Is the web-server secure? i.e. is Apache, NGinx, IIS etc fully patched and as secure as possible. Same for databases.

We then also need to consider the ability of users to "do bad things". As a previous respondent says, deny everything and allow by exception. This is typically achieved by using some form of RBAC mechanism in the software (Role Based Access Control). Each user is given on the level of access to the monitoring software that is needed to deliver the service the business needs. For instance, A firewall guy (or gal) does not the ability to run scripts on an Oracle database. Therefore I'd include in my review an assessment of the granularity of RBAC for users of the monitoring software. Let's call this the security of the APPLICATION.

Now that's a long response, but never, ever lose sight of the simple truth - the human brain is more complex, intricate and flexible than any IT system. Or in other words, don't underestimate the ability of man to screw it all up.

DAVE COLLIER

Nobius IT.

It may not be mandatory for conducting a security review before procuring Infrastructure monitoring tools but understanding the security concerns and planning a security monitoring platform goes a long way. You can adopt a sectional approach and address each security section. The following sections may help address the security concerns:

1. Monitoring Platform exposure to the Internet - Ensure that the monitoring platform has restricted access to OEM sites and sessions are initiated by the monitoring platform only. If the platform is accessible from the internet, ensure access via secure mechanisms like VPN (IPSec/SSL).

2. Email security - accounts used by the platform to send out email alerts

3. Web server security - the console of most monitoring solutions will be a web-based interface - pay attention to enabling SSL with certificates and ensuring other aspects of web security. Ensure acceptable security practices for web server security, Self signed certificates, Trusted certificates.

4. User access - Create a list of administrators of the platform and monitoring users. Also, identify if you need to have an integration with existing LDAP or Active Directory setups. Role-based access should be charted out maybe based on the LDAP/AD groups. Pay attention to the local users created on the platform. 

5. Credentials used for end devices - Many monitoring tools will require device credentials to be stored on the monitoring platform (for example network device configuration backup). Make sure to have a security strategy for these credentials.

6. Anti-X solutions deployed on the monitoring platform - Define clear guidelines for anti-virus, anti-malware solutions, etc for deployment on the monitoring platform itself. You may be asked by the monitoring solution OEM to exclude certain files, folders, services, executables from scans.

7. Monitoring protocol security - use of SNMP, WMI are the defacto monitoring protocols. Use of secure methods like SNMPv3 with strong encryption methods. 

8. Database security - the monitoring application would eventually store captured information into a database.

9. Integration with other solutions like ticketing - Secure the integration whether using API integration, connectors available out-of-the-box, credentials, etc.

Each section may have elaborate security measures that may need to be adopted in consultation with domain specialists. 

Although in our company we didn't require to conduct a security review before choosing an infrastructure monitoring solution, we have particularly look about the authentication method. Talking about user's accounts, groups and permissions.
One tip we have used, was to look for a monitoring solution that can interface with an existing entreprise authentication server (LDAP Server). In other that users could directly log in this purchased solution with their entreprise accounts.
So we have no more need to invest in creating a new secure users database and simply focus on creating users permissions depending on employees category.

I would start focussing on the used acounts and their privileges, other components aren't that interresting security wise. But the used accounts are probably over privileged as my experience has showed my before.

The documentation MUST indicate that the standard security configuration is DENY EVERYTHING and grant permissions based on multiple conditions (IP, user, schedule, ...).
The BD with which it is compatible must be able to be encrypted.
Compatible with iso 27000.
The trial must pass several security tests before being included as an option to choose.

My company does not require a security review per se, although we do incorporate security measures to protect our network. For example, if your monitoring system is public facing, you'd want to lock it down so that only the IP ranges and TCP/UDP port ranges necessary for you to monitor what you want to monitor are allowed in. If you are doing only active monitoring, then you don't really need to allow any establishment of connections from outside. If you are using SNMP traps, or an agent that pushes info to the monitoring services, the respective IPs and ports need to be allowed in. You can do this with a firewall like iptables. Security by obscurity is also still a helpful thing. Default port numbers, etc. are low-hanging fruit for bots and things that scour the internet for easy victims. You can also use something like fail2ban, which creates a blacklist of IPs who repeat failed logins. It is also helpful to ask the vendor which versions of software they use. It is possible they use an older version, which is not as secure as using one that is regularly updated with security patches. For example, do they use mySql? Which version? What about the OS? Is it a version still supported?

IT security is an ongoing exercise, with some sporadic penetration testing. SOC should be closely coupled to NOC, especially in terms of log management, traffic capture and analysis (for heuristics/forensics), connectivity/management, DNS security, WAF, etc.
So it's more than security review before deploying NOC, it's rather complete integration with due proper design and planning.

Security is always important, the first thing you review is if you start using monitoring is do you need this on-premise or from the cloud.

With on-premise you follow your own security rules however important are the following questions:

-How is the monitoring data stored in the database?
-Are the DB fips enabled?
-How are agents sending data, is the data encrypted?
-What kind of data is sent between customer systems and monitoring server?
-Does the monitoring software using security policies or for example integrate with LDAP or active directory?

Today you have many tools for infra monitoring we deliver monitoring from the cloud and using a VPN/IPSec tunnel between the customer and the systems in our cloud.

Also, we have customers doing a security check on our servers and we using patent recognition to check if our systems have no security leaks. Second, we using local gateways at the customer to collect the data we need and only the local gateway has a connection with our servers. Using this technology we have only one connection between datacenter and gateway and this connection is monitored all the time as well only 2 ports are open in the firewall.

Important is what are you using for infrastructure monitoring and how is it connected, what kind of interface is it web or client/server from the client to the monitoring server.

security review for infrastructure monitoring software are limited to,
1. Software layer for venerability.
2. User privileges.