 |
Thomas Myer (tom@tripledogdaremedia.com)
Principal, Triple Dog Dare Media
13 May 2004
The GGF Security area has its hands full with
requirements.
In past installments
of this column, I've introduced you to the Global Grid Forum (GGF) --
who they are, what they're up to, where to read important documents,
how to get involved -- and to the Data and Architecture areas of the
GGF. Recently, I covered OGSA (Open Grid Services Architecture) and
OGSI (Open Grid Services Infrastructure) as well as some proposed
changes to WSRF.
I've said it before, but I'll say it again: things are
changing fast in the grid community. So fast, in fact, that it's
sometimes a challenge to keep up with it. It's definitely a developing
story. With that in mind, let's get on with the current focus: security.
So what's the big
deal with security?
We live in an interesting society -- one that is at once fairly open
and increasingly less secure. Our communication networks connect
millions of systems and billions of individuals on the planet. These
myriad systems, and the data they contain, present juicy targets for
those who want to steal, damage, corrupt, or otherwise gain unlawful
access to those systems.
When it comes to computational grids, some old challenges that
have always existed in the realm of computing security still remain.
Security is always a balance of vulnerabilities and threats. Without
both sides of the equation, you don't have the correct picture.
- Vulnerabilities are weaknesses or flaws that allow
unauthorized users to gain access to the system or data. Every
operating system and piece of software on earth has vulnerabilities.
Some are obvious, others hard to find; some are catastrophic, others
trivial. Most vendors offer patches for their different systems, and a
good majority of them are security related.
- Threats are potential violations of security.
Hundreds, if not thousands, of threats can be enumerated for any given
vulnerability. Threats can come from viruses, worms, human interaction
with a TCP/IP protocol, and so on.
In the world of security, vulnerabilities become more acute if
credible threats exist to exploit them. For example, theoretically
speaking, having a wide-open Web server on your home network certainly
makes for a vulnerable system. However, if the LAN is self-enclosed
without an opening to the greater Internet, then there aren't that many
threats to it (apart from the ones mounted by you). However, connect
that LAN to the Internet via a wireless access point, and now you have
a different story. Anyone who can sniff out your wireless network can
now gain access to the Web server. The possibility is still remote, but
the threat is much larger.
Let's take a closer look at grids. Grids can be used to
harness computational horsepower, provide access to unified data, or
other intensive tasks. From a security manager's viewpoint, a corporate
grid represents a high-value target for anyone who would want to gain
unauthorized access. They need to be protected not only because they
are high-value assets representing lots of hardware and software, but
because they often serve a strategic function that's central to success.
At the same time, security managers understand that successful
security is about tradeoffs. Tighten security too much, and it'll
become harder for the R&D folks to share their findings with
Engineering. Make it too hard to share information, and pretty soon all
kinds of ad-hoc systems will start popping up that provide back doors
to the system. (Think about all those folks who installed desktop
modems to circumvent their network security only to leave their company
wide open to war dialers).
From a grid perspective, other challenges are involved with
running a secure ship:
- How do you administer the ultimate in heterogeneous
environments? In any particular grid, you will have a multitude of
hardware/OS configurations, potentially owned by different
corporations, probably in multiple countries, all providing resources
or horsepower to multiple communities of users, all of whom probably
have different behavior and task profiles.
- How do you deal with authorization and authentication? In
any given grid, you might have multiple layers of ownership. The
network is owned and managed by the organization. Individual machines
are also owned by the organization, but for practical purposes, are run
by the person assigned to it. Finally, tasks that are run on the grid
are owned by the task originator, but the task has to make its way
through the myriad possible authorization scenarios. On top of that,
the task originator might be a software process or intelligent agent,
not a human user.
- How do you express and transport security policies? What
language do you use to express a security policy? Once codified, how do
you disseminate this policy to the entire grid in such a manner that
all systems, users, and agents receive and understand the policy?
- Finally, how do you keep up with all the changes on a grid?
Users come and go, whether human or software. If a user is cut off from
the grid, what do you do with all the tasks that might exist that
originated with that user? Clear-cut answers might not be appropriate.
Let's say you decide to terminate all tasks when you terminate a user
account. Well, some users might have tasks that perform recurring
queries that speed up work in a particular department. Even if that
user is terminated, someone else in that department would likely find
those queries worth saving.
What the security
area of the GGF is up to
As you can tell, there are lots and lots of requirements needed to make
security work on a grid. The question then becomes, how is the Security
area of the GGF addressing these requirements?
One thing is certain: they can't rely on simplistic notions of
security. They need robust, flexible, and operational software. It has
to work in the real world, allow for all kinds of contingencies, but be
powerful enough to drive security throughout the grid.
You can't have a successful piece of operational software if
it's too complex. One of the big problems with extremely popular
PKI-based (Public Key Infrastructure) security is the complexity
involved. You have public and private keys, both of which need to be
managed; hierarchical levels of certificate authorities; and the
process by which senders encrypt and receivers decrypt information
before it can be shared. You might ask, "Why is it so popular?" The
answer is, it provides some pretty kick-butt security, regardless of
complexity.
Security
working/research groups
Here's a brief rundown of the GGF workgroups:
Authorization
Frameworks and Mechanisms WG (AuthZ-WG)
Current and future security requirements of grid systems call for
advanced, fine-grain, and flexible authorization mechanisms. This group
will define a conceptual grid authorization framework for grid
developers with the goal to provide a basis for the design of such grid
authorization systems. A main goal of this document is to provide for
the immediate needs in the area of authorization by categorizing
existing authorization modules and systems as a first step toward
standardization of interfaces among modules. Another important aim of
this work is to put existing services and modules in relation to newer
grid architectures currently under development. We will synchronize our
efforts with the work done by other groups in the security area,
specifically with S3A and OGSA-Sec.
Open Grid Services
Architecture Security Working Group (OGSA-SEC)
The purpose of the OGSA Security WG (OGSA-Sec) is to enumerate and
address the grid security requirements in the context of OGSA. Given
that OGSA leverages Web services, the OGSA security architecture will
leverage the Web services security foundations published in the
WS-Security specification and under the context of the Web Services
Security Roadmap published in April, 2002. OGSA-Sec will closely
monitor the related efforts in other standards bodies (for example,
OASIS); there is no intention of duplicating the efforts within other
standards bodies. The primary outcome of the OGSA Security WG will be
two documents: [1] "The Security Architecture for Open Grid Services":
This document will describe a security architecture intended to be
consistent with the security model currently being defined for the Web
services framework used to realize OGSA's service-oriented
architecture. [2] "OGSA Security Roadmap": This document is a roadmap
enumerating a set of proposed specifications to be defined in the
Global Grid Forum in order to ensure interoperable implementations of
the OGSA Security Architecture. This group will discuss topics related
primarily to the development of these two documents.
Certificate Authority
Operations Working Group (CAOPS-WG)
The purpose of the Certificate Authority Operations (CAOPS) Working
Group is to develop operational procedures and guidelines that
facilitate the use of X.509 and other technologies for cross-grid
authentication. By developing common practices, the group hopes to
facilitate mutually accepted authentication services. The GGF has
developed a model CP/CPS to be used by sites and virtual organizations
that will deploy a CA. The efforts of this working group will focus on
issues associated with deploying certificate authorities. The CAOPS WG
will not be working on user private key management.
OGSA Authorization
Working Group (OGSA-AUTHZ)
The objective of the OGSA Authorization WG is to define the
specifications needed to allow for basic interoperability and
pluggability of authorization components in the OGSA framework. A
number of authorization systems are emerging in the grid today (Akenti,
PERMIS, CAS, VOMS, Cardea, and so on), and these specifications will
allow the solutions to be interchangeably used with middleware that
requires authorization functionality.
Site Authentication,
Authorization, and Accounting Requirements RG (SA3-RG)
The purpose of this research group is to collect and codify the
requirements of existing grid resource sites with respect to the
acceptance of grid credentials for access to their services. Where
those requirements are nonuniform, or even mutually exclusive, the
group will strive to recommend hooks that grid toolkits or applications
should provide for the sites to insert their own implementations of
their requirements.
Authority Recognition
Research Group (ARRG-RG)
Trust between entities in many transactions is enabled by a separate
authority issuing assertions (for example, X.509 certificates, SAML
assertions, Kerberos tickets) regarding the identity, other
characteristics of the actors involved, or both.
The assertions issued by an authority must be recognized as
valid and appropriate to its requirements before a party will rely on
them. Whether or not an assertion from a particular authority is
appropriate will depend on a number of factors, including the
commitments the authority makes with respect to the assertion, the
liabilities the authority is willing to assume, and the obligations
assumed by the relying party if they use the assertion. Existing
mechanisms do not facilitate the dissemination of this information from
the authority to the relying party to enable an informed recognition
decision.
The Authority Recognition Research Group will explore the
potential for simple, inexpensive, semi-automatable mechanisms by which
a relying party will make the decision to recognize the assertions of
an authority. It is hoped that such mechanisms will simplify and enable
the establishment of trust between grid participants.
Summary
I've covered a lot of territory just now. If it seems that there is a
lot going on, that it's changing a lot, or that it's somewhat
confusing, then you'd be right on all counts.
Resources
- You can learn more about the GGF by going to http://www.ggf.org.
This site contains general information on the group, as well as links
to important documents and events (such as ongoing conferences). To see
all the research and working groups within each Area, go to GGF@work
and click the Area Overview.
- Another important site is GridForge, which is at http://forge.ggf.org.
If you have a need for more detail on what each of the working Areas is
up to, then sign up for a free account. Doing so will give you access
to a working drafts of specifications and other documents in each Area.
The site also contains forums and bug tracking tools for
developer/researcher collaboration.
- Take a look at all the projects going on the GGF Security
area at https://forge.gridforum.org/projects/sec.
- If you want to browse all the GGF working groups, go to http://www.ggf.org/L_WG/wg.htm.
- Ian Foster's paper on the "Anatomy of the Grid" at http://www.globus.org/research/papers/anatomy.pdf
is pretty much required reading, as is his paper on the "Physiology of
the Grid" at http://www.globus.org/research/papers/physiology.pdf.
About the
author
 Thomas Myer is
the founding principal of Triple Dog Dare Media, an Austin-TX based
firm that specializes in building Web services, XML, and database
applications. He can be reached at tom@tripledogdaremedia.com |
|
|
