[BreachExchange] What is behind far too many security leaks? Laziness

[Audrey McNeil]

http://www.computerworld.com/article/3157836/retail-it/
what-is-behind-far-too-many-security-leaks-laziness.html

When the PCI Security Council last month rolled out new, and quite useful,
scoping/segmentation guidelines for retailers, the council's CTO made an
interesting comment.

“For years, we have preached the need to simplify and minimize the
footprint of cardholder data,” said Troy Leach in a statement. “One way to
accomplish this is through good segmentation. It allows an organization to
focus their attention on a limited number of assets and more readily
address security issues as they arise. As a result, it should also reduce
the level of effort to comply with PCI DSS.”

Although segmentation is to be applauded (dig at PCI: you have yet to make
segmentation a requirement, which is something you really want to do soon),
it's not the panacea for the cardholder data problem Leach is referencing.

Network segmentation is a great method for helping people who are following
the rules to do so more securely. But I would argue that a much greater
percentage of errant data happens because employees are either not
following the rules or that the rules are nowhere near strict enough.

Problem 1: Orphaned data

A workgroup was created for a project three years ago, for example, and
when the project ended and the team was reassigned, no one bothered to go
back and delete no longer needed sensitive data. Most likely, no one even
saw it as their responsibility. Now multiply that by the thousands of such
projects that the typical enterprise starts and stops each year and the
problem becomes clear.

Even worse, this orphaned data is solely secured by the requirements that
existed at the time it was created. No one is going back and upgrading
security on forgotten data.

Rules are needed for handling such data. People have to be assigned at the
conclusion of all projects to go back and seek and secure all sensitive
data.

Note: With the exception of public-facing web content and perhaps some
brochures, the overwhelming majority of the typical enterprise's content is
indeed sensitive. It may not be covered by PCI, HIPAA or Sarbanes-Oxley,
and it may not be of significant value to a cyberthief, but if information
gets lost and can't be easily re-created, it needed to be treated as
sensitive.

Problem 2: Internally shared data

The quintessential example here is with a request from marketing to examine
all customer data dealing with, let's say, a specific time frame. They have
no need to see payment card details and related details and probably no
interest in seeing it either.

But for far too many enterprises, unless someone in IT takes the time to
strip out that PCI-germane sensitive data from what marketing really wants,
it will all be included in the data dump. And given that marketing's people
have no need to understand PCI rules, they are unlikely to properly deal
with it themselves.

Problem 3: Traveling data

Fortunately, this problem is sharply declining, but it still exists,
especially in midsized and small businesses. This is where someone takes
the secured data and transports it out of the secure environment. It might
be placed on a thumb drive, downloaded to a smartphone or even moved to an
insecure cloud location.

>From there, it might travel to a home laptop and worked on in a hotel room.
After that, it might get transmitted on an insecure hotel LAN (or, for that
matter, a Starbucks LAN). Even more likely, it could get grabbed by an
insecure backup by way of iTunes or Carbonite.

All of a sudden, your data is sitting on five distant locations. If any one
of them gets breached, that stolen data will eventually get tracked back to
your systems. Oops!

None of these problems will be addressed by network segmentation.

In a phone interview last week, PCI's Leach acknowledged those issues and
added one of his own: "Third-party access is still the biggest problem."

In terms of volume, third-party access is indeed horrible. The huge number
of contractors and partners (suppliers, resellers, supply chain
distribution players, etc.) that companies work with require far too much
access. That said, it's also a straightforward problem to address, with
VPNs almost universally used. The issue with third parties shares the
internally shared data referenced above: allowing sensitive data to be
shared when it's not needed. A healthy dose of strict need-to-know rules
wipes out so much of this problem.

Leach added that the internet of things (IoT) is going to be one of the
bigger data-retention and data-access headaches in the frighteningly near
future.

But this all comes back to sharing what needs not be shared. Companies
"don't do the analysis of what they are sharing," and this requires not as
much a security answer as a need to "re-evaluate the business process. It's
not a technical solution. It's a business solution," Leach said.

Still, there are some technology ways of mitigating this mess. Leach
applauded more tokenization of primary account number (PAN) data. That
would allow, for example, marketing to have the full customer data because
the sensitive payment elements would be inaccessible to them. In theory,
that would reduce or eliminate the harm if it gets out into the wild.

Many companies "need to do a larger business re-engineering process, and
that requires communication and engagement throughout the organization,"
and "it needs to come down from senior leadership" beyond the CIO and CFO,
Leach said.

The problem is that many executives "don't see the ROI" from protecting
payment data, he said. Beyond protecting the data better, these changes
will "create efficiencies and reduce the overall risk to the organization."

That's exactly right. It will allow for more sharing and fewer headaches.
CEOs: Don't do this to help your firm stay PCI compliant. Do it for the 50
other advantages your company will realize. More intelligent data processes
isn't just compliant. It's the smart business move.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170116/86f3212f/attachment.html>