201

IT Project Report
Xansa’s Network Architecture and IT
policy

Sanchit Sharma
1 |Page
Roll No.70
WMG 18B
 Table of Contents

Network Architecture in Xansa.................................................................5

Network Connectivity.................................................................................................5

Key Features...........................................................................................................6

Importance of Protocols.............................................................................................6

Protocols Used...........................................................................................................7

IPsec-Virtual Private Network Protocol....................................................................7

E-mail protocols......................................................................................................8

Advantages over POP..........................................................................................9

Connected and disconnected modes of operation...............................................9

TCP IP-Network Protocol.......................................................................................10

The Need for an Information Security Policy............................................................16

Introduction of Xansa’s Information Security policy.............................................17

Audit Policy........................................................................................................... 19

Introduction.......................................................................................................... 19

Internet Policy.....................................................................................................20

Email Policy.........................................................................................................26

2 |Page
 ACKNOWLEDGEMENT

It has been a great pleasure for me to work on this project. My sincere thanks goes out to Prof.
D. Punia for giving me an opportunity to work on this project which helped me to increase the
span of our knowledge and developed my thinking on more practical lines. I thank him for him
guidance and support throughout the time when I was working on this project.

3 |Page
4 |Page
 Network Architecture in Xansa

Network Connectivity

5 |Page
The Barclaycard Project team consists of users based in Steria Noida, Pune Offices
and Barclaycard Northampton Office. The users log onto BSP domain and then use
Citrix Farm to access various applications dependent on the user’s work profile. The
Citrix Farm resides within the Barclaycard estate and is managed by Barclaycard;
however the connectivity to the Citrix Farm is via the Steria WAN.

The connectivity route for Noida users is a link between Steria Noida and Steria
Birmingham and A mega stream link from Steria Birmingham to Barclaycard
Northampton.

The connectivity route for Pune users is a link between Steria Pune and Steria
Reading and thereafter from BT link to Steria Birmingham reroute to Barclaycard
Northampton.

Key Features

• Users in Barclaycard domain are connecting to (BSP) domain in Pune and

Noida.

• 80 users in Bites and 700 users in Barclaycard are providing support to the
development and production system for Barclays.

• Our DC & ADC's are IBHANAN and Inesh - Noida ; ISHAN & ISHWAR - Pune
managed by Server team of Noida and Pune.

• Local services running are Symantec End Point 11.0, WSUS, DHCP, DNS, print
server.

• Citrix Web Interface is used to access the client applications.

• All the applications required by users are published in Citrix.

• Local Printer configured on the user workstation will act as the printer for Citrix
application as well.

• Server details for Bites: Chandrak, chinmay, chitrani.

• Server details for BSP( Noida & Pune): Sonu, Sunil, Chahna, Chakori , Chanchal,
Chandi, Charita, Cheri.

Importance of Protocols
The protocols in human communication are separate rules about appearance,
speaking, listening and understanding. All these rules, also called protocols of

6 |Page
conversation, represent different layers of communication. They work together to
help people successfully communicate. The need for protocols also applies to network
devices. Computers have no way of learning protocols, so network engineers have
written rules for communication that must be strictly followed for successful host-to-
host communication. These rules apply to different layers of sophistication such as
which physical connections to use, how hosts listen, how to interrupt, how to say
good-bye, and in short how to communicate, what language to use and many others.
These rules, or protocols, that work together to ensure successful communication are
grouped into what is known as a protocol suite

Protocols Used
IPsec-Virtual Private Network Protocol
Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP)
communications by authenticating and encrypting each IP packet of a data stream.
IPsec also includes protocols for establishing mutual authentication between agents
at the beginning of the session and negotiation of cryptographic keys to be used
during the session. IPsec can be used to protect data flows between a pair of hosts
(e.g. computer users or servers), between a pair of security gateways (e.g. routers or
firewalls), or between a security gateway and a host.

IPsec is a dual mode, end-to-end, security scheme operating between the Internet
and Transport layers of the Internet Protocol Suite. It effectively acts as an additional,
optional "presentation layer" considering a transport level protocol the application.

Some other Internet security systems in widespread use, such as Secure Sockets
Layer (SSL), Transport Layer Security (TLS) and Secure Shell (SSH), operate in the
upper layers of these models. Hence, IPsec can be used for protecting any application
traffic across the Internet. Applications don't need to be specifically designed to use
IPsec. The use of TLS/SSL, on the other hand, must typically be incorporated into the
design of applications.

IPsec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP
was based on the SP3 protocol that was published by NIST, but designed by the
Secure Data Network System project of the National Security Agency (NSA).

IPsec is officially specified by the Internet Engineering Task Force (IETF) in a series of
Requests for Comment addressing various components and extensions, including the
official capitalization style of the term.

The point is that the internal network should be the sole trusted infrastructure that
can be protected at the highest level by IPSec VPN.

SSL VPN can provide the granular access control such that all users, both in and nut
of the physical office, and all connected foreign networks need explicit permission to
access any resource within the intranet. Technically speaking, IPSec VPN protects
network-to-network data communications between intra-networks across the
7 |Page
Internet, while SSL VPN protects intranet data communications from classified users,
extranets and the Internet.

The next logical trend is a solution that can effectively integrate various forms of
access so that all ingress points can he managed centrally, within the SSL VPN
infrastructure and outside the firewall and IPSec VPN management. By achieving such
a goal, companies can establish an enforceable policy-based access for all end-users
based on classifications--telecommuter, road warriors/traveling employees, partners,
vendors.

A comprehensive SSL VPN solution should support both end-user access as well as
remote IT administration. It should also support advanced remote-access methods
required by technical users, such as all out-of-band and power-control capabilities.

Companies should look for an SSL VPN that can significantly augment IPSec VPN to
improve mobility and to enhance internal security for remote access. As SSL VPNs
become mainstream in managing mobile business users accessing desktops and
applications, the evolutionary trend will demand secure remote administrative
access, in addition to end-user access.

E-mail protocols
The Internet Message Access Protocol (commonly known as IMAP, and previously
called Internet Mail Access Protocol, Interactive Mail Access Protocol (RFC 1064), and
Interim Mail Access Protocol[2]) is an Application Layer Internet protocol that allows
an e-mail client to access e-mail on a remote mail server. The current version, IMAP
version 4 revision 1 (IMAP4rev1), is defined by RFC 3501.

IMAP supports both on-line and off-line modes of operation. E-mail clients using IMAP
generally leave messages on the server until the user explicitly deletes them. This
and other characteristics of IMAP operation allow multiple clients to manage the same
mailbox. Most e-mail clients support IMAP in addition to POP to retrieve messages;
however, fewer email services support IMAP.[3] IMAP offers access to the mail store.
Clients may store local copies of the messages, but these are considered to be a
temporary cache.

