Mitigating the Insider Threat in Enterprise Networks

1. August 20, 2002 Mitigating the Insider Threat in Enterprise Networks S. Raj Rajagopalan Telcordia Technologies OASIS PI Meeting, Santa Rosa, CA.

2. Project Details • Title: Mitigating the Insider Threat • Start Date: June 10, 2002 • End Date: March 10, 2003 (Seedling Project) • Agent: Tom Blake, AFRL • Key Participants: • S. Raj Rajagopalan • Rajesh Talpade • Prasad Rao • Suranjan Pramanik (SUNY – Buffalo) • Allen McIntosh

3. Real Examples of Insider Actions • Temporary and changing roles among consumers • Many users are given temporary root access in enterprise environments • A user may create a backdoor while root. • Mis-configurations and operator errors • Buggy or runaway processes can over-consume CPU or memory • User profiles may be set wrongly • Adversarial Actions • Leaving-soon users may leave “bombs” behind • Viruses & worms may generate traffic that swamp the network/servers • Compromised 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.

4. An Administrator’s Nightmare • A large Enterprise Network with thousands of nodes, 100 thousands of users, tens of administrative domains. • Highly heterogeneous environment • A 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 impossible • Administrators 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?

5. Fundamental Questions • For a large dynamic enterprise network, can we • Keep the network in a “good” state with respect to resource usage at all times • Allow legitimate users to access the resources they need without excessive overhead • Can 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?”

6. 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.

7. Our Approach • Network-wide Resources • Abstract 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 network • We do not try to discover if an insider is “bad.” • Monitor and control access by all users to resources. • Assumptions • The 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.

8. 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 mechanisms • We will keep Policy Language specification informal until we have better idea of feasibility • Enforcement tools • Users identified on network-wide basis using Kerberos tokens. • Assemble tools for coarse monitoring and control of abstract resourceusage • Create a central policy enforcement engine that implements network-wide resource policies.

9. Boolean vs Quantitative Policies • Boolean security policies (Allow/Deny) are well-studied • Access control in operating systems • Network services security policy management in dynamic networks • Examples: • “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.

10. 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 Examples • Spatscheck and Petersen. 1999. Scout Operating System. • Banga, Druschel, and Mogul. 1999. “Resource Containers.” • Afek, Mansour, and Ostfeld. 1996. Phantom.

11. Time Sequence Diagram for Client kdc cpu user system PE network vproc login getcred getpolicy create start activity add use update send renew donice use update subtract send logout destroy

12. Roadmap • Short Term • “Client” instrumentation (done) • Stub policy engine and server instrumentation • Choose and incorporate existing work on process monitoring and control • Algorithms for deciding “nice” actions on processes to control resource access. • Issues: Correlating user data on clients and servers with least overhead. • 03/03 • FreeBSD prototype that implements basic protections on CPU and network bandwidth abuse • Long Term • Policy Enforcement • Policy language that is feasible to validate and enforce • “Fairness” Criteria for network-wide resource usage • Generalizations 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.

13. 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 aggravation • Minimum changes to existing infrastructure • No change if possible to applications and services • Keeping services up is very important

14. 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.