Our databases are exposed
The Register recently published this article showing that almost half of databases have a known CVE.
Software vulnerabilities are mainly outside of the control of businesses who use databases (and businesses who use data analytics, business intelligence and data science tools which leverage the business databases in the background). This creates a good news / bad news situation.
Let’s start with the good news : ). The good news is businesses can still prevent the attacks from reaching the databases in the first place, and it is relatively simple. Simple means protecting your data in hours or days, rather than weeks or months, as well as eliminating some legacy complexity and systems.
The bad news is most businesses are not shielding their databases from cyber attackers – the databases are behind firewalls with open inbound ports (holes). Those holes are then leveraged by the cyber attackers. Let’s quickly peek into the Firewall holes before we return to the good news.
Firewall holes
Why don’t our firewalls protect our databases against cyberattacks which will cost us over $1 trillion this year? Because firewalls usually don’t know the difference between your database users and ransomware attackers. Since firewalls only speak the 5-tuple language centered on IP addresses, you are forced to open up holes in your firewall (inbound ports and IPs). Then, after the firewall, we try to separate between good packets and bad packets. Unfortunately, that doesn’t always work, as evidenced by all of these successful attacks. Adding to the problem, maintaining thousands of firewall rules adds complexity and potential for errors.
Ok, we are almost back to the good news. We can close those inbound firewall ports, making your databases invisible and unreachable to the cyber attackers. We can transform the leaky firewall into a fully closed firewall.
How to close your inbound firewall holes to seal off your databases
Step 1: deny all inbound on your firewall
Typical firewalls have thousands of rules, exceptions and polices. Your North Star is to wipe them all out. Replace them with one rule: deny all inbound sessions. That rule means the ransomware attack against your database will never get to your database. You probably won’t get to this North Star overnight : ), but we’ll give you an iterative path to get there. And, with full Zero Trust, you can also eliminate related infrastructure such as IPS/IDS and DDoS appliances because you will eliminate the attack surface itself – you will not be open to attacks from the network.
Step 2: identity, authentication, authorization
Great, we have sealed off your databases from cyber attackers. But your users need access. We use X.509 certificates to authenticate users, and only give them least privileged access to the specific database resources they require. Ok, ‘great’ from a security perspective (bidirectional certificate authentication and least privileged access are far more secure than IP addresses and open firewall holes)…but how simple can this really be?
It actually is simple. No SAML integrations, no VPN clients and no DNS trickery. Your data clients, such as BI apps, use standard APIs such as JDBC to access the databases. We provide a Zero Trust software wrapper around that driver, so that your users just keep doing what they already do – the certs act in the background – the user does nothing.
And we open sourced these wrappers (here is the Zero Trust wrapper for JDBC). It is similar on the other side of the connection – the private or public cloud where your databases are. There, you leverage software endpoints available in every major cloud marketplace, or containers/VMs for your private DCs, orchestrating them as code from your DevOps and NetOps tools.
We also provide SDK options to embed the Zero Trust directly into your apps, and thin clients for every device, so that you have full flexibility to choose whatever is simplest for you. Don’t take my word for the simple aspect – the video demo linked at the bottom of this post shows how all this was done in about 15 minutes, as code (there are also links to deeper tech info, and to enable you to kick the tires yourself, for free).
In summary, while the backend magic (e.g. the bootstrapped secure identity software which enables the bidirectional certificate authentication without requiring you to implement PKI infrastructure) is there, we keep it in the background, while giving you the controls and visibility you require.
Step 3: Private Fabric brokers
Terrific, we have both sides of the database connection covered in a manner that they get strongly identified, authenticated, authorized least privileged access. But we closed our firewalls! How do we connect those two sides?
Via your Private Fabric Routers, which act as session brokers. Both sides only open outbound sessions to their Private Fabric Routers (inbound firewalls closed!), and your Private Fabric only accepts strongly identified, authenticated, authorized sessions (so that ransomware attack trying to get to your database CVE…not allowed on your Fabric to begin with):
Routers sometimes has a complex connotation – but in this case, as you can see in the video demo linked at the end, you spin them up an down, programmatically, in minutes, often with your NetOps or DevOps tools…just like you can do for your VMs. Additionally, these Routers are on multiple tier 1 backbones and run patented routing algorithms to find the best performing paths for your data.
Everything you see in the picture is controlled by you and dedicated to you, with NetFoundry managing the underpinnings as SaaS.
Spin up Zero Trust database security to close your firewall ports
Most of us in the security, tech and networking worlds are cynics, and for good reason. Meanwhile, the marketeers have flocked to use and abuse the Zero Trust terms because all the experts are saying Zero Trust helps mitigate against cyberattacks such as this one and the recent ransomware attacks, making this post seem even more suspicious. So here are some handy links to enable you to decide for yourself:
Download a whitepaper to get into the nitty gritty details, and read through some customer case studies.
Head over to our open source to try it for yourself.
Check out a video demo in which an engineer makes a Postgres database dark in about 15 minutes with zero infrastructure.
See how NetFoundry’s Zero Trust aligns with NIST Special Publication 800-207
Grab a whitepaper on attacking ransomware with Zero Trust
And, most importantly, find some way to close your firewall ports (even if it is a different way than the NetFoundry customers used to secure their databases). There will always be database CVEs. You don’t need to expose the CVEs, or your databases, to the world via open firewall ports.