Incoming e-mail messages are sent to an e-mail server that stores messages in the
recipient's email box. The user retrieves the messages with an e-mail client that uses
one of a number of e-mail retrieval protocols. Some clients and servers preferentially
use vendor-specific, proprietary protocols, but most support the Internet standard
protocols, SMTP for sending e-mail and POP and IMAP for retrieving e-mail, allowing
interoperability with other servers and clients. For example, Microsoft's Outlook client
uses a proprietary protocol to communicate with a Microsoft Exchange Server server
as does IBM's Notes client when communicating with a Domino server, but all of
these products also support POP, IMAP, and outgoing SMTP. Support for the Internet
standard protocols allows many e-mail clients such as Pegasus Mail or Mozilla

8 |Page
Thunderbird (see comparison of e-mail clients) to access these servers, and allows
the clients to be used with other servers (see list of mail servers).

Advantages over POP

Connected and disconnected modes of operation

When using POP, clients typically connect to the e-mail server briefly, only as long as
it takes to download new messages. When using IMAP4, clients often stay connected
as long as the user interface is active and download message content on demand. For
users with many or large messages, this IMAP4 usage pattern can result in faster
response times.

Multiple clients simultaneously connected to the same mailbox

The POP protocol requires the currently connected client to be the only client
connected to the mailbox. In contrast, the IMAP protocol specifically allows
simultaneous access by multiple clients and provides mechanisms for clients to
detect changes made to the mailbox by other, concurrently connected, clients.

Access to MIME message parts and partial fetch

Usually all Internet e-mail is transmitted in MIME format, allowing messages to have a
tree structure where the leaf nodes are any of a variety of single part content types
and the non-leaf nodes are any of a variety of multipart types. The IMAP4 protocol
allows clients to separately retrieve any of the individual MIME parts and also to
retrieve portions of either individual parts or the entire message. These mechanisms
allow clients to retrieve the text portion of a message without retrieving attached files
or to stream content as it is being fetched.

Message state information

Through the use of flags defined in the IMAP4 protocol, clients can keep track of
message state; for example, whether or not the message has been read, replied to,
or deleted. These flags are stored on the server, so different clients accessing the
same mailbox at different times can detect state changes made by other clients. POP
provides no mechanism for clients to store such state information on the server so if
a single user accesses a mailbox with two different POP clients, state information—
such as whether a message has been accessed—cannot be synchronized between
the clients. The IMAP4 protocol supports both pre-defined system flags and client
defined keywords. System flags indicate state information such as whether a
message has been read. Keywords, which are not supported by all IMAP servers,
allow messages to be given one or more tags whose meaning is up to the client.
Adding user created tags to messages is an operation supported by some web-based
email services, such as Gmail.

Multiple mailboxes on the server

9 |Page
IMAP4 clients can create, rename, and/or delete mailboxes (usually presented to the
user as folders) on the server, and move messages between mailboxes. Multiple
mailbox support also allows servers to provide access to shared and public folders.

Server-side searches

IMAP4 provides a mechanism for a client to ask the server to search for messages
meeting a variety of criteria. This mechanism avoids requiring clients to download
every message in the mailbox in order to perform these searches.

Built-in extension mechanism

Reflecting the experience of earlier Internet protocols, IMAP4 defines an explicit

mechanism by which it may be extended. Many extensions to the base protocol have
been proposed and are in common use. IMAP2bis did not have an extension
mechanism, and POP now has one defined by RFC 2449.

TCP IP-Network Protocol

Data transfer

There are a few key features that set TCP apart from User Datagram Protocol:
Ordered data transfer - the destination host rearranges according to sequence
number
Retransmission of lost packets - any cumulative stream not acknowledged is
retransmitted Discarding duplicate packets

Error-free data transfer

Flow control - limits the rate a sender transfers data to guarantee reliable delivery.
The receiver continually hints the sender on how much data can be received
(controlled by the sliding window). When the receiving host's buffer fills, the next
acknowledgment contains a 0 in the window size, to stop transfer and allow the data
in the buffer to be processed.

Reliable transmission

TCP uses a sequence number to identify each byte of data. The sequence number
identifies the order of the bytes sent from each computer so that the data can be
reconstructed in order, regardless of any fragmentation, disordering, or packet loss
that may occur during transmission. For every payload byte transmitted the sequence
number must be incremented. In the first two steps of the 3-way handshake, both
computers exchange an initial sequence number (ISN). This number can be arbitrary,
and should in fact be unpredictable to defend against TCP Sequence Prediction
Attacks.

10 | P a g e
TCP primarily uses a cumulative acknowledgment scheme, where the receiver sends
an acknowledgment signifying that the receiver has received all data preceding the
acknowledged sequence number. Essentially, the first byte in a segment's data field
is assigned a sequence number, which is inserted in the sequence number field, and
the receiver sends an acknowledgment specifying the sequence number of the next
byte they expect to receive. For example, if computer A sends 4 bytes with a
sequence number of 100 (conceptually, the four bytes would have a sequence
number of 100, 101, 102, & 103 assigned) then the receiver would send back an
acknowledgment of 104 since that is the next byte it expects to receive in the next
packet.

In addition to cumulative acknowledgments, TCP receivers can also send selective

acknowledgments to provide further information (see selective acknowledgments).

If the sender infers that data has been lost in the network, it retransmits the data.

Error detection

Sequence numbers and acknowledgments cover discarding duplicate packets,

retransmission of lost packets, and ordered-data transfer. To assure correctness a
checksum field is included (see TCP segment structure for details on check summing).

The TCP checksum is a weak check by modern standards. Data Link Layers with high
bit error rates may require additional link error correction/detection capabilities. The
weak checksum is partially compensated for by the common use of a CRC or better
integrity check at layer 2, below both TCP and IP, such as is used in PPP or the
Ethernet frame. However, this does not mean that the 16-bit TCP checksum is
redundant: remarkably, introduction of errors in packets between CRC-protected hops
is common, but the end-to-end 16-bit TCP checksum catches most of these simple
errors [9]. This is the end-to-end principle at work.

Flow control

TCP uses an end-to-end flow control protocol to avoid having the sender send data
too fast for the TCP receiver to receive and process it reliably. Having a mechanism
for flow control is essential in an environment where machines of diverse network
speeds communicate. For example, if a PC sends data to a hand-held PDA that is
slowly processing received data, the PDA must regulate data flow so as not to be
overwhelmed.

TCP uses a sliding window flow control protocol. In each TCP segment, the receiver
specifies in the receive window field the amount of additional received data (in bytes)
that it is willing to buffer for the connection. The sending host can send only up to
that amount of data before it must wait for an acknowledgment and window update
from the receiving host.

TCP sequence numbers and receive windows behave very much like a clock. The
receive window shifts each time the receiver receives and acknowledges a new

