What the Antiquated Bank ATM Can Teach Us About Database Security

by | Data Limits, Network Security, Proximity Security

Though the automated teller machine (ATM) may soon go the way of the eight-track and the VHS player — with automation features such as direct deposit and debit cards now available, few people use ATMs — there was a time when the ATM was the primary way most people checked their account balance and obtained cash. (Not to mention college students looking to fund their next box of macaroni and cheese.)

And though the ATM may soon become an obsolete technology, this doesn’t mean it can’t serve as an instructive metaphor for understanding the relationship between the web and your organization’s database server.

The Myth of the “Secure” ATM

There is one incontrovertible fact: access to safeguarded and sensitive data starts with the server.  

Web servers, like ATMs, typically provide a small amount of sensitive data in a specific context. In financial records that could be one client’s data at a time.The ATM does not give you the financial details of every single member of a bank, nor should it, unless you are somehow able to log-in to each account to gather specific data, as each account (or specific user context) requires different credentials.

In an ATM context, this could mean your savings account displayed on the screen while you wait for your cash-withdrawal receipt.

Access to a bank vault is similar to access to a database. The back-end database houses the bulk data, not unlike a bank vault which houses the bulk of a financial institution’s cash. The Web user looks for one client’s data, usually their own, providing the name or account number required to access that data.

The Web Server then looks up that one client’s data by providing a query to the database, where all data is stored for all clients. Upon finding that one client’s data, the database provides data to the Web Server, which in turn formats it for the Web user to view.

If the Web server is compromised, it is disastrous, as multiple queries can be made, releasing precious data stored in the database. When the database is compromised, it is catastrophic.  

With a minimum of effort, a single query can hand over a copy of the entire database into unscrupulous hands. In this way, databases are like a bank vault and the Web server is like an ATM.

But in another — more catastrophic — way, they are drastically different.

The truth is, a bank vault is more protected than an ATM, whether because of locking mechanisms, armed guards, or sheer concrete.

And while databases are generally secure, they are not as hardened as a Web server. Databases are not public on a network, and a Web user does not require access to the database, directly, to do their appropriate work.  

What does this mean?

It means, from a Web standpoint, that the ATM is far more secure than the bank vault. Or better put, it’s as if, from a Web server standpoint, once someone gets past the defenses of an ATM, the bank vault is left open, unguarded and ripe for the picking.

Databases should be protected behind the Web server, with limited accessibility to anyone or anything; they are your bank vault or as we call them your, “Golden Goose.” Database servers accessible by internal end-users are vulnerable.

On an internal network, users share access to many devices protected by firewalls, credentials, or both. Internal user computers often have access to servers that should be limited.  

We understand why a Web server needs to be accessed by Web users. But allowing a database to be accessed by internal or VPN users leaves the most sensitive bulk data open to potential compromise.  

An internal user knows the value of the data in the database and has “some” physical access to the people and facilities where sensitive data is stored. It’s much easier for an internal user to learn database security credentials than someone on the outside. Leaving the database server, or “Golden Goose” server, accessible to internal users opens the server to potential compromise.

Every institution has and uses firewalls — even those that have been the victim of compromise. Using a solution such as HOPsphere Radius Security, to determine the appropriate number of hops and to lock down the database from being overly-accessible reduces risk beyond the use of conventional firewalls and security methods.

After HOPsphere Radius Security methods are applied, an unauthorized internal user armed with security credentials can’t even get a login prompt, with or without a firewall.

And that’s something any network administrator, or bank branch manager, can appreciate.

Keeping Data on a Short Leash to Avoid Breaches

Even the best-trained dogs have leashes while in public. Despite how much one trusts their dog to act obediently, it simply is not possible to know what kind of situations one might encounter while on a walk—maybe an enticing squirrel? A loud noise?...

HOPZERO Selected as “EMA Vendor to Watch”

Enterprise Management Associates (EMA) is a leading voice in the information security industry. With its dedication to in-depth research — and unrivaled analysis — the EMA is an important resource for data management and IT professionals...

Bill Alderson is CEO and co-founder of HOPZERO. He has been involved with network security since 1980, where he began analyzing secure networks for Lockheed. Formerly Technology Officer of NetQoS/CA Technologies, he is a deep packet analyst, and was an integral member of the 9/11 Pentagon restoral team. Alderson has trained over 50,000 network forensic professionals through his Certified NetAnalyst program, and has assisted 75 Fortune 100 companies with network security needs. He was deployed six times with US Central Command to Iraq and Afghanistan to provide deep packet analysis for large-scale network Department of Defense biometric network systems.