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?