IT infrastructure layers requiring Privileged Identity ... · accounts in their IT environments and...

7
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

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