Site Security in the Grid Era

1
Site Security in the Grid Era
meets
2
Outline

• Getting Back to basics
• How do we do site security now ?
• How does the Grid change things ?
• What do we need to do ?
• Conclusions

3
Principles

• Computers are tools for facilitating the science.
• HEP is an international collaborative endeavor,
  with a strong history of internationalism in the
  face of political strife.
• Owners are ultimately responsible for what is
  done with their machines.

4
Principals
It has to perform
It has to work!
Users
Developers

It has to KEEP working and performing
It has to do what I want
I have to be able to prove it
Owners
Operations Teams
Regulators
5
Why care about security ?

• Have to avoid the tragedy of the commons
• Need appropriate ways to grant priority and
  privacy
• Need appropriate controls on access
• Provide touchstones for recovery and
  investigation.
• Avoid visits from the Police and/or lawyers or
  from your funding sponsor

6
Why is security so frustrating ?

• The function of security software to deny
  unauthorized actions.
• Its a negative goal (and so often poorly tested)
• The more dangerous actions there are, the harder
  the problem (e.g. buggy code forces firewalls)
• Inevitably some allowed actions are frustrated
• Details matter
• I want my /dev/psychic !
• A single mistake can give away the store.

7
Security by Design

• Algorithms
• Protocols
• Implementations
• Operations
• Incident Response
• Yes, but most of all
• Avoid Complexity

8
Make it as simple as possible . but no
simpler.
IETF

• Systems need to be designed with security built
  in and not as an afterthought.
• Secure operations must be sufficiently tested
• User interfaces/interaction need to account for
  realistic behavior
• Errors have to be checked and should not give
  away the game
• Reality must be acknowledged.
• Wishful thinking doesnt make it so
• The fact that it hasnt happen doesnt mean it
  wont

9
What are the threats ?

• Automated attacks
• application holes
• authentication systems
• Someone gaming the system
• anonymizers (eg. SPAM)
• (attempts at) local optimization may congest the
  whole
• Targeted attacks

10
Computer Security Policy

• Risk management not elimination
• Balance components of prevention, response, and
  prosecution.
• Prevention is usual focus
• Response is labor intensive but viable
• Prosecution has not been widely successful to
  date
• Resilient to attack
• Agile in the face of change

11
What is the Grid ?

• At highest level, we are in the transition of
  computing from a service to a utility.
• Utilities are defined various ways, but one of
  the simplest is they are services one notices by
  their absence rather than their presence.
• A utility grid is a network of service providers
  each delivering interchangeable product.
• We want a computing grid of interoperable, if not
  interchangeable, services

12
What is new with the Grid ?

• Forces specification and standardization of
  service interfaces
• no one wants to learn N different ways to
  interact with a mass storage system
• Teaching programs to do so is REALLY a bummer
• Forces distribution of management and support.
• Previous ability to take locally optimal
  decisions is reduced.
• We are now responsible to each other more directly

13
Whats new with the Grid ? (2)

• Forces specification of service levels
• concept of working hours support is ambiguous
• partnership arrangements dont scale
• Pressure for global licenses and open code is
  even more intense
• Vendors would love to lock us into their access
  methods.
• Ability to distribute infrastructure to all
  collaborators is mandatory

14
Site Security and the Grid

• Sites become service providers
• Accelerator centers are not used to this role
• Refer to talk by John Gordon on the Multipurpose
  Center
• Outsourcing identification and authentication
• The usual concerns about managing an outsourced
  service.
• Question is not primarily one of trust but rather
  clarifying responsibilities and problem
  resolution methods
• No overarching organization to bear liability
• Not clear what jurisdictions apply (eg. Privacy,
  )

15
Identity Who are you ?

• Our (user)names are not sufficient.
• Who is John Galt ?
• Our identities are often complex contextual
  combinations of roles, identifiers, time.
• Current trend in the grid is for a single
  identity with minimal information, but this
  complicates the authorization issues.
• Which identity a person wants to assert often
  depends on what task s/he wants to perform.

16
AuthenticationWho are you THIS time ?

• You want to be assured that the person claiming
  to be X is the same person to whom identity X was
  issued.
• (What do you do about the cases where you want to
  have Y act on Xs behalf ?)
• All authentication is based on some secret the
  user has and (another ?) the server has.
• Guessing attacks are gaining on what the average
  human can remember. Parity is close.
• Token theft attacks are often easier than brute
  force.

