Previous section.
Technical Study: Security in Federated Naming
Technical Study: Security in Federated Naming
Copyright © 1997 The Open Group
Name Service Threats and Countermeasures
This chapter outlines the generic threats to IT systems and describes the
nature of a name service architecture to set the context for the
subsequent discussion of name service specific security concerns,
specific threats and appropriate countermeasures.
Generic Threats
The Distributed Security Framework (XDSF) categorises
the generic threats to IT systems as follows:
-
unauthorised modification
-
unauthorised disclosure
-
unauthorised use of resources
-
unauthorised denial of service
-
false repudiation.
These generic threats are realised by specific actions or sets of actions.
For example, eavesdropping on a communications channel may reveal user
passwords. Those passwords may
then be used to enable the user who eavesdropped to masquerade as other users.
The XDSF describes the many ways in which the generic threats above may be
realised and also describes generic measures that may be deployed to counter
these threats. This chapter identifies the threats that are specific to
a name service.
As well as threats arising from unauthorised operations threats also
arise from the irresponsible or malicious exercise of authorised
operations. It may not be possible to prevent threats arising from
authorised operations. however, by recording and analysing system
operations it may be possible to deter such behaviour, or react and
recover promptly to its occurrence.
Name Service Architecture
A name service is typically implemented as a client-server architecture,
as described in
Federated Naming Specification (XFN)
,
and may be considered to have the following aspects from a security
viewpoint:
-
Data Storage
The bindings between names and addresses and the attributes of objects
managed via the name service have to be stored. These are generally
stored in databases controlled by services that may be authorative or
non-authorative for a particular binding. Object attributes may
be stored by the name service or by the object itself.
An authorative service for a binding is a service that has management
responsibility for the creation, modification, and deletion of the
binding. An authorative service generally stores binding information
on a permanent basis. A non-authorative service does not have management
responsibility for a binding and is generally caching the information as
a result of a previous enquiry for performance purposes. That is, a
non-authorative service generally stores binding information on a
transient basis.
A name service
client may request that the binding information supplied is
authorative.
-
Communications
A name service uses communication services between its components and
possibly between client applications and its components. In the case of
communications between XFN clients and an XFN protocol exporter then an
RPC based protocol is specified.
-
Client and Administrative APIs
Access to name services are provided via interfaces that may be invoked
by client programs. Additionally, interfaces may be provided for the
administration of the name service.
Name Service Security Policy Concerns
Availability
Name services are a critical component of distributed systems providing
a service via which users and applications may locate objects with which
they require to interact. The availability and responsiveness of
name services therefore have a direct impact upon the overall usability
and responsiveness of a whole system. An attack on the availability of a
name service may be used as the basis of a denial of service attack on a
system or other individual services.
Integrity
The maintenance of the integrity of the binding of a name to an object is
a fundamental requirement of a naming service. The modification or
destruction of a binding between a name and an object may lead to
attacks on other system services through denial of service or through
masquerade. Denial of service can arise from an inability to locate a
service, masquerade attempts can occur through deliberate
modification of a binding or interference with the name resolution process
resulting in a caller interacting with a subverted object.
Associated with the integrity of the binding of a name to an object, a
security policy may require uniqueness of the binding of a
name to an object. A name should only refer to a unique object. If a
name does not refer to a unique object then any reliance upon that
binding, for example in support of authentication, is compromised.
The existence of multiple bindings to a single object may or may not be
a security concern.
This requirement for uniqueness may be extended in time to also cover
the reuse or re-assignment of names. This is of particular security
significance in the context of the historic analysis of security audit
trails for which the binding information needs to be preserved.
Note that a binding may actually reference multiple instances of
a single object, or a distributed object, for the purposes of
resilience.
Also note that in some namespaces the re-assignment of names is a fundamental
part of the operation of applications. For example, in the filesystem
namespace a wordprocessing
application frequently updates a document by creating a new object, a
file, renaming the original file as a backup and re-assigning the
document name to the new object. In this example the uniqueness in the binding
is between
a name and a user concept of a document. The mapping between the
document object and a filesystem object varies according to a policy
enforced by the appropriate application.
If the name server also supports the assignment of attributes to objects
then the integrity of that assignment may also be significant if the
attributes are used for security related purposes.
Confidentiality
In the context of a naming service, confidentiality is generally of lesser
importance than integrity and availability. It is of significance if
the revealing of the existence or location of objects or of attributes
assigned to objects is subject to control under the applicable
security policy.
An example may be an enterprise policy prohibiting disclosure of
information about the enterprise's user and service namespaces to
principals that are not part of the enterprise.
Accountability
A security policy is likely to require principals that modify binding
and attribute information to be held accountable for their actions.
This is often likely to particularly apply to the principals with
administrative authority over a name service. Accountability is
generally enforced through the use of a security audit service to record
security significant events and their subsequent analysis.
Data Store Threats
Destruction or corruption of a name server's database may be used to
attack the availability of a name service. That is, unauthorised
modification can lead to denial of service.
Unauthorised modification of a name server's database may be used to attack the
integrity of the name service.
Read access to a name server database may be used to attack the
confidentiality of name service information, that is unauthorised disclosure.
Threats and appropriate countermeasures include:
-
Back Door Interfaces
Operating system file system services, backup/restore facilities, and
low-level disc access facilities may be used to read or modify data
held on disc, potentially bypassing any application level controls on
such access.
Appropriate countermeasures depend upon the existence of suitable
operating system access controls, physical access controls and
administrative procedures in the processing environment supporting the
name service components.
Additionally, cryptographic techniques may be
used by the application to protect its data by sealing or signing or both the
data whilst stored within operating
system resources. The security of such techniques then depends upon the
protection provided to the cryptographic keys used to provide those services.
-
Reuse of Resources
Information can be disclosed or corrupted if the resource in which it
is stored is
reused for other purposes without the previous contents being purged.
Reliance is generally placed upon an operating system to purge memory
before allocation to a process. Responsibility rests with the
application developer to purge any memory under the direct control of
the application that is reused.
-
Physical Damage
A name service database may be destroyed or corrupted when the physical
media on which it is stored is damaged. This can arise from physical
damage or by electromagnetic means.
Appropriate programmatic countermeasures include the provision of
replicated name servers. Administrative countermeasures include
normal business continuity measures such as backup procedures and
service recovery plans. High availability servers could also be used.
-
Resource Overload
If a disc or other resource such as memory is exhausted then a name
server may not be able to store new bindings and object attributes and
may not be able to process requests for name resolution. This may arise
from excessive requests upon the name server itself or by the
overloading of another service that is competing for resources with the
name service.
Appropriate countermeasures include resource level monitoring and
administrative alarms.
Communication Service Threats
Interference with communication services offer the opportunity to affect
the availability, integrity and confidentiality of name services.
Threats and appropriate countermeasures include:
-
Masquerade of Communications Partner
Masquerading as a name server enables an attacker to supply
modified name and object bindings. Such an attack may subvert the name
service for a considerable period if such false information is cached by
a name service client.
Masquerading as an authorised client may enable an attacker to
create new, or modify or delete existing bindings of names and
attributes to objects.
These threats are countered by the use of appropriate authentication
exchanges between client and server components. These services may be
invoked via the GSS-API or other security protocol, for example SSL or
IPSEC.
-
Message Insertion/Modification
An attacker may insert or modify messages into the communication stream so that it
appears to a name service client that the name server has returned more
information than has actually been requested. Such additional
information may be cached by the name server client and subsequently
used in name resolution or attribute retrieval operations.
This may be countered by a client verifying that the information
returned is only that requested and by the use of cryptographic
techniques such as digital signatures for verifying the integrity
and origin of messages received.
-
Tampering with Communications Service Configuration
Access to name system services may be disrupted by modification of the
configuration of the communications services, at either the client or
server hosts. This may also be used to masquerade as a
communications partner by another host.
This may be countered by regularly monitoring the communications service
configuration on both server and client hosts or by signing the
configuration files themselves and verifying the signature whenever
accessed by the name service.
-
Eavesdropping on Communications Traffic
Eavesdropping on communications traffic may be used to obtain
unauthorised disclosure of name service information, such as object
attributes.
This may be countered by the enciphering of messages exchanged between
clients and servers or between servers themselves.
These services may be invoked via the GSS-API or other security protocols,
for example SSL or IPSEC.
-
Network Damage or Congestion
The availability of a name service may be impaired by overloading the
network with spurious traffic or physically disrupting the network.
Also an individual name server may be saturated with spurious client
requests so that it is unable to respond to valid client requests.
The saturation of a name server may be countered in some part by
applying quotas to the number of requests of specific types (some of which
take longer than others)
a server will concurrently service from a single client.
However, it is not possible to counter an overloading with spurious
connection requests.
-
Repudiation
The originator of a message that modifies a name to object binding, or
that modifies object attributes, may deny having sent it.
This may be countered by the use of message origin authentication based
on digital signatures and by security auditing of the use of binding
and attribute management functions.
Analysis of Name Service Requests
An analysis of name service requests may reveal information about a
client's activities, for example which trading partners it is
currently dealing with. This may be countered to some extent by "traffic
padding", that is, generating false requests to mask the real reqests.
Programming Interface Threats
Threats and appropriate countermeasures include:
-
Masquerade
A name service client can masquerade at a programmatic interface by
presenting a user identity that does not belong to its principal
(normally the user that invoked it).
This may be countered by requiring a client to authenticate itself, or
its ultimate principal, to the name service.
-
Exercise of Unauthorised Authority
A program may exercise authority for which it is not authorised by
attempting, under the identity of
its own principal, to use services that it is not authorised to use, or
attempting to access information that it is not authorised to access,
perhaps claiming privileges to which the client is not entitled.
This may be countered by the enforcement of an access control policy
based upon authentication and authorisation services.
-
Abuse of authorised access
Authorised access either via the normal name service client interfaces
or via name service administrative interfaces may be abused, for example
by performing actions irresponsibly.
Appropriate countermeasures rely upon
the definition of operating procedures for the use of the service and
the auditing of activity in support of making the initiators of actions
accountable for those actions.
-
Substitution or Modification of Name Service Programs
Name service programs may be substituted or modified to include trojan horses.
By this means Name service
requests and responses may then be modified.
This may be countered by the control and monitoring of the software
configuration of hosts.
-
Substitution or Modification of Dynamic Linked libraries
The substitution of dynamic linked libraries used to implement name
server specific context implementations may result in the invocation of
subverted name service clients or the interception and modification of
name service requests and responses.
This may be countered by the use of static linking or by
regular monitoring of host system configuration.
-
Incomplete Operations
The interruption of a binding or attribute management operation may
result in a partially completed update compromising the integrity of
that aspect of the name service. This threat may be particularly
significant when object attributes manipulated via a name service
interface are actually located with the object itself and managed by the
object management system.
An appropriate countermeasure is for an implementation to use
transaction processing techniques to ensure the atomicity of operations.
Generic Countermeasures
The following countermeasures do not relate to individual threats but
form part of an overall protective environment:
Access Control within Name Services
Name services are frequently integrated with other services, such as
a filesystem, directory service, etc. As such there is no single generic
access control policy applicable to all instances of a name service.
However, it is possible to discuss some commonly applicable policy types,
and these are addressed in this section.
Context Functions
These may be subject to an access control policy if they require name
resolution to be performed. See Name Resolution functions below.
Name Resolution Functions
Name resolution functions are often offered to anonymous principals.
For a significant set of name services, such as DNS, the identity of an
individual user is irrelevant for access control policy enforcement and
accountability is not a concern.
What is more likely to be relevant for access control purposes is the
enterprise or organisational
unit affiliation of a user. In this case the user principal does not
require to be authenticated to the name service but a client may have to
present a security attribute representing the enterprise or organisational unit.
The name server needs to be able to verify the authenticity of that
security attribute.
In some services, for example a file system, name resolution functions
such as listing the names within a context are subject to a similar access
control policy to the access control policy that applies to access to the
objects themselves.
Binding and Attribute Management Functions
In general a name service security policy is concerned with the
accountability of individual user principals for the use of functions
that create, modify, an destroy bindings and object attributes.
The support of such accountability requires the authentication of
individual user principals and the propagation of that information
between the name service components participating in the operation.
The access control policy enforced on binding and attribute management
may be based on a concept of the possession of authorities for the
execution of a subset of a name services functions or on the basis of
a relationship to the object, for example ownership or specifically
assigned access rights.
Possession of authority is frequently linked with administrative
responsibility for aspects of the name service and may be represented
by a capability or privilege mechanism.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.