11 | P a g e
segment of data. Once it runs out of sequence numbers, the sequence number loops
back to 0.

When a receiver advertises a window size of 0, the sender stops sending data and
starts the persist timer. The persist timer is used to protect TCP from a deadlock
situation that could arise if the window size update from the receiver is lost and the
sender has no more data to send while the receiver is waiting for the new window
size update. When the persist timer expires, the TCP sender sends a small packet so
that the receiver sends an acknowledgement with the new window size.

If a receiver is processing incoming data in small increments, it may repeatedly

advertise a small receive window. This is referred to as the silly window syndrome,
since it is inefficient to send only a few bytes of data in a TCP segment, given the
relatively large overhead of the TCP header. TCP senders and receivers typically
employ flow control logic to specifically avoid repeatedly sending small segments.
The sender-side silly window syndrome avoidance logic is referred to as Nagle's
algorithm.

Congestion control

The final main aspect of TCP is congestion control. TCP uses a number of mechanisms
to achieve high performance and avoid 'congestion collapse', where network
performance can fall by several orders of magnitude. These mechanisms control the
rate of data entering the network, keeping the data flow below a rate that would
trigger collapse.

Acknowledgments for data sent, or lack of acknowledgments, are used by senders to

infer network conditions between the TCP sender and receiver. Coupled with timers,
TCP senders and receivers can alter the behavior of the flow of data. This is more
generally referred to as congestion control and/or network congestion avoidance.

Modern implementations of TCP contain four intertwined algorithms: Slow-start,

congestion avoidance, fast retransmit, and fast recovery (RFC 2581).

In addition, senders employ a retransmission timeout (RTO) that is based on the

estimated round-trip time (or RTT) between the sender and receiver, as well as the
variance in this round trip time. The behavior of this timer is specified in RFC 2988.
There are subtleties in the estimation of RTT. For example, senders must be careful
when calculating RTT samples for retransmitted packets; typically they use Karn's
Algorithm or TCP timestamps (see RFC 1323). These individual RTT samples are then
averaged over time to create a Smoothed Round Trip Time (SRTT) using Jacobson's
algorithm. This SRTT value is what is finally used as the round-trip time estimate.

Enhancing TCP to reliably handle loss, minimize errors, manage congestion and go
fast in very high-speed environments are ongoing areas of research and standards
development. As a result, there are a number of TCP congestion avoidance algorithm
variations.

Maximum segment size

12 | P a g e
The Maximum segment size (MSS) is the largest amount of data, specified in bytes,
that TCP is willing to send in a single segment. For best performance, the MSS should
be set small enough to avoid IP fragmentation, which can lead to excessive
retransmissions if there is packet loss. To try to accomplishthis, typically the MSS is
negotiated using the MSS option when the TCP connection is established, in which
case it is determined by the maximum transmission unit (MTU) size of the data link
layer of the networks to which the sender and receiver are directly attached.
Furthermore, TCP senders can use Path MTU discovery to infer the minimum MTU
along the network path between the sender and receiver, and use this to dynamically
adjust the MSS to avoid IP fragmentation within the network.

Selective acknowledgments

Relying purely on the cumulative acknowledgment scheme employed by the original

TCP protocol can lead to inefficiencies when packets are lost. For example, suppose
10,000 bytes are sent in 10 different TCP packets, and the first packet is lost during
transmission. In a pure cumulative acknowledgment protocol, the receiver cannot say
that it received bytes 1,000 to 9,999 successfully, but failed to receive the first
packet, containing bytes 0 to 999. Thus the sender may then have to resend all
10,000 bytes.

To solve this problem TCP employs the selective acknowledgment (SACK) option,
defined in RFC 2018, which allows the receiver to acknowledge discontinuous blocks
of packets that were received correctly, in addition to the sequence number of the
last contiguous byte received successively, as in the basic TCP acknowledgment. The
acknowledgement can specify a number of SACK blocks, where each SACK block is
conveyed by the starting and ending sequence numbers of a contiguous range that
the receiver correctly received. In the example above, the receiver would send SACK
with sequence numbers 1,000 and 9,999. The sender thus retransmits only the first
packet, bytes 0 to 999.

An extension to the SACK option is the "duplicate-SACK" option, defined in RFC 2883.
An out-of-order packet delivery can often falsely indicate the TCP sender of lost
packet and, in turn, the TCP sender retransmits the suspected-to-be-lost packet and
slow down the data delivery to prevent network congestion. The TCP sender undoes
the action of slow-down, that is a recovery of the original pace of data transmission,
upon receiving a D-SACK that indicates the retransmitted packet is duplicate.

The SACK option is not mandatory and it is used only if both parties support it. This is
negotiated when connection is established. SACK uses the optional part of the TCP
header (see TCP segment structure for details). The use of SACK is widespread - all
popular TCP stacks support it. Selective acknowledgment is also used in Stream
Control Transmission Protocol (SCTP).

Window scaling

13 | P a g e
For more efficient use of high bandwidth networks, a larger TCP window size may be
used. The TCP window size field controls the flow of data and its value is limited to
between 2 and 65,535 bytes.

Since the size field cannot be expanded, a scaling factor is used. The TCP window
scale option, as defined in RFC 1323, is an option used to increase the maximum
window size from 65,535 bytes to 1 Gigabyte. Scaling up to larger window sizes is a
part of what is necessary for TCP Tuning.

The window scale option is used only during the TCP 3-way handshake. The window
scale value represents the number of bits to left-shift the 16-bit window size field. The
window scale value can be set from 0 (no shift) to 14 for each direction
independently. Both sides must send the option in their SYN segments to enable
window scaling in either direction.

Some routers and packet firewalls rewrite the window scaling factor during a
transmission. This causes sending and receiving sides to assume different TCP
window sizes. The result is non-stable traffic that may be very slow. The problem is
visible on some sending and receiving sites behind the path of defective routers.

TCP Timestamps

TCP timestamps, defined in RFC 1323, help TCP compute the round-trip time between
the sender and receiver. Timestamp options include a 4-byte timestamp value, where
the sender inserts its current value of its timestamp clock, and a 4-byte echo reply
timestamp value, where the receiver generally inserts the most recent timestamp
value that it has received. The sender uses the echo reply timestamp in an
acknowledgment to compute the total elapsed time since the acknowledged segment
was sent.

TCP timestamps are also used to help in the case where TCP sequence numbers
encounter their 232 bound and "wrap around" the sequence number space. This
scheme is known as Protect Against Wrapped Sequence numbers, or PAWS (see RFC
1323 for details). Furthermore, the Eifel detection algorithm, defined in RFC 3522,
which detects unnecessary loss recovery requires TCP timestamps.

Out of band data