17
Keeping the Secrets

• The protocol cant depend on being a secret
  itself.
• Exposure of secrets must be a survivable if
  painful - event
• Good systems have ways to rapidly and easily
  change the secrets
• Want the impedance to resetting the secrets to be
  low (so that they will be reset when they should
  be).

18
Authorization What can I do for you ?

• There are many tiers to the question ?
• What limits do you want to put on the transaction
  to protect yourself from errors ?
• What limits does your Organization want ?
• What limits does the Resource Owner want?
• What limits does the Resource maintainer want?

19
Auditing How can I prove who did it ?

• Why do you care ?
• Troubleshooting operations
• Resource accounting
• Inevitable cases of misuse
• Legal requirements

20
Error HandlingSo NOW what do I do?

• Many security systems fall back on weaker methods
  in case of error.
• Attackers know this (read Mitnicks book if
  youre curious) and exploit it.
• Failing to check return codes is THE most common
  programming security mistake.
• How do we deal with error handling on the Grid ?

21
Look at a System

• Current email situation is good example of what
  happens with a faulty system
• (Worked well until popular)
• Identity is fairly unique (user_at_f.q.d.n)
• Authentication is zero
• Authorization is an industry (SPAM filters,)
• System is currently so bad that what was nuisance
  threatens to disrupt work.
• Yet, the maillist is probably the most effective
  dynamic VO we currently have.

22
Putting it all together on the Grid

• Extended identities must be established
• Gridwide unique identity(ies)
• Replacing these should not be expensive
• Roles
• Scope of validity
• Authentication needs to indicate whos been
  persuaded and how convinced they are.
• This vouchsafe helps authorization tremendously
• This also indicates who is responsible for fraud

23
Putting it together (2)

• Authorization needs to be generalized so that
  arbitration can be carried out
• I (or my agent) ought not to have to present all
  my authorities to you to choose
• You should be able to request different or
  supplemental information.
• Logging has to be sufficient for debugging the
  system
• tie actions to processes/users

24
Issues

• Registration
• Method of identifying users and informing them of
  rights and responsibilities has to withstand
  legal review
• Firewalls
• Least labor intensive method of shielding
  unmanaged systems/software.
• Inconsistent application drives multiplexing onto
  common ports (everything over port 80 ?)
• Incident Handling
• Who is responsible ? To whom ? For what ? When ?

25
Issue Resolution

• In the past sites have made locally optimal
  decisions about security configuration
• Local obligations (legal and social)
• Time constraints
• Leveraging financial interests
• Personnel strengths and interests
• Grid will require coordination.
• How will this be done ?
• Requirements must be articulated, defended and
  distributed to the developers.

26
Example

• One current hot topic is method of authentication
• Private held keys
• Individual has sole control
• No enforcement of hygiene possible
• Server held keys
• Uniformly well defended service
• Attractive target holds many keys

27
How to resolve ?

• Focus on technical arguments has not been
  persuasive to proponents
• Letting the market decide leads to fracture.
• Restrict what can be done with Grid jobs ?
• Focus on responsibilities
• Authentication is persuading someone who you are.
• If theyre wrong, I lose time, reputation,
  money,
• Whoever authenticates is responsible for
  resolving reports of fraud.
• They can then determine the methods.

28
Beware Big Brother !

• The desires for universal identifiers facilitate
  universal tracking.
• Your wallet has many forms of currency. Some are
  anonymous (cash) and you usually have partitioned
  lines of credit (separate credit cards). You may
  well wish to have a wallet of identities.

29
Conclusions

• Were all in this together
• More closely coupled operations are necessary.
• Security will get harder.
• Internet continues to grow
• Attackers are getting better faster than
  applications are hardening
• Security is a process not a milestone
• Responsibilities have to be made clear
• Commitment and forum for resolving differences is
  essential.

30
Whos working on Security ?

• EDG and PPDG
• http//edms.cern.ch/document/340234
• http//www.ppdg.net/pa/ppdg-pa/siteaa/
• Educause and Internet2
• http//www.educause.edu/security/
• IETF
• http//www.ietf.org/html.charters/wg-dir.htmlSecu
  rity20Area
• NIST
• http//csrc.nist.gov/
• GGF
• http//www.gridforum.org/2_SEC/SEC.htm
• Web Services/OASIS
• http//www.oasis-open.org/
• Liberty Alliance
• http//www.projectliberty.org/