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 doesnt 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 systems 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, jobs 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 doesnt 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?