Next generation remote networks aruba instant gokul rajagopalan
Mitigating the Insider Threat in Enterprise Networks S. Raj Rajagopalan Telcordia Technologies OASIS...
-
Upload
hannah-morgan -
Category
Documents
-
view
214 -
download
0
Transcript of Mitigating the Insider Threat in Enterprise Networks S. Raj Rajagopalan Telcordia Technologies OASIS...
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.