IT Project Report

8/8/2019 IT Project Report

1/34

1 | P a g e

IT Project ReportXansas Network Architecture and ITpolicy

201

0

Sanchit SharmaRoll No.70

WMG 18B


2/34

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 Xansas Information Security policy ............................................. 17

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

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

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

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

2 | P a g e


3/34

ACKNOWLEDGEMENTIt 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 | P a g e


4/34

4 | P a g e


5/34

Network Architecture in Xansa

Network Connectivity

5 | P a g e


6/34

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 users 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 calledprotocols of

6 | P a g e


7/34

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 aregrouped 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 useIPsec. 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 | P a g e


8/34

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 IMAPgenerally 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 standardprotocols, 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 | P a g e


9/34

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 asit 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 accessedcannot 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 amessage 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 | P a g e


10/34

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 sequencenumberRetransmission of lost packets - any cumulative stream not acknowledged isretransmitted 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 bereconstructed 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


11/34

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 anacknowledgment 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 achecksum 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


12/34

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 size12 | P a g e


13/34

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 MTUalong 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 all10,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 SACKwith 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 isnegotiated 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


14/34

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 numbersencounter 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. Anexample 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


15/34

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


16/34

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


17/34

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 Xansas 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 organizations 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 clients own IT security policies.

The following policy and guidelines is specific to Xansas 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


18/34

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 users 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 mayhave 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 reuse. 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


19/34

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 somedefinitive 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


maximise their availability, integrity and confidentiality. All workforce members

have a responsibility to maintain and enhance the organisations professional and

19 | P a g e


20/34

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.



The Xansa Information Security policy applies to the whole organisation. It iswritten in a generic format. Each Xansa region is responsible for compliance with

regional legislation, organisational structure and authorised processes.



All representatives of Xansa working on client facilities must also follow this

security policy as well as adhering to each clients own IT security policies.

The following policy and guidelines is specific to Xansas 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


maximise their availability, integrity and confidentiality. All workforce members

have a responsibility to maintain and enhance the organisations professional and

secure image by utilising its technology in an appropriate and productive manner.






20 | P a g e


21/34

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






The following policy and guidelines is specific to Xansas Internet Policy.

Policy

Access to the Internet from Xansa PCs must only be from the Xansa network via

Xansas 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 theuser 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


22/34

Examples are provided where needed to facilitate understanding of the policy -

theseare 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 widerInternet, 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 ( h t tp: // x a n s an e t.x a n s a . c om) and the web site

( h t t p :/ /w w w .x an s a.c o m)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 inpublic 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
http://xansanet.xansa.com/http://xansanet.xansa.com/http://www.xansa.com/http://www.xansa.com/http://www.xansa.com/http://xansanet.xansa.com/


23/34

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 informations accuracy, timeliness and relevance to

Xansas 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 Xansas 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 Xansas 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 willalways comply with any reasonable requests from law enforcement and regulatory

agencies for logs diaries and archives on an individuals 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


24/34

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 Xansasdata 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 Xansas data and systems and requires special security. Thismay 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 workforces

first concern. A user will be held accountable for any breaches of security or

confidentiality and for the protection of data in accordance with Xansas 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


25/34

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. Xansas

integrity must always be maintained in anything written, transmitted, or receivedby 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 Xansas 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 thesubject 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

individuals 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


26/34

Categ Appro Exam

Access to Personal Yes On-line banking, shopping,

Personal Yes CBT, Open University

Peer to Peer No File sharing products

Personal No Standalone or networked

Illegal No All

Instant No Only Xansa approved

Advert No Gator, adverts which pop

Screensa No Only Xansa screensavers

Email Policy

Introduction


maximize their availability, integrity and confidentiality. All workforce members

have a responsibility to maintain and enhance the organizations professional and

secure image by utilizing its technology in an appropriate and productive 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






The following policy and guidelines is specific to Xansas 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


27/34

The purpose of the Email Policy is to:

ensure the efficient and ethical use of the business tool to protect the

integrity ofXansa, 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

servicesare 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 particularnot use them for frivolous or libellousmessages 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 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 ofterms

The following terms are widely used within this policy:

Email

27 | P a g e


28/34

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


29/34

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 colleagues mail in his/herabsence, 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

w ww .ho t m a il.c o m and ww w .y a ho o .c om.

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 persons 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 Xansas

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
http://www.hotmail.com/http://www.hotmail.com/http://www.yahoo.com/http://www.hotmail.com/http://www.yahoo.com/


30/34

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,

includingjunk mail, spam, chain communications or other forms of solicitation.

Interference with the service, network or connections associated with providing thebusiness 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 disciplinaryaction.

Every member of the workforce has a responsibility to maintain and enhance the

Companys 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


31/34

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 specificbusiness 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 ofsuch 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 senders 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


32/34

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 senders 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 Xansas ISMF and signed off by the Xansa

Executive Board.

Responsibilities and rights of the organisation

Xansas 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


33/34

files stored in private areas of the network or individual networked PCs 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 andsecurity 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 organizations 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. ExcessivepersonalEmail 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 workforces

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 Xansas 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


34/34

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 toan 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

IT Project Report

Documents

Transcript of IT Project Report