When Bruce asked me to write this forward I was at something of a loss – how do you introduce such a

wide topic as Information Security? My focus has been at the “sharp end” – investigating incidents,
testing firewall and network security systems, providing advice on policy, writing secure tools, and
designing strong protocols that will resist interception.

One of the things that has become apparent over time is that security requires support from
management, from the supervisory level, right up to the executive and board level. Many companies
have security groups, who are hidebound by the lack of effective management muscle, and by
developers/product managers who see security as “an irritating obstacle to be got around”, in the
process of getting products to the marketplace. As several unfortunate incidents have revealed in the
last two years, lack of security works fine until something goes wrong. Then, when it does, it goes
badly wrong. Recent events have included financial services firms, software houses, and computer
systems manufacturers. Security incidents tend to gain a high press profile in the national press, and a
not insignificant consequence can be the damage caused to the good name of the organisation.

So, why bother with security? What do we have to lose if we suffer a security incident? The answer to
this is called Risk Management, and starts with an objective assessment of the risks of running a
particular operation, and what assets are likely to be affected. One of the first points to note is that the
security process must be an integral part of the entire lifecycle. Those projects that present themselves
for a security view shortly before the implementation date frequently find that they are in a situation
not unlike needing to replace the hull of a ship when already out at sea. Problems are more expensive
to fix, harder to get right, and you really wish you had done all this before setting out.

Assets can be classified in two ways. Firstly, they can be classified as tangible or intangible. Tangible
assets are measurable in monetary terms, and intangible assets are not so easily measured. The brand
name of a company is an example of an intangible asset – its value is difficult to measure, and can
change over time. Assets can also be classified as physical or logical – for example a floppy disk is a
physical asset, while the data and programs stored on it are logical assets. The value of the asset is then
a combination of tangible and intangible – about £0.50 for the disk itself, but depending on the
information stored on it, the intangible asset can be hundreds of thousands of pounds (How much is
your customer database worth?)

All company assets can be categorised in this way, including the most important asset – the people who
make up the company. The process of managing physical assets – buildings, desks, chairs, computers,
etc. is well understood, and there is frequently a security policy in place that will control the physical
security of these. A human resources group frequently controls the process of managing human assets
(or human resources), setting various policies concerning recruitment, dismissal, and employment. HR
and information security policies overlap when considering how to deal with an employee responsible
for a security incident, and also when considering the issues regarding employees leaving the company.
In many sensitive roles, a policy of removing staff in sensitive roles immediately they have made their
intention to resign plain can be advisable, despite the impact on morale.
All data in the company (and hence, any business process) should have a defined owner, responsible
for the data or information. The owner may delegate responsibility – for example, the finance director
owns all accounting data, and can delegate responsibility for accounts receivable data to the A/R
manager. It is important that as data changes (due to its movement through the system), any changes in
ownership are noted. When focussing on information security issues, three attributes of each asset
should be considered: confidentiality, availability and integrity. Integrity is defined as the expectation
that data will remain unchanged, except when a business process makes an authorised change to it.
Confidentiality is defined as the control of data distribution – restricting it to those persons authorised
by the data owner. Availability is (as the name suggests) the property of being able to make use of the
data, for example, when a database server system is responding to requests, it is said to be available.
Every organisation has slightly different requirements in this area – commercial businesses frequently
have the primary concern as integrity, while military establishments may value confidentiality above
all.

Assessments must be made of the business impact (using each of the above criteria), and also of the
threats, vulnerabilities, and controls that exist in the system. The business impact assessment should
include areas such as:

Competitive disadvantage

• How damaging would it be if information were disclosed to a competitor? (Confidentiality)

Direct loss of business

• Could business be lost if information is disclosed? (Confidentiality)

• Could orders or contracts be lost as a result of errors in or unauthorised changes to information?

(Integrity)

• Could loss of business result from the application being unavailable? (Availability)

Public confidence

• If information is disclosed, what damage could there be done to customer confidence, public
image or shareholder/supplier loyalty? (Confidentiality)

• What damage could there be to customer confidence, public image, and reputation, or
shareholders or supplier loyalty as a result of errors in or unauthorised changes to information?
(Integrity)

• Could customer confidence, public image and reputation, or shareholder or supplier loyalty be
damaged if the application is unavailable? (Availability)
Additional Costs

• Could extra costs be incurred if information is disclosed? (Confidentiality)

• Could additional costs arise through unauthorised changes to, or errors in information e.g. the
need to investigate integrity problems, or to restore the integrity of lost or corrupted data?
(Integrity)

• What additional costs could arise from the application becoming unavailable? (Availability)

Legal Liability

• Could disclosure of information result in a breach of legal, regulatory or contractual obligations?

(Confidentiality)

• Could legal, regulatory or contractual obligations be breached if there are errors in or

unauthorised changes to information? (Integrity)

• Could legal, regulatory or contractual obligations be breached through a loss of availability of the
application? (Availability)

