[BreachExchange] Solving the bulk password theft puzzle

Audrey McNeil audrey at riskbasedsecurity.com
Tue Mar 8 21:18:00 EST 2016


http://www.continuitycentral.com/index.php/news/technology/934-solving-the-bulk-password-theft-puzzle

Another year, and another round of large-scale data breaches has started.
We were barely a week into 2016 when Time Warner was forced to announce a
breach of up to 320,000 users’ email account passwords; this followed
2015’s mega-breaches at organizations such as Ashley Madison, the US
Government’s Office of Personnel Management, toy maker Vtech and many
others.

Despite the scale of these ongoing data losses, and the reputational damage
and remediation costs they cause, the methods for enterprise-level
protection of bulk passwords and personally identifiable information (PII)
have remained fundamentally unchanged over the past 20 years. And it’s
evident that these approaches are simply not effective in preventing
breaches.

A majority of data thefts are done from an organization’s bulk file
storage. This is because once a successful attack is executed, whether via
a social engineering exploit to gain administrator credentials, malware
installation, or a privilege-escalation attack using known software flaws,
the theft itself can be done remarkably quickly. A million
username/password pairs may be stolen in just 60 seconds.

To protect sensitive data at the server or storage level, three broad
security techniques are generally used:

- Cryptographic protection, encompassing secure hash functions and the use
of symmetric key encryption;
- Operating system privileges;
- Intrusion detection.

While each offers a level of security, each also has weak points that can
be exploited: that is, of course, if they are applied at all.

Limitations of encryption solutions

Encryption doesn’t prevent data from being stolen; it simply delays the use
of that data for an uncertain amount of time, until the attackers are able
to decrypt it. With strong encryption, this may never happen. But it’s a
risk: and many organizations still store PII without applying any
encryption. And whether the data is encrypted or not, the organization must
publicly disclose a data breach, risking brand damage and worse.

Limitations of operating system privileges

Two elements can lead to vulnerabilities here. Operating system privileges
are highly vulnerable to social engineering attacks and human error, and
any flaws or bugs in the organization’s operating system or software can
allow sophisticated attackers to circumvent the privilege system
altogether, potentially using malware agents.

Limitations of intrusion detection

An intrusion may be detected before any data is lost, but many systems
often only trigger after some data is actually stolen. Intrusion detection
is an important tool in a security armoury, but it mitigates rather than
solves the problem.

So encryption and intrusion detection can reduce the impact of a bulk PII
or password theft, and sophisticated intrusion detection might alert the
organization before the theft takes place. It’s only operating system
privileges, alongside firewalls within the network architecture, that
actively prevent attackers from getting to the databases holding the PII.

And here, the key problem is that the PII is stored on database file
servers utilising industry standard architecture (ISA), which is
fundamentally vulnerable to malicious attacks. Typical commercial
off-the-shelf processors are vulnerable to malware; enterprise software
platforms are too big to trust, encompassing literally millions of lines of
code; and the permissions-based architecture that underpins any enterprise
network is vulnerable to permissions-escalation attacks and social
engineering exploits.

While increasingly powerful protective measures have been introduced to try
and close vulnerabilities, they are being layered onto existing ISAs. We’ve
kept doing the same thing repeatedly, building a security house of straw
simply because there’s been no alternative.

Locking up your data

Where do we go from here? We need to start thinking outside of the ISA box.
Bulk storage of usernames, passwords and other PII (credit card numbers,
addresses, biometric data) needs to be removed from standard, flawed
architecture; and to not rely on encryption for protection. The solution
also needs to be immune to both software and operating system
vulnerabilities, and to social engineering attacks.

This can be achieved by using a hardware data store that physically
encapsulates the PII. By encoding the data into the hardware and applying
hashing and shadow file principles, the information (such as passwords) can
be input and stored in the appliance, but never read out again or extracted.

Instead, the stored passwords are simply used as a reference to compare
against login attempts, and the appliance returns a ‘yes’ or ‘no’ answer
against users’ password input. There should be no interface from which the
information can be divulged, and no software or operating system that can
be attacked by hacking methods.

After two decades of using variations on the same techniques, the only way
to stop the bulk theft of sensitive data from organizations is to go
against convention, and take a completely different approach that locks
that information away, for good. To continue doing what we are currently
doing would be madness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160308/bccbaaf8/attachment-0001.html>


More information about the BreachExchange mailing list