Roger Clarke's 'Introduction to Info Security'
Roger
Clarke
Principal,
Xamax
Consultancy Pty Ltd, Canberra
Visiting Fellow,
Department
of Computer Science,
Australian
National University
Version of 2 February 2001
©
Xamax Consultancy Pty Ltd, 2001
This document is at http://www.rogerclarke.com/EC/IntroSecy.html
1.
Introduction
Security has long been viewed by information systems professionals as being
vital. Computing facilities and the information systems they support have
become increasingly accessible as a result of the explosion of the open, public
Internet since about 1993. A great deal of public attention is now being
focussed on the topic. Regrettably late, even corporate executives are getting
the message.
The demand for security safeguards has long been dominated by the military. As
a result, the orientation is rather different from what corporations,
government agencies and the public really need. Meanwhile, the supply of
security safeguards has been dominated by computing and communications
specialists. As a result, the language used is arcane.
There is a serious shortage of straightforward introductions to the topic of
security in the context of information systems and the inter-connected
computing facilities that support them. This document sets out to provide such
an outline.
Feedback
is actively sought, especially criticisms and suggestions for improvement.
My intention has been to deliver a lead-in and overview for relative newcomers
to the topic, and a summary and review for those who know a bit about it. This
paper simply is not a substitute for deeper study through text-books,
peer-reviewed articles and standards documents. For those, see the substantial
bibliography.
A word of warning about the writing style. I've been in the I.T. industry for
30 years, and much of this material has been drawn from previous reports. So
for some readers it may still be too jargon-ridden; whereas a person
steeped in the lore of Internet cracking may find it old-fashioned and probably
too shallow. Sorry, but you gets what you pays for.
2.
The Nature of Security
This first section considers security in general. It is applicable to the
security of people, buildings, the contents of buildings, organisations, and
even nations, as well as information.
Security is used in at least two senses:
- a condition in which harm does not
arise, despite the occurrence of threatening events; and
- a set of safeguards designed to achieve that condition.
Threatening events can be analysed into the following kinds:
- natural threats, commonly referred to in the insurance
industry as Acts of God or Nature, e.g. fire, flood, lightning strike, tidal
wave, earthquake, volcanic eruption;
- accidental threats:
- by humans who are directly involved, e.g. dropping something, tripping
over a power-cord, failing to perform a manual procedure correctly, mis-coding
information, mis-keying, failing to perform a back-up;
- by other humans, e.g. skiers causing an avalanche, transmission failure
due to a back-hoe cutting a power cable, the insolvency, bankruptcy, or
withdrawal of support by a key supplier;
- by machines and machine-designers, e.g. disk head-crash, electricity
failure, software bug, air-conditioning failure; and
- intentional threats:
- by humans who are directly involved, e.g. sabotage, intentional capture of
incorrect data, unjustified amendment or deletion of data, theft of backups,
extortion, vandalism;
- by other humans, e.g. graffiti, vandalism, release of malicious software
('malware'), riot, terrorism, warfare.
Threatening events may give rise to harm. The generic categories of
harm are as follows:
- injury to persons;
- damage to property;
- loss of data, alteration of data, access to or disclosure of data, and
replication of data;
- loss of value of an asset; and
- loss of reputation and confidence.
A legal framework exists within which determinations can be made about the
responsibility for security, and for reparation or compensation for harm. This
comprises a wide range of heads of law, including contract, negligence and
product liability.
Appendix 1 contains
a
glossary of security terms. The terminology and definitions provided there
differ somewhat from those commonly used in military circles (in that they are
less oriented toward intentional threats), and from those common in computing
and communications (in that they extend beyond the boundaries of technical
systems).
3.
The Nature of Information Security
The focus of this document is on the security of information. The scope is
not limited to information systems internal to organisations. Local
area networks linked the computing islands within organisations as far back as
the mid-1980s. Inter-connection between organisations over wide-area networks
was mainstream by the late 1980s. Widespread inter-connection via the open
public Internet has exploded since about 1992. (On the subject of
supra-organisational systems generally, see
Clarke
2001). The scope of this paper therefore extends to security against
threatening events that occur outside the organisation and involve electronic
communications.
A mainstream definition of information security is provided by the Australian
Defence Signals Directorate (DSD).
DSD
defines information security as the combination of communications security,
computer security and radiation security (i.e. emissions from devices such as
monitors and printers, also known as TEMPEST). This usage is fairly consistent
with authorities and standards such as TCSEC (1985), ITSEC (1991), Guttman
& Roback (1995), GMITS (1996-2000), AS/NZS 3931 (1998), CCIB (1998), BS
7799 (1999), TPEP (1999), AS/NZS 4444 (1999/2000)
Many of these standards and guidelines concentrate on technical aspects of
information systems. A great many of the threats to information arise outside
the technical aspects of information systems, however, and hence the scope
needs to be defined broadly enough to expressly and meaningfully encompass the
whole of an information system. This includes organisational and individual
behaviour, and manual aspects of the overall system, as well as aspects of the
system supported by computing and communications facilities.
For an information system to be secure, it must have a number of
properties:
- service integrity. This is a property of an information
system whereby its availability, reliability, completeness and promptness are
assured;
- data integrity. This is a property whereby records are
authentic, reliable, complete, unaltered and useable, and the processes that
operate on them are reliable, compliant with regulatory requirements,
comprehensive, systematic, and prevent unauthorized access, destruction,
alteration or removal of records (AS 4390, 1996). These requirements apply to
machine-readable databases, files and archives, and to manual records;
- data secrecy . This is a property of an information
system whereby information is available only to those people authorised to
receive it. Many sources discuss secrecy as though it was only an issue during
the transmission of data; but it is just as vital in the context of data
storage and data use. This property is often misleadingly referred to in the
technical literature as `confidentiality', and even more misleadingly as
`privacy'. I explain the appropriate usages for these terms
elsewhere;
- authentication.
Authentication
is a property of an information system whereby assertions are checked. Forms
of assertion that are subjected to authentication include:
- `data authentication', whereby captured data's
authenticity, accuracy, timeliness, completeness and other quality aspects are
checked;
- `identity authentication', whereby an entity's claim as
to its identity is checked. This applies to all of the following:
- `attribute authentication', whereby an entity's claim to
have a particular attribute is checked, typically by inspecting a `credential'.
Of especial relevance in advanced electronic communications is claims of being
an authorised
agent,
i.e. an assertion by a person, a software agent or a device to represent an
organisation or a person; and
- non-repudiation. This is a property of an information
system whereby an entity is unable to convincingly deny an action it has taken.
There is a strong tendency in the information systems security literature to
focus on the security of data communications. But security is important
throughout the information life-cycle, i.e. during the
collection, storage, processing, use and disclosure phases, as well as
transmission. Each of the properties of a secure system identified above needs
to be applied to all of the information life-cycle phases.
4.
Information Security Architecture
There are many elements in a security strategy. To ensure orderliness and
integration among them, a framework or architecture is needed.
A comprehensive security strategy comprises a suite of inter-related safeguards
structured in a hierarchical fashion, as follows, and as depicted in Exhibit 1:
- underlying all other components is Infrastructure
Security, which provides protections for both technical components and
organisational processes;
- at the mid-level are Threat Management and
Vulnerability Management, which provide safeguards relating
to, respectively, the occurrences that can cause harm, and the features of the
information system that can be affected; and
- at the uppermost level, Application-Specific Security
safeguards are needed, which address aspects particular to the context.
It is important to apply the longstanding military principle of
'defence-in-depth'. This asserts that a security architecture
has to be devised such that any threatening event must break through successive
layers of safeguards before it causes harm. A more recent expression of the
principle is that there must be many onion-layers that have to be peeled back
before serious damage is suffered.
5.
The Information Security Process
The process whereby information security is assured comprises a series of
phases, expressed below and depicted in Exhibit 2. References include ACSI 33
(1998), AS/NZS 4360 (1999), BS 7799 (1999) and AS/NZS 4444 (1999).
(1)
Scope Definition
A Security Strategy and Plan needs to be sculpted to the context. The first
step in the process is the definition of its scope, with reference to the
following:
- the set of stakeholders. A checklist is provided in
AS.NZS 4360 (1999, p.28), and an improved one at
Appendix
2.
- the proxies that represent those stakeholders;
- the interests of those stakeholders;
- the degree of importance of security in the organisation's
business strategy, e.g. in relation to business continuity, and the
accessibility and/or secrecy of various categories of data;
- the degree of importance of public visibility of
assurance of the system's security; and
- legal requirements to which the organisation and its
stakeholders are subject, including contracts with customers and other parties,
data protection and privacy statutes, intellectual property laws, occupational
health and safety, the laws of evidence, and common law obligations such as the
duty of confidence, and the duty of care inherent in the tort of negligence.
It is highly desirable that the scope definition be formalised, and that
relevant executives be exposed to it, and commit to it. It then sets the
framework within which the subsequent phases unfold.
(2)
Threat Assessment
A stocktake needs to be undertaken of the information and
processes involved, their sensitivity from the perspectives of the various
stakeholders, and their attractiveness to other parties. This needs to be
followed by analysis of the nature, source and situation of threats.
The nature of threats are of a variety of kinds, including
access to data by unauthorised persons, disclosure of it to others, its
alteration, and its destruction.
The sources of the threats include several categories of
entities:
- a person who has authorisation to access the data, but for a purpose
different from that for which they use it;
- an intruder, who has no authorisation to access the data, including:
- an interceptor of data during a transmission; and
- a 'cracker' who gains access to data within storage; and
- an unauthorised recipient of data from an intruder.
Categorisations of intentional threats to facilities are to be found in
Neumann (1995, reproduced in
Appendix
3), and Anderson 2001.
The situations of the threats include several categories of
locations:
- within manual processes, content and data storage;
- within the physical premises housing facilities connected
with the system; and
- within the organisation's computing and communications
facilities, including:
- data storage, including:
- permanent storage, such as hard disk, including high-level cache;
- transient storage, such as RAM, including low-level cache and video RAM;
- archival storage;
- software that:
- receives data;
- stores data (e.g. a file-handler or database manager);
- renders data (e.g. a viewer or player);
- despatches data; and
- enables access to the data, in any of the above storage media (e.g. disk
utilities and screen-scrapers); and
- transmission, including via:
- discrete media (e.g. diskettes, CD-ROMs); and
- electronic transmission over local area and wide area networks;
- within other people's computing and communications
facilities, e.g.:
- a workstation on a trusted network that is cracked by an intruder;
- a powerful computer that is cracked, and that is used to crack one or more
passwords on the organisation's computers;
- one or more weakly protected machines that are cracked and then used to
launch denial of service (DOS) or distributed denial of service (DDOS) attacks
against the organisation's servers or networks;
- within supporting infrastructure, including electrical
supplies, air-conditioning, and fire protection systems.
(3)
Vulnerability Assessment
The existence of a threat does not necessarily mean that harm will arise.
For example, it is not enough for there to be lightning in the vicinity. The
lightning has to actually strike something that is relevant to the system.
Further, there has to be some susceptibility within the system, such that the
lightning strike can actually cause harm. The purpose of the Vulnerability
Assessment is to identify all such susceptibilities to the identified threats,
and the nature of the harm that could arise from them.
It is common for vulnerabilities to be countered by safeguards. For example,
safeguards against lightning strikes on a facility include lightning rods on
the building in which it is housed. Safeguards may also exist against
threatening events occurring in situations remote to the system in question.
For example, a lightning strike on a nearby electricity substation may result
in a power surge, or a power outage in the local facility. This may be
safeguarded against by means of a surge protector and an Uninterruptable Power
Supply (UPS).
Every safeguard creates a further round of vulnerabilities, including
susceptibilities to threats that may not have been previously considered. For
example, a UPS may fail because the batteries have gone flat and not been
subjected to regular inspections, or because its operation is in fact dependent
on the mains supply not failing too quickly, and has never been tested in such
a way that that susceptibility has become evident.
(4)
Risk Assessment
The term 'risk' is used in many different senses (including as a synonym for
what was called above 'threat', and 'harm', and even 'vulnerability'!). But
when security specialists use the word 'risk', they have a very specific
meaning for it: a measure of the likelihood of harm arising from a threat.
Risk assessment builds on the preceding analyses of threats and
vulnerabilities, by considering the likelihood of threatening events occurring
and impinging on a vulnerability. More detailed discussion is to be found in
AS/NZS 4360 (1999).
In most business contexts, the risk of each particular harmful outcome is not
all that high. The costs of risk mitigation, on the other hand, may be very
high. Examples of the kinds of costs involved include:
- the time of managers, for planning and control;
- the time of operational staff and computer time, for regular backups;
- the loss of service to clients during backup time;
- additional media, for storing software and data;
- the time of operational staff, for training;
- duplicated hardware and networks; and
- contracted support from alternative 'hot-sites' or 'warm-sites'.
Risks have varying degrees of likelihood, have varying impacts if they do
happen, and it costs varying amounts of time and money in order to establish
safeguards against the threatening events or against the harm arising from a
threatening event.
The concept of `absolute security' is a chimera; it is of the nature of
security that risks have to be managed. It is therefore necessary to weigh up
the threats, the risks, the harm arising, and the cost of safeguards. A
balance must be found between predictable costs and uncertain benefits, in
order to select a set of measures appropriate to the need.
The aim of risk assessment is therefore to determine the extent to which
expenditure on safeguards is warranted in order to provide an appropriate level
of protection against the identified threats.
(5)
Risk Management Strategy and Security Plan
A range of alternative approaches can be adopted to each threat. These
comprise:
- Proactive Strategies. These are:
- Avoidance, e.g. non-use of a risk-prone technology or procedure;
- Deterrence, e.g. signs, threats of dismissal, publicity for prosecutions;
- Prevention, e.g. surge protectors and backup power sources; quality
equipment, media and software; physical and logical access control; staff
training, assigned responsibilities and measures to sustain morale; staff
termination procedures;
- Reactive Strategies. These are:
- Detection, e.g. fire and smoke detectors, logging, exception reporting;
- Recovery, e.g. investment in resources, procedures/documentation, staff
training, and duplication including 'hot-sites' and 'warm-sites';
- Insurance, e.g. policies with insurance companies, fire extinguishing
apparatus, mutual arrangements with other organisations, maintenance contracts
with suppliers,
escrow
of third party software, inspection of escrow deposits;
- Non-Reactive Strategies. These are:
- Tolerance, i.e. 'it isn't worth the worry' / 'cop it sweet';
- Graceless Degradation, e.g. siting a nuclear energy company's headquarters
adjacent to the power plant, on the grounds that if it goes, the organisation
and its employees should go with it.
Devising a risk management strategy involves the following:
- selection of a mix of measures that reflects the outcomes of the preceding
threat and risk assessments. The measures need to comprise:
- technical safeguards. These are variously of a
preventative nature, support the detection of the occurrence of threatening
events, enable the investigation of threatening events, and monitor the
environment for signs of possible future threatening events. Categorisations
of technical safeguards are to be found in AS/NZS 4444-1 in chapters 6-10. An
outline is provided in
Appendix
4; and
- policies and procedures. These are organisational
features, in the form of structural arrangements, responsibility assignment,
and process descriptions;
- formulation of a Security Plan, whereby the safeguards
and the policies and procedures will be put into place;
- resourcing of the Security Plan;
- devising and implementing controls, to detect security
incidents and investigate and address them, and to monitor whether that all
elements of the Security Plan are in place and functioning;
- embedment of audit processes, in order to periodically
evaluate the safeguards, the policies and procedures, the actual practices that
are occurring, and the implementation of the planned controls.
(6)
Security Plan Implementation
The process of implementing the Security Plan must be subjected to strong
project management. Policies need to be expressed and communicated. Manual
procedures need to be variously modified and created, in order to comply with
the strategy and policy. Safeguards need to be constructed, tested and
cutover.
Critically, implementation of a Security Plan also requires the development of
awareness among staff, education in the generalities, and training in the
specifics of the attitudes and actions required of them. This commonly
involves a change in organisational culture, which must be achieved, and then
sustained.
(7)
Security Audit
No strategy is complete without a mechanism whereby review is precipitated
periodically, the need for adaptation detected, and appropriate actions
taken.
To be effective, audit must be comprehensive, rather than being limited to
specific aspects of security; and it must follow through the entire
organisation and its activities rather than being restricted to examinations of
technical safeguards. Needless to say, this is heavily dependent on real
commitment to the security strategy by executives and managers.
6.
Information Security Tools, Standards and Protocols
A range of tools have been devised to assist in information security. In
some cases, they are general-purpose safeguards, intended to be implemented by
multiple organisations in order to provide protections against particular kinds
of threats. In other cases, they are tool-kits rather than tools, devised as
means whereby specific-purpose safeguards can be conveniently developed.
Examples of tools include:
- tools to assist with organisational safeguards:
- checklists for assessments of threats, vulnerabilities and risks;
- checklists of safeguards;
- guidelines for the design of safeguards, such as password selection;
- checklists of security alert lists (e.g.
AusCERT,
and individual software vendors' lists)
- checklists of the sites from which software fixes, patches and replacement
versions can be downloaded
- internal systems security tools:
- means of encrypting and decrypting data in storage;
- means of inspecting for viruses on disk, and eliminating them;
- means of examining and analysing log files;
- audit tools for internal security (e.g. COPS, Tiger);
- means of checking the integrity of systems and application software (e.g.
Tripwire);
- means of checking the vulnerability of systems software and endeavouring
to address them (e.g. Solaris ASET,
Titan,
Bastille
Linux);
- networking security tools:
- access control tools, enabling the specification of privileges and groups,
creating user accounts, and administering user accounts and passwords;
- programs to access remote computers securely, e.g. ssh (`secure shell');
- means of encrypting and decrypting messages;
- packages to support private-key management;
- tools to check digital certificate validity;
- means of monitoring traffic to and from individual workstations;
- means of filtering content arriving from remote computers (e.g. banner ad
filters, virus detection tools, and cookie managers);
- means of blocking unauthorised traffic between internal devices and
external networks (`firewalls');
- intrusion detection software (IDS);
- audit tools that assist in testing external security, e.g. the Security
Administrator Tool for Analysing Networks (SATAN).
Particularly in contexts in which interaction between networks is involved,
commonality is important. Standards have been negotiated and published, and
some categories of tools need to be compliant with them. In the area of
electronic communications, standards are expressed in the form of protocols
which connected devices need to comply with.
Examples of security standards and protocols include:
- SSL/TLS. Secure Sockets Layer (SSL) is a protocol that
provides an overlay of `channel encryption' over standard web-transmissions
that use the http protocol. SSLv3 is implemented in all mainstream browsers
(SSL 1996). Transport Layer Security (TLS) is a more recent enhancement to SSL
(RFC2246 1999, RFC2487 1999, RFC2595 1999). In principle, SSLv3 and TLS also
support two-sided authentication of both server and client. In practice, they
are usually used for weak, one-sided authentication, with clients not providing
certificates, and servers providing only weak evidence of their identity;
- IPSec. Internet Protocol Security (IPSec) is a series of
standards and guidelines for the protection of data transmitted over the
Internet (RFC2411 1998). They addres encryption, authentiation, integrity and
replay protection, and key management through the Internet Key Exchange (IKE)
standard (RFC2409 1998). IPSec has provided a mainstream way in which
tunnelling can be performed, and Virtual Private Networks (VPNs) run over the
open public Internet;
- X.509v3. This is a standard for the format of digital
certificates (X.509 1997). It was originally conceived to operate within the
context of X.500 directories, but has been widely applied independently of
them. PKIX is a standard for using them on the Internet;
- AADS. The Account Authority Digital Signature Model
(AADS) is a cut-down variant of conventional digital signature processes,
applicable to communications among parties that have well-established
relationships (i.e. already have `accounts' with one another), and who have
already received and stored one another's public keys (Wheeler 1998). This
obviates the need for public keys and key certificates to be transmitted with
each message, and thereby avoids some of the problems inherent in X.509;
- SDSI. Simple Distributed Security Infrastructure (SDSI)
is another alternative approach to the conventional X.509 scheme (SDSI 1996-).
SDSI abandons the X.509 nirvana of a single, global name-space. A certificate
associates a public key (and hence a key-pair) to an entity that only the CA
knows, and no warranties are provided by the CA to the recipient of the message
as to who the keyholder is. It is up to the relying party to build up an image
of the sender based on its successive interactions with the holder of that key;
- P3P. Platform for Privacy Preferences (P3P) is a
protocol for the communication of privacy policy statements by servers on
behalf of service providers, such that clients, on behalf of consumers, can
decide whether or not to deal with that provider (Clarke 1998);
- SSH. Secure Shell (SSH) is a de facto standard protocol
for secure logins, file transfer and remote execution of programs (like telnet,
ftp and rlogin with strong crypto). It can also be used as a transport for
other protocols. It is currently undergoing formal standardisation, under the
name sesch (SSH 2001).
In an increasingly mature marketplace, a significant proportion of a
Security Plan comprises the selection of tools that are compliant with relevant
standards and protocols, and the specification of ways in which their
potentials are to be applied in order to achieve safeguards desired in the
particular context.
7.
Conclusions
Information security is important, challenging, and multi-faceted. It
involves organisational safeguards as well as technical safeguards. It cannot
be approached using naive military ideas about 'absolute security'. Instead a
'risk-managed' approach has to be adopted, and costs and inconvenience
traded-off against security. And it requires vigilance, because security
schemes suffer from entropy, i.e. they run down very quickly unless they are
maintained.
Appendix
1: Glossary of Security Terms
- Security
- A condition in which an Entity does not suffer Harm from Threatening Events
- Threat
- A circumstance that could result in Harm to the Entity, e.g. earthquake,
electricity failure, vandalism, malware, software bug. A Threat may be
natural, accidental or intentional
- Threatening Event
- An actual occurrence of a Threat
- Harm
- Anything that has deleterious consequences for the Entity, and includes
injury to persons, damage to property, loss of value of an asset, and loss of
reputation and confidence
- Safeguard
- A measure that:
-
- - prevents a Threatening Event causing Harm to the Entity;
-
- - mitigates the Harm caused by a Threatening Event; or
-
- - enables detection and/or investigation of a Threatening Event
- Vulnerability
- The susceptibility of an Entity to a Threat, in the form of a weakness that
may permit a Threatening Event to give rise to Harm. Safeguards are intended
to reduce Vulnerablities. However, they may also increase them, and they may
create new Vulnerabilities
- Risk
- A measure of the likelihood of Harm arising from a Threat
- Threat Analysis or Threat Assessment
- A process to identify and examine the nature and implications of Threats to
an Entity
- Risk Analysis or Risk Assessment
- A process to determine the extent to which expenditure on Safeguards is
warranted in order to protect against the identified Threats
- Security Strategy or Risk Strategy
- A statement of the approaches adopted to Threats, including the Safeguards
implemented, and the reasoning underlying the choices made
- Security Plan
- A plan to implement Safeguards, to monitor Threats, Vulnerabilities and
Safeguards, to respond to Threatening Events, and to progressively adapt Risk
Strategy to reflect new information
Appendix
2: Checklist of Stakeholders and Proxies
- Stakeholders
- Proxies
- employees
- unions, and regulators
- management and executives
-
- volunteers
-
- investors
- investor associations, and regulators
- funding providers
- insurers
- insurance associations
- customers
- industry associations
- suppliers
- industry associations
- the public as consumers
- consumer representative associations, consumer advocates, regulators
- the public as residents
- environmental associations, environmental advocates, local and regional
governments, and regulators
- the public as citizens
- public interest associations and advocates (e.g. privacy, civil liberties),
elected representatives, and regulators
- the physically disadvantaged
- associations, advocates
- the economically disadvantaged
- welfare associations, welfare advocates
- the aged
- associations, advocates
- politicians
- researchers
- historians
- students
- educators
Appendix
3: Categories of Computer Misuse
From Neumann (1995, p.102):
External
- visual spying
- misrepresentation
- physical scavenging
Hardware Misuse
- logical scavenging
- eavesdropping
- interference
- physical attack
- physical removal
Masquerading
- impersonation
- piggybacking attack
- spoofing attack
- network weaving
Pest Programs
- Trojan Horse attack
- logic bombs
- malevolent worm
- virus attack
Bypasses
- trapdoor attack
- authorisation attack
Active Misuse
- basic inactive misuse
- incremental attack
- denial of service
Passive Misuse
- browsing
- inference, aggregation
- covert channels
Inactive Misuse
Indirect Misuse
Appendix
4: Conventional Categories of Security Safeguard
Security measures can be usefully categorised into the following categories:
- physical security for sites, equipment, data, software and documentation;
- logical security for computer processes;
- logical security for data, software and documentation;
- network security;
- organisational measures relevant to application development staff;
- organisational measures relevant to technical operations staff;
- organisational measures relevant to all staff; and
- legal measures.
Physical security for sites, equipment, data, software and
documentation includes:
- access restrictions for sensitive sites and locations, hierarchically
structured for individuals and classes of individuals, according to their need
for access;
- issue, variation and revocation of access-enablers (e.g. id-cards,
security PINs);
- allocation of individuals to security classes;
- restriction of security-sensitive software capabilities and data access to
workstations/sockets in physically secure locations;
- fire-backups and off-site, disaster backups.
Logical security for computer processes includes:
- userid/password pairs to limit access, modification, replacement and
deletion of software, and of data, and to identify and authenticate individuals
who conduct transactions of those kinds;
- measures to prevent staff and contractors from sharing userid/password
pairs;
- tight controls over software that circumvents security measures;
- audit trails of transactions that change the system's state or access
sensitive data;
- timeout of workstations that have not been used for a period of time;
- workstation disablement at times when site security is not assured;
- measures to detect, prevent and enable the investigation of malicious
software.
Logical security for data, software and documentation
includes:
- measures to protect data, software and documentation against inappropriate
access, modification, replacement and deletion;
- measures to ensure version management, archival and media-cycling;
- application software configuration management.
Network security includes:
- limitations on the capabilities of remote servers and workstations;
- measures to detect, prevent, and enable the investigation of 'hacking'
from within the network, via dial-up lines and via network inter-connections;
- 'confidentiality' protections against the tapping of communications
channels, and the monitoring of emanations from communications channels;
- measures to protect message integrity;
- measures relating to the authentication of message-senders and -receivers;
- measures relating to the non-repudiability of message-despatch and
-receipt.
Organisational measures relevant to application development
staff include:
- educational standards on entry;
- training in relation to application quality and security;
- standards relating to design, development, testing and documentation;
- quality assurance built into all phases of the system life-cycle;
- testing of components and integrated applications, and for acceptance.
Organisational measures relevant to technical operations
staff include:
- controls over software component versions and software fixes;
- controls over application changes;
- backup procedures and controls;
- recovery procedures specification and rehearsal.
Organisational measures relevant to all staff, including
users, include:
- security training;
- security clearance, where appropriate;
- division of duties;
- incident reporting procedures and controls;
- interim procedures during service outages;
- clear lines of authority in relation to security matters;
- occasional reminders to staff and contractors of the importance of
security;
- publicity for instances of public disapproval, disciplinary action,
dismissals and prosecutions relating to security matters.
Legal measures include:
- contractual terms for staff and subcontractors;
- occasional reminders to staff and contractors.
Created: 23 January 2001 -
Last Amended: 2 February 2001
by Roger Clarke
- Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/IntroSecy.html
Mail to Webmaster -
© Xamax Consultancy Pty Ltd, 1995-2024 -
Privacy Policy
