IT infrastructure layers requiring Privileged Identity ... · accounts in their IT environments and...
Transcript of IT infrastructure layers requiring Privileged Identity ... · accounts in their IT environments and...
Much of today’s IT infrastructure is structured as different layers of devices (virtual and
physical) and applications. Now each installation (device or application) on each of these
layers comes with its own administrative account. These credentials, in turn, have to be
managed themselves to prevent security breaches. To get a sense of the scale, just one
large-scale IT deployment can potentially have privileged accounts to the tune of 6-digits
(>100,000) if we count all installations on all the layers. Even if the number of vulnerable
credentials is a small subset of this number, an automated tool can work through them in
matters of minutes. Just the thought of manually managing all of them can be very
intimidating. Fortunately, automated privileged identity management systems exist for this
very purpose. And the best part is that you can integrate them at all layers of your
infrastructure.
Abstract
IT infrastructure layers requiring Privileged Identity Management
White Paper
www.arconnet.com
The layered architecture of IT infrastruc-
ture exists for several reasons, like flexibility
in switching vendors, having separate
operational team manage each layer, no
single points of failures and so on. But with
all these advantages comes the cost of
having a multitude of systems that need to
be managed separately, i.e., the administra-
tive logins don’t get mis-configured, stale or
shared; instances are not published with
default logins that can be looked up in the
device’s user manual; and other general
security practices that should be followed
for credentials and access rights. If an
attacker gets access to just a small subset of
these vulnerable credentials, he can breach
the system, working as a privileged user,
with complete control over the installation
in question, without leaving any trace, until
it’s too late.
With the advent of the cloud, IT is expected
to work at an absolute minimum cost to
ensure high service availability and con-
sistent data security. Until now, privileged
access has been difficult to secure within a
large-scale, dynamic IT setup using just
manual intervention and outdated software
tools. This, predictably, has led to
inappropriately secured privileged accounts,
which has been exploited byhackers and
malicious insiders.
As an example, compromised credentials
were the reason for 84% of stolen data, as
per a 2012 Verizon survey of larger orga-
nizations that suffered data breaches. This
problem of fragile and unmanaged privileged
credentials can be successfully addressed by
automated Privileged Identity Management
solutions across the disparate layers of the
IT infrastructure, which are getting more
complicated each passing day.
Overview – vulnerable privileged Identities are a clear and present danger
White Paper 01
www.arconnet.com
IT infrastructure is mostly structured as layers of devices (virtual and physical), which are
home to vast numbers of rapidly changing privileged accounts (Figure 1 below), including
- Administrative logins at the Operating System layer - on physical and virtual computers
(Windows, Linux, UNIX, and others), as well as the privileged logins present in VM
hypervisors.
- Administrator and Root accounts present in shared file system layer.
- Highly privileged service and process accounts on the Application and Database layers
- used for application-to-application and application-to-database authentication.
- Root and Admin accounts on the Network layer - present on physical and virtual network
security appliances and backup appliances.
Securing these privileged identities is very crucial to the secure functioning any IT setup.
According to the SANS Institute, a “primary method for attackers to spread inside a target
enterprise” is the misuse of these administrative privileges.
It is tempting to reason that these administrative credentials can be managed by
conventional Identity and Access Management (IAM) systems. But privileged accounts
aren’t typically provisioned as user logins are. Privileged accounts are found on the network
whenever physical and virtual IT assets are deployed (or changed).
Problems managing privileged identities
White Paper 02
www.arconnet.com
a typical example
Thus, automated software (not IAM) must discover and continuously track privileged
credentials. And IT regulatory mandates including Critical National Infrastructure mandates,
PCI DSS, SOX, HIPAA and others require that these credentials be frequently changed, as
every shared, static, or cryptographically weak privileged identity represents a potential
attack surface. These privileged passwords must also be cryptographically complex. Access
to these passwords must be attributed to named individuals and audited.
Because of the risks introduced by unmanaged privileged identities, industry groups cite
the control and auditing of privileged access as an essential cornerstone of effective cloud
security.
man
ufa
ctu
rin
gP
rivi
lege
d Id
enit
itie
s -
Ad
min
; Ser
vice
Acc
ou
nts
U
sed
to
- A
cces
s d
ata
feed
s; E
nab
le/D
isab
le m
on
ito
rin
g
bac
kup
P
rivi
lege
d Id
enit
itie
s -
Ad
min
istr
ato
r; R
oo
t; S
ervi
ce A
cco
un
tsU
sed
to
- A
cces
s tr
ansa
ctio
n d
ata;
Man
age
arch
ives
; Pu
rge
save
d fi
les;
M
od
ify
bac
kup
con
figs
shared file systemPrivileged Identities - Root Admin Used to - Add/Delete User, Change user privileges, Manage storage use.
applicationsPrivileged Identities - Service Accounts, ASP.Net, Run AsUsed to - Modify back-end applications, After published web-content, Access DB, Transact
operating systemPrivileged Identities - Administrator; Root; Super UserUsed to - Read/Copy/Alter data; Manage security settings; Manage user accounts; Run daemons; Enable/Remove shared files.
databasePrivileged Identities - SYS, SYSDBA, SAUsed to - After schema/DB configs; Modify schema objects; Manage Data
networkPrivileged Identities - Admin; Root EnableUsed to - After config settings; Manage security policies; Grant/Deny/Revoke network access; Access data feeds.
Figure 1: An inventory of privileged accounts across various layers
White Paper 03
www.arconnet.com
Consider an IT setup for a bank’s data center. Because of the sheer transaction volume that
the system can experience at any time, there are several virtualized as well as physical
servers distributing the load amongst them. Also, the regulatory mandates require each
transaction to be atomic, and the system fault-tolerant. This requires the system to have
multiple levels of redundancy with regular monitoring of nodes over a robust network, with
regular backups.
On breaking the setup into various layers, we can do a high level walkthrough. Keep in mind
that each installation on each of the below layers have privileged identities that need to be
managed:
Database layer – Though the DB is a
specialized application server, it’s
categorized as a separate layer due to the
sizeable chunk of dedicated resources it
needs. It is innermost, and the most
important layer to protect, even from DBAs,
as any unauthorized or mis-configured
access can have disastrous consequences
for the organization and its customers.
Shared File System layer – A fairly common
need in such a setup is file sharing across
applications. These can be reports, or data
feeds, etc. This warrants a NAS (Network
Attached Storage), or SAN (Storage Area
Network) installation within the
deployment.
Backup layer – Generally an automated
task, backups themselves require privileged
read-only access to data that needs to be
backed-up. Sometimes, though, the back-up
scripts are hard-coded with super-user
credentials, which in itself is very unsafe as :
a) bugs in the scripts can change the
original data as it can write to it;
b) and access to the script would be like
handing someone the keys to the
treasure vault.
Network Devices layer – Any networked
system of this scale has a whole army of
routers (wired and wireless), switches, load
balancers and firewalls. The hardware surge
on this layer is specifically to:
a) handle the immense workload that
transactional systems experience;
b) and to act as the first line of defense
for the entire setup by being
impenetrable.
Operating Systems layer – As deployments
of scale require multiple applications
running on multiple servers, each with its
own hardware and software requirements,
the same environment can have Linux,
Windows, Solaris or, custom OS’s with
multiple flavors (like CentOS, Ubuntu,
Debian), and versions (like Windows Server
2003, 2008)
Application layer – The plethora of apps,
custom-made and licensed, that run on these
servers need to interact with each other, and
other installations like network and OS, over
the line. Credentials with access to more
resources than necessary are usually
configured for them. Any backdoors in
these apps, in case of improperly managed
privileged credentials, can compromise the
whole system.
White Paper 04
www.arconnet.com
Compliance standards also require the bank to have on-site and off-site Disaster Recovery
(DR) setups that can be switched over to in case of failures. Thus, the DR needs to be a
reasonable reproduction of the main system, with close to 75% (if not 100%) of all nodes
replicated. It is more often than not, that the DR setups once provisioned lay forgotten until
the next system -wide failure. This means that not only are they not up-to-date with respect
to the actual system they are supposed to fill in for, but also their privileged identities need
to be excavated from long overdue reminders about updating the setup.
Conclusion
Now that solutions have evolved to service platforms that are designed to meet IT
infrastructure requirements for managing privileged identities, certificates and other
file-based secrets in large, ever-changing environments, a significant operational roadblock
is removed that once prevented the largest service providers (in-house or vendor) from
complying with industry and regulatory requirements.
Monitoring layer – Fault-tolerant systems
need to be constantly monitored, and alerts
need to be raised if something goes wrong.
The automated systems that handle this
requirement exist outside as well as inside
the setup, and generally have deep access to
all resources to properly accomplish these
tasks. A breach at this layer can potentially
lead to data leak about the internal
configuration and will be disastrous.
Large setups generally, but not always, go
with a specific vendor for these devices/
applications because of economies of scale.
Consider the following facts: the vendor’s
website
a) has the bank listed as a satisfied
customer;
b) and has the downloadable user manuals
with the default privilegedcredentials
printed for all to see. This is generally
enough for an attacker to get started
on breaking in. Each layer above can act
as a blockade(with properly managed
privileged identities) or a gateway(with
default, static, or weak privileged
identities) for hackers.
White Paper 05
www.arconnet.com
Organizations these days are aware of the potential risks of the unsecured privileged
accounts in their IT environments and want to work to close these gaps. A PIM solution doc-
uments potential risks present in the infrastructure, enumerating privileged accounts by
hardware platform, account and service type. It then continuously secures privileged
accounts everywhere on a network and provides an audit trail of each access request.
About ARCON
ARCON is a leading Information Security solutions company specializing in Privileged
Identity Management and Continuous Risk Assessment solutions. With its roots strongly
entrenchaed in identifying business risks across industries, it is in a unique position to
comprehend and identify inherent security gaps in an organizations infrastructure
framework and build and deploy innovative solutions/products to significantly mitigate
potential risks.
White Paper 06
www.arconnet.com