MITHRIL: Adaptable Security for Survivability in Collaborative Computing Sites

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

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

3. 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)

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

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

6. 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 off of the network • Need mechanisms for adaptable site security

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

8. Bridging the Gap Computer Science Research Enterprise SecurityManagement Systems

9. 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. IA64 Linux) • Can we replicate this functionality for OpenSSH? • ArcSight ESM, Symantec ESM, Lightning Console, etc. • Are these systems applicable to our environments? • cfEngine • Alert Correlation: TIAA • Intrusion Detection Systems: Prelude, Snort, Tripwire, etc. • Mithril should integrate with these as possible • Previous prelude automatic intrusion response work

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

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

12. Mithril Architecture

13. 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 OpenSSH key management subsystem and ssh-remote-agent • Develop management system for Kerberos Telnet

14. SSH Key Management • SSH public key authentication provides single sign-on • SSH keys can be difficult to manage • Keys scattered onto multiple machines • Unencrypted or encrypted with poor passwords • No lifetime restrictions, no revocation capability • OpenSSH 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

15. 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 Compute Resource RSA-authenticated access

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

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

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

19. 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 ElGamal public/private keys and encryption/decryption algorithms. • Integrated with GPG toolkit to facilitate client deployment. • Mailman plug-in on server side

20. 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. N00014-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.