Before we begin my article, let me talk about CVEs.

A CVE, or Common Vulnerabilities and Exposures, is a standardised system for identifying and cataloguing security vulnerabilities in software and hardware.

Vulnerabilities identified with a CVE are often assigned a severity rating using the Common Vulnerability Scoring System (CVSS). This system evaluates the impact of a vulnerability based on factors like exploitability, impact on confidentiality, integrity, and availability, and environmental considerations.

The CVSS score ranges from 0 to 10, with corresponding severity levels:

As I write this article, March is coming to an end. I have no idea what will happen in the next few days (OK, except summertime), but what happened before is enough for several articles.

IBM published an advisory about security problems in AIX with a score of 10 out of 10!

Kubernetes published several security advisories with scores between 9 and 10.

VMware was very shy and published an advisory with a score of 7.8, even though the problem’s description would be better suited to 10.

These are very good reasons to start with the usual lecture about IT security in the data centre and why you must implement good security practices.

But before starting the lecture, let me take a step back and talk about vulnerabilities in general.

First, we usually start talking about IT security problems if we see a new CVE. However, a CVE is only an entry in a database. It doesn’t mean that the problem existed before or that it exists at all. Everyone can request an entry and get a CVE number for a future problem.

Google for some CVE bogus entries and find out that hackers can report a probable security problem in some software only to submit a malicious patch for it.

Second, even if you get a CVE with a score of 10, it doesn’t mean the world goes down and you must close your data centre. It means that the CVE’s author thinks that the problem is critical.

The author may err. In any case, the author has no idea about your environment. You must get the CVE, read it, understand it, and audit your own environment. Maybe you have already taken precautionary measures, and you are not vulnerable to this problem at all. Then, your own CVSS score is 0. Maybe you can mitigate the risk by using a workaround or even multiple workarounds.

Third, don’t trust any patch management tools. In my newsletter several weeks ago, I wrote about how to produce “fake” security patches for AIX.

These are shown like a normally installed security fix, but they don’t have any content and don’t patch anything. The vulnerability scanners find no problems with the systems and the fake patches.

This can be done for each operating system, not only AIX. It is not a problem with any operating system but a problem with how the scanners work.

If we can’t rely on our vulnerability scanning software and CVE databases, what can we rely on?

You must rely on your own. As I usually say, “Don’t trust the data that you didn’t fake before.” If you didn’t fake them, someone did it for you, and the data is untrustworthy.

Implement some good practices. IT Security is a huge topic now, but if you implement only some of the security recommendations, you will fix most problems.

Another good piece of advice is that hacking must cost more for the hackers than the price of the data they can get.

If we talk technically about the recent AIX problem, you can take several very simple steps to mitigate the risk to zero.

Don’t use your NIM server as a jump server for all servers. Use the NIM server as the NIM server for installations and updates. Install another server to be your jump server and control everyone who can log in to that server.

If you use your NIM server as a NIM server, you don’t need it daily. What does it mean for you? You can switch it off. Switch it on only when needed – before installation and update operations. You can do it automatically using Ansible – switch on NIM, update the AIX server, and switch NIM off. As you probably know, the most secure server is a switched-off server.

Another easy way to mitigate the problem is to switch off push operations from the NIM server.

You issue the command “nimclient -P” on each of your AIX clients, and the NIM server administrator (or hacker) can’t execute commands on your AIX servers anymore. You can still update your AIX clients or install software by using the nimclient command directly from your AIX client. If you use automation tools like Ansible, it is a no-brainer for you.

If we talk about NIM operations like updates, yes, I will tell you. Be on a current AIX level! I love customers saying they are on the way to migrate from AIX to Linux, and this is why they don’t want to upgrade their AIX 7.1 servers. AIX 7.1 is, meanwhile, in the last months of its extended support mode. The same customers don’t pay for the extended support and just wait till they are hacked. Then they have one more reason to say that AIX is insecure.

No guys! Your IT operations practices are insecure! Unless the system is decommissioned from the data centre, it must be updated, and security patches must be applied.

Otherwise, you are an untrustworthy company, and nobody should do business with you. You risk your customers’ data. Will your customers be happy to learn about it when you get hacked?