Professional Documents
Culture Documents
http://www.positif.org http://www.deserec.eu
The System Description Language (SDL) - user’s manual
Contents
1 Introduction 4
1 / 41
The System Description Language (SDL) - user’s manual
2 / 41
The System Description Language (SDL) - user’s manual
3 / 41
The System Description Language (SDL) - user’s manual
1 Introduction
SDL is a language defined to provide a format for description of networked ICT systems. Although SDL
attempts to be general and complete, its main purpose is to provide the data needed to perform various kind of
security analysis. For this reason some details (e.g. the MAC addresses) are optional and can be omitted if the
user creating the description thinks that they are irrelevant to the kind of analysis he wants to perform.
SDL is a user-friendly (although verbose) language, based on XML. This document provides the definition of
the language itself and gives instructions on how to use the schema checker (to verify the description correct-
ness) and the translator towards the internal format, which is based on CIM. The choice of a translation of the
SDL into CIM language was in fact made in order to adhere, at least at low level, to a well-known, standard
language. Programmer-level details about the checker, the translator and the internal format are given in a
separate document.
SDL is used to formally describe an ICT system. It can convey:
• the topology of the system, both physical (nodes and cables) and logical (such as that created by a VLAN);
• the network configuration and black-box functionality of each node (that is, the network services offered
and the applications supported);
• the security functionality of each node (that is, its capabilities, such as packet filtering, OS controls, or
application-level access controls).
2.1 Notation
The notation used in this manual to describe the SDL syntax is mostly taken from the ABNF.
The names in italic – such as Identifier or L3 interface – are either a datatype (defined in section 2) or a
generalized SDL element.
The cardinality of a syntax element is defined by the following notation:
minOcc * maxOcc
where minOcc and maxOcc are optional decimal values, used to require at least minOcc and at most maxOcc
occurrences of element. Default values are 0 and infinity so that *element allows any number, including zero,
1*element requires at least one, 3*3element allows exactly three and 1*2element allows one or two.
Optional parts are enclosed within square brackets:
[ element ]
2.2 Comments
Comments can be inserted in any place, can span multiple rows and follow the usual XML syntax, that is a
comment is any text inserted between the <!-- and --> tags, as in the following example:
4 / 41
The System Description Language (SDL) - user’s manual
2.3 Identifier
This is a case-sensitive string of characters, to create user-defined names that identify SDL elements. Any legal
Unicode character can be used1 , with the following exceptions:
• the single-quote (’) and double-quote (”) characters cannot be used because they are XML separators for
the attribute values.
It is also forbidden to use characters like tab, carriage return, and line feed, but the space character can be used.
2.4 String
This is a string of printable Unicode characters.
01:23:45:67:89:ab 01-23-45-67-89-ab
1080:0:0:0:0:800:0:417A/48
2.9 uint8
This datatype represents an unsigned 8-bit integer which can take only decimal values in the range 0. . . 255.
2.10 pint16
This datatype represents a positive 16-bit integer which can take only decimal values in the range 1. . . 65535.
2.11 pint32
This datatype represents a positive 32-bit integer which can take only decimal values in the range 1. . . 4294967295.
1
However, it is suggested to use only printable characters, to avoid problems with applications that display identifiers or request
user input to identify an element.
5 / 41
The System Description Language (SDL) - user’s manual
2.12 DateType
This datatype represents a calendar date according to the ISO 8601 standard, that is in the form YYYY-MM-DD
(e.g. 2005-12-15).
2.13 CapabilityType
This datatype represents the different security capabilities available for softwares. The allowed values are:
2.14 AccessType
This datatype enumerates the different ways available to the user to access a machine. The allowed values are:
2.15 DNSNameType
This datatype represent the human-readable address of a machine on a network, as requested to a DNS name-
server. It is expressed in the well-known hierarchical dotted notation for URL, like www.foobar.org.
2.16 portPosition
This datatype represents the position of a physical port on a network device. It is expressed in the form:
[N /M /]P
where N stands for linecard number, M stands for the slot number and P is the port number.
2.17 connectorType
This type represents the physical connector and can take only the following predefined values:
2.18 technologyType
This datatype represents the data link technology and can take only the following predefined values:
2.19 L1type
This datatype represents physical layer details for the technology used and can take only the following prede-
fined values:
6 / 41
The System Description Language (SDL) - user’s manual
2.20 L2protoType
This type represents a data link protocol and it can take only the following predefined values:
2.24 cpuType
This type represents the processor and can take only the following predefined values:
7 / 41
The System Description Language (SDL) - user’s manual
2.25 SensitivityType
This type represents the security sensitivity characteristics of an element, and can take only the predefined
values:
confidentiality integrity availability
2.26 ConnectionTechnologyType
The ConnectionTechnologyType type defines the particular kind of technology through which transmission
signals pass. The available values are:
Unknown Other Cat1 Cat2
Cat3 Cat4 Cat5 50-ohm Coaxial
75-ohm Coaxial 100-ohm Coaxial Fiber-optic UTP
STP Ribbon Cable Twinaxial Optical 9um
Optical 50um Optical 62.5um
8 / 41
The System Description Language (SDL) - user’s manual
2.27 ByteSizeType
This type defines the size (expressed in bytes) of a physical storage. It is expressed in the form:
N [B | KB | MB | GB | TB ]
where N stands for an integer number and B, KB, MB, GB or TB is the order of magnitude (bytes, kilobytes,
megabytes, gigabytes or terabytes).
2.28 Reference
This type is used to define a reference from an element to another element. The Reference data type is used as
the argument of the IdRef attributes found inside many SDL elements. It is a string, expressed in the form:
ID[.ID]*
where IDs are strings of the Identifier type. This is equivalent to the XPath query
*[..]/*[id="Identifier"]/*[id="Identifier"]/...
In this way it’s possible to have hierarchical references, using the “path” of the IdRef attributes of an element.
For example:
<network id="emptyNetwork">
<computer id="pc1">
<interface id="eth0" />
</computer>
<switch id="switch1">
<interface id="eth0" />
</switch>
<connection id="connection1">
<endpoint idRef="pc1.eth0"/>
<endpoint idRef="switch1.eth0"/>
</connection>
</network>
In this way the connection endpoints are indicated with a single, hierarchical idRef, and not with the old-style
<connection>
<endpoint elementId="pc1" interfaceId="eth0" />
<endpoint elementId="switch1" interfaceId="eth0" />
</connection>
It’s worth noting that the use of hierarchical references is only needed when referencing a sub-element contained
in another element (like an interface or a service). References to top-level elements (computer,
switch and so on) are unchanged.
In other words: the elements in the path are searched in the XML document, and are expressed as the minimum
subtree where the target can be found. This subtree is first searched in the element containing the reference. If
it can’t be found there, the same search is done in the upper-level element (the container), and so on, until the
desired element is found or no element can be found. In the latter case, the reference is a so-called “broken
reference”, not pointing to anything. This situation must be avoided.
9 / 41
The System Description Language (SDL) - user’s manual
parameters of a component to the complex components and the connections among them. These elements and
the attributes are used to define logical models for actual network systems. They represent the vocabulary of
the language. The grammar of SDL is established through the relations specified among the elements and the
attributes of the language.
In SDL there are network topology elements and elements that are part of the network topology elements
themselves or are used to express associations between the network elements or networks.
The network topology nodes have the following predefined names:
Most of the names are self-explanatory. In addition, unknown is an element not known to the user, while
other is an element known to the user but not supported by SDL.
The following predefined names are used to describe sub-element of the nodes (for example, a physical inter-
face) or to express associations between the nodes:
This is the root element of any description. Each description is composed by a main mandatory part, that has,
as root node, the network element, and some other optional parts (extensions); these optional parts are used
to explicitly describe details about the network physical environment or the security level associated to each
element in the description.
This is the root element of the core description: the network nodes and the links between them are children of the
network element. The id attribute uniquely identifies the network being described. The network element
is a node too: that means that a network may contain one or more other networks. A network (or subnetwork)
may have network interfaces (logical interfaces) representing the endpoints connecting the network with other
10 / 41
The System Description Language (SDL) - user’s manual
external networks or elements. A network can be empty, with no elements explicitly expressed other than the
virtual interfaces. Otherwise, the nodes inside a network can be expressed: in this case, the logical interfaces of
the network refer to real interfaces belonging to the border elements of the network, like a firewall or a router.
An example of a network named voidNetwork is given below:
<network id="emptyNetwork">
<interface id="virtualIF1" />
<interface id="virtualIF2" />
</network>
This is an empty network: only its logical interfaces, which connect the network with the rest of the world, are
expressed.
An example of explicitly expressed virtual interfaces:
<network id="realNetwork">
<interface id="virtualIF1">
<actual_interface IdRef="firewall.eth1" />
</interface>
...
<firewall id="firewall">
<interface id="eth0" />
<interface id="eth1" />
</firewall>
...
</network>
This example shows a firewall, having its interface eth1 as border element of the inner network.
This element represents a black box to be used when the device type is unknown. This element is provided
as a catch-all solution to permit at least insertion of the device at the topological level, with a base network
configuration up to level 3.
This element represents a network device whose type is known to the user but it is not (currently) explicitly
supported by SDL. This element is provided as a catch-all solution to permit at least insertion of the device at
the topological level, with a base network configuration up to level 3.
11 / 41
The System Description Language (SDL) - user’s manual
This element represents a router, that is a network device that works at layer 3 (network layer) of the OSI model
and forwards data packets towards their destination, through the process known as routing.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This device has the optional management child element, representing the IP address used for network man-
agement purposes. Since this IP address is a characteristic of the device, and is not assigned to any interface, it
is a sub-element of the router itself.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
An example of a router named R1 is given below:
<router id="R1">
<management id="mng1">
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.1"/>
</management>
<interface id="eth0">
<address type="ipv4" netmask="255.255.0.0" value="10.1.0.1"/>
</interface>
<interface id="eth1">
<address type="ipv4" netmask="255.255.0.0" value="10.2.0.1"/>
</interface>
</router>
This element represents a network device that operates at layer 3 (the network layer) of the OSI model and
performs operations similar to routers. It is also referred to as a “layer 3 switch” to emphasize its speed, closer
to that of a layer-2 switch than that of a router. In other words, it is a sort of high-performance router optimized
for LAN or intranet use.
This element has the same syntax as the router element (see section 3.1.5), but for the tag name (switch3
instead of router).
12 / 41
The System Description Language (SDL) - user’s manual
This element is used to represent a link-layer switch, that is a network device providing dedicated connections
for network nodes. Unlike hubs that broadcast packets to all ports, a switch provides dedicated bandwidth
between source and destination ports. So unlike a hub, a switch splits the network traffic and sends it to
different destinations rather than to all systems on the network. It operates at layer 2 (the data link layer) of the
OSI seven-level layer model.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This device has the optional management child element, representing the IP address used for network man-
agement purposes. Since this IP address is a characteristic of the device, and is not assigned to any interface, it
is a sub-element of the switch itself.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This element represents a device that allows network nodes to communicate with each other, making them act
as a single segment. It works at layer 1 (physical layer) of the OSI network model, repeating the signal that
comes into one port out each of the other ports. It has two or more interfaces. In hubs, when a bit arrives from
one interface, the hub simply re-creates the bit, boosts its energy strength and transmits the bit onto all the other
interfaces. Thus, in hubs the bandwidth is shared between all the connected devices.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
13 / 41
The System Description Language (SDL) - user’s manual
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This element represents a device that connects multiple network segments at the data link layer.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
Besides its unique identifier, a bridge must have at least two network interfaces, configured at most at the
data level.
<repeater id="Identifier">
2*L1 interface
</repeater>
This element represents a network device that works at OSI layer 1 (the physical layer) and amplifies or regen-
erates the digital signals while transporting them between its interfaces.
Besides its unique identifier, a repeater must have exactly two network interfaces, configured only at the
physical level.
This element represents an autonomous computing device capable to communicate with other network devices.
It is used to represent both workstations and servers.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This element contains the sub-elements os, to indicate the operating system (more information on this topic in
section 3.2.6), and service, to list the network application services provided by this device (more information
on this topic in section 3.2.10).
The sub-element localStorage specifies physical storages, like hard disks, installed on the system. More
information about the localStorage element can be found in section 3.2.9.
14 / 41
The System Description Language (SDL) - user’s manual
The sub-element cpu specifies the hardware platform and it takes one of the predefined values specified in
section 2.24. This element has the frequency attribute, whose value is an integer specifying the processor’s
clock speed in MHz.
An example of a wireless node named station1 is given below:
<computer id="station1">
<interface id="ath0" technology="Wireless LAN" protocol="802.11g">
<address type="ipv4" value="10.0.0.2"/>
<address type="hw" value="00:11:11:11:11:22"/>
</interface>
</computer>
This element represents a Network Attached Storage (NAS), a system used to store and share data over the
network.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This element contains the sub-elements os, to indicate the operating system (more information on this topic in
section 3.2.6), and service, to list the network application services provided by this device (more information
on this topic in section 3.2.10).
The sub-element localStorage specifies physical storages, like hard disks, installed on the system. More
information about the localStorage element can be found in section 3.2.9.
The sub-element cpu specifies the hardware platform and it takes one of the predefined values specified in
section 2.24. This element has the frequency attribute, whose value is an integer specifying the processor’s
clock speed in MHz.
This element represents a dedicated network device whose main purpose is to filter the traffic between different
trust domains.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
15 / 41
The System Description Language (SDL) - user’s manual
<printer id="Identifier">
*access
L3 interface
*os
*service
</printer>
<gateway id="Identifier">
*access
1*L3 interface
*os
*service
</gateway>
This element represents a network device performing some sort of protocol transformation to/from another
network that uses different protocols. It works at OSI layers 4 to 7.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This is a dummy element used to model the access points to other (external) networks. Besides its unique iden-
tifier, a networkAccessPoint must contain exactly one interface, configured at most at the network
level; this is used to model the entry point to the linked network.
Here is an example of an access point (of the network being currently described) towards an external network
named Internet, which provides an interface (named rl0) with the IP address 192.168.1.24:
<networkAccessPoint id="Internet">
<interface id="rl0">
<address type="ipv4" netmask="255.255.255.255" value="192.168.1.24"/>
</interface>
</networkAccessPoint>
Note that the link between the router of the network being described and the access point of the linked network
is given by a connection SDL element (not present in the example).
16 / 41
The System Description Language (SDL) - user’s manual
This element represents a wireless LAN Access Point (AP) which is compliant with the 802.11 specifications.
An AP manages a cell of 802.11 stations, forwarding traffic between them and to/from the rest of the LAN. It
has at least one wireless interface. Typically, it has one Ethernet interface to connect to the wired network.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
The wirelessAccessPoint element has also an optional child element named management, represent-
ing the IP address used for network management purposes. Since this IP address is a characteristic of the
device, and is not assigned to any interface it is an element of the wirelessAccessPoint element itself.
An example of an AP named AP1 and having two interfaces is given below. The interface wlan0 is the wireless
interface compliant with the 802.11g specification while the interface eth0 is an Ethernet one.
<wirelessAccessPoint id="AP1">
<interface id="wlan0" technology="Wireless LAN" protocol="802.11g">
<address type="hw" value="00:11:11:11:11:11"/>
</interface>
<interface id="eth0" technology="Ethernet">
<address type="hw" value="00:22:22:58:28:EA"/>
</interface>
</wirelessAccessPoint>
• interface
• addr
• address
• dnsname
• os
• operatingSystem
• connection
17 / 41
The System Description Language (SDL) - user’s manual
• localStorage
• service
• protocol
• software
• distribution
• kernel
• module
• patch
Interfaces are physically distinguishable network adapters. For example normally a PC has just one interface,
while a router has multiple interfaces and so on. The interface element describes one physical network
interface of a node.
The optional attributes are:
• technology represents the data link (layer 2) technology and can only take the values in section 2.18;
• number represents the number of the physical port and follows the syntax in section 2.16;
• connector represents the physical connector and can only take the values in section 2.17;
• protocol represents the physical layer details and can take only the values in section 2.19.
• datalinkprotocol represents the data link protocol and can take only the values in section 2.20.
The interface element has three types of sub-elements: address, vlan interface and actual interface.
address is used to describe the layer 2 and 3 addresses (details in section 3.2.2).
vlan interface is used to specify the membership in a VLAN by pointing – through the idRef attribute
– to an external vlan element. The trunking attribute specifies whether the interface operates in trunking
mode: its default value is no.
actual interface is used, in virtual (logical) interfaces inside a network element, as a reference to a
real network interface on a device.
An example of an interface named eth0, assigned to the physical port number 1 and that supports the
Ethernet 10-100 BaseT technology is given below:
<interface id ="eth0" number="1" technology="Ethernet" protocol="10-100BaseT"
datalinkprotocol="Ethernet CSMA/CD">
. . .
</interface>
18 / 41
The System Description Language (SDL) - user’s manual
L1 interface type It is used to represent interfaces of physical-layer network devices (e.g. a hub or a repeater).
Thus, an interface of type L1 type does not contain any address element.
An interface of type L1 interface has the following syntax:
Note that the attribute datalinkprotocol is not present, unlike in interface elements of type L2 interface
and L3 interface.
L1V interface type It is the same as a L1 interface, but is used to represent the network interfaces of switches,
which can have a VLAN tag.
An interface of type L1 interface has the following syntax:
L2 interface type It is used to represent interfaces of data link-layer network devices (e.g. a switch or a
bridge).
This type of device has a MAC address but it does not have an IP address and consequently only the address
element of type hw can be specified.
An interface of type L2 interface has the following syntax:
L3 interface type It is used to represent interfaces of network-layer devices (e.g. a router or a computer).
This type of device has a MAC address and an IP address and consequently the address elements of type hw
and ipv4 are compulsory. The address element of type ipv6 is optional. The syntax of an interface of
type L3 interface is given below:
19 / 41
The System Description Language (SDL) - user’s manual
L3 logicalinterface type A virtual (logical) interface is like a L3 interface type, but is used only inside a
network element, simulating an endpoint of the generic network. The actual interface sub-element is
a reference to a real interface inside the network, and specifies that this given interface is on the border of the
network. The syntax of an interface of type L3 logicalinterface is given below:
Examples about the usage of virtual interfaces in a network element can be found in section 3.1.2.
Each network device connects to the network through a network interface card (NIC) that has a unique hardware
address. At the physical layer, these network devices communicate with each other through the hardware
addresses. IP, being a higher level protocol in the OSI model, communicates through a logical address, which
in this case, is the IP address.
The address SDL element represents a network address (e.g. MAC, IPv4 or IPv6). The element has a
mandatory attribute named type, which can take one of the following values:
• hw represents a hardware address (e.g. MAC address) and in this case the attribute value of the
address element must be of Ethernet address t datatype (defined in Section 2).
• ipv4 represents an IPv4 address and in this case the attribute value of the address element must
be of IPv4 addr t datatype (defined in 2) and it is mandatory to define also the netmask attribute of
IPv4 mask t datatype (defined in Section 2).
• ipv6 represents an IPv6 address and in this case the attribute value of the address element must be
of type IPv6 addr t.
If the type attribute is ipv4 or ipv6, the address element may include additional sub-elements of dnsname
type. Please refer to section 3.2.4 for the details about the dnsname element.
The example below illustrates the case of a computer with one Ethernet interface named eth0, with known
MAC, IPv4 address and DNS names:
20 / 41
The System Description Language (SDL) - user’s manual
<computer id="client2">
<interface id="eth0" technology="Ethernet">
<address type="hw" value="00:08:02:57:28:EA" />
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.254">
<dnsname>alpha.foobar.eu</dnsname>
<dnsname>omega.foobar.eu</dnsname>
</address>
</interface>
</computer>
The dnsname element represents one of the DNS names associated with a given IP address.
Important note: the addr element is deprecated. It is still present only for backward compatibility with
already existing SDL descriptions. Please use the address element (section 3.2.2) for any new SDL descrip-
tion.
The addr SDL element represents a network address (e.g. MAC, IPv4 or IPv6). The element has a mandatory
attribute named type, which can take one of the following values:
• hw represents a hardware address (e.g. MAC address) and in this case the content of the addr element
must be of Ethernet address t datatype (defined in Section 2).
• ipv4 represents an IPv4 address and in this case the content of the addr element must be of IPv4 addr t
datatype (defined in 2) and it is mandatory to define also the netmask attribute of IPv4 mask t datatype
(defined in Section 2).
• ipv6 represents an IPv6 address and in this case the content of the addr element must be of type
IPv6 addr t.
The example below illustrates the case of a computer with one Ethernet interface named eth0, with known
MAC and IPv4 addresses:
<computer id="client2">
<interface id="eth0" technology="Ethernet">
<addr type="hw">00:08:02:57:28:EA</addr>
<addr type="ipv4" netmask="255.255.255.0">192.168.1.254</addr>
</interface>
</computer>
The dnsname elements represent the different names, expressed as strings, assigned to a single machine on
the net. From the DNS name the IP address of a machine can be obtained through a query to a DNS server:
the DNS name unambiguously links a human-readable string to a specific IP address. Several different DNS
names can point to a single IP address: for example, a web server may have different virtual hosts bounded on
the same IP address and port.
21 / 41
The System Description Language (SDL) - user’s manual
The access element is used to specify which service must be used to manage the machine or deploy a
configuration file. Besides its unique identifier, this element has two other mandatory attributes:
• type, stating which protocol must be used to access the machine. For example, ssh for an access
through a secure shell, or human, for a machine which cannot be used remotely and requires the presence
of a human operator. A complete list of the protocols currently supported can be found in section 2.14;
• value, a free-form string indicating the URL, the generic address or the commands needed to access to
the machine.
This element is used to specify the operating systems that are running and/or installed on a network compo-
nent. It can be used also to specify a firmware for a special purpose device (e.g. a router). Thus, this
element is a child element of an active SDL element (e.g. computer, router a.s.o.). The SDL element
os references the installed/running operating system described by another SDL element, namely the element
operatingSystem. It has a mandatory attribute named idRef of type Reference, which is a reference to
an identifier (id) of an SDL element named operatingSystem. This means that the value of the idRef at-
tribute must match the value of the id attribute of an operatingSystem element that was already specified
(or is to be specified) in the network to be described. It has an optional attribute running, which can take the
values: yes, no. If no running attribute is specified, then the first encountered os is the running one. The
following is an example of a server with two installed operating systems named by MyOS1 and MyOS2:
<computer id="server1">
. . .
<os idRef="MyOS1"/> <!-- this is the running OS -->
<os idRef="MyOS2"/>
. . .
</computer>
<operatingSystem id="Identifier">
[ <product> OSproduct type | String </product> ]
[ <version> String </version> ]
*<kernel idRef="Reference">
*<distribution idRef="Reference">
*<patch idRef="Reference">
*<module idRef="Reference">
* [capability]
</operatingSystem>
This element describes an operating system (that can be referred to by the os sub-element in a network node).
Its sub-elements are:
• product represents the product name and usually takes one of the values in section 2.23 for the most
widely used operating system; additionally, a generic string can be used to describe the OS or firmware
of a special-purpose device (e.g. a router)
• kernel references an external kernel element (see section 3.2.14) that describes the kernel of this
operating system
22 / 41
The System Description Language (SDL) - user’s manual
• distribution references an external distribution element (see section 3.2.13) that describes a
specific operating system distribution
• patch references an external patch element (see section 3.2.16) that describes a patch applied to this
operating system
• module describes a functional enhancement module applied to the operating system, by referencing the
id of a global module element (see section 3.2.15)
• capability describes the security capabilities of the operating system, with the format specified in
section 3.2.19
Note that the version sub-element can be used not only to express the version number (e.g. 4.9) but also
to further refine the product type. For example, for WINNT we could use this field to specify whether it is
the workstation (expressed by the string WK) or server (expressed by the string SRV). Similarly, for Windows
2000, the version element could express the specific variant:
Professional Server AdvancedServer DatacenterServer
An example of an operating system Solaris 4.9, identified by the name mySolaris is given below:
<operatingSystem id="mySolaris">
<product>Solaris</product>
<version>4.9</version>
</operatingSystem>
This element describes a physical connection between two network elements. A connection is used to link two
interfaces. Thus, this element is used when two network elements must be connected, e.g. a switch and a
router as well as when it is necessary to link two networks, i.e. a network element (e.g. a router) and a
networkAccessPoint.
The endpoints of the connection are specified with the endpoint SDL element, which is a child element of the
connection SDL element. The endpoint sub-element has the mandatory attribute idRef, a (hierarchical)
reference to an interface contained in a network node.
The optional attribute type express, in the case of a wired connection, the link technology type, like Cat5,
100-ohm Coaxial or Fiber-optic. This attribute can’t apply to wireless connections, since they don’t
establish a physical link between two network interfaces.
The following example describes a connection between between the interface port01 of the switch S1 and
the interface eth0 of the server server1:
<switch id="switch1">
<interface id="port01">
...
</interface>
</switch>
<computer id="server1">
<interface id="eth0">
...
</interface>
</computer>
<connection id="connection1">
<endpoint idRef="switch1.port01" />
<endpoint idRef="server1.eth0" />
</connection>
23 / 41
The System Description Language (SDL) - user’s manual
The following is an example of a connection with an external network, i.e. between the interface eth1 of the
router R1 and the interface rl0 of an access point to the external network named Internet:
<router id="R1">
<interface id="eth1">
...
</interface>
</router>
<networkAccessPoint id="Internet">
<interface id="rl0">
...
</interface>
</networkAccessPoint>
<connection id="connection1">
<endpoint idRef="Internet.rl0" />
<endpoint idRef="R1.eth1" />
</connection>
This element represents a physical storage installed on a node, like an hard disk or a USB memory stick, and
therefore it is available only inside an active SDL element with storage (e.g. a computer or a NAS). The
localStorage element is an empty element, with the standard id attribute, plus three optional attributes:
• technology, which indicates the bus type for the storage, like IDE, SATA, USB, . . .
• removable, a flag indicating if the storage is meant to be a removable storage, like a memory stick.
<computer id="c1">
<interface id="eth1"/>
This element represents a network service provided by a node therefore it is available only inside an active SDL
element (e.g. a computer or a router).
The sub-elements of a service are:
• protocol represents the application protocol (e.g. HTTP). This is an empty element with only the
mandatory attribute idRef, which is a reference to the id of an external protocol element providing
unique and detailed protocol description.
24 / 41
The System Description Language (SDL) - user’s manual
• software represents the software element providing the service. This element has the mandatory
attribute idRef, which is a reference to the id of an external software element providing unique and
detailed software description.
• sap represents the service access point and has four attributes:
– addr is a mandatory attribute which specifies the addresses where the service is provided. The
value of this attribute is of type IPv4 addr or IPv6 addr, or a dnsname. The wildcard character
“* ” can be used to bind the service to all addresses of the device, both IPv4 and IPv6 types. The
notations “*IPv4” or “*IPv6” can be used to bind the service respectively to all IPv4 or IPv6
addresses of the device.
– transport is an optional attribute that represents the underlying transport protocol and it can
take only the values in section 2.21.
– port is an optional attribute (of type pint16) that represents the transport protocol port.
– session is an optional attribute, taking the value “SSL”. It is used to express that a certain service
is secured by means of SSL.
Note that when port and/or transport are unspecified they default to the standard values for the
application protocol (e.g. 80/tcp for HTTP).
The example below illustrates the case of a server providing the HTTP and FTP services.
<computer id="server1">
...
<service id="web server">
<protocol idRef="http"/>
<sap addr="192.168.1.17" transport="tcp" port="80"/>
<sap addr="192.168.1.17" transport="tcp" port="4444"/>
<software idRef="MyApache"/>
</service>
<service id="ftp server">
<protocol idRef="ftp"/>
<sap addr="*" transport="tcp" port="21"/>
<software idRef="Myftpd"/>
</service>
...
</computer>
It is worth mentioning that multiple instances of the protocol and sap elements are allowed.
<protocol id="Identifier">
<name> L7proto type </name>
[ <version> String </version> ]
</protocol>
This element defines an application protocol and, besides its id attribute, it has two sub-elements:
• name specifies the application protocol name and it can take only one of the values listed in section 2.22.
<protocol id="myhttp">
<name>http</name>
<version>1.1</version>
</protocol>
25 / 41
The System Description Language (SDL) - user’s manual
This element represents the software implementing a service. Its sub-elements are:
• patch describes a security patch applied to the software, by referencing the id of a global patch
element (see section 3.2.16)
• module describes a functional enhancement module applied to the software, by referencing the id of a
global module element (see section 3.2.15)
• date gives the release date of the software, with the format specified in section 2.12.
• capability gives the security capabilities of the software, with the format specified in section 3.2.19
The example below describes the standard version of the Apache software, compiled without any additional
security patch or functional module:
<software id="MyApache">
<name>Apache</name>
<version>1.3.34</version>
<maintainer>apache.org</maintainer>
</software>
This element is used to specify an operating system distribution (e.g. RedHat Enterprise Server 2.1). Apart
from the tag (distribution rather than software), it follows the syntax of the software element.
26 / 41
The System Description Language (SDL) - user’s manual
This element is used mainly to describe Linux kernels. Apart from the tag (kernel rather than software),
it follows the syntax of the software element.
This element is used mainly to describe modules that add some functionality to a software element, be that an
operating system or an application software. Apart from the tag (module rather than software), it follows
the syntax of the software element.
<patch id="Identifier">
<name>String</name>
*<version> String </version>
*<maintainer> String </maintainer>
*<description> String </description>
*<date> DateType </date>
*capability
</patch>
This element describes a patch that corrects an error or fixes a security vulnerability but don’t add a new
functionality. Apart from the tag (patch rather than software), it follows the syntax of the software
element.
This element specifies a group of active network nodes – such as a computers – that can act as replacement for
each other. The node acting as main system is identified by referencing its id in the activeSystem sub-
element. The replacement stand-by nodes are identified by referencing their id in one or more spareSystem
sub-elements.
27 / 41
The System Description Language (SDL) - user’s manual
This element contains all general information specific for a VLAN. Its id attribute is the unique user-assigned
VLAN identifier while the vlan id attribute represents the 802.1q VLAN id of the VLAN.
<capability type="CapabilityType"/>
This element contains the security-relevant capabilities supported by a given SDL element, e.g. by a software,
an operating system, a distribution, patch or a module. In particular, the capability element highlights
that a given software element has the potential to enforce a security policy of the same type. Note that in this
conceptual model, the configuration of security properties (e.g. the parameters of the SSL protocol) in the
system is not interpreted as system description, and thus it is not described by an SDL element.
The attribute type can take the values expressed in section 2.13. Their meanings are:
• channel protection: this tag is used to express that an SDL element (e.g. software) supports a
security protocol, such as SSL or IPsec, and thus can enforce a channel protection policy;
• authorization: this tag is used to express the ability of a software to grant authorization criteria,
based on privileges;
• authentication: this tag is used to state that a software can enforce policies regarding the authenti-
cation of a user on a given network system;
• filtering: this tag is used to express the packet filtering capability of an SDL element, such as
iptables;
• operational: this tag is used to express that a software can enforce operational policies, changing
the behavior of a network element when an event occurs.
sensitivities environment
The sub-elements inside extensions can have the following predefined values:
The following example shows the basic use of extensions in an SDL description:
28 / 41
The System Description Language (SDL) - user’s manual
The sensitivities extension has been added to permit an explicit definition of the security sensitivity
level of the elements expressed in an SDL network description.
The sensitivities element must contain at least one sensitivity element.
<sensitivity>
1*<feature type="SensitivityType" level="low"|"medium"|"high"/>
1*<target idRef="Reference/>
</sensitivity>
A sensitivity element is a collection of elements sharing the same security features and levels. Each
sensitivity element contains one or more feature sub-elements. The feature element is an empty
node, with two mandatory attributes:
• type, indicating which security attribute is specified. The type attribute can take the values specified
by the SensitivityType(2.25).
• level, defining the security level on a three-values scale: low, medium and high.
Each sensitivity element also contains a list of target elements. The target element is an empty
element indicating an element with the given security property. The element contains a reference to the id
attribute of another element
<sensitivities>
<sensitivity>
<feature type="availability" level="high"/>
<feature type="integrity" level="high"/>
<target idRef="SVNServer"/>
</sensitivity>
29 / 41
The System Description Language (SDL) - user’s manual
<sensitivity>
<feature type="confidentiality" level="low"/>
<target idRef="PC1"/>
<target idRef="PC2"/>
<target idRef="PC3"/>
</sensitivity>
</sensitivities>
In this example, two sensitivity groups are defined, each with its own security features and levels. Elements
with the same security sensitivity are referenced by the target elements.
The environment element is the main SDL extension concerning the physical environment containing a
network. This element has many sub-elements, each describing a specific feature.
power line is an element indicating that, in this particular environment, a power supplier is present. It has
the attribute id, which specifies a name for the power source, and two optional attributes:
• ups : this attributes, set to yes, indicates that this power supplier acts as an UPS (Uninterruptible Power
Source). That means that if its power sources die, this power line will keep on working. Default for this
attribute is no.
• default : if a power line is marked as “default”, it’s considered the power supplier for each contained
element (unless otherwise specified). If at least a power line is present in the main environment
element, one of these powerlines must be marked as default. In case of more power supplier, only one
default can be present.
A power line element can have sub-elements of source type. These empty elements have an attribute
idRef, referenced to another power supplier. The source element is used to simulate the connection to
another power supplier, acting as a source of power. If all the sources stop working, the power line dies, unless
the attribute ups is set to yes.
30 / 41
The System Description Language (SDL) - user’s manual
contained is an element used to specify which network elements are contained in a location. This element
has an attribute idRef, referencing a node in the main SDL description contained in this container. The
contained element may contain many optional ps elements(meaning “power source”): these sub-elements
indicate which power line the physical element is connected to. If ps is not specified, the power supplier for
this element is considered to be the default one. Instead, if a power supplier is indicated, it overrides the default
one. This means that, if an element is connected to the default power supplier and to an additional, redundant
one, both must be explicitly indicated.
area is an upper-level element, representing a block or a group of buildings, for example. It can only be
contained inside an environment element.
This element contains many sub-elements, like power line and contained. Their meaning is the same as
in the main environment element(see section 4.2). An area can also contain buildings. If it’s not required to
describe the whole environment, only floor, room or locker can be expressed inside the area element.
<building id="Identifier">
*power line
*contained
*floor
*room
*locker
</building>
building is an element representing a single building. This element contains many sub-elements, like
power line and contained. Their meaning is the same as in the main environment element(see
section 4.2). A building can also contain floor, room or locker elements.
<floor id="Identifier">
*power line
*contained
*room
*locker
</floor>
This element contains many sub-elements, like power line and contained. Their meaning is the same as
in the main environment element(see section 4.2). A floor can also contain room or locker elements.
31 / 41
The System Description Language (SDL) - user’s manual
<environment id="world">
<power_line id="ENEL" default="yes"/>
<power_line id="generator"/>
<building id="boella">
<room id="e-security">
<contained idRef="pc1"/>
<contained idRef="pc2"/>
<contained idRef="server1">
<ps idRef="generator"/>
</contained>
<locker id="rack1">
<power_line id="UPS" ups="yes">
<source idRef="generator"/>
</power_line>
<contained idRef="switch1">
<ps idRef="UPS"/>
</contained>
<contained idRef="switch2">
<ps idRef="UPS"/>
</contained>
</locker>
</room>
</building>
</environment>
32 / 41
The System Description Language (SDL) - user’s manual
33 / 41
The System Description Language (SDL) - user’s manual
34 / 41
The System Description Language (SDL) - user’s manual
<ps idRef="UPS"/>
</contained>
</locker>
</room>
</environment>
<sensitivities>
<sensitivity>
<feature type="integrity" level="low"/>
<target idRef="client1"/>
</sensitivity>
</sensitivities>
</sdl>
This network is located in a room with alarm and access control. The switch and router are contained inside
a locked rack. Server, switch and router are connected to an UPS. A low level of integrity is specified for the
client.
• the Java JDK (1.5+) or Java Runtime Environment (1.5+)2 . If no Java environment is installed, please
download the right version for your system and install it.
• the Xerces2 Java Parser (2.7.1+)3 , which is a fully compliant XML parser (Apache Xerces family) and
XML schema processor
• the Saxon84 XSLT and XQuery processor, that provides the libraries needed for SDL transformation.
6.1.1 Java
java -version
You can then read the running version from the output; for example:
6.1.2 Xerces2
Xerces2 is a fully compliant XML parser (Apache Xerces family) and a fully conforming XML Schema pro-
cessor needed to perform validation of SDL documents against the SDL schema.
If you don’t already have it, download the appropriate package for your system from the http://www.
apache.org/dist/xml/xerces-j/binaries/ page:
2
http://www.java.com
3
http://xml.apache.org/xerces2-j/index.html
4
http://saxon.sourceforge.net/
35 / 41
The System Description Language (SDL) - user’s manual
Windows installation Unzip the distribution package; a folder named xerces-2 9 0 is created (by default)
and we assume that the complete installation path be named:
C:\xml\xerces-2_9_0
• xercesSamples.jar
• xercesImpl.jar
• xml-apis.jar
Finally to complete the installation, set the XERCES environment variable to:
C:\xml\xerces-2_9_0\xercesSamples.jar;C:\xml\xerces-2_9_0\xercesImpl.jar
Unix installation Unpack the distribution package by using the following command:
A directory named xerces-2 9 0 is created (by default) under the installation directory and therefore we
assume that the complete installation path be named:
/usr/java/xerces-2_9_0
• xercesSamples.jar
• xercesImpl.jar
• xml-apis.jar
Finally to complete the installation, set the XERCES environment variable to:
"/usr/java/xerces-2_9_0/xercesSamples.jar":"/usr/java/xerces-2_9_0/xercesImpl.jar"
6.1.3 Saxon8
Saxon is an open-source XSLT and XQuery processor. This software provides the libraries needed to transform
SDL into the SDL/CIM format.
If you don’t already have it, download the package saxonb8-8j.zip from the http://prdownloads.
sourceforge.net/saxon/saxonb8-8j.zip page and then follow the installation instructions in the
next sections.
36 / 41
The System Description Language (SDL) - user’s manual
Windows installation To install saxon8 on Windows systems, just unzip the downloaded archive in the folder
where you want to install the package. Let us assume the folder be:
C:\xml\saxonb8-8j
Then, to complete the installation, set the SAXON environment variable to:
C:\xml\saxonb8-8j\saxon8.jar
Unix installation To install saxon8 on Unix systems, just unzip the downloaded archive in the directory
where you want to install the package. Let us assume the directory be:
/usr/java/saxonb8-8j
Finally to complete the installation, set the SAXON environment variable to:
/usr/java/saxonb8-8j/saxon8.jar
<network id="local_example"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="sdl.xsd">
For sake of simplicity, we suggest to create a dedicated directory that will be used to store both the SDL
description and the SDL XML Schema. Let us assume that the SDL description is named mynet.sdl, the
schema is named sdl.xsd and these two files are stored in the folder:
37 / 41
The System Description Language (SDL) - user’s manual
Open a text command window, change to the SDL folder and then use the following command to validate an
SDL description against the SDL schema:
If the SDL document is valid then no error will be produced and the checker will only show the time taken and
some statistics about the complexity of the description, as in the following output :
In case of errors, they will be listed each on separate a line prefixed with [Error], like in the following
example produced by a SDL document containing an invalid element (i.e. an hyperswitch):
A batch file sdl check.bat is also provided to avoid tedious command typing; it takes as parameter the
basename of the SDL file (that is, without the .sdl extension) and works as in the following example:
From the command line, change to the SDL directory and then use the following command to validate an SDL
description against the SDL schema:
38 / 41
The System Description Language (SDL) - user’s manual
If the SDL document is valid then no error will be produced and the checker will only show the time taken and
some statistics about the complexity of the description, as in the following output :
In case of errors, they will be listed each on separate a line prefixed with [Error], like in the following
example produced by a SDL document containing a wrong attribute (i.e. ifaceos):
A script sdl check is also provided to avoid tedious command typing; it takes as parameter the basename of
the SDL file (that is, without the .sdl extension) and works as in the following example:
basides the file to be transformed is named mynet.sdl and is stored in the same folder.
Figure 2: Transformation of network description from SDL to the internal format based on CIM (SDL/CIM)
39 / 41
The System Description Language (SDL) - user’s manual
Open a text command window, change to the SDL folder and then use the following command to translate an
SDL description to SDL/CIM:
where <sdl_file> is the name of the SDL file to be validated and <cim_file> is the name of the
SDL/CIM that will be created.
Back to our example, use the following command to transform a document file named mynet.sdl from SDL to
SDL/CIM:
If no errors are encountered during the transformation, then the output file mynet.cim is generated.
A batch file sdl2cim.bat is also provided to avoid tedious command typing; it takes as parameter the
basename of the SDL file (that is, without the .sdl extension) and works as in the following example:
From the command line, change to the SDL directory and then use the following command to translate an SDL
description to SDL/CIM:
where <sdl_file> is the name of the SDL file to be validated and <cim_file> is the name of the
SDL/CIM that will be created.
Back to our example, use the following command to transform a document file named mynet.sdl from SDL to
SDL/CIM:
If no errors are encountered during the transformation, then the output file mynet.cim is generated.
40 / 41
The System Description Language (SDL) - user’s manual
This manual has been written by Diana Berbecaru, Luca Dutto, Antonio Lioy, Massimiliano Pala and Paolo
Carlo Pomi of the Politecnico di Torino, Dip. di Automatica e Informatica.
However the SDL language is the joint effort of all the partners of the POSITIF project, that have contributed
to its birth and development.
The language has been further augmented and developed in the DESEREC project.
41 / 41