The Myth of the Insider Threat
Too often after the
announcement of a new breach, the first reaction from the victim company and
the media is "another malicious insider attack". Case in point,
I was catching up on news from various sources and came across the following:
http://www.idgconnect.com/abstract/19647/lessons-sage-leak
"“We believe there has been some unauthorised access using an
internal login to the data of a small number of our UK customers so we are
working closely with the authorities to investigate the situation,” the Newcastle,
England-headquartered firm said in a statement."
Of course an internal
login was used to access the data, as part of the attack lifecycle, during your
reconnaissance phase you identify accounts to target for possible compromise,
based on the access/role of the individual.
Phishing attacks or
other simply attacks are often successful in gathering login credentials for
individual users, which can then often be used to access an environment (using
approved remote access methods such as external facing jump boxes, VPN systems,
etc.).
Once an attacker
has compromised an account, they use that to access the network or
systems, perform additional reconnaissance, identify additional user accounts
to target (based on access, and depending on the goal of the compromise). Once
they have an account that provides access to the system or network that
contains the data they are after, they begin the data theft process.
"Despite the “distinct lack of facts” currently in the public
domain, Clarke says the case “looks to be an insider
threat” and praised the fact that Sage appears to
have publicised the incident quickly.
Insider threats are, of course, nothing new. Before the World
Wide Web, the notion that insider threats were the most serious challenges to
information security was generally acknowledged to be true. With the advent of
the web, media attention moved on to juicy new topics such as phishing,
state-sponsored attacks, denial-of-service takedowns, hacktivism and so on. But
the insider threat regained stature in dramatic fashion with the Edward Snowden
PRISM disclosures.
“Insiders are trusted individuals that have access to the ‘crown
jewels’,” Clarke says. “The lesson here is to get your house in order and
realise that while, traditionally, security has been about perimeter defences,
it also has to be about protecting from the inside.”
Regular auditing, encryption and data segmentation should all be
part of a holistic approach to security, Clarke says, so that in the event of a
breach at least companies know the likely impact and size of the issue. “Nobody
is immune to a breach but it’s important that in the event I do get breached
that I know the scale of the threat.”"
Active and meaningful detection,
baseline use profiling, and correlation can help to identify either internal
misuse, or attempts or usage from external attackers.
Recommended
counters:
- Multifactor authentication – I can’t stress it
enough, but organizations who rely on passwords alone WILL be compromised. When you decide to deploy Multifactor
authentication, select a reputable vendor and have an implementation partner
that has done this before and has a good track record. A bad (either weak
implementation or poor product) multifactor authentication system is not an improvement,
and may provide a very expensive, and false sense of security.
- Audit the accounts – establish a periodic
account review for privileged accounts, establish both an on-boarding and
termination process that documents the request, approval, access required, and
requires the hiring manager to identify the specific access required (and
justify the access). You can’t just use a request process of “Give my new hire
the same access that I have”.
- Remove/reduce access for key systems. Systems
that house confidential data, regulated data, customer information, or business
sensitive systems should all have a very short list of users who legitimately
need access. This should not include company executives or non-technical
managers, just because they could request access does not mean they need
access.
- Using access control logs, create a baseline for
your privileged account holders. Don’t over do it, start with the most critical
accounts (Admins, Domain Admins, people that have SUDO on key systems, and
executives) and profile their login behavior. Using your SIEM or log management
system, identify the systems they standardly login to and from, and generate
events when access exceeds these standard behaviors, especially for unexpected
VPN sources, use of multiple VPN connections, excessive logins, logins after
hours, or attempts to login to critical systems. Each of these potentially
should have a Tier 1 level analyst take a look at the events, and look for correlation
or possibly contact the account holder to validate the activity.
Comments