One is able to interrupt or abort the queued stream instead of waiting for the stream
to finish. This is done by specifying the data as urgent. This tells the receiving
program to process it immediately, along with the rest of the urgent data. When
finished, TCP informs the application and resumes back to the stream queue. An
example is when TCP is used for a remote login session, the user can send a
keyboard sequence that interrupts or aborts the program at the other end. These
signals are most often needed when a program on the remote machine fails to
operate correctly. The signals must be sent without waiting for the program to finish
its current transfer.[2]

14 | P a g e
TCP OOB data was not designed for the modern Internet. The urgent pointer only
alters the processing on the remote host and doesn't expedite any processing on the
network itself. When it gets to the remote host there are two slightly different
interpretations of the protocol, which means only single bytes of OOB data are
reliable. This is assuming it's reliable at all as it's one of the least commonly used
protocol elements and tends to be poorly implemented.

Forcing data delivery

Normally, TCP waits for the buffer to exceed the maximum segment size before
sending any data. This creates serious delays when the two sides of the connection
are exchanging short messages and need to receive the response before continuing.
For example, the login sequence at the beginning of a telnet session begins with the
short message "Login", and the session cannot make any progress until these five
characters have been transmitted and the response has been received. This process
can be seriously delayed by TCP's normal behavior when the message is provided to
TCP in several send calls.

However, an application can force delivery of segments to the output stream using a
push operation provided by TCP to the application layer.[2] This operation also causes
TCP to set the PSH flag or control bit to ensure that data is delivered immediately to
the application layer by the receiving transport layer.

In the most extreme cases, for example when a user expects each keystroke to be
echoed by the receiving application, the push operation can be used each time a
keystroke occurs. More generally, application programs use this function to force
output to be sent after writing a character or line of characters. By forcing the data to
be sent immediately, delays and wait time are reduced.

Connection termination

The connection termination phase uses, at most, a four-way handshake, with each
side of the connection terminating independently. When an endpoint wishes to stop
its half of the connection, it transmits a FIN packet, which the other end
acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and
ACK segments from each TCP endpoint.

A connection can be "half-open", in which case one side has terminated its end, but
the other has not. The side that has terminated can no longer send any data into the
connection, but the other side can. The terminating side should continue read the
data until the other side terminates as well.

It is also possible to terminate the connection by a 3-way handshake, when host A

sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one)
and host A replies with an ACK.[13] This is perhaps the most common method.

It is possible for both hosts to send FINs simultaneously then both just have to ACK.
This could possibly be considered a 2-way handshake since the FIN/ACK sequence is
done in parallel for both directions.
15 | P a g e
The Need for an Information Security Policy
There are a number of risks inherent to your business IT systems that locking down computers can limit –
but not really remove.

Some of these risks are:

• Loss of data through deletion and corruption.

Data theft.

• Leaking of information protected by the Privacy Act, confidentiality requirements or expectations.

• Exposing staff to indecent media (text, sound or graphics).

• Inappropriate use of company equipment and resources including:

• Downloading of bulk materials (known as leaching)

* Downloading of illegal or inappropriate material
* Distribution of spam
* Use of stolen or pirated software
* Distribution of stolen or pirated software
* Hosting of inappropriate material for download
* Forwarding of illegal actions (hackers like to hide behind other identities).

• Activating viruses on inappropriate websites by initiation of web scripts.

Unfortunately, this list goes on and on. Many of these risks can be mitigated with good use of security
systems within your organization, but not all of them can be prevented or detected without significant
expense. With a strong IT policy in place, staff can be encouraged to not deliberately embark on these
activities, and – if caught – can be strongly disciplined or, if necessary, removed from the company.

IT policy can also be used to set expectations about who owns the data stored on the systems, and who
owns any IP created or stored on the systems.

I've seen many examples of IT policy being required by a range of companies. One such example was a
case where staffs were downloading videos using torrent software, and ran up a bill for many thousands of
dollars before being found out.

16 | P a g e
I've also seen employees downloading and running pirated software to "get a job done" when the required
software was not made available to them. The employees were thinking "get the job done, don't spend
money", but management were oblivious to the risks this exposed the company to. Good systems
monitoring may have prevented both issues, but clear policy can deter staff from embarking on the wrong
path.

Introduction of Xansa’s Information Security policy

Xansa manages its technology systems, services and assets in such a way as to
maximize their availability, integrity and confidentiality. All workforce members
have a responsibility to maintain and enhance the organization’s professional and
secure image by utilizing its technology in an appropriate and productive manner.
Any improper use of technology is not permitted and is treated as a serious offence.
The same standards will be applied to all work with client facilities, in conjunction
with each client's own information security policy.

Xansa is committed to the provision of the information resources necessary to

enable workforce to perform their duties in an effective and well-informed manner.

The Xansa Information Security policy applies to the whole organization. It is written
in a generic format. Each Xansa region is responsible for compliance with regional
legislation, organizational structure and authorized processes.

The policy applies to all users of Xansa equipment and Xansa infrastructure. Users
include the entire workforce and any client, supplier or other third party.

All representatives of Xansa working on client facilities must also follow this security
policy as well as adhering to each client’s own IT security policies.

The following policy and guidelines is specific to Xansa’s Access Control Policy.

Policy

Xansa will ensure that appropriate security controls are in place to maintain the
confidentiality, integrity and availability of data and information for which it is
responsible.

Access to Xansa's technology systems, services and assets are granted on a business
need basis. All access must be formally requested, recorded and authorized.
Managers are responsible for

Access to network systems and services

17 | P a g e
The workforce must only access systems for which they have authorization.
Attempts to gain unauthorized access to systems, impersonation of other users on
the network, or attempts to bypass security controls will be treated as a serious
violation of security policy.

Non work related file browsing on Xansa's systems and networks is prohibited.
Searching for files and/or programs in the directories of other users is prohibited.
Legitimate steps taken to locate information needed to perform one's job are not
considered browsing. Unauthorized access rights should be reported to the Xansa
Customer Service Desk.

Access to all systems and resources are provided on the basis that it is necessary
to meet a business need. When the business need ceases the access rights must
be promptly revoked.

Access to systems is granted through the standard request procedure. All requests
for access to ITsystems must be made to the Xansa Customer Service Desk.

All access to network systems and services is administered by Technical Services

Practice under instruction from line managers.

All changes to user accounts must be documented and authorized.

All access should be subject to regular review by the owner to ensure that access
privileges are appropriate. Access must be promptly removed for all leavers.
Human Resources is responsible for providing notification of leavers.

Unauthorized access, or hacking, is an offence under Computer Misuse Act. If any

user believes they have access to unauthorized systems, software or data this
should be reported to the Customer Service Desk (CSD).

User access management

Access to all systems must be via a user identity and password. All user accounts
on all systems require a personal user ID and password.

User IDs and passwords are provided to workforce in order to access those systems
that they need for their work. They are provided for the user’s sole use and must
not be shared. Workforce must never log on as another member of staff.

It is the responsibility of the user to ensure that their password remains

confidential. Users shall be required to follow good security practices in the
selection and use of passwords. Workforce who suspects that their password may
have been disclosed must immediately report this to the Xansa Customer Service
Desk, who will arrange for it to be reset.

Passwords must be subject to regular enforced change with precautions enforced

against re use. Passwords must not be easy to guess. A previous password or
incremental numbers cannot be used nor can it contain a user name or any part of
the full name.
18 | P a g e
Passwords disclosed to support third parties must be promptly changed when
support responsibilities granted to that party are terminated.

Passwords must always be encrypted when held in storage for any significant
period of time or when transmitted over networks.

Xansa Customer Service Desk must only issue a one-time access if a new user-ID is
being assigned, if the involved user has forgotten or misplaced a password, or is
locked out of his or her user-ID and the involved user has first provided some
definitive evidence substantiating his or her identity.

User ID and associated password that are transmitted to a user must be protected
from unauthorised disclosure.

All vendor-supplied default passwords must be changed before any computer or

communications system is used for business.

Wherever business use priorities permit, systems must automatically blank the
screen and suspend the session if there has been no activity on a computer
terminal, workstation or PC for a reasonable period of time (15 minutes). Re-
establishment of the session must take place only after the user has provided the
correct password.

Guest accounts are not permitted on the network and must be disabled on all
systems.

All remote access to Xansa networks must be via dual authentication. Login and
password access must be enhanced by strong authentication using hardware
tokens, ie SecureID.

Unattended user accounts

User accounts must always be automatically logged out when unattended for at
least 15 minutes. Users must not leave their accounts logged on to systems when
not being used.

Screens displaying sensitive information should not be left unattended. Screen

savers should be

invoked with password protection.

Audit Policy
Introduction
Xansa manages its technology systems, services and assets in such a way as to
maximise their availability, integrity and confidentiality. All workforce members
have a responsibility to maintain and enhance the organisation’s professional and

19 | P a g e
secure image by utilising its technology in an appropriate and productive manner.
Any improper use of technology is not permitted and is treated as a serious
offence. The same standards will be applied to all work with client facilities, in
conjunction with each client's own information security policy.

Xansa is committed to the provision of the information resources necessary to

enable workforce to perform their duties in an effective and well-informed manner.

The Xansa Information Security policy applies to the whole organisation. It is

written in a generic format. Each Xansa region is responsible for compliance with
regional legislation, organisational structure and authorised processes.

The policy applies to all users of Xansa equipment and Xansa infrastructure. Users
include the entire workforce and any client, supplier or other third party.

All representatives of Xansa working on client facilities must also follow this
security policy as well as adhering to each client’s own IT security policies.

The following policy and guidelines is specific to Xansa’s Audit Policy.

Policy

Auditing should be configured to record an audit trail of user activity on all Xansa
systems. As a minimum all systems must audit attempts to log on, successful and
failed.

As a minimum audit logs should be analysed monthly by systems administrators.

All audit logs must be retained for a minimum of a month and then archived.

Internet Policy

Introduction

Xansa manages its technology systems, services and assets in such a way as to
maximise their availability, integrity and confidentiality. All workforce members
have a responsibility to maintain and enhance the organisation’s professional and
secure image by utilising its technology in an appropriate and productive manner.
Any improper use of technology is not permitted and is treated as a serious
offence. The same standards will be applied to all work with client facilities, in
conjunction with each client's own information security policy.

Xansa is committed to the provision of the information resources necessary to

enable workforce to perform their duties in an effective and well-informed manner.

20 | P a g e
The Xansa Information Security policy applies to the whole organisation. It is
written in a generic format. Each Xansa region is responsible for compliance with
regional legislation, organisational structure and authorised processes.

The policy applies to all users of Xansa equipment and Xansa infrastructure. Users
include the entire workforce and any client, supplier or other third party.

All representatives of Xansa working on client facilities must also follow this
security policy as well as adhering to each client’s own IT security policies.

The following policy and guidelines is specific to Xansa’s Internet Policy.

Policy

Access to the Internet from Xansa PCs must only be from the Xansa network via
Xansa’s Internet firewalls.

Purpose

Access to the Internet is primarily provided for business use and may only be used
on an occasional, reasonable basis for personal use. Workforce must use the
services responsibly and in particular must not use them for viewing obscene or
pornographic material.

All workforce working in Xansa make heavy use of Internet and intranet services
and the provision of such facilities places significant responsibilities on both the
organisation as a whole and individual users.

Internet access is provided as a business tool and users are encouraged to

optimise the use of technology in order to raise the business performance of
Xansa.

Managers will take responsibility for a user's adherence to this policy and will
ensure that the user has received the appropriate training if required.

The Internet is an insecure environment; hence security controls are necessary to

protect Xansa networks and information assets to reduce risk and potential
liability. Similarly, email can be an insecure communication medium, in particular
Internet email - knowing how to use it securely is essential.

This policy applies to all users; employees, contractors, auditors and third parties
and shall apply regardless of how access to the Internet was achieved, whether by
Xansa LAN or the secure dial service.

The policy is not intended to restrict people unfairly.

21 | P a g e
Examples are provided where needed to facilitate understanding of the policy -
these are not exhaustive.

Xansanet and the Internet

Xansanet is in effect a "private internet" provided solely for Xansa. It is used to

host internal websites for all of Xansa while also providing a gateway to the wider
Internet, the World Wide Web.

Throughout this policy, the term “Internet” will be used to refer equally to
Xansanet, Internet and World Wide Web (WWW).