Recovery
• How costly would it be to recover from the backlog in processing if the application was
unavailable? (Availability)

Staff Morale

• If information is disclosed, could there be a damaging effect on staff morale or motivation?

(Confidentiality)

• Could there be a damaging effect on staff morale or motivation if staff cannot rely on
information? (Integrity)

• Could there be a damaging effect on staff morale or motivation if the availability of the
application was disrupted? (Availability)

Fraud

• If information is disclosed, could goods, services or funds be improperly diverted?

(Confidentiality)

• Could fraudulent diversion of goods or funds arise from or be concealed by unauthorised changes
 to information? (Integrity)

• Could fraudulent diversion of goods or funds arise from, or be concealed by the application being
unavailable? (Availability)

Management Decisions

• Could incorrect business decisions be made as a result of errors in or unauthorised changes to

information? (Integrity)

• Could decision making be adversely affected by the application being unavailable (Availability)

Business Disruption

• Could business be otherwise disrupted as a result of errors in or unauthorised changes to

information?(Integrity)

• Could the business be otherwise disrupted by the application being unavailable? (Availability)

The above questions should be discussed with the data owners, as well as any persons with delegated
responsibility (e.g. systems administration, development), and objective statements formed, grading the
business impact for the risks described above. As a second stage, the threats, vulnerabilities, and
controls in the system and application should be assessed, using the three-prong confidentiality-
integrity-availability model described above.

Confidentiality
• Outsiders gaining sight of print-outs and documents
• Disclosure by employees of sensitive information to outsiders
• Unauthorised entry into premises
• Unauthorised access to data by employees
• Unauthorised access to data by external personnel
• Confidentiality problems with connected systems
• Interception of communications links
• Electronic emanations
• Other threats to confidentiality not bulleted above
Integrity
• Input errors
• Program errors
• Operator errors
• Manipulation or suppression of input documents
• Unauthorised use of transaction facilities
• Unauthorised modification of programs
• Unauthorised modification of files
• Manipulation of job streams
• Manipulation of equipment or computer media
• Integrity problems with feeder systems
• Other threats to integrity not bulleted above

Availability
• Major disasters
• Inadequate IT contingency arrangements
• Inadequate business continuity plans
• Day-to-day system outages
• Degraded system performance
• Loss of key staff
• Theft of data, software or equipment
• Loss of data in transmission
• Viruses
• Other threats to systems/application availability not bulleted above

This second assessment should be completed as per the previous one, and from this, a qualitative and
quantitative risk assessment of current business practice can be drawn up. This then acts in two ways:

1. To allow an action plan to be formed, addressing highlighted risks in the current business practice.

2. To allow the process owner to accept the risks highlighted – it is better to know the dangers and
pitfalls of your systems, rather than blindly continue until an incident forcefully points them out to
you!

3. To allow recovery plans to be drawn up, against the eventuality of an incident happening. Note that
most computer forensics specialists expect a given organisation to suffer a major incident at least
every four years, and on average, every two years!
The risk assessment must be carried out objectively, and with the participation of all parties involved.
This usually comprises a security professional (driving the process), one or more users of the
application, key development staff, and also systems operations and administration personnel. This
requires two things; firstly active support and mandate from senior (preferably board-level)
management, and secondly active communication processes by the security professional. Basically, if
there is no high-level support of the security policy, then it will be ignored in the rush to get to the
marketplace; if there is no commitment and involvement from all parties, then there is no security!

On occasion, a business process owner may choose to accept the risks as highlighted in the assessment,
and continue operations as before. This must then be escalated appropriately, and it becomes a high-
level decision (note the advantages of securing prior commitment to security by the executive!). It is
not the role of the security professional to pass judgement on what the business may or may not do –
the security professional is rarely able to obtain the customer focus and overall view of the company to
make this decision.

An action plan should show an evolutionary approach to solving the security problems highlighted in
the assessment – it is extremely rare to obtain commitment to the revolutionary approach of starting
again from scratch. Moreover, timelines to reach the marketplace must be considered – there is no point
in having a perfectly secure system, if the customer requirement needed to be fulfilled several years
ago!

Given the risks as highlighted in the assessment, a plan must be drawn up of necessary steps to recover
from security incidents – at the very least, the more likely ones. For example, upon discovering
unauthorised access by an employee, is it best to shut down the system? Arrest the employee? Monitor
his actions, hoping to gather clues regarding the intrusion? As with security requirements, every
company will have a slightly different solution. However, without a well-formulated incident response
plan, it is hard to decide appropriate action in the heat of the moment, and when an incident occurs (or
is discovered), time is usually critical.

One of the other hot issues in security is the use of encryption. Until very recently, encryption systems
were the sole purview of the military establishment, and considered something of a “black art” by the
commercial and industrial world. In the last few years, a plethora of publicly available, low-cost
encryption systems have been published, subjected to extensive peer review, and are now being
adopted by application and system developers. Historically, any information that people have had to
send to someone else along insecure channels has been encrypted in some fashion before transmission.
Notable historic systems included alphabetic ciphers, use of inks requiring special treatment to become
readable, and of course, the Enigma rotor device, used in World War II, and analysed by Alan Turing.

