Secure Configuration - Trancript
In this module you learned about the need to maintain software at a vendor or community-supported
level; regularly check your system configurations against industry standard or project defined security
baseline; disable functions that are not needed or not secure; and remediate misconfigurations in a
timely manner.
Why does all of this matter? Let’s take a look at a couple real world examples in PostgreSQL.
First: a case where a misconfiguration alone could allow malicious actors to compromise a system:
One well-known threat actor often uses the Linux malware “Kinsing” to target containerized environments for
crypto mining. Earlier this year, researchers observed an increase in Kinsing attacks on PostgreSQL databases, and
identified a potential attack path: the threat actors were leveraging misconfigured PostgreSQL servers by
capitalizing on the “trust authentication” setting, which when misconfigured, results in PostgreSQL
assuming that “anyone who can connect to the server is authorized to access the database.” In that case,
if the attackers were able to gain access to the server, they immediately got access to the database as
well.
How could we prevent this attack? By applying a layered security defense:
• Primarily, remove the trust authentication setting and follow the best security practices for
configuring PostgreSQL, as recommended by the PostgreSQL community
• Harden access to the server itself
• Remove default users and extensive permissions.
Now, let’s look at second a case where a misconfiguration in a container image coupled with an unpatched
vulnerability allowed bad-actors to compromise systems:
In the same PostgreSQL context, attackers scanned for default ports mistakenly left open to the internet
in the container image. Once they found those open ports, they could scan for unpatched vulnerabilities
with known exploitations. Most critically, there were several remote code execution vulnerabilities in
PostgreSQL that the attackers were able to leverage and install malware.
How could we prevent this attack? Similar to the first real-world scenario we looked at, the mitigations for
this attack pathway demand multiple layers of protection:
• Use IBM approved container image registries and check and continuously monitor for open ports.
• Scan for vulnerabilities, and don’t delay patching
Security vulnerabilities do not exist in isolation, especially in a complex IT environment. We must
constantly work on reducing our risk exposure by adhering to a layered defense of proactive and reactive
controls.
While all vulnerabilities should be fixed according to the timelines in ITSS, there are some vulnerabilities
that require your expedited attention based. IBM’s CISO Vulnerability Response team is here to help you
stay aware of some of the highest risk vulnerabilities, like Remote Code Execution vulnerabilities in
PostgreSQL, so that you can quickly scan and patch your systems before they’re compromised. Make sure
to subscribe to their blog to receive notifications.
