Cyber attack and monitoring software - best practices

Cyber attack and monitoring software - best practices

In less than 2 months, 2 software programs - Solarwinds and Centreon (product based on Nagios) - have been the victims of unprecedented attacks. It is obvious that we want to minimise the damage, but how can we estimate the consequences of hacking that has been going on for years? What cybercriminal does not want to cover his tracks, after his intrusion, in order to commit his crimes without being caught? It is difficult to know what happened after the infection and to what extent the misdeeds have been covered up...

Monitoring software is a target of choice

Monitoring software are targets of choice for hackers because this software generally has access to all the components of an Information System. Using monitoring as a pivot is a real gold mine of information that allows malicious people to understand a company's information system in order to speed up each stage of a malicious act, whether it be in terms of recognition, exploitation of vulnerabilities or data exfiltration.

It is obvious that all software is vulnerable, but might there be considerations that make open source software more of a at risk than proprietary software from a security standpoint? The Canadian government recommends precautions when using open source software and even mentions certain risks related to its use www.cyber.gc.ca.

Why is it easier to analyze security holes in Open Source software?

1. The source code is open and accessible to all
2. The lists of vulnerabilities are also
3. The "perverse" effects of the open community

When maintaining software, administrators must keep abreast of all security issues, whether they concern software, operating systems or the network environment.

For example, in a recent version of Centreon 19.04, there are more than sixty detailed security patches on the Github website: https://github.com/centreon/centreon/tree/19.04.x/doc/en/release_notes/centreon-19.04.
It is also necessary to add certain very vulnerable dependencies such as Apache and PHP which total a history of more than 1,200 vulnerabilities for one and 600 for the other.

Many other sources of information allow the exploitable vulnerabilities (CVE) to be referenced in detail for many open-source software:

• Centreon: https://www.cvedetails.com/vendor/7565/Centreon, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=centreon
• Zabbix: https://www.cvedetails.com/product/9588/Zabbix, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=zabbix
• Nagios: https://www.cvedetails.com/product/2468/Nagios, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nagios

On the other hand, there are many tutorials on hacking techniques https://medium.com/@0x616163/pivoting-with-devops-tools-abusing-zabbix-877e92bf49c2, MetaSploit-type modules targeting the tools mentioned above https://www. cvedetails.com/metasploit-modules/vendor-1424/Nagios.html which can provide an almost turnkey hacking solution from a Kali Linux virtual machine. Whether on the software itself or on the embedded libraries, hackers can quietly study each vulnerability, develop a tailor-made virus or an intrusion technique and perform tests for the chosen version.

The role of publishers for software security

At ServicePilot, we also produce highly sensitive software and take the issue of cyber crime very seriously. The source code is under control and closed to the public. The architecture allows for a unidirectional secure flow for data between the servers and the monitoring platform using TLS 1.2, thus avoiding the need to open ports on the target servers.
We work with the largest French companies on software quality mark problems from a security point of view.
We regularly carry out Pentests (penetration tests).
We have already worked with some clients on particular security mechanisms, for example with non-IP networks. We carefully choose every component, every detail of the architecture.

Good practices

Here are 7 good practices that we suggest in addition to the usual recommendations:

1. Put IS monitoring back at the centre of concerns on the same level as security
2. Avoid old monitoring techniques based on remotely-triggered scripts that require opening some ports on critical servers (SNMP, NRPE or NSClient++ for example)
3. Analyze and log all traffic suspects on each critical server (network connections and application requests)
4. Continuously measure the security of the IS with very reliable solutions that can be implemented very quickly: logging (desktop-web servers), network conversations, file events, ...
5. Audit the vulnerability of each sensitive software, dependent software, manipulation possibilities (e.g. Apache/PHP scripts)
6. Evaluate risks related to internal threats (malicious insiders, disgruntled employees, third parties, etc.)
7. Check if there is actually a maintenance agreement on critical software, because in general Open Source software is excluded from it

Cyber security standards, an idea to improve software security?

The adoption of a quality mark "secured by design" and "tamper-proof" emphasising software security would not only help companies to improve the security of their own software, but would also provide companies with an indication of the security of the software architecture they wish to integrate into their information system.