|
2010:
The Year of the Insider Threat
Two
high-profile news stories in 2010 served as a
reminder of the tough challenges faced by IT
managers, specifically regarding insider threats.
That is, the potential damage that can be caused,
intentionally or unintentionally, by people with
privileged access to data and systems.
The
first insider threat story of note from 2010 is
WikiLeaks. At first blush, the type of threat
represented by WikiLeaks is this: people can take
sensitive information from inside an organization,
publish it to a forum designed for that purpose, and
make a big splash. But more generally, the threat is
of any sort of unauthorized disclosure (e.g.
classified data; software source code; a customer
list; etc.), and it’s important to note that it can
happen maliciously or accidentally.
Mitigation of the unauthorized disclosure risk can
be a major effort. Organizations must undertake the
time-consuming and frequently ambiguous process of:
| |
a. |
Locating and classifying data
|
| |
b. |
Determining who has access to that data, who
should have access, how, and when
|
| |
c. |
Instituting the necessary access controls
for enforcement
|
| |
d.
|
Auditing access and archiving logs
|
Even
so, discretionary access controls don’t protect the
organization against rogue insiders who are
authorized to access certain information but not to
disclose it externally. Some additional protection
is afforded by commercial
Data Loss Prevention (DLP) technologies, but it
is infeasible to guard against every possible way
that sensitive data can be exfiltrated or disclosed.
The importance of the human element – including
instituting periodic vetting of personnel in a
manner commensurate with the risk – cannot be
overlooked, and neither can the importance of being
prepared in advance to respond to a disclosure
incident when one occurs.
The
second prominent insider threat story from 2010 is
StuxNet. StuxNet makes an interesting contrast
to the WikiLeaks story for two reasons. First, it
reinforces the point that the insider can be
innocent, albeit careless. While it’s admittedly
unclear to what extent user carelessness played a
role in the propagation of StuxNet, the takeaway for
the rest of us is clear: a trusted user can, for
example, introduce an infected USB key into the
vulnerable internal LAN. User education is crucial.
But
StuxNet also reminds us of the importance of two
parallel efforts: secure configuration on the part
of the IT organization and the disciplined
employment of Security Development Lifecycle
practices on the part of software vendors. |