Re: [PLUG] Fwd: [FD] Massive Breach in Panera Bread

[Rich Kulawiec <rsk@gsp.org>]

Y'know, at one point in time I strongly agreed with what you've expressed
here.  Over the years, though, I find myself slowly but increasingly
disagreeing, because I've watched the nonstop parade of security breaches
and dataloss incidents accompanied by an equally nonstop parade of
stonewalling, denial, obfuscation, and outright lying, with almost no
consequences for the people who should bear the most responsibility.

A recent example: Experian.

(Actually, in all probability, a recent and future example, since I
can see absolutely no reason why they should change a thing except
for perhaps hiring more and better spokesliars.  Therefore I expect an
encore performance.)

But there's another problem with this "responsible disclosure" approach
that so many companies are trying to push: it's presumptive.

What I mean by that is this: look at the Panera situation.  The researcher
told them.  Suppose, instead of blowing it off they'd actually taken it
seriously, and done what they should do: call in all available IT staff,
launch an inmmediate 24x7 investigation, pursue that until the root
cause is identified and fixed, until the consequences are understand
and remediated, and so on.

The presumption of "responsible disclosure" is that this method prevents
knowledge of the problem from reaching people who might want to exploit
it rather than just report it.

But there's no reason at all to believe that's how it works.  What one
person can find another can find.  And given the low risk (in many
situations) and high reward (in some situations) there's every reason to
expect that other people are looking...and that rather than reporting it,
they're extracting data, packaging it, and selling it.

[ Actually, there's an easier way.  Hack the researchers.  It's an old
lesson in tradecraft: acquiring intelligence is tedious, expensive,
difficult, and sometimes risky.   So don't do that.  Instead, wait
for someone else to do it, or convince them to do it, then steal it
from them.  Now granted, researchers may be harder targets than most,
but they're not impervious.  So if I were running an intelligence
agency for $EvilOverlord, I would try to get the inside track by
penetrating their operations. ]

In other words, "responsible disclosure" requires us to believe that
nobody else can do or has done or is doing what the original reporter
has done.  I think a better presumption is that when A reports a
problem, B, C, and D have already known about it for a while and
that the interests of the public are best served by telling everyone --
not just the company or organization or agency involved.

There's another related problem that's one of my pet peeves: noncompliance
with RFC 2142.  (If you are reading this and don't know what RFC 2142
is and you run an Internet-connected operation, then you should (a)
go read it right now (b) implement it before close-of-business today.)

I'll even help you:

	Mailbox Names for Common Services, Roles and Functions
	http://www.ietf.org/rfc/rfc2142.txt

Note that RFC 2142 doesn't say how you should route mail received at
those addresses.  At a small operation, it might be appropriate to send
it all to one person.  At a medium operation, maybe an internal mailing
list.  At a large operation, maybe a ticketing system.	Not important:
what's important is that arriving traffic gets triaged, read by clueful
eyeballs, and dealt with.  (Also important is that you don't block your
abuse@ traffic. Think about it.)

This is Operations 101.  And yet...all kinds of operations fail miserably.

Which means that they have effectively stuck their fingers in their ears
and are doing their best to ignore problem reports of all kinds -- not
just security issues -- and this is why in turn their plantive whining
after-the-fact that "we weren't told!" is so much BS.  (As a side note,
trying to reach a CSO via normal customer/tech support is a completely
losing proposition.  I'm a customer of one financial entity whose customer
support people claim that they *do not know who their CSO or CTO or CIO
are AND can't find out*.  This conversation is ongoing.)

If you read NANOG or some other lists, you will occasionally see people
who are trying hard to do the right thing by paging someone, anyone,
in the tech hierarchy at Company X, because they've exhausted all other
approaches and Company X does not support RFC 2142.  Think about that
for a moment: some senior engineer or analyst or programmer is very
generously volunteering their professional time for the benefit of a
company they don't even work for, and the company, instead of making
this easy, instead of graciously listening, instead of being profoundly
thankful that someone else is doing their job for them for free and
is trying to rescue them from a possibly-terrible mistake, is doing
its best to make it impossible.

I really can't summon up much sympathy for people who do that, given
that RFC 2142 dates from 1997 and much of what's in it was a de facto
best practice for many years before that.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug