MITHRIL Adaptable Security for Survivability in Collaborative Computing

MITHRIL: Adaptable Security for Survivability in Collaborative Computing Sites Jim Basney, Patrick Flanigan, Himanshu Khurana, Joe Muggli, Meenal Pant, Adam Slagell, Von Welch National Center for Supercomputing Applications

Mithril § ONR-funded project under the National Center for Advaced Secure Systems Research § Mithril is a fictional material from J. R. R. Tolkien's universe, Middle-earth. It is a precious silvery metal, stronger than steel but much lighter in weight. (from Wikipedia) § A mithril coat of mail provides strong protection but is light and flexible § Our project will develop adaptable site security mechanisms that maintain usability

Mithril Goals § Adaptable Security for Survivability • Maintain high-level of openness and usability during normal operation • Allow response by applying security counter-measures and adjusting level of service during heavy attack § In Collaborative Computing Sites • Examples: NRL Center for Computational Science (CCS), NSF centers (NCSA, SDSC, PSC, NCAR), DOE Labs (NERSC, LBNL)

Collaborative Computing Sites § Support large, geographically distributed user communities • NCSA has 7000+ users from all over the world § Enable pooling of distributed resources • Intra and inter site • Single sign-on • Open networks § Provide a variety of general-purpose and specialized computing services

Motivator: Cyber Attacks of 2004 § Series of attacks against a number of sites - DOE, NSF, commercial, Universities § Attacker compromised a large number of hosts and installed SSH Trojans to collect usernames and passwords • Was careful not to otherwise disturb system so when undetected to a large degree § Used usernames and password to gain access to NCSA and other places, then other vulnerabilities to escalate privileges, install SSH trojan and repeat

Problem Statement § Site security mechanisms cannot change quickly to respond to emerging threats • Handle a small number of compromised accounts as a matter of course § Leads to service interruptions when serious attacks occur • Only defense is to take yourself of the network § Need mechanisms for adaptable site security

Challenges § Must maintain usability and openness § Off-site users • Vulnerabilities outside local site control § Leading-edge Research systems • Heterogeneity • Special-purpose platforms • Obstacles to software roll-out

Bridging the Gap Enterprise Security Management Systems Computer Science Research

Existing Work § Survivable systems research: SABER, Willow, SITAR, APOD • How can we bring survivability research into production? § Enterprise Security Management Systems • SSH Tectia: Enterprise management of SSH services • Doesn’t support unique site platforms (ex. IA 64 Linux) • Can we replicate this functionality for Open. SSH? • Arc. Sight ESM, Symantec ESM, Lightning Console, etc. • Are these systems applicable to our environments? • cf. Engine § Alert Correlation: TIAA § Intrusion Detection Systems: Prelude, Snort, Tripwire, etc. • Mithril should integrate with these as possible • Previous prelude automatic intrusion response work

Mithril Organization § SSH-based Key Management • Lead: Jim Basney § Adaptable IDS for Survivability • Lead: Von Welch § Secure Email for Incident Response prevention • Lead: Himanshu Khurana detection SURVIVABILITY response

Mithril Technology Choices § Prelude IDS • Open source, extensible • Extend with applied survivability and alert correlation research § SSH • Ubiquitous • Extend to add key management § SELS • Prior NCASSR work in secure group email communication

Mithril Architecture

Managing Remote Login Services § Remote login is arguably the most essential service provided by collaborative computing sites today § SSH is very configurable • Wide variety of authentication mechanisms • Many options for security restrictions § SSH can be an effective site access control point § Plans: • Develop an Open. SSH key management subsystem and ssh-remote-agent • Develop management system for Kerberos Telnet

SSH Key Management § SSH public key authentication provides single signon § SSH keys can be difficult to manage • Keys scattered onto multiple machines • Unencrypted or encrypted with poor passwords • No lifetime restrictions, no revocation capability § Open. SSH credential management service • Private keys generated and stored on locked-down key server, public keys distributed • Authentication uses ssh-agent protocol link to key server that retains private key • Provides revocation capabilities

SSH Key Management SSH Key Server • Maintains private RSA keys Client Authenticates via site mechanisms e. g. Kerberos, OTP Public Key Distribution Client accesses private RSA key via ssh-agent RSA-authenticated access Compute Resource

Adaptability: OTP Deployment § One Time Password tokens are costly and inconvenient for routine use by NCSA users § In case of sustained, large-scale attack, transition resources to high-security mode • Update SSH configurations to temporarily require OTP hardware token authentication • Distribute tokens to priority users via overnight mail § Keep serving small number of high-priority users during intrusion response / clean-up

Adaptable/Reactive IDS § Match monitoring precision with current threat level • Host-based IDS competes for cycles with high performance computing jobs § Detect violations of current policy • Sites like NCSA are flooded with scans, brute-force attacks, buffer overflow attempts, etc. • Apply correlation of events to detect the “real attackers” and filter out the script kiddies § Activate OTP-only policy -> kill non-OTP processes

Secure Email Services § Needed for intrusion detection and coordinating intrusion response • Monitoring and IDS processes send alerts via email • Need for system administrators to communicate securely (signed, encrypted) across-site when under ongoing attack • Need intrusion tolerant system so attackers can’t eavesdrop § SELS: Secure Email List Services • Solution developed under NCASSR program with deployability and usability in mind • Provide encryption and signature support for Mailing Lists • Use GPG at client, Mailman plug-in at List Server

SELS § SELS provides intrusion tolerance by using proxy encryption techniques • Enables the List Server to transform encrypted messages exchanged between list subscribers without requiring access to the message contents. § We have developed proxy encryption techniques using the El Gamal crypto-system that allow us use standard El. Gamal public/private keys and encryption/decryption algorithms. § Integrated with GPG toolkit to facilitate client deployment. § Mailman plug-in on server side

Thank you § Questions? § Email: vwelch@ncsa. uiuc. edu § Project URL: http: //security. ncsa. uiuc. edu/research/mithril/ § Work funded by ONR as part of NCASSR § http: //www. ncassr. org • This material is based upon work supported by the Office of Naval Research under Award No. N 00014 -04 -1 -0562 • Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the author(s) and do not necessarily reflect the views of the Office of Naval Research.