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)

• 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)

• 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 confidentialityintegrity-availability model described above.

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

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

• • • • • • • • • • 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. 2. To allow an action plan to be formed, addressing highlighted risks in the current business practice. 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 highlevel 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 nonrepudiation 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)

Sign up to vote on this title
UsefulNot useful