In the modern world, cryptography has two main uses. Firstly, it can protect a communications channel
from unauthorised eavesdropping, and from interception modification. Secondly, it can provide non-
repudiation and authentication of the message, proving that the person who sent the message did so,
and that it has not been altered en route from sender to recipient. One of the most important uses of
encryption is in the growing on-line electronic commerce market, which is experiencing a growth rate
never before encountered in history. To understand how a company develops its Internet commerce
presence, we need to look at the 6 generations of Internet commerce development.

At time of writing, most companies are still in stages one and two, however many technology leader
companies are developing and implementing plans for fourth and fifth generation Internet commerce
centres.

1. HOME PAGE - In this first stage, a company lists its background and product information. This is
the primal stage of development, where information is static, and consists mostly of corporate and
contact information.

2. MARKET INFORMATION - In the second stage, the company will make most of its market
information available, including brochures, white papers, catalogues, configurations, price lists and so
on. It also may provide hyperlinks to some of its partners' home pages. Note: Few companies have
ventured past stage two. This type of Internet commerce centre is acting primarily as a second-stage
advertising site – it is unlikely to promote market awareness and/or generate revenue by itself, however
it can prove a low-cost method of communicating to interested customers, being primarily promoted by
conventional marketing communication.

3. EXTERNAL BUSINESS APPLICATION INTEGRATION (INTERNET) - When a company gets to

the third stage, it is an Internet intermediate. In stage three, technical manuals, a help desk and/or a
problem resolution chat line are put on the Web. At this stage, the Internet commerce centre is acting as
an information source to interested Web customers, and acting not only as second stage advertising, but
also as a support and customer information centre.

4. ORDER PROCESSING - There are two kinds of order processing. The first is simply an order form,
which is later batched into the order processing application. The second is when the order form will
edit for correct information. Later, in stage six, the order forms will go against an inventory database to
provide immediate shipping information. At this stage, the Internet commerce centre is acting as a
revenue enhancement tool, adding additional channels for interested customers to make purchases.

5. INTERNAL BUSINESS APPLICATION INTEGRATION (INTRANET) - In this stage business

applications are integrated within the company's Internet firewall. Users can place orders as well as
send purchase orders, expense reports, accounting information, and team product development. This
sees the activation of internal processes into a web-client model, eliminating manual paper-based
systems, and helping to automate day-to-day business processes. Potentially, these applications can be
extended to remote workers connecting via the Internet, given suitably robust authentication and
privacy assurance.

6. EXTERNAL BUSINESS APPLICATION INTEGRATION (INTERNET) - In stage six a company

crosses over the firewall into the unstable environment. The business-critical applications are now
participating in the company's business using the net. Relationships are established through the net, and
electronic business-to-business deals are conducted. EDI (Electronic Data Interchange) over the
Internet is now a possibility, using strong encryption systems to guarantee transaction integrity and
confidentiality. The Internet commerce centre is now a major revenue generator and business facilitator
– purchase orders are sent to clients via Internet EDI, customer support is provided via e-mail and the
web, and the possibilities of remote working, while still retaining the office IT systems infrastructure,
becomes a reality. (Note that remote working is becoming more and more significant in the USA, as the
government combats pollution and traffic congestion issues with legislation. Anyone stuck in traffic on
the M25 may like to consider how long it will be before similar measures are adopted in the UK).

One of the interesting things about the evolutionary cycle described above is that the further one
progresses, the less useful the traditional firewall model becomes. As companies reach out, sharing
their data with each other across the Internet, the “Us vs. Them” approach becomes increasingly
obsolete.

Of course, the exciting opportunities described above do rely on strong cryptographic techniques that
can be trusted implicitly, and can be used without restriction by government. Currently many
governments (including the UK government) are considering methods to restrict and limit the use of
encryption technology. Most notable is the US government, which classes strong encryption as
munitions, prohibited from export. It is interesting and instructive to note that many encryption
technology companies have been set up in other countries, in order to avoid the legal straitjackets. The
task before the government is to balance national security requirements (which seem to consist of
having the ability to decode any encrypted traffic without notification to the communicating parties)
with the growing Internet commerce market.

Finally, what really sets this book apart is its intended audience. Many books have been written,
detailing technical issues in electronic privacy and trusted systems, aimed at the technical operator, and
application developer who wishes to incorporate cryptographic techniques into their work. Few books
have attempted to de-mystify the technical jargon, and provide a management explanation and
overview of where this technology is heading, and what solutions are currently available. Written by a
veteran journalist, with many years of experience in the IT world, it provides real-world, practical
solutions for the busy manager, exploring this brave new world.

- Jon Care (jonc@netcetera.co.uk)