||three notions of security
independent advice on tools and methods
|security as fence
||Security is a container. It keeps
the good stuff in and the bad stuff out.
|security as game
||Security is a battle between attackers and defenders.
Attackers try to navigating a complex (and changing) space, where each
place or state gives you access to certain other places or states, and
visibility of some further places or states not directly accessible.
Defenders try to detect intrusion, close off as many access points as possible,
set traps, and keep changing the configuration of the space. This is a
of conceiving security.
|security as landscape
||Security involves a complex terrain, where some points
are (or appear) more attractive or vulnerable than others - to a range
of diverse stakeholders. Security involves a balance of risk and reward.
These three notions of (demanding) security provide
an important counterweight to the three notions of (demanding)
change described elsewhere on this website.
IBM, Microsoft and Verisign have joined forces to develop and promote
a new architecture for web service security.
||to enable a variety of systems to securely interoperate
in a platform- and language-neutral manner
||to ensure the integrity, confidentiality and security of Web services
||defines a comprehensive Web service security model that supports, integrates
and unifies several popular security models, mechanisms, and technologies
(including both symmetric and public key technologies)
||describes a set of specifications and scenarios that show how these
specifications might be used together
||brings together formerly incompatible security technologies
||Security in a Web Services World: A Proposed Architecture
and Roadmap (Joint White Paper from IBM and Microsoft, April
|"A customer making an on-line purchase should not be
impacted by whether they are using a cell phone or a laptop computer, as
long as each device can securely express the proper identity."
||Thus it should be possible to specify security requirements and policies
(e.g. relating to identity) in a technology-neutral manner, and then implement
specific mechanisms on each platform (cell phone, laptop, and so on) that
demonstrably conform to the requirements and policies.
|"Integration through the abstractions of a single security
model enables organizations to use their existing investments in security
technologies while communicating with organizations using different technologies."
||This means establishing a common level of abstraction at which the
diversity and heterogeneity of rival security devices and mechanisms disappears.
While this represents an attractive simplification, it also potentially
represents a dangerous reduction in biodiversity. An attack that is designed
at the appropriate level of abstraction might be able to overcome any security
mechanism that conforms to the common model.
|"A security token is a representation of security-related
information (e.g. X.509 certificate, Kerberos tickets and authenticators,
mobile device security tokens from SIM cards, username, etc.)"
"The subject of the security token is a principal (e.g.
a person, an application or a business entity) about which the claims expressed
in the security token apply. Specifically, the subject, as the owner of
the security token possesses information necessary to prove ownership of
the security token."
|In the case of a SIM card, the subject of the security token seems
to be the SIM card or the mobile phone. A further step seems to be required
to associate this token with a human subscriber.
In many business and social contexts, a principal can delegate authority
to an agent, which may involve lending the necessary tokens. The model
describes various scenarios for the exchange of tokens. But there also
needs to be a higher level of abstraction at which these scenarios can
be understood as different ways of achieving the same underlying business
|"An intermediary may add headers, encrypt or decrypt
pieces of the message, or add additional security tokens. In such situations,
care should be taken so that alterations to the message do not invalidate
message integrity, violate the trust model, or destroy accountability."
||Who is the caretaker? Can this be independently verified?
||Web service security is only credible if it can be verified and tested
- and any breaches detected.
The architecture should also provide some basis for diagnosing any breach
of security - how did this intruder get in, how did this information leak
out - and planning appropriate corrective/preventative action.
||The general requirement on privacy is to define the ownership of information
and knowledge (including commercial, industrial and intellectual property),
and to constrain its storage, use and propagation.
While a web service may require some information to perform its proper
function, companies will be reluctant to send commercially sensitive or
valuable data to a third party web service without some guarantees that
these data will be safeguarded and not abused. In some cases, use of information
is permitted -- but only in anonymous or statistical form.
Special cases include digital rights management and escrow. For example,
a web service may perform some work on a document or software artefact,
and may therefore require special provision to penetrate any copy-protection
attached to the artefact, or to access the source code.
||Security always conflicts with other interests: change, innovation,
marketing, sales, surveillance.
||Many powerful players want to see security as a feature, or as a collection
of features. They claim that certain products are more secure than ever,
because these products have greater security features. But at the same
time, these products are more complex and have more vulnerabilities than
||Interference and interaction between security mechanisms. Adding
another layer of security doesn't always make you safer - in some cases,
unwanted interference between the layers can introduce gaping holes.
||All systems can be broken, given sufficient effort.
||Technical systems always have human weaknesses.
Pat Helland of Microsoft has proposed the Autonomous Computing model
as an application design pattern for cooperation between independent systems
that do not trust each other. It has two key notions.
||An independent computing environment that refuses to trust any outsiders
and maintains tight control over a set of mission critical data
||A computing component that helps prepare requests to submit to a fiefdom.
It operates exclusively on published (snapshot) reference data and single-user
Helland uses the autonomous computing model to explain many of the new
types of applications including offline apps, scalable web-farms, B2B apps,
content syndication and content aggregation. (How secure are these then?)
Roger Sessions of Object Watch has combined the Helland model with other
elements to produce an elaborate Fortress Model of computer security.
A fortress is a self-contained software system, contains business logic
(grunts) and private data (strongboxes), and is surrounded
by an unbreachable
wall. Communication with the outside world passes
through a drawbridge, and is controlled by guards and by
I have many reservations about these models. Here are three to be going
||Reliance on an absolute, binary notion of trust. Anything or anybody
inside the wall is trusted absolutely, anything or anybody outside the
wall is mistrusted.
||Reliance on simple topology. A wall creates a simple enclosed space,
a straightforward boundary between inside and outside.
||Reliance on technology. The fortress model depends on firewalls and
other security mechanisms.
||This is an extract from an article in the January
2002 issue of the CBDi Forum Journal.
Silver or Gold membership of the Forum is required for full access to journal
articles, but free Bronze membership will give you access to lots of other
resources, including recent news and product reviews.
While Microsoft has been developing the notion of autonomous
computing, IBM (along with a host of other companies doing related
research) has developed the notion of autonomic computing.
From a security point of view, the IBM model of autonomic computing
includes self-protection capabilities similar to the human immune system,
capable of recognizing foreign anomalies and sending agents to destroy
them. The goal is to survive the unpredictable.
||A new article on autonomic computing is planned for
the January 2003 issue of the CBDi Journal. Meanwhile you
may wish to read previous articles on security and related topics, including
a discussion of immune systems from January 2002. For journal articles,
plus news, analysis, product reviews, patterns and other materials, please
register at the CBDi Forum website
(Silver/Gold membership required for full access to articles, but free
Bronze membership will give you access to lots of other resources.)
Research - Computer Immune
This page last updated on December 18th, 2002
Copyright © 2001-2002 Veryard Projects Ltd
in asssociation with