Overview of local security issues in Campus Grid environments Bruce Beckles University of Cambridge Computing Service Overview • Organisational issues • Authentication • Authorisation • Auditing (not Accounting) – Rhys will talk about Accounting next • Control access to the Campus Grid • Workstation issues: – Securing workstations (“nodes”) – Control the local environment • User issues Organisational issues • Need dedicated staff responsible for security of campus grid: – Must have or develop expertise in “grid security” – very much a moving target! – May be part of local IT security team – …If not, must work closely with IT security team • Automate, automate, automate!: – Automate deployment and monitoring procedures – …but periodically perform manual checks as well • Decide a security policy: – Prevention or Punishment? – What information must be collected to enforce / support this policy? (Auditing) Authentication • Why do we need authentication?: – Without it we have no idea who is using the Campus Grid – No way to tell authorised use from illegitimate use • Use your existing authentication infrastructure: – Kerberos, Active Directory, NIS, etc – Users are already familiar with it – Administration is handled by existing procedures and personnel • Avoid digital certificates and GSI. If you must use them: – Find (or create) a usable implementation – Make it completely transparent to users – Remember it doesn’t scale well Authorisation • Needs low administrative overhead: – Develop quick, simple, usable procedures – Build in error checking! • Must scale well: – Centralised database with secondary servers – …Or distribute database automatically • Balance central control vs. delegated control: – Central control: • • • • Clear where to apply for access Tight control over who grants access Easier to audit handling of access requests Less vulnerable to “persuasion” – Delegated control: • Divisions more likely to know individual users • …but easier for user to “persuade” them to grant access • Periodically audit authorisation database Auditing (1) • Absolutely vital, but frequently overlooked • Determine what you need to audit to support your security policy • Analyse usage logs so you have some idea of what is “normal” for your Campus Grid • Analyse network traffic logs so you have some idea of what is “normal” for your network • Consider using an Intrusion Detection System (IDS) only if security staff already use one Auditing (2) • Current grid software not very good at it …but use whatever it gives you (usage logs, etc) • Use system’s auditing facilities wherever possible – Login records, process accounting (psacct), syslog, Windows Event Logs, etc. • Do not store audit trails on the local machine! • Consider keeping copies of users’ executables (but if you do this, make sure you let the users know) Control Access • Tightly control access points: – – – – As few as possible …but balance need for scalability Ideally centralised Must be under your control • Restrict user access to underlying grid middleware as much as possible • Develop usable front-ends for users: – Web portals – Interfaces to familiar queuing systems – etc Secure the workstation • Secure each individual workstation / “node” in Campus Grid: – A single insecure workstation can compromise the entire Campus Grid – So keep all software on workstations up to date! – Centrally manage workstations – Keep network services to a minimum – Tightly control software installed – Consider using sensible local firewalls (iptables, Windows Firewall, etc) with simple rule sets • Plan for a different attack profile: – A grid will attract different types of attacks (and attackers) than a managed workstation service – If your grid consists of managed workstations, then expect to get both types of attacks Control the local environment • Control local environment on workstation where jobs will run: – Restrict privileges of job processes (privilege separation, ACLs, etc) – Control network access if possible / practical – Sanitise environment before and after jobs run: • Start job with a clean environment • Delete temporary files, job’s data files, etc • Kill any extraneous processes – Run jobs in a sandbox / “virtual machine” if possible (but consider performance implications) – Make local environment uniform across each workstation OS User Issues • No users, no problem!: – So start small, with known, trusted users (of course, this doesn’t scale) – Then expand your user base gradually – Try to avoid a “our campus grid is open to all” policy • ‘Vet’ your users: – Ask for sample jobs and inspect them personally – Initially constrain new users to a small part of the Campus Grid – ‘Paranoia’: only allow them to run code you have approved • Know your users: – Try to get to know your users (not personally, although that helps), but their patterns of behaviour – How much do you trust them? Questions?