Mitigating the Insider Threat in Enterprise Networks

S. Raj RajagopalanTelcordia Technologies

OASIS PI Meeting, Santa Rosa, CA.

August 20, 2002

2August 20, 2002

Project Details

Title: Mitigating the Insider ThreatStart Date: June 10, 2002End Date: March 10, 2003 (Seedling Project)Agent: Tom Blake, AFRLKey Participants:

S. Raj RajagopalanRajesh TalpadePrasad RaoSuranjan Pramanik (SUNY – Buffalo)Allen McIntosh

3August 20, 2002

Real Examples of Insider Actions

Temporary and changing roles among consumersMany users are given temporary root access in enterprise

environmentsA user may create a backdoor while root.

Mis-configurations and operator errorsBuggy or runaway processes can over-consume CPU or memoryUser profiles may be set wrongly

Adversarial ActionsLeaving-soon users may leave “bombs” behindViruses & worms may generate traffic that swamp the network/serversCompromised users may be used to starve legitimate users by

flooding the system with resource requests.“Friendly Fire”

All the above dangers and more are multiplied by any cross-connections between administrative domains.

4August 20, 2002

An Administrator’s Nightmare

A large Enterprise Network with thousands of nodes, 100 thousands of users, tens of administrative domains.

Highly heterogeneous environmentA group of colluding insiders cause a combination of multiple resources

to be saturated Using viruses with internal mailing-lists to amplify this, they make trace-

back impossibleAdministrators discover that network resources have failed or are

thrashing – high apparent utilization but no real progress.No break-ins reported, every user is apparently legitimate.Only way to bring the network back to normal is to stop and restart,

causing great damage.

Is there a better way to deal with this problem?

5August 20, 2002

Fundamental Questions

For a large dynamic enterprise network, can we Keep the network in a “good” state with respect to resource usage at

all timesAllow legitimate users to access the resources they need without

excessive overheadCan we prevent resources from being stolen or taken over by

“suddenly” corrupted users? High-level Policy:

What policies are reasonable and effective?How do we balance monitoring with the need for control?

Defining Scenario:“My enterprise network resources are all stalled. What do I have to do

to bring it back to normal with minimal damage to existing work?”

6August 20, 2002

Why this is hard to do

Security mind-set is still perimeter-oriented.Networks are not instrumented for monitoring insiders.

Networking technology has blurred the boundary.Dynamic collaborations, VPNs etc. blur the distinction between “insider” and

“outsider.”User profiling is hard.

A legitimate user may “turn” at any time and bad actions may seem to be from legitimate users.

Internal users are also the owners.“False” positive problem has severe consequences (such as job loss).

More resources are available to insiders. Users/adversaries have access to lots of internal resources to launch an

attack such as mailing lists, DNS & NIS servers, new applications etc.Privacy concerns exist.

Users assume that they should be allowed all actions without monitoring after the initial authentication.

7August 20, 2002

Our Approach

Network-wide ResourcesAbstract resources: CPU, network bandwidth, disk, memory, …Users may be real users, applications, end-hosts.For every user and resource, the goal is to provide the user a minimum level

of resource if demanded and never more than a maximum level.A user’s resource usage is logged across the network.

Limit what any user can do in the networkWe do not try to discover if an insider is “bad.”Monitor and control access by all users to resources.

AssumptionsThe minimum and maximum are system parameters.We assume that there is enough resource to satisfy the minimum requirement

for the current set of admitted users.The policy set is assumed to be sufficient to keep the network in a good state.

How do we hope to deal with insider DoS attacks?Attackers cannot grab resources to a level that can cause system paralysis.This project will implement the first steps towards this goal.

8August 20, 2002

Policy-driven Resource Usage

Goal: Implement the stated high-level resource access policies automatically in a

dynamic network (to the best approximation possible).Policy specification

Policies are invariants that need to be maintained in a dynamic environment.Policy needs to be restricted by both computational feasibility and the power

of enforcement mechanismsWe will keep Policy Language specification informal until we have better idea

of feasibilityEnforcement tools

Users identified on network-wide basis using Kerberos tokens.Assemble tools for coarse monitoring and control of abstract resource usageCreate a central policy enforcement engine that implements network-wide

resource policies.

9August 20, 2002

Boolean vs Quantitative Policies

Boolean security policies (Allow/Deny) are well-studied Access control in operating systemsNetwork services security policy management in dynamic networksExamples:

“Managers can access the HR database server.” “Non-manager employees cannot access the HR database server.”

Quantitative security policies are not as well-studied (or harder)Examples:

“Managers can send/receive at least 10 Kbytes over an hour” “No Router link should be at more than 80% of capacity” “Users can get at least 1% CPU over a 10 minute period”

Quantitative policies are much harder [Cowan] “Resource management is a security attribute.”Getting telnet access is easier than getting a “good” telnet connection.Quantitative policies are needed for DoS mitigation but hard.But everyone wants them (even “ghettohackers”)!

Our larger goal is to find an incremental path of increasingly richer quantitative security policies that are enforceable automatically.

10August 20, 2002

Current Status

FreeBSD “client” Instrumented to use tokens from a Kerberos server (KDC). Kernel modifications for collect CPU and network utilization per

user in a vproc table. vproc used for controlling process scheduling (CPU) and access to

network buffers. vproc has hooks for incorporating other monitoring methods. A central policy engine manages resource usage by reading/writing

vproc data. Lots of Relevant work from OS and networking

Specific Examples1. Spatscheck and Petersen. 1999. Scout Operating System.2. Banga, Druschel, and Mogul. 1999. “Resource Containers.”3. Afek, Mansour, and Ostfeld. 1996. Phantom.

11August 20, 2002

Time Sequence Diagram for Client

user system vproc kdc PE cpu network

login getcred

getpolicy

create

add

use

update

send

renew

use

update

donice

subtract

logout senddestroy

start activity

                        

 

12August 20, 2002

Roadmap

Short Term“Client” instrumentation (done)Stub policy engine and server instrumentation Choose and incorporate existing work on process monitoring and controlAlgorithms for deciding “nice” actions on processes to control resource access. Issues: Correlating user data on clients and servers with least overhead.

03/03FreeBSD prototype that implements basic protections on CPU and network

bandwidth abuseLong Term

Policy Enforcement Policy language that is feasible to validate and enforce

“Fairness” Criteria for network-wide resource usageGeneralizations to other resources and enforcement points

Explore what resources need to be monitored. Correctness requirements for resource squelch.

Scalability issues: tradeoffs of control between local and central policy engines.

13August 20, 2002

Meta-approach

“Principle of Least work” Reuse existing work as much as possible. Allow for future plug-ins

for monitoring and control technologies.Least overhead for security always wins (sometimes, even at the cost

of useful features).Only the simplest designs are robust.

Low cost and aggravationMinimum changes to existing infrastructureNo change if possible to applications and servicesKeeping services up is very important

14August 20, 2002

Conclusions

Insider threats are a clear and present danger to the normal functioning of enterprise networks.

Tackling Insider threats can be tricky because of overhead and privacy concerns.

Our approach is to assume all insiders are corruptible or may be mis-configured. Instead we seek to manage resource usage so that no user can take over dangerous levels.

We take a network-wide view and use Kerberos credentials to reduce authentication overhead.

Current prototype is focused on managing CPU and bandwidth on DOS-like phenomena.

The goal is to construct a lightweight framework for network-wide monitoring and policy-based control that is easy to plug in to.

We also hope to raise interesting research questions in policy management and adequate monitoring in this project.