Ictnwk602 V7.2

TMG Learner Resource
tmg.edu.au | 1300 888 TMG (1300 888 864)
ICTNWK602
Plan, configure and test
advanced server-based security
LEARNER GUIDE
The Malka Group Pty Ltd Trading as TMG College Australia | Registered Training Organisation #21694 | CRICOS Provider Code 03397E
Document Type: DC-1265 TMG Trainer Learner Guide
Version 7.2 Release Date: Sep 2018 Page 1 of 731
Unit details: ICTNWK602 - Plan, configure and test advanced server-based security
tmg.edu.au | 1300 888 TMG (1300 888 864)
Contents
Consult with client and key stakeholders to identify security requirements in an

advanced network server environment ................................................................................... 10
Activity 1 ............................................................................................................................................. 13
Activity 2 ............................................................................................................................................. 25
Activity 3 ............................................................................................................................................. 35
Analyse and review existing client security documentation and predict network
service vulnerabilities ...................................................................................................................... 36
Activity 4 ............................................................................................................................................. 39
Activity 5 ............................................................................................................................................. 52
Research network authentication and network service configuration options and
implications to produce network security solutions ............................................................... 54
Activity 6 ........................................................................................................................................... 101
Activity 7 ........................................................................................................................................... 156
Ensure features and capabilities of network service security options meet the
business needs ................................................................................................................................ 159
Activity 8 ........................................................................................................................................... 171
Produce or update server security design documentation to include new solutions
............................................................................................................................................................ 174
Activity 9 ........................................................................................................................................... 177
Activity 10 ......................................................................................................................................... 193
Obtain sign-off for the security design from the appropriate person ............................. 195
Activity 11 ......................................................................................................................................... 199
Prepare for work in line with site-specific safety requirements and enterprise
occupational health and safety (OHS) processes and procedures .............................. 201
Activity 12 ......................................................................................................................................... 218
Identify safety hazards and implement risk control measures in consultation with
appropriate personnel ................................................................................................................. 219
Activity 13 ......................................................................................................................................... 233
Consult appropriate person to ensure the task is coordinated effectively with others
involved at the worksite ............................................................................................................... 235
Activity 14 ......................................................................................................................................... 240
Back up server before implementing configuration changes ......................................... 241
Activity 15 ......................................................................................................................................... 247
Configure update services to provide automatic updates to ensure maximum
security and reliability ................................................................................................................... 249
Document Type: DC-1265 TMG Trainer Assessment Guide
Unit details: ICTNWK602 Plan, configure and test advanced server-based security
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 16 ......................................................................................................................................... 256

Configure network authentication, authorisation and accounting services to log and
prevent unauthorised access to the server ........................................................................... 258
Activity 17 ......................................................................................................................................... 274
Configure basic service security and access control lists to limit access to authorised
users, groups or networks ............................................................................................................. 293
Activity 18 ......................................................................................................................................... 374
Implement encryption as required by the design................................................................ 376
Activity 19 ......................................................................................................................................... 382
Configure advanced network service security options for services and remote
access ............................................................................................................................................... 393
Activity 20 ......................................................................................................................................... 467
Configure the operating system or third-party firewall to filter traffic in line with
security requirements.................................................................................................................... 470
Activity 21 ......................................................................................................................................... 494
Activity 22 ......................................................................................................................................... 529
Ensure security of server logs and log servers are appropriately implemented for
system integrity ............................................................................................................................... 532
Activity 23 ......................................................................................................................................... 532
Implement backup and recovery methods to enable restoration capability in the
event of a disaster ......................................................................................................................... 555
Activity 24 ......................................................................................................................................... 585
Test server to assess the effectiveness of network service security according to
agreed design plan ...................................................................................................................... 587
Activity 25 ......................................................................................................................................... 588
Activity 26 ......................................................................................................................................... 590
Monitor server logs, network traffic and open ports to detect possible intrusions ...... 592
Activity 27 ......................................................................................................................................... 597
Monitor important files to detect unauthorised modifications ......................................... 599
Investigate and verify alleged violations of server or data security and privacy
breaches .......................................................................................................................................... 608
Recover from, report and document security breaches according to security policies
and procedures ............................................................................................................................. 691
Activity 28 ......................................................................................................................................... 693
Evaluate monitored results and reports to implement and test improvement actions
required to maintain the required level of network service security .............................. 695
tmg.edu.au | 1300 888 TMG (1300 888 864)
Application
This unit describes the skills and knowledge required to implement advanced server security
using secure authentication and network services on a network server.
It applies to individuals working as information and communications technology (ICT)

network specialists, ICT network engineers, network security specialists, network security
planners and network security designers.
No licensing, legislative or certification requirements apply to this unit at the time of

publication.
Unit Sector
Networking
Elements and Performance Criteria

ELEMENT PERFORMANCE CRITERIA
Elements describe the Performance criteria describe the performance needed to
essential outcomes. demonstrate achievement of the element.
1. Plan advanced 1.1 Consult with client and key stakeholders to identify security
network server security requirements in an advanced network server environment
according to business
needs 1.2 Analyse and review existing client security documentation
and predict network service vulnerabilities
1.3 Research network authentication and network service

configuration options and implications to produce network
security solutions
1.4 Ensure features and capabilities of network service security

options meet the business needs
1.5 Produce or update server security design documentation

to include new solutions
1.6 Obtain sign-off for the security design from the appropriate
person
2. Prepare for Network 2.1 Prepare for work in line with site-specific safety
server security requirements and enterprise occupational health and safety
implementation (OHS) processes and procedures
2.2 Identify safety hazards and implement risk control measures

in consultation with appropriate personnel
tmg.edu.au | 1300 888 TMG (1300 888 864)
2.3 Consult appropriate person to ensure the task is

coordinated effectively with others involved at the worksite
2.4 Back up server before implementing configuration

changes
3. Configure the 3.1 Configure update services to provide automatic updates
advanced network to ensure maximum security and reliability
server security according
to design 3.2 Configure network authentication, authorisation and
accounting services to log and prevent unauthorised access
to the server
3.3 Configure basic service security and access control lists to

limit access to authorised users, groups or networks
3.4 Implement encryption as required by the design
3.5 Configure advanced network service security options for

services and remote access
3.6 Configure the operating system or third-party firewall to

filter traffic in line with security requirements
3.7 Ensure security of server logs and log servers are

appropriately implemented for system integrity
3.8 Implement backup and recovery methods to enable

restoration capability in the event of a disaster
4. Monitor and test 4.1 Test server to assess the effectiveness of network service
network server security security according to agreed design plan
4.2 Monitor server logs, network traffic and open ports to

detect possible intrusions
4.3 Monitor important files to detect unauthorised

modifications
4.4 Investigate and verify alleged violations of server or data

security and privacy breaches
4.5 Recover from, report and document security breaches

according to security policies and procedures
4.6 Evaluate monitored results and reports to implement and

test improvement actions required to maintain the required
level of network service security
tmg.edu.au | 1300 888 TMG (1300 888 864)
Foundation Skills
This section describes language, literacy, numeracy and employment skills incorporated in
the performance criteria that are required for competent performance.
Skill Performance Description

Criteria
Reading 1.2, 1.3, 3.6, 4.1, 4.3,  Recognises and interprets technical
4.5, 4.6 enterprise security procedures, policies,
specifications, and vendor notifications
to determine and confirm job
requirements
Writing 1.5, 4.5  Develops a broad range of material

including security reports for a specific
audience, using clear and detailed
language to convey explicit
information, requirements and
recommendations
Oral 1.1, 2.2, 2.3, 4.5  Uses listening and questioning skills to
Communication confirm understanding for requirements
 Articulates clearly, using specific and
relevant language suitable to audience,
and participates in verbal exchanges of
ideas and solutions
Interact with 1.6  Actively identifies the requirements of

others important communication exchanges,
selecting appropriate channels, format,
tone and content to suit purpose and
audience
Navigate the 2.1  Keeps up to date on changes to

world of work legislation or regulations relevant to own
rights and responsibilities, and considers
implications of these when planning,
negotiating and undertaking work
Get the work 1.2, 1.4, 2.2, 2.4, 3.1-  Considers the strategic and operational
done 3.8, 4.1, 4.2, 4.4-4.6 potential of digital trends to achieve
work goals, enhance work processes,
create opportunities and enhance or
reduce risks
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Uses a broad range of strategies to

store, access and organise virtual
information, recognising that design
choices will influence what information is
retrieved and how it may be interpreted
and used
 Is acutely aware of the importance of
understanding, monitoring and
controlling access to digitally stored and
transmitted information
 May operate from a broad conceptual
plan, developing the operational detail
in stages, regularly reviewing priorities
and performance during
implementation, and identifying and
addressing issues
 Uses nuanced understanding of context
to detect, investigate and recover from
security breaches
Unit Mapping Information

Code and title Code and title Comments Equivalence
status
current version previous version
ICTNWK602 Plan, ICANWK602A Plan, Updated to meet Standards Equivalent
configure and test configure and test for Training Packages. unit
advanced server- advanced server-
based security based security
Assessment requirements
Modification History
Release Comments
Release 1 This version first released with ICT Information and

Communications Technology Training Package Version 1.0.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Performance Evidence
Evidence of the ability to:
 identify network service security vulnerabilities and appropriate controls

 plan, design and configure a secure network authentication service
 secure a wide range of network services to ensure server and data security, including:
 dynamic name system (DNS)
 web and proxy
 mail
 file transfer protocol (FTP)
 firewall
 implement cryptographic techniques
 monitor the server for security breaches.
Note: If a specific volume or frequency is not stated, then evidence must be provided at
least once.
Knowledge Evidence
To complete the unit requirements safely and effectively, the individual must:
 explain auditing and penetration testing techniques

 summarise best practice procedures for implementing backup and restore
 outline cryptographic techniques
 clarify the procedures for error and event logging and reporting
 explain intrusion detection and recovery procedures
 outline network service configuration, including:

 DNS
 dynamic host configuration protocol (DHCP)
 web
 mail
 FTP
 server messages block (SMB)
 network time protocol (NTP)
 proxy
 summarise network service security features, options and limitations
 outline network service vulnerabilities
 summarise operating system help and support utilities
 describe planning, configuration, monitoring and troubleshooting techniques
 outline security protection mechanisms
 summarise security threats and risks
 explain server firewall configuration
tmg.edu.au | 1300 888 TMG (1300 888 864)
 explain server monitoring and troubleshooting tools and techniques, including

network monitoring and diagnostic utilities
 summarise user authentication and directory services.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consult with client and key stakeholders to identify security requirements in an advanced
network server environment
Introduction to Networking
A basic understanding of computer networks is requisite in order to understand the principles
of network security. In this section, we'll cover some of the foundations of computer
networking, then move on to an overview of some popular networks. Following that, we'll
take a more in-depth look at TCP/IP, the network protocol suite that is used to run the
Internet and many intranets.
Once we've covered this, we'll go back and discuss some of the threats that managers and
administrators of computer networks need to confront, and then some tools that can be
used to reduce the exposure to the risks of network computing.
What is a Network?
A ``network'' has been defined[1] as `àny set of interlinking lines resembling a net, a network
of roads || an interconnected system, a network of alliances.'' This definition suits our
purpose well: a computer network is simply a system of interconnected computers. How
they're connected is irrelevant, and as we'll soon see, there are a number of ways to do this.
The ISO/OSI Reference Model

The International Standards Organization (ISO) Open Systems Interconnect (OSI) Reference
Model defines seven layers of communications types, and the interfaces among them. (See
Figure 1.) Each layer depends on the services provided by the layer below it, all the way
down to the physical network hardware, such as the computer's network interface card, and
the wires that connect the cards together.
An easy way to look at this is to compare this model with something we use daily: the
telephone. In order for you and I to talk when we're out of earshot, we need a device like a
telephone. (In the ISO/OSI model, this is at the application layer.) The telephones, of course,
are useless unless they have the ability to translate the sound into electronic pulses that can
be transferred over wire and back again. (These functions are provided in layers below the
application layer.) Finally, we get down to the physical connection: both must be plugged
into an outlet that is connected to a switch that's part of the telephone system's network of
switches.
If I place a call to you, I pick up the receiver, and dial your number. This number specifies
which central office to which to send my request, and then which phone from that central
office to ring. Once you answer the phone, we begin talking, and our session has begun.
Conceptually, computer networks function exactly the same way.
It isn't important for you to memorize the ISO/OSI Reference Model's layers; but it's useful to
know that they exist, and that each layer cannot work without the services provided by the
layer below it.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 1: The ISO/OSI Reference Model
What are some Popular Networks?

Over the last 25 years or so, a number of networks and network protocols have been defined
and used. We're going to look at two of these networks, both of which are ``public'' networks.
Anyone can connect to either of these networks, or they can use types of networks to
connect their own hosts (computers) together, without connecting to the public networks.
Each type takes a very different approach to providing network services.
UUCP
UUCP (Unix-to-Unix CoPy) was originally developed to connect Unix (surprise!) hosts together.
UUCP has since been ported to many different architectures, including PCs, Macs, Amigas,
Apple IIs, VMS hosts, everything else you can name, and even some things you can't.
Additionally, a number of systems have been developed around the same principles as
UUCP.
Batch-Oriented Processing.
UUCP and similar systems are batch-oriented systems: everything that they have to do is
added to a queue, and then at some specified time, everything in the queue is processed.
Implementation Environment.
UUCP networks are commonly built using dial-up (modem) connections. This doesn't have to
be the case though: UUCP can be used over any sort of connection between two
computers, including an Internet connection.
Building a UUCP network is a simple matter of configuring two hosts to recognize each other,
and know how to get in touch with each other. Adding on to the network is simple; if hosts
called A and B have a UUCP network between them, and C would like to join the network,
then it must be configured to talk to A and/or B. Naturally, anything that C talks to must be
made aware of C's existence before any connections will work. Now, to connect D to the
tmg.edu.au | 1300 888 TMG (1300 888 864)
network, a connection must be established with at least one of the hosts on the network, and
so on. Figure 2 shows a sample UUCP network.
Figure 2: A Sample UUCP Network
In a UUCP network, users are identified in the format host!userid. The ``!'' character
(pronounced ``bang'' in networking circles) is used to separate hosts and users. A bangpath
is a string of host(s) and a userid like A!cmcurtin or C!B!A!cmcurtin. If I am a user on host A
and you are a user on host E, I might be known as A!cmcurtin and you as E!you. Because
there is no direct link between your host (E) and mine (A), in order for us to communicate, we
need to do so through a host (or hosts!) that has connectivity to both E and A. In our sample
network, C has the connectivity we need. So, to send me a file, or piece of email, you would
address it to C!A!cmcurtin. Or, if you feel like taking the long way around, you can address
me as C!B!A!cmcurtin.
The ``public'' UUCP network is simply a huge worldwide network of hosts connected to each
other.
Popularity.
The public UUCP network has been shrinking in size over the years, with the rise of the
availability of inexpensive Internet connections. Additionally, since UUCP connections are
typically made hourly, daily, or weekly, there is a fair bit of delay in getting data from one
user on a UUCP network to a user on the other end of the network. UUCP isn't very flexible, as
it's used for simply copying files (which can be netnews, email, documents, etc.) Interactive
protocols (that make applications such as the World Wide Web possible) have become
much more the norm, and are preferred in most cases.
tmg.edu.au | 1300 888 TMG (1300 888 864)
However, there are still many people whose needs for email and netnews are served quite
well by UUCP, and its integration into the Internet has greatly reduced the amount of
cumbersome addressing that had to be accomplished in times past.
Security.
UUCP, like any other application, has security tradeoffs. Some strong points for its security is
that it is fairly limited in what it can do, and it's therefore more difficult to trick into doing
something it shouldn't; it's been around a long time, and most its bugs have been
discovered, analyzed, and fixed; and because UUCP networks are made up of occasional
connections to other hosts, it isn't possible for someone on host E to directly make contact
with host B, and take advantage of that connection to do something naughty.
On the other hand, UUCP typically works by having a system-wide UUCP user account and
password. Any system that has a UUCP connection with another must know the appropriate
password for the uucp or nuucp account. Identifying a host beyond that point has
traditionally been little more than a matter of trusting that the host is who it claims to be, and
that a connection is allowed at that time. More recently, there has been an additional layer
of authentication, whereby both hosts must have the same sequence number , that is a
number that is incremented each time a connection is made.
Hence, if I run host B, I know the uucp password on host A. If, though, I want to impersonate
host C, I'll need to connect, identify myself as C, hope that I've done so at a time that A will
allow it, and try to guess the correct sequence number for the session. While this might not be
a trivial attack, it isn't considered very secure.
The Internet
Internet: This is a word that I've heard way too often in the last few years. Movies, books,
newspapers, magazines, television programs, and practically every other sort of media
imaginable has dealt with the Internet recently.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 1
Why is security a critical aspect of networking?
tmg.edu.au | 1300 888 TMG (1300 888 864)
What is the Internet?

The Internet is the world's largest network of networks . When you want to access the
resources offered by the Internet, you don't really connect to the Internet; you connect to a
network that is eventually connected to the Internet backbone , a network of extremely fast
(and incredibly overloaded!) network components. This is an important point: the Internet is a
network of networks -- not a network of hosts.
A simple network can be constructed using the same protocols and such that the Internet
uses without actually connecting it to anything else. Such a basic network is shown in
Figure 3.
Figure 3: A Simple Local Area Network
I might be allowed to put one of my hosts on one of my employer's networks. We have a

number of networks, which are all connected together on a backbone , that is a network of
our networks. Our backbone is then connected to other networks, one of which is to an
Internet Service Provider (ISP) whose backbone is connected to other networks, one of which
is the Internet backbone.
If you have a connection ``to the Internet'' through a local ISP, you are actually connecting
your computer to one of their networks, which is connected to another, and so on. To use a
service from my host, such as a web server, you would tell your web browser to connect to
my host. Underlying services and protocols would send packets (small datagrams) with your
query to your ISP's network, and then a network they're connected to, and so on, until it
found a path to my employer's backbone, and to the exact network my host is on. My host
would then respond appropriately, and the same would happen in reverse: packets would
traverse all of the connections until they found their way back to your computer, and you
were looking at my web page.
In Figure 4, the network shown in Figure 3 is designated ``LAN 1'' and shown in the bottom-
right of the picture. This shows how the hosts on that network are provided connectivity to
other hosts on the same LAN, within the same company, outside of the company, but in the
same ISP cloud , and then from another ISP somewhere on the Internet.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4: A Wider View of Internet-connected Networks
The Internet is made up of a wide variety of hosts, from supercomputers to personal

computers, including every imaginable type of hardware and software. How do all of these
computers understand each other and work together?
TCP/IP: The Language of the Internet

TCP/IP (Transport Control Protocol/Internet Protocol) is the ``language'' of the Internet.
Anything that can learn to ``speak TCP/IP'' can play on the Internet. This is functionality that
occurs at the Network (IP) and Transport (TCP) layers in the ISO/OSI Reference Model.
Consequently, a host that has TCP/IP functionality (such as Unix, OS/2, MacOS, or Windows
NT) can easily support applications (such as Netscape's Navigator) that uses the network.
Open Design
One of the most important features of TCP/IP isn't a technological one: The protocol is an
`òpen'' protocol, and anyone who wishes to implement it may do so freely. Engineers and
scientists from all over the world participate in the IETF (Internet Engineering Task Force)
working groups that design the protocols that make the Internet work. Their time is typically
donated by their companies, and the result is work that benefits everyone.
IP
As noted, IP is a ``network layer'' protocol. This is the layer that allows the hosts to actually
``talk'' to each other. Such things as carrying datagrams, mapping the Internet address (such
tmg.edu.au | 1300 888 TMG (1300 888 864)
as 10.2.3.4) to a physical network address (such as 08:00:69:0a:ca:8f), and routing, which

takes care of making sure that all of the devices that have Internet connectivity can find the
way to each other.
Understanding IP
IP has a number of very important features which make it an extremely robust and flexible
protocol. For our purposes, though, we're going to focus on the security of IP, or more
specifically, the lack thereof.
Attacks Against IP
A number of attacks against IP are possible. Typically, these exploit the fact that IP does not
perform a robust mechanism for authentication , which is proving that a packet came from
where it claims it did. A packet simply claims to originate from a given address, and there
isn't a way to be sure that the host that sent the packet is telling the truth. This isn't necessarily
a weakness, per se , but it is an important point, because it means that the facility of host
authentication has to be provided at a higher layer on the ISO/OSI Reference Model. Today,
applications that require strong host authentication (such as cryptographic applications) do
this at the application layer.
IP Spoofing.
This is where one host claims to have the IP address of another. Since many systems (such as
router access control lists) define which packets may and which packets may not pass
based on the sender's IP address, this is a useful technique to an attacker: he can send
packets to a host, perhaps causing it to take some sort of action.
Additionally, some applications allow login based on the IP address of the person making the
request (such as the Berkeley r-commands )[2]. These are both good examples how trusting
untrustable layers can provide security that is -- at best -- weak.
IP Session Hijacking.
This is a relatively sophisticated attack, first described by Steve Bellovin [3]. This is very
dangerous, however, because there are now toolkits available in the underground
community that allow otherwise unskilled bad-guy-wannabes to perpetrate this attack. IP
Session Hijacking is an attack whereby a user's session is taken over, being in the control of
the attacker. If the user was in the middle of email, the attacker is looking at the email, and
then can execute any commands he wishes as the attacked user. The attacked user simply
sees his session dropped, and may simply login again, perhaps not even noticing that the
attacker is still logged in and doing things.
For the description of the attack, let's return to our large network of networks in Figure 4. In this
attack, a user on host A is carrying on a session with host G. Perhaps this is a telnet session,
where the user is reading his email, or using a Unix shell account from home. Somewhere in
the network between A and G sits host H which is run by a naughty person. The naughty
person on host H watches the traffic between A and G, and runs a tool which starts to
tmg.edu.au | 1300 888 TMG (1300 888 864)
impersonate A to G, and at the same time tells A to shut up, perhaps trying to convince it
that G is no longer on the net (which might happen in the event of a crash, or major network
outage). After a few seconds of this, if the attack is successful, naughty person has
``hijacked'' the session of our user. Anything that the user can do legitimately can now be
done by the attacker, illegitimately. As far as G knows, nothing has happened.
This can be solved by replacing standard telnet-type applications with encrypted versions of
the same thing. In this case, the attacker can still take over the session, but he'll see only
``gibberish'' because the session is encrypted. The attacker will not have the needed
cryptographic key(s) to decrypt the data stream from G, and will, therefore, be unable to do
anything with the session.
TCP
TCP is a transport-layer protocol. It needs to sit on top of a network-layer protocol, and was
designed to ride atop IP. (Just as IP was designed to carry, among other things, TCP packets.)
Because TCP and IP were designed together and wherever you have one, you typically
have the other, the entire suite of Internet protocols are known collectively as ``TCP/IP.'' TCP
itself has a number of important features that we'll cover briefly.
Guaranteed Packet Delivery
Probably the most important is guaranteed packet delivery. Host A sending packets to host B
expects to get acknowledgments back for each packet. If B does not send an
acknowledgment within a specified amount of time, A will resend the packet.
Applications on host B will expect a data stream from a TCP session to be complete, and in
order. As noted, if a packet is missing, it will be resent by A, and if packets arrive out of order,
B will arrange them in proper order before passing the data to the requesting application.
This is suited well toward a number of applications, such as a telnet session. A user wants to
be sure every keystroke is received by the remote host, and that it gets every packet sent
back, even if this means occasional slight delays in responsiveness while a lost packet is
resent, or while out-of-order packets are rearranged.
It is not suited well toward other applications, such as streaming audio or video, however. In
these, it doesn't really matter if a packet is lost (a lost packet in a stream of 100 won't be
distinguishable) but it does matter if they arrive late (i.e., because of a host resending a
packet presumed lost), since the data stream will be paused while the lost packet is being
resent. Once the lost packet is received, it will be put in the proper slot in the data stream,
and then passed up to the application.
UDP
UDP (User Datagram Protocol) is a simple transport-layer protocol. It does not provide the
same features as TCP, and is thus considered `ùnreliable.'' Again, although this is unsuitable
tmg.edu.au | 1300 888 TMG (1300 888 864)
for some applications, it does have much more applicability in other applications than the
more reliable and robust TCP.
Lower Overhead than TCP
One of the things that makes UDP nice is its simplicity. Because it doesn't need to keep track
of the sequence of packets, whether they ever made it to their destination, etc., it has lower
overhead than TCP. This is another reason why it's more suited to streaming-data
applications: there's less screwing around that needs to be done with making sure all the
packets are there, in the right order, and that sort of thing.
Risk Management: The Game of Security

It's very important to understand that in security, one simply cannot say ``what's the best
firewall?'' There are two extremes: absolute security and absolute access. The closest we can
get to an absolutely secure machine is one unplugged from the network, power supply,
locked in a safe, and thrown at the bottom of the ocean. Unfortunately, it isn't terribly useful
in this state. A machine with absolute access is extremely convenient to use: it's simply there,
and will do whatever you tell it, without questions, authorization, passwords, or any other
mechanism. Unfortunately, this isn't terribly practical, either: the Internet is a bad
neighborhood now, and it isn't long before some bonehead will tell the computer to do
something like self-destruct, after which, it isn't terribly useful to you.
This is no different from our daily lives. We constantly make decisions about what risks we're
willing to accept. When we get in a car and drive to work, there's a certain risk that we're
taking. It's possible that something completely out of control will cause us to become part of
an accident on the highway. When we get on an airplane, we're accepting the level of risk
involved as the price of convenience. However, most people have a mental picture of what
an acceptable risk is, and won't go beyond that in most circumstances. If I happen to be
upstairs at home, and want to leave for work, I'm not going to jump out the window. Yes, it
would be more convenient, but the risk of injury outweighs the advantage of convenience.
Every organization needs to decide for itself where between the two extremes of total
security and total access they need to be. A policy needs to articulate this, and then define
how that will be enforced with practices and such. Everything that is done in the name of
security, then, must enforce that policy uniformly.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network Security is an organization’s strategy and provisions for ensuring the security of its
assets and of all network traffic. Network security is manifested in an implementation of
security hardware, and software. For the purposes of this discussion, the following
approach is adopted in an effort to view network security in its entirety:
1. Policy
2. Enforcement
3. Auditing
Policy
The IT Security Policy is the principle document for network security. Its goal is to outline the
rules for ensuring the security of organizational assets. Employees today utilize several tools
and applications to conduct business productively. Policy that is driven from the
organization’s culture supports these routines and focuses on the safe enablement of
these tools to its employees. The enforcement and auditing procedures for any regulatory
compliance an organization is required to meet must be mapped out in the policy as well.
Enforcement
Most definitions of network security are narrowed to the enforcement mechanism.

Enforcement concerns analyzing all network traffic flows and should aim to preserve the
confidentiality, integrity, and availability of all systems and information on the network.
These three principles compose the CIA triad:
 Confidentiality - involves the protection of assets from unauthorized entities

 Integrity - ensuring the modification of assets is handled in a specified and
authorized manner
 Availability - a state of the system in which authorized users have continuous
access to said assets.
Strong enforcement strives to provide CIA to network traffic flows. This begins with a
classification of traffic flows by application, user, and content. As the vehicle for content,
all applications must first be identified by the firewall regardless of port, protocol, evasive
tactic, or SSL. Proper application identification allows for full visibility of the content it
carries. Policy management can be simplified by identifying applications and mapping
their use to a user identity while inspecting the content at all times for the preservation of
CIA.
The concept of defense in depth is observed as a best practice in network security,

prescribing for the network to be secured in layers. These layers apply an assortment of
security controls to sift out threats trying to enter the network:
 Access control
 Identification
 Authentication
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Malware detection
 Encryption
 File type filtering
 URL filtering
 Content filtering
These layers are built through the deployment of firewalls, intrusion prevention systems (IPS),
and antivirus components. Among the components for enforcement, the firewall (an
access control mechanism) is the foundation of network security.
Providing CIA of network traffic flows was difficult to accomplish with previous
technologies. Traditional firewalls were plagued by controls that relied on port/protocol to
identify applications—which have since developed evasive characteristics to bypass the
controls—and the assumption that IP address equates to a users identity.
The next generation firewall retains an access control mission, but reengineers the
technology; it observes all traffic across all ports, can classify applications and their
content, and identifies employees as users. This enables access controls nuanced enough
to enforce the IT security policy as it applies to each employee of the organization, with no
compromise to security.
Additional services for layering network security to implement a defense in depth strategy
8have been incorporated to the traditional model as add-on components. Intrusion
prevention systems (IPS) and antivirus, for example, are effective tools for scanning content
and preventing malware attacks. However, organizations must be cautious of the
complexity and cost that additional components may add to its network security, and
more importantly, not depend on these additional components to do the core job of the
firewall.
Auditing
The auditing process of network security requires checking back on enforcement

measures to determine how well they have aligned with the security policy. Auditing
encourages continuous improvement by requiring organizations to reflect on the
implementation of their policy on a consistent basis. This gives organizations the
opportunity to adjust their policy and enforcement strategy in areas of evolving need.
Types And Sources Of Network Threats

Now, we've covered enough background information on networking that we can actually
get into the security aspects of all of this. First of all, we'll get into the types of threats there are
against networked computers, and then some things that can be done to protect yourself
against various threats.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Denial-of-Service
DoS (Denial-of-Service) attacks are probably the nastiest, and most difficult to address. These
are the nastiest, because they're very easy to launch, difficult (sometimes impossible) to
track, and it isn't easy to refuse the requests of the attacker, without also refusing legitimate
requests for service.
The premise of a DoS attack is simple: send more requests to the machine than it can handle.
There are toolkits available in the underground community that make this a simple matter of
running a program and telling it which host to blast with requests. The attacker's program
simply makes a connection on some service port, perhaps forging the packet's header
information that says where the packet came from, and then dropping the connection. If
the host is able to answer 20 requests per second, and the attacker is sending 50 per second,
obviously the host will be unable to service all of the attacker's requests, much less any
legitimate requests (hits on the web site running there, for example).
Such attacks were fairly common in late 1996 and early 1997, but are now becoming less
popular.
Some things that can be done to reduce the risk of being stung by a denial of service attack
include
 Not running your visible-to-the-world servers at a level too close to capacity

 Using packet filtering to prevent obviously forged packets from entering into your
network address space.
Obviously forged packets would include those that claim to come from your own
hosts, addresses reserved for private networks as defined in RFC 1918 [4], and the
loopback network (127.0.0.0).
 Keeping up-to-date on security-related patches for your hosts' operating systems.
Unauthorized Access
`Ùnauthorized access'' is a very high-level term that can refer to a number of different sorts
of attacks. The goal of these attacks is to access some resource that your machine should
not provide the attacker. For example, a host might be a web server, and should provide
anyone with requested web pages. However, that host should not provide command shell
access without being sure that the person making such a request is someone who should get
it, such as a local administrator.
Executing Commands Illicitly
It's obviously undesirable for an unknown and untrusted person to be able to execute
commands on your server machines. There are two main classifications of the severity of this
problem: normal user access, and administrator access. A normal user can do a number of
things on a system (such as read files, mail them to other people, etc.) that an attacker
tmg.edu.au | 1300 888 TMG (1300 888 864)
should not be able to do. This might, then, be all the access that an attacker needs. On the
other hand, an attacker might wish to make configuration changes to a host (perhaps
changing its IP address, putting a start-up script in place to cause the machine to shut down
every time it's started, or something similar). In this case, the attacker will need to gain
administrator privileges on the host.
Confidentiality Breaches
We need to examine the threat model: what is it that you're trying to protect yourself
against? There is certain information that could be quite damaging if it fell into the hands of
a competitor, an enemy, or the public. In these cases, it's possible that compromise of a
normal user's account on the machine can be enough to cause damage (perhaps in the
form of PR, or obtaining information that can be used against the company, etc.)
While many of the perpetrators of these sorts of break-ins are merely thrill-seekers interested in
nothing more than to see a shell prompt for your computer on their screen, there are those
who are more malicious, as we'll consider next. (Additionally, keep in mind that it's possible
that someone who is normally interested in nothing more than the thrill could be persuaded
to do more: perhaps an unscrupulous competitor is willing to hire such a person to hurt you.)
Destructive Behavior
Among the destructive sorts of break-ins and attacks, there are two major categories.
Data Diddling.
The data diddler is likely the worst sort, since the fact of a break-in might not be immediately
obvious. Perhaps he's toying with the numbers in your spreadsheets, or changing the dates in
your projections and plans. Maybe he's changing the account numbers for the auto-deposit
of certain paychecks. In any case, rare is the case when you'll come in to work one day, and
simply know that something is wrong. An accounting procedure might turn up a discrepancy
in the books three or four months after the fact. Trying to track the problem down will
certainly be difficult, and once that problem is discovered, how can any of your numbers
from that time period be trusted? How far back do you have to go before you think that your
data is safe?
Data Destruction.
Some of those perpetrate attacks are simply twisted jerks who like to delete things. In these
cases, the impact on your computing capability -- and consequently your business -- can be
nothing less than if a fire or other disaster caused your computing equipment to be
completely destroyed.
Where Do They Come From?

How, though, does an attacker gain access to your equipment? Through any connection
that you have to the outside world. This includes Internet connections, dial-up modems, and
even physical access. (How do you know that one of the temps that you've brought in to
tmg.edu.au | 1300 888 TMG (1300 888 864)
help with the data entry isn't really a system cracker looking for passwords, data phone
numbers, vulnerabilities and anything else that can get him access to your equipment?)
In order to be able to adequately address security, all possible avenues of entry must be
identified and evaluated. The security of that entry point must be consistent with your stated
policy on acceptable risk levels.
Lessons Learned
From looking at the sorts of attacks that are common, we can divine a relatively short list of
high-level practices that can help prevent security disasters, and to help control the damage
in the event that preventative measures were unsuccessful in warding off an attack.
Hope you have backups
This isn't just a good idea from a security point of view. Operational requirements should
dictate the backup policy, and this should be closely coordinated with a disaster recovery
plan, such that if an airplane crashes into your building one night, you'll be able to carry on
your business from another location. Similarly, these can be useful in recovering your data in
the event of an electronic disaster: a hardware failure, or a breakin that changes or
otherwise damages your data.
Don't put data where it doesn't need to be
Although this should go without saying, this doesn't occur to lots of folks. As a result,
information that doesn't need to be accessible from the outside world sometimes is, and this
can needlessly increase the severity of a break-in dramatically.
Avoid systems with single points of failure
Any security system that can be broken by breaking through any one component isn't really
very strong. In security, a degree of redundancy is good, and can help you protect your
organization from a minor security breach becoming a catastrophe.
Stay current with relevant operating system patches
Be sure that someone who knows what you've got is watching the vendors' security
advisories. Exploiting old bugs is still one of the most common (and most effective!) means of
breaking into systems.
Watch for relevant security advisories
In addition to watching what the vendors are saying, keep a close watch on groups like
CERT and CIAC. Make sure that at least one person (preferably more) is subscribed to these
mailing lists
tmg.edu.au | 1300 888 TMG (1300 888 864)
Have someone on staff be familiar with security practices
Having at least one person who is charged with keeping abreast of security developments is
a good idea. This need not be a technical wizard, but could be someone who is simply able
to read advisories issued by various incident response teams, and keep track of various
problems that arise. Such a person would then be a wise one to consult with on security
related issues, as he'll be the one who knows if web server software version such-and-such
has any known problems, etc.
This person should also know the ``dos'' and ``don'ts'' of security, from reading such things as
the ``Site Security Handbook.''
Activity 2
Describe in detail one network threat.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 2
Firewalls
As we've seen in our discussion of the Internet and similar networks, connecting an
organization to the Internet provides a two-way flow of traffic. This is clearly undesirable in
many organizations, as proprietary information is often displayed freely within a corporate
intranet (that is, a TCP/IP network, modeled after the Internet that only works within the
organization).
In order to provide some level of separation between an organization's intranet and the
Internet, firewalls have been employed. A firewall is simply a group of components that
collectively form a barrier between two networks.
A number of terms specific to firewalls and networking are going to be used throughout this
section, so let's introduce them all together.
Bastion host.
A general-purpose computer used to control access between the internal (private)

network (intranet) and the Internet (or any other untrusted network). Typically, these
are hosts running a flavor of the Unix operating system that has been customized in
order to reduce its functionality to only what is necessary in order to support its
functions. Many of the general-purpose features have been turned off, and in many
cases, completely removed, in order to improve the security of the machine.
Router.
A special purpose computer for connecting networks together. Routers also handle
certain functions, such as routing , or managing the traffic on the networks they
connect.
Access Control List (ACL).

tmg.edu.au | 1300 888 TMG (1300 888 864)
Many routers now have the ability to selectively perform their duties, based on a
number of facts about a packet that comes to it. This includes things like origination
address, destination address, destination service port, and so on. These can be
employed to limit the sorts of packets that are allowed to come in and go out of a
given network.
Demilitarized Zone (DMZ).
The DMZ is a critical part of a firewall: it is a network that is neither part of the
untrusted network, nor part of the trusted network. But, this is a network that connects
the untrusted to the trusted. The importance of a DMZ is tremendous: someone who
breaks into your network from the Internet should have to get through several layers in
order to successfully do so. Those layers are provided by various components within
the DMZ.
Proxy.
This is the process of having one host act in behalf of another. A host that has the
ability to fetch documents from the Internet might be configured as a proxy server ,
and host on the intranet might be configured to be proxy clients . In this situation,
when a host on the intranet wishes to fetch the <http://www.interhack.net/> web
page, for example, the browser will make a connection to the proxy server, and
request the given URL. The proxy server will fetch the document, and return the result
to the client. In this way, all hosts on the intranet are able to access resources on the
Internet without having the ability to direct talk to the Internet.
Types of Firewalls
There are three basic types of firewalls, and we'll consider each of them.
Application Gateways
The first firewalls were application gateways, and are sometimes known as proxy gateways.
These are made up of bastion hosts that run special software to act as a proxy server. This
software runs at the Application Layer of our old friend the ISO/OSI Reference Model, hence
the name. Clients behind the firewall must be proxitized (that is, must know how to use the
proxy, and be configured to do so) in order to use Internet services. Traditionally, these have
been the most secure, because they don't allow anything to pass by default, but need to
have the programs written and turned on in order to begin passing traffic.
Figure 5: A sample application gateway
tmg.edu.au | 1300 888 TMG (1300 888 864)
These are also typically the slowest, because more processes need to be started in order to
have a request serviced. Figure 5 shows a application gateway.
Packet Filtering
Packet filtering is a technique whereby routers have ACLs (Access Control Lists) turned on. By
default, a router will pass all traffic sent it, and will do so without any sort of restrictions.
Employing ACLs is a method for enforcing your security policy with regard to what sorts of
access you allow the outside world to have to your internal network, and vice versa.
There is less overhead in packet filtering than with an application gateway, because the
feature of access control is performed at a lower ISO/OSI layer (typically, the transport or
session layer). Due to the lower overhead and the fact that packet filtering is done with
routers, which are specialized computers optimized for tasks related to networking, a packet
filtering gateway is often much faster than its application layer cousins. Figure 6 shows a
packet filtering gateway.
Because we're working at a lower level, supporting new applications either comes
automatically, or is a simple matter of allowing a specific packet type to pass through the
gateway. (Not that the possibility of something automatically makes it a good idea; opening
things up this way might very well compromise your level of security below what your policy
allows.)
There are problems with this method, though. Remember, TCP/IP has absolutely no means of
guaranteeing that the source address is really what it claims to be. As a result, we have to
use layers of packet filters in order to localize the traffic. We can't get all the way down to the
tmg.edu.au | 1300 888 TMG (1300 888 864)
actual host, but with two layers of packet filters, we can differentiate between a packet that
came from the Internet and one that came from our internal network. We can identify which
network the packet came from with certainty, but we can't get more specific than that.
Hybrid Systems
In an attempt to marry the security of the application layer gateways with the flexibility and
speed of packet filtering, some vendors have created systems that use the principles of both.
Figure 6: A sample packet filtering gateway
In some of these systems, new connections must be authenticated and approved at the
application layer. Once this has been done, the remainder of the connection is passed
down to the session layer, where packet filters watch the connection to ensure that only
packets that are part of an ongoing (already authenticated and approved) conversation
are being passed.
Other possibilities include using both packet filtering and application layer proxies. The
benefits here include providing a measure of protection against your machines that provide
services to the Internet (such as a public web server), as well as provide the security of an
application layer gateway to the internal network. Additionally, using this method, an
tmg.edu.au | 1300 888 TMG (1300 888 864)
attacker, in order to get to services on the internal network, will have to break through the
access router, the bastion host, and the choke router.
So, what's best for me?

Lots of options are available, and it makes sense to spend some time with an expert, either
in-house, or an experienced consultant who can take the time to understand your
organization's security policy, and can design and build a firewall architecture that best
implements that policy. Other issues like services required, convenience, and scalability
might factor in to the final design.
Some Words of Caution

The business of building firewalls is in the process of becoming a commodity market. Along
with commodity markets come lots of folks who are looking for a way to make a buck
without necessarily knowing what they're doing. Additionally, vendors compete with each
other to try and claim the greatest security, the easiest to administer, and the least visible to
end users. In order to try to quantify the potential security of firewalls, some organizations
have taken to firewall certifications. The certification of a firewall means nothing more than
the fact that it can be configured in such a way that it can pass a series of tests. Similarly,
claims about meeting or exceeding U.S. Department of Defense `Òrange Book'' standards,
C-2, B-1, and such all simply mean that an organization was able to configure a machine to
pass a series of tests. This doesn't mean that it was loaded with the vendor's software at the
time, or that the machine was even usable. In fact, one vendor has been claiming their
operating system is ``C-2 Certified'' didn't make mention of the fact that their operating
system only passed the C-2 tests without being connected to any sort of network devices.
Such gauges as market share, certification, and the like are no guarantees of security or
quality. Taking a little bit of time to talk to some knowledgeable folks can go a long way in
providing you a comfortable level of security between your private network and the big,
bad Internet.
Additionally, it's important to note that many consultants these days have become much less
the advocate of their clients, and more of an extension of the vendor. Ask any consultants
you talk to about their vendor affiliations, certifications, and whatnot. Ask what difference it
makes to them whether you choose one product over another, and vice versa. And then ask
yourself if a consultant who is certified in technology XYZ is going to provide you with
competing technology ABC, even if ABC best fits your needs.
Single Points of Failure
Many ``firewalls'' are sold as a single component: a bastion host, or some other black box
that you plug your networks into and get a warm-fuzzy, feeling safe and secure. The term
``firewall'' refers to a number of components that collectively provide the security of the
system. Any time there is only one component paying attention to what's going on between
the internal and external networks, an attacker has only one thing to break (or fool!) in order
to gain complete access to your internal networks.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Secure Network Devices

It's important to remember that the firewall is only one entry point to your network. Modems, if
you allow them to answer incoming calls, can provide an easy means for an attacker to
sneak around (rather than through ) your front door (or, firewall). Just as castles weren't built
with moats only in the front, your network needs to be protected at all of its entry points.
Secure Modems; Dial-Back Systems

If modem access is to be provided, this should be guarded carefully. The terminal server , or
network device that provides dial-up access to your network needs to be actively
administered, and its logs need to be examined for strange behavior. Its passwords need to
be strong -- not ones that can be guessed. Accounts that aren't actively used should be
disabled. In short, it's the easiest way to get into your network from remote: guard it carefully.
There are some remote access systems that have the feature of a two-part procedure to
establish a connection. The first part is the remote user dialing into the system, and providing
the correct userid and password. The system will then drop the connection, and call the
authenticated user back at a known telephone number. Once the remote user's system
answers that call, the connection is established, and the user is on the network. This works
well for folks working at home, but can be problematic for users wishing to dial in from hotel
rooms and such when on business trips.
Other possibilities include one-time password schemes, where the user enters his userid, and is
presented with a ``challenge,'' a string of between six and eight numbers. He types this
challenge into a small device that he carries with him that looks like a calculator. He then
presses enter, and a ``response'' is displayed on the LCD screen. The user types the response,
and if all is correct, he login will proceed. These are useful devices for solving the problem of
good passwords, without requiring dial-back access. However, these have their own
problems, as they require the user to carry them, and they must be tracked, much like
building and office keys.
No doubt many other schemes exist. Take a look at your options, and find out how what the
vendors have to offer will help you enforce your security policy effectively.
Crypto-Capable Routers
A feature that is being built into some routers is the ability to use session encryption between
specified routers. Because traffic traveling across the Internet can be seen by people in the
middle who have the resources (and time) to snoop around, these are advantageous for
providing connectivity between two sites, such that there can be secure routes.
Virtual Private Networks

Given the ubiquity of the Internet, and the considerable expense in private leased lines,
many organizations have been building VPNs (Virtual Private Networks). Traditionally, for an
organization to provide connectivity between a main office and a satellite one, an
expensive data line had to be leased in order to provide direct connectivity between the
two offices. Now, a solution that is often more economical is to provide both offices
tmg.edu.au | 1300 888 TMG (1300 888 864)
connectivity to the Internet. Then, using the Internet as the medium, the two offices can
communicate.
The danger in doing this, of course, is that there is no privacy on this channel, and it's difficult
to provide the other office access to `ìnternal'' resources without providing those resources
to everyone on the Internet.
VPNs provide the ability for two offices to communicate with each other in such a way that it
looks like they're directly connected over a private leased line. The session between them,
although going over the Internet, is private (because the link is encrypted), and the link is
convenient, because each can see each others' internal resources without showing them off
to the entire world.
A number of firewall vendors are including the ability to build VPNs in their offerings, either
directly with their base product, or as an add-on. If you have need to connect several offices
together, this might very well be the best way to do it.
Security is a very difficult topic. Everyone has a different idea of what ``security'' is, and what
levels of risk are acceptable. The key for building a secure network is to define what security
means to your organization . Once that has been defined, everything that goes on with the
network can be evaluated with respect to that policy. Projects and systems can then be
broken down into their components, and it becomes much simpler to decide whether what
is proposed will conflict with your security policies and practices.
Many people pay great amounts of lip service to security, but do not want to be bothered
with it when it gets in their way. It's important to build systems and networks in such a way
that the user is not constantly reminded of the security system around him. Users who find
security policies and systems too restrictive will find ways around them. It's important to get
their feedback to understand what can be improved, and it's important to let them know
why what's been done has been, the sorts of risks that are deemed unacceptable, and what
has been done to minimize the organization's exposure to them.
Security is everybody's business, and only with everyone's cooperation, an intelligent policy,
and consistent practices, will it be achievable.
Involve all stakeholders to ensure smooth, secure change
How can development, operations and security teams collaborate

around change to ensure security is maintained and even
improved?
In smaller companies, there is typically just one person looking after IT and its security, while
others in the firm will undertake software or application development on an ad-hoc basis.
Bigger companies will generally have a dedicated development team, operations team
and a dedicated IT security person or team.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Maintaining and/or improving security during change can be a challenge – and the
challenge is the same for companies of all sizes.
The following key points must be covered when addressing security matters during change
and on an ongoing basis.
First, ensure that both the security people and the operations people are involved with any
project from its inception. It is easier, cheaper and far more effective to build security in from
the beginning rather than add it later, like a sticking plaster.
Also ensure that the business is involved. After all, the end product should be what the
business actually wants, not what it is believed to want. A change of application design at
the last minute because a desired feature was missing can have an adverse impact on an
application's security and/or manageability.
Second, ensure there is a formal change management process that involves all stakeholders
and captures all changes. In other works, a project should not be able to bypass the change
management process because a project board has authorised it for deployment.
Third, ensure that the development area implements the same patches on the same cycle
as the main business and, of course, ensure that security patching is up to date and not
running months in arrears.
Fourth, ensure that, in any change involving a new piece of software or an application
where issues were encountered during its installation, that these issues are documented and
discussed by all stakeholders at the earliest opportunity to identify improvements in either the
development or deployment process.
Finally, establish and maintain regular meetings (monthly recommended), which can be
informal, between security, operations, development and business. The purpose of these
meetings is to exchange ideas, discuss industry happenings such as new products and
security briefings, discuss potential new business areas and what that might mean in terms of
development work, and to discuss any issues identified in the previous period.
How can development, operations and security teams collaborate

around change to ensure security is maintained and even
improved?
‘Collaboration’ is a buzzword in the world of cyber security. International collaboration is

seeing countries working together to successfully bring down cyber terrorists and hackers.
Domestic collaboration is seeing leading businesses and governments striving to implement
common cyber security practices such as ISO27001, PCI-DSS and Cyber Essentials.
So, if we can all work so well together on a macro level, why is it we seem to struggle at the
micro level with our own internal teams? Whether it is for digital transformation, operating
tmg.edu.au | 1300 888 TMG (1300 888 864)
system upgrades, new networks, acceptable use policies changes or just introducing a new
user, collaboration is a key factor to the success of any project and ensures the security of
information assets stored, managed or processed as part of that activity.
Yet still we do not seem to be singing from the same hymn sheet as our colleagues. So where
do the challenges lie?
When data is compromised, it is often because security has not been considered as part of
the change and configuration management framework. We build secure technological
infrastructures and conduct penetration testing to identify vulnerabilities, but there is often no
ongoing security maintenance – and security failures ensue. Failures can be put down to a
number of inherent issues:
 Disparate systems with no oversight or joined up management;

 Slow change management leading to processes being circumnavigated, ignored or
no joined up decision-making;
 Security not built in, but bolted on after the event;
 Legacy thinking rather than agile planning;
 Poor succession planning for legacy platforms;
 Lack of security process maintenance;
 Management out of the loop with corporate protection.
Change and configuration management should be a business-centric process that involves

all appropriate stakeholders and ensures the maintenance and integrity of security controls.
Basically, this means make it secure, check it’s secure and keep it secure.
All stakeholders need to be involved in discussions about business change. Security teams
are often marginalised as they are seen as ‘trouble-makers’, when in reality they are business
enablers helping create secure environments and improve asset protection. When
collaboration does not occur, that is when breaches occur.
Security needs to change its mindset and be more flexible, working in harmony with the
business needs and ways of working – agile working rather than the traditional ‘waterfall’
approach where projects are managed by timescales and milestones. Even if we are
working in an agile, iterative manner, this does not mean always mean we do governance
and change management right.
Indeed, the definition of ‘done right’ should always include elements of security, change
management and testing.
In the same vein, Business needs to change its mindset and embrace security, understanding
that it is there to deliver a business-centric service to realise benefits, enable business and
ensure that change is introduced in a logical, safe and, most importantly, risk-managed
manner.
tmg.edu.au | 1300 888 TMG (1300 888 864)
In short, when all teams collaborate, security will be successfully maintained and ultimately
improved as teams become more security-conscious and embed it as part of business as
usual change management processes.
Activity 3
In a small to medium size enterprise, who would you consult with to identify the security
requirements in an advanced network server environment and why?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 3
Analyse and review existing client security documentation and predict network service
vulnerabilities
Linux Server and Network Security
The most dangerous threat to internal networks are Internet gateways. Gateways are systems
(or other hardware devices) with a minimum of two network interfaces where one interface
is connected to the Internet (via an ISP connection) and at least one interface is connected
to an internal LAN segment. Just as a gateway allows traffic to go out from your LAN onto the
Internet, it also allows traffic from the Internet onto your LAN. The trick is to only let the traffic
you want onto your LAN, and it's no easy feat.
You could be legally liable if someone hacks their way into your LAN and steals confidential
tmg.edu.au | 1300 888 TMG (1300 888 864)
data (social security numbers, credit card numbers, etc) that you maintain on your clients or
customers. Worms or trojans could be planted that send passwords or other sensitive
information out onto the Internet to a waiting sniffer. The risks are many and the
consequences could threaten the very existence of your company. It's not uncommon for
large institutions like banks and insurance firms to decline pressing charges against a hacker
simply because they don't want the negative press and loss of confidence they would suffer
as the result of a public prosecution by a district attorney.
"Multi-homed" (multi-connection) systems such as gateways are not the only security risk. A
server that is only connected to the Internet, such as a Web server, is also at risk of being
hacked. You may not care if some hacker cracks his way in and defaces your Web pages.
You just reload the pages. But there are other, more hideous, attacks that are not
uncommon:
 Your server can be used as a base from which attacks on other systems can be
launched.
 Your e-mail server could be used as a relay for spammers.
 Your system can be surreptitiously used as an IRC (chat) server or for some other
band-width intensive application that steals performance from both your server and
your Internet connection.
 Your could be the target of DoS (Denial of Service) attacks which renders your servers
(e-mail or Web), and your Internet connection, useless.
 Internet servers that use SSL to collect sensitive information such as credit card
numbers or account numbers and passwords can be targets of hackers in order to try
and gain access to the devices where this data is stored. (SSL only protects in-transit
HTTP traffic. It does nothing for operating system or server security.)
Addressing security issues is one of those cases where "an ounce of prevention is worth a
pound of cure". A hacker could do untold damage if they get into your system or network.
And because hackers learn their trade in underground electronic communities, if one finds a
way into your system you can bet that they'll let everyone else know about it.
If your company has public address space with an available IP you may want to try a little
test just for grins. Do a full-boat install of Debian (including all Internet-related apps you can
think of) and put the system on the Internet. It doesn't need a domain name with a DNS
record, just a static public IP address. Set it up with the Apache, Sendmail, wu_ftpd, telnet,
and any other services running and just leave it sit there. Check the /var/log/messages file
every week or so and see how long it takes for the hackers to find it and start playing around
with it. When I tried this they took all of two weeks. Since there's no way of telling what they
did during their visits, you'd be wise to totally wack the partitions on the hard-drive and do an
install from scratch when you do want to re-use the system as a production server.
Setting up a system like this is actually a new security tool that's emerging. It's called setting
up a "honey-pot". The hackers are drawn to the the honey-pot because it's the most
responsive, and are drawn away from your production servers. Before you deploy your
tmg.edu.au | 1300 888 TMG (1300 888 864)
honey-pot you may want to hang a tape drive on the system and do a full backup so you
can go back to square one once it gets compromised. Again, thre's no way to really know
everything that a hacker may have done to your system once they get in so the only safe
thing to do is start over. Monitoring your honey-pot on a regular basis will let you know when
things are happening so you can keep an even closer eye on your production servers.
Don't always assume that the "untrusted" network you're trying to protect yourself from is the
Internet. If you have VPNs or other types of network connectivity established with business
partners or even other divisions within the same company, you must be watchful for
unauthorized access attempts from these networks as well. "Trust no one" is a good rule to
follow when it comes to system and network security.
Organizations use local area networks and wide area networks to communicate with
multiple mail servers as well as Web servers. Network hackers are always on the prowl to
attack an organization's network. Although these attacks mostly take place at major
financial institutions, government agencies and pharmaceutical companies, that does not
mean that an organization that deals in any other business is free from the network hacker.
A patient network hacker would not compromise the network servers during normal
working hours. He will usually launch an attack between 9 p.m. and 6 a.m., reducing the
likelihood of anyone knowing about the attack. This gives the network hacker more time to
apply sniffers and backdoors on the network hosts without having to worry about the
presence of system administrators. Here are some areas that are mostly targeted by
hackers: A hacker can apply social engineering to gain confidential information from
companies by pretending to be an employee and calling other employees to gain useful
information.
 Mail Servers are common targets when hackers want to gain access to network
resources. Companies that access e-mail from the Internet, especially, are
potential targets. To prevent a mail server from being attacked, ensure that the
latest security patch is applied to both the operating system and the e-mail
application.
 Network hackers scan for vulnerabilities in a firewall that is not configured properly
or does not have proper configuration updates. A properly configured firewall is
one measure that can prevent a hacker from attacking a network.
 Filtering routers are also another main source targeted by hackers with aggressive
SNMP scanners. If an attack is effective, the router can easily be turned into a
bridge, thus allowing unauthorized access to the network.
 Network hackers can also intercept data transmitted over the network to mail
servers. Network administrators can prevent this from occurring by using 128-bit key
encryption when transferring information over the Internet or to mail servers.
Today's state-of-the-art network security appliances do a great job of keeping the cyber
monsters from invading your business. But what do you do when the monster is actually inside
the security perimeter? Unfortunately, all of the crosses, garlic, wooden stakes and silver
tmg.edu.au | 1300 888 TMG (1300 888 864)
bullets in the world have little effect on today's most nefarious cyber creatures. Here are the
top 10 ways your network can be attacked from inside and what you can do to insure your
business never has to perform an exorcism on your servers.
1. USB thumb drives: Believe it or not, USB drives are actually one of, if not the most, common
ways you can infect a network from inside a firewall. There are several reasons for this; they're
inexpensive, small, hold a lot of data and can be used between multiple computer types.
The ubiquity of thumb drives has driven hackers to develop targeted malware, such as the
notorious Conficker worm, that can automatically execute upon connecting with a live USB
port. What's worse is that default operating system configurations typically allow most
programs (including malicious ones) to run automatically. That's the equivalent of everyone
in your neighborhood having an electric garage door opener and being able to use it to
open everyone else's garage doors.
What to do: Change the computer's default autorun policies.
Activity 4
How can autorun policies cause a network vulnerability?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 4
2. Laptop and netbooks: Laptops are discreet, portable, include full operating systems, can
operate using an internal battery and come with a handy Ethernet port for tapping directly
into a network. What's more, a notebook may already have malicious code running in the
background that is tasked to scour the network and find additional systems to infect. This
notebook could belong to an internal employee or guest who's visiting and working from an
open cube or office.
Beyond infected laptops compromising an internal network, it's important to think about the
laptops themselves. All companies have some forms of sensitive information that absolutely
cannot leave the walls of the building (salary information, medical records, home addresses,
phone numbers and Social Security numbers are just a few obvious examples). It becomes
very dangerous when that information is stored on an unsecured portable computer, as they
are easy to walk off with. We've seen numerous, publicly disclosed instances of notebooks
tmg.edu.au | 1300 888 TMG (1300 888 864)
with sensitive data that have "gone missing." Unless the laptop employs a tough encryption
algorithm, data is often easy to recover from any given file system.
What to do: Implement an encrypted file system for sensitive data. There are a number of off-
the-shelf solutions out there to choose from, along with open source ones such as TrueCrypt.
Control over endpoints that enter and exit the internal system is also important. Sensitive
information, such as VPN, DV and Wi-Fi access should not be stored persistently on devices
such as laptops or netbooks.
3. Wireless access points: Wireless APs provide immediate connectivity to any user within
proximity of the network. Wireless attacks by wardrivers (people in vehicles searching for
unsecured Wi-Fi networks) are common and have caused significant damage in the past. TJ
Stores, owners of Marshalls and TJMaxx, was attacked using this method, and intruders
penetrated the company's computer systems that process and store customer transactions
including credit card, debit card, check and merchandise return transactions. It's been
reported that this intrusion has cost TJ Stores more than $500 million dollars to date.
Wireless APs are naturally insecure, regardless if encryption is used or not. Protocols such as
wireless encryption protocol contain known vulnerabilities that are easily compromised with
attack frameworks, such as Aircrack. More robust protocols such as wireless protected
access (WPA) and WPA2 are still prone to dictionary attacks if strong keys are not used.
What to do: WPA2 Enterprise using RADIUS is recommended along with an AP that is capable
of performing authentication and enforcing security measures. Strong, mixed passwords
should be used and changed on a fairly frequent basis. Generally, wireless APs are
connected for convenience, so it is usually not necessary to have them connected to a
working environment.
4. Miscellaneous USB devices: Thumb drives aren't the only USB-connected devices IT needs
to be wary of. Many devices are also capable of storing data on common file systems that
can be read and written to through a USB or similar connection. Since it isn't the primary
function of these devices, they are often forgotten as a potential threat. The fact is, if an
endpoint can read and execute data from the device, it can pose just as much of a threat
as a thumb drive. These devices include digital cameras, MP3 players, printers, scanners, fax
machines and even digital picture frames. In 2008, Best Buy reported that they found a virus
in the Insignia picture frames they were selling at Christmas that came directly from the
manufacturer.
What to do: Implement and enforce asset control and policies around what devices can
enter the environment and when. And then follow that up with frequent policy reminders. In
2008, the Department of Defense developed policies and banned USB and other removable
media from entering/exiting their environments.
5. Inside connections: Internal company employees can also inadvertently or intentionally

access areas of the network that they wouldn't or shouldn't otherwise have access to and
compromise endpoints using any of the means outlined in this article. Maybe the employee
tmg.edu.au | 1300 888 TMG (1300 888 864)
"borrows" a co-worker's machine while he's away at lunch. Maybe the employee asks a
fellow worker for help accessing an area of the network that he doesn't have access to.
What to do: Passwords should be changed regularly. Authentication and access levels are a
must for any employee -- he should only have access to systems, file shares, etc. that are
needed to fulfill his duties. Any special requests should always be escalated to a team (not a
single user with authority) who can authorize the request.
6. The Trojan human: Like the Trojan horse, the Trojan human comes into a business in some
type of disguise. He could be in business attire or dressed like legitimate repairman
(appliance, telecom, HVAC). These types of tricksters have been known to penetrate some
pretty secure environments, including server rooms. Through our own social conditioning, we
have the tendency to not stop and question an appropriately attired person we don't
recognize in our office environment. An employee may not think twice about swiping their
access card to allow a uniformed worker into their environment for servicing. It can take less
than a minute for an unsupervised person in a server room to infect the network.
What to do: Reminders should be sent to employees about authorizing third parties. Identify
the source by asking questions, not making assumptions.
7. Optical media: In June 2010, an Army intelligence analyst was arrested after being
charged with stealing and leaking confidential data to public networks. Sources claim the
analyst did so by bringing in music CDs labeled with popular recording artists, using this
medium only as a guise. Once he had access to a networked workstation, he would access
the classified information he had authorized credentials for and store the data on the "music"
CDs in encrypted archives. To help cover his tracks, the analyst would lip sync to the music
that was supposedly stored on the CDs while at his workstation. Recordable media that
appear to be legitimate can and has been used to piggyback data in and out of networks.
And, like the thumb drives mentioned above, they can be used as a source for network
infection.
What to do: As with the USB tip, it's important to implement and enforce asset control and
policies around what devices can enter the environment and when. And then follow that up
with frequent policy reminders.
8. Hindsight is 20/20: While much of this list focuses on mitigating threats that capitalize on
digital technology, we shouldn't forget that the human mind is also very effective at storing
information. Who is watching you when you log into your desktop? Where are your hard
copies stored? What confidential documents are you reading on your laptop at the coffee
shop, airplane, etc.?
What to do: The best safeguard is being conscious and alert about this threat whenever
working on sensitive material -- even if it means stopping what you're doing momentarily to
observe your surroundings.
tmg.edu.au | 1300 888 TMG (1300 888 864)
9. Smartphones and other digital devices: Today, phones do more than just allow you to call
anyone in the world from anywhere; they're full-functioning computers, complete with Wi-Fi
connectivity, multithreaded operating systems, high storage capacity, high-resolution
cameras and vast application support. And they, along with other portable tablet-like
devices, are starting to be given the green light in business environments. These new devices
have the potential to pose the same threats we've seen with notebooks and thumb drives.
What's more, these devices also have the potential to elude traditional data-leak prevention
solutions. What's to stop a user from taking a high-resolution picture of a computer screen,
and then e-mailing it over a phone's 3G network?
What to do: The same rules for USB devices and optical media apply here. Implement and
enforce asset control and policies around what devices can enter the environment and
when.
10. E-mail: E-mail is frequently used within businesses to send and receive data; however, it's
often misused. Messages with confidential information can easily be forwarded to any
external target. In addition, the e-mails themselves can carry nasty viruses. One targeted e-
mail could phish for access credentials from an employee. These stolen credentials would
then be leveraged in a second-stage attack.
What to do: With e-mail security, source identification is key. Identify the sender using
technology such as PGP, or a simple array of questions before sending sensitive information.
Access control to broad alias-based e-mail addresses should be enforced. And policy and
reminders should be sent out to employees.
Identifying Vulnerabilities and Risks on Your Network
A vulnerability is a weak spot in your network that might be exploited by a security threat.
Risks are the potential consequences and impacts of unaddressed vulnerabilities. In other
words, failing to do Windows Updates on your Web server is vulnerability. Some of the risks
associated with that vulnerability include loss of data, hours or days of site downtime and
the staff time needed to rebuild a server after it’s been compromised.
Key Actions
 Understand common attacks. Attacks on and within your network come in many
different varieties. Many times the attackers do not even know who they are
attacking, but there are instances of networks or organizations that are specifically
tmg.edu.au | 1300 888 TMG (1300 888 864)
targeted. Learning the different methods used to compromise computers and

networks will give you the necessary perspective to proceed.
 Inventory your vulnerabilities. Establish a full list of potential vulnerabilities. Take
special care to identify anything unknown about your network. For example, a
library new to network security might think they have a “firewall” while they might
just have a router provided by their ISP.
 Use vulnerability scanning tools. Many tools exist to check the existing security state
of your network. These tools check for open ports, unpatched software and other
weaknesses. Some of these programs focus on a specific machine, while others
can scan your entire network. Microsoft offers one such tool, the Microsoft Baseline
Security Analyzer. This tool checks for updates and common configuration errors for
Microsoft products. Nmap is another popular, free scanning program. For more
about Nmap and other vulnerability scanning tools.
 Assess the risks. The various vulnerabilities on your network represent potential costs
— time, money and assets — to your library. These costs, along with the chance
someone will exploit these vulnerabilities, help determine the level of risk involved.
Risk assessment is a combination of both quantifying (the cost of the threat) and
qualifying (the odds of the attack). Each library will have to determine its own
tolerance for risk depending on the situation. Some examples are provided here.
o Patron information: Having your patron data compromised is unacceptable
for any library. You would need to design your network and implement
security to minimize this risk. While you can almost never remove risk
completely, you can reduce risk to very low levels.
o Slow Internet connection: A library shares an Internet connection between
public networks and staff networks. Since the cost of adding another
Internet connection, increasing the speed of the current connection or
purchasing complex network monitoring equipment might be too
prohibitive, the library has a higher tolerance for a periodically slow Internet
connection. Another library hosts its own Web site, online catalogue and
email server, which require a more stable Internet connection, so a much
lower tolerance for this risk exists.
Where and How to Find Vulnerabilities

POSSIBLE WHAT TO CONSIDER
VULNERABILITIES
Patrons can access Use your networking equipment (e.g., router, switch, firewall) to
the staff network create separate sub-networks for patron computing and staff
computing. Network administrators often use Virtual LANs (VLANs)
and firewalls to accomplish this. This step is especially important if
you have a wireless network for patrons. Some of those laptops
will be riddled with viruses and malware. Also, while most patrons
have no interest in hacking your network, there's no point in
tempting them
tmg.edu.au | 1300 888 TMG (1300 888 864)

VULNERABILITIES
You don't have control Where do you keep your patron data, circulation records,
of critical data financial documents, staff documents and critical databases?
Make sure you have a list of all the mission-critical data
collections in your library, where they're stored, how they're
backed up and who has access to them.
You haven't secured Devices that connect directly to the Internet must be secured.
your servers Do you have servers (e.g., Web servers or email servers) exposed
to the Internet or your public network? Have the servers been
"hardened" by removing all unnecessary applications, services
and user accounts? You should not have a Web server that has
additional services running beyond what it needs to complete its
primary function. The exact steps for hardening a server depend
on your configuration, but you should look for advice and see if
there are any software tools that might help (e.g., the Microsoft
Baseline Security Analyzer).
You aren't taking basic All PCs should have the latest operating system updates, the
precautions latest software patches and up to date virus definitions. As much
as possible, try to automate these updates so they aren't
forgotten.
You haven't paid Who has the keys to your building? Are there locks on your server
attention to physical room? Who has keys to that room? Do you have any computers
security in far-off corners of the library where your staff has a hard time
seeing them? If you check out laptops and other equipment to
the public, have you thought about theft prevention?
You aren't backing up
critical data on a
regular basis
You aren't testing your We've heard a few horror stories about libraries who thought they
backups had backups, only to find that the backup tapes were blank or
unusable.
You're using weak
passwords
You have not Many surveys show that internal security breaches are the most
addressed possible common type. Departing, bored and disgruntled employees are
internal security potential problems that we sometimes overlook. Design your
threats network with limited and appropriate access. Create policies
regarding the process for changing of passwords. When an
employee leaves, delete or suspend their user accounts
immediately.
Your staff doesn't Social engineering is a technique that hackers use to trick people
understand the risks of into divulging private, secure information. It's still one of the
social engineering leading causes of security breaches. For example, an employee
might receive a phone call from someone who claims to work for
your Internet service provider or other technical support. The
tmg.edu.au | 1300 888 TMG (1300 888 864)

VULNERABILITIES
caller says that he's fixing a problem and needs the user's
password to test a possible solution. The employee hands over
the information without verifying the caller's identity.
One of the key elements of that is testing the network for vulnerabilities, whether they are
open ports, unpatched software or something else. A full network scan is also a good way to
ensure a business can inventory everything connected to it, as even devices can and do
provide security weak points.
Ensuring the prolonged security of the network is a multi-step process. First, companies should
look into a vulnerability scanner. There are many options available, both free and paid-for.
However, as is so often the case, the paid-for versions tend to have more features and offer
better support.
The vulnerability scanner will identify open ports and IP addresses in use, as well as operating
systems and software. It will then compare what it has discovered against its database of
known vulnerabilities and report back. Generally, vulnerabilities will be presented on a risk
scale, from low risk to high risk.
It is up to the business to then verify whether the vulnerabilities are in fact dangerous, rather
than a false positive or a port that has been intentionally left open, for example.
It is crucial to assess the potential risk to the business from each vulnerability and the
likelihood of that vulnerability being used as an attack vector. It is also important to look at
how easy it would be to fix. Some will be as easy as patching software, but others may
require a more in-depth and time-consuming fix.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network security: Common threats, vulnerabilities, and mitigation techniques
It will be good if the networks are built and managed by understanding everything. The
problem is that there are users who are familiar and who stole the data, embarrass the
company and will confuse everything. It needs little effort to fight against with the threats
on the computers and networks. The vulnerability will make the threat as reality and helps
to mitigate that threats are discussed below. It includes wireless network security, threats
and mitigation techniques which helps perform better.
Wireless
Nowadays, due to its popularity and wide range of advantage the wireless plays
important role everywhere from large organizations to individual personal use computer
and networks. Here listed below are some of the threats which are specific to the wireless
networks to recognize and to mitigate the threats.
War driving
The war driving is an act of searching for the wireless network in the moving vehicles with
the help of the PDA or portable computer. It introduce with the earliest of the wireless
network because it was more popular among many organizations are also setting this
wireless network that they really did not know to secure it. To keep the wireless network
more secure, implement the measures which needed for the wireless network.
War chalking
In the year 2002, a group of people developed the series of symbol which indicates that a
network was nearby as well as whether it was unsecure, secure, protected by the WEP.
They marked the symbols onto the street sign or wall to indicate the network location. This
method has gone away and the people started using Wi-Fi when it need and various cell
phones are looking for it.
tmg.edu.au | 1300 888 TMG (1300 888 864)
WEP cracking
The wireless network, which is protected by the WEP is not secure as per today's
technology. All the attackers have to determine a WEP key and it can be done in a
fraction of a second. Once the attacker determined the key, then he can get into the
system and also monitor the traffic or can take the administrator's role and change the
settings.
WPA cracking
The WPA is the one which uses the security mechanism is known as temporal key integrity
protocol. There are ways that the experienced and determined attacker can also decrypt
the incoming traffic to the computers using WPA with the TKIP. It is not a secure option
anymore and make use of the WPA2 with the AES for the secure network.
Evil twin
An evil twin is the bogus type Wi-Fi connection which fools users that believing that it is the
legitimate connections to phishing attacks as well as exploitation of the data transaction
purposes. These kinds of attacks are more common, it is necessary to aware of it and
guard against it. It will affect it professionally and personally. Protect computer or network
against the evil twin attacks by learning about such attacks. Make use of the VPN with TLS
or SSL to ensure that the all passwords, emails and all sensitive information are encrypted
while transmission. It is better to avoid sending highly sensitive and important information
through wireless networks, which is not 100 % safe.
Rogue access point
The rogue access point is the wireless access point which installed without explicit
permission of a network administration team. It creates the potential for the man in the
middle attack where the security of a network has breached. To avoid the installation of
the rogue access points, monitors the network for the newly installed access point with the
help of wireless intrusion prevention system that will detect changes in a radio spectrum
which indicate the new access point is operational and installed. Most of these systems will
take automatic countermeasures by identifying a rogue and redirecting the traffic away
from that.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Attacks:
The security threat to the network can be the attacker who attempts to grasp information
to exploit the network vulnerability. This kind of attack is also known as passive attack. On
the other hand, the attacker is attempting to disrupt the network communication and also
affect the user productivity of a network. It is also known as an active attack. Here listed
below are some of the most common types of the security threats.
DoS
The DOS- denial of service attack overwhelms the network host with the stream of bogus
data which keep it to process the designed data. The DoS attacks will be launched
against the computers and against the network devices. The DoS attack is the security
threat which implies that the larger attacks are in progress. Then the DoS attack is a part of
the attack that the hijacks communication from the user who already authenticated to
the resource. When the users computers are blocked by a DoS attack, then the attacker
access the resource and receive the needed information and returns the control to a user
who does not know what occurred in it.
DDoS
The distributed denial of service is the attack occurs when the multiple system is used to
flood the resources or bandwidth of a group of servers or one server. The main purpose of
this attack is to saturate a resource so that it is not available longer for the legitimate use. It
is used as the decoy to hide more malicious attack which attempts to steal sensitive
information or other data. The specialized software called DDS can able to block the
traffic that has a legitimate content but the bad intent.
Man in the middle
The man in the middle attack occurs when the person keep a logical connection or
equipment between 2 communicating parties. These 2 communicating parties assume
tmg.edu.au | 1300 888 TMG (1300 888 864)
they are directly communicating with each other, but the information is being sent to a
man in the middle who forwards it to the proposed recipient. This attack is very harmful to
the organizations. Most of the organizations will adopt measures such as strong
authentication as well as latest protocols, including IPSec/L2TP with the tunnel endpoint
authentications.
Social engineering
A social engineering attacks are not relying on technology or protocols to succeed, but
instead it relies on the human nature. Users generally trust each other and where the this
type of attacks start. It may comprise of false sites that ask for the information from the
unsuspecting web surfers. And this type of attack is known as phishing. A social
engineering attacks might be prevented by just training the users not to provide their
credentials who asks for the information on the web page.
Virus
The computer virus is the program which can infect the computer and copy itself without
user knowledge. These viruses started infecting the computers in 1980 itself and also
continued to evolve till date. Some of the viruses are able to change after it infects the
computers to try to hide from the antivirus software. As the viruses changed over the years
and years, companies like McAfee and Symantec have specialized in the software, which
can eradicate and detect viruses from the computer system. There are nearly more than
76,000 known viruses and users can eradicate it by updating the antivirus software up to
date on all the clients and servers.
Worms
The worm is the something different from the viruses, it is just a program and just not an
infestation. These worms will use a computer network to send worm copies to the other
computers without the user's knowledge. They are proposed to cause network problem
such as resource utilization and bandwidth issues. The most famous worms such as sobig
and mydoom worms have affected more thousands of servers and computers in the past.
You can prevent the spread by maintaining the servers and clients up to date with latest
security patches.
Buffer overflow
The buffer overflow is the attack created anomaly by the rogue program when writing
data to the buffer intentionally overwrite the buffer memories and the adjacent memory. It
may result in memory errors and erratic behavior and a crash or breach of the system
tmg.edu.au | 1300 888 TMG (1300 888 864)
security. Make use of the products like ProPolice and Stackguard to prevent the buffer
overflow attack from succeeding.
Packet sniffing
The attacker can use the protocol analyzer to launch the attack by the packet sniffing.
This is the process in which an attacker gathers the data sample with a software or
hardware device which allows data inspection at a packet level. The attacker may see
the IP addresses, unencrypted passwords, sensitive data and MAC addresses. After a
vulnerability is discovered, the attacker will begin an active attack. The perfect method to
prevent this attack is to forbid anything except the trusted network administrators from
placing the packet analyzer on a network. Most of the packet analyzers can identify the
presence of the packet analyzer, unless an attacker uses software to make the attack
invisible.
FTP bounce
An FTP bounce attack is the legacy attack that will not work well on the FTP software. It
uses the port command to indirectly request access through a victim machine. At once in
a a port, an attacker can gain information or else disrupt network communication.
Smurf
The smurf attack exploits the common network toll such as ping. To prevent this smurf
attack, just install the recent security patches. This patch will avoid any network host to
ping the own broadcast addresses. It will stop the smurf attack.
Mitigation techniques:
Take a deep look to protect against the threats. The mitigate techniques and methods are
mainly depends upon the type of threats. Listed below are some of the mitigation
techniques:
Training and awareness
It is considered as the most convenient and comfortable form of security. User training is
considered as the least expensive and most effective mitigation techniques. It is the best
way to keep the users from making mistakes that will lead to a success of the social
engineering attack is educating how to handle them. It is important to know the
tmg.edu.au | 1300 888 TMG (1300 888 864)
procedures, protocols and policies for the security of a network. Or else training users give
a real advantage of the relatively low cost.
Patch management
When an application or an operating system is released, it is not perfect from the security
perspective. Then after the release, updates and security patches are released on the
ongoing basis, which can add to a software to make them more secure or provide it more
functionality. The windows update systems which are installed in the latest servers and
clients can be configured to install as well as download the patches automatically from
the site. The windows server update services to download the patches to servers and then
test it before applying to the bulk of the clients on the network.
Policies and procedures
The security procedures and policies must be outlined clearly in writing in the organization.
It should define acceptable behaviors on networks and organization computers. Who uses
the computers has to read the procedures and policies and also sign the form for
agreeing it.
Incident response
When the intruder has enacted an attack on the network, then the first instinct gets the
user back to work regardless of what that takes. It makes a more sense in the short run, but
in case of long run it might be a wrong move. The reinstall software which is damaged by
the attack, then this re-installation may cover the track of an attacker and prevent it from
prosecuting and finding it.
It is essential to understand the security threats which affect the networks. And be familiar
with the affecting networks like DoS attacks, worms, viruses, smurf, social engineering and
man in the middle attacks. It is necessary to learn each type of these attacks operates
and how to secure it. Additionally, understand the mitigation techniques such as incident
response, procedure and policies, patch management and training and awareness.
Understand efficient and effective method of protecting against the social engineering
threats and also other network weaknesses. Understand the security patches must be used
to update the applications and operating systems.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 5
Describe one way to predict network service vulnerabilities.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Research network authentication and network service configuration options and implications
to produce network security solutions
Authentication
Authentication is the process of determining whether someone or something is, in fact, who
or what it is declared to be.
Logically, authentication precedes authorization (although they may often seem to be

combined). The two terms are often used synonymously but they are two different processes.
Authentication vs. authorization
Authentication is a process in which the credentials provided are compared to those on file
in a database of authorized users’ information on a local operating system or within an
authentication server. If the credentials match, the process is completed and the user is
granted authorization for access. The permissions and folders returned define both the
environment the user sees and the way he can interact with it, including hours of access and
other rights such as the amount of allocated storage space.
The process of an administrator granting rights and the process of checking user account
permissions for access to resources are both referred to as authorization. The privileges and
preferences granted for the authorized account depend on the user’s permissions, which are
either stored locally or on the authentication server. The settings defined for all these
environment variables are set by an administrator.
User authentication vs. machine authentication
User authentication occurs within most human-to-computer interactions other than guest
accounts, automatically logged-in accounts and kiosk computer systems. Generally, a user
has to enter or choose an ID and provide their password to begin using a system. User
authentication authorizes human-to-machine interactions in operating systems and
applications as well as both wired and wireless networks to enable access to networked and
Internet-connected systems, applications and resources.
Machines need to authorize their automated actions within a network too. Online backup
services, patching and updating systems and remote monitoring systems such as those used
in telemedicine and smart grid technologies all need to securely authenticate to verify that it
is the authorized system involved in any interaction and not a hacker.
Machine authentication can be carried out with machine credentials much like a users’ ID
and password only submitted by the device in question. They can also use digital certificates
issued and verified by a Certificate Authority (CA) as part of a public key infrastructure to
prove identification while exchanging information over the Internet, like a type of digital
password.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The importance of strong machine authentication
With the increasing number of Internet-enabled devices, reliable machine authentication is

crucial to allow secure communication in home automation and other networked
environments. In the Internet of things scenario, which is increasingly becoming a reality,
almost any imaginable entity or object may be made addressable and able to exchange
data over a network. It is important to realize that each access point is a potential intrusion
point. Each networked device needs strong machine authentication and also, despite their
normally limited activity, these devices must be configured for limited permissions access as
well, to limit what can be done even if they are breached.
Password-based authentication
In private and public computer networks (including the Internet), authentication is commonly
done through the use of login IDs (user names) and passwords. Knowledge of the login
credentials is assumed to guarantee that the user is authentic. Each user registers initially (or is
registered by someone else, such as a systems administrator), using an assigned or self-
declared password. On each subsequent use, the user must know and use the previously
declared password. However, password-based authentication is not considered to provide
adequately strong security for any system that contains sensitive data.
The problem with password-based authentication:
User names are frequently a combination of the individual’s first initial and last name, which
makes them easy to guess. If constraints are not imposed, people often create weak
passwords -- and even strong passwords may be stolen, accidentally revealed or forgotten.
For this reason, Internet business and many other transactions require a more stringent
authentication process.
Password-based authentication weaknesses can be addressed to some extent with smarter

user names and password rules like minimum length and stipulations for complexity, such as
including capitals and symbols. However, password-based authentication and knowledge-
based authentication (KBA) are more vulnerable than systems that require multiple
independent methods.
An authentication factor is a category of credential used for identity verification. The three
most common categories are often described as something you know (the knowledge
factor), something you have (the possession factor) and something you are (the inherence
factor).
Authentication factors:
 Knowledge factors -- a category of authentication credentials consisting of

information that the user possesses, such as a personal identification number (PIN), a
user name, a password or the answer to a secret question.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Possession factors -- a category of credentials based on items that the user has with
them, typically a hardware device such as a security token or a mobile phone used
in conjunction with a software token.
 Inherence factors -- a category of user authentication credentials consisting of
elements that are integral to the individual in question, in the form of biometric data.
User location and current time are sometimes considered the fourth factor and fifth factor for
authentication. The ubiquity of smartphones can help ease the burdens of multifactor
authentication for users. Most smartphones are equipped with GPS, enabling reasonable
surety confirmation of the login location. Lower surety measures include the MAC address of
the login point or physical presence verifications through cards and other possession factor
elements.
Strong authentication vs. multifactor authentication (MFA)
Strong authentication is a commonly used term that is largely without a standardized

definition. For general purposes, any method of verifying the identity of a user or device that
is intrinsically stringent enough to ensure the security of the system it protects can be
considered strong authentication.
The term strong authentication is often used to refer to two factor authentication (2FA) or
multifactor authentication (MFA). That usage probably came about because MFA is a
widely-applied approach to strengthen authentication. In cryptography, strong
authentication is defined as a system involving multiple challenge/ response answers.
Because such a system involves multiple instances from a single factor (the knowledge
factor), it is an example of single-factor authentication (SFA), regardless of its strength.
Other definitions of strong verification:
In some environments, any system in which the password is not transmitted in the verification
process is considered strong. As defined by the European Central Bank, strong security is any
combination of at least two mutually-independent factors of authentication, which must also
have one non-reusable element that is not easily reproduced or stolen from the Internet.
Although strong authentication is not necessarily multifactor, multifactor authentication

processes have become commonplace for system logins and transactions within systems
with high security requirements.
Two factor (2FA) and three factor authentication (3FA) are becoming common; four factor
(4FA) and even five factor (5FA) authentication systems are used in some high-security
installations. The use of multiple factors increases security due to the unlikelihood that an
attacker could access all of the elements required for authentication. Each additional factor
increases the security of the system and decreases the likelihood that it could be breached.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Authentication in a Linux Environment (Suse Linux Example)
Authentication with PAM
Linux uses PAM (pluggable authentication modules) in the authentication process as a layer
that mediates between user and application. PAM modules are available on a systemwide
basis, so they can be requested by any application. This chapter describes how the modular
authentication mechanism works and how it is configured.
What is PAM?
System administrators and programmers often want to restrict access to certain parts of the
system or to limit the use of certain functions of an application. Without PAM, applications
must be adapted every time a new authentication mechanism, such as LDAP, Samba, or
Kerberos, is introduced. This process, however, is rather time-consuming and error-prone. One
way to avoid these drawbacks is to separate applications from the authentication
mechanism and delegate authentication to centrally managed modules. Whenever a newly
required authentication scheme is needed, it is sufficient to adapt or write a suitable PAM
module for use by the program in question.
The PAM concept consists of:
 PAM modules, which are a set of shared libraries for a specific authentication
mechanism.
 A module stack with of one or more PAM modules.
 A PAM-aware service which needs authentication by using a module stack or PAM
modules. Usually a service is a familiar name of the corresponding application, like
login or su. The service name other is a reserved word for default rules.
 Module arguments, with which the execution of a single PAM module can be
influenced.
 A mechanism evaluating each result of a single PAM module execution. A positive
value executes the next PAM module. The way a negative value is dealt with,
depends on the configuration—no influence, proceed up to terminate immediately
and anything in between are valid options.
Structure of a PAM Configuration File
PAM can be configured in two ways:
File based configuration (/etc/pam.conf)
The configuration of each service is stored in /etc/pam.conf. However, for

maintenance and usability reasons, this configuration scheme is not used in SUSE Linux
Enterprise Server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Directory based configuration (/etc/pam.d/)
Every service (or program) that relies on the PAM mechanism has its own
configuration file in the /etc/pam.d/ directory. For example, the service for sshd can
be found in the /etc/pam.d/sshd file.
The files under /etc/pam.d/ define the PAM modules used for authentication. Each file
consists of lines, which define a service, and each line consists of a maximum of four
components:
TYPE
CONTROL
MODULE_PATH
MODULE_ARGS
The components have the following meaning:
TYPE
Declares the type of the service. PAM modules are processed as stacks. Different
types of modules have different purposes. For example, one module checks the
password, another verifies the location from which the system is accessed, and yet
another reads user-specific settings. PAM knows about four different types of
modules:
auth
Check the user's authenticity, traditionally by querying a password. However, this can
also be achieved with the help of a chip card or through biometrics (for example,
fingerprints or iris scan).
account
Modules of this type check if the user has general permission to use the requested
service. As an example, such a check should be performed to ensure that no one
can log in with the username of an expired account.
password
The purpose of this type of module is to enable the change of an authentication

token. In most cases, this is a password.
session
tmg.edu.au | 1300 888 TMG (1300 888 864)
Modules of this type are responsible for managing and configuring user sessions. They
are started before and after authentication to log login attempts and configure the
user's specific environment (mail accounts, home directory, system limits, etc.).
CONTROL
Indicates the behavior of a PAM module. Each module can have the following
control flags:
required
A module with this flag must be successfully processed before the authentication
may proceed. After the failure of a module with the required flag, all other modules
with the same flag are processed before the user receives a message about the
failure of the authentication attempt.
requisite
Modules having this flag must also be processed successfully, in much the same way
as a module with the required flag. However, in case of failure a module with this flag
gives immediate feedback to the user and no further modules are processed. In case
of success, other modules are subsequently processed, just like any modules with the
required flag. The requisite flag can be used as a basic filter checking for the
existence of certain conditions that are essential for a correct authentication.
sufficient
After a module with this flag has been successfully processed, the requesting
application receives an immediate message about the success and no further
modules are processed, provided there was no preceding failure of a module with
the required flag. The failure of a module with the sufficient flag has no direct
consequences, in the sense that any subsequent modules are processed in their
respective order.
optional
The failure or success of a module with this flag does not have any direct
consequences. This can be useful for modules that are only intended to display a
message (for example, to tell the user that mail has arrived) without taking any further
action.
include
If this flag is given, the file specified as argument is inserted at this place.
tmg.edu.au | 1300 888 TMG (1300 888 864)
MODULE_PATH
Contains a full filename of a PAM module. It does not need to be specified explicitly,
as long as the module is located in the default directory /lib/security (for all 64-bit
platforms supported by SUSE® Linux Enterprise Server, the directory is /lib64/security).
MODULE_ARGS
Contains a space-separated list of options to influence the behavior of a PAM

module, such as debug (enables debugging) or nullok (allows the use of empty
passwords).
In addition, there are global configuration files for PAM modules under /etc/security, which
define the exact behavior of these modules (examples include pam_env.conf and
time.conf). Every application that uses a PAM module actually calls a set of PAM functions,
which then process the information in the various configuration files and return the result to
the requesting application.
To facilitate the creation and maintenance of PAM modules, common default configuration
files for the types auth, account, password, and session modules have been introduced.
These are retrieved from every application's PAM configuration. Updates to the global PAM
configuration modules in common-* are thus propagated across all PAM configuration files
without requiring the administrator to update every single PAM configuration file.
The global PAM configuration files are maintained using the pam-config tool. This tool
automatically adds new modules to the configuration, changes the configuration of existing
ones or deletes modules (or options) from the configurations. Manual intervention in
maintaining PAM configurations is minimized or no longer required.
NOTE: 64-Bit and 32-Bit Mixed Installations
When using a 64-bit operating system, it is possible to also include a runtime environment for
32-bit applications. In this case, make sure that you install both versions of the PAM modules.
The PAM Configuration of sshd
Consider the PAM configuration of sshd as an example:
Example 2-1 PAM Configuration for sshd (/etc/pam.d/sshd)
#%PAM-1.0
auth requisite pam_nologin.so
auth include common-auth
account requisite pam_nologin.so
account include common-account
password include common-password
tmg.edu.au | 1300 888 TMG (1300 888 864)
session required pam_loginuid.so

session include common-session
Declares the version of this configuration file for PAM 1.0. This is merely a convention, but
could be used in the future to check the version.
Checks, if /etc/nologin exists. If it does, no user other than root may log in.
Refers to the configuration files of four module types: common-auth, common-account,
common-password, and common-session. These four files hold the default configuration
for each module type.
Sets the login uid process attribute for the process that was authenticated.
By including the configuration files instead of adding each module separately to the
respective PAM configuration, you automatically get an updated PAM configuration when
an administrator changes the defaults. Formerly, you had to adjust all configuration files
manually for all applications when changes to PAM occurred or a new application was
installed. Now the PAM configuration is made with central configuration files and all changes
are automatically inherited by the PAM configuration of each service.
The first include file (common-auth) calls three modules of the auth type: pam_env.so,
pam_gnome_keyring.so and pam_unix2.so. See Example 2-2.
Example 2-2 Default Configuration for the auth Section (common-auth)
auth required pam_env.so

auth required pam_unix2.so
pam_env.so loads /etc/security/pam_env.conf to set the environment variables as
specified in this file. It can be used to set the DISPLAY variable to the correct value,
because the pam_env module knows about the location from which the login is taking
place.
pam_unix2 checks the user's login and password against /etc/passwd and /etc/shadow.
The whole stack of auth modules is processed before sshd gets any feedback about whether
the login has succeeded. All modules of the stack having the required control flag must be
processed successfully before sshd receives a message about the positive result. If one of the
modules is not successful, the entire module stack is still processed and only then is sshd
notified about the negative result.
As soon as all modules of the auth type have been successfully processed, another include
statement is processed, in this case, that in Example 2-3. common-account contains just one
module, pam_unix2. If pam_unix2 returns the result that the user exists, sshd receives a
message announcing this success and the next stack of modules (password) is processed,
shown in Example 2-4.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Example 2-3 Default Configuration for the account Section (common-account)
account required pam_unix2.so
Example 2-4 Default Configuration for the password Section (common-password)
password requisite pam_pwcheck.so nullok cracklib

password required pam_unix2.so nullok use_authtok
Again, the PAM configuration of sshd involves just an include statement referring to the
default configuration for password modules located in common-password. These modules
must successfully be completed (control flags requisite and required) whenever the
application requests the change of an authentication token.
Changing a password or another authentication token requires a security check. This is

achieved with the pam_pwcheck module. The pam_unix2 module used afterwards carries
over any old and new passwords from pam_pwcheck, so the user does not need to
authenticate again after changing the password. This procedure makes it impossible to
circumvent the checks carried out by pam_pwcheck. Whenever the account or the auth
type are configured to complain about expired passwords, the password modules should
also be used.
Example 2-5 Default Configuration for the session Section (common-session)
session required pam_limits.so

session required pam_unix2.so
session optional pam_umask.so
As the final step, the modules of the session type (bundled in the common-session file) are
called to configure the session according to the settings for the user in question. The
pam_limits module loads the file /etc/security/limits.conf, which may define limits on the use
of certain system resources. The pam_unix2 module is processed again. The pam_umask
module can be used to set the file mode creation mask. Since this module carries the
optional flag, a failure of this module would not affect the successful completion of the entire
session module stack. The session modules are called a second time when the user logs out.
Configuration of PAM Modules
Some of the PAM modules are configurable. The configuration files are located in
/etc/security. This section briefly describes the configuration files relevant to the sshd
example—pam_env.conf and limits.conf.
tmg.edu.au | 1300 888 TMG (1300 888 864)
pam_env.conf
pam_env.conf can be used to define a standardized environment for users that is set
whenever the pam_env module is called. With it, preset environment variables using the
following syntax:
VARIABLE [DEFAULT=value] [OVERRIDE=value]

VARIABLE
Name of the environment variable to set.
[DEFAULT=<value>]
Default value the administrator wants to set.
[OVERRIDE=<value>]
Values that may be queried and set by pam_env, overriding the default value.
A typical example of how pam_env can be used is the adaptation of the DISPLAY variable,
which is changed whenever a remote login takes place. This is shown in Example 2-6.
Example 2-6 pam_env.conf
REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST}

DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
The first line sets the value of the REMOTEHOST variable to localhost, which is used whenever
pam_env cannot determine any other value. The DISPLAY variable in turn contains the value
of REMOTEHOST. Find more information in the comments in /etc/security/pam_env.conf.
pam_mount.conf
The purpose of pam_mount is to mount user home directories during the login process, and
to unmount them during logout in an environment where a central file server keeps all the
home directories of users. With this method, it is not necessary to mount a complete /home
directory where all the user home directories would be accessible. Instead, only the home
directory of the user who is about to log in, is mounted.
After installing pam_mount, a template of pam_mount.conf.xml is available in /etc/security.

The description of the various elements can be found in the manual page man 5
pam_mount.conf.
A basic configuration of this feature can be done with YaST. Select Network Settings >
Windows Domain Membership > Expert Settings to add the file server
tmg.edu.au | 1300 888 TMG (1300 888 864)
limits.conf
System limits can be set on a user or group basis in limits.conf, which is read by the pam_limits
module. The file allows you to set hard limits, which may not be exceeded at all, and soft
limits, which may be exceeded temporarily. For more information about the syntax and the
options, see the comments in /etc/security/limits.conf.
Configuring PAM Using pam-config
The pam-config tool helps you configure the global PAM configuration files
(/etc/pam.d/common-*-pc) as well as several selected application configurations. For a list
of supported modules, use the pam-config --list-modules command. Use the pam-config
command to maintain your PAM configuration files. Add new modules to your PAM
configurations, delete other modules or modify options to these modules. When changing
global PAM configuration files, no manual tweaking of the PAM setup for individual
applications is required.
A simple use case for pam-config involves the following:
1. Auto-generate a fresh Unix-style PAM configuration. Let pam-config create the

simplest possible setup which you can extend later on. The pam-config --create
command creates a simple UNIX authentication configuration. Pre-existing
configuration files not maintained by pam-config are overwritten, but backup copies
are kept as *.pam-config-backup.
2. Add a new authentication method. Adding a new authentication method (for
example, LDAP) to your stack of PAM modules comes down to a simple pam-config --
add --ldap command. LDAP is added wherever appropriate across all common-*-pc
PAM configuration files.
3. Add debugging for test purposes. To make sure the new authentication procedure
works as planned, turn on debugging for all PAM-related operations. The pam-config
--add --ldap-debug turns on debugging for LDAP-related PAM operations. Find the
debugging output in /var/log/messages.
4. Query your setup. Before you finally apply your new PAM setup, check if it contains all
the options you wanted to add. The pam-config --query --module lists both the type
and the options for the queried PAM module.
5. Remove the debug options. Finally, remove the debug option from your setup when
you are entirely satisfied with the performance of it. The pam-config --delete --ldap-
debug command turns off debugging for LDAP authentication. In case you had
debugging options added for other modules, use similar commands to turn these off.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Manually Configuring PAM
If you prefer to manually create or maintain your PAM configuration files, you need to make
sure to disable pam-config for these files.
When you create your PAM configuration files from scratch using the pam-config --create
command, it creates symbolic links from the common-* to the common-*-pc files. pam-
config only modifies the common-*-pc configuration files. Removing these symbolic links
effectively disables pam-config, because pam-config only operates on the common-*-pc
files and these files are not put into effect without the symbolic links.
Using NIS
As soon as multiple UNIX systems in a network access common resources, it becomes

imperative that all user and group identities are the same for all machines in that network.
The network should be transparent to users: their environments should not vary, regardless of
which machine they are actually using. This can be done by means of NIS and NFS services.
NFS distributes file systems over a network.
NIS (Network Information Service) can be described as a database-like service that provides
access to the contents of /etc/passwd, /etc/shadow, and /etc/group across networks. NIS
can also be used for other purposes (making the contents of files like /etc/hosts or
/etc/services available, for example), but this is beyond the scope of this introduction.
People often refer to NIS as YP, because it works like the network's yellow pages.
Configuring NIS Servers
To distribute NIS information across networks, either install one single server (a master) that
serves all clients, or NIS slave servers requesting this information from the master and relaying
it to their respective clients.
 To configure just one NIS server for your network, proceed with Configuring a NIS
Master Server.
 If your NIS master server needs to export its data to slave servers, set up the master
server and set up slave servers in the subnets.
Configuring a NIS Master Server
To configure a NIS master server for your network, proceed as follows:
1. Start YaST > Network Services > NIS Server.

2. If you need just one NIS server in your network or if this server is to act as the master for
further NIS slave servers, select Install and Set Up NIS Master Server. YaST installs the
required packages.
tmg.edu.au | 1300 888 TMG (1300 888 864)
HINT: If NIS server software is already installed on your machine, initiate the creation of
a NIS master server by clicking Create NIS Master Server.
Figure 3-1 NIS Server Setup
3. Determine basic NIS setup options:

1. Enter the NIS domain name.
2. Define whether the host should also be a NIS client (enabling users to log in
and access data from the NIS server) by selecting This Host is also a NIS Client.
3. If your NIS server needs to act as a master server to NIS slave servers in other
subnets, select Active Slave NIS Server Exists.
The option Fast Map Distribution is only useful in conjunction with Active Slave
NIS Servers Exist. It speeds up the transfer of maps to the slaves.
4. Select Allow Changes to Passwords to allow users in your network (both local
users and those managed through the NIS server) to change their passwords
on the NIS server (with the command yppasswd). This makes the options Allow
Changes to GECOS Field and Allow Changes to Login Shell available. GECOS
tmg.edu.au | 1300 888 TMG (1300 888 864)
means that the users can also change their names and address settings with
the command ypchfn. Shell allows users to change their default shell with the
command ypchsh (for example, to switch from Bash to sh). The new shell must
be one of the predefined entries in /etc/shells.
5. Select Open Port in Firewall to have YaST adapt the firewall settings for the NIS
server.
Figure 3-2 Master Server Setup
6. Leave this dialog with Next or click Other Global Settings to make additional
settings.
Other Global Settings include changing the source directory of the NIS server
(/etc by default). In addition, passwords can be merged here. The setting
should be Yes to create the user database from the system authentication
files /etc/passwd, /etc/shadow, and /etc/group. Also, determine the smallest
user and group ID that should be offered by NIS. Click OK to confirm your
settings and return to the previous screen.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 3-3 Changing the Directory and Synchronizing Files for a NIS Server
4. If you previously enabled Active Slave NIS Server Exists, enter the hostnames used as
slaves and click Next. If no slave servers exist, this configuration step is skipped.
5. Continue to the dialog for the database configuration. Specify the NIS Server Maps,
the partial databases to transfer from the NIS server to the client. The default settings
are usually adequate. Leave this dialog with Next.
6. Check which maps should be available and click Next to continue.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 3-4 NIS Server Maps Setup
7. Determine which hosts are allowed to query the NIS server. You can add, edit, or
delete hosts by clicking the appropriate button. Specify from which networks requests
can be sent to the NIS server. Normally, this is your internal network. In this case, there
should be the following two entries:
8. 255.0.0.0 127.0.0.0
9. 0.0.0.0 0.0.0.0
The first entry enables connections from your own host, which is the NIS server. The
second one allows all hosts to send requests to the server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 3-5 Setting Request Permissions for a NIS Server
10. Click Finish to save your changes and exit the setup.
Configuring a NIS Slave Server
To configure additional NIS slave servers in your network, proceed as follows:
1. Start YaST > Network Services > NIS Server.

2. Select Install and Set Up NIS Slave Server and click Next.
HINT: If NIS server software is already installed on your machine, initiate the creation of
a NIS slave server by clicking Create NIS Slave Server.
3. Complete the basic setup of your NIS slave server:

1. Enter the NIS domain.
2. Enter hostname or IP address of the master server.
3. Set This Host is also a NIS Client if you want to enable user logins on this server.
4. Adapt the firewall settings with Open Ports in Firewall.
5. Click Next.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. Enter the hosts that are allowed to query the NIS server. You can add, edit, or delete
hosts by clicking the appropriate button. Specify all networks from which requests can
be sent to the NIS server. If it applies to all networks, use the following configuration:
5. 255.0.0.0 127.0.0.0
6. 0.0.0.0 0.0.0.0
7. The first entry enables connections from your own host, which is the NIS server. The
second one allows all hosts with access to the same network to send requests to the
server.
8. Click Finish to save changes and exit the setup.
Configuring NIS Clients
To use NIS on a workstation, do the following:
1. Start YaST > Network Services > NIS Client.

2. Activate the Use NIS button.
3. Enter the NIS domain. This is usually a domain name given by your administrator or a
static IP address received by DHCP. For information about DHCP.
Figure 3-6 Setting Domain and Address of a NIS Server
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. Enter your NIS servers and separate their addresses by spaces. If you do not know
your NIS server, click on Find to let YaST search for any NIS servers in your domain.
Depending on the size of your local network, this may be a time-consuming process.
Broadcast asks for a NIS server in the local network after the specified servers fail to
respond.
5. Depending on your local installation, you may also want to activate the
automounter. This option also installs additional software if required.
6. If you do not want other hosts to be able to query which server your client is using, go
to the Expert settings and disable Answer Remote Hosts. By checking Broken Server,
the client is enabled to receive replies from a server communicating through an
unprivileged port. For further information, see man ypbind.
7. Click Finish to save them and return to the YaST control center. Your client is now
configured with NIS.
LDAP—A Directory Service
The Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access
and maintain information directories. LDAP can be used for user and group management,
system configuration management, address management, and more. This chapter provides
a basic understanding of how OpenLDAP works and how to manage LDAP data with YaST.
In a network environment it is crucial to keep important information structured and to serve it

quickly. A directory service—like the common yellow pages, keeps information available in a
well-structured and readily-searchable form.
Ideally, a central server stores the data in a directory and distributes it to all clients using a
well-defined protocol. The structured data allow a wide range of applications to access
them. A central repository reduces the necessary administrative effort. The use of an open
and standardized protocol like LDAP ensures that as many different client applications as
possible can access such information.
A directory in this context is a type of database optimized for quick and effective reading
and searching:
 To make multiple concurrent reading accesses possible, the number of updates is

usually very low. The number of read and write accesses is often limited to a few users
with administrative privileges. In contrast, conventional databases are optimized for
accepting the largest possible data volume in a short time.
 When static data is administered, updates of the existing data sets are very rare.
When working with dynamic data, especially when data sets like bank accounts or
accounting are concerned, the consistency of the data is of primary importance. If
an amount should be subtracted from one place to be added to another, both
operations must happen concurrently, within one transaction, to ensure balance over
the data stock. Traditional relational databases usually have a very strong focus on
data consistency, such as the referential integrity support of transactions. Conversely,
tmg.edu.au | 1300 888 TMG (1300 888 864)
short-term inconsistencies are usually acceptable in LDAP directories. LDAP directories

often do not have such strong consistency requirements as relational databases.
The design of a directory service like LDAP is not laid out to support complex update or query
mechanisms. All applications are guaranteed to access this service quickly and easily.
Structure of an LDAP Directory Tree
To get background knowledge on how a LDAP server works and how the data is stored, it is
vital to understand the way the data is organized on the server and how this structure
enables LDAP to provide fast access to the data. To successfully operate an LDAP setup, you
also need to be familiar with some basic LDAP terminology. This section introduces the basic
layout of an LDAP directory tree and provides the basic terminology used with respect to
LDAP. Skip this introductory section if you already have some LDAP background knowledge
and just want to learn how to set up an LDAP environment in SUSE Linux Enterprise Server.
An LDAP directory has a tree structure. All entries (called objects) of the directory have a
defined position within this hierarchy. This hierarchy is called the directory information tree
(DIT). The complete path to the desired entry, which unambiguously identifies it, is called the
distinguished name or DN. A single node along the path to this entry is called relative
distinguished name or RDN.
The relations within an LDAP directory tree become more evident in the following example,
shown in Figure 4-1.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-1 Structure of an LDAP Directory
The complete diagram is a fictional directory information tree. The entries on three levels are
depicted. Each entry corresponds to one box in the image. The complete, valid distinguished
name for the fictional employee Geeko Linux, in this case, is cn=Geeko
Linux,ou=doc,dc=example,dc=com. It is composed by adding the RDN cn=Geeko Linux to
the DN of the preceding entry ou=doc,dc=example,dc=com.
The types of objects that can be stored in the DIT are globally determined following a
Schema. The type of an object is determined by the object class. The object class
determines what attributes the relevant object must or can be assigned. The Schema,
therefore, must contain definitions of all object classes and attributes used in the desired
application scenario. There are a few common Schemas (see RFC 2252 and 2256). The LDAP
RFC defines a few commonly used Schemas (see e.g., RFC4519). Additionally there are
Schemas available for many other use cases (e.g., Samba, NIS replacement, etc.). It is,
however, possible to create custom Schemas or to use multiple Schemas complementing
each other (if this is required by the environment in which the LDAP server should operate).
Table 4-1 offers a small overview of the object classes from core.schema and
inetorgperson.schema used in the example, including required attributes and valid attribute
values.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 4-1 Commonly Used Object Classes and Attributes
Object Class Meaning Example Required

Entry Attributes
dcObject domainComponent (name components of example dc
the domain)
organizationalUnit organizationalUnit (organizational unit) doc ou
inetOrgPerson inetOrgPerson (person-related data for the Geeko sn and cn
intranet or Internet) Linux
Example 4-1 shows an excerpt from a Schema directive with explanations.
Example 4-1 Excerpt from schema.core
attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName')

DESC 'RFC2256: organizational unit this object belongs to'
SUP name )
objectclass ( 2.5.6.5 NAME 'organizationalUnit'

DESC 'RFC2256: an organizational unit'
SUP top STRUCTURAL
MUST ou
MAY (userPassword $ searchGuide $ seeAlso $ businessCategory
$ x121Address $ registeredAddress $ destinationIndicator
$ preferredDeliveryMethod $ telexNumber
$ teletexTerminalIdentifier $ telephoneNumber
$ internationaliSDNNumber $ facsimileTelephoneNumber
$ street $ postOfficeBox $ postalCode $ postalAddress
$ physicalDeliveryOfficeName
$ st $ l $ description) )
...
The attribute type organizationalUnitName and the corresponding object class

organizationalUnit serve as an example here.
The name of the attribute, its unique OID (object identifier) (numerical), and the
abbreviation of the attribute.
A brief description of the attribute with DESC. The corresponding RFC, on which the
definition is based, is also mentioned here.
SUP indicates a superordinate attribute type to which this attribute belongs.
The definition of the object class organizationalUnit begins—the same as in the definition
of the attribute—with an OID and the name of the object class.
tmg.edu.au | 1300 888 TMG (1300 888 864)
A brief description of the object class.

The SUP top entry indicates that this object class is not subordinate to another object
class.
With MUST list all attribute types that must be used in conjunction with an object of the
type organizationalUnit.
With MAY list all attribute types that are permitted in conjunction with this object class.
An introduction to the use of Schemas can be found in the OpenLDAP documentation.

When installed, find it in /usr/share/doc/packages/openldap2/guide/admin/guide.html.
Configuring an LDAP Server with YaST
Use YaST to set up an LDAP server. Typical use cases for LDAP servers include the
management of user account data and the configuration of mail, DNS, and DHCP servers.
Figure 4-2 YaST LDAP Server Configuration
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-3 YaST LDAP Server—New Database
To set up an LDAP server for user account data, make sure the yast2-ldap-server and
openldap2 packages are installed. Then proceed as follows:
1. Start YaST as root and select Network Services > LDAP Server to invoke the
configuration wizard.
2. Configure the Global Settings of your LDAP server (you can change these settings
later)—see Figure 4-2:
1. Set LDAP to be started.
2. If the LDAP server should announce its services via SLP, check Register at an
SLP Daemon.
3. Configure Firewall Settings.
4. Click Next.
3. Select the server type: stand-alone server, master server in a replication setup, or
replication (slave) server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. Select security options (TLS Settings).
It is strongly recommended to Enable TLS.
WARNING: Password Encryption
Enabling TLS ensures passwords are sent encrypted over the network. When this
option is not enabled, passwords are sent unencrypted.
Also consider to use LDAP over SSL and certificates.
5. Confirm Basic Database Settings with entering an LDAP Administrator Password and
then clicking Next—see Figure 4-2.
6. Check the LDAP Server Configuration Summary and click Finish to exit the
configuration wizard.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-4 YaST LDAP Server Configuration
For changes or additional configuration start the LDAP server module again and in the left
pane expand Global Settings to make subentries visible—see Figure 4-4:
1. With Log Level Settings, configure the degree of logging activity (verbosity) of the
LDAP server. From the predefined list, select or deselect the logging options
according to your needs. The more options are enabled, the larger your log files
grow.
2. Configure which connection types the server should offer under Allow/Disallow
Features. Choose from:
LDAPv2 Bind Requests
This option enables connection requests (bind requests) from clients using the
previous version of the protocol (LDAPv2).
tmg.edu.au | 1300 888 TMG (1300 888 864)
Anonymous Bind When Credentials Not Empty
Normally the LDAP server denies any authentication attempts with empty credentials
(DN or password). Enabling this option, however, makes it possible to connect with a
password and no DN to establish an anonymous connection.
Unauthenticated Bind When DN Not Empty
Enabling this option makes it possible to connect without authentication

(anonymously) using a DN but no password.
Unauthenticated Update Options to Process
Enabling this option allows non-authenticated (anonymous) update operations.

Access is restricted according to ACLs and other rules.
3. Allow/Disallow Features also lets you configure the server flags. Choose from:
Disable Acceptance of Anonymous Bind Requests
The server will no longer accept anonymous bind requests. Note, that this does not
generally prohibit anonymous directory access.
Disable Simple Bind Authentication
Completely disable Simple Bind authentication.
Disable Forcing Session to Anonymous Status upon StartTLS Operation Receipt
The server will no longer force an authenticated connection back to the anonymous
state when receiving the StartTLS operation.
Disallow the StartTLS Operation if Authenticated
The server will disallow the StartTLS operation on already authenticated connections.
4. To configure secure communication between client and server, proceed with TLS
Settings:
1. Activate Enable TLS to enable TLS and SSL encryption of the client/server
communication.
2. Either Import Certificate by specifying the exact path to its location or enable
the Use Common Server Certificate. If the Use Common Server Certificate is
not available because it has not been created during installation, go for
Launch CA Management Module first.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Add Schema files to be included in the server's configuration by selecting Schema Files in the
left part of the dialog. The default selection of schema files applies to the server providing a
source of YaST user account data.
YaST allows to add traditional Schema files (usually with a name ending in .schema) or LDIF
files containing Schema definitions in OpenLDAP's LDIF Schema format.
Figure 4-5 YaST LDAP Server Database Configuration
To configure the databases managed by your LDAP server, proceed as follows:
1. Select the Databases item in the left part of the dialog.

2. Click Add Database to add a new database.
3. Enter the requested data:
Base DN
Enter the base DN of your LDAP server.
Administrator DN
tmg.edu.au | 1300 888 TMG (1300 888 864)
Enter the DN of the administrator in charge of the server. If you check Append Base
DN, only provide the cn of the administrator and the system fills in the rest
automatically.
LDAP Administrator Password
Enter the password for the database administrator.
Use This Database as the Default for OpenLDAP Clients
For convenience, check this option if wanted.
4. In the next dialog configure replication settings.

5. In the next dialog, enable enforcement of password policies to provide extra security
to your LDAP server:
1. Check Enable Password Policies to be able to specify a password policy.
2. Activate Hash Clear Text Passwords to have clear text passwords be hashed
before they are written to the database whenever they are added or
modified.
3. Disclose "Account Locked" Status provides a relevant error message for bind
requests to locked accounts.
WARNING: Locked Accounts in Security Sensitive Environments
Do not use the Disclose "Account Locked" Status option if your environment is
sensitive to security issues, because the Locked Account error message
provides security-sensitive information that can be exploited by a potential
attacker.
4. Enter the DN of the default policy object. To use a DN other than the one
suggested by YaST, enter your choice. Otherwise, accept the default settings.
6. Complete the database configuration by clicking Finish.
If you have not opted for password policies, your server is ready to run at this point. If you
have chosen to enable password policies, proceed with the configuration of the password
policy in detail. If you have chosen a password policy object that does not yet exist, YaST
creates one:
1. Enter the LDAP server password. In the navigation tree below Databases expand your
database object and activate the Password Policy Configuration item.
2. Make sure Enable Password Policies is activated. Then click Edit Policy.
3. Configure the password change policies:
1. Determine the number of passwords stored in the password history. Saved
passwords may not be reused by the user.
tmg.edu.au | 1300 888 TMG (1300 888 864)
2. Determine if users will be able to change their passwords and if they will need
to change their passwords after a reset by the administrator. Require the old
password for password changes (optional).
3. Determine whether and to what extent passwords should be subject to quality
checking. Set the minimum password length that must be met before a
password is valid. If you select Accept Uncheckable Passwords, users are
allowed to use encrypted passwords, even though the quality checks cannot
be performed. If you opt for Only Accept Checked Passwords only those
passwords that pass the quality tests are accepted as valid.
4. Configure the password time-limit policies:
1. Determine the minimum password time-limit (the time that needs to pass
between two valid password changes) and the maximum password time-limit.
2. Determine the time between a password expiration warning and the actual
password expiration.
3. Set the number of postponement uses of an expired password before the
password expires permanently.
5. Configure the lockout policies:
1. Enable password locking.
2. Determine the number of bind failures that trigger a password lock.
3. Determine the duration of the password lock.
4. Determine the length of time that password failures are kept in the cache
before they are purged.
6. Apply your password policy settings with OK.
To edit a previously created database, select its base DN in the tree to the left. In the right
part of the window, YaST displays a dialog similar to the one used for the creation of a new
database (with the main difference that the base DN entry is grayed out and cannot be
changed).
After leaving the LDAP server configuration by selecting Finish, you are ready to go with a
basic working configuration for your LDAP server. To fine-tune this setup, make use of
OpenLDAP's dynamic configuration back-end.
The OpenLDAP's dynamic configuration back-end stores the configuration in an LDAP

database. That database consists of a set of .ldif files in /etc/openldap/slapd.d. There is no
need to access these files directly. To access the settings you can either use the YaST LDAP
server module (the yast2-ldap-server package) or an LDAP client such as ldapmodify or
ldapsearch. Find more LDAP-related configuration and system data in /etc/sysconfig/ldap
and /var/lib/ldap.
For more information on the dynamic configuration of OpenLDAP, see the OpenLDAP
Administration Guide.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configuring an LDAP Client with YaST
YaST includes a module to set up LDAP-based user management. If you did not enable this
feature during the installation, start the module by selecting Network Services > LDAP Client.
YaST automatically enables any PAM and NSS-related changes as required by LDAP and
installs the necessary files. Simply connect your client to the server and let YaST manage users
over LDAP.
Use the YaST LDAP client to further configure the YaST group and user configuration modules.
This includes manipulating the default settings for new users and groups and the number and
nature of the attributes assigned to a user or group. LDAP user management allows you to
assign far more and different attributes to users and groups than traditional user or group
management solutions.
Configuring Basic Settings
The basic LDAP client configuration dialog (Figure 4-6) opens during installation if you choose
LDAP user management or when you select Network Services > LDAP Client in the YaST
Control Center in the installed system.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-6 YaST: LDAP Client Configuration
To authenticate users of your machine against an OpenLDAP server and to enable user
management via OpenLDAP, proceed as follows:
1. Click Use LDAP to enable the use of LDAP. Select Use LDAP but Disable Logins instead
if you want to use LDAP for authentication, but do not want other users to log in to this
client.
2. Enter the IP address of the LDAP server to use.
3. Enter the LDAP Base DN to select the search base on the LDAP server. To retrieve the
base DN automatically, click Fetch DN. YaST then checks for any LDAP database on
the server address specified above. Choose the appropriate base DN from the
search results given by YaST.
4. If TLS or SSL-protected communication with the server is required, select LDAP TLS/SSL.
Click Download CA Certificate to download a certificate in PEM format from a URL.
5. Select Start Automounter to mount remote directories on your client, such as a
remotely managed /home.
6. Select Create Home Directory on Login to have a user's home automatically created
on the first user login.
tmg.edu.au | 1300 888 TMG (1300 888 864)
7. Click OK to apply your settings.
To modify data on the server as administrator, click Advanced Configuration. The following
dialog is split into two tabs. See Figure 4-7.
Figure 4-7 YaST: Advanced Configuration
1. In the Client Settings tab, adjust the following settings according to your needs:
1. If the search base for users, passwords, and groups differs from the global
search base specified in the LDAP base DN, enter these different naming
contexts in User Map, Password Map, and Group Map.
2. Specify the password change protocol. The standard method to use
whenever a password is changed is crypt, meaning that password hashes
generated by crypt are used. For details on this and other options, refer to the
pam_ldap man page.
3. Specify the LDAP group to use with Group Member Attribute. The default
value for this is member.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. If a secure connection requires certificate checking, specify where your CA

Certificate File in PEM format is located. Or specify a directory with
certificates.
5. If the LDAP server still uses LDAPv2, enable the use of this protocol version by
selecting LDAP Version 2.
2. In Administration Settings, adjust the following settings:
1. Set the base for storing your user management data via Configuration Base
DN.
2. Enter the appropriate value for Administrator DN. This DN must be identical
with the rootdn value specified in /etc/openldap/slapd.conf to enable this
particular user to manipulate data stored on the LDAP server. Enter the full DN
(such as cn=Administrator,dc=example,dc=com) or activate Append Base
DN to have the base DN added automatically when you enter
cn=Administrator.
3. Check Create Default Configuration Objects to create the basic
configuration objects on the server to enable user management via LDAP.
4. If your client machine needs to act as a file server for home directories across
your network, check Home Directories on This Machine.
5. Use the Password Policy section to select, add, delete, or modify the password
policy settings to use. The configuration of password policies with YaST is part
of the LDAP server setup.
6. Click OK to leave the Advanced Configuration, then Finish to apply your
settings.
Use Configure User Management Settings to edit entries on the LDAP server. Access to the
configuration modules on the server is then granted according to the ACLs and ACIs stored
on the server.
Configuring the YaST Group and User Administration Modules#
Use the YaST LDAP client to adapt the YaST modules for user and group administration and to
extend them as needed. Define templates with default values for the individual attributes to
simplify the data registration. The presets created here are stored as LDAP objects in the
LDAP directory. The registration of user data is still done with the regular YaST modules for user
and group management. The registered data is stored as LDAP objects on the server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-8 YaST: Module Configuration
The dialog for module configuration (Figure 4-8) allows the creation of new modules,
selection and modification of existing configuration modules, and design and modification
of templates for such modules.
To create a new configuration module, proceed as follows:
1. In the LDAP Client Configuration click Advanced Configuration, then open the
Administration Settings tab. Click Configure User Management Settings and enter the
LDAP server credentials.
2. Click New and select the type of module to create. For a user configuration module,
select suseUserConfiguration and for a group configuration choose
suseGroupConfiguration.
3. Choose a name for the new template (e.g., userConfig). The content view shows a
table listing all attributes allowed in this module and their assigned values.
4. Accept the preset values or adjust the defaults to use in group and user
configurations by selecting the relevant attribute, pressing Edit, and entering the new
tmg.edu.au | 1300 888 TMG (1300 888 864)
value. Rename a module by changing the cn attribute of the module. Clicking

Delete deletes the currently selected module.
5. After you click OK, the new module is added to the selection menu.
The YaST modules for group and user administration embed templates with standard values.
To edit a template associated with a configuration module, start the object template
configuration (Figure 4-9).
1. In the Module Configuration dialog, click Configure Template.

2. Determine the values of the general attributes assigned to this template according to
your needs or leave them empty. Empty attributes are deleted on the LDAP server.
3. Modify, delete, or add new default values for new objects (user or group
configuration objects in the LDAP tree).
Figure 4-9 YaST: Configuration of an Object Template
tmg.edu.au | 1300 888 TMG (1300 888 864)
Connect the template to its module by setting the susedefaulttemplate attribute value of the
module to the DN of the adapted template.
HINT: The default values for an attribute can be created from other attributes by using a
variable instead of an absolute value. For example, when creating a new user, cn=%sn
%givenName is created automatically from the attribute values for sn and givenName.
Once all modules and templates are configured correctly and ready to run, new groups and
users can be registered in the usual way with YaST.
Configuring LDAP Users and Groups in YaST
The actual registration of user and group data differs only slightly from the procedure when
not using LDAP. The following instructions relate to the administration of users. The procedure
for administering groups is analogous.
1. Access the YaST user administration with Security and Users > User and Group
Management.
2. Use Set Filter to limit the view of users to the LDAP users and enter the password for
Root DN.
3. Click Add to enter the user configuration. A dialog with four tabs opens:
1. Specify username, login, and password in the User Data tab.
2. Check the Details tab for the group membership, login shell, and home
directory of the new user. If necessary, change the default to values that
better suit your needs. The default values (as well as those of the password
settings) can be defined with the procedure described in Configuring the
YaST Group and User Administration Modules.
3. Modify or accept the default Password Settings.
4. Enter the Plug-Ins tab, select the LDAP plug-in, and click Launch to configure
additional LDAP attributes assigned to the new user (see Figure 4-10).
4. Click OK to apply your settings and leave the user configuration.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-10 YaST: Additional LDAP Settings
The initial input form of user administration offers LDAP Options. This allows you to apply LDAP
search filters to the set of available users. Alternatively open the module for configuring LDAP
users and groups by selecting LDAP User and Group Configuration.
Browsing the LDAP Directory Tree
To conveniently browse the LDAP directory tree and all its entries, use the YaST LDAP Browser:
1. Log in as root.
2. Start YaST > Network Services > LDAP Browser.
3. Enter the address of the LDAP server, the Administrator DN, and the password for the
Root DN of this server (if you need both to read and write the data stored on the
server).
tmg.edu.au | 1300 888 TMG (1300 888 864)
Alternatively, choose Anonymous Access and do not provide the password to gain
read access to the directory.
The LDAP Tree tab displays the content of the LDAP directory to which your machine
connected. Click to expand each item's submenu.
Figure 4-11 Browsing the LDAP Directory Tree
4. To view any entry in detail, select it in the LDAP Tree view and open the Entry Data
tab.
All attributes and values associated with this entry are displayed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4-12 Browsing the Entry Data
5. To change the value of any of these attributes, select the attribute, click Edit, enter
the new value, click Save, and provide the Root DN password when prompted.
6. Leave the LDAP browser with Close.
Manually Configuring an LDAP Server
YaST uses OpenLDAP's dynamic configuration database (back-config) to store the LDAP
server's configuration. For details about the dynamic configuration back-end, see the slapd-
config(5) man page or the OpenLDAP Software 2.4 Administrator's Guide located at
/usr/share/doc/packages/openldap2/guide/admin/guide.html on your system if the
openldap2 package is installed.
HINT: Upgrading an Old OpenLDAP Installation
YaST does not use /etc/openldap/slapd.conf to store the OpenLDAP configuration anymore.
In case of a system upgrade, a copy of the original /etc/openldap/slapd.conf file will get
created as /etc/openldap/slapd.conf.YaSTsave.
To conveniently access the configuration back-end, you use SASL external authentication.
For example, the following ldapsearch command executed as root can be used to show the
complete slapd configuration:
ldapsearch -Y external -H ldapi:/// -b cn=config
tmg.edu.au | 1300 888 TMG (1300 888 864)
Starting and Stopping the Servers
Once the LDAP server is fully configured and all desired entries have been made according
to the pattern described in Manually Administering LDAP Data, start the LDAP server as root
by entering rcldap start. To stop the server manually, enter the command rcldap stop. Query
the status of the running LDAP server with rcldap status.
Use the YaST runlevel editor, described in Configuring System Services (Runlevel) with YaST,
(↑Administration Guide), to have the server started and stopped automatically on system
bootup and shutdown. It is also possible to create the corresponding links to the start and
stop scripts with the insserv command from a command prompt as described in Init Scripts.
Manually Administering LDAP Data
OpenLDAP offers a series of tools for the administration of data in the LDAP directory. The four
most important tools for adding to, deleting from, searching through and modifying the data
stock are explained in this section.
Inserting Data into an LDAP Directory#
Once your LDAP server is correctly configured (it features appropriate entries for suffix,
directory, rootdn, rootpw and index), proceed to entering records. OpenLDAP offers the
ldapadd command for this task. If possible, add the objects to the database in bundles (for
practical reasons). LDAP is able to process the LDIF format (LDAP data interchange format)
for this. An LDIF file is a simple text file that can contain an arbitrary number of attribute and
value pairs. The LDIF file for creating a rough framework for the example in Figure 4-1 would
look like the one in Example 4-2.
IMPORTANT: Encoding of LDIF Files
LDAP works with UTF-8 (Unicode). Umlauts must be encoded correctly. Otherwise, avoid
umlauts and other special characters or use iconv to convert the input to UTF-8.
Example 4-2 An LDIF File
# The Organization
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: Example dc: example
# The organizational unit development (devel)

dn: ou=devel,dc=example,dc=com
objectClass: organizationalUnit
ou: devel
tmg.edu.au | 1300 888 TMG (1300 888 864)
# The organizational unit documentation (doc)

dn: ou=doc,dc=example,dc=com
ou: doc
# The organizational unit internal IT (it)

dn: ou=it,dc=example,dc=com
ou: it
Save the file with the .ldif suffix then pass it to the server with the following command:
ldapadd -x -D dn_of_the_administrator -W -f file.ldif
-x switches off the authentication with SASL in this case. -D declares the user that calls the
operation. The valid DN of the administrator is entered here just like it has been configured in
slapd.conf. In the current example, this is cn=Administrator,dc=example,dc=com. -W
circumvents entering the password on the command line (in clear text) and activates a
separate password prompt. The -f option passes the filename. See the details of running
ldapadd in Example 4-3.
Example 4-3 ldapadd with example.ldif
ldapadd -x -D cn=Administrator,dc=example,dc=com -W -f example.ldif
Enter LDAP password:

adding new entry "dc=example,dc=com"
adding new entry "ou=devel,dc=example,dc=com"
adding new entry "ou=doc,dc=example,dc=com"
adding new entry "ou=it,dc=example,dc=com"
The user data of individuals can be prepared in separate LDIF files. Example 4-4 adds Tux to
the new LDAP directory.
Example 4-4 LDIF Data for Tux
# coworker Tux
dn: cn=Tux Linux,ou=devel,dc=example,dc=com
objectClass: inetOrgPerson
cn: Tux Linux
givenName: Tux
sn: Linux
mail: tux@example.com
uid: tux
telephoneNumber: +49 1234 567-8
tmg.edu.au | 1300 888 TMG (1300 888 864)
An LDIF file can contain an arbitrary number of objects. It is possible to pass directory
branches (entirely or in part) to the server in one go, as shown in the example of individual
objects. If it is necessary to modify some data relatively often, a fine subdivision of single
objects is recommended.
Modifying Data in the LDAP Directory#
The tool ldapmodify is provided for modifying the data stock. The easiest way to do this is to
modify the corresponding LDIF file and pass the modified file to the LDAP server. To change
the telephone number of colleague Tux from +49 1234 567-8 to +49 1234 567-10, edit the LDIF
file like in Example 4-5.
Example 4-5 Modified LDIF File tux.ldif
# coworker Tux
dn: cn=Tux Linux,ou=devel,dc=example,dc=com
changetype: modify
replace: telephoneNumber
Import the modified file into the LDAP directory with the following command:
ldapmodify -x -D cn=Administrator,dc=example,dc=com -W -f tux.ldif
Alternatively, pass the attributes to change directly to ldapmodify as follows:
1. Start ldapmodify and enter your password:

2. ldapmodify -x -D cn=Administrator,dc=example,dc=com -W
Enter LDAP password:
3. Enter the changes while carefully complying with the syntax in the order presented
below:
4. dn: cn=Tux Linux,ou=devel,dc=example,dc=com
5. changetype: modify
6. replace: telephoneNumber
For more information about ldapmodify and its syntax, see the ldapmodify man page.
Searching or Reading Data from an LDAP Directory
OpenLDAP provides, with ldapsearch, a command line tool for searching data within an
LDAP directory and reading data from it. This is a simple query:
ldapsearch -x -b dc=example,dc=com "(objectClass=*)"
tmg.edu.au | 1300 888 TMG (1300 888 864)
The -b option determines the search base (the section of the tree within which the search
should be performed). In the current case, this is dc=example,dc=com. To perform a more
finely-grained search in specific subsections of the LDAP directory (for example, only within
the devel department), pass this section to ldapsearch with -b. -x requests activation of
simple authentication. (objectClass=*) declares that all objects contained in the directory
should be read. This command option can be used after the creation of a new directory tree
to verify that all entries have been recorded correctly and the server responds as desired. For
more information about the use of ldapsearch, see the ldapsearch(1) man page.
Deleting Data from an LDAP Directory#
Delete unwanted entries with ldapdelete. The syntax is similar to that of the other commands.
To delete, for example, the complete entry for Tux Linux, issue the following command:
ldapdelete -x -D cn=Administrator,dc=example,dc=com -W cn=Tux \

Linux,ou=devel,dc=example,dc=com
Active Directory Support
Active Directory* (AD) is a directory-service based on LDAP, Kerberos, and other services that
is used by Microsoft Windows to manage resources, services, and people. In an MS Windows
network, AD provides information about these objects, restricts access to them, and enforces
policies. SUSE® Linux Enterprise Server lets you join existing AD domains and integrate your
Linux machine into a Windows environment.
Integrating Linux and AD Environments
With a Linux client (configured as an Active Directory client) that is joined to an existing
Active Directory domain, benefit from various features not available on a pure SUSE Linux
Enterprise Server Linux client:
Browsing Shared Files and Folders with SMB
Both Nautilus (the GNOME file manager) and Dolphin or Konqueror (its KDE
counterparts) support browsing shared resources through SMB.
Sharing Files and Folders with SMB
Both Nautilus, Dolphin, and Konqueror support sharing folders and files as in Windows.
Accessing and Manipulating User Data on the Windows Server
Through Nautilus and Konqueror, users are able to access their Windows user data
and can edit, create, and delete files and folders on the Windows server. Users can
access their data without having to enter their password multiple times.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Offline Authentication
Users are able to log in and access their local data on the Linux machine even if they
are offline or the AD server is unavailable for other reasons.
Windows Password Change
This port of AD support in Linux enforces corporate password policies stored in Active
Directory. The display managers and console support password change messages
and accept your input. You can even use the Linux passwd command to set
Windows passwords.
Single-Sign-On through Kerberized Applications
Many applications of both desktops are Kerberos-enabled (kerberized), which means

they can transparently handle authentication for the user without the need for
password reentry at Web servers, proxies, groupware applications, or other locations.
A brief technical background for most of these features is given in the following section.
Background Information for Linux AD Support
Many system components need to interact flawlessly in order to integrate a Linux client into
an existing Windows Active Directory domain. Figure 5-1 highlights the most prominent ones.
The following sections focus on the underlying processes of the key events in AD server and
client interaction.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 5-1 Active Directory Authentication Schema
To communicate with the directory service, the client needs to share at least two protocols
with the server:
LDAP
LDAP is a protocol optimized for managing directory information. A Windows domain

controller with AD can use the LDAP protocol to exchange directory information with
tmg.edu.au | 1300 888 TMG (1300 888 864)
the clients. To learn more about LDAP in general and about the open source port of
it, OpenLDAP, refer to LDAP—A Directory Service.
Kerberos
Kerberos is a third-party trusted authentication service. All its clients trust Kerberos's
authorization of another client's identity, enabling kerberized single-sign-on (SSO)
solutions. Windows supports a Kerberos implementation, making Kerberos SSO
possible even with Linux clients.
The following client components process account and authentication data:
Winbind
The most central part of this solution is the winbind daemon that is a part of the
Samba project and handles all communication with the AD server.
NSS (Name Service Switch)
NSS routines provide name service information. Naming service for both users and
groups is provided by nss_winbind. This module directly interacts with the winbind
daemon.
PAM (Pluggable Authentication Modules)
User authentication for AD users is done by the pam_winbind module. The creation of
user homes for the AD users on the Linux client is handled by pam_mkhomedir. The
pam_winbind module directly interacts with winbindd. To learn more about PAM in
general, refer to Authentication with PAM.
Applications that are PAM-aware, like the login routines and the GNOME and KDE display
managers, interact with the PAM and NSS layer to authenticate against the Windows server.
Applications supporting Kerberos authentication (such as file managers, Web browsers, or e-
mail clients) use the Kerberos credential cache to access user's Kerberos tickets, making
them part of the SSO framework.
Domain Join
During domain join, the server and the client establish a secure relation. On the client, the
following tasks need to be performed to join the existing LDAP and Kerberos SSO environment
provided by the Window domain controller. The entire join process is handled by the YaST
Domain Membership module, which can be run during installation or in the installed system:
1. The Windows domain controller providing both LDAP and KDC (Key Distribution
Center) services is located.
2. A machine account for the joining client is created in the directory service.
tmg.edu.au | 1300 888 TMG (1300 888 864)
3. An initial ticket granting ticket (TGT) is obtained for the client and stored in its local
Kerberos credential cache. The client needs this TGT to get further tickets allowing it
to contact other services, like contacting the directory server for LDAP queries.
4. NSS and PAM configurations are adjusted to enable the client to authenticate
against the domain controller.
During client boot, the winbind daemon is started and retrieves the initial Kerberos ticket for
the machine account. winbindd automatically refreshes the machine's ticket to keep it valid.
To keep track of the current account policies, winbindd periodically queries the domain
controller.
Activity 6
Summarise how LDAP is used for authentication.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 6
tmg.edu.au | 1300 888 TMG (1300 888 864)
Domain Login and User Homes
The login managers of GNOME and KDE (GDM and KDM) have been extended to allow the
handling of AD domain login. Users can choose to log in to the primary domain the machine
has joined or to one of the trusted domains with which the domain controller of the primary
domain has established a trust relationship.
User authentication is mediated by a number of PAM modules as described in Background

Information for Linux AD Support. The pam_winbind module used to authenticate clients
against Active Directory or NT4 domains is fully aware of Windows error conditions that might
prohibit a user's login. The Windows error codes are translated into appropriate user-readable
error messages that PAM gives at login through any of the supported methods (GDM, KDM,
console, and SSH):
Password has expired
The user sees a message stating that the password has expired and needs to be
changed. The system prompts for a new password and informs the user if the new
password does not comply with corporate password policies (for example the
password is too short, too simple, or already in the history). If a user's password
change fails, the reason is shown and a new password prompt is given.
Account disabled
The user sees an error message stating that the account has been disabled and to
contact the system administrator.
Account locked out
The user sees an error message stating that the account has been locked and to
contact the system administrator.
Password has to be changed
The user can log in but receives a warning that the password needs to be changed
soon. This warning is sent three days before that password expires. After expiration,
the user cannot log in.
Invalid workstation
When a user is restricted to specific workstations and the current SUSE Linux Enterprise
Server machine is not among them, a message appears that this user cannot log in
from this workstation.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Invalid logon hours
When a user is only allowed to log in during working hours and tries to log in outside
working hours, a message informs the user that logging in is not possible at that time.
Account expired
An administrator can set an expiration time for a specific user account. If that user
tries to log in after expiration, the user gets a message that the account has expired
and cannot be used to log in.
During a successful authentication, pam_winbind acquires a ticket granting ticket (TGT) from
the Kerberos server of Active Directory and stores it in the user's credential cache. It also
renews the TGT in the background, requiring no user interaction.
SUSE Linux Enterprise Server supports local home directories for AD users. If configured through
YaST as described in Configuring a Linux Client for Active Directory, user homes are created
at the first login of a Windows (AD) user into the Linux client. These home directories look and
feel entirely the same as standard Linux user home directories and work independently of the
AD domain controller. Using a local user home, it is possible to access a user's data on this
machine (even when the AD server is disconnected) as long as the Linux client has been
configured to perform offline authentication.
Offline Service and Policy Support
Users in a corporate environment must have the ability to become roaming users (for
example, to switch networks or even work disconnected for some time). To enable users to
log in to a disconnected machine, extensive caching was integrated into the winbind
daemon. The winbind daemon enforces password policies even in the offline state. It tracks
the number of failed login attempts and reacts according to the policies configured in
Active Directory. Offline support is disabled by default and must be explicitly enabled in the
YaST Domain Membership module.
When the domain controller has become unavailable, the user can still access network
resources (other than the AD server itself) with valid Kerberos tickets that have been acquired
before losing the connection (as in Windows). Password changes cannot be processed
unless the domain controller is online. While disconnected from the AD server, a user cannot
access any data stored on this server. When a workstation has become disconnected from
the network entirely and connects to the corporate network again later, SUSE Linux Enterprise
Server acquires a new Kerberos ticket as soon as the user has locked and unlocked the
desktop (for example, using a desktop screen saver).
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configuring a Linux Client for Active Directory
Before your client can join an AD domain, some adjustments must be made to your network
setup to ensure the flawless interaction of client and server.
DNS
Configure your client machine to use a DNS server that can forward DNS requests to
the AD DNS server. Alternatively, configure your machine to use the AD DNS server as
the name service data source.
NTP
To succeed with Kerberos authentication, the client must have its time set accurately.
It is highly recommended to use a central NTP time server for this purpose (this can be
also the NTP server running on your Active Directory domain controller). If the clock
skew between your Linux host and the domain controller exceeds a certain limit,
Kerberos authentication fails and the client is logged in using the weaker NTLM (NT
LAN Manager) authentication.
Firewall
To browse your network neighborhood, either disable the firewall entirely or mark the
interface used for browsing as part of the internal zone.
To change the firewall settings on your client, log in as root and start the YaST firewall
module. Select Interfaces. Select your network interface from the list of interfaces and
click Change. Select Internal Zone and apply your settings with OK. Leave the firewall
settings with Next > Finish. To disable the firewall, just check the Disable Firewall
Automatic Starting option, and leave the firewall module with Next > Finish.
AD Account
You cannot log in to an AD domain unless the AD administrator has provided you
with a valid user account for that domain. Use the AD username and password to log
in to the AD domain from your Linux client.
Join an existing AD domain during installation (or by later activating SMB user authentication
with YaST in the installed system).
IMPORTANT: Domain Name
Joining a domain may not succeed if the domain name ends with .local. Names ending in
.local cause conflicts with Multicast DNS (MDNS) where .local is reserved for link-local
hostnames.
tmg.edu.au | 1300 888 TMG (1300 888 864)
NOTE: Currently only a domain administrator account, such as Administrator, can join SUSE
Linux Enterprise Server into Active Directory.
To join an AD domain in a running system, proceed as follows:
Joining an AD Domain
1. Log in as root and start YaST.

2. Start Network Services > Windows Domain Membership.
3. Enter the domain to join at Domain or Workgroup in the Windows Domain
Membership screen (see Figure 5-2). If the DNS settings on your host are properly
integrated with the Windows DNS server, enter the AD domain name in its DNS format
(mydomain.mycompany.com). If you enter the short name of your domain (also
known as the pre–Windows 2000 domain name), YaST must rely on NetBIOS name
resolution instead of DNS to find the correct domain controller.
Figure 5-2 Determining Windows Domain Membership
4. Check Also Use SMB Information for Linux Authentication to use the SMB source for
Linux authentication.
tmg.edu.au | 1300 888 TMG (1300 888 864)
5. Check Create Home Directory on Login to automatically create a local home

directory for your AD user on the Linux machine.
6. Check Offline Authentication to allow your domain users to log in even if the AD
server is temporarily unavailable, or if you do not have a network connection.
7. Select Expert Settings, if you want to change the UID and GID ranges for the Samba
users and groups. Let DHCP retrieve the WINS server only if you need it. This is the case
when some of your machines are resolved only by the WINS system.
8. Configure NTP time synchronization for your AD environment by selecting NTP
Configuration and entering an appropriate server name or IP address. This step is
obsolete if you have already entered the appropriate settings in the stand-alone YaST
NTP configuration module.
9. Click OK and confirm the domain join when prompted for it.
10. Provide the password for the Windows administrator on the AD server and click OK
(see Figure 5-3).
Figure 5-3 Providing Administrator Credentials
After you have joined the AD domain, you can log in to it from your workstation using the
display manager of your desktop or the console.
Logging In to an AD Domain
Provided your machine has been configured to authenticate against Active Directory and
you have a valid Windows user identity, you can log in to your machine using the AD
credentials. Login is supported for both desktop environments (GNOME and KDE), the
console, SSH, and any other PAM-aware application.
IMPORTANT: Offline Authentication
SUSE Linux Enterprise Server supports offline authentication, allowing you to log in to your
client machine even when it is offline.
tmg.edu.au | 1300 888 TMG (1300 888 864)
GDM and KDM
To authenticate a GNOME client machine against an AD server, proceed as follows:
1. Select the domain.

2. Enter your Windows username and press Enter.
3. Enter your Windows password and press Enter.
To authenticate a KDE client machine against an AD server, proceed as follows:
1. Select the domain.

2. Enter your Windows username.
3. Enter your Windows password and press Enter.
If configured to do so, SUSE Linux Enterprise Server creates a user home directory on the local
machine on the first login of each AD authenticated user. This allows you to benefit from the
AD support of SUSE Linux Enterprise Server while still having a fully functional Linux machine at
your disposal.
Console Login
As well as logging into the AD client machine using a graphical front-end, you can log in
using the text-based console login or even remotely using SSH.
To log in to your AD client from a console, enter DOMAIN\user at the login: prompt and
provide the password.
To remotely log in to your AD client machine using SSH, proceed as follows:
1. At the login prompt, enter:
ssh DOMAIN\\user@hostname
The \ domain and login delimiter is escaped with another \ sign.
2. Provide the user's password.
Changing Passwords
SUSE Linux Enterprise Server has the ability to help a user choose a suitable new password
that meets the corporate security policy. The underlying PAM module retrieves the current
password policy settings from the domain controller, informing the user about the specific
password quality requirements a user account typically has by means of a message on login.
Like its Windows counterpart, SUSE Linux Enterprise Server presents a message describing:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Password history settings

 Minimum password length requirements
 Minimum password age
 Password complexity
The password change process cannot succeed unless all requirements have been
successfully met. Feedback about the password status is given both through the display
managers and the console.
GDM and KDM provide feedback about password expiration and the prompt for new
passwords in an interactive mode. To change passwords in the display managers, just
provide the password information when prompted.
To change your Windows password, you can use the standard Linux utility, passwd, instead of
having to manipulate this data on the server. To change your Windows password, proceed
as follows:
1. Log in at the console.

2. Enter passwd.
3. Enter your current password when prompted.
4. Enter the new password.
5. Reenter the new password for confirmation. If your new password does not comply
with the policies on the Windows server, this feedback is given to you and you are
prompted for another password.
To change your Windows password from the GNOME desktop, proceed as follows:
1. Click the Computer icon on the left edge of the panel.

2. Select Control Center.
3. From the Personal section, select About Me > Change Password.
4. Enter your old password.
5. Enter and confirm the new password.
6. Leave the dialog with Close to apply your settings.
To change your Windows password from the KDE desktop, proceed as follows:
1. Select Configure Desktop from the main menu.

2. Select About Me from the Personal section.
3. Click Password & User Account.
4. Click Change Password.
5. Enter your current password.
6. Enter and confirm the new password and apply your settings with OK.
7. Leave the configuration dialog with File > Quit.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network Authentication with Kerberos
An open network provides no means of ensuring that a workstation can identify its users
properly, except through the usual password mechanisms. In common installations, the user
must enter the password each time a service inside the network is accessed. Kerberos
provides an authentication method with which a user registers only once and is trusted in the
complete network for the rest of the session. To have a secure network, the following
requirements must be met:
 Have all users prove their identity for each desired service and make sure that no one
can take the identity of someone else.
 Make sure that each network server also proves its identity. Otherwise an attacker
might be able to impersonate the server and obtain sensitive information transmitted
to the server. This concept is called mutual authentication, because the client
authenticates to the server and vice versa.
Kerberos helps you meet these requirements by providing strongly encrypted authentication.
Only the basic principles of Kerberos are discussed here.
Kerberos Terminology
The following glossary defines some Kerberos terminology.
credential
Users or clients need to present some kind of credentials that authorize them to
request services. Kerberos knows two kinds of credentials—tickets and authenticators.
ticket
A ticket is a per-server credential used by a client to authenticate at a server from

which it is requesting a service. It contains the name of the server, the client's name,
the client's Internet address, a time stamp, a lifetime, and a random session key. All
this data is encrypted using the server's key.
authenticator
Combined with the ticket, an authenticator is used to prove that the client presenting
a ticket is really the one it claims to be. An authenticator is built using the client's
name, the workstation's IP address, and the current workstation's time, all encrypted
with the session key known only to the client and the relevant server. An
authenticator can only be used once, unlike a ticket. A client can build an
authenticator itself.
tmg.edu.au | 1300 888 TMG (1300 888 864)
principal
A Kerberos principal is a unique entity (a user or service) to which it can assign a

ticket. A principal consists of the following components:
 Primary—the first part of the principal, which can be the same as your
username in the case of a user.
 Instance—some optional information characterizing the primary. This string is
separated from the primary by a /.
 Realm—this specifies your Kerberos realm. Normally, your realm is your domain
name in uppercase letters.
mutual authentication
Kerberos ensures that both client and server can be sure of each other's identity. They
share a session key, which they can use to communicate securely.
session key
Session keys are temporary private keys generated by Kerberos. They are known to
the client and used to encrypt the communication between the client and the server
for which it requested and received a ticket.
replay
Almost all messages sent in a network can be eavesdropped, stolen, and resent. In
the Kerberos context, this would be most dangerous if an attacker manages to
obtain your request for a service containing your ticket and authenticator. The
attacker could then try to resend it (replay) to impersonate you. However, Kerberos
implements several mechanisms to deal with this problem.
server or service
Service is used to refer to a specific action to perform. The process behind this action
is referred to as a server.
How Kerberos Works
Kerberos is often called a third party trusted authentication service, which means all its clients
trust Kerberos's judgment of another client's identity. Kerberos keeps a database of all its users
and their private keys.
To ensure Kerberos is working correctly, run both the authentication and ticket-granting
server on a dedicated machine. Make sure that only the administrator can access this
machine physically and over the network. Reduce the (networking) services running on it to
the absolute minimum—do not even run sshd.
tmg.edu.au | 1300 888 TMG (1300 888 864)
First Contact
Your first contact with Kerberos is quite similar to any login procedure at a normal networking
system. Enter your username. This piece of information and the name of the ticket-granting
service are sent to the authentication server (Kerberos). If the authentication server knows
you, it generates a random session key for further use between your client and the ticket-
granting server. Now the authentication server prepares a ticket for the ticket-granting
server. The ticket contains the following information—all encrypted with a session key only the
authentication server and the ticket-granting server know:
 The names of both, the client and the ticket-granting server

 The current time
 A lifetime assigned to this ticket
 The client's IP address
 The newly-generated session key
This ticket is then sent back to the client together with the session key, again in encrypted
form, but this time the private key of the client is used. This private key is only known to
Kerberos and the client, because it is derived from your user password. Now that the client
has received this response, you are prompted for your password. This password is converted
into the key that can decrypt the package sent by the authentication server. The package is
unwrapped and password and key are erased from the workstation's memory. As long as the
lifetime given to the ticket used to obtain other tickets does not expire, your workstation can
prove your identity.
Requesting a Service
To request a service from any server in the network, the client application needs to prove its
identity to the server. Therefore, the application generates an authenticator. An
authenticator consists of the following components:
 The client's principal

 A checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for
this special server. The authenticator and the ticket for the server are sent to the server. The
server uses its copy of the session key to decrypt the authenticator, which gives it all the
information needed about the client requesting its service, to compare it to that contained
in the ticket. The server checks if the ticket and the authenticator originate from the same
client.
Without any security measures implemented on the server side, this stage of the process
would be an ideal target for replay attacks. Someone could try to resend a request stolen off
tmg.edu.au | 1300 888 TMG (1300 888 864)
the net some time before. To prevent this, the server does not accept any request with a
time stamp and ticket received previously. In addition to that, a request with a time stamp
differing too much from the time the request is received is ignored.
Mutual Authentication
Kerberos authentication can be used in both directions. It is not only a question of the client
being the one it claims to be. The server should also be able to authenticate itself to the
client requesting its service. Therefore, it sends an authenticator itself. It adds one to the
checksum it received in the client's authenticator and encrypts it with the session key, which
is shared between it and the client. The client takes this response as a proof of the server's
authenticity and they both start cooperating.
Ticket Granting—Contacting All Servers
Tickets are designed to be used for one server at a time. This implies that you have to get a
new ticket each time you request another service. Kerberos implements a mechanism to
obtain tickets for individual servers. This service is called the ticket-granting service. The ticket-
granting service is a service (like any other service mentioned before) and uses the same
access protocols that have already been outlined. Any time an application needs a ticket
that has not already been requested, it contacts the ticket-granting server. This request
consists of the following components:
 The requested principal

 The ticket-granting ticket
 An authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the
authenticator. If they are considered valid, the ticket-granting server builds a new session key
to be used between the original client and the new server. Then the ticket for the new server
is built, containing the following information:
 The client's principal

 The server's principal
 The newly-generated session key
The new ticket has a lifetime, which is either the remaining lifetime of the ticket-granting
ticket or the default for the service. The lesser of both values is assigned. The client receives
this ticket and the session key, which are sent by the ticket-granting service, but this time the
answer is encrypted with the session key that came with the original ticket-granting ticket.
The client can decrypt the response without requiring the user's password when a new
service is contacted. Kerberos can thus acquire ticket after ticket for the client without
bothering the user.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Compatibility to Windows 2000
Windows 2000 contains a Microsoft implementation of Kerberos 5. SUSE® Linux Enterprise

Server uses the MIT implementation of Kerberos 5.
Users' View of Kerberos
Ideally, a user's one and only contact with Kerberos happens during login at the workstation.
The login process includes obtaining a ticket-granting ticket. At logout, a user's Kerberos
tickets are automatically destroyed, which makes it difficult for anyone else to impersonate
this user. The automatic expiration of tickets can lead to a somewhat awkward situation
when a user's login session lasts longer than the maximum lifespan given to the ticket-
granting ticket (a reasonable setting is 10 hours). However, the user can get a new ticket-
granting ticket by running kinit. Enter the password again and Kerberos obtains access to
desired services without additional authentication. To get a list of all the tickets silently
acquired for you by Kerberos, run klist.
Here is a short list of some applications that use Kerberos authentication. These applications
can be found under /usr/lib/mit/bin or /usr/lib/mit/sbin after installing the package krb5-
apps-clients. They all have the full functionality of their common UNIX and Linux brothers plus
the additional bonus of transparent authentication managed by Kerberos:
 telnet, telnetd
 rlogin
 rsh, rcp, rshd
 ftp, ftpd
 ksu
You no longer have to enter your password for using these applications because Kerberos
has already proven your identity. ssh, if compiled with Kerberos support, can even forward all
the tickets acquired for one workstation to another one. If you use ssh to log in to another
workstation, ssh makes sure that the encrypted contents of the tickets are adjusted to the
new situation. Simply copying tickets between workstations is not sufficient because the
ticket contains workstation-specific information (the IP address). XDM, GDM, and KDM offer
Kerberos support, too. Read more about the Kerberos network applications in Kerberos V5
UNIX User's Guide at http://web.mit.edu/kerberos.
Installing and Administering Kerberos
A Kerberos environment consists of several different components. A key distribution center

(KDC) holds the central database with all Kerberos-relevant data. All clients rely on the KDC
for proper authentication across the network. Both the KDC and the clients need to be
configured to match your setup:
tmg.edu.au | 1300 888 TMG (1300 888 864)
General Preparations
Check your network setup and make sure it meets the minimum. Choose an
appropriate realm for your Kerberos setup. Carefully set up the machine that is to
serve as the KDC and apply tight security. Set up a reliable time source in your
network to make sure all tickets contain valid timestamps.
Basic Configuration
Configure the KDC and the clients. Enable remote administration for your Kerberos
service, so you do not need physical access to your KDC machine. Create service
principals for every service in your realm.
Enabling Kerberos Authentication
Various services in your network can make use of Kerberos.
Kerberos Network Topology
Any Kerberos environment must meet the following requirements to be fully functional:
 Provide a DNS server for name resolution across your network, so clients and servers
can locate each other.
 Provide a time server in your network. Using exact time stamps is crucial to a Kerberos
setup, because valid Kerberos tickets must contain correct time stamps. Provide a
key distribution center (KDC) as the center piece of the Kerberos architecture. It holds
the Kerberos database. Use the tightest possible security policy on this machine to
prevent any attacks on this machine compromising your entire infrastructure.
 Configure the client machines to use Kerberos authentication.
The following figure depicts a simple example network with just the minimum components
needed to build a Kerberos infrastructure. Depending on the size and topology of your
deployment, your setup may vary.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 6-1 Kerberos Network Topology
HINT: Configuring Subnet Routing
For a setup similar to the one in Figure 6-1, configure routing between the two subnets
(192.168.1.0/24 and 192.168.2.0/24).
Choosing the Kerberos Realms
The domain of a Kerberos installation is called a realm and is identified by a name, such as
EXAMPLE.COM or simply ACCOUNTING. Kerberos is case-sensitive, so example.com is
actually a different realm than EXAMPLE.COM. Use the case you prefer. It is common
practice, however, to use uppercase realm names.
It is also a good idea to use your DNS domain name (or a subdomain, such as
ACCOUNTING.EXAMPLE.COM). As shown below, your life as an administrator can be much
easier if you configure your Kerberos clients to locate the KDC and other Kerberos services
via DNS. To do so, it is helpful if your realm name is a subdomain of your DNS domain name.
Unlike the DNS name space, Kerberos is not hierarchical. You cannot set up a realm named
EXAMPLE.COM, have two subrealms named DEVELOPMENT and ACCOUNTING underneath
it, and expect the two subordinate realms to somehow inherit principals from EXAMPLE.COM.
Instead, you would have three separate realms for which you would have to configure
crossrealm authentication for users from one realm to interact with servers or other users from
another realm.
tmg.edu.au | 1300 888 TMG (1300 888 864)
For the sake of simplicity, let us assume you are setting up just one realm for your entire
organization. For the remainder of this section, the realm name EXAMPLE.COM is used in all
examples.
Setting Up the KDC Hardware
The first thing required to use Kerberos is a machine that acts as the key distribution center, or
KDC for short. This machine holds the entire Kerberos user database with passwords and all
information.
The KDC is the most important part of your security infrastructure—if someone breaks into it,
all user accounts and all of your infrastructure protected by Kerberos is compromised. An
attacker with access to the Kerberos database can impersonate any principal in the
database. Tighten security for this machine as much as possible:
1. Put the server machine into a physically secured location, such as a locked server
room to which only a very few people have access.
2. Do not run any network applications on it except the KDC. This includes servers and
clients—for example, the KDC should not import any file systems via NFS or use DHCP
to retrieve its network configuration.
3. Install a minimal system first then check the list of installed packages and remove any
unneeded packages. This includes servers, such as inetd, portmap, and cups, as well
as anything X-based. Even installing an SSH server should be considered a potential
security risk.
4. No graphical login is provided on this machine as an X server is a potential security
risk. Kerberos provides its own administration interface.
5. Configure /etc/nsswitch.conf to use only local files for user and group lookup.
Change the lines for passwd and group to look like this:
6. passwd: files
group: files
Edit the passwd, group, and shadow files in /etc and remove the lines that start with a
+ character (these are for NIS lookups).
7. Disable all user accounts except root's account by editing /etc/shadow and
replacing the hashed passwords with * or ! characters.
Configuring Time Synchronization
To use Kerberos successfully, make sure that all system clocks within your organization are
synchronized within a certain range. This is important because Kerberos protects against
replayed credentials. An attacker might be able to observe Kerberos credentials on the
network and reuse them to attack the server. Kerberos employs several defenses to prevent
this. One of them is that it puts time stamps into its tickets. A server receiving a ticket with a
time stamp that differs from the current time rejects the ticket.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Kerberos allows a certain leeway when comparing time stamps. However, computer clocks
can be very inaccurate in keeping time—it is not unheard of for PC clocks to lose or gain half
an hour over the course of a week. For this reason, configure all hosts on the network to
synchronize their clocks with a central time source.
A simple way to do so is by installing an NTP time server on one machine and having all
clients synchronize their clocks with this server. Do this either by running an NTP daemon in
client mode on all these machines or by running ntpdate once a day from all clients (this
solution probably works for a small number of clients only). The KDC itself needs to be
synchronized to the common time source as well. Because running an NTP daemon on this
machine would be a security risk, it is probably a good idea to do this by running ntpdate via
a cron entry. To configure your machine as an NTP client, proceed as outlined in Configuring
an NTP Client with YaST.
A different way to secure the time service and still use the NTP daemon is to attach a
hardware reference clock to a dedicated NTP server as well as an additional hardware
reference clock to the KDC.
It is also possible to adjust the maximum deviation Kerberos allows when checking time
stamps. This value (called clock skew) can be set in the krb5.conf as described in Adjusting
the Clock Skew.
Configuring the KDC
This section covers the initial configuration and installation of the KDC, including the creation
of an administrative principal. This procedure consists of several steps:
1. Install the RPMs On a machine designated as the KDC, install the following software
packages: krb5, krb5-server and krb5-client packages.
2. Adjust the Configuration Files The /etc/krb5.conf and
/var/lib/kerberos/krb5kdc/kdc.conf configuration files must be adjusted for your
scenario. These files contain all information on the KDC.
3. Create the Kerberos Database Kerberos keeps a database of all principal identifiers
and the secret keys of all principals that need to be authenticated.
4. Adjust the ACL Files: Add Administrators The Kerberos database on the KDC can be
managed remotely. To prevent unauthorized principals from tampering with the
database, Kerberos uses access control lists. You must explicitly enable remote
access for the administrator principal to enable him to manage the database. The
Kerberos ACL file is located under /var/lib/kerberos/krb5kdc/kadm5.acl.
5. Adjust the Kerberos Database: Add Administrators You need at least one
administrative principal to run and administer Kerberos. This principal must be added
before starting the KDC. Refer to Creating a Principal for details.
6. Start the Kerberos Daemon Once the KDC software is installed and properly
configured, start the Kerberos daemon to provide Kerberos service for your realm.
Refer to Starting the KDC for details.
tmg.edu.au | 1300 888 TMG (1300 888 864)
7. Create a Principal for Yourself You need a principal for yourself. Refer to Creating a
Principal for details.
Setting Up the Database
Your next step is to initialize the database where Kerberos keeps all information about
principals. Set up the database master key, which is used to protect the database from
accidental disclosure (in particular if it is backed up to tape). The master key is derived from
a pass phrase and is stored in a file called the stash file. This is so you do not need to enter the
password every time the KDC is restarted. Make sure that you choose a good pass phrase,
such as a sentence from a book opened to a random page.
When you make tape backups of the Kerberos database

(/var/lib/kerberos/krb5kdc/principal), do not back up the stash file (which is in
/var/lib/kerberos/krb5kdc/.k5.EXAMPLE.COM). Otherwise, everyone able to read the tape
could also decrypt the database. Therefore, keep a copy of the pass phrase in a safe or
some other secure location, because you will need it to restore your database from backup
tape after a crash.
To create the stash file and the database, run:
kdb5_util create -r EXAMPLE.COM -s
You will see the following output:
Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',

master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Type the master password.
Type the password again.
To verify, use the list command:
kadmin.local
kadmin> listprincs
You will see several principals in the database, which are for internal use by Kerberos:
tmg.edu.au | 1300 888 TMG (1300 888 864)
K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM
Creating a Principal
Create two Kerberos principals for yourself: one normal principal for everyday work and one
for administrative tasks relating to Kerberos. Assuming your login name is geeko, proceed as
follows:
kadmin.local
kadmin> ank geeko
You will see the following output:
geeko@EXAMPLE.COM's Password:
Verifying password:
Type geeko's password.
Type geeko's password again.
Next, create another principal named geeko/admin by typing ank geeko/admin at the
kadmin prompt. The admin suffixed to your username is a role. Later, use this role when
administering the Kerberos database. A user can have several roles for different purposes.
Roles are basically completely different accounts with similar names.
Starting the KDC
Start the KDC daemon and the kadmin daemon. To start the daemons manually, enter
rckrb5kdc start and rckadmind start. Also make sure that KDC and kadmind are started by
default when the server machine is rebooted with the command insserv krb5kdc and
insserv kadmind or use the YaST runlevel editor.
Configuring Kerberos Clients
Once the supporting infrastructure is in place (DNS, NTP) and the KDC has been properly
configured and started, configure the client machines. You can either use YaST to configure
a Kerberos client or use one of the two manual approaches described below.
Configuring a Kerberos Client with YaST
tmg.edu.au | 1300 888 TMG (1300 888 864)
Rather than manually editing all relevant configuration files when configuring a Kerberos
client, let YaST do the job for you. You can either perform the client configuration during the
installation of your machine or in the installed system as follows:
1. Log in as root and select Network Services > Kerberos Client (Figure 6-2).
2. Select Use Kerberos.
3. To configure a DNS-based Kerberos client, proceed as follows:
1. DNS-Based Static Kerberos Client
NOTE: Using DNS Support
The Use DNS option cannot be selected if the DNS server does not provide
such data.
2. Click Advanced Settings to configure details on ticket-related issues, OpenSSH

support, time synchronization, and extended PAM configurations.
4. To configure a static Kerberos client, proceed as follows:
1. Set Default Domain, Default Realm, and KDC Server Address to the values that
match your setup.
2. Click Advanced Settings to configure details on ticket-related issues, OpenSSH
support, time synchronization, and extended PAM configurations.
Figure 6-2 YaST: Basic Configuration of a Kerberos Client
tmg.edu.au | 1300 888 TMG (1300 888 864)
To configure ticket-related options in the Advanced Settings dialog (Figure 6-3), choose from
the following options:
 Specify the Default Ticket Lifetime and the Default Renewable Lifetime in days, hours,
or minutes (using the units of measurement d, h, and m, with no blank space
between the value and the unit).
 To forward your complete identity (to use your tickets on other hosts), select
Forwardable.
 Enable the transfer of certain tickets by selecting Proxiable.
 Enable Kerberos authentication support for your OpenSSH client by selecting the
corresponding check box. The client then uses Kerberos tickets to authenticate with
the SSH server.
 Exclude a range of user accounts from using Kerberos authentication by providing a
value for the Minimum UID that a user of this feature must have. For instance, you may
want to exclude the system administrator (root).
 Use Clock Skew to set a value for the allowable difference between the time stamps
and your host's system time.
 To keep the system time in sync with an NTP server, you can also set up the host as an
NTP client by selecting NTP Configuration, which opens the YaST NTP client dialog that
is described in Configuring an NTP Client with YaST,. After finishing the configuration,
YaST performs all the necessary changes and the Kerberos client is ready to use.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 6-3 YaST: Advanced Configuration of a Kerberos Client
Manually Configuring Kerberos Clients
When configuring Kerberos, there are basically two approaches you can take—static
configuration in the /etc/krb5.conf file or dynamic configuration with DNS. With DNS
configuration, Kerberos applications try to locate the KDC services using DNS records. With
static configuration, add the hostnames of your KDC server to krb5.conf (and update the file
whenever you move the KDC or reconfigure your realm in other ways).
DNS-based configuration is generally a lot more flexible and the amount of configuration
work per machine is a lot less. However, it requires that your realm name is either the same as
your DNS domain or a subdomain of it. Configuring Kerberos via DNS also creates a minor
security issue—an attacker can seriously disrupt your infrastructure through your DNS (by
shooting down the name server, spoofing DNS records, etc.). However, this amounts to a
denial of service at worst. A similar scenario applies to the static configuration case unless
you enter IP addresses in krb5.conf instead of hostnames.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Static Configuration
One way to configure Kerberos is to edit /etc/krb5.conf. The file installed by default contains
various sample entries. Erase all of these entries before starting. krb5.conf is made up of
several sections (stanzas), each introduced by the section name in brackets like [this].
To configure your Kerberos clients, add the following stanza to krb5.conf (where
kdc.example.com is the hostname of the KDC):
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
}
The default_realm line sets the default realm for Kerberos applications. If you have several
realms, just add additional statements to the [realms] section.
Also add a statement to this file that tells applications how to map hostnames to a realm. For
example, when connecting to a remote host, the Kerberos library needs to know in which
realm this host is located. This must be configured in the [domain_realms] section:
[domain_realm]
.example.com = EXAMPLE.COM
www.foobar.com = EXAMPLE.COM
This tells the library that all hosts in the example.com DNS domains are in the EXAMPLE.COM
Kerberos realm. In addition, one external host named www.foobar.com should also be
considered a member of the EXAMPLE.COM realm.
DNS-Based Configuration#
DNS-based Kerberos configuration makes heavy use of SRV records. See (RFC2052) A DNS RR
for specifying the location of services at http://www.ietf.org.
The name of an SRV record, as far as Kerberos is concerned, is always in the format
_service._proto.realm, where realm is the Kerberos realm. Domain names in DNS are case
insensitive, so case-sensitive Kerberos realms would break when using this configuration
method. _service is a service name (different names are used when trying to contact the
KDC or the password service, for example). _proto can be either _udp or _tcp, but not all
services support both protocols.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The data portion of SRV resource records consists of a priority value, a weight, a port number,
and a hostname. The priority defines the order in which hosts should be tried (lower values
indicate a higher priority). The weight value is there to support some sort of load balancing
among servers of equal priority. You probably do not need any of this, so it is okay to set
these to zero.
MIT Kerberos currently looks up the following names when looking for services:
_kerberos
This defines the location of the KDC daemon (the authentication and ticket granting
server). Typical records look like this:
_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com.

_kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com.
_kerberos-adm
This describes the location of the remote administration service. Typical records look
like this:
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 0 0 749 kdc.example.com.
Because kadmind does not support UDP, there should be no _udp record.
As with the static configuration file, there is a mechanism to inform clients that a specific host
is in the EXAMPLE.COM realm, even if it is not part of the example.com DNS domain. This can
be done by attaching a TXT record to _kerberos.hostname, as shown here:
_kerberos.www.foobar.com. IN TXT "EXAMPLE.COM"
Adjusting the Clock Skew
The clock skew is the tolerance for accepting tickets with time stamps that do not exactly
match the host's system clock. Usually, the clock skew is set to 300 seconds (five minutes). This
means a ticket can have a time stamp somewhere between five minutes behind and five
minutes ahead of the server's clock.
When using NTP to synchronize all hosts, you can reduce this value to about one minute. The
clock skew value can be set in /etc/krb5.conf like this:
[libdefaults]
clockskew = 60
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configuring Remote Kerberos Administration
To be able to add and remove principals from the Kerberos database without accessing the
KDC's console directly, tell the Kerberos administration server which principals are allowed to
do what by editing /var/lib/kerberos/krb5kdc/kadm5.acl. The ACL (access control list) file
allows you to specify privileges with a precise degree of control. For details, refer to the
manual page with man 8 kadmind.
For now, just grant yourself the privilege to administer the database by putting the following
line into the file:
geeko/admin *
Replace the username geeko with your own. Restart kadmind for the change to take effect.
You should now be able to perform Kerberos administration tasks remotely using the kadmin
tool. First, obtain a ticket for your admin role and use that ticket when connecting to the
kadmin server:
kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:
Using the getprivs command, verify which privileges you have. The list shown above is the full
set of privileges.
As an example, modify the principal geeko:
kadmin: getprinc geeko

Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
tmg.edu.au | 1300 888 TMG (1300 888 864)
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin: modify_principal -maxlife "8 hours" geeko

Principal "geeko@EXAMPLE.COM" modified.
kadmin: getprinc joe
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:
This changes the maximum ticket life time to eight hours. For more information about the
kadmin command and the options available, see the krb5-doc package or refer to the
man8 kadmin manual page.
Creating Kerberos Service Principals
So far, only user credentials have been discussed. However, Kerberos-compatible services
usually need to authenticate themselves to the client user, too. Therefore, special service
principals must be present in the Kerberos database for each service offered in the realm. For
example, if ldap.example.com offers an LDAP service, you need a service principal,
ldap/ldap.example.com@EXAMPLE.COM, to authenticate this service to all clients.
The naming convention for service principals is service/hostname@REALM, where hostname

is the host's fully qualified hostname.
Valid service descriptors are:
Service Descriptor Service

host Telnet, RSH, SSH
tmg.edu.au | 1300 888 TMG (1300 888 864)
nfs NFSv4 (with Kerberos support)

HTTP HTTP (with Kerberos authentication)
imap IMAP
pop POP3
ldap LDAP
Service principals are similar to user principals, but have significant differences. The main
difference between a user principal and a service principal is that the key of the former is
protected by a password—when a user obtains a ticket-granting ticket from the KDC, he
needs to type his password so Kerberos can decrypt the ticket. It would be quite
inconvenient for the system administrator if he had to obtain new tickets for the SSH daemon
every eight hours or so.
Instead, the key required to decrypt the initial ticket for the service principal is extracted by
the administrator from the KDC only once and stored in a local file called the keytab.
Services such as the SSH daemon read this key and use it to obtain new tickets
automatically, when needed. The default keytab file resides in /etc/krb5.keytab.
To create a host service principal for jupiter.example.com enter the following commands
during your kadmin session:
kadmin: addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.
Instead of setting a password for the new principal, the -randkey flag tells kadmin to
generate a random key. This is used here because no user interaction is wanted for this
principal. It is a server account for the machine.
Finally, extract the key and store it in the local keytab file /etc/krb5.keytab. This file is owned
by the superuser, so you must be root to execute the next command in the kadmin shell:
kadmin: ktadd host/jupiter.example.com

Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:
When completed, make sure that you destroy the admin ticket obtained with kinit above
with kdestroy.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Enabling PAM Support for Kerberos
SUSE® Linux Enterprise Server comes with a PAM module named pam_krb5, which supports
Kerberos login and password update. This module can be used by applications such as
console login, su, and graphical login applications like KDM (where the user presents a
password and would like the authenticating application to obtain an initial Kerberos ticket
on his behalf). To configure PAM support for Kerberos, use the following command:
pam-config --add --krb5
The above command adds the pam_krb5 module to the existing PAM configuration files and
makes sure it is called in the right order. To make precise adjustments to the way in which
pam_krb5 is used, edit the file /etc/krb5.conf and add default applications to pam. For
details, refer to the manual page with man 5 pam_krb5.
The pam_krb5 module was specifically not designed for network services that accept
Kerberos tickets as part of user authentication. This is an entirely different matter, and is
discussed below.
Configuring SSH for Kerberos Authentication
OpenSSH supports Kerberos authentication in both protocol version 1 and 2. In version 1,

there are special protocol messages to transmit Kerberos tickets. Version 2 does not use
Kerberos directly anymore, but relies on GSSAPI, the General Security Services API. This is a
programming interface that is not specific to Kerberos—it was designed to hide the
peculiarities of the underlying authentication system, be it Kerberos, a public-key
authentication system like SPKM, or others. However, the included GSSAPI library only
supports Kerberos.
To use sshd with Kerberos authentication, edit /etc/ssh/sshd_config and set the following
options:
# These are for protocol version 1

#
# KerberosAuthentication yes
# KerberosTicketCleanup yes
# These are for version 2 - better to use this

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
Then restart your SSH daemon using rcsshd restart.
To use Kerberos authentication with protocol version 2, enable it on the client side as well. Do
this either in the systemwide configuration file /etc/ssh/ssh_config or on a per-user level by
editing ~/.ssh/config. In both cases, add the option GSSAPIAuthentication yes.
tmg.edu.au | 1300 888 TMG (1300 888 864)
You should now be able to connect using Kerberos authentication. Use klist to verify that you
have a valid ticket, then connect to the SSH server. To force SSH protocol version 1, specify
the -1 option on the command line.
HINT: Additional Information
The file /usr/share/doc/packages/openssh/README.kerberos discusses the interaction of

OpenSSH and Kerberos in more detail.
HINT: Additional Directives for Protocol Version 2
Since SLES 11 SP3, the GSSAPIKeyExchange is supported. This directive specifies how host keys
are exchanged. For further information see manual page sshd_config(5).
Using LDAP and Kerberos
When using Kerberos, one way to distribute the user information (such as user ID, groups, and
home directory) in your local network is to use LDAP. This requires a strong authentication
mechanism that prevents packet spoofing and other attacks. One solution is to use Kerberos
for LDAP communication, too.
OpenLDAP implements most authentication flavors through SASL, the simple authentication
session layer. SASL is basically a network protocol designed for authentication. The SASL
implementation is cyrus-sasl, which supports a number of different authentication flavors.
Kerberos authentication is performed through GSSAPI (General Security Services API). By
default, the SASL plug-in for GSSAPI is not installed. Install the cyrus-sasl-gssapi with YaST.
To enable Kerberos to bind to the OpenLDAP server, create a principal

ldap/ldap.example.com and add that to the keytab.
By default, the LDAP server slapd runs as user and group ldap, while the keytab file is
readable by root only. Therefore, either change the LDAP configuration so the server runs as
root or make the keytab file readable by the group ldap. The latter is done automatically by
the OpenLDAP start script (/etc/init.d/ldap) if the keytab file has been specified in the
OPENLDAP_KRB5_KEYTAB variable in /etc/sysconfig/openldap and the
OPENLDAP_CHOWN_DIRS variable is set to yes, which is the default setting. If
OPENLDAP_KRB5_KEYTAB is left empty, the default keytab under /etc/krb5.keytab is used and
you must adjust the privileges yourself as described below.
To run slapd as root, edit /etc/sysconfig/openldap. Disable the OPENLDAP_USER and

OPENLDAP_GROUP variables by putting a comment character in front of them.
To make the keytab file readable by group LDAP, execute
chgrp ldap /etc/krb5.keytab

chmod 640 /etc/krb5.keytab
tmg.edu.au | 1300 888 TMG (1300 888 864)
A third (and maybe the best) solution is to tell OpenLDAP to use a special keytab file. To do
this, start kadmin, and enter the following command after you have added the principal
ldap/ldap.example.com:
ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM
Then in the shell run:
chown ldap.ldap /etc/openldap/ldap.keytab

chmod 600 /etc/openldap/ldap.keytab
To tell OpenLDAP to use a different keytab file, change the following variable in
/etc/sysconfig/openldap:
OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"
Finally, restart the LDAP server using rcldap restart.
Using Kerberos Authentication with LDAP#
You are now able to automatically use tools such as ldapsearch with Kerberos
authentication.
ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)'
SASL/GSSAPI authentication started

SASL SSF: 56
SASL installing layers
[...]
# geeko, people, example.com

dn: uid=geeko,ou=people,dc=example,dc=com
uid: geeko
cn: Olaf Kirch
[...]
As you can see, ldapsearch prints a message that it started GSSAPI authentication. The next
message is very cryptic, but it shows that the security strength factor (SSF for short) is 56 (The
value 56 is somewhat arbitrary. Most likely it was chosen because this is the number of bits in
a DES encryption key). What this tells you is that GSSAPI authentication was successful and
that encryption is being used to protect integrity and provide confidentiality for the LDAP
connection.
In Kerberos, authentication is always mutual. This means that not only have you
authenticated yourself to the LDAP server, but also the LDAP server has authenticated itself
tmg.edu.au | 1300 888 TMG (1300 888 864)
to you. In particular, this means communication is with the desired LDAP server, rather than
some bogus service set up by an attacker.
Kerberos Authentication and LDAP Access Control#
There is one minor piece of the puzzle missing—how the LDAP server can find out that the
Kerberos user joe@EXAMPLE.COM corresponds to the LDAP distinguished name
uid=joe,ou=people,dc=example,dc=com. This sort of mapping must be configured manually
using the saslExpr directive. In this example, the "authz-regexp" change in LDIF would look as
follows:
dn: cn=config
add: olcAuthzRegexp
olcAuthzRegexp: uid=(.*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=example,dc=com
All these changes can be applied via ldapmodify on the command line.
To understand how this works, you need to know that when SASL authenticates a user,
OpenLDAP forms a distinguished name from the name given to it by SASL (such as joe) and
the name of the SASL flavor (GSSAPI). The result would be uid=joe,cn=GSSAPI,cn=auth.
If a authz-regexp has been configured, it checks the DN formed from the SASL information
using the first argument as a regular expression. If this regular expression matches, the name is
replaced with the second argument of the authz-regexp statement. The placeholder $1 is
replaced with the substring matched by the (.*) expression.
More complicated match expressions are possible. If you have a more complicated
directory structure or a schema in which the username is not part of the DN, you can even
use search expressions to map the SASL DN to the user DN.
For more information, see the slapd-config man page.
Authentication in Windows
Machine or Computer Authentication is what is occurring any time a supplicant is

authenticating to the network with a stored credential.
If an iPad has a certificate stored on it, and that certificate is used for network
authentication, what is it really proving? It's proving that MACHINE had a credential stored in
it, right?
Microsoft, however, took that to a completely different level! I know, you mention Microsoft
and Security in the same sentence, and many will laugh. However, if you get past that initial
knee-jerk reaction & dive deep into things they have done to enhance security, you realize
Microsoft takes security very seriously; at least that is my opinion from observing them for 20+
years.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Enough of that ramble - let's get back to what they did to enhance security as it relates to
network authentication.
~2000, the world welcomes the arrival of a shiny new baby boy named "IEEE 802.1X".
So back around the year 2000, we standardized on a network access protocol called 802.1X,
which was going to usher in a new era of network security. Never again would a computer
enter a network without knowing WHO was using that computer. So let's think about this:
In my own weird way, Figure 1 is meant to illustrate a Windows Computer connecting to an

802.1X enabled network. Since 802.1x was designed to authenticate the USER, the machine
is still sitting there waiting for an interactive user to press CTL-ALT-DEL and log in.
Figure 1 - No Interactive User
Since there is no interactive user, there would be no "Identity" to send into the network for
authentication & now this machine is sitting there without any ability to reach Active
Directory for Group Policy (GPO) updates, or other important endpoint management tasks.
This is Where Microsoft Does Something Very Cool
When a Windows desktop machine joins Active Directory, there is a computer account that
gets created and a unique password is negotiated between the machine and AD. Figure 2
shows a screen shot from Active Directory Users and Computers showing the domain joined
computer accounts.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 2 - AD Computer Accounts
This computer account can now be used to identify the machine, even when no user is
logged in, which can be used to provide the machine access to the network. This is what we
commonly call a "machine auth". The access could naturally be customized and specific for
a machine-only to access the things that the machine may need access to (such as AD),
and not provide full network access, that's entirely up to you & how you design the
authorization result for the machine-auth.
Figure 3 is a poor attempt to illustrate a limited access provided to a computer account, so

the computer can get it's management updates from AD, users are able to login to
computers with AD credentials, even if they've never been logged into that desktop before,
etc.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 3 - Computer Account Authorized
What About When a User Logs In?
The computer is on the network, and able to communicate. What happens when a user sits
down & presses CTL-ALT-DEL and logs into the laptop. Most of the time, the Windows device
will send a new "start" message into the network to initiate a new network login, this time
using the User-Credentials.
Note: While it is possible to configure the user session to continue leveraging the machine
credential, it is not possible to configure windows to leverage the user credential when the
user is not logged in. That is (of course) unless you are using a very intelligent supplicant like
Cisco AnyConnect or "Juni-Pulse-Funk" Oddessy, etc.
Windows is a multi-user operating system. This is important to note, because each user will
have their own credential store on the same computer. This means that employee1 will have
his/her certificates and other credentials in a totally different location than employee2 &
each user will not have access to anyone's credentials except their own. This concept is very
different from the Android and iOS devices of today, which are mostly single-user devices.
Figure 4 is my ridiculous attempt to illustrate the concept of the computer and each user
having separate credential stores.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4 - Seperate Credential Stores
When the user logs into the Windows machine, the "state" changes & uses their
credentials. There is an option to keep the machine state for the network authentication, but
there is no option in native Windows for the user state to extend beyond logoff, or to validate
both the machine and the user credentials.
To try and illustrate this concept, Figure 5 shows the credential used for the network
authentication when there is no interactive user logged in. Figure 6 shows the credential for
the network authentication when Employee2 is logged into the Windows system.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 5 - Computer Authenticated to Network
Figure 6 - User Context
Let's ReGroup and Level-Set

tmg.edu.au | 1300 888 TMG (1300 888 864)
"Let me explain.. No there is too much, let me sum-up" - Mandy Patinkin, The Princess Bride
At this point, we've covered that computer authentications are possible because Microsoft
creates a computer-account in Active Directory which both the PC and AD are aware of,
thereby allowing the computer to have it's own identity for network access purposes (among
other things).
When a user logs in, the context of the system on the network changes, and a new EAP
authentication occurs, thereby changing the authentication on the port to a user-based
authentication
EAP authentications were always (and technically still are) designed to cary a single
credential per EAP transaction. The only standard EAP type that can handle the dual
identity "chaining" is TEAP (RFC 7170); which as of July 2015 - no vendor has published an
implementation yet. Cisco can do EAP-Chaining today with EAP-FASTv2, but that is not a
standard, TEAP is.
What Is Constrained Delegation?
Constrained delegation lets you limit the back-end services for which a front-end service can
request tickets on behalf of another user. A common example of constrained delegation is
the web-browser-to-IIS-to-SQL-Server scenario. In this scenario, a user navigates to a web-
based reports server hosted on Microsoft IIS, which retrieves data using an authenticated
connection to a Microsoft SQL Server system. The IIS server needs to authenticate to the SQL
Server system on behalf of the user. Through Kerberos delegation, the IIS server (i.e., the front-
end service) can request a service ticket for any service (i.e., back-end service)—not just SQL
Server—on behalf of the user. This means that the IIS server can essentially authenticate on
behalf of the user to SQL Server, a file share, or a web service. Using constrained delegation,
you can limit the IIS server (the front end) so that it can authenticate the user only to SQL
Server (the back end) and no other service or application.
Kerberos constrained delegation has been a part of the OS since Windows Server 2003. It
requires you to configure an allow list of service principal names (SPNs) on user or computer
objects in Active Directory (AD). You add the list of SPNs that represent the back-end services
to which a front-end service is allowed to request tickets on behalf of the user to the ms-DS-
Allowed-To-Delegate-To attribute of the principal under which the application or service on
the front-end server runs. In the previous example, the front-end service is IIS and the back-
end service is SQL Server. To constrain the delegation for IIS, you would add SPNs for the SQL
Server instances running on the SQL Server system to the ms-DS-Allowed-To-Delegate-To
attribute on the IIS computer account in AD—or the user account running the IIS application
pool. This model constrains the front-end service to only request service tickets that are listed
in the ms-DS-Allowed-To-Delegate-To attribute. The downside of this delegation model is that
it relies heavily on SPNs.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Service Principal Names
SPNs are difficult to manage. Although they’re simple in concept, SPNs can cause a
significant amount of frustration, stemming from unique constraints associated with using
them.
Kerberos uses SPNs to identify the security principal responsible for running an application or
service. This enables the Key Distribution Center (KDC) to encrypt tickets and keys with the
correct hash so that the security principal (running the service or application) can decrypt
the service ticket upon receiving the AP_REQ. This design requires that SPNs registered on
security principals be unique for the AD forest. An SPN registered on multiple security
principals will cause authentication to fail.
Constrained delegation appears to contradict the basic rule of registering a duplicate SPN;
however, this is only in appearance. The KDC doesn’t look at the ms-DS-Allowed-To-
Delegate-To attribute when trying to map an SPN to a security principal. Therefore, the
unique SPN requirement is limited only to values in the servicePrincipalName attribute. To
constrain the delegation of a service or application, you must list the service's SPNs on the
security principal that runs the application on the front-end server.
Managing the number of SPNs, knowing when and where to register them, and avoiding
duplicates is cumbersome. This makes constrained delegation difficult to implement,
maintain, and troubleshoot.
Point of Delegation
Constrained delegation is a model that controls delegation on the front-end server. Most
delegation models manage the point of delegation closest to the resource (i.e., on the back
end). Implementing delegation on the front end removes control from the resource
administrator and places it on the administrator of the front-end server (and application). This
model prevents the resource administrator from managing access to the resource. The
current model requires domain administrative privileges to modify the ms-DS-Allowed-To-
Delegate-To attribute, thus adding more administrative overhead to the management of
constrained delegation.
Scope of Delegation
Scope of delegation refers to the limit to which the delegation extends from the front-end
server to the back-end server. The current constrained delegation model scope is limited to
the domain, meaning that the security principal under which the application or service runs
can forward constrained delegated tickets only to an application or service running under a
security principal in the same domain. You can’t use constrained delegation across domain
or forest trusts.
tmg.edu.au | 1300 888 TMG (1300 888 864)
What Server 2012 Brings
Server 2012 introduces a new kind of Kerberos constrained delegation that addresses many
of the shortcomings that exist with the previous constrained delegation model. The new
implementation of constrained delegation removes the dependencies on SPNs for
delegation configuration, removes the need for domain administrative privileges, enables
the resource administrator to own the delegation experience, and increases the scope of
delegation.
Constrained delegation in Server 2012 introduces the concept of controlling delegation of

service tickets using a security descriptor rather than an allow list of SPNs. This change
simplifies delegation by enabling the resource to determine which security principals are
allowed to request tickets on behalf of another user.
Figure 1 shows a sample scenario. A server in Domain A runs an IIS application. The security
principal under which the IIS application’s AppPool runs has the SPNs registered for the front-
end service or application (HTTP/app1.contoso.com). These SPNs allow the user to
authenticate to the front-end server using normal Kerberos authentication.
Figure 1: Constrained Delegation in Server 2012
The application retrieves data from a back-end server in Domain B running SQL Server. The
security principal running the SQL Server service has the SPNs registered for SQL Server and
SQL Server instances. Again, this configuration is normal to enable Kerberos authentication.
The KDC in the domain hosting the security principal running SQL Server receives a Service-
for-User-to-Proxy (S4U2Proxy) Ticket Granting Service (TGS) request from the IIS server on
behalf of another user. The KDC reads the security descriptor stored in the msDS-
AllowedToActOnBehalfOfOtherIdentity attribute on the security principal running the SQL
tmg.edu.au | 1300 888 TMG (1300 888 864)
Server service and performs an access check using the identity under which the IIS
Application Pool runs. A successful access check allows the authentication process to
continue, whereas an unsuccessful access check fails the authentication attempt.
Resource-based constrained delegation functions correctly regardless of domain functional

level and number of domain controllers (DCs) running a version of Windows Server prior to
Server 2012, provided you have at least one Server 2012 DC in the same domain as the front-
end server and one Server 2012 DC in the domain hosting the back-end server. When the
domain is a hybrid domain (both Server 2012 DCs and DCs running an earlier version of
Windows Server), then Windows 8 and Windows 2012 computers ensure they use a Server
2012 DC to use resource-based constrained delegation by deliberately locating a Server
2012 DC.
Requirements
The new implementation of Kerberos constrained delegation has the following requirements:
 Server 2012 KDCs must reside in the front-end account domain

 Server 2012 KDCs must reside in the back-end account domain
 The front-end server must run Server 2012
Server 2012 KDCs are required for this feature because these are the only KDCs that know
how to return referred S4U2Proxy requests and use the new msDS-
AllowedToActOnBehalfOfOtherIdentity attribute on the service account. The front-end server
requires Server 2012 because the version of Kerberos on these servers understands that it
must chase S4U2Proxy referrals to trusted domains and forests.
Management
You manage Server 2012 Kerberos constrained delegation using Windows PowerShell. Use
the following Windows PowerShell cmdlets to manage constrained delegation. Typically,
you'll want to use the Get-ADUser, Get-ADComputer, or Get-ADServiceAccount of the
principal running the front-end service and pass that principal object as the argument value
to the -PrincipalsAllowedToDelegateToAccount argument.
Diving into the Technical Depths
Constrained delegation lets you limit the back-end services for which a front-end service can
request tickets on behalf of another user. To understand this behavior, it’s best to analyze
authentication flow as two separate events: the client authenticating to the front-end
service, and the front-end service authenticating to the back-end service.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Client to front-end authentication. Authentication from the Kerberos client to the front-end
server doesn’t change when you use resource-based constrained delegation. The Kerberos
client requests a service ticket from its local Key Distribution Center (KDC) for the target
service principal name (SPN).
If the target service resides in the same domain, the KDC issues a service ticket and session
key to the Kerberos client in a TGS-REP message. If the target service resides outside the
current domain, the KDC issues a Ticket Granting Ticket (TGT) referral ticket using the inter-
realm session key of the trust in a TGS-REP. The Kerberos client chases the referral as it
normally does when authenticating to a resource outside of its domain (across a trust).
Front-end to back-end authentication. Authentication from the front end (Service-for-User—

S4U—client) to the back end is different when using resource-based constrained delegation.
Resource-based constrained delegation requires that the computer running the front-end
service use Server 2012 because services running on versions of Windows earlier than
Windows 8 and Server 2012 don’t support resource-based constrained delegation; earlier
versions of Windows don’t chase referrals from the Service-for-User-to-Proxy (S4U2Proxy) TGS-
REQ across the domain boundary.
During front-end to back-end authentication, the front-end service asks a KDC for a service
ticket on behalf of another user. This exchange uses the Kerberos extension S4U2Proxy (aka
constrained delegation). The Kerberos client successfully presents a service ticket to the front-
end service. The front-end service impersonates the identity presented in the service ticket
and attempts to authenticate to the back-end service by way of SPN. This authentication
attempt results in the front-end service creating an S4U2Proxy TGS-REQ to the KDC in the
front-end server's domain. This request includes the target SPN, which resides in another
domain, and the service ticket used to authenticate to the front-end service. The TGS-REP
returned depends on the answering KDC.
Front-End KDC Behavior
Constrained delegation, at the micro level, involves many decisions and exchanges of
information, beginning with the client contacting the front-end KDC.
KDC earlier than Server 2012.A KDC earlier than Server 2012 receiving an S4U2Proxy TGS-REQ
for a target SPN outside of its domain returns the Kerberos error KDC_ERR_BADOPTION (13) in
a TGS-REP to the front-end service. This response results from an inability of a KDC earlier than
Server 2012 to provide a TGT referral for an S4U2Proxy TGT_REQ for a target SPN residing
outside its own domain. Constrained delegation prior to Server 2012 wasn’t supported across
domain and forest trusts.
Server 2012 KDC.A Server 2012 KDC receiving the S4U2Proxy TGS-REQ determines whether the
target SPN resides in its domain. In this scenario, the target SPN resides in another domain.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Therefore, the Server 2012 KDC—aware that it supports resource-based constrained

delegation—provides a referral TGT to the front-end service in a TGS-REP.
Front-End Service TGS-REP Behavior
The front-end service receives a TGS-REP from the KDC. The next action the front-end service
performs depends on the KDC response from the S4U2Proxy TGS-REP.
TGS-REP from KDC earlier than Server 2012.The front-end service receives a TGS-REP in
response to the S4U2Proxy TGS-REQ. The response from the KDC is a Kerberos ERROR -
KDC_ERR_BADOPTION (13). The front-end service runs on a Server 2012 member server. Server
2012 is a cross-domain constrained delegation–aware Kerberos client; therefore, when the
front-end service receives an S4U2Proxy TGS-REP with KDC_ERR_BADOPTION (13), it knows
that it might have contacted a KDC that doesn’t support constrained delegation across
domains. In response, the Server 2012 member server running the front-end service attempts
to locate a Server 2012 domain controller (DC). After locating a Server 2012 DC, the member
server running the front-end service sends the same S4U2Proxy TGS-REQ to the Server 2012
DC.
TGS-REP from Server 2012 KDC.The front-end service receives a TGS-REP in response to the
S4U2Proxy TGS-REQ. The response from the KDC is a TGT referral to the domain that’s
responsible for providing authentication for the target SPN. Server 2012 is a cross-domain
constrained delegation–aware Kerberos client. The member server running the front-end
service chases the referral to the domain listed in the TGT referral. (Important: When
traversing trusts using resource-based constrained delegation, the computer must
authenticate to traverse the trust. Therefore, it is expected for the computer to perform a
TGS-REQ for a TGT in each domain as well as the first S4U2Proxy TGS-REQ performed by the
front-end service.) The TGS-REQ referral process continues until it locates a Server 2012 DC in
the domain that hosts the targeted SPN.
Back-End KDC Behavior
The back-end KDC receives an S4U2Proxy TGS-REQ from the front-end service. The TGS-REQ
includes an evidentiary ticket, which is the service ticket from the initial authentication to the
front-end service as well as the inter-realm referral TGT received from an earlier exchange
with a KDC.
The KDC first determines whether the target SPN resides in its domain. If it doesn’t, the KDC
creates a referral TGS-REP, as previously described. Alternatively, the target SPN might exist in
the current domain. In this case, the KDC can provide a service ticket for the targeted
service and can respond directly rather than with a referral to another domain. The KDC then
reads the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the security principal
registered for the targeted back-end SPN. If the attribute is empty, the Server 2012 DC will use
traditional constrained delegation logic (msDS-AllowedToDelegateTo [A2D2]). If the msDS-
AllowedToActOnBehalfOfOtherIdentity has a value, the KDC impersonates the security
tmg.edu.au | 1300 888 TMG (1300 888 864)
principal under which the front-end service runs and performs an access check using the
security descriptor stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
An access check failure causes the KDC to use traditional constrained delegation logic
(A2D2) to determine whether constrained delegation is allowed. A successful access check
means the back-end service allows the front-end service to request tickets on behalf of other
security principals that are used for authentication to the back-end service. The KDC builds a
service ticket for the back-end service using the client name from the evidentiary ticket and
returns the service ticket and session key for the front-end service to use to authenticate to
the back-end service as the user.
KDC Behavior With and Without Traditional Constrained Delegation
If the back-end server is configured using traditional constrained delegation (msDS-

AllowedToDelegateTo—A2D2), which must reside in the same domain, then a Server 2012
KDC or a KDC running an earlier version of Windows can be used for authentication.
Behavior for non-Server 2012 KDCs.KDCs running earlier versions of Windows behave the
same with traditional constrained delegation. If A2D2 isn’t configured, and the back-end
service resides in the current domain, the KDC returns KDC_ERR_BADOPTION with a sub status
of STATUS_NOT_FOUND. If A2D2 isn’t configured, and the back-end service resides in another
domain, the KDC returns KDC_ERR_BADOPTION with a sub status of STATUS_NOT_FOUND.
If A2D2 is configured, and the back-end service is not a value in the attribute, and the back-
end service resides in the current domain, the KDC returns KDC_ERR_BADOPTION with a sub
status of STATUS_NOT_FOUND. If the back-end service resides in another domain, the KDC
returns KRB-ERR-POLICY with a sub status of STATUS_CROSSREALM_DELEGATION_FAILURE.
Behavior for Server 2012 KDCs. If A2D2 isn’t configured, and the back-end service resides in
another domain, the Server 2012 KDC returns a referral TGT. If A2D2 isn’t configured, and the
back-end service resides in the current domain, and resource-based constrained delegation
isn’t configured on the principal object, the Server 2012 KDC returns KDC_ERR_BADOPTION
with a sub status of STATUS_NOT_FOUND.
If A2D2 is configured, and the back-end SPN isn’t a value within the attribute, the back-end
service resides in the current domain, and resource-based constrained delegation isn’t
configured on the principal object, the Server 2012 KDC returns KDC_ERR_BADOPTION with a
sub status of STATUS_NOT_FOUND. If the back-end SPN resides in another domain, the Server
2012 KDC returns a referral TGT.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Message Flow Walkthrough
Now that all the academic explanation is out of the way, here's a walkthrough of the
message flow to help you visualize how all of this works together. Don’t worry if you don’t
understand all of it the first time! It's a lot to take in, and the changes are a shift in thinking
from how delegation used to work to how it can work in Server 2012. When teaching this
material, I explain to engineers that if they think it's too simple, then they’re catching on! The
management of it is simple, but the inner workings require a little more thought before they
make sense.
To reduce the number of visible steps to those included in the resource-based constrained
delegation message exchange, successful client-to-front-end authentication is assumed in
Figure 1.
1. The front-end service sends an S4U2Proxy TGS-REQ to the KDC in

root.fabrikam.com, requesting a service ticket for the back-end service on
behalf of the user. The TGS-REQ includes the front-end service TGT; a
forwardable client service ticket for the front-end service, or an
evidentiary ticket; and the KDC option cname-in-addl-tkt. If the KDC in
root.fabrikam.com returns KRB-ERR-BADOPTION, the front-end service
locates a Server 2012 DC and retries the TGS-REQ.
2. The KDC in root.fabrikam.com determines that the back-end service
doesn’t reside in root.fabrikam.com and returns a referral TGT for
corp.contoso.com to the front-end service on behalf of the user. The
cname field in the ticket uses the name of the front-end service, and the
crealm field uses the name of the front-end service domain.
3. The front-end service must authenticate to the back-end domain to chase
the referral on behalf of the user. The front-end service sends a TGS-REQ,
as itself, to the KDC in the root.fabrikam.com to request a service ticket for
the back-end service.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. The KDC in root.fabrikam.com determines that the back-end service isn’t

in root.fabrikam.com and returns a TGS-REP that includes a referral TGT to
corp.contoso.com.
5. The front-end service sends a TGS-REQ, for itself, requesting a service ticket
for the back-end service.
6. The KDC in corp.contoso.com sends a TGS-REP that includes a service
ticket for the back-end service that is used by the front-end service.
7. The front-end service locates a Server 2012 DC in corp.contoso.com and
sends an S4U2Proxy TGS-REQ to the KDC in corp.contoso.com, requesting
a service ticket for the back-end service on behalf of the user present in
the evidentiary ticket. The request includes a front-end service referral TGT,
additional tickets (S4U referral TGT), and the KDC option cname-in-addl-
tkt.
8. The KDC in corp.contoso.com retrieves account information from AD using
SamIGetUserLogonInformation, impersonates the front-end service, and
performs an access check using the security descriptor in the msDS-
AllowedToActOnBehalfOfOtherIdentity attribute. If the access check fails,
the KDC returns KRB-ERR-BADOPTION; otherwise, the KDC returns a service
ticket in a TGS-REP)
9. The front-end service presents the service ticket requested on behalf of
the user to the back-end service by sending an AP-REQ.
10. The back-end service returns an AP-REP if mutual authentication is
required.
Protocol Transition (S4U2Self)
The protocol transition extension to Kerberos doesn’t require a Server 2012 DC. Therefore,
Windows 8 and Server 2012 S4U clients don’t attempt to locate a Server 2012 DC to service
these requests.
Front-end servers need to locate Server 2012 DCs when the initial S4U2Proxy TGS-REQ returns
a KRB-ERR-BADOPTION or KRB-ERR-POLICY. To accomplish this, the S4U client uses the public
directory service API DsGetDCName, which makes an RPC call to a DC. The specific call
includes the DS_DIRECTORY_SERVICE_8_REQUIRED flag, which indicates the API need only
return Server 2012 DCs.
The <windowsAuthentication> element defines configuration settings for the Internet

Information Services (IIS) 7 Windows authentication module. You can use Windows
authentication when your IIS 7 server runs on a corporate network that is using Microsoft
Active Directory service domain identities or other Windows accounts to identify users.
Because of this, you can use Windows authentication whether or not your server is a member
of an Active Directory domain.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows authentication (formerly named NTLM, and also referred to as Windows NT

Challenge/Response authentication) is a secure form of authentication because the user
name and password are hashed before being sent across the network. When you enable
Windows authentication, the client browser sends a strongly hashed version of the password
in a cryptographic exchange with your Web server.
Windows authentication supports two authentication protocols, Kerberos and NTLM, which
are defined in the <providers> element. When you install and enable Windows
authentication on IIS 7, the default protocol is Kerberos. The <windowsAuthentication>
element can also contain a useKernelMode attribute that configures whether to use the
kernel mode authentication feature that is new to Windows Server 2008.
Windows authentication is best suited for an intranet environment for the following reasons:
 Client computers and Web servers are in the same domain.

 Administrators can make sure that every client browser is Internet Explorer 2.0 or later.
 HTTP proxy connections, which are not supported by NTLM, are not required.
 Kerberos version 5 requires a connection to Active Directory, which is not feasible in
an Internet environment.
New in IIS 7.5
The <extendedProtection> element was introduced in IIS 7.5, which allows you to configure
the settings for the new extended protection features that have been integrated into
Windows authentication.
Compatibility
Version Notes
IIS 10.0 The <windowsAuthentication> element was not modified in IIS 10.0.
IIS 7.5 The <extendedProtection> element was added in IIS 7.5.
IIS 7.0 The <windowsAuthentication> element was introduced in IIS 7.0.
The <windowsAuthentication> element replaces portions of the IIS 6.0 AuthType and
IIS 6.0
AuthFlags metabase properties.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Setup
The default installation of IIS 7 and later does not include the Windows authentication role
service. To use Windows authentication on IIS, you must install the role service, disable
Anonymous authentication for your Web site or application, and then enable Windows
authentication for the site or application.
Note: After you install the role service, IIS 7 commits the following configuration settings to the
ApplicationHost.config file.
<windowsAuthentication enabled="false" />
Windows Server 2012 or Windows Server 2012 R2
1. On the taskbar, click Server Manager.

2. In Server Manager, click the Manage menu, and then click Add Roles and Features.
3. In the Add Roles and Features wizard, click Next. Select the installation type and click
Next. Select the destination server and click Next.
4. On the Server Roles page, expand Web Server (IIS), expand Web Server, expand
Security, and then select Windows Authentication. Click Next.
.
5. On the Select features page, click Next.
6. On the Confirm installation selections page, click Install.
7. On the Results page, click Close.
Windows 8 or Windows 8.1
1. On the Start screen, move the pointer all the way to the lower left corner, right-click
the Start button, and then click Control Panel.
2. In Control Panel, click Programs and Features, and then click Turn Windows features
on or off.
tmg.edu.au | 1300 888 TMG (1300 888 864)
3. Expand Internet Information Services, expand World Wide Web Services, expand
Security, and then select Windows Authentication.
4. Click OK.
5. Click Close.
Windows Server 2008 or Windows Server 2008 R2
1. On the taskbar, click Start, point to Administrative Tools, and then click Server
Manager.
2. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS).
3. In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add
Role Services.
4. On the Select Role Services page of the Add Role Services Wizard, select Windows
Authentication, and then click Next.
5. On the Confirm Installation Selections page, click Install.

6. On the Results page, click Close.
Windows Vista or Windows 7
1. On the taskbar, click Start, and then click Control Panel.

2. In Control Panel, click Programs and Features, and then click Turn Windows Features
on or off.
3. Expand Internet Information Services, then World Wide Web Services, then Security.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. Select Windows Authentication, and then click OK.
How To
How to enable Windows authentication for a Web site, Web application, or

Web service
1. Open Internet Information Services (IIS) Manager:

o If you are using Windows Server 2012 or Windows Server 2012 R2:
 On the taskbar, click Server Manager, click Tools, and then click
Internet Information Services (IIS) Manager.
o If you are using Windows 8 or Windows 8.1:
 Hold down the Windows key, press the letter X, and then click Control
Panel.
 Click Administrative Tools, and then double-click Internet Information
Services (IIS) Manager.
 On the taskbar, click Start, point to Administrative Tools, and then click
o If you are using Windows Vista or Windows 7:
 On the taskbar, click Start, and then click Control Panel.
 Double-click Administrative Tools, and then double-click Internet
Information Services (IIS) Manager.
2. In the Connections pane, expand the server name, expand Sites, and then the site,
application, or Web service for which you want to enable Windows authentication.
3. Scroll to the Security section in the Home pane, and then double-click Authentication.
4. In the Authentication pane, select Windows Authentication, and then click Enable in
the Actions pane.
tmg.edu.au | 1300 888 TMG (1300 888 864)
How to enable Extended Protection for Windows authentication
1. Open Internet Information Services (IIS) Manager:

 On the taskbar, click Server Manager, click Tools, and then click
o If you are using Windows 8 or Windows 8.1:
 Hold down the Windows key, press the letter X, and then click Control
Panel.
 Click Administrative Tools, and then double-click Internet Information
Services (IIS) Manager.
 On the taskbar, click Start, point to Administrative Tools, and then click
o If you are using Windows Vista or Windows 7:
 On the taskbar, click Start, and then click Control Panel.
 Double-click Administrative Tools, and then double-click Internet
Information Services (IIS) Manager.
2. In the Connections pane, expand the server name, expand Sites, and then the site,
application, or Web service for which you want to enable Extended Protection for
Windows authentication.
3. Scroll to the Security section in the Home pane, and then double-click Authentication.
4. In the Authentication pane, select Windows Authentication.
5. Click Enable in the Actions pane.
6. Click Advanced Settings in the Actions pane.

7. When the Advanced Settings dialog box appears, select one of the following options
in the Extended Protection drop-down menu:
o Select Accept if you want to enable extended protection while providing
down-level support for clients that do not support extended protection.
tmg.edu.au | 1300 888 TMG (1300 888 864)
o Select Required if you want to enable extended protection without providing

down-level support.
8. Click OK to close the Advanced Settings dialog box.
Configuration
The <windowsAuthentication> element is configurable at the site, application, or virtual

directory level in the ApplicationHost.config file.
Attributes
Attribute Description
Optional Boolean attribute.
Specifies whether IIS automatically reauthenticates every non-

NTLM (for example, Kerberos) request, even those on the same
connection. False enables multiple authentications for the same
connections.
authPersistNonNTLM
Note: A setting of true means that the client will be authenticated

only once on the same connection. IIS will cache a token or ticket
on the server for a TCP session that stays established.
The default is false.
Setting this flag to true specifies that authentication persists only for
a single request on a connection. IIS resets the authentication at
authPersistSingleRequest
the end of each request, and forces reauthentication on the next
request of the session.
The default value is false.
enabled Required Boolean attribute.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Specifies whether Windows authentication is enabled.
The default value is false.
Specifies whether Windows authentication is done in kernel mode.

True specifies that Windows authentication uses kernel mode.
Kernel-mode authentication may improve authentication

performance and prevent authentication problems with
useKernelMode
application pools that are configured to use a custom identity.
As a best practice, do not disable this setting if you use Kerberos

authentication and have a custom identity on the application
pool.
The default is true.
Child Elements
Element Description
Optional element.
extendedProtection Specifies extended protection options for Windows authentication.
Note: This element was added in IIS 7.5.
Optional element.
providers
Specifies security support providers used for Windows authentication.
Configuration Sample
The following default <windowsAuthentication> element is configured at the root

ApplicationHost.config file in IIS 7.0, and disables Windows authentication by default. It also
defines the two Windows authentication providers for IIS 7.0.
<windowsAuthentication enabled="false">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
tmg.edu.au | 1300 888 TMG (1300 888 864)
</windowsAuthentication>
The following example enables Windows authentication and disables Anonymous

authentication for a Web site named Contoso.
<location path="Contoso">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
Sample Code
The following examples disable Anonymous authentication for a site named Contoso, then
enable Windows authentication for the site.
AppCmd.exe
appcmd.exe set config "Contoso" -

section:system.webServer/security/authentication/anonymousAuthentication
/enabled:"False" /commit:apphost
appcmd.exe set config "Contoso" -

section:system.webServer/security/authentication/windowsAuthentication /enabled:"True"
/commit:apphost
Note: You must be sure to set the commit parameter to apphost when you use AppCmd.exe
to configure these settings. This commits the configuration settings to the appropriate
location section in the ApplicationHost.config file.
C#
using System;
using System.Text;
using Microsoft.Web.Administration;
internal static class Sample {
private static void Main() {
using(ServerManager serverManager = new ServerManager()) {

tmg.edu.au | 1300 888 TMG (1300 888 864)
Configuration config = serverManager.GetApplicationHostConfiguration();
ConfigurationSection anonymousAuthenticationSection =
config.GetSection("system.webServer/security/authentication/anonymousAuthentication",
"Contoso");
anonymousAuthenticationSection["enabled"] = false;
ConfigurationSection windowsAuthenticationSection =
config.GetSection("system.webServer/security/authentication/windowsAuthentication",
"Contoso");
windowsAuthenticationSection["enabled"] = true;
serverManager.CommitChanges();
}
}
}
VB.NET
Imports System
Imports System.Text
Imports Microsoft.Web.Administration
Module Sample
Sub Main()
Dim serverManager As ServerManager = New ServerManager
Dim config As Configuration = serverManager.GetApplicationHostConfiguration
Dim anonymousAuthenticationSection As ConfigurationSection =

config.GetSection("system.webServer/security/authentication/anonymousAuthentication",
"Contoso")
anonymousAuthenticationSection("enabled") = False
Dim windowsAuthenticationSection As ConfigurationSection =

config.GetSection("system.webServer/security/authentication/windowsAuthentication",
"Contoso")
windowsAuthenticationSection("enabled") = True
serverManager.CommitChanges()
End Sub
End Module
JavaScript
var adminManager = new

ActiveXObject('Microsoft.ApplicationHost.WritableAdminManager');
tmg.edu.au | 1300 888 TMG (1300 888 864)
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST";
var anonymousAuthenticationSection =
adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAu
thentication", "MACHINE/WEBROOT/APPHOST/Contoso");
anonymousAuthenticationSection.Properties.Item("enabled").Value = false;
var windowsAuthenticationSection =
adminManager.GetAdminSection("system.webServer/security/authentication/windowsAuth
entication", "MACHINE/WEBROOT/APPHOST/Contoso");
windowsAuthenticationSection.Properties.Item("enabled").Value = true;
adminManager.CommitChanges();
VBScript
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")

adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST"
Set anonymousAuthenticationSection =
adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAu
thentication", "MACHINE/WEBROOT/APPHOST/Contoso")
anonymousAuthenticationSection.Properties.Item("enabled").Value = False
Set windowsAuthenticationSection =
adminManager.GetAdminSection("system.webServer/security/authentication/windowsAuth
entication", "MACHINE/WEBROOT/APPHOST/Contoso")
windowsAuthenticationSection.Properties.Item("enabled").Value = True
adminManager.CommitChanges()
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 7
What is the difference between machine (computer) and network server authentication.
Use a windows environment for your examples.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 7
tmg.edu.au | 1300 888 TMG (1300 888 864)
Ensure features and capabilities of network service security options meet the business needs
How Businesses Use Security Technologies
Network security has become a requirement for businesses, especially those that rely on the
Internet. Your customers, vendors and business partners probably expect you to protect any
information they share with you.
While network security has almost become a prerequisite to running a business, it also pays
off in multiple ways. Here are some of the benefits businesses gain from a secured network:
Customer trust
 Privacy is assured
 Collaboration is encouraged
A strong security stance assures customers that sensitive information, such as credit card
numbers or confidential business details, will not be accessed and exploited. Your business
partners will feel more confident sharing data such as sales forecasts or pre-release product
plans. In addition, the same technologies that keep intruders out can give your partners
secure access to information on your network, helping you collaborate and work together
more effectively.
Mobility
 Secure access on the road

 Promotes productivity while out of the office
Strong network security lets your employees safely access your network from the road or from
home without introducing viruses or other threats. Secure, convenient network access means
that employees can use critical information when they need it, making them more
productive when they're away from their desks.
Improved productivity
 Less time wasted on spam

 Better employee morale and collaboration
An effective network security program can boost productivity across your organization.
Employees spend less time on non-productive tasks such as sifting through spam or dealing
with viruses. Your network and your Internet connection remain safe, ensuring you and your
employees have regular access to the Internet and e-mail.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Reduced costs
 Service disruption is avoided

 Advanced services safely evolve
Network downtime is costly to all types of businesses. By ensuring your network and your
Internet connection are safely up and running, you can be sure that customers can reach
you when they need you. Effective security allows your business to add new services and
applications without disrupting the performance of your network. Taking a proactive
approach to safeguarding your data ensures your business remains up and running when it
needs to be.
As your company grows, its networking needs will change. Establishing a strong, secure
network today will allow your company to add advanced features such as secured wireless
networking or voice and conferencing.
Getting Started with Network Security
Matching the needs of your business with the right security technologies is the first step to
launching a network security project.
Use the following list of considerations to get you started:
Your current security level

Take an inventory of the security features your network already has. This list will help identify
gaps in your current protection methods.
 Does it offer firewalls, a virtual private network, intrusion prevention, virus protection, a
secured wireless network, anomaly detection, and identity management and
compliance validation?
 Do these features communicate with one another?
Your assets
Make a "laundry list" of your assets to determine how many levels, or layers, of protection your
system needs.
 Within your particular business, what assets are the most critical to your success?
 Is protecting your internal information most important; your customers' information; or
both?
 How much are these assets worth?
 Where do these assets reside within you system?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Information transfer
Assess how information is shared inside and outside of your company.
 Do your employees need quick access to internal information in order to do their

jobs?
 Do you share data outside the four walls of your business?
 How do you control who has access to this information?
 Do you provide varying levels of access to different network users?
Plans for growth

Is your company planning on adding advanced features to your system? How adaptable
and flexible will your system need to be? Your security solution should be able to
accommodate increased network traffic or advanced applications without disrupting
service.
Risk assessment
Determine if the consequences of a security breach extend beyond lost productivity or an
interruption in service.
 How regulated is your business environment?

 What are the risks of non-compliance?
 How much downtime can your business tolerate before financial or reputation losses
accrue?
Ease of use
The best security technology will do you no good if it can't easily be installed or used. Make
sure you have the resources to manage the system you install.
Business and Network Security
In today’s global, digital world, data rule. Safeguarding intellectual property, financial
information, and your company’s reputation is a crucial part of business strategy. Yet with the
number of threats and the sophistication of attacks increasing, it’s a formidable challenge.
PwC’s US Security Leader Gary Loveland and Security Principal Mark Lobel reveal how
company leaders can protect—and strengthen—the business with the right approach to
information security.
Information security probably isn’t something that gets a lot of executive attention. It’s the
CIO’s job or the responsibility of his lieutenants. Yet every so often when scanning the
headlines, news about the latest high-profile cyberattacks elevates your blood pressure as
you wonder: Could that happen to us? What would be the impact on our business? How
would we respond to customers and shareholders?
But then it’s often back to the more pressing issues of the day, and the state of your
company’s information security recedes to the background. You won’t likely give it another
thought—until there’s an incident. Then it’s damage-control mode, as the company deals
tmg.edu.au | 1300 888 TMG (1300 888 864)
with stolen customer data, disclosure of confidential financial information, a disabled Web
storefront, or worse.
This reactive approach is all too common, even though the question is not if a company will
suffer an incident but when. In the annual PwC, CIO, and CSO survey of more than 9,600
global executives, 41 percent of US respondents had experienced one or more security
incidents during the past year.1 And that number is rising. Respondents reported financial
losses, intellectual property theft, reputational damage, fraud, and legal exposure, among
other effects. (See Figure 1.) With such high stakes, most would agree that information
security deserves full attention at the highest levels of the company.
Figure 1
US business impact of security incidents
Government leaders, at least, are taking notice: Lawmakers, the Securities and Exchange
Commission (SEC), and the Administration have been highlighting increased security risks and
the need for both the private and public sectors to step up their security game. In October
2011, the SEC issued guidance on the disclosure of cybersecurity risks and incidents.2 While
the guidance didn’t propose new requirements, it reminded company leaders—and boards
tmg.edu.au | 1300 888 TMG (1300 888 864)
of directors—of their obligations under current rules. That same month, in the aftermath of
disclosures by WikiLeaks, President Obama issued an Executive Order calling for measures to
enhance national security in order to reduce the risk of a similar breach in the future.3 These
developments follow ongoing efforts to move cybersecurity legislation through Congress and
into law.
Perception versus reality
Back in the corporate world, is cybersecurity still considered a purely technical matter? Or do
businesses understand that it is the lynchpin for safeguarding their most precious assets—
intellectual property, customer information, financial data, employee records, and much
more?
It depends upon whom you ask. The PwC, CIO, and CSO survey revealed that executives
may say and believe one thing, but the data and expert analysis indicate that they do
another. First, the survey asked, How confident are you that your organization’s information
security activities are effective? Seventy-two percent of respondents answered that they
were very confident or somewhat confident.4 However, when executives were asked to
characterize their company’s approach to information security, identifying whether they
possess an information security strategy and have proactively implemented it, the positive
results took a nosedive.
14%
of executives surveyed admitted to lacking a strategy and being reactive when it came to
information security.
Just 43 percent of respondents self-identified as Front-runners; that is, those who felt they
have an effective information security strategy in place and are proactive in executing the
plan. Those who saw themselves as Strategists (27 percent) felt they have the big picture right
but fall down on execution, while Tacticians (15 percent) said they are better at getting
things done than in defining a broader strategy. Finally, the Firefighters (14 percent globally
but 22 percent in the US) admitted to lacking a strategy and to being reactive regarding
information security.5
But when it came time to let the data do the talking, the companies that were “walking the
walk” and not merely “talking the talk” were significantly fewer: just 13 percent of
respondents. (See Figure 2.) These leading companies not only have an information security
strategy in place, but they demonstrate a number of other leading practices, including
having a high-level security chief, regularly measuring and reviewing the effectiveness of
their policies and procedures each year, and possessing a deep understanding of the types
of security events that have occurred in their organizations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 2
Differing views of information security effectiveness and leadership
The majority of executives in the survey—72%—reported being very confident or somewhat
confident that their organization’s information security activities were effective. Yet just 43%
described themselves as Front-runners, meaning they had a strategy in place and
proactively executed it. But when we analyzed their information security practices, only 13%
of companies could be considered True Leaders.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Barriers to effective cybersecurity
Figure 3
Primary obstacles to information security, by senior executive
tmg.edu.au | 1300 888 TMG (1300 888 864)
Addressing information security can be especially challenging because executives do not

always agree about company issues and goals. In the survey, we asked respondents what
the greatest obstacles were to improving their organization’s information security. While the
number one response predictably was about resources—insufficient funding for capital
expenditures—the answers often changed when we looked more specifically at who was
answering.
CEOs agreed that lack of capital funding was the problem, but CFOs indicated a lack of
leadership from the CEO was the reason. Meanwhile, CIOs and security executives pointed
to a lack of actionable vision or understanding within the organization.
Four growing cyberthreats
The companies in this top tier—whom we refer to as security leaders—understand that they
are up against different types of cyberthreats. There essentially are four types of attacks,
each of which has a different motive. It’s helpful to think of these as storm waves, swirling
around your business. At any given time, it is impossible to know which wave will hit and what
type of damage it will wreak.
The first and oldest wave is nuisance hacking, in which there is little material impact to the
company. A classic example is hackers defacing your company’s website. More serious and
widespread is the second wave, which is hacking for financial gain.
As business has migrated to the digital world, criminals have, too. What has emerged is a
sophisticated criminal ecosystem that has matured to the point that it functions much like
any business—management structure, quality control, offshoring, and so on. This type of
hacking now goes beyond blindly stealing customer credit card information or employee
passwords. For example, hackers might target a company’s financial function in order to
obtain its earnings report before it is publicly released. With such advance knowledge, they
can profit by acquiring or dumping stock.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Protecting the business from cybercrime is one thing, but companies also must worry about a
new type of risk—the advanced persistent threat. If you think the term sounds like it’s out of a
spy movie, you’re not far off. This type of hacking is predominantly about stealing intellectual
property and typically is associated with state-sponsored espionage. The motives go beyond
financial gain. Experts may quibble about the specifics of this type of attack and whether it
always has involved use of advanced techniques, but this is a serious and growing threat. It is
not an understatement to say that what’s at risk is not only your intellectual property but
possibly national security.
The high-profile Stuxnet worm case demonstrates how specialized and sophisticated these
attacks can be. The Stuxnet worm that was discovered in 2010 was designed to infiltrate
industrial control systems, such as those that manage water or power plants. But it wasn’t an
infrastructure system that was hit; hackers infiltrated and potentially sabotaged the Iranian
systems that manage uranium. As the chilling details emerge, what’s noteworthy is that the
attack was planned (and the worm developed and placed) as many as four years ahead of
the incident.
This foresight echoes a trend we have seen in our work with companies such as defense
contractors. When they announce plans to acquire another company, perpetrators go after
the potential acquisition. Their hope is to embed malicious software on the systems of the
acquisition target so that when the companies ultimately are integrated, hackers will have
access to the parent company’s systems—even if it means biding time for 18 to 24 months or
longer.
And it’s not only specialized industries like defense that are at risk for advanced persistent
threats. We have seen considerable activity in the financial services and technology
industries. In some cases, the perpetrators infiltrate a bank or service provider in order to get
access to the organization’s customers’ systems.
Finally, there’s one more type of threat that is on the rise: hacktivism. WikiLeaks immediately
comes to mind, but, for the private sector, think of this as the digital equivalent to Occupy
Wall Street. The goal of perpetrators is to change or create a public perception of your
brand. For example, hackers might obtain sensitive information and disclose it to the public.
Keeping pace with new technologies
Not only do companies face a myriad of threats, their exposure grows as they invest in
technologies like mobile, social, and cloud. In the survey, only a minority of US companies
had strategies in place to protect against the risks that these new technologies bring. 6 (See
Figure 3.)
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4
Companies addressing security risks from new technologies
Mobile, in particular, challenges the business because suddenly corporate data can be
widely accessed outside of the enterprise. And employees often don’t realize the risks being
introduced when sharing, sending, or receiving corporate information on a smartphone or
tablet, especially if it is a personal device.
Likewise, with social media, where the line

between personal and professional can
become blurry, employees inadvertently may
be disclosing sensitive information. Called
data leakage, it can happen when
employees share seemingly innocuous details,
such as the airport they are in or the coffee
shop they are frequenting every morning.
Others within their social networks can use
these clues, along with profile information about their jobs (bankruptcy attorney, M&A
specialist), to ferret out potentially sensitive information, such as the identity of a financially
troubled company or a potential acquisition target.
Strategies for strengthening the business
With so many risks, business leaders may be unsure of where to focus. In our experience, it is
crucial to elevate the role of information security in the organization and emphasize the fact
that it is not just a technology function. As a make-or-break business issue, it requires a leader
who reports directly to a senior executive. The title of the person—chief security officer, chief
information security officer, security director—isn’t what matters. Instead, it’s the ability of that
individual to bring security issues to the C-suite and help the management team think and
talk about how security affects every other business decision.
Effective security leaders consistently demonstrate the linkages between security and the
company’s goals. They remind the rest of the management team that security is a strategic
tmg.edu.au | 1300 888 TMG (1300 888 864)
issue. In the survey, the Front-runner group emphasized this approach by citing client
requirements as the driving force behind the company’s information security investments.
The other respondents pointed to legal and regulatory requirements as the main justification
for information security spending in their organizations.
An organization that embraces this mindset, for example, might engage the security leader
and the sales leader, together, to consider how better information security can help close or
speed sales. They might determine that having well-documented information security
controls, processes, or certifications in place enables them to anticipate and address
customer concerns immediately when or before the issue first is raised.
Some companies we work with find it effective to have security leaders embedded within
each business unit. These individuals report to line-of-business heads and work directly with
them to evaluate how security can support each group’s business goals.
Where’s the data?
Companies that understand the value that security brings to the business also ensure that
they have a comprehensive strategy in place—and that they have the processes and
procedures to back up their vision. The guiding principles for strategy are driven, in large part,
by their data. Companies will want to ask a seemingly simple question: What’s our most
sensitive data?
Surprisingly, many companies can’t begin to answer that question. Company leaders will
need to identify their most sensitive data. They’ll consider business assets like intellectual
property, as well as information that they have a fiduciary responsibility to protect, including
customer, business partner, or employee data.
As companies undertake this foundational exercise, they will ask: What data do we have?
Where are they located? What laws and regulations apply to them? What controls do we
have around them? Are we sending data to third parties? If so, is it being handled securely?
There’s much work to be done here: In the survey, only 29 percent of companies have an
accurate inventory of data—a decline of 10 percent from just two years ago.
For companies that have grown through mergers and acquisitions, there’s the additional
hurdle of getting a handle on disparate data sources—not to mention different policies,
processes, and systems that were inherited with each merger or acquisition.
In the process of evaluating what’s currently in place and where the company’s attention
needs better focus, some organizations find it helpful to conduct an outside assessment of
their current operations. Often, when companies get a glimpse into what really is going on,
they are surprised. They discover that the biggest problems may be caused by their
employees.
For example, companies may find that workers lack even a basic awareness of the
information security risks to which employees are subjecting the business when they don’t
tmg.edu.au | 1300 888 TMG (1300 888 864)
follow policy—for example, they fail to change default passwords or they leave their
computers on when they go home. Some companies bring in outside security experts to
conduct an assessment, particularly if an organization wants to test the security of its
networks. This so-called ethical hacking attempts to penetrate a company’s network to
pinpoint vulnerabilities.
In our work as security specialists, the trend we’ve observed is that companies have become
much better about protecting the organization from the outside. But once a perpetrator is
able to gain access to an internal network—whether by walking in the door and plugging
into a network jack or via malware that is dormant on a USB drive that an employee picks up
in the parking lot and plugs into his networked computer—we always have been able to
gain levels of unauthorized access.
A security assessment also might reveal that the company has not kept up with a changing IT
environment, especially one in which business units or employees have independently
added their own devices or applications to the mix. All too often, businesses maintain the
status quo but don’t adequately address how these latest technologies and new ways of
working put them at risk.
Testing, testing, testing
100% of the companies we defined as security leaders measure and review the effectiveness
of their security policies and procedures annually.
Recognizing that organizations are dynamic—and that criminals always are innovating—it’s
especially important for companies to consistently monitor and test what they have in place.
In the survey, the companies that we defined as True Leaders measure and review the
effectiveness of their security policies and procedures annually (compared with just 54
percent of other respondents). These organizations also know where they are vulnerable and
need to shore up their defences. This is significant because just a few years ago, almost half
of the survey’s respondents couldn’t answer the most basic questions about the nature of
security-related breaches; now approximately 80 percent or more of respondents can
provide specific information about the frequency, type, and source of security breaches
their organizations faced. And they are seeing results: The leaders reported half as many
information security incidents per year, compared with the rest of survey respondents.
50% fewer information security incidents were experienced by the security leaders,
compared with the rest of the survey respondents.
Companies that are proactive about information security also consider the impact of
breaches—especially given that these events are on the rise. Of those, risks associated with
customers, partners, or suppliers are a major concern, having nearly doubled in the past two
years. This situation is compounded by the fact that given recent economic uncertainty,
security has not been a priority. The levels of investment, awareness, and training all have
declined.
tmg.edu.au | 1300 888 TMG (1300 888 864)
In thinking about potential breaches, organizations will determine to whom they need to
disclose an event. This issue is gaining more attention in light of the SEC’s recent guidance on
the matter, reminding public companies that the following impacts must be included:
remediation costs to customers or partners, increased information security investments
required to remedy the situation, lost revenues due to breach, litigation resulting from
breach, and reputational damage affecting customer or investor confidence. Company
management and boards will want to consider the balancing act required to fulfill these
responsibilities to investors and customers while ensuring that leadership does not disclose
information that would make the company further vulnerable to hackers.
Follow the leaders
Leading companies today are rethinking the role of information security in their organizations.
They realize that in a digital world, cybersecurity is the key to safeguarding their most
precious assets—intellectual property, customer information, financial data, and employee
records, among others. But far more than a defensive measure, companies also know that
cybersecurity can better position their organization with business partners, customers,
investors, and other stakeholders.
Additionally, a sustained approach to security enables companies to better take advantage

of newer technologies—mobile, social media, and cloud—that are driving business growth
for many organizations. Company executives are leading the charge, working across the
business to assess the current environment, define their most sensitive data, assign
accountability, devise a strategy, and measure their progress. With strong leadership and a
comprehensive approach that continually links information security back to business
strategy, top managers will better position their organizations for success.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 8
Why is it important to match network service security options to business needs? Is there a
one-size-fits-all option that can be applied to all businesses?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 8
tmg.edu.au | 1300 888 TMG (1300 888 864)
Produce or update server security design documentation to include new solutions
Network documentation can provide valuable information to

service providers as well as providing backup in the event of a
catastrophic network failure. Learn how to ensure a smooth
network documentation process with these 10 steps.
Although network documentation is always a good idea, it's especially important for service
providers and value-added resellers (VARs). Documenting your customers' networks can
make the troubleshooting process much more efficient when problems arise. These same
network documents can also help you spot areas of your customers' networks that may need
to be upgraded, giving you the possibility of earning extra revenue. Finally, good network
documentation proves that you adhere to industry best practices, and could be your best
defense should a customer ever file litigation against you for something network-related.
There are a number of network documentation products available that can assist with the
documentation process, and Windows Vista also has mapping capabilities built in. Some of
the more well-known network documentation applications include:
 SmartDraw
 QonDoc
 LAN Surveyor
 NetZoom
 ConceptDraw
 Microsoft Vision 2007
Create a network documentation policy
A network documentation policy should detail what aspects of a network need to be

documented, especially each server. A documentation policy also communicates to each
administrator exactly what is expected of them regarding the documentation process.
Sample Network Documentation Policy
Network Documentation Policy
1.0 Overview
This network documentation policy is an internal IT policy and defines the requirements for
network documentation. This policy defines the level of network documentation required
such as documentation of which switch ports connect to what rooms and computers. It
defines who will have access to read network documentation and who will have access
to change it. It also defines who will be notified when changes are made to the network.
tmg.edu.au | 1300 888 TMG (1300 888 864)
2.0 Purpose
This policy is designed to provide for network stability by ensuring that network
documentation is complete and current. This policy should complement disaster
management and recovery by ensuring that documentation is available in the event that
systems should need to be rebuilt. This policy will help reduce troubleshooting time by
ensuring that appropriate personnel are notified when changes are made to the network.
3.0 Documentation
The network structure and configuration shall be documented and provide the following
information:
1. IP addresses of all devices on the network with static IP addresses.
2. Server documentation on all servers as outlined in the “Server Documentation”
document.
3. Network drawings showing:
a) The locations and IP addresses of all hubs, switches, routers, and firewalls on the
network.
b) The various security zones on the network and devices that control access between
them.
c) The locations of every network drop and the associated switch and port on the switch
supplying that connection.
d) The interrelationship between all network devices showing lines running between the
network devices.
e) All subnets on the network and their relationships including the range of IP addresses on
all subnets and net mask information.
f) All wide area network (WAN) or metropolitan area network (MAN) information including
network devices connecting them and IP addresses of connecting devices.
4. Configuration information on all network devices including:
a) Switches
b) Routers
c) Firewalls
5. Configuration shall include but not be limited to:
a) IP Address
b) Netmask
c) Default gateway
d) DNS server IP addresses for primary and secondary DNS servers.
e) Any relevant WINS server information.
6. Network connection information including:
a) Type of connection to the internet or other WAN/MAN including T1,T3, frame relay.
b) Provider of internet/WAN/MAN connection and contact information for sales and
support.
c) Configuration information including net mask, network ID, and gateway.
d) Physical location of where the cabling enters the building and circuit number.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4.0 Access
The IT networking and some enterprise security staff shall have full access to all network
documentation. The IT networking staff shall have the ability to read and modify network
documentation. Designated enterprise security staff shall have access to read and
change network documentation but those not designated with change access cannot
change it. Help desk staff shall have read access to network documentation.
5.0 Change Notification

The help desk staff, server administration staff, application developer staff, and IT
management shall be notified when network changes are made including.
a) Reboot of a network device including switches, routers, and firewalls.
b) Changes of rules or configuration of a network device including switches, routers, and
firewalls.
c) Upgrades to any software on any network device.
d) Additions of any software on any network device.
Notification shall be through email to designated groups of people.
6.0 Documentation Review

The network or IT manager shall ensure that network documentation is kept current by
performing a monthly review of documentation or designating a staff member to perform
a review. The remedy or help desk requests within the last month should be reviewed to
help determine whether any network changes were made. Also any current or completed
projects affecting network settings should be reviewed to determine whether there were
any network changes made to support the project.
7.0 Storage Locations

Network documentation shall be kept either in written form or electronic form in a
minimum of two places. It should be kept in two facilities at least two miles apart so that if
one facility is destroyed, information from the other facility may be used to help construct
the IT infrastructure. Information in both facilities should be updated monthly at the time of
the documentation review.
Create a network topology diagram
Ideally, you want this map of the network's topology to include each network segment, the
routers connecting the various segments, and the servers, gateways and other major pieces
of networking hardware that are connected to each segment. For larger networks, you may
have to create a general segment map and make more specific maps of each individual
segment.
Document server names, roles and IP addresses

tmg.edu.au | 1300 888 TMG (1300 888 864)
While the information included in a network topology diagram is not necessarily specific,
there is certain information that you should include for each server, even if that information
has to be placed in an appendix. For each server, list the server's name, its IP address and
the role that the server is performing (DNS, DHCP, mail server, etc.). Keep in mind that a
server may be assigned multiple IP addresses or have multiple NICs, so you should document
that information too.
Activity 9
The Network Topology Mapper application can auto-detect changes to

network topology. Why would this be an advantageous feature when
producing or updating server security design documentation to include
new solutions?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 9
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 9
tmg.edu.au | 1300 888 TMG (1300 888 864)
Create a change log for each server
When a server fails, the failure can often be traced to a recent change. As a part of the
network documentation, consider making a log book for each server for documenting
changes such as patch and application installations and modified security settings. Not only
will the log help you troubleshoot future problems, it can help you rebuild the server in the
event of a catastrophic failure.
Document software versions and proof of licenses
Document the applications and their versions running on each server. You might also include
a copy of the software license or a receipt within this documentation just in case your
customer becomes involved in a software audit.
Document hardware components
I have talked about documenting individual servers, but it's equally important to document
switches, routers, gateways and other networking hardware. The documentation should
include information such as:
 How is the device connected to the network?

 How is the device configured?
 Does a backup of the configuration exist?
 What firmware revision is the device running?
 Is the device configured to use a password? (Don't include the actual password, but
you can include a password hint or a reference to the password being written in a
notebook that is stored in the safe.)
Document the Active Directory
Here are a few things that you should consider documenting:
 The names of the domains in the forest.

 The Active Directory site structure.
 Where the various servers exist within the Active Directory hierarchy.
 The location and contents of each group policy.
 Any external trusts that may exist.
Document your backup procedures
Backup is your customer's best defense against a catastrophe, but it will do little good if
nobody can figure out how to use it. Be sure to document the backup software used and its
tmg.edu.au | 1300 888 TMG (1300 888 864)
version (very important). You will also want to document the tape rotation scheme, a
general description of what's included in each backup job and where the backup tapes are
stored.
Label everything
I once had a client ask me to do a consulting project for them. They gave me a thorough
and well-written copy of their network documentation to review ahead of time. But when I
got on site, I realized that none of the hardware was labeled. All of the servers looked
identical and there was no way to differentiate between them.
Get a label maker and label all servers, critical hardware components (gateways, routers,
etc.) and the most important cables. This will make it easy to identify the various pieces of
hardware listed in your network document.
Evaluate your documentation
The last step in the documentation process is to evaluate your network documentation to
make sure that it's sufficient for you and your customer's needs. Think of your network
documentation as a critical part of your disaster recovery strategy. When the first draft of
your documentation is complete, you must ask yourself if it's good enough to help someone
with no prior knowledge of the setup to rebuild the network from scratch in the event of a
catastrophe. If the answer is yes, then you've done a good job on the documentation.
Creating Your Solution Design and Architecture, Project Plans, and Project Schedule
Introduction to the Planning Phase
The Planning Phase is the time when the project team translates the initial vision/scope from
the Envisioning Phase into practical plans on how to achieve it. The purpose of the Planning
Phase is to define the solution in detail along with the approved project plan and schedule.
This work includes creating a functional specification, developing the solution architecture
and design, and preparing cost estimates. Team members draw upon their expertise to
create detailed individual plans, such as the development plan, test plan, and deployment
plan, as well as schedules for all aspects of the project. Program Management combines
these individual plans and schedules and synchronizes them to create the master project
plan and schedules. The Planning Phase culminates in the Project Plans Approved Milestone.
Passing this milestone indicates that the customer, the project team, and all stakeholders
agree on the details of the plans, including what will be built, how it will be built, when it will
be delivered, and what it will cost.
Planning Phase Tasks
The major migration tasks conducted during the Planning Phase are summarized in the
following list. They will be described in more detail in the subsequent sections.
tmg.edu.au | 1300 888 TMG (1300 888 864)
1. Developing the solution design and architecture. The development team begins the
design process with the solution design and architecture and culminates it with a
design document that becomes part of the functional specification.
2. Validating the technology. The development team also validates technologies to
ensure that they meet the business needs for the specific solution.
3. Creating the functional specification. The project team and Program Management
Role create a functional specification that describes the solution requirements, the
architecture, and the detailed design for all the features. This represents the contract
between the project team and customer.
4. Developing the project plans. The Program Management Role and the various teams
that make up the project team develop a collection of plans to define the tasks for
all six MSF team roles, and Program Management consolidates them into a master
project plan.
5. Creating the project schedules. The Program Management Role and the various
teams create milestone-driven schedules for each individual team role, and Program
Management consolidates them into the master project schedule.
6. Setting up the development and test environment. The development and test teams
create development and testing environments that are independent of the
production environment to develop and test the solution.
7. Close the Planning Phase. The project team completes the Planning Phase with the
approval process for the Project Plans Approved Milestone.
Note Although listed sequentially, many of these activities can be performed concurrently.
Planning Phase Deliverables
The Planning Phase activities culminate in a major milestone, the Project Plans Approved
Milestone. By the end of the Planning Phase, the project team and all major stakeholders
(other members of the organization who will be affected by the project) should have agreed
upon the functional specification, technology for the solution, and project plans and
schedule. These deliverables include:
 A technology validation-complete document that:

o Documents the current environment.
o Develops and tests the key features in the solution with a proof of concept.
o Documents all the potential issues and their resolution.
 A functional specification document that:
o Describes requirements of all the components of the solution.
o Describes solution design and architecture of the components.
o Provides quantitative specifications about performance measures, database
capacity, and concurrent usage and security measures.
 A master project plan of the solution that:
o Contains individual plans for various roles.
o Guides the project completion as per the functional specification.
 A master project schedule that:
o Integrates all the schedules along with release dates.
tmg.edu.au | 1300 888 TMG (1300 888 864)
o Creates awareness about project priorities.

 A risk management document that:
o Identifies the potential risks and mitigation strategies.
 An instruction document on setting up the development and test environments that:
o Creates a proper development and testing environment for the solution
without affecting the production system.
o Identifies the hardware and infrastructure requirements for the environment.
Together, these deliverables comprise a high-level design description and plan of the project
that form the basis for the subsequent phases. Therefore, the functional specification
document, especially, must be viewed as a living document that keeps changing, subject to
change control. The deliverables may undergo numerous iterations before the project team,
the customers, and the stakeholders reach a final consensus.
Instructions for setting up the development and test environments are explained in Chapter
4, “Planning: Setting Up the Development and Test Environments” of this volume.
Planning Phase Activities
The following sections detail the various activities involved in the Planning Phase of the MSF
Process Model and how these activities specifically relate to a migration project.
Developing the Solution Design and Architecture
The development of the solution design and architecture begins with a design process, the
results of which become the functional specification. The design process helps identify the
project team structure and the team's responsibilities for the upcoming Developing Phase.
The foundation of the design process is the vision that the team developed and the business
goals that were gathered during the Envisioning Phase. The architectural design describes
how features and functions operate together to form the solution. It identifies the specific
components of the solution and their relationships.
The design document contains details of the architecture and the components that go into
building the solution. For UNIX-to-Windows migration projects, the solution architecture
remains the same; however, to include it in the design document ensures completeness. This
helps the team to work in a systematic way—from abstract concepts in the vision/scope
document down to specific technical details in the design process. It also helps to maintain
the correlation between the requirements and the solution features.
Conceptual Design
The conceptual design stage includes the process of analyzing and prioritizing business and
user perspectives of the problem and the solution, and then creating a high-level
representation of the solution. This stage helps in mapping the functionality associated with
each of the requirements.
tmg.edu.au | 1300 888 TMG (1300 888 864)
A conceptual design is a means to understand the business expectations and application

requirements that include both technical and infrastructure requirements in terms of business,
user, system, and operational requirements. The design formulates the solution to be
developed, keeping in mind the end users and the business requirements. It is therefore
essential to answer all questions in the assessment checklist provided with this guide. This
helps to assess the current situation and further define the project scope developed during
the Envisioning Phase in order to obtain a clear understanding of the functionality required to
build the solution.
The conceptual design lays the foundation for developing the solution and addresses the
requirements by describing the design and architecture of its components.
For migration projects, the conceptual design is generally identical to the original
functionality of the current application or infrastructure component. It is nonetheless
important to articulate the existing design in the functional specification for the migration
project because the actual concept for the current component may have drifted from its
initial conception. Even if that conceptual design has remained constant, it serves as a
touchstone for subsequent design phases.
The following example demonstrates what is meant by conceptual design.
Example of a Conceptual Design
Consider an engineering graphics application developed in UNIX that is used by the design
staff within an organization. Because of evolving business requirements and a globalized
environment, the organization now wants to make use of the capability of its external
partners to provide design solutions using the same application.
To achieve this, the application needs to be available on the Microsoft® Windows® platform,
which most of its suppliers have already standardized on.
Migrating this application to the Windows platform enables it to be shared with the partners,
resulting in an increased degree of collaboration between users who use the application,
both within the organization and outside.
The conceptual design should document any unique requirements that would arise in this
new environment and verify that the proposed solution architecture caters to these
requirements.
Logical Design
During the logical design stage, each part of the conceptual design is assigned to a specific
role within the architecture of the solution. It provides a clear view of the solution from the
functional perspective. A logical design identifies and defines all the objects and their
behaviors, attributes, and relationships within the scope of the solution. The application
design is split into three levels: presentation, business, and the data layer. For a migration
tmg.edu.au | 1300 888 TMG (1300 888 864)
project, you must document the existing logical design as well as the logical design of the
migrated application or infrastructure component and emphasize the areas of change if
applicable. It is also important to show how the migration project affects the other
components outside the scope of the project.
Example of Logical Design
Continuing with the same engineering application example, the logical design documents
the existing as well as the new architectural components required to realize the conceptual
design. The presentation layer can be achieved by a Windows user interface (UI) instead of
the existing X-Motif–based user interface. The communication layer can be achieved by
Winsock or .NET messaging in place of the existing UNIX sockets calls.
It may also be necessary to show how the migrated applications interact with other
components outside the scope of the migration project. For example, it is possible for
applications on the partner’s side to exchange data with the migrated application on
Windows.
Physical Design
The physical design of the solution identifies the pieces from the logical design that must fit
into the physical architecture. The physical design identifies the physical infrastructure
architecture and topology. It creates a set of physical design models, including the
component’s design, UI design, and a physical database design for the applications. The
physical design should include anticipated metrics to assess performance goals, uptime
goals, and milestones for writing the solution code. For example, the physical design might
include metrics for transaction time and performance requirements for the transactions
before deployment. Production metrics for the particular deployment scenarios must also be
established.
The physical design is a complete implementation design, in the form of a technical

specification, that the development team uses to build the solution. For a migration project,
the physical design should also include the process of implementing the infrastructure and
the step-by-step details of how to deploy the migrated application, keeping in mind the
current milestones of the application. It must also cover how the new implementation satisfies
the business requirements without violating ongoing service level agreements (SLAs).
Example of Physical Design
The physical design of the application might describe which components in each of the
layers (presentation, business, and data) need to be changed in one of the following ways:
 Ported to recompile and fix problems that arise.

 Rewritten if there is no corresponding library or component available on Windows.
 Replaced if an equivalent library is available in Windows.
 Purchased if the library or component is to be bought from third-party vendors.
tmg.edu.au | 1300 888 TMG (1300 888 864)
It might also provide a detailed mapping of the source UNIX architecture to the target
Windows architecture, where each component/library of the UNIX application is mapped to
one that provides equivalent functionality on Windows.
Validating the Technology
Often, in tandem with the design process, your team can also validate the technologies
being used in the solution. In the technology validation process, the team evaluates the
products or technologies to ensure that they work according to the specifications provided
by their vendors and that they address the business needs for the specific solution scenario.
Validating the technology is an essential step in a UNIX-to-Windows migration project
because the tools, software, and hardware in the new Windows environment must work
together to produce the same or better effect than that produced in the UNIX environment.
For example, if the UNIX application uses a third-party library and if a Windows version of it is
also available, it would be a good idea to check if the Windows equivalent of the library
works according to the required specifications.
Technical Proof of Concept
After validating the technologies, the team makes an initial attempt at creating a model of
the technology that will be implemented. This produces a proof of concept. The initial proof-
of-concept model often produces both answers and additional questions for the team
about the issues that might arise with the technology during the Developing Phase. This
information helps in the risk management process and identifies overall design changes that
must be incorporated into the specifications.
The various libraries or modules in the UNIX application can be listed in the functional
specification document, as shown in the following proof-of-concept identification table for a
sample banking solution application.
Table 3.1. Sample Proof-of-Concept Identification
Name of Library or Area or Layer of the Functionality Prototype

Module Application Covered Required (Y/N)?
LoanInterestCalLib Loans–Business Layer Interest calculating N
routines
AuthenticationLib User Authentication– Secured login N
Business Layer routines
Super-annuityLib Retirements–Business Retirements Y
Layer routines
DataAccessLib DataAccess Layer Database routines Y
In a UNIX-to-Windows migration project, the proof of concept typically addresses such areas
as the compatibility and suitability of certain third-party libraries in the Windows environment,
the manner in which certain UNIX-environment–specific features are handled in Windows,
and how the performance of the application in the Windows environment will change. It
tmg.edu.au | 1300 888 TMG (1300 888 864)
may even involve the porting of a small portion of the application to confirm the migration
methodology. If possible, steps should be taken to create a reusable prototype, which can
be used again in the actual migration phase.
The following are examples of proof of concepts:
 Porting of a small portion of the communications library in the UNIX application to

Windows in order to establish the communication model between the migrated
Windows client and server.
 Porting of a text-based library of the UNIX application, which uses GLX (OpenGL
Extensions) for character rendering to Windows and uses WGL (Wiggle) to compare
the rendering speed of characters.
Baselining the Environment
The team must also conduct an audit of the as-is production environment in which the
solution is now operating. Information is collected on server configurations, network, desktop
software, and all relevant hardware. This baseline allows for the team to account for any
changes that might be required or design issues that might cause the solution to be at risk.
This baselining step is critical to the success of a migration project.
Interim Milestone: Technology Validation Complete
At this point, the team has confirmed the technologies to be used and should be well versed
with the technical issues in order to move forward with creating the functional specification.
The team also validates the technology, considering the implementation of the features from
the business perspective. When you reach this milestone, you are ready to create the
functional specification for the solution.
Creating the Functional Specification for the Solution
The functional specification document is a technical description of the solution and

represents the contract between the customer and the project team. It is the basis for
building project plans and schedules for the migration project. The program manager takes
the lead in creating the functional specifications, with input from the role leads regarding
their areas of responsibility. During the Planning Phase, the functional specification document
is baselined and, after a formal review from the project manager, is taken as the final
document. Otherwise, a change document is prepared for the functional specification.
The Solution Feature Set
A basic functional specification document must include the following:
 A summary of the vision/scope document as agreed upon and refined, including

background information to place the solution in a business context.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Any additional user and customer requirements beyond those already identified in
the vision/scope document.
 The solution design (including conceptual, logical, and physical designs).
 Specifications of the components that will be a part of the solution.
Interim Milestone: Functional Specification Baselined
The functional specification is maintained as a detailed description of the various solution

components and how the solution will look and operate. The team baselines this functional
specification and formally tracks the changes based on the customer’s approval of the
changes. The functional specification is the basis for building the master project plan and
schedule. When you reach this milestone, you are ready to develop plans to execute the
project.
Developing the Project Plans
During the Planning Phase, you must map the requirements to the conceptual, logical, and
physical designs, as well as plan for the future phases of the project. Plans need to be
developed for developing or migrating, stabilizing, deploying, and operating the system, and
also for other aspects of the project such as the budget, team communication, facilities, and
purchasing. Depending on the size and complexity of the project, the number of plans can
vary. The essential plans that are a part of the master project plan are discussed in this
section. The program manager is responsible for creating the master project plan
components in consultation with various teams. The master project plan consolidates the
feature team and role plans and guides the project to completion, as defined by the
functional specification. It is a key Planning Phase deliverable.
The benefit of having a plan that breaks into smaller plans is that it:
 Facilitates concurrent planning by various team roles.

 Keeps accountability clear because specific roles are responsible for various plans.
The benefit of presenting these plans as one Master Project Plan is that it:
 Facilitates synchronization into a single schedule.

 Facilitates reviews and approvals.
 Helps identify gaps and inconsistencies.
The following table lists the various essential plans that are part of a master project plan,
describes the purpose of each plan, and names who is responsible for creating the
corresponding plan.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 3.2. Preparing the Master Project Plan
Name of Plan Purpose of Plan Responsibility

Budget and To establish the estimated cost of migration Program
Purchasing Plan and determine what resources and Management team
infrastructure requirements will be required
for the migration.
Solution To validate the feasibility of the migration Development team
Development Plan strategy and identify requirements for
environment readiness.
Solution Testing To ensure the quality of the migrated Test team
Plan solution, test plan, and test methodology.
Pilot Deployment To ensure smooth deployment at Release Management
Plan production. team
Production To specify the deployment instructions on Release Management
Deployment Plan the production computer configuration. team
User Operations To ensure that the UNIX users are Release Management
Training Plan comfortable with the migrated Windows team
applications.
Security Plan To make the migrated application as Development team
secure as it was on UNIX. and Release
Management team
Communications To define the communication strategy with Product Management
Plan the customer. team
Budget and Purchasing Plan
Adequate financing is crucial for a project to survive, and therefore a budget plan is
important. You may get into a situation where you need resources that your project budget
cannot accommodate. The needs and demands of all the phases of the project must be
taken into account when planning the budget.
The budget plan must include the following information:
 Software costs, including those of the operating system, development tools, and
management tools.
 Hardware costs, including those of computers, power supplies, racks, and cables.
 Personnel costs, including those for executing the migration and maintaining the
system post-migration.
 Cost of training resources, including those associated with developers, administrators,
and end users.
 Cost of vendor support for software, hardware, and network.
 Miscellaneous costs, such as those for travel and shipping.
The purchasing plan includes (but is not limited to) the following information:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Equipment required for the setup, such as racks, power points, and uninterruptible
power supply (UPS).
 Test setup resources.
 Systems required for the setup.
Solution Development Plan
The development plan describes the solution development process for the project, in
addition to the tasks to create and assemble the components of the solution. A
development plan for a UNIX-to-Windows migration project should include (but not be
limited to) the following information:
 How to set up an Interix or Win32/Win64 or .NET development environment for the

migration.
 How to set up the test environment to migrate the application code.
 The different components of the application and an indication of the components
that will be migrated and the ones that will be replaced.
 After the various scripts, modules, and tools of the UNIX system have been successfully
migrated to Windows, they need to be integrated into the Windows environment.
They must work together with other dependent applications. This development must
precede the development of the application. Integration activities must be added to
the existing development plan.
 A list of the porting methodologies that can be used for the application. (Porting
methodologies are discussed in detail in the build volumes [Volumes 2, 3, and 4] of
the guide.)
 Configuration management is the process used to control, coordinate, and track
code, requirements, documentation, issues, change requests, tools, changes
affected, and the people making the changes. Configuration management activities
must be added to the existing development plan.
Solution Testing Plan
The testing team tests the migrated application. Testing can begin before the entire
development is complete. It must include tests for security, scalability, and performance of
the application, along with the functionality tests of the migrated application.
A testing plan describes the strategy and approach that is used to plan, organize, and
manage the testing activities in a project. It identifies the testing objectives, methodologies,
tools, expected results, responsibilities, and resource requirements. The Test Role is responsible
for creating the test plan. The test plan must include (but is not limited to) the following
information:
 Manual procedures or script to test if the setup works.

 Testing procedures (testing methodology).
 Test cases to test the functionality of the application.
 Test cases to test the interaction with other applications.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Expected results compared with the existing UNIX application functionality.

 Assumptions made prior to testing.
 Bug reporting and tracking mechanisms.
 Plans to improve the performance of the application and the application
infrastructure.
Pilot Deployment Plan
The pilot deployment plan addresses the initial deployment of the solution into the
production environment. The pilot deployment plan includes (but is not limited to) the
following information:
 Pilot participant profiles and their selection process.

 The number of pilot builds and the number of participants in them.
 The procedure for the pilot deployment.
 Backup and recovery mechanisms in case of deployment failures.
 Mechanisms to gather feedback on the pilot application.
Production Deployment Plan
The production deployment plan addresses the deployment of the migrated application
based on various scenarios that you have encountered and the best practices that you
have drawn up for deploying the pilot application. The production deployment plan must
include (but is not limited to) the following information:
 Details of the deployment process for the operating system.

 The modules of the migrated application to be deployed.
 The tools to be used for the deployment of the migrated application and other
software.
 The deployment procedure.
 Backup and recovery mechanisms in case of deployment failures.
User and Operations Training Plan
The user and operations training plan focuses on the process that the users and their
operations should follow to make a successful transition from the UNIX environment to the
new Windows environment. It includes details on the process that the Release Management
Role should follow to coordinate with the current operations team to ensure a smooth
migration and rollover. The user and operations training plan includes (but is not limited to)
the following information:
 Details of the training needs of the existing users, which will enable them to work on
the migrated application and the Windows environment.
 Details on making software and hardware inventories.
 Details on network administration and security administration in the new environment.
 Backup procedure details for the new system.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Details on monitoring the new system's performance on a daily basis.
Security Plan
Security is often overlooked during the Planning Phase. The importance of security is only
realized when you begin working on the system. A security plan includes (but is not limited to)
the following information:
 Details of various roles and users who may access the application.
 Types of access rights given to various user groups.
 Response measures for a possible security breach.
 Physical security plans.
 Details on how users can access the setup location.
 Details on the roles that can access the application for infrastructure maintenance.
Communications Plan
Communication between various roles and with the customer is very important for the
success of a project. Most delays and wrong executions are usually due to a communication
gap. A communications plan should contain (but is not limited to) the following information:
 Procedures for escalating issues.

 Procedures for managing status updates.
 Types of issues and the roles that will handle communication regarding the issues.
A service level agreement (SLA) can be drawn up at the start of the project. This lists the
communication channels and the levels of escalation for each.
Interim Milestone: Master Project Plan Baselined
At this point, the team has rolled up all initial drafts of the plans required to create estimates
for the time required to fulfill these project plans.
Creating the Project Schedules
The UNIX Migration Project Guide (UMPG), a companion to this guide, contains most of the
information that you will need to develop a schedule for your migration project. Some
important points to consider while creating the project schedules are as follows:
 The individual schedules must fit into the overall migration project schedule.
 When drawing up project schedules, it is best to define the milestones early in order to
establish the proof of concept. In a UNIX-to-Windows migration project, the proof of
concept provides valuable inputs for overall project estimations by giving a realistic
picture of the expertise and the time required to complete the application by
extrapolating on the proof-of-concept time and the overall cost of the project.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 You may want to treat the application infrastructure migration separately from
application migration. If you do, you may have parallel milestones. In a UNIX-to-
Windows migration project, the effort required to procure the hardware and software
is often underestimated. Effort estimations are often based solely on the size of the
application, which results in an inaccurate estimate. A project schedule must
therefore include the hardware and software procurement time, the time required for
the initial setup of the infrastructure, and the time needed to establish the proof of
concept.
 The project schedule must be drawn up by the Program Management Role in
consultation with representatives of all the roles because this will provide estimates for
all areas of the project.
Interim Milestone: Master Project Schedule Baselined
At this point, the goal for the schedule should be set. It creates awareness about the
project’s priorities and contributes to a sense of ownership by all the project’s contributors.
Interim Milestones
This chapter discussed the major tasks of the Planning Phase (with the exception of setting up
the development and test environments and closing the Planning Phase). The key interim
milestones that accompany the activities performed in this chapter are:
 Technology Validation Complete

 Functional Specification Baselined
 Master Project Plan Baselined
 Master Project Schedule Baselined
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 10
Why would you take the time to develop a project plan?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Obtain sign-off for the security design from the appropriate person
One of the hardest parts of our job as designers is getting the client to approve the design.
Nothing is more demoralising than if you have worked on a design for days only to have it
rejected when you finally show it to the client.
Then there are the clients who want to see two or three designs. You end up doing three
times the work only to have them ask if they can combine parts of each design. The site ends
up looking like Frankensteins Monster.
In short dealing with clients is a nightmare when it comes to design. But it doesn’t need to be
that way.
The problem is that we tend to work on our designs in isolation. We fail to include the client in
the process.
How to Get Design Sign-off Through Collaboration
We need to escape the world of sign off nightmares, endless iterations and many initial
designs. We need to create the design with the client.
Unfortunately too often we take a brief from the client and then go away. We produce the
design in isolation before doing a big reveal. This is the worst way we could work.
First, a big reveal will always come as a shock. The design will not look the way they expect
and people rarely respond well to a surprise.
Second, the client has no sense of ownership over the design you have produced. If they
don’t feel like they contributed to the design they have no problem rejecting it.
The more you involve the client in creating a design, the greater the sense of ownership they
have over that design. This means they are less likely to reject it because we don’t tend to
reject something we slaved over.
Better still, they will feel invested in the design. This means they will defend it against other
stakeholders in the organisation. The design is then less likely to get derailed by a boss,
colleague or relation who “doesn’t like the color.”
Finally, they will get to see and influence the design as it evolves. This means that there will be
no big reveal and no shock. But, it also does away with the need to provide more than one
design concept. Clients ask for more than one concept because they want a choice. They
want to be involved in the process. If we do involve them at every step, they don’t need to
choose between concepts.
But the benefits of collaborative design does not stop at getting design sign off.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Other Benefits of Collaboration
I acknowledge that designing with a client can sound scary and does carry with it some risks.
But, the benefits far outweigh the drawbacks. As well as helping secure design sign off it also:
Ensures the client is happy over the long term
When we do not collaborate with our clients to produce a design we often have to
convince them to sign it off. Once they do we maybe happy, but the chances are they are
not. At least not for the long term. They have to live with the website long after we are gone.
By working alongside the client on the design, there is a good chance the client will be
happy with the final result. What is more they will understand why the design is the way it is
and that will ensure they remain happy for the long term.
You are educating the client through the process
Because we engage the client with the process they are learning about web design best
practice. This not only means they understand the design, it also equips them to run, maintain
and improve their website.
Improves the design quality
Finally working hand in hand with clients on a design improves the quality of the design. It is
easy as web designers to fall into patterns of design. In the end our designs all start to look
similar. This is particularly true if we do a lot of work in one sector. Before long we end up
producing cookie cutter design.
Having the client involved in the process avoids this. They bring a perspective that keeps our
designs fresh. They also ensure that the design reflects the nature of the organisation rather
than our own in-house style. It ensures the design reflects the clients personality and not ours.
Collaboration Done Right
The benefits of design collaboration are obvious. But, the question now becomes how to
collaborate successfully.
You need to find the way that works best for you. But I want to end with a few tips that have
helped me over the years:
Sit with the client
Design collaboration is possible over a distance, but it will make life much easier if you can
go and work in the clients office for a few days. It’s not that the client needs to be watching
you work the whole time. But being able to lean over and ask their opinion about something
is invaluable.
tmg.edu.au | 1300 888 TMG (1300 888 864)
If co-location is not possible, make sure your client is available on Skype while you are
working. That way you can show them stuff as you go.
Work on content together
We tell ourselves that content is the clients problem. In reality it is the building block of good
design.
Arrange a meeting to discuss the content with the client. Start from the users perspective by
discussing what the user wants to know. Then design an information architecture and visual
hierarchy around that. Together you can identify what content the client needs to write.
By ‘helping’ the client with content you guide them in the right direction. You also ensure the
design accommodates the content they write.
Give the client a role
Remember that the client is not experienced in working on a website. Even if they are they
have never worked with you and your processes. That means you need to give them
guidance about their role.
I tend to give my clients three roles:
 Focus on the user. It is always good to keep the client thinking about what the user
needs.
 Focus on the business. It is the clients job to ensure any design meets business
objectives.
 Focus on the problem. The clients job is to identify problems and mine to suggest
solutions. In other words they shouldn’t say “change the color to green”. Their job is to
identify the color might be a problem.
Value the clients opinion
Not that clients cannot have good ideas for potential solutions. Anybody is able to come up
with a good design idea. Unfortunately our pride often prevents us accepting that. The client
has a lot to add to the design process.
Of course there will be occasions when you and the client disagree. When this happens
don’t allow it to become a point of conflict. Instead test both approaches with a tool like
Verify, rather than arguing.
tmg.edu.au | 1300 888 TMG (1300 888 864)
A Better Way of Working
You may feel that all this collaboration sounds like a lot of work that your client will not pay
for. I won’t deny it does take longer, but it is better than the alternative.
It works out cheaper than multiple designs, arguments with the client and endless iterations.
You might hit on the right idea first time if you work by yourself. But its a gamble. Working with
the client is much more predictable. That means you can cost more realistically, win more
work and make a greater profit.
Every designer has worked on a project that has had moments of frustration. Some
frustrations are common and have become part of design lore. The client who changes the
direction of the project late in the game; the client who can’t leave the content alone and
makes multiple revisions right up to the deadline; the new stakeholder who’s brought in late
in the game and changes the direction at the last minute. For designers, these are more than
just bumps in the road. They represent wasted time, money and effort. Common frustrations
include:
• Running off in the wrong direction

• Rework/constant updates
• Changing direction midstream
• A new stakeholder signing onto the project late
• Clients playing designer
These frustrations are not only irritating, but in some cases they are the difference between
doing average work and doing great work. Although frustrations like these cannot be
eliminated, they can be managed. Identifying potential areas of frustration and prioritizing
the ones that are the most costly and have the highest probability of happening can help
designers focus on what needs to be addressed first.
Design by its nature is a risky endeavor. Designers make things and express complicated
ideas in ways that have never been seen before. So how do designers manage risk while
developing new and exciting works?
Design process uses several controls in the project so that designer and client can check
their alignment. Design briefs are created at the beginning of the process and act as a
scope-of-work document, including basic project specifications, information about voice
and tone, and positioning. Along with the brief, sign-offs placed at critical junctures help
preserve alignment and minimize frustration. Along with these tools, there are methods of
working that promote alignment from stakeholders.
Design process offers several tools for managing project frustrations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Design Brief
By developing the brief with the client’s help, the designer creates a guide for how to
proceed that can be shared with all stakeholders. As an alignment tool, the brief documents
direction—taking some of the subjectivity out of the design process.
The design brief is a very important control tool. By outlining the direction with stakeholders
and documenting it, designers create accountability for all involved in the project. By having
the brief in writing and accessible to all, clients are less likely to make costly and time-
consuming changes later in the design process.
The Sign-Off
Along with the design brief, sign-offs at specific times during the process help check progress
so that designer and client are in sync on status before committing time and effort toward a
particular direction. Sign-offs are usually done before and after the concept phases, so
designers can confirm a general direction before executing the concept.
“I have the client sign off on the project brief before I get started with the design process,”
says Jose Nieto, principal and creative director of the design firm square zero. “That allows us
to deal with any misconceptions that I might have with the project from the beginning. So if
there’s any problem in what I interpreted, it’s dealt with before the project starts.”
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 11
Outline the consequences of not obtaining sign-off for the security design from the
appropriate person.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Prepare for work in line with site-specific safety requirements and enterprise occupational
health and safety (OHS) processes and procedures
Creating a safe work environment is critical to the success of your business, and is one of the
best ways to retain staff and maximise productivity. Though it may cost to implement safe
practices and install safety equipment, the effect of not taking action can be severe.
As a business owner you have responsibilities regarding health and safety in your workplace.
You need to ensure that your business doesn't create health and safety problems for your
employees, customers or the public.
Knowing and understanding the WHS laws, previously known as Occupational Health and
Safety (OH&S), will help you avoid unnecessary costs and damage to your business caused
by workplace injury and illness. It will also provide your business with a strong foundation to
achieve long-term success.
If you want to reduce health and safety hazards in your workplace but don't know where to
begin, there are simple steps that will allow you to concentrate your efforts as well as help
your business to be prepared in all situations.
Having the right attitude towards the safety of your workers, contractors, customers and the
public is an important first step. WHS shouldn't be seen as an additional cost - it's better to
deal with health and safety issues before they escalate.
If you're looking for assistance with WHS/OH&S requirements specific to your industry, You can
utilise state or territory WHS agencies for advice and kits on how to incorporate safety
management into your business operations.
Your WHS obligations
Under WHS legislation you are obliged to provide:
 safe premises
 safe machinery and materials
 safe systems of work
 information, instruction, training and supervision
 a suitable working environment and facilities
 insurance and workers compensation for your employees.
Complying with these duties can prevent you from being prosecuted and fined, and help
you to retain skilled staff.
WHS authorities in each state and territory and Safe Work Australia have responsibilities for
enforcing the WHS legislation. They provide education, training and advice on health and
safety at work. You can get information about your workplace health and safety obligations
and other valuable WHS/OH&S resources both in hard copy and online from their websites.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Please note that legal obligations of employers vary according to circumstances. You may
wish to seek independent legal advice on what is applicable to your situation.
Workplace Health and Safety
An important employee relations area, Workplace Health and Safety covers legislation
relating to an employee's safety in the workplace. Beyond legislation this topic also includes
the need for organisations to consider an employee's overall wellbeing and how an
organisation can develop health and wellbeing programs to improve their employment
brand.
Importance of WHS law
The purpose and objective of work health and safety (WHS) law in Australia is to provide a
legislative framework for employers and business operators to take steps to ensure the safety
of people they employ and others affected by their business or undertaking.
Harmonisation of WHS laws
Prior to 1 January 2012, each State and Territory in Australia had its own unique set of
legislation for dealing with workplace health and safety issues. The purpose of the WHS Act
was to impose uniform health and safety obligations on businesses and individuals across
Australia and reduce the burden of having to comply with different obligations across
different States and Territories.
Current WHS legal framework
Currently, the Commonwealth and all States and Territories, except for Western Australia and
Victoria, have adopted the model WHS Act.
Jurisdiction WHS/OHS Regulator

legislation
Commonwealth Work Health and Comcare [http://www.comcare.gov.au/]
Safety Act 2011
New South Wales Work Health and WorkCover NSW
Safety Act 2011 [http://www.workcover.nsw.gov.au/]
Queensland Work Health and Queensland Work Health and Safety
Safety Act 2011
South Australia Work Health and SafeWork SA [http://www.safework.sa.gov.au/]
Safety Act 2012
Tasmania Work Health and Workplace Standards Tasmania
Safety Act 2012
Australian Work Health and WorkSafe ACT
Capital Territory Safety Act 2011 [http://www.worksafe.act.gov.au/health_safety]
tmg.edu.au | 1300 888 TMG (1300 888 864)
Northern Territory Work Health and NT WorkSafe

Safety Act 2011 [http://www.worksafe.nt.gov.au/home.aspx]
Victoria Occupational WorkSafe Victoria
Health and Safety
Act 2004
Western Australia Occupational WorkSafe WA
Safety and Health [http://www.commerce.wa.gov.au/worksafe]
Act 1984
Model WHS Regulations and Codes of Practice
While the WHS Act sets out the overriding duties and obligations, the WHS Regulations
provide the substantive elements that must be adhered to in order to comply with those WHS
Act duties and obligations. It also covers specific types of work such as hazardous work,
construction work, hazardous chemicals etc.
The model Codes of Practice, which have been developed by Safe Work Australia, are user
friendly guides to assist PCBUs in carrying out work safely. These Codes set out methods of
best practice to ensure that work is carried out in a safe manner. While the Codes are not
legally enforceable, regulators and the courts will rely on them to determine whether PCBUs
have done everything reasonably practicable to ensure the health and safety of workers
and others.
For more information on the model Codes of Practice, please visit the Safe Work Australia
website.
Costs of getting it wrong
Apart from the obvious injuries/death, penalties and compensation associated with
workplace incidents, there are significant indirect costs when WHS systems fail. Poor safety
performance can have a large impact on a business' operation and performance, often as
a result of reduced productivity and low morale.
Posture-related injuries from computer use

Back and neck pain, headaches, and shoulder and arm pain are common computer-
related injuries. Such muscle and joint problems can be caused or made worse by poor
workstation (desk) design, bad posture and sitting for long periods of time.
Although sitting requires less muscular effort than standing, it still causes physical fatigue
(tiredness) and you need to hold parts of your body steady for long periods of time. This
reduces circulation of blood to your muscles, bones, tendons and ligaments, sometimes
leading to stiffness and pain. If a workstation is not set up properly, these steady positions can
put even greater stress on your muscles and joints.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Setting up your work area
This is a visual exercise using a graphic of an office worker sitting at her workstation. You
are invited to adjust the workstation to meet occupational safety and health requirements.
 The height of the seat is raised or lowered – the forearms should be parallel to the
desktop and the legs should fit comfortably underneath. (Shorter people may need
to use a footrest.)
 The height of the backrest is raised or lowered – the small of the back should be
supported.
 The tilt of the seat is adjusted – the thighs should be parallel to the desktop, knees at
approximately right angles with feet flat on floor or on a footstool.
 The height of the computer monitor on the desk is raised or lowered – the centre of
the screen should be near shoulder height.
 The distance of the monitor from the eyes is adjusted – it should be about arm's
length from the face.
 The tilt of the computer screen is adjusted – it should be set so the bottom of the
screen can be read without having to bend your head down (optimum viewing
angle is 38° below the horizontal).
Preventing computer-related muscle and joint injuries
Tips to avoid muscle and joint problems include:
 Sit at an adjustable desk specially designed for use with computers.

 Have the computer monitor (screen) either at eye level or slightly lower.
 Have your keyboard at a height that lets your elbows rest comfortably at your sides.
Your forearms should be roughly parallel with the floor and level with the keyboard.
 Adjust your chair so that your feet rest flat on the floor, or use a footstool.
 Use an ergonomic chair, specially designed to help your spine hold its natural curve
while sitting.
 Use an ergonomic keyboard so that your hands and wrists are in a more natural
position.
 Take frequent short breaks and go for a walk, or do stretching exercises at your desk.
Stand often.
Computer-related overuse injuries of the hand or arm

Muscles and tendons can become painful with repetitive movements and awkward
postures. This is known as ‘overuse injury’ and typically occurs in the elbow, wrist or hand of
computer users. Symptoms of these overuse injuries include pain, swelling, stiffness of the
joints, weakness and numbness.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Preventing computer-related overuse injuries
Tips to avoid overuse injuries of the hand or arm include:
 Have your mouse at the same height as your correctly positioned keyboard.
 Position the mouse as close as possible to the side of the keyboard.
 Use your whole arm, not just your wrist, when using the mouse.
 Type lightly and gently.
 Mix your tasks to avoid long, uninterrupted stretches of using the computer.
 Remove your hands from the keyboard when not actively typing, to let your arms relax.
Eyestrain from computer use

Focusing your eyes at the same distance point for long periods of time causes fatigue. The
human eye structurally prefers to look at objects more than six metres away, so any work
performed close up puts extra demands on your eye muscles.
The illuminated computer screen can also cause eye fatigue. Although there is no evidence
that eye fatigue damages your eyesight, computer users may get symptoms such as blurred
vision, temporary inability to focus on faraway objects and headaches.
Preventing eyestrain from computer use
Tips to avoid eyestrain include:
 Make sure your main source of light (such as a window) is not shining into your face or
directly onto the computer screen.
 Tilt the screen slightly to avoid reflections or glare.
 Make sure the screen is not too close to your face.
 Put the screen either at eye level or slightly lower.
 Reduce the contrast and brightness of your screen by adjusting the controls.
 Frequently look away from the screen and focus on faraway objects.
 Have regular eye examinations to check that any blurring, headaches and other
associated problems are not caused by any underlying disorders.
Injuries from laptop computers

The growing use of laptop computers has caused more pains, strains and injuries among
computer users.
Laptop computers were designed to be used for short periods of time when a person
couldn’t access a desktop computer. But these days many people use a laptop all the time.
The problem is that the monitor and keyboard of a laptop are very close together. To
position the monitor at the right height for your back and neck causes you to lift your arms
tmg.edu.au | 1300 888 TMG (1300 888 864)
and shoulders too high. But to position the keyboard at the best height for your arms and
shoulders, you must hunch your shoulders and neck to see the monitor.
Carrying your laptop around can also strain your muscles and joints.
Preventing injury from laptop computers
Tips to reduce laptop dangers include:
 Use a correctly set-up desktop computer instead of a laptop as often as you can.
 Use peripheral equipment, such as a docking station, separate keyboard, mouse and
laptop stand.
 Take frequent breaks.
 Carry your laptop in a backpack or in wheel-along luggage.
Sample Safe Work Method Statement
tmg.edu.au | 1300 888 TMG (1300 888 864)
tmg.edu.au | 1300 888 TMG (1300 888 864)
Customer cabling rules and requirements
The ACMA is responsible for regulating and monitoring telecommunications cabling in

Australia.
The Telecommunications Cabling Provider Rules 2014 (CPRs)

[http://www.comlaw.gov.au/Series/F2014L01684] regulate the cabling industry and replaced
the previous cabler licensing system with an industry-managed registration scheme.
CPRs ensure that minimum cabling requirements are in place to promote safety and
maintain network integrity.
The major requirements of CPRs are that:
 All customer cabling work in the telecommunications, fire, security and data industries
must be performed by a registered cabler.
 Depending on the cabling work performed, cablers must obtain either an Open,
Restricted or Lift registration that meets the ACMA's training competency
requirements.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Cabling work must comply with the industry standard AS/CA S009:2013 Installation
requirements for customer cabling (wiring rules). The wiring rules detail the minimum
requirements for cabling installations to ensure that network integrity and the health
and safety of end-users, other cablers and carrier personnel is protected.
 A key requirement of the Wiring Rules is that telecommunications cabling is
adequately separated or segregated from electrical cabling to avoid the potentially
hazardous situation where simultaneous penetration from nails, screws, drills, saws and
other sharp objects may cause harmful electrical current to appear on the
telecommunications cable .
 Cablers are required to install only cabling product (including cable) and customer
equipment that complies with the requirements of the Telecommunications (Labelling
Notice for Customer Equipment and Customer Cabling) Instrument 2015 (the TLN).
 Cablers must, at the completion of each cabling task, provide the client with a job
sign-off form such as a Telecommunications cabling advice form - TCA1 form.
 Registered cablers must directly supervise an unqualified cabler's cabling work. This is
known as the supervision rule.
 Under the supervision rule, a registered cabler must accept full responsibility for the
work done by an unqualified cabler and ensure that it fully complies with the wiring
rules including signing the TCA1 form.
 Cablers must provide all reasonable cooperation and assistance to ACMA inspectors
and cabling auditors. Cablers can be subject to fines if they do not abide by their
registration conditions.
 Cablers are required to notify their registrar of any change of contact details within 21
days.
WORK SYSTEMS: ORGANISATION AND DESIGN

The aim of effective work systems design is to satisfy both technological and organisational
requirements as well as the individual's social and personal needs.
When work systems are being designed or redesigned, consider the following factors:
· Variety: people should be able to vary the tasks they do, work at different speeds and
move about while carrying out their jobs. Repetitive short cycle tasks should be avoided.
· Autonomy: people should be involved in decisions related to their work such as the method
of work and the order in which tasks are carried out, particularly when changes are planned.
Employees should be given responsibility for the completion of some tasks.
· Identity: tasks should fit together to make a complete job, as when a typist types a
complete document, from first draft to final stage.
· Feedback: effective feedback links will allow valuable information to be passed to and
from workers.
· Social contact: most, but not all, people desire to have contact with other people as part
of their job. On the other hand, they also like to be able to choose to have some privacy.
· Achievement: people like to be able to go home at the end of the day feeling they have
done a useful job and have achieved something.
· Opportunities for learning and development: although this might seem an unobtainable aim
in every job, it is usually possible to provide training and development away from the
worksite.
tmg.edu.au | 1300 888 TMG (1300 888 864)
· Job Demand: too much work or too little work can lead to strain. In practice, it may be
difficult to achieve the necessary balance, as the appropriate levels vary from person to
person.
Three of these factors are particularly relevant to the design of work systems from a health
and safety viewpoint: job demand, autonomy and social contact. Excessive job demands
and lack of autonomy have been specifically linked with occupational overuse syndrome.
Approaches to Job Design

Job enrichment (increasing elements of decision making, responsibility and autonomy) and
job enlargement (varying the job with additional, alternative tasks) are means of improving
job design.
In keyboard employment, where additional or alternative tasks are giving to staff, care
should be taken to ensure that these tasks are non-repetitive.
An example of the application of job enrichment and job enlargement in keyboard

employment is the reorganisation and restructuring of keyboard jobs in a typing pool. In a
conventional typing pool there is little scope for keyboard users in terms of autonomy,
decision-making responsibility and planning. Typically, the jobs are repetitive and keyboard
users have little or no contact with the authors of the documents they are required to key.
One option for job design would be to disband the typing pool and assign keyboard users to
particular groups of authors. Jobs can then be enlarged, with additional clerical tasks such
as editing, proof-reading or filing, and enriched with additional responsibilities such as liaising
with authors on matters including the content of material to be keyed, deadlines and work
priorities.
With this change, the workloads and work practices of individual workers will need to be
carefully monitored and managed by the supervisor.
If jobs are redesigned in this way, keyboard users will then:

· have increased decision-making responsibility;
· be required to learn and apply a number of skills;
· have more scope to plan and organise their work;
· have more opportunity to develop feedback links with both their supervisors and authors;
· feel that their major task (keying) is more significant as they will be able to both appreciate
and influence how that task fits into a range of other tasks in the organisation.
Redesign of work systems will also have implications for training of both managers and
employees. Consideration of the work system is likely to lead to additional changes in
organisations and technology which may have implications for the prevention strategy.
Organisational and Technological Change

A comprehensive and consultative approach to technological change is the best way to
maximise the positive outcomes and minimise any adverse consequences. Without
consultation changes could meet opposition, reducing the anticipated gains in efficiency.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Careful planning is an essential aspect of the effective management of technological

change. The following stages may be followed.
Pre-implementation Stage
This stage can include a number of steps such as management discussions, equipment trials,
feasibility studies and calling for tenders.
Consultation with keyboard users and their supervisors is important, to raise awareness of the
proposed changes, to identify and highlight current problems and to incorporate their
suggestions.
Implementation Stage
During the changeover period, managers need to ensure that:
· production targets and demands on staff are carefully balanced;
· staff are provided with training in the use of the new system and to enhance their career
prospects.
Post-implementation Stage
The operation and impact of the technological change should be monitored and reviewed.
Although these stages may be distinct processes within a large organisation, they would
usually proceed quickly and may not appear as distinct steps in a smaller organisation.
Aspects of Computer Systems Design

Human-computer interactions can contribute to the risk of occupational overuse syndrome.
When a computerised system is used, consideration should be given to the potential effects
of:
· system breakdowns;
· response times;
· software facilities;
· system messages;
· user assistance.
System Breakdowns
System breakdowns can increase operator stress and create uneven workloads. Increases in
work rate, to compensate for the time lost during a breakdown, can increase the risk of
occupational overuse syndrome.
Problems connected with breakdowns are probably greatest while a system is new, and it is
important to be prepared for these difficulties. The consequences of stoppages can be
reduced by production planning, job organisation, personnel planning and reserve
capacities.
Response Times
Poor software design or a high load on the computer system can prolong response times. The
`silence' can cause uncertainty as to whether the system has broken down, interrupt work
rhythm and increase operator stress.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The response time should be short and consistent, especially during peak work times. If the
response time does vary significantly, the user should be informed of the reason and
expected time of return to normal operations.
Software Facilities
Software should be flexible and ùser friendly'. It should specify the required skill of the user, or
be adaptable to the variable capabilities of users.
System Messages
Messages should be brief and constructive, giving guidance for using the system in a
courteous way. All messages should be explained in the user manuals.
The system and data should be protected from user errors. Error messages should be simple,
informing the user of the nature of the error and the remedy as soon as the error occurs. They
should be consistent and appear in the same position on the screen.
User Assistance
User assistance or support can be provided by:
· formal training in the operation of the system;
· software assistance, such as `HELP' functions;
· documentation, such as easy to understand user manuals;
· secondary support from supervisory staff or management, when the system or the manual is
unable to provide the assistance required.
Supervision
As supervisors provide the main link between employees and managers, one of their prime
functions is to ensure that production is maintained without compromising the health and
safety of employees.
The fulfil this role, supervisors need:

· management support;
· a clearly defined position of authority and responsibility;
· training in relevant aspects of occupational health and safety;
· training in supervisory skills. (See `Training and Education', later in this Guidance Note)
When supervisors are aware of the work practices and the concerns of employees, they may
be in a position to anticipate problems which, if corrected, will reduce the occurrence of
injury. In this way, supervisors can take a preventive approach to occupational overuse
syndrome.
Work Practices
Work practices which need to be considered include:
· work rates;
· work adjustment periods;
· deadlines, peak demands and overtime;
· work pauses/task variation.
tmg.edu.au | 1300 888 TMG (1300 888 864)
General principles on these work practices are provided in this section.
Work Rates
The rate at which keyboard work can be performed will vary depending on the type of work,
type of equipment, system efficiency, the capacities and experience of the individual worker
and the total job demands.
The target work rates and the allocation of work should be determined in consultation, taking
these factors into account.
Work Adjustment Periods

Employees newly engaged in keyboard work, or returning from an absence of two weeks or
more, need a period of adjustment.
The adjustment period will depend on the individual, the equipment, the environment, and
the
duration of the keyboard and VDU work involved.
The adjustment may be achieved through reduced work rates, or provision of alternative
duties with gradual re-introduction to keyboard work.
Deadlines, Peak Demands and Overtime

Meeting unreasonable deadlines and peak demands will increase time pressures, reduce
control over workflow and may contribute to increased risk of occupational overuse
syndrome.
Methods of reducing the affects of peak demands include:
· long-term planning of resources:
· organisation of tasks;
· use of extra staff;
· ensuring authors and supervisors are aware of the problem and the opportunities they have
to reduce peak demands;
· giving individuals greater control over their workload and workplace.
Overtime is not recommended because extending the hours of daily keyboard operation
increases the risk of occupational overuse syndrome.
Work Pauses/Task Variation

It is desirable for keyboard users to spend part of the working day on alternative duties away
from the screen and keyboard. Alternative activities should not be visually exacting or of a
static sitting nature. As an example, word processor operators could move away from the
keyboard to collect new material, discuss details with authors and collect finished items from
the printer on a regular basis.
If there are no suitable alternative work activities, work pauses must be provided. As noted
previously, both physical and psychological factors may be important in the development of
occupational overuse syndrome. A number of these factors will influence the need for work
pauses:
tmg.edu.au | 1300 888 TMG (1300 888 864)
· the duration and intensity of VDU and keyboard use;

· the maintenance of constrained postures;
· the visual demands;
· psychosocial stressors, including customer liaison, and other sustained mental effort.
The length and frequency of work pauses will depend on the individual, the task and other
factors.
Frequent short pauses are preferable to infrequent longer pauses.
The need for work pauses, and their frequency and duration, should be determined by
management in consultation.
Both management and employees need to be aware of the importance of regular work
pauses.
Supervisors should ensure that operators have appropriate breaks from keyboard work, and
that the alternative activities are suitable.
Ergonomic Factors in Work Design

Where a user's work involves a mix of activities that form a satisfying job, the consequences
of minor inadequacies in the ergonomics of the equipment or work place are minimised. On
the other hand, when the pace of work is determined by the system, when use is prolonged
and intense and when the individual is not motivated or involved in the work process, the
ergonomics of the equipment and workplace become critical.
One way of increasing the motivation and involvement of the users is to involve them in the
work design process. This ensures both a better system design, and that the users have a
realistic view of the strengths and weaknesses of the system. An individual's response to the
equipment and the workplace often depends as much on psychological and organisational
issues as on the objective suitability of the equipment. For example, eyestrain can be as
much a symptom of poorly designed work as of poorly designed equipment.
WORKPLACES: ORGANISATION AND DESIGN

Introduction
The design of workplaces should be largely determined by the task requirements (task
analysis),
the human requirements (ergonomic analysis) and the environmental conditions.
A correctly designed workplace will increase user comfort, improve efficiency and minimise
the risk of occupational overuse syndrome.
The Standards Association of Australia have developed and produced a variety of
documents on the design of workstations, and reference will be made to specific standards
where relevant.
Equipment should be maintained and serviced regularly to ensure that it operates to
specifications.
A system for reporting faults is also recommended.
Task Analysis
Tasks analysis gathers information on:
· the task and sub-tasks that are performed;
· the frequency and duration of tasks;
tmg.edu.au | 1300 888 TMG (1300 888 864)
· the material, equipment and tools used.

A wide variety of tasks may be performed at any one workstation. For example, the tasks
involved in word processing include:
· keying in information;
· formatting the text;
· proofreading and editing;
· making changes to earlier drafts;
· operating a printer.
The equipment may include:

· the VDU and its associated components;
· the keyboard;
· disc-drive;
· printer;
· telephone and a modem.
Ergonomic Analysis
Ergonomics involves the consideration of human requirements, both psychological and
physical, in workplace design.
Equipment and furniture design and layout must allow for a large variation in the physical size
(for example, height and reach) of users.
Environmental Conditions
Environmental conditions can have a profound effect on individual well being and posture.
The best attempts to provide properly designed workstations may be ineffective if the work
environment is unsuitable, as keyboard users may adopt poor working positions or rearrange
their workstations in order to avoid such things as glare, reflections and draughts.
Environmental factors which require consideration include:

· atmospheric conditions;
· lighting
· noise;
· space.
Office Space
Sufficient space should be provided to allow safe and easy access to and from workstations.
The layout of furniture and equipment and allocation of space, needs to be considered
carefully to optimise:
· efficiency and comfort;
· privacy and security;
· communication and workflow;
· unconstrained work posture and body movement;
· flexibility and individual control;
· social interaction.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Work Posture
A good working posture increases efficiency and reduces fatigue and the risk of injury. It
comprises a natural and relaxed position, providing opportunity for movement from which
the worker can assume a number of alternative postures. It is not a single, rigidly defined
position.
Whichever option is chosen, keyboard working positions should follow these fundamental
principles:
· the feet must be firmly and comfortably supported, either on the floor or on a footrest;
· there must be ample room to move the legs;
· the thighs must be adequately supported, and the underside of the thighs should not be
compressed by the seat edges;
· the hips and knees should not be constrained in limited positions. Angles less than 90
degrees are generally not recommended;
· the natural curvatures of the spine should be maintained and excessive twisting and
bending of the spine should be avoided;
· shoulders should be comfortable and relaxed. Elevated or slumped posture should be
avoided;
· elbows should be close to the side of the body, and the elbow angle should be around 90
degrees;
· frequent or continuous bending of the wrist (upwards, downwards or sideways) should be
avoided.
Three options for providing seated working positions for keyboard users are:
· the conventional erect posture - where ankles, knees, hips and elbows are at right angles,
and thighs and forearms parallel to the floor;
· the tilt forward seatpan position - with the front edge of the seat tilted downwards,
increasing the angle between the seatpan and backrest. The effort needed to hold the trunk
erect is reduced, but, with prolonged use, the legs and/or knees become fatigued as they
are preventing the body from slipping forward;
· the leaning-back posture - this method also increases the hip angle, with a horizontal or
slightly tilted back seat, a reclined upper body and the entire back supported by a well-
shaped backrest. This posture partly restricts the mobility of the head and the arms.
Workstation Arrangement
The four main factors which determine posture are:
· chair design and seat height;
· work height and desk design;
· equipment design and layout;
· reach and vision requirements.
Chair Design and Seat Height

Well designed chairs will promote good posture, allow changes in posture and minimise
fatigue.
The seat height should relate to the size of the person and the height of the work surface.
When this work surface is adjustable it is easy to select an appropriate height. However,
tmg.edu.au | 1300 888 TMG (1300 888 864)
when the work surface is at a fixed height then the chair must be able to be raised
sufficiently to accommodate the smallest person and a variable height footrest provided.
Work Height and Desk Design

An adjustable height desk will promote good work postures for the majority of users and will
be suitable for a variety of tasks.
The appropriate height of the desk depends on:

· the space required for thigh clearance;
· the thickness of the desk top;
· task analysis, for example, writing versus touch typing;
· the equipment used, for example, the thickness of the keyboard.
The desk must be low enough to provide for comfortable working postures of the upper limb
and
back, without interfering with the space required for the thighs.
If a desk of fixed-height is used, the height should relate to the taller users and the
predominant task performed.
The desk top should have sufficient surface area for the work tasks and equipment, and
provide
space to rest the hands and forearms.
There should be sufficient space under the desk, free of storage or other obstacles, to permit
movement and stretching of the legs.
Equipment Layout
The ideal Arrangement of materials and equipment will be determined by:
· the tasks performed, their frequency and duration, and the equipment used;
· visual requirements;
· reach distances;
· space allowances.
There is a great need for flexibility in the location and positioning of equipment.
Reach Distances
The location of equipment should be determined by task analysis. As a general rule:
· the most frequently handled objects should be within easy reach when the elbow is resting
on the desk top (optimum reach);
· the less frequently handled objects should be placed within the distance reached by the
outstretched arm (maximum reach).
Visual Requirements
Head and neck postures are largely determined by the visual demands of the task.
Frequently viewed material and equipment should be located so that the viewing angle and
distance allows the operator to maintain an efficient posture while still being able to see the
task easily.
As the main tasks in keyboard work pose high visual demands, it is essential that the user has
adequate vision, corrected if necessary, to perform the work without undue visual fatigue.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Equipment design should aim at optimising visual quality; while work organisation should take
into account that visual quality is often less than ideal. For example, source material, may be
of varying quality and legibility (for example, handwritten text) and different types of paper
(for example, carbon copies and glossy finishes) can be difficult to read.
Lighting factors are critical in optimising viewing conditions and minimising visual discomfort.
Activity 12
Describe the information you would expect to find in a Safe Work Statement.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 12
Identify safety hazards and implement risk control measures in consultation with appropriate
personnel
The hazard identification and risk control process

By following a hazard identification and risk control process, employers can anticipate the
types of health of safety problems that might affect workers, and take action to prevent
problems from occurring, or at least minimize the risk.
The process of managing risks is a three-step process:
1 Find the hazards (hazard identification).
2 Check them out and consider how likely it is that problems will occur, and how serious
the consequences might be (risk assessment).
3 Do what can reasonably be done to prevent accidents or injuries (risk control).
tmg.edu.au | 1300 888 TMG (1300 888 864)
Measures put in place to control health and safety risks must be checked to see if they are
actually working – that is, if they are successfully controlling the risks they were intended to
control monitoring and evaluation of risk controls. The process of hazard identification and
risk control can be applied to any type of work or risk.
Hazard identification
The first step in the hazard identification and risk control process is known as hazard
identification. A hazard is anything with the potential to harm life, health or property. All the
types of potential hazards present in a particular job or task need to be considered and the
risks presented by these hazards need to be assessed to work out how likely they are to
cause harm, and how serious the harm might be.
Hazards arise from:
 the work environment
 the use of machinery and substances
 poor work design
 inappropriate systems and procedures.
Types of hazards
Many kinds of hazards are found in workplaces.
 Chemical hazards are substances that can harm people’s health when they are
breathed in or absorbed through the skin, or when they irritate the skin. Examples
include some kinds of dusts, vapours and fumes. Cigarette smoke is a chemical hazard,
as are asbestos fibres in the air. Substances such as pesticides, solvents, ozone, and
toner can present chemical hazards. Chemical hazards can poison people or make
them ill, if enough is absorbed into the body.
 Physical hazards include electricity, noise, temperature, lighting, radiation and

vibration. For example, excessive noise can cause noise-induced hearing loss, fine work
done in poor lighting can cause eye strain, and excessive heat can cause a range of
health effects, like heat stress.
 Biological hazards such as infectious diseases can also be present in workplaces. For
example, workers in a childcare centre can get contagious diseases from the children.
 Lifting and moving loads can cause back injuries and other strain or sprain injuries.
Occupational overuse syndrome can result from work practices and work organisation
that involves people working in postures which are uncomfortable or which do not
involve enough variety.
 Psychological stress can result from workplace violence, bullying, threats or

intimidation.
Employers need to identify whatever hazards exist in the workplace, and to do this they
should consult workers, to find out workers’ views of any threats to their health or safety.
Workers need to be able to contribute to this process by telling their supervisor of any
potential health and safety problems they find.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Workers should note matters such as trip hazards, unsafe electrical installations, any type of
unsafe situation or dangerous work practice, or anything else they think might be a health or
safety problem, and bring these to the attention of their supervisor according to workplace
procedure. Supervisors should take action to rectify the problem.
If the problem is not resolved, workers may need to report the matter to the workplace
health and safety committee or the OHS representative. If the matter is still not resolved,
workers could ask for advice from the state’s OHS authority, which in New South Wales is
WorkCover NSW.
Management should also investigate all accidents and near misses to work out what could
have been done to prevent them. Workers should co-operate fully in these investigations,
reporting incidents according to workplace procedures.
Identifying drug and alcohol abuse as a hazard

Drug and alcohol abuse in the workplace must be seen as part of the hazard and risk control
process. Employees must at all times carry out their duties and responsibilities in a safe
manner. Where an employer believes that a person’s capacity to perform work in a safe
manner may be impaired, the employer has the responsibility to ensure they are not in a
position of personal risk, and they do not present a risk to the health and safety of others. A
duty of care rests with employers. If an employer believes that substance abuse may be
affecting workplace performance, they must take steps to ensure the health and safety of
the individual, and other employees who may be affected by that individual’s actions. It is
appropriate for the employer to remove the employee from any position of risk and refer the
individual to an appropriate assessment agency eg medical practitioner.
Identifying hazards in the IT environment

OHS risk analysis consists of hazard identification, workplace assessment and risk control.
Hazards are the main identifiable cause of workplace health and safety problems. They
include:
 machinery
 chemicals
 noise
 electrical hazards
 poor work design
 poor management systems and procedures
 human behaviour.
Once a hazard has been found it is then assessed as to its potential to cause damage and
then a solution to the problem is sought.
Remember—find it, check it out, get it fixed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Occupational health and safety supervisor

Hazards should be reported to the occupational health and safety supervisor. The
occupational health and safety supervisor may be:
 a person appointed to this position (in a large company)
 the chairman or a member of the occupational health and safety committee
 a safety representative.
Receiving and installing new computer equipment

Consider the situation where new computer equipment arrives at your company. This
equipment needs to be unpacked, moved from one location to another and then installed
at the workstation. Care must be taken doing all these tasks to avoid injury.
Unpacking computer equipment

 Make sure there is enough room for you to unpack the equipment and enough lighting
so you can see what you are doing.
 Do not unpack in a hallway or area where someone is likely to be in danger of tripping

over you and the packaging.
 Don’t place boxes in doorways or at the top of stairs. It is illegal to block fire escapes.
Safe lifting
Good safe lifting techniques are crucial when lifting computer equipment or other objects.
Even when the load appears small make sure you use the right technique.
Figure 1: How to lift safely
Before you lift, make sure you’ve cleared a space to put the equipment.
When lifting,
 keep your back straight
 bend your knees
 hold the equipment you are lifting close to your body.
 If you need help — ask for it or get a trolley.

tmg.edu.au | 1300 888 TMG (1300 888 864)
Storing computer equipment

Sometimes, you might receive equipment before you’re ready. If you need to store
computer equipment for a while before installing it, put it where it can be accessed easily.
It’s better to store it in the original packaging. If you can’t, ensure the packaging is properly
disposed of, and not just left lying around.
Installing computer equipment

When you’re installing computer equipment, consider the space and the user before you
start the installation. If an existing computer is being replaced, don’t just assume that the new
one should go in exactly the same position.
Routing cables
Remember also that you’ll need to route any cables and power leads so that they:
 can reach to the appropriate connection point
 won’t be in danger of being trodden on, rolled over by chairs, or in an area where
there’s water or any other fluid
 won’t be placed so that people can trip over them, or be in any danger from them
 won’t be placed in such a way that a user could pull the cable, and so pull the
peripheral onto the floor.
User access
Also consider how the user will use the equipment. There’s no point having a device that
needs to be accessed regularly (like a printer) placed under a desk. On the other hand, it
may be possible to place a modem in a less accessible place.
If possible, discuss with the person who’ll be using the equipment where they’d like you to put
it. For example, a monitor shouldn’t be placed so that light from a window reflects off it into
the user’s eyes.
Electrical hazards
All employees should be given instructions for dealing with electrical hazards.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Take special note:

 Always turn off the power at the power point and disconnect the lead. Just turning
off the switch on the peripheral isn’t enough. It will still contain 240V.
 Avoid overloading a power board or power point. Whilst most computer equipment
doesn’t use more power than a power point can handle, you shouldn’t connect any
high power appliances, such as heaters, to the same power point or power board.
Ideally, the computer should have its own power point.
 Where you need to use extension leads or power boards, make sure they’re not
damaged, and if possible use ones with safety switches fitted.
 Don’t poke tools into any peripheral device. Apart from doing damage to the
device, you could also hurt yourself. For example, the voltages in the rear of a typical
monitor can exceed 25 000 volts (yes,
25 thousand)! Lethal voltages also exist in many other types of peripherals.
 Make sure that there’s no water or other fluid in an area where a peripheral device is
to be stored, installed or used. As fluids conduct electricity, they can both damage
the device and endanger the user.
Earthing strap
Earthing straps should be used if you need to touch components inside a computer. The next
screen explains how to use this strap.
The antistatic wrist strap wraps around your wrist, and is then connected to the outer casing
of a PC (which is, of course, switched off and unplugged from the mains). If you need to
switch the PC back on you must first detach the strap.
The earthing strap also protects the equipment because there is enough charge in your
body to damage the sensitive electrical components in the equipment.
Figure 2: Earthing strap
tmg.edu.au | 1300 888 TMG (1300 888 864)
Cables
Even though the outside of a cable may appear undamaged, the wire inside may be
broken, which will make it inoperative. The following screen has instructions for care of
cables.
Don’t twist or wind cables up tightly and avoid routing them around sharp objects or corners
which could eventually wear through the insulation. Power leads can be lethal if damaged
in this way.
Figure 3: Take care not to bend cables too sharply

or route them around sharp corners.
Frayed cords don’t have protective coating around the electrical wires. This is very
dangerous. You may get an electric shock if you touch frayed cord. Report frayed cords to
your supervisor. The cord should be replaced.
Before installing any computer equipment, always conduct a visual inspection of any cables
and connectors to be used, and replace any that appear to have been damaged.
Connectors
Always make sure you check for damaged connectors and use the correct methods for
plugging and unplugging them.
When you’re plugging a connector into a socket, always make sure that you line it up so that
the pins can slide easily into the holes, without bending. A common fault is a single bent or
broken pin, as seen the figure, which can be difficult to trace. Always visually check the pins
in any connectors before plugging them in. Never plug a cable into a machine that is turned
on. There is a risk of electric shock to the user and damage to the equipment due to the
power surge.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4: Take care not to bend pins
Once you have plugged in the connector, tighten the screws by hand. Don’t over tighten
these screws, as you may damage the connector, or make it difficult to remove.
Figure 5: Don’t over tighten screws
When removing a connector, never pull it by the cable. First loosen any screws, and then,
holding the body of the connector, gently rock and remove the connector. If it doesn’t
come out, check that the screws have been loosened fully, and then try again.
Figure 6: The right way to remove connectors
Some devices use an IEC connector for connection to the 240V power supply. An example is
the backplane of the system unit, which has both a male and a female IEC connector, one
to connect to the 240V power supply, and the other for connecting a monitor power lead.
Figure 7: IEC connectors
IEC connectors don’t have tightening screws, but rely on friction to hold them in place.
Sometimes they may need to be wriggled in or out of place quite firmly.
Practise identifying cables and connectors
Turn the power off on your computer. Turn the power off on each of your peripherals that
has a power switch. Also turn the power off at all power points being used and disconnect
any plugs from the power points. Verify that the power is off by trying to turn on your
computer and peripherals. Turn them off again.
On a piece of paper, sketch a diagram of your computer backplane.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Carefully unplug one of the cables from your backplane (either serial or parallel port) by
first undoing the screws, and then gently removing the plug as described above.
On your diagram, note the type of connector, and what peripheral it is connected to. Is it
what you expected? Reconnect the plug carefully, as described above, and lightly
tighten the screws.
Repeat for all connectors on your backplane, ensuring you replace them in the correct
positions. When finished, you’ll have a diagram of all the ports on your backplane, with
descriptions.
Turn the power back on.
Cleaning and maintaining computer equipment

Particular care must be taken when cleaning computer equipment.
Before cleaning any electrical equipment make sure that it’s switched off and unplugged
from the mains. This is important, because if there’s a short circuit or malfunction in the
equipment it could still be ‘live’ and result in an electric shock and possible death.
Allow certain equipment, such as monitors and laser printers, to cool down and lose their
capacitance before cleaning them. You should leave monitors switched off for at least 30
minutes before cleaning the outside of them, and laser printers switched off for at least 30
minutes before cleaning inside them.
If you’re cleaning inside a PC, or you’re going to handle parts from a PC such as hard disks or
circuit boards, you should earth yourself using an antistatic earthing wrist strap.
Always refer to the manufacturer’s manual before attempting to clean any equipment,
because improper cleaning or maintenance may be dangerous and also may invalidate
your warranty.
Some equipment, such as power supplies and monitors, use large voltages and therefore
should only be maintained by people specially trained. It could be dangerous for anyone
else to open them for maintenance.
Occupational overuse syndrome

Occupational Overuse Syndrome (OOS) is a serious injury that can affect you if you perform
repetitive tasks, forceful movements and/or have poor posture. It has also been called
Repetitive Strain Injury (RSI).
If you have symptoms of OOS, you will feel discomfort or persistent pain in muscles, tendons
and other soft tissues, especially in the arms, hands and neck.
There are some specific medical conditions that can be found in people who have OOS. The
most well known condition is carpal tunnel syndrome, where the median nerve is
compressed as it enters the palm of the hand. If you suffer from this condition, you would feel
pain and numbness in the index and middle fingers and a weakness of the thumb.
Ways to avoid OOS
tmg.edu.au | 1300 888 TMG (1300 888 864)
To avoid OOS your job should not involve too much repetitive keyboard work. You should
take a break, your workstation should be well designed and you should be prepared to
change your work habits if necessary.
Good job design
You may suffer OOS if your work or study involves repetitive actions that don’t allow you to
change what you’re doing or switch to a completely different movement. It is important to
design jobs so that:
 you don’t have too many peak demand periods
 you don’t get a bonus for doing more
 you can do tasks that require different actions over the day or night
 every hour you can stop and stretch.
Good work area design
It is important that you use furniture and equipment for the purpose for which it was designed
in the first place. If your chair, desk and workstation have not been designed for repetitive
work such as keying or moving the mouse you may suffer OOS injuries. Computer equipment
such as the keyboard and mouse should meet Australian Standards.
The right attitude
Be aware that OOS is a potential problem and you should pay attention to any early signs,
especially when you are dealing with a heavy workload. There are good stretching exercises
that you can do to minimise further trouble or permanent damage as long as you act as
soon as or before you get the first twinge.
Remember, if it hurts – stop! OOS injuries are made worse by ignoring them and continuing
the activity without eliminating the cause of the stress.
Risk assessment
Assessing workplace risks means considering how likely it is that problems will occur, and how
serious the consequences might be.
Clearly, this is not always easy, but workers are often in the best position to know which
details of the task or process might involve the greatest risks of something going wrong. Near
misses, or incidents which could have resulted in undesirable outcomes, can also provide
information on the potential for accidents and injuries.
The seriousness of the potential consequences can be considered by asking questions such
as ‘Could anyone be killed?’ or ‘What could happen if…?’
Through a process of considering the likelihood and possible consequences of the various
hazards or risks that have been identified, the risks can be ranked from highest priority to
tmg.edu.au | 1300 888 TMG (1300 888 864)
lowest priority. Risks that are potentially most serious and/or most likely to cause health and
safety problems should then be tackled first.
Figure 8: Assess the risk
Workers have a lot to contribute to this process of assessing risks, through their familiarity with
the details of the work process.
Risk control
Controlling workplace risks means doing what can be done to prevent problems and protect
people’s health and safety.
Clearly, the most desirable way of managing risks of work injury is to eliminate the risk entirely,
if this is possible. For example, if a noisy machine can be replaced with a quiet one, the noise
hazard has been eliminated.
If the risk cannot be eliminated, it should be minimised in whatever ways are most likely to be
practicable and effective. This could involve:
1 substituting the process or substance with a safer one
2 designing premises or equipment so that it is safer to use
3 engineering controls (altering tools, equipment or work systems to make them safer, eg.
enclosing or isolating the hazard)
4 administrative measures (such as training workers in safe procedures, organising suitable

maintenance or housekeeping practices, job rotation or changing work organisation)
5 using personal protective equipment (PPE—such as ear muffs, dust masks, gloves, etc).
This list of types of strategies is known as the hierarchy of risk controls (or the hierarchy of
hazard controls), because risk control should be accomplished using strategies as close as
possible to the top of the list (these are more effective).
In many cases it will be necessary to use more than one control method. PPE is the least
effective and should be the method of last resort, used only as an interim measure or if no
other measures are practicable.
tmg.edu.au | 1300 888 TMG (1300 888 864)
This is because PPE often does not give as much protection as other types of controls. For
example, a dust mask will not give much protection if it is already clogged up with dust, or if
there is not a good facial fit for the wearer and dust can enter the worker’s lungs via the
gaps between face and mask. PPE can also be hot, awkward or uncomfortable, and
workers may neglect to wear it for some of the time they are exposed to the hazard.
Risk controls that have been put in place should be monitored to check that the risk is
adequately controlled, and that the risk controls do not create new hazards. Workers’
feedback is an important part of checking whether risk controls are achieving their purpose.
Information on hazards
Part of the process of identifying and controlling hazards relies on finding out what you can
about how likely it is that someone could be harmed, how serious the injury or illness may be,
and how the hazard can be controlled. Review any available information about the hazard,
such as:
 information supplied to you by the manufacturer of the product or equipment
(handbooks/operating manuals)
 material safety data sheets (MSDS) prepared by the supplier of a hazardous substance
 experience from the workplace with the hazard or similar hazards, such as workers’
experience or injury data
 control measures outlined in Chapters 4–8 of the Occupational Health and Safety
Regulation 2001
 WorkCover NSW guidance material to help you assess potential risks for particular
hazards, processes and work tasks
 Australian Standards that set out specifications for a range of equipment, products and
materials to ensure that they are safe and of a good quality.
 codes of practice to give you direction and guidance on the identification and control
of specific hazards.
Codes of practice
Codes of practice provide practical guidance and advice on how to achieve the standard
required by the Act and Regulation. Codes of practice are developed through consultation
with representatives from industry, workers and employers, special interest groups and
government agencies.
A code of practice is not law, but it should be followed unless there is an alternative course
of action that achieves the same or better standards.
Here is a partial list of codes of practice in force in New South Wales. Listed here are only
codes that apply across a variety of industries. Each sector, for example, the construction
industry, may have detailed codes of practice that apply only to this sector.
 Code of Practice for Risk Assessment 2001
 Code of Practice for the Control of Workplace Hazardous Substances 1996
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Code of Practice: Safe Handling Storage of Enzymatic Detergent Powders and Liquids
1994.
 Code of Practice for Work in Hot or Cold Environments 2001.
 Code of Practice for Noise Management and Protection of Hearing at Work 1997.
 Code of Practice: Occupational Health and Safety Consultation 2001.
 Code of Practice for Manual Handling 1991
 Code of Practice for Workplace Injury and Disease Recording 1991 (NSW adopts AS
1885.1-1990)
 Code of Practice for the Prevention of Occupational Overuse Syndrome 1996.
Material safety data sheets (MSDS)

MSDS are prepared by the supplier of a hazardous substance and should be available on
request from the supplier. There is a national Code of Practice for the Preparation of MSDS
(2003) and a Code of Practice for the Preparation of MSDS (1996) for NSW.
On the Internet there are a number of sites that hold compilations of MSDS. Here are two:
http://www.ilpi.com/msds/index.html
http://physchem.ox.ac.uk/MSDS
Safe working procedures

When the hazards have been identified and assessed and control measures have been
worked out, management may formulate policies, programs and procedures to make sure
the risks are properly controlled. The policy is essentially the statement of management’s
commitment to health and safety; the program is a set of plans and activities to give effect
to the policy, and the procedures are the details about how each job and task can be done
in the safest way practicable.
Workers should be trained in these procedures, and it is essential for them to understand and
follow whatever safe working procedures have been established.
These systems of work are sometimes referred to as Safe Operating Procedures (SOPs), or
Safe Work Method Statements (SWMS). A SWMS is a statement that describes how work is to
be carried out. It identifies the work activities assessed as having a safety risk and outlines the
safety risks. It also describes the control measures that will be applied to the work activities.
The SWMS includes a description of the equipment used in the work, the standards or codes
to be complied with, the qualifications of the personnel and training required to do the work.
The consequences of not following these systems of work them can include injuries or illness
for workers or others present at the workplace, loss of morale and productivity, and
prosecutions of the employer.
Safety signs and symbols

Some organisations use safety signs and symbols to indicate the hazards present in various
parts of the work environment. These are standard international signs from which workers can
tmg.edu.au | 1300 888 TMG (1300 888 864)
tell, eg where eye protection should be worn, or where emergency showers are located.
Workers should be familiar with these signs and comply with them at all times.
Safety signs and what they mean
Make sure you know what each of these signs means:
Figure 9: International safety signs
Sign 1: Do not smoke
Sign 2: You must wear a hard hat
Sign 3: Caution, risk of electric shock
Sign 4: Caution, chemical hazard
Sign 5: First aid
Sign 6: Not drinking water
Sign 7: You must wear safety boots
Sign 8: Caution, biological hazard
Sign 9: Do not enter
Training
Training in risk control measures, in safe work procedures, and in how to participate in the
hazard identification and risk control process, is essential to achieve a safe and healthy
workplace. Induction training must be given when workers first start work at an organisation,
and from time to time after that, as necessary. Workers should be trained in how to use
substances and equipment safely, and in the systems which are in place to protect health
and safety, including the functions of the workplace OHS committee (if there is one) and the
tmg.edu.au | 1300 888 TMG (1300 888 864)
OHS representative. The training should also cover the reporting and investigation of
accidents/incidents, and any other health or safety concerns. Workers should make sure they
follow the training they have been given, and should always ask their supervisor if they are
not sure how the job can be done safely.
Summary
The hazard identification and risk control process can be simple or complex, depending on
the scope and nature of the risks to health and safety.
The principles, however, remain the same. Risks need to be:
 identified (using records of injury, illness, incidents, talking to workers, workplace
inspections, audits, surveys or accident investigations)
 assessed (risks are checked out for the likelihood and severity of possible harm, and
ranked in priority order)
 controlled (effective ways to control the risk are identified then put into practice, using
the hierarchy of risk controls)
 evaluated (new risks need to be checked for, and methods of risk control need to be
checked to see whether they are accomplishing their purpose adequately, and not
creating new risks).
Workers need to follow organisational procedures and instructions for risk control when
hazards are present. Complying with safety signs is part of risk control.
Activity 13
Select and describe one hazard related to server administration activities and provide at
least one control method.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 13
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 13
Consult appropriate person to ensure the task is coordinated effectively with others involved
at the worksite
Why is consultation important?
Consultation is a legal requirement and an essential part of managing health and safety risks.
A safe workplace is more easily achieved when everyone involved in the work
communicates with each other to identify hazards and risks, talks about any health and
safety concerns and works together to find solutions. This includes cooperation between the
people who manage or control the work and those who carry out the work or who are
affected by the work.
By drawing on the knowledge and experience of your workers, more informed decisions can
be made about how the work should be carried out safely.
Effective health and safety consultation also has other benefits:
 Greater awareness and commitment – because workers who have been actively
involved in how health and safety decisions are made will better understand the
decisions.
 Positive working relationships – because understanding the views of others leads to
greater co-operation and trust.
 In situations where you share responsibility for health and safety with another person,
the requirement to consult, co-operate and co-ordinate activities with other duty
holders will help address any gaps in managing health and safety risks that often
occur when:
 there is a lack of understanding of how the activities of each person may add to the
hazards and risks to which others may be exposed
 duty holders assume that someone else is taking care of the health and safety matter
 the person who takes action is not the best person to do so.
The outcome of consulting, co-operating and co-ordinating activities with other duty holders
is that you each understand how your activities may impact on health and safety and that
the actions you each take to control risks are complementary.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Many organisational decisions or actions have health and safety consequences for workers.
For example, introducing new equipment into the workplace may affect the tasks your
workers carry out, the timeframes for doing work, how they interact with each other and the
environment in which they work.
The WHS Act identifies specific matters that trigger the requirement for consultation.
A person conducting a business or undertaking must consult with workers when:
 identifying hazards and assessing risks arising from the work carried out or to
be carried out
 making decisions about ways to eliminate or minimise those risks
 making decisions about the adequacy of facilities for the welfare of
workers
 proposing changes that may affect the health or safety of your workers,
and
 making decisions about procedures for consulting with workers; resolving
health or safety issues; monitoring health of your workers; monitoring the conditions
at the workplace and providing information and training for your workers.
Consultation is a two-way process between you and your workers where you:
 talk to each other about health and safety matters

 listen to their concerns and raise your concerns
 seek and share views and information, and
 consider what your workers say before you make decisions.
Consultation requires that:
 relevant work health and safety information is shared with workers

 workers are given a reasonable opportunity to express their views and to
raise health or safety issues
 workers are given a reasonable opportunity to contribute to the decision-
making process relating to the health and safety matter
 the views of workers are taken into account, and
 workers are advised of the outcome of any consultation in a timely
manner.
The information should be presented in a way that can be easily understood by your workers
and take into account literacy needs and the cultural or linguistically diverse backgrounds of
your workers.
Young workers and those with limited English may be less likely to question health and safety
practices or speak up if they are unsure. They may find it easier to communicate through a
health and safety representative, an interpreter or worker representative. Information should
also be simplified and presented in different ways, such as using diagrams, to make it easier
to understand.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Meeting face-to-face is usually the most effective way of communicating, although that
may not always be possible or preferable. Information can also be shared in other ways,
including:
 by telephone or email
 featuring current health and safety news and information on intranet sites or
noticeboards.
Information should be updated and attention drawn to new material so that people who do
not regularly check it will know what is happening in their workplace.
Providing reasonable opportunities to express views and contribute
Giving your workers a reasonable opportunity to express their views and contribute to health
and safety decisions may involve:
 providing a suitable time during work hours for consultation with workers
 allowing opinions about health and safety to be regularly discussed and considered
during workplace meetings
 providing workers with different ways to provide feedback, for example using email,
setting up an intranet health and safety page or a suggestion box.
How long the consultation process takes will depend on the complexity of the health and
safety matter, how many people are being consulted, the accessibility of workers and the
methods of consultation. A simple issue affecting only a small number of workers can
probably be dealt with in a few hours or days through regular channels of communication. A
complex technical matter, or consulting a large workforce, may require more time.
If there are health and safety representatives for the workplace, you must include them in
the discussions, with or without the involvement of workers directly.
Taking views into account
You must take the views of your workers and health and safety representatives into account
before making a decision. Consultation does not require consensus or agreement but you
must allow your workers to contribute to any health and safety decisions you make in your
business.
To what extent should you consult?
You must consult on health and safety matters so far as is reasonably practicable with
workers who carry out work for you and who are (or are likely to be) directly affected. This
includes consulting with your contractors and their workers and volunteers (if any) about
health and safety decisions that directly affect them and which you influence or control.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consultation that is ‘reasonably practicable’ is both possible and reasonable in the particular
circumstances. What is reasonably practicable will depend on factors such as the:
 size and structure of the business

 nature of the work that is carried out
 nature and severity of the particular hazard or risk
 nature of the decision or action, including the urgency to make a decision or take
action
 availability of the relevant workers and any health and safety representatives
 work arrangements, such as shift work and remote work
 characteristics of the workers, including languages spoken and literacy levels.
The aim of consultation should be to ensure that you have sufficient information to make
well-informed decisions and that the workers who may be affected are given a reasonable
opportunity to provide their views and understand the reasons for the decisions.
You are not expected to do the impossible, but are required to take a proactive and
sensible approach to consultation. For example, an urgent response to an immediate risk
may necessarily limit the extent of consultation in some circumstances. It may also not be
reasonably practicable to consult with workers who are on extended leave. However, it
would be appropriate to ensure that these workers are kept informed about any matters that
may affect their health and safety when they return to work.
It is not always necessary to consult with every worker in your workplace. The workers you
consult with will be those who are, or could be, directly affected by the health and safety
matter. For example, a problem with air temperature experienced on one level of an office
block may not directly affect the work health and safety of workers on other levels. Only
workers on the affected level need to be consulted about the matter.
Consultation with workers can be undertaken in various ways. It does not need to be a
formal process and can be as simple as talking to them regularly and considering their views
when making health and safety decisions.
Consultation can also be undertaken through health and safety representatives and health
and safety committees. However, the WHS Act does not require the establishment of these
consultation mechanisms, unless:
 in relation to a health and safety representative – a request is made by a worker

 in relation to a health and safety committee – a request is made by 5 or more workers
or a health and safety representative.
You may establish any arrangements for consultation to suit your workers and workplace
situations, including agreed consultation procedures, as long as those arrangements are
consistent with the requirements of the WHS Act.
What kind of consultation is best for your workplace?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consultation arrangements should take into account the size of the business, the way work is
arranged and what suits your workers. Many workplaces will already have ways to consult on
health and safety that suit their needs. These arrangements can continue if they are
consistent with the requirements of the WHS Act and workers have been consulted about
them.
To determine how best to consult, you should first discuss with your workers issues such as:
 the duty to consult and the purpose of consultation

 the range of work and associated health and safety issues at the workplace
 the various ways for consultation to occur, including your workers’ right to elect
health and safety representatives
 your workers’ ideas about the most effective way to consult.
You should work out methods that:
 meet your duty to consult

 ensure all workers can participate in consultation including any shift workers or mobile
workers
 will best integrate with the way your business manages health and safety.
Consideration should be given to how management normally communicates with the

workers. You may not need to establish separate consultation arrangements if there are
regular discussions between managers or supervisors and the workers, for example weekly
team meetings. This may be the case in a small business with few workers where there are
direct discussions as part of everyday work.
In organisations where it may not be reasonably practicable to consult each worker

individually, health and safety representatives or committees may be more appropriate.
Some workplaces may need a mix of consultation arrangements to suit different types of
workers and situations. For example, a business may have a number of full-time workers
where structured arrangements involving health and safety representatives and committees
may be suitable. On occasions the business may also engage contractors or on-hire workers
to carry out specific tasks, where arrangements such as ‘toolbox talks’ (short discussions on
specific health and safety topics relevant to the task) may be the most practical way to
consult with them.
When unexpected matters arise, there may not be time to plan consultation, so
consideration should be given to whether the issue can be addressed through one of the
regular communication channels, or if there is a need to do something different like hold a
one-off meeting.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 14
Why would you need to discuss your work activities with non IT technical personnel?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 14
Back up server before implementing configuration changes
Why Is It Necessary To Backup Your Server ?
Backing up your server is an essential task to be performed on a regular basis. By backing up

your server data helps you to prevent data loss. It should be your regular job to backup your
server, just like brushing your teeth. Backup can be done using two different methods, using
automated software’s and the another way is to backup manually. You need to ensure that
the backups are working properly and on regular basis. If you think or believe, that backups
are not essential, check out the following points explaining, why you should always backup
your dedicated server ?
 The server data may includes other users data, for example, if you are hosting reseller
and hosting a couple of websites for your clients or suppose if you have a large social
media website consisting sensitive information posted by its users. Such users or clients
completely rely on you to keep their sensitive information safe and secured.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Although, if you have informed them to backup their own data, you should also
backup the server data, just in case if they forget to backup.
 Backups are Bit Costly: There are several backup hosting plans which are only a bit
costly, however they can save a bunch for you. Moreover, you will have to pay for a
backup server or extra backup storage device. For such data loss issues, the offsite
backup hosting plans are really cost-effective which may save your business from a
permanent data loss. The offsite backup hosting provides the R1Soft’s Continuous
Data Protection (CDP) solution, where your server data is stored on offsite servers.
Even if your original server gets crashed, you can still recover your data from the
offsite servers.
 If you search a bit for server backup solution, you will get hundreds of good backup
software’s for both Linux as well as Windows. Many of them will be free and easy to
use, but some may be the premium softwares like R1Soft’s. Some of the web hosting
control panel may have an in-built backup utility which can be used to backup your
critical data.
 Though your web hosting provider says that their dedicated servers are fully secured,
you should be prepared for such instances. Because, you never know, what and
when something will happen. It is better to be prepared to face such issues.
 Having your backups ready also helps you in making your data migration easier. If
you plan to move your data from old to a new server at the same location but on a
different server, the backups will save you both time and money.
From the above points, you must have realized that why your dedicated server backups are
necessary and the most important task for your business.
Windows Server Backup Example
Incremental Backups with the Built-In Windows 2012 Server Backup Over the Network
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows Server products have always had built in utilities to perform backups over the
network, however beginning with Server 2008, the utility would no longer allow incremental
backups to a destination that was across the network. However, there is a work around to
this if you consider using iSCSI. iSCSI is a protocol that allows you to use a storage location on
a different device on the network as a local drive on your server.
iSCSI has often been associated with expensive SAN devices in the past, but most modern
server operating systems have the ability to act as an iSCSI target. There are many consumer
grade NAS devices that also have built-in iSCSI capabilities. In this example I am going to use
a Linux iSCSI target as seen in this guide, but you can also use Windows Server 2008 R2 or
greater. Windows Server uses VHD files as your LUN but starting with Windows Server 2012 R2,
it uses a VHDX so that it grows dynamically. There is a good chance that the server or device
you want to send your backups to supports iSCSI and if Windows Server Backup thinks you are
backing up to a local drive, it will let you perform incremental backups instead of performing
a full backup each night. This has two benefits. It is quicker to perform an incremental
backup and you also get revisions history of backups to restore from instead of just the
previous night.
I want to backup my Windows 2012 R2 Server to my iSCSI server. We first need to install the
Windows Server Backup feature. In the Server Manager click on Manage and then Add Roles
and Features
Under the features, click Windows Server Backup and install. You should not require a reboot,
perform one if required.
Before we configure our backup we must next configure our iSCSI Initiator (the client side of
iSCSI). In the Administrative Tools under Control Panel, open iSCSI Initiator and if prompted to
set the service to start automatically, click Yes. Just a note, I am not going to detail on how
tmg.edu.au | 1300 888 TMG (1300 888 864)
to setup the iSCSI target because you can use many different systems for that. Consult your
documentation on how to setup the LUNs and Targets on that end.
Click the Discovery tab and the Discover Portal button. Enter in the IP or host name of the
iSCSI target you wish to use:
In my example, I have created 4 targets to choose from. If I have multiple servers to backup,
I can use a different target for each server.
Click a target you wish to backup to and hit Connect. You will be given the option to Add
this connection to the list of Favorite Targets. If you do this, it will auto connect upon each
reboot so you will want to leave this checked. The status should have changed to
Connected as well.
tmg.edu.au | 1300 888 TMG (1300 888 864)
We need to now bring the disk online initialize it so that Windows Backup Server sees it. Go to
Computer Management under Administrative Tools and Disk Management.
In my example I would right click on Disk 1 and bring it online and then right click again to
intialize it. You also need to format the disk. You can format it without assigning a drive letter
or mounting anywhere. We just need to give Windows Backup Server a point to backup to.
Next we can open up Windows Backup Server under Administrative Tools. On the right
Column under Local Backup select Backup Schedule…. This will let us setup our backup
options and then schedule it for an appropriate time each night to backup. I am selecting to
backup the Full Server. You can pick and choose what to backup if you prefer.
Net select the time or times that you would like to backup. It will backup each day and you
cannot select to backup only certain days. Click Next and then select to Back up to a hard
disk that is dedicated for backups (recommended) and then click Next.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Click Show All Available Disks to select the

target disk and then put a check next to Disk 1. Click Ok and then Check Disk 1 again in the
next screen and click Next.
You should now get a warning that this volume was set to be backed up. Click OK to remove
this volume from being backed up. Then click Yes to allow it to be reformatted and to not be
tmg.edu.au | 1300 888 TMG (1300 888 864)
visible in File Explorer. Click Finish and then close after the backup has been created
successfully.
You can click Backup Once… if you want to test your backup. It will give you a progress
window so you can view the status.
You should now have a daily incremental backup running of your server or servers. However,
Windows Server Backup has no built-in way to let you know if the backup runs successfully or
not.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 15
What is the purpose of backing up the server configuration?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configure update services to provide automatic updates to ensure maximum security and
reliability
Patch management
Patch management is an area of systems management that involves acquiring, testing, and
installing multiple patches (code changes) to an administered computer system. Patch
management tasks include: maintaining current knowledge of available patches, deciding
what patches are appropriate for particular systems, ensuring that patches are installed
properly, testing systems after installation, and documenting all associated procedures, such
as specific configurations required. A number of products are available to automate patch
management tasks, including RingMaster's Automated Patch Management, PatchLink
Update, and Gibraltar's Everguard.
Like its real world counterpart, a patch is a "make-do" fix rather than an elegant solution.
Patches are sometimes ineffective, and can sometimes cause more problems than they fix.
Patch management experts, such as Mark Allen, CTO of Gibraltar Software, suggest that
system administrators take simple steps to avoid problems, such as performing backups and
testing patches on non-critical systems prior to installations.
The patching of software is a tried and true activity that helps to protect IT infrastructure and
end-user computers from possible security threats, while also supporting the installation of
ongoing software bug fixes and feature enhancements.
Most software is updated by the software vendor either on a regular schedule -- think
Microsoft's so-called Patch Tuesday -- or on an ad hoc basis as the need for software
patching arises. In this article we will discuss whether a company should manually patch
infrastructure servers and end users, or whether it makes more sense to purchase an
automated patch management tool to reduce the time IT personnel spends keeping
operating systems (OSes) and software applications up to date?
As the description above makes clear, whether or not to patch is not the dilemma --
companies must keep their computer software up to date with the appropriate patches. In
fact, in the case of publicly traded companies, regular patching of software may actually be
required by federal regulations such as The Sarbanes-Oxley Act (SOX), Federal Rules of Civil
Procedure (FRCP) and Health Insurance Portability and Accountability Act (HIPAA). Many of
these government regulations provide for substantial financial penalties and even possible
criminal charges for CEOs and CFOs of publicly traded companies that do not abide by
regulatory requirements.
There are similar financial, healthcare and corporate regulations in most countries around
the world, so patch management should be a priority for every company. The decision to
deploy automated patch management is influenced by a number of factors, some specific
to an organization and some related to the function of IT as a whole within it.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The patching process
Depending on the size of an organization, and the duties expected of or assigned to IT,
patch management is likely considered a prime area of focus for information technology
professionals. In most companies, IT owns the computing infrastructure that includes servers,
load balancers, storage arrays, appliances, network gear and more. Obviously, IT must
always take responsibility for the timely patching of those infrastructure servers and devices. It
should be sure to create a sandbox environment, however, where new patch releases can
be tested before distribution to servers and other devices.
In addition to keeping infrastructure computers patched and up to date, IT must devise and
distribute a process for keeping end-user computers patched as well. There are two possible
processes for implementing patch management for end users:
1. Define and distribute a written process for all employees to follow in order to keep
their desktop or laptop OS up to date, as well as their locally installed applications.
2. Deploy an automated patch management system that lets IT tightly control what
and when patches are distributed.
If an organization trusts its employees to keep their own computer patching up to date, it
might also be wise to occasionally inventory a representative sample of users to make sure
they are complying with corporate patch management policy. Be aware, though, that
trusting employees to manage their own OS and applications patching can expose a
company to liability if it is subject to governmental or corporate compliance regulations. In
an organization's analysis of whether to use self-compliance or an automated tool for patch
management, it should be sure to factor in the potential financial implications of running
afoul of governance and compliance regulations should its patching efforts come up short
of those regulations.
If a company owns software inventorying tools such as Microsoft System Center

Configuration Manager or Symantec Endpoint Management (formerly known as Altiris), then
the underlying inventory infrastructure is already in place to conduct regular audits of
software license and patch levels. When inventory audits indicate that end-user applications
are out of date, patch management software can then be used to ensure compliance with
patching guidelines or requirements.
Though there can obviously be substantial costs to implementing a comprehensive patch

management infrastructure, for enterprise-scale companies in tightly regulated industries the
benefits of automated patch management likely far outweigh those costs. Let's take a look
at a couple of scenarios that will help amplify the possible business cases for automated
patch management.
As companies continue to struggle with budget pressures in a tight economy, the

importance of automating routine tasks remains a prominent consideration in the allocation
of IT budgets. Enterprise patch management software is a prime example of a tedious
manual task that benefits greatly from automation, ensuring that all computers remain up to
tmg.edu.au | 1300 888 TMG (1300 888 864)
date with the latest patch releases from operating system (OS) and application software
vendors.
Keeping computers up to date with the latest patches is no longer just a recommended best
practice for corporate IT. The Sarbanes-Oxley Act (SOX) and internal corporate guidelines
have codified the requirement for consistent, up-to-date patching of all computers in a
given IT infrastructure.
Patch management software offers companies the ability to abide by industry best practices
while also complying with any applicable regulatory requirements for the securing of IT
systems against possible malware or unauthorized intrusions.
Why patch operating systems and software?
Rather than relying on industry best practice recommendations for manually keeping all OS
and applications up to date with patches, enterprise patch management software enables
IT pros to delegate that task to sophisticated software that can seamlessly handle the
distribution process. Patch management software can also provide automated compliance
reports that document which computers are -- and are not -- up to date, as well as sending
notifications to admins based on successful or unsuccessful patch activities.
One need only refer to recent, well-publicized outbreaks of malware that were specifically
designed to attack vulnerabilities in popular software such as Microsoft SQL Server to see that
patching isn't just a good idea; keeping patches up to date is a mandatory component of
the IT software management process.
How does automated patching work?
Most enterprise patch management software requires the installation of an agent on target
computers. This agent provides a connection between the patch management server and
the computers to be patched. Agents can also handle patching tasks such as sending alerts,
caching patches locally on the target computer prior to installation, and retrying failed
patch installations.
Many admins are understandably reluctant to install an agent on hundreds or thousands of

computers just to handle patch management. This is one of the reasons that standalone
patch management software is frequently included in an integrated bundle with other
monitoring and management software that also requires an agent.
Installing one agent that, for example, facilitates patch management, performance
monitoring and server health statistics is usually a better strategy than installing three
separate agents that each address different aspects of managing a target computer. Any
modern patch management software will include agents that run on all recent versions of
Windows, Linux/UNIX and, in a nod to the BYOD movement currently afoot, will frequently
include agents that run on mobile platforms such as Android or iOS.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Patch management caveats
As it turns out, the practical challenges of enterprise patch management are not usually in
the distribution of the patches themselves. Pushing patches across a modern network with
patch management software is a relatively simple process, once all of the target computers
have an appropriate agent installed. The trick comes not in how to push patches but rather
in which patches should be pushed to targets and when.
Patch management software offers companies the ability to abide by industry best practices
while also complying with any applicable regulatory requirements for the securing of IT
systems against possible malware or unauthorized intrusions.
Even though software vendors regularly release patches -- and experts usually recommend
installing these immediately -- there is also a patch management best practice that all
patches should be installed and tested in a development or test environment before those
patches are pushed to all pertinent computers requiring the patch. Why? Because, while it's
a logical assumption that software vendors would never release a patch that might break
existing software, it's not difficult to find examples of patches that addressed one or more
existing issues while also breaking other features or functionality.
Patch admins must also be mindful of the fact that not every software vendor tests its
patches against every possible other piece of software running in IT. The only thing worse
than not applying a patch that could leave software vulnerable, is to install a patch that
breaks other pieces of software in the process.
The cost of automating patch management
The cost of purchasing automated patch management software is as varied as the many
patch management products on the market. There are freeware versions of patch
management products, there are standalone products for those with a budget but also on a
budget, and there is patch management software that is integrated within an all-
encompassing monitoring and management software suite.
There is no one right answer for which type of enterprise patch management software is the
best fit for a specific situation. Each method of patch management software licensing
represents a different price point and feature set that will help guide organizations to the
best product within their budget.
Part of the patch management product comparison process is to examine the tradeoffs
between price and features, then settling on a short list of the software that most closely
aligns with your requirements and budget. Although patch management automates a
previously manual process, organizations must still include costs for administration of their
chosen patch management product. Even automated patch management products
require trained expertise to configure and maintain the product.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Automated patch management: Scenario #1
The first business-case scenario for the automated patch management process will usually
come to bear when the total number of employees plus the total number of servers reaches
approximately 50. At that point, IT can no longer risk relying on employees to keep their OS
and locally installed applications up to date with manual patching performed by IT and end
users.
Though there can obviously be substantial costs to implementing a comprehensive patch

management infrastructure, for enterprise-scale companies in tightly regulated industries the
benefits of automated patch management likely far outweigh those costs.
In addition, manually patching servers starts to become a very time-consuming process. A

quick cost-benefit analysis (see sidebar) reveals that IT can no longer afford to take the time
to manually install patches on servers and other infrastructure devices once they have more
than 10 to 15 servers or other patchable devices in their infrastructure environment.
A similar cost-benefit analysis should be performed for patching end-user computers. Many
companies utilize inventory software that can produce reports showing which OSes and
applications are installed on end-user computers and servers, and the version and patching
level of all installed software. These reports can also help smaller IT shops monitor how well
end-users are maintaining their patch levels.
In addition to larger enterprises, automated patch management tools are an excellent

option in smaller companies where end-user patching falls short, leaving the company
vulnerable to malware and possible legal ramifications.
Automated patch management: Scenario #2
The second business case scenario for automated patch management -- and this one is a
strong one -- is of particular interest for a publicly-traded company subject to federal rules
and regulations such as SOX, FRCP and HIPAA. In these cases, ongoing patch management
may be a statutory requirement, with significant criminal and civil penalties possible for the
CEO and CFO if these regulations are violated.
In addition to meeting regulatory requirements, patching may be a required process in order

to protect the organization from potential lawsuits from customers, suppliers and others who
may be financially damaged by patch-related issues in the corporate network. If a company
fails to keep its computers and other devices up to date with the recommended patch
distributions, it can be exposed to lawsuits from customers, partners and other related parties.
For instance, if malware is introduced to an organization's IT infrastructure via a bug for which
a fix has already been distributed, and should that malware lead to the accidental or
purposeful release of personally identifiable information (PII) that damages others, the
ensuing civil liabilities can be substantial and ongoing.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consider this business case to be based on mitigating the risk of financial and legal
consequences for not keeping an organization's infrastructure and end-user computers
patched. Regardless of the cost of automated patch management tools, it is important to
bear in mind what's at stake for publicly held companies that don't have a verifiable,
repeatable automated patch management process. Depending on a company's specific
operating environment and governance compliance guidelines, a great deal of time,
money and customer goodwill is at stake should a patch-related incident cause harm to
your corporate stakeholders. The cost to implement automated patch management tools is
typically relatively minor compared to the cost of defending the company from legal or
regulatory actions spurred by lack of patch management.
Patch management software: a cost-benefit analysis
Deciding whether or not a patch management product is right for your company involves a
series of questions about the various seen and unseen costs of implementing patching
software, balanced by the perceived benefits of those costs. Here are a few important
considerations for a patch management cost/benefit analysis:
 How much does the patching software itself cost for the initial licenses and ongoing
product maintenance and support?
 What are the costs of the underlying infrastructure required to run patching software?
Will the patching software run locally in a company data center or on a cloud-based
platform?
 What are the personnel requirements, including man hours and training, required to
implement and administer patching software? Do those requirements change if the
software is cloud-based versus locally hosted within an existing company
infrastructure?
 Will automated patch management conserve personnel commitments and time
compared to a manual patching strategy?
 Are there any other financial considerations unique to your company that could also
affect the true costs of manual patching versus automated patching? For instance, if
your company is subject to governance and compliance regulations that expose
your company to civil liability for not keeping patches up to date, be sure to include
that in your analysis.
Best practices for automated patch management
The following are a number or practical best practices and tips to take into account while
researching, evaluating, procuring and deploying automated patch management tools to
protect an organization's digital assets:
Know your infrastructure and end-user device patching status at all times, either via manual
inventory of a representative sample of devices, or via an automated software inventorying
tool that can detect and track software versions and patch levels for OSes and applications.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Perform a cost/benefit analysis to determine whether or not the company can justify
deploying an automated patch management process. For example, for a small software
development startup that hasn't yet begun to sell its product publicly -- and has only a
handful of employees -- the risk of a patch-related incident causing damage to customers or
employees is relatively low. Conversely, a software development company that has a
publicly released product that collects and stores customer credit card information is highly
susceptible to a patch-related incident causing the exposure of PII, which could be
devastating to the company's established customer goodwill and bottom line.
Be sure to test any prospective patch management product live in the organization's
environment to ensure it is compatible with existing computers and devices. That testing
needs to include some subset of the company's production computers to ensure
compatibility in its environment. Most patch management vendors offer a 30-day trial of their
software running live in an environment.
Consider a cloud-based patch management product such as Kaseya or Panarama9, where

the patch management vendor is responsible for keeping the patch management cloud
infrastructure running at peak performance. Cloud-based patch management products also
ensure the patch management software running in the cloud is always up to date.
Enterprise-scale companies with existing software suites with patch management capabilities
can leverage that existing infrastructure to support locally installed and managed patch
management software, recognizing that managing locally installed patching software must
be administered on a regular basis.
Mobile device access to corporate networks, including both corporate-provided mobile

devices as well as BYOD, is now allowed by a wide proliferation of companies. Be sure the
organization's patch management policy also includes a methodology and capability for
patching mobile devices, such as tablets and smartphones that connect to the corporate
network.
Always test patches in a sandbox environment to ensure compatibility with OSes and
applications once a patch management product has been chosen. If an organization does
not have the available infrastructure to host such a sandbox environment, it should be aware
that many of the large cloud-hosting companies such as Amazon Web Services and
Microsoft Azure offer free or very low-cost virtual server hosting options that are perfect for
small-scale testbeds and sandboxes.
To patch or not to patch
Patch management is a frequently overlooked aspect of digital asset management for

many companies, but regulatory requirements make patch management a mandatory IT
activity for many organizations today. Keeping application software and OSes up to date
with the most recent patches also protects a company from malware attacks due to unseen
bugs and other vulnerabilities. In addition, automated patch management assures that
tmg.edu.au | 1300 888 TMG (1300 888 864)
deployed software includes the latest features, functionality and capabilities offered by the
application or OS vendor.
Though we strongly recommend automated patch management for all companies, those
strict government regulations applying to publicly traded companies take patch
management from the recommended category to the mandatory category.
Activity 16
Red Hat has Satellite (see screenshot below). What is the purpose of this application?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 16
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configure network authentication, authorisation and accounting services to log and prevent
unauthorised access to the server
Authentication, authorization, and accounting (AAA) is a term for a framework for

intelligently controlling access to computer resources, enforcing policies, auditing usage,
and providing the information necessary to bill for services. These combined processes are
considered important for effective network management and security.
As the first process, authentication provides a way of identifying a user, typically by having
the user enter a valid user name and valid password before access is granted. The process of
authentication is based on each user having a unique set of criteria for gaining access. The
AAA server compares a user's authentication credentials with other user credentials stored in
a database. If the credentials match, the user is granted access to the network. If the
credentials are at variance, authentication fails and network access is denied.
Following authentication, a user must gain authorization for doing certain tasks. After logging
into a system, for instance, the user may try to issue commands. The authorization process
determines whether the user has the authority to issue such commands. Simply put,
authorization is the process of enforcing policies: determining what types or qualities of
activities, resources, or services a user is permitted. Usually, authorization occurs within the
context of authentication. Once you have authenticated a user, they may be authorized for
different types of access or activity.
The final plank in the AAA framework is accounting, which measures the resources a user
consumes during access. This can include the amount of system time or the amount of data
a user has sent and/or received during a session. Accounting is carried out by logging of
session statistics and usage information and is used for authorization control, billing, trend
analysis, resource utilization, and capacity planning activities.
Authentication, authorization, and accounting services are often provided by a dedicated

AAA server, a program that performs these functions. A current standard by which network
access servers interface with the AAA server is the Remote Authentication Dial-In User Service
(RADIUS).
Core Components of AAA
 Client: The client is the device attempting to access the network. The client either
authenticates itself, or it acts as a proxy to authenticate the user.
 Policy Enforcement Point (Authenticator): The Policy Enforcement Point (PEP) is
someÃ‚Âtimes called the authenticator or dial-in server, VPN concentrator, firewall,
gateway General Packet Radio Service (GPRS) support node, Ethernet switch,
wireless access point, or an inline security gateway. The PEP is responsible for
enforcing the terms of a client's access. This enforcement varies based on the
capabilities of the PEP and is discussed later in this article.
 Policy Information Point: The Policy Information Point (PIP) is a repository of information
to help make the access decision. It could be a database of device IDs, a user
tmg.edu.au | 1300 888 TMG (1300 888 864)
directory such as the Lightweight Directory Access Protocol (LDAP), a one-time

password (OTP) token server, or any other system that houses data relevant to a
device or user access request.
 Policy Decision Point (AAA Server): The Policy Decision Point (PDP) is the brain of the
AAA decision. It collects the access request from the client through the PEP. It also
queries any relevant PIPs to gather the information it needs to make the access
decision. The PDP, as its name implies, is the entity that makes the final decision
around network access. It also can send specific authorizations back to the PEP that
apply settings or constraints to the client's network traffic.
 Accounting and Reporting System: Whether on a dedicated system or built as part of
a PDP, tracking use of the network with accounting is one of the best features of
AAA. With all forms of network access now offering controlled access, the AAA
service can tell you who got on the network, from where, and what that person was
granted access to.
It is important to note that the preceding categories are logical containers of functions and
not necessarily dedicated physical devices. Often elements are combined, such as PEP with
PDP, and PDP with PIP.
Example AAA Flow
Now that we have examined the components of a AAA solution, walking through a typical
use case will help cement our understanding of the role that each entity plays. Figure 1
shows an example of a client attempting to gain access to the network.
Figure 1: A Client Connects to a AAA-Protected Network
1. The client attempts to connect to the network, is challenged for identity information,
and sends this information to the PEP. In this example, let's assume the client is a
tmg.edu.au | 1300 888 TMG (1300 888 864)
laptop with a worker attempting to access an organization's VPN from a remote

location. Additionally, we'll assume this is a valid, permitted use of the network.
2. The PEP sends the collected identity information to the PDP. In some cases (discussed
in part two of this article), the PEP cannot see the specific identity information
provided but instead relays the information directly to the PDP.
3. The PDP queries any configured PIPs for information about the client and validates
that the credential provided by the client is valid. In this example, the PIP is an LDAP
directory.
4. The PIP returns a success or failure message from the credential validation step and
sends additional information about the client to the PDP for evaluation. This
information could include the role of the user, the home location for the user, and so
on.
5. The PDP evaluates information learned about the client through the client, PEP, and
PIP; the role of the PEP and PIP that serviced the request; and any contextual
information (such as time of day) against its configured policies. Based on this
information, the PDP makes an authorization decision.
6. The PDP sends the PEP the authentication result and any authorizations specific to the
client. These authorizations trigger specific PEP actions to apply to the client. For
example, the authorization data might trigger specific Access Control Lists (ACLs) or IP
pool assignments for the client.
7. The PDP also sends the result of this transaction to the accounting system.
8. The PEP applies the authorization profile learned from the PDP and sends the
"authentication successful" message to the client. The PEP can also be configured to
send accounting information on this new connection to the accounting and
reporting system.
9. The client accesses the production network through the PEP.
Elements of Authentication
When performing authentication, numerous elements can be evaluated before a PDP

reaches its access decision. At a high level, these elements can be broken down into three
categories: the principal itself (the user, device, or service requesting access), the credential
the principal submits (shared key, one-time password, digital certificate, or biometric
credential), and the contextual information describing the transaction (location, time of day,
software state, and so on).
 Principal: The principal is the entity requesting authorization. It is generally some

combination of user, device, or service. When concerned with a user, the PIP can
provide attributes about the user such as role or group affiliations, job title, e-mail
address, physical address, and so on. In specific applications, it can include much
more granular information. For example, a higher-education facility might be
interested in knowing a student's class schedule when servicing the student's
authentication request. When the principal is a device, the same thinking applies. The
PIP can inform the PDP if the device is a managed asset, what its basic usage
parameters are, and so on. User and device authentication can be carried out
sequentially for the same transaction, often involving device authentication first and
tmg.edu.au | 1300 888 TMG (1300 888 864)
then user authentication. Lastly, a service such as a network management process

can authenticate. In this case, the service almost always looks like a user to the AAA
infrastructure and is handled accordingly.
 Credential: The next element the PDP considers is the credential the user or device
submits as proof of identity. There are four main types of credentials: shared key
(password), one-time password (OTP), digital certificate, and biometric credential.
This section examines each of these types. The first and most widely used form of
credential is the shared key, typically a user password. AAA deployments that use
shared keys can be subdivided based on the protocol the system uses to verify the
password, including the Password Authentication Protocol (PAP) [4], Challenge
Handshake Authentication Protocol (CHAP) [5], and Microsoft CHAP Extensions (MS-
CHAP) Versions 1 [6] and 2 [7]. PAP authentication is a plaintext authentication
method that is not recommended for use in security-sensitive environments.
However, many newer protocols provide a secure transport for PAP, making its use in
AAA still quite common. Some of these methods are discussed in part two of this
article. CHAP improves on the security of PAP by not sending the password in the
clear but rather a challenge based on a hash of the password. MS-CHAP is a
Microsoft extension to CHAP that tunes things a little bit for Microsoft environments.
Version 2 of MS-CHAP addresses security weaknesses in Version 1. MS-CHAPv2 is quite
common today in Microsoft environments. CHAP in all its forms is vulnerable to
dictionary attacks because even if a hash cannot be decrypted, common passwords
can be guessed and those hash values can be computed.
A second, also widely used credential type is the OTP. At login time, users refer to their
personal token to get the OTP they will type in. The token is generally provided in
hardware or software form. Tokens are designed to generate seemingly random
passwords that are synchronized with a token server acting as a PIP. The OTP can be
sent in the clear because it is used only once; after a configurable time (for example,
30 seconds) a new password is generated. When an OTP is combined with a Personal
Identification Number (PIN), two-factor authentication is achieved because the client
needs to have something (the token) and know something (the PIN).
The third type of credential is the digital certificate. Digital certificates can be stored
either locally on the client or on some sort of removable device such as a smartcard.
A full discussion of asymmetric-key cryptography is outside the scope of this article,
but at a high level, certificates work by asserting the identity of their bearer by having
the certificate signed by a trusted Certificate Authority (CA). CAs can be external
entities such as a government or commercial enterÃ‚Âprise or they can be internal to
a given organization. The certificate itself can be freely distributed, because the only
way it can be validated as belonging to the rightful owner is in combination with the
private key. Because they reside on the client, certificates are most often used to
authenticate a physical entity rather than an individual. However, smartcards are
changing this paradigm by enabling users to take their digital certificate (and private
keys) with them, thereby disassociating the certificate from the machine itself. Similar
to an OTP without a PIN, a digital certificate or smartcard alone does not provide
tmg.edu.au | 1300 888 TMG (1300 888 864)
two-factor authentication. Certificate deployments, particularly smartcards, are

addressing this problem by requiring a PIN to unlock access to the credential.
The fourth and least widely deployed type of credential is the biometric credential.
Biometrics [12] ignores something you have and something you know and instead
focus on something you are. Fingerprint scanners, iris scanners, and facial recognition
are all forms of biometric authentication. Because biometrics is the newest form of
credential, it is currently experiencing heightened anticipation among users
regarding potential applications—and also scrutiny for potential weaknesses.
 Contextual: The last element the PDP typically considers in its authentication decision
is the contextual information associated with the AAA request, including the network
and physical location of the request, the type of access provided by the PEP, the
time of day, and potentially other elements such as network load, security threat
level, and so on. A relatively new entrant into this set of contextual information is
client device posture, typically discussed under the rubric of Network Access Control
(NAC). NAC or posture checks examine the software state of the client before it
connects. NAC data allows the PDP to assess the degree of risk posed by the
connecting client before granting the client access to the network. For example, if a
system is running an out-of-date operating system, has no current security
applications running, or otherwise exhibits high-risk behavior, it may not be granted
access to the network. NAC will be discussed in more detail in part two of this article.
Authorization Approaches
At its core, authorization means determining what a client is allowed to do on the network.
However, the granularity of this authorization is only as good as the sophistication of the PDP
and the enforcement capabilities of the PEP. This section examines the authorization options
for network AAA, including Layer 2 segmentation, Layer 3 filtering, and Layer 7 entitlements. It
closes with an examination of some of the challenges encountered when sending or
"provisioning" the authorizations from the PDP to the PEP.
 Null Authorization (Authentication Only): Strangely the most common authorization in

AAA is no authorization at all. After the authentication event occurs, the client is
immediately granted full access to the network. This characteristic is a holdover from
the original goal of remote-access AAA: to perform an authentication check that
simply determines whether the client should be trusted as if it were connected to the
organization's home network. Because these home networks employed no
segmentation or filtering within them, it was natural that remote-access techniques
such as dialup and VPN would likewise employ neither. Today however,
authentication is increasingly being used for all forms of network access, with a goal
of providing clients with network rights commensurate with their role in the
organization. This latter goal requires a strong authorization foundation through the
cooperation of the PDP and PEP.
 Layer 2 Segmentation: For wireless access points and Ethernet switches, the most
common form of authorization enforcement is Layer 2 segmentation, which works by
splitting the network into multiple logical segments, isolating certain classes of client
tmg.edu.au | 1300 888 TMG (1300 888 864)
from one another. This process is most typically achieved by deploying Virtual LANs
(VLANs), which separate the members of one VLAN from other VLANs in the same
Layer 2 network—even though the VLANs traverse the same physical network
infrastructure.
VLANs can be used to restrict access to specific resources by working in coordination

with VLAN-specific ACLs on Layer 3 devices upstream from the Layer 2 device. For
access points, a given wireless Service Set Identifier (SSID) can be associated with a
VLAN on the wired side of the access point. Multiprotocol Label Switching (MPLS) is
more commonly associated as a WAN transport, but there is nothing to prevent labels
for traffic based on AAA. More commonly, the client is associated with a VLAN and
the VLAN is associated with an MPLS label further into the infrastructure.
 Layer 3 Filtering: Layer 3 filtering authorizes access to resources through ACLs
configured on Layer 3 devices (routers, Ethernet switches, security gateways, and so
on). These ACLs (which generally encompass Layer 4 of the OSI stack as well) can
enforce authorizations to a range of hosts, specific hosts, or services on those hosts. As
mentioned earlier, Layer 3 filtering can be combined with Layer 2 segmentation to
provide aggregate authorizations for an entire VLAN. This filtering is the most common
technique on network infrastructure devices, whereas security gateways tend to
apply ACLs to specific clients. Additionally, technologies such as IP Security (IPsec) [8]
provide a Layer 3 filtering capability by allowing only certain types of traffic to travel
through the VPN tunnel.
 Layer 7 Entitlements: Increasingly, security gateways are able to go beyond Layer 3
and 4 filtering and are starting to become application-aware, meaning that the
authorizations handed from the PDP to the PEP can be very granular, focusing on the
specific applications that are needed rather than broader filters based on segments
or hosts on the network. Because this technology is still relatively new, there are no
standards yet to make this interaction work transparently. As a result, most granular
application filters are written on the PEP itself in order to allow the PDP to trigger a
preexisting profile on the PEP. These sorts of provisioning challenges are discussed
further in the next section.
 Provisioning Challenges: In AAA parlance, the term "provisioning" refers to
communicating a user's session rights and constraints to the PEP so that the PEP can
grant and enforce these permissions. One of the most difficult aspects of provisioning
access rights on a PEP is communicating the decision of the PDP in a format the PEP
can understand. This fact is one of the reasons that many PEPs come with a
lightweight PDP. This approach solves the narrow problem for that PEP but creates
management challenges when coordinating network AAA across a broader
enterprise, because the enterprise AAA policies must be implemented individually on
each unique type of PEP on the network. Because RADIUS is the most commonly used
network AAA protocol, it is natural to communicate the PDP decision using that
protocol. RADIUS attributes such as the "filter-id" allow the PDP to trigger a preexisting
filter on the PEP
In addition, many PEP vendors support Vendor Specific Attributes (VSAs) in RADIUS to
enable the PDP to speak the language of the PEP more specifically. This process
tmg.edu.au | 1300 888 TMG (1300 888 864)
works well but creates a significant amount of work on the PDP to enable it to
translate the policy result and correctly communicate it to each type of PEP. Another
option soon to be sanctioned by the standards bodies is an extension to RADIUS that
enables the sending of standard IP ACLs using RADIUS attributes [9].
One further option for provisioning is through the Simple Network Management
Protocol (SNMP), which is typically used to assign Layer 2 ports to VLANs or to enable
or disable interfaces. This process can work, but remember that the version of SNMP
typically in deployment is still SNMPv2c, which is User Datagram Protocol (UDP)-based
(connectionless) and unencrypted. Therefore, the SNMP traffic is prone to packet loss
when links are congested or devices are busy, thereby requiring costly application
layer retransmission schemes. It also means the transmissions themselves are
vulnerable to inspection or modification. These attributes make SNMP generally a
poor choice for security-sensitive tasks. RADIUS also uses UDP, but supports basic
retransmission as part of the protocol.
Another provisioning method used today is standard Secure Shell (SSH) Protocol or
HTTPS-based configuration. This method manages a device through standard
administrative interfaces to set enforcement techniques. Although this method gives
the PDP full access to the features of the PEP, it is very difficult to coordinate the
dynamic aspects of the client AAA event with the static elements of the running
configuration of the PEP. Finally, new protocols are emerging to make provisioning
easier. NETCONF [10] is an Extensible Markup Language (XML)-based protocol
designed as a replacement for network management applications connecting to
devices over the command-line interface (CLI).
As this section has shown, there are numerous approaches to authorization in AAA. Each PEP
has its own capabilities, but the challenge for a diverse network is to consistently authorize
clients, regardless of the given PEP they access the network through.
Accounting Techniques
Accounting is an increasingly critical step in the overall AAA process. Regulatory controls are
starting to mandate better auditing of network access. The last stage of AAA, accounting
simply records which clients accessed the network, what they were granted access to, and
when they disconnected from the network. Accounting has always been widely used in the
Internet Service Provide (ISP) space because auditing network access is the basis for billing
ISP customers. Increasingly, accounting is being used as a way to correlate client attribute
information (username, IP address, etc.) with actions and events on the network.
This correlation can make other systems that are not user-aware more intelligent in the
security decisions that they make. For example, a network Intrusion Detection System (IDS)
can learn a lot about the behavior of a given IP address. However, when that information is
correlated with the user assigned to that IP address—and the permissions that user should
have—the relevance of the IDS data increases dramatically.
tmg.edu.au | 1300 888 TMG (1300 888 864)
One of the design considerations of accounting systems is that, given the centralized nature
of audit and the decentralized nature of access, they are generally out-of-band with the
client's normal communications. This makes them excellent resources to refer to when the
network administrator wants to know when the client connected and what the client was
granted access to. However, their out-of-band nature makes them poor resources for
determining what the client actually did while connected to the network. This information
can be learned by the network, as mentioned earlier, by coordinating the AAA accounting
information with the rest of the network enforcement and monitoring systems.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configuring RADIUS
To configure RADIUS authentication for your network, you start by opening the NPS
management console that’s shown in Figure 1, which you’ll find in the administrative tools
menu after you’ve installed the NPS server role (as we showed you in a previous installment
in this article series).
You can use either the Standard or Advanced Configuration option to configure RADIUS.
The Standard Configuration option will start a configuration wizard, so we’ll look at it first.
Figure 1
You have two choices under the Standard Configuration option:
 You can configure a RADIUS server for dial-up or VPN connections

 You can configure a RADIUS server for 802.1x wireless or wired connection
In our scenario, we’ll configure the RADIUS server for dial-up or VPN connections, since we
have already set up a VPN server. Click the Configure VPN or Dial-up link.
On the next page, you’ll be asked to select the type of connection (Dial-up or VPN). In this
case, we’ll choose Virtual Private Network (VPN) Connections. NPS will be able to
authenticate and authorize the connection requests from VPN clients. On this page, you
tmg.edu.au | 1300 888 TMG (1300 888 864)
also need to provide a name to be used as part of the policy name for policies that the
wizard will create. This dialog box is shown in Figure 2.
Figure 2
On the next page, you need to add the RADIUS clients. These are the network access
servers that will forward connection requests from remote clients to the RADIUS server. Click
the ADD button, shown in Figure 3,to add your RADIUS clients and fill in the dialog box fields
asking for a friendly name, IP address or DNS, and a shared secret template if you’re using
one. You can also manually type a shared secret if you prefer, or you can have a shared
secret automatically generated, by clicking the appropriate button.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 3
On the following page of the wizard, you will configure the authentication method(s) to be
used by RADIUS. The default selection is Microsoft Encrypted Authentication version 2 (MS-
CHAPv2). You can also select MS-CHAP if the operating systems on your network do not
support MS-CHAPv2, but this is not recommended as it’s not as secure. The other choice is
to use the Extensible Authentication Protocol (EAP). If you choose EAP, you can use a
secured password (EAP-MSCHAPv2) or Microsoft Protected EAP (PEAP), or you can use a
smart card or certificate. This is the most secure authentication method. Note that you can
select multiple protocols, as shown in Figure 4.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4
The next step is to select user groups, the members of which will be allowed or denied
access to the network access servers through the VPN, based on the network policy
Access Permission setting. Click the Add button to add user groups. This will invoke a dialog
box through which you can select the groups, as shown in Figure 5.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 5
The next page in the wizard allows you to configure IPv4 and IPv6 IP filters to control what
types of network traffic can be sent and received through the VPN server. You can
configure input and output filters for each IP protocol here, as you can see in Figure 6. We
discussed input and output filters in a previous installment of this article series.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 6
The next page of the wizard is where you specify the encryption settings to determine the
minimum encryption strength(s) that will be allowed between the access clients and the
network access servers.
Your choices include:
 Basic encryption (MPPE 40 bit)

 Strong encryption (MPPE 56 bit)
 Strongest encryption (MPPE 128 bit)
You can select multiple encryption strengths and the server and clients will negotiate the
strongest supported by both. All strengths are allowed by default, as shown in Figure 7. You
can unchecked the lower strength encryption choices to force connections only when the
more secure encryption can be supported. If you uncheck all of the boxes, the traffic from
the clients to the network access server will not be encrypted, so this is not recommended.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 7
The next page of the wizard asks you to specify a realm name, which is part of the user
name that the ISP uses to identify the connection requests that route to this server. It is not
required that you specify a realm name; you can leave this field blank if you don’t know
the realm name or don’t care about it. If you do specify a realm name, you should leave
the box checked that says Before authentication, remove the realm name form the user
name, as shown in Figure 8, so Windows will be able to authenticate the connection
request.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 8
This completes the wizard and when you click Finish on the next page, it will automatically
create two policies: a network policy and a connection request policy. The names of
these policies will use the name that you assigned earlier in the wizard. The RADIUS clients
will also be configured. There is a link labeled Configuration Details by which you can see a
summary of the configuration settings (it opens in your default web browser) so you can
review it and make sure everything is right before you click the Finish button.
After you click Finish, the new policies will show up in the Policies nodes of the NPS
management console, under Connect Request Policies and Network Policies, as you can
see in Figure 9.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 9
Your RADIUS clients that you configured through the wizard will show up in the RADIUS
Clients node.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 17
What is the purpose of authorisation on a network?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Securing a Linux System
Before You Install a System
The facilities provided by the installation system offer the most convenient way to configure
many of the features described here. For this reason, consider how you will secure and
update the system before you install it. Popular distributions install tools to update individual
systems by default.
If you will be installing more than one copy of a distribution, carry out a trial run, and use the
test installation to create an answer file that contains the settings for the final systems. The
installation software may take the setup options from your answer file, rather than prompting
you for every option. This enables you to decide the best possible options at your leisure, and
then have the installation software automatically use them.
Many distributions support answer files, and include tools to generate them. Debian uses the
term preseeding. The equivalent facility for Red Hat Enterprise and Fedora is known as
Kickstart.
Keeping Your System Updated
Update Your System Immediately After Installation: Software development moves so rapidly
that updates will exist for any operating system. To ensure that your system does not include
any known vulnerability, run the update process immediately after you have completed the
installation.
To carry out a full system update on Linux systems, follow the instructions in the
documentation. Each distribution provides specific tools for installing and updating software.
If you manually install software without using the supplied tools, you must check and update
those products yourself. To ensure that you have the latest versions of any manually installed
software, subscribe to email or RSS services that notify you when new versions are released.
Most software providers now offer such an announcement service for their products.
Enabling BIOS Security
Always use the security options in your computer BIOS (Basic Input/Output System). These
ensure that attackers may not quickly circumvent security by booting the computer with
another operating system:
1. Set the BIOS, or firmware, of your machine to boot from the drive that holds the Linux
system.
2. Disable booting from all other devices.
3. Enable the option in the BIOS to require a password for access to BIOS settings.
4. For portable systems, enable the option in the BIOS to require a password to boot the
machine.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Securing the GRUB Boot Loader
If you specify a password for GRUB (Grand Unified Bootloader), users must unlock the boot
menu and give the correct password before they may access the maintenance utilities built
in to the boot loader. You can also restrict access to the options on the menu itself, so that
users may only choose particular boot options after successfully unlocking.
The best time to set a boot loader password is during the installation process. Some
distributions also include tools to configure GRUB after installation. On all systems you may set
a password for GRUB with the following procedure:
1. In a terminal window, type /sbin/grub-md5-crypt.

2. When prompted, specify the password that you wish to use.
3. Note the MD5 hash that appears. This holds the password that you specified in an
encoded format.
4. Add the following line to the file /boot/grub/menu.lst:
password --md5 MD5-HASH
Replace MD5-HASH with the hash that you generated with grub-md5-crypt.
You must have root access to edit /boot/grub/menu.lst.
Reboot the system for the change to take effect.
To protect a specific boot configuration, add the lock option after the title. For example:
title Fedora (2.6.17-1.2157_FC5)

lock
root (hd0,0)
kernel /vmlinuz-2.6.17-1.2157_FC5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Debian and Ubuntu systems enable you to lock all of the recovery mode and custom boot
options with one setting. To lock all non-standard boot options, edit /etc/boot/grub/menu.lst,
and change lockalternative to true. Leave the comment marker in place.
# lockalternative=true
Then run the update-grub utility to update the active boot configuration:
# update-grub
Refer to the project Web site for more information about the facilities provided by GRUB:
http://www.gnu.org/software/grub/
tmg.edu.au | 1300 888 TMG (1300 888 864)
Enabling Password Security for Recovery Mode
Recovery mode (or single-user mode) boots the system without activating a network
connection, using only the minimum processes needed to allow a login. If the sulogin facility
is enabled on the system, users must enter the root password in order to access a system that
is in recovery mode. Debian systems enable sulogin by default.
To enable password security for single-user mode on other Linux systems, add the following
line to the file /etc/inittab:
~~:S:wait:/sbin/sulogin
You must have root access to edit /etc/inittab.
This change takes effect the next time that you boot the system.
Ubuntu and sulogin: Ubuntu configures sulogin by default, but actually permits unrestricted
access with single-user mode unless you have enabled the root account. To enhance the
security of Ubuntu systems, consider locking the non-standard boot options, as described in
the previous section.
Disabling Special Key Combinations
Linux systems support several key combinations that may override the normal running of the
system. The well-known Ctrl-Alt-Delete key combination triggers a graceful shutdown of the
system. Linux also supports Magic SysRq, a set of key combinations that send instructions
directly to the kernel.
These enable users to control an unresponsive system, but may also be used by malicious
users to bring down a running system. For this reason, you may wish to disable them on
publicly accessible computers.
Disabling Ctrl-Alt-Delete
To disable the Ctrl-Alt-Delete key combination, add a comment marker (#) to the start of the
relevant line in /etc/inittab:
# ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
You must have root access to edit /etc/inittab.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Disabling SysRq
To disable the Magic SysRq facility, add this to /etc/sysctl.conf:
kernel/sysrq=0
You must have root access to edit /etc/sysctl.conf.
Managing User Accounts
Create one account per user, with a strong password. If possible, configure your systems to
use the accounts provided by a centralized authentication service, rather than creating
accounts on each system. Centralized services enable you to enforce strong passwords and
other security policies across the systems on the network. They also ensure that the logins for
your systems remain current and easy to verify.
The section below explains strong passwords.
Manage Local Accounts with the Tools Provided: Use the tools supplied with your distribution
to manage the local accounts, rather than editing the account files directly. Errors in these
files may prevent you from logging in to the system.
Each user should log in to the system with their own account. A user may cause configuration
and data files in their own home directory to be damaged or deleted, but they may not
modify system files, nor may they alter the files in the home directories of others. Use su or
sudo to safely obtain root privileges when carrying out administrative tasks.
Avoid Generic and Shared Accounts
Automated cracking programs use standard and generic account names like admin and
guest for their login attempts. Only enable remote access to uniquely identifiable accounts
that are associated with a named individual.
Understanding Strong Passwords
Automated password cracking programs include multiple dictionaries for one or more
languages, in order to be able to identify any password that is based on a standard word or
name. Password cracking programs are also often able to identify a word even if characters
are substituted.
 Use Phrases Instead of Single Words: To produce a long and memorable password,
use a phrase instead of a single word.
 Create Unique Passwords. Avoid using the same password or key for more than one
system.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Use a combination of upper case letters, lower case letters, numbers, and
punctuation. This ensures that your passwords may not be easily identified.
 Use at least 8 characters in your passwords. Each character in the password multiplies
the difficulty of guessing the complete password. Avoid passwords with less than 6
characters, as these are too weak.
Obsolete Software May Limit Password Length: Modern systems support extremely long
passwords. Obsolete software may reject or truncate passwords that are longer than 8
characters.
Configure PAM (Pluggable Authentication Modules) modules to enforce password

requirements for local user accounts on the system.
If possible, use authentication keys rather than passwords for SSH (Secure SHell) remote
access. SSH keys are considerably more complex than passwords. By default, the OpenSSH
service on Linux prompts the user for a password if they do not provide a key, but you may
configure it to require keys for all logins.
The well-known tool John the Ripper demonstrates how vulnerable weak passwords are to
modern cracking techniques. Administrators commonly use this utility to audit the accounts
on their network. For more information about the capabilities of John the Ripper, refer to the
Web site:
http://www.openwall.com/john/
Securing Home Directories on Debian and Ubuntu
Debian and Ubuntu systems create world-readable home directories by default. This allows
users on a shared system to conveniently access files in each other’s home directories. In
many cases, administrators may wish to change this default.
To disable world-readable home directories, enter this command in a terminal window:
# dpkg-reconfigure adduser
Choose No to world-readable home directories. This changes the default permissions for
home directories from 0755 to 0751.
Existing Home Directories Remain Accessible: This change affects how adduser creates new
home directories. Existing home directories remain accessible.
Managing Access to Administrator Privileges (root)
To perform administrative tasks at the command-line, log in to your system with a standard
user account, and use either su or sudo to run commands in a terminal with the privileges of
tmg.edu.au | 1300 888 TMG (1300 888 864)
the root account. The graphical administrative tools supplied with your Linux distribution
automatically prompt for a password as required.
Ubuntu systems lock the root account, and configure sudo by default. Most distributions
require you to manually configure sudo.
root Access with su
The su utility enables you to acquire the privileges of another account. By default, su switches
your terminal session to root privileges. This means that all of the commands executed in that
session run with unrestricted access to the system, until the session is restored back to normal
status. If possible, use su -c or sudo to run individual commands with root access, rather
switching the privileges of the whole session.
To give a terminal session root privileges and settings with su, enter the following command:
su -
Specify the root password when prompted.
To return the session to unprivileged status, type exit:
exit
To use su to run a command with root privileges, type su -c, followed by the command.
Enclose the command in quotes. For example, this line runs the command /sbin/shutdown -h
now:
su -c '/sbin/shutdown -h now'
Specify the root password when prompted.
Read the info manual on your system for details of the su command:
info su
Controlled root Access with sudo
If you have several administrators for a system, configure sudo to enable each administrator
to carry out commands with root access.
Only One Administrator Needs the root Password: Authorized sudo users use their own
password to run root commands with sudo. For this reason, only one administrator needs to
know the root password for a system that runs sudo.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Administrators may also use the sudo facility to grant groups or user accounts root privileges
for specific applications. This enables you to delegate certain administrative tasks without
giving either the root password, or unrestricted access to root privileges.
More importantly, sudo logs all of the commands that it executes to /var/log/auth.log. This
ensures that every administrative command is recorded, and may be traced to an individual
user account. In the event of a system problem this audit trail may provide valuable
information.
As a convenience, sudo prompts a user for their password only once within a certain time
period. If the user runs runs sudo again within that period the command is automatically
authorized. By default, the period is 15 minutes.
Use visudo to Edit the sudo Configuration: Use the visudo command to edit the configuration
file for sudo. This utility ensures that the modified configuration is consistent before it becomes
active.
To grant full root access to all members of the admin group, use the following line in the sudo
configuration file:
%admin ALL = (ALL) ALL
Once you configure privileges for groups you may manage access to sudo by adding or
removing accounts from the designated groups.
To grant an individual account full root access, specify the name of the account. This line
grants full privileges to the exampleuser account:
exampleuser ALL = (ALL) ALL
To use sudo to run a command with root privileges, type sudo, followed by the command.
For example, this line runs the command /sbin/shutdown -h now:
sudo /sbin/shutdown -h now
If prompted, enter the password for your account.
To edit a file with root privileges, type sudoedit, followed by the name of the file. For
example, to edit /etc/nsswitch.conf, enter the following:
sudoedit /etc/nsswitch.conf
If prompted, enter the password for your account.
Use gksu for Graphical Applications: To run graphical applications in the GNOME desktop
environment with the sudo facilities, use the gksu utility.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Refer to the man page for sudoers for detailed information on configuring the sudo facility.
The man page for sudo explains how to use the sudo utility.
man sudoers
man sudo
Setting Login Restrictions
Linux systems use the pam_unix or pam_unix2 module to authenticate users with the local
account files. Many distributions also enable some other PAM modules by default. For
example, Red Hat Enterprise Linux and Fedora systems use pam_cracklib by default. Debian
and Ubuntu systems automatically use pam_motd for the login service.
The relevant PAM modules for account security are:
 pam_cracklib - enforces password quality checks

 pam_limits - enforces resource limits on user accounts
 pam_motd - prints a message on the screen after the user logs in
 pam_tally - enforces a maximum number of unsuccessful login attempts
 pam_time - limits access to services by time
Debian Supplies Cracklib Separately: Debian provides pam_cracklib as a separate package:

libpam-cracklib. Install either pam_cracklib or the stronger pam_passwdqc module. The
package libpam-passwdqc provides pam_passwdqc.
Configuring PAM
On many distributions, the PAM configuration file for each service imports settings from a
central set of files. This enables you to configure PAM for all of the services on the system by
editing the main configuration.
Red Hat and Fedora provide /etc/pam.d/system-auth for central PAM configuration.
Debian-based systems use four files:
 /etc/pam.d/common-account - modules that restrict access by valid users

 /etc/pam.d/common-auth - modules that handle user authentication and group
membership
 /etc/pam.d/common-password - modules that handle password changes
 /etc/pam.d/common-session - modules that set up facilities for valid users during the
login process
tmg.edu.au | 1300 888 TMG (1300 888 864)
Ensuring Strong Passwords with PAM
Red Hat and Fedora systems include the pam_cracklib password complexity check in their
default configuration. For Debian and Ubuntu systems, install either pam_cracklib or
pam_passwdqc.
Use pam_cracklib to provide simple password checks. To ensure extremely strong passwords,
install pam_passwdqc. Non-technical users may find the default settings for pam_passwdqc
too demanding.
To enable password complexity checks on Debian and Ubuntu systems with pam_passwdqc,
use these settings in /etc/pam.d/common-password:
password required pam_unix.so use_authtok md5

password required pam_passwdqc.so
Alternatively, to enable checks with pam_cracklib, use these settings in

/etc/pam.d/common-password:
password required pam_unix.so use_authtok md5

password required pam_cracklib.so retry=1 minlen=6 difok=3
Enforcing Resource Limits with PAM
The pam_limits module applies the hardware resource limits set in /etc/security/limits.conf to
each account that logs in. Set resource limits to ensure that users cannot slow down or crash
the system by running programs that consume all of the available computer resources.
root is Exempt From All Resource Limits: Resource limits do not apply to the root account, or
any program that it runs.
Several distributions enable pam_limits by default for the login services, but define no limits in
the supplied configuration file. The site administrator sets appropriate limits for the system.
Red Hat, Fedora, Debian and Ubuntu enable pam_limits by default.
For other distributions, add the following line to the PAM configuration files for cron, login, ssh
and su:
session required pam_limits.so
The relevant files are:
 /etc/pam.d/cron
 /etc/pam.d/login
 /etc/pam.d/ssh
 /etc/pam.d/su
tmg.edu.au | 1300 888 TMG (1300 888 864)
Once pam_limits is active, edit the configuration file to define resource limits. The
configuration file explains the format. Below is a simple configuration:
# —- Resource Limits for an Application Server —-

#
1. “Soft” limits are defaults that users may change.

2. “Hard” limits may not be altered by users.
#
3. Note that the root account is always exempt from all resource
limits.
# Disable core dumps
* hard core 0
# Restrict sessions to 20Mb each
* hard rss 20000
# Maximum of 20 processes per user
* hard nproc 20
# Allow upto 2 logins per user, in case a session crashes
* - maxlogins 2
Resource limits take effect for logins immediately after the configuration file is saved.
The cpu Limit Eventually Terminates Sessions: The cpu limit defines the maximum amount of
CPU time that a session may use before it is forced to log out.
Protecting Network Services from Attack
Every system connected to the Internet is eventually checked by automated cracking

programs. Such programs frequently run on systems that have already been compromised
by crackers, or infected with a virus. Compromised systems constantly check thousands of
Internet addresses for active systems that use specific network services, and attack those
that they find. These attacks may be defeated by simple countermeasures.
Security is Built on Good Decisions: You may significantly reduce the number of issues that
you deal with, simply by carefully selecting the services and Web applications that run on
your systems.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Selecting Services
Expose the minimum number of services possible. Certain types of service are inherently
unsafe, and if possible you should avoid them:
 FTP: Use SSH or HTTP (with WebDAV for write access) instead
 NFS: Use version 4 between trusted systems on private networks, and avoid previous
versions
 NIS: Use LDAP with SSL or Kerberos instead
 The “r” suite of utilities (e.g. rexec, rlogin): Superseded by SSH
 Telnet: Superseded by SSH
To block the installation of unsafe services on Debian and Ubuntu systems, add the harden-
servers package.
Use the forwarding features of SSH, or separate VPN (Virtual Private Networking) software, to
tunnel remote access to any unsafe services through more secure connections. For example,
you must protect syslog and VNC (Virtual Network Computing), as neither facility encrypts
their communications.
The popular DNS server BIND requires extra caution, due to a history of security problems. For
this reason Debian provides a package to run BIND in a chroot environment. Current versions
of Fedora and Red Hat Enterprise Linux automatically use SELinux (Security Enhanced Linux)
to restrict BIND. If you use BIND, ensure that your distribution uses version 9 rather than any
earlier version, and enable the distribution security features. Alternatively, use a different
Open Source DNS server, such as Dnsmasq, MaraDNS, or PowerDNS.
Choose Web Applications with Care
By their nature Web applications may be exposed to the public Internet, accept information
from remote systems, and often have access to valuable data. Research a Web application
carefully before you deploy it. Some applications have a history of security problems that
may stem from poor design or development practices.
For each application that you choose to run, apply all of the security recommendations that
the documentation describes. If you install a Web application manually, rather than from
packages provided by your distribution, subscribe to a relevant email or RSS service to
receive news of security alerts and product updates.
Configuring Services
Unless a particular service is intended for public or global access, configure it to only accept
connections from the specific networks or systems that should have access to it. For
information on how to secure a service, refer to the documentation for the product.
Although attackers may configure their systems to falsely claim to have another name or IP
address, access restrictions defeat casual attacks.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Remote Access to Email and Printers: By default, the email, logging, and printing services
provided by Linux distributions reject connections from remote systems. Only enable remote
access to these services if you intend the system to provide facilities for other systems.
You should not assume that every system on your network is trustworthy, nor should you
disable security features for internal clients. Many legitimate products exist that can
conveniently reach internal systems by traversing NAT, and bypass standard firewalls by using
HTTP. The spread of wireless access and laptops also mean that systems may be connected
to your network without actually being authorized or maintained.
In all cases, only provide remote users with write access to files or databases if it is necessary.
Certain services, like HTTP file transfer, provide read-only access by default. If a file sharing or
database service permits users to edit the data that it provides, ensure that access is
protected by key-based authentication or strong passwords.
Ensure That The Security Features are Enabled!
The OpenSSH service automatically encrypts all of the communications between SSH clients
and the server, as well as providing a means for clients to verify the identity of remote servers.
You must configure most other services to use a security facility for identification and
encryption. Use either SSH, Kerberos, or TLS (also known as SSL), as the product
documentation describes.
Apply New Updates Rapidly
Many attacks attempt to exploit known vulnerabilities in Web applications or network

services, and may be defeated by running current versions with a safe configuration.
Once a new vulnerability is known, providers modify their software to address the issue and
release a new version. Attackers also quickly begin to run automated tests for vulnerable
systems, in order to make use of the delay between the announcement of a vulnerability
and the application of updates.
To avoid becoming vulnerable, you must plan to apply important updates to your publicly
accessible systems within a period of hours, rather than days. Do not hesitate to restrict
access to non-critical services until they are updated. If a system becomes compromised it
may not only affect your own data, but that system could also be used to carry out attacks
on others.
Understand Firewalls and Their Limitations
The netfilter framework included in the Linux kernel restricts incoming and outgoing network
connections according to a set of rules that have been defined by the administrator.
Fedora, Mandriva, Red Hat, and SUSE automatically configure netfilter to act as a firewall,
and supply their own graphical configuration utilities. You must manually configure and
tmg.edu.au | 1300 888 TMG (1300 888 864)
enable the firewall on Debian and Ubuntu systems. Current releases of Ubuntu include a
command-line utility called ufw for firewall configuration.
You may also manage the firewall rules on any Linux system with the standard iptables and
ip6tables command-line utilities, or with third-party utilities such as Firestarter. If you decide to
use iptables, remember that it only configures restrictions for IP version 4 connections, and
that you will need to use ip6tables to setup rules for IP version 6 as well.
A correct firewall configuration blocks incoming connections to all services, except those
that should be available over the network, and all outgoing connections, except those
needed for clients to operate. Treat the firewall as a fail-safe measure to protect you against
human error, as no service should accept network connections unless it has been specifically
configured for the required purpose, and you should be aware of all of the network client
software installed on the system.
Once a service has been configured for remote connections then a firewall can only offer
two defenses: it can restrict access to ports based on the source, and it can rate-limit
connections to prevent attackers overloading the server. Whether you configure access
restrictions on the service or through the firewall is a matter of choice.
Configuring a Backup System
You must select a backup system that best matches your particular circumstances. The
programs listed here are widely-used and well maintained, but you may find other
applications that better suit your needs.
Popular Backup Software
The command-line tool rdiff-backup provides simple backup and recovery facilities:
http://www.nongnu.org/rdiff-backup/
This utility may backup to either local storage, or other systems over a network connection. To
further customize the backup process to your needs, write a script and add it as a scheduled
job for cron.
BackupPC enables you to backup multiple computers to a central server over the network,
and incorporates a Web interface for easy management:
http://backuppc.sourceforge.net/
Client computers may run Windows, Mac OS X, or any Linux distribution.
If you need advanced backup facilities for a larger network, use Bacula or Amanda. Both of
these provide a central backup service that may be accessed by multiple clients over a
network, and can manage tape media.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Database Backups Require Specialized Tools: Always use dedicated tools to backup your
LDAP and SQL databases. Simply copying the transaction logs and storage files for an active
database service may produce inconsistent data.
Configure backups to run automatically on a schedule. If you rely on manual backups you
may later find that you do not have copies of important versions of your files.
Important Files to Backup
Configuration files:
 /boot/grub/menu.lst - Boot loader menu configuration file

 /etc/ - Main directory for configuration files
 /var/backups/ - Backup copies of key files (Debian and Ubuntu only)
Log files:
 /var/log/ - Main directory for log files
Data files:
 /root/ - Home directory for the root account

 /home/ - Main directory for all user home directories
 /var/spool/mail/ - Directory that holds all mailboxes
 /var/www/ - Directory for the main Web site
Applications May Use Non-Standard Locations: Some applications may default to non-
standard locations for their configuration, data, or log files. Always check the locations of the
key files when you install a new application or service, especially if the software was not
provided by your distribution.
Enabling Email Reports
Automated processes on your Linux system use the email (SMTP) service to send reports to
the system administrator. If installed, the logwatch script sends an overall status report each
day at 4am. Fedora and Red Hat Enterprise Linux systems include logwatch by default.
Ubuntu Has No Email Service by Default: Ubuntu does not include an email service by
default. To enable system reports from an Ubuntu system, install the logwatch package, and
an email service of your choice. The nullmailer and postfix packages both provide efficient
and secure email services.
Follow the instructions below to configure the email service on your system to deliver these
messages to a remote email address, rather than a local mailbox:
Edit the file /etc/aliases. Change the line:
tmg.edu.au | 1300 888 TMG (1300 888 864)
root: root
Replace the second root with your email address. For example:
root: me@example.com
Save the file, and close the text editor.
You must have root access in order to edit the aliases file.
To update the email server configuration with the new alias, run the newaliases command.
# newaliases
The newaliases command requires root privileges.
Exim Does Not Require newaliases: The Exim mail service automatically registers changes to
the aliases file. You do not need to run the newaliases command on systems that use Exim as
their email service. Debian systems include Exim by default.
Restricting Task Scheduling
Current Linux systems include four mechanisms for users to schedule tasks. You may wish to
disable user access to these on your servers.
The task schedulers are:
 at - runs a task once, at a specific time in the future

 batch - runs a particular task when the system load drops below a specified value
 cron - runs tasks at specific times according to a schedule
 anacron - periodically runs specified tasks when the system is available
The atd Service Manages Both at and batch: The cron and anacron facilities each use a
separate service. Both at and batch both rely on the atd service.
Restricting Access to at and batch
All accounts listed in /etc/at.deny may not use the at and batch facilities. To block all user
access to these facilities, create an /etc/at.allow file:
# touch /etc/at.allow
If an /etc/at.allow file exists, then no user may access at or batch unless their account is
explicitly listed in that file. Each facility checks for an at.allow file before reading at.deny.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Restricting Access to cron
To restrict user access to cron, create a file called /etc/cron.allow. If this file exists, cron limits
access to specific users. Only those users listed in the file may schedule tasks with cron.
Use the touch command to create an empty cron.allow file:
# touch /etc/cron.allow
If a /etc/cron.deny file exists it provides the reverse of cron.allow. It enables all users to
access cron, except those whose usernames are listed in cron.deny.
Choose One Restriction File. To avoid confusion, use either a cron.allow file or a cron.deny
file, but not both.
Debian and Ubuntu do not provide either a cron.allow file or a cron.deny file. Fedora and
Red Hat Enterprise Linux systems include a cron.deny file by default.
Subscribing to Security Announcement Services
Distribution Announcement Services
Each distribution vendor notifies users of security issues through email announcements or RSS
feeds. For example, the Debian project announces all security issues on this dedicated
mailing list:
http://lists.debian.org/debian-security-announce/
To subscribe to email security announcements for Ubuntu distributions, visit this Web page:
http://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
Red Hat provide security updates and information to their customers through the Red Hat
Network service.
US-CERT Bulletins
US-CERT provide security advisories for all commonly used operating systems and software. If
you administer a range of systems, subscribe to the weekly Cyber Security Bulletin:
https://forms.us-cert.gov/maillists/
Adding Anti-Virus Software
Install anti-virus software if you provide network services for users that work on Microsoft
Windows systems, or regularly exchange files with unprotected Windows systems.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Your distribution may include packages for ClamAV software. ClamAV scans files for viruses
and malware, and may be used by applications and network services such as email servers.
The ClamAV project provide free updates for new malware as it is discovered.
The clamtk desktop virus scanner uses ClamAV:
http://clamtk.sourceforge.net/
Refer to the ClamAV project Website for more information on the ClamAV software:
http://www.clamav.net/
Several commercial vendors offer a range of anti-virus products for Linux systems. Refer to
their Web sites for details.
Additional Security Measures for Servers
These facilities provide specific defenses against attempts to compromise a server:
 Samhain - Host integrity monitoring for single systems and groups of servers
 Fail2Ban - Dynamically modifies system firewall rules to block attacks
Security Checklists
Securing the Boot Process
 Set the BIOS, or firmware, of your machine to boot from the drive that holds the Linux
system
 Disable booting from all other devices
 Enable the option in the BIOS to require a password for access to BIOS settings
 For portable systems, enable the option in the BIOS to require a password to boot the
machine
 Lock the GRUB boot loader by setting a password
 Ensure that access to single-user mode requires a password
Using Your System Safely
 Use strong passwords for your accounts

 Log in with a standard user account
 Perform administrative tasks that require root access with su, sudo, or the supplied
configuration tools
 Only install software or plug-ins from trusted sources
 Discard emails if you do not recognize the source
 Only keep or copy a file if you know the original source of that file
tmg.edu.au | 1300 888 TMG (1300 888 864)
Secure System Configuration
 Create one system account per active user

 Configure password complexity checking, to ensure strong passwords
 Set reasonable resource limits
 Enable email reports
 If a number of users require some form of administrative access, configure sudo rather
than distributing the root password
 Use SSH for remote access to the system
 If possible, require SSH keys rather than passwords for remote access
 Only enable additional network services if they are necessary
 If possible, configure services to allow connections only from specific IP addresses
that you know
 Only configure a network service to allow write access to files if it is necessary
 If you expect to receive infected files, install and configure anti-virus software
 Consider limiting access to task scheduling
Routine Security Tasks
Linux distributions include tools for all of the tasks below. Much of this work can, and should,
be automated. Human administrators must of course check that the scheduled scripts and
processes are operating correctly.
 Check your RSS and email subscriptions for relevant security announcements
 Update the system regularly
 If you install anti-virus software, update the virus signature data at least once a day
 Create backups of data and configuration files
 Lock user accounts that are no longer required
 Deactivate any network services that are no longer required
 Check the log files for unusual activity
Configure basic service security and access control lists to limit access to authorised users,
groups or networks
Many organizations today include computers running both UNIX and Microsoft® Windows®
operating systems in their network environments. Ensuring the security of information located
on either type of network infrastructure requires validating every user's identity and specifying
which network data each user can access.
Currently, most organizations with heterogeneous environments maintain separate systems

for Windows and UNIX to authenticate a user's identity when the user logs on to the network
(or authenticates to an application server) and to determine which network resources an
authenticated user is authorized to access. Maintaining these separate systems incurs
administrative overhead and requires users to log on separately to each system or service
that they want to access.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The goal of this guide is to demonstrate that it is both feasible and advantageous to
integrate Windows and UNIX more closely than the basic interoperation at the network level
that is enabled by the fact that both are TCP/IP-based operating systems. Specifically, this
guide describes how to integrate Windows and UNIX at the level of authentication
(determining the identity of a user before allowing the user to log on) and, optionally,
authorization (determining whether an authenticated user is authorized to access a given
resource on the network).
This chapter provides a brief introduction to the following topics:
 The central role of the Active Directory® directory service in identity and access
management.
 Overview of authentication and authorization.
 End states for integrating Windows and UNIX.
In this guide, an end state defines a specific set of authentication and authorization—or
authentication only—interoperability options for a network of computers running the
Windows or UNIX operating systems. Five end state options are defined in this guide:
 End State 1. UNIX clients use Active Directory Kerberos for authentication but continue
to use a UNIX-based store for authorization.
 End State 2. UNIX clients use Active Directory Kerberos for authentication and use
Active Directory Lightweight Directory Access Protocol (LDAP) for authorization.
 End State 3. UNIX clients use Active Directory LDAP for authentication but continue to
use a UNIX-based store for authorization.
 End State 4. UNIX clients use Active Directory LDAP for both authentication and
authorization.
 End State 5. A cross-realm trust is established between UNIX-based Kerberos and
Active Directory–based Kerberos in UNIX and Windows infrastructures that remain
separate. Windows and UNIX clients each authenticate to their own Kerberos Key
Distribution Center (KDC) and (if the trust is two-way) can then access resources
hosted by computers on the other side.
More than one technology solution is available to implement a given end state. This guide
describes two commercial solutions for End State 2; multiple custom or "do-it-yourself"
solutions for End States 1, 2, 3, and 4; and one custom solution for End State 5.
For links to in-depth information about the topics summarized in this overview, see "For More
Information" at the end of this chapter.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Central Role of Active Directory in Identity and Access Management
On a computer network, a directory is both a data store used for storing and organizing
information about objects on a computer network and the directory service used for
locating and retrieving the information about those network objects from the data store.
Industry-wide directory service standards were developed, in part, to enable interoperability
among vendors of different computer operating systems.
Active Directory was introduced with Microsoft Windows 2000 Server as an integral part of
the server operating system and was enhanced in Windows Server™ 2003. Two core services
that Active Directory provides are:
 Directory services. Active Directory stores user, group, computer, and much other
information about a network.
 Security services. Active Directory enables clients to retrieve information from its data
store in order to provide services such as authentication and authorization.
Active Directory uses a hierarchical structure—including forests, sites, domains, and

organizational units (OUs) as well as the user, group, and computer accounts stored in those
containers—to hold information about network objects. In addition to user, group, and
computer accounts, network objects include servers, applications, shared folders (network
shares), printers, domains, security policies that specify which resources a user or computer is
allowed (or not allowed) to access, and other entities included in your network infrastructure.
Like any directory service, Active Directory makes the network information that it stores
available to authorized administrators, users, and applications.
One of the ways in which Active Directory integrates the identity of network objects with
network security is by managing logon authentication as well as authorization to network
resources. Active Directory is designed to be capable of authenticating user identity and
authorizing or blocking user access to network resources for users of computers that run not
only Windows operating systems but also operating systems other than Windows. This guide
shows you how to extend the use of Active Directory as the centralized store for identity,
authentication, and authorization information to UNIX-based and Linux-based computers.
The following figure depicts some of the ways in which Active Directory plays a central role
for a network environment.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 1.1. Active Directory's central role in supporting a network infrastructure
Services that Active Directory provides to the network as a whole include:
 Domain controller. For Microsoft Windows 2000 Server and Windows Server 2003,
Active Directory runs only on domain controllers; any Windows-based server that does
not run Active Directory is not a domain controller. Domain controllers store domain-
wide directory data (such as system security policies and user authentication data)
and manage user-domain interactions, including user logon processes,
authentication, and directory searches.
 Global catalog. The first domain controller installed in a Windows forest is an Active
Directory global catalog, and each multi-domain forest must have at least one
global catalog. The global catalog contains a replica of every object in Active
Directory but only a small number of each object's attributes. The attributes in the
global catalog are those most frequently used in search operations (such as a user’s
first and last names and logon names) and those required to locate a full replica of
the object.
 LDAP. LDAP stores user accounts centrally in a single repository and provides directory
services, authorization, and, optionally, authentication. Active Directory supports
LDAP version 2 (v2) and LDAP version 3 (v3) and acts as the LDAP directory service for
a Windows-based network.
 Kerberos protocol. Kerberos provides highly secure logon and network service
authentication, letting users sign on once and then transparently access network
resources without being prompted repeatedly for user name and password. Active
tmg.edu.au | 1300 888 TMG (1300 888 864)
Directory supports Kerberos version 5 (v5) and acts as the Kerberos service for a
Windows-based network.
 Group Policy. Group Policy configuration settings stored in Group Policy objects
(GPOs) enable policy-based administration. Administrators can apply policy settings
to computer and user objects, controlling each object's registry, NTFS security, audit
and security policy, software installation, logon and logoff scripts, folder redirection,
and Internet Explorer settings. An administrator can update thousands of computers
or users by changing a single GPO.
 Integration with DNS. Active Directory clients typically use DNS to locate domain
controllers. The integration of Active Directory with the Domain Name System (DNS) is
a central feature introduced with the advent of Active Directory in the Windows 2000
Server operating system. DNS domains and Active Directory domains can and often
do use identical domain names for their respective namespaces. If this is the case,
the DNS and Active Directory namespaces share an identical hierarchical domain
structure; however, each namespace stores different data and therefore manages
different objects. DNS stores its zones and resource records. Active Directory stores its
domains and domain objects. Thus, even when the DNS and Active Directory
namespaces have an identical structure, the DNS host record that represents a
specific computer in a DNS zone is in a different namespace than the Active
Directory domain computer account object that represents the same computer.
When the DNS and Active Directory namespaces have an identical structure, a
Kerberos realm (used in End State 5) is a DNS domain whose name is shown, by
convention, in uppercase letters; thus, the example.com domain is the
EXAMPLE.COM realm. On the other hand, if DNS and Active Directory do not share
an identical structure, the example.com domain might be the MYKDC.LOCAL realm.
Alternatively, in some organizations, the DNS namespace and the Active Directory
namespace do not use an identical structure.
 Integration with key infrastructure services. In addition to its integration with DNS,
Active Directory is also integrated with other key infrastructure services, such as
Certificate Services, File and Print Services, and Remote Access Service.
 Integration with key business applications. Active Directory is integrated with such
business applications as Microsoft Exchange Server, SQL Server™, and Internet
Information Services (IIS).
 Interoperability. Active Directory supports interoperability with clients that run
operating systems other than Windows and that use directory services other than
Active Directory.
This guide focuses on enabling integration between UNIX and Active Directory by migrating
UNIX user data to Active Directory (End States 1–4) or by establishing a cross-realm trust
between UNIX and Windows infrastructures that remain autonomous (End State 5).
Integrating your UNIX or Linux infrastructure with your Windows infrastructure by using Active
Directory as the common centralized, scalable, and distributed directory service brings the
combined benefits of Active Directory to your integrated environment.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Each of the interoperability solutions in this guide ends with a section (for the Quest Software
VAS product or the Centrify DirectControl product) or chapter (for the custom solutions)
about how you can evolve your chosen solution beyond authentication and authorization.
After you have a stable end state solution in place, you can extend your solution to take full
advantage of Active Directory as the central directory with a single identity infrastructure for
computers running UNIX and Linux as well as Windows.
Overview of Authentication and Authorization
Authentication and authorization—both integral components of identity and access

management—are separate security mechanisms that work together to help ensure network
security:
 Authentication. Verifying that a user, computer, or service (such as an application

provided on a network server) is the entity that it claims to be. Authentication is an
important part of identity management.
Users, computers, and services that can be authenticated when they log on to a
network or, after logon, when they authenticate to a network service, are known
collectively as principals, security principals, or digital identities.
 Authorization. Determining which actions an authenticated principal is authorized to

perform on the network. The tasks required to control authorization are also referred
to as access management.
Data about principals that specifies which network objects a principal is authorized to
access and what level of access is allowed is kept in a repository called an
authorization store.
Colloquially, the relationship between authentication and authorization might be

summarized as "Now that I know who you are, here's what you can do."
This section provides a brief overview of each of the following topics:
 Authentication and authorization mechanisms.

 Kerberos and LDAP.
 UNIX authentication and authorization.
 Windows authentication and authorization.
Authentication and Authorization Mechanisms
Some methods used by Windows and UNIX for authentication and authorization have
evolved in isolation from each other. Other methods are based on standard, platform-
independent protocols that both Windows and UNIX can use.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The following sections describe the authentication and authorization mechanisms available
in Windows and UNIX.
Logon Authentication
Authenticating the identity of users who want to log on to a computer on a network is an

important part of network security. Windows and UNIX can use the logon authentication
mechanisms listed in the following table.
Table 1.1. Windows and UNIX Logon Authentication Mechanisms
Windows Logon UNIX Logon Authentication

Authentication
 Kerberos v5 (default)  /etc/passwd, /etc/shadow (default)
 Kerberos v5, including:
Windows Server 2003, o MIT Kerberos, available at
Windows 2000 Server, http://web.mit.edu/kerberos/www/
and Windows XP use o Native UNIX or Linux operating system
Active Directory– Kerberos
based Kerberos v5 o Heimdal Kerberos, available at
authentication by http://www.pdc.kth.se/heimdal/ (not
default. included in the solutions in this guide)
 LDAP-compatible directories, including:
 LDAP v2 and LDAP v3 o iPlanet Directory Server, now owned by Sun
Microsystems
Although Kerberos is  Network Information Service (NIS), NIS+
the default  PKI certificates
authentication  Smart cards
method in an Active
Directory domain, it is Note For UNIX or Linux operating systems that support
also possible to use pluggable authentication modules (PAM), all of the
Active Directory LDAP nondefault UNIX-based authentication methods are
to authenticate enabled through PAM. The Solaris and Red Hat operating
clients. systems used in this guide support PAM. (For more
information about PAM, see "Using PAM" later in this
 Public key chapter.)
infrastructure (PKI)
with certificates and
public and private
keys
Active Directory
(which is fully
compliant with RFC
1510 that defines
Kerberos
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows Logon UNIX Logon Authentication

Authentication
authentication)
extends RFC 1510 to
support public key
authentication.
 Smart cards
 NTLM (pre–Active
Directory)
Authentication
protocol for Microsoft
Windows NT® 4.0 or
earlier networks, for
Windows Workgroups,
and for mixed
domains in which
Windows Server 2003
or Windows 2000
Server domain
controllers must
authenticate
computers running
Windows NT.
Authentication mechanisms can be used singly or in combination. For example, a smart card
logon typically also requires a password.
Application Authentication
In the context of network environment security, authentication refers not only to the process
of validating the identity of a user when the user logs on to a network computer but also to
the identity validation that occurs between a client and a server. For example, if Kerberos v5
authentication is the authentication method in use on your network, application
authentication refers to the process of mutual validation that takes place between client
and server when the user logged on to the client attempts to connect to an application
hosted by the server. The client and server must verify each other's identity before the client
can access the network resource residing on the server.
If mutual authentication between client and server is successful (and if the user is authorized
to access the resource on that server), the user can connect to the network resource without
being prompted for a user name and password. This capability, when a user types a user
name and password to authenticate to the network at logon and can then connect to
various applications, is called single sign-on (sometimes abbreviated SSO). Single sign-on
tmg.edu.au | 1300 888 TMG (1300 888 864)
makes multiple applications and services available to the user over the network without the
user having to provide credentials more than once.
Authorization
Windows Server 2003, Windows 2000 Server, and Windows XP use Active Directory–based
authorization. Active Directory and UNIX can use the authorization stores listed in the
following table.
Table 1.2. Windows and UNIX Authorization Stores
Windows Authorization UNIX Authorization

Active Directory LDAP  /etc/passwd and /etc/group (default)
 LDAP-compatible directories (such as iPlanet)
 NIS, NIS+
Kerberos and LDAP
Most implementations of UNIX and the Active Directory service in Windows Server 2003,
Windows 2000 Server, and Windows XP can use Kerberos and LDAP to provide secure,
centralized authentication for identified users and to determine if an authenticated user is
authorized to access a specific network resource.
Both Kerberos and LDAP are platform-independent TCP/IP-based IETF standards, and both
are client/server protocols. The following sections describe these protocols independently of
any specific implementation.
Kerberos
Kerberos is a network authentication protocol that enables secure logon by individuals to a

computer network and enables secure authentication by a client computer to a server
hosting a network resource. The Kerberos IETF standard was originally developed at the
Massachusetts Institute of Technology (MIT) to provide strong authentication for a TCP/IP-
based client/server network. The primary purpose of Kerberos is to authenticate two
principals to each other and to establish a cryptographic key that the two can use to secure
any messages they exchange with each other. Each client and server shares a secret key
known only to it and to the KDC; knowledge of this key serves as proof of a computer's
identity.
Kerberos authentication involves three types of entities:
 Kerberos clients. Users, computers (workstations or servers), or applications that

require authentication to connect to a network or to a resource on the network.
 Kerberos servers. Servers that provide a network resource that clients need.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Kerberos Key Distribution Center (KDC). The KDC service that maintains a database
with account information for all principals (users, groups, computers, or services) in its
Kerberos realm.
On a Windows network, a Kerberos realm is the equivalent of an Active Directory

domain, and the KDC is an Active Directory service. As explained earlier, by
convention, a realm name is the DNS domain name converted to uppercase. For
example, in a Windows network, the example.com Active Directory domain is the
Kerberos realm EXAMPLE.COM.
Kerberos authentication requires host name resolution because, to locate a Kerberos server,
a client needs the IP address of a Kerberos server in its domain. In most enterprises, including
Windows and many UNIX implementations, host name resolution is done by using DNS.
Alternatives to DNS for resolving a host name to its corresponding IP address include hosts
files and LDAP.
The Kerberos KDC provides two services as a single process:
 Authentication Service (AS). The AS authenticates a user and issues a ticket-granting

ticket (TGT) that the client uses to request a service ticket:
o TGT. A TGT enables the AS to safely transport the requester's credentials to the
ticket-granting service (TGS). A TGT, which is sometimes called "a Ticket to Get
Tickets" as a mnemonic device, typically has a default lifetime of 10 hours.
o Service ticket. A service ticket is a credential presented by a client to a
network service when the client authenticates to that service.
 Ticket-Granting Service (TGS). The TGS issues service tickets for network services based
on the TGT issued to a client. The service tickets issued by the TGS to clients let clients
authenticate to other services on the network. After logon, when a client wants to
authenticate to a network service, it must contact the TGS, present a TGT, and ask for
a service ticket for that network service.
For a depiction of this process on a Windows-based network, see "Active Directory Kerberos"
later in this chapter.
For a list of resources about Kerberos, see "For More Information" at the end of this chapter.
LDAP
The Lightweight Directory Access Protocol (LDAP) is a network protocol designed for querying
directory services and modifying data in a directory store. The LDAP IETF standard provides
access to a directory service on a TCP/IP-based client/server network. The LDAP standard
specifies a protocol for communicating between LDAP clients and servers but leaves the
implementation details for LDAP servers to the vendors who develop LDAP products. An LDAP
client connects to an LDAP server, issues a query, receives a response, and disconnects from
the server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
LDAP defines how to query an existing directory, how to refer to an entity in the directory,
how to describe the characteristics of an entity, and the security features that control access
to the entities within the directory. LDAP, which updates the older X.500 Directory Access
Protocol (DAP), is designed to store information hierarchically. An LDAP directory is structured
as a tree of entities; each entity consists of named attributes; and each attribute can contain
certain types of values. LDAP can use DNS names for structuring the top levels of the
hierarchy and typically uses entries representing network objects (for example, users, groups,
computers, or printers) at the lower levels of the hierarchy.
LDAP is extensible to enable the addition of new features (schema extension) while
maintaining backward compatibility. Currently, all major directory services conform to the
LDAP standard. Windows-based Active Directory and UNIX-based iPlanet are examples of
LDAP directories.
An LDAP directory is similar to a relational database but lacks some features of a relational
database and contains descriptive, attribute-based data that is read more often than it is
modified. A UNIX-based LDAP directory can be read by using the ldapsearch tool. Originally
a UNIX command-line tool for querying a UNIX-based LDAP directory, ldapsearch can also
be compiled for Windows and used to search for and display attributes of Active Directory
objects.
Clients and client applications use host name resolution to locate LDAP servers.
LDAP consists of four component models:
 Information model. The LDAP information model provides the data structures and
data types necessary to describe the attributes of an entry. The attributes and the
characteristics associated with an entry are defined in the entry's object classes. The
definition of object classes and attributes is held in the schema. An LDAP directory
requires the capability to search for specific entries by their attribute values.
 Naming model. The LDAP naming model defines how each entry can be referenced.
In an LDAP directory, entries are organized in a hierarchical tree called a Directory
Information Tree (DIT). Each node in the tree is an entry that can both store
information and be a container for other entries. There are two methods of
referencing an entry in the tree: using its relative distinguished name (RDN) or its
distinguished name (also known as DN). An RDN is unique within a directory, and a
distinguished name is globally unique.
 Functional model. The LDAP functional model is the method by which a directory
client can communicate with the directory. This is the LDAP protocol itself. LDAP
provides the following operations:
o Interrogation. This operation allows searching of the directory.
o Modification. This operation allows updating, adding, or deleting entries in the
directory.
o Authentication and control. This operation allows authenticating to the
directory (the bind operation).
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Security model. The LDAP security model provides methods for authenticating against
the directory and for authorizing client access control to the directory. There are two
components to the security model:
o Authentication by using LDAP binds. LDAP authentication involves an entity
binding to the LDAP server. The success of the bind operation is determined
by the acceptance or rejection of the entity's credentials. If the bind is
successful, the entity is authenticated; if it is unsuccessful, the entity is not
authenticated.
o Access control to objects in the directory. After a client is authenticated, the
client can use the LDAP directory only as defined by the directory's access
control lists (ACLs). Each network object has an ACL that identifies user
accounts, groups, and computers that are allowed (or denied) access to that
object. The implementation of ACLs in an LDAP directory is implementation-
dependent.
For information about using Active Directory LDAP for authorization or for authentication, see
"Active Directory LDAP" later in this chapter. For a list of resources about LDAP, see "For More
Information" at the end of this chapter.
UNIX Authentication and Authorization
Computers in a UNIX-based network can use the default authentication and authorization
mechanisms that are built in to UNIX or Linux operating systems. By default, these
mechanisms use text files for storing user and group configuration information. Alternatively, a
UNIX-based network can use other methods, including Kerberos and LDAP, for
authentication and authorization.
This section briefly summarizes file-based authentication and authorization for UNIX. It also
introduces pluggable authentication modules (PAM) that support non-file–based
authentication methods and the name service switch (NSS) that supports non–file-based
authorization methods.
For more in-depth information about UNIX, including file-based authentication and
authorization services, PAM, and NSS, see Appendix A: "Architectural Overview of UNIX and
Windows Authentication and Authorization."
File-based Authentication and Authorization
By default, UNIX operating systems use the following text files, located in the /etc directory,
for authentication and authorization:
 /etc/passwd
 /etc/shadow
 /etc/group
These files are used for authentication and authorization as follows:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Used for both authentication and authorization—/etc/passwd file. User account

information is stored in the /etc/passwd file. This file contains UNIX directory service
information (if no other directory service is used) and is used for authentication and
authorization as well as for other purposes.
The /etc/passwd file contains the information required by user programs to map user
names to user identification (UID) numbers. On a computer with no other
authentication sources, this file contains entries for all users of the computer. Even
when the file-based authentication method is augmented by other authentication
methods, this file is still essential for the correct operation of the system. The standard
format for each entry in the /etc/passwd file is:
username:password:uid:gid:gcos-field:home-dir:login-shell
These fields are defined as follows:
o username. The unique name of the user account on this computer.

o password. In most UNIX and Linux implementations, the password field
contains an asterisk (*) instead of the plaintext password. The actual password
is stored as a one-way hash in the /etc/shadow file (described later).
o uid. The user ID or unique ID number associated with the user account. This
number is assigned to files or directories to which the user has specific
permissions (as opposed to permissions assigned through membership in a
group). This is similar to the access control mechanisms used in Active
Directory and controlled with the user's logon name.
o gid. The group ID number of the primary group associated with a user
account. Like Active Directory, UNIX separates group membership into a
primary group and multiple secondary groups for a user. A user must be
associated with a primary group. The addition of secondary groups is optional.
Group IDs are assigned to files and directories to provide access control for
groups of users.
o gcos-field. The field named, for historical reasons, the General Electric
Comprehensive Operating System (GECOS) field, can be used to hold any
data. Traditionally, it holds the user's full name and might contain other data,
such as the user's phone number.
o home-dir. The full path and directory name of the user's home directory.
o login-shell. The program environment in which the user will operate upon
initial logon. Examples of this include /bin/csh (C Shell), /bin/sh (Bourne Shell),
and /bin/bash (Bourne Again Shell). All shells are not supported by all
operating systems.
 Used only for authentication—/etc/shadow file (optional). Encrypted passwords—that
is, a one-way hash of passwords—are stored in the /etc/shadow file, which was
developed to improve security for UNIX passwords. Because the /etc/passwd file must
be readable by everyone so that programs can map user names to UIDs, it is
relatively easy to carry out a brute force attack where all possible values are tried
one-by-one. You can resolve this problem by removing the encrypted password from
tmg.edu.au | 1300 888 TMG (1300 888 864)
/etc/passwd and storing it in /etc/shadow, which can only be read by the system
superuser (root). Use of the /etc/shadow file is optional, although some systems are
configured to use it by default. The standard format for the /etc/shadow file is:
username:password:lastchg:min:max:warn:inactive:expire:flag
o username. The user's logon name.

o password. An encrypted password.
o lastchg. A number indicating the last date that the password was modified.
o min. The minimum number of days required between password changes.
o max. The maximum number of days the password is valid.
o warn. The number of days before a user is warned that the password is about
to expire.
o inactive. The number of days of inactivity configured for that user.
o expire. A number indicating when the password will expire.
o flag. A number indicating the number of failed logon attempts.
The hashing algorithm used to create the one-way hash of the password that UNIX-
based computers store is, traditionally, a variant of the Data Encryption Standard
(DES); more recently, the hashing algorithm used is Message Digest 5 (MD5). In UNIX or
Linux environments, the crypt() application programming interface (API) is used to
compute the hash. This function takes a plaintext password and returns the
cryptographic hash text appropriate for use with this system.
 Used only for authorization—/etc/group file. Group information is stored in the

/etc/group file and is referenced in the passwd file by the GID field. The standard
format for the /etc/group file is:
groupname:password:gid:user-list
o groupname. The name of the group.

o password. If the password field is empty, no password is required.
o gid. The unique ID number associated with this group.
o user-list. A list of users allowed in the group (separated by commas).
File Access Mode
Authorization on UNIX-based computers is based on UIDs and GIDs and is provided at the
individual file level through access permissions (read, write, or execute) that are set on files,
directories, and programs. In UNIX, the file access mode refers to the default access
permissions that are applied to any file or directory when it is created. A user can use the
UNIX list (ls) command to list permissions for files and directories and (if the user is the owner or
tmg.edu.au | 1300 888 TMG (1300 888 864)
has root access to where the files or directory reside) can use the change mode (chmod)
command to assign or change the access mode of files or directories.
The read, write, and access permissions on a file or directory are represented in a UNIX
command-line shell by the letters r, w, and x. These permissions apply to three types of users,
as shown in the following table.
Table 1.3. Access Permissions
Owner Permissions Group Permissions Permissions for Everyone Else

rwx rwx rwx
For example, the following permissions indicate that the owner has read, write, and execute
permissions, the group has read and write permissions, and everyone else has only read
permissions:
rwxrw-r--
Authorization Data Retrieved When a UNIX User Logs On
When a user attempts to log on to a UNIX-based computer, the operating system must
retrieve both authentication data (user name and password) and authorization data for the
user. The UNIX authorization data defines the environment in which the user will operate and
the tools and files to which the user will have access, including whether the user has read,
write, or execute access to files and directories. A UNIX client must retrieve UNIX authorization
data in order to perform the access checks defined by the file access mode. The
authorization data needed for UNIX logon includes these UNIX attributes for the user: UID,
primary GID, home directory, and login shell. In addition to these attributes, the GECOS field
might also be required.
As described later in this chapter, authorization information for a UNIX client that participates
in an End State 2 or End State 4 solution is migrated to Active Directory and is retrieved from
Active Directory by the UNIX client when a solution for either of these end states is deployed.
However, Active Directory prior to the R2 release of Windows Server 2003 does not include
the UNIX attributes listed previously and thus, in most cases, configuring an End State 2 or End
State 4 solution requires extending the Active Directory schema so that it can store these
UNIX attributes.
Windows Server 2003 R2 includes support for RFC 2307 (which introduces the LDAP attributes
used to store UNIX or Linux user and group account information) as part of its default
installation. None of the solutions developed in this guide were tested with Windows Server
2003 R2.
The commercial solutions in this guide can each use a variety of methods to handle UNIX
authorization data in Active Directory. The custom solutions in this guide use Windows
Services for UNIX to handle UNIX authorization data.
tmg.edu.au | 1300 888 TMG (1300 888 864)
For more information about the UNIX file system, see Appendix A: "Architectural Overview of
UNIX and Windows Authentication and Authorization."
PAM and NSS Add Secure Authentication and Authorization to UNIX
The limited form of file-based authentication and authorization used by default in UNIX
environments has significant drawbacks. Approaches to overcome these limitations include
the following:
 PAM supports multiple authentication methods. Pluggable authentication modules

(PAM) can support a variety of authentication methods.
This capability underlies all of the authentication solutions described in this guide. It
allows UNIX-based computers to authenticate against Active Directory when either
Kerberos or LDAP is used for authentication.
 NSS supports multiple authorization methods. Name service switch (NSS) can support
a variety of mechanisms for looking up user and group information.
This capability underlies the authorization solutions described in this guide that allow
UNIX-based computers to retrieve authorization information from the Active Directory
LDAP store.
Both PAM and NSS are important for the technology solutions used to achieve most of the
end states described in this guide. Any solution that uses the Active Directory server for
authentication or authorization, or both, requires that you configure UNIX-based computers
participating in that solution to act as Active Directory clients. In part, this means configuring
the UNIX client to use PAM as part of an authentication solution and to use NSS as part of an
authorization solution.
Using PAM
The PAM service provides one interface that makes alternative authentication methods
available. Typically, UNIX users log on by supplying a unique user name and a password.
PAM allows user name and password authentication to be performed in ways that are more
secure than comparing strings in text files.
One important feature of the PAM configuration files is that rules defining the behavior of the
PAM modules can be stacked to combine the features of different PAM modules for a
specific task. The stack contains various mechanisms (modules) to perform the
authentication check. Each PAM module checks to see if the user name and password
match, using whatever approach is correct for that module. For example:
 An /etc/passwd PAM module looks for the user entry in the /etc/passwd file. If the
module finds the user entry, the module passes the user-supplied password through
the cryptographic API and checks it against the hash stored in /etc/shadow.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 A Kerberos PAM module uses the user-supplied user name and password to attempt
to retrieve a TGT for that user from the KDC. In this process, no form of the password
itself ever goes out over the network.
PAM also enables different methods of authentication that do not use user names and
passwords, such as retina scans and smart cards.
On systems that use PAM, the logon process and some tools that require user authentication
must be designed to use PAM for authentication and authorization. You must also configure
PAM to correctly handle the different authentication methods allowed on a particular
system. This configuration is comparatively simple because PAM provides a standard plug-in
interface that developers can write to.
In the authentication solutions for End States 1–4 included in this guide, PAM enables UNIX
clients to authenticate against Active Directory using either Kerberos or LDAP.
Note UNIX-based applications might or might not be designed to use PAM. In a Kerberos
environment, tools such as telnet, rlogin, and ftp can either use PAM for authentication on
the server side (the telnetd, krlogind, and ftpd services) or can use Kerberized versions of
these services that might or might not use PAM, depending on design and configuration.
Some tools that require user authentication might be capable of using Kerberos credentials
directly and therefore do not need PAM support. For example, the Kerberos kinit tool does
not use PAM. A user might use kinit to authenticate and receive a credential that can be
used to access an application.
Using NSS
The NSS architecture was developed to allow UNIX-based computers to use different
methods for obtaining configuration information, including identity and authorization
information. By using NSS, applications can, for example, obtain a user name by providing a
UID or obtain a list of group memberships by providing a GID. This process is independent of
the underlying mechanism performing the lookup.
The NSS architecture allows administrators to specify which data stores to query to obtain
information. NSS can be used to retrieve UNIX configuration information from the following
types of stores:
 Text files
 NIS
 NIS+
 DNS
 LDAP
tmg.edu.au | 1300 888 TMG (1300 888 864)
In the authorization solutions for End States 2 and 4 included in this guide, NSS enables UNIX
clients to use Active Directory LDAP as the authorization store.
Windows Authentication and Authorization
Active Directory stores user account information, authenticates users, and enforces security
policy for a Windows-based (or heterogeneous) network. Active Directory is integrated with
the Windows security subsystem through logon authentication and through access control to
objects in the directory. It ensures that only authenticated users can log on to the network
and that each network resource is available only to authorized users or to members of
authorized groups.
Active Directory uses the Kerberos protocol and LDAP as follows:
 Active Directory uses the Kerberos protocol for authentication (by default).
 Active Directory uses LDAP for authorization (by default).
 Active Directory can use LDAP for authentication (optionally).
Because Active Directory, by default, uses the Kerberos v5 protocol for authentication and
LDAP v3 for authorization, Active Directory is compatible with Kerberos v5 clients and LDAP v3
clients across all platforms, including UNIX and Linux. Together, Active Directory
authentication and authorization can provide a strong, easy-to-administer security system for
a mixed network.
Before you begin exploring how to extend Active Directory authentication and authorization
to UNIX users, it is helpful to first gain an understanding of how Active Directory uses the
Kerberos and LDAP protocols to handle identity authentication and access management.
This section includes the following topics:
 Active Directory Kerberos

 Active Directory LDAP
 Example: Kerberos and LDAP in a mixed environment
Active Directory Kerberos
By default, the Kerberos protocol is the gatekeeper that enables authentication to an Active
Directory network. Active Directory works with the Kerberos protocol to confirm the identity of
any user trying to log on to an Active Directory domain and lets authenticated users access
resources that they are authorized to access located anywhere on the network. Kerberos
single sign-on provides access to resources within an Active Directory domain and to
resources located in trusted domains.
On an Active Directory–based network, the Kerberos KDC is implemented as a domain

service, and each Active Directory domain controller runs the KDC service. Kerberos uses
Active Directory as its account database and uses a special kind of domain controller,
tmg.edu.au | 1300 888 TMG (1300 888 864)
called a global catalog, to direct referrals for a client to KDCs in other domains in the Active
Directory forest.
The Kerberos client component runs on all nondomain controller computers that are running
Windows Server 2003, Windows 2000 Server, or Windows XP and are joined to an Active
Directory domain. Every Active Directory domain controller acts as a KDC; therefore, a client
can find a KDC server by querying DNS (or by using a non-DNS method for host name
resolution) for the IP address of a domain controller in its domain.
RFC 1510, which defines Kerberos v5, specifies that the security principal name of a KDC is
krbtgt. Windows creates this account automatically whenever you run the Active Directory
Installation Wizard (the dcpromo command) to create a new domain. Clients address
messages to a domain's KDC by specifying both the service principal name (krbtgt) and the
name of the domain.
The Kerberos Ticket Process in Active Directory
Like other implementations of the Kerberos protocol, with Active Directory Kerberos, a user is
authenticated by successfully logging on, and then each subsequent client/server
connection requires that the client and server mutually authenticate each other. If the
authentication process is successful, a secure client/server session is established and the
client can then connect to the network service that the server provides.
When the user logs on, the client first contacts the KDC service running on the Active
Directory server to authenticate to the network (interactive logon), during which process the
client requests and the Kerberos authentication service (AS) returns a ticket-granting ticket
(TGT). The client can then request service tickets from the KDC for specific network resources
(network authentication). The client obtains a service ticket from the Ticket-Granting Service
(TGS) on the KDC during the latter part of the authentication process. Then, the client
presents this ticket to the network server with which the client wants to interact. A Kerberos
ticket represents the client's network credentials throughout the period of time that the client
is logged on to the network. The interaction is not bilateral between the client and the server
hosting the network resource to which the client wants to connect; instead, it is a trilateral
interaction between the client, the AS and TGS on the Active Directory KDC, and the server
hosting the network resource.
Illustration of the Kerberos Ticket Process in Active Directory
The following figure illustrates a simplified version of the steps that take place in the Kerberos
authentication process on an Active Directory network. Two exchanges—first between the
client and the AS on the Active Directory server to obtain the TGT and then between the
client and TGS to obtain the service ticket—are followed (if both exchanges succeed) by the
establishment of a session between the client and a server hosting the network resource that
the user wants to access. A new client/server session can be established later without
repeating the process, that is, without prompting the user to provide a password more than
once.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 1.2. Interactive logon followed by authenticating to a network resource
The following steps outline the Active Directory–based Kerberos single sign-on process
depicted in the figure.
1. When the user logs on to a computer, the Kerberos client component on the user's
workstation begins the logon authentication process to the KDC service on the Active
Directory domain controller by requesting a TGT from the AS component of the KDC.
2. If the AS successfully validates the user's identity, the AS provides a TGT to the user.
When Kerberos returns the TGT to the user, Windows includes information called a
Windows Privilege Attribute Certificate (PAC) in the Kerberos v5 authorization data
field. The Windows Local Security Authority (LSA) on the client uses the PAC to create
an access token. Windows will use the access token later to enforce access checking
when the client attempts to access network objects.
The LSA is a Windows subsystem service used for logon authentication. The access
token identifies the user to the network, identifies the groups to which the user
belongs, and identifies the user's rights to access specific network objects. Each
network object has an Access Control List (ACL) that identifies the users and groups
that are authorized to access that object as well as users or groups to which access is
denied.
Because Active Directory Kerberos provides the user rights data in the PAC, no call to
LDAP is needed to assemble the user data at logon. (This differs from the logon
process on a UNIX network that uses, for example, MIT Kerberos. In the UNIX case, the
system uses UNIX LDAP APIs to retrieve user authorization data at logon.)
tmg.edu.au | 1300 888 TMG (1300 888 864)
3. When the user attempts to contact a network resource for the first time, the Kerberos
client does not send a request directly to that resource. Instead, the client sends its
TGT to the TGS component of the KDC, requesting a service ticket specifically for the
network resource to which it wants to establish a connection.
4. The TGS returns a service ticket to the client for the network resource to which the
client wants to connect.
5. Next, the client sends the service ticket that it received from the KDC to the network
resource to which it wants to connect:
1. If mutual authentication occurs—that is, if the client successfully identifies itself
to the network resource, and if the network resource successfully identifies
itself to the client—the client can contact the resource.
2. After the user authenticates to the network and then authenticates to the
network resource, the user is allowed or blocked from actually accessing the
information available on the network resource based on a comparison of the
privileges in the user's access token with the permissions specified in the ACL
of the resource.
6. When the client wants to contact the same network resource again, it checks its
ticket cache for a service ticket valid for that network resource.
o If the client finds a valid ticket, it presents the ticket for access.
o If the ticket has expired, the client must return to the TGS to renew the out-of-
date ticket.
When the user on the client wants to access a different network resource, the client can use
the TGT that it received initially from the KDC for the network resource that the client
contacted earlier. The client submits the TGT to the TGS along with the name of the new
network resource that the client wants to contact. After validating the user's identity, the TGS
issues a service ticket for the new network resource, which the client stores in its system
cache and uses to contact the new network resource.
This process, which occurs repeatedly over the course of a typical day, is transparent to the
user because single sign-on means that the user is prompted for credentials only once, when
initially logging on to the computer.
The interaction between the KDC, the client, and the network resource when Kerberos
authentication takes place is actually much more complex than the simplified version just
described. For a list of resources about the Kerberos protocol, see "For More Information" at
the end of this chapter.
The secure user authentication provided by Kerberos v5 is tightly integrated with Windows
Active Directory; in addition, a growing number of other operating systems, including
implementations of UNIX and Linux, can use Kerberos. For this reason, the Kerberos standard
plays an increasing role in enabling computers running the Windows and UNIX or Linux
operating systems to interoperate with each other in a heterogeneous environment.
For information about using Active Directory Kerberos to authenticate UNIX clients, see "End
State 1: Use Active Directory Kerberos to Authenticate UNIX Clients" and see "End State 2: Use
tmg.edu.au | 1300 888 TMG (1300 888 864)
Active Directory Kerberos to Authenticate and Active Directory LDAP to Authorize UNIX
Clients" later in this chapter.
Active Directory LDAP
Active Directory implements an LDAP directory service that runs on Windows Server 2003 and
Windows 2000 Server domain controllers. Active Directory supports LDAP v2 (RFC 1777) and
LDAP v3 (defined in a series of IETF RFCs, which are summarized in RFC 3377). LDAP is the only
network protocol used to access information in Active Directory.
Because LDAP v3 is an industry standard, it can be used to provide interoperability with any
directory service that implements the LDAP protocol. Thus, Active Directory uses LDAP to
enable interoperability with other LDAP-compatible client applications. Given the
appropriate permission, you can use any LDAP-compatible client application to browse,
query, add, modify, or delete information in Active Directory.
Active Directory LDAP As Directory Store
Like any LDAP directory service, Active Directory stores and organizes information about a
network and allows administrators to manage access to network resources. LDAP is used to
add, modify, and delete information stored in Active Directory as well as to query and
retrieve data from Active Directory. LDAP defines how services or applications running on a
directory client can access a directory server (in Windows, a domain controller) and how the
client can perform directory operations and share directory data.
Active Directory stores information about directory objects in the Ntds.dit file located, by
default, in the C:\Windows\Ntds folder on each domain controller. The .dit extension stands
for directory information tree. To ensure availability, directory data is replicated to other
domain controllers in an Active Directory domain.
The Windows Server 2003 and Windows 2000 Server operating systems include several Active
Directory administrative tools, and a related Group Policy tool, to simplify directory service
administration. These tools are Microsoft Management Consoles (MMCs), which are
graphical user interface (GUI) consoles that host administrative tools called snap-ins:
 Active Directory Users and Computers snap-in. Used to create and manage Active
Directory accounts for users, groups, and computers, including passwords and other
configuration information. When you deploy an End State 1, 2, 3, or 4 solution, you
migrate UNIX accounts to Active Directory and can administer these accounts with
the Active Directory Users and Computers snap-in. The UNIX user acquires an Active
Directory account, and the UNIX client is joined to the Active Directory domain.
 Active Directory Domains and Trusts snap-in. Used to create and manage Active
Directory domains and trusts. For an End State 5 solution, you use this tool to configure
a trust between an Active Directory–based domain and a UNIX-based Kerberos
realm.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Active Directory Sites and Services snap-in. Used to create and manage Active
Directory sites.
 Active Directory Schema snap-in. Used to extend the Active Directory schema. If you
deploy an End State 2 or End State 4 solution (and if your domain controllers are
running an operating system earlier than Windows Server 2003 R2, which includes
UNIX attributes by default), most solutions included in this guide require that you
extend the Active Directory schema to include UNIX authorization data (UID, primary
GID, home directory, and UNIX login shell).
Although each solution in this guide (except for End State 5) requires that you extend
the Active Directory schema, you might or might not need to use the Active Directory
Schema snap-in to extend the schema. If, for example, you deploy one of the custom
solutions, which use Windows Services for UNIX, you do not need to use this tool to
extend the schema.
 Group Policy snap-in. Used to create and configure Group Policy objects (GPOs),
which contain policy settings and control settings for users, groups, and computers in
Active Directory sites, domains, and organizational units. The Group Policy snap-in is
accessed either through Active Directory Users and Computers or through Active
Directory Sites and Services (depending on which task you want to perform).
You can also use command-line tools to configure, manage, and troubleshoot Active
Directory.
Active Directory LDAP As an Authorization Mechanism
Active Directory works with the LDAP protocol to secure resources from unauthorized access.
For Windows clients, after a user account is authenticated and can therefore potentially
access a network object, the type of access actually granted to the user to access specific
network objects is determined by user rights, which are assigned to group (or user) accounts,
and by access control permissions, which are attached to the network objects that the user
wants to access.
In order for LDAP to be used by a UNIX client for authorization in an End State 2 or End State 4
solution, in the custom solutions included in this guide, the UNIX client must be configured to
use LDAP NSS. In the commercial solutions (Quest VAS or Centrify DirectControl), the UNIX
client must be configured to use the commercial product's NSS module.
For information about using Active Directory to authorize UNIX clients, see "End State 2: Use
Active Directory Kerberos to Authenticate and Active Directory LDAP to Authorize UNIX
Clients" and see "End State 4: Use Active Directory LDAP to Authenticate and Authorize UNIX
Clients" later in this chapter.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Active Directory LDAP As Authentication Mechanism
In addition to the role that Active Directory LDAP plays as a source of information used for
authorization, Active Directory LDAP can also, optionally, be used to authenticate users, such
as users on UNIX clients migrated from an environment that does not use Kerberos. Although,
by default, LDAP provides authorization and Kerberos provides authentication on a Windows-
based network, it is also possible for Active Directory LDAP to store authentication information
and thus to authenticate users as they log on and to enable clients to authenticate to a
network service.
Unlike Kerberos, which is designed as an authentication mechanism for users logging on and
for clients connecting to resources on network servers, LDAP authentication is designed
specifically for securing directory transactions. Using LDAP authentication for purposes other
than LDAP directory access (such as using it for logon authentication) might provide
performance that is slower than when Kerberos is used for authentication. This is because
LDAP directory services are not designed to handle large numbers of authentication
requests. Instead, LDAP is tuned to perform optimally when handling directory transactions.
In order for LDAP to be used by a UNIX client for logon or service authentication in an End
State 3 or End State 4 solution, the UNIX client must be configured to use LDAP PAM.
For information about using Active Directory to authenticate UNIX clients, see "End State 3:
Use Active Directory LDAP to Authenticate UNIX Clients" and "End State 4: Use Active
Directory LDAP to Authenticate and Authorize UNIX Clients" later in this chapter.
Example: Kerberos and LDAP in a Mixed Environment
The example in the following table compares the sequence, in real time, for client
authentication and authorization in one possible interoperability solution—in this case, an End
State 2 solution—that uses Active Directory to support both Windows-based and UNIX-based
computers. In this example, the user on the UNIX client, like the user on a Windows client, has
an account in Active Directory, uses Active Directory Kerberos for authentication, and uses
Active Directory LDAP for authorization.
As the user logs on, each client interacts with Kerberos and LDAP. This interaction achieves
the same end but differs in some of the details depending on whether the client computer is
running Windows or UNIX.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 1.4. Example: Comparison of Windows and UNIX Client Interaction with Kerberos and
LDAP in an End State 2 Solution
Windows Client UNIX Client

Start: Start:
Adam sits down at his Windows Eva sits down at her UNIX workstation and types
workstation and types his Active her Active Directory user name and password.
Directory user name and password.
PAM: PAM—mediates between UNIX client and
Kerberos:
[Not applicable—the Windows client
does not use PAM.] The UNIX client hands Eva's user name and
password to PAM.
PAM hands Eva's user name and password to the

PAM Kerberos module on the UNIX client.
Kerberos: Kerberos:
Kerberos on the Windows client The PAM Kerberos module on the UNIX client
contacts the KDC on the Active contacts the KDC on the Active Directory server to
Directory server to request a TGT from request a TGT from the AS component of the KDC.
the AS component of the KDC.
If the AS successfully validates Eva's identity, the AS
If the AS successfully validates returns a TGT to Eva's UNIX-based workstation.
Adam's identity, the AS returns a TGT
to Adam's Windows-based The TGT does include the Windows PAC and
workstation. authorization data—but most UNIX
implementations cannot make use of it.
The TGT includes the Windows PAC in
the Kerberos v5 authorization data Now Eva is authenticated.
field of the Kerberos ticket.
The UNIX client puts away the TGT for future use.
Now Adam is authenticated.
The Windows client puts away the

TGT for future use.
PAC and access token: PAC and access token:
LSA (a Windows subsystem used for [Not applicable: Eva's UNIX client does not use the
logon authentication) on Adam's Windows PAC. Eva does not have an access token
Windows-based workstation uses the and therefore does not have SIDs.]
PAC to create Adam's access token.
Adam's access token defines Adam's

rights, which are contained in
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows Client UNIX Client

Adam's security identifier or SID
(which identifies him to the network)
and in the SIDs of each group to
which he belongs.
LDAP calls: LDAP calls—UNIX login uses NSS to perform LDAP
lookups:
[Not applicable: Because Active
Directory Kerberos provides the user The UNIX client connects to the LDAP server (the
rights data in the PAC, no call to Active Directory server) to retrieve Eva's UNIX
LDAP is needed to assemble the user authorization, using Eva's user name to do the
authorization data at logon.] lookup:
1. The UNIX login command makes a UNIX API

call, which hands the request to NSS; NSS
makes an LDAP call to Active Directory to
retrieve Eva's attributes—her UID, the GID of
her primary group, her home directory, and
shell.
2. The UNIX login command makes a UNIX API
call, which hands the request to NSS; NSS
makes another LDAP call to Active
Directory to retrieve the GID of all groups
known to the system; and then NSS uses
LDAP queries to see if Eva is a member of
each group.
3. The UNIX login command uses the
information retrieved from LDAP to
construct the "security context" for the initial
process that login creates on Eva's behalf.
The security context is Eva's identity and the
groups to which she belongs as well as the
rights granted to her UID and GIDs.
Adam accesses a network resource: Eva accesses a network resource:
Adam is allowed or blocked from Eva is allowed or blocked from accessing

accessing information on the information on the network resource based on a
network resource based on a comparison of the rights in her UID and GIDs with
comparison of the rights in his access the permissions specified in the ACL of the network
token with the permissions specified resource.
in the ACL of the network resource.
The UNIX kernel on the client performs this
The Windows System Resource comparison.
Manager on the network resource
performs this comparison.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Of the five end states in this chapter, End State 2 (the example used in Table 1.4) provides a
level of integration with Active Directory for UNIX-based computers that is closer to that
available by default in an Active Directory–based domain for Windows computers than the
integration provided by the other end states. Of all the possible end states, End State 2 thus
has the highest potential for secure interoperability between Active Directory and UNIX-
based computers and applications.
End States for Integrating Windows and UNIX
The first key step in a comprehensive identity and access management strategy is to
consolidate— to the greatest extent possible—divergent identity stores into a single,
centralized store. Ideally, UNIX-based computers can use the same identity store as
Windows—namely, Active Directory—for both authentication and authorization.
Alternatively, UNIX-based computers can use Active Directory for authentication only.
By integrating UNIX system authentication and authorization information into Active

Directory, you put the foundation in place for a more comprehensive integration of all
applications into a single identity and access management scheme. Although the scope of
this guide is restricted to solving the basic authentication and authorization requirement for
UNIX-based computers, how to extend your identity and access management strategy is
discussed in the section (for the Quest Software VAS product or the Centrify DirectControl
product) or chapter (for the custom solutions) about evolving each solution beyond this
basic implementation.
This section summarizes:
 Five end state options

 Technology solutions available for each end state
Five End State Options
The five end states described in this guide represent possible options for enabling
interoperability between UNIX and Windows computers in a mixed network environment. You
can configure interoperability either at the level of authentication only or at the level of both
End States 1–4 are integrated solutions in which the account for each UNIX user is migrated
to Active Directory using any of four combinations of authentication and authorization
options. For End State 5, the Windows and UNIX environments remain separate but are
connected by a cross-realm trust that enables authentication between the UNIX and
Windows realms. For End State 5, when authentication occurs, if the trust is a two-way trust,
each client is trusted by workstations and servers hosting network resources in the other
environment. UNIX user accounts continue to be stored in the UNIX KDC. Authorization is not
a factor in End State 5.
The following figure depicts the authentication and authorization options by end state.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 1.3. End states vary by how they use Active Directory authentication and authorization.
Although these five end states are described independently of each other in this guide, the
appropriate solution for your organization might be to use more than one end state solution.
Depending on your networking environment, it might be appropriate to:
 Deploy one end state throughout your entire organization.

 Deploy one end state in part of your organization.
 Deploy more than one end state in different parts of your organization. For example,
one typical combination might be to deploy both an End State 2 solution and an End
State 5 solution.
The following sections briefly describe each of the end states included in this guide.
End State 1: Use Active Directory Kerberos to Authenticate UNIX Clients
End State 1 introduces the use of Active Directory as a Kerberos KDC to store authentication
data for users on both UNIX and Windows computers. However, an End State 1 solution
continues to rely on your existing UNIX-based source, such as the local /etc/passwd and
/etc/group files, iPlanet, or NIS, to store authorization data for UNIX users.
Using Active Directory Kerberos authentication for both Windows and UNIX clients lets users
log on securely to either UNIX or Windows hosts with a single user name and password. An
authenticated UNIX user, like an authenticated Windows user, can access Kerberized
applications (applications that use Kerberos for authentication) without being prompted
again to provide a user name or password.
With an End State 1 solution, Windows and UNIX clients both authenticate to the Kerberos
KDC on Active Directory, but the logon process is not completely identical:
 Windows Active Directory Kerberos logon. The Windows client requests a TGT from the
AS component of the Active Directory KDC. When the AS returns a TGT to the
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows client, the TGT includes the Windows PAC in the Kerberos v5 authorization
data field of the Kerberos ticket.
 UNIX Active Directory Kerberos logon. The UNIX client requests a TGT from the AS
component of the Active Directory KDC. In this case, when the AS returns a TGT to the
UNIX client, it includes the Windows PAC and authorization data, but most UNIX
implementations cannot make use of it. Instead, the UNIX client retrieves
authorization data from Active Directory by making a series of LDAP calls.
For a more detailed description of this process, see "Example: Kerberos and LDAP in a Mixed
Environment" earlier in this chapter.
Consolidating Windows and UNIX authentication data storage in Active Directory eliminates
the need for separate administration of authentication data on the UNIX side. However,
typically, in an End State 1 solution, you cannot retire UNIX-based computers currently used
for storing authentication data because in most cases these computers also store
authorization data. LDAP, NIS, and /etc/passwd stores typically store not only passwords
(authentication data) but also store UIDs and GIDs (authorization data). In addition, these
computers might also be used for authentication by UNIX-based computers not included in
the End State 1 solution.
Maintaining two authorization data stores—one for UNIX users and another for Windows
users—incurs extra administrative overhead. However, your organization might prefer to
maintain two authorization data stores for one or more of the following reasons:
 If your UNIX infrastructure includes applications that require a UNIX-based

authorization store. For example, if you have an existing legacy system such as iPlanet
and do not want to migrate authorization data to Active Directory yet.
 If you have a sophisticated infrastructure already in place to manage authorization
on UNIX-based computers.
 If you want to minimize risk by changing only one element of security at a time. In this
case, you might find it appropriate to migrate to an End State 2 solution later after
confirming that the End State 1 solution functions well and operates securely.
End State 1 is appropriate for an organization with an existing UNIX infrastructure where you
want to migrate to Active Directory authentication data that is currently maintained in any
type of UNIX-based authentication data store, such as in local files, on a UNIX-based
Kerberos server, or in NIS, but it is impractical or not possible to migrate authorization data to
Active Directory.
End State 1 Example
In this example, an organization currently uses NIS to store both authentication and
authorization data for UNIX users. They want to centralize administration of authentication
data for both Windows and UNIX users in Active Directory while maintaining the existing NIS
infrastructure to store UNIX authorization data. They also want to provide users with a single
tmg.edu.au | 1300 888 TMG (1300 888 864)
user name and password to access both UNIX-based and Windows-based computers on
their network.
This organization plans to migrate authorization data to Active Directory in the future, but
they want to make the change one step at a time.
Figure 1.4. End State 1: UNIX clients using Active Directory Kerberos for authentication and
UNIX-based NIS for authorization
End State 2: Use Active Directory Kerberos to Authenticate and Active Directory LDAP to
Authorize UNIX Clients
The use of the Kerberos protocol and LDAP in conjunction with each other is integral to the
Windows security model. To take full advantage of the authentication and authorization
support that Active Directory can extend to UNIX users, the ideal interoperability solution
includes:
 UNIX clients authenticate to Active Directory Kerberos v5.

 UNIX clients use Active Directory LDAP v3 for authorization.
End State 2 introduces the use of Active Directory to store both authentication and
authorization data for UNIX users, replacing existing UNIX-based authentication and
authorization storage methods. With an End State 2 solution, authentication data for UNIX
users is migrated to the Active Directory Kerberos KDC so that UNIX clients can authenticate
to the Active Directory KDC. Authorization data for UNIX users is migrated to the Active
Directory LDAP data store so that UNIX clients can use Active Directory LDAP for
authorization. Using both Active Directory Kerberos and Active Directory LDAP enables UNIX
clients to take full advantage of Windows authentication and authorization security
mechanisms.
Storing UNIX authentication data in Active Directory allows users to log on securely to either
UNIX or Windows hosts with a single user name and password. An authenticated UNIX user,
like an authenticated Windows user, can access Kerberized applications without being
prompted again to provide a user name or password.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consolidating Windows and UNIX authentication and authorization data in Active Directory
eliminates the need for separate administration of authentication and authorization data on
the UNIX side. You can retire UNIX-based computers currently used for storing authentication
and authorization data or reallocate them for other use.
Like End State 1, with End State 2, Windows and UNIX clients both authenticate to the
Kerberos KDC on Active Directory, but the logon process is not completely identical:
 Windows Active Directory Kerberos logon. The Windows client requests a TGT from the
AS component of the Active Directory KDC. When the AS returns a TGT to the
Windows client, the TGT includes the Windows PAC in the Kerberos v5 authorization
data field of the Kerberos ticket.
 UNIX Active Directory Kerberos logon. The UNIX client requests a TGT from the AS
component of the Active Directory KDC. In this case, when the AS returns a TGT to the
UNIX client, it does include the Windows PAC and authorization data, but most UNIX
implementations cannot make use of it. Instead, the UNIX client retrieves
authorization data from Active Directory by making a series of LDAP calls.
For a more detailed description of this process, see "Example: Kerberos and LDAP in a Mixed
Environment" earlier in this chapter.
When you use Active Directory as the LDAP store for one of the custom End State 2 solutions
in this guide, you must either extend the Active Directory schema to include UNIX-specific
attributes (for versions of Windows earlier than Windows Server 2003 R2), or you must install or
upgrade to Windows Server 2003 R2.
The two commercial End State 2 solutions included in this guide handle UNIX attributes for
UNIX users whose accounts have been migrated to Active Directory in the following ways:
 Quest Software VAS product:

o Provides its own RFC 2307-compliant schema extension.
o Provides the VAS UNIX Personality Management (UPM) feature. UPM solves the
UNIX attribute problem in a different way than the VAS schema extension by
enabling VAS to manage UNIX user attributes through defining "Personalities"
(alternative identities) that the user can assume when logging on to different
UNIX-based computers. Even though UNIX users can have multiple UNIX
personalities, they have only one underlying identity—the Active Directory
user account.
o Supports the use of Windows Services for UNIX schema extensions for storing
UNIX user attributes in Active Directory.
o Supports Windows Server 2003 R2, which includes support for RFC 2307 as part
of its default installation. The VAS solution described in this guide was not
tested with Windows Server 2003 R2.
 Centrify DirectControl product:
o Provides its own method for solving the UNIX attribute problem through its use
of zones. DirectControl zones make use of the Active Directory feature that
tmg.edu.au | 1300 888 TMG (1300 888 864)
allows applications to store data in Active Directory under the Program Data
container hierarchy. UNIX users can be associated with multiple UNIX identities
in numerous zones, if required, even though they have only one underlying
identity—the Active Directory user account.
o Supports the use of Windows Services for UNIX schema extensions for storing
UNIX user attributes in Active Directory.
o Supports Windows Server 2003 R2, which includes support for RFC 2307 as part
of its default installation. The DirectControl solution in this guide was not tested
with Windows Server 2003 R2.
End State 2 is appropriate for organizations that want to simplify administration, retire UNIX
authentication and authorization data stores, take advantage of Active Directory Kerberos,
and provide users with a single user name and password for logon to both Windows-based
and UNIX-based computers.
End State 2 Example
In this example, an organization currently uses NIS to store authentication and authorization
data for UNIX users. They want to retire existing user data storage systems and use Active
Directory to store both authentication and authorization data. They also want to provide
users with a single user name and password to access UNIX-based or Windows-based
computers on their networks. The added security of Kerberized authentication with single
sign-on to applications using Kerberos credentials also interests them.
Figure 1.5. End State 2: UNIX clients using Active Directory Kerberos for authentication and
Active Directory LDAP for authorization
End State 3: Use Active Directory LDAP to Authenticate UNIX Clients
In End State 3, Windows clients continue to use the Kerberos KDC on Active Directory, which
is the default Windows method for storing authentication data. However, in an End State 3
solution, UNIX clients do not use Active Directory Kerberos for authentication. Although
Kerberos v5 is the default method used for authentication in an Active Directory–based
network, it is also possible to use Active Directory LDAP for authentication, and End State 3
introduces the use of Active Directory LDAP to store authentication data for UNIX clients. End
State 3 continues to rely on your existing UNIX-based source, such as the local etc/passwd
and /etc/group files, iPlanet, or NIS, to store authorization data for UNIX clients.
Centralizing Windows and UNIX authentication data storage in Active Directory allows users
to log on to either UNIX or Windows hosts with a single user name and password. However,
tmg.edu.au | 1300 888 TMG (1300 888 864)
with End State 3, users do not get the single sign-on benefits provided by Kerberos
authentication for applications: Users logged on to UNIX clients must provide their user name
and password each time they want to access a Kerberized application (or any application
that requires authentication) because End State 3 uses LDAP instead of Kerberos for
authentication.
Consolidating Windows and UNIX authentication data storage in Active Directory eliminates
the need for separate administration of authentication data on the UNIX side. Typically, in an
End State 3 solution, you cannot retire or reallocate UNIX-based computers currently used for
authentication data storage for other use because, in most cases, these computers also
store authorization data or are used for authentication by UNIX-based computers not
included in the End State 3 solution.
As with End State 1, in End State 3 maintaining two authorization data stores—one for UNIX
users and another for Windows users—incurs extra administrative overhead. However, your
organization might prefer to maintain two authorization data stores for one or more of the
following reasons:
 If your UNIX infrastructure includes applications that require a UNIX-based

authorization store. For example, if you have an existing legacy system such as iPlanet
and do not want to migrate authorization data to Active Directory yet.
 If you have a sophisticated infrastructure already in place to manage authorization
on UNIX-based computers.
 If you want to minimize risk by changing only one element of security at a time. In this
case, you might find it appropriate to migrate to an End State 4 solution later after
confirming that the End State 3 solution functions well and operates securely.
End State 3 is appropriate for an organization with an existing UNIX infrastructure where the
authentication data is currently stored in a UNIX-based LDAP database, where it is
impractical or not possible to migrate from UNIX-based LDAP authentication to Active
Directory–based Kerberos authentication, and where it is impractical or not possible to
migrate authorization data to Active Directory. This includes customers who have extensive,
complex, and rich multiplatform authorization infrastructures in place that they want to
maintain but who do want to move toward a single identity and single point of
authentication.
End State 3 is also appropriate for custom UNIX systems that have a unique authorization
environment but want centralized authentication. For example, a Linux-based cash register
has no file system and thus does not make standard authorization decisions, but it does need
to authenticate cashiers. An organization whose environment includes a small-footprint
device such as this might find that using LDAP for authentication meets its needs.
End State 3 Example
In this example, an organization uses a tool that they developed in-house to centrally build
and distribute /etc/passwd files to all of its UNIX clients. These files are constructed on a
tmg.edu.au | 1300 888 TMG (1300 888 864)
nightly basis to control the computers to which individual users have access. The in-house
tool is tightly coupled to other internal business systems and processes. The customer wants to
move to a centralized authentication environment to reduce the cost of password-related
help desk calls. While all of their computer systems support LDAP authentication, some clients
do not support Kerberos.
Adopting an End State 3 solution enables users to have the same user name and password
on all computers, centralizing administration and reducing help desk costs; it allows the
organization to continue to use the tightly coupled authorization systems (which, in this
example, use the default UNIX /etc/passwd and /etc/group files for storing authorization
data) that it depends upon today.
Figure 1.6. End State 3: UNIX clients using Active Directory LDAP for authentication and UNIX
/etc/passwd and /etc/group files for authorization
End State 4: Use Active Directory LDAP to Authenticate and Authorize UNIX Clients
End State 4 introduces the use of Active Directory LDAP to store both authentication and
authorization data for UNIX clients. End State 4 is similar to End State 2 in that both end states
replace UNIX-based authentication and authorization methods with the use of Active
Directory to provide both authentication and authorization for UNIX users. However, unlike
End State 2, which uses Active Directory as a Kerberos KDC for authentication and Active
Directory LDAP to handle authorization, End State 4 uses Active Directory LDAP for both
Centralizing Windows and UNIX authentication data storage in Active Directory allows users
to log on to either UNIX or Windows hosts with a single user name and password. However,
with End State 4, users do not get the single sign-on benefits provided by Kerberos
authentication for applications: Users logged on to UNIX clients must provide their user name
and password each time they want to access a Kerberized application (or any application
that requires authentication) because End State 4 uses LDAP instead of Kerberos for
authentication.
Consolidating Windows and UNIX authentication and authorization data in Active Directory
eliminates the need for separate administration of authentication and authorization data on
tmg.edu.au | 1300 888 TMG (1300 888 864)
the UNIX side. You can retire UNIX-based computers currently used for storing authentication
and authorization data or reallocate them for other use.
End State 4 is appropriate for an organization with an existing UNIX infrastructure that
currently stores both authentication and authorization data in a UNIX-based LDAP database,
wants to move both types of UNIX data into Active Directory, but finds it impractical or not
possible to migrate from UNIX-based LDAP authentication to Active Directory–based
Kerberos authentication.
End State 4 might also be appropriate for an organization that has standardized on LDAP or
does not want to maintain a dual Kerberos/LDAP stack on every UNIX client. In addition, End
State 4 is appropriate for customers with computers for which Kerberos is unavailable;
adopting LDAP enables a single authentication mechanism for all of their resources.
End State 4 Example
In this example, an organization currently uses a UNIX-based LDAP directory for both
authentication and authorization data for UNIX users. The organization wants to consolidate
this information to reduce infrastructure costs and to let users use the same user names and
passwords on both Windows and UNIX-based computers.
Figure 1.7. End State 4: UNIX clients using Active Directory LDAP for both authentication and
authorization
End State 5: Create a Cross-Realm Trust Between UNIX and Windows KDCs
End State 5, unlike End States 1–4, continues to use your existing UNIX and Windows
infrastructures but establishes interoperability between UNIX-based Kerberos (such as MIT
Kerberos) and Active Directory–based Kerberos by deploying a cross-realm trust. Windows
clients and UNIX clients each authenticate to their own KDC and, if the trust is a two-way
trust, are then trusted by workstations and servers hosting network resources on the other
side.
UNIX users, when authenticated to the UNIX KDC, can access services (applications) in the
Windows environment without having to reauthenticate. The Windows KDC trusts the UNIX
KDC's authentication credentials and so grants access to Windows services to UNIX users
without reprompting the user for authentication. You can configure the trust to be one-way
(the Windows KDC trusts the UNIX KDC but the UNIX KDC does not trust the Windows KDC, or
vice versa) or two-way (each KDC trusts the other).
tmg.edu.au | 1300 888 TMG (1300 888 864)
End State 5 requires minimal infrastructure modification yet enables both Windows users and
UNIX users to access Kerberized applications in either environment without being prompted
repeatedly for user name and password. With End State 5, authorization is not a factor, so
you continue to use your existing UNIX-based authorization method for UNIX users.
End State 5 is appropriate for an organization with an existing UNIX-based Kerberos

infrastructure where it is impractical or not possible to make extensive changes to that
infrastructure.
End State 5 Example
In this example, an organization has a network that includes a UNIX-based Kerberos

environment and a separate Active Directory environment, which uses Kerberos
authentication by default. In this case, the network has Kerberized applications in each
environment that administrators want to make available to users from either side without
requiring users to retype their user names and passwords.
Figure 1.8. End State 5: UNIX and Windows clients using a two-way cross-realm trust to
authenticate to Kerberized applications in the opposite realm
Technology Solutions Available for Each End State
The technology solutions presented in later chapters in this guide represent possible
alternatives for deploying the end state—the authentication and authorization choices—that
you decide to implement.
More than one approach is available to achieve the various end states. This guide includes
the following technology solution categories:
 Commercial. Commercially available products that you can buy.

 Custom , or do-it-yourself , solutions:
tmg.edu.au | 1300 888 TMG (1300 888 864)
o Native OS solutions. You can develop a solution that uses only components of
the native UNIX or Linux operating system. These solutions are referred to in this
guide as the "native OS" solutions.
o Open source solutions. You can implement a solution that uses the native
operating system as a foundation but adds Kerberos and LDAP components
and tools, which are available as open source software and free downloads
from third parties. These solutions are referred to in this guide as the "open
source" solutions.
The following table maps the technology solutions described in this guide to the five end
states.
Table 1.5. Technology Solutions Available for Each End State
1st 2nd Decision:

Decision:
Types of Technology Solution
End State
End State  Custom, or do-it-yourself, solutions that use either:
1 o UNIX or Linux native OS components
o UNIX or Linux open source software

 Commercial solutions:
o Centrify DirectControl, available at http://www.centrify.com
o Quest Software Vintela Authentication Services (VAS),
available at http://www.vintela.com


End State  UNIX or Linux native OS component (native KDC) or open source
5 system component (MIT KDC)
Both the native OS and the open source custom scenarios described for each end state in
this guide include two alternative solutions: one for the Solaris 9 version of UNIX and another
for the Red Hat 9 version of Linux.
tmg.edu.au | 1300 888 TMG (1300 888 864)
CAUTION We do not recommend deploying the native OS Red Hat 9 solution in your
production environment because of the security risks inherent in this solution.
Major Envisioning Phase Tasks and Deliverables
Envisioning Phase tasks follow the basic sequence of identifying and defining the business
problem, envisioning an ideal outcome in the context of larger organizational goals, and
then developing a solution that the project will implement. In some cases, an organization
might decide to restrict the scope of the project because of various constraints that apply,
but it should be made clear how the project contributes to the realization of the vision.
The following table divides this approach into a list of major tasks and shows the deliverable
that documents each task and the team role that bears primary (but not sole) responsibility
for completing it. The timing of the tasks often overlaps and some tasks will span the entire
phase. Many tasks require several iterations before a solution that is considered viable and
agreeable by all interested parties and stakeholders is reached.
Table 2.1. Major Tasks , Deliverables , and Primary Owners
Task Project Deliverable Primary Owners

Set up a project team Program
Management
Product
Management
Identify stakeholders and gain their Product
commitment Management
Create the problem statement Vision/scope document Product
Management
Clarify the business goals for the project Vision/scope document Product
Management
Draft a vision statement Vision/scope document Product
Management
Assess the current systems Program
Management
Define design goals Vision/scope document Product
Management
Identify high-level requirements Vision/scope document Product
Management
Define end-user profiles Vision/scope document User Experience
Define assumptions and constraints Vision/scope document Program
Management
Define the project scope Vision/scope document Program
Management
Define the solution concept Vision/scope document Program
Management
tmg.edu.au | 1300 888 TMG (1300 888 864)
Task Project Deliverable Primary Owners

Define the project structure Project structure Program
document Management
Assess risk Risk assessment Program
document Management
Note This chapter provides information about the essential tasks of the Envisioning Phase for
a Microsoft Windows® security and directory services project. The chapter is not exhaustive in
its discussion of processes. For a detailed description of all the activities and deliverables for
the MSF Envisioning Phase, refer to the UNIX Migration Project Guide (UMPG), available at
http://go.microsoft.com/fwlink/?LinkId=19832. The UMPG can be used to map MSF processes
to the project management system used in your organization if this is necessary.
By the end of the Envisioning Phase, the team and all major stakeholders for the project
should have agreed upon the following conceptual areas, documented their understanding
in a vision/scope document, and formally approved it:
 A vision for the solution

 A solution concept
 The scope of the project
 An assessment of risks
 A rough estimate of the project time frame and duration
Together, these conceptual areas comprise a high-level description of the project that forms
the basis for further planning. The vision/scope document is a living document that represents
a baseline; it might need to be revised as planning progresses and as dictated by new
information. Refer to the UMPG for more detailed discussions on how to approach these tasks
and deliverables and how to assign responsibility for them.
Job Aids
The job aids included with the Windows Security and Directory Services for UNIX Guide
specific to the Envisioning Phase are designed to give the project team a jumpstart in
creating the deliverables needed for this phase. These Microsoft Word templates and Excel®
spreadsheets have been populated with information relevant to this project. Each job aid is
mentioned throughout this chapter in the context of its specific use. Job aids are not part of
the documentation; they are included as separate components of the solution in a Tools and
Templates folder. The job aids relevant to the Envisioning Phase are:
 Project Team Skills Template (Microsoft Word document)

 End State Selection Tool (Excel workbook)
 Vision/Scope Template (Word document)
 Project Structure Template (Word document)
 Risk Assessment Tool (Excel workbook)
tmg.edu.au | 1300 888 TMG (1300 888 864)
Setting Up a Team
One of the first tasks in the Envisioning Phase is to set up a project team—that is, to establish
who will do the work of the project and to assign specific responsibilities. The MSF approach is
to structure a multidisciplinary project team around six core roles. The definition of each role
begins with a focus on a fundamental goal that is generally considered essential for project
success. The role is then assigned a "cluster" of responsibilities that will directly lead to the
realization of this goal when they are carried out. Collectively, the responsibilities of a role
often transcend the skill sets called for in traditional, specialized jobs. For example, the
Program Management Role calls for both project management and architectural skills. A
role may thus need more than one individual to fill it.
The MSF role names are referenced throughout this guidance to indicate who has
responsibility for a particular task. If your team is structured differently, you might need to do
a mapping to prevent confusion. The following table summarizes the MSF team structure,
including core roles, associated responsibilities, and goals.
Table 2.2. Key Roles and Responsibilities of the Project Team
Role and Goal Responsibilities

Product Management Ensures that the team addresses business goals and
customer requirements. Manages customer expectations
Goal: To satisfy customers and communications. Plans launch.
Program Management Tracks and manages the budget and project schedule;
drives risk management process; manages resource
Goal: To deliver solution allocation; facilitates communication within the team;
within project constraints drives overall solution design; manages solution scope and
critical trade-off decisions.
Development Provides input on technical implication and feasibility of the
solution; may prototype technology options; drives the
Goal: To build the solution development plan, infrastructure development, and
according to specifications configuration management. Develops the solution.
User Experience Analyzes user performance and support requirements; may
develop use cases and usage scenarios; defines user
Goal: To enhance user assistance documentation and training needs.
effectiveness of the solution
Test Articulates quality goals for the solution; defines test
approach and acceptance criteria; creates test strategies
Goal: To approve solution to ensure quality of the solution; conducts tests; tracks all
for release only after all bugs; and communicates issues.
quality issues are identified
and addressed
Release Management Defines deployment requirements and implications; creates
rollout and pilot plans; manages deployment.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Role and Goal Responsibilities

Goal: To achieve smooth
deployment and ongoing
operations
The Product Management and Program Management Roles are normally the earliest team
assignments and carry the heaviest workload in the Envisioning Phase, including
considerable interaction with IT senior management and other project stakeholders. Before
the phase ends, however, persons need to be identified for each role, even if they are not
yet fulltime participants. If the project is small, a six-person team (or an even smaller team,
with one person filling two or more roles) might suffice for the entire project. For larger
projects, roles such as Development are likely to require several persons, each with different
specialized skills, to fill them. The MSF Team Model scales by having the core team member
become the lead for that role and work with Program Management to bring on other
individuals in the role as they are needed. For a more extensive discussion of the MSF Team
Model, including team setup, communications, nonhierarchical structure, and scaling, see
the UMPG.
The Project Team Skills Template Job Aid
The “Project Team Skills Template” job aid is designed to help you set up your team and
identify skill and knowledge gaps (and thus the training needs) for the chosen team
members. The job aid lists the roles and associated responsibilities at a more granular level
than the preceding table. It also lists the specific skills and knowledge required to fill each
role for this type of project and suggests the organizational job titles of persons who are likely
to have the required skill/knowledge sets.
Special Considerations for Setting Up the Team for a Windows Security and Directory Services
Project
This type of project can represent unique staffing issues for your project team. The solution(s)
you choose to evaluate and implement will affect your staffing needs. For example,
evaluating only packaged solutions will require fewer skills than those needed to evaluate
open source solutions. Keep the following considerations in mind when selecting the project
team:
 Sourcing of expertise. Because of the broad range of skills required to successfully

evaluate these solutions and deploy one of them, it may be difficult to build a team
with all the required skills when drawing upon in-house resources. Therefore, it might
be necessary to consider including outside resources.
It is relatively easy to find technical staff with a deep knowledge of UNIX or Microsoft
Windows operating systems, but it is less easy to find technical staff that has a deep
understanding of both of these areas. Implementation of the solution involves
creating a bridge between the two environments. Make sure that the architect on
the team has a sufficiently deep understanding of both UNIX and Windows to
tmg.edu.au | 1300 888 TMG (1300 888 864)
engineer the bridge's creation. If this skill is not available in-house, consider a
consultant or a consulting organization with experience in implementing this type of
solution. Consulting organizations often offer services to complete this type of project
end-to-end, including implementation and data migration.
 Timing of involvement. Ensure that the hardware and infrastructure experts from the
Development and Test Roles are actively engaged during the Envisioning Phase.
Experts in the Active Directory® directory service infrastructure need to be involved
early in the process to ensure consideration is given to UNIX-related requirements,
remote offices, and anything unique about the existing infrastructure. The UNIX
administration experts need to be included early because they may have already
addressed some of the challenges that the Active Directory infrastructure will need to
address, such as remote offices, high-latency links, and administrative needs. Teams
commonly overlook the hardware on which databases and applications are run until
later than optimal in the project life cycle. Involving the experts early in the project
helps inform more accurate estimates regarding budget, time, and resources.
 Kerberos skill sets. Implementing End States 1, 2, or 5 requires Kerberos skills. Kerberos
implementation differs between UNIX and Windows, and someone without
experience with Kerberos in both environments might experience confusion. Ideally,
your team includes members with significant experience using Kerberos in both
environments. Differences in Kerberos implementation include: encryption types, key
tables (for UNIX), Kerberos configuration (UNIX uses files, Windows uses DNS), and
manual (UNIX) versus automatic (Windows) load balancing. (See the “Project Team
Skills Template” job aid for more information about required Kerberos skill sets.)
 UNIX skill sets. UNIX administrators are likely to be more familiar with command-line
interfaces than with GUI-based tools and often make heavy use of scripting. You will
need someone on the team to help these administrators access similar functions in
Active Directory—scheduled jobs or at versus cron, general command-line tools, and
remote access via ldapsearch-type tools. UNIX skill sets should also include
knowledge of the differences between one UNIX distribution and the next (such as
Solaris versus Red Hat). (See the “Project Team Skills Template” job aid for more
information about UNIX skill sets.)
 Windows skill sets. In general, existing Windows administrators may need a deeper
understanding of the Active Directory structure—time synchronization, Kerberos, and
LDAP—than they currently possess. You may need to involve team members who are
highly skilled in Active Directory, and even then you might need additional training or
outside help. The Active Directory team might not, for instance, have experience
accessing the Active Directory database from the back end with ADSIEdit or similar
tools or in adding computer accounts manually.
Windows administrators are likely to be more familiar with GUI-based administration

tools than with command-line administration tools. They are also less likely to use
scripting. These administrators may need additional training to make the translation.
Acquiring these skill sets will help them to work compatibly with the UNIX
administrators and to "talk the same language." Integrated security and directory
services projects tend to expose Windows administrators to details and features not
tmg.edu.au | 1300 888 TMG (1300 888 864)
normally used in a Windows-only environment. (See the “Project Team Skills Template”
job aid for more information about Windows skill sets.)
 Other initiatives. If initiatives are underway in the enterprise related to identity

management or with partners related to identity, gather input from these groups to
gauge the impact of their work on this project.
 Special requirements for administrative interfaces. It might be necessary or desirable
to build new administrative interfaces or to integrate administration of this solution into
your existing enterprise management tool. Solutions that are not packaged
commercial solutions may require extending or building an administrative interface to
incorporate the administration of computer accounts, Kerberos key tables, or UNIX
user attributes. All the solutions include some tools for this; however, these tools may
not be appropriate for deployment in your production environment or integration
with your enterprise management system. You will need to evaluate the included
tools and determine if they are suitable in your environment. If they are not, then you
might need to develop a new interface or develop tools to integrate with your
existing enterprise management system. You might need team members who can
scope, design, test, and implement such a solution.
 Career impacts. Because moving from authorization and authentication support on
UNIX to Active Directory is a major paradigm shift, it may have an impact on the
employment and careers of existing personnel. Take this issue into consideration when
forming the team and carrying out the migration. Change is often inevitable, but it
may also be met with resistance. Acceptance is more likely if the change is
perceived as an opportunity to expand and develop skills.
 Collaboration between UNIX and Windows personnel. Collaboration between UNIX
and Windows personnel is essential for the success of the project but may present a
challenge because of "historical" rivalries and cultural differences between the two
groups. It is recommended that you openly acknowledge the differences in points of
view while emphasizing the necessity to collaborate in building a viable solution.
Some approaches that can help promote collaboration include:
o Building a cultural bridge through education of both groups about each

others’ platforms, capabilities, tools, and management methods to help
overcome misconceptions.
o Positioning the required changes as containing career growth opportunities
and following through with the opportunities.
o Involvement by all, especially UNIX administrators, in designing test and proofs
of concept (POC). Invite UNIX administrators to design rigorous tests or a POC
for Active Directory that would address any concerns they have about its
performance, strength, or security.
o Encouraging UNIX administrators to help build a robust structure by voicing
their concerns regarding the performance and security of Active Directory.
Encourage Windows administrators to listen openly to these concerns and use
the project as a learning opportunity to find ways to address them.
tmg.edu.au | 1300 888 TMG (1300 888 864)
o Offering to have a third party do a security audit or architecture audit of the

Active Directory infrastructure to show that it is sufficiently robust for the
solution.
Gaining Commitment and Support of Sponsors and Stakeholders
Successfully fulfilling a major goal of the Envisioning Phase—to reach agreement on the high-
level goals and requirements for the project—requires that business sponsors and key
stakeholders outside of the project team be involved in major decisions concerning the
project.
Securing stakeholder commitment means ensuring that the project's stakeholders agree with
the need to solve the problem and that they are willing and able to commit resources.
Discussions should lead to the resolution of potential conflicts and a formal endorsement of
the project by all stakeholders at the end of the Envisioning Phase, including an approval of
the vision/scope document at a milestone meeting.
Identify Key Stakeholders
The identities of all stakeholders might not be immediately apparent. Members of the core
team need to call upon their technical and role-based expertise to identify organizational
groups and individuals that the implementation activities, or outcome, of the project will
affect. For example, Operations is considered a key stakeholder because they are the IT
organization responsible for ongoing operation of the solution after it is delivered.
In fact, this solution can affect almost everyone in the organization at all levels. One way to
make sure all affected people are represented in some way is to consider the impact of the
project from several viewpoints:
 Employees (including end users)

 Application owners
 Internal development groups
 Corporate management (including finance, audit, risk management)
 Operations management (including backup, help desk)
 Other IT management (including provisioning, hardware acquisitions, UNIX IT
administrators, Windows IT administrators)
It is important to not underestimate the amount of buy-in needed across the enterprise
because a Windows security and directory services project affects everything in the IT
infrastructure.
Facilitate Key Stakeholders' Involvement
Ongoing stakeholder participation is important to the success of the project. Major

milestones at the end of each subsequent phase represent opportunities for the stakeholders
to review the progress of the project. By definition, the stakeholders are invested parties and
tmg.edu.au | 1300 888 TMG (1300 888 864)
their role is to ensure that the project is on track to meet the agreed-upon goals. Additionally,
they alert the team to circumstances that necessitate a change in some aspect of the
project.
Stakeholders also contribute to project success by serving as its champions within the
organization, helping to overcome possible resistance to change. Conversely, they
sometimes derail a project by withdrawing support. Project teams need to be aware of the
importance of stakeholders and keep in mind the need to maintain a positive relationship
with them.
Defining the Business Problem or Opportunity
Defining the business problem or opportunity is the starting point for deciding what you want
an integrated security and directory services project to accomplish. This leads to the
formation of specific business goals, which are then examined within the context of broader
and long-term business goals to ensure congruence. You can then capture the most
important aspects of your goals by formulating a vision statement that helps guide the
project to its completion. The discussion in this section of common triggers for security and
directory services projects is intended to help you capture the most important drivers for your
organization.
There are three basic reasons (or categories of reasons) why organizations decide to
investigate and deploy an integrated security and directory services solution. These
categories may be viewed as business drivers, or motivations, and each can apply to many
specific situations:
 Reduce cost
 Increase effectiveness (including organization, staff, systems)
 Increase compliance (internal or external)
Cost savings is normally the overriding goal when pursuing an integrated security and
directory services solution. However, it is often an event or a situation (the result of a series of
events) that finally tips the balance and causes an organization to seriously consider a
security and directory services project. A merger or isolated security incident are examples of
single events that could trigger this decision. Systems that are overly complex or that have a
large number of users after years of growth are examples of situational triggers.
Both triggers cause a specific business problem, commonly referred to as a "pain point,” that
becomes a priority for the organization to solve. Resolving the pain point becomes the
primary business driver for undertaking the project.
The following is a list of 13 events and situations that commonly motivate organizations to
investigate an integrated security and directory services solution. Identifying your situation on
the list will help you formulate your business problem. Consulting with the stakeholders
discussed earlier, each of whom can view any one business driver differently and assign it a
tmg.edu.au | 1300 888 TMG (1300 888 864)
different level of importance, can help in evaluating the relevance of these drivers to your
organization. In a later section, six business scenarios illustrate some of these triggers.
Common Triggers Leading to Integrated Security and Directory Services Projects
1. Regulatory or policy changes (internal or external). Regulatory changes (such as

HIPPA or SOX) may require changes to password policies, data encryption, and
authorization procedures in order to satisfy new auditing, security, and time
requirements. Internal policy changes may have other drivers that inspired them,
including liability, goodwill, and consumer perception. An example of an external
policy change is new policies adopted by a credit card company for applications
that process credit cards. Therefore, the credit card company requires that you
adhere to these policies in your applications to continue dealing with you.
See Scenario 2b: Northwind Traders in the “Representative Business Scenarios”

section.
2. Merger or acquisition. Mergers and acquisitions can spawn a number of reasons to

examine a security and directory services solution, including needs to:
o Merge, consolidate, and eliminate redundancy in the multiple data stores
from the previously separate environments.
o Meet new requirements for access to systems (new group of users need
access to a particular system).
o Satisfy new policies or regulations that now apply.
In general, a merger or acquisition means that the IT systems need to, at a minimum,
work together. Typically the systems are also examined to see which ones make sense
to keep and what major changes are reasonable to undertake.
Most mergers and acquisitions have cost savings as a fundamental goal, with the
expectation that the combined entity will be more efficient. As a result, management
often looks for cost-saving opportunities in the post-merger organization.
See Scenario 3: Fabrikam.
3. Overloaded administrators and help desk. If multiple directories exist in the

organization, user provisioning, deprovisioning, changes to access, and password
changes can start to overwhelm the IT and help desk staff. Maintaining the directory
infrastructures (including backups and patches/updates) also becomes a large
burden.
The problem may worsen because of organizational growth, introduction of new

applications, or staff reductions. Also, the extra required administrative effort might
prevent the IT department from completing other projects.
See Scenario 2a: Walnut University and Scenario 5: Maple University.
tmg.edu.au | 1300 888 TMG (1300 888 864)
4. Aging software , operating systems , and hardware. Part of the infrastructure for your
existing authentication or authorization system is aging or expiring. Any of the
following situations may apply:
o Hardware has aged and is becoming unreliable.
o Hardware has reached the end of lease.
o The vendor is ceasing support for the specific hardware, software, or an
operating system you are using (for example, Sun has discontinued support for
NIS and NIS+).
o The vendor is changing license agreements or is undergoing other changes
that make it impossible or undesirable to continue to use its products.
o The vendor itself is ceasing operations and there will no longer be support for
a product you are using.
Significant effort may be required to move to newer models or versions and

organizations may choose to pursue a different solution instead of an upgrade.
See Scenario 2a: Walnut University.
5. Deployment of new services. New applications or services that need to be accessed

from both Windows and UNIX platforms are planned for deployment. Organizations
must anticipate and plan for costs of development and deployment, manageability,
and system flexibility.
See Scenario 1: Litware, Inc.
6. Occurrence of event related to security. A significant security event in the

organization or in related organizations such as partners, competitors, suppliers, or
customers results in the organization investigating ways to improve security. Security
events include break-ins, leaked data, and other electronic or physical threats.
Security events also include the inauguration of new regulations imposed by
governmental legislation (such as HIPPA or SOX), new internal policies, and new
policies adopted by partners, customers, or industry groups, which affect security.
(See item #1 Regulatory or policy changes.) Each of these events drives the
organization to strengthen security.
7. Recognition of the need to simplify (and typically standardize) the environment. The
organization recognizes that the IT systems are too complex and need simplification
for auditing and compliance purposes. This situation is really tied to cost reduction.
Note Simplifying can be seen as another way of stating other drivers in this list as well,
or may be a major component of other drivers in this list.
8. A new requirement for various applications to work together or be available to a

wider audience. This requirement includes the need to extend functionality to new
platforms or to cross-platform users (for example, Windows users needing access to
UNIX applications). It sometimes manifests itself as the decision to use a new
enterprise application in the organization, resulting in the need for various existing
tmg.edu.au | 1300 888 TMG (1300 888 864)
applications to now interact with the new application. Examples of this type of
scalability issue include PeopleSoft, SAP, and identity management applications.
9. Organizational growth. The organization is growing because of the introduction of
remote offices or other special challenges and could benefit from a new approach.
Challenges might include adding support for access over satellite links, supporting
increasing numbers of telecommuters, supporting contractors who come and go
frequently, integrating outsourcing partners, and interacting with or providing
accounts to partners, customers, or suppliers. Projected future growth requires that
the solution meet not only the current growth needs, but be scalable into the future.
See Scenario 4: Humongous Insurance.
10. Personnel changes. Staff growth, staff reduction, and outsourcing means that
different people are now using or administering the systems. This situation typically
involves an organization that uses complex, homegrown tools and has a set of new
users who were not the original developers of the tools but who now need to use and
maintain them. Without significant learning time, the new team will not have the
same level of expertise with the tools as the original developers. Therefore, the
organization needs to reduce the skill sets required for use of the tools.
This item is closely related to item #5, Deployment of new services, which is often
associated with personnel changes.
11. Need to increase environment stability and uptime. Each separate infrastructure in an
enterprise adds to the complexity of the environment, and complex environments are
more challenging to keep stable and available. The challenge is even greater if one
infrastructure is using an older or obsolete technology. This situation is most likely to
occur in an older organization that has developed a complex environment over time.
A system downtime event is the most likely trigger for an organization to recognize the
need to improve stability and uptime and look for ways to accomplish it.
12. Desire to implement integrated identity management and single sign-on (SSO). SSO
and identity management are often on the radar for organizations and can become
a priority as productivity, cost, and security issues increase. In this case, SSO and
identity management are perceived as obvious goals in themselves because they
provide answers to many problems and have demonstrated their benefits so well.
13. Desire or need for cost reduction. Organizations are sometimes just looking for ways to
reduce costs.
Defining Business Goals
Business goals are implicit in the business problem or opportunity, and articulating them may
be as simple as stating what is necessary to solve the problem that is the primary impetus for
the project. When articulating your goals, however, keep in mind the entire range of
problems that can be addressed with an integrated security and directory services project. It
tmg.edu.au | 1300 888 TMG (1300 888 864)
should be clear from the preceding list that the types of problems that can be addressed
with this solution are likely interconnected. Fortunately, this means that the opportunity exists
to address related but less urgent problems while tackling the most painful problem, which
can result in achieving multiple goals with this solution.
As mentioned earlier, it is important to keep in mind the broader goals and future plans of the
organization itself. For example, is the business planning to expand and, if so, by how much
and in what directions? The business goals for the project should support the broader
business goals of the organization and accommodate, or at least not conflict with, future
plans.
The following is a list of general business goals. Each goal is accompanied by examples that
connect business goals with technology by showing how an integrated security and
directory system might address the goals. You can use this list as a starting point for
articulating your own goals.
 Increase user productivity

o User accounts are likely to proliferate in a heterogeneous computing
environment, necessitating several passwords. An integrated security solution
allows for use of the same user name and password to log on to multiple
platforms and potentially use single sign-on to access applications, ultimately
saving time in remembering, tracking, and resetting passwords.
o If you have an obsolete technology that is incompatible with some of the
diverse components making up your systems, these incompatibilities can
create barriers to information-sharing and user productivity. These barriers can
be eliminated by replacing the old technology with an integrated security
system based on open standards such as Kerberos and LDAP.
 Increase the availability of information and services to users and applications
o Directories store information such as an address or telephone number and
make it widely available to users and applications within your organization.
When there are two or more unsynchronized directories within your
organization, users and applications must search more than once for each
piece of information. Single, integrated directory services accessible by all
client computers and applications make published information immediately
available to the entire organization.
o The introduction of new services, mergers and acquisitions, personnel
changes, and outdated hardware and software can all result in the need to
improve access to information and services.
Note Metadirectory services and other technologies can be used to ensure

that two directories are synchronized so that all information appears in both
directories. Users can then find what they need with a single search. However,
in this case, data is duplicated in two or more places and the synchronization
system must be maintained.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Reduce ongoing costs (administration , help desk , licensing , and support)

o Reducing infrastructure complexity and associated hardware, software, and
personnel costs often means significant cost reductions in IT operations.
o Integrating two systems into one, thereby reducing the number of accounts,
should reduce the number of administrative tasks such as creating, updating,
canceling, and troubleshooting accounts. Moreover, maintaining two systems
requires either maintaining two sets of administrators or training new
administrators in the skills required for each system. These costs are reduced
when skills in only one system are required.
o Directory consolidation and single sign-on are often viewed as useful ways to
reduce help desk costs because they can reduce the number of calls from
users having trouble managing multiple passwords and needing password
resets. (See "Increase User Productivity.")
o Older technologies are frequently incompatible with other system
components, adding to administration complexity. Removing this source of
complexity can reduce troubleshooting costs.
 Reduce the risk of service unavailability
o When security and directory systems are operating in a system-specific
manner, each client must find a server of its own type to secure service. Server
availability to all clients can be improved with an integrated security system in
which one server is capable of authenticating clients from all operating
systems. This assumes, however, a high-quality system design with sufficient
redundancy.
o By adopting technologies such as Kerberos and LDAP that are based on open
standards and interoperate with many systems, you decrease the risk of losing
support should a single manufacturer cease producing the technology.
 Improve the security of your organization's systems
o You can improve security by implementing an authentication mechanism
where passwords are not sent in the clear (if your current system does not
already have one). Centralizing authorization data can also help by
decreasing the types of infrastructure, which increases the efficiency and
reliability of removing access when it is no longer appropriate, and by
replacing any unsecured access channels with secured channels.
o Directory consolidation and single sign-on help solve security problems when
the burden of remembering and using multiple passwords leads to insecure
practices, such as the use of simple passwords, writing down passwords, and
account sharing, where several users share a single account and password.
o Obsolete technologies are more likely to have vulnerabilities that are well
known to attackers. Replacing them with LDAP v3 and Kerberos v5 (the latest
versions of open standards), which include resilience to the latest security
attacks, will improve security.
 Comply with new regulatory requirements , business policies , or industry best
practices
o New regulations and policies often call for a level of auditing capability,
security provisions, and the capability to meet time deadlines that is not
possible with current systems, but that this solution can achieve.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note The Product Management Role is responsible for driving the determination of the
business goals and requirements and ensuring that they reflect input from the appropriate
stakeholders. Development and Program Management are also key contributors, and all
roles must read, understand, and agree upon the business goals. Product Management
documents the business goals in the vision/scope document.
Creating the Vision Statement for Your Security and Directory Services
Solution
After you have explored the problems and opportunities you want to address and have
articulated your business goals, you can begin drafting an initial vision statement. This
statement describes the desired future state of your organization's environment at solution
completion in clear and concise language. The vision statement is an unbounded view of
the solution that, in fact, might never be completely achieved. Later in your decision-making
process, you will narrow the unbounded view into what will and will not be included in this
particular project when you define its scope. More than one project may be required to fully
realize the vision.
The Vision Statement's Purpose
It can be tempting to skip writing a vision statement and let your project be guided by a
simple list of business goals. Failing to achieve consensus around a crisp, strong vision
statement, however, is a critical failure factor for a project. The vision statement helps to
ensure project success in the following ways:
 Because it must be agreed upon, the vision statement helps stakeholders think
through and voice their priorities. This often leads to the surfacing of conflicts that are
easier and far less expensive to address at the beginning of a project than at the
midway point or later. Thus, the statement helps mitigate the risk of a stakeholder
derailing the project at a later stage.
 The process of creating a vision statement helps participants to think broadly instead
of myopically, opening up possibilities and helping to capture opportunities to realize
additional value.
 The articulated statement can serve as motivation to business sponsors and
stakeholders to commit to the project initially as well as provide their ongoing support.
 After agreement is achieved, the vision helps the project team maintain focus on the
most essential goals during the course of the project by serving as a decision-making
guide.
A good vision statement is short enough to be remembered, clear enough to be understood,

and strong enough to be motivational. You may be able to use one of the following sample
visions—at least as a starting point. Writing it is often an iterative process and you might need
to revise it many times before it is acceptable to all stakeholders. Program Management
records the statement in the vision/scope document. (See the “Vision/Scope Template” job
aid for more information.)
tmg.edu.au | 1300 888 TMG (1300 888 864)
Sample Visions
For a Windows security and directory services project, there are essentially two possible core
visions. The first vision is the most complete and robust; it is realized by achieving either End
State 2 or 4.
All users of IT systems can access any system in the organization for which they have the
appropriate permissions by signing on once with a single user name and password. All
security-related user information is stored in one place. (A shorter version of this is: "One user
name , one password , one place for user information.")
This vision addresses the needs of two groups in the organization: the end users of the systems
and the administrators and other IT personnel who manage the systems. The single user
name and password benefits end users directly and administrators indirectly and the single
store reduces administrative work.
The second vision is more restricted, omitting the second part of the first vision. It describes
End States 1, 3, and 5.
All UNIX and Windows users can access any system in the organization for which they have
the appropriate permissions by signing on once with a single user name and password.
Important To realize either vision, you might need to tackle the project in phases, depending
upon the complexity of your systems. You might, in fact, choose to defer, indefinitely, working
on some aspect of this vision. Nonetheless, your vision should reflect your ideal of where you
would like your organization to be. The older your organization and the more systems present,
the more likely it is that your environment is complex. Consequently, the more likely it is that a
multiphased project will be required to implement your vision. Factors that generate
complexity include: acquiring other companies, evolving through several waves of
information technology, and making many small incremental changes to existing systems
over time.
Because the second vision is a more restricted version of the first vision, the end states it leads
to could represent preliminary stops on a route that eventually leads to the achievement of
the first vision. For example, it is possible to get to End State 4 via End State 3, or to End State 2
via End State 1.
Representative Business Scenarios
To demonstrate the connections between business problems, business goals, and vision
statements, six typical business scenarios are described in this section. Each scenario includes
key facts about the organization's existing IT infrastructure and the business drivers for
change. Although it is unlikely that any one scenario exactly matches your situation, you may
find it helpful to identify the one that seems closest as a starting point for deciding upon a
"best fit" end state. The scenarios are deliberately kept at a very high level so that the salient
tmg.edu.au | 1300 888 TMG (1300 888 864)
differences between them are the factors that would cause you to choose one end state
over another.
Note that, for each scenario, the suggested vision statement is considerably broader than
the specific drivers mentioned for the scenario. This is consistent with the purpose of
developing a vision: to provide an unbounded, best-of-all-worlds view of where you want the
organization to be. The actual project scope will be more constrained, as is discussed later in
this chapter.
Note Scenario 1 leads to End State 1 as the best choice, Scenarios 2a and 2b to End State 2,
Scenario 3 to End State 3, Scenario 4 to End State 4, and Scenario 5 to End State 5. However,
a key difference between your scenario and the sample scenario that first appears most
similar may require you to choose another path.
Caution If your situation is radically different from any of the described scenarios, it is
possible that the solutions provided in this guide are not suitable for your organization.
Scenario 1: Litware, Inc.
Litware, Inc. has existing computers running UNIX and Windows operating systems; these
computers use different stores for account data. On the UNIX-based computers, the
accounts are managed using local files and the standard UNIX authentication mechanisms.
A set of complex homegrown tools is used to manage those files to precisely control which
users are authorized to access which applications on which computers. The applications are
written specifically to rely upon this authorization structure. New human resources and
productivity services are being deployed on the Windows-based computers, and UNIX users
need access to these services. In the current environment, new Windows accounts need to
be created for the UNIX users in order to provide access to the new services, which are
Kerberized. The necessity for multiple accounts and passwords is difficult for users and creates
help desk overhead.
Current Infrastructure:
 Account management for UNIX and Active Directory environments is entirely

separate.
 Account management for UNIX environments is not centralized.
 Application requirements dictate maintaining customized authorization systems.
Problem Statement:
UNIX users need access to new services being deployed on the Windows platform. (See
trigger #5, Deployment of new services.)
tmg.edu.au | 1300 888 TMG (1300 888 864)
Primary Business Goals:
 Make Windows services available to user and service accounts that currently exist on
the UNIX-based computers (increase the availability of information to users and
applications).
 Reduce ongoing costs by simplifying administration and help desk tasks.
Additional Business Goals:
 Increase system security.

 Increase user productivity.
Vision Statement:
All UNIX and Windows users can access any system in the organization for which they have
the appropriate permissions by signing on once with a single user name and password. Users
get timely responses to requests for administrative and help desk services.
Scenario 2a: Walnut University
The Walnut University infrastructure is currently limping along on outdated hardware that is
past its useful life. The increasing use of computing resources by staff and students on multiple
platforms is overloading the systems and administrators. The outdated hardware must be
replaced, but this must be accomplished on a modest budget. Security for the environment
as a whole needs to be improved.
 Active Directory infrastructure exists.

 Existing UNIX authentication and authorization system uses NIS.
 Account management for UNIX and Active Directory environments is entirely
separate.
 Staff and students log on to shared UNIX workstations to access UNIX-based
applications.
Problem Statement:
Capacity of systems and administrators has been exceeded due to old hardware and
increasing use of systems. (See triggers #3, Overloaded administrators and help desk and #4,
Aging software, operating systems, and hardware.)
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Replace outdated hardware/software on a tight budget.

 Reduce ongoing costs by simplifying administration and help desk tasks.

 Increase user (university staff) productivity by introducing single sign-on.
Vision Statement:
security-related user information is stored in one place. (The short version is: "One user name,
one password, one place for user information.")
Scenario 2b: Northwind Traders
Northwind Traders is faced with bringing their systems in line with regulatory requirements,
which include securing all sensitive information with data encryption and minimizing
operational risks. Their current systems do not consistently use data encryption for internal
network communications. Recent problems with downtime on critical systems have made
clear that the wide variety of separate infrastructures in the enterprise, some using obsolete
technology, presents a risk.
Problem Statement:
System changes must be made to comply with regulatory requirements. (See trigger #1,
Regulatory or policy changes.)
 Meet security-related regulatory requirements.

 Reduce the risk of service unavailability.
 Conform to new industry or organization policies/best practices.

 Contain administrative and help desk costs.
Vision Statement:
security-related user information is stored in one place. The security infrastructure complies
tmg.edu.au | 1300 888 TMG (1300 888 864)
with all current regulations and is flexible enough to accommodate future changes. (The
short version of this vision is: "One user name, one password, one place for user information.")
Scenario 3: Fabrikam
Fabrikam currently uses LDAP for authentication and local files for authorization. When the
existing LDAP directory was implemented, it was intended to be used as the central
authentication data repository for the entire infrastructure. However, the recent merger of
Fabrikam with another company has introduced many other systems into the environment
using diverse data repositories (a large Active Directory infrastructure plus several smaller
UNIX systems). The existing, outdated LDAP directory is only used for authentication to the
pre-merger UNIX systems, and the introduction of multiple other proprietary data stores in
mission-critical roles has created a large administration burden. There is no way to export the
contents of the proprietary data stores, which prevents total consolidation.
 Existing UNIX infrastructure uses LDAP for authentication.

 A small Active Directory infrastructure exists.
 A new, large Active Directory infrastructure has been brought over from the other
company.
 Several new, small UNIX environments using diverse authorization methods have been
introduced by another company.
 Users have multiple logons to access the many different environments.
Problem Statement:
The merged company has too many data stores to operate efficiently, from both
administrators' and users' points of view. (See trigger #2, Merger or acquisition.)
 Consolidate authentication IT from pre-merger companies into a single unit (data

store).
 Reduce ongoing costs (administration and help desk) by simplifying authentication.
 Increase access to information and services by users and applications across the
organization.
Vision Statement:
All UNIX and Windows users can access any system in the combined organization for which
they have the appropriate permissions by signing on once with a single user name and
tmg.edu.au | 1300 888 TMG (1300 888 864)
password. The flexible security infrastructure will accommodate significant change in

corporate structures.
Scenario 4: Humongous Insurance
Humongous Insurance currently uses an LDAP directory for both authentication and
authorization of UNIX-based computers. In addition, they have an existing, small Active
Directory infrastructure serving a separate, small user base. The organization is experiencing
dramatic growth and opening new offices. Staff in remote offices will be using Windows
clients but will also need access to computers in the UNIX environment via remote logon. The
current infrastructure does not have the capacity to handle the increased load of
authentication and authorization and the existing system does not encrypt LDAP traffic.
Problem Statement:
Employees working from new, remote offices must be given secure access to systems in order
to do their jobs. (See trigger #9, Organizational growth.)
 Allow users in remote offices to remotely log on to the UNIX computers.

 Meet growing demand for authentication and authorization services.
 Contain ongoing administrative costs by simplifying the environment to enable
administrators to support more people.

Vision Statement:
All current and future users of IT systems, regardless of location, can access any system in the
organization for which they have the appropriate permissions by signing on once with a
single user name and password. Security-related user information is stored in just one place.
Scenario 5: Maple University
Maple University has a large UNIX environment with many legacy services using Kerberos for
authentication. An increasing number of Windows users need access to the services in the
UNIX environment. As the base of Windows users needing access to UNIX services grow, the
administration overhead and user burden inherent in using multiple user names and
passwords for the differing environments increases. The university's IT budget for staff,
software, and hardware is small, however, and will not support dramatic changes to the
existing environment.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Existing UNIX-based Kerberos server is used for authentication in the UNIX

environment.
 Active Directory is used for authentication in the Windows environment.
 Active Directory and UNIX environment authentication data are maintained
separately.
 Several key applications in the UNIX environment use Kerberos for authentication.
Problem Statement:
Administrative load has outgrown capacity of system administrators to handle it. (See trigger
#3, Overloaded administrators and help desk.)
 Make UNIX services available to users in the Windows environment.

 Contain project costs.
 Reduce ongoing costs (help desk).
Vision Statement:
All UNIX and Windows users can access any university system for which they have the
appropriate permissions by signing on once with a single user name and password. Minimal
changes, low costs, and a short project duration—yet it's easier to do more.
Assessing the Current Security and Directory Systems
Achieving an understanding of your current situation is a vital step early in any project. Just
as defining your problem statement, resulting business goals, and vision clarifies where you
want to get to, assessing your current systems establishes your starting point. A current state
assessment entails both an inventory of your current systems and an evaluation of them in
light of the business goals you defined.
You may find it convenient to approach inventory-taking iteratively, beginning with the
relatively high-level information that is needed for early Envisioning Phase decisions. To
determine the best way to scope your project, you will find it helpful to have more
knowledge about your current systems, and then when you move on to the Planning Phase
and need to make concrete planning decisions for project plans, you will need a great deal
of detail.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Inventory Your Current Systems
Performing an inventory is a task that can be done in parallel with the work that goes into
articulating a vision. In addition to the specific decisions that inventory information supports,
having an overall understanding of your inventory picture will help you to do the following:
 Identify high-level technical requirements and issues that must be addressed.

 Determine the technical feasibility of a possible solution by applying the identified
requirements.
 Recognize opportunities for addressing a cluster of related problems with a particular
solution.
 Identify elements that are not supported by the solution and thereby mitigate the risk
of disabling functionality. For example, you may plan to retire parts of your existing
infrastructure, but discover a system that currently relies on it, such as an older UNIX
operating system that implements Kerberos and LDAP in ways that are not
compatible with Active Directory.
 Complete a gap analysis that measures the difference between the capabilities of
your current system and the capabilities required to achieve your business goals.
 Understand the extent of the effort in terms of time, dollars, and resources required to
implement a solution.
Whether you complete your inventory at this time or delay the collection of detailed
information until the Planning Phase is underway, your inventory should focus on the following
general categories:
 User and identity management infrastructure. You should document the scale and
range of the user and identity management infrastructure currently employed within
the organization. Identify and describe all user databases and identity stores
regardless of their purpose or location.
A human resources database, for example, might be overlooked because it is not,

strictly speaking, a directory and used by an individual department at a single site.
Include this in the evaluation because it may be possible to incorporate it into the
integrated solution you create. It can be used as a source of user names for bulk
administration operations.
For each infrastructure component, you should record the technology that each
employs and its current version. In addition, you should determine which technologies
support the Kerberos or LDAP protocols and are compatible with the Active Directory
implementation of these protocols. Those that do so will require little or no
modification to take part in your integrated solution.
 Network topology. Obtain network diagrams from network managers. These should
include segment bandwidth capacities and the bandwidth capacity of the
interfaces to servers affected by this project. If possible, obtain current figures on
network utilization.
tmg.edu.au | 1300 888 TMG (1300 888 864)
This is important because a significant proportion of network traffic can be related to

authentication, authorization, and directory lookups. The current project may result in
an increase or decrease in network traffic.
Some changes made by such a project tend to decrease the network load. For
example, a single integrated directory does not require clients to query twice to
search all information, whereas a directory split between UNIX and Windows does. If
you are using a metadirectory service to keep two directories in agreement, the
synchronization traffic may be significant; it is removed by creating an integrated
system.
Other changes can increase network traffic. These include switching from using a
nonencrypted channel for retrieving authorization data to an encrypted channel to
retrieve this data, or switching from a local data store to a server-based data store.
The latter would result in increased traffic only if in the present configuration there is
no system for synchronizing data between local data stores. If there is a homegrown
tool that takes the data from a local file on computer A and synchronizes it with local
files on computers B and C, this will probably create about as much traffic as would
replacing this and migrating computers A, B, and C to using a centralized server-
based data store.
It is not possible to accurately estimate how traffic will change in response to your
solution until the Stabilizing Phase of the project. However, detailed knowledge of the
network will influence your design.
 Access control mechanisms. The access control mechanisms within your organization
determine which resources a given user can access and what actions they are
permitted to perform. Your evaluation of these mechanisms must describe how they
are implemented and used in Windows and your versions of UNIX. In particular,
document the mechanisms' support, if it is included, for the Kerberos and LDAP
protocols and whether this support is compatible with the Active Directory
implementation of these protocols. For example, if you have a RADIUS service, then
you should investigate and then document whether RADIUS user accounts can be
held in a remote LDAP directory such as Active Directory.
 Management procedures. List the administration and management procedures that
are in place pertaining to authentication, authorization, and identity management.
These procedures guarantee quality and consistency. Many of them can be carried
over into the new solution, albeit with revisions because of the new features, user
interfaces, and administrative tools. Others can be discarded. For example, if you
have dispensed with a metadirectory service because you now have a single
integrated directory, you no longer need the procedures for maintaining that service.
The following actions and events related to system and network administration
include procedures that might be affected by this project:
tmg.edu.au | 1300 888 TMG (1300 888 864)
o Management of user accounts

o Changes to access controls on resources such as files, printers, and the
directory
o Publishing information in the directories
o Modification of the directory schemas
o Changes to the configuration of authorization mechanisms
o Changes to the configuration of authentication mechanisms
Developing the Solution Concept
If the business goals and vision define what the project is expected to accomplish, the
solution concept addresses how the solution will accomplish these goals. It explains at a high
level how the solution will solve the business problem in terms of the approaches (most
importantly, the technical approach) it will take to build and deliver the solution. It includes
an early description of functionality, an initial approach to building and delivering the
solution, and project success factors and acceptance criteria. The result is the first summary
of the system that you are proposing and becomes a significant part of the vision/scope
document.
Because the solution concept will be evaluated by an audience with varying technical
expertise (IT management, customers, stakeholders, and team members), it should be written
in nontechnical language. It should not go into great technical detail; you will add the
details as part of the work of the next phase (Planning). However, the solution concept
should include enough information to inform feasibility studies, risk analysis, usability studies,
and performance analysis.
Note Solution concept is an MSF term that should not be confused with the other use of the
word solution (or technology solution) in this guide: the implementation of the end states.
This guide simplifies the process of developing the solution concept by offering five fully
developed solutions (the five end states described in Chapter 1, "Overview of Authentication
and Authorization Technologies and Solution End States"). The guide also describes
technology alternatives for achieving each end state, as shown in the following table.
Table 2.3. Alternatives for Achieving Each State
1st Decision: End State 2nd Decision: Solution Technology

End State 1 NC
OS
End State 2 NC
OS
CS (DirectControl)
tmg.edu.au | 1300 888 TMG (1300 888 864)
1st Decision: End State 2nd Decision: Solution Technology

CS (VAS)
End State 3 NC
OS
End State 4 NC
OS
End State 5 NC*
*For End State 5, the solution described in this guide uses native UNIX operating system
components; however, it is easy to extrapolate from this solution to an open source solution.
Key:
CS – commercial solution
NC – solution using native UNIX operating system components
OS – solution using native UNIX operating system plus open source components
Thus, developing a solution concept for any of the variations of the Windows security and
directory services solution offered in this guide equates to deciding first which end state is
appropriate for your situation, and then choosing the technology you will use to implement
that end state (a commercial solution, or using components included in the UNIX operating
system, or using UNIX OS in conjunction with open source components). The first decision is
discussed in this chapter, whereas the second is addressed in Chapter 1, “Choosing the Right
Technology and Planning Your Solution” of each volume in this guide.
Note One implication of this serial decision process is that scope and risk lists will be less
complete than usual when the Vision/Scope Approved Milestone meeting takes place at the
end of the Envisioning Phase because project scope will be heavily dependent upon the
solution technology that is chosen. Both the vision/scope and risk assessment documents,
however, are intended to be "living" documents that are subject to change as more
information becomes known. The completed prototype, budget, and schedule may also
result in scope modifications.
Having preconceived end states can save the work of developing a solution concept, but it
does not eliminate the need to consider several inputs to decide among them. This requires
identifying and documenting the items on the following list:
 Business problem statement

 Business goals
 Vision statement
 Assessment of current infrastructure
 Design goals
tmg.edu.au | 1300 888 TMG (1300 888 864)
 High-level requirements
 User requirements
 Constraints
 Assumptions
Note You have already done the work for the first four items in the preceding list. The
sections that follow describe how to create the others.
Identify Your Design Goals
Design goals identify how technology will be used to achieve the business goals for the
project. In most cases, it should be possible to link each design goal to one or more specific
business goals. Design goals include descriptions of:
 What the solution should enable users to do and what functionalities it will provide.
 What the final design should look like at a high level—the technologies, their
attributes, and how they interact.
 Results that are aimed for during the process of reaching the final design, such as the
impact on the production environment.
General design goals for an integrated security and directory services project may include:
 A robust yet cost-effective authentication infrastructure.

 Single sign-on, enabling users to log on to any computer or application in the
organization by using a single set of credentials.
 Sending only encrypted authentication information over the network.
 Eliminating dependence on an existing data store (for example, NIS or LDAP), thereby
eliminating any associated software licensing costs as well as platform costs.
 Providing a single directory for administrators to manage authentication and
authorization data for all accounts.
 Using standards-based protocols and interfaces, thereby increasing flexibility in
planning for future system enhancements or changes.
The following table lists common design goals as they apply to each of the end states.
Although the list is not exhaustive, it is sufficient to clarify important differences and similarities
among the five end states. You can use this table in conjunction with the preceding general
list to speed the process of identifying design goals for your project.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 2.4. Design Goals for End States (ES) 1–5
Design Goal Select ES ES ES ES ES

This 1 2 3 4 5
Goal?
Consolidate Kerberos authentication for diverse systems
into a single data store.
Consolidate LDAP authentication for diverse systems

into a single data store.
Consolidate authentication account information (but

not authorization account information) into a single
data store.
Consolidate authentication and authorization account
information into a single data store.
Retire existing authentication store and eliminate

redundant stores.
Retire existing authorization store and eliminate

redundant stores.
Enable users to access any Kerberized application in

the organization using a single set of credentials and
without needing to enter a password more than once
(single sign-on).
Enable users to acquire Kerberos credentials for single
sign-on during logon.
Adopt a consistent password policy across the

enterprise, enabling users to change passwords by
remembering just one set of rules.3,4
Do not permit authentication information (user name
and password) to be sent over the network in clear
text.1
Provide seamless logon on multiple platforms.
Use Kerberos credentials to access Kerberized

applications in alternate Kerberos realms (cross-realm
authentication).
Limit disruption to administration and user communities.
Minimize purchase of additional hardware.2

tmg.edu.au | 1300 888 TMG (1300 888 864)
Design Goal Select ES ES ES ES ES

This 1 2 3 4 5
Goal?
Minimize expansion of administration and help desk

staff with company growth.
Minimize burden of changes to client computer

configuration and applications.
Use existing UNIX Kerberos infrastructure.
Use existing Windows Kerberos infrastructure.
Use existing Windows LDAP infrastructure.
Minimize changes to the environment, applications,

client computers, and staff.
Reduce need for retraining end users.
Reduce need to make changes to Kerberized

applications.
1For End States 2, 3, and 4, you must protect your LDAP connection with Kerberos or SSL/TLS.
2This is a possible goal for all end states, depending on the existing environment, but most
likely for End State 5.
3This can be implemented for End States 1 and 2 using the instructions provided in this guide.
4This is possible in theory for End States 3 and 4, but cannot be implemented using the
instructions provided in this guide. The current state of Active Directory does not provide for
LDAP password change during logon and the UNIX passwd command must be configured
for LDAP password change. The UNIX passwd tools are not entirely functional when
configured for LDAP password change, and therefore no instructions are provided. See
Chapter 8, "Evolving a Custom Solution" for discussion and references.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Identify Your High-Level Requirements
A requirement is a condition that the solution must meet. In defining high-level requirements,
the team clarifies the vision statement by interpreting it in more concrete terms.
The high-level requirements should be brief and state only what the solution needs to
address; they should not address how the requirements will be met. They should account for
the business sponsor's, key stakeholders,' and end users' viewpoints and address the business
goals identified earlier. The requirements should also include acceptance criteria.
Each team role drives a set of high-level requirements. However, because the focus of the
Envisioning Phase is on defining and solving a business problem, the Product Management
Role takes the lead in creating them. User Experience also plays an important role in creating
requirements from the end users' viewpoints. The initial list of requirements is likely to be
broad, but the team narrows it down to requirements considered essential; the subsequent
application of constraints and results of trade-off negotiations will reduce it even further.
The following sample list reflects common high-level requirements for security and directory
services projects. You can use these to begin your list, customize them as appropriate, and
then add any others that are specific to your organization. You will also need to specify the
criteria that you will use to determine whether the requirement has been met. The
completed list should be documented in the vision/scope document. In this list, the sample
requirements are placed beneath the business goal, shown in bold, that they most obviously
support (some requirements support more than one business goal):
 Increase user productivity. Eliminate the difficulties for users associated with multiple
user accounts.
This is a barrier to user productivity that is removed when a single sign-on

authentication system is in place.
 Increase the availability of information and services to users and applications. Make
Windows services available to user and service accounts that currently exist on the
UNIX-based computers and vice versa.
 Reduce ongoing costs such as administration , help desk , licensing , support , and
hardware replacement:
o Remove the necessity to synchronize multiple directories and identity stores.
When a single directory serves the whole organization, no synchronization or

metadirectory system is required, resulting in less administration.
o Lower expenditure on hardware.
Opportunities become available to reduce the number of servers in the

system when a single directory or a single integrated authentication system is
created. Clients of any operating system can then authenticate against
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows-based servers, and Linux-based and UNIX-based servers will no

longer be required to provide security and directory services.
o Reduce administrative overhead associated with account maintenance.

 Increase the security of the organization's systems:
o Provide for encryption of all sensitive data communications.
o Implement tighter controls for authentication and access control.
o Provide a strong authentication system that can be extended to provide
secure channels for custom applications (GSS-API/SSPI).
o Provide a strong authentication system that can be extended to provide
single sign-on to such various off-the-shelf software systems as SAP, Oracle,
and Microsoft IIS, SharePoint®, and SQL Server™.
 Reduce the risk of service unavailability:
o Increase the system's resilience to failures.
If you do not make this a high-level requirement, you might create a system in
which failures have a greater effect than before. For example, the failure of
an Active Directory server might affect not only Windows users, but also Linux
and UNIX users. Redundancy should be built in, allowing for alternate
authentication and directory servers to be located and used during failure.
 Comply with new regulatory requirements , business policies , or industry best

practices:
o Meet regulatory requirements for items such as password policy and
encrypted authentication (no clear text passwords).
o Provide high uptime for critical systems.
This requirement also addresses the service unavailability business goal.
Identify User Requirements
Identifying user requirements begins with developing a detailed understanding of the ways
that different users will use the new security and directory services solution. A systematic and
efficient way to discover and list the uses is to create user profiles. The User Experience Role
does this by identifying and describing all the different types of users who will use the solution,
including system administrators who operate the solution and end users who benefit from it.
User Profiles
User profiles are descriptions of the eventual users of the solution in terms of geography,
organizational and communication structures, user functions, resource availability, and other
information that is relevant to their requirements for the solution.
For each user type, investigate how they will use the system, which features are relevant to
them, and how the planned system improves on the existing systems.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The following are example user profiles for an integrated security and directory services
solution. Each item describes a use that might apply. You can use them as starting points for
the profiles you build, adding and eliminating items as necessary.
 Windows-based workstation users:

o Have no interaction with the UNIX environment.
o Use authenticated applications hosted in the UNIX environment.
o Use authenticated applications hosted in the Windows environment.
o Use remote command-line logon to access UNIX clients or servers.
o Use a remote graphical user interface logon to access UNIX clients or servers.
o Use authentication to access services in the UNIX environment.
o Use authentication to access services in the Windows environment.
 UNIX-based workstation users:
o Have no interaction with the Windows environment.
o Use an authenticated application that is hosted in the UNIX environment.
o Use an authenticated application that is hosted in the Windows environment.
o Log on to UNIX-based workstations.
o Use local command-line logon as the primary access method to local UNIX-
based workstations.
o Use remote command-line logon to access UNIX clients or servers.
o Use a local graphical user interface logon as the primary way to access local
UNIX-based workstations.
o Use a remote graphical user interface logon to access UNIX clients or servers.
o Use authentication to access services in the Windows environment.
o Use authentication to access services in the UNIX environment.
 UNIX/Linux IT administrators:
o Maintain UNIX-based authorization and authentication identity stores.
o Maintain UNIX operating systems and hardware.
o Maintain UNIX-side configuration of application and service access.
 Windows IT administrators:
o Maintain Windows-based authorization and authentication identity stores.
o Maintain Windows operating systems and hardware.
o Maintain Windows-side configuration for application and service access.
 Help desk administrators:
o Add new users to authorization and authentication identity stores.
o Disable user accounts in authorization and authentication identity stores.
o Change user passwords.
o Assist end users with logon problems.
o Assist end users with password change problems.
The User Experience Role documents user profiles in the vision/scope document and
examines them in conjunction with the usage statistics described in the following paragraph
to formulate the user requirements for the solution. The user requirements should also be
documented. User profiles with the associated user requirements will be used by testers as
part of systematic acceptance testing.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Usage Statistics
You should document the size of the user community with respect to the platforms that will
be employed in the solution. User numbers will help prioritize user requirements and enable
you to quantify the benefits that result from implementing a heterogeneous security and
directory services solution based on Microsoft Windows Server™ 2003. For example,
quantifying the number of duplicate accounts provides an indication of the efficiency
improvements that can be made by moving to a single, unified account database and
authentication system. This information can also be helpful for decisions about scope (which
user groups to include and exclude in a solution). Examples of the statistics to quantify and
evaluate users include:
 The number of UNIX and Linux users and applications.

 The number of Windows users and applications.
 The number of cross-platform users and applications.
 The user population growth rates.
 The user transfer rates between platforms (for example, the number of UNIX users
becoming Windows users).
Identify Project Constraints
A constraint is a nonfunctional requirement that applies to various aspects of projects (such

as budget, resources, or technology) and places a limit or dictates a limited range of
possibilities. Constraints have both internal and external sources and represent an important
input in developing a solution concept because they help narrow your choice of end state.
A constraint may also present a conflict with other requirements. For example, spending limits
can preclude a requirement that would entail extensive changes to existing infrastructure.
However, you can sometimes deal with a constraint by restricting your project scope to
reduce time, resources, or parts of the environment that are affected by the project.
The following is a sample list of common project constraints. Select those that are relevant
and customize the items to apply specifically to your situation. Add additional constraints
that are not on the list when documenting them in the vision/scope document.
 Maintain system stability and existing functionality throughout the entire project,
limiting disruption to administration and user communities.
 Minimize changes to desktop configurations, applications, and environment.
 Avoid making changes to Kerberized applications.
 Minimize impact on existing authorization systems.
 Minimize purchase of additional or replacement hardware.
 Limit project costs to a specific budget.
 Minimize expansion of staff needed to support a growing infrastructure.
 Avoid creating UNIX user accounts for each Windows user who needs to access UNIX-
based services.
 Do not combine UNIX and Windows administrators into a single administration team.
 Deliver solution within time deadline required by regulations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Identify Assumptions
Assumptions are factors that are considered to be true, real, or certain but that are not yet
validated. They are either prerequisites to project success or implications of actions that
occur during the project that are key to success. The following table lists the technical
assumptions that this guidance makes for each end state. Use this list as a checklist to ensure
that the relevant assumptions are acceptable in your situation. After you have made the
choice of end state, document all applicable assumptions in the vision/scope document.
You may also want to include any nontechnical assumptions you are making that can affect
the success of the project.
Table 2.5. Assumptions That Apply to Each End State (ES)
P/I1 Assumption E E E E E
S S S S S
1 2 3 4 5
P All domain controllers are running in Windows Server 2003
domain mode.
P Host name resolution (for example, DNS) is operating

correctly.
I Active Directory will replace the current authorization data

store (for example, local files or NIS).
I Active Directory will replace the current authentication data

store.
P UNIX-based workstations are running operating systems and

OS versions that are compatible with the solution (generally
very recent OS versions)2.
P UNIX key distribution centers (KDCs) are running operating
systems and OS versions that are compatible with the solution.
P The Active Directory infrastructure is capable of supporting

the additional authentication load from the UNIX-based
workstations (for End State 5, the additional load from the
UNIX-based applications).
P The Active Directory infrastructure is capable of supporting
the additional authentication and authorization load from the
UNIX-based workstations.
I UNIX user authentication data will be migrated from the old
data store to Active Directory or will be re-created in Active
Directory.
tmg.edu.au | 1300 888 TMG (1300 888 864)
P/I1 Assumption E E E E E
S S S S S
1 2 3 4 5
I UNIX user authentication and authorization data will be
migrated from the old data store to Active Directory or will be
re-created in Active Directory.
I UNIX-based workstations and application servers will be
modified to support Kerberos authentication against Active
Directory.
modified to support LDAP authorization against Active
Directory.
modified to support LDAP authentication against Active
Directory.
I SSL/TLS will be used to secure the LDAP connection to Active
Directory.3
I Kerberos cross-realm configurations will be pushed out to all

UNIX-based workstations and application servers as needed.
All Windows-based client computers will also need to be
updated in order for them to participate in cross-realm
activities.
P UNIX-based workstations are time-synchronized with Active
Directory servers and servers running Kerberized services.
I Applications used by UNIX clients will not rely on the

authorization data found in the Windows Kerberos ticket
(PAC).
I Active Directory will not store any authorization data for the
UNIX users.
P Schema changes will be made to the Active Directory

database.4
1P indicates a prerequisite for the solution; I indicates an implication of implementing it.
2If
the open source solution is used, the version of the operating system is not as important. It
may be possible to implement the open source solution on older operating system versions.
3Therequirement for SSL depends upon the implementation selected. Some solutions support
Kerberos to secure the LDAP connection.
4Not necessarily true for Centrify DirectControl (End State 2).

tmg.edu.au | 1300 888 TMG (1300 888 864)
Select the Most Appropriate End State
At this point, you have completed the groundwork required for selecting the appropriate
end state by identifying and considering all of the inputs to your decision. The process of
compiling current state inventory information and determining requirements should have
helped to shape your thinking and may have led to a preliminary conclusion about which
solution best meets your needs. On the simplest level, the decision is a matter of identifying
the end state that best matches your business, user, and technical requirements.
One challenge in determining the best match is that requirements are generally expressed in
business terms and the end states are defined in terms of technology. Because the root
problem that the organization is trying to solve is a business problem, any conflicts that arise
need to be evaluated in terms of business results.
Participants can facilitate the decision-making process by staying focused on their areas of
expertise. Decision makers who represent the business can contribute most effectively by
ensuring that the business requirements are clear and by being prepared to assign priorities
and make tradeoff decisions from the business perspective. Technical decision-makers need
to act as interpreters by explaining the business implications of meeting or not meeting a
technical requirement so that the two types of requirements can be compared. They also
need to be able to clarify the business implications of technical alternatives when these
alternatives are not apparent. Similarly, advocates for the end-user perspective must be
prepared to articulate the business implications of user requirements.
Alternative Approaches
Different organizations will approach the end state decision in ways that vary in their
formality, rigor, and required effort. Regardless of which approach or combination of
approaches you use, the End State Selection Tool is a valuable supplement.
 You may have a "best fit" end state in mind based on what you have learned about
the end states and your organization's needs. Or you may read the sample business
scenarios, each of which has an implied best fit end state, and identify the one that
most closely matches your own situation. For these top-down approaches, you can
increase confidence in your choice by checking your lists of goals, requirements, and
constraints to ensure it meets them, and by reviewing the inventory section of your
current state infrastructure assessment to ensure that the end state is feasible. This
informal approach is faster than a more methodical approach but carries a greater
risk that an important requirement or constraint will be overlooked.
Requirements frequently conflict with each other; a set of "must have" requirements
might eliminate all possible solutions, or an otherwise-ideal solution might be ruled out
by a single requirement. In those cases, it may be possible to adjust the scope of the
project to eliminate the conflict. For example, you might determine that using
Kerberos to provide a single authentication mechanism is the best solution to a
problem, but then discover that Kerberos authentication is not supported by a small
tmg.edu.au | 1300 888 TMG (1300 888 864)
number of systems in your environment. Instead of choosing a less suitable

authentication solution, you could instead change the project scope to omit
coverage of that small set of systems.
If your unique requirements result in none of the five end states being viable even
after you have adjusted the project scope to the maximum possible degree, then
you have a further choice: you can explicitly drop requirements until the conflict is
resolved and at least one solution becomes possible, or you can broaden the solution
concept to consider bringing in additional mechanisms such as synchronization to
solve the part of the problem that conflicts, or you can cancel the project. Do not
regard cancellation as "failure"—it is the best possible choice when the alternative is
to spend a great deal of money pursuing an unobtainable solution.
 You can use the decision tree placed after this text to systematically narrow your
choices from a technical perspective. Note that the scope of the decision tree is
restricted to well-established solutions covered in this guidance, and there may be
additional authentication and authorization solutions not reflected here. The decision
flow assumes that, all else being equal, Kerberos is the most stable and robust
authentication protocol. This is the reason that it was incorporated into Active
Directory, which has a good track record as an implementation of Kerberos.
Furthermore, it is assumed that one directory is less expensive to manage than two,
and any reduction in the number of directories will save costs. Therefore, if Active
Directory is already present, the best solution is to use it. This bias and assumption lead
to End State 2 as the end state that most satisfactorily fulfills the more complete vision
of "One user name, one password, one place for user information."
Although the questions concern technical choices, they are answered by applying
the relevant business, user, and technical requirements and constraints. Working
through this decision tree will require close collaboration between business and
technical decision-makers, with technical people explaining the connections
between the technical choices and their business implications.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 2.1. Decision tree for end state decision
The End State Selection Tool
The End State Selection Tool (ESST) is a simple tool written in Excel that is intended to cut
through some of the complexity in making a decision that must take several factors into
account. It compares the end states on the basis of their capability to meet a number of
common business and technical requirements, taken as a whole. The tool uses users’ inputs
about their requirements and the importance of each requirement to show results for every
end state and suggests the "best fit" end state. Many requirements are conflicting, all of the
end states meet several of them, and no single end state meets all of them. Therefore, there
will seldom be a single suitable solution—only one that is better than the others.
The tool also highlights the desired requirements that are not met by each end state, thus
exposing the risks associated with choosing a particular end state.
The results of using the tool might show an unsatisfactory degree of differences between the
end states, or it might highlight an unacceptable risk associated with the best fit end state.
Users can then experiment with eliminating requirements or adjusting the importance
(weight) they have assigned to a requirement to achieve more differentiation in the
comparative scores, clarify the impact of a particular requirement, or eliminate a risk.
Caution The tool's list of major requirements that are collectively satisfied by the end states is
not comprehensive; the tool uses only those requirements that help discriminate among the
five end states. Thus the tool is best used to supplement other decision processes, not
supplant them.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Defining the Project Scope
Defining project scope is a matter of establishing boundaries upon the "unbounded vision."
The drivers for setting these limits include factors such as time, cost, legal constraints,
technical constraints, resource availability, and market pressures. Project scope may be
limited in terms of the features (defined as something that the user experiences) and
functions (something that the underlying system does) that it delivers. It may also be limited in
other ways, such as the systems and system components that the solution affects, the degree
of integration with other systems, and the degree of planned support.
The scope of the project:
 Defines which desired features and functions the project provides, solution trade-offs,
and out-of-scope items. Out-of-scope items should explicitly identify any users or parts
of the infrastructure, as well as solution-related services such as training, that the
project will not include.
 Distinguishes between the scope of the solution and the scope of the project in cases
where the solution is implemented in stages or requires discrete projects that are run
in parallel.
The Purpose of Scope
A clear definition of scope moves the team one step closer to a realistic plan for the project.
It does not invalidate the vision, but sets the expectations for which part of it or aspects of it
are planned to be accomplished in this project.
After the project is underway, a well-defined scope also helps prevent "scope creep"—the
gradual addition of desirable features, functions, or affected parts of the infrastructure to the
work of a project. Scope creep is a problem because it results in delays and cost overruns.
The clear distinction between "in-scope" items and "out-of-scope" items helps the team
adapt quickly to the new risks, constraints, and requirements that develop during the course
of the project. Project scope may change after it is agreed upon at the end of the
Envisioning Phase and documented in the vision/scope document, but it is important that
any changes are made deliberately, with a clear understanding of their impact and with the
explicit support of all stakeholders and the team. This is one reason for considering the
vision/scope document a living document and putting it under change control.
The concept of scope can also be used to outline a plan for implementing a desired solution
in phased projects. An initial project can restrict scope by limiting features and functions or
by limiting the user groups, applications, or parts of the infrastructure affected by the project.
Subsequent projects can be designed to accommodate budgetary and scheduling needs
of an organization by including the elements that were excluded in the first project. In a
phased solution, for instance, the first project might just cover single sign-on access to new
human resource and productivity tools.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Scope in a phased solution can even be broadly defined in terms of implementing one end
state in an initial project with the intention of implementing another end state in a later
project. End States 1 and 3, and possibly even 5, may be considered as the first step or
"phase" in moving to End State 2 or 4.
Reviews That May Help with Scope Decisions
Reviews that supplement the information gathering undertaken as part of the end state
selection process can help in making scope decisions. The discoveries made as a result of a
review could be used to limit scope. For instance, if a review determines that the
authorization data for a specific group of users is especially complex, it might be a good
plan to leave this group of users out of the first level-implementation of the solution. Following
is a list of recommended reviews:
 Review of Active Directory architecture in your environment to ensure it meets the

requirements of this solution.
 Review of domain name system (DNS) infrastructure to ensure it meets the
requirements of this solution.
 Review of time synchronization infrastructure to ensure it meets the requirements of
this solution.
 Enterprise-wide review of authorization roles.
Features and Functions In-Scope and Out-of-Scope
The following tables supply examples of features and functions that are in-scope or out-of-
scope for each end state. A "Y" in an end state column indicates that the feature or function
is in-scope and an "N" indicates that the feature or function is out-of-scope. You can use the
information to specify both in-scope and out-of-scope items for your project. However, out-
of-scope items need to be called out only when users and other stakeholders would normally
associate them with the solution.
Table 2.6. In-Scope and Out-of-Scope Features by End State (ES)
Feature Select This E E E E E

Feature? S S S S S
1 2 3 4 5
Users can easily change their passwords manually Y Y N N Y
without help desk intervention. 1 1
Users with expired passwords can change their Y Y N N N

passwords during logon. 2 2
Users can log on to computers in both Windows and Y Y Y Y N

UNIX environments with one user name and password.3
Users can access Kerberized services in both Windows Y Y N N Y
and UNIX environments without being prompted for a
user name or password.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Feature Select This E E E E E

Feature? S S S S S
1 2 3 4 5
Users can access services on UNIX and Windows Y Y Y Y N
designed to use Active Directory domain credentials for
authentication with the same user name and password
used for UNIX logon.3
Current logon steps for users will remain unchanged.4 N N N N Y
Help desk staff can troubleshoot logon and password N Y N Y Y
change issues with a minimum of training. 5 5
No changes need to be made to help desk structure or N N N N Y

staff training.
Administrators can work with a single directory to provide N Y N Y N
user authentication and authorization for both Windows
and UNIX users.
UNIX users receive a warning of impending password Y Y N N N
expiration. 6 7
Consolidation of authorization data into a single store. N Y N Y N

UNIX users on UNIX-based workstations can use group N Y N Y N
data defined in Active Directory.
Capability to log on to UNIX-based workstation using N Y N N N
cached credentials. 8
Encrypted remote access to UNIX-based N N N N N

workstations/servers without implementation of
additional tools.
Consolidation of authentication data into a single store. Y Y Y Y N
Capability to log on to UNIX-based and Windows-based Y Y Y Y N
workstations with the same user name and password.
Note Y indicates that the function is in-scope for the end state; N indicates that the function
is out-of-scope for the end state.
1Available through commercial and open source solutions.
2Not available with native Red Hat 9 solution.
3Assumes no synchronization between multiple data stores.
4In most cases, changes visible to the user are minor.
5This might be possible if a preexisting user-provisioning tool can be modified without

significant changes to the help-desk user interface.
6Available through open source solutions.
tmg.edu.au | 1300 888 TMG (1300 888 864)
7Available through commercial and open source solutions.
8True only of Vintela and Centrify solutions.
Table 2.7. In-Scope and Out-of-Scope Functions by End State (ES)
Functions Select This E E E ES E

Function? S S S S
4
1 2 3 5
Enforcement of a single password policy throughout Y Y Y Y N
the enterprise.
Authentication accomplished securely through Y Y N N Y
Kerberos.
Kerberos features could be used to provide single Y Y N N Y
sign-on.
Availability of protected access credential (PAC) on Y Y N N N
UNIX-based computers for PAC-enabled
applications.
Storage of authentication and authorization data in N Y N Y N
a user object in Active Directory.
SSL certificate management (certificates expire and N Y Y Y N
need to be renewed). 1
Use of SSL/TLS to protect user information during N Y Y Y N

logon. 1
Synchronization of passwords between Active N N N N N

Directory server and other data stores.
Synchronization of passwords between Active N N N N N
Directory server and UNIX key distribution center
(KDC).
Note Y indicates that the function is in-scope for the end state; N indicates that the function
is out-of-scope for the end state.
1For open source solutions, Kerberos instead of SSL/TLS is used to secure user data.
Other Common Ways to Limit Scope
Scope can be limited across several dimensions in addition to features and functions. The
following is a list of suggested items to consider when you are deciding how you will "bound"
your vision by limiting the scope of your current project:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Account information:
o Specific users delineated by job function, role, business group, location, or
division in your environment.
o Local UNIX accounts used for mission-critical services. (For example, for a
mission-critical transaction processing system that runs as a particular UNIX
account, you may want to consider keeping that account as a local account
instead of migrating to Active Directory.)
o Other directory information. For example, deciding whether to migrate other
information, such as automount maps and other NIS maps, stored in an LDAP
directory to Active Directory as well.
 Included systems and components:
o Specific computers delineated by function, role, business group, location, or
division in your environment.
o Specific applications in your environment.
o Single sign-on to specific applications.
o Intranet authentication and authorization.
o Extranet authentication and authorization.
o Using existing PKI, deploying internal PKI, purchasing certificates from outside
vendor.
 Degree of integration:
o Integration with or impact upon enterprise monitoring or management
systems.
 Support:
o Support for specific version of operating systems.
 Training:
o Developing help desk, administrator, end-user processes, and training.
 Miscellaneous:
o Two-factor authentication.
o Delegating credentials (authenticate to a server, and then from there
authenticate to another server or back-end service). Kerberos provides this;
most other authentication does not.
o Kerberizing existing custom application to support single sign-on, possibly
adding use of GSS-API/SSPI to provide encryption to the custom applications.
Job Aid: Vision/Scope Document
The job aids for this solution include a vision/scope document template in Microsoft Word. For
the first four sections (“Business Problem/Opportunity,” “Vision Statement,” “Solution
Concept,” and “Scope”), the template points to sections in this chapter that should be
helpful in creating the document. The fourth section, “Solution Design Strategies,” refers to
material covered in Chapter 1 of each of Volumes 2, 3, and 4 of this guide.
A completed template provides solid documentation to serve as the foundation for the
project. Depending on your situation, you may find it appropriate to take a less detailed
approach in this document. Nonetheless, it should be valuable to review the template to
ensure that important considerations have not been overlooked.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Interim Milestone: Vision/Scope Document Drafted
The project team and customer now have a document that includes a broad view of the
project, describing the problems and opportunities it addresses, the user community that
benefits, how they benefit, and the approach to provide a solution. In addition, the scope of
the project and solution are defined in terms of features included and those excluded. The
team also has a clear and shared vision that defines the purpose of the project and provides
direction.
Defining the Project Structure
The project structure document defines the approach your team will take to organize and
manage the integrated security and directory services project. It serves as an essential
reference for the project team members on how they will work together successfully. The
document contains such information as:
 Team member contact information.

 Team organization and reporting structure.
 Lists of team roles and responsibilities.
 Communication and meeting logistics.
 Procedures for elevating project issues.
Program Management takes the lead in defining the project structure. For more details, refer
to the “Project Structure Template” job aid.
Assessing Project Risks
Risk (defined as the possibility of a loss) is inherent in any project. The loss could be anything
from the diminished quality of a solution to increased cost, missed deadlines, or project
failure.
Although risks cannot be eliminated, they can be managed. Continuous and proactive risk
management, beginning with identification and prioritization (risk assessment) at the start of
the project and including control and mitigation, is essential to delivering a successful
solution.
For example, one risk associated with integrating the separate UNIX and Windows directory
systems is that it might increase the impact of failures. After the integration is complete, a
failure that previously only affected Windows users now affects UNIX users as well. The
probability of this happening can be lessened by ensuring that the Active Directory
environment is robust and that failover configuration for UNIX-based computers includes a
wide and varied Active Directory environment. Identifying this risk early enables you to plan
for its mitigation.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Risk Assessment Job Aid
The team's risk assessment activities during the Envisioning Phase result in a risk assessment
document that you can create using the “Risk Assessment Tool” job aid. This job aid contains
extensive prepopulated lists of risks that apply to your project, one list for each end state. For
each risk, the job aid defines and then specifies or explains how to calculate the following
elements: condition, consequence, probability, impact, exposure, mitigation, and
contingency. The document thus captures critical risk information: the risk description along
with the impact that it will have on the project if it occurs, the chance of the risk occurring,
and mitigation plans to reduce the chance of it occurring.
The job aid focuses on specific technical risks and is intended to jumpstart your initial
identification of risks. Consider each risk and eliminate those that do not apply to your
project. You will also need to identify and add risks that apply to your situation but which are
more general in nature, such as those related to resource availability, time windows, and
management support.
Overview of Technical Risks for an Integrated Security and Directory Services Project
The following is an overview of common types of risks you are likely to face with this project.
Possible risks are listed in more detail in the job aid.
 Service unavailability. If there is no authentication service available to a client, a user

is prevented from logging on or accessing a resource. If there is no directory server
available, a user might be unable to obtain information. Fortunately, both Kerberos
and LDAP systems can be designed in such a way that clients can find other servers if
their preferred one is down.
 Time synchronization problems. This does not significantly affect directory access, but
Kerberos is sensitive to differences in the system time of clients and servers. If a client is
unsynchronized with the server (for Kerberos functionality, clocks on the client and
server computers must be within x minutes of one another, where x is configured in
Active Directory Group Policy), no user is allowed to log on to that computer. If two
servers have time differences, trust relationships may break down, resulting in
disrupted access to resources.
 Replication interruptions. A distributed LDAP directory system, such as Active
Directory, replicates changes from one server to another so that each user is
presented with the most current information. If this fails, users are misled by data that
was not replaced with up-to-date information.
 Poor password management. If users choose insecure passwords, such as dictionary
words without numbers or other characters, attackers can crack them with relatively
little effort.
Estimating the Project Time Frame and Duration
At this time, the project team should be able to make a preliminary estimate of when the
project will begin and how long it is expected to take. Considering that detailed plans have
tmg.edu.au | 1300 888 TMG (1300 888 864)
not been made, the project duration estimate is necessarily very rough and is based on
experiences with similar or comparable projects. One important task is to identify and
account in the estimate for schedule-related constraints, such as windows of opportunity for
the work or potential conflicts with other planned events within the organization.
Closing the Envisioning Phase
The Envisioning Phase ends with the project’s first major milestone—Vision/Scope Approved.
Achieving this milestone is customarily acknowledged at a formal meeting attended by the
project team, the business sponsor, and the key stakeholders. The project team presents the
vision/scope document and an initial risk assessment. Prior to the meeting, discussions and
negotiations among these groups should have enabled them to reach consensus about the
overall direction for the project, including which features the solution will and will not include,
and a general timetable for delivery. The vision/scope document, as described throughout
the preceding sections, should reflect this consensus.
By approving the vision/scope document, the meeting attendees indicate their willingness
for the project team to proceed with the Planning Phase and signify their approval of the
following:
 The business needs that the solution is expected to meet.

 The vision for the solution.
 The design goals for the solution.
 The risks that might be incurred by undertaking the project.
The signed-off vision/scope document is now subject to change control. Your next step is to
move to the Planning Phase based on the end state solution you selected.
Activity 18
What are access control lists and how are they used to limit access to authorised users,
groups or networks?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 18
tmg.edu.au | 1300 888 TMG (1300 888 864)
Implement encryption as required by the design
Configuring Your Web Server to use encryption
Configuring your Apache Server (Linux)
The Apache server must be configured with supplementary API modules in order to support
SSL. There are many SSL software packages available. My examples are based on Apache
configured with ModSSL and OpenSSL. There are countless mailing lists and newsgroups
available to support these products. You may find these instructions helpful for some
commercial SSL software packages that are based on the Apache web server.
A few things to keep in mind: You can have multiple virtual hosts on the same server. You
can have numerous name-based virtual hosts on the same IP address. You can also have
numerous name-based virtual hosts and one (1) secure virtual host on the same IP. But - you
cannot have multiple secure virtual hosts on the same IP. The question that so many ask:
Why? The answer is: SSL works below the application layer. Name based hosts are not
defined until the application layer.
Specifically, you cannot have multiple secure virtual hosts on the same SOCKET (IP address +
port). By default, a secure host will use port 443. You can change configure your virtual host
to use a different port number with the same IP, thus creating another socket. There are
many disadvantages to this approach. The most obvious disadvantage is that if you are not
using the default port, your URL must also contain the port number to access the secure site.
Example:
 Site using default port - www.something.com - would be accessed as

https://www.something.com
 A site using port 8888 would be accessed as https://www.something.com:8888
Another disadvantage is that if you introduce more ports, you will be providing more
opportunities for port sniffing hackers. Last, if you select a port that is used by something else,
you will create conflict problem.
Define a Secure Virtual Host
Setting up virtual hosts is fairly straightforward. I will go through the basics of setting up a
secure virtual host.
In these examples, I use the .crt and .key file extensions. That is my personal way of avoiding
confusion with the various files. With Apache, you can use any extension you choose - or no
extension at all.
All of your secure virtual hosts should be contained within <IfDefine SSL> and </IfDefine SSL>,
usually located towards the end of the httpd.conf file.
tmg.edu.au | 1300 888 TMG (1300 888 864)
An example of a secure virtual host:
<VirtualHost 172.18.116.42:443>
DocumentRoot /etc/httpd/htdocs
ServerName www.somewhere.com
ServerAdmin someone@somewhere.com
ErrorLog /etc/httpd/logs/error_log
TransferLog /etc/httpd/logs/access_log
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/etc/httpd/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog /etc/httpd/logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
The directives that are the most important for SSL are the SSLEngine on, SSLCertificateFile,
SSLCertificateKeyFile, and in many cases SSLCACertificateFile directives.
SSL Engine
"SSLEngine on" - this is ModSSL's command to start SSL.
SSLCertificateFile
SSLCertificateFile Tells Apache where to find the certificate file and what it is named. The
example above shows "server.crt" as the certificate file name. This is the default that is added
when you configure ModSSL with Apache. I personally don't recommend using the default
names. Save yourself some frustration and name your certificates as servername.crt
(domainname.crt). You may also decide to use an alternative directory than the default
/etc/httpd/conf/ssl.crt or /usr/local/apache/conf/ssl.crt. Just remember to make the
necessary changes to the path.
SSLCertificateKeyFile
SSLCertificateKeyFile tells Apache the name of the private key and where to find it. The
directory defined here should have read/write permissions for root only. No one else should
have access to this directory.
tmg.edu.au | 1300 888 TMG (1300 888 864)
SSLCACertificateFile
The SSLCACertificateFile directive tells Apache where to find the Intermediate (root)
certificate. This directive may or may not be necessary depending on the CA that you are
using. This certificate is essentially a ring of trust.
Intermediate Certificate - A Certificate Authority obtains a certificate in much the same way
as you. This is known as an intermediate certificate. It basically says that the holder of the
intermediate certificate is whom they say they are and is authorized to issue certificates to
customers. Web browsers have a list of "trusted" certificate authorities that is updated with
each release. If a Certificate authority is fairly new, its intermediate certificate may not be in
the browser's list of trusted CA's. Combine this with the fact that most people don't update
their browsers very often; it could take years before a CA is recognized as trusted
automatically. The solution is to install the intermediate certificate on the server using the
SSLCACertificateFile directive. Usually, a "trusted" CA issues the intermediate certificate. If it is
not, then you may need to use the SSLCertificateChainFile directive, although this is unlikely.
Certificate Examples
Server Certificate File
-----BEGIN CERTIFICATE-----
MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm
MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1
MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UECh
MS
RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1
c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG
q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ
QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z
dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB
Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD
BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA
A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7
oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3
j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH
-----END CERTIFICATE-----
tmg.edu.au | 1300 888 TMG (1300 888 864)
Contents of the Certificate File
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1516 (0x5ec)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, O=Equifax Secure Inc, CN=Equifax Secure E-Business CA
Validity
Not Before: Jul 12 15:21:01 2000 GMT
Not After : Jun 2 22:42:34 2001 GMT
Subject: C=us, ST=ga, L=atlanta, O=Equifax, OU=Rick,
CN=172.18.116.44/Email=richard.sigle@equifax.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c8:eb:93:26:97:ca:00:ce:4c:e4:f3:fd:43:31:
cd:53:ed:b4:8a:ad:93:84:dc:7a:48:39:b5:28:57:
03:7f:a9:ac:3e:58:6a:7a:e3:52:3e:1e:52:58:a2:
6f:23:ad:bb:84:d8:88:ed:6d:a5:da:08:6b:c8:6c:
a5:4c:34:67:d8:46:1c:ca:20:50:b0:e8:54:7f:ca:
5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45:
12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a:
5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45:
12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a:
5a:2f:3b:6e:73:84:d8:d6:17:bd:12:39:34:fa:3d:
d8:a9:e8:59:3c:c2:61:c5:b3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
Netscape Cert Type:
SSL Server
X509v3 Authority Key Identifier:
keyid:5B:E0:A8:75:1C:78:02:47:71:AB:CE:27:32:E7:24:88:42:28:48:56
Signature Algorithm: md5WithRSAEncryption
87:53:74:e9:e1:a6:10:56:8c:fa:63:0e:7b:72:ff:76:4b:79:
0e:49:2a:58:ed:71:7a:bf:77:61:fa:e8:74:04:37:8c:d3:6a:
9a:3d:80:76:7a:c3:64:30:e7:1b:40:25:4e:2a:81:8b:e5:ac:
76:a4:38:67:cc:3f:93:43:e1:1d:c3:8d:ba:ed:cc:d7:aa:a4:
ab:d3:84:77:7c:8f:26:f6:dd:ba:3b:6a:99:81:e1:9e:7e:0f:
ca:a6:ff:c0:c3:59:6e:dc:a6:03:23:bf:8f:24:ff:15:ad:ac:
0d:85:fc:38:bf:d1:24:2d:1a:d3:72:55:12:95:5f:65:f0:60:
df:b1
tmg.edu.au | 1300 888 TMG (1300 888 864)
Private Key File
-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,124F61450D85A480
ELz64SV+tFSRybsHjY9NH7CP7yDHXP6xcd9FY6MVgQykTkq2h0n7j+tmpfUPbStT
6jCgm/dTYM9mpkQ3jYZBALiVD5JNJ9t1dWisxQXY/nsak8LSTN7LhUtZSfk5xSmV
Zsl4gwQS20UdBzFiJ+4qDajP/pzocSdSuQvxIHq7UzNwJsW8UYxR3I1qrDgyNXKS
db41BWH4QdNtE0p+pi9VndDzXktqZGHEvtrQTV+39DV/dwOdnGBpYBETljMO5X6t
D42xcVs0Doa1vZ6PiMCkwFNPXsPlKHZtHwEL4I3CQdiH4E0oYh3klBzlXBY4YldN
A+s4xU44FpXp5xwt9nnVPUKHPo+NpdaRK7dAcRNO3GN3+ek1ggzvEjjuWKes3RQh
PlHPuF7VWo4KeaTfTIwJWfGxz4nvwlVByPJ6Z73Mn0VcDXCkVm6+h3PLlYL0FMqM
baUyQPpw6bhfW71FO/IIQxz3R1EqkxW7OHv74uuYl8kjHXf3S6qRZEGUG/zOGLGr
mI5s2qnU69HlBObFkc6WQq0QxMq4PiUi7HhCLMkH8+wBsNNMnb75+7lQKkEhdOeE
iUMKe5kgQqfd9w8jsBH5nu+J/nCfvPdp0isQW+P3/Rrh6YMwdKnlVfNZWdGiTzpQ
ngThAGq5lit4uf4zdTIYYrs+T9I5ltjj0KgCUD4VL5/7OfnR3gcphpbHXQf0E2cz
Qwq7q7ppKwCf/x92pHi8oVevlV5Dx9NQbGhEOA5pooqD6S2xZBbPLzkUKWDEO2il
oBZ5L1jClR5jjdF2U61w7aRrL0t6luDU/aRv/fcoYes=
-----END RSA PRIVATE KEY-----
Contents of the Private Key
read RSA key

Enter PEM pass phrase:
Private-Key: (1024 bit)
modulus:
00:c8:eb:93:26:97:ca:00:ce:4c:e4:f3:fd:43:31:
cd:53:ed:b4:8a:ad:93:84:dc:7a:48:39:b5:28:57:
03:7f:a9:ac:3e:58:6a:7a:e3:52:3e:1e:52:58:a2:
6f:23:ad:bb:84:d8:88:ed:6d:a5:da:08:6b:c8:6c:
a5:4c:34:67:d8:46:1c:ca:20:50:b0:e8:54:7f:ca:
5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45:
12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a:
5a:2f:3b:6e:73:84:d8:d6:17:bd:12:39:34:fa:3d:
d8:a9:e8:59:3c:c2:61:c5:b3
publicExponent: 65537 (0x10001)
privateExponent:
00:b6:57:7d:3b:58:24:1e:a9:1b:85:e9:9c:9e:5f:
d3:3d:69:0c:21:93:37:bf:2b:2c:da:e1:6c:74:48:
cb:c7:0f:60:5f:50:74:8a:44:45:be:54:5c:5d:4e:
45:58:f6:f1:a8:b5:af:46:f2:ec:c2:bc:43:bd:28:
44:b7:ad:13:d3:ca:de:59:24:e8:fa:f8:e5:5f:45:
38:2c:a0:a3:de:98:13:d8:80:38:e1:47:53:4c:ea:
e4:66:c3:82:93:89:c3:90:83:44:e1:13:4f:74:76:
e2:c0:89:97:77:5f:33:d8:7d:27:21:52:55:c2:d7:
tmg.edu.au | 1300 888 TMG (1300 888 864)
dc:01:f9:bc:21:8d:a3:f5:c1
prime1:
00:e3:2d:6b:5e:05:6b:e1:46:e6:ab:ae:f3:8b:d0:
5f:94:5c:6f:f5:47:46:1d:4e:66:d3:7e:98:18:e0:
2c:0d:08:ca:b7:29:72:af:53:62:30:ec:be:26:1f:
cc:5a:ed:65:62:65:70:1e:18:19:61:e3:77:00:a7:
3a:9e:4e:12:93
prime2:
00:e2:69:56:78:e8:39:ff:17:db:cc:39:d7:7f:70:
41:dc:c5:59:43:16:c1:84:4c:ae:e7:5d:8a:c5:4b:
da:88:8e:03:99:7c:88:f2:8a:13:31:57:44:e0:b5:
c8:0a:60:b0:05:de:f6:9e:f2:00:ec:37:21:8d:3b:
dc:8e:c9:d4:61
exponent1:
1a:ad:6a:be:4f:c4:ab:5f:b8:16:d1:24:a8:76:7f:
c2:dc:58:09:65:a5:46:2b:be:c7:77:46:45:25:8e:
06:b9:d1:94:50:b9:b6:fd:03:ba:db:12:39:47:e2:
a7:8a:d9:2d:04:dc:75:ac:3e:ce:cf:f7:59:8c:49:
c5:ed:45:21
exponent2:
2d:4e:fd:32:06:ef:0c:40:7f:08:d8:8e:6a:7f:51:
7e:d7:b3:6c:3c:92:8f:62:35:22:31:d3:02:76:92:
8d:ff:35:73:32:bb:c9:25:9e:7f:a2:42:33:61:cd:
5d:5e:49:fb:72:ca:11:b6:c6:3e:7f:2d:e4:b0:95:
0b:b2:12:21
coefficient:
50:52:09:22:cb:fb:b2:b8:58:85:ab:1d:82:b9:6e:
d0:f6:dc:e8:ce:a6:5d:a1:ff:c8:4d:3b:2b:1c:19:
64:f0:c4:4a:bc:b2:1d:2b:2d:09:59:83:a3:9a:89:
f8:db:2c:2c:8a:bd:fd:a3:16:51:76:aa:ce:ea:85:
6b:1c:9f:f7
Restart the Web Server
The script to restart the webserver may be located in /usr/local/sbin, /usr/sbin, (where the
script is called httpd) or /usr/local/apache/bin (where the script is called apachectl). If you
are not running the server with SSL enabled, you will need to stop and start the server. You
may also write your own customized scripts to start, restart, and stop your server. As long as it
starts the SSL engine, you should be OK.
The commands are:
httpd stop
httpd startssl
httpd restart
tmg.edu.au | 1300 888 TMG (1300 888 864)
or
apachectl stop
apachectl startssl
apachectl restart
SSL/TLS Strong Encryption
Apache SSL/TLS Encryption
As an introduction this chapter is aimed at readers who are familiar with the Web, HTTP, and
Apache, but are not security experts. It is not intended to be a definitive guide to the SSL
protocol, nor does it discuss specific techniques for managing certificates in an organization,
or the important legal issues of patents and import and export restrictions. Rather, it is
intended to provide a common background to mod_ssl users by pulling together various
concepts, definitions, and examples as a starting point for further exploration.
 Cryptographic Techniques
 Certificates
 Secure Sockets Layer (SSL)
 References
Activity 19
What is the purpose of an SSL Certificate? Where do you get one from?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 19
tmg.edu.au | 1300 888 TMG (1300 888 864)
Cryptographic Techniques
Understanding SSL requires an understanding of cryptographic algorithms, message digest

functions (aka. one-way or hash functions), and digital signatures. These techniques are the
subject of entire books and provide the basis for privacy, integrity, and authentication.
Cryptographic Algorithms
Suppose Alice wants to send a message to her bank to transfer some money. Alice would
like the message to be private, since it will include information such as her account number
and transfer amount. One solution is to use a cryptographic algorithm, a technique that
would transform her message into an encrypted form, unreadable until it is decrypted. Once
in this form, the message can only be decrypted by using a secret key. Without the key the
message is useless: good cryptographic algorithms make it so difficult for intruders to decode
the original text that it isn't worth their effort.
There are two categories of cryptographic algorithms: conventional and public key.
Conventional cryptography
also known as symmetric cryptography, requires the sender and receiver to share a
key: a secret piece of information that may be used to encrypt or decrypt a
message. As long as this key is kept secret, nobody other than the sender or recipient
can read the message. If Alice and the bank know a secret key, then they can send
each other private messages. The task of sharing a key between sender and
recipient before communicating, while also keeping it secret from others, can be
problematic.
Public key cryptography
also known as asymmetric cryptography, solves the key exchange problem by

defining an algorithm which uses two keys, each of which may be used to encrypt a
message. If one key is used to encrypt a message then the other must be used to
decrypt it. This makes it possible to receive secure messages by simply publishing one
key (the public key) and keeping the other secret (the private key).
Anyone can encrypt a message using the public key, but only the owner of the private key
will be able to read it. In this way, Alice can send private messages to the owner of a key-pair
(the bank), by encrypting them using their public key. Only the bank will be able to decrypt
them.
Message Digests
Although Alice may encrypt her message to make it private, there is still a concern that
someone might modify her original message or substitute it with a different one, in order to
transfer the money to themselves, for instance. One way of guaranteeing the integrity of
tmg.edu.au | 1300 888 TMG (1300 888 864)
Alice's message is for her to create a concise summary of her message and send this to the
bank as well. Upon receipt of the message, the bank creates its own summary and
compares it with the one Alice sent. If the summaries are the same then the message has
been received intact.
A summary such as this is called a message digest, one-way function or hash function.
Message digests are used to create a short, fixed-length representation of a longer, variable-
length message. Digest algorithms are designed to produce a unique digest for each
message. Message digests are designed to make it impractically difficult to determine the
message from the digest and (in theory) impossible to find two different messages which
create the same digest -- thus eliminating the possibility of substituting one message for
another while maintaining the same digest.
Another challenge that Alice faces is finding a way to send the digest to the bank securely; if
the digest is not sent securely, its integrity may be compromised and with it the possibility for
the bank to determine the integrity of the original message. Only if the digest is sent securely
can the integrity of the associated message be determined.
One way to send the digest securely is to include it in a digital signature.
Digital Signatures
When Alice sends a message to the bank, the bank needs to ensure that the message is
really from her, so an intruder cannot request a transaction involving her account. A digital
signature, created by Alice and included with the message, serves this purpose.
Digital signatures are created by encrypting a digest of the message and other information
(such as a sequence number) with the sender's private key. Though anyone can decrypt the
signature using the public key, only the sender knows the private key. This means that only
the sender can have signed the message. Including the digest in the signature means the
signature is only good for that message; it also ensures the integrity of the message since no
one can change the digest and still sign it.
To guard against interception and reuse of the signature by an intruder at a later date, the
signature contains a unique sequence number. This protects the bank from a fraudulent
claim from Alice that she did not send the message -- only she could have signed it (non-
repudiation).
Certificates
Although Alice could have sent a private message to the bank, signed it and ensured the
integrity of the message, she still needs to be sure that she is really communicating with the
bank. This means that she needs to be sure that the public key she is using is part of the
bank's key-pair, and not an intruder's. Similarly, the bank needs to verify that the message
signature really was signed by the private key that belongs to Alice.
tmg.edu.au | 1300 888 TMG (1300 888 864)
If each party has a certificate which validates the other's identity, confirms the public key
and is signed by a trusted agency, then both can be assured that they are communicating
with whom they think they are. Such a trusted agency is called a Certificate Authority and
certificates are used for authentication.
Certificate Contents
A certificate associates a public key with the real identity of an individual, server, or other
entity, known as the subject. As shown in Table 1, information about the subject includes
identifying information (the distinguished name) and the public key. It also includes the
identification and signature of the Certificate Authority that issued the certificate and the
period of time during which the certificate is valid. It may have additional information (or
extensions) as well as administrative information for the Certificate Authority's use, such as a
serial number.
Table 1: Certificate Information

Subject Distinguished Name, Public Key
Issuer Distinguished Name, Signature
Period of Validity Not Before Date, Not After Date
Administrative Information Version, Serial Number
Extended Information Basic Constraints, Netscape Flags, etc.
A distinguished name is used to provide an identity in a specific context -- for instance, an

individual might have a personal certificate as well as one for their identity as an employee.
Distinguished names are defined by the X.509 standard [X509], which defines the fields, field
names and abbreviations used to refer to the fields (see Table 2).
Table 2: Distinguished Name Information

DN Field Abbrev. Description Example
Common Name CN Name being certified CN=Joe Average
Organization or O Name is associated with this O=Snake Oil, Ltd.
Company organization
Organizational Unit OU Name is associated with this OU=Research
organization unit, such as a Institute
department
City/Locality L Name is located in this City L=Snake City
State/Province ST Name is located in this ST=Desert
State/Province
Country C Name is located in this Country C=XZ
(ISO code)
A Certificate Authority may define a policy specifying which distinguished field names are
optional and which are required. It may also place requirements upon the field contents, as
may users of certificates. For example, a Netscape browser requires that the Common Name
for a certificate representing a server matches a wildcard pattern for the domain name of
that server, such as *.snakeoil.com.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The binary format of a certificate is defined using the ASN.1 notation [ASN1] [PKCS]. This
notation defines how to specify the contents and encoding rules define how this information
is translated into binary form. The binary encoding of the certificate is defined using
Distinguished Encoding Rules (DER), which are based on the more general Basic Encoding
Rules (BER). For those transmissions which cannot handle binary, the binary form may be
translated into an ASCII form by using Base64 encoding [MIME]. When placed between
begin and end delimiter lines (as below), this encoded version is called a PEM ("Privacy
Enhanced Mail") encoded certificate.
Example of a PEM-encoded certificate (snakeoil.crt)
-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----
Certificate Authorities
By verifying the information in a certificate request before granting the certificate, the
Certificate Authority assures itself of the identity of the private key owner of a key-pair. For
instance, if Alice requests a personal certificate, the Certificate Authority must first make sure
that Alice really is the person the certificate request claims she is.
Certificate Chains
A Certificate Authority may also issue a certificate for another Certificate Authority. When
examining a certificate, Alice may need to examine the certificate of the issuer, for each
parent Certificate Authority, until reaching one which she has confidence in. She may
decide to trust only certificates with a limited chain of issuers, to reduce her risk of a "bad"
certificate in the chain.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Creating a Root-Level CA
As noted earlier, each certificate requires an issuer to assert the validity of the identity of the
certificate subject, up to the top-level Certificate Authority (CA). This presents a problem:
who can vouch for the certificate of the top-level authority, which has no issuer? In this
unique case, the certificate is "self-signed", so the issuer of the certificate is the same as the
subject. Browsers are preconfigured to trust well-known certificate authorities, but it is
important to exercise extra care in trusting a self-signed certificate. The wide publication of a
public key by the root authority reduces the risk in trusting this key -- it would be obvious if
someone else publicized a key claiming to be the authority.
A number of companies, such as Thawte and VeriSign have established themselves as

Certificate Authorities. These companies provide the following services:
 Verifying certificate requests

 Processing certificate requests
 Issuing and managing certificates
It is also possible to create your own Certificate Authority. Although risky in the Internet
environment, it may be useful within an Intranet where the organization can easily verify the
identities of individuals and servers.
Certificate Management
Establishing a Certificate Authority is a responsibility which requires a solid administrative,

technical and management framework. Certificate Authorities not only issue certificates,
they also manage them -- that is, they determine for how long certificates remain valid, they
renew them and keep lists of certificates that were issued in the past but are no longer valid
(Certificate Revocation Lists, or CRLs).
For example, if Alice is entitled to a certificate as an employee of a company but has now
left that company, her certificate may need to be revoked. Because certificates are only
issued after the subject's identity has been verified and can then be passed around to all
those with whom the subject may communicate, it is impossible to tell from the certificate
alone that it has been revoked. Therefore when examining certificates for validity it is
necessary to contact the issuing Certificate Authority to check CRLs -- this is usually not an
automated part of the process.
Note
If you use a Certificate Authority that browsers are not configured to trust by default, it is
necessary to load the Certificate Authority certificate into the browser, enabling the browser
to validate server certificates signed by that Certificate Authority. Doing so may be
dangerous, since once loaded, the browser will accept all certificates signed by that
Certificate Authority.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Secure Sockets Layer (SSL)
The Secure Sockets Layer protocol is a protocol layer which may be placed between a
reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application
protocol layer (e.g. HTTP). SSL provides for secure communication between client and server
by allowing mutual authentication, the use of digital signatures for integrity and encryption
for privacy.
The protocol is designed to support a range of choices for specific algorithms used for
cryptography, digests and signatures. This allows algorithm selection for specific servers to be
made based on legal, export or other concerns and also enables the protocol to take
advantage of new algorithms. Choices are negotiated between client and server when
establishing a protocol session.
Table 4: Versions of the SSL protocol
Version Source Description

SSL Vendor Standard First SSL protocol for which implementations exist
v2.0 (from Netscape
Corp.)
SSL Expired Internet Draft Revisions to prevent specific security attacks, add non-
v3.0 (from Netscape RSA ciphers and support for certificate chains
Corp.) [SSL3]
TLS v1.0 Proposed Internet Revision of SSL 3.0 to update the MAC layer to HMAC,
Standard (from IETF) add block padding for block ciphers, message order
[TLS1] standardization and more alert messages.
TLS v1.1 Proposed Internet Update of TLS 1.0 to add protection against Cipher
Standard (from IETF) block chaining (CBC) attacks.
[TLS11]
TLS v1.2 Proposed Internet Update of TLS 1.2 deprecating MD5 as hash, and adding
Standard (from IETF) incompatibility to SSL so it will never negotiate the use of
[TLS12] SSLv2.
There are a number of versions of the SSL protocol, as shown in Table 4. As noted there, one
of the benefits in SSL 3.0 is that it adds support of certificate chain loading. This feature allows
a server to pass a server certificate along with issuer certificates to the browser. Chain
loading also permits the browser to validate the server certificate, even if Certificate
Authority certificates are not installed for the intermediate issuers, since they are included in
the certificate chain. SSL 3.0 is the basis for the Transport Layer Security [TLS] protocol
standard, currently in development by the Internet Engineering Task Force (IETF).
Establishing a Session
The SSL session is established by following a handshake sequence between client and server,
as shown in Figure 1. This sequence may vary, depending on whether the server is configured
tmg.edu.au | 1300 888 TMG (1300 888 864)
to provide a server certificate or request a client certificate. Although cases exist where
additional handshake steps are required for management of cipher information, this article
summarizes one common scenario. See the SSL specification for the full range of possibilities.
Note
Once an SSL session has been established, it may be reused. This avoids the performance
penalty of repeating the many steps needed to start a session. To do this, the server assigns
each SSL session a unique session identifier which is cached in the server and which the client
can use in future connections to reduce the handshake time (until the session identifier
expires from the cache of the server).
Figure 1: Simplified SSL Handshake Sequence
The elements of the handshake sequence, as used by the client and server, are listed below:
1. Negotiate the Cipher Suite to be used during data transfer

2. Establish and share a session key between client and server
3. Optionally authenticate the server to the client
4. Optionally authenticate the client to the server
The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite
supported by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A
Cipher Suite is defined by the following components:
 Key Exchange Method

 Cipher for Data Transfer
 Message Digest for creating the Message Authentication Code (MAC)
tmg.edu.au | 1300 888 TMG (1300 888 864)
These three elements are described in the sections that follow.
Key Exchange Method
The key exchange method defines how the shared secret symmetric cryptography key used
for application data transfer will be agreed upon by client and server. SSL 2.0 uses RSA key
exchange only, while SSL 3.0 supports a choice of key exchange algorithms including RSA
key exchange (when certificates are used), and Diffie-Hellman key exchange (for
exchanging keys without certificates, or without prior communication between client and
server).
One variable in the choice of key exchange methods is digital signatures -- whether or not to
use them, and if so, what kind of signatures to use. Signing with a private key provides
protection against a man-in-the-middle-attack during the information exchange used to
generating the shared key [AC96, p516].
Cipher for Data Transfer
SSL uses conventional symmetric cryptography, as described earlier, for encrypting messages
in a session. There are nine choices of how to encrypt, including the option not to encrypt:
 No encryption
 Stream Ciphers
o RC4 with 40-bit keys
o RC4 with 128-bit keys
 CBC Block Ciphers
o RC2 with 40 bit key
o DES with 40 bit key
o DES with 56 bit key
o Triple-DES with 168 bit key
o Idea (128 bit key)
o Fortezza (96 bit key)
"CBC" refers to Cipher Block Chaining, which means that a portion of the previously
encrypted cipher text is used in the encryption of the current block. "DES" refers to the Data
Encryption Standard [AC96, ch12], which has a number of variants (including DES40 and
3DES_EDE). "Idea" is currently one of the best and cryptographically strongest algorithms
available, and "RC2" is a proprietary algorithm from RSA DSI [AC96, ch13].
Digest Function
The choice of digest function determines how a digest is created from a record unit. SSL
supports the following:
 No digest (Null choice)

 MD5, a 128-bit hash
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Secure Hash Algorithm (SHA-1), a 160-bit hash
The message digest is used to create a Message Authentication Code (MAC) which is
encrypted with the message to verify integrity and to protect against replay attacks.
Handshake Sequence Protocol
The handshake sequence uses three protocols:
 The SSL Handshake Protocol for performing the client and server SSL session
establishment.
 The SSL Change Cipher Spec Protocol for actually establishing agreement on the
Cipher Suite for the session.
 The SSL Alert Protocol for conveying SSL error messages between client and server.
These protocols, as well as application protocol data, are encapsulated in the SSL Record
Protocol, as shown in Figure 2. An encapsulated protocol is transferred as data by the lower
layer protocol, which does not examine the data. The encapsulated protocol has no
knowledge of the underlying protocol.
Figure 2: SSL Protocol Stack
The encapsulation of SSL control protocols by the record protocol means that if an active
session is renegotiated the control protocols will be transmitted securely. If there was no
previous session, the Null cipher suite is used, which means there will be no encryption and
messages will have no integrity digests, until the session has been established.
Data Transfer
The SSL Record Protocol, shown in Figure 3, is used to transfer application and SSL Control
data between the client and server, where necessary fragmenting this data into smaller
units, or combining multiple higher level protocol data messages into single units. It may
compress, attach digest signatures, and encrypt these units before transmitting them using
tmg.edu.au | 1300 888 TMG (1300 888 864)
the underlying reliable transport protocol (Note: currently, no major SSL implementations
include support for compression).
Figure 3: SSL Record Protocol
Securing HTTP Communication
One common use of SSL is to secure Web HTTP communication between a browser and a
webserver. This does not preclude the use of non-secured HTTP - the secure version (called
HTTPS) is the same as plain HTTP over SSL, but uses the URL scheme https rather than http, and
a different server port (by default, port 443). This functionality is a large part of what mod_ssl
provides for the Apache webserver.
Configure advanced network service security options for services and remote access
Security Options in Windows
The Security Options section of Group Policy configures computer security settings for digital
data signatures, Administrator and Guest account names, access to floppy disk and CD
drives, driver installation behavior, and logon prompts.
Security Options Settings
You can configure the security options settings in the following location within the Group
Policy Object Editor:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
tmg.edu.au | 1300 888 TMG (1300 888 864)
Accounts: Administrator account status
This policy setting enables or disables the Administrator account for normal operational
conditions. If you start a computer in Safe Mode, the Administrator account is always
enabled, regardless of how you configure this policy setting.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
The built-in Administrator account cannot be locked out no matter how many failed logons it
accrues, which makes it a prime target for brute force attacks that attempt to guess
passwords. Also, this account has a well-known security identifier (SID), and there are non-
Microsoft tools that allow authentication by using the SID rather than the account name.
Therefore, even if you rename the Administrator account, an attacker could launch a brute
force attack by using the SID to log on. All other accounts that are members of the
Administrator's group have the safeguard of locking the account out if it has exceeded the
maximum number of failed logons.
Countermeasure
Disable the Accounts: Administrator account status setting so that the built-in Administrator
account cannot be used in a normal system startup.
If it is very difficult to maintain a regular schedule for periodic password changes for local
accounts, you may want to disable the built-in Administrator account instead of relying on
regular password changes to protect it from attack.
Potential impact
Maintenance issues can arise under certain circumstances if you disable the Administrator
account. For example, if the secure channel between a member computer and the domain
controller fails in a domain environment for any reason and there is no other local
Administrator account, you must restart in Safe Mode to fix the problem that caused the
secure channel to fail.
If the current Administrator password does not meet the password requirements, you cannot
re-enable the Administrator account after it is disabled. If this situation occurs, another
member of the Administrators group must set the password on the Administrator account
with the Local Users and Groups tool.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Accounts: Guest account status
This policy setting enables or disables the Guest account.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
The default Guest account allows unauthenticated network users to log on as Guest with no
password. These unauthorized users could access any resources that are accessible to the
Guest account over the network. This capability means that any shared folders with
permissions that allow access to the Guest account, the Guests group, or the Everyone
group will be accessible over the network, which could lead to the exposure or corruption of
data.
Countermeasure
Disable the Accounts: Guest account status setting so that the built-in Guest account cannot
be used.
Potential impact
All network users will need to be authenticated before they can access shared resources. If
you disable the Guest account and the Network Access: Sharing and Security Model option
is set to Guest Only, network logons, such as those performed by the Microsoft Network
Server (SMB Service), will fail. This policy setting should have little impact on most
organizations because it is the default setting in Microsoft Windows® 2000, Windows XP,
Windows Vista®, and Windows Server® 2003.
Accounts: Limit local account use of blank passwords to console logon only
This policy setting enables or disables remote interactive logons by network services such as
Terminal Services, Telnet, and File Transfer Protocol (FTP) for local accounts that have blank
passwords. If you enable this policy setting, a local account must have a non-blank password
to perform an interactive or network logon from a remote client.
Possible values:
 Enabled
 Disabled
 Not Defined
tmg.edu.au | 1300 888 TMG (1300 888 864)
Caution
This policy setting does not affect interactive logons that are performed physically at the
console or logons that use domain accounts. It is possible for non-Microsoft applications that
use remote interactive logons to bypass this policy setting.
Vulnerability
Blank passwords are a serious threat to computer security and should be forbidden through
both organizational policy and suitable technical measures. In fact, the default settings for
Windows Server 2003 Active Directory® directory service domains require complex passwords
of at least seven characters. However, if users with the ability to create new accounts bypass
your domain-based password policies, they could create accounts with blank passwords. For
example, a user could build a stand-alone computer, create one or more accounts with
blank passwords, and then join the computer to the domain. The local accounts with blank
passwords would still function. Anyone who knows the name of one of these unprotected
accounts could then use it to log on.
Countermeasure
Enable the Accounts: Limit local account use of blank passwords to console logon only
setting.
Potential impact
None. This is the default configuration.
Accounts: Rename administrator account
This policy setting determines whether a different account name is associated with the SID for
the Administrator account.
Possible values:
 User-defined text
 Not Defined
Vulnerability
The Administrator account exists on all computers that run the Windows 2000, Windows
Server 2003, or Windows XP Professional operating systems. If you rename this account, it is
slightly more difficult for unauthorized persons to guess this privileged user name and
password combination. In Windows Vista, the person who installs the operating system
specifies an account that is the first member of the Administrator group and has full rights to
configure the computer. The account may not have the name Administrator, so this
countermeasure is applied by default on new Windows Vista installations. If a computer is
tmg.edu.au | 1300 888 TMG (1300 888 864)
upgraded from a previous version of Windows to Windows Vista, the account with the name
Administrator is retained with all rights and privileges that were defined for the account in the
previous installation.
The built-in Administrator account cannot be locked out, regardless of how many times an
attacker might use a bad password. This capability makes the Administrator account a
popular target for brute force attacks that attempt to guess passwords. The value of this
countermeasure is lessened because this account has a well-known SID, and there are non-
Microsoft tools that allow authentication by using the SID rather than the account name.
Therefore, even if you rename the Administrator account, an attacker could launch a brute
force attack by using the SID to log on.
Countermeasure
Specify a new name in the Accounts: Rename administrator account setting to rename the
Administrator account.
Potential impact
You need to provide users who are authorized to use this account with the new account
name. (The guidance for this setting assumes that the Administrator account was not
disabled, which was recommended earlier in this section.)
Accounts: Rename guest account
This policy setting determines the account name is associated with the SID for the Guest
account.
Possible values:
 Not Defined
Vulnerability
The Guest account exists on all computers that run the Windows 2000, Windows Server 2003,
Windows XP Professional, or Windows Vista operating systems. Because the account name is
well known it provides a vector for a malicious user to get access to network resources and
attempt to elevate privileges or install software that could be used for a later attack on your
system.
Countermeasure
Specify a new name in the Accounts: Rename guest account setting to rename the Guest
account. If you rename this account, it is slightly more difficult for unauthorized persons to
guess this privileged user name and password combination.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Potential impact
There should be little impact, because the Guest account is disabled by default in
Windows 2000, Windows XP, Windows Vista, and Windows Server 2003.
Audit: Audit the access of global system objects
If you enable this policy setting, a default system access control list (SACL) is applied when
the computer creates system objects such as mutexes, events, semaphores, and MS-DOS®
devices. If you also enable the Audit object access audit setting, access to these system
objects is audited.
Global system objects, also known as "base system objects" or "base named objects," are
temporary kernel objects that have had names assigned to them by the application or
system component that created them. These objects are most commonly used to
synchronize multiple applications or multiple parts of a complex application. Because they
have names, these objects are global in scope, and therefore visible to all processes on the
computer. These objects all have a security descriptor but typically have a NULL SACL. If you
enable this policy setting at startup time, the kernel will assign a SACL to these objects when
they are created.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
A globally visible named object, if incorrectly secured, could be acted upon by malicious
software that knows the name of the object. For instance, if a synchronization object such as
a mutex had a poorly chosen discretionary access control list (DACL), then malicious
software could access that mutex by name and cause the program that created it to
malfunction. However, the risk of such an occurrence is very low.
Countermeasure
Enable the Audit: Audit the access of global system objects setting.
Potential impact
If you enable the Audit: Audit the access of global system objects setting, a large number of
security events could be generated, especially on busy domain controllers and application
servers. Such an occurrence could cause servers to respond slowly and force the Security log
to record numerous events of little significance. This policy setting can only be enabled or
disabled, and there is no way to choose which events are recorded. Even organizations that
tmg.edu.au | 1300 888 TMG (1300 888 864)
have the resources to analyze events that are generated by this policy setting would not
likely have the source code or a description of what each named object is used for.
Therefore, it is unlikely that most organizations would benefit by enabling this policy setting.
Audit: Audit the use of Backup and Restore privilege
This policy setting enables or disables auditing of the use of all user privileges, including
Backup and Restore, when the Audit privilege use setting is in effect. If you enable both
policy settings, an audit event is generated for every file that is backed up or restored.
If you enable this policy setting in conjunction with the Audit privilege use setting, any
exercise of user rights is recorded in the Security log. If you disable this policy setting, actions
by users of Backup or Restore privileges are not audited, even if Audit privilege use is
enabled.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
When backup and restore is used, it creates a copy of the file system that is identical to the
target of the backup. Making regular backups and restore volumes is an important part of a
your incident response plan, but a malicious user could use a legitimate backup copy to get
access to information or spoof a legitimate network resource to compromise your enterprise.
Countermeasure
Enable the Audit: Audit the use of Backup and Restore privilege setting. Alternatively,
implement automatic log backup by configuring the AutoBackupLogFiles registry key. If you
enable this option when the Audit privilege use setting is also enabled, an audit event is
generated for every file that is backed up or restored. This information could help you to
identify an account that was used to accidentally or maliciously restore data in an
unauthorized manner.
For more information about configuring this key, see article 100879, The event log stops
logging events before reaching the maximum log size, in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=100879).
Potential impact
If you enable this policy setting, a large number of security events could be generated,
which could cause servers to respond slowly and force the Security event log to record
tmg.edu.au | 1300 888 TMG (1300 888 864)
numerous events of little significance. If you increase the Security log size to reduce the
chances of a system shutdown, an excessively large log file may affect system performance.
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit
policy category settings
Windows Vista and Windows Server 2008 allow audit policy to be managed in a more precise
way by using audit policy subcategories. Setting audit policy at the category level will
override the new subcategory audit policy feature. A new registry value introduced in
Windows Vista, SCENoApplyLegacyAuditPolicy, allows audit policy to be managed by using
subcategories without requiring a change to Group Policy. This registry value can be set to
prevent the application of category-level audit policy from Group Policy and from the Local
Security Policy administrative tool.
In Windows Vista there are 40 new auditing subcategories that enable you to get more
precise details about activities on a computer. The following table provides a list of these
subcategories:
Category– Description Default

Subcategory Setting
System–Security Reports the loading of extension code such as No
System Extension authentication packages by the security subsystem. Auditing
System–System Reports on violations of integrity of the security Success
Integrity subsystem. and
Failure
System–IPsec Driver Reports on the activities of the Internet Protocol security No
(IPsec) driver. Auditing
System–Other Reports on other system events. Success
System Events and
Failure
System–Security Reports changes in security state of the system, such as Success
State Change when the security subsystem starts and stops.
Logon/Logoff– Reports when a user attempts to log on to the system. Success
Logon
Logon/Logoff– Reports when a user logs off from the system. Success
Logoff
Logon/Logoff– Reserved for future use. No
Account Lockout Auditing
Logon/Logoff–IPsec Reports the results of Internet Key Exchange (IKE) No
Main Mode protocol and Authenticated Internet Protocol (AuthIP) Auditing
during Main Mode negotiations.
Logon/Logoff–IPsec Reports the results of IKE protocol and AuthIP during No
Quick Mode Quick Mode negotiations. Auditing
Logon/Logoff–IPsec Reports the results of AuthIP during Extended Mode No
Extended Mode negotiations. Auditing
tmg.edu.au | 1300 888 TMG (1300 888 864)

Subcategory Setting
Logon/Logoff– Reports when a special logon is used. A special logon is Success
Special Logon a logon that has administrator-equivalent privileges
and can be used to elevate a process to a higher level.
Logon/Logoff– Reports events generated by RADIUS (IAS) and Network No
Network Policy Access Protection (NAP) user access requests. These Auditing
Server requests can be Grant, Deny, Discard, Quarantine,
Lock, and Unlock. Auditing this setting will result in a
medium or high volume of records on NPS and IAS
servers.
Logon/Logoff–Other Reports other logon/logoff-related events, such as No
Logon/Logoff Events Terminal Services session disconnects and reconnects, Auditing
using RunAs to run processes under a different account,
and locking and unlocking a workstation.
Object Access–File Reports file system objects are accessed. Only file No
System system objects with SACLs cause audit records to be Auditing
generated, and only when they are accessed in a
manner matching their SACL.
Object Access– Reports when registry objects are accessed. Only No
Registry registry objects with SACLs cause audit records to be Auditing
manner matching their SACL.
Object Access– Reports when kernel objects such as processes and No
Kernel Object mutexes are accessed. Only kernel objects with SACLs Auditing
cause audit records to be generated, and only when
they are accessed in a manner matching their SACL.
Typically kernel objects are only given SACLs if the
AuditBaseObjects or AuditBaseDirectories auditing
options are enabled.
Object Access–SAM Reports when SAM objects are accessed. No
Auditing
Object Access– Reports when Certification Services operations are No
Certification performed. Auditing
Services
Object Access– Reports when applications attempt to generate audit No
Application events by using the Windows auditing application Auditing
Generated programming interfaces (APIs).
Object Access– Reports when a handle to an object is opened or No
Handle closed. Only objects with SACLs cause these events to Auditing
Manipulation be generated, and only if the attempted handle
operation matches the SACL. Handle Manipulation
events are only generated for object types where the
corresponding Object Access subcategory is enabled;
for example, File System or Registry.
tmg.edu.au | 1300 888 TMG (1300 888 864)

Subcategory Setting
Object Access–File Reports when a file share is accessed. No
Share Auditing
Object Access– Reports the when packets are dropped by Windows No
Filtering Platform Filtering Platform (WFP). These events can have a very Auditing
Packet Drop high volume.
Object Access– Reports when connections are allowed or blocked by No
Filtering Platform Windows Filtering Platform (WFP). These events can Auditing
Connection have a high volume.
Object Access– Reports other object access-related events such as Task No
Other Object Scheduler jobs and COM+ objects. Auditing
Access Events
Detailed Tracking– Reports when a process terminates. No
Process Termination Auditing
Detailed Tracking– Reports encrypt or decrypt calls into the data No
DPAPI Activity protections application programming interface Auditing
(DPAPI). DPAPI is used to protect secret information
such as stored password and key information.
Detailed Tracking– Reports remote procedure call (RPC) connection No
RPC Events events. Auditing
Detailed Tracking– Reports the creation of a process and the name of the No
Process Creation program or user that created it. Auditing
Policy Change– Reports changes in audit policy including SACL Success
Audit Policy Change changes.
Policy Change– Reports changes in authentication policy. Success
Authentication
Policy Change
Policy Change– Reports changes in authorization policy including No
Authorization Policy permissions (DACL) changes. Auditing
Change
Policy Change– Reports changes in policy rules used by the Microsoft No
MPSSVC Rule-Level Protection Service (MPSSVC.exe). This service is used by Auditing
Policy Change Windows Firewall.
Policy Change– Reports the addition and removal of objects from No
Filtering Platform Windows Filtering Platform (WFP), including startup Auditing
Policy Change filters. These events can have a very high volume.
Policy Change– Reports other types of security policy changes such as No
Other Policy configuration of the Trusted Platform Module (TPM) or Auditing
Change Events cryptographic providers.
Account Reports each event of user account management, Success
Management–User such as when a user account is created, changed,
Account deleted, renamed, disabled, or enabled or when a
Management password is set or changed.
tmg.edu.au | 1300 888 TMG (1300 888 864)

Subcategory Setting
User Account Reports each event of computer account No
Management– management, such as when a computer account is Auditing
Computer Account created, changed, deleted, renamed, disabled, or
Management enabled.
User Account Reports each event of security group management, Success
Management– such as when a security group is created, changed, or
Security Group deleted or when a member is added to or removed
Management from a security group.
User Account Reports each event of distribution group management, No
Management– such as when a distribution group is created, changed, Auditing
Distribution Group or deleted or when a member is added to or removed
Management from a distribution group.
User Account Reports each event of application group management No
Management– on a computer, such as when an application group is Auditing
Application Group created, changed, or deleted or when a member is
Management added to or removed from an application group.
User Account Reports other account management events. No
Management–Other Auditing
Account
Management
Events
DS Access–Directory Reports changes to objects in Active Directory Domain No
Service Changes Services (AD DS). DS Change auditing, where Auditing
appropriate, indicates the old and new values of the
changed properties of the objects that were changed.
Only objects with SACLs cause an audit to be
manner that matches their SACL. Some objects and
properties do not cause an audit to be generated due
to settings on the object class in the schema.
DS Access–Directory Reports when replication between two domain No
Service Replication controllers begins and ends. Auditing
DS Access–Detailed Reports detailed information about the information No
Directory Service replicating between domain controllers. These events Auditing
Replication can have a very high volume.
DS Access–Directory Reports when an AD DS object is accessed. Only No
Service Access objects with SACLs cause audit to be generated, and Auditing
only when they are accessed in a manner that
matches their SACL. These events are similar to the
directory service access events in Windows 2000 Server.
Account Logon– Reports the results of validation tests on Kerberos tickets No
Kerberos Ticket submitted for a user account logon request. Auditing
Events
tmg.edu.au | 1300 888 TMG (1300 888 864)

Subcategory Setting
Account Logon– Reports the events that occur in response to credentials No
Other Account submitted for a user account logon request that do not Auditing
Logon Events relate to credential validation or Kerberos tickets.
Account Logon– Reports the results of validation tests on credentials No
Credential submitted for a user account logon request. Auditing
Validation
Privilege Use– Reports when a user account or service uses a sensitive No
Sensitive Privilege privilege. A sensitive privilege includes the following user Auditing
Use rights: Act as part of the operating system, Back up files
and directories, Create a token object, Debug
programs, Enable computer and user accounts to be
trusted for delegation, Generate security audits,
Impersonate a client after authentication, Load and
unload device drivers, Manage auditing and security
log, Modify firmware environment values, Replace a
process-level token, Restore files and directories, and
Take ownership of files or other objects. Auditing this
subcategory will create a high volume of events.
Privilege Use–Non- Reports when a user account or service uses a non- No
Sensitive Privilege sensitive privilege. A non-sensitive privilege includes the Auditing
Use following user rights: Access Credential Manager as a
trusted caller, Access this computer from the network,
Add workstations to domain, Adjust memory quotas for
a process, Allow log on locally, Allow log on through
Terminal Services, Bypass traverse checking, Change
the system time, Create a pagefile, Create global
objects, Create permanent shared objects, Create
symbolic links, Deny access this computer from the
network, Deny log on as a batch job, Deny log on as a
service, Deny log on locally, Deny log on through
Terminal Services, Force shutdown from a remote
system, Increase a process working set, Increase
scheduling priority, Lock pages in memory, Log on as a
batch job, Log on as a service, Modify an object label,
Perform volume maintenance tasks, Profile single
process, Profile system performance, Remove
computer from docking station, Shut down the system,
and Synchronize directory service data. Auditing this
subcategory will create a very high volume of events.
Privilege Use–Other This category is reserved for future use. No events are No
Privilege Use currently mapped to this subcategory. Auditing
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
Prior to the introduction of auditing subcategories in Windows Vista, it was difficult to track
events at a per-system or per-user level. The larger event categories created too many
events and the key information that needed to be audited was difficult to find.
Countermeasure
Enable audit policy subcategories as needed to track specific events.
Potential impacts
The individual audit policy subcategories that are available in Windows Vista are not
exposed in the interface of Group Policy tools. Administrators can deploy a custom audit
policy that applies detailed security auditing settings to Windows Vista–based client
computers in a Windows Server 2003 domain or in a Windows 2000 domain. If after enabling
this setting, you attempt to modify an auditing setting by using Group Policy, the Group
Policy auditing setting will be ignored in favor of the custom policy setting. To modify auditing
settings by using Group Policy, you must first disable this key.
Important
Be very cautious about audit settings that can generate a large volume of traffic. For
example, if you enable either success or failure auditing for all of the Privilege Use
subcategories, the high volume of audit events generated can make it difficult to find other
types of entries in the Security log. Such a configuration could also have a significant impact
on system performance.
Audit: Shut down system immediately if unable to log security audits
This policy setting enables or disables shutting down the computer if it is unable to log security
events. The Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria
certifications require that the computer be able to prevent the occurrence of auditable
events if the audit system is unable to log them. The way Windows meets this requirement is
to halt the computer and display a stop message if the audit system fails. If you enable this
policy setting, the computer stops if a security audit cannot be logged for any reason.
Typically, an event fails to be logged when the Security log is full and its specified retention
method is either Do Not Overwrite Events or Overwrite Events by Days.
When this policy setting is enabled, the following Stop message displays if the security log is
full and an existing entry cannot be overwritten:
STOP: C0000244 {Audit Failed}
An attempt to generate a security audit failed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
To recover, an administrator must log on, archive the log (optional), clear the log, and
disable this option to allow the computer to be restarted. At that point, it may be necessary
to manually clear the Security log before you can configure this policy setting to Enabled.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
If the computer is unable to record events to the Security log, critical evidence or important
troubleshooting information may not be available for review after a security incident. Also,
an attacker could potentially generate a large volume of Security log events to purposely
force a computer shutdown.
Countermeasure
Enable the Audit: Shut down system immediately if unable to log security audits setting to
ensure that security auditing information is captured for review.
Potential impact
If you enable this policy setting, the administrative burden can be significant, especially if you
also configure the Retention method for the Security log to Do not overwrite events (clear log
manually). This configuration causes a repudiation threat (a backup operator could deny
that they backed up or restored data) to become a denial of service (DoS) vulnerability,
because a server could be forced to shut down if it is overwhelmed with logon events and
other security events that are written to the Security log. Also, because the shutdown is
abrupt, it is possible that irreparable damage to the operating system, applications, or data
could result. Although the NTFS file system maintains its integrity when this type of computer
shutdown occurs, it cannot guarantee that every data file for every application will still be in
a usable form when the computer restarts.
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL)
This policy setting allows administrators to define additional computer-wide access controls
that govern access to all Distributed Component Object Model (DCOM)–based applications
on a computer. These controls restrict call, activation, or launch requests on the computer.
The simplest way to think about these access controls is as an additional access check call
that is done against a computer-wide access control list (ACL) on each call, activation, or
launch of any COM server on the computer. If the access check fails, the call, activation, or
launch request is denied. (This check is in addition to any access check that is run against the
server-specific ACLs.) In effect, it provides a minimum authorization standard that must be
tmg.edu.au | 1300 888 TMG (1300 888 864)
passed to access any COM server on the computer. This policy setting controls access
permissions to cover call rights.
These computer-wide ACLs provide a way to override weak security settings that are
specified by a specific application through CoInitializeSecurity or application-specific
security settings. They provide a minimum security standard that must be passed, regardless
of the settings of the specific server.
These ACLs also provide a centralized location for an administrator to set general
authorization policy that applies to all COM servers on the computer.
This policy setting allows you to specify an ACL in two different ways. You can type in the
security descriptor in SDDL, or you can choose users and groups and grant or deny them
Local Access and Remote Access permissions. We recommend that you use the built-in user
interface to specify the ACL contents that you want to apply with this setting.
The default ACL settings vary depending on the version of Windows you are running. To learn
more about ACLs, see the following resources:
 In Windows Vista these ACLs are modified to provide support for User Account
Control. For an overview of these changes, see New ACLs Improve Security in
Windows Vista (http://go.microsoft.com/fwlink/?LinkId=100880).
 For information about the default ACLs in Windows Server 2003, you can download
Default Access Control Settings in Windows Server 2003
(http://go.microsoft.com/fwlink/?LinkID=36346).
 For information about the restrictions that are applied in Windows Server 2003 with
SP1, see the "DCOM Security Enhancements" section
(http://go.microsoft.com/fwlink/?LinkId=111965) in the "Changes to Functionality in
Microsoft Windows Server 2003 Service Pack 1" document.
 For more information about launch permissions, see LaunchPermission
Vulnerability
Many COM applications include some security-specific code (for example, to call
CoInitializeSecurity) but use weak settings that often allow unauthenticated access to the
process. Administrators cannot override these settings to force stronger security in earlier
versions of Windows without modifying the application. An attacker could attempt to exploit
weak security in an individual application by attacking it through COM calls.
Also, COM infrastructure includes the Remote Procedure Call System Service (RPCSS), a
system service that runs during and after computer startup. This service manages activation
of COM objects and the running object table, and provides helper services to DCOM
remoting. It exposes RPC interfaces that can be called remotely. Because some COM servers
allow unauthenticated remote access, these interfaces can be called by anyone, including
tmg.edu.au | 1300 888 TMG (1300 888 864)
unauthenticated users. As a result, RPCSS can be attacked by malicious users who use
remote, unauthenticated computers.
Countermeasure
To protect individual COM-based applications or services, set the DCOM: Machine Access
Restrictions in Security Descriptor Definition Language (SDDL) setting to an appropriate
computer-wide ACL.
Potential impact
Windows operating systems implement default COM ACLs when they are installed. Modifying
these ACLs from the default may cause some applications or components that
communicate by using DCOM to fail. If you implement a COM server and you override the
default security settings, confirm that the application-specific call permissions ACL assigns
correct permission to appropriate users. If it does not, you need to change your application-
specific permission ACL to provide appropriate users with activation rights so that
applications and Windows components that use DCOM do not fail.
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)
This policy setting is similar to the DCOM: Machine Access Restrictions in Security Descriptor
Definition Language (SDDL) setting in that it allows administrators to define additional
computer-wide access controls that govern access to all DCOM–based applications on a
computer. However, the ACLs that are specified in this policy setting control local and
remote COM launch requests (not access requests) on the computer. The simplest way to
think about this access control is as an additional access check call that is done against a
computer-wide ACL on each launch of any COM server on the computer. If the access
check fails, the call, activation, or launch request will be denied. (This check is in addition to
any access check that is run against the server-specific ACLs.) In effect, it provides a
minimum authorization standard that must be passed to launch any COM server on the
computer. The DCOM: Machine Access Restrictions in Security Descriptor Definition
Language (SDDL) policy differs in that it provides a minimum access check that is applied to
attempts to access an already launched COM server.
These computer-wide ACLs provide a way to override weak security settings that are
specified by a specific application through CoInitializeSecurity or application-specific
security settings. They provide a minimum security standard that must be passed, regardless
of the settings of the specific COM server. These ACLs provide a centralized location for an
administrator to set general authorization policy that applies to all COM servers on the
computer.
The DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL)
setting allows you to specify an ACL in two different ways. You can type the security
descriptor in SDDL, or you can choose users and groups and grant or deny them Local
tmg.edu.au | 1300 888 TMG (1300 888 864)
Access and Remote Access permissions. We recommend that you use the built-in user
interface to specify the ACL contents that you want to apply with this setting.
The default ACL settings vary depending on the version of Windows you are running. To learn
more about ACLs, see the following resources:
 In Windows Vista these ACLs are modified to provide support for User Account
Control. For an overview of these changes, see
http://go.microsoft.com/fwlink/?LinkId=100880.
 For information about the default ACLs in Windows Server 2003, you can download
Default Access Control Settings in Windows Server 2003
(http://go.microsoft.com/fwlink/?LinkID=36346).
 For information about the restrictions that are applied in Windows Server 2003 with
SP1, see the "DCOM Security Enhancements" section
(http://go.microsoft.com/fwlink/?LinkId=111965) in the "Changes to Functionality in
Microsoft Windows Server 2003 Service Pack 1" document.
 For more information about launch permissions, see LaunchPermission
Vulnerability
Many COM applications include some security-specific code (for example, to call
CoInitializeSecurity) but use weak settings that often allow unauthenticated access to the
process. Administrators cannot override these settings to force stronger security in earlier
versions of Windows without modifying the application. An attacker could attempt to exploit
weak security in an individual application by attacking it through COM calls.
Also, COM infrastructure includes the RPCSS, a system service that runs during computer
startup and always runs after that. This service manages activation of COM objects and the
running object table and provides helper services to DCOM remoting. It exposes RPC
interfaces that can be called remotely. Because some COM servers allow unauthenticated
remote component activation, these interfaces can be called by anyone, including
unauthenticated users. As a result, RPCSS can be attacked by malicious users using remote,
unauthenticated computers.
Countermeasure
To protect individual COM-based applications or services, set this policy setting to an

appropriate computer-wide ACL.
Potential impact
Windows operating systems implement default COM ACLs when they are installed. Modifying
these ACLs from the default may cause some applications or components that
communicate by using DCOM to fail. If you implement a COM server and you override the
default security settings, confirm that the application-specific launch permissions ACL assigns
tmg.edu.au | 1300 888 TMG (1300 888 864)
activation permission to appropriate users. If it does not, you need to change your
application-specific launch permission ACL to provide appropriate users with activation rights
so that applications and Windows components that use DCOM do not fail.
Devices: Allow undock without having to log on
This policy setting enables or disables the ability of a user to remove a portable computer
from a docking station without logging on. If you enable this policy setting, users can press a
docked portable computer's physical eject button to safely undock the computer. If you
disable this policy setting, the user must log on to receive permission to undock the
computer. Only users who have the Remove Computer from Docking Station privilege can
obtain this permission.
Note
You should only disable this policy setting for portable computers that cannot be
mechanically undocked. Computers that can be mechanically undocked can be
physically removed by the user whether or not they use the Windows undocking
functionality.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
If this policy setting is enabled, anyone with physical access to portable computers in
docking stations could remove them and possibly tamper with them.
Countermeasure
Disable the Devices: Allow undock without having to log on setting.
Potential impact
Users who have docked their computers will have to log on to the local console before they
can undock their computers. For computers that do not have docking stations, this policy
setting will have no impact.
Devices: Allowed to format and eject removable media
This policy setting determines who is allowed to format and eject removable media.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Possible values:
 Administrators
 Administrators and Power Users
 Administrators and Interactive Users
 Not Defined
Vulnerability
Users may be able to move data on removable disks to a different computer where they
have administrative privileges. The user could then take ownership of any file, grant
themselves full control, and view or modify any file. The fact that most removable storage
devices will eject media by pressing a mechanical button diminishes the advantage of this
policy setting.
Countermeasure
Configure the Devices: Allowed to format and eject removable media setting to
Administrators.
Potential impact
Only administrators will be able to format and eject removable media. If users are in the
habit of using removable media for file transfers and storage, they will need to be informed
of the change in policy.
Devices: Prevent users from installing printer drivers
This policy setting determines who is allowed to install a printer driver when adding a network
printer. For a computer to print to a network printer, that network printer driver must be
installed on the local computer. If you enable this policy setting, only members of the
Administrators and Power Users groups are allowed to install a printer driver when they add a
network printer. If you disable this policy setting, any user can install printer drivers when they
add a network printer. This policy setting prevents typical users from downloading and
installing untrusted printer drivers.
Note
This policy setting has no impact if an administrator has configured a trusted path to
download drivers. If you use trusted paths, the print subsystem attempts to use the trusted
path to download the driver. If the trusted path download succeeds, the driver is installed
on behalf of any user. If the trusted path download fails, the driver is not installed and the
network printer is not added.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
It may be appropriate in some organizations to allow users to install printer drivers on their
own workstations. However, you should allow only administrators, not users, to do so on
servers, because printer driver installation on a server may unintentionally cause the
computer to become less stable. A malicious user could install inappropriate printer drivers in
a deliberate attempt to damage the computer, or a user might accidentally install malicious
software that masquerades as a printer driver.
Countermeasure
Enable the Devices: Prevent users from installing printer drivers setting.
Potential impact
Only users with Administrative, Power User, or Server Operator privileges will be able to install
printers on the servers. If this policy setting is enabled but the driver for a network printer
already exists on the local computer, users can still add the network printer.
Devices: Restrict CD-ROM access to locally logged-on user only
This policy setting determines whether a CD is accessible to both local and remote users
simultaneously. If you enable this policy setting, only the interactively logged-on user is
allowed to access removable CDs. If this policy setting is enabled and no one is logged on
interactively, the CD can be accessed over the network.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
A remote user could potentially access a mounted CD that contains sensitive information.
This risk is small, because CD drives are not automatically made available as shared drives;
administrators must deliberately choose to share the drive. However, administrators may
want to deny network users the ability to view data or run applications from removable
media on the server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Enable the Devices: Restrict CD-ROM drive access to locally logged-on user only setting.
Potential impact
Users who connect to the server over the network will not be able to use any CD drives that
are installed on the server whenever anyone is logged on to the local console of the server.
System tools that require access to the CD drive will fail. For example, the Volume Shadow
Copy service attempts to access all CD and floppy disk drives that are present on the
computer when it initializes, and if the service cannot access one of these drives, it will fail.
This condition will cause the Windows Backup tool to fail if volume shadow copies were
specified for the backup job. Any non-Microsoft backup products that use volume shadow
copies will also fail. This policy setting would not be suitable for a computer that serves as a
CD jukebox for network users.
Devices: Restrict floppy access to locally logged-on user only
This policy setting determines whether removable floppy disks are accessible to both local
and remote users simultaneously. If you enable this policy setting, only the interactively
logged-on user is allowed to access removable floppy disks. If this policy setting is enabled
and no one is logged on interactively, a floppy disk can be accessed over the network.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
A remote user could potentially access a mounted floppy that contains sensitive information.
This risk is small because floppy disk drives are not automatically shared; administrators must
deliberately choose to share the drive. However, administrators may want to deny network
users the ability to view data or run applications from removable media on the server.
Countermeasure
Enable the Devices: Restrict floppy access to locally logged-on user only setting.
Potential impact
Users who connect to the server over the network will not be able to use any floppy disk
drives that are installed on the server whenever anyone is logged on to the local console of
the server. System tools that require access to floppy disk drives will fail. For example, the
Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives present
tmg.edu.au | 1300 888 TMG (1300 888 864)
on the computer when it initializes, and if the service cannot access one of these drives it will
fail. This condition will cause the Windows Backup tool to fail if volume shadow copies were
specified for the backup job. Any non-Microsoft backup products that use volume shadow
copies will also fail.
Devices: Unsigned driver installation behavior
This policy setting determines what happens when an attempt is made to install a device
driver that has not been certified and signed by the Windows Hardware Quality Lab (WHQL)
by means of the Setup API. This policy setting prevents the installation of unsigned drivers, or
warns the administrator that unsigned driver software is about to be installed. This capability
can prevent use of the Setup API to install drivers that have not been certified to run on
Windows Vista or Windows Server 2003.
Note
This setting is not available in the Local Group Policy Editor in Windows Vista.
Possible values:
 Silently succeed
 Warn but allow installation
 Do not allow installation
 Not Defined
Vulnerability
This policy setting will not prevent a method that is used by some attack tools in which
malicious .sys files are copied and registered to start as system services.
Countermeasure
Configure the Devices: Unsigned driver installation behavior setting to Warn but allow
installation, which is the default configuration for Windows Vista and Windows XP with SP2.
The default configuration for Windows Server 2003 is Not Defined.
Potential impact
Users with sufficient privileges to install device drivers will be able to install unsigned device
drivers. However, this capability could result in stability problems for servers. Another potential
problem with a Warn but allow installation configuration is that unattended installation scripts
will fail if they attempt to install unsigned drivers.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
On 64-bit versions of Windows Vista, running of unsigned kernel mode drivers is disabled
when the operating system attempts to load them into memory. While installation of such
drivers might be possible depending on the configuration of this policy, running of unsigned
drivers on 64-bit versions of Windows Vista is not possible without regard to this policy setting.
Domain controller: Allow server operators to schedule tasks
This policy setting determines whether server operators are allowed to submit jobs by means
of the AT schedule tool. If you enable this policy setting, jobs that are created by server
operators by means of the AT service will run in the context of the account that runs that
service. By default, that is the local SYSTEM account. If you enable this policy setting, server
operators could perform tasks that SYSTEM is able to do but that they would typically not be
able to do, such as add their account to the local Administrators group.
Note
This security option setting affects only the AT schedule tool. It does not affect the Task
Scheduler tool.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
Tasks that run under the context of the local SYSTEM account may be able to affect
resources that are at a higher privilege level than the user account that scheduled the task.
Countermeasure
Disable the Domain controller: Allow server operators to schedule tasks setting.
Potential impact
The impact should be small for most organizations. Users (including those in the Server
Operators group) will still be able to create jobs by means of the Task Scheduler Wizard.
However, those jobs will run in the context of the account that the user authenticates with
when setting up the job.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Domain controller: LDAP server signing requirements
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP)
server requires LDAP clients to negotiate data signing.
Possible values:
 None. Data signatures are not required to bind with the server. If the client requests
data signing, the server supports it.
 Require signature. The LDAP data-signing option must be negotiated unless Transport
Layer Security/Secure Sockets Layer (TLS/SSL) is in use.
 Not Defined.
Vulnerability
Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an

intruder captures packets between the server and the client, modifies them, and then
forwards them to the client. Where LDAP servers are concerned, an attacker could cause a
client to make decisions that are based on false records from the LDAP directory. To lower
the risk of such an intrusion in an organization's network, you can implement strong physical
security measures to protect the network infrastructure. You could also implement Internet
Protocol security (IPsec) authentication header mode (AH), which performs mutual
authentication and packet integrity for IP traffic to make all types of man-in-the-middle
attacks extremely difficult.
Countermeasure
Configure the Domain controller: LDAP server signing requirements setting to Require
signature.
Potential impact
Clients that do not support LDAP signing will be unable to run LDAP queries against the
domain controllers. All Windows 2000–based computers in your organization that are
managed from Windows Server 2003–based or Windows XP–based computers and that use
NTLM authentication must have Windows 2000 Service Pack 3 (SP3) installed. Alternatively,
these clients must have a registry change. For information about this registry change, see
article 325465, Windows 2000 domain controllers require SP3 or later when using Windows
Server 2003 administration tools, in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=100900). Also, some non-Microsoft operating systems
do not support LDAP signing. If you enable this policy setting, client computers that use those
operating systems may be unable to access domain resources.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Domain controller: Refuse machine account password changes
This policy setting enables or disables the blocking of a domain controller from accepting
password change requests for computer accounts.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
If you enable this policy setting on all domain controllers in a domain, domain members will
not be able to change their computer account passwords, and those passwords will be
more susceptible to attack.
Countermeasure
Disable the Domain controller: Refuse machine account password changes setting.
Potential impact
Domain member: Digitally encrypt or sign secure channel data (multiple related settings)
The following policy settings determine whether a secure channel can be established with a
domain controller that cannot sign or encrypt secure channel traffic:
 Domain member: Digitally encrypt or sign secure channel data (always)

 Domain member: Digitally encrypt secure channel data (when possible)
 Domain member: Digitally sign secure channel data (when possible)
If you enable the Domain member: Digitally encrypt or sign secure channel data (always)
setting, a secure channel cannot be established with any domain controller that cannot sign
or encrypt all secure channel data.
To protect authentication traffic from man-in-the-middle, replay, and other types of network
attacks, Windows–based computers create a communication channel through NetLogon
called secure channels. These channels authenticate computer accounts, and they also
authenticate user accounts when a remote user connects to a network resource and the
user account exists in a trusted domain. This authentication is called pass-through
authentication, and it allows a computer that has joined a domain to have access to the
user account database in its domain and in any trusted domains.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
To enable the Domain member: Digitally encrypt or sign secure channel data (always)
setting on a member workstation or server, all domain controllers in the domain that the
member belongs to must be able to sign or encrypt all secure channel data. This
requirement means that all such domain controllers must run Microsoft Windows NT® 4.0 with
Service Pack 6a (SP6a) or a later version of the Windows operating system.
If you enable the Domain member: Digitally encrypt or sign secure channel data (always)
setting, the Domain member: Digitally sign secure channel data (when possible) setting is
automatically enabled.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
When a computer joins a domain, a computer account is created. After it joins the domain,
the computer uses the password for that account to create a secure channel with the
domain controller for its domain every time that it restarts. Requests that are sent on the
secure channel are authenticated—and sensitive information such as passwords are
encrypted—but the channel is not integrity-checked, and not all information is encrypted. If
a computer is configured to always encrypt or sign secure channel data but the domain
controller cannot sign or encrypt any portion of the secure channel data, the computer and
domain controller cannot establish a secure channel. If the computer is configured to
encrypt or sign secure channel data when possible, a secure channel can be established,
but the level of encryption and signing is negotiated.
Countermeasure
Select one of the following settings as appropriate for your environment to configure the
computers in your domain to encrypt or sign secure channel data when possible.
 Enable the Domain member: Digitally encrypt or sign secure channel data (always)
setting.
 Enable the Domain member: Digitally encrypt secure channel data (when possible)
setting.
 Enable the Domain member: Digitally sign secure channel data (when possible)
setting.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Potential impact
Digital encryption and signing of the secure channel is a good idea where it is supported. The
secure channel protects domain credentials as they are sent to the domain controller.
However, only Windows NT 4.0 with SP6a and subsequent versions of the Windows operating
system support digital encryption and signing of the secure channel. Windows 98 Second
Edition clients do not support it unless they have the Dsclient installed. Therefore, you cannot
enable the Domain member: Digitally encrypt or sign secure channel data (always) setting
on domain controllers that support Windows 98 clients as members of the domain. Potential
impacts can include the following:
 The ability to create or delete trust relationships with clients running versions of
Windows earlier than Windows NT 4.0 with SP6a will be disabled.
 Logons from clients running versions of Windows earlier than Windows NT 4.0 with SP6a
will be disabled.
 The ability to authenticate other domains' users from a domain controller running a
version of Windows earlier than Windows NT 4.0 with SP6a in a trusted domain will be
disabled.
You can enable this policy setting after you eliminate all Windows 9x clients from the domain
and upgrade all Windows NT 4.0 servers and domain controllers from trusted/trusting domains
to Windows NT 4.0 with SP6a. You can enable the other two policy settings, Domain member:
Digitally encrypt secure channel data (when possible) and Domain member: Digitally
encrypt sign channel data (when possible), on all computers in the domain that support
them and clients running versions of Windows earlier than Windows NT 4.0 with SP6a and
applications that run on these versions of Windows will not be affected.
Domain member: Disable machine account password changes
This policy setting enables or disables the blocking of the periodic changing of computer
account passwords. If you enable this policy setting, the domain member cannot change its
computer account password. If you disable this policy setting, the domain member is
allowed to change its computer account password as specified by the Domain Member:
Maximum age for computer account password setting, which is every 30 days by default.
Caution
Do not enable this policy setting. Computer account passwords are used to establish secure
channel communications between members and domain controllers and, within the
domain, between the domain controllers themselves. After such communications are
established, the secure channel transmits sensitive information that is needed to make
authentication and authorization decisions.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Caution
Do not use this policy setting in an attempt to support dual-boot scenarios that use the
same computer account. If you want to support such a scenario for two installations that
are joined to the same domain, use different computer names for the two installations.
This policy setting was added to Windows to make it easier for organizations that stockpile
pre-built computers that are put into production months later. It eliminates the need for those
computers to rejoin the domain. This policy setting is also sometimes used with imaged
computers or those with hardware or software level change prevention. Correct imaging
procedures make use of this policy unnecessary for imaged computers.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
The default configuration for Windows Server 2003–based computers that belong to a
domain is that they are automatically required to change the passwords for their accounts
every 30 days. If you disable this policy setting, computers that run Windows Server 2003 will
retain the same passwords as their computer accounts. Computers that are no longer able
to automatically change their account password are at risk from an attacker who could
determine the password for the computer's domain account.
Countermeasure
Verify that the Domain member: Disable machine account password changes setting is
configured to Disabled.
Potential impact
Domain member: Maximum machine account password age
This policy setting determines the maximum allowable age for a computer account
password. This setting also applies to Windows 2000-based computers, but it is not available
through the Security Configuration Manager tool on these computers.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Possible values:
 User-defined number of days between 0 and 999

 Not Defined
Vulnerability
In Active Directory–based domains, each computer has an account and password just as
every user does. By default, the domain members automatically change their domain
password every 30 days. If you increase this interval significantly, or set it to 0 so that the
computers no longer change their passwords, an attacker will have more time to undertake
a brute force attack to guess the password of one or more computer accounts.
Countermeasure
Configure the Domain member: Maximum machine account password age setting to 30
days.
Potential impact
Domain member: Require strong (Windows 2000 or later) session key
This policy setting determines whether a secure channel can be established with a domain
controller that cannot encrypt secure channel traffic with a strong, 128-bit session key. If you
enable this policy setting, you can establish a secure channel only with a domain controller
that can encrypt secure channel data with a strong key. If you disable this policy setting, 64-
bit session keys are allowed.
Note
To enable this policy setting on a member workstation or server, all domain controllers in the
domain to which the member belongs must be able to encrypt secure channel data with a
strong, 128-bit key. In other words, all such domain controllers must run Windows 2000 or a
later version of the Windows operating system.
Possible values:
 Enabled
 Disabled
 Not Defined
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
Session keys that are used to establish secure channel communications between domain
controllers and member computers are much stronger in Windows 2000 than they were in
previous Windows operating systems.
Whenever possible, you should take advantage of these stronger session keys to help protect
secure channel communications from attacks that attempt to hijack network sessions and
eavesdrop. (Eavesdropping is a form of hacking in which network data is read or altered in
transit. The data can be modified to hide or change the sender, or be redirected.)
Countermeasure
Enable the Domain member: Require strong (Windows 2000 or later) session key setting.
If you enable this policy setting, all outgoing secure channel traffic will require a strong,
Windows 2000 or later encryption key. If you disable this policy setting, the key strength is
negotiated. You should enable this policy setting only if the domain controllers in all trusted
domains support strong keys. By default, this policy setting is disabled.
Potential impact
Computers that have this policy setting enabled will not be able to join Windows NT 4.0
domains, and trusts between Active Directory domains and Windows NT domains may not
work properly. Also, computers that do not support this policy setting will not be able to join
domains in which the domain controllers have this policy setting enabled.
Interactive logon: Do not display last user name
This policy setting enables or disables preventing the display of the name of the last user to
log on to the computer in the logon dialog box.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
An attacker with access to the console (for example, someone with physical access or
someone who is able to connect to the server through Terminal Services) could view the
name of the last user who logged on to the server. The attacker could then try to guess the
password, use a dictionary, or use a brute force attack to try to log on.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Enable the Interactive logon: Do not display last user name setting.
Potential impact
Users will always have to type their user names when they log on to the servers.
Interactive logon: Do not require CTRL+ALT+DEL
This policy setting enables or disables the non-requirement for users to press CTRL+ALT+DEL
before they log on to Windows, unless they use a smart card, a tamper-proof device that
stores security information.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
This setting makes it easier for users with certain types of physical impairments to log on to
computers that run Windows. However, if users are not required to press CTRL+ALT+DEL, they
are susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is
required before logon, user passwords are communicated by means of a trusted path.
If this setting is enabled, an attacker could install a Trojan horse program that looks like the
standard Windows logon dialog box and capture the user's password. The attacker would
then be able to log on to the compromised account with whatever level of privilege that
user has.
Countermeasure
Disable the Interactive logon: Do not require CTRL+ALT+DEL setting.
Potential impact
Unless they use a smart card to log on, users will have to simultaneously press the three keys
before the logon dialog box will display.
Interactive logon: Message text for users attempting to log on and Message title for users
attempting to log on
There are two separate policy settings that relate to logon displays:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Interactive logon: Message text for users attempting to log on

 Interactive logon: Message title for users attempting to log on
The first policy setting specifies a text message that displays to users when they log on, and
the second policy setting specifies a title for the title bar of the text message window. Many
organizations use this text for legal purposes; for example, to warn users about the
ramifications of misuse of company information, or to warn them that their actions may be
audited.
Possible values:
 Not Defined
Vulnerability
Users often do not understand the importance of security practices. However, the display of
a warning message before logon may help prevent an attack by warning malicious or
uninformed users about the consequences of their misconduct before it happens. It may also
help to reinforce corporate policy by notifying employees of the appropriate policy during
the logon process.
Countermeasure
Configure the Interactive logon: Message text for users attempting to log on and Interactive
logon: Message title for users attempting to log on settings to an appropriate value for your
organization.
Note
Any warning message that displays should be approved by your organization's legal and
human resources representatives.
Potential impact
Users will see a message in a dialog box before they can log on to the server console.
Note
Windows Vista and Windows XP Professional support logon banners that can exceed 512
characters in length and that can also contain carriage-return line-feed sequences.
However, Windows 2000-based clients cannot interpret and display these messages. You
must use a Windows 2000-based computer to create a logon message policy that applies
to Windows 2000-based computers. If you inadvertently create a logon message policy on
a Windows Vista-based or Windows XP Professional-based computer and you discover that
tmg.edu.au | 1300 888 TMG (1300 888 864)
it does not display properly on Windows 2000-based computers, do the following: Change
the setting to Not Defined, and then change the setting to the desired value by using a
Windows 2000-based computer.
Important
If you do not reconfigure this setting to Not Defined before reconfiguring the setting using a
Windows 2000-based computer, the changes will not take effect properly.
Interactive logon: Number of previous logons to cache (in case domain controller is not
available)
This policy setting determines the number of different unique users who can log on to a
Windows domain by using cached account information. Logon information for domain
accounts can be cached locally so that if a domain controller cannot be contacted on
subsequent logons, a user can still log on. This policy setting determines the number of unique
users whose logon information is cached locally.
If a domain controller is unavailable and a user's logon information is cached, the user is
prompted with the following message:
A domain controller for your domain could not be contacted. You have been logged on
using cached account information. Changes to your profile since you last logged on may not
be available.
If a domain controller is unavailable and a user's logon information is not cached, the user is
prompted with this message:
The system cannot log you on now because the domain <DOMAIN_NAME> is not available.
Possible values:
 User-defined number between 0 and 50

 Not Defined
Vulnerability
The number that is assigned to this policy setting indicates the number of users whose logon
information the servers will cache locally. If the number is set to 10, then the server caches
logon information for 10 users. When an eleventh user logs on to the computer, the server
overwrites the oldest cached logon session.
Users who access the server console will have their logon credentials cached on that server.
An attacker who is able to access the file system of the server could locate this cached
information and use a brute force attack to attempt to determine user passwords.
tmg.edu.au | 1300 888 TMG (1300 888 864)
To mitigate this type of attack, Windows encrypts the information and obscures its physical
location.
Countermeasure
Configure the Interactive logon: Number of previous logons to cache (in case domain
controller is not available) setting to 0, which disables the local caching of logon information.
Additional countermeasures include enforcement of strong password policies and physically
secure locations for the computers.
Potential impact
Users will be unable to log on to any computers if there is no domain controller available to
authenticate them. Organizations may want to configure this value to 2 for end-user
computers, especially for mobile users. A configuration value of 2 means that the user's logon
information will still be in the cache, even if a member of the IT department has recently
logged on to their computer to perform system maintenance. This method allows users to log
on to their computers when they are not connected to the organization's network.
Interactive logon: Prompt user to change password before expiration
This policy setting determines how many days in advance users are warned that their
password is about to expire. With this advance warning, the user has time to construct a
password that is sufficiently strong.
Possible values:
 User defined number of days between 1 and 999

 Not Defined
Vulnerability
If user passwords are configured to expire periodically in your organization, users need to be
warned when this is about to happen, or they may inadvertently be locked out of the
computer when their passwords expire. This condition could lead to confusion for users who
access the network locally, or make it impossible for users to access your organization's
network through dial-up or virtual private network (VPN) connections.
Countermeasure
Configure the Interactive logon: Prompt user to change password before expiration setting to
14 days.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Potential impact
Users will see a dialog box prompt to change their password each time that they log on to
the domain when their password is configured to expire in 14 or fewer days.
Interactive logon: Require Domain Controller authentication to unlock workstation
This policy setting enables or disables the requirement for a domain account to contact a
domain controller to unlock a computer. Logon information is required to unlock a locked
computer. If you enable this setting, a domain controller must authenticate the domain
account that is being used to unlock the computer. If you disable this setting, logon
information confirmation with a domain controller is not required for a user to unlock the
computer. However, if you configured the Interactive logon: Number of previous logons to
cache (in case domain controller is not available) setting to a value that is greater than zero,
the user's cached credentials will be used to unlock the computer.
Note
This setting can be applied to Windows 2000-based computers, but it is not available
through the Security Configuration Manager tool on those computers.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
By default, the computer caches in memory the credentials of any users who are
authenticated locally. The computer uses these cached credentials to authenticate anyone
who attempts to unlock the console. When cached credentials are used, any changes that
have recently been made to the account—such as user rights assignments, account lockout,
or the account being disabled—are not considered or applied after the account is
authenticated. User privileges are not updated, and (more important) disabled accounts are
still able to unlock the console of the computer.
Countermeasure
Configure the Interactive logon: Require Domain Controller authentication to unlock

workstation setting to Enabled and configure the Interactive logon: Number of previous
logons to cache (in case domain controller is not available) setting to 0.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Potential impact
When the console on a computer is locked, either by a user or automatically by a screen

saver timeout, the console can be unlocked only if the user is able to re-authenticate to the
domain controller. If no domain controller is available, users cannot unlock their workstations.
If you configure the Interactive logon: Number of previous logons to cache (in case domain
controller is not available) setting to 0, users whose domain controllers are unavailable (such
as mobile or remote users) will not be able to log on.
Interactive logon: Require smart card
This policy setting enables or disables the requirement for users to log on to a computer with
a smart card. The use of smart cards instead of passwords for authentication dramatically
increases security, because current technology makes it extremely difficult for an attacker to
impersonate another user. Smart cards that require personal identification numbers (PINs)
provide two-factor authentication: the user must both possess the smart card and know its
PIN. Attackers who capture the authentication traffic between the user's computer and the
domain controller will find it extremely difficult to decrypt the traffic and, even if they do, the
next time the user logs onto the network a new session key will be generated to encrypt
traffic between the user and the domain controller.
Note
This setting can be applied to Windows 2000-based computers, but it is not available
through the Security Configuration Manager tool on those computers.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
It can be difficult to make users choose strong passwords, and even strong passwords are
vulnerable to brute force attacks if an attacker has sufficient time and computing resources.
Countermeasure
For users with access to computers that contain sensitive data, issue smart cards to users and
configure the Interactive logon: Require smart card setting to Enabled.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Potential impact
All users of a computer with this setting enabled will have to use smart cards to log onto the
local computer, which means that the organization will need a reliable public key
infrastructure (PKI) as well as smart cards and smart card readers for these users. These
requirements are significant challenges, because expertise and resources are required to
plan for and deploy these technologies. However, Windows Server 2003 includes Certificate
Services, a highly advanced service for implementing and managing certificates. When
Certificate Services is combined with Windows XP or Windows Vista, features such as
automatic user and computer enrollment and renewal become available. For more
information about deploying Smart Cards with Windows Vista see Windows Vista Smart Card
Infrastructure (http://go.microsoft.com/fwlink/?LinkId=111969).
Interactive logon: Smart card removal behavior
This policy setting determines what happens when the smart card for a logged-on user is
removed from the smart card reader.
Possible values:
 No Action
 Lock Workstation
 Force Logoff
 Disconnect if a remote Terminal Services session
 Not Defined
By default, this setting is Not Defined, which results which is equivalent to the No Action
setting.
Note
On computers running Windows Vista or later operating systems, the Smart Card Removal
Policy service must be started for this setting to work.
Vulnerability
Users sometimes forget to lock their workstations when they are away from them, allowing
the possibility for malicious users to access their computers. If smart cards are used for
authentication, the computer should automatically lock itself when the card is removed to
ensure that only the user with the smart card is accessing resources using those credentials.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Configure the Interactive logon: Smart card removal behavior setting to Lock Workstation.
If you select Lock Workstation for this policy setting, the workstation locks when the smart
card is removed. Users can leave the area, take their smart card with them, and still maintain
a protected session. This behavior is similar to the setting that requires users to log on when
resuming work on the computer after the screen saver has started.
If you select Force Logoff for this policy setting, the user is automatically logged off when the
smart card is removed. This setting is very useful when a computer is deployed as a public
access point, such as a kiosk or other type of shared computer.
Potential impact
If you select Force Logoff, users will have to re-insert their smart cards and re-enter their PINs
when they return to their workstations.
Microsoft network client and server: Digitally sign communications (four related settings)
There are four separate policy settings that relate to packet signing requirements for Server
Message Block (SMB) communications:
 Microsoft Network Client: Digitally Sign Communications (Always)

 Microsoft Network Server: Digitally Sign Communications (Always)
 Microsoft Network Client: Digitally Sign Communications (If Server Agrees)
 Microsoft Network Server: Digitally Sign Communications (If Client Agrees)
Implementation of digital signatures in high-security networks helps to prevent the

impersonation of clients and servers, known as session hijacking.
Possible values for each of these policy settings are:
 Enabled
 Disabled
 Not Defined
Vulnerability
Session hijacking uses tools that allow attackers who have access to the same network as the
client or server to interrupt, end, or steal a session in progress. Attackers can potentially
intercept and modify unsigned Server Message Block (SMB) packets and then modify the
traffic and forward it so that the server might perform undesirable actions. Alternatively, the
attacker could pose as the server or client after legitimate authentication and gain
unauthorized access to data.
tmg.edu.au | 1300 888 TMG (1300 888 864)
SMB is the resource sharing protocol that is supported by many Windows operating systems. It
is the basis of NetBIOS and many other protocols. SMB signatures authenticate both users
and the servers that host the data. If either side fails the authentication process, data
transmission will not take place.
Countermeasure
Configure the settings as follows:
 Disable Microsoft Network Client: Digitally Sign Communications (Always).

 Disable Microsoft Network Server: Digitally Sign Communications (Always).
 Enable Microsoft Network Client: Digitally Sign Communications (If Server Agrees).
 Enable Microsoft Network Server: Digitally Sign Communications (If Client Agrees).
In highly secure environments we recommend that you configure all of these settings to
Enabled. However, that configuration may cause slower performance on client computers
and prevent communications with earlier SMB applications and operating systems.
Note
An alternative countermeasure that could protect all network traffic would be to implement
digital signatures with Internet Protocol security (IPsec). There are hardware-based
accelerators for IPsec encryption and signing that could be used to minimize the
performance impact on the servers' CPUs. No such accelerators are available for SMB
signing.
Potential impact
The Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, Windows XP
Professional, and Windows Vista implementations of the SMB file and print sharing protocol
support mutual authentication, which prevents session hijacking attacks and supports
message authentication to prevent man-in-the-middle attacks. SMB signing provides this
authentication by placing a digital signature into each SMB, which is then verified by both
the client and the server.
Implementation of SMB signing may negatively affect performance, because each packet
needs to be signed and verified. If these settings are enabled on a server that is performing
multiple roles, such as a small business server that is serving as a domain controller, file server,
print server, and application server, performance may be substantially slowed. Additionally, if
you configure computers to ignore all unsigned SMB communications, older applications and
operating systems will not be able to connect. However, if you completely disable all SMB
signing, computers will be vulnerable to session hijacking attacks.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Microsoft network client: Send unencrypted password to third-party SMB servers
This policy setting enables or disables the sending of plaintext passwords by the SMB
redirector to non-Microsoft SMB servers that do not support password encryption during
authentication.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
If you enable this policy setting, the server can transmit passwords in plaintext across the
network to other computers that offer SMB services. These other computers might not use any
of the SMB security mechanisms that are included with Windows Server 2003.
Countermeasure
Disable the Microsoft network client: Send unencrypted password to connect to third-party
SMB servers setting.
Potential impact
Some very old applications and operating systems such as MS-DOS, Windows for Workgroups
3.11, and Windows 95a may not be able to communicate with the servers in your
organization by means of the SMB protocol.
Microsoft network server: Amount of idle time required before suspending session
This policy setting determines the amount of continuous idle time that must pass in an SMB
session before the session is suspended because of inactivity. Administrators can use this
policy setting to control when a computer suspends an inactive SMB session. The session
automatically re-establishes when client activity resumes. A value of 0 will disconnect an idle
session as quickly as possible. The maximum value is 99999, which is 208 days; in effect, this
value disables the setting.
Possible values:
 User-defined period of time in minutes

 Not Defined
By default this policy is not defined, which means that the system allows 15 minutes idle time
for servers and an undefined time for workstations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
Each SMB session consumes server resources, and numerous null sessions will slow the server
or possibly cause it to fail. An attacker could repeatedly establish SMB sessions until the
server's SMB services become slow or unresponsive.
Countermeasure
The default behavior on a server mitigates this threat by design in Windows Server 2003.
Potential impact
There will be little impact because SMB sessions will be re-established automatically if the
client resumes activity.
Microsoft network server: Disconnect clients when logon hours expire
This policy setting enables or disables the forced disconnection of users who are connected
to the local computer outside their user account's valid logon hours. It affects the SMB
component. If you enable this policy setting, client sessions with the SMB service will be
forcibly disconnected when the client's logon hours expire. If you disable this policy setting,
established client sessions will be maintained after the client's logon hours expire. If you
enable this policy setting you should also enable Network security: Force logoff when logon
hours expire.
Possible values:
 Enabled
 Disabled
 Not Defined
By default, this setting is enabled in Windows Vista.
Vulnerability
If your organization configures logon hours for users, it makes sense to enable this policy
setting. Otherwise, users who should not have access to network resources outside of their
logon hours may actually be able to continue to use those resources with sessions that were
established during allowed hours.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Enable the Microsoft network server: Disconnect clients when logon hours expire setting.
Potential impact
If logon hours are not used in your organization, this policy setting will have no impact. If
logon hours are used, existing user sessions will be forcibly terminated when their logon hours
expire.
Network access: Allow anonymous SID/Name translation
This policy setting enables or disables the ability of an anonymous user to request SID
attributes for another user.
Possible values:
 Enabled
 Disabled
 Not Defined
By default, this setting is enabled on domain controllers and is disabled on workstations and
member servers.
Vulnerability
If this policy setting is enabled, a user with local access could use the well-known
Administrator's SID to learn the real name of the built-in Administrator account, even if it has
been renamed. That person could then use the account name to initiate a password
guessing attack.
Countermeasure
Disable the Network access: Allow anonymous SID/Name translation setting.
Potential impact
Disabled is the default configuration for this policy setting on member computers; therefore it
will have no impact on them. The default configuration for domain controllers is Enabled. If
you disable this policy setting on domain controllers, computers running versions of Windows
earlier than Windows Server 2003 may be unable to communicate with Windows
Server 2003–based domains. For example, the following computers may not work:
 Windows NT 4.0–based Remote Access Service servers

 Servers that host Microsoft SQL Server™ and run on Windows NT 3.x–based or
Windows NT 4.0–based computers
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Servers that host Remote Access Service or Microsoft SQL Server, run on
Windows 2000–based computers, and are located in Windows NT 3.x domains or
Windows NT 4.0 domains
Network access: Do not allow anonymous enumeration of SAM accounts
This policy setting determines what additional permissions will be granted for anonymous
connections to the computer. Windows allows anonymous users to perform certain activities,
such as enumerate the names of domain accounts and shared folders. This capability is
convenient, for example, when an administrator wants to grant access to users in a trusted
domain that does not maintain a reciprocal trust. However, even if this setting is enabled,
anonymous users will still have access to any resources that have permissions that explicitly
include the special built-in group ANONYMOUS LOGON.
In Windows 2000, a similar policy setting called Additional Restrictions for Anonymous
Connections managed a registry value called RestrictAnonymous, which was located in the
HKLM\SYSTEM\CurrentControlSet\Control\LSA registry key. In Windows Server 2003, the
policy settings Network access: Do not allow anonymous enumeration of SAM accounts and
Network access: Do not allow anonymous enumeration of SAM accounts and shares replace
the Windows 2000 policy setting. They manage the registry values RestrictAnonymousSAM
and RestrictAnonymous, respectively, which are both located in the
HKLM\System\CurrentControlSet\Control\Lsa registry key.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
An unauthorized user could anonymously list account names and use the information to
perform social engineering attacks or attempt to guess passwords. (Social engineering
attacks try to deceive users in some way to obtain passwords or some form of security
information.)
Countermeasure
Enable the Network access: Do not allow anonymous enumeration of SAM accounts setting.
Potential impact
It will be impossible to establish trusts with Windows NT 4.0–based domains. Also, client
computers that run earlier versions of the Windows operating system such as Windows NT 3.51
and Windows 95 will experience problems when they try to use resources on the server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network access: Do not allow anonymous enumeration of SAM accounts and shares
This policy setting determines whether anonymous enumeration of Security Accounts

Manager (SAM) accounts and shared folders is allowed. Windows allows anonymous users to
perform certain activities, such as enumerate the names of domain accounts and shared
folders. This capability is convenient, for example, when an administrator wants to grant
access to users in a trusted domain that does not maintain a reciprocal trust. You can enable
this policy setting if you do not want to allow anonymous enumeration of SAM accounts and
shared folders. However, even if it is enabled, anonymous users will still have access to any
resources that have permissions that explicitly include the special built-in group ANONYMOUS
LOGON.
In Windows 2000, a similar policy setting called Additional Restrictions for Anonymous
Connections managed a registry value called RestrictAnonymous, which was located in the
HKLM\SYSTEM\CurrentControlSet\Control\LSA registry key. In Windows Server 2003, the
policy settings Network access: Do not allow anonymous enumeration of SAM accounts and
Network access: Do not allow anonymous enumeration of SAM accounts and shares replace
the Windows 2000 policy setting. They manage registry values RestrictAnonymousSAM and
RestrictAnonymous, respectively, which are both located in the
HKLM\System\CurrentControlSet\Control\Lsa registry key.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
An unauthorized user could anonymously list account names and shared resources and use
the information to attempt to guess passwords or perform social engineering attacks.
Countermeasure
Enable the Network access: Do not allow anonymous enumeration of SAM accounts and
shares setting.
Potential impact
It will be impossible to grant access to users of another domain across a one-way trust
because administrators in the trusting domain will be unable to enumerate lists of accounts in
the other domain. Users who access file and print servers anonymously will be unable to list
the shared network resources on those servers; the users will have to be authenticated
before they can view the lists of shared folders and printers.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network access: Do not allow storage of credentials or .NET Passports for network
authentication
This policy setting determines whether the Stored User Names and Passwords feature may
save passwords or credentials for later use when it gains domain authentication. If you
enable this policy setting, the Stored User Names and Passwords feature of Windows does not
store passwords and credentials.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
Passwords that are cached can be accessed by the user when logged on to the computer.
Although this information may sound obvious, a problem can arise if the user unknowingly
runs malicious software that reads the passwords and forwards them to another,
unauthorized user.
Note
The chances of success for this exploit and others that involve malicious software will be
reduced significantly for organizations that effectively implement and manage an
enterprise antivirus solution combined with sensible software restriction policies.
Countermeasure
Enable the Network access: Do not allow storage of credentials or .NET Passports for network
authentication setting.
Potential impact
Users will be forced to enter passwords whenever they log on to their Windows Live ID or
other network resources that are not accessible to their domain account. This policy setting
should have no impact on users who access network resources that are configured to allow
access with their Active Directory–based domain account.
Network access: Let Everyone permissions apply to anonymous users
This policy setting determines what additional permissions are granted for anonymous
connections to the computer. If you enable this policy setting, anonymous users can
enumerate the names of domain accounts and shared folders and perform certain other
activities. This capability is convenient, for example, when an administrator wants to grant
access to users in a trusted domain that does not maintain a reciprocal trust.
tmg.edu.au | 1300 888 TMG (1300 888 864)
By default, the token that is created for anonymous connections does not include the
Everyone SID. Therefore, permissions that are assigned to the Everyone group do not apply to
anonymous users. If you enable this policy setting, the Everyone SID is added to the token
that is created for anonymous connections, and anonymous users will be able to access any
resource for which the Everyone group has been assigned permissions.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
An unauthorized user could anonymously list account names and shared resources and use
the information to attempt to guess passwords, perform social engineering attacks, or launch
DoS attacks.
Countermeasure
Disable the Network access: Let Everyone permissions apply to anonymous users setting.
Potential impact
Network access: Named Pipes that can be accessed anonymously
This policy setting determines which communication sessions, or pipes, will have attributes
and permissions that allow anonymous access.
Possible values:
 User-defined list of shared folders

 Not Defined
For this policy setting to take effect, you must also enable the Network access: Restrict
anonymous access to named pipes and shares setting.
Vulnerability
You can restrict access over named pipes such as COMNAP and LOCATOR to help prevent
unauthorized access to the network. The default list of named pipes and their purpose is
provided in the following table.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Named Purpose
pipe
COMNAP SNABase named pipe. Systems network Architecture (SNA) is a collection of
network protocols that were originally developed for IBM mainframe
computers.
COMNODE SNA Server named pipe.
SQL\QUERY Default named pipe for SQL Server.
SPOOLSS Named pipe for the Print Spooler service.
EPMAPPER End Point Mapper named pipe.
LOCATOR Remote Procedure Call Locator service named pipe.
TrlWks Distributed Link Tracking Client named pipe.
TrkSvr Distributed Link Tracking Server named pipe.
Countermeasure
Configure the Network access: Named Pipes that can be accessed anonymously setting to
a null value (enable the setting but do not enter named pipes in the text box).
Potential impact
This configuration will disable null session access over named pipes, and applications that
rely on this feature or on unauthenticated access to named pipes will no longer function. This
may break trust between Windows Server 2003 domains in a mixed mode environment. For
example, with Microsoft Commercial Internet System 1.0, the Internet Mail Service runs under
the Inetinfo process. Inetinfo starts in the context of the System account. When Internet Mail
Service needs to query the Microsoft SQL Server database, it uses the System account, which
uses null credentials to access a SQL pipe on the computer that runs SQL Server.
Network access: Remotely accessible registry paths
This policy setting determines which registry paths will be accessible when an application or
process references the WinReg key to determine access permissions.
Possible values:
 User-defined list of paths

 Not Defined
Vulnerability
An attacker could use information in the registry to facilitate unauthorized activities. To

reduce the risk of such an attack, suitable ACLs are assigned throughout the registry to help
protect it from access by unauthorized users.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Configure the Network access: Remotely accessible registry paths setting to a null value
(enable the setting but do not enter any paths in the text box).
Potential impact
Remote management tools such as the Microsoft Baseline Security Analyzer and Microsoft
Systems Management Server require remote access to the registry to properly monitor and
manage those computers. If you remove the default registry paths from the list of accessible
ones, such remote management tools could fail.
Note
If you want to allow remote access, you must also enable the Remote Registry service.
Network access: Remotely accessible registry paths and sub-paths
This policy setting determines which registry paths and sub-paths will be accessible when an
application or process references the WinReg key to determine access permissions.
Possible values:
 User-defined list of paths

 Not Defined
Vulnerability
The registry contains sensitive computer configuration information that could be used by an
attacker to facilitate unauthorized activities. The fact that the default ACLs assigned
throughout the registry are fairly restrictive and help to protect the registry from access by
unauthorized users reduces the risk of such an attack.
Countermeasure
Configure the Network access: Remotely accessible registry paths and sub-paths setting to a
null value (enable the setting but do not enter any paths in the text box).
Potential impact
Remote management tools such as the Microsoft Baseline Security Analyzer and Microsoft
Systems Management Server require remote access to the registry to properly monitor and
manage those computers. If you remove the default registry paths from the list of accessible
ones, such remote management tools could fail.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
If you want to allow remote access, you must also enable the Remote Registry service.
Network access: Restrict anonymous access to Named Pipes and Shares
This policy setting enables or disables the restriction of anonymous access to only those
shared folders and pipes that are named in the Network access: Named pipes that can be
accessed anonymously and Network access: Shares that can be accessed anonymously
settings. This policy setting controls null session access to shared folders on your computers by
adding RestrictNullSessAccess with the value 1 in the registry key
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters. This registry value
toggles null session shared folders on or off to control whether the Server service restricts
unauthenticated clients' access to named resources.
Possible values:
 Enabled
 Disabled
 Not Defined
This setting is enabled by default.
Vulnerability
Null sessions are a weakness that can be exploited through shared folders (including the
default shared folders) on computers in your environment.
Countermeasure
Enable the Network access: Restrict anonymous access to Named Pipes and Shares setting.
Potential impact
You can enable this policy setting to restrict null session access for unauthenticated users to
all server pipes and shared folders except those that are listed in the NullSessionPipes and
NullSessionShares entries.
If you choose to enable this setting and are supporting Windows NT 4.0 domains, you should
check if any of the named pipes are required to maintain trust relationships between the
domains, and then add the pipe to the Network access: Named pipes that can be accessed
anonymously:
 COMNAP–SNA session access

 COMNODE–SNA session access
 SQL\QUERY–SQL instance access
tmg.edu.au | 1300 888 TMG (1300 888 864)
 SPOOLSS–Spooler service
 LLSRPC–License Logging service
 Netlogon–Net Logon service
 Lsarpc–LSA access
 Samr–Remote access to SAM objects
 browser–Computer Browser service
In operating systems earlier than Windows Server 2003 with Service Pack 1 (SP1), these
named pipes were allowed anonymous access by default, but with the increased hardening
in Windows Server 2003 with SP1 these pipes must be explicitly added if needed.
Network access: Shares that can be accessed anonymously
This policy setting determines which shared folders can be accessed by anonymous users.
Possible values:
 User-defined list of shared folders

 Not Defined
Vulnerability
It is very dangerous to enable this setting. Any shared folders that are listed can be accessed
by any network user, which could lead to the exposure or corruption of sensitive data.
Countermeasure
Configure the Network access: Shares that can be accessed anonymously setting to a null
value.
Potential impact
There should be little impact because this is the default configuration. Only authenticated
users will have access to shared resources on the server.
Network access: Sharing and security model for local accounts
This policy setting determines how network logons that use local accounts are
authenticated. If you configure this policy setting to Classic, network logons that use local
account credentials authenticate with those credentials. If you configure this policy setting to
Guest only, network logons that use local accounts are automatically mapped to the Guest
account. The Classic model provides precise control over access to resources, and allows
you to grant different types of access to different users for the same resource. Conversely,
the Guest only model treats all users equally as the Guest user account, and they all receive
the same level of access to a given resource, which can be either Read Only or Modify.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The default configuration for a stand-alone computer running Windows Vista or Windows XP
Professional is Guest only. The default configuration for domain-joined computers running
Windows Vista or Windows XP Professional is Classic. Computers that are running Windows
Server 2003 also use the Classic security model.
Note
This policy setting does not affect network logons that use domain accounts. Nor does this
policy setting affect interactive logons that are performed remotely through services such
as Telnet or Terminal Services. This setting also has no effect on Windows 2000-based
computers. When the computer is not joined to a domain, this policy setting also tailors the
Sharing and Security tabs in Windows Explorer to correspond to the sharing and security
model that is being used.
Possible values:
 Classic - Local users authenticate as themselves

 Guest only - Local users authenticate as Guest
 Not Defined
Vulnerability
With the Guest only model, any user who can authenticate to your computer over the
network does so with guest privileges, which probably means that they will not have write
access to shared resources on that computer. Although this restriction does increase security,
it makes it more difficult for authorized users to access shared resources on those computers
because ACLs on those resources must include access control entries (ACEs) for the Guest
account. With the Classic model, local accounts should be password protected. Otherwise, if
Guest access is enabled, anyone can use those user accounts to access shared system
resources.
Countermeasure
For network servers, configure the Network access: Sharing and security model for local
accounts setting to Classic – local users authenticate as themselves. On end-user computers,
configure this policy setting to Guest only – local users authenticate as guest.
Potential impact
Network security: Do not store LAN Manager hash value on next password change
This policy setting determines whether LAN Manager is prevented from storing hash values for
the new password the next time the password is changed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
The SAM file can be targeted by attackers who seek access to user name and password
hashes. Such attacks use special tools to discover passwords, which can then be used to
impersonate users and gain access to resources on your network. These types of attacks are
not prevented by enabling this policy setting, as LAN Manager hashes are much weaker
than NTLM hashes, but it will be much more difficult for these attacks to succeed.
Countermeasure
Enable the Network security: Do not store LAN Manager hash value on next password
change setting. Require all users to set new passwords the next time they log on to the
domain so that LAN Manager hashes are removed.
Potential impact
Earlier operating systems such as Windows 95, Windows 98, and Windows Millennium Edition,
as well as some non-Microsoft applications, will not be able to connect to the system.
Network security: Force logoff when logon hours expire
This policy setting enables or disables the forced disconnection of users who are connected
to the local computer outside their user account's valid logon hours. It affects the SMB
component. If you enable this policy setting, client sessions with the SMB server will be
disconnected when the client's logon hours expire. If you disable this policy setting,
established client sessions will be maintained after the client's logon hours expire.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
If you disable this policy setting, users can remain connected to the computer outside of their
allotted logon hours.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Enable the Network security: Force logoff when logon hours expire setting. This policy setting
does not apply to administrator accounts.
Potential impact
When a user's logon time expires, SMB sessions will terminate. The user will be unable to log on
to the computer until his or her next scheduled access time commences.
Network security: LAN Manager authentication level
This policy setting determines which challenge/response authentication protocol is used for
network logons. LAN Manager (LM) is a family of early Microsoft client/server software that
allows users to link personal computers together on a single network. Network capabilities
include transparent file and print sharing, user security features, and network administration
tools. In Active Directory domains, the Kerberos protocol is the default authentication
protocol. However, if the Kerberos protocol is not negotiated for some reason, Active
Directory uses LM, NTLM, or NTLM version 2 (NTLMv2).
LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and is the
protocol that is used to authenticate all Windows clients when they perform the following
operations:
 Join a domain
 Authenticate between Active Directory forests
 Authenticate to domains based on earlier versions of Windows
 Authenticate to computers that do not run Windows 2000, Windows Server 2003,
Windows Vista, or Windows XP
 Authenticate to computers that are not in the domain
Possible values:
 Send LM & NTLM responses

 Send LM & NTLM - use NTLMv2 session security if negotiated
 Send NTLM responses only
 Send NTLMv2 responses only
 Send NTLMv2 responses only\refuse LM
 Send NTLMv2 responses only\refuse LM & NTLM
 Not Defined
The Network security: LAN Manager authentication level setting determines which
challenge/response authentication protocol is used for network logons. This choice affects
the authentication protocol level that clients use, the session security level that the
computers negotiate, and the authentication level that servers accept as follows:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Send LM & NTLM responses. Clients use LM and NTLM authentication and never use
NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2
authentication.
 Send LM & NTLM – Use NTLMv2 session security if negotiated. Clients use LM and NTLM
authentication and use NTLMv2 session security if the server supports it. Domain
controllers accept LM, NTLM, and NTLMv2 authentication.
 Send NTLM response only. Clients use NTLM authentication only and use NTLMv2
session security if the server supports it. Domain controllers accept LM, NTLM, and
NTLMv2 authentication.
 Send NTLMv2 response only. Clients use NTLMv2 authentication only and use NTLMv2
session security if the server supports it. Domain controllers accept LM, NTLM, and
NTLMv2 authentication.
 Send NTLMv2 response only\refuse LM. Clients use NTLMv2 authentication only and
use NTLMv2 session security if the server supports it. Domain controllers refuse LM
(accept only NTLM and NTLMv2 authentication).
 Send NTLMv2 response only\refuse LM & NTLM. Clients use NTLMv2 authentication
only and use NTLMv2 session security if the server supports it. Domain controllers refuse
LM and NTLM (accept only NTLMv2 authentication).
These settings correspond to the following security levels which are denoted by level number
in the associated registry settings:
 Level 0—Send LM and NTLM response; never use NTLMv2 session security. Clients use
LM and NTLM authentication, and never use NTLMv2 session security. Domain
 Level 1—Use NTLMv2 session security if negotiated. Clients use LM and NTLM
authentication, and use NTLMv2 session security if the server supports it. Domain
 Level 2—Send NTLM response only. Clients use only NTLM authentication, and use
NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM,
and NTLMv2 authentication.
 Level 3—Send NTLMv2 response only. Clients use NTLMv2 authentication, and use
NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM,
and NTLMv2 authentication.
 Level 4—Domain controllers refuse LM responses. Clients use NTLM authentication,
and use NTLMv2 session security if the server supports it. Domain controllers refuse LM
authentication, that is, they accept NTLM and NTLMv2.
 Level 5—Domain controllers refuse LM and NTLM responses (accept only NTLMv2).
Clients use NTLMv2 authentication, use and NTLMv2 session security if the server
supports it. Domain controllers refuse NTLM and LM authentication (they accept only
NTLMv2).
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
In Windows Vista, this setting is undefined. However, in Windows 2000, Windows Server 2003,
and Windows XP, clients are configured by default to send LM and NTLM authentication
responses (Windows 95-based and Windows 98-based clients only send LM). The default
setting on servers allows all clients to authenticate with servers and use their resources.
However, this means that LM responses—the weakest form of authentication response—are
sent over the network, and it is potentially possible for attackers to intercept that traffic to
more easily reproduce the user's password.
The Windows 95, Windows 98, and Windows NT operating systems cannot use the Kerberos
version 5 protocol for authentication. For this reason, in a Windows Server 2003 domain, these
computers authenticate by default with both the LM and NTLM protocols for network
authentication. You can enforce a more secure authentication protocol for Windows 95,
Windows 98, and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a secure
channel to protect the authentication process. Even if you use NTLMv2 for earlier clients and
servers, Windows-based clients and servers that are members of the domain will use the
Kerberos authentication protocol to authenticate with Windows Server 2003 domain
controllers.
Countermeasure
Configure the Network security: LAN Manager Authentication Level setting to Send NTLMv2
responses only. We and a number of independent organizations strongly recommend this
level of authentication when all clients support NTLMv2.
Potential impact
Clients that do not support NTLMv2 authentication will not be able to authenticate in the
domain and access domain resources by using LM and NTLM.
Network security: LDAP client signing requirements
This policy setting determines the level of data signing that is requested on behalf of clients
that issue LDAP BIND requests, as follows:
 None. The LDAP BIND request is issued with the caller-specified options.
 Negotiate signing. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) has not
been started, the LDAP BIND request is initiated with the LDAP data signing option set
in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND
request is initiated with the caller-specified options.
 Require signing. This level is the same as Negotiate signing. However, if the LDAP
server's intermediate saslBindInProgress response does not indicate that LDAP traffic
signing is required, the caller is told that the LDAP BIND command request failed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
This policy setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No
Microsoft LDAP clients that are included with Windows XP Professional or Windows Vista use
ldap_simple_bind or ldap_simple_bind_s to communicate with a domain controller.
Possible values:
 None
 Negotiate signing
 Require signature
 Not Defined
Vulnerability
Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder

captures the packets between the client and server, modifies them, and then forwards them
to the server. For an LDAP server, this susceptibility means that an attacker could cause a
server to make decisions that are based on false or altered data from the LDAP queries. To
lower this risk in your network, you can implement strong physical security measures to
protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks
extremely difficult if you require digital signatures on all network packets by means of IPsec
authentication headers.
Countermeasure
Configure the Network security: LDAP server signing requirements setting to Require
signature.
Potential impact
If you configure the server to require LDAP signatures, you must also configure the client. If
you do not configure the client, it will not be able to communicate with the server, which
could cause many features to fail, including user authentication, Group Policy, and logon
scripts.
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
This policy setting allows a client computer to require the negotiation of message
confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security.
These values are dependent on the LAN Manager Authentication Level policy setting value.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Possible values:
 Require message confidentiality. The connection will fail if encryption is not

negotiated. Encryption converts data into a form that is not readable until decrypted.
 Require message integrity. The connection will fail if message integrity is not
negotiated. The integrity of a message can be assessed through message signing.
Message signing proves that the message has not been tampered with; it attaches a
cryptographic signature that identifies the sender and is a numeric representation of
the contents of the message.
 Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not
negotiated.
 Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not
negotiated.
 Not Defined.
Vulnerability
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) might be exposed
such that an attacker who has gained access to the network can create man-in-the-middle
attacks.
Countermeasure
Enable all four options that are available for the Network security: Minimum session security
for NTLM SSP based (including secure RPC) clients policy setting.
Potential impact
Client computers that are enforcing these settings will be unable to communicate with older
servers that do not support them.
Network security: Minimum session security for NTLM SSP based (including secure RPC)
servers
This policy setting allows a server to require the negotiation of message confidentiality
(encryption), message integrity, 128-bit encryption, or NTLMv2 session security. These values
are dependent on the LAN Manager Authentication Level security setting value.
Possible values:
 Require message integrity. The connection will fail if message integrity is not
negotiated. The integrity of a message can be assessed through message signing.
Message signing proves that the message has not been tampered with; it attaches a
cryptographic signature that identifies the sender and is a numeric representation of
the contents of the message.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Require message confidentiality. The connection will fail if encryption is not

negotiated. Encryption converts data into a form that is not readable by anyone until
decrypted.
 Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not
negotiated.
 Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not
negotiated.
 Not Defined.
Vulnerability
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) might be exposed
such that an attacker who has gained access to the network can create man-in-the-middle
attacks.
Countermeasure
Enable all four options that are available for the Network security: Minimum session security
for NTLM SSP based (including secure RPC) servers policy.
Potential impact
Older clients that do not support these security settings will be unable to communicate with
the computer.
Recovery console: Allow automatic administrative logon
This policy setting determines whether the Administrator account password must be provided
before access to the computer is granted. If you enable this setting, the Administrator
account is automatically logged on to the computer at the Recovery Console; no password
is required.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
The Recovery Console can be very useful when you need to troubleshoot and repair
computers that do not start. However, it is dangerous to allow automatic logon to the
console. Anyone could walk up to the server, disconnect the power to shut it down, restart it,
select Recover Console from the Restart menu, and then assume full control of the server.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Disable the Recovery console: Allow automatic administrative logon setting.
Potential impact
Users will have to enter a user name and password to access the Recovery Console.
Recovery console: Allow floppy copy and access to all drives and all folders
This policy setting enables or disables the Recovery Console SET command, which allows you
to set the following Recovery Console environment variables.
 AllowWildCards. Enables wildcard support for some commands (such as the DEL
command).
 AllowAllPaths. Allows access to all files and folders on the computer.
 AllowRemovableMedia. Allows files to be copied to removable media, such as a
floppy disk.
 NoCopyPrompt. Suppresses the prompt that typically displays before an existing file is
overwritten.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
An attacker who can cause the system to restart into the Recovery Console could steal
sensitive data and leave no audit or access trail.
Countermeasure
Disable the Recovery console: Allow floppy copy and access to drives and folders setting.
Potential impact
Users who have started a server through the Recovery Console and logged in with the built-in
Administrator account will not be able to copy files and folders to a floppy disk.
Shutdown: Allow system to be shut down without having to log on
This policy setting determines whether a computer can be shut down without having to log
on to Windows. If you enable this policy setting, the Shut Down command is available on the
Windows logon screen. If you disable this policy setting, the Shut Down option is removed
tmg.edu.au | 1300 888 TMG (1300 888 864)
from the Windows logon screen. This configuration requires users to be able to log on to the
computer successfully and have the Shut down the system user right before they can
perform a computer shutdown.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
Users who can access the console locally could shut down the computer.
Attackers could also walk to the local console and restart the server, which would cause a
temporary DoS condition. Attackers could also shut down the server and leave all of its
applications and services unavailable.
Countermeasure
Disable the Shutdown: Allow system to be shut down without having to log on setting.
Potential impact
Operators will have to log on to servers to shut them down or restart them.
Shutdown: Clear virtual memory pagefile
This policy setting determines whether the virtual memory page file is cleared when the
computer is shut down. Virtual memory support uses a system page file to swap pages of
memory to disk when they are not used. On a running computer, this page file is opened
exclusively by the operating system, and it is well protected. However, computers that are
configured to allow other operating systems to start might have to make sure that the system
page file is cleared when the computer shuts down. This confirmation ensures that sensitive
information from process memory that might be placed in the page file is not available to an
unauthorized user who manages to directly access the page file after shutdown.
When you enable this policy setting, the system page file is cleared when the system shuts
down normally. Also, this policy setting will force the computer to clear the hibernation file
Hiberfil.sys when hibernation is disabled on a portable computer.
Possible values:
 Enabled
 Disabled
 Not Defined
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
Important information that is kept in real memory may be written periodically to the page file
to help Windows Server 2003 handle multitasking functions. An attacker who has physical
access to a server that has been shut down could view the contents of the paging file. The
attacker could move the system volume into a different computer and then analyze the
contents of the paging file. Although this process is time consuming, it could expose data
that is cached from random access memory (RAM) to the paging file.
Caution
An attacker who has physical access to the server could bypass this countermeasure by
simply unplugging the server from its power source.
Countermeasure
Enable the Shutdown: Clear virtual memory page file when system shuts down setting. This
configuration causes Windows Server 2003 to clear the page file when the computer is shut
down. The amount of time that is required to complete this process depends on the size of
the page file. As the process overwrites the storage area used by the page file several times,
it could be several minutes before the computer completely shuts down.
Potential impact
It will take longer to shut down and restart the server, especially on servers with large paging
files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting
could increase the shutdown process by 20 to 30 minutes, or more. For some organizations,
this downtime violates their internal service level agreements. Therefore, use caution before
you implement this countermeasure in your environment.
System cryptography: Force strong key protection for user keys stored on the computer
This policy setting determines whether users can use private keys, such as their S/MIME key,
without a password.
Possible values:
 User input is not required when new keys are stored and used
 User is prompted when the key is first used
 User must enter a password each time they use a key
 Not Defined
Vulnerability
If a user's account is compromised or the user's computer is inadvertently left unsecured, the
malicious user can use the keys stored for the user to access protected resources.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Configure the System cryptography: Force strong key protection for user keys stored on the
computer setting to User must enter a password each time they use a key so that users must
provide a password that is distinct from their domain password every time they use a key. This
configuration makes it more difficult for an attacker to access locally stored user keys, even if
the attacker takes control of the user's computer and determines their logon password.
Potential impact
Users will have to enter their password every time they access a key that is stored on their
computer. For example, if users use an S-MIME certificate to digitally sign their e-mail, they will
be forced to enter the password for that certificate every time they send a signed e-mail
message. For some organizations the overhead that is involved using this configuration may
be too high. At a minimum, this setting should be set to User is prompted when the key is first
used.
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
This policy setting determines whether the TLS/SSL Security Provider will support only the
Federal Information Processing Standard (FIPS)-compliant strong cipher suite known as
TLS_RSA_WITH_3DES_EDE_CBC_SHA, which means that the provider only supports the TLS
protocol as a client and as a server, if applicable. It uses only the Triple Data Encryption
Standard (DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-
Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only
the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing
requirements.
When this setting is enabled, the Encrypting File System (EFS) Service supports only the Triple
DES encryption algorithm for encrypting file data. By default, the Windows Vista and the
Windows Server 2003 implementation of EFS uses the Advanced Encryption Standard (AES)
with a 256-bit key. The Windows XP implementation uses DESX.
Possible values:
 Enabled
 Disabled
 Not Defined
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
This setting is configured differently in Windows Vista and Windows Server 2008 than in
Windows Server 2003 and Windows XP.
Vulnerability
You can enable this policy setting to ensure that the computer will use the most powerful
algorithms that are available for digital encryption, hashing and signing. Use of these
algorithms will minimize the risk of compromise of digitally encrypted or signed data by an
unauthorized user.
Countermeasure
Enable the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and
signing setting.
Potential impact
Client computers that have this policy setting enabled will be unable to communicate by
means of digitally encrypted or signed protocols with servers that do not support these
algorithms. Network clients that do not support these algorithms will not be able to use servers
that require them for network communications. For example, many Apache-based Web
servers are not configured to support TLS. If you enable this setting, you also need to
configure Internet Explorer® to use TLS. This policy setting also affects the encryption level
that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool
uses the RDP protocol to communicate with servers that run Terminal Services and client
computers that are configured for remote control; RDP connections will fail if both computers
are not configured to use the same encryption algorithms.
To enable Internet Explorer to use TLS
1. On the Internet Explorer Tools menu, click Internet Options.

2. Click the Advanced tab.
3. Select the Use TLS 1.0 check box.
It is also possible to configure this policy setting through Group Policy or by using the Internet
Explorer Administrators Kit.
System objects: Default owner for objects created by members of the Administrators group
This policy setting determines whether the Administrators group or an object creator is the
default owner of any system objects that are created.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Possible values:
 Administrators group
 Object creator
 Not Defined
Vulnerability
If you configure this policy setting to Administrators group, it will be impossible to hold
individuals accountable for the creation of new system objects.
Countermeasure
Configure the System objects: Default owner for objects created by members of the
Administrators group setting to Object creator.
Potential impact
When system objects are created, the ownership will reflect which account created the
object instead of the more generic Administrators group. A consequence of this policy
setting is that objects will become orphaned when user accounts are deleted. For example,
when a member of the information technology group leaves, any objects that they created
anywhere in the domain will have no owner. This situation could become an administrative
burden as administrators have to manually take ownership of orphaned objects to update
their permissions. This potential burden can be minimized if you can ensure that Full Control is
always assigned to new objects for a domain group such as Domain Admins.
System objects: Require case insensitivity for non-Windows subsystems
This policy setting enables or disables the enforcement of case insensitivity for all subsystems.
The Microsoft Win32® subsystem is case-insensitive. However, the kernel supports case
sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX).
If you enable this setting, case insensitivity is enforced for all directory objects, symbolic links,
and IO as well as file objects. If you disable this setting, case insensitivity is not enforced, but
the Win32 subsystem does not become case-sensitive.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
Because Windows is case-insensitive but the POSIX subsystem will support case sensitivity,
failure to enable this policy setting would make it possible for a user of that subsystem to
tmg.edu.au | 1300 888 TMG (1300 888 864)
create a file with the same name as another file but with a different mix of upper and lower
case letters. Such a situation could potentially confuse users when they try to access such
files from normal Win32 tools because only one of the files will be available.
Countermeasure
Enable the System objects: Require case insensitivity for non-Windows subsystems setting.
Potential impact
All subsystems will be forced to observe case insensitivity. This configuration may confuse
users who are familiar with any UNIX-based operating systems that are case-sensitive.
System objects: Strengthen default permissions of internal system objects (e.g. Symbolic
Links)
This policy setting determines the strength of the default DACL for objects. Windows
maintains a global list of shared computer resources (such as MS-DOS device names,
mutexes, and semaphores) so that objects can be located and shared among processes.
Each type of object is created with a default DACL that specifies who can access the
objects and with what permissions. If you enable this setting, the default DACL is
strengthened because non-administrator users are allowed to read shared objects but not
modify shared objects that they did not create.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
This setting is enabled by default to protect against a known vulnerability that can be used
with either hard links or symbolic links. Hard links are actual directory entries in the file system.
With hard links the same data in a file system can be referred to by different file names.
Symbolic links are text files that provide a pointer to the file that is interpreted and followed
by the operating system as a path to another file or directory. It is a file on its own and can
exist independently of its target. If a symbolic link is deleted, its target remains unaffected.
When this setting is disabled it is possible for a malicious user to destroy a data file by creating
a link that looks like a temporary file that the system automatically creates, such as a
sequentially named log file, but points to the data file that the malicious user wants to
eradicate. When the system writes the files with that name the data is overwritten. Enabling
System objects: Strengthen default permissions of internal system objects (e.g., Symbolic
Links) prevents an attacker from exploiting programs that create files with predictable names
by not allowing them to write to objects that they did not create.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Enable the System objects: Strengthen default permissions of global system objects (for
example, Symbolic Links) setting.
Potential impact
System settings: Optional subsystems
This policy setting determines which subsystems support your applications. You can use this
security setting to specify as many subsystems as your environment demands.
Possible values:
 User-defined list of subsystems

 Not Defined
Vulnerability
The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that
defines a set of operating system services. The POSIX subsystem is required if the server
supports applications that use that subsystem.
The POSIX subsystem introduces a security risk that relates to processes that can potentially
persist across logons. If a user starts a process and then logs out, there is a potential that the
next user who logs on to the computer could access the previous user's process. This
potential is dangerous, because anything the second user does with that process will be
performed with the privileges of the first user.
Countermeasure
Configure the System settings: Optional subsystems setting to a null value. The default value
is POSIX.
Potential impact
Applications that rely on the POSIX subsystem will no longer operate. For example, Microsoft
Services for Unix (SFU) installs an updated version of the POSIX subsystem that is required, so
you would need to reconfigure this setting in a Group Policy for any servers that use SFU.
System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies
This policy setting determines whether digital certificates are processed when software
restriction policies are enabled and a user or process attempts to run software with an .exe
tmg.edu.au | 1300 888 TMG (1300 888 864)
file name extension. This security setting enables or disables certificate rules (a type of
software restriction policies rule). With software restriction policies, you can create a
certificate rule that will allow or disallow Authenticode®-signed software to run, based on the
digital certificate that is associated with the software. For certificate rules to work in software
restriction policies, you must enable this security setting.
Possible values:
 Enabled
 Disabled
 Not Defined
Vulnerability
Without the use of software restriction policies, users and computers might be exposed to the
running of unauthorized software, such as viruses and Trojans horses.
Countermeasure
Enable the System settings: Use Certificate Rules on Windows Executables for Software
Restriction Policies setting.
Potential impact
If you enable certificate rules, software restriction policies check a certificate revocation list
(CRL) to ensure that the software's certificate and signature are valid. This checking process
may negatively affect performance when signed programs start. To disable this feature you
can edit the software restriction policies in the desired GPO. On the Trusted Publishers
Properties dialog box, clear the Publisher and Timestamp check boxes.
User Account Control: Admin Approval Mode for the Built-in Administrator account
This policy setting determines the behavior of Admin Approval mode for the built-in
Administrator account.
Possible values:
 Enabled. The built-in Administrator account will log on in Admin Approval Mode. By
default any operation that requires elevation of privilege will prompt the Consent
Admin to choose either Permit or Deny.
 Disabled. The built-in Administrator account will log on in XP compatible mode and
run all applications by default with full administrative privilege.
By default this setting is set to Disabled. However, if a computer is upgraded from a previous
version of Windows to Windows Vista and the "Administrator" account is the only account on
tmg.edu.au | 1300 888 TMG (1300 888 864)
the computer, the built-in Administrator account will remain enabled and this setting will also
be enabled.
Vulnerability
One of the risks that the User Account Control (UAC) feature introduced with Windows Vista is
trying to mitigate is that of malicious software running under elevated credentials without the
user or administrator being aware of its activity. An attack vector for these programs was to
discover the password of the account named "Administrator" because that user account
was created for all installations of Windows. To address this risk, in Windows Vista the built-in
Administrator account is disabled. In a default installation of a new computer, accounts with
administrative control over the computer are initially set up in one of two ways:
 If the computer is not joined to a domain, the first user account you create has the
equivalent permissions as a local administrator.
 If the computer is joined to a domain, no local administrator accounts are created.
The enterprise or domain administrator must log on to the computer and create one if
a local administrator account is warranted.
Once Windows Vista is installed, the built-in Administrator account may be enabled, but we
strongly recommend that this account remain disabled.
Countermeasure
Enable the User Account Control: Admin Approval Mode for the Built-in Administrator
account setting if you have the built-in Administrator account enabled.
Potential impact
Users who log on by using the local Administrator account will be prompted for consent
whenever a program requests an elevation in privilege.
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval
Mode
This policy setting determines the behavior of the elevation prompt for accounts that have
administrative credentials.
Possible values:
 Elevate without prompting. This option assumes that the administrator will permit an
operation that requires elevation and additional consent or credentials are not
required.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
Selecting Elevate without prompting minimizes the protection provided by the UAC
feature and is not recommended unless administrator accounts are tightly
controlled and the operating environment is highly secure.
 Prompt for credentials. An operation that requires elevation of privilege will prompt
the administrator to enter the user name and password. If the administrator enters
valid credentials the operation will continue with the applicable privilege.
 Prompt for consent. An operation that requires elevation of privilege will prompt the
administrator to select either Permit or Deny. If the administrator selects Permit, the
operation will continue with the administrator's highest available privilege.
The default value for this setting is Prompt for consent.
Vulnerability
One of the risks that the UAC feature introduced with Windows Vista is trying to mitigate is
that of malicious software running under elevated credentials without the user or
administrator being aware of its activity. This setting raises awareness to the administrator of
elevated privilege operations and permits the administrator to prevent a malicious program
from elevating its privilege when the program attempts to do so.
Countermeasure
Configure the User Account Control: Behavior of the elevation prompt for administrators in
Admin Approval Mode setting to Prompt for consent.
Potential impact
This is the default behavior. Administrators should be made aware that they will be prompted
for consent.
User Account Control: Behavior of the elevation prompt for standard users
This policy setting determines the behavior of the elevation prompt for standard users.
Possible values:
 Automatically deny elevation requests. This option results in an access denied error
message being returned to the standard user when they try to perform an operation
that requires elevation of privilege. Most enterprises running desktops as standard user
will configure this policy to reduce help desk calls.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Prompt for credentials. An operation that requires elevation of privilege will prompt
the user to enter an administrative user name and password. If the user enters valid
credentials the operation will continue with the applicable privilege.
The default configuration for this setting is Prompt for credentials.
Vulnerability
One of the risks that the UAC feature introduced with Windows Vista is trying to mitigate is
that of malicious programs running under elevated credentials without the user or
administrator being aware of their activity. This setting raises awareness to the user that a
program requires the use of elevated privilege operations and requires that the user be able
to supply administrative credentials in order for the program to run.
Countermeasure
Configure the User Account Control: Behavior of the elevation prompt for standard users to
Automatically deny elevation requests. This setting will require the user to log on with an
administrative account to run programs that require elevation of privilege. As a security best
practice, standard users should not have knowledge of administrative passwords. However, if
your users have both standard and administrator level accounts, then the Prompt for
credentials setting is recommended so that the users will not choose to always log in with
their administrator accounts and will shift their behavior to using the standard user account.
Potential impact
Users will need to provide administrative passwords to be able to run programs with elevated
privileges. This could cause an increased load on IT staff while the programs that are
affected are identified and standard operating procedures are modified to support least
privilege operations.
User Account Control: Detect application installations and prompt for elevation
This policy setting determines the behavior of application installation detection for the entire
system.
Possible values:
 Enabled. Application installation packages that require an elevation of privilege to

install will be detected and the user will be prompted for administrative credentials.
 Disabled. Enterprises running standard users desktops that leverage delegated
installation technologies like Group Policy Software Install (GPSI) or SMS may disable
this feature. In this case, installer detection is unnecessary and thus not required.
The default configuration for this setting is Enabled.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
Some malicious software will attempt to install itself after being given permission to run; for
example, malicious software with a trusted application shell. The user may have given
permission for the program to run because the program is trusted, but if they are then
prompted for installation of an unknown component this provides another way of trapping
the software before it can do damage.
Countermeasure
Enable the User Account Control: Detect application installations and prompt for elevation
setting.
Potential impact
Users will need to provide administrative passwords to be able to install programs.
User Account Control: Only elevate executables that are signed and validated
This policy setting enforces public key infrastructure (PKI) signature checks on any interactive
application that requests elevation of privilege. Enterprise administrators can control the
applications that are allowed to run through the population of certificates in the local
computer's Trusted Publishers store.
Possible values:
 Enabled. Enforces the PKI certificate chain validation of a given executable before it
is permitted to run.
 Disabled. Does not enforce PKI certificate chain validation before a given
executable is permitted to run.
The default configuration for this setting is Disabled.
Vulnerability
Intellectual property, personally identifiable information, and other confidential data are
normally manipulated by applications on the computer and require elevated credentials to
get access to the information. Users and administrators inherently trust applications used with
these information sources and provide their credentials. If one of these applications is
replaced by a rogue application that appears identical to the trusted application, the
confidential data could be compromised and the user's administrative credentials would
also be compromised.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Countermeasure
Enable the UserAccount Control: Only elevate executables that are signed and validated.
Potential impact
Enabling this setting requires that you have a PKI infrastructure and that your enterprise
administrators have populated the Trusted Publishers store with the certificates for the
allowed applications. Some older applications are not signed and will not be able to be
used in an environment that is hardened with this setting. You should carefully test your
applications in a pre-production environment before implementing this setting. For
information about the steps required to test application compatibility, make application
compatibility fixes, and sign installer packages to prepare your organization for deployment
of Windows Vista User Account Control, see Understanding and Configuring User Account
Control in Windows Vista (http://go.microsoft.com/fwlink/?LinkID=79026).
Control over the applications that are installed on the desktops and the hardware that is
able to join your domain should provide similar protection from the vulnerability addressed by
this setting. Additionally, the level of protection provided by this setting is not an assurance
that all rogue applications will be found
User Account Control: Only elevate UIAccess applications that are installed in secure
locations
This policy setting enforces the requirement that applications that request running with a
UIAccess integrity level (by means of a marking of UIAccess=true in their application
manifest), must reside in a secure location on the file system. Relatively secure locations are
limited to the following directories:
 \Program Files\ including subdirectories

 \Windows\system32\
 \Program Files (x86)\ including subdirectories for 64-bit versions of Windows
Note
Windows enforces a PKI signature check on any interactive application that requests
running with UIAccess integrity level regardless of the state of this security setting.
Possible values:
 Enabled. An application can start with UIAccess integrity only if it resides in a secure
location in the file system.
 Disabled. An application can start with UIAccess integrity even if it does not reside in
a secure location in the file system.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
UIAccess Integrity allows an application to bypass User Interface Privilege Isolation (UIPI)
restrictions when an application is elevated in privilege from a standard user to an
administrator. When this setting is enabled, an application that has the UIAccess flag set to
true in its manifest will be able to interchange information with applications that are running
at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability
is required to support accessibility features such as screen readers that are transmitting user
interfaces to alternative forms, but is not required by most applications. A process that is
started with UIAccess rights has the following abilities:
 To set the foreground window.

 To drive any application window by using the SendInput function.
 To use read input for all integrity levels by using low-level hooks, raw input,
GetKeyState, GetAsyncKeyState, and GetKeyboardInput.
 To set journal hooks.
 To use AttachThreadInput to attach a thread to a higher integrity input queue.
Countermeasure
Enable the User Account Control: Only elevate UIAccess applications that are installed in
secure locations setting.
Potential impact
If the application that requests UIAccess meets the UIAccess setting requirements,
Windows Vista starts the application with the ability to bypass most of the UIPI restrictions. If
the application does not meet the security restrictions, the application will be started without
UIAccess rights and can interact only with applications at the same or lower privilege level.
User Account Control: Run all users, including administrators, as standard users
This policy setting determines the behavior of all UAC policies for the entire system.
Possible values:
 Enabled. Admin Approval Mode and all other UAC policies are dependent on this
option being enabled. Changing this setting requires restarting the system.
 Disabled. Admin Approval Mode user type and all related UAC policies will be
disabled.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note
If this security setting is configured to Disabled, the Security Center will notify the user
that the overall security of the operating system has been reduced.
Vulnerability
This is the setting that turns on or off UAC. If this setting is disabled, UAC will not be used and
any security benefits and risk mitigations that are dependent on UAC will not be present on
the system.
Countermeasure
Enable the User Account Control: Run all users, including administrators, as standard users
setting.
Potential impact
Users and administrators will need to learn to work with UAC prompts and adjust their work
habits to use least privilege operations.
User Account Control: Switch to the secure desktop when prompting for elevation
This policy setting determines whether the elevation request will prompt on the interactive
user desktop or the secure desktop.
Possible values:
 Enabled. All elevation requests by default will go to the secure desktop.

 Disabled. All elevation requests will go to the interactive user desktop.
Vulnerability
Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to
malicious software.
Countermeasure
Enable the User Account Control: Switch to the secure desktop when prompting for elevation
setting. The secure desktop helps protect against input and output spoofing by presenting
tmg.edu.au | 1300 888 TMG (1300 888 864)
the credentials dialog box in a protected section of memory that is accessible only by
trusted system processes.
Potential impact
User Account Control: Virtualize file and registry write failures to per-user locations
This policy setting enables or disables the redirection of the write failures of earlier
applications to defined locations in both the registry and file system. This feature mitigates
those applications that historically ran as administrator and wrote runtime application data
back to either %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software\.
Virtualization facilitates the running of pre-Windows Vista-based applications that historically

failed to run with standard user privileges. An administrator running only Windows Vista–
compliant applications may choose to disable this feature as it is unnecessary.
Possible values:
 Enabled. Facilitates the runtime redirection of application write failures to defined

user locations for both the file system and registry.
 Disabled. Applications that write data to protected locations will simply fail as they
did in previous versions of Windows.
Vulnerability
Earlier applications might not write data to secure locations.
Countermeasure
Enable the User Account Control: Virtualize file and registry write failures to per-user locations
setting.
Potential impact
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 20
Describe 2 methods of securing remote server access.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 20
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configure the operating system or third-party firewall to filter traffic in line with security
requirements
Firewall is a barrier between Local Area Network (LAN) and the Internet. It allows keeping
private resources confidential and minimizes the security risks. It controls network traffic, in
both directions.
The following diagram depicts a sample firewall between LAN and the internet. The
connection between the two is the point of vulnerability. Both hardware and the software
can be used at this point to filter network traffic.
There are two types of Firewall system: One works by using filters at the network layer and the
other works by using proxy servers at the user, application, or network layer.
Key Points
 Firewall management must be addressed by both system managers and the network
managers.
 The amount of filtering a firewall varies. For the same firewall, the amount of filtering
may be different in different directions.
A firewall is a hardware or software system that prevents unauthorized access to or from a

network. It can be implemented in both hardware and software, or a combination of both.
Firewalls are frequently used to prevent unauthorized Internet users from accessing private
tmg.edu.au | 1300 888 TMG (1300 888 864)
networks connected to the Internet. All data entering or leaving the intranet pass through
the firewall, which examines each packet and blocks those that do not meet the specified
security criteria.
Generally, firewalls are configured to protect against unauthenticated interactive logins from
the outside world. This helps prevent hackers from logging into machines on your network.
More sophisticated firewalls block traffic from the outside to the inside, but permit users on
the inside to communicate a little more freely with the outside.
Firewalls are essential since they provide a single block point, where security and auditing
can be imposed. Firewalls provide an important logging and auditing function; often, they
provide summaries to the administrator about what type/volume of traffic has been
processed through it. This is an important benefit: Providing this block point can serve the
same purpose on your network as an armed guard does for your physical premises.
What are the different types of firewalls?
The National Institute of Standards and Technology (NIST) 800-10 divides firewalls into three
basic types:
 Packet filters
 Stateful inspection
 Proxys
These three categories, however, are not mutually exclusive, as most modern firewalls have a
mix of abilities that may place them in more than one of the three. For more information and
detail on each category, see the NIST Guidelines on firewalls and firewall policy.
tmg.edu.au | 1300 888 TMG (1300 888 864)
One way to compare firewalls is to look at the Transmission Control Protocol/Internet Protocol
(TCP/IP) layers that each is able to examine. TCP/IP communications are composed of four
layers; they work together to transfer data between hosts. When data transfers across
networks, it travels from the highest layer through intermediate layers to the lowest layer;
each layer adds more information. Then the lowest layer sends the accumulated data
through the physical network; the data next moves upward, through the layers, to its
destination. Simply put, the data a layer produces is encapsulated in a larger container by
the layer below it. The four TCP/IP layers, from highest to lowest, are described further in the
figure below.
Firewall implementation
The firewall remains a vital component in any network security architecture, and today's
organizations have several types to choose from. It's essential that IT professionals identify the
type of firewall that best suits the organization's network security needs.
Once selected, one of the key questions that shapes a protection strategy is "Where should
the firewall be placed?" There are three common firewall topologies: the bastion host,
screened subnet and dual-firewall architectures. Enterprise security depends on choosing the
right firewall topology.
The next decision to be made, after the topology chosen, is where to place individual firewall
systems in it. At this point, there are several types to consider, such as bastion host, screened
subnet and multi-homed firewalls.
Remember that firewall configurations do change quickly and often, so it is difficult to keep
on top of routine firewall maintenance tasks. Firewall activity, therefore, must be continuously
audited to help keep the network secure from ever-evolving threats.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network layer firewalls
Network layer firewalls generally make their decisions based on the source address,
destination address and ports in individual IP packets. A simple router is the traditional
network layer firewall, since it is not able to make particularly complicated decisions about
what a packet is actually talking to or where it actually came from.
One important distinction many network layer firewalls possess is that they route traffic
directly through them, which means in order to use one, you either need to have a validly
assigned IP address block or a private Internet address block. Network layer firewalls tend to
be very fast and almost transparent to their users.
Application layer firewalls
Application layer firewalls are hosts that run proxy servers, which permit no traffic directly
between networks, and they perform elaborate logging and examination of traffic passing
through them. Since proxy applications are simply software running on the firewall, it is a
good place to do logging and access control. Application layer firewalls can be used as
network address translators, since traffic goes in one side and out the other after having
passed through an application that effectively masks the origin of the initiating connection.
However, run-of-the-mill network firewalls can't properly defend applications. As Michael

Cobb explains, application layer firewalls offer Layer 7 security on a more granular level, and
may even help organizations get more out of existing network devices.
In some cases, having an application in the way may impact performance and make the
firewall less transparent. Older application layer firewalls that are still in use are not
particularly transparent to end users and may require some user training. However, more
modern application layer firewalls are often totally transparent. Application layer firewalls
tend to provide more detailed audit reports and tend to enforce more conservative security
models than network layer firewalls.
Future firewalls will likely combine some characteristics of network layer firewalls and
application layer firewalls. It is likely that network layer firewalls will become increasingly
aware of the information going through them, and application layer firewalls have already
become more transparent. The end result will be kind of a fast packet-screening system that
logs and checks data as it passes through.
Proxy firewalls
Proxy firewalls offer more security than other types of firewalls, but at the expense of speed
and functionality, as they can limit which applications the network supports.
Why are they more secure? Unlike stateful firewalls or application layer firewalls, which allow
or block network packets from passing to and from a protected network, traffic does not
flow through a proxy. Instead, computers establish a connection to the proxy, which serves
tmg.edu.au | 1300 888 TMG (1300 888 864)
as an intermediary, and initiate a new network connection on behalf of the request. This
prevents direct connections between systems on either side of the firewall and makes it
harder for an attacker to discover where the network is, because they don't receive packets
created directly by their target system.
Proxy firewalls also provide comprehensive, protocol-aware security analysis for the protocols
they support. This allows them to make better security decisions than products that focus
purely on packet header information.
Unified threat management
A new category of network security products -- called unified threat management (UTM) --
promises integration, convenience and protection from pretty much every threat out there;
these are especially valuable for enterprise use. As Mike Rothman explains, the evolution of
UTM technology and vendor offerings make these products even more valuable to
enterprises.
Security expert Karen Scarfone defines UTM products as firewall appliances that not only
guard against intrusion but also perform content filtering, spam filtering, application control,
Web content filtering, intrusion detection and antivirus duties; in other words, a UTM device
combines functions traditionally handled by multiple systems. These devices are designed to
combat all levels of malicious activity on the computer network.
An effective UTM solution delivers a network security platform comprised of robust and fully
integrated security and networking functions along with other features, such as security
management and policy management by a group or user. It is designed to protect against
next generation application layer threats and offers a centralized management through a
single console, all without impairing the performance of the network.
Advantages of using UTM
Convenience and ease of installation are the two key advantages of unified threat
management security appliances. There is also much less human intervention required to
install and configure them appliances. Other advantages of UTM are listed below:
 Reduced complexity: The integrated all-in-one approach simplifies not only product
selection but also product integration, and ongoing support as well.
 Ease of deployment: Since there is much less human intervention required, either
vendors or the customers themselves can easily install and maintain these products.
 Integration capabilities: UTM appliances can easily be deployed at remote locations
without the on-site help of any security professional. In this scenario a plug-and-play
appliance can be installed and managed remotely. This kind of management is
synergistic with large, centralized software-based firewalls.
 Black box character: Users have a tendency to play with things, and the black box
nature of a UTM limits the damage users can do and, thus, reduces help desk calls
and improves security.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Troubleshooting ease: When a box fails, it is easier to swap out than troubleshoot. This
process gets the node back online quicker, and a non-technical person can do it,
too. This feature is especially important for remote offices without dedicated
technical staff on site.
Some of the leading UTM solution providers are Check Point, Cisco, Dell, Fortinet, HP, IBM and
Juniper Networks.
Challenges of using UTM
UTM products are not the right solution for every environment. Many organizations already
have a set of point solutions installed that, combined, provide network security capabilities
similar to what UTMs offer, and there can be substantial costs involved in ripping and
replacing the existing technology install a UTM replacement. There are also advantages to
using the individual products together, rather than a UTM. For instance, when individual point
products are combined, the IT staff is able to select the best product available for each
network security capability; a UTM can mean having to compromise and acquire a single
product that has stronger capabilities in some areas and weaker ones in others.
Another important consideration when evaluating UTM solutions is the size of the organization
in which it would be installed. Smallest organizations might not need all the network security
features of a UTM. There is no need for a smaller firm to tax its budget with a UTM if many of its
functions aren't needed. On the other hand, a UTM may not be right for larger, more cyber-
dependent organizations either, since these often need a level of scalability and reliability in
their network security that UTM products might not support (or at least not support as well as
a set of point solutions). Also a UTM system creates a single point of failure for most or all
network security capabilities; UTM failure could conceivably shut down an enterprise, with a
catastrophic effect on company security. How much an enterprise is willing to rely on a UTM
is a question that must be asked, and answered.
PLACEMENT OF A FIREWALL
When developing a perimeter protection strategy for an organization, one of the most
common questions is "Where should I place firewalls for maximum effectiveness?" Security
expert Mike Chapple breaks up firewall placement into three basic topology options: bastion
host, screened subnet and dual firewalls.
The first, bastion host topology, is the most basic option, and is well suited for relatively simple
networks. This topology would work well if you're merely using the firewall to protect a
corporate network that is used mainly for surfing the Internet, but it is probably not sufficient if
you host a website or email server.
Firewall best practices
Network security expert Puneet Mehta gives you quick but detailed information on firewall
topology best practices in this expert response.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The screened subnet option provides a solution that allows organizations to offer services
securely to Internet users. Any servers that host public services are placed in the demilitarized
zone (DMZ), which is separated from both the Internet and the trusted network by the
firewall. Therefore, if a malicious user does manage to compromise the firewall, he or she
does not have access to the Intranet (providing that the firewall is properly configured).
The most secure (and most expensive) option is to implement a screened subnet using two
firewalls. The use of two firewalls still allows the organization to offer services to Internet users
through the use of a DMZ, but provides an added layer of protection.
ARE TWO FIREWALLS BETTER THAN ONE?
Most enterprises use a combination of firewalls, virtual private networks (VPNs) and intrusion
detection/prevention systems (IDS/IPS) to limit access to internal networks.
Generally speaking, there isn't much work to do in these areas; it's about maintaining these
controls and adapting them as dynamic infrastructures change. The maturity of the
technology offers the opportunity to focus limited financial and human resources on more
challenging problems, such as endpoint/server management and application security.
SearchSecurity expert Mike Chapple says that two firewalls from different vendors may not
cause processing delays, but if not used and arranged correctly, the devices can become a
hassle for IT teams. If you're experiencing network latency by adding an additional firewall,
consider the placement of the firewalls. Are they both directly connected to each other with
nothing else in between? If that's the case, consider using a different firewall topology that
will get the most out of the two firewalls.
FIREWALL IMPLEMENTATION PRECAUTIONS
Many people think that as long as their SAN or NAS is behind a firewall then everything is
protected. This is a myth of network security. Most storage environments span across multiple
networks, both private and public.
Storage devices are serving up multiple network segments and creating a virtual bridge that
basically negates any sort of firewall put in place. This can provide a conduit into the storage
environment, especially when a system is attacked and taken control of in the DMZ or public
segment. The storage back end can then be fully accessible to the attacker because there
is a path for the attack.
FIREWALL MANAGEMENT AND MAINTENANCE
We can only dream that once you've made it through the challenging phases of firewall
selection and architecture design, you're finished setting up a DMZ. In the real world of
firewall management, we're faced with balancing a continuous stream of change requests
and vendor patches against the operational management of our firewalls. Configurations
change quickly and often, making it difficult to keep on top of routine maintenance tasks.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Network security expert Michael Chapple takes a look at four practical areas where some
basic log analysis can provide valuable firewall management data:
 Monitor rule activity: System administrators tend to be quick on the trigger to ask for
new rules, but not quite so eager to let you know when a rule is no longer necessary.
Monitoring rule activity can provide some valuable insight to assist you with
managing the rulebase. If a rule that was once heavily used suddenly goes quiet, you
should investigate whether the rule is still needed. If it's no longer necessary, trim it
from your rulebase. Legacy rules have a way of piling up and adding unnecessary
complexity.
Over the years, Chapple had a chance to analyze the rulebases of many production
firewalls, and estimates that at least 20% of the average firewall's rulebase is unnecessary.
There are systems where this ratio is as high as 60%.
 Traffic flows: Monitor logs for abnormal traffic patterns. If servers that normally receive
a low volume of traffic are suddenly responsible for a significant portion of traffic
passing through the firewall (either in total connections or bytes passed), then you
have a situation worthy of further investigation. While flash crowds are to be
expected in some situations (such as a Web server during a period of unusual
interest), they are also often signs of misconfigured systems or attacks in progress.
 Rule violations: Looking at traffic denied by your firewall may lead to interesting
findings. This is especially true for traffic that originates from inside your network. The
most common cause of this activity is a misconfigured system or a user who isn't
aware of traffic restrictions, but analysis of rule violations may also uncover attempts
at passing malicious traffic through the device.
 Denied probes: If you've ever analyzed the log of a firewall that's connected to the
Internet, you know that it's futile to investigate probes directed at your network from
the Internet. They're far too frequent and often represent dead ends. However, you
may not have considered analyzing logs for probes originating from inside the trusted
network. These are extremely interesting, as they most likely represent either a
compromised internal system seeking to scan Internet hosts or an internal user running
a scanning tool -- both scenarios that merit attention.
Your firewall audit logs are a veritable goldmine of network security intelligence. Use them to
your advantage!
tmg.edu.au | 1300 888 TMG (1300 888 864)
Linux Firewall: IPTables Tables, Chains, Rules Fundamentals
iptables firewall is used to manage packet filtering and NAT rules. IPTables comes with all
Linux distributions. Understanding how to setup and configure iptables will help you manage
your Linux firewall effectively.
iptables tool is used to manage the Linux firewall rules. At a first look, iptables might look
complex (or even confusing). But, once you understand the basics of how iptables work and
how it is structured, reading and writing iptables firewall rules will be easy.
This article is part of an ongoing iptables tutorial series. This is the 1st article in that series.
This article explains how iptables is structured, and explains the fundamentals about iptables
tables, chains and rules.
On a high-level iptables might contain multiple tables. Tables might contain multiple chains.
Chains can be built-in or user-defined. Chains might contain multiple rules. Rules are defined
for the packets.
So, the structure is: iptables -> Tables -> Chains -> Rules. This is defined in the following
diagram.
Fig: IPTables Table, Chain, and Rule Structure
Just to re-iterate, tables are bunch of chains, and chains are bunch of firewall rules.
tmg.edu.au | 1300 888 TMG (1300 888 864)
I. IPTABLES TABLES and CHAINS
IPTables has the following 4 built-in tables.
1. Filter Table
Filter is default table for iptables. So, if you don’t define you own table, you’ll be using filter
table. Iptables’s filter table has the following built-in chains.
 INPUT chain – Incoming to firewall. For packets coming to the local server.
 OUTPUT chain – Outgoing from firewall. For packets generated locally and going out
of the local server.
 FORWARD chain – Packet for another NIC on the local server. For packets routed
through the local server.
2. NAT table
Iptable’s NAT table has the following built-in chains.
 PREROUTING chain – Alters packets before routing. i.e Packet translation happens
immediately after the packet comes to the system (and before routing). This helps to
translate the destination ip address of the packets to something that matches the
routing on the local server. This is used for DNAT (destination NAT).
 POSTROUTING chain – Alters packets after routing. i.e Packet translation happens
when the packets are leaving the system. This helps to translate the source ip address
of the packets to something that might match the routing on the desintation server.
This is used for SNAT (source NAT).
 OUTPUT chain – NAT for locally generated packets on the firewall.
3. Mangle table
Iptables’s Mangle table is for specialized packet alteration. This alters QOS bits in the TCP
header. Mangle table has the following built-in chains.
 PREROUTING chain
 OUTPUT chain
 FORWARD chain
 INPUT chain
 POSTROUTING chain
4. Raw table
Iptable’s Raw table is for configuration excemptions. Raw table has the following built-in
chains.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 PREROUTING chain
 OUTPUT chain
The following diagram shows the three important tables in iptables.
Fig: IPTables built-in tables
II. IPTABLES RULES
Following are the key points to remember for the iptables rules.
 Rules contain a criteria and a target.

 If the criteria is matched, it goes to the rules specified in the target (or) executes the
special values mentioned in the target.
 If the criteria is not matached, it moves on to the next rule.
Target Values
Following are the possible special values that you can specify in the target.
 ACCEPT – Firewall will accept the packet.

 DROP – Firewall will drop the packet.
 QUEUE – Firewall will pass the packet to the userspace.
 RETURN – Firewall will stop executing the next set of rules in the current chain for this
packet. The control will be returned to the calling chain.
If you do iptables –list (or) service iptables status, you’ll see all the available firewall rules on
your system. The following iptable example shows that there are no firewall rules defined on
tmg.edu.au | 1300 888 TMG (1300 888 864)
this system. As you see, it displays the default input table, with the default input chain,
forward chain, and output chain.
# iptables -t filter --list

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)

Do the following to view the mangle table.
# iptables -t mangle --list
Do the following to view the nat table.
# iptables -t nat --list
Do the following to view the raw table.
# iptables -t raw --list
Note: If you don’t specify the -t option, it will display the default filter table. So, both of the
following commands are the same.
# iptables -t filter --list

(or)
# iptables --list
The following iptable example shows that there are some rules defined in the input, forward,
and output chain of the filter table.
# iptables --list
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)

1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)

tmg.edu.au | 1300 888 TMG (1300 888 864)
Chain RH-Firewall-1-INPUT (2 references)

1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
3 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
5 ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
6 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631
7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
8 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
9 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
10 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
The rules in the iptables –list command output contains the following fields:
 num – Rule number within the particular chain

 target – Special target variable that we discussed above
 prot – Protocols. tcp, udp, icmp, etc.,
 opt – Special options for that specific rule.
 source – Source ip-address of the packet
 destination – Destination ip-address for the packet
Iptables is an extremely flexible firewall utility built for Linux operating systems. Whether you’re
a novice Linux geek or a system administrator, there’s probably some way that iptables can
be a great use to you. Read on as we show you how to configure the most versatile Linux
firewall.
About iptables
iptables is a command-line firewall utility that uses policy chains to allow or block traffic.
When a connection tries to establish itself on your system, iptables looks for a rule in its list to
match it to. If it doesn’t find one, it resorts to the default action.
iptables almost always comes pre-installed on any Linux distribution. To update/install it, just
retrieve the iptables package:
sudo apt-get install iptables
There are GUI alternatives to iptables like Firestarter, but iptables isn’t really that hard once
you have a few commands down. You want to be extremely careful when configuring
iptables rules, particularly if you’re SSH’d into a server, because one wrong command can
permanently lock you out until it’s manually fixed at the physical machine.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Types of Chains
iptables uses three different chains: input, forward, and output.
Input – This chain is used to control the behavior for incoming connections. For example, if a
user attempts to SSH into your PC/server, iptables will attempt to match the IP address and
port to a rule in the input chain.
Forward – This chain is used for incoming connections that aren’t actually being delivered
locally. Think of a router – data is always being sent to it but rarely actually destined for the
router itself; the data is just forwarded to its target. Unless you’re doing some kind of routing,
NATing, or something else on your system that requires forwarding, you won’t even use this
chain.
There’s one sure-fire way to check whether or not your system uses/needs the forward chain.
iptables -L -v
The screenshot above is of a server that’s been running for a few weeks and has no
restrictions on incoming or outgoing connections. As you can see, the input chain has
processed 11GB of packets and the output chain has processed 17GB. The forward chain,
on the other hand, has not needed to process a single packet. This is because the server isn’t
doing any kind of forwarding or being used as a pass-through device.
Output – This chain is used for outgoing connections. For example, if you try to ping
howtogeek.com, iptables will check its output chain to see what the rules are regarding ping
and howtogeek.com before making a decision to allow or deny the connection attempt.
The caveat
tmg.edu.au | 1300 888 TMG (1300 888 864)
Even though pinging an external host seems like something that would only need to traverse
the output chain, keep in mind that to return the data, the input chain will be used as well.
When using iptables to lock down your system, remember that a lot of protocols will require
two-way communication, so both the input and output chains will need to be configured
properly. SSH is a common protocol that people forget to allow on both chains.
Policy Chain Default Behavior
Before going in and configuring specific rules, you’ll want to decide what you want the
default behavior of the three chains to be. In other words, what do you want iptables to do if
the connection doesn’t match any existing rules?
To see what your policy chains are currently configured to do with unmatched traffic, run the
iptables -L command.
As you can see, we also used the grep command to give us cleaner output. In that
screenshot, our chains are currently figured to accept traffic.
More times than not, you’ll want your system to accept connections by default. Unless
you’ve changed the policy chain rules previously, this setting should already be configured.
Either way, here’s the command to accept connections by default:
iptables --policy INPUT ACCEPT

iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD ACCEPT
By defaulting to the accept rule, you can then use iptables to deny specific IP addresses or
port numbers, while continuing to accept all other connections. We’ll get to those
commands in a minute.
If you would rather deny all connections and manually specify which ones you want to allow
to connect, you should change the default policy of your chains to drop. Doing this would
probably only be useful for servers that contain sensitive information and only ever have the
same IP addresses connect to them.
iptables --policy INPUT DROP

iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
tmg.edu.au | 1300 888 TMG (1300 888 864)
Connection-specific Responses
With your default chain policies configured, you can start adding rules to iptables so it knows
what to do when it encounters a connection from or to a particular IP address or port. In this
guide, we’re going to go over the three most basic and commonly used “responses”.
Accept – Allow the connection.
Drop – Drop the connection, act like it never happened. This is best if you don’t want the
source to realize your system exists.
Reject – Don’t allow the connection, but send back an error. This is best if you don’t want a
particular source to connect to your system, but you want them to know that your firewall
blocked them.
The best way to show the difference between these three rules is to show what it looks like
when a PC tries to ping a Linux machine with iptables configured for each one of these
settings.
Allowing the connection:
Dropping the connection:
Rejecting the connection:
tmg.edu.au | 1300 888 TMG (1300 888 864)
Allowing or Blocking Specific Connections
With your policy chains configured, you can now configure iptables to allow or block specific
addresses, address ranges, and ports. In these examples, we’ll set the connections to DROP,
but you can switch them to ACCEPT or REJECT, depending on your needs and how you
configured your policy chains.
Note: In these examples, we’re going to use iptables -A to append rules to the existing chain.
iptables starts at the top of its list and goes through each rule until it finds one that it matches.
If you need to insert a rule above another, you can use iptables -I [chain] [number] to specify
the number it should be in the list.
Connections from a single IP address
This example shows how to block all connections from the IP address 10.10.10.10.
iptables -A INPUT -s 10.10.10.10 -j DROP
Connections from a range of IP addresses
This example shows how to block all of the IP addresses in the 10.10.10.0/24 network range.
You can use a netmask or standard slash notation to specify the range of IP addresses.
iptables -A INPUT -s 10.10.10.0/24 -j DROP
or
iptables -A INPUT -s 10.10.10.0/255.255.255.0 -j DROP
Connections to a specific port
This example shows how to block SSH connections from 10.10.10.10.
iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -j DROP
You can replace “ssh” with any protocol or port number. The -p tcp part of the code tells
iptables what kind of connection the protocol uses. If you were blocking a protocol that uses
UDP rather than TCP, then -p udp would be necessary instead.
tmg.edu.au | 1300 888 TMG (1300 888 864)
This example shows how to block SSH connections from any IP address.
iptables -A INPUT -p tcp --dport ssh -j DROP
Connection States
As we mentioned earlier, a lot of protocols are going to require two-way communication. For
example, if you want to allow SSH connections to your system, the input and output chains
are going to need a rule added to them. But, what if you only want SSH coming into your
system to be allowed? Won’t adding a rule to the output chain also allow outgoing SSH
attempts?
That’s where connection states come in, which give you the capability you’d need to allow
two way communication but only allow one way connections to be established. Take a look
at this example, where SSH connections FROM 10.10.10.10 are permitted, but SSH
connections TO 10.10.10.10 are not. However, the system is permitted to send back
information over SSH as long as the session has already been established, which makes SSH
communication possible between these two hosts.
iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -d 10.10.10.10 -m state --state ESTABLISHED -j ACCEPT
Saving Changes
The changes that you make to your iptables rules will be scrapped the next time that the
iptables service gets restarted unless you execute a command to save the changes. This
command can differ depending on your distribution:
Ubuntu:
sudo /sbin/iptables-save
Red Hat / CentOS:
/sbin/service iptables save
Or
/etc/init.d/iptables save
Other Commands
List the currently configured iptables rules:
iptables -L
tmg.edu.au | 1300 888 TMG (1300 888 864)
Adding the -v option will give you packet and byte information, and adding -n will list
everything numerically. In other words – hostnames, protocols, and networks are listed as
numbers.
To clear all the currently configured rules, you can issue the flush command.
iptables -F
Ubuntu Firewall Set Up
The Linux kernel includes the Netfilter subsystem, which is used to manipulate or decide the
fate of network traffic headed into or through your server. All modern Linux firewall
solutions use this system for packet filtering.
The kernel's packet filtering system would be of little use to administrators without a
userspace interface to manage it. This is the purpose of iptables: When a packet reaches
your server, it will be handed off to the Netfilter subsystem for acceptance, manipulation,
or rejection based on the rules supplied to it from userspace via iptables. Thus, iptables is all
you need to manage your firewall, if you're familiar with it, but many frontends are
available to simplify the task.
ufw - Uncomplicated Firewall
The default firewall configuration tool for Ubuntu is ufw. Developed to ease iptables firewall
configuration, ufw provides a user-friendly way to create an IPv4 or IPv6 host-based
firewall.
ufw by default is initially disabled. From the ufw man page:
“ ufw is not intended to provide complete firewall functionality via its command interface,
but instead provides an easy way to add or remove simple rules. It is currently mainly used
for host-based firewalls. ”
The following are some examples of how to use ufw:
 First, ufw needs to be enabled. From a terminal prompt enter:

 sudo ufw enable
 To open a port (SSH in this example):
 sudo ufw allow 22
 Rules can also be added using a numbered format:
 sudo ufw insert 1 allow 80
 Similarly, to close an opened port:
 sudo ufw deny 22
 To remove a rule, use delete followed by the rule:
 sudo ufw delete deny 22
tmg.edu.au | 1300 888 TMG (1300 888 864)
 It is also possible to allow access from specific hosts or networks to a port. The
following example allows SSH access from host 192.168.0.2 to any IP address on this
host:
 sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Replace 192.168.0.2 with 192.168.0.0/24 to allow SSH access from the entire subnet.
 Adding the --dry-run option to a ufw command will output the resulting rules, but
not apply them. For example, the following is what would be applied if opening the
HTTP port:
 sudo ufw --dry-run allow http
 *filter
 :ufw-user-input - [0:0]
 :ufw-user-output - [0:0]
 :ufw-user-forward - [0:0]
 :ufw-user-limit - [0:0]
 :ufw-user-limit-accept - [0:0]
 ### RULES ###

 ### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0
 -A ufw-user-input -p tcp --dport 80 -j ACCEPT

 ### END RULES ###
 -A ufw-user-input -j RETURN
 -A ufw-user-output -j RETURN
 -A ufw-user-forward -j RETURN
 -A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT]: "
 -A ufw-user-limit -j REJECT
 -A ufw-user-limit-accept -j ACCEPT
 COMMIT
 Rules updated
 ufw can be disabled by:
 sudo ufw disable
 To see the firewall status, enter:
 sudo ufw status
 And for more verbose status information use:
 sudo ufw status verbose
 To view the numbered format:
 sudo ufw status numbered
If the port you want to open or close is defined in /etc/services, you can use the port
name instead of the number. In the above examples, replace 22 with ssh.
This is a quick introduction to using ufw. Please refer to the ufw man page for more
information.
tmg.edu.au | 1300 888 TMG (1300 888 864)
ufw Application Integration
Applications that open ports can include an ufw profile, which details the ports needed for
the application to function properly. The profiles are kept in /etc/ufw/applications.d, and
can be edited if the default ports have been changed.
 To view which applications have installed a profile, enter the following in a terminal:
 sudo ufw app list
 Similar to allowing traffic to a port, using an application profile is accomplished by
entering:
 sudo ufw allow Samba
 An extended syntax is available as well:
 ufw allow from 192.168.0.0/24 to any app Samba
Replace Samba and 192.168.0.0/24 with the application profile you are using and
the IP range for your network.
There is no need to specify the protocol for the application, because that
information is detailed in the profile. Also, note that the app name replaces the
port number.
 To view details about which ports, protocols, etc., are defined for an application,
enter:
 sudo ufw app info Samba
Not all applications that require opening a network port come with ufw profiles, but if you
have profiled an application and want the file to be included with the package, please
file a bug against the package in Launchpad.
ubuntu-bug nameofpackage
IP Masquerading
The purpose of IP Masquerading is to allow machines with private, non-routable IP

addresses on your network to access the Internet through the machine doing the
masquerading. Traffic from your private network destined for the Internet must be
manipulated for replies to be routable back to the machine that made the request. To do
this, the kernel must modify the source IP address of each packet so that replies will be
routed back to it, rather than to the private IP address that made the request, which is
impossible over the Internet. Linux uses Connection Tracking (conntrack) to keep track of
which connections belong to which machines and reroute each return packet
accordingly. Traffic leaving your private network is thus "masqueraded" as having
originated from your Ubuntu gateway machine. This process is referred to in Microsoft
documentation as Internet Connection Sharing.
tmg.edu.au | 1300 888 TMG (1300 888 864)
ufw Masquerading
IP Masquerading can be achieved using custom ufw rules. This is possible because the
current back-end for ufw is iptables-restore with the rules files located in /etc/ufw/*.rules.
These files are a great place to add legacy iptables rules used without ufw, and rules that
are more network gateway or bridge related.
The rules are split into two different files, rules that should be executed before ufw
command line rules, and rules that are executed after ufw command line rules.
 First, packet forwarding needs to be enabled in ufw. Two configuration files will
need to be adjusted, in /etc/default/ufw change the DEFAULT_FORWARD_POLICY
to “ACCEPT”:
 DEFAULT_FORWARD_POLICY="ACCEPT"
Then edit /etc/ufw/sysctl.conf and uncomment:
net/ipv4/ip_forward=1
Similarly, for IPv6 forwarding uncomment:
net/ipv6/conf/default/forwarding=1
 Now add rules to the /etc/ufw/before.rules file. The default rules only configure the
filter table, and to enable masquerading the nat table will need to be configured.
Add the following to the top of the file just after the header comments:
 # nat Table rules
 *nat
 :POSTROUTING ACCEPT [0:0]

 # Forward traffic from eth1 through eth0.
 -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

 # don't delete the 'COMMIT' line or these nat table rules won't be processed
 COMMIT
The comments are not strictly necessary, but it is considered good practice to
document your configuration. Also, when modifying any of the rules files in
/etc/ufw, make sure these lines are the last line for each table modified:
# don't delete the 'COMMIT' line or these rules won't be processed

COMMIT
tmg.edu.au | 1300 888 TMG (1300 888 864)
For each Table a corresponding COMMIT statement is required. In these examples

only the nat and filter tables are shown, but you can also add rules for the raw and
mangle tables.
In the above example replace eth0, eth1, and 192.168.0.0/24 with the appropriate
interfaces and IP range for your network.
 Finally, disable and re-enable ufw to apply the changes:

 sudo ufw disable && sudo ufw enable
IP Masquerading should now be enabled. You can also add any additional FORWARD
rules to the /etc/ufw/before.rules. It is recommended that these additional rules be added
to the ufw-before-forward chain.
iptables Masquerading
iptables can also be used to enable Masquerading.
 Similar to ufw, the first step is to enable IPv4 packet forwarding by editing
/etc/sysctl.conf and uncomment the following line:
 net.ipv4.ip_forward=1
If you wish to enable IPv6 forwarding also uncomment:
net.ipv6.conf.default.forwarding=1
 Next, execute the sysctl command to enable the new settings in the configuration
file:
 sudo sysctl -p
 IP Masquerading can now be accomplished with a single iptables rule, which may
differ slightly based on your network configuration:
 sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE
The above command assumes that your private address space is 192.168.0.0/16
and that your Internet-facing device is ppp0. The syntax is broken down as follows:
o -t nat -- the rule is to go into the nat table

o -A POSTROUTING -- the rule is to be appended (-A) to the POSTROUTING
chain
o -s 192.168.0.0/16 -- the rule applies to traffic originating from the specified
address space
o -o ppp0 -- the rule applies to traffic scheduled to be routed through the
specified network device
o -j MASQUERADE -- traffic matching this rule is to "jump" (-j) to the
MASQUERADE target to be manipulated as described above
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Also, each chain in the filter table (the default table, and where most or all packet
filtering occurs) has a default policy of ACCEPT, but if you are creating a firewall in
addition to a gateway device, you may have set the policies to DROP or REJECT, in
which case your masqueraded traffic needs to be allowed through the FORWARD
chain for the above rule to work:
 sudo iptables -A FORWARD -s 192.168.0.0/16 -o ppp0 -j ACCEPT
 sudo iptables -A FORWARD -d 192.168.0.0/16 -m state \
 --state ESTABLISHED,RELATED -i ppp0 -j ACCEPT
The above commands will allow all connections from your local network to the
Internet and all traffic related to those connections to return to the machine that
initiated them.
 If you want masquerading to be enabled on reboot, which you probably do, edit
/etc/rc.local and add any commands used above. For example add the first
command with no filtering:
 iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE
Logs
Firewall logs are essential for recognizing attacks, troubleshooting your firewall rules, and
noticing unusual activity on your network. You must include logging rules in your firewall for
them to be generated, though, and logging rules must come before any applicable
terminating rule (a rule with a target that decides the fate of the packet, such as ACCEPT,
DROP, or REJECT).
If you are using ufw, you can turn on logging by entering the following in a terminal:
sudo ufw logging on
To turn logging off in ufw, simply replace on with off in the above command.
If using iptables instead of ufw, enter:
sudo iptables -A INPUT -m state --state NEW -p tcp --dport 80 \

-j LOG --log-prefix "NEW_HTTP_CONN: "
A request on port 80 from the local machine, then, would generate a log in dmesg that
looks like this (single line split into 3 to fit this document):
[4304885.870000] NEW_HTTP_CONN: IN=lo OUT=

MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=58288 DF PROTO=TCP
SPT=53981 DPT=80 WINDOW=32767 RES=0x00 SYN URGP=0
tmg.edu.au | 1300 888 TMG (1300 888 864)
The above log will also appear in /var/log/messages, /var/log/syslog, and

/var/log/kern.log. This behavior can be modified by editing /etc/syslog.conf appropriately
or by installing and configuring ulogd and using the ULOG target instead of LOG. The
ulogd daemon is a userspace server that listens for logging instructions from the kernel
specifically for firewalls, and can log to any file you like, or even to a PostgreSQL or MySQL
database. Making sense of your firewall logs can be simplified by using a log analyzing tool
such as logwatch, fwanalog, fwlogwatch, or lire.
Activity 21
What can't a firewall protect against?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 21
tmg.edu.au | 1300 888 TMG (1300 888 864)
Windows Firewall Configuration
The Windows Firewall made its debut in Windows XP. Prior to that, Windows system needed to
rely on third-party solutions or dedicated hardware to protect them from network-based
attacks. Over the years, Microsoft has done a great job with it and it is one of the best
firewalls you will ever find for Windows operating systems. Seriously, it is so good that some
commercial vendors have decided to piggyback on it!
Let’s talk about what you will learn in this lesson. First, you will learn about what the Windows
Firewall is, what it does, and how it works. Afterward, you will start to get your hands dirty and
edit the list of apps, programs, and features that are allowed to communicate through the
Windows Firewall depending on the type of network you are connected to.
Moving on from there, you will learn how to add new apps or programs to the list of allowed
items and how to remove the apps and programs that you want to block. Last but not least,
you will learn how to enable or disable the Windows Firewall, for only one type of networks or
for all network connections.
By the end of this lesson, you should know enough about the Windows Firewall to use and
manage it effectively.
What is the Windows Firewall?
Windows Firewall is an important security application that’s built into Windows. One of its roles
is to block unauthorized access to your computer. The second role is to permit authorized
data communications to and from your computer.
Windows Firewall does these things with the help of rules and exceptions that are applied
both to inbound and outbound traffic. They are applied depending on the type of network
you are connected to and the location you have set for it in Windows, when connecting to
the network. Based on your choice, the Windows Firewall automatically adjusts the rules and
exceptions applied to that network.
tmg.edu.au | 1300 888 TMG (1300 888 864)
This makes the Windows Firewall a product that’s silent and easy to use. It bothers you only
when it doesn’t have any rules and exceptions for what you are trying to do or what the
programs running on your computer are trying to do.
Another benefit of the Windows Firewall is that it is so tightly and nicely integrated into
Windows and all its networking features, that some commercial vendors decided to
piggyback onto it and use it in their security products. For example, products from
companies like Trend Micro or F-Secure no longer provide their proprietary firewall modules
but use the Windows Firewall instead.
Except for a few wording differences, the Windows Firewall works the same in Windows 7 and
Windows 8.x. The only notable difference is that in Windows 8.x you will see the word “app”
being used instead of “program.”
Where to Find the Windows Firewall
By default, the Windows Firewall is turned on and you don’t need to do anything special in
order for it work. You will see it displaying some prompts once in a while but they show up so
rarely that you might forget that is even working.
If you want to access it and configure the way it works, go to the Control Panel, then go to
“System and Security” and select “Windows Firewall.”
tmg.edu.au | 1300 888 TMG (1300 888 864)
Now you will see the Windows Firewall window where you can get a quick glimpse on
whether it is turned on and the type of network you are connected to: private networks or
public network.
tmg.edu.au | 1300 888 TMG (1300 888 864)
For the network type that you are connected to, you will see additional information like:
 The state of the Windows Firewall

 How the Windows Firewall deals with incoming connections
 The active network
 When the Windows Firewall will notify you
You can easily expand the other section and view the default settings that apply when
connecting to networks of that type.
If you have installed a third-party security application that also includes a firewall module,
chances are that the Windows Firewall has been disabled, in order to avoid performance
issues and conflicts between the two security products. If that is the case for your computer
or device, you won’t be able to view any information in the Windows Firewall window and
you won’t be able to configure the way it works.
Instead, you will see a warning that says: “These settings are being managed by vendor
application – Application Name.” In the screenshot below you can see an example of how
this looks.
tmg.edu.au | 1300 888 TMG (1300 888 864)
How to Allow Desktop Applications Through the Windows Firewall
Windows Firewall has a very comprehensive set of rules and most Windows programs that
you install add their own exceptions to the Windows Firewall so that they receive network
and Internet access. This means that you will see prompts from the Windows Firewall on
occasion, generally when you install programs that do not add their own exceptions to the
Windows Firewall’s list.
In a Windows Firewall prompt, you are asked to select the network locations to which you
allow access for that program: private networks or public networks. By default, Windows
Firewall selects the checkbox that’s appropriate for the network you are currently using.
tmg.edu.au | 1300 888 TMG (1300 888 864)
You can decide to allow access for both types of network locations or just to one of them. To
apply your setting press “Allow access.” If you want to block network access for that
program, press “Cancel” and the program will be set as blocked for both network locations.
At this step you should note that only administrators can set exceptions in the Windows
Firewall. If you are using a standard account without administrator permissions, the programs
that do not comply with the Windows Firewall rules and exceptions are automatically
blocked, without any prompts being shown.
You should note that in Windows 8.x you will never see any Windows Firewall prompts related
to apps from the Windows Store. They are automatically given access to the network and
the Internet based on the assumption that you are aware of the permissions they require
based on the information displayed by the Windows Store.
Windows Firewall rules and exceptions are automatically created for each app that you
install from the Windows Store. However, you can easily block access to the network and the
Internet for any app, using the instructions in the next section.
How to Customize the Rules for Allowed Apps
Windows Firewall allows any user with an administrator account to change the list of rules
and exceptions applied for apps and desktop programs. In order to do this, first start the
Windows Firewall.
tmg.edu.au | 1300 888 TMG (1300 888 864)
On the column on the left, click or tap “Allow an app or feature through Windows Firewall”
(in Windows 8.x) or “Allow a program or feature through Windows Firewall” (in Windows 7).
Now you see the list of apps and programs that are allowed to communicate through the
Windows Firewall. At this point, the list is grayed out and you can only view which apps,
features, and programs have rules that are enabled in the Windows Firewall.
You will notice that some entries have check marks on the left side of their name. This means
that the rule for that app, program or feature is enabled and used by the Windows Firewall to
allow or block access.
On the right, there are two columns: Private and Public. If a check mark is found in the
Private column it means that network access is given to that app, program, or feature when
you are connected to networks that are set as “private.” If a check mark is found in the
Public column it means that network access is given to that app, program or feature when
you are connected to networks that are set as “public.”
To change anything in this list, you need to press the “Change settings” button.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The list is no longer grayed out and you can edit any of the existing entries. You can select
any item for which you want to change the rules applied by Windows Firewall. To learn more
about it, press the “Details” button.
tmg.edu.au | 1300 888 TMG (1300 888 864)
You will see a small window that shows a description of the selected item or, if you have
selected a program, the path where it is installed and its name. When you’re finished, press
“OK.”
tmg.edu.au | 1300 888 TMG (1300 888 864)
For some items, the “Details” button is grayed out. That’s because there’s no additional
information stored by the Windows Firewall and there are no details available to display. You
will encounter this especially when selecting Windows Store apps.
If you want to block access to the network for an app, program, or feature, select it and then
uncheck the box near its name (to block access to any network) or one of the check boxes
on the right (Private or Public), depending on the types of networks you want to block access
to.
Alternatively, if you want to give network access to an app, program, or feature that doesn’t
have it, enable the checkbox near its name and then set the types of networks you give it
access to.
When you’re done setting things up, press “OK.”
How to Add Apps & Programs to the Allowed List
In the rare event that an app or program that you want to give network access to is not in
this list, you can easily add it. First, make sure that the list of allowed apps, programs, and
tmg.edu.au | 1300 888 TMG (1300 888 864)
features is editable, using the procedure described in the previous section, then click or tap
“Allow another app” (in Windows 8.x) or “Allow another program” (in Windows 7).
In the “Add an app”/”Add a Program” window, look for the app or program that you want
to add and select it. If you can’t find it, press “Browse,” go to its location and select its
executable, then click or tap the “Add” button.
tmg.edu.au | 1300 888 TMG (1300 888 864)
You are back to the list of items allowed through the Windows Firewall. The program or app
that you just added is now selected and you can edit the types of networks it can access.
tmg.edu.au | 1300 888 TMG (1300 888 864)
When you’re done adding programs and apps, press “OK” to apply your settings.
How to Remove Apps and Programs from the Allowed List
You can also remove apps or desktop programs from the list of items allowed through the
Windows Firewall. When you remove an app or program, it becomes blocked by default and
the next time you use it, you will see a prompt from the Windows Firewall, requesting your
approval for giving network access to it.
First, make sure that the list of allowed apps, programs, and features is editable, using the
procedure shared earlier in this lesson, then select the app or program that you want to
delete and press “Remove.”
tmg.edu.au | 1300 888 TMG (1300 888 864)
You are asked to confirm your choice. Press “Yes” and the selected app or program is
removed from the list of items allowed through the Windows Firewall.
Press “OK” to save your changes.
tmg.edu.au | 1300 888 TMG (1300 888 864)
How to Enable or Disable the Windows Firewall
In order to enable or disable the Windows Firewall, you must first open it, then look on the left
column and click or tap the link that says “Turn Windows Firewall on or off.”
The “Customize Settings” window is now opened. Here you can set how to turn on or off the
Windows Firewall: turn it on or off just for private networks, for public networks, or for both
types of networks.
For example, you can set the Windows Firewall to be turned off when you are connected to
trusted private networks like the one in your home and to be turned on when you are
connected to untrusted public networks. While having this kind of flexibility is great, not that
many people understand the concept of network locations, what is different about them,
and what profile to assign to each network connection you make.
To recap, if you want to enable the Windows Firewall only for private networks, then select
“Turn on Windows Firewall” in the “Private network settings” section. If you want to enable it
only for public networks, then select “Turn on Windows Firewall” in the “Public network
tmg.edu.au | 1300 888 TMG (1300 888 864)
settings” section. If you want it to turn it on for all types of networks select this setting in both
sections and press “OK.”
The same goes for disabling the Windows Firewall. Select “Turn off Windows Firewall” in both
sections if you want to disable it completely or select this setting only for the type of networks
where you don’t want to use it. When done, press “OK” to save your settings.
tmg.edu.au | 1300 888 TMG (1300 888 864)
How to Create Advanced Firewall Rules in the Windows Firewall
Windows’ built-in firewall hides the ability to create powerful firewall rules. Block programs
from accessing the Internet, use a whitelist to control network access, restrict traffic to
specific ports and IP addresses, and more – all without installing another firewall.
The firewall includes three different profiles, so you can apply different rules to private and
public networks. These options are included in the Windows Firewall with Advanced Security
snap-in, which first appeared in Windows Vista.
Accessing the Interface
There are a variety of ways to pull up the Windows Firewall with Advanced Security window.
One of the most obvious is from the Windows Firewall control panel – click the Advanced
settings link in the sidebar.
tmg.edu.au | 1300 888 TMG (1300 888 864)
You can also type “Windows Firewall” into the search box in the Start menu and select the
Windows Firewall with Advanced Security application.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Configuring Network Profiles
The Windows firewall uses three different profiles:
 Domain Profile: Used when your computer is connected to a domain.

 Private: Used when connected to a private network, such as a work or home network.
 Public: Used when connected to a public network, such as a public Wi-Fi access
point or a direct connection to the Internet.
Windows asks whether a network is public or private when you first connect to it.
A computer may use multiple profiles, depending on the situation. For example, a business
laptop may use the domain profile when connected to a domain at work, the private profile
when connected to a home network, and the public profile when connected to a public Wi-
Fi network – all in the same day.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Click the Windows Firewall Properties link to configure the firewall profiles.
The firewall properties window contains a separate tab for each profile. Windows blocks
inbound connections and allows outbound connections for all profiles by default, but you
can block all outbound connections and create rules that allow specific types of
connections. This setting is profile-specific, so you can use a whitelist only on specific
networks.
If you block outbound connections, you won’t receive a notification when a program is
blocked – the network connection will fail silently.
Creating a Rule
To create a rule, select the Inbound Rules or Outbound Rules category at the left side of the
window and click the Create Rule link at the right side.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Windows firewall offers four types of rules:
 Program – Block or allow a program.

 Port – Block or a allow a port, port range, or protocol.
 Predefined – Use a predefined firewall rule included with Windows.
 Custom – Specify a combination of program, port, and IP address to block or allow.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Example Rule: Blocking a Program
Let’s say we want to block a specific program from communicating with the Internet — we
don’t have to install a third-party firewall to do that.
First, select the Program rule type. On the next screen, use the Browse button and select the
program’s .exe file.
tmg.edu.au | 1300 888 TMG (1300 888 864)
On the Action screen, select “Block the connection.” If you were setting up a whitelist after
blocking all applications by default, you’d select “Allow the connection” to whitelist the
application instead.
tmg.edu.au | 1300 888 TMG (1300 888 864)
On the Profile screen, you can apply the rule to a specific profile – for example, if you only
want a program blocked when you’re connected to public Wi-Fi and other insecure
networks, leave the “Public” box checked. By default, Windows applies the rule to all profiles.
tmg.edu.au | 1300 888 TMG (1300 888 864)
On the Name screen, you can name the rule and enter an optional description. This will help
you identify the rule later.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Firewall rules you create take effect immediately. Rules you create will appear in the list, so
you can easily disable or delete them.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Example Rule: Restricting Access
If you really want to lock down a program, you can restrict the ports and IP addresses it
connects to. For example, let’s say you have a server application that you only want
accessed from a specific IP address.
From the Inbound Rule list, click New Rule and select the Custom rule type.
tmg.edu.au | 1300 888 TMG (1300 888 864)
On the Program pane, select the program you want to restrict. If the program is running as a
Windows service, use the Customize button to select the service from a list. To restrict all
network traffic on the computer to communicating with a specific IP address or port range,
select “All programs” instead of specifying a specific program.
tmg.edu.au | 1300 888 TMG (1300 888 864)
On the Protocol and Ports pane, select a protocol type and specify ports. For example, if
you’re running a web server application, you can restrict the web server application to TCP
connections on ports 80 and 443 by entering these ports in the Local port box.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Scope tab allows you to restrict IP addresses. For example, if you only want the server
communicating with a specific IP address, enter that IP address in the remote IP addresses
box.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Select the “Allow the connection” option to allow the connection from the IP address and
ports you specified. Be sure to check that no other firewall rules apply to the program – for
example, if you have a firewall rule that allows all inbound traffic to the server application,
this rule won’t do anything.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The rule takes effect after you specify the profiles it will apply to and name it.
The Windows firewall isn’t as easy-to-use as third-party firewalls, but it offers a surprising
amount of power. If you want more control and ease of use, you may be better off with a
third-party firewall.
Manage the Windows Server 2012 Firewall
This article will detail how to perform the most common tasks with the windows firewall on
Windows Server 2012. This includes managing the firewall settings and creating custom
inbound and outbound firewall rules.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Manage firewall settings
The Windows Firewall with Advanced Security is a host-based firewall that runs on Windows
Server 2012 and is turned on by default. Firewall settings within Windows Server 2012 are
managed from within the Windows Firewall MMC (Microsoft Management Console). To
review and set Firewall settings perform the following:
1. Open the Server Manager from the task bar.

2. In the right-hand side of the top navigation bar, click Tools and select Windows
Firewall with Advanced Security.
3. First review the current configuration settings by selecting Windows Firewall Properties
from the MMC landing page. This allows access to modify the settings for each of the
three firewall profiles, Domain, Private, and Public, as well as IPSec settings.
Applying Custom Rules
Custom Rules allow the finest level of control over inbound and outbound traffic to your
Windows Server 2012.
1. If you have not already done so, load the Windows Firewall MMC by opening the
Server Manager from the task bar, clicking the Tools menu, and selecting Windows
Firewall with Advanced Security.
2. Select either Inbound Rules or Outbound Rules under Windows Firewall with
Advanced Security on the left side of the management console.
Note: This will provide a listing on each of the currently configured firewall rules. Rules
that are currently enabled are denoted by green checkbox icon, while disabled rules
display a grey checkbox icon. Right-clicking a rule will allow you toggle
enable/disable.
3. From the right side of either the Inbound Rules or Outbound Rules tab click New Rule.
The new rule wizard launches.
4. Select Custom from the Rule Type radial button and click Next.
5. Select the Program association for the Custom Firewall Rule as either All programs or
specify the path to a program and click Next.
6. From the Protocol type field select the protocol type and click Next.
Note: This walkthrough uses TCP on port 80 (HTTP) for example purposes.
tmg.edu.au | 1300 888 TMG (1300 888 864)
7. Select an IP address association for both local and remote addresses and click Next.
8. For traffic matching the IP address(es) you specified in the previous step, select
whether to Allow the connection, Allow the connection if it is secure, or Block the
connection and click Next.
Note: If you choose to allow the connection if it is secure, you can customize this
further by clicking Customize.
9. Select which profiles you want to associate with the custom rule, Domain, Public, or
Private, and click Next.
10. Provide a name for your Firewall rule and an optional description and click Finish.
11. After you finish creating the rule, it is automatically enabled.
The firewall rule can be found on the corresponding Rule tab, either inbound or outbound
depending on the type created. To disable or delete the rule find the rule in the MMC, right-
click it, and select either Disable Rule or Delete.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 22
What are Network layer firewalls?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 22
tmg.edu.au | 1300 888 TMG (1300 888 864)
Ensure security of server logs and log servers are appropriately implemented for system
integrity
Activity 23
Select one server you have access to. Summarise the logs kept on the server and their
locations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 23
tmg.edu.au | 1300 888 TMG (1300 888 864)
Event Logs in Windows
The event logs record events that happen on the computer. Examining the events in these
logs can help you trace activity, respond to events, and keep your systems secure.
Configuring these logs properly can help you manage the logs more efficiently and use
the information they provide more effectively.
Windows Vista® has a new event system that saves event log files into XML files that can
be reported on and managed as part of a collective reporting schema. There are several
additional log providers and categories that you can monitor.
Event Viewer in Windows Vista tracks information in a number of logs, including:
 Application. Events in this log are classified as error, warning, or information,

depending on the severity of the event. An error is a significant problem, such as
loss of data. A warning is an event that is not necessarily significant, but might
indicate a possible future problem. An information event describes the successful
operation of a program, driver, or service.
 Security. This log contains security-related events, which are called audit events,
and are described as successful or failed, depending on the event, such as
whether a user's attempt to log on to Windows® was successful.
 Setup. Computers that are configured as domain controllers will have additional
logs displayed here.
 System. System events are sent to this log by Windows and Windows system
services, and are classified as error, warning, or information.
 Forwarded Events. Events are forwarded to this log by other computers.
Each of these logs each have attributes, such as maximum log size, access rights for each
log, and retention settings and methods, that can be defined in the Event Log section in
Group Policy.
Event Log Settings
You can configure the event log settings in the following location within the Group Policy
Management Console:
Computer Configuration\Windows Settings\Security Settings\Event Log\
The following sections describe the options and issues for configuring event log settings for
better system management and security.
Maximum event log size
This policy setting specifies the maximum sizes of the Application, Security, and System logs.
Although the user interfaces (UIs) of both the Group Policy Object Editor and Event Viewer
allow you to enter values as large as 4 gigabytes (GB), the effective maximum size for
tmg.edu.au | 1300 888 TMG (1300 888 864)
these logs is much smaller in the 32-bit version of Windows Server 2003. If you are using the
64-bit version of Windows Server 2003, you can use the 4-GB maximum value. However,
larger log file sizes can affect system performance.
Note
Windows Vista and Windows Server 2008 use a new event reporting infrastructure and do
not exhibit the behavior described in the following paragraphs.
The Event Log service uses memory-mapped files, and it runs as one of the services under
the Services.exe process as Eventlog.dll. When files are loaded in this way, the entire file is
loaded into the computer's memory. All of the current versions of Windows have an
architectural limitation with regard to memory-mapped files: no process can have more
than 1 GB of memory-mapped files in total. This limitation means that all of the services that
run under the Services.exe process must share the 1-GB pool. The memory is assigned in
contiguous 64-kilobyte (KB) portions, and if the computer cannot assign additional memory
to expand memory-mapped files, problems will occur.
For the Event Log service, the use of memory-mapped files means that regardless of the
amount of memory that a maximum event log size setting specifies, events can no longer
be recorded in the log when the computer has no more memory available for the
memory-mapped file. Error messages will not be displayed; the events will simply not
appear in the event log, or they might overwrite other events that had been recorded
previously. Fragmentation of the log files within memory has also been shown to lead to
significant performance problems on busy computers.
Because of these limitations—even though the theoretical limit for memory-mapped files
suggests otherwise and the Event Viewer and Group Policy Object Editor user interfaces
allow you to specify as much as 4 GB per log—we have verified that the practical limit is
approximately 300 megabytes (MBs) on most 32-bit servers running Windows Server 2003—
that is, 300 MBs for all of the event logs combined. On Windows XP-based computers,
member servers, and stand-alone servers, the combined size of the Application, Security,
and System logs should not exceed 300 MBs. On domain controllers, the combined size of
these three logs plus the Directory Service, the DNS Server service, and File Replication
Service logs should not exceed 300 MBs.
Although there is no simple equation to determine the best log size for a particular server,
you can calculate a reasonable size. The average event takes up about 500 bytes within
each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the
average number of events that are generated each day for each type of log in your
organization, you can determine a good size for each type of log file.
For example, if your file server generates 5,000 events per day in its Security log and you
want to ensure that you have at least four weeks of data available at all times, then you
should configure the size of that log to about 70 MB (500 bytes * 5000 events/day * 28 days
tmg.edu.au | 1300 888 TMG (1300 888 864)
= 70,000,000 bytes). Then, check the servers occasionally over the following four weeks to
verify that your calculations are correct and that the logs retain enough events for your
needs. Event log size and log wrapping should be defined to match the business and
security requirements you determined when you designed your organization's security
plan.
Possible values:
 User-defined value in KBs between 64 and 4,194,240, which must be a multiple of 64

 Not Defined
Vulnerability
If you significantly increase the number of objects to audit in your organization and if you
enabled the Audit: Shut down system immediately if unable to log security audits setting,
there is a risk that the Security log will reach its capacity and force the computer to shut
down. If such a shutdown occurs, the computer will be unusable until an administrator
clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down
system immediately if unable to log security audits setting, and increase the Security log
size.
Countermeasure
Enable sensible log size policies for all computers in your organization so that legitimate
users can be held accountable for their actions, unauthorized activity can be detected
and tracked, and computer problems can be detected and diagnosed.
Potential impact
When event logs fill to capacity, they stop recording information unless the retention
method for each is set so that the computer will overwrite the oldest entries with the most
recent ones. To mitigate the risk of loss of recent data, you can configure the retention
method so that older events are overwritten as needed.
The consequence of this configuration is that older events are removed from the logs.
There are many ways that attackers can take advantage of event log configurations. If
the log is set to overwrite events, attackers could overwrite evidence of their attack by
generating a large number of spurious events that fill the log after performing some
malicious activity. If the log is set to not overwrite events, an attacker could generate
enough events to fill the logs first and then perform the malicious actions that would not be
recorded. If the log is set to shut down the computer if unable to write logs, the attacker
could use this to provoke a denial of service (DoS). The only ways to circumvent these
vulnerabilities are to set an event log size large enough not to be easy to fill, to frequently
monitor and export logs, to set audit policy to only log useful events, and to filter access to
tmg.edu.au | 1300 888 TMG (1300 888 864)
the systems so that it is difficult for malicious users to perform actions that result in spurious
events being recorded.
Ideally, all specifically monitored events should be sent to a server that uses System Center
Operations Manager 2007 or other automated monitoring tool. Such a configuration is
particularly important because an attacker who successfully compromises a server could
clear the Security log. If all events are sent to a monitoring server, you will be able to
gather forensic information about the attacker's activities.
Prevent local guests group from accessing event logs
This policy setting determines whether guests can access the Application, Security, and
System logs.
Possible values:
 Enabled
 Disabled
 Not Defined
Note
This policy setting does not appear in the Local Computer Policy object.
This policy setting only affects computers that run Windows 2000 and subsequent versions
of Windows.
Vulnerability
Attackers who successfully log onto a computer with guest privileges could learn important
information about the computer if they are able to view the event logs. They could then
use this information to implement additional exploits.
Countermeasure
Enable the Prevent local guests group from accessing event logs setting for the policies of
all three event logs.
Potential impact
tmg.edu.au | 1300 888 TMG (1300 888 864)
Retain event log
This policy setting determines the number of days of event log data to retain for the
Application, Security, and System logs if the retention method that is specified for the log is
By Days. You should only configure this setting if you archive the log at scheduled intervals
and you ensure that the maximum log size is large enough to accommodate the interval.
Possible values:
 User-defined number in days between 1 and 365

 Not Defined
Note
A user must be assigned the Manage auditing and security log user right to access the
Security log.
Vulnerability
Retaining event logs introduces a greater risk of both a DoS attack by filling up the event
log and an evidence obfuscation method by preventing critical information about an
attack from being logged due to lack of space during the interval period.
Countermeasure
Configure the Retain event log setting for the policies of all three event logs to Not Defined.
If you decide that you must retain the event log and set up a scheduled interval to archive
the log, you can partially mitigate the risk introduced to your systems by configuring the
setting as follows:
1. Open the Properties dialog box for this policy setting.

2. Specify the appropriate number of days in the Retain application log setting.
3. Select Overwrite events by days for the event log retention method.
Also, ensure that the maximum log size is large enough to accommodate the interval.
Potential impact
tmg.edu.au | 1300 888 TMG (1300 888 864)
Retention method for event log
This policy setting determines the wrapping method for the Application, Security, and
System logs.
Possible values:
 Overwrite events by days

 Overwrite events as needed
 Do not overwrite events (clear log manually)
 Not defined
Note
To prevent the archiving of the Application log
1. Open the Properties dialog box for the Retention method for application log policy
setting.
2. Select the Define this policy setting check box.
3. Click Overwrite events as needed, and then click OK.
To archive the Application log at scheduled intervals
1. Open the Properties dialog box for the Retention method for application log policy.
3. Click Overwrite events by days, and then click OK.
4. Open the Properties dialog box for the Retain application log policy.
6. Specify the appropriate number of days in the Retain application log box, and
then click OK. Ensure that the maximum log size is large enough to accommodate
the interval.
To retain all the events in the Application log
1. Open the Properties dialog box for the Retention method for application log policy.
3. Click Do not overwrite events (clear log manually), and then click OK.
This option requires that the log be cleared manually. In this configuration, new events are
discarded when the maximum log size is reached.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability
If you significantly increase the number of objects to audit in your organization, there is a
risk that the Security log will reach its capacity and force the computer to shut down. If
such a shutdown occurs, the computer will be unusable until an administrator clears the
Security log. To prevent such a shutdown, you can disable the Audit: Shut down system
immediately if unable to log security audits setting and then increase the Security log size.
If you set the Retention method for event log to Manual or Overwrite events by days, it is
possible for important recent events to not be recorded or for a DoS attack to occur.
Countermeasure
Configure the retention method for all three event logs to the option Overwrite events as
needed. Some resources recommend that you configure this setting to Manual; however,
the administrative burden that this setting imposes is too great for most organizations.
Ideally, all significant events will be sent to a monitoring server that uses Operations
Manager 2007 or other automated monitoring tool.
Potential impact
When event logs fill to capacity, they will stop recording information unless the retention
method is set so that the computer can overwrite the oldest entries with the most recent
ones.
Delegating access to the event logs
In Windows Server® 2003, Windows Vista, and Windows Server® 2008, it is possible to
customize the permissions on each event log on a computer. This capability was not
available in previous versions of Windows. Some organizations may want to grant read-
only access to one or more of the System event logs to some members of the IT team, such
as auditors. The access control list (ACL) is stored as a Security Descriptor Definition
Language (SDDL) string, in a REG_SZ value called "CustomSD" for each event log in the
registry. The following procedure shows how to delegate read-only access for an event
log. You will need to repeat this procedure for each event log that you wish to delegate
read-only access to by changing the registry key as needed.
Caution
Incorrectly editing the registry may severely damage your system. Before making changes
to the registry, you should back up any valued data on the computer.
tmg.edu.au | 1300 888 TMG (1300 888 864)
To delegate access to an event log using the registry
1. Open Registry Editor.

2. Navigate to the following registry path:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog
You will see that there are keys available for each event log. Select the event log
for which you want to delegate read-only access.
3. Add a new key with the name CustomSD to the event log you selected.
4. Add a new String value to the CustomSD key. The name of this string is not required,
but it represents the access control list for the event log in the Security Descriptor
Definition Language (SDDL) syntax. In this procedure this value will be referred to as
SDDLACL.
5. Set the value of the SDDLACL to the following:
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)
(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU) (A;;0x1;;;S-1-5-
3)(A;;0x2;;;LS)(A;;0x2;;;NS)
Once you edit this value and restart the computer, the new setting will take effect. Be
certain that you fully understand SDDL and the default permissions that are placed on
each event log before you use this procedure. Also, be certain to test any changes
thoroughly before you implement them in a production environment, because you could
accidentally configure the ACLs on an event log in such a way that no one could access
it.
How To View and Configure Linux Logs on Ubuntu and Centos
Linux system administrators often need to look at log files for troubleshooting purposes. In
fact, this is the first thing any sysadmin would do.
Linux and the applications that run on it can generate all different types of messages, which
are recorded in various log files. Linux uses a set of configuration files, directories, programs,
commands and daemons to create, store and recycle these log messages. Knowing where
the system keeps its log files and how to make use of related commands can therefore help
save valuable time during troubleshooting.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Default Log File Location
The default location for log files in Linux is /var/log.
You can view the list of log files in this directory with a simple ls -l /var/log command.
This is what I see in my CentOS system:
[root@TestLinux ~]# ls -l /var/log

total 1472
-rw-------. 1 root root 4524 Nov 15 16:04 anaconda.ifcfg.log
-rw-------. 1 root root 59041 Nov 15 16:04 anaconda.log
-rw-------. 1 root root 42763 Nov 15 16:04 anaconda.program.log
-rw-------. 1 root root 299910 Nov 15 16:04 anaconda.storage.log
-rw-------. 1 root root 40669 Nov 15 16:04 anaconda.syslog
-rw-------. 1 root root 57061 Nov 15 16:04 anaconda.xlog
-rw-------. 1 root root 1829 Nov 15 16:04 anaconda.yum.log
drwxr-x---. 2 root root 4096 Nov 15 16:11 audit
-rw-r--r-- 1 root root 2252 Dec 9 10:27 boot.log
-rw------- 1 root utmp 384 Dec 9 10:31 btmp
-rw-------. 1 root utmp 1920 Nov 28 09:28 btmp-20131202
drwxr-xr-x 2 root root 4096 Nov 29 15:47 ConsoleKit
-rw------- 1 root root 2288 Dec 9 11:01 cron
-rw-------. 1 root root 8809 Dec 2 17:09 cron-20131202
-rw-r--r-- 1 root root 21510 Dec 9 10:27 dmesg
-rw-r--r-- 1 root root 21351 Dec 6 16:37 dmesg.old
-rw-r--r--. 1 root root 165665 Nov 15 16:04 dracut.log
-rw-r--r--. 1 root root 146876 Dec 9 10:44 lastlog
-rw------- 1 root root 950 Dec 9 10:27 maillog
-rw-------. 1 root root 4609 Dec 2 17:00 maillog-20131202
-rw------- 1 root root 123174 Dec 9 10:27 messages
-rw-------. 1 root root 458481 Dec 2 17:00 messages-20131202
-rw------- 1 root root 2644 Dec 9 10:44 secure
-rw-------. 1 root root 15984 Dec 2 17:00 secure-20131202
-rw------- 1 root root 0 Dec 2 17:09 spooler
-rw-------. 1 root root 0 Nov 15 16:02 spooler-20131202
-rw-------. 1 root root 0 Nov 15 16:02 tallylog
-rw-rw-r--. 1 root utmp 89856 Dec 9 10:44 wtmp
-rw------- 1 root root 3778 Dec 6 16:48 yum.log
Viewing Log File Contents
Here are some common log files you will find under /var/log:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 wtmp
 utmp
 dmesg
 messages
 maillog or mail.log
 spooler
 auth.log or secure
The wtmp and utmp files keep track of users logging in and out of the system. You cannot
directly read the contents of these files using cat– there are specific commands for that.
We will now use some of these commands.
To see who is currently logged in to the Linux server, simply use the who command. This
command gets its values from the /var/run/utmp file (for CentOS and Debian) or /run/utmp
(for Ubuntu).
Here is an example from CentOS:
[root@TestLinux ~]# who

root tty1 2013-12-09 10:44
root pts/0 2013-12-09 10:29 (10.0.2.2)
sysadmin pts/1 2013-12-09 10:31 (10.0.2.2)
joeblog pts/2 2013-12-09 10:39 (10.0.2.2)
In this particular case, I am the sole user of the system. I was running the server from an
Oracle VirtualBox and accessing it as root from both the console and an SSH session. Two
other user accounts (sysadmin and joebolg) were also accessing the system.
The last command tells us the login history of users:
[root@TestLinux ~]# last | grep sysadmin

sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31 still logged in
sysadmin pts/0 10.0.2.2 Fri Nov 29 15:42 - crash (00:01)
sysadmin pts/0 10.0.2.2 Thu Nov 28 17:06 - 17:13 (00:06)
sysadmin pts/0 10.0.2.2 Thu Nov 28 16:17 - 17:05 (00:48)
sysadmin pts/0 10.0.2.2 Thu Nov 28 09:29 - crash (06:04)
sysadmin pts/0 10.0.2.2 Wed Nov 27 16:37 - down (00:29)
sysadmin tty1 Wed Nov 27 14:05 - down (00:36)
sysadmin tty1 Wed Nov 27 13:49 - 14:04 (00:15)
In this example, I am trying to find the login history of the user sysadmin. As you can see, there
were couple of instances where he managed to crash the system.
To find out when was the system last rebooted, we can run the following command:
tmg.edu.au | 1300 888 TMG (1300 888 864)
[root@TestLinux ~]# last reboot
The result may look like this
reboot system boot 2.6.32-358.el6.x Mon Dec 9 10:27 - 10:47 (00:19)

reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:37 - 10:47 (2+18:10)
reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:28 - 16:36 (00:08) reboot system boot
2.6.32-358.el6.x Fri Dec 6 11:06 - 16:36 (05:29)
reboot system boot 2.6.32-358.el6.x Mon Dec 2 17:00 - 16:36 (3+23:36)
reboot system boot 2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34)
reboot system boot 2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53)
...
...
wtmp begins Fri Nov 15 16:11:54 2013
To see when did someone last log in to the system, use lastlog:
[root@TestLinux ~]# lastlog
In my system, the output looked like this:
Username Port From Latest

root tty1 Mon Dec 9 10:44:30 +1100 2013
bin **Never logged in**
daemon **Never logged in**
adm **Never logged in**
lp **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
uucp **Never logged in**
operator **Never logged in**
games **Never logged in**
gopher **Never logged in**
ftp **Never logged in**
nobody **Never logged in**
vcsa **Never logged in**
saslauth **Never logged in**
postfix **Never logged in**
sshd **Never logged in**
sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013
dbus **Never logged in**
joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013
For other text-based log files, you can use cat, head or tail commands to read the contents.
tmg.edu.au | 1300 888 TMG (1300 888 864)
In the example below, I am trying to look at the last ten lines of /var/log/messages file in a
Debian box:
debian@debian:~$ sudo tail /var/log/messages
Output:
Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP filters: protocol multicast
Dec 16 01:21:08 debian kernel: [ 9.648220] Bridge firewalling registered
Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO (Voice Link) ver 0.6
Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO socket layer initialized
Dec 16 01:21:08 debian kernel: [ 9.832215] lp: driver loaded but no devices found
Dec 16 01:21:08 debian kernel: [ 9.868897] ppdev: user-space parallel port driver
Dec 16 01:21:11 debian kernel: [ 12.748833] [drm] Initialized drm 1.1.0 20060810
Dec 16 01:21:11 debian kernel: [ 12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11
(level, low) -> IRQ 11
Dec 16 01:21:11 debian kernel: [ 12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for
0000:00:02.0 on minor 0
The rsyslog Daemon
At the heart of the logging mechanism is the rsyslog daemon. This service is responsible for
listening to log messages from different parts of a Linux system and routing the message to an
appropriate log file in the /var/log directory. It can also forward log messages to another
Linux server.
The rsyslog Configuration File
The rsyslog daemon gets its configuration information from the rsyslog.conf file. The file is
located under the /etc directory.
Basically, the rsyslog.conf file tells the rsyslog daemon where to save its log messages. This
instruction comes from a series of two-part lines within the file.
This file can be found at rsyslog.d/50-default.conf on ubuntu.
The two part instruction is made up of a selector and an action. The two parts are separated
by white space.
The selector part specifies what's the source and importance of the log message and the
action part says what to do with the message.
The selector itself is again divided into two parts separated by a dot (.). The first part before
the dot is called *acility (the origin of the message) and the second part after the dot is
called priority (the severity of the message).
tmg.edu.au | 1300 888 TMG (1300 888 864)
Together, the facility/priority and the action pair tell rsyslog what to do when a log message
matching the criteria is generated.
Here is excerpt from a CentOS rsyslog.conf file:
# rsyslog v5 configuration file

...
...
# Include all config files in /etc/rsyslog.d/
IncludeConfig /etc/rsyslog.d/*.conf
#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.

authpriv.* /var/log/secure
# Log all the mail messages in one place.

mail.* -/var/log/maillog
# Log cron stuff

cron.* /var/log/cron
# Everybody gets emergency messages

*.emerg *
# Save news errors of level crit and higher in a special file.

uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log

local7.* /var/log/boot.log
...
...
To understand what this all means, let's consider the different types of facilities recognized by
Linux. Here is a list:
 auth or authpriv: Messages coming from authorization and security related events
 kern: Any message coming from the Linux kernel
tmg.edu.au | 1300 888 TMG (1300 888 864)
 mail: Messages generated by the mail subsystem

 cron: Cron daemon related messages
 daemon: Messages coming from daemons
 news: Messages coming from network news subsystem
 lpr: Printing related log messages
 user: Log messages coming from user programs
 local0 to local7: Reserved for local use
And here is a list of priorities in ascending order:
 debug: Debug information from programs

 info: Simple informational message - no intervention is required
 notice: Condition that may require attention
 warn: Warning
 err: Error
 crit: Critical condition
 alert: Condition that needs immediate intervention
 emerg: Emergency condition
So now let's consider the following line from the file:
cron.* /var/log/cron
This just tells the rsyslog daemon to save all messages coming from the cron daemon in a file
called /var/log/cron. The asterix (*) after the dot (.) means messages of all priorities will be
logged. Similarly, if the facility was specified as an asterix, it would mean all sources.
Facilities and priorities can be related in a number of ways.
In its default form, when there is only one priority specified after the dot, it means all events
equal to or greater than that priority will be trapped. So the following directive causes any
messages coming from the mail subsystem with a priority of warning or higher to be logged in
a specific file under /var/log:
mail.warn /var/log/mail.warn
This will log every message equal to or greater than the warn priority, but leave everything
below it. So messages with err, crit, alert or emerg will also be recorded in this file.
Using an equal sign (=) after the dot (.) will cause only the specified priority to be logged. So
if we wanted to trap only the info messages coming from the mail subsystem, the
specification would be something like the following:
mail.=info /var/log/mail.info
tmg.edu.au | 1300 888 TMG (1300 888 864)
Again, if we wanted to trap everything from mail subsystem except info messages, the
specification would be something like the following
mail.!info /var/log/mail.info
or
mail.!=info /var/log/mail.info
In the first case, the mail.info file will contain everything with a priority lower than info. In the
second case, the file will contain all messages with a priority above info.
Multiple facilities in the same line can be separated by commas.
Multiple sources (facility.priority) in the same line is separated by semicolon.
When an action is marked as an asterix (*), it means all users. This entry in my CentOS
rsyslog.conf file is saying exactly that:
# Everybody gets emergency messages

*.emerg *
Try to see what's the rsyslog.conf is saying in your Linux system. Here is an excerpt from the
Debian server I am running:
# /etc/rsyslog.conf Configuration file for rsyslog.

#
# For more information see
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
...
...
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
tmg.edu.au | 1300 888 TMG (1300 888 864)
mail.err /var/log/mail.err
#
# Logging for INN news system.
#
news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice -/var/log/news/news.notice
As you can see, Debian saves all security/authorization level messages in /var/log/auth.log
whereas CentOS saves it under /var/log/secure.
The configurations for rsyslog can come from other custom files as well. These custom
configuration files are usually located in different directories under /etc/rsyslog.d. The
rsyslog.conf file includes these directories using $IncludeConfig directive.
Here is what it looks like in Ubuntu:
# Default logging rules can be found in /etc/rsyslog.d/50-default.conf

....
....
$IncludeConfig /etc/rsyslog.d/*.conf
The contents under the /etc/rsyslog.d directory looks like the following:
-rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf

-rw-r--r-- 1 root root 252 Apr 11 2012 21-cloudinit.conf
-rw-r--r-- 1 root root 1655 Mar 30 2012 50-default.conf
Now the destination for a log message does not necessarily have to be a log file; the
message can be sent to a user's console. In this case, the action field will contain the
username. If more than one user needs to receive the message, their usernames are
separated by commas. If the message needs to be broadcast to every user, it's specified by
an asterix (*) in the action field.
Because of being part of a network operating system, rsyslog daemon can not only save log
messages locally, it can also forward them to another Linux server in the network or act as a
repository for other systems. The daemon listens for log messages in UDP port 514. The
example below will forward kernel critical messages to a server called "texas".
kern.crit @texas
Creating and Testing Your Own Log Messages
So now it's time for us to create our own log files.
To test this, we will do the following

tmg.edu.au | 1300 888 TMG (1300 888 864)
 Add a log file specification in /etc/rsyslog.conf file

 Restart the rsyslog daemon
 Test the configuration using the logger utility
In the following example, I am adding two new lines in my CentOS Linux system's rsyslog.conf
file. As you can see, each of them are coming from a facility called local4 and they have
different priorities.
[root@TestLinux ~]# vi /etc/rsyslog.conf

....
....
# New lines added for testing log message generation
local4.crit /var/log/local4crit.log
local4.=info /var/log/local4info.log
Next, the service is restarted so the config file data is reloaded:
[root@TestLinux ~]# /etc/init.d/rsyslog restart

Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
[root@TestLinux ~]#
To generate the log message now, the logger application is called:
[root@TestLinux ~]# logger -p local4.info " This is a info message from local 4"
Looking under the /var/log directory now shows two new files:
...
...
-rw------- 1 root root 0 Dec 9 11:21 local4crit.log
-rw------- 1 root root 72 Dec 9 11:22 local4info.log
The size of the local4info.log is non-zero. So when it's opened, I see the message has been
recorded:
[root@TestLinux ~]# cat /var/log/local4info.log

Dec 9 11:22:32 TestLinux root: This is a info message from local 4
Rotating Log Files
As more and more information is written to log files, they get bigger and bigger. This obviously
poses a potential performance problem. Also, the management of the files become
cumbersome.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Linux uses the concept of "rotating" log files instead of purging or deleting them. When a log
is rotated, a new log file is created and the old log file is renamed and optionally
compressed. A log file can thus have multiple old versions remaining online. These files will go
back over a period of time and will represent the backlog. Once a certain number of
backlogs have been generated, a new log rotation will cause the oldest log file to be
deleted.
The rotation is initiated through the logrotate utility.
The logrotate Configuration File
Like rsyslog, logrotate also depends on a configuration file and the name of this file is
logrotate.conf. It's located under /etc.
Here is what I see in the logrotate.conf file of my Debian server:
debian@debian:~$ cat /etc/logrotate.conf

# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs

rotate 4
# create new (empty) log files after rotating old ones

create
# uncomment this if you want your log files compressed

#compress
# packages drop log rotation information into this directory

include /etc/logrotate.d
# no packages own wtmp, or btmp -- we'll rotate them here

/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 1
tmg.edu.au | 1300 888 TMG (1300 888 864)
# system-specific logs may be configured here
The lines are fairly self-explanatory. By default, log files are to be rotated weekly with four
backlogs remaining online at any one time. When the program runs, a new, empty log file
will be generated and optionally the old ones will be compressed.
The only exception is for wtmp and btmp files. wtmp keeps track of system logins and btmp
keeps track of bad login attempts. Both these log files are to be rotated every month and no
error is returned if any previous wtmp or btmp file can be found.
Custom log rotation configurations are kept under etc/logrotate.d directory. These are also
inluded in the logrotate.conf with the include directive. The Debian installation shows me the
content of this directory:
debian@debian:~$ ls -l /etc/logrotate.d
total 44
-rw-r--r-- 1 root root 173 Apr 15 2011 apt
-rw-r--r-- 1 root root 79 Aug 12 2011 aptitude
-rw-r--r-- 1 root root 135 Feb 24 2010 consolekit
-rw-r--r-- 1 root root 248 Nov 28 2011 cups
-rw-r--r-- 1 root root 232 Sep 19 2012 dpkg
-rw-r--r-- 1 root root 146 May 12 2011 exim4-base
-rw-r--r-- 1 root root 126 May 12 2011 exim4-paniclog
-rw-r--r-- 1 root root 157 Nov 16 2010 pm-utils
-rw-r--r-- 1 root root 94 Aug 8 2010 ppp
-rw-r--r-- 1 root root 515 Nov 30 2010 rsyslog
-rw-r--r-- 1 root root 114 Nov 26 2008 unattended-upgrades
The contents of the rsyslog shows how to recycle a number of log files:
debian@debian:~$ cat /etc/logrotate.d/rsyslog

/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
}
tmg.edu.au | 1300 888 TMG (1300 888 864)
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
}
As you can see, the syslog file will be reinitialized every day with seven days' worth of logs
being kept online. Other log files are rotated every week.
Also worth noting is the postrotate directive. This specifies the action that happens after the
whole log rotation has completed.
Testing the Rotation
Logrotate can be manually run to recycle one or more files. And to do that, we simply
specify the relevant configuration file as an argument to the command.
To see how this works, here is a partial list of log files under /var/log directory in my test
CentOS server:
[root@TestLinux ~]# ls -l /var/log

total 800
...
-rw------- 1 root root 359 Dec 17 18:25 maillog
-rw-------. 1 root root 1830 Dec 16 16:35 maillog-20131216
-rw------- 1 root root 30554 Dec 17 18:25 messages
-rw-------. 1 root root 180429 Dec 16 16:35 messages-20131216
tmg.edu.au | 1300 888 TMG (1300 888 864)
-rw------- 1 root root 591 Dec 17 18:28 secure

-rw-------. 1 root root 4187 Dec 16 16:41 secure-20131216
...
...
The partial contents of the logrotate.conf file looks like this:
[root@TestLinux ~]# cat /etc/logrotate.conf

# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs

rotate 4
# create new (empty) log files after rotating old ones

create
...
...
Next we run the logrotate command:
[root@TestLinux ~]# logrotate -fv /etc/logrotate.conf
Messages scroll over as new files are generated, errors are encountered etc. When the dust
settles, we try to check for new mail, secure or messages files:
[root@TestLinux ~]# ls -l /var/log/mail*

-rw------- 1 root root 0 Dec 17 18:34 /var/log/maillog
-rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216
-rw------- 1 root root 359 Dec 17 18:25 /var/log/maillog-20131217
[root@TestLinux ~]# ls -l /var/log/messages*

-rw------- 1 root root 148 Dec 17 18:34 /var/log/messages
-rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216
-rw------- 1 root root 30554 Dec 17 18:25 /var/log/messages-20131217
[root@TestLinux ~]# ls -l /var/log/secure*

-rw------- 1 root root 0 Dec 17 18:34 /var/log/secure
-rw-------. 1 root root 4187 Dec 16 16:41 /var/log/secure-20131216
-rw------- 1 root root 591 Dec 17 18:28 /var/log/secure-20131217
[root@TestLinux ~]#
tmg.edu.au | 1300 888 TMG (1300 888 864)
As we can see, all three new log files have been created. The maillog and secure files are still
empty, but the new messages file already has some data in it.
Implement backup and recovery methods to enable restoration capability in the event of a
disaster
Linux Implementation
Backup and recovery is essential. Failure to have verified backup and recovery procedures
puts your data at risk of loss. Users often only learn this lesson after critical information they
require is permanently lost. Attempting to recover from data loss can be both time
consuming and extremely difficult. So learn from others mistakes, and ensure beforehand
that you have a system in place that protects your data and suits your needs.
Before deciding on a backup and recovery strategy you have to ask the following questions:
 Why? - Why are you protecting yourself against disaster? Does it matter if you lose
data? What losses will you suffer ($$$)?
 What? - What are you going to backup? Your entire hard drive or just some of the
data?
 When? - When is the best time to backup your system? How often will you perform a
backup? When will you use full backups and incremental backups.
 Where? - Where will the backups be stored? On-site? Off-Site? Cloud?
 Medium? - Attached storage (usb stick, usb hard drive, tape drive), backup server?
Backup
Types of Backup
There are many methods to provide backup and recovery; choosing the best process for you
or your business will have to take several factors in to account.
 Recovery time objective (RTO): How fast should data be recovered? Can you
continue to operate if data recovery is not recovered for a day, a week, etc?
 Recovery point objective (RPO): How much data can be lost. Can you lose two hours,
two days or two weeks of data?
example: if you can withstand losing one week of data then a weekly backup would be
sufficient, but if you can only withstand losing one day then you would need to employ a
nightly backup (or a variation)
This document will cover three basic types of backup; Full, Incremental, and Differential.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Full: A full backup backs up all the files in the back up target.
Incremental: An incremental backup backs up all the files that have changed since the last
backup.
Differential: A differential backup backs up all the files that have changed since the last full
backup.
Backup Methods
Depending on your budget and specific RTO and RPO you can choose from manual, local
automated, or remote automated.
 manual - Manual backup would be initiated on a schedule by the user and is the
most common method for home users to backup their files. This method is also the
least reliable.
 local automated - Automated backups that target a hard drive or tape drive
attached to the physical box being backed up fall into this category. Advanced
home users and small businesses will often use this method.
 remote automated - Automated backups that target a hard drive, tape drive or
virtual tape library (VTL) over the network fall into this backup. This type of backup is
often used by businesses that have money they can dedicate to the process of
backup. As the organization becomes more mature they may even stage the
backup on multiple mediums and increase the distance between backup and
production systems.
mtime, atime and ctime
Ubuntu records three different times for each file:
 mtime - modification time; this value is changed when the contents of the file is
changed.
note: file system backups change atime while raw device backups will not. If you are
implementing incremental or differential backups this is important
 atime - access time; the value of this is changed when the file is accessed. The atime
can also change when a backup utility or script has read the file as well as when a
user has reads the file.
 ctime - change time; the value is updated whenever the attributes of the file
change. This can be ownership or permission.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Recovery
note: many people consider only the backup part of this process and do nothing to verify
that the backup can be restored. It is very important to test that your backup process is
working and that data can be recovered.
It is crucial that your backups are tested by restoring them. Here are some tests you should
do to ensure that you can recover from a disaster:
 Restore many single files

 Restore an older version of a file
 Restore an entire folder
 Restore an entire drive and compare the checksum
If you do not test you may find out that nothing was being backed up when you need to
restore the files in reality.
Backup Utilities
wiki documented utilities

Utility Interface Raw Supports
/ File Remote Incremental Differential Automation
Déjà Dup Graphical FILE YES YES NO YES
(Duplicity
frontend)
grsync Graphical FILE YES YES ? via Cron
pybackpack Graphical FILE YES YES ? NO
TAR Command FILE YES YES ? via Cron
line
rsync Command FILE YES YES ? via Cron
line
dump Command RAW YES YES ? via Cron
line
Duplicity Command FILE YES YES NO via Cron
line
BackupPC Command FILE YES YES ? via Cron
line
Bacula 1 2 Both FILE YES YES ? YES
Mondo Rescue Command FILE YES YES ? YES
line
SimpleBackupSuite Graphical FILE YES YES ? YES
backup-manager Command FILE YES YES ? via Cron
line
tmg.edu.au | 1300 888 TMG (1300 888 864)
You can spend a fortune on a storage medium that's anti-scratch, dust-resistant, heat-proof
and contains no moving parts, but it'll all come to naught eventually if you haven't also
invested effort in backing your data up.
Although it isn't particularly time consuming, backing up data requires careful thought and
preparation, and involves more than just zipping files into a tarball. This means it's often
neglected.
Note that an archive isn't a backup and it's important to know the difference between the
two. An archive is a primary copy of data that's put away for future use. A backup, on the
other hand, is a secondary copy that you call upon to recover your important files and
information from data loss disasters.
So no matter what kind of user you are, or how you use your Linux distribution, this article has
got something for you. Most of the backup tools discussed here only require a bit of thought
and a little time to set up. Best of all, unless you've got terabytes of data, you can safely file it
for little or no cost both on and offline.
We'll also discuss ways to organise and store your data more efficiently so that it's easily
accessible and simple to back up. You need never lose data again.
A primer to the thought process behind making your data safe
Preparing for a backup involves careful consideration. For starters, where do you store your
data? Keeping it on another partition of the same disk isn't advisable - what if the whole disk
fails? A copy on another disk is one solution.
To protect your data against physical disasters, such as fires, foods and theft, keep the
backup as far away from the original as possible, perhaps on the cloud.
Each method has it's advantages: hard disks offer the best price-to-space ratio and are also
a convenient and readily available option, Flash drives offer portability, optical media's easily
distributable, and online storage is globally accessible.
The kind of data also influences the choice of storage medium. A DVD might be useful for
holiday snapshots, but is of limited use to a pro photographer. If you'll be backing up large
quantities of data, it's advisable to get multiple, high-capacity hard disks. Or you might want
to invest in a NAS (network attached storage) box.
Another option would be to create your own cloud by attaching USB disks to network
accessible devices such the PogoPlug or TonidoPlug. Figure out which of these options best
suits your needs.
What to backup?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Depending on the size of your home directory, backing it up completely could be overkill.
Here are the essentials:
Your documents and files

/Documents, /Downloads, /Desktop
Most modern distros keep the files you've created or downloaded under these directories.
Don't forget to check /home for any important documents.
Your email data (Evolution/Thunderbird/Kmail)

/.evolution, /.thunderbird, /.kde/share/apps/kmail
Depending on your client, one of these should contain your emails, plus their attachments,
your address book and so on.
Other apps' data
Other apps create their own data repositories to store files. Most prompt you for the location,
while some create their own. Check under their Preferences to search these out.
Installed software
/var/cache/apt, /var/cache/yum
If there's a piece of software that's crucial to you and you don't want to spend time
downloading it again, back it up.
Personal settings
.bashrc, .profile, .gnupg/, .local/, .openoffice/, .mozilla/
These are some of the essential hidden directories that store user settings. Back them up for
every user in your installation. Be vigilant, though. Some contain Cache directories, such as
Firefox (under /.mozilla/firefox/whvmajqx.default/Cache for us), which needlessly add to the
backup's size.
System settings
/etc, /var/spool/cron/, /var/spool/mail, /boot,
Pay close attention to these directories if you're backing up your entire installation. You'll find
system settings in /etc. Although it's got a large number of files, it isn't very bulky. This is unlike
/var. It contains cache directories for several apps you can miss out, plus /var/spool/mail,
which houses the user mail files, and /var/spool/cron, which has the settings for cron, both of
which you should back up.
If you've made changes elsewhere in the system, consider backing up those files under /usr/
and /usr/local/.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Data considerations
Now we know what to back up, so let's consider how to go about it. Do you want to back up
manually or automatically based on a schedule? The correct frequency varies based on the
kind and value of data being safeguarded.
Depending on the size of the files, it might not be a good idea to back them up completely
every day either. Many backup tools enable you to do incremental backups - only creating
copies of files that have changed since the last backup.
Will you manipulate the data before safeguarding it? If you're backing up large quantities of
data, it's advisable to compress it. If the data's sensitive, you can encrypt it too. Remember
that both add to backup overheads.
Finally, to ensure the data's integrity, checksum and validate it regularly.
Step-by-step: Crontab entries from a GUI
1. Create your crontab
tmg.edu.au | 1300 888 TMG (1300 888 864)
Despite its simplicity, automating tasks with Cron can be a tricky task if you are not used to it.
Corntab (www.corntab.com) is a browser-based visual front-end that helps you cook up an
appropriate crontab entry.
2. Email it
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Corntab interface has sliders and check boxes to help you pick both the time (in
minutes, hours, days of the month, months and days of the week) and command that you
wish to schedule with Cron.
3. Paste into crontab
When you're done, copy or email the crontab entry, and paste it into crontab from the
tmg.edu.au | 1300 888 TMG (1300 888 864)
command line with the crontab -e command. When you save and exit the crontab editor,
the new entry will be activated.
Protect your data easily with these no-fuss tools for beginners
Déjà Dup
Aren't yet used to the ways of a backup tool? Then Déjà Dup is for you. It has a minimal
interface so as to not overwhelm new users, yet it's based on the powerful command
linebased Duplicity and integrates nicely with Gnome.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Pulled from the repositories, Déjà Dup installs under Applications > System Tools. Before you
use it, you'll need to set its Preferences. Start by pointing it towards the location where you
want to house your backups. This can be a local hard disk, a remote location via SSH, or
Amazon's S3 web storage.
Then specify the list of directories you want to include in and exclude from the backup. By
separating these two, Déjà Dup gives you the flexibility to include a large directory - for
instance, /home - in your backup, while specifying parts to leave out, such as .cache/.
By default, Déjà Dup encrypts your backups, but you can ask it not to do so by unchecking
the Encrypt Backup Files box. Next to it is a pull-down menu that enables you schedule
regular backups.
When you're done, click the Backup icon to invoke the process. If you've opted to encrypt
the data, Déjà Dup now prompts you for a password. It then provides a summary list of the
directories involved and begins.
This initial backup may take some time, but subsequent backups are incremental - dealing
only with what's changed - and thus much faster.
When restoring backups, Déjà Dup enables you to restore them to their original location or
under a specific directory. Since the backup's directory contains encrypted material, you'll
be prompted for your password again.
Finally, you're presented with a time-stamped list of backups to restore. That's all there's to it.
Déjà Dup is ideal for backing up files under a user's /home directory, but you might run into
authorisation issues with system files. Also Déjà Dup doesn't allow you to create backup sets.
So if you wish to back up a different directory, you'll have to modify the Preferences.
Similarly, in order to restore from different locations, you'll have to change the location first
under Preferences.
LuckyBackup
tmg.edu.au | 1300 888 TMG (1300 888 864)
While Déjà Dup is suitable for most users, if you want something that's able to handle multiple
backup schemes, then use LuckyBackup.
Among its strong points is that it supports multiple profiles, enabling you to manage different
backup sets. A default profile is created when you first launch the app and, like all profiles,
must have a task attached - either to perform a backup or restore data from one.
Tasks can be one of three types: you can select to back up just the contents of a directory,
replicate the entire source directory as is, or you can synchronise the source and destination,
which is handy when you need to keep files found under two directories in sync.
When the synchronisation task is executed, LuckyBackup checks for the newest version of a
file under both the source and destination directories and copies them to the other. So newly
created files in one location are replicated in the other. The only drawback is that if you have
deliberately deleted a file/folder in one location but not its counterpart, these will be
automatically recreated.
Elsewhere, the Advanced button expands the New Task dialogue to give you fine control
over the files to include in, and exclude from, the backup. If you'll be backing up to a remote
directory, specify your connection details under the Remote tab.
Power users will appreciate the convenience of the Also Execute tab, which enables you to
specify a list of commands to execute before and after the backup.
When you're done creating a backup, click the Validate button to ensure your settings are
good to go. With all your tasks for multiple locations set up, it's time to schedule them. Head
tmg.edu.au | 1300 888 TMG (1300 888 864)
over to Profile > Schedule, and click Add. Now select the profile to schedule and customise
its run time.
Finally, click the CrontIT! button, which automatically creates a Cron job for the backup. To
manually run a backup, select the task to execute and click Start. You might also want to
check the Simulator box to simulate the backup and ensure it will run properly.
The process of restoring a backup in LuckyBackup is just a backup task with the directories
reversed. Also remember to uncheck the Skip Newer Destination Files box under the
Command Options tab in the Advanced view.
Finally, execute the restore task as usual and your backed up data will be reinstated in its
original place.
Enterprise solutions
BackupPC
tmg.edu.au | 1300 888 TMG (1300 888 864)
If you manage a computer lab or work in an enterprise setting, backing up individual

computers using the tools we've covered so far would be a chore. When you have a bunch
of machines to take care of, it's best to rely on BackupPC. Be warned, however, that it's not
for the faint of heart, despite its web-based interface and extensive documentation.
While it can be used on individual machines, it's best called upon when you want to
safeguard data on multiple computers. Not only that, but it will work across Linux, Mac, or
Windows, and is well suited for environments that have a mix of different OSes.
It has impressive features too, including pooling. This reduces backup sizes by saving only one
copy of identical files that exist on many computers. For example, if you have the same distro
running on all computers, BackupPC will only keep one copy of the system files.
Install and configure
You can install BackupPC from your distro's repository, or get the latest version via the tarball.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Before you extract and install it, make sure you have the following Perl modules:
Compress::Zlib, Archive::Zip, XML::RSS, Net::FTP and File::RsyncP.
You can install them using CPAN a la: perl -MCPAN -e 'install Compress::Zlib
With the various libraries in place, you should download the tarball, untar it and then enter
the following: perl configure.pl
When you run configure.pl, you'll be prompted for the full paths of various executables and
for configuration information such as the BackupPC user, the data directory and so on. By
default, the configuration files will be stored in /etc/backuppc.
Once it's set up, you can start the program with /etc/init.d/backuppc start
The basic BackupPC configuration can be edited via the app's web interface, which you'll
find by pointing your browser towards localhost/backuppc. Use the username and password
you specified when configuring BackupPC to login to this.
The interface also lets you browse the various hosts as well as initiate backup and restore
operations. You can edit basic configuration settings from the Edit Config menu. Use the Add
button under the Edit Hosts section to include a client to back up.
In order to set up individual clients, you'll have to manually edit their configuration files, and
provide details depending on the method used for backing up (BackupPC supports SMB,
TAR, Rsync and FTP).
An /etc example
For example, the following backs up the /etc directory on localhost using TAR:
$Conf{XferMethod} = 'tar'; $Conf{TarShareName} = ['/etc']; $Conf{TarClientCmd} =
'/usr/bin/env LC_ALL=C $tarPath -c -v -f - -C $shareName'
To begin the back up, head to the web interface, select a host and then click Start Full
Backup. The Status page will show you which backups are running. Alternatively, you could
also perform an incremental backup if you have previously archived files to add to.
With backup data in place, BackupPC enables you to view and restore individual files, or
complete filesystems. You can either download the backed up files as zipped archives, or
directly restore them into their original computer.
There's far more to BackupPC than we can touch on here; it's the most comprehensive
program in this feature. As such, you'll need to spend time browsing its documentation and
adapting it to your network to make full use of it. Our in-depth tutorial in LXF125 may also help
if you have access to it.
MondoRescue
tmg.edu.au | 1300 888 TMG (1300 888 864)
MondoRescue isn't your everyday backup program, but rather specialises in recovery after
catastrophic data loss. It's ideal for backing up the core filesystem, say once a month. It can
also be used to clone an installation on larger partitions.
While your distro might include MondoRescue in its repositories, it's best to grab packages for
the app from ftp://ftp.mondorescue.org. You'll also need Mindi, Mondo's companion tool
that packages backups into bootable distros, and mindi-busybox, which contains the tools
Mindi needs.
When you're all set, launch MondoRescue as root with sudo mondoarchive You'll see the
tool's crude-but-effective Ncurses-based interface. You're asked for your choice of backup
medium, how much compression you'd like to use, and whether it should divide the backups
to fit CDs or DVDs.
Then you'll be asked what to back up. By default, the app backs up everything under the
root directory. MondoRescue can also back up Windows partitions if it detects them on your
disk. You should let MondoRescue verify the archives it creates too - this takes time but is well
worth it.
tmg.edu.au | 1300 888 TMG (1300 888 864)
When it's ready to copy data, MondoRescue creates a catalogue of files, divides them into
sets, then calls Mindi and finally begins backing up, which can take several hours. If you've
asked MondoRescue to back up to a hard disk, when it's done you'll find one or several ISO
images inside the directory you specified. Boot from the first image and enter compare at
the boot prompt to check the archived copies against your filesystem.
At the end of the process, this prints the non-matching files. There might be some
immediately after backing up, but these are often just cache files, which can be safely
ignored. To format and restore all files, type nuke, or interactive.
If you're restoring to a blank hard disk, MondoRescue will also partition it and adjust the
backed up partitions to suit. It'll also regenerate the bootloader, which you can then fine
tune.
Tonido
tmg.edu.au | 1300 888 TMG (1300 888 864)
Back in LXF 122, we looked at a piece of software called Tonido to help you create your own
personal cloud server. It's a wonderful tool for sharing your files over an internal network as
well as the internet. It might not be open source, but it gets the job done without you having
to mess with your router and firewall settings.
Tonido is available as a binary for both Deb and RPM-based distros, or you can download it
from www.tonido.com.
The only bit of setting up it requires is a username, which becomes part of your tonido web
address. So if you choose Fluffy as your user name, you can access your files from anywhere
by pointing your browser at fluffy.tonodoid.com.
Note that your data is still stored on your computer, not external servers, and is simply served
over the internet, which may help qualm any fears you have about the security of what you
store.
Tonido also includes an application to back up data to a local disk or remote computer. To
perform a backup, log into Tonido's web interface and click the Backup app. This then opens
tmg.edu.au | 1300 888 TMG (1300 888 864)
another interface that enables you to add and schedule backups. Click on the New button
to add a new backup record.
The process involves selecting the device and the backup source and destination folders if
you want to backup to a local disk. If you want to back up to a remote computer, you'll be
presented with a list of peers. You can only back up to remote machines that are in your
group.
Tonido identifies machines with their globally addressable peer ID. So you can back up to
any machine on the internet, as long as it's in your group.
Once the backup is good to go, you can schedule it to run at periodic intervals, or run it
manually. If you're particularly paranoid, you'll also be glad to know that Tonido encrypts
data using AES encryption and transfers it directly from the source computer to the remote
computer.
Tonido has many other features too. It enables you to collaborate, share, and sync files with
others on the internet via Group Workspaces. To sync content through Tonido Groups, other
users will need to have Tonido installed.
Since the software runs and functions the same way on both Windows and Mac OSX,
however, you can share your data with them regardless of their chosen operating system.
How to make crash-proof discs
tmg.edu.au | 1300 888 TMG (1300 888 864)
DVDisaster
Optical discs are the commonly preferred media for keeping backups. However, even when
stored carefully, they'll go bad over time. One option is to make new copies of the backup
discs. Depending on your backup catalogue, this could be an exhaustive and expensive
exercise.
A better option is to use DVDisaster. The tool creates an error correction code (ECC) file from
a healthy disk, which can be used later to recover data when the media is damaged.
DVDisaster works on ISO images. To create one, insert the disc into the drive and launch
DVDisaster after it's spun down. Now click on the Image File Selection icon, type in a name
for the ISO image and select a directory for it to be stored in, then click the Read button. The
app will read the disk sector by sector, then create the image as per the name and location
you specified earlier.
Correction corner
tmg.edu.au | 1300 888 TMG (1300 888 864)
Now it's time to create an ECC file. DVDisaster supports two types: RS01 and RS02. The former
stores the ECC file in a remote location, while the latter bundles it along with the ISO image.
To make your selection, head over to Preferences > Error Correction, and select the storage
method from the drop-down menu. We'd advise you to stick to the default RS01 method and
store the ECC file using a separate medium.
Using the default settings, the ECC file is about 15% the size of the ISO file. For better
protection, head back over to Preferences > Error Correction and select the High option. This
balloons the ECC file to about 35% the size of the image, but gives you a better chance of
restoring badly damaged media.
With an ECC in place, it's now a good idea to regularly check backup media with
DVDisaster. Just insert the media in the drive, and click on the Scan button. If the scan
detects bad sectors in the media, it's time to recover the lost data.
For that, first create an ISO image of the damaged media using the same procedure as
before. Then find the ECC file you created earlier for the damaged media and point to it
using the button for ECC file selection. With the image and ECC file in place, click on the Fix
button, which reads and repairs the damaged image.
The success rate of the recovery depends on the state of the damaged disk, which is why it is
necessary to scan the media regularly and repair it as soon as bad blocks show up.
Step-by-step: Back up a disk or partitions
tmg.edu.au | 1300 888 TMG (1300 888 864)
1. Where to save?
With a Clonezilla Live CD you can back up your entire disk. After booting the CD and opting
to create a clone, select where the images are saved, which can be on a local device or
over the network.
2. Disk or partitions
tmg.edu.au | 1300 888 TMG (1300 888 864)
Now you'll need to choose your mode. The Save disk option clones whole disks, and will later
prompt you to select a disk on the computer. To save individual partitions, select the
Saveparts option instead.
3. Back up selection
tmg.edu.au | 1300 888 TMG (1300 888 864)
Depending on your previous selection, you're shown a list of disks or partitions. Use the
Spacebar to mark multiple partitions to back up. Once done, follow the onscreen instructions
to complete the process.
Store your files online

tmg.edu.au | 1300 888 TMG (1300 888 864)
SpiderOak
The most convenient place to back up is online. There are plenty of services that enable you
to store files online and access them from anywhere you want. In fact, newer versions of
Ubuntu bundle clients for the Ubuntu One service, but this isn't as cross-platform as Dropbox.
In turn, Dropbox has the drawback of restricting you to a single directory for backups and
synchronisation. SpiderOak, on the other hand, has a consistent interface across Linux,
Windows, and Mac, and enables you to back up any file or folder.
The service offers 2GB of free space, or 100GB for $10 per month. When you install the client
and register for the service, the installer generates encryption keys that it then uses to encrypt
the data before transmission.
The app's interface is divided into tabs. To back up files, simply head to the Backup tab and
select your files or directories. Switch to the Advanced view to fine tune your file selection.
When you're done, click on the Save Settings button. That's it.
Now SpiderOak compares the contents of the local folder with the one it keeps online.
Whenever there's a change, it automatically starts the backup. Moreover, the service keeps
track of changes to the files using version control with a date stamp, which lets you roll back
to previous versions of a file.
This makes SpiderOak ideal for keeping copies of important documents you're working on, or
photos you've transferred from your camera. Your files are kept on the server unless you
explicitly ask SpiderOak to remove them.
tmg.edu.au | 1300 888 TMG (1300 888 864)
In addition to its backup features, the service can help you share files with others via virtual
isolated silos. Others can subscribe to these silos via RSS, which keeps them updated of any
new additions.
JungleDisk
Although it's proprietary, JungleDisk works across platforms, and enables you to keep data in
Amazon's S3 service or the Rackspace storage equivalent. The Desktop Edition costs $3 per
month with 5GB of free storage. You can get additional storage for $0.15 per GB per month -
find out more at https://www.jungledisk.com.
What sets JungleDisk apart from other online solutions is that it lets you mount your online
storage as a network device in your filesystem, so you can directly save files to the cloud. To
restore the files, just mount your drive and copy them onto your desktop.
Besides the network drive, JungleDisk also enables you to schedule automatic backups,
which are kept separate from the network drive. The data is encrypted and compressed
using data de-duplication. So although it keeps multiple timestamped copies of your data, it
minimises online disk space usage by avoiding backing up redundant data.
tmg.edu.au | 1300 888 TMG (1300 888 864)
What's more, when you upload a file, JungleDisk automatically creates a public URL with an
expiry date one week in the future in order to help you share this file with anyone.
Once installed, the JungleDisk client sits in your taskbar. Use it to configure backup settings,
such as selecting files and folders to back up. You can also use it to change the schedule of
an automatic backup or run one manually.
What's more, you can set up JungleDisk to keep certain files and folders on your local disk in
sync with the online disk. Any changes to files locally will be automatically copied to your
online storage.
Step-by-step: Back up browser data
1. Download
Head to www.xmarks.com to get hold of XMarks. It works with Firefox, Opera, Chrome,
Internet Explorer and Safari; is cross-platform; and even works on mobile devices.
2. Configure
tmg.edu.au | 1300 888 TMG (1300 888 864)
From the Addons window, click Preferences and then run the Setup Wizard to configure
XMarks to back up your browser's collection of bookmarks and passwords.
3. Restore
tmg.edu.au | 1300 888 TMG (1300 888 864)
Now when you install XMarks on a new computer, you can download and sync your
bookmarks from the server. You may also manually restore them.
This is the real world of backing up - here's how to deal with it
With your hard disk's contents now more secure than a locked box in a reinforced vault that's
buried in concrete at the bottom of the Mariana Trench, you might imagine you're done, but
think beyond your hard disks for a moment.
Do you blog? Run a website? Use a web-based email service that also holds your calendars
and contacts? Then you'll want to keep that safe too.
Back up blogs
Most blogging software and content management systems, such as Wordpress and Drupal,
have plugins or modules to help you download and save your content offline, which you can
then file away with your favourite backup tool. If your web host runs PhpMyAdmin, you can
also use its Export feature to download entire databases - or selected tables inside them - in
a variety of formats.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Alternatively, if you have shell or telnet access to your database server, you can back up the
database from the command line with mysqldump, as in the following example: mysqldump
-u [username] -p [password] [databasename] > [backupfile.sql]
The backupfile.sql file will contain all the SQL statements needed to create and populate the
tables in a new database server.
Some web hosting control panels, such as cPanel, also enable you to back up your entire
website with a single click.
Back up online email
Then there's web-based email services such as Yahoo and Gmail. Yahoo lets you archive
messages via POP, but you'll have to sign up for Yahoo Mail Plus, which costs $19.99 a year.
Once subscribed, however, you can configure offline email clients such as Evolution and
Thunderbird to fetch messages from the Yahoo servers, and keep them on your hard disk.
Gmail uses the IMAP protocol to synchronise your online mailbox with the one on your disk. In
your Gmail account, make sure IMAP access is enabled under Settings > Forwarding And
POP/IMAP.
Thunderbird will automatically configure itself for sending and receiving emails once you've
pointed it towards your Gmail account, and the setup procedure isn't much different with
Evolution. Once it's been prepared, right-click on a folder and select the Copy Folder
Content Locally For Offline Operation option. Then head to File > Download Messages For
Offline Usage to download messages.
Evolution also enables you to save individual messages with the File > Save As Mbox option.
To make your emails easy to back up, Evolution will also compress them in a single tarball.
Head to File > Backup Settings and specify the location where you want to keep this.
To restore your email, head to File > Restore settings, and point it towards the compressed
tarball.
Backupify
There's a lot of other data you already have online on Facebook, Twitter and other such
services. Like your blog and email, it's a good idea to take occasional snapshots of this data
and back it up locally, which is where Backupify comes in.
tmg.edu.au | 1300 888 TMG (1300 888 864)
It's a web-based service that backs up data on other internet services and enables you to
download it all to your local disk. It can even handle your blog and email if you want an all-
in-one solution. It requires no installation either; just register on its website and authorise the
service to back up your accounts.
It currently works with over a dozen different services, including the ever-popular Facebook,
Twitter, Flickr, Google Docs, Gmail, Blogger and Hotmail, but check the website for a full list.
The basic service is free, offers 2GB of free storage, and backs up data from your online
accounts weekly. There are also paid-for plans that offer more storage and let you adjust the
backup frequency.
Backupify backs up data it receives from the services as is, which is generally in XML.
However, for some services, such as Twitter, it can also generate a PDF.
Currently, the service doesn't enable you to download emails in bulk and the ability to search
backed up messages is under beta testing. You do have the option to download individual
messages in the EML format, though, and Backupify can also restore backed up messages to
Gmail directly.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 24
Summarise the process to back up a Windows Server, version 2012.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 24
tmg.edu.au | 1300 888 TMG (1300 888 864)
Test server to assess the effectiveness of network service security according to agreed design
plan
Penetration tests should be run on a regular basis to identify potential attack vectors, which
are often caused by out-of-date server modules, configuration or coding errors and poor
patch management. Web site security logs should be audited on a continuous basis and
stored in a secure location. Other best practices include using a separate development
server for testing and debugging, limiting the number of superuser and administrator
accounts and deploying an intrusion detection system (IDS) that includes monitoring and
analysis of user and system activities, the recognition of patterns typical of attacks, and the
analysis of abnormal activity patterns.
Penetration Testing
Penetration testing (also called pen testing) is the practice of testing a computer system,
network or Web application to find vulnerabilities that an attacker could exploit.
Pen tests can be automated with software applications or they can be performed manually.
Either way, the process includes gathering information about the target before the test
(reconnaissance), identifying possible entry points, attempting to break in (either virtually or
for real) and reporting back the findings.
The main objective of penetration testing is to determine security weaknesses. A pen test can
also be used to test an organization's security policy compliance, its employees' security
awareness and the organization's ability to identify and respond to security incidents.
Penetration tests are sometimes called white hat attacks because in a pen test, the good
guys are attempting to break in.
Pen test strategies include:
Targeted testing
Targeted testing is performed by the organization's IT team and the penetration testing team
working together. It's sometimes referred to as a "lights-turned-on" approach because
everyone can see the test being carried out.
External testing
This type of pen test targets a company's externally visible servers or devices including
domain name servers (DNS), e-mail servers, Web servers or firewalls. The objective is to find
out if an outside attacker can get in and how far they can get in once they've gained
access.
Internal testing
This test mimics an inside attack behind the firewall by an authorized user with standard
access privileges. This kind of test is useful for estimating how much damage a disgruntled
employee could cause.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Blind testing
A blind test strategy simulates the actions and procedures of a real attacker by severely
limiting the information given to the person or team that's performing the test beforehand.
Typically, they may only be given the name of the company. Because this type of test can
require a considerable amount of time for reconnaissance, it can be expensive.
Double blind testing

Double blind testing takes the blind test and carries it a step further. In this type of pen test,
only one or two people within the organization might be aware a test is being conducted.
Double-blind tests can be useful for testing an organization's security monitoring and incident
identification as well as its response procedures.
Activity 25
Describe the process of penetration testing.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 25
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 26
Why should not only the network perimeter be tested, but also the internal network?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 26
tmg.edu.au | 1300 888 TMG (1300 888 864)
Monitor server logs, network traffic and open ports to detect possible intrusions
Log Management
Log management is the collective processes and policies used to administer and facilitate
the generation, transmission, analysis, storage, archiving and ultimate disposal of the large
A log, in a computing context, is the automatically produced and time-stamped

documentation of events relevant to a particular system. Virtually all software applications
and systems produce log files.
Effective log management is essential to both security and compliance. Monitoring,

documenting and analyzing system events is a crucial component of security intelligence
(SI). In regard to compliance, regulations such as HIPPA, the Gramm-Leach-Bliley Act and
the Sarbanes Oxley Act have specific mandates relating to audit logs.
Log management software automates many of the processes involved. An event log
manager (ELM), for example, tracks changes in an organization's IT infrastructure. These
changes are reflected in audit trails that must be produced for a compliance audit.
How to spot attacks through Apache Web server log analysis
Log analysis requires refined search skills that will help you ferret
out security issues. Brad Causey explains how to sift through log
data and find the relevant security information.
It seems every new device, appliance and even desktop software program has the
capability to generate logs or text-baseddata. There are a number of challenges associated
with managing the onslaught of log data.
The first is centrally storing and gathering these logs; luckily, there are a number of available
products for this. Logs are usually shipped off to a syslog, log management or SIM system that
is centrally located in the network. So the big question is: How do you sift through Web server
log data and find relevant security information?
Although there are many different open source and commercial software applications that
perform some level of log analysis, one thing is usually common among them -- regular
expressions (regex). Regular expressions are basically a string of characters that allow nearly
any scripting language or search tool to perform fast, advanced searches against large
amounts of text data. There are a few variations of regex formats, and the most commonly
used by scripting languages are called Perl-derivative regular expressions. These include
regex formats for .NET framework, Python, Java, JavaScript and, of course, Perl. By using this
type of regex in combination with any scripting language or search tool, you can quickly
and efficiently parse large amounts of data for meaningful information.
tmg.edu.au | 1300 888 TMG (1300 888 864)
One of the most common log formats we tend to see issues in is Apache, or httpd. These
Web server logs tend to hide a number of secrets that are vital to find, such as attack
attempts, successful attack signatures, and even precursor activities to an impending attack.
We will focus on the use of regex with egrep. Egrep uses a very simple syntax for searching
files and is readily present on nearly every operating system in common environments today.
(Windows users can download a free version from a variety of sources).
What to watch for
Here are a few key things to keep an eye out for when searching logs:
• Executable file requests, such as /system32/cmd.exe?c+dir
• File system paths for *nix, such as /var/log or etc/shadow • SQL injection attempts, such as
' or 1=1— or SELECT
• High numbers of login attempts
• Attempts to access restricted areas of your site
• TRACE or OPTIONS request methods
• High numbers of 404 or 500 return codes
Keep in mind that regex used with egrep is also compatible with any program or scripting
language that supports regex.
For this article, we'll look at Apache logs. But the concepts applied via egrep, regex and
httpd logs can be used across hundreds of other platforms, tools and log types.
Understanding what is dangerous and how to search for it is a great step toward recognizing
security issues within your organization.
Step one: Web log format
In order to create expressions to analyze the contents of these logs, we need to understand
the log entry structure. Apache stores something called a server access log, usually in
/etc/httpd/logs, and typically is named something like access_log.
You can configure httpd (Apache) to send these logs to a syslog or SIM system; if so, your log
format may be different from the default. Apache stores return delimited entries in
access_log in the following format:
10.10.10.10 - frank
[10/Oct/2007:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
tmg.edu.au | 1300 888 TMG (1300 888 864)
Let's break this down section by section. The first value, 10.10.10.10, is simply the client IP
address, directly followed by the hostname of the client if HostnameLookups is enabled.
Next, we have the date and time stamp, 10/Oct/2007:11:55:36 -0700. This is obviously
important for correlation purposes.
Next, we have the HTTP header information. This is especially helpful because it gives us
details about what request was made by the client. In this case, GET/apache_pb.gif HTTP/1.0
indicates a GET method of request, targeting the image file named apache_pb.gif that is
located in the root of the httpd Web server's directory.
Finally, the server return code, 200, indicates the request was completed successfully. The last
bit of information is simply the size of the object returned to the client for that request.
Step two: Begin your log analysis and investigation
Now that we understand the breakdown of the log format, we can begin to determine ways
to check for requests that indicate suspicious activity. For example, requests that call for
admin components such as WebMin, a Web server management tool, or admin, a common
login interface name. This will most likely come as part of the request details in the log. With
this in mind, we could simply place these names as strings in a regex query into egrep:
>egrep -n webmin access_log
The structure of this is simple: egrep, followed by any configuration parameters, followed by
the search criteria, followed by the name of the file to be searched.
In this case -n, will display the log line number for reference purposes.
This should produce any server log entries where a request was made to a URL containing
webmin. An example return would look like:
57:10.10.10.10 - bob
[10/Oct/2007:20:24:18 -0700] "GET / webmin HTTP/1.0" 404 726
Breaking down our result, on line 57 of the log file, a request was made at 8:44 p.m. on Oct.
10 to our Web server, requesting the Webmin directory. We can also see the server returned
a 404 message, indicating it unable to locate the directory. This is important because
someone who should have access to administrative functions on the server would know
where to look. Bob could be searching for a way to break into the server.
Step 3: Refine your server log search
It may be of interest to search for other requests by Bob, specifically ones that returned a 200
code, to indicate that he found something. Our command could look something like this:
>egrep -n -i "bob|200" access_log
tmg.edu.au | 1300 888 TMG (1300 888 864)
Although this will find log entries that have Bob or the integer 200 somewhere in them, it
doesn't mean every log returned will be "200" server codes that Bob requested. This will
actually return quite a bit of data we don't really want. It would be more accurate to search
for logs with both Bob and 200. Because both Bob and 200 will have white space around
them, we can further isolate the requests we are looking for. Also note the -i parameter,
which will remove the case-match requirement so that Bob, bOb, boB, bob and BOB, all
match our regex query.
egrep -n -i "\bbob\b.*200*" access_log
This command will restrict our query to only lines in the log that contain both the word bob
and the number 200. The \b that you see on both sides of bob indicate a word boundary, or
the start and stop of a word. The * you see before the 200 indicate that some character will
exist between bob and the 200 and the * after the 200 allow for characters to exist after the
200. This would return entries such as this:
57:10.10.10.10 - bob
[10/Oct/2007:20:24:18 -0700] "GET / webmin HTTP/1.0" 404 726
59:10.10.10.10 - bob
[10/Oct/2007:20:24:59 -0700] "GET /admin HTTP/1.0" 404 726
65:10.10.10.10 - bob
[10/Oct/2007:20:25:35 -0700] "GET /login HTTP/1.0" 404 726
How to harden Linux operating systems
What you will notice when inspecting the results is that it appears Bob is looking for
something. Perhaps an admin interface of some sort, or a way into the Web server. Also, by
paying close attention to the time stamp information, you can see all three requests were
made within about one minute, which tells us Bob is really fast on his keyboard, or he is using
an automated tool of some sort. The latter is most likely, and this may give us enough
information to start investigating further into his actions.
Also, notice that Bob's requests were all met by 404 "not found" messages. If that is the case,
then why did they show up? We did ask for only 200 codes, right? This is a prime example
that a computer only does what you tell it to do, in this case, the date- time stamp happens
to contain the string "200" and that is what we asked for. Using regex can often cause false
positives, but by using our simple query, we were able to eliminate most of them.
Let's investigate Bob a little further.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Step 4: Follow the trail
As a last-ditch effort to track all of Bob's activities, we can search for all requests that Bob
made from his IP address. This requires escaping the periods in the IP address as part of the
regex. Escaping is a method of telling a regex engine that instead of using the special
meaning for a character, we want to use it as a literal search. Note the command below:
>egrep -n -i "10\.10\.10\.10" access_log
In this case, we are telling egrep to find all instances of 10.10.10.10 in the log file. Our results
will look much like this: 57:10.10.10.10 - bob
[10/Oct/2000:20:24:18 -0700] "GET /web min HTTP/1.0" 404 726
59:10.10.10.10 - bob
[10/Oct/2000:20:24:59 -0700] "GET /admin HTTP/1.0" 404 726
65:10.10.10.10 - bob
[10/Oct/2000:20:25:35 -0700] "GET /login HTTP/1.0" 404 726
120:10.10.10.10 - [10/Oct/2000:21:14:11 -0700] "GET /index.html HTTP/1.0" 200 2571
157:10.10.10.10 - [10/Oct/2000:21:50:59 -0700] "GET /parent/directory HTTP/1.0" 404 726
260:10.10.10.10 - [10/Oct/2000:22:25:15 -0700] "GET /support.htm HTTP/1.0" 200 1056
So now we have a pretty good idea that Bob is poking around the site, but hasn't necessarily
violated any laws or crossed any boundaries. But, it's a good idea to continue to watch for
logs containing this information.
Using Web log data to stay alert
When looking for more dangerous attack indicators, keep an eye out for the frequency and
destination of the request. For example, when monitoring an online banking application,
keep a particularly close eye on requests sent to transfers. For example, we may see several
of these when someone is trying to view other's transfer records:
10.10.10.10 - [10/Oct/2000:x:x:x -0700] "GET /banking/view/transfer.jsp?id=12345 HTTP/1.0" 200

1042

798

1042
tmg.edu.au | 1300 888 TMG (1300 888 864)

798
Here we can see where someone noticed the ID=xxxxx in the URL and tried incrementing the
number by one until they found other transfer records. This is a serious breakdown in the
security of the Web application and most certainly something you will want to catch when
analyzing your logs.
Activity 27
Why would you monitor network traffic? What would you be looking for?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 27
tmg.edu.au | 1300 888 TMG (1300 888 864)
Monitor important files to detect unauthorised modifications
Monitoring Linux File access, Changes and Data Modifications
Linux has several solutions to monitor what happens with your data. From changing contents
to who accessed particular information, and at what time.
For our auditing toolkit Lynis, we researched and tested several solutions over the last few
years. In this article we have a look at these solutions to monitor file access, changes and
modifications to the data and beyond.
What is Data?
Data is a collection of bits, ordered in such a way it gives meaning to humans. The related
information stored in data blocks, can be as simple as text, or become a visible
representation like an image. Data is usually the most important part on a system, which
means it has to be properly safeguarded.
Data versus Meta-data
Besides the information stored for us, the system needs to store a little bit of information as
well. For example a data block on disk, might need some supporting information to know
where it is stored. This data is usually not useful for us, but certainly for the system to retrieve
the information, especially when we ask for it. This “data about data” is called meta-data. So
besides protecting data, we have to take the protection of meta-data in mind as well.
Monitoring File Access
The first level of monitoring is who is accessing specific files. This helps us understand what
particular files are being accessed, by what process and by whom. To accomplish this task,
we can use the Linux audit framework. The framework is written by Red Hat and uses
“watches” on files and directories to determine what should be monitored. Additionally it
can monitor processes, including the underlying system calls which are performed by them.
Adding watches
To protect our kernel configuration, we can determine who accesses the sysctl.conf file. This
file stores kernel settings, so it interesting to start with this file. To have this file monitored, we
need to add a watch on the file.
auditctl -w /etc/sysctl.conf -p a -k kernel
The parameter -w sets the watch, followed by the file name. The -p defines the related
permission action (a = attribute change, r = read, w = write, x = execute). It looks similar to file
tmg.edu.au | 1300 888 TMG (1300 888 864)
permissions, but actually it is slightly different. With the -k we define a custom key, which
simplifies searching at a later moment. It is also helpful to categorize events.
Reporting watches
Now we have defined our watch, we can search for it with the earlier defined key.
ausearch -k kernel
Running this command gives us the following output:
File access monitoring with Linux audit framework
When looking at this output, you might be overwhelmed by all the fields available.
Additionally some fields actually have rather strange values, like an architecture of c000003e
(which actually equals x86_64).
The most important fields are the purple box, showing what object was hit and the green box
revealing the process (or binary), followed by the defined key. In this case both the cat
command and vim editor have opened the file
tmg.edu.au | 1300 888 TMG (1300 888 864)
In this screenshot we can also see a failed syscall in the yellow box, with the value 89. To
determine what syscall this is, we first have to look it up:
ausyscall –dump
This will show all available syscalls for our particular system architecture. So in this case a call
to “getrusage”, to retrieve process statistics from the kernel.
Monitoring specific functions
We can use the Linux audit framework also for monitoring specific system calls, or functions.
We have to use the -S followed by the system call.
auditctl -a always,exit -S openat -F success=1
The -a always,exit defines to write out an event at exit time of the related system call.
For example when you want to monitor all successful “openat” calls, add this system call and
tell auditctl only to log successful requests. In this case you might get a message that the
system call is unclear, as it is found on multiple architectures. Find the related system call ID
with ausyscall openat and add the ID instead. Even better is specifying the architecture
together with the system call, as it is easier to read (example: -F arch=b64 -S openat).
File Integrity Monitoring
Another interesting level to monitor file changes, is by implementing file integrity tooling. Linux
has several options for this, varying from simple tools up to kernel modules.
File Integrity Tools
The easiest way to verify if a file has been changed, is using tools. Simple tools like md5sum or
shasum can help with detecting changes. Also specialized tools like AIDE and Samhain are a
great help to set-up automatic monitoring and alerting.
Since setting up these tools are worth a blog post of their own, it will be covered in a
separate post.
Integrity Measurement Architecture (IMA)
The most extensive option is monitoring files with IMA. This security module allows the system
to create and monitor hashes for files and block unauthorized changes.
IMA has a few modes it can operate in, like fix and appraise. In “fix mode” the system allows
the administrator to set hash values along each file. These hashes are small strings of text to
tmg.edu.au | 1300 888 TMG (1300 888 864)
help the system detect changes and are stored in extended attributes (xattrs) of the file
system.
Digital signatures
Additionally IMA supports digital signing. This ensures you that the contents of the file is
correct (or unaltered). Additionally because it is signed, you can validate the signature. So if
a file is to be changed, it also needs proper signing.
Since IMA is a very extensive way of monitoring, we will cover more in other blogs posts. It’s a
very exciting subject and a great help to protect your data.
Extended Verification Method (EVM)
Where IMA monitors the file contents, EVM performs monitoring of the file attributes. It also
allows hashing and digital signing. It’s a great extension to IMA, to ensure that both contents
and the attributes of a file are being unaltered.
Monitoring File Attributes
To monitor file permissions, we can also use the audit framework. File permissions and
ownership are part of the file attributes. The file attributes can be monitored with “-p a“.
Additionally, we can use the earlier covered EVM to ensure attributes are not changed by
an unauthorized process or person.
Now we have looked at some of the tools, it should be clear that a lot of areas can be
monitored on Linux systems. It is up to the administrator to define what files should be
monitored and to which extent. From simply logging changes to attributes with the Linux
audit framework, up to fully blocking altered files with IMA and EVM.
If you're running a stable server and are worried about an intruder modifying your system
binaries to install new corrupted versions you should be using a filesystem integrity checker.
There are several available as part of Debian's stable and unstable archive.
The most widely known integrity checker is tripwire, but several other packages are
available to do the same job including integrit and aide.
tmg.edu.au | 1300 888 TMG (1300 888 864)
All these tools work in the same way, and it's mostly a matter of personal preference which
one you choose to install.
When they are first installed you use them to build up a database of all your important files,
and a corresponding checksum of their contents.
Later you can recompute the checksums of the binaries and compare them against those
you stored in your initial database. This will allow you to detect any binaries, or files, on your
local filesystem which have been modified.
It is important that you store the database of the filesystem securely - such that any
malicious intruder couldn't update it to hide their tracks.
A good way of doing this if you have physical access is to burn it onto CD-ROM as this
allows you to mount it without the ability to write to it.
However each time you legitimately update your system you must rebuild your pristine
database - so this might get expensive fast.
As a simple guide we'll walk through installing both integrit and aide, the latter seems to be
the most popular integrity checker available.
Installing integret is very straightforward. Download and install it via apt-get and you'll be
presented with a couple of simple questions.
apt-get install integrit
When it is installed you must be careful to not tell the software to update or create its
database - because we've not configured it yet. All the other questions may be safely
answered with the defaults.
Once installed you'll find a configuration file /etc/integrit/integrit.conf.
This configuration file contains a list of directories, or paths, which are checked.
Every file beneath the named directory will be checksumed using the SHA-1 hash, and its
details will be stored in the integret database located at /var/lib/integrit.
The configuration file contains a list of example directories along with a brief explaination
of how to add new entries.
A minimal configuration for my machine looks like this:
#
# Global settings
#
tmg.edu.au | 1300 888 TMG (1300 888 864)
root=/
known=/var/lib/integrit/known.cdb
current=/var/lib/integrit/current.cdb
#
# Ignore '!' the following directories because we don't care if their contents are modified.
#
!/mnt
!/dev
!/etc
!/home
!/lost+found
!/proc
!/tmp
!/usr/local
!/usr/src
Once this is setup you can create the initial database:
integrit -C /etc/integrit/integrit.conf -u
This saves the current state of the system into the file /var/lib/integrit/current.cdb, we need
to move this into the known state - and also take a copy offsite.
mv /var/lib/integrit/current.cdb /var/lib/integrit/known.cdb
Mailing a copy of this file offsite to a safe location is useful as it allows you to test again
later - even if you think your database might have been modified by a local user.
To check the filesystem for changes we can now run:
integrit -C /etc/integrit/integrit.conf -c
As you've just created a pristine database you should see no errors.
To test that the system is working run:
touch /bin/ls # Modify a file

integrit -C /etc/integrit/integrit.conf -c
This time you should see an error message:
changed: /bin/ls m(20020318-151001:20041130-142618) c(20031107-102841:20041130-

142618)
tmg.edu.au | 1300 888 TMG (1300 888 864)
(m in this case is the modification date of the file, c being the creation date).
The Debian package will mail you every day if files have changed - and even if they
haven't. There is a cron job setup by the file /etc/cron.daily/integrit. You can edit that file if
you only wish to see an email in the case of differences, the comments explain how to do
so:
# * UNCOMMENT the two following lines marked with `# !' if you don't
# * want to receive reports if no mismatches were found
# ! if [ '$(echo '$output' | egrep -v 'întegrit: ')' ]; then

message=$(echo '$message' && echo '$output')
# ! fi
This overview really showed you the kind of thing that you will have to do with any integrity
checking system:
 Create an initial database.

 Move it somewhere safe. (So that it can be used if you don't trust the local copy).
 Run regular checks of the current system against that database.
All the systems we've mentioned so far, aide, integrit, and tripwire use exactly this mode of
operation.
First of all install it, and when prompted decline the opertunity to create the initial
database:
apt-get install aide
aide is configured by the file /etc/aide/aide.conf and the process is mostly the same as
that shown for integrit already.
The configuration file defines a list of checks, such as the following:
Binlib = p+i+n+u+g+s+b+m+c+md5+sha1
Here we see the check called Binlib is defined as a combination of different tests from the
following table:
# Here are all the things we can check - these are the default rules
#
#p: permissions
#i: inode
#n: number of links
#u: user
tmg.edu.au | 1300 888 TMG (1300 888 864)
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#md5: md5 checksum
#sha1: sha1 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#R: p+i+n+u+g+s+m+c+md5
#L: p+i+n+u+g
#E: Empty group
#>: Growing logfile p+u+g+i+n+S
There are a number of tests defined for different purposes, such as ConfFiles designed to
cover things in /etc, Logs for logfiles, etc.
Then these tests are applied to a group of directories.
So my previous example covering most of the important directories looks like this for aide:
# Binaries
/bin Binlib
/sbin Binlib
/usr/bin Binlib
/usr/sbin Binlib
/usr/local/bin Binlib
/usr/local/sbin Binlib
/usr/games Binlib
# Libraries
/lib Binlib
/usr/lib Binlib
/usr/local/lib Binlib
# Logfiles
/var/log$ StaticDir
/var/log Logs
# Things to ignore
!/dev
!/proc
!/mnt
!/usr/src
tmg.edu.au | 1300 888 TMG (1300 888 864)
!/usr/doc
!/usr/share/doc
Once this is done you can intialise the database, with the following command:
aideinit
The database, by default, will be placed in /var/lib/aide/aide.db.new. If you're happy with

the output you can copy it to the real location for running tests against:
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
As before we'll modify a file and then run a test:
touch /bin/ls
aide --check
This gives the following output:
AIDE found differences between database and filesystem!!

Start timestamp: 2004-11-30 14:39:45
Summary:
Total number of files=11247,added files=0,removed files=0,changed files=1
Changed files:
changed:/bin/ls
Detailed information about changes:
File: /bin/ls
Mtime : 2004-11-30 14:26:18 , 2004-11-30 14:39:39
Ctime : 2004-11-30 14:26:18 , 2004-11-30 14:39:39
As you can see this is more readable than the example we showed previously with integrit,
but this is offset by the trickier setup required.
If you're happy to acknowlege the change just re-run the aideinit command and move
the new database into the live location - this will cause future checks to be error free.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Investigate and verify alleged violations of server or data security and privacy breaches 1
This guide provides general guidance for agencies and organisations when responding to a
data breach involving personal information that they hold.
 Agencies and organisations have obligations under the Privacy Act 1988 (Cth) to put
in place reasonable security safeguards and to take reasonable steps to protect the
personal information that they hold from misuse, interference and loss, and from
unauthorised access, modification or disclosure.
 Those reasonable steps may include the preparation and implementation of a data
breach policy and response plan (that includes notifying affected individuals and the
OAIC).
 Data breaches are not limited to malicious actions, such as theft or ‘hacking’, but
may arise from internal errors or failure to follow information handling policies that
cause accidental loss or disclosure.
 In general, if there is a real risk of serious harm as a result of a data breach, the
affected individuals and the OAIC should be notified.
 Notification can be an important mitigation strategy for individuals, and can promote
transparency and trust in the organisation or agency.
 Notification of a data breach supports good privacy practice.
 Notification of a data breach in compliance with this guide is not required by the
Privacy Act. However, the steps and actions in this guide are highly recommended by
the OAIC.
 The ALRC has recommended that the Privacy Act be amended to impose a
mandatory obligation to notify the Privacy Commissioner and affected individuals in
the event of a data breach that could give rise to a real risk of serious harm to
affected individuals. The operation of this guide could inform the Australian
Government’s response to the ALRC’s recommendation that mandatory breach
notification be introduced into law.
Key terms
ALRC means the Australian Law Reform Commission
APPs means the Australian Privacy Principles set out Schedule 1 to the Privacy Act, which
apply to APP entities.
APP entity has the meaning set out in s6 of the Privacy Act, and means an agency or
organisation for the purpose of the Privacy Act.
1
Source: Office of the Australian Information Commissioner, as at https://www.oaic.gov.au/agencies-and-
organisations/guides/data-breach-notification-a-guide-to-handling-personal-information-security-breaches, as
on 26th July, 2016.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Agency has the meaning set out in s6 of the Privacy Act and includes most Australian
Government and Norfolk Island departments, agencies and Ministers.
Privacy Act means the Privacy Act 1988 (Cth).
Personal information has the meaning as set out in s6 of the Privacy Act:
personal information means information or an opinion about an identified individual, or an

individual who is reasonably identifiable:
a. whether the information or opinion is true or not; and

b. whether the information or opinion is recorded in a material form or not.
Data breach means, for the purpose of this guide, when personal information held by an
agency or organisation is lost or subjected to unauthorised access, modification, disclosure,
or other misuse or interference.
Note: The Privacy Act regulates the handling of personal information, and does not generally
refer to ‘data’. As such, in the interest of consistency with the Act, the previous edition of this
guide used the term ‘personal information security breach’.
However, the term ‘data breach’ has since entered into common usage in Australia and in
various other jurisdictions. Accordingly, in the interests of clarity and simplicity, this guide uses
the term ‘data breach’ rather than ‘personal information security breach’.
OAIC means the Office of the Australian Information Commissioner.
Organisation has the meaning set out in s6C of the Privacy Act and, in general, includes all
businesses and non-government organisations with an annual turnover of more than
$3 million, all health service providers and a limited range of small businesses (see ss6D and 6E
of the Privacy Act).
TFN means Tax File Number. The Privacy Act includes provisions relating to TFNs in Part III. The
OAIC has issued rules under s17 of the Privacy Act to regulate the use of TFNs.
Background
The purpose of this guide
This guide was developed to assist agencies and organisations to respond effectively to data
breaches.
The OAIC developed this guide in August 2008 in response to requests for advice from
agencies and organisations, and in recognition of the global trends relating to data breach
notification. In July 2011, the OAIC revised this guide to keep pace with the changing
attitudes and approaches to data breach management. In August 2014, the OAIC revised
tmg.edu.au | 1300 888 TMG (1300 888 864)
this guide again to take account of amendments to the Privacy Act, including the
introduction of the APPs.
In its 2008 report titled ‘For Your Information: Australian Privacy Law and Practice’ (Report
108), the ALRC recommended that the Privacy Act be amended to impose a mandatory
obligation to notify the Privacy Commissioner and affected individuals in the event of a data
breach that could give rise to a ‘real risk of serious harm’ to the affected individuals
(recommendation 51-1). The OAIC strongly supports that recommendation.
Accordingly, this guide is aimed, in part, at encouraging agencies and organisations to

voluntarily put in place reasonable measures to deal with data breaches (including
notification of affected individuals and the OAIC), while legislative change is considered by
the Australian Government.
Scope of this guide
Data breach notification is an important option in responding to a data breach. However, a

key challenge in responding to a data breach is determining if and when notification is an
appropriate response.
This guide provides general guidance on key steps and factors for agencies and
organisations to consider when responding to a data breach, including notification of
breaches.
This guide encourages a risk-analysis approach. Agencies and organisations should evaluate
data breaches on a case-by-case basis and make decisions on actions to take according to
their own assessment of risks and responsibilities in their particular circumstances.
This guide also highlights the importance of preventative measures as part of a

comprehensive information security plan (which may include a data breach response plan).
It is not intended that the advice in this guide be limited to data breaches that are breaches
of the APPs. Rather, the guide is intended to apply to any situation where personal
information has been compromised.
While establishing appropriate thresholds and processes for data breach notification is good
privacy practice, the steps and actions outlined in this guide are not specifically required
under the Privacy Act. Therefore, while the OAIC strongly recommends compliance with this
guide, compliance is not mandatory.
Who should use this guide?
This guide has been developed for use by Australian Government and Norfolk Island
agencies, and private sector organisations, that handle personal information and are
covered by the Privacy Act.
tmg.edu.au | 1300 888 TMG (1300 888 864)
State and territory government agencies, as well as private sector entities not covered by the
Privacy Act, may find the guide helpful in outlining good privacy practice. However, the
OAIC would not have a role in receiving notifications about data breaches experienced by
those entities, other than for ACT Government agencies.
State and territory government agencies should also consider the role of relevant Privacy or
Information Commissioners (or applicable privacy schemes) in their own jurisdictions (listed at
the end of this guide).
Data breaches
How do data breaches occur?
Data breaches occur in a number of ways. Some examples include:
 lost or stolen laptops, removable storage devices, or paper records containing

personal information
 hard disk drives and other digital storage media (integrated in other devices, for
example, multifunction printers, or otherwise) being disposed of or returned to
equipment lessors without the contents first being erased
 databases containing personal information being ‘hacked’ into or otherwise illegally
accessed by individuals outside of the agency or organisation
 employees accessing or disclosing personal information outside the requirements or
authorisation of their employment
 paper records stolen from insecure recycling or garbage bins
 an agency or organisation mistakenly providing personal information to the wrong
person, for example by sending details out to the wrong address, and
 an individual deceiving an agency or organisation into improperly releasing the
personal information of another person.
Preventing data breaches — obligations under the Privacy Act
Security is a basic element of information privacy. In Australia, this principle is reflected in the
Privacy Act in the APPs.
Agencies and organisations are required to take reasonable steps to protect the personal
information they hold from misuse, interference and loss, and from unauthorised access,
modification or disclosure. This requirement is set out in APP.
Sections 20Q and 21S of the Privacy Act imposes equivalent obligations on credit reporting
agencies and all credit providers. Similarly, guideline 6.1 of the statutory TFN guidelines
requires TFN recipients to protect TFN information by such security safeguards as are
reasonable in the circumstances.
Depending on the circumstances, those reasonable steps may include the preparation and
implementation of a data breach policy and response plan. Notification of the individuals
tmg.edu.au | 1300 888 TMG (1300 888 864)
who are or may be affected by a data breach, and the OAIC, may also be a reasonable
step.
Other obligations
Many agencies are subject to agency-specific legislative requirements that add further
protections for personal information (such as secrecy provisions), as well as legislative and
other requirements which apply more generally across government. These other
requirements can include the Australian Government’s Protective Security Policy Framework
and the Information Security Manual.
Organisations may also be subject to additional obligations through sector-specific

legislation in respect of particular information they hold. For example, Part 13 of the
Telecommunications Act 1997 (Cth) sets out obligations on the telecommunications industry
in relation to the handling of certain telecommunications-related personal information. Some
organisations may also have common law duties relating to the confidentiality of particular
information.
These additional obligations need to be considered by agencies and organisations when

taking steps to prevent or respond to data breaches.
Considerations for keeping information secure
Note: Some of the information in Step 4 of this guide (Prevent future breaches: see page 30)
could equally be used by agencies or organisations as a way of assessing what security
measures are necessary to prevent data breaches.
What are the reasonable steps (as required by APP 11) necessary to secure personal
information will depend on context, including (but not limited to):
 the sensitivity (having regard to the affected individual(s)) of the personal information
held by the agency or organisation
 the harm that is likely to result to individuals if there is a data breach involving their
personal information
 the potential for harm (in terms of reputational or other damage) to the agency or
organisation if their personal information holdings are breached, and
 how the agency or organisation stores, processes and transmits the personal
information (for example, paper-based or electronic records, or by using a third party
service provider).
Appropriate security safeguards for personal information need to be considered across a

range of areas. This could include maintaining physical security, computer and network
security, communications security and personnel security. To meet their information security
obligations, agencies and organisations should consider the following steps:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Risk assessment – Identifying the security risks to personal information held by the
organisation and the consequences of a breach of security.
 Privacy impact assessments – Evaluating, in a systemic way, the degree to which
proposed or existing information systems align with good privacy practice and legal
obligations.
 Policy development – Developing a policy or range of policies that implement
measures, practices and procedures to reduce the identified risks to information
security.
 Staff training – Training staff and managers in security and fraud awareness, practices
and procedures and codes of conduct.
 The appointment of a responsible person or position – Creating a designated position
within the agency or organisation to deal with data breaches. This position could
have responsibility for establishing policy and procedures, training staff, coordinating
reviews and audits and investigating and responding to breaches.
 Technology – Implementing privacy enhancing technologies to secure personal
information held by the agency or organisation, including through such measures as
access control, copy protection, intrusion detection, and robust encryption.
 Monitoring and review – Monitoring compliance with the security policy, periodic
assessments of new security risks and the adequacy of existing security measures, and
ensuring that effective complaint handling procedures are in place.
 Standards – Measuring performance against relevant Australian and international
standards as a guide.
 Appropriate contract management – Conducting appropriate due diligencewhere
services (especially data storage services) are contracted, particularly in terms of the
IT security policies and practices that the service provider has in place, and then
monitoring compliance with these policies through periodic audits.
Further, in seeking to prevent data breaches, agencies and organisations should consider
their other privacy obligations under the APPs. Some breaches or risks of harm can be
avoided or minimised by not collecting particular types of personal information or only
keeping it for as long as necessary. Consider the following:
 What personal information is it necessary to collect? – Personal information that is

never collected, cannot be mishandled. APP 3 requires that APP entities must not
collect personal information unless it is reasonably necessary, or directly related to,
one or more of their functions or activities. Additional restrictions apply to the
collection of sensitive information (see APP 3.3).
 How long does the personal information need to be kept? – APPs 4.3 and 11.2 require
APP entities organisations to take reasonable steps to destroy information, on ensure
that it is de-identified, if that information is no longer needed for any purpose
permitted under the APPs.
Agencies have record-keeping obligations with respect to Commonwealth records –

this is reflected in APP 11.2(c). Accordingly, agencies should carefully consider
retention practices, subject to record keeping requirements such as those contained
tmg.edu.au | 1300 888 TMG (1300 888 864)
in the Archives Act 1983 (Cth) (including their Records Disposal Authorities) or other
legislation.
Why data breach notification is good privacy practice
Notifying individuals when a data breach involves their personal information supports good
privacy practice, for the following reasons:
 Notification as a reasonable security safeguard – As part of the obligation to keep

personal information secure, notification may, in some circumstances, may be a
reasonable step in the protection of personal information from misuse, interference
and loss, and from unauthorised access, modification or disclosure (as required by
APP 11).
 Notification as openness about privacy practices – Being open and transparent with
individuals about how personal information may be handled is recognised as a
fundamental privacy principle. Part of being open about the handling of personal
information may include telling individuals when something goes wrong and
explaining what has been done to try to avoid or remedy any actual or potential
harm.
 Notification as restoring control over personal information – Where personal
information has been compromised, notification can be essential in helping
individuals to regain control of that information. For example, where an individual’s
identity details have been stolen, once notified, the individual can take steps to
regain control of their identity information by changing passwords or account
numbers, or requesting the reissue of identifiers.
 Notification as a means of rebuilding public trust – Notification can be a way of
demonstrating to the public that an agency or organisation takes the security of
personal information seriously, and is working to protect affected individuals from the
harms that could result from a data breach. Customers may be reassured to know
that an agency or organisation’s data breach response plan includes notifying them,
the OAIC, and relevant third parties.
The OAIC strongly encourages notification in appropriate circumstances as part of good

privacy practice, and in the interest of maintaining a community in which privacy is valued
and respected.
The role of the Office of the Australian Information Commissioner
A data breach may constitute a breach of information security obligations under the Privacy
Act; for example, the obligations imposed by the APPs, the TFN guidelines, or the credit
reporting provisions of the Act. In those circumstances, the breach will be an interference
with an individual’s privacy. Individuals can complain about such interferences to the OAIC.
The OAIC has the function of investigating possible breaches of the Privacy Act. It also has
the function of providing guidance and advice to agencies and organisations on the
tmg.edu.au | 1300 888 TMG (1300 888 864)
operation of the Privacy Act. As such, the OAIC may provide general information on how to
respond to a data breach.
Step 3(d) of this guide provides guidance on when it may be appropriate to notify the OAIC
of a data breach. Consistent with its statutory functions, the OAIC may consider whether it
needs to investigate the conduct. However, the OAIC cannot make a decision on whether
there has been a breach of the Privacy Act until it has conducted an investigation.
If an individual thinks an agency or organisation covered by the Privacy Act has interfered
with his or her privacy, and they have been unable to resolve the matter directly with the
agency or organisation, they can complain to the OAIC. The OAIC may investigate and
may attempt to resolve the matter by conciliation between the parties.
The Commissioner also has the power to initiate an investigation on their own initiative in
appropriate circumstances without first receiving a complaint.
The Commissioner has a range of enforcement powers, including the power to:
 make a determination requiring the payment of compensation for damages or other

remedies, such as the provision of access or the issuance of an apology (enforceable
by the Federal Court or Federal Magistrates Court)
 accept an enforceable undertakings,
 seek civil penalties of up to or apply for civil penalty orders of up to $340,000 for
individuals and up to $1.7 million for companies, and
 seek an injunction regarding conduct that would contravene the Privacy Act.
Contraventions of some of the credit reporting provisions in Part IIIA of the Privacy Act carry
specific penalties.
Agencies should also be aware that, under s28B(1)(b) of the Privacy Act, the Information
Commissioner can inform the Minister responsible for the Privacy Act of action that needs to
be taken by an agency in order to comply with the APPs.
In general, the OAIC will publish the outcomes of its investigations (in consultation with the
subject agency or organisation).
In some circumstances, consistent with its roles of education and enforcement, the OAIC
may publicise information about the information management practices of an agency or
organisation.
Responding to data breaches: four key steps
Data breaches can be caused or exacerbated by a variety of factors, affect different types
of personal information and give rise to a range of actual or potential harms to individuals,
agencies and organisations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
As such, there is no single way of responding to a data breach. Each breach will need to be
dealt with on a case-by-case basis, undertaking an assessment of the risks involved, and
using that risk assessment as the basis for deciding what actions to take in the circumstances.
There are four key steps to consider when responding to a breach or suspected breach:
Step 1: Contain the breach and do a preliminary assessment
Step 2: Evaluate the risks associated with the breach
Step 3: Notification
Step 4: Prevent future breaches
Each of the steps is set out in further detail below.
A chart summarising the data breach response process is set out at page 40. Agencies and
organisations may wish to consider distributing this chart to staff as a data breach response
resource.
General tips:
 Be sure to take each situation seriously and move immediately to contain and assess
the suspected breach.
 Breaches that may initially seem immaterial may be significant when their full
implications are assessed.
 Agencies and organisations should undertake steps 1, 2 and 3 either simultaneously or
in quick succession. In some cases it may be appropriate to notify individuals
immediately, before containment or assessment of the breach occurs.
 The decision on how to respond should be made on a case-by-case basis.
Depending on the breach, not all steps may be necessary, or some steps may be
combined. In some cases, agencies and organisations may choose to take
additional steps that are specific to the nature of the breach.
Step 1: Contain the breach and do a preliminary assessment
Once an agency or organisation has discovered or suspects that a data breach has
occurred, it should take immediate common sense steps to limit the breach. These may
include the following:
Contain the breach
Take whatever steps possible to immediately contain the breach.
tmg.edu.au | 1300 888 TMG (1300 888 864)
For example, stop the unauthorised practice, recover the records, or shut down the system
that was breached. If it is not practical to shut down the system, or if it would result in loss of
evidence, then revoke or change computer access privileges or address weaknesses in
physical or electronic security.
Assess whether steps can be taken to mitigate the harm an individual may suffer as a result
of a breach.
For example, if it is detected that a customer’s bank account has been compromised, can
the affected account be immediately frozen and the funds transferred to a new account?
Initiate a preliminary assessment
Move quickly to appoint someone to lead the initial assessment. This person should have
sufficient authority to conduct the initial investigation, gather any necessary information and
make initial recommendations. If necessary, a more detailed evaluation may subsequently
be required.
Determine whether there is a need to assemble a team that could include representatives
from appropriate parts of the agency or organisation.
Consider the following preliminary questions:
 What personal information does the breach involve?

 What was the cause of the breach?
 What is the extent of the breach?
 What are the harms (to affected individuals) that could potentially be caused by the
breach?
 How can the breach be contained?
Consider who needs to be notified immediately
Determine who needs to be made aware of the breach (internally, and potentially
externally) at this preliminary stage.
In some cases it may be appropriate to notify the affected individuals immediately (for
example, where there is a high level of risk of serious harm to affected individuals).
Escalate the matter internally as appropriate, including informing the person or group within
the agency or organisation responsible for privacy compliance.
It may also be appropriate to report such breaches to relevant internal investigation units.
If the breach appears to involve theft or other criminal activity, it will generally be
appropriate to notify the police.
tmg.edu.au | 1300 888 TMG (1300 888 864)
If the data breach is likely to involve a real risk of serious harm to individuals, or receive a high
level of media attention, inform the OAIC. The OAIC may be able to provide guidance and
assistance.
Other matters
Where a law enforcement agency is investigating the breach, consult the investigating
agency before making details of the breach public.
Be careful not to destroy evidence that may be valuable in determining the cause or would
allow the agency or organisation to take appropriate corrective action.
Ensure appropriate records of the suspected breach are maintained, including the steps
taken to rectify the situation and the decisions made.
An example of breach containment and preliminary assessment
An online recruitment agency accepts résumés from jobseekers and makes these available
to recruiters and employers on a password protected website.
Jane, a jobseeker whose résumé is on the website, receives an email which she suspects is a
‘phishing’ email. The email is personalised and contains information from her résumé. It
contains a number of spelling mistakes and offers her a job. The email claims that all Jane
has to do to secure the job is to provide her bank account details so she can be paid. Jane
advises the recruitment agency of her suspicions, and forwards a copy of the email to the
recruitment agency.
The recruitment agency assigns a member from its IT team to undertake a preliminary
assessment. It is found that the email is indeed a phishing email. It claims to be from a
recruiter and directs the recipient to a website which asks them to enter further information. It
also installs spyware on the recipient’s computer.
The recruitment agency attempts to establish how phishers came to have the résumé details
of the jobseeker. The recruitment agency’s preliminary assessment reveals that the phishers
have stolen legitimate user names and passwords from recruiters who use the agency’s
website and have fraudulently accessed jobseeker information.
The IT team escalates the issue internally by informing senior staff members and quickly
contains the breach by disabling the compromised recruiter accounts. Based on the IT
team’s preliminary assessment, senior staff move to evaluate risks associated with the breach
and consider what actions should be taken to mitigate any potential harm.
Step 2: Evaluate the risks associated with the breach
To determine what other steps are immediately necessary, agencies and organisations
should assess the risks associated with the breach.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consider the following factors in assessing the risks:
a. The type of personal information involved.

b. The context of the affected information and the breach.
c. The cause and extent of the breach.
d. The risk of serious harm to the affected individuals.
e. The risk of other harms.
a) Consider the type of personal information involved
Does the type of personal information that has been compromised create a greater risk of
harm?
Some information is more likely to cause an individual harm if it is compromised, whether that
harm is physical, financial or psychological.
For example, government-issued identifiers such as Medicare numbers, driver’s licence and
health care numbers, health information, and financial account numbers such as credit or
debit card numbers might pose a greater risk of harm to an individual than their name or
address.
Also, a combination of personal information typically creates a greater risk of harm than a
single piece of personal information.
It may also matter whether the information is permanent or temporary. Permanent

information, such as someone’s name place and date of birth, or medical history cannot be
‘re-issued’.
The permanence of the information may be more significant if it is protected by encryption –

over time, encryption algorithms may be broken, so such information may be at greater
longer term risk of being compromised. On the other hand, temporary information may have
changed by the time it has been decrypted.
Who is affected by the breach?
Employees, contractors, the public, clients, service providers, other agencies or

organisations?
Remember that certain people may be particularly at risk of harm. A data breach involving
name and address of a person might not always be considered high risk. However, a breach
to a women’s refuge database containing name and address information may expose
women who attend the refuge to a violent family member. There may be less risk if the
breach only relates to businesses that service the refuge.
b) Determine the context of the affected information and the breach
tmg.edu.au | 1300 888 TMG (1300 888 864)
What is the context of the personal information involved?
For example, a list of customers on a newspaper carrier’s route may not be sensitive
information. However, the same information about customers who have requested service
interruption while on vacation may be more sensitive.
The sensitivity of personal information that may also publicly available information (such as
the type found in a public telephone directory) also depends on context. For example, what
might be the implications of someone’s name and phone number or address being
associated with the services offered, or the professional association represented?
What parties have gained unauthorised access to the affected information?
To whom was the information exposed? Employee records containing information about
employment history such as performance and disciplinary matters or a co-worker’s mental
health might be particularly sensitive if exposed to other employees in the workplace and
could result in an individual being the subject of humiliation or workplace bullying.
Have there been other breaches that could have a cumulative effect?
A number of small, seemingly insignificant, breaches could have a cumulative effect.

Separate breaches that might not, by themselves, be assessed as representing a real risk of
serious harm to an affected individual, may meet this threshold when the cumulative effect
of the breaches is considered.
This could involve incremental breaches of the same agency or organisation’s database. It
could also include known breaches from a number of different sources.
How could the personal information be used?
Could the information be used for fraudulent or otherwise harmful purposes, such as to cause
significant embarrassment to the affected individual?
Could the compromised information be easily combined either with other compromised
information or with publicly available information to create a greater risk of harm to the
individual?
c) Establish the cause and extent of the breach
Is there a risk of ongoing breaches or further exposure of the information?
What was the extent of the unauthorised access to or collection, use or disclosure of personal
information, including the number and nature of likely recipients and the risk of further
access, use or disclosure, including via mass media or online?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Is there evidence of theft?
Is there evidence that suggests theft, and was the information the target? For example,
where a laptop is stolen, can it be determined whether the thief specifically wanted the
information on the laptop, or the laptop hardware itself?
Evidence of theft could suggest a greater intention to do harm and heighten the need to
provide notification to the individual, as well as law enforcement.
Is the personal information adequately encrypted, anonymised or otherwise not easily

accessible?
Is the information rendered unreadable by security measures that protect the stored
information? Is the personal information displayed or stored in such a way so that it cannot
be used if breached?
For example, if a laptop containing adequately encrypted information is stolen, but is

subsequently recovered and investigations show that the information was not accessed,
copied or otherwise tampered with, notification to affected individuals may not be
necessary.
What was the source of the breach?
For example, did it involve external or internal malicious behaviour, or was it an internal
processing error? Does the information seem to have been lost or misplaced?
The risk of harm to the individual may be less where the breach is unintentional or accidental,
rather than intentional or malicious.
For example, the client may have a common surname which leads a staff member to
accidentally access the wrong client record. The access records show that the staff member
immediately closed the client record once they became aware of their mistake. The risk of
harm will be less in this case than in the case where a staff member intentionally and
deliberately opens a client’s record to browse the record, or to use or disclose that
information without a legitimate business reason for doing so.
Has the personal information been recovered?
For example, has a lost laptop been found or returned? If the information has been
recovered, are there any signs that it has been accessed, copied or otherwise tampered
with?
tmg.edu.au | 1300 888 TMG (1300 888 864)
What steps have already been taken to mitigate the harm?
Has the agency or organisation contained the breach? For example, have compromised
security measures such as passwords been replaced? Has the full extent of the breach been
assessed? Are further steps required?
Is this a systemic problem or an isolated incident?
When checking the source of the breach, it is important to check whether any similar
breaches have occurred in the past. Sometimes, a breach can signal a deeper problem with
system security. This may also reveal that more information has been affected than initially
thought, potentially heightening the awareness of the risk posed.
How many individuals are affected by the breach?
If the breach is a result of a systemic problem, there may be more people affected than first
anticipated.
Even where the breach involves accidental and unintentional misuse of information, if the
breach affects many individuals, the scale of the breach may create greater risks that the
information will be misused. The agency or organisation’s response should be proportionate.
While the number of affected individuals can help gauge the severity of the breach, it is
important to remember that even a breach involving the personal information of one or two
people can be serious, depending on the information involved.
d) Assess the risk of harm to the affected individuals
Who is the recipient of the information?
Is there likely to be any relationship between the unauthorised recipients and the affected
individuals?
For example, was the disclosure to an unknown party or to a party suspected of being
involved in criminal activity where there is a potential risk of misuse? Was the disclosure to a
person against whom the individual has a restraining order, or to co-workers who have no
need to have the information?
Or was the recipient a trusted, known entity or person that would reasonably be expected to
return or destroy the information without disclosing or using it? For example, was the
information sent to the individual’s lawyer instead of being sent to them, or to another party
bound by professional duties of confidentiality or ethical standards?
What harm to individuals could result from the breach?
Examples include:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 identity theft
 financial loss
 threat to physical safety
 threat to emotional wellbeing
 loss of business or employment opportunities
 humiliation, damage to reputation or relationships, or
 workplace or social bullying or marginalisation.
e) Assess the risk of other harms
Other possible harms, including to the agency or organisation that suffered the breach
Examples include:
 the loss of public trust in the agency, government program, or organisation

 reputational damage
 loss of assets (e.g., stolen computers or storage devices)
 financial exposure (e.g., if bank account details are compromised)
 regulatory penalties (e.g., for breaches of the Privacy Act)
 extortion
 legal liability, and
 breach of secrecy provisions in applicable legislation.
An example of evaluating the risks associated with the breach
A newspaper publisher receives a call from a newsagent that sells its newspapers. The
newsagent says that the address labels on the bundles of newspapers delivered to his shop
appear to show subscriber information printed on the other side. The information includes
names, addresses and credit card details.
Following a preliminary investigation, the newspaper publisher confirms that some labels
have been inadvertently printed on the back of subscriber lists.
As a first step to containing the breach, the publisher attempts to contact newsagencies that
have received the newspapers and asks them to check the labels on the bundles and
securely destroy any that show subscriber details on the back.
With these first steps completed, the newspaper publisher begins to evaluate the risks
associated with the breach.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The information that was involved in the breach was name, address and credit card
information. The newspaper has a large number of subscribers. Further investigations into the
breach are unable to reveal how many subscribers’ details have been exposed.
The bundles of newspapers displaying subscriber information have been delivered to

newsagencies in the early hours of the morning. The newspaper publisher notes that the
subscriber information was therefore at risk of unauthorised access during the time between
delivery and when the newsagents arrived to open shop.
Further investigations reveal that many newsagencies have already discarded the labels
before checking could be carried out as to whether they contained subscriber information.
This means that, in many cases, the subscriber lists may not have been securely destroyed.
The newspaper publisher concludes that the exposure of this information could present a real
risk of serious harm (in this case, financial harm) to many individuals. Based on the conclusion
that this is a serious breach, the publisher moves to notify subscribers. Given the large number
of potentially affected individuals and the risk of serious financial harm, the publisher also
notifies the OAIC, particularly as there is a real possibility that individuals may complain about
the breach.
An example of evaluating the risks associated with the discovery of routine breaches
An Australian Government agency undertakes a periodic audit of user access records. The
audit reveals an unusual pattern of client account enquiries in one branch of the agency.
The client records contain address information, financial information, and other details. The
enquiries have occurred over a 12 month period.
After some investigation, which includes interviewing the relevant staff, managers and the
department head, it is determined that a specific staff member, John, has been browsing
the client accounts of his family and friends without any legitimate business purpose (and
therefore without authorisation). There is no evidence that client information has been
disclosed to any third party.
The agency recognises that some of the information in the client accounts (the financial
information in particular) is sensitive information that is not readily available. The agency
considers that there is real risk of embarrassment or other harms from the release of that
information, especially to a person such as John, who has a personal relationship with the
affected individuals and could combine the information with the details about the
individuals that he already knows.
On that basis, the agency decides to notify the individuals affected by the unauthorised
access. It also takes measures to prevent unauthorised access to client accounts by staff,
and to ensure that all staff are aware of their obligations to act appropriately.
The agency considers that, having regard to the sensitivity of the information and the context
of the breach, the breach is sufficiently serious to warrant notification to the OAIC.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Step 3: Notification
Agencies and organisations should consider the particular circumstances of the breach,
and:
a. decide whether to notify affected individuals, and, if so

b. consider when and how notification should occur, who should make the notification,
and who should be notified
c. consider what information should be included in the notification, and
d. consider who else (other than the affected individuals) should be notified.
Notification can be an important mitigation strategy that has the potential to benefit both
the agency or organisation and the individuals affected by a data breach. The challenge is
to determine when notification is appropriate. While notification is an important mitigation
strategy, it will not always be an appropriate response to a breach. Providing notification
about low risk breaches can cause undue anxiety and de-sensitise individuals to notice.
Each incident needs to be considered on a case-by-case basis to determine whether
breach notification is required.
In general, if a data breach creates a real risk of serious harm to the individual, the affected
individuals should be notified.
Prompt notification to individuals in these cases can help them mitigate the damage by
taking steps to protect themselves. Agencies and organisations should:
 take into account the ability of the individual to take specific steps to mitigate any
such harm, and
 consider whether it is appropriate to inform other third parties such as the OAIC, the
police, or other regulators or professional bodies about the data breach.
a) Deciding whether to notify affected individuals
Agencies and organisations should consider whether their obligations under APP11 require
them to notify affected individuals and the OAIC (as a ‘reasonable step’ to ensure the
security of personal information that they hold).
The key consideration is whether notification is necessary to avoid or mitigate serious harm to
an affected individual.
Agencies and organisations should consider the following factors when deciding whether
notification is required:
 What is the risk of serious harm to the individual as determined by step 2?

 What is the ability of the individual to avoid or mitigate possible harm if notified of a
breach (in addition to steps taken by the agency or organisation)? For example,
would an individual be able to have a new bank account number issued to avoid
tmg.edu.au | 1300 888 TMG (1300 888 864)
potential financial harm resulting from a breach? Would steps such as monitoring
bank statements or exercising greater vigilance over their credit reporting records
assist in mitigating risks of financial or credit fraud?
 Even if the individual would not be able to take steps to fix the situation, is the
information that has been compromised sensitive, or likely to cause humiliation or
embarrassment for the individual?
 What are the legal and contractual obligations to notify, and what are the
consequences of notification?
There may be adverse consequences if an agency or organisation does not notify affected
individuals. For example, if the public, including the affected individuals, subsequently find
out about the breach through the media, there may be loss of public trust in the agency or
organisation (which, in turn, could have its own costs).
b) Notification process
At this stage, the organisation or agency should have as complete a set of facts as possible
and have completed the risk assessment to determine whether to notify individuals. The
following tables set out some of the considerations in the notification process.
Sometimes the urgency or seriousness of the breach dictates that notification should happen
immediately, before having all the relevant facts.
When to notify?
In general, individuals affected by the breach should be notified as soon as reasonably

possible.
If law enforcement authorities are involved, check with those authorities whether notification
should be delayed to ensure that the investigation is not compromised.
Delaying the disclosure of details about a breach of security or information systems may also
be appropriate until that system has been repaired and tested or the breach contained in
some other way.
How to notify?
In general, the recommended method of notification is direct – by phone, letter, email or in

person – to the affected individuals.
Indirect notification, either by website information, posted notices, media, should

generallyonly occur where direct notification could cause further harm, is cost-prohibitive, or
the contact information for affected individuals is not known.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Preferably, notification should be ‘standalone’ and should not be ‘bundled’ with other
material unrelated to the breach, as it may confuse recipients and affect the impact of the
breach notification.
In certain cases, it may be appropriate to use multiple methods of notification.
Agencies and organisations should also consider whether the method and content of
notification might increase the risk of harm, such as by alerting the person who stole the
laptop of the value of the information on the laptop, if it would not otherwise be apparent.
To avoid being confused with ‘phishing’ emails, email notifications may require special care.
For example, only communicate basic information about the breach, leaving more detailed
advice to other forms of communication.
Who should notify?
Typically, the agency or organisation that has a direct relationship with the customer, client
or employee should notify the affected individuals.
This includes where a breach may have involved handling of personal information by a third
party service provider, contractor or related body corporate.
Joint and third party relationships can raise complex issues. For example, the breach may
occur at a retail merchant but involve credit card details from numerous financial institutions,
or the card promoter may not be the card issuer (for example, many airlines, department
stores and other retailers have credit cards that display their brand, though the cards are
issued by a bank or credit card company). Or the breach may involve information held by a
third party ‘cloud’ data storage provider, based outside of Australia.
The issues in play in each situation will vary. Organisations and agencies will have to consider
what is best on a case by case basis. However some relevant considerations might include:
 Where did the breach occur?

 Who does the individual identify as their ’relationship’ manager?
 Does the agency or organisation that suffered the breach have contact details for
the affected individuals? Are they able to obtain them easily? Or could they draft
and sign off the notification, for the lead organisation to send?
Is trust important to the organisation’s or agency’s activities?
Who should be notified?
Generally, it should be the individual(s) affected by the breach. However, in some cases it
may be appropriate to notify the individual’s guardian or authorised representative on their
behalf.
tmg.edu.au | 1300 888 TMG (1300 888 864)
There may be circumstances where carers or authorised representatives should be notified

as well as, or instead of, the individual.
Where appropriate, clinical judgement may be required where notification may exacerbate
health conditions, such as acute paranoia.
c) What should be included in the notification?
The content of notifications will vary depending on the particular breach and the notification
method. In general, the information in the notice should help the individual to reduce or
prevent the harm that could be caused by the breach. Notifications should include the types
of information detailed below:
 Incident Description — Information about the incident and its timing in general terms.
The notice should not include information that would reveal specific system
vulnerabilities.
 Type of personal information involved — A description of the type of personal
information involved in the breach. Be careful not to include personal information in
the notification, to avoid possible further unauthorised disclosure.
 Response to the breach — A general account of what the agency or organisation
has done to control or reduce the harm, and proposed future steps that are planned.
 Assistance offered to affected individuals — What the agency or organisation will do
to assist individuals and what steps the individual can take to avoid or reduce the risk
of harm or to further protect themselves.
For example, whether the agency or organisation can arrange for credit monitoring
or other fraud prevention tools, or provide information on how to change
government issued identification numbers (such as a driver’s licence number).
 Other information sources — Sources of information designed to assist individuals in

protecting against identity theft or interferences with privacy.
 Agency/ Organisation contact details — Contact information of areas or personnel

within the agency or organisation that can answer questions, provide further
information or address specific privacy concerns.
Where it is decided that a third party will notify of the breach, a clear explanation
should be given as to how that third party fits into the process and who the individual
should contact if they have further questions.
 Whether breach notified to regulator or other external contact(s) — Indicate whether

the agency or organisation has notified the OAIC or other parties listed in the table at
3(d).
 Legal implications — The precise wording of the notice may have legal implications;
organisations and agencies should consider whether they should seek legal advice.
The legal implications could include secrecy obligations that apply to agencies.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 How individuals can lodge a complaint with the agency or organisation — Provide
information on internal dispute resolution processes and how the individual can make
a complaint to the agency or organisation or industry complaint handling bodies.
 How individuals can lodge a complaint with the OAIC — If the agency or organisation
is covered by the Privacy Act, explain that if individuals are not satisfied with the
response by the agency or organisation to resolve the issue, they can make a
complaint to the OAIC. The OAIC’s contact details are set out at page 38.
 How individuals can lodge a complaint with the relevant state or territory privacy or
information regulator — If the agency or organisation is not covered by the Privacy
Act, explain how and in what circumstances individuals can lodge a complaint with
the relevant regulator. See Appendix B for the contact details of State and Territory
regulators.
d) Who else should be notified?
In general, notifying the OAIC, or other authorities or regulators should not be a substitute for
notifying affected individuals. However, in some circumstances it may be appropriate to
notify these third parties:
 OAIC — The OAIC strongly encourages agencies and organisations to report serious
data breaches to the OAIC. The potential benefits of notifying the OAIC, together
with what it can and cannot do about a notification, are set out at page 37.
 The following factors should be considered in deciding whether to report a breach to
the OAIC:
o any applicable legislation that may require notification
o the type of the personal information involved and whether there is a real risk
of serious harm arising from the breach, including non-monetary losses
o whether a large number of people were affected by the breach
o whether the information was fully recovered without further disclosure
o whether the affected individuals have been notified, and
o if there is a reasonable expectation that the OAIC may receive complaints or
inquiries about the breach.
 Police — If theft or other crime is suspected. The Australian Federal Police should also
be contacted if the breach may constitute a threat to national security.
 Insurers or others — If required by contractual obligations.
 Credit card companies, financial institutions or credit reporting agencies — If their
assistance is necessary for contacting individuals or assisting with mitigating harm.
 Professional or other regulatory bodies — If professional or regulatory standards
require notification of these bodies. For example, other regulatory bodies, such as the
Australian Securities and Investments Commission, the Australian Competition and
Consumer Commission, and the Australian Communications and Media Authority
have their own requirements in the event of a breach.
 Other internal or external parties not already notified — Agencies and organisations
should consider the potential impact that the breach and notification to individuals
may have on third parties, and take action accordingly. For example, third parties
tmg.edu.au | 1300 888 TMG (1300 888 864)
may be affected if individuals cancel their credit cards, or if financial institutions issue
new cards.
Consider:
o third party contractors or other parties who may be affected

o internal business units not previously advised of the breach, (for example,
communications and media relations, senior management), or
o union or other employee representatives.
 Agencies that have a direct relationship with the information lost/stolen — Agencies
and organisations should consider whether an incident compromises Australian
Government agency identifiers such as TFNs or Medicare numbers. Notifying
agencies such as the Australian Taxation Office for TFNs or Medicare Australia for
Medicare card numbers may enable those agencies to provide appropriate
information and assistance to affected individuals, and to take steps to protect the
integrity of identifiers that may be used in identity theft or other fraud.
An example of notification of affected individuals
A bank customer, Margaret, receives mail from her bank. When she opens the envelope she
notices that correspondence intended for another customer – Diego – has been included in
the same envelope. The correspondence includes Diego’s name, address and account
details.
Margaret contacts the bank to report the incident. The bank asks that she return the mail
intended for Diego to them.
The bank then contacts Diego by phone to notify him of the breach, apologises to him, and
advises that it will be investigating the matter to determine how the incident occurred and
how to prevent it from reoccurring. The bank also offers to restore the security of Diego’s
customer information by closing his existing account and opening a new account. In
addition, the bank agrees to discuss with Diego any further action he considers should be
taken to resolve the matter to his satisfaction and provides a contact name and number that
Diego can use for any further enquiries.
The bank investigates the matter, including getting reports from the mailing house it uses to
generate and despatch customer correspondence. While the mailing house has a number
of compliance measures in place to manage the process flow, it appears that an isolated
error on one production line meant that two customer statements were included in one
envelope.
Following its assessment of the breach, the bank is satisfied that this is an isolated incident.
However, it reviews the compliance measures taken by the mailing house has in place to
ensure they are sufficient to protect customer information from unintentional disclosure
through production errors. The bank writes to Diego and informs him of the outcome of its
investigation.
tmg.edu.au | 1300 888 TMG (1300 888 864)
An example of notification of affected individuals and the OAIC
A memory stick containing the employee records of 200 employees of an Australian

Government Department goes missing. Extensive searches fail to locate the whereabouts of
the memory stick. The information contained in the employee records includes the names,
salary information, TFNs, home addresses, phone numbers, birth dates and in some cases
health information (including disability information) of current staff. The data on the memory
stick is not encrypted.
Due to the sensitivity of the unencrypted information – not only the extent and variety of the
information, but also the inclusion of health and disability information in the records – the
Department decides to notify employees of the breach. Anticipating that individuals may, at
some point, complain, it also notifies the OAIC of the breach and explains what steps it is
taking to resolve the situation.
A senior staff member emails the affected staff to notify them of the breach. In the
notification she offers staff an apology for the breach, explains what types of information
were involved, notes that the OAIC has been informed of the breach, and explains what
steps have been put in place to prevent this type of a breach occurring in the future. The
senior staff member also provides staff with details about how they can have a new TFN
issued, and informs staff that they can make a complaint to the OAIC if they are unhappy
with the steps the agency has taken.
An example of notification of affected individuals, OAIC and police
FunOnline, a popular online gaming service provider, sells access to its gaming network on a
subscription basis. FunOnline collects and holds a range of personal information from its
customers in order to create a user account and deal with subscription payments, including
names, dates of birth, email addresses, postal addresses, and credit card numbers.
During a routine security check, FunOnline discovers through the use of intrusion detection
software that the server containing its account information has been compromised, and the
account information of over 500,000 customers has been accessed without authorisation
and, most likely, copied.
FunOnline takes immediate steps to contain the breach (including temporarily shutting down
its servers) and notifies the OAIC. Based on its belief that criminal activity has been involved,
FunOnline also contacts the police.
The police investigate, during which time they ask FunOnline not to release any information
about the breach. FunOnline uses this period to engage a technology security firm to
enhance the security of its accounts systems.
As soon as the police are satisfied it will not compromise their investigation, FunOnline notifies
the affected customers. FunOnline explains exactly what happened and when, that the
police have been investigating, and that the OAIC has been notified. FunOnline also
tmg.edu.au | 1300 888 TMG (1300 888 864)
suggests that affected customers monitor their credit card accounts and contact their
financial institution if they have any concerns.
An example of no notification
In contravention of policy, a staff member at an Australian Government Department takes a

memory stick out of the office so that he can work on some files at home. At some point
between leaving work and arriving at home, the staff member loses the memory stick. He
reports it missing the next day.
Despite the assistance of the transport authority, the Department is unable to locate the
memory stick. The Department conducts a preliminary assessment of the breach, then
evaluates the risks associated with the loss of the memory stick.
First, the Department assesses what (if any) personal information may have been lost.. While
the memory stick did not contain client records, it did contain the names, phone numbers
and business email addresses of about 120 external stakeholders involved in a project lead
by the Department, along with email correspondence from these stakeholders.
Further evaluation reveals that data held on the stick is protected by high level encryption
technology. The Department consults with its IT team to confirm that the encryption on the
memory stick is adequately secure and, following confirmation by that team, decides that
notification of individuals whose personal information was held on the memory stick is
unnecessary.
In contravention of policy, a staff member at an Australian Government Department takes a

memory stick out of the office so that he can work on some files at home. At some point
between leaving work and arriving at home, the staff member loses the memory stick. He
reports it missing the next day.
Despite the assistance of the transport authority, the Department is unable to locate the
memory stick. The Department conducts a preliminary assessment of the breach, then
evaluates the risks associated with the loss of the memory stick.
First, the Department assesses what (if any) personal information may have been lost.. While
the memory stick did not contain client records, it did contain the names, phone numbers
and business email addresses of about 120 external stakeholders involved in a project lead
by the Department, along with email correspondence from these stakeholders.
Further evaluation reveals that data held on the stick is protected by high level encryption
technology. The Department consults with its IT team to confirm that the encryption on the
memory stick is adequately secure and, following confirmation by that team, decides that
notification of individuals whose personal information was held on the memory stick is
unnecessary.
tmg.edu.au | 1300 888 TMG (1300 888 864)
A pathologist receives a phone call from a GP, Dr Jones, with whom he has a professional
relationship. Dr Jones advises the pathologist that she has just received a fax from the
pathologist’s office disclosing test results for an individual that is not her patient. When the
pathologist checks his records, he discovers that the test results were intended for a different
GP.
The pathologist asks Dr Jones to destroy the test results and considers whether notification of
the patient is warranted.
The pathologist recognises that Dr Jones is bound by ethical duties, and is familiar with
principles of confidentiality and privacy. Accordingly, the pathologist is confident that Dr
Jones can be relied upon not to mishandle the information contained in the test results and
the disclosure is unlikely to pose a serious risk to the privacy of the patient.
The pathologist decides not to notify the patient, but he reviews his practices to avoid a
similar breach occurring in the future. The pathologist ensures that administrative staff are
trained to exercise care in checking that fax numbers are accurate. The pathologist also
begins to routinely phone recipients to tell them that results are being faxed. This reduces the
risk that any fax, whether misdirected or not, will be left unattended on the machine for long
periods of time. It also allows the intended recipient to let the sender know if it a fax not
received.
Step 4: Prevent future breaches
Once the immediate steps are taken to mitigate the risks associated with the breach,
agencies and organisations need to take the time to investigate the cause and consider
whether to review the existing prevention plan or, if there is no plan in place, develop one.
A prevention plan should suggest actions that are proportionate to the significance of the
breach, and whether it was a systemic breach or an isolated event.
This plan may include:
 a security audit of both physical and technical security

 a review of policies and procedures and any changes to reflect the lessons learned
from the investigation, and regular reviews after that (for example, security, record
retention and collection policies)
 a review of employee selection and training practices, and
 a review of service delivery partners (for example, offsite data storage providers).
The plan may include a requirement for an audit at the end of the process to ensure that the
prevention plan has been fully implemented.
Suggested preparations for responding to a data breach include the following:

tmg.edu.au | 1300 888 TMG (1300 888 864)
 Develop a breach response plan — While the aim should be to prevent breaches,
having a breach response plan may assist in ensuring a quick response to breaches,
and greater potential for mitigating harm.
The plan could set out contact details for appropriate staff to be notified, clarify the
roles and responsibilities of staff, and document processes which will assist the agency
or organisation to contain breaches, coordinate investigations and breach
notifications, and cooperate with external investigations.
 Establish a breach response team — Depending on the size of the agency or

organisation, consider establishing a management team responsible for responding
to personal information breaches. The team could include representatives from
relevant areas that may be needed to investigate an incident, conduct risk
assessments and make appropriate decisions (for example, privacy, senior
management, IT, public affairs, legal).
The team could convene periodically to review the breach response plan, discuss
new risks and practices, or consider incidents that have occurred in other agencies or
organisations.
It may also be helpful to conduct ‘scenario’ training with team members to allow
them to develop a feel for an actual breach response. Key issues to test in such
training would be identifying when notification is an appropriate response, and the
timing of that notification.
 Identify relevant service providers — Consider researching and identifying external

service providers that could assist in the event of a data breach, such as forensics
firms, public relations firms, call center providers and notification delivery services. The
contact details of the service providers could be set out in the breach response plan.
This could save time and assist in responding efficiently and effectively to a data
breach.
 Enhance internal communication and training — Ensure staff have been trained to
respond to data breaches effectively, and are aware of the relevant policies and
procedures. Staff should understand how to identify and report a potential data
breach to the appropriate manager(s).
 Enhance transparency — Include information in the agency or organisation’s privacy
policy about how it responds to breaches. This could include letting individuals know
when and how they are likely to be notified in the event of a breach, and whether
the agency or organisation would ask them to verify any contact details or other
information.
This would make clear to individuals how their personal contact information is used in
the event of a breach, and may also assist individuals to avoid ‘phishing’ scam emails
involving fake breach notifications and requests that recipients verify their account
details, passwords and other personal information.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Tips for preventing future breaches
Some of the measures that have resulted from real-life data breaches include:
 the creation of a senior position in the agency or organisation with specific

responsibility for data security
 the institution of a ban on bulk transfers of data onto removable media without
adequate security protection (such as encryption)
 disabling the download function on computers in use across the agency or
organisation, to prevent the download of data onto removable media
 the institution of a ban on the removal of unencrypted laptops and other portable
devices from government buildings
 the institution of a policy requiring the erasing of hard disk drives and other digital
storage media (including digital storage integrated in other devices such as
multifunction printers or photocopiers) prior to being disposed of or returning to the
equipment lessor
 the use of secure couriers and appropriate tamper proof packaging when
transporting bulk data, and
 the upgrading of passwords (for example, an increase from 6 to 8 characters,
including numbers and punctuation), and the institution of a policy requiring
passwords to be changed every 8 weeks.
Technological advances allow increasingly larger amounts of information to be stored on

increasingly smaller devices. This creates a greater risk of data breaches due to the size and
portability of these devices, which can be lost or misplaced more easily when taken outside
of the office. There is also a risk of theft because of the value of the devices themselves
(regardless of the information they contain).
Preventative steps that agencies and organisations can take include conducting risk
assessments to determine:
 whether and in what circumstances (and by which staff), personal information is

permitted to be removed from the office, whether it is removed in electronic form on
DVDs, USB storage devices such as memory sticks, portable computing devices such
as laptops, or in paper files, and
 whether their stored data, both in the office and when removed from the office,
requires security measures such as encryption and password protection.
Responding to a large scale data breach: An illustration of how to

work through the Four Key Steps
A health insurer discovers that a backup tape containing customer details and other data
has been lost. The information on the tape was not encrypted. The insurer routinely creates
two copies of each backup tape. One tape is stored on site; the other tape is stored securely
tmg.edu.au | 1300 888 TMG (1300 888 864)
off-site. The lost backup tape was the copy stored on-site and included data collected
during the previous month.
Step 1 — Containing the breach and the preliminary assessment
The Chief Executive Officer nominates the Risk & Compliance Manager to lead an
investigation. The Risk Manager’s initial assessment suggests that the tapes were lost when
the insurer’s IT department moved some records between floors.
The Risk Manager interviews the staff involved in moving the records, reviews the relocation
plan and arranges for the building to be searched. Despite these efforts, the tape cannot be
found.
The Risk Manager moves on to assessing the breach. She thinks that the breach was most
likely the result of poor practices and sloppy handling. However, while there is no evidence
that the tape was stolen, theft cannot be ruled out. The type of information that has been
lost and how it could be used is an important part of the risk assessment.
Step 2 — Evaluate the risks associated with the breach
The evaluation shows that the information on the tapes falls into 3 main groups:
Group 1 — Enquiry information
 Type of information — Enquiry information collected via the website to provide

quotes. Only included state, date of birth and gender and was retained for statistical
marketing purposes.
 Identity apparent or ascertainable? — No. The information is aggregated statistical
data only.
 Sensitivity — None.
 How could the information be used? — The information is likely to be of little or no use
other than for statistical purposes
 Source — Probably unintentional and accidental. But theft is also a possibility. As the
source of the breach is unclear, and given the sensitivity of much of the information,
the insurer decides to assume a worst case scenario.
 Severity — The information was not encrypted or recovered. The large number of
records involved and the sensitivity of the many of the records (health and financial
information, as well as identifying information), make this a serious breach.
 A real risk of serious harm? — No.
 Current contact details held? — No.
Group 2 — Application information
 Type of information — Application information, including full name, address, contact

details, and date of birth. Also includes Medicare card number, and credit card
details.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Identity apparent or ascertainable? — Yes.

 Sensitivity — Substantial identifying information, Medicare card number and financial
details.
 How could the information be used? — The information could be used for identity
theft and financial fraud. There is a lesser possibility that it could be used to attempt
fraud against the Medicare and PBS systems.
 A real risk of serious harm? — Yes. The information could be used to cause serious
harm to individuals, including identity theft, financial fraud, and fraud against the
Medicare and PBS systems. Possibly health fraud.
 Current contact details held? — Yes, from current member list and external sources.
Group 3 — Claims information
 Type of information — Claims information, including full name, member number,

contact details, and clinical information about the treatment being claimed.
 Identity apparent or ascertainable? — Yes.
 Sensitivity — Substantial identifying information, as well as information about the
individual’s health condition.
 How could the information be used? — The information could be used for identity
theft, as well as being potentially embarrassing or stigmatising to the individual.
 A real risk of serious harm? — Yes. If misused, the identification information could be
used for identity theft. Serious harm could also arise from misuse of the health
information, including stigma, embarrassment, discrimination or disadvantage or, in
extreme cases, blackmail.
 Current contact details held? — Yes, from current member list and external sources.
The evaluation shows that there is a real risk of serious harm for Group 2 and 3 individuals,
and that the information in Group 1 is not personal information.
Step 3 – Notification
The evaluation indicates that Group 2 and 3 individuals should be notified about the breach,
and that there is a real risk of serious harm to their interests. If notified, individuals could take
steps to mitigate the risks of identity theft and financial fraud. This could include changing
tmg.edu.au | 1300 888 TMG (1300 888 864)
credit card details or monitoring their credit reports. While there may be limited steps that
can be taken to mitigate the risks of their health information being mishandled, individuals
should still be informed given the heightened sensitivities of this information.
The Risk Manager also considered whether notification would cause harm by leading to
unfounded concern or alarm.
Taking all these factors and the evaluation into account, it is decided that individuals in
Groups 2 and 3 should be notified. Separate letters are drawn up for each group, outlining
the general types of information that are affected.
The Risk Manager also arranges for the notification letters to include:
 a general description of the type of information that has been lost for each group
 what individuals can do to mitigate the harm caused by the breach, and
 who they can call to get further information or assistance.
For example, the notification to individuals in Group 2 tells them that the information they
provided on their application form, including their Medicare number and credit card details,
may have been compromised. If an individual is concerned about either, they are advised
to contact Medicare Australia or their financial institution so as to change their registration
and account details. Group 3 individuals are told that a record containing their claims
information has been lost, including the clinical details held on their file.
Both letters explain that there is no evidence of theft, and that the company is notifying the
individuals as a precautionary measure only.
The notifications also include contact details for the insurer’s customer care area and the
OAIC, and suggest that individuals should check their credit card account statements and
credit reports for any unusual activity.
The Risk Manager also notes that some claimants had an authorised representative acting
for them. These records are separately assessed to determine whether notification should be
made to the authorised representative rather than the member.
Staff in the insurer’s customer care area are briefed about the breach and given instructions
about how to help customers responding to a notification.
Given the large number of individuals affected, and the sensitive nature of the information,
the insurer notifies the OAIC. The insurer explains what steps it has taken to address the
breach. It also advises the OAIC of the contact details for the insurer’s customer care area,
so that customers contacting the OAIC can be redirected to the insurer if appropriate.
Step 4 – Preventing Future Breaches
tmg.edu.au | 1300 888 TMG (1300 888 864)
Once immediate steps have been taken to respond to the breach, the Chief Information
Officer (CIO) carries out an audit of the security policies for storage and transfer of backup
tapes and reviews the access of staff in the area. The CIO also makes some amendments to
the compliance program to ensure non-compliance with IT Security policies will be detected
and reported in the future.
Reporting a data breach to the Office of the Australian Information

Commissioner
Agencies and organisations are strongly encouraged to notify the OAIC of a data breach
where the circumstances indicate that it is appropriate to do so, as set out in Step 3(d). The
potential benefits of notifying the OAIC of a data breach may include the following:
 An agency or organisation’s decision to notify the OAIC on its own initiative is likely to
be viewed by the public as a positive action. It demonstrates to clients and the
public that the agency or organisation views the protection of personal information
as an important and serious matter, and may therefore enhance client/public
confidence in the agency or organisation.
 It can assist the OAIC in responding to inquiries made by the public and managing
any complaints that may be received as a result of the breach. If the agency or
organisation provides the OAIC with details of the matter and any action taken to
address it, and prevents future occurrences, then, based on that information, any
complaints received may be able to be dealt with more quickly. In those
circumstances, consideration will need to be given to whether an individual
complainant can demonstrate that they have suffered loss or damage, and whether
some additional resolution is required. Alternatively, the OAIC may consider that the
steps taken have adequately dealt with the matter.
Note: Reporting a breach does not preclude the OAIC from receiving complaints and
conducting an investigation of the incident (whether in response to a complaint or on the
Commissioner’s initiative).
If the agency or organisation decides to report a data breach to the OAIC, the following
provides an indication of what the OAIC can and cannot do:
What the OAIC can do
 Provide general information about obligations under the Privacy Act, factors to
consider in responding to a data breach, and steps to take to prevent similar future
incidents.
 Respond to community enquiries about the breach and explain possible steps that
individuals can take to protect their personal information.
What the OAIC cannot do
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Provide detailed advice about how to respond to a breach, or approve a particular

proposed course of action. Agencies and organisations will need to seek their own
legal or other specialist advice.
 Agree not to investigate (either using the Commissioner’s power to investigate on
their own initiative, or if a complaint is made to the OAIC) if the OAIC is notified of a
breach.
When the OAIC receives a complaint about an alleged breach of the Act, in most cases, the
OAIC must investigate. As set out above, the OAIC may also investigate an act or practice in
the absence of a complaint on the Commissioner’s initiative. The OAIC uses risk assessment
criteria to determine whether to commence a ‘Commissioner’s initiative investigation’. Those
criteria include:
 whether a large number of people have been, or are likely to be affected, and the
consequences for those individuals
 the sensitivity of the personal information involved
 the progress of an agency or organisation’s own investigation into the matter
 the likelihood that the acts or practices involve systemic or widespread interferences
with privacy
 what actions have been taken to minimise the harm to individuals arising from the
breach, such as notifying them and/or offering to re-secure their information, and
 whether another body, such as the police, is investigating.
These factors are similar to those included in the risk assessment criteria for responding to a
data breach.
What to put in a notification to the OAIC
Any notice provided to the OAIC should contain similar content to that provided to
individuals (see page 24). It should not include personal information about the affected
individuals. It may be appropriate to include:
 a description of the breach

 the type of personal information involved in the breach
 what response the agency or organisation has made to the breach
 what assistance has been offered to affected individuals
 the name and contact details of the appropriate contact person, and
 whether the breach has been notified to other external contact(s).
How to contact the OAIC
Telephone
1300 363 992 (local call cost, but calls from mobile and payphones may incur higher charges)
TTY
1800 620 241 (this number is dedicated for the hearing impaired only, no voice calls)
tmg.edu.au | 1300 888 TMG (1300 888 864)
Post:
GPO Box 5218
Sydney NSW 2001
Facsimile
+61 2 9284 9666
Email
enquiries@oaic.gov.au
Website
www.oaic.gov.au
Data breach response process
Maintain information security—APP 11
Protect information from misuse, interference and loss, and from unauthorised access,
modification or disclosure.
To comply with their obligations under the APPs, agencies and organisations should consider:
 the sensitivity of the personal information
 the harm likely to flow from a security breach
 developing a compliance and monitoring plan, and
 regularly reviewing their information security measures.
Data breach occurs
Personal information is lost or subjected to unauthorised access, modification, use or

disclosure, or other misuse or interference.
Key steps in responding to a data breach
Step 1
Contain the breach and make a preliminary assessment
 Take immediate steps to contain breach
 Designate person/team to coordinate response
Step 2
Evaluate the risks for individuals associated with the breach
 Consider what personal information is involved
 Determine whether the context of the information is important
 Establish the cause and extent of the breach
 Identify what is the risk of harm
Step 3
tmg.edu.au | 1300 888 TMG (1300 888 864)
Consider breach notification

 Risk analysis on a case-by-case basis
 Not all breaches necessarily warrant notification
SHOULD AFFECTED INDIVIDUALS BE NOTIFIED?
Where there is a real risk of serious harm, notification may enable individuals to take steps to
avoid or mitigate harm. Consider:
 Legal/contractual obligations to notify
 Risk of harm to individuals (identity crime, physical harm, humiliation, damage to
reputation, loss of business or employment opportunities
Process of Notification
 When? - as soon as possible
 How? - direct contact preferred (mail/phone)
 Who? - entity with the direct relationship with the affected individual
 What? - description of breach, type of personal information involved, steps to help
mitigate, contact details for information and assistance.
SHOULD OTHERS BE NOTIFIED?
 Office of the Australian Information Commissioner

 Police/Law Enforcement
 Professional or Regulatory Bodies
 Other agencies or organisations affected by the breach or contractually required to
notify
Step 4
Review the incident and take action to prevent future breaches
 Fully investigate the cause of the breach
 Consider developing a prevention plan
 Option of audit to ensure plan implemented
 Update security/ response plan
 Make appropriate changes to policies and procedures
 Revise staff training practices
Appendix A – APP 11
Australian Privacy Principle 11 – security of personal information
11.1 If an APP entity holds personal information, the entity must take such steps as are
reasonable in the circumstances to protect the information:
tmg.edu.au | 1300 888 TMG (1300 888 864)
a. from misuse, interference and loss; and

b. from unauthorised access, modification or disclosure.
11.2 If:
a. an APP entity holds personal information about an individual; and

b. the entity no longer needs the information for any purpose for which the information
may be used or disclosed by the entity under this Schedule; and
c. the information is not contained in a Commonwealth record; and
d. the entity is not required by or under an Australian law, or a court/tribunal order, to
retain the information;
the entity must take such steps as are reasonable in the circumstances to destroy the
information or to ensure that the information is de-identified.
Appendix B – Contact list: State and territory privacy contacts
Information and Privacy Commission New South Wales
Telephone
(02) 8019 1600
Post
GPO Box 7011
Sydney NSW 2001
Facsimile
(02) 8114 3755
Email
privacyinfo@privacy.nsw.gov.au
Website
www.ipc.nsw.gov.au
Privacy Victoria
Telephone
1300 666 444 (Within Australia: local call cost, but calls from mobile and payphones may incur
higher charges)
+61 3 8619 8719 (From outside Australia)
Post
GPO Box 5057
Melbourne Victoria 3001
Australia
tmg.edu.au | 1300 888 TMG (1300 888 864)
Facsimile
Local call within Australia: 1300 666 445 (local call cost, but calls from mobile and payphones
may incur higher charges)
From outside Australia: +61 3 8619 8700
Email
enquiries@privacy.vic.gov.au
Website
www.privacy.vic.gov.au
Office of the Information Commissioner, Queensland
Telephone
(07) 3234 7373
Post
PO Box 10143
Adelaide Street
BRISBANE QLD 4000
Facsimile
(07) 3405 1122
Email
administration@oic.qld.gov.au
Website
www.oic.qld.gov.au
State Records, South Australia
Telephone
(08) 8204 8786
Post
GPO Box 2343
Adelaide SA 5001
Facsimile
(08) 8204 8777
Email
privacy@sa.gov.au
Website
www.archives.sa.gov.au/privacy/index.html
Ombudsman: Western Australia

tmg.edu.au | 1300 888 TMG (1300 888 864)
Telephone
(08) 9220 7555 (Western Australia)
1800 117 000 (toll free for country and interstate callers)
Post
Ombudsman Western Australia
PO Box Z5386
St Georges Terrace
PERTH WA 6831
Facsimile
(08) 9325 1107
Email
mail@ombudsman.wa.gov.au
Website
www.ombudsman.wa.gov.au
Ombudsman: Tasmania
Telephone
1800 001 170 (Tasmania – toll free)
1300 766 725 (Within Australia: local call cost, but calls from mobile and payphones may incur
higher charges)
Post
GPO Box 960
HOBART 7001
Facsimile
(03) 6233 8966
Email
ombudsman@ombudsman.tas.gov.au
Website
www.ombudsman.tas.gov.au
Office of the Information Commissioner, Northern Territory
Telephone
1800 005 610 (Northern Territory – toll free)
(08) 8999 1500
Post
GPO Box 3750
DARWIN NT 0801
Facsimile
(08) 8981 3812
tmg.edu.au | 1300 888 TMG (1300 888 864)
Email
infocomm@nt.gov.au
Website
www.infocomm.nt.gov.au
Australian Capital Territory
ACT Government agencies are subject to the Territory Privacy Principles (TPPs) in the
Information Privacy Act 2014 (ACT). The TPPs came into effect on 1 September 2014. The
OAIC is undertaking some of the functions of the ACT’s information privacy commissioner,
including receiving voluntary data breach notifications.
The OAIC can be contacted at:
Telephone
1300 363 992
Email
enquiries@oaic.gov.au
Website
www.oaic.gov.au
Forensics and evidence collection
The earliest stage of any investigation is forensics. Having third-party forensics assistance on
hand, or having those skillsets internally within the company is essential. Similar to trauma
response, or crime scene investigations, this stage is the most critical. Preparedness,
training and a well thought-of plan can contain the damage and determine the scope of
the breach. The work by forensics teams can limit the damage before evidence is lost or
compromised, and collect essential data required for the hard work of analysis. As
information about the breach is collected, law enforcement agencies may need to be
notified within a specific timeframe.
Forensics teams no longer serve just in post-incident response. As part of a continuous

monitoring security framework, forensics teams can proactively look for possible risks in the
network.
Security Monitoring and Attack Detection
The number of high profile cases of malicious software threats and incidents that have
dominated media reporting for years has served to raise awareness and spur most businesses
to invest time and resources into defending against this prevalent security issue. However, the
greatest threat to business infrastructure may not be in the form of an attack from the
outside, such as from a virus, but may well reside within the internal network itself.
Attacks launched from inside a business network have a very high potential for damage,
especially if performed by personnel who hold trusted positions and who have access to all
tmg.edu.au | 1300 888 TMG (1300 888 864)
the network resources within a company. When the risks posed by both external and internal
threats are carefully examined, many businesses decide to research systems that can
monitor networks and detect attacks wherever they may originate.
Security monitoring practices are not open to consideration for businesses that are governed
by regulatory restrictions—they are a requirement. These same regulations may even control
how long and in what way security monitoring records must be kept and archived. The ever-
changing regulatory environment and continually increasing demands placed on regulated
businesses to secure their networks, track the identification of people who access resources,
and protect private information places greater demands on businesses around the world to
institute effective security monitoring solutions.
There are several reasons why security monitoring and attack detection should also be an
important issue to midsize businesses that do not need to comply with any regulatory
requirements. These reasons include the consequences any business could face if an attack
on that business’s infrastructure were to succeed. Not only could business operations be
disrupted, resulting in productivity losses and even monetary loss. A business could even
suffer from a loss of reputation, which often takes longer to recover from than any other loss
incurred due to an attack.
The security log facilities available in Microsoft® Windows® can be the starting point for a
security monitoring solution. However, security logs alone do not provide enough information
to plan responses to incidents. These security logs can be combined with other technologies
that collect and query that information to form the central part of a comprehensive security
monitoring and attack detection solution.
The primary goal of a security monitoring and attack detection system is to help identify
suspicious events on a network that may indicate malicious activity or procedural errors. This
paper will describe how to develop a plan to help address the need for such a system on
Windows–based networks. It will also provide instructions about how to implement, manage,
and validate such a system.
Overview
This paper consists of four main sections that focus on essential concepts and issues required
to design and implement an effective security monitoring and attack detection solution. The
first section is the "Introduction," which you are currently reading. The remaining sections are:
Definition
This section provides information that is useful for understanding the processes involved with
the generation and application of the solution presented in this paper.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Midsize Business Challenge
This section describes many of the common challenges faced by midsize businesses in
relation to a security monitoring and attack detection system.
Solutions
This section provides detailed information about how to develop, implement, manage, and
validate the solution presented in this paper, and is further divided into two subsections.
"Developing the Solution" discusses prerequisite activities and creates planning steps.
"Deploying and Managing the Solution" provides information that will assist efforts to deploy,
manage, and validate a security monitoring and attack detection system.
Who Should Read This Paper
This paper addresses privacy and security concerns for midsize businesses, especially those
that require identity protection and controls over data access because of regulatory
constraints. Accordingly, the intended audience for this paper ranges from technical
managers and decision makers to IT professionals and technology implementers who are
responsible for the planning, deployment, operation, or especially the security of a
company’s network.
Although portions of this paper should be useful to most technical decision makers, readers
should have familiarity with the security and risk issues in their own network environment and
have an understanding of Windows event logging services concepts to apply all of the
subject matter presented within.
Definition
This paper uses the Microsoft Operations Framework (MOF) Process Model in addition to the
MOF Security Administration and Incident Management service management functions
(SMFs).
In particular, the solution presented in this paper recommends use of a continual process
approach instead of a linear deployment approach to security monitoring and attack
detection. Specifically, this solution should involve the steps shown in the following figure:
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 1. Applying MOF
A security monitoring solution is actually a continual process of planning, implementing,

managing, and testing, because that is the very nature of security monitoring. Because the
threats to business networks are always changing, the system that monitors the security in a
business network must also change.
Application of this process to security monitoring fits with the Security Management SMF,
which seeks to accomplish the following:
 Assess business exposure and identify which assets to secure.

 Identify ways to reduce risk to acceptable levels.
 Design a plan to mitigate security risks.
 Monitor the efficiency of security mechanisms.
 Re-evaluate effectiveness and security requirements regularly.
Risk management is the process of determining an organization’s level of acceptable risk,

assessing current risks, finding ways to reach that acceptable risk level, and managing risk.
Although this paper deals with some risk management concepts and some steps that will
assist with risk assessment, an in-depth discussion of risk management is a subject in its own
right and deserves its own dedicated focus.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Midsize Business Challenge
Midsize businesses contend with numerous challenges when attempting to construct an

effective security monitoring system and institute policies that support that effort. These
challenges include:
 Understanding the need and the benefits of securing the entire network environment
from internal and external threats.
 Designing an effective security monitoring and attack detection system that includes
methods that detect and prevent efforts to work around established policies.
 Implementing comprehensive and effective monitoring polices that not only detect
attacks but also provide an overall picture of an environment’s security level for
remediation efforts.
 Maintaining policies and processes that efficiently correlate security reports with
established policies to ease administrative efforts in detecting suspicious activities.
 Implementing and enforcing efficient business practices and policies that support
security monitoring efforts while balancing business needs.
 Determining acceptable risk thresholds to balance usability and risk mitigation.
Solutions
As discussed earlier, a comprehensive security monitoring process not only assists with the
need to perform forensic analysis but can also be a proactive security measure capable of
supplying information prior to, during, and after an attack. By providing a centralized
repository for security reports, an attack can be detected during the probing phase, as the
attack occurs, or immediately following the attack to supply responders with the information
they need to react to an attack effectively, which can reduce the impact of intrusion
attempts.
Understanding the range of benefits that can be gained by implementing security

monitoring is important during the conceptualization phase of development so that the
design and policies can take advantage of all these benefits. Some of the advantages that
security monitoring provides include:
 Identification and remediation of systems that do not comply with security or update
policies to reduce the vulnerability profile of a midsize business.
 Produce information that can alert staff to intrusion attempts before an actual attack
occurs by identifying unusual activity.
 Create security audit information and protect it to improve forensic analysis, which
not only meets regulatory requirements but also reduces the impact of any attack
that might occur.
 Assist with security level analysis efforts to improve overall security.
 Detect activities that occur outside of established business processes, whether
intentional or accidental.
 Assist with the identification of unmanaged systems on a network or the remediation
of vulnerable devices.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Developing the Solution
Security is an important issue for many businesses. Although most companies put a
reasonable degree of resources into physical security by using methods ranging from the
common door lock to those as elaborate as card-based access controls, many still do not
sufficiently address the security of the data that they have become increasingly reliant upon.
When data security and monitoring issues do get attention, companies commonly focus
data security efforts at the perimeter with firewalls. However, reliance on this approach
leaves other sources of attack quite vulnerable. According to the 2004 E-Crime Watch
Survey, published by the United States Secret Service and the CERT Coordination Center at
www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf, 29 percent of identified
attackers were actually from internal sources, including current employees, contractors, and
prior employees. When this information is considered, it becomes apparent that a
multilayered security approach should be made to safeguard against internal threats in
addition to threats that originate from the outside.
One method that is used to address both internal and external threats from a reactive
security stance is to implement a security audit logging process. All versions of Microsoft
Windows, from Microsoft Windows NT® 3.1 to present versions, use a built in security event log
file to record security events. However, although this built-in functionality alone can be useful
when performing a forensics investigation in response to an intrusion that has already
occurred, it would be difficult to use this functionality by itself in a proactive manner to
identify precursory attack activity or alert the proper personnel to intrusion attempts while
they occur.
As mentioned, security logs are often used reactively during a forensic analysis of a security
incident after it has occurred. However, in the 2005 Insider Threat Study, published by the US
Secret Service and CERT at www.cert.org/archive/pdf/insidercross051105.pdf, an analysis of
key findings found that security logging and monitoring can be used for proactive detection
rather than solely for reactive forensics. Also, most attackers, internal and external, will
attempt to cover their tracks by altering logs; therefore, steps should be taken to protect
system logs. It turns out that security logs and other methods used to monitor and detect
attacks can be a vital tool in the network security arsenal if used and secured correctly.
Although system security logs are the focus of this document, they only form the core of
security monitoring and attack detection methodology. Other issues that should be
considered include how to identify and remediate any systems that are not compliant with
established security policies or have not implemented currently recommended vulnerability
patches. Internal network infrastructure should also be monitored, including switch port
security reporting (to prevent unmanaged systems from gaining access to the network) and
wireless security monitoring (to prevent unauthorized connections or packet sniffing). Many
of these monitoring topics are beyond the scope of this document, but they deserve
attention in any well-rounded security monitoring solution.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Implementing Security Monitoring
The following subsections provide information about various implementation considerations

with regard to a security monitoring system.
Windows Security Event Logging
All versions of Microsoft Windows, from Microsoft Windows NT version 3.1 and later, are able
to record security events using built-in log file functionality. In a Microsoft Windows–based
environment, this functionality provides the basis for security monitoring. However, without
additional utilities or tools to correlate this information it becomes difficult to use proactively
because it is dispersed.
Figure 2. Event Viewer Security log
The Security event log (shown in the preceding figure) uses a custom file format to record
security monitoring data. Although it is possible to read portions of these records with a text
editor, a suitable program such as Event Viewer is necessary to see all of the information
recorded in these logs. The Security event log file (SecEvent.evt) resides in the
%systemroot%\System32\config directory. Access to event logs is always governed through
the Event Log service, and the Event Log service enforces access controls to each log. The
default permissions on the security log are very strict compared to other logs on the system;
only Administrators have access to the security log by default.
There are two types of events that are recorded in the Security event log: success audits and
failure audits. Success Audit events indicate an operation that a user, service, or program
performed has completed successfully. Failure Audit events detail operations that have not
completed successfully. For example, failed user logon attempts would be examples of
Failure Audit events and would be recorded in the Security event log if logon audits were
enabled.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The Audit Policy Group Policy settings, located under Computer Configuration\Windows
Settings\Local Policies, control which events create entries in the security logs. Audit Policy
settings can be configured either through the Local Security Settings console or at the site,
domain, or organizational unit (OU) level through Group Policy with Active Directory.
Interpreting Audit Events
Audit events are discussed in much greater detail throughout this paper, so a basic
understanding of audit event structure and the information contained in audit events is
important.
Figure 3. Event Properties Window
Events are made up of three basic parts: the event header, the event description and a
binary data section.
Event headers consist of the following fields:
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 1. The Event Header
Field Definition
Date The date the event occurred
Time The local time when the event occurred
Type A classification of the event severity or type. For security audit events these
are either of type Success Audit or Failure Audit.
Source The application that logged the event. This can either be an actual program,
like SQL Server, a driver name, or a component of the system, like Security for
instance.
Category The event source’s classification of the event. This is pertinent in security audit
logs as it corresponds to an event type that can be configured in Group
Policy.
Event ID This code identifies the specific type of event. In the figure above the Event ID
is listed as 680, this Event ID indicates that a set of credentials was passed to
the authentication system by a local process, remote process, or user.
User The username of the user on whose behalf the event occurred. This name is
the client ID if it was caused by a process or the primary ID if impersonation s
not taking place. In security events both the primary and impersonation
information will be displayed if possible and applicable.
Computer The name of the computer where the event occurred.
The event description field actually contains a variety of information that can vary from
event to event. For example, in the Event 680 sample shown in the preceding figure, the Error
Code: field specifies 0xC000006A, which means an incorrect password was supplied. Each
event type will display event specific information in this field.
Windows Security Event Log events do not use the binary data section of the event record.
Technical Issues
To implement a security monitoring and attack detection system based on Windows security
event logging, the following issues must be addressed:
 Manage high volumes of security events. To cope with the high volume of security
events that will be generated careful attention will need to be given to which specific
security audit events should be tracked. These considerations are particularly
important when dealing with file and object access auditing, both of which can
generate very large quantities of data.
 Store and manage event information in a central repository. Storage of event
information can involve terabytes of data depending on the configuration of a
monitoring system. This is most important when considering forensic analysis needs
and is covered in detail under that section.
 Identify and respond to attack signatures. In order to identify patterns of activity
which can signal an attack a reviewer or configured query must be able to pick out
the events associated with such activity imbedded within the information provided.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Once a suspicious activity is identified there should be a mechanism in place that

prompts a timely and appropriate response.
 Restrict staff from circumventing security audit controls. Personnel with elevated
privileges on a network, especially administrators, should be compartmentalized in
order to restrict access to audit information so that only security specialists are
responsible for the administration of audit systems.
Solution Planning
The following activities should be completed before implementing a security monitoring and
attack detection system:
 Review current security audit settings.

 Assess administrator roles and normal user tasks.
 Review business policies and procedures.
 Identify vulnerable systems.
 List high-value assets.
 Identify sensitive or suspicious accounts.
 List authorized programs.
For more information regarding storage requirements, see the "Implement Forensic Analysis"
section later in this paper.
Review Current Security Audit Settings
Businesses should review their current security auditing and Security log file settings to provide
a baseline for changes recommended in this paper. Such a review should be conducted
regularly after implementing a solution and will need to obtain the following information:
 Current effective security audit settings.

 Level to which these settings apply (local computer, site, domain, or OU).
 Current log file settings (size limits and behavior when maximum size reached).
 Additional security audit settings that may apply (for example, audit the use of
backup and restore privileges).
Information in "Appendix B: Implementing Group Policy Settings” at the end of this paper can
be used to assist with the identification of which settings to record.
Assess Administrator Roles and Normal User Tasks
A key element to the implementation of an effective security monitoring solution is to ensure

that administrator account holders are known and their roles and responsibilities are
understood. For example, most businesses include administrators in the Domain Admins
group so they can create new user accounts in the domain. However, business policies may
specify that only an installed provisioning system is permitted to create new accounts. In
tmg.edu.au | 1300 888 TMG (1300 888 864)
such a situation, an account creation event initiated by an administrator account would

prompt an immediate investigation.
An assessment of user account tasks is usually much simpler because such accounts typically
have significantly less access to network resources than administrator accounts do. For
example, since normal users usually have no need to access the file system on computers
residing in the perimeter of a network, there is little need to monitor such servers for normal
user activity.
Review Business Policies and Procedures
A review of business processes and procedures corresponds closely to, but is not limited to,
an assessment of administrator roles and responsibilities. Important components of such a
review would include an examination of the user creation process and the change control
process, for example. Examination of the mechanisms that provide an approval process and
audit trail for all events that occur on a network is vital to provide a correlation to what would
be authorized audit events and what may be an intrusion attempt.
Identify Vulnerable Systems
Vulnerable systems are the computers and devices on a network that an external attacker is
most likely to probe and launch access attempts against before they try any other
approach. Typically, these computers reside in the perimeter of a network, but internal
devices can also be vulnerable to attack and should not be completely ignored.
A comprehensive review of vulnerable systems should ensure the following:
 All relevant security updates and service packs have been applied.
 Unnecessary services and user accounts have been disabled.
 Services are configured to run under Local Service or Network Service accounts when
possible.
 Services that require user account credentials are checked to ensure they require
that level of access, especially when such accounts have administrator privileges.
 High-security policy templates have been applied.
Note This review process should not be limited to vulnerable computers residing on the
perimeter. A good security practice would apply these checks to all computers on a
network.
List High Value Assets
Most businesses are likely to have already identified the high-value assets that reside in their
networks, but they might not have formalized this information as a part of an organizational
policy by documenting and detailing the protections in place for each asset. For example, a
company might use access control lists (ACLs) and encryption to store sensitive financial
records securely on NTFS file system partitions. However, an organizational policy should
tmg.edu.au | 1300 888 TMG (1300 888 864)
identify such records as protected files that unauthorized users and administrators should not
attempt to access so that administrators and users are aware of this restriction.
Any changes to an ACL that is used to protect such files should be investigated, especially
when ownership changes are involved because these events can indicate illicit attempts to
access files without proper authorization. Because ownership changes of this nature should
be very rare, they should be easy to detect after high-value assets are identified and
documented.
Identify Sensitive or Suspicious Accounts
All sensitive accounts should be reviewed to identify which accounts require a higher
auditing level. Such accounts will include the default Administrator account, any members of
the Enterprise, Schema, or Domain Admins groups, and any accounts that are used by
services.
Aside from sensitive accounts, it is also important to adjust security audit levels for accounts
held by individuals who have been identified as risks or who may be suspected of
participating in suspicious activity. For more information about how to adjust audit levels for
individual user accounts, see the “Policy Violations and Thresholds” section later in this paper.
List Authorized Programs
To discover information about a network, an attacker must run programs on systems that
reside within that network. By restricting what programs are permitted to run on a network, a
business can significantly reduce the threat of external attack. To establish a list of authorized
programs, an audit should be performed on all programs currently authorized or identified as
necessary in a network environment. Any unknown programs discovered during such an
audit should be considered suspect and investigated immediately. Microsoft Systems
Management Server 2003 can assist with software audits but is not required.
Note Some exceptions may be required for certain computers, such as developer
workstations where executables under development may not be on an approved programs
list. However, a more secure approach would be to require that development and testing
only occur in a virtual computer environment or only in an isolated development network
domain.
Detect Policy Violations and Thresholds
Policy violations form the largest category of security issues for which businesses must plan.
These types of incidents include:
 Creation of user accounts outside of the established process.

 Improper or unauthorized usage of administrator privileges.
 Use of service accounts for interactive log on.
 File access attempts by unauthorized user accounts.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Deletion of files that user accounts have permission to access.

 Installation and execution of unapproved software.
Although the most common type of policy violation is unintentional user access attempts,
such as browsing to restricted directories, such violations are usually the least significant
because access limitations and well-designed rights policies address this issue. Administrative
policy violations are the most significant type of event, whether deliberate or accidental,
because of the very nature of administrative rights.
Administrative account privileges grant a significant degree of systems access to the

individuals who require that type authority to perform their duties. However, this authority
does not imply the authorization to use those system rights outside of authorized scope or
process. The ability of administrative accounts to enable user account creation, modify user
accounts, view restricted data, and modify data access rights requires careful consideration
of ways to mitigate the risks associated with such powerful capabilities.
Threat Modeling
As can be seen, some sets of threats can be mitigated with auditing, others may not, and
some can be mitigated with auditing yet may not be worth the cost to do so. The main point
to understand is that not every vulnerability presents a threat to a network. To make
determinations as to which vulnerabilities can or should be mitigated, it may be useful to
apply principles of threat modeling.
Threat modeling is an engineering technique that can be used to help identify threats and
vulnerabilities to more efficiently create countermeasures in the context of a specific
environment. This process generally involves three basic steps:
 Understanding the attacker’s perspective.

 Identifying the security profile of the system.
 Determining and ranking the relevant threats.
More to the point, examining a network environment from an attacker’s perspective involves
determining what targets would be most tempting to a person attempting to gain access to
a network and what conditions must be met for an attack on such targets to succeed. When
vulnerable targets of opportunity have been identified, the environment can be examined
to determine how existing safeguards affect the attack conditions. This process reveals
relevant threats, which can then be ranked according to the level of risk they present, which
remediation activities can deliver the most valuable solution to that threat, and whether
mitigation may affect other areas in beneficial or detrimental ways that may affect the value
of that remediation.
Accordingly, there are actually a few specific steps to a successful network threat modeling
process that are based on these requirements:
tmg.edu.au | 1300 888 TMG (1300 888 864)
1. Identify Critical Assets. Part of determining where best to spend security resources is
to list the assets that are critical to business operations. This process should involve the
business process owners as well as the technology owners, because each will have
important perspectives concerning which assets would cause harm to the business if
compromised.
2. Identify Possible Attack Points. This identification phase actually involves two different
perspectives as well. First, it is necessary to classify the types of boundaries that data
on the network can reside within. These boundaries reside within either the critical,
sensitive, and public realms based on the damage that could be done if said data
was exposed. Second, a technology perspective examines the attack points by way
of vectors and what possible points of vulnerability could grant exposure to critical
and sensitive assets. This combination of information can help narrow the focus of
security efforts to vulnerabilities at the points where critical information can be
accessed.
3. Identify Actual Threats. When critical assets and the possible access points have been
revealed, a list of what attackers could do to cause damage can be created. With
such a list it is then possible to focus efforts on actual specific threats.
There are different methods that can be used to identify actual threats. STRIDE is one
method that examines threats based on the types of attacks that can be used
(Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and
Elevation of Privilege). Other iterative measures exist as well, such as breaking threats
down by logical layers (for example, network, host, and application). The approach is
up to the organization based on what makes the most sense for a given environment.
4. Categorize and Rank Threats. This step brings common risk assessment and
management principles into play by ranking threats based on the probability of their
use and the potential impact those threats could have on a business. The standard
formula used is as follows:
Risk = Probability of Exploitation x Potential Business Impact
There are actually a number of methods involved in such a process, as well as a

number of tools available to help with such risk assessments that are well beyond the
scope of this paper.
5. Remediate and Re-evaluate. The product of the previous steps provides a list of
actual threats that are capable of affecting the business, which are ranked in order
of the risk the present to that business. This list enables a focused remediation effort
that should also be evaluated for the cost-to-benefit ratio they present. After all, there
may be several different ways to mitigate specific risks and some may address other
vulnerabilities that then make such security efforts even more effective.
Even after a remediation plan is enacted, the threat modeling method is an iterative process
that should be performed on a regular basis with constant re-evaluation efforts to ensure that
security efforts are as effective and comprehensive as possible.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Background Investigations and Reviews
Most businesses already perform some sort of background check on prospective employees
as a condition of employment, but do not perform checks afterwards. Businesses should
consider performing background checks at regular intervals during employment, especially
for critical positions with access to restricted information.
Computer Use Policy Agreements
Computer or network usage agreements are important not only to inform employees about
how they may use company assets but also to inform them about policies to monitor network
activity and computer use in addition to the possible consequences of any attempts to
violate these policies.
Usage policy statements also act as legal documents when they define these issues in
explicit terms and require employee signatures as an indication of agreement. Without proof
that an employee was fully aware of internal security monitoring policies and the
expectation of acceptable use of company assets, it is increasingly difficult to prosecute
abusers in case of any wrongdoing.
It is also important to issue an access and unauthorized usage warning at any access point
on a company’s network that informs any person who attempts access that it is a private
network and that any unauthorized access is prohibited and will be prosecuted. For
example, Windows operating systems have the capability to display a warning statement
during an attempted logon event that can be used to inform users that they are about to
attempt access to a protected company resource and that unauthorized access is
prohibited.
Although it is outside the scope of this document to discuss the legal issues involved with the
exact wording and use of such documents, it is important to mention that such documents
and policies should exist. Many examples of such usage and access statements may exist on
the Internet, but these materials should only be prepared with the support and consultation
of qualified legal advisors because there are many unique local and international legal
issues that require careful consideration.
Separation of Duties
Just as different functionalities for systems are segmented across a network for security,
performance, and availability purposes, it is also important to provide for duplication and
separation of duties when developing staffing requirements for an IT security department.
Important roles that involve access or control of sensitive data and systems should be
redundant whenever possible and reasonable, not only to protect against issues surrounding
the loss of knowledge if a staff member is lost but also to provide a security function in cases
of internal sabotage. For example, it would be difficult to recover if only one staff member
tmg.edu.au | 1300 888 TMG (1300 888 864)
knew the administrator passwords and that staff member left without providing those
passwords.
In addition to role redundancy, it is also important to separate critical roles, especially for
security monitoring. The people who manage the network should not also be responsible for
reviewing security audit information, and the security staff should not have administrative
rights that are equal to the administrators. Sometimes it is also necessary to safeguard
departmental information from administrative staff to further apply separation of duties. For
example, some businesses have organizational units that have their own systems or
administrative accounts to protect sensitive information such as finances or human
resources.
Note Although it may not be possible to prevent administrator account holders from finding
workarounds for such separations of duties, it is important to at least establish set guidelines
for authorized usage for administrative authority that uses the principle of separation of duty.
Validate Security Monitoring Functionality
Regular testing of a security monitoring solution should be planned carefully before

implementing such a program. Although initial testing is important to validate a security
monitoring solution, it is important to have a schedule of tests that occur regularly due to the
ever-changing security environment.
Testing can include intrusion attempts and testing use of administrative privileges to
determine whether the solution is effective at finding such activities. However, it is also
important to research the latest changes in security techniques and attack profiles to
determine if changes need to be made. The threats to business networks are constantly
changing as attackers adjust to security implementations, so the defenses and monitoring
techniques should constantly evolve to remain effective.
Establish Processes
To separate authorized events from unauthorized security events it is necessary to create a

plan for established mandatory change control and problem management processes. Such
a plan can provide a detailed paper trail that can be cross-correlated with security log
information. Although issue tracking is commonplace in most companies by way of help desk
tickets or other problem tracking processes, change control is often neglected. Change
control is a necessary mechanism, and may be used not only to track trends for spotting
problematic systems or applications but also as a vital security mechanism.
Change control processes should occur as a proactive procedure, and reactive changes
should be limited to use of a problem management process. A change control process
should require submittal and approval prior to any change and include the following details:
 Approver name
 Implementer name
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Timeframe of the change

 Reasons for the change
 Changes to be made
 Systems affected by the change
 Business impact
 Actual results of the change
Another process that should be established is a user provisioning process via an

add/change/delete user procedure that also creates an audit trail to guard against
unauthorized account changes. Prior to the establishment of such a process, it is important to
perform a security audit of the current user accounts that exist to verify the validity of those
accounts and periodically validate that list as it changes.
Use of automatic user provisioning and identity management solutions, such as Microsoft
Identity Integration Server (MIIS) 2003, can be helpful as well by automating account
changes and the processes behind such activities. When using such solutions it is important to
remember that administrator accounts still retain the capability to create new accounts but
that they would have no need to do so—because accounts would be created by
established processes. Therefore, any events associated with account creation, such as
event 624, should only correlate to the MIIS 2003 or other established service account that is
used for automatic provisioning.
Although external threats to business networks are constantly aired in the media, experience
shows that networks and company data are much more vulnerable to loss or compromise
from incorrect configurations or procedural missteps. It is important to protect against all
threats external and internal, and many vendors exist to help protect your company from
external threats, but no one can sell a business a package that will prevent mistakes made
by the people responsible for your network and security. The best way to mitigate such risks is
by implementing and enforcing sound processes and procedures regarding changes
performed on the network.
Define Security Responses
To limit the damage a security breach can cause, it is important to develop a defined
suitable response plan and establish processes for responding to incidents. Incident reports,
the formation of a rapid response team, and an emergency response protocol are good
examples. The speed and effectiveness of incident responses will enhance an organization's
security profile and limit the actual and perceived damage an intrusion attempt may cause.
The formation of an established security response process not only helps limit the damage an
actual incident may cause, it also acts as a deterrent by notifying staff and other individuals
that an incident will provoke a coordinated and immediate response to any security
violations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Human Resources
According to studies done by CERT and the U.S. Secret Service, many attacks from internal
sources could be averted if businesses were more aware of and took actions in response to
an employee’s behavioral changes or threats. Probably the most valuable security resources
in a business are the employees themselves, because they are aware of when a staff
member may become disgruntled or alert the proper personnel to when a visitor may be
acting suspiciously. In fact, one of the first actions by an outside security auditing group will
be to perform a “walk around” in an attempt to find password information on paper, spot
unsecured devices, or to attempt intrusions by connecting directly to the internal network.
A business’s staff can serve as an important layer of protection against internal and external
threats. Encouraging open door policies to discuss worrisome behavior from peers and
training support personnel to take any reports of unusual computer activity from staff seriously
can help mitigate intrusion attempts or malware incidents. Internal training is also important
as a method of teaching employees how to spot types of computer behavior that should be
reported. Training also serves as a preventative measure with regard to avoiding social
engineering attacks.
Correlate Security Policy Violations with Audit Events
Correlating security event information involves the collection of security events from multiple
systems and the placement of this data into a secure central location. When security
information has been correlated, the appropriate personnel can analyze this central
repository to identify violations or external attacks. This repository is not only important for
forensic analysis, but also as a tool to detect attacks and address vulnerabilities. Although
there are several third-party solutions that exist for this purpose, the following Microsoft
products and tools can help address this need by correlating security event logs and other
security monitoring information into a central repository.
EventCombMT
EventCombMT (multi-threaded) is a component of the Windows Server 2003 Security Guide,

which is available at http://go.microsoft.com/fwlink/?LinkId=14845. This tool can parse and
collect events from the event logs on multiple computers. It runs as a multi-threaded
application that enables the user to specify any number of parameters when scanning event
logs, such as:
 Event IDs (individual or multiple)

 Event ID ranges
 Event sources
 Specific event text
 Event age in minutes, hours, or days
tmg.edu.au | 1300 888 TMG (1300 888 864)
Figure 4. EventCombMT
Certain specific search categories are built in to EventCombMT, such as account lockouts
(shown in the preceding figure), which provide search functionality for the following events:
 529. Logon failure (bad user name or password)

 644. A user account was auto locked
 675. Pre-authentication failed on a domain controller (incorrect password)
 676. Authentication ticket request failed
 681. Logon failure
Another security-related event that does not reside in the Security log file is event 12294,
which is from the System log file. It is important to add this event to any search, because it
can be used to detect attack attempts against the Administrator account which does not
have a lockout threshold and is therefore a vulnerable and tempting target for any would-be
attacker.
Note Event 12294 appears as a Security Accounts Manager (SAM) event in the System log,
not in the Security log.
EventCombMT can save events to a Microsoft SQL Server™ database table, which makes it
useful for long-term storage and analysis. After it is stored in a SQL Server database, the
information from the event logs can be accessed by an array of different programs, such as
SQL Query Analyzer, Microsoft Visual Studio® .NET, or a number of third-party utilities.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Log Parser 2.2
Log Parser is a free tool available from Microsoft that can be used to search for data in a log,
upload logs to a SQL database or CSV file, and generate reports from event logs, CSV files, or
other log formats (including IIS logs, for which it was originally designed).
This command-line scripting tool can be used as a resource to correlate event log
information into a central location, parse events that are of interest, and even generate
reports. However, the scripting and command-line interface require a level of detail that is
beyond the scope of this paper.
EventQuery.vbs
EventQuery.vbs is a tool that was released with Windows XP. It can be used to list events and
event properties from one or more event logs. The command-based script host (CScript.exe)
must be running to use this script. If the default Windows Script Host has not been set to
CScript, you can accomplish this by running the following command:
Cscript //h:cscript //s //nologo
This command-line script utility is very flexible and can accept many different parameters to
adjust the filtering and format applied to its output.
Internet Information Services Logging
The additional logging functionality available with Internet Information Services (IIS) provides
the ability to report on the identity of site visitors, what a visitor accessed, and when that
visitor accessed it. IIS logs record successful and failed attempts to access sites, virtual folders,
and files, and can be configured to selectively audit that information to minimize storage
requirements and limit the recording of unnecessary information.
These logs can either be stored in native format as a file, which can then filtered by using one
of the parsing and collation tools listed earlier, or directly to a centralized location by using
ODBC database logging, which can be used to store the information to a SQL database or
any other ODBC-compliant database.
Certain activities and sequences of events should be monitored closely, including the
following:
 Multiple failed commands attempting to run executable files or scripts.

 Excessive failed logon attempts from a single IP address or range of addresses, which
can indicate either a DoS attempt or a privilege escalation attempt.
 Failed attempts to access or modify .bat or .cmd files.
 Unauthorized attempts to upload files to a folder that contains executable files.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Beginning with Windows Server 2003, new auditing capabilities are built-in with IIS and can
either be used with the new logging capabilities of IIS, integrated directly into the Event Log,
or accessed with ASP pages for custom solutions. For more information about these
capabilities and how to implement them, refer to the IIS documentation.
Microsoft Internet Security and Acceleration Server
Microsoft Internet Security and Acceleration (ISA) Server is an advanced stateful packet and
application layer firewall that also provides additional functionality, including VPN and proxy
caching capabilities.
In addition to the active defense utility that ISA Server provides, it can also serve a security
monitoring function by using its ability to act as a centralized logging tool that can monitor all
activity flowing through the perimeter of a network. The logging capabilities in ISA Server
include the ability to capture firewall traffic, Web proxy activity, and SMTP message
screening logs. These logs can be filtered, queried, or monitored on a real-time basis by using
the built-in real-time log viewer (shown in the following screen shot) or monitoring dashboard.
Figure 5. Microsoft ISA Server 2004 Real-Time Log Viewer
In addition to the built-in logging functionality, ISA Server has an alerting feature that can
issue alerts via e-mail and event log entries or even start or stop services. The ability to log
suspect activity to event log entries is particularly useful in the scope of this paper. This
capability allows for the recording and storage of possible attack information into a
centralized location with other audit event log data.
tmg.edu.au | 1300 888 TMG (1300 888 864)
In addition to this logging and alerting functionality, there are also built-in intrusion detection
tools that can be enabled in ISA Server. These basic intrusion detection services (IDS) are
licensed from Internet Security Systems and include several IP packet filters, DNS application
filters, and a POP application filter. These services are capable of detecting many common
exploits.
The intrusion detection functionality in ISA Server is capable of logging events and
generating alerts when potential attacks are detected. It can also terminate services or
suspicious connections. Some of the attack profiles that can be detected include:
 WinNuke (Windows out-of-band attacks)

 Land attacks
 IP half scan attacks
 UDP bombs
 Port scans
 DNS hostname length overflow Attacks
 DNS zone transfers from privileged or high TCP/IP ports
In any case, whether using ISA Server or some other firewall and IDS solution, it is important to
consider the perimeter network (also known as DMZ, demilitarized zone, and screened
subnet) when designing a security monitoring and attack detection system.
Microsoft Operations Manager 2005
Microsoft Operations Manager (MOM) monitors multiple servers in an enterprise environment

from a central location. The MOM agent collects events from event logs and forwards them
to the MOM management server, which then places those events into the MOM database.
MOM 2005 and later versions are capable of collecting events from computers that do not
run the MOM agents.
MOM uses its management pack rules to identify issues that affect the operational
effectiveness of servers. Additional rules can be created to monitor for specific events and,
when these events occur, send alert notifications via e-mail, pop-up messages, or directly to
pager devices.
Although MOM provides many useful features that can be used for security monitoring and
attack detection, it was not designed for this functionality. Future releases of MOM will
provide greater security log collection functionality.
Microsoft Systems Management Server 2003
Microsoft Systems Management Server (SMS) 2003 can monitor and manage servers and
workstations in a network from a central location. Although it is geared to management
tasks, it can also help serve vital security-related functions in a security monitoring solution by
managing security updates distribution and reporting or by reporting on any unauthorized
software installations.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The SMS inventory functionality can help serve a vital need in a security monitoring solution
by serving as a real-time centralized inventory management solution, which is vital to any
security audit and monitoring process.
Implement Forensic Analysis
Forensic analysis is a large subject in its own right and this paper cannot explain this topic in
entirety. In particular, this paper does not discuss the evidence handling requirements of
forensic analysis or describe forensic data other than information supplied by security event
logs.
Determining the timing, severity, and results of security breaches and identifying systems
affected by attackers can be accomplished with forensic analysis. To be effective, the
information gathered for forensic analysis must contain the following information:
 Time of an attack
 Duration of an attack
 Systems affected by an attack
 Changes made during an attack
Again, because of the myriad number of details involved with understanding the laws that
govern evidential procedure, key data types in regard to forensics, the tools required for
analysis, evidence collection, evidence preservation, and forensic methodologies, it is
impossible to address this subject in detail in this paper. However, there are some excellent
resources, such as the First Responders Guide to Computer Forensics
[http://www.cert.org/archive/pdf/FRGCF_v1.3.pdf ] from CERT at
www.cert.org/archive/pdf/FRGCF_v1.3.pdf, which are available at sites devoted to security
studies.
Business Issues
Planning for the use of forensic analysis differs from approaches to other solutions, because it
involves the investigation of incidents after they have occurred instead of a real-time analysis
of incidents. Therefore, a detailed history of events from multiple systems must be maintained
for a longer period of time. Because of this additional need, an effective forensic analysis
system should be centralized and have a significant amount of storage capability to store a
large number of records in a suitable database structure.
One of the mitigating business decisions regards the length of time that such records should
be kept for forensic analysis, and also what type of retention cycle should be used. Such
factors can greatly affect storage and equipment requirements for a forensic analysis plan.
The following table illustrates the typical retention times that are often found at businesses
that have established forensic analysis plans.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 2. Storage Limits for Forensic Analysis
Storage factors Storage Comments

limits
Online storage 21 days Provides for rapid access to event details
(database)
Offline storage (backup) 180 days Reasonable archival limit for most organizations
Regulated environment 7 years Archival requirement for regulated businesses
Intelligence agencies Permanent Intelligence and defense organizational
requirements
Note Some regulated industry practices (such as those in businesses that handle medical
records, for example), use time limit specifications in terms of “do not retain longer than”
instead of a set retention time.
One option for consideration is to use online databases to retain the online forensic analysis
data and then archive older events into a more compressible format, such as comma-
delimited (also known as comma-separated values or CSV) text for offline storage. If
necessary, CSV files can be imported back into the online database for analysis if needed.
Ensure that whatever solution is selected serves the business requirements for the rapid
investigation of recent events with the added ability to recover older events when necessary.
A history of security incidents within a business along with a list of available resources should
guide the development of a plan that provides the best combination of data retention times
for online and offline storage. If possible, test the event collection system in a reasonably
large database with the reports that you wish to run, and verify that the reports run in a
reasonable amount of time and deliver actionable information.
Security for forensic analysis data must also be considered, because access to this
information should rarely be necessary. If access is needed, it should only be provided to a
select few trusted security personnel. Administrator access to this information should be
strictly regulated within an established change control process that has additional security
oversight. No one else should have the capability to access this information, disrupt its
collection, or modify it.
Technical Issues
Planning a security monitoring solution for forensic analysis requires careful provisioning for
the secure and reliable collection of, and storage for, a very large number of events. Security
monitoring requirements are similar to those detailed in other solution scenarios, but require
far greater resources for database storage and highly efficient data management.
Some technical challenges that should be considered include:
 Reliable and secure storage for online data.

 Provisioning for large amounts of high performance disk space for online storage.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Reliable backup systems to store older events to archival media.

 Secure archive storage management processes.
 Tested restoration processes to retrieve information from backup storage.
These challenges should not be specific to security monitoring, because database

administrators have similar concerns for other applications such as online transaction
processing (OLTP) databases. However, unlike other traditional database applications such
as OLTP, a forensic analysis database must cope with a far greater volume of writes rather
than reads.
Requirements
To plan for an effective forensic analysis program, the following requirements must be
addressed:
 Proper configuration of security logging settings.

 Secure log entry checking processes are established.
 A secure and centralized collection point and process created for security logs.
 Reliable storage of security monitoring information.
 Effective archival plans and schedules developed.
The requirements, capabilities, and regulatory restrictions of a business environment should

be factored into any forensic analysis solution because each organization varies in these
regards.
Deploying and Managing the Solution
The ability to identify, profile, and respond to an attack is the basic goal of any security
monitoring and attack detection solution. Therefore, the bulk of this section will be a detailed
discussion of pertinent events that may indicate attacks in progress when found in an event
log. With this in mind, a security monitoring and attack detection plan should address the
following requirements:
 Detect internal policy violations

 Identify attacks from external sources
 Enable efficient and precise forensic analysis
The solution detailed in this paper uses similar components for each of these three
requirements. The implementation of forensic analysis capabilities has additional
requirements that will be discussed later.
Security Monitoring and Attack Detection
The solution concept for security monitoring and attack detection requires planning the
appropriate levels of security audits for the following areas:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Account management
 Protected file access
 Security policy changes
 Trust creation and deletion
 User rights usage
 System restarts and time changes
 Registry modifications
 Unknown program execution
The security monitoring and attack detection system collects information from the security
event logs and collates this information in a central location. Security auditors can then
analyze this data for suspicious activity. In addition, this information can also be stored and
archived for later forensic analysis should the need arise.
A major component to this solution is the ability to configure a feature of Microsoft Windows
2003 with Service Pack 1 (SP1) and Microsoft Windows XP with Service Pack 2 (SP2) called
per-user auditing. Per-user audits allow for a specification of different audit levels for specific
user accounts, thereby permitting a higher level of audit detail for sensitive or suspicious
accounts.
Solution Prerequisites
Configuring this security monitoring and attack detection solution has the following
prerequisites:
 Servers must run Windows Server 2003 SP1 or later and reside in an Active Directory
domain.
 Client computers must run Windows XP SP2 or later as members of an Active Directory
domain.
Note If the computers in a company’s perimeter do not reside within a domain, they cannot
be configured with Active Directory Group Policy settings. However, local policies and
templates can be used to configure such systems.
This paper concentrates on identifying the characteristic signatures of attacks and does not
make any recommendations for any specific technology to be used for the collation of
security events, even though it lists some possible solutions. After a decision is made
regarding a suitable collection mechanism, the events and event sequences listed in this
paper can be used to design queries and alerts to identify suspicious behavior.
Policy Violations and Thresholds
New features available in Microsoft Windows Server 2003 and Microsoft Windows XP with SP2
allow for selective audit levels on individual user accounts. For example, audit levels can be
set to report only logon and logoff activity for all users while auditing all activity for a specific
user. Per-user selective audit can also be used to reduce the volume of events in the Security
tmg.edu.au | 1300 888 TMG (1300 888 864)
log by allowing certain accounts to be excluded from audit generation for certain activities.
Only user accounts can be audited using this functionality; security and distribution groups
cannot be so audited. Accounts that belong to the Administrators local group cannot be
excluded from audit using the per-user selective audit mechanism.
The command-line utility used to set per-user auditing policy for selective auditing on
Windows Server 2003 and Windows XP SP2 is Auditusr.exe. Valid selective auditing categories
are:
 System Event
 Logon/Logoff
 Object Access
 Privilege Use
 Detailed Tracking
 Policy Change
 Account Management
 Directory Service Access
 Account Logon
When Aauditusr.exe is run from the command-line without any parameters, it will display the
current selective auditing settings, which will be blank at first. There are two ways to populate
the selective auditing parameters; input one per-user manually as command-line
parameters, or multiple parameters by importing a per-user auditing settings file.
Usage of Audituser.exe is as follows:
Audituser.exe /parameter useraccount:”category”
(or a comma-delimited list of categories).
For example, to enable failure auditing of System Events and Logon/Logoff events on an
account named LocalUser, the following command-line entry would be used:
Audituser /if LocalUser:”System Event”,”Logon/Logoff”
The following parameters can be used at the command line:
 /is – adds or changes an include-success entry

 /if – adds or changes an include-failure entry
 /es – adds or changes an exclude-success entry
 /ef – adds or changes an exclude-failure entry
 /r – removes all per-user auditing entries for a specific user account
 /ra – removes all per-user auditing entries for all user accounts
 /e – exports settings into the specified filename
 /i – imports settings from a specified filename
tmg.edu.au | 1300 888 TMG (1300 888 864)
A per-user auditing settings file is a plain text file, and uses the format shown in the following
figure.
Figure 6. Sample Auditusr.exe import file
Note The import file must start with the line “Auditusr 1.0” as shown to import successfully.
So to import the audit settings file shown in the preceding figure, the following command
would be used:
Audituser /i path\audit.txt
You can use this utility to help establish thresholds for audit logging information, which can
reduce storage requirements and increase the likelihood that intrusion attempts will be
noticed.
Security Policy Violations and Audit Event Correlation
Although this section makes no distinction between policy violations caused by external or
internal sources it is important to note that internal policy breaches can be just as
devastating to a business as attacks that originate from the outside. As noted previously in
this paper, a significant percentage of malicious attacks are carried out by internal sources,
and this percentage does not include the accidental damage caused by inappropriate use
of elevated privileges outside of established procedural scope.
Because of the risk involved with accidental or intentional abuse of elevated privileges by
internal sources, it is important to establish policies and procedures regarding the
appropriate use of those privileges and to establish audit trails for cross-correlation. After the
institution of a change management process and documentation policy, a correlation can
be developed to match audit information with approved and unapproved events, thereby
easing the ability to detect unusual behavior within a business. This section will assist with that
correlation by describing the different types of events that can be tracked and how they
might apply to policies and processes.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Accessing Unauthorized Computers
Administrative and support staff increasingly use remote management facilities, such as
Terminal Services, to connect with and manage remote systems. These systems should be
monitored for interactive logon attempts and each connection attempt should be checked
for validity. Such checks should perform the following actions:
 Identify service account logons.

 Record access attempts by unauthorized accounts.
 Investigate attempts from unusual geographic areas.
 List attempts from external IP address ranges.
Particular attention should be paid to monitoring high-value assets. Such critical resources
should reside on specific servers configured with strict audit monitoring and access control
settings.
The following table lists Logon audit events, which should be compared to lists of authorized
accounts when seen on high-value asset systems.
Table 3. Unauthorized Computer Usage Events
Event Occurrence Comments

ID
528 Successful Logon Check Workstation Name and User Account Name.
Ensure Source Network Address resides within a network.
529 Logon Failure – Check for attempts where Target Account Name equals
Unknown User Name Administrator or the renamed default administrator
or Bad Password account. Also check for multiple logon failures that are
below the account lockout threshold.
530 Logon Failure – Time Indicates an attempt to log on outside permitted time
Restrictions range. Check User Account Name and Workstation
Name.
531 Logon Failure – Check for Target Account Name and Workstation Name.
Account Currently This event can signal attempted intrusions from former
Disabled users and should provoke an investigation.
532 Logon Failure – The Check Target Account Name and Workstation Name. This
Specified User event can signal abuse attempts from contract or
Account Has Expired temporary employees and should provoke an
investigation.
533 Logon Failure – User Indicates that a user may be attempting to logon to
Not Allowed to Logon restricted workstations.
at This Computer
534 Logon Failure – Logon Check Target Account Name, Workstation Name, and
Type Not Allowed Logon Type. This event indicates a failed attempt to log
on interactively with service account credentials when
tmg.edu.au | 1300 888 TMG (1300 888 864)

ID
Group Policy settings prevent interactive logons with such
accounts.
535 Logon Failure – The Indicates that a user is attempting to logon with an
Specified Account’s account that has an expired password. May prompt
Password Has Expired investigation if repeated without a corresponding
password change or support call.
536 Logon Failure – The Check to ensure that the NetLogon service is operational.
NetLogon Otherwise, this event may prompt investigation.
Component Is Not
Active
540 Successful Logon This event is the network equivalent of Event 528.
Trojans, Rootkits, and Malware
Event ID 592 is particularly useful for detecting occurrences of Trojans, rootkits, and other
malware, because it is created whenever a new process starts. Any occurrence of this event
should prompt immediate investigation whenever the Image File Name does not correspond
with a process listed in an approved programs list.
Although Trojans and keyloggers are relatively easy to identify, rootkits are particularly
stealthy. They can be detected by locating unknown programs that start and stop in quick
succession. However, when a rootkit is started the operating system has no way to detect it
and therefore does not generate any further events.
Other malware attempts can take the form of e-mail attachments or infected Web sites, and
may attempt to escalate privileges when the executing account does not have the rights to
launch new programs. In such cases, the unauthorized software should create a failure event
that should be investigated, especially when the following events occur:
 Processes spawning as LocalSystem. Processes that run as LocalSystem should be well

defined in a list of approved programs, and can include such processes as
Services.exe.
 Processes spawned at unexpected times. If the monitored system does not use any
scheduled batch processes, certain activities (such as backups, CGI, or scripts)
should be investigated when they occur. In other cases, an investigation should
occur when such events occur outside of the regularly scheduled batch times.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 4. Event 592

ID
592 Creating a New Check the Image File Name and User Name entries for
Process unapproved process, unexpected launch times, or when
unknown programs start and then stop in quick succession.
Access Resources by Changing File Permissions
It is possible to use administrative privileges to access files to which access would normally be
denied by changing ownership of the data and then adding the accounts to the read
permissions list to that data. It is also possible to disguise such activity in Windows Server 2003
by changing ownership and permissions back to the original settings.
Identification of high-value assets and data is important in this regard, because it would be
counterproductive to implement object access auditing for every file on an average midsize
business network because of the sheer volume of access events that occur normally each
day. Object access auditing should be enabled for sensitive files and folders; ACL entries are
insufficient as a suitable defense against unauthorized access attempts.
To detect illicit activity efficiently, the following factors should be easily identifiable for all
high-value files:
 Which object was targeted by an access attempt?

 Which account was used to request access?
 Which account authorized access?
 What type of access was attempted?
 Was the event a success or failure?
 Which system was used to launch the attempt?
The built-in event viewer does not have sufficient filter settings to identify this information.
Therefore, EventCombMT or some other mechanism must be used to perform this analysis.
The Object Access audit events in the following table deal with attempts of this nature.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 5. File Permission Change Events

ID
560 Access Granted Indicates a successfully granted access request to an object.
to Existing Object Check Primary Logon ID, Client User Name, and Primary User
Name to detect unauthorized access. Check Accesses field to
determine operation type. This event only detects access
requests, not whether an actual access occurred.
567 A Permission Indicates the first instance of an access type to an object and
Associated with that permissions were changed if the Access field includes
a Handle Used “WRITE_DAC.” Correlate with event 560 by comparing Handle
ID fields.
Access Resources by Resetting Passwords
Password changes should only occur within an approved framework of established

procedures. Properly configured audit levels should record the Account Management
events shown in the following table and correlate those events against recorded procedures
to identify activity that does not follow that procedure.
Table 6. Password Reset Events

ID
627 Change Password Indicates a password change request in which the
Attempt requester supplied the original password. Compare Primary
Account Name to Target Account Name to determine if
the requesting account is the changed account.
628 User Account Indicates a password reset from an administrative interface
Password Set or rather than a password change process. The requester
Reset should be an authorized account, such as a help desk
account or self-service password reset account.
698 Change Directory Indicates an attempt to change the Directory Services
Services Restore Restore Mode password on a domain controller. Check
Mode Password Workstation IP and Account name. This event warrants an
immediate investigation.
User Account Modification
Any account modification, whether adding, deleting, or changing an account, should

correspond to an established process that involves a multiple-step business logic process
initiated by an official request from a management level employee. All of the events in the
following table should correspond to an official account modification request or prompt an
immediate investigation.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 7. User Account Change Events

ID
624 Creating a User Account Indicates a network account creation occurrence.
630 Deleting a User Account Indicates a network account deletion occurrence.
642 Changing a User Indicates security related user account changes not
Account covered by events 627-630.
685 Changing a User Indicates a user account name change.
Account Name
To effectively identify Account Management issues, queries should be configured to

accomplish the following:
 Find irregular or unusual account activities.

 Identify administrator level accounts that abuse privileges to create or modify
accounts.
 Detect patterns of account activities that occur outside of organizational security
policy.
It is also important to confirm the interval between account creation and initial logon and
password change. If a new account is not used within a predetermined timeframe, (usually
an account creation process will record the expected start date of a new user), the account
should be disabled and an investigation initiated to determine the reason for delay.
Group Membership Changes
A good security practice involves the principle of least privilege, which means granting
accounts the minimum level of access required to perform their functions adequately. When
this practice is applied, most accounts will be members of the default Domain Users group
with additional membership to business-specific security groups.
Security group membership changes should only occur within established policy guidelines,
especially when accounts with elevated privileges are involved. Such group membership
changes should only be performed by established accounts used for account management,
and such events should correlate to an established process for said changes. Any changes
outside of this process should provoke an immediate investigation.
The account management audit events in the following table detail group membership
changes.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 8. Group Membership Change Events
Event ID Occurrence Comments

631, Security Enabled Examine the Target Account Name field to determine if
632, Global Group the group changed was global or had broad access
633, 634 Change privileges.
635, Security Enabled Examine the Target Account Name field to determine if
636, Local Group the group changed was Administrators, Server Operators,
637, 638 Change or Backup Operators.
639, Security Enabled Indicates a change to a group other than deletion,
641, Group Change creation, or membership changes. Examine the Target
668 Account name to ensure that a high privilege group was
not altered.
659, Security Enabled Examine the Target Account Name field to ensure that a
660, Universal Group high privilege group, such as Enterprise Admins, was not
661, 662 Change altered.
Note Distribution group membership does not provide access to network resources,
because distribution groups are not security principles. However, membership of certain
distribution groups can create security issues, depending on the group. For example,
placement of user accounts into a management or executive distribution group could result
in a user receiving e-mail messages inappropriate to their position.
Unauthorized Account Usage Attempts
Promotion of the first Active Directory domain controller in a forest creates an administrator
account that is a member of both the Domain Admin and Enterprise Admin groups. This
account requires particular protection, because it is the only account that is not affected by
account lockout settings. Therefore, even when an account lockout policy is in place, this
account is especially vulnerable to dictionary attacks.
Effective security monitoring should be able to identify all attempts to log on with this
administrator account, even if it has been renamed.
In addition, attempts to log on with disabled or expired accounts can indicate that a former
employee, temporary worker, or contractor has tried to gain access to the network without
current credentials. Such events should prompt immediate investigations.
The following table lists events that identify unauthorized account usage and belong to the
Account Logon and Logon audit categories.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 9. Unauthorized Logon Events

ID
528 Logon Success 528 is a common event. However, event 540 should provoke
an examination of the Target Account Name to determine if it
540 was caused by the default administrator account.
529 Logon Failure – Always investigate when Target Account Name is the
Unknown User Administrator or renamed default administrator account. Also
Name or investigate if logon failures are just below the lockout
Password threshold. Also check for attempts where Target Account
Name is administrator or root and when Domain Name is
unknown.
531 Logon Failure – Examine the Target Account Name and Workstation Name to
Disabled Account determine source. This event should prompt an investigation
as a possible intrusion attempt by former account users.
532 Logon Failure – Examine the Target Account Name and Workstation Name to
Expired Account determine source. This event should prompt an investigation
as a possible intrusion attempt by former account users.
576 Special Privileges Indicates a privilege assignment that can grant a new
Assigned to New account administrative privilege or the ability to alter the
Logon audit trail. Compare Logon ID field with events 528 or 540 to
easily determine if an account obtained administrator
equivalence.
Another security issue that involves unauthorized use of account credentials stems from use
of effective password policies, such as strong password policies and shorter password
expiration times; sometimes users write down or otherwise record their passwords so that they
can remember them. This issue is particularly noticeable in environments that have multiple
identity stores without identity management services, which demand use of multiple
passwords and accounts.
Organizations must guard against users recording their passwords, especially in plain sight,
because unauthorized individuals could discover and use this information to launch an
attack. Monitoring this type of intrusion is possible using the information from the preceding
table, but involves a cross-correlation of this information with a history of logon successes for
the user account in question so that a list of workstations common for that account to access
can be created for comparison.
Note It is possible to restrict user accounts to specific workstations using built-in Active
Directory functionality. However, to use this functionality the network must support network
basic input/output system (NetBIOS) naming, as supplied by Windows Internet Naming
Service (WINS), for example.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Interactive Logon with Service Account Credentials
When services start they must present logon credentials. Sometimes, certain services may
require the use of a domain account to run services or connect to remote computers. Some
services may even require administrator credentials, or must interact with the desktop as well.
In Windows Server 2003 and later, some service accounts (such as the Alerter service) can be
started with the –LocalService switch. In addition, services that require network connectivity
can use the Network Service account NT AUTHORITY\Network Service. All services that
require user accounts should be checked to ensure that the accounts used are protected
with strong passwords. Security monitoring should confirm that logon events for such
accounts occur only when associated services start.
The primary security concern with service accounts develops when such accounts log on
interactively instead of as a service. Such events only occur when a service account has
been compromised by an intruder and logs on with that account. If the compromised
service account has administrator privileges, the intruder has gained access to substantial
capability and can disrupt normal network services.
All resources that service accounts can access should be identified and should not have any
unexplained permissions that involve access to high-value data. For example, a service
account may occasionally require write access to a log file directory, but this is generally not
the case. Service accounts that can interact with the desktop also deserve special scrutiny
because such accounts provide greater opportunities for attackers to exploit.
The following table lists Account Logon and Login audit events that identify unauthorized use
of service account credentials.
Table 10. Logon with Service Account Credentials Events

ID
528 Logon Success – Indicates an attack in progress if a Logon Type 10, a service
Console Attack or account, or the local system account is associated with this
Terminal Services event. This event should prompt an immediate investigation.
534 Logon Failure – Indicates a failed attempt to log on interactively with service
Logon Type Not account credentials when forbidden by group policy
Allowed settings. Check the Target Account Name, Workstation
Name, and Logon Type when this event occurs.
600 Process Was Indicates a service is using a named account to log on to a
Assigned a Primary system running Windows XP or later. Correlate with
Token information in events 672, 673, 528, and 592 to investigate.
601 User Attempt to This event should not occur often in a business environment
Install a Service with a clearly defined acceptable applications policy and
tmg.edu.au | 1300 888 TMG (1300 888 864)

ID
system standardization process. This event should prompt an
investigation when change control processes do not
correlate in such environments.
Unauthorized Program Execution
Administrator level accounts are capable of installing and executing programs, and are
therefore typically only delegated to trusted personnel who require such elevated
capabilities. Because of the risks associated with untested software, it is important to design a
list of approved and licensed software along with a process for requesting, testing, and
approving new applications. Unapproved applications should be limited to an isolated test
environment, and should not be installed in a production network environment outside of an
established change control process. Even then, they should only be allowed after being
added to an approved software list.
The following table lists process tracking events that can identify the use of unauthorized
programs.
Table 11. Run Unauthorized Program Events

ID
592 Creating a Indicates a new process was created. Examine the Image File
new Process Name and User Name fields and compare with an authorized
programs list when there is an established permissible program
policy in a business. Also look for instances where LocalSystem is
used to launch a command prompt, because this is a common
method for evading an audit trail.
602 Creating a Examine the Target Name and Task Time when such events occur
Scheduled at unexpected times.
Job
Note Process tracking security audits are capable of identifying unauthorized programs.
However, process tracking generates multiple Security log entries, so care must be taken that
the number of events does not overwhelm security detection mechanisms.
Access Unauthorized Resources
The following table of object access audit events involve attempts to access resources that a
user is not authorized to use.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 12. Access Attempts to Unauthorized Resources Events

ID
560 Access Refused to Examine the Object Name field to determine the
Existing Object accessed resource and correlate the Primary User Name
and Primary Domain fields or the Client User Name and
Client Domain Fields to determine the source.
568 Attempt Made to Indicates a user or program attempted to create a hard
Create a Hard Link to link to a file or object. An established hard link allows an
an Audited File account to manipulate a file without creating an audit
trail if the account has rights to the object.
Use of Unauthorized Operating Systems
The use of unauthorized operating systems can cause significant issues, ranging from
reduced protection from vulnerability exploits to the increased likelihood of data corruption
on file systems. Administrators and users can introduce unauthorized operating systems into a
network through the following mechanisms:
 Personal computers connected to the network locally or remotely.

 Use of CD-bootable operating systems.
 Reinstallation of a Windows operating system.
 Use of Virtual PC images.
Organizational policies can specify how users may connect to the network from remote
locations via a virtual private network or remote access service, and include requirements for
connecting systems such as operating system type, update level, and installation of
protective measures such as personal firewalls and antivirus software.
It is also possible for users to use Windows XP installation CDs and restart their computers to
install an unmanaged operating system. In such cases it may be possible to detect this type
of activity by locating logon attempts from an Administrator user account from an
unidentified workgroup name or the default Workgroup name.
Note Some open source distributions are available in CD-bootable form, which enables use
of the operating system without installing in on a local system. Because the operating system
is not actually installed on the local computer, it is difficult to spot such activity. However,
logon attempts from user accounts named “root” in a homogenous network environment or
from unexpected computer names can indicate the presence of an unauthorized operating
system in use. It is possible to prevent this type of activity by disabling the ability to boot from
CD in a computer’s BIOS settings and then password protecting the BIOS configuration, but
this approach might not be practical in some environments.
Virtual PC images provide a complete emulation of a computer environment on a host

computer. This emulation runs its own operating system with its own computer name, user
tmg.edu.au | 1300 888 TMG (1300 888 864)
accounts, directory services structure, and programs in a virtual environment. A virtual PC

instance is also capable of starting, running, and stopping independently from a host system
and so will not likely create any audit events on that host computer. This capability, along
with the ability of a virtual computer to connect to the host’s network, obtain IP addresses,
and even map to shared drives, presents a number of security risks ranging from weak
password protection to increased vulnerability to exploits, because it would not likely be
governed by any established update process in place on the network. Given these risks
presented by virtual PCs, it is important to restrict the usage of virtual PC software to
authorized personnel and establish documented processes regarding the creation and
usage of virtual PC instances.
To detect unauthorized operating system usage, a security monitoring solution needs to be

able to detect the following:
 Unrecognized user accounts, computer names, workgroups, or domain names.

 Duplicate or out-of-range IP addresses.
 Attempts to log on with the default Administrator account.
The Process Tracking events listed in the following table can be used to detect the use of
unauthorized operating systems.
Table 13. Unauthorized Platform Usage Events

ID
529 Logon Failure – Unknown Check for attempts in which the Target Account
User Name or Password Name field equals Administrator or root or where
the Domain Name is unknown.
533 Logon Failure-User Not Indicates that a user may be attempting to log on
Allowed to Logon at This to restricted workstations.
Computer
592 Creating a New Process Check the Image File Name and User Name fields
to ensure that the program is authorized for that use
by that account.
Create or Break Trust Relationships
Trust relationships enable accounts in one domain to access resources residing in another
domain. The creation of trust relationships is clearly not a routine operation and should only
occur within the scope of an established change control process. Breaking trust relationships
is also an activity that should only be performed after being approved in a change control
process and after careful consideration with regard to this action’s effects on the network.
The Policy Change audit events in the following table identify trust relationship activities.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 14. Changing Trust Relationships Events

ID
610 Trust Relationship with These events will be generated on the domain controller
611 Another Domain Was that established the trust relationship. This event should
620 Created, Deleted, or prompt an immediate investigation when not correlated
Modified with an established change control request process.
Examine the User Name field to determine the requesting
account.
Unauthorized Security Policy Changes
Changes to approved security policy settings should only occur within the framework of an
established change control process. Any changes occurring outside of this approval process
should lead to an immediate investigation.
This type of security policy changes include:
 Group Policy settings

o User account password policy
o User account lockout policy
o Audit policy
o Event log settings applying to the security event log
o IPsec policy
o Wireless network (IEEE 802.1x) policies
o Public key and Encrypting File System (EFS) policies
o Software restriction policies
 Security settings
o User rights settings
o User account password policy
o Security options
The preceding list only represents minimum requirements, because most businesses will likely
add more Group Policy settings in their environment. Security audits will need to identify both
successful and failed attempts to change these settings, because successful attempts should
correspond to accounts with the authority to make these changes within an established
process to do so.
The following table lists Policy Change audit events that identify Group Policy and local
system policy changes.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 15. Policy Change Events

ID
612 Changing Audit Indicates a change to an audit policy. These events should
Policy be correlated with an established change control policy to
determine if they were authorized.
613 Changing IPsec Indicates a change to the IPsec policy. Should be
614 Policy investigated when they occur outside of a system startup.
615
618 Encrypted Data These events occur when an encrypted data recovery
Recovery Policy policy is in use. Any occurrence outside of specified policies
should prompt an investigation.
Attempt to Compromise Credentials
Attackers can use several approaches, ranging from dictionary attacks to social engineering
efforts, to obtain user account credentials. Although the most well-known approach involves
dictionary attacks against a single account, another common approach is the use of a set of
passwords on all accounts in a directory services database. In the second case it is likely that
the attacker either has access to the organization’s directory database or has guessed at
the user name nomenclature and has a list of employees. To detect this type of attack it is
necessary to have the ability to detect multiple logon failures on multiple accounts, even if
account lockout thresholds are not triggered.
Password resets are another way to gain control of account credential information. Because
password reset or change operations generate the same event for both success and failure,
an attacker can avoid detection by circumventing the account lockout policy. To thwart
these attempts, a security monitoring solution must be able to identify multiple password
change or reset attempts, especially those that occur outside of established policies and
business process frameworks.
Although password cycling is not an attack (it occurs when users attempt to circumvent
password reuse policies by using scripts to cycle through numerous passwords to use the
original password), they still present a threat to security efforts. During such efforts, the
number of password resets will roughly equal the password reuse threshold and therefore will
appear as a rapid series of 627 events. Implementation of password minimum age policies
can cause such attempts to fail.
The following table lists events that can result from attack attempts on authentication
credentials, but these events can also occur as part of normal network operations—such as
when legitimate users forget passwords.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Table 16. Attack Authentication Credentials Events

ID
529 Logon Failure – Check for attempts in which Target Account Name equals
Unknown User Administrator or some other administrative level account
Name or Password that may not be authorized to change passwords. Check
for multiple logon failures that are below the lockout
threshold. Correlate with Event 529 with Event 539 to identify
patterns of continuous account lockouts.
534 Logon Failure – Indicates that a user attempted to log on with an account
Logon Type Not type that is not permitted, such as network, interactive,
Allowed batch, or service. Check Target Account Name, Workstation
Name, and Logon Type fields.
539 Account Locked Indicates an attempt to log on with an account that has
Out been locked out. Correlate with Event 529 to detect
patterns of continued lockouts.
553 Replay Attack Indicates that an authentication package, usually Kerberos,
Detected detected an attempt to log on by replay of a user’s
credentials. Although this event could be a sign of incorrect
network configuration, it should still prompt an immediate
investigation.
627 Change Password Indicates that someone other than the account holder
Attempt attempted to change a password when the Primary
Account Name field does not match the Target Account
Name field.
628 User Account This activity should be restricted to authorized accounts,
Password Set or such as a help desk account or a user self-service password
Reset reset account.
644 User Account Indicates an account lockout due to the number of
Automatically sequential failed logon attempts being greater than the
Locked account lockout limit. Correlate with events 529, 675, 681,
and 676 (Windows 2000 Server only). Also refer to the entry
for event 12294 in this table.
675 Pre-authentication Indicates a possible time synchronization issue or computer
Failed accounts that are not correctly joined to the domain.
Correlate with event 529 to determine the exact reason for
logon failure.
12294 Account Lockout Indicates a possible brute force attack against the default
Attempt administrator account. Because account lockout policies
are not enforced on this account, it is recorded as SAM
Event 12294 in the System event log. Any occurrence of this
event should prompt an investigation because it can
indicate the use of an unauthorized operating system.
Check the Domain Name field for unknown domains.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Vulnerability Exploits
Vulnerabilities are a prime target for an attacker to exploit in an intrusion attempt, because
they can exist on any computer and require time and effort to remediate. The period of time
between the discovery of vulnerabilities and the development of exploits for those
vulnerabilities, typically called the vulnerability to exploit window, has grown shorter over
time, which means there is less time to develop, test, and distribute patches for those
vulnerabilities.
The best defense against vulnerability exploits is still an effective patch management process
that quickly tests and deploys security updates within an environment. Some services that
can assist with this process are Microsoft Systems Management Server (SMS) 2003 or Windows
Software Update Service (WSUS).
Security monitoring on the perimeter network is also particularly important in this regard,
because computers residing there are most readily available to an attacker. Without
mechanisms in place to detect attacks as they occur, an organization my not realize that
anything is amiss until the network has already been compromised. Therefore it is vitally
important that computers residing in the perimeter network are carefully monitored for a
wide range of audit events.
In addition to events already discussed, most notable events detailed in the “Attempt to
Compromise Credentials" section include unauthorized access attempts and privilege
identity usage. The following table lists some events that can identify such attacks.
Table 17. Vulnerability Events Cause by Vulnerability Exploit Escalation of Privileges

ID
528 Local Logon Correlate the Logon ID field when such events occur on perimeter
and Logoff computers. Should prompt investigation when User Account
538 Name, Time, or Workstation Name fields contain unexpected
values.
551 User Initiates This event can be considered as equivalent to Event 538, because
Logoff a token leak can cause a failure to audit Event 538 but will cause
Event 551 to occur instead.
576 Privileged Indicates an administrator account logon, an account logon with
Logon sufficient privileges to tamper with the Trusted Computing Base
(TCP), or sufficient privileges to take over a computer on a
Windows Server 2003 with SP1 or later. On earlier versions of
Windows, this event is only of interest when associated with
sensitive privileges such as SeSecurityPrivilege or
SeDebugPrivelege.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Note In Windows versions prior to Windows Server 2003, event 576 will list in the Privileged Use
category. In Windows Server 2003 and later, the Logon category will also list this event.
Therefore configuration of audit settings for either category will cause this event to appear.
Attempts to Circumvent Auditing
Just as there are multiple methods available to attack a business’s network, there are also
various techniques available to hide those attempts and elude discovery. For example, an
attacker can change the security policy on a compromised system or domain to prevent
event logs from recording suspicious activity, or a Security log can be deliberately erased so
that any audited information is lost.
It is possible to detect attempts to elude a security monitoring solution with such techniques,
but it is challenging to do so because many of the same events that can occur during an
attempt to cover the tracks of intrusive activity are events that occur regularly on any typical
business network.
The following table of multiple event types can help identify auditing circumvention attempts
by attackers who are trying to hide evidence of a security breach.
Table 18. Circumvent Event Auditing Events

ID
512 Windows Start Usually occurs after Event 513. Unexpected restarts should be
Up investigated.
513 Windows Shut Usually occurs before Event 512. High-value computers should
Down only be restarted by authorized personnel, and even then only in
accordance with an established change control or other
procedure. Occurrence of this event on any server should
prompt an immediate investigation.
516 Audit Failure This event can occur either when too many events overwhelm
the event log buffer or when the security log is not set to
overwrite. Although these issues can be prevented by limiting
the types of events monitored on most computers, high-value or
vulnerable computers require more detailed monitoring to
secure and therefore need to be carefully monitored.
517 Clearing Security event logs should never be cleared without
Security Event authorization. Check the Client User Name and Client Domain
Log fields to cross-correlate with authorized personnel and
procedural approval records.
520 Changing the This activity can be used to mislead forensic investigations or
System Time provide attackers with false alibis. Check the Client User Name
and Client Domain fields for cross-correlation with authorized
personnel in addition to checking the Process Name to ensure it
is listed as %windir%\system32\svchost.exe.
tmg.edu.au | 1300 888 TMG (1300 888 864)

ID
521 Unable to Log Occurs when Windows is unable to write events to the event log.
Events This event should be investigated whenever it occurs on any
high-value systems.
608 A User Account Occurs when a new privilege is assigned to a user account. The
Privilege Was event log records this action along with the user account
Assigned Security Identifier (SID), not the user account name.
609 A User Account Occurs when a privilege was removed from a user account. The
Privilege Was event log records this action along with the user account’s SID,
Removed not the user account name.
612 Changing Although this event does not necessarily indicate that there is a
Audit Policy problem, an attacker can modify audit policies as part of an
attack. This event should be monitored on high-value computers
and domain controllers.
621 System Access Occurs when a user was granted access to a system. The User
Was Granted Name and Account Modified fields should be checked when
to an Account the access permission is listed as interactive.
622 System Access This event may signal that an attacker has attempted to remove
Was Removed evidence involving Event 621 or is attempting to deny service to
from a System some other account(s).
643 Changing the Occurs when there is an attempt to modify password policy or
Domain other domain security policy settings. Check the User Name and
Security Policy correlate with any authorization records.
Forensic Analysis
Although forensic analysis relies on many elements discussed in this paper, it is still
fundamentally different from the other monitoring and attack detection solutions discussed
because it focuses on storage and analysis of security information and is used in response to
an attack after it has occurred. Most forensic investigations begin as a list of events
associated with a specific user or system.
Security monitoring for forensic analysis requires:
 Archival of selected event types.

 An estimate of the expected number of events each day.
 Set time limits for online, offline, and archive storage.
 Databases scaled to cope with the expected number of events.
 Backup system capable of coping with the expected daily event load.
 Set policies regarding management of the archival system.
There are three main factors that determine storage requirements for a forensic analysis
program:
 The number of events that must be recorded.

tmg.edu.au | 1300 888 TMG (1300 888 864)
 The rate these events are generated by target computers.

 Online storage duration for availability.
An understanding of business needs along with the information provided in previous sections
should help make determinations with regard to these three factors so that a reasonable
storage requirement can be obtained.
Recover from, report and document security breaches according to security policies and
procedures
Data breaches can occur in a number of ways (such as through hacking, phishing or
physical theft) and it’s unsettling to think about what could happen to stolen data if it falls
into the wrong hands.
What should you do if your business experiences a data breach? What proactive measures
should you take to minimize your risk of attack?
You may not know the answers to these questions, but fear not, companies can protect
themselves against threats.
Let’s start with question one. If your company experiences a data breach – how should you
proceed?
What steps should my business take if it faces a data breach?
1. Inform company personnel: First, you need to inform select staff in your company
about the breach. This may include personnel who will be responsible for taking
action or response – most likely security, IT, finance and HR.
2. Collect evidence: Then you need to gather and preserve any evidence related to
the breach which can be used as support in an internal or criminal investigation.
3. Contact external parties: Next you’ll want to consider which outside entities need to
be aware of the attack (especially if the breach is a potential crime). These parties
could include law-enforcement, legal advisors or your PR/crisis management team.
4. Investigate: Once law enforcement becomes involved in the breach, you’ll want to
carefully conduct your investigation to determine what information and which servers
have been compromised.
5. Address regulatory concerns: If your data center encounters a breach, your
company may face compliance issues. You’ll need to address what these issues are,
inform your legal team and then contact the applicable regulatory agencies.
6. Notify those affected: This can be the most difficult part, but it’s imperative that you
inform all parties affected by the security breach, especially if the information is
highly-sensitive.
Now that you know how to handle a data breach, you should take steps internally to protect
your organization from a future attack. Which leads us to the next question:
tmg.edu.au | 1300 888 TMG (1300 888 864)
What proactive measures should my company take to minimize the risk of a breach?
1. Create a data breach notification policy: Creating a data breach notification policy
will let customers know what steps you’ll take if an attack occurs, while also ensuring
that your company will follow the right procedures.
2. Train IT employees: Employees responsible for securing your network should be
trained on how hackers operate, how to spot a data breach and how to recognize
phishing schemes.
3. Establish company policies: To minimize the risk of an attack, all employees should
have a clear understanding of what tools, devices and networks are allowed to be
used and when. You should also educate your organization on the security and
regulatory risks associated with using tools outside of company policies.
4. Implement an enterprise-grade collaboration solution: To enable your organization to
collaborate freely and securely, consider a file sharing solution that builds on your
existing solutions, puts the end user first and does not compromise on security and
control.
5. Hire a security guru: Attacks are only becoming more complex and multifaceted.
Your business should put someone in charge of security who can protect your
company’s information.
6. Maintain regulatory requirements: To ensure your business practices are compliant,
it’s important for you to work with your security and legal team to understand the
regulatory environment.
Continue to Prepare, Protect and Secure

The best way to avoid a data breach in your enterprise is to continuously prepare, protect
and secure your organization and its information.
Taking these preventative steps to guard against threats will put you on the right track to
securing your enterprise.
Check your infrastructure for compromise
If the nature of the attack was not a DoS but, let's say, a server administrator discovered a
rootkit on several PCs that were using a peer-to-peer file-sharing program, or your Intrusion
Detection System informs you that the attacks are coming from one of your routers, then you
want to check your routers and switches to make sure they weren't compromised. The simple
way is to verify that the software images' checksums still match those listed by your vendor.
Restore your configuration:
If you want to make absolutely sure you're OK, reload the software images and restore the
devices to their factory default configs and then reload your configs from backups. You do
have backups of all your configs, right?
tmg.edu.au | 1300 888 TMG (1300 888 864)
An extra tip
While most administrators keep their device configs in a configuration management tool on
the network, a network disruption might prevent you from accessing them just when you
need them most. It's a good idea to keep a copy of all the configs on a flash drive or CD in
case you have to restore over the console cable, but you definitely have to exercise some
common-sense physical security there. You don't want those to fall into the wrong hands, as
it could be pretty easy to crack the password hashes found in many config files.
Steps to shield from attacks
If the nature of the attack is a DoS, then the way you stop the attack can vary widely. It's also
entirely possible that you simply can't stop the attack from occurring, as companies with
extreme budgets like Microsoft and the Federal Government get service denial attacks all
the time. But you should be prepared to take the usual steps, such as manually implementing
shunning on your firewall, or applying some temporary ACLs to your screening routers, or just
shutting down the ports of offending internal machines. Alternately, you can configure an
Intrusion Prevention System to do these things automatically.
Activity 28
Who do you need to inform if there has been a breach of privacy? Why?
tmg.edu.au | 1300 888 TMG (1300 888 864)
Activity 28
tmg.edu.au | 1300 888 TMG (1300 888 864)
Evaluate monitored results and reports to implement and test improvement actions required
to maintain the required level of network service security
The most important part of deployment is planning. It is not possible to plan for security,
however, until a full risk assessment has been performed. Security planning involves
developing security policies and implementing controls to prevent computer risks from
becoming reality.
The policies outlined in this section are merely guidelines. Each organization is different and
will need to plan and create policies based upon its individual security goals and needs.
The discussion of tools and technologies in this paper is focused on features rather than
technology. This emphasis allows security officials and IT managers to choose which tools and
techniques are best suited to their organizations' security needs.
Basic Risk Assessment
Overview
Risk assessment is a very important part of computer security planning. No plan of action can
be put into place before a risk assessment has been performed. The risk assessment provides
a baseline for implementing security plans to protect assets against various threats. There are
three basic questions one needs to ask in order to improve the security of a system:
 What assets within the organization need protection?

 What are the risks to each of these assets?
 How much time, effort, and money is the organization willing to expend to upgrade
or obtain new adequate protection against these threats?
You cannot protect your assets if you do not know what to protect against. Computers need
protection against risks, but what are risks? In simple terms, a risk is realized when a threat
takes advantage of a vulnerability to cause harm to your system. After you know your risks,
you can then create policies and plans to reduce those risks.
There are many ways to go about identifying all the risks to your assets. One way is to gather
personnel from within your organization and have a brainstorming session where you list the
various assets and the risks to those assets. This will also help to increase security awareness
within your organization.
Risks can come from three sources: natural disaster risks, intentional risks, and unintentional
risks. These sources are illustrated in the following figure.
tmg.edu.au | 1300 888 TMG (1300 888 864)
In Security Strategies, another paper in the Best Practices for Enterprise Security white paper
series, a methodology to define security strategies is outlined in the following flowchart. The
first step in the flowchart is assessing risk.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The risk assessment step in the Security Strategy flowchart can be divided further into the
following steps.
1. Identify the assets you want to protect and the value of these assets.
2. Identify the risks to each asset.
3. Determine the category of the cause of the risk (natural disaster risk, intentional risk, or
unintentional risk).
4. Identify the methods, tools, or techniques the threats use.
Once these steps have been completed, it is possible to plan security policies and controls to
minimize the realization of risks. In this paper, we will discuss primarily the first two steps. For
information about steps three and four, please see the Security Strategies paper.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Companies are dynamic, and your security plan must be too. Update your risk assessment
periodically. In addition, redo the risk assessment whenever you have a significant change in
operation or structure. Thus, if you reorganize, move to a new building, switch vendors, or
undergo other major changes, you should reassess the risks and potential losses.
Identifying the Assets
One important step toward determining the risks to assets is performing an information asset
inventory by identify the various items you need to protect within your organization. The
inventory should be based on your business plan and the sensitivity of those items. Consider,
for example, a server versus a workstation. A server has a higher level of sensitivity than a
typical user's workstation. Organizations should store the inventory online and categorize
each item by its importance. The inventory should include everything that the organization
would consider to be valuable. To determine if something is valuable, consider what the loss
or damage of the item might be in terms of lost revenue, lost time, or the cost of repair or
replacement. Some of the items that should be on your item inventory are:
 Physical items
o Sensitive data and other information
o Computers, laptops, palmtops, etc.
o Backups and archives
o Manuals, books, and guides
o Communications equipment and wiring
o Personnel records
o Audit records
o Commercial software distribution media
 Non-physical items
o Personnel passwords
o Public image and reputation
o Processing availability and continuity of operations
o Configuration information.
o Data integrity
o Confidentiality of information
For each asset, the following information should be defined:
 Type: hardware, software, data

 General support system or a critical application system
 Designated owner of the information
 Physical or logical location
 Inventory item number where applicable
 Service levels, warranties, key contacts, where it fits in to supplying availability and or
security, and replacement process
tmg.edu.au | 1300 888 TMG (1300 888 864)
Identifying Risks to the Assets
After identifying the assets, it is necessary to determine all the risks that can affect each asset.
One way of doing this is by identifying all the different ways an asset can be damaged,
altered, stolen, or destroyed. For example:
The asset:
 Financial information stored on a database system
The risks:
 Component failure
 Misuse of software and hardware
 Viruses, Trojan horses, or worms
 Unauthorized deletion or modification
 Unauthorized disclosure of information
 Penetration ("hackers" getting into your machines)
 Software bugs and flaws
 Fires, floods, or earthquakes
 Riots
In order to develop an effective information security policy, the information produced or

processed during the risk analysis should be categorized according to its sensitivity to loss or
disclosure. Most organizations use some set of information categories, such as Proprietary, For
Internal Use Only, or Organization Sensitive. The categories used in the security policy should
be consistent with any existing categories. Data should be broken into four sensitivity
classifications with separate handling requirements: sensitive, confidential, private, and
public. This standard data sensitivity classification system should be used throughout the
organization. These classifications are defined as follows:
 Sensitive. This classification applies to information that needs protection from

unauthorized modification or deletion to assure its integrity. It is information that
requires a higher than normal assurance of accuracy and completeness. Examples of
sensitive information include organizational financial transactions and regulatory
actions.
 Confidential. This classification applies to the most sensitive business information that is
intended strictly for use within the organization. Its unauthorized disclosure could
seriously and adversely impact the organization, its stockholders, its business partners,
and/or its customers. Health care-related information should be considered at least
confidential.
 Private. This classification applies to personal information that is intended for use
within the organization. Its unauthorized disclosure could seriously and adversely
impact the organization and/or its employees.
 Public. This classification applies to all other information that does not clearly fit into
any of the above three classifications. While its unauthorized disclosure is against
tmg.edu.au | 1300 888 TMG (1300 888 864)
policy, it is not expected to impact seriously or adversely affect the organization, its
employees, and/or its customers.
After identifying the risks and the sensitivity of data, estimate the likelihood of each risk
occurring. Quantifying the threat of a risk is hard work. Some ways to estimate risk include:
 Obtaining estimates from third parties, such as insurance companies.

 Basing estimates on your records, if the event happens on a regular basis.
 Investigating collected statistics or published reports from industry organizations.
 Basing estimates on educated guesses extrapolated from past experience. For
instance:
o Your power company can provide an official estimate of the likelihood that
your building will experience a power outage in the next year.
o Past experience and best guess can be used to estimate the probability of a
serious bug being discovered in your vendor software.
Once all the risks have been realized for each asset, it is necessary to identify whether the
damage caused will be intentional or accidental.
Identifying Type of Threat and Method of Attack
A threat is any action or incident with the potential to cause harm to an organization through
the disclosure, modification, or destruction of information, or by the denial of critical services.
Security threats can be divided into human threats and natural disaster threats, as the
following picture illustrates.
Human threats can be further divided into malicious (intentional) threats and non-malicious
(unintentional) threats. A malicious threat exploits vulnerabilities in security policies and
controls to launch an attack. Malicious threats can range from opportunistic attacks to well-
planned attacks.
Non-malicious human threats can occur through employee error or ignorance. These
employees may accidentally cause data corruption, deletion, or modification while trying to
capture data or change information. (Hardware or software failures, while not a human
threat, are other non-malicious threats.)
tmg.edu.au | 1300 888 TMG (1300 888 864)
In understanding these various threats, it is possible to determine which vulnerabilities may be

exploited and which assets are targeted during an attack. Some methods of attack include:
 Social engineering
 Viruses, worms, and Trojan horses
 Denial of service attack tools
 Packet replaying
 Packet modification
 IP spoofing
 Password cracking
Proactive Security Planning
Overview
After assessing your risk, the next step is proactive planning. Proactive planning involves
developing security policies and controls and implementing tools and techniques to aid in
security.
As with security strategies, it is necessary to define a plan for proactive and reactive security
planning. The proactive plan is developed to protect assets by preventing attacks and
employee mistakes. The reactive plan is a contingency plan to implement when proactive
plans have failed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Developing Security Polices and Controls
A company's security plan consists of security policies. Security policies give specific
guidelines for areas of responsibility, and consist of plans that provide steps to take and rules
to follow to implement the policies.
Policies should define what you consider valuable, and should specify what steps should be
taken to safeguard those assets. Policies can be drafted in many ways. One example is a
general policy of only a few pages that covers most possibilities. Another example is a draft
policy for different sets of assets, including e-mail policies, password policies, Internet access
policies, and remote access policies.
Two common problems with organizational policies are:
1. The policy is a platitude rather than a decision or direction.

2. The policy is not really used by the organization. Instead it is a piece of paper to show
to auditors, lawyers, other organizational components, or customers, but it does not
affect behavior.
A good risk assessment will determine whether good security policies and controls are
implemented. Vulnerabilities and weaknesses exist in security policies because of poor
security policies and the human factor, as shown in the following diagram. Security policies
that are too stringent are often bypassed because people get tired of adhering to them (the
human factor), which creates vulnerabilities for security breaches and attacks.
For example, specifying a restrictive account lockout policy increases the potential for denial
of service attacks. Another example is implementing a security keypad on the server room
door. Administrators may get tired of entering the security PIN number and stop the door
from closing by using a book or broom, thereby bypassing the security control. Specifying
restrictive password policy can actually reduce the security of the network. For example, if
you require passwords longer than seven characters, most users have difficulty remembering
them. They might write their passwords down and leave them where an intruder can find
them.
The following diagram illustrates the relationships between a good risk assessment and good
security polices and controls.
tmg.edu.au | 1300 888 TMG (1300 888 864)
To be effective, policy requires visibility. Visibility aids implementation of policy by helping to

ensure policy is fully communicated throughout the organization. This is achieved through the
plan of each policy that is a written set of steps and rules. The plan defines when, how, and
by whom the steps and rules are implemented. Management presentations, videos, panel
discussions, guest speakers, question/answer forums, and newsletters increase visibility. If the
organization has computer security training and awareness, it is possible to effectively notify
users of new policies. It also can be used to familiarize new employees with the organization's
policies.
Computer security policies should be introduced in a manner that ensures that

management's unqualified support is clear, especially in environments where employees feel
inundated with policies, directives, guidelines, and procedures. The organization's policy is
the vehicle for emphasizing management's commitment to computer security and making
clear their expectations for employee performance, behavior, and accountability.
Types of Security Policies
Policies can be defined for any area of security. It is up to the security administrator and IT
manager to classify what policies need to be defined and who should plan the policies.
There could be policies for the whole company or policies for various sections within the
company. The various types of policies that could be included are:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Password policies
o Administrative Responsibilities
o User Responsibilities
 E-mail policies
 Internet policies
 Backup and restore policies
Password Policies
The security provided by a password system depends on the passwords being kept secret at
all times. Thus, a password is vulnerable to compromise whenever it is used, stored, or even
known. In a password-based authentication mechanism implemented on a system,
passwords are vulnerable to compromise due to five essential aspects of the password
system:
 A password must be initially assigned to a user when enrolled on the system.

 A user's password must be changed periodically.
 The system must maintain a "password database."
 Users must remember their passwords.
 Users must enter their passwords into the system at authentication time.
 Employees may not disclose their passwords to anyone. This includes administrators
and IT managers.
Password policies can be set depending on the needs of the organization. For example, it is
possible to specify minimum password length, no blank passwords, and maximum and
minimum password age. It is also possible to prevent users from reusing passwords and ensure
that users use specific characters in their passwords making passwords more difficult to
crack. This can be set through Windows 2000 account policies discussed later in the paper.
Administrative Responsibilities
Many systems come from the vendor with a few standard user logins already enrolled in the
system. Change the passwords for all standard user logins before allowing the general user
population to access the system. For example, change administrator password when
installing the system.
The administrator is responsible for generating and assigning the initial password for each user
login. The user must then be informed of this password. In some areas, it may be necessary to
prevent exposure of the password to the administrator. In other cases, the user can easily
nullify this exposure. To prevent the exposure of a password, it is possible to use smart card
encryption in conjunction with the user's username and password. Even if the administrator
knows the password, he or she will be unable to use it without the smart card. When a user's
initial password must be exposed to the administrator, this exposure may be nullified by
having the user immediately change the password by the normal procedure.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Occasionally, a user will forget the password or the administrator may determine that a user's
password may have been compromised. To be able to correct these problems, it is
recommended that the administrator be permitted to change the password of any user by
generating a new one. The administrator should not have to know the user's password in
order to do this, but should follow the same rules for distributing the new password that apply
to initial password assignment. Positive identification of the user by the administrator is
required when a forgotten password must be replaced.
User Responsibilities
Users should understand their responsibility to keep passwords private and to report changes
in their user status, suspected security violations, and so forth. To assure security awareness
among the user population, we recommend that each user be required to sign a statement
to acknowledge understanding these responsibilities.
The simplest way to recover from the compromise of a password is to change it. Therefore,
passwords should be changed on a periodic basis to counter the possibility of undetected
password compromise. They should be changed often enough so that there is an
acceptably low probability of compromise during a password's lifetime. To avoid needless
exposure of users' passwords to the administrator, users should be able to change their
passwords without intervention by the administrator.
E-mail Policies
E-mail is increasingly critical to the normal conduct of business. Organizations need policies
for e-mail to help employees use e-mail properly, to reduce the risk of intentional or
inadvertent misuse, and to assure that official records transferred via e-mail are properly
handled. Similar to policies for appropriate use of the telephone, organizations need to
define appropriate use of e-mail. Organizational polices are needed to establish general
guidance in such areas as:
 The use of e-mail to conduct official business

 The use of e-mail for personal business
 Access control and confidential protection of messages
 The management and retention of e-mail messages
It is easy to have e-mail accidents. E-mail folders can grow until the e-mail system crashes.
Badly configured discussion group software can send messages to the wrong groups. Errors in
e-mail lists can flood the subscribers with hundreds of error messages. Sometime errors
messages will bounce back and forth between e-mail servers. Some ways to prevent
accidents are to:
 Train users what to do when things go wrong, as well as how to do it right.

 Configure e-mail software so that the default behavior is the safest behavior.
 Use software that follows Internet e-mail protocols and conventions religiously. Every
time an online service gateways its proprietary e-mail system to the Internet, there are
tmg.edu.au | 1300 888 TMG (1300 888 864)
howls of protest because of the flood of error messages that result from the online
service's misbehaving e-mail servers.
Using encryption algorithms to digitally sign the e-mail message can prevent impersonation.
Encrypting the contents of the message or the channel that it's transmitted over can prevent
eavesdropping. E-mail encryption is discussed later in this paper under "Public Key
Infrastructures."
Using public locations like Internet cafes and chat rooms to access e-mail can lead to the
user leaving valuable information cached or downloaded on to internet computers. Users
need to clean up the computer after they use it, so no important documents are left behind.
This is often a problem in places like airport lounges.
Internet Policies
The World Wide Web has a body of software and a set of protocols and conventions used to
traverse and find information over the Internet. Through the use hypertext and multimedia
techniques, the Web is easy for anyone to roam, browse, and contribute to.
Web clients, also known as Web browsers, provide a user interface to navigate through
information by pointing and clicking. Browsers also introduce vulnerabilities to an
organization, although generally less severe than the threat posed by servers. Various settings
can set on Internet Explorer browsers by using Group Policy in Windows 2000.
Web servers can be attacked directly, or used as jumping off points to attack an
organization's internal networks. There are many areas of Web servers to secure: the
underlying operating system, the Web server software, server scripts and other software, and
so forth. Firewalls and proper configuration of routers and the IP protocol can help to fend off
denial of service attacks.
Backup and Restore Policies
Backups are important only if the information stored on the system is of value and
importance. Backups are important for a number of reasons:
 Computer hardware failure. In case certain hardware devices such as hard drives or
RAID systems fail.
 Software Failure. Some software applications could have flaws in them whereby
information is interpreted or stored incorrectly.
 User Error. Users often delete or modify files accidentally. Making regular backups can
help restore deleted or modified files.
 Administrator Error. Sometimes administrators also make mistakes such as accidentally
deleting active user accounts.
 Hacking and vandalism. Computer hackers sometimes alter or delete data.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Theft. Computers are expensive and usually easily to sell. Sometimes a thief will steal
just the hardware inside the computer, such as hard drives, video cards, and sound
drivers.
 Natural disasters. Floods, earthquakes, fires, and hurricanes can cause disastrous
effects on computer systems. Building can be demolished or washed away.
 Other disasters. Unforeseeable accidents can cause damage. Some examples are if
a plane crashes into buildings or if gas pipes leak and cause explosions.
When doing hardware and software upgrades:
 Never upgrade without backing data files that you must have.
 Be sure to back up system information such as registries, master boot records, and the
partition boot sector.
 In operating systems such as Microsoft Windows 2000 and Microsoft Windows NT,
make sure that an up-to-date emergency repair disk exists.
Information that should be backed up includes:
 Important information that is sensitive to the organization and to the continuity of

operations. This includes databases, mail servers, and any user files.
 System databases, such as registries and user account databases.
Backup Policies
The backup polices should include plans for:
 Regularly scheduled backups.

 Types of backups. Most backup systems support, normal backups, incremental
backups, and differential backups.
 A schedule for backups. The schedule should normally be during the night when the
company has the least amount of users.
 The information to be backed up.
 Type of media used for backups. Tapes, CD-ROMs, other hard drives, and so forth.
 The type of backup devices: Tape devices, CD writers, other hard drives, swappable
hard drives, and maybe to a network share. Devices also come in various speeds,
normally measured in the amount of megabytes backed up per minute. Depending
on the system requirements, the amount of time it takes to perform backups.
 Onsite and offsite storage of backups.
o Onsite Storage: Store backups in a fireproof safe. Backups should not be
stored in the drawer of the table on which the computer sits. Secure storage
protects against natural disaster, theft, and sabotage of critical data. All
software including operating system software, service packs, and other critical
application software should also be safely stored.
o Offsite storage: Important data should also be stored offsite. Certain
companies specialize in storing data. An alternative solution could be using a
safe deposit box and a bank.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Emergency Repair Disks
In Microsoft Windows 2000 and Microsoft Windows NT, there is an option to create an
emergency repair disk (ERD). The ERD contains certain registry information and other system
files to help recover or repair a corrupted Windows installation. The repair disk should be
updated periodically or every time new users or system configuration changes, such as
adding or deleting disk partitions. ERDs should be stored with backups both onsite and offsite
if possible.
Windows 2000 Software Policies
Account Policies
In Windows 2000, account policies are the first subcategory of Security Settings. Account
policies include:
 Password Policy. Password policies can be set depending on the needs of the
organization. For example, it is possible to specify minimum password length, no blank
passwords, and maximum and minimum password age. It is also possible to prevent
users from reusing passwords and ensure that users use specific characters in their
passwords making passwords more difficult to crack.
 Account Lockout Policy. With this policy, it is possible to determine what happens
when users fail to enter the correct password for an account. Users can be locked out
after a specified number of failed logon attempts and the period of time that
accounts are locked out for.
 Kerberos Authentication Policy. You can modify the default Kerberos settings for each
domain. For example, you can set the maximum lifetime of a user ticket.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Group Policy
Group Policy is a way of forcing rules about computer configuration and user behavior. It is
possible to have different policies throughout the company. As a user connects to a
Windows 2000 domain controller that has Group Policy settings enabled, the policies are
automatically downloaded to the user's computer and stored in the registry. Some of the
settings include:
 Addition or removal of items from the desktop and control panel.

 Automatically installing software on users' computers without user interaction.
 Configuring Internet Explorer options for users including security zones.
 Configuring network settings such as mapped network drives and permissions to view
computer browse list.
 Configuring system settings such as disabling computer shutdown options and the
ability to run task manager.
tmg.edu.au | 1300 888 TMG (1300 888 864)
IP Security Policies
The Internet Protocol (IP) underlies the majority of corporate networks as well as the Internet.
It has worked well for decades. It is powerful, highly efficient, and cost-effective. Its strength
lies in its flexibly routed packets, in which data is broken up into manageable pieces for
transmission over networks. And it can be used by any operating system.
In spite of its strengths, IP was never designed to be secure. Due to its method of routing
packets, IP-based networks are vulnerable to spoofing, sniffing, session hijacking, and man-in-
the-middle attacks—threats that were unheard of when IP was first introduced.
The initial attempts to provide security over the Internet have been application-level
protocols and software, such as Secure Sockets Layer (SSL) for securing Web traffic and
Pretty Good Privacy (PGP) for securing e-mail. These applications, however, are limited to
specific applications.
Using IP security it is possible to secure and encrypt all IP traffic. It is possible to make use of IP
security policies in Windows 2000 to control how, when, and on whom IP security works. The IP
security policy can define many rules, such as:
 What IP addresses to scan for

 How to encrypt packets
 Setting filters to take a look at all IP traffic passing through the object on which the IP
security policy is applied
tmg.edu.au | 1300 888 TMG (1300 888 864)
Tools and Techniques to Aid in Security
There are various technologies, tools, and techniques to help aid in securing networks and
computers. This section deals with some of those technologies, outlining the features and
uses more than providing an in-depth technical evaluation. The idea is to allow security
officials and IT managers to gain an overall impression of these techniques and then to
decide what techniques and tools will best suit the organization. In-depth technical studies of
some of the concepts discussed can be found on the Windows 2000 resource kit and in the
links to various sites in the References section at the end of the chapter.
Secure Access, Secure Data, Secure Code
People like confidentiality and privacy, however attackers can eavesdrop or steal
information that is sensitive to a person or organization. If a company comes up with a new
innovative product and would like to store the ideas on a computer system, it is going to
want protection for that the data on the system and the transferring of data from one system
to another. Networks and data communication channels are often insecure, subjecting
messages transmitted over the channels to passive and active threats. With a passive threat,
an intruder intercepts messages to view the data. This intrusion is also known as
eavesdropping. With an active threat, the intruder modifies the intercepted messages. An
effective tool for protecting messages against the active and passive threats inherent in
data communications is cryptography.
Cryptography is the science of mapping readable text, called plaintext, into an unreadable
format, called ciphertext, and vice versa. The mapping process is a sequence of
mathematical computations. The computations affect the appearance of the data, without
changing its meaning.
To protect a message, an originator transforms a plaintext message into ciphertext. This

process is called encryption as shown in following flow diagram. The ciphertext is transmitted
over a network or data communications channel. If the message is intercepted, the intruder
only has access to the unreadable ciphertext. Upon receipt, the message recipient
transforms the ciphertext into its original plaintext format. This process is called decryption.
tmg.edu.au | 1300 888 TMG (1300 888 864)
The mathematical operations used to map between plaintext and ciphertext are
cryptographic algorithms. Cryptographic algorithms require the text to be mapped, and at a
minimum, require some value that controls the mapping process. This value is called a key.
Given the same text and the same algorithm, different keys produce different mappings.
Cryptography is used to provide the following services: authentication, integrity, non-

repudiation, and secrecy. In an e-mail message, for example, cryptography provides:
 Authentication. Allows the recipient of a message to validate its origin. It prevents an

imposter from masquerading as the sender of the message.
 Integrity. Assures the recipient that the message was not modified en route. Note that
the integrity service allows the recipient to detect message modification, but not to
prevent it.
 Non-repudiation. There are two types of non-repudiation service. Non-repudiation
with proof of origin provides the recipient assurance of the identity of the sender.
Non-repudiation with proof of delivery provides the sender assurance of message
delivery.
 Secrecy. Also known as confidentiality, prevents disclosure of the message to
unauthorized users.
Public Key Infrastructures
Public key cryptography can play an important role in helping provide the needed security
services including confidentiality, authentication, digital signatures, and integrity. Public key
cryptography uses two electronic keys: a public key and a private key. These keys are
mathematically related, but the private key cannot be determined from the public key. The
public key can be known by anyone while the owner keeps the private key secret.
A Public Key Infrastructure (PKI) provides the means to bind public keys to their owners and
helps in the distribution of reliable public keys in large heterogeneous networks. Public keys
are bound to their owners by public key certificates. These certificates contain information
such as the owner's name and the associated public key and are issued by a reliable
certification authority (CA). Digital certificates, also called Digital IDs, are the electronic
counterparts to driver licenses, passports, or membership cards. A digital certificate can be
presented electronically to prove your identity or your right to access information or services
online. Digital certificates are used not only to identify people, but also to identify Web sites
(crucial to e-business) and software that is being sent over the Web. Digital certificates bring
trust and security when you are communicating or doing business on the Internet.
A PKI is often composed of many CAs linked by trust paths. The CAs may be linked in several
ways. They may be arranged hierarchically under a "root CA" that issues certificates to
subordinate CAs. The CAs can also be arranged independently in a network. This makes up
the PKI architecture.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Digital Signatures
Electronic transactions are becoming increasingly important. Many companies offering

online services and e-commerce would like to have mechanisms in place to increase
confidence in electronic transactions. When a buyer buying a product from a seller hands a
bank check (bill of exchange) to the seller he or she has to sign the check verifying his or her
identity and making the transaction legal.
The widespread use of PKI technology to support digital signatures can help increase
confidence in electronic transactions. For example, the use of a digital signature allows a
seller to prove that goods or services were requested by a buyer and therefore demand
payment. The use of a PKI allows parties without prior knowledge of each other to engage in
verifiable transactions.
For example, a buyer interested in purchasing goods electronically would need to obtain a
public key certificate from a CA. The process of obtaining a certificate from a CA is to
generate a public-private key pair. The buyer sends the public key with valid information
about the company to a registration authority (RA), and asks for a certificate. The RA verifies
the buyer's identity based on the information provided and vouches for the identity of the
buyer to a CA, who would then issue the certificate.
The newly certified buyer can now sign electronic purchase orders for the goods. The goods
vendor receiving the purchase order can obtain the buyer's certificate and the certificate
revocation list (CRL) for the CA that issued the buyer's certificate, check that the certificate
has not been revoked, and verify the buyer's signature. By verifying the validity of the
certificate, the vendor ensures receipt of a valid public key for the buyer; by verifying the
signature on the purchase order, the vendor ensures the order was not altered after the
buyer issued it.
Once the validity of the certificate and the signature are established, the vendor can ship
the requested goods to the buyer with the knowledge that the buyer ordered the goods. This
transaction can occur without any prior business relationships between the buyer and the
seller.
Secure Sockets Layer
Secure Sockets Layer (SSL) is a protocol that protects data sent between Web browsers and
Web servers. SSL also ensures that the data came from the Web site it is supposed to have
originated from and that no one tampered with the data while it was being sent. Any Web
site address that starts with "https" has been SSL-enabled.
SSL provides a level of security and privacy for those wishing to conduct secure transactions
over the Internet. SSL protocol protects HTTP transmissions over the Internet by adding a layer
of encryption. This ensures that your transactions are not subject to "sniffing" by a third party.
tmg.edu.au | 1300 888 TMG (1300 888 864)
SSL provides visitors to your Web site with the confidence to communicate securely via an
encrypted session. For companies wishing to conduct serious e-commerce, such as receiving
credit card numbers or other sensitive information, SSL is a must. Web users can tell when
they've reached an SSL-protected site by the "https" designation at the start of the Web
page's address. The "s" added to the familiar HTTP—the Hypertext Transfer Protocol—stands
for secure.
Companies that want to conduct business via the Internet through and using the capabilities
of SSL need to contact a certificate authority, such as VeriSign Inc., which is a third-party
organization that confirms a company is indeed what it claims to be. Once that is complete,
the company can set up its Web servers for SSL connections. Users don't have to do anything
to trigger an SSL connection. The client portion of SSL is built into the Web browser.
Secure E-mail
Standard Internet e-mail is usually sent as plaintext over networks. Intruders can monitor mail
servers and network traffic to obtain sensitive information.
There are currently two actively proposed methods for providing secure e-mail security
services: Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extensions
(S/MIME). These services typically include authentication of the originator and privacy for the
data. They can also provide a signed receipt from the recipient. At the core of these
capabilities is the use of public key technology and large-scale use of public keys requires a
method of certifying that a given key belongs to a given user.
PGP is a military grade encryption scheme available to all computer users. It works using
paired sets of keys. The public key can be used to encode a message that can only be
decoded with the matching private key. Likewise, e-mail "signed" with a private key can be
verified as authentic with its matching public key.
S/MIME is the same cryptographic method used for secure e-mail, adopted by every major
e-mail vendor in the industry. S/MIME uses public key cryptography to digitally sign and
encrypt each message sent between trading partners. This ensures that not only can the
message not be read, but also that the message came only from the sender and was not
altered in transport.
Encryption File System
Data encryption has become an increasingly important factor in everyday work. Users seek a
method of securing their data with maximum comfort and minimum additional requirements
on their part. They want a security system that protects any files used by any of their
applications, without resorting to application-specific encryption methods.
In today's world of advanced technology, your electronic records are your business.
Previously, using networked computers or remote laptops meant either sacrificing
tmg.edu.au | 1300 888 TMG (1300 888 864)
productivity or risking loss. Traveling with copies of important business databases was out of
the question, but not anymore.
Today, critical enterprise information no longer resides solely on mainframe computers or

central servers. Strategic planning, research, product development, marketing data, third-
party information, and other corporate secrets are widely distributed on individual computers
throughout an enterprise. These workstations, regular desktop computers, individual
computers in home offices, and notebook computers are the most numerous, most
vulnerable entry points to any enterprise, and they're all open to intrusion and theft. Even if
an enterprise uses advanced network access security, an unattended workstation offers
instant access to files on the hard drive and also the network. Similarly, a stolen notebook
computer offers easy access to critical data by competitors, unauthorized employees, and
others whose knowledge of such information can profit at the expense of the victimized
organization.
To solve the problem of attackers being able to read the files on the disks, you can use
Encrypting File System (EFS). EFS is a new feature in Microsoft Windows 2000 that allows the
protection and confidentiality of sensitive data by using symmetric key encryption in
conjunction with public key technology. Only the owner of the protected file can open it
and read just like a normal document. EFS is integrated into the NT file system (NTFS). You can
set the encryption attribute for folders and files just as you would for other attributes.
EFS provides users with privacy. Besides the user who encrypts the file, only a designated
administrator can decrypt the file in cases of emergency recovery. EFS is a transparent
operation in which file encryption does not require the user to encrypt and decrypt the file.
Authentication
Modern computer systems provide a service to multiple users and require the ability to
accurately identify the user making a request. In traditional systems, the user's identity is
verified by checking a password typed during login; the system records the identity and uses
it to determine what operations may be performed. The process of verifying the user's identity
is called authentication. Password-based authentication is not suitable for use on computer
networks. Passwords sent across the network can be intercepted and subsequently used by
eavesdroppers to impersonate the user.
Verifying the identity of someone or something is important. Administrators do not want

unauthorized users or imposters to impersonate users. Administrators want to be able to verify
that whoever is logging on to a system is who they say they are. Microsoft Windows 2000
supports two types of authentication protocols: Kerberos authentication protocol and NTLM
authentication protocol. Kerberos authentication protocol is the default authentication
protocol for computers running Windows 2000. NTLM authentication protocol is provided for
backward compatibility with other Microsoft operating systems. In this section we are going
to outline the various features of each protocol and the application of each protocol.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Kerberos Authentication
Kerberos is designed to provide strong authentication for client/server applications by using

secret-key cryptography. The Kerberos protocol uses strong cryptography so that a client
can prove its identity to a server (and vice versa) across an insecure network connection.
Kerberos is a trusted third-party authentication system, whose main purpose is to allow
people and processes (known to Kerberos as principals) to prove their identity in a reliable
manner over an insecure network. Instead of transmitting secret passwords in the clear,
where they may be intercepted and read by unauthorized parties, principals obtain special
Kerberos vouchers (known as session tickets) from Kerberos, which they can use to
authenticate themselves to each other. The session ticket lasts only for the session while a
user is logged on.
Kerberos authentication requires the existence of a trusted network entity that acts as an
authentication server for clients and servers requesting authentication information. This
authentication server is known the key distribution center (KDC). It has access to a database
consisting of a list of users and client services, their default authentication parameters, their
secret encryption keys, and other data. Authentication is typically a one-way process. This is
the process by which a service authenticates the client. An advantage of Kerberos over
NTLM is that it allows for mutual authentication, where the client authenticates the service.
Kerberos authentication occurs when special authentication model messages, session

tickets, are passed among client applications, server applications, and one or more KDCs.
Client processes acting on behalf of users authenticate themselves to servers by means of
the session ticket. The KDC generates tickets, which are sent to the requesting client
processes. Kerberos maintains a set of secret keys, one for every entity to be authenticated
within a particular realm (a realm is the Protocols equivalent of a Windows 2000 domain) or
domain. A client presents a ticket to the server as evidence that the principal is who it claims
to be. The ticket presented to the server "proves" that a KDC authenticated the client.
Kerberos streamlines the process of logging on and accessing resources as opposed to NTLM.
In Kerberos authentication, the computer first contacts the KDC for authentication to the
network. Then, when the user is ready to access a resource for the first time, the computer
contacts the KDC for a session ticket to access the resource. On each subsequent attempt,
the computer can simply contact the resource directly, using the same ticket, without having
to go to a domain controller first. In this way unnecessary communication with the domain
controller is eliminated. This new process allows users to log on faster and gain access to
network resources more quickly.
NTLM Authentication
In NTLM authentication, to avoid revealing passwords directly over an untrusted network, a

challenge-response system is used. At its simplest, the server sends the user some sort of
challenge, which would typically be some sort of random string. The user would then
compute a response, usually some function based on both the challenge and the password.
This way, even if an intruder captures a valid challenge-response pair, it will not help the
tmg.edu.au | 1300 888 TMG (1300 888 864)
intruder gain access to the system since future challenges are likely to be different and thus
require different responses.
In Microsoft Windows NT, the client contacts a primary domain controller (PDC) or a backup
domain controller (BDC) to log on to the domain. Then, when the client is ready to establish a
session with a particular resource, such as a printer share, it will contact server that maintains
the resource. The server, in turn, will contact the domain controller that maintains the
resource in order to give it the client's required credentials or access token. NTLM is used in
Windows 2000 for backward compatibility with other Windows products such as Windows NT.
NTLM is also used with the Telnet service in Windows 2000 so users do not transmit their
passwords in clear text to the Telnet service. The Telnet service is only implemented on
Windows 2000 when Services for Unix is installed.
Smart Cards
Smart Cards are typically credit card type cards that contain a small amount of memory and
sometimes a processor. Since smart cards contain more memory than a typical magnetic
stripe and can process information, they are being used in security situations where these
features are a necessity. They can be used to hold system logon information such as the
user's private key along with other personal information on the user including passwords. In a
typical smart card logon environment, the user is required to insert his or her smart card into a
reader device connected to the computer. Then, the software uses the information stored
on the smart card for authentication. When paired with a password and/or a biometric
identifier, the level of security is increased. For example, requiring the user to simply enter a
password for logon is less secure than having them insert a smart card and enter a password.
File encryption utilities which use the smart card as the key to the electronic lock is another
security use of smart cards.
Secure Code
Electronic software distribution over any network involves potential security problems.
Software can contain programs such as viruses and Trojan horses. To help address some of
these problems, you can associate digital signatures with the files. A digital certificate is a
means of establishing identity via public key cryptography; code signed with a digital
certificate verifies the identity of the publisher and ensures that the code has not been
tampered with after it was signed. Certificates and object signing establish identity and let
the user make decisions about the validity of a person's identity. When the user executes the
code for the first time, a dialog box comes up. The dialog box provides information on the
certificate and a link to the certificate authority.
Microsoft developed the Microsoft Authenticode technology, which enables developers and
programmers to digitally sign software. Before software is released to the public or internal to
the organization, developers can digitally sign the code. If the software is modified after
digitally signing the software, the digital signature becomes invalid. In Internet Explorer, you
can specify security settings that prevent users form downloading and running unsigned
software from any security zone. Internet Explorer can be configured to automatically trust
tmg.edu.au | 1300 888 TMG (1300 888 864)
certain software vendors and authorities so that software and other information is
automatically accepted.
Technologies to Secure Network Connectivity
Businesses and other organizations use the Internet because it provides useful services.
Organization could choose to support or not support Internet-based services based on a
business plan or an information technology strategic plan. In other words, organizations
should analyze their business needs, identify potential methods of meeting the needs, and
consider the security ramifications of the methods along with cost and other factors.
Most organizations use Internet-based services to provide enhanced communications

between business units, or between the business and its customers, or provide a cost-savings
means of automating business processes. Security is a key consideration—a single security
incident can wipe out any cost savings or revenue provided by Internet connectivity.
Some of the ways to protect the organization from outside intrusions include firewalls and
virtual private networks (VPN).
Firewalls
Many organizations have connected or want to connect their private LANs to the Internet so
that their users can have convenient access to Internet services. Since the Internet as a
whole is not trustworthy, their private systems are vulnerable to misuse and attack. A firewall is
a safeguard that one can use to control access between a trusted network and a less
trusted one. A firewall is not a single component; it is a strategy for protecting an
organization's Internet-reachable resources. A firewall serves as the gatekeeper between the
untrustworthy Internet and the more trustworthy internal networks.
The main function of a firewall is to centralize access control. If outsiders or remote users can
access the internal networks without going through the firewall, its effectiveness is diluted. For
example, if a traveling manager has a modem connected to his office computer that he or
she can dial into while traveling, and that computer is also on the protected internal
network, an attacker who can dial into that computer has circumvented the firewall. If a user
has a dial-up Internet account with a commercial ISP, and sometimes connects to the
Internet from his or her office computer via modem, he or she is opening an unsecured
connection to the Internet that circumvents the firewall. Firewalls provide several types of
protection:
 They can block unwanted traffic.

 They can direct incoming traffic to more trustworthy internal systems.
 They hide vulnerable systems that cannot easily be secured from the Internet.
 They can log traffic to and from the private network.
 They can hide information such as system names, network topology, network device
types, and internal user IDs from the Internet.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 They can provide more robust authentication than standard applications might be
able to do.
As with any safeguard, there are trade-offs between convenience and security.
Transparency is the visibility of the firewall to both inside users and outsiders going through a
firewall. A firewall is transparent to users if they do not notice or stop at the firewall in order to
access a network. Firewalls are typically configured to be transparent to internal network
users (while going outside the firewall); on the other hand, firewalls are configured to be non-
transparent for outside network coming through the firewall. This generally provides the
highest level of security without placing an undue burden on internal users.
Types of firewalls include packet filtering gateways, application gateways, and hybrid or
complex gateways.
Packet Filtering Gateways
Packet filtering firewalls use routers with packet filtering rules to grant or deny access based
on source address, destination address, and port. They offer minimum security but at a very
low cost, and can be an appropriate choice for a low-risk environment. They are fast,
flexible, and transparent. Filtering rules are not often easily maintained on a router, but there
are tools available to simplify the tasks of creating and maintaining the rules.
Filtering gateways do have inherent risks, including:
 The source and destination addresses and ports contained in the IP packet header
are the only information that is available to the router in making decision whether or
not to permit traffic access to an internal network.
 They do not protect against IP or DNS address spoofing.
 An attacker will have a direct access to any host on the internal network once
access has been granted by the firewall.
 Strong user authentication isn't supported with some packet filtering gateways.
 They provide little or no useful logging.
Application Gateways
An application gateway uses server programs (called proxies) that run on the firewall. These
proxies take external requests, examine them, and forward legitimate requests to the internal
host that provides the appropriate service. Application gateways can support functions such
as user authentication and logging.
Because an application gateway is considered as the most secure type of firewall, this
configuration provides a number of advantages to the medium-high risk site:
 The firewall can be configured as the only host address that is visible to the outside
network, requiring all connections to and from the internal network to go through the
firewall.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 The use of proxies for different services prevents direct access to services on the
internal network, protecting the enterprise against insecure or badly configured
internal hosts.
 Strong user authentication can be enforced with application gateways.
 Proxies can provide detailed logging at the application level.
Hybrid or Complex Gateways
Hybrid gateways combine two or more of the above firewall types and implement them in
series rather than in parallel. If they are connected in series, then the overall security is
enhanced; on the other hand, if they are connected in parallel, then the network security
perimeter will be only as secure as the least secure of all methods used. In medium to high-
risk environments, a hybrid gateway may be the ideal firewall implementation.
Virtual Private Networks and Wide Area Networks
Many organizations have local area networks and information servers spread across multiple
locations. When organization-wide access to information or other LAN-based resources is
required, leased lines are often used to connect the LANs into a Wide Area Network. Leased
lines are relatively expensive to set up and maintain, making the Internet an attractive
alternative for connecting physically separate LANs.
The major shortcoming to using the Internet for this purpose is the lack of confidentiality of the
data flowing over the Internet between the LANs, as well as the vulnerability to spoofing and
other attacks. Virtual private networks use encryption to provide the required security
services. Typically encryption is performed between firewalls, and secure connectivity is
limited to a small number of sites.
One important consideration when creating virtual private networks is that the security
policies in use at each site must be equivalent. A VPN essentially creates one large network
out of what were previously multiple independent networks. The security of the VPN will
essentially fall to that of the lowest common denominator—if one LAN allows unprotected
dial-up access, all resources on the VPN are potentially at risk.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Remote Access
Increasingly, businesses require remote access to their information systems. This may be
driven by the need for traveling employees to access e-mail, sales people to remotely enter
orders, or as a business decision to promote telecommuting. By its very nature, remote
access to computer systems adds vulnerabilities by increasing the number of access points.
Dial-in
Typically the remote computer uses an analog modem to dial an auto answer modem at
the corporate location. Security methods for protecting this connection include:
 Controlling knowledge of the dial-in access numbers. This approach is vulnerable to

automated attacks by "war dialers," simple pieces of software that use auto-dial
modems to scan blocks of telephone numbers and locate and log modems.
 Username/password pairs. Since an attacker would need to be tapping the
telephone line, dial-in connections are less vulnerable to password sniffer attacks that
have made reusable passwords almost useless over public networks. However, the
use of network sniffers on internal networks, the lack of password discipline, and social
engineering make obtaining or guessing passwords easy.
 Advanced authentication. There are many methods that can be used to supplement
or replace traditional passwords. A few examples are:
o Dial-back modems. These devices require the user to enter a
username/password upon initial connection. The corporate modem then
disconnects and looks up the authorized remote telephone number for the
connecting user. The corporate modem then dials the remote modem and
establishes a connection.
o Public key certificates. The use of public key certificates described earlier
when logging on.
o Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). This is a
variant of CHAP that does not require a plaintext version of the password on
the authenticating server.
o Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP
v2). This provides mutual authentication, stronger initial data encryption keys,
and different encryption keys for sending and receiving.
o Extensible Authentication Protocol (EAP). This is an extension to the Point-to-
Point protocol (PPP) that works with dial-up clients.
The organization's ability to monitor the use of remote access capabilities can also become
an issue. The most effective approach is to centralize the modems into remote access servers
or modem pools. There should be control in allowing users to connect their own modems to
their work computers. In most cases, this should not be allowed due to the fact that it
becomes difficult to monitor modems that are not accessed through the firewall and are
distributed throughout the organization. They are potential security risks.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Information regarding access to company computer and communication systems, such as

dial-up modem phone numbers, should be considered confidential. This information should
not be posted on electronic bulletin boards, listed in telephone directories, placed on
business cards, or made available. The Network Services Manager should periodically scan
direct dial-in lines to monitor compliance with policies and should periodically change the
telephone numbers to make it more difficult for unauthorized parties to locate company
communications numbers.
Intrusion Detection Tools
Intrusion detection is the process of detecting unauthorized use of, or attack upon, a
computer or network. Intrusion Detection Systems (IDSs) are software or hardware systems
that detect such misuse. IDSs can detect attempts to compromise the confidentiality,
integrity, and availability of a computer or network. The attacks can come from attackers on
the Internet, authorized insiders who misuse the privileges given them, and unauthorized
insiders who attempt to gain unauthorized privileges.
Intrusion detection capabilities are rapidly becoming necessary additions to every large
organization's security infrastructure. The question for security professionals should not be
whether to use intrusion detection, but which features and capabilities to use. However, one
must still justify the purchase of an IDS. There are at least three good reasons to justify the
acquisition of IDSs: to detect attacks and other security violations that cannot be prevented,
to prevent attackers from probing a network, and to document the intrusion threat to an
organization.
There are several types of IDSs available today, characterized by different monitoring and
analysis approaches. Each has distinct uses, advantages, and disadvantages. IDSs can
monitor events at three different levels: network, host, and application. IDSs can analyze
these events using two techniques: signature detection and anomaly detection. Some IDSs
also have the ability to automatically respond to the detected attacks. These variations are
discussed in the following sections.
Virus Detection
Anti-virus tools perform three basic functions. Tools may be used to detect, identify, or
remove viruses. Detection tools perform proactive detection, active detection, or reactive
detection. That is, they detect a virus before it executes, during execution, or after execution.
Identification and removal tools are more straightforward in their application; neither is of use
until a virus has been detected.
Detection tools detect the existence of a virus on a system. These tools perform detection at
a variety of points in the system. The virus may be actively executing, residing in memory, or
being stored in executable code. The virus may be detected before execution, during
execution, or after execution and replication. There are three categories of analysis
detection tools:
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Static Detection. Static analysis detection tools examine executables without

executing them. They can be used to detect infected code before it is introduced to
a system.
 Detection by Interception. To propagate, a virus must infect other host programs.
Some detection tools are intended to intercept attempts to perform such activities.
These tools halt the execution of virus-infected programs as the virus attempts to
replicate or become resident.
 Detection of Modification. All viruses cause modification of executables in their
replication process. As a result, the presence of viruses can also be detected by
searching for the unexpected modification of executables. This process is sometimes
called integrity checking. Note that this type of detection tool works only after
infected executables have been introduced to the system and the virus has
replicated.
Identification tools are used to identify which virus has infected a particular executable. This
allows the user to obtain additional information about the virus. This is a useful practice, since
it may provide clues about other types of damage incurred and appropriate clean-up
procedures.
Removal tools attempt to efficiently restore the system to its uninfected state by removing
the virus code from the infected executable. In many cases, once a virus has been
detected, it is found on numerous systems or in numerous executables on a single system.
Recovery from original diskettes or clean backups can be a tedious process.
There are many third-party vendors developing the previously mentioned tools and releasing
updates on viruses. Acquiring the correct type of tool will depend on the organization's
needs for virus scanning and removal.
Auditing
After you have established the protection mechanisms on your system, you will need to
monitor them. You want to be sure that your protection mechanisms actually work. You will
also want to observe any indications of misbehavior or other problems. This process of
monitoring the behavior of the system is known as auditing.
Various operating systems maintain a number of log files that keep track of what has been
happening to the computer. Log files are an important building block of a secure system:
they form a recorded history, or audit trail, of your computer past, making it easier to track
down intermittent problems or attacks. By using log files, you may be able to piece together
enough information to discover the cause of a bug, the source of a break-in, and the scope
of the damage involved. In cases where you cannot stop damage from occurring, at least
you will have some record of it. Those logs could be exactly what you need to build your
system, conduct an investigation, give testimony, recover insurance money, or get accurate
field service performed.
tmg.edu.au | 1300 888 TMG (1300 888 864)
Log files also have a fundamental vulnerability: because they are often recorded on the
system itself, they are subject to alteration or deletion.
Events to Audit
Careful consideration should be taken when looking at which events to audit. Auditing can
cause potential performance loss. If all events are audited on a system, the performance of
a system will degrade substantially. The events to be audited are to be chosen carefully
depending on what you want to audit. Operating systems audit a variety of events:
 Logon and logoff information

 System shutdown and restart information
 File and folder access
 Password changes
 Object access
 Policy changes
Most audit logs are able to keep a history or backlog of events. Log files can be set up in
various ways. Some of these ways include:
 Setting the log file to a certain size and then overwriting the events as needed when
the log file fills up. They use the concept of first in-first out.
 Setting the log file to fill up for a certain amount of days.
 Setting the log file to specified size. Once the log file fills up, the log file needs to be
cleared manually.
Technologies to Keep the System Running in the Event of a Failure
Computers are not failure proof; you can only make computers more failure resistant. Faulty
hardware, attackers, natural disasters, power failures, and errors from users can corrupt,
damage, or delete data from a system. In the likely event that any of these threats do occur,
a disaster recovery plan needs to be in place.
To prevent these disasters from becoming a financial burden on the organization, you should
develop plans for the recovery and restoration of data. There are several questions one
needs to ask in order to establish what plans and recovery systems are currently in use:
 What information needs to be backed up and what backup strategies and plans
need to be considered?
 Are backups stored onsite and offsite? If onsite, are the backups stored in fireproof
safes? If offsite, how readily are the backups available in case of emergencies? Are
backups tested regularly?
 Are technologies such as Microsoft Cluster Server in place?
 What Redundant Array of Inline Disks (RAID) system implementations are in place?
 Is there a record of critical systems hardware and software configurations?
tmg.edu.au | 1300 888 TMG (1300 888 864)
 What training is required so operators and administrators can respond in a timely and
professional manner?
 What records need to be maintained in order to recover from a failure or disaster?
 Is there an incident response team available to in case of emergency?
 Where are licensed software packages kept and what onsite support is there from
vendors?
 Have fire drills been practiced by the incident response team and security officials?
Other components and procedures could be included also; this is just a guideline on how to
start going about setting up a disaster recovery plan. One important step to take is to always
try to test what plans you have implemented. Most administrators know that it takes money,
equipment, and time to test recovery procedures. If plans and procedures are structured
and tested correctly, recovery will become easier. Here is a general list of some things that
can make it easier to recover from disasters:
 Plans and procedures should already be developed before a failure occurs. Most the
time when a failure occurs and continuity of operations is halted for a prolonged
period of time is because procedures and plans have not been developed correctly.
 The software configuration of systems should be maintained. This includes operating
system versions, service pack updates, and any other software.
 You should keep track of hardware configurations such as disks and partitions;
peripheral devices installed; and IRQ, DMA, and I/O addresses.
 Always ensure that backups are current and up to date. If possible, perform trial
restore operations to test backups.
 Implement new technologies such as Microsoft Cluster Server. Microsoft cluster server
technology will be discussed later in the paper.
 Implement RAID technologies. These are also discussed later in the paper.
 It is also possible in some cases to implement standby servers. Backed up information
is restored on a computer that is purely for redundant purposes.
Spares
It's always a good idea to have spares readily available in case of emergency. This includes
both hardware and software spares. The following is a basic inventory that lists the hardware
and software components that should be stored as emergency spares:
 Motherboards, CPUs, memory modules, video cards and screens, and power supplies
 Hard drives, floppy drives, tape drives, CD ROM readers, etc.
 Network interface cards and modems
 Network cables, hubs, switches, bridges, routers, and other networking hardware
 Original copies of currently installed software and service packs
 Original copies of currently installed operating systems and service packs
 Any additional hardware cards like serial cards and printer port cards
 Any peripheral components like printers, scanners, and multimedia devices
tmg.edu.au | 1300 888 TMG (1300 888 864)
Once you decide which hardware and software components to have spares of, general
maintenance and record keeping will help you discover impending errors. Many
organizations keep a configuration management database or record book for each critical
system. Configuration databases help to track when patches and changes are made to a
system, or hardware or software changes. Included in the database should be general
system information such as:
 Hardware configuration
 Software configuration including operating system versions, service packs applied,
software packages installed, and disk configurations such as partition information
 Network configuration such as network cards, protocols, and any physical and
logical addresses
Errors and failures should also be logged in the database. This creates a history and often
certain patterns and events appear.
Maintenance schedules should be set up to check general systems. Audit logs and general
system and application logs should be checked on a regular basis. If possible, run
defragmentation utilities on disks and partitions where general data is stored. Run integrity
checking utilities on databases like Microsoft SQL Server and Exchange Server. Run registry-
monitoring utilities like Regmon to track registry changes and file monitoring utilities like
Filemon. You can find Regmon and Filemon utilities at see http://www.sysinternals.com/.
Develop an Incident Response Team
Develop an incident response team to help control and recover systems in the event of a
disaster. The incident response team should document:
 Notification plan of who to contact for which kinds of problems or emergencies, and
how to notify them
 Contact information for administrators that need to be notified
 Contact information on certain vendors and consultants support
 Management personnel that need to be notified
 Any other critical users
Fault Tolerance
To minimize the loss of data and allow for the continuity of operations, you can use
technologies such as Redundant Array of Inline Disks (RAID) and Microsoft Cluster
Technology. In this section we are going to concentrate on RAID technologies. RAID is a fault
tolerant disk configuration in which part of the physical storage capacity contains redundant
information about data stored on the disks. Redundant information that is stored on the disks
helps to keep the system running in the event of a single disk failure.
RAID technology is either implemented through software or hardware systems. Hardware

implementations of RAID are more expensive than software, but faster. Some hardware
tmg.edu.au | 1300 888 TMG (1300 888 864)
implementations of RAID support hot swapping of disks, which enables administrators to

swap failed hard disks while the computer is running. Software fault tolerant RAID systems are
cheaper and are only available on Microsoft Windows NT and Microsoft Windows 2000. Both
hardware and software fault tolerant RAID systems regenerate data when a drive fails and
reconstructs the data onto the new disk when the failed disk is replaced.
There are various types of RAID techniques used. For simplicity's sake we are only going to
discuss the two most common techniques: Disk mirroring and disk striping with parity.
Disk Mirroring
In disk mirroring only two disks are used. Information on one disk is duplicated onto the other
disk. When data is written to one disk, it is duplicated on the other disk. This could cause a
slight loss in write performance. A variation of mirroring is disk duplexing, where each disk has
its own controller. This helps to increase write operations and provide redundancy incase a
controller fails. Read operations on disk duplexing and mirroring.
Advantages of using mirror sets are:
 Read operations are fast.

 Recovery from failure is rapid.
 In software implantations of mirror sets, the system and boot partitions can be
mirrored.
Disadvantages of mirror sets are:
 There is a slight loss in performance during write operations.

 Only fifty percent of the total storage space can be used to store data. For example,
two 1GB hard drives. One drive is used as a backup; the other stores the data.
 If you use software mirror sets, you will be required to create a fault tolerant boot disk.
Disk Striping with Parity
Strips of equal size on each disk in the volume make up a stripe set. A stripe set with parity
adds parity to a stripe set configuration.
Data is written across two or more hard drives, while another hard drive holds the parity
information. The data and parity information is written in such a way on the volume so that
they are always on different disks.
This way, if one of the hard drives fails, the two remaining drives can recalculate the lost
information using the parity information from other disks. When the faulty hard drive is
replaced, information can be regenerated back onto a newly installed working hard drive
tmg.edu.au | 1300 888 TMG (1300 888 864)
by using the parity information. The minimum number of hard drives involved in disk striping
with parity is 3, and the maximum number is 32 hard drives.
A stripe set with parity works well when large databases are implemented on a system and
read operations are performed more often than write operations. This is because a stripe set
with parity has excellent read operations. Stripe sets with parity should be avoided in
situations where applications require high-speed data collection from a process or database
applications, where records are continually being updated. In write operations, performance
degrades as the percentage of write operations increases.
Advantages of using stripe set with parity are:
 Read operations are faster than using a single disk drive. The more drives you put into
the system the faster the read operations.
 Stripe set with parity uses only one disk for parity information. The more disks you insert
the more space there is for data.
 There is not a lot of administrative effort in replacing a faulty disk.
Disadvantages are:
 In software implementations of stripe sets with parity, neither the boot nor the system
partition can be on the strip set.
 Write operations are slower because of the parity information that needs to be
generated.
 When a hard disk fails in the stripe set the performance of the system degrades. This is
due to the information having to be recalculated when requests for information
occurs.
 Stripe sets with parity consume more memory than mirror sets because of the parity
information that needs to be generated.
Cluster Server Technology
Certain organizations would like to keep computer systems operational continuously, 24

hours a day, 7 days a week, 365 days a year. One way to do this is by implementing cluster
server technology. A cluster is an interconnected group of servers that act as a single unit in
sharing some resource or responsibility. Cluster server technology allows users to view a group
of clustered computers as one entity. Both cables and cluster server software connect the
computers in into a cluster. Microsoft Windows 2000 advanced server has cluster software
readily available that will allow you to manage clustering. Microsoft cluster service and
network load balancing offer availability and scalability to organizations that build
applications using a multi-tier model.
Cluster server technology allows features such as:
 Fault tolerance. In the event of a computer or node failure in a cluster, the other
computers keep running. Fault-tolerant systems employ redundant hardware and
tmg.edu.au | 1300 888 TMG (1300 888 864)
operating systems that work together at every level in exact synchronization across
two server units. Think of a fault-tolerant system as a failover cluster with very high
responsiveness (often on the order of milliseconds).
 High availability. This focuses on maximizing uptime by implementing automated
response to failure and failover systems. To enhance availability, you add on more
servers and backup systems to the cluster in order to take over responsibility in the
event of a failure. The servers need to keep monitoring each other's activities, and
must maintain consistency every few milliseconds. This is usually implemented by a
high-speed interconnect directly between the servers.
 Resource sharing. Resource sharing involves making server components, such as disk
storage and printers, available across all the nodes in the cluster. This is especially
important for database servers, which need to share large volumes between
machines while maintaining consistency of data.
 Load sharing. Load sharing involves balancing application processing across the
various nodes in the cluster. This can be implemented by distributing new logins to
different servers, based on their load at the moment. It could also involve directly
moving a running application from one server to another
 High throughput. High throughput focuses on the ability to process network requests
or packets quickly. This becomes most important in applications like Web or FTP
servers, whose primary job is to push out data. This kind of clustering focuses on
improving the network interfaces and the routing of network requests to servers. It can
be built into the cluster nodes themselves, or may be a property of an external
balancing device.
Using a two-node cluster, Microsoft cluster service empowers reliable application,

transactional, and file and print services. To create reliable database and messaging services
combine Microsoft cluster service with Microsoft SQL server and Exchange Server.
In multitier applications designed for the Internet, Network Load Balancing can extend the
functionality of IIS 5.0 by supplying load balancing and high availability to the first tier—the
user interface. Up to 32 servers can be used in a Web cluster.
Organizations can combine both cluster service and network load balancing to provide
comprehensive enterprise e-commerce solutions. An example on an e-commerce Web site is
to cluster your front-end Web servers running IIS 5.0 with network load balancing, and have
them accessing a back-end cluster running SQL Server Enterprise Edition.
Standby Servers
It is possible to set up a standby server in case the production server fails. The standby server
should mirror the production server. You can use the standby server to replace the
production server in the event of a failure or as a read-only server.
Create the standby server by loading the same operating system and applications as on the
production server. Make backups of the data on the production server and restore these
backups on the standby server. This also helps to verify backups that are performed. The
tmg.edu.au | 1300 888 TMG (1300 888 864)
standby server will have a different IP address and name if it is connected to the network.
You will have to change the IP address and name of the standby server if the production
server fails and the standby server needs to become the production server.
To maintain the standby server, regular backups and restorations need to be performed. For
example, let's say you make a full backup on Mondays and incremental backups every
other day of the week. You would restore the full backup on the standby server and
subsequent incremental backups thereafter on the days that the backups are performed.
Reactive Security Planning
Overview
In reactive planning the goal is to get the business back to normal operations as fast as
possible in the event of a disaster. By having efficient and well thought out contingency
plans, this goal can be achieved.
Contingency Plan
A contingency plan is an alternative plan that should be developed in case an attack

causes damage to data or any other assets, stopping normal business operations and
productivity, and requiring time to restore them. The ultimate goal of the contingency plan is
to maintain the availability, integrity, and confidentiality of data. It is the proverbial "Plan B."
There should be a plan per type of attack and/or per type of threat. A contingency plan is a
set of steps that should be taken in case an attack breaks through the security policies and
controls. The plan should address who must do what, when, and where to keep the
organization functional.
For example:
 Moving productivity to another location or site

 Implementing disaster recovery plans.
 Contacting vendors and consultants
 Contacting clients
 Rehearsed the plan periodically to keep staff up to date with current contingency
steps.
The following points outline the various tasks to develop a contingency plan:
 Address the organization's current emergency plan and procedures and how they
are integrated into the contingency plan.
 The current emergency response procedures should be evaluated and their effect on
continuous operation of business.
 Planned responses to attacks and whether they are adequate to limit damage and
minimize the impact on data processing operations should be developed and
integrated into the contingency plan.
tmg.edu.au | 1300 888 TMG (1300 888 864)
 Backup procedures, including the most recent documentation and disaster recovery
tests.
 Disaster recovery plans should be added to provide a temporary or longer operating
environment. Disaster recovery plans should cover the required levels of security to
see if they continue to enforce security throughout the process of recovery,
temporary operations, and when the organization moves back to its original
processing site or to the new processing site.
Draw up a detailed document outlining the various findings in the above tasks. The
document should list:
 Any scenarios to test the contingency plan.

 The impact that any dependencies, assistance outside the organization, and
difficulties in obtaining essential resources will have on the plan.
 A list of priorities observed in the recovery operations and the rationale in establishing
those priorities.
A contingency plan should be tested and revised by someone other than the person who
created and wrote it. This should be done to test whether the contingency plan is clearly
outlined so that anybody who reads it can implement the plan.

Ictnwk602 V7.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ictnwk602 V7.2

Uploaded by

Copyright:

Available Formats

TMG Learner Resource

tmg.edu.au | 1300 888 TMG (1300 888 864)

Consult with client and key stakeholders to identify security requirements in an

Activity 16 ......................................................................................................................................... 256

It applies to individuals working as information and communications technology (ICT)

No licensing, legislative or certification requirements apply to this unit at the time of

Elements and Performance Criteria

1.3 Research network authentication and network service

1.4 Ensure features and capabilities of network service security

1.5 Produce or update server security design documentation

2.2 Identify safety hazards and implement risk control measures

2.3 Consult appropriate person to ensure the task is

2.4 Back up server before implementing configuration

3.3 Configure basic service security and access control lists to

3.4 Implement encryption as required by the design

3.5 Configure advanced network service security options for

3.6 Configure the operating system or third-party firewall to

3.7 Ensure security of server logs and log servers are

3.8 Implement backup and recovery methods to enable

4.2 Monitor server logs, network traffic and open ports to

4.3 Monitor important files to detect unauthorised

4.4 Investigate and verify alleged violations of server or data

4.5 Recover from, report and document security breaches

4.6 Evaluate monitored results and reports to implement and

Skill Performance Description

Writing 1.5, 4.5  Develops a broad range of material

Interact with 1.6  Actively identifies the requirements of

Navigate the 2.1  Keeps up to date on changes to

 Uses a broad range of strategies to

Unit Mapping Information

Release 1 This version first released with ICT Information and

Evidence of the ability to:

 identify network service security vulnerabilities and appropriate controls

 explain auditing and penetration testing techniques

 outline network service configuration, including:

 explain server monitoring and troubleshooting tools and techniques, including

The ISO/OSI Reference Model

Figure 1: The ISO/OSI Reference Model

What are some Popular Networks?

Figure 2: A Sample UUCP Network

Why is security a critical aspect of networking?

What is the Internet?

Figure 3: A Simple Local Area Network

I might be allowed to put one of my hosts on one of my employer's networks. We have a

Figure 4: A Wider View of Internet-connected Networks

The Internet is made up of a wide variety of hosts, from supercomputers to personal

TCP/IP: The Language of the Internet

as 10.2.3.4) to a physical network address (such as 08:00:69:0a:ca:8f), and routing, which

Guaranteed Packet Delivery

Lower Overhead than TCP

Risk Management: The Game of Security

Most definitions of network security are narrowed to the enforcement mechanism.

 Confidentiality - involves the protection of assets from unauthorized entities

The concept of defense in depth is observed as a best practice in network security,

The auditing process of network security requires checking back on enforcement

Types And Sources Of Network Threats

 Not running your visible-to-the-world servers at a level too close to capacity

 Keeping up-to-date on security-related patches for your hosts' operating systems.

Executing Commands Illicitly

Where Do They Come From?

Hope you have backups

Don't put data where it doesn't need to be

Avoid systems with single points of failure