All content posted to the intranet (http://xan sanet.xan sa.com) and the web site
(http://www.xansa.com)is the property of Xansa, or permission has been obtained
from the owner to use it.

Acceptable Use

The Internet will normally be used for Xansa related purposes, e.g.to communicate
with colleagues and clients, to research relevant topics and obtain useful business
information.

Users must conduct themselves honestly and respect the copyrights, software
licensing rules, property rights and privacy of others. Due to the insecure nature of
Internet mail, users must consider email outside of the Xansa to be public
information, including email-generating (‘contact us’) web pages. In common with
the Information Security Policy of Xansa no confidential material or company
-classified information must be transmitted over the Internet.

Only those users or officials who are duly authorised to speak to the media, to
analysts or in public gatherings on behalf of the Xansa may speak/write in the
name of Xansa to any Internet newsgroup or chat room. Users must refrain from
any unauthorised endorsement or appearance of endorsement by Xansa of any
commercial product or service or of anything which would be in breach of
commercial confidence or which could have a detrimental effect on Xansa.

In addition, the use of personal web logs (blogs) must not be detrimental to Xansa
and its clients or suppliers.

Therefore, subject to the points described below in Unacceptable use, the Internet
may be used for any normal Xansa business activity that is in line with of the aims
and policies of Xansa.Internet access from the Xansa infrastructure is only
permissible through a firewall. Workforce accessing Internet and other future
services:by dial-in using their Xansa laptop (including SSL VPN) Broadband from
any browser that has access to the Internet, regardless of where it is located via

22 | P a g e
client-supplied equipment must be authenticated by means of technology which
meets recognised international security standards.

Webmasters and any other workforce posting material to the intranet (Xansanet)
or the web site(Xansa.com) information must thoroughly check all information and
programs to make sure they do not include viruses, Trojan horses, and other
malicious code confirm the information’s accuracy, timeliness and relevance to
Xansa’s business before posting it

ensure legal issues are raised with Xansa Legal - for example whether or not the
action may result in the disclosure of confidential information, or copyright
infringement

Unacceptable use

The Internet must not be used for any of the following:

The creation, transmission or downloading of any offensive, obscene or indecent

images, data or other material or any data capable of being incorporated into
obscene or indecent images or material. The downloading, storing, viewing,
printing, or redistribution of any kind of sexually explicit image or document on any
Xansa system is a breach of Xansa’s policy on sexual harassment. If workforce
finds that they are connected accidentally or incidentally to a site that contains
sexually explicit or offensive material, they must disconnect from that site
immediately. Similarly, such activities are prohibited on personal PCs/Laptops
provided for official duties.

The creation, transmission or downloading of any material which is designed to or

likely to cause offence, annoyance, inconvenience or needless anxiety.

The creation, transmission or downloading of defamatory material, or anything

which might be deemed to be harassing or intimidating

The transmission or downloading of material such as infringes the copyright of

another person

See Copyright and Software Licensing policy.

The Xansa’s Internet facilities and computing resources must not be used
knowingly for any illegal activity. In the event of such activity being discovered
Xansa may proceed to act in accordance with its Disciplinary Procedure. Xansa will
always comply with any reasonable requests from law enforcement and regulatory
agencies for logs diaries and archives on an individual’s Internet activities.

The transmission of unsolicited commercial or advertising material to organisations

connected to other networks (ie the wider Internet).

No confidential information should be posted to intranet or the web site.

23 | P a g e
Non business use that grossly abuses the service.

Gross abuse of the service by the unsolicited sending of inappropriate e-mail to

large numbers of people, whether on Xansanet or the wider Internet.

Deliberate unauthorised access to facilities or services accessible via Xansanet, for

example the disclosure of sensitive information to commercial organisations or
contact details to non- Xansa workforce. Users are also reminded that Xansa
already has a policy concerning confidentiality and should ensure that Xansa’s
data is treated as confidential at all times.

Access or attempting to access offensive, obscene, malicious or indecent material

from the Internet such as pornography, racist material, sexist material, material
that is intolerant of religious belief or sexual orientation, violent imagery or
incitement to commit criminal behavior.

Security

While a direct connection to the Internet offers many potential benefits, it also
increases risks to Xansa’s data and systems and requires special security. This
may include preventing computers with sensitive data or applications from
connecting to the Internet entirely or for that matter separating those machines
connecting to external information sources from the network entirely.
Alternatively it may mean that certain users must be prevented from using certain
Internet features such as file transfers. Such decisions will be the remit of the CSD
team in conjunction with Xansa Security management.

The overriding principle is that security is to be every member of the workforce’s

first concern. A user will be held accountable for any breaches of security or
confidentiality and for the protection of data in accordance with Xansa’s data
protection policy.

Users who are Xansa employees who attempt to disable, defeat or circumvent any
Xansa security facility will be subject to Xansa disciplinary procedures, which could
ultimately lead to dismissal.

Users who are not Xansa employees such as contractors and project staff will be
subject to an equivalent level of investigation and treatment. Sub-contractors will
be expected to discipline their own staff (where appropriate), which will include the
sub contractor removing such staff from Xansa. In all cases individual users will be
disconnected from the network, Internet and or any other form of computer access
pending the outcome of the investigation.

Users who become aware of weaknesses in security facilities or attempts to breach

security must inform Xansa Security Team via CSD at the earliest opportunity.

Monitoring

24 | P a g e
Technical Services Practice can monitor, record and, as appropriate, review
individual Internet usage for each web site or newsgroup visited or email message
and file transferred into and out of workforce computer. This will not be practised
as a matter of course but in the event of any real or suspected breach of security
or transgression against Xansa policies on email usage or Internet access such
actions may be authorised by Business Management team in conjunction with
Technical Services Practice management and in line with HR policy. Xansa’s
integrity must always be maintained in anything written, transmitted, or received
by any individual user. Xansa, therefore reserves the right to inspect any files
stored in private areas of the network or individual networked PCs in order to
assure compliance with policy and no employee should have any expectation of
absolute privacy as to their usage of the Internet.

Clearly it is not the intention or desire of Xansa that individual Internet or Email
records be scrutinised but Xansa has a responsibility to itself and its clients to
ensure that standards and security are upheld. These arrangements will apply to
all user access.

Personal use

Xansa PCs/laptop etc should be used for the conduct of Xansa’s business activity
and excessive personal Internet or private email activity whilst at a Xansa
workstation during working hours will be considered a breach of Xansa Information
Security Policy and the subject of disciplinary action.

Limited personal use of the Internet is available to staff from their workstations
during lunch breaks but every effort should be made to reduce the impact on the
business related Internet traffic.

The purchase of goods or services over the Internet or through the use of email is
permitted. Where possible staff must make it clear that they are purchasing them
in a personal capacity and that they are responsible for any commitments entered
into.

Any such personal use of the Internet or any email facility, whether from an
individual’s PC or provided through the “Internet Kiosk”, shall remain the subject of
this policy.

Users must not use Xansa Internet facilities to download entertainment software,
screensavers or games, or to play games either alone or against opponents over
the Internet.

Abuse of this privilege will lead to disciplinary action being taken against
employees and restrictions and appropriate for the wider workforce.

The list below shows categories of approved and non approved personal software.
This includes but is not restricted to:

25 | P a g e
 Categ Appro Exam
ory
Access to Personal ved
Yes ple
On-line banking, shopping,
Websites
Personal Yes holidays,
CBT, Open rentals
University
Development
Peer to Peer No software
File sharing products
Software
Personal No e.g. KAZZA or networked
Standalone
Games
Illegal No games
All e.g. Doom 3
Diallers
Instant No diallers
Only Xansa approved
Messaging
Advert No Gator, adverts which pop
Sponsors
Screensa No up unwanted
Only Xansa screensavers
vers are permitted

Email Policy

Introduction

Xansa manages its technology systems, services and assets in such a way as to
maximize their availability, integrity and confidentiality. All workforce members
have a responsibility to maintain and enhance the organization’s professional and
secure image by utilizing its technology in an appropriate and productive manner.
Any improper use of technology is not permitted and is treated as a serious
offence. The same standards will be applied to all work with client facilities, in
conjunction with each client's own information security policy.

Xansa is committed to the provision of the information resources necessary to

enable workforce to perform their duties in an effective and well-informed manner.

The Xansa Information Security policy applies to the whole organisation. It is

written in a generic format. Each Xansa region is responsible for compliance with
regional legislation, organisational structure and authorised processes.

The policy applies to all users of Xansa equipment and Xansa infrastructure. Users
include the entire workforce and any client, supplier or other third party.

All representatives of Xansa working on client facilities must also follow this
security policy as well as adhering to each client’s own IT security policies.

The following policy and guidelines is specific to Xansa’s Email Policy.

Policy

Only Xansa supplied or Xansa approved email facilities can be used for Xansa
business communications via email.

Purpose

26 | P a g e
The purpose of the Email Policy is to:

• ensure the efficient and ethical use of the business tool to protect the
integrity of Xansa, by not expressing views that may be detrimental to the
organisation or its workforce

• ensure usage of the service is not in breach of company policy

• ensure usage of the service is not in breach of current legislation

Workforce should be aware that content of any communication represents the

organisation, either directly or indirectly, regardless of the existence of any
specification that views expressed are solely that of the sender. It is therefore
fundamental that every authorised user adheres to the guidelines set out within
this policy.

Many members of the workforce have access to email and to the Internet. These
services are primarily provided for business use and may only be used on an
occasional, reasonable basis for personal reasons. Workforce must use the
services responsibly and in particular not use them for frivolous or libellous
messages or for viewing pornographic material.

Xansa employs automatic email content scanning tools to identify selected words,
file types and other information. Users should restrict their communications to
business matters in recognition of this electronic monitoring as emails not
recognised as business emails may be intercepted. Privacy therefore cannot be
guaranteed.

Xansa is committed to the provision of the information resources necessary to

enable workforce to perform their duties in an effective and well-informed manner.

Xansa makes extensive use of Email, Internet and Intranet services and the
provision of such facilities places significant responsibilities on both the
organisation as a whole and on individual users.

Email is the primary method for business communication, surpassing the usage of
communication tools such as post, facsimile and telephone.Unlike the use of formal
documents e.g. letters, memoranda and telephone conversations; the use of Email
is not sufficiently established or tested (in technical, legal and cultural terms) for
its acceptable uses and applications to be completely clear. Therefore the use of
Email should be treated with caution.

Xansa is committed to providing high quality Email access to all users with a
business need for such a service.

Definitions of terms

The following terms are widely used within this policy:

Email
27 | P a g e
Throughout this policy the Electronic Mail service provided by Xansa is referred to
as ‘Email’.

Authorised users

A person with access to the business service via specification of a username and
password.

Communications

The use of the Email service for the transmitting of any material, including
messages, uploaded data, attachments and associated media.

Unlawful material

Transmitted communication that does not conform to English Law (or any other law
that may be breached by the communication) including International Law and
Contractual Agreements.

Background

Access to the service

Authorised users will be granted access via an assigned username and user-
defined password.

Generic guidelines

The content of this policy is generic and therefore the guidelines on acceptable and
unacceptable service usage apply to all authorised users.

For example, the sender cannot deem a communication to be inoffensive because

the content will not, in his/her opinion, be offensive to the specified recipient(s). It
is the nature of the communication itself that defines whether it is, or is not, an
offensive article.

Scope

The policy applies to all Email communications sent by authorised users via the
Lotus Notes or any other email systems provided by Xansa. In additional, many of
the policy statements also apply to the usage of other communication tools within
Xansa, including instant messaging, telephone, facsimile and post.

Unauthorised users will, in the first instance, be subject to disciplinary action for
accessing the system without authorization.

Inappropriate use

28 | P a g e
Authorised users must not engage in any of the following when communicating,
transmitting, uploading or posting information via the business service:

‘Company confidential’ information must not be sent by email across the Internet
when security cannot be guaranteed. Such information may only be sent by
internal email to other Xansa email accounts.

Workforce must not use an email identity assigned to another individual either to
send or receive messages. If there is a need to read a colleague’s mail in his/her
absence, other facilities must be used. These facilities are easy to use and advice
is available from the Xansa Customer Service Desk (CSD).

Emails must not contain program files (*.exe) or other non-business formats. This
includes video, games, software and joke-programs. Email attachments for
external use are limited to a size of 5Mb

Standard software is provided to reduce the size of attachments. In exceptional

circumstances larger attachments may be transmitted after prior authorisation
from the Xansa CSD.

For security reasons, Xansa email accounts must not be forwarded permanently to
third party email accounts. All redirects must be agreed with the TSP security team
via CSD. Redirects to web based email accounts are forbidden e.g. Yahoo, Hotmail.
Redirect requests must highlight why the redirect is required and for how long.

Workforce is provided with Xansa email accounts when needed or in some cases
workforce based on client sites will be supplied with client email address. These
are the only email accounts that should be accessed from Xansa equipment. Use
of Internet-based email facilities is prohibited, for example sites such as
www.hotmail.com and www.yahoo.com.

Misrepresentation of an affiliation with any other person or persons, including

organisational bodies, either by false identification or usage of another individuals
service account.

Forging or manipulation of data/document content, history, identifiers or origin

with intention to misguide the recipient

Access or attempted access to another person’s account without specific

permission from the account holder

The transmitting of any dangerous content or inclusion of any virus with intent to
cause damage, interruption or limited performance to computer code, files,
programs, hardware or software.

The transmitting of unlawful, abusive, libellous, invasive, in breach of Xansa’s

equal opportunity, harassing and/or obscene material or views.

The transmitting of material that infringes patent, copyright, trademark, trade

secret or intellectual property rights of any third party. Copyright material must
29 | P a g e
not be uploaded or distributed electronically or as printed matter without the
authority of the copyright owner.

The transmitting of material for promotional, advertisement or personal gain,

including junk mail, ‘spam’, chain communications or other forms of solicitation.

Interference with the service, network or connections associated with providing the
business service.

Performance of any activity that may be deemed objectionable to the Xansa or

other service users.

Impersonation of any other person, persons or organisation, either by false

identification or usage of another individuals service account.

Passwords are assigned to individuals and must be kept secret. Workforce are
reminded that they must not share identities or passwords.

Inappropriate use and failure to comply with the policy may result in disciplinary
action.

Every member of the workforce has a responsibility to maintain and enhance the
Company’s image and to use Company email in a productive manner. Electronic
communications must always be carried out in a way that will prevent or minimise
legal liability and potential damage to the reputation of Xansa.

Improper use of the email will not be permitted and will be treated as a serious
offence. Workforce should be aware that such improper conduct could result in
disciplinary action or the termination of Client or Supplier agreements.

Acceptable use and guidelines

These guidelines should be adhered to where possible, to ensure the service is

managed effectively and used to its maximum potential in a lawful and appropriate
manner.

Workforces are advised to consider email to be the electronic equivalent of a

postcard.

Because of the risk of interception, all emails must be signed and those containing
sensitive information must be password protected (where possible) and encrypted
or sent using Sealed Media. Workforces are advised to use their judgement in
deciding what constitutes sensitive information. Examples include documents
marked "Company Confidential", passwords, identities, critical business
information, personal details, salary, bid and other financial information.

30 | P a g e
A Xansa disclaimer will be appended to all external email.The use of Internet email
list-servers and subscription to Internet email sources must be for business
purposes only - for example subscriptions to joke list-servers are prohibited.

Workforce must exercise professional care when sending or forwarding email.

Electronic communications must always be carried out in a way that will prevent or
minimise legal liability and potential damage to the reputation of Xansa.

Broadcast email provides important information to workforce and certain specific

business clients. Broadcast email must be used with caution and only after
authorisation has been obtained. This can be arranged through Xansa Corporate
Communications for non IT related emails and Xansa CSD for IT.

Email groups must only be used when sending business email. Personal email
must be addressed to individuals and not sent to business email groups.

Ensure outgoing messages are sent to the correct address by keeping address
books updated. In addition, ensure messages are only sent to the intended
person(s) – do not ‘Reply to All’ if this action is unnecessary.

Include the ‘subject’ for every message communicated, read through the message
once it has been drafted, and ensure the message is spell-checked as poor
grammar and spelling errors may reflect negatively upon Xansa.

Login regularly and read messages promptly to ensure action is taken as and when
necessary. In most cases, the Email service can remain connected while other
desktop applications are in process. However, do not act impetuously as a result
of fast communication.

When absent for a given period of time, set-up the out of office message to advise
others. The CSD team will be happy to provide assistance in setting up the ‘out-of-
office reply’ feature.

Archive received messages in a systematic and organized fashion, to ensure

communications can be found, actioned and deleted effectively.

Only open attachments if they are received from a reputable source, as the
content of such attachments may contain material that is inappropriate, harmful or
otherwise detrimental to the recipient and/or Xansa. If a user believes that they
have downloaded a virus they should inform the CSD team immediately.

Do not print or forward sensitive messages without the sender’s permission.

If a workstation is left unattended for any period of time, log-out of the system to
prevent the account being used by an unauthorised person.

Select a suitable password (Access Control Policy - User Access Management for
further details).

31 | P a g e
Take care to ensure that messages are not in breach of appropriate use as detailed
herein.

Should an authorised user receive a message they believe to be in breach of policy,

please report the incident to the appropriate Manager — do not forward the
message as this may implicate the sender and others.

Sign off with sender’s name, role, organisation and contact details if necessary

Do not attach large files unless absolutely necessary — often a file can be trimmed,
or the data copied into the message itself to prevent the need for a large
attachment.

Do not type in BLOCK CAPITALS unless absolutely necessary as this can be

considered aggressive. An Email message can easily be misinterpreted. It is not
good practice to write in a sarcastic, demanding or cynical tone.

Always adhere to the etiquettes associated with sending letters by hand/post — in a

professional environment the same standards apply with Email.

Use all of the facilities provided within the Email system to support collaboration
and team working. Particularly useful are, rules based messaging, appointment
scheduling, shared folders and Email groups.

Enforcing the email policy

Managers will take responsibility for an authorised user's adherence to this policy
and will ensure that the users are aware of the Information Security Policy and will
organise a user awareness session if required. In addition, Technical Services
Practice retains the rights to manage the service and enforce this policy as
detailed below.

Managing the System

The Technical Services Practice teams in both UK and India manage the Email
systems and deal with technical issues surrounding the service. In the case of
misuse of the service, Managers will be notified as appropriate.

Updating the Policy

The Information, Risk and Security Manager and Technical Services Practice
management team are responsible for future revisions of this policy.

All policy updates must be agreed by Xansa’s ISMF and signed off by the Xansa
Executive Board.

Responsibilities and rights of the organisation

Xansa’s integrity must always be maintained in anything written, transmitted, or

received by any individual user. Therefore, Xansa reserves the right to inspect any

32 | P a g e
files stored in private areas of the network or individual networked PC’s in order to
assure compliance with policy and no member of the workforce should have any
expectation of absolute privacy as to their usage of Email.

Clearly it is not the intention of Xansa that individual Email records be scrutinised,
particularly as this would place a large administrative overhead on the Technical
Services Practice team, but Xansa has a responsibility to itself, its clients and its
partners to ensure that standards and security are upheld.

Xansa may monitor, preserve or disclose any communication with a view to:

Administration of an account in line with organisational procedure

Re-enforcing the case of misuse against an individual, must any such case arise

Respond to complaints made by a third party

Protect the organization’s rights, privacy, property and integrity

Complying with legal requirements

To ensure the service is managed effectively and fairly, the organisation may
define restrictions on individual accounts to limit:

Communication with a specified account

The amount of messages a user can store (mailbox limits)

A single communication to a specified size

Personal use

Xansa equipment should be used for the conduct of business activities. Excessive
personal Email activity whilst at a Xansa workstation during working hours will be
considered a breach of Xansa policy and the subject of disciplinary action.

Limited personal use of Email facilities is available to workforce from their

workstations but every effort should be made to reduce the impact on the core
business Internet traffic by keeping downloads to a minimum.

Security

The overriding principle is that security is to be every member of the workforce’s

first concern. A user will be held accountable for any breaches of security or
confidentiality via their logon email account and for the protection of data in
accordance with Xansa’s data protection policy.

Appropriate management of passwords is a very effective security method (further

details can be found in the Information Security Policy document). The Anti-Virus
Policy also details measures that help protect the organisation from potential
attack.

33 | P a g e
Any member of the workforce who attempts to disable, defeat or circumvent any
Xansa security facility will be subject to the Xansa disciplinary procedures, which
could ultimately lead to dismissal or termination of contractual relationship.

Users who are not Xansa employees, such as contractors and third party staff, will
be subject to an equivalent level of investigation and treatment. Sub-contractors
will be expected to discipline their own staff (where appropriate), which will include
the sub-contractor removing such staff from Xansa. In all cases individual users
will be disconnected from the network, Internet and or any other form of computer
access pending the outcome of the investigation. This could ultimately lead to
termination of contractual relationship.

Users who become aware of weaknesses in security facilities or attempts to breach

security must inform the CSD team immediately.

Thank you

34 | P a g e