Overview of local security issues in Campus Grid

environments

Bruce BecklesUniversity 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?