What a Security Policy Should Include

When writing a security policy, you should first perform an inventory of the resources you want to protect. Identify the users who need to access each resource, and determine the most likely place a threat to the resource might come from. With this information, you then can begin to construct a security policy that users will have to follow.

The security policy should not be something that is simply generally understood by everyone. It should be an actual written document. To remind users about the importance of security, you might want to post copies of it around the office so that they will see it on a regular basis.

A good security policy will be composed of several elements, including these:

• Risk assessment—What are you trying to protect and from whom? Identify your network assets and possible sources of problems.

• Responsibilities—Describe who in the company is responsible for handling specific matters relating to security. This can include who is authorized to approve a new user account up to items such as who will conduct investigations into security breaches.

• Proper use of network resources—State in the policy that users are not to misuse information, use the network for personal use, or intentionally cause damage to the network or information that resides on it.

• Legal ramifications—Be sure to get advice from the proper sources about any legal matters that apply to the information you store or generate on your network. Include statements to this effect in the security policy documents.

• Procedures to remedy security problems—State what procedures will be followed when a security event occurs and what actions will be taken against those who perpetrate them.

These are the five classes of vulnerability vectors:

• Hardware—This includes workstations and servers, printers, disk drives, network wiring, and

disk drives. This also includes internetworking devices such as bridges, routers, and switches.

• Software—Every piece of software you run on any computer in the network is a potential security problem. This includes programs purchased from outside vendors and software created in-house by your own programming staff. Operating systems frequently have to be patched as new bugs are discovered that give an intruder an easy way to infiltrate.

• Data—The most important asset on your network is probably the data that is generated or used by your business. You can replace software programs and operating systems. When important data, such as customer lists, sales information, or proprietary trade secrets, is compromised, this can have a significant impact on business.

• People—Users, operators, and anyone else who interacts with your network or any device attached to it is a potential security risk.

• Paperwork—Often overlooked by many, this is a very valuable resource to hackers. Passwords are written down. Reports are generated that have confidential information contained in them. Often this resource is simply thrown in a dumpster when it is no longer needed. A better approach is to shred or otherwise make it unusable before getting rid of it.

A good security policy that is understood by users will go a long way toward preventing some of the problems you can potentially encounter. Make it a point to review the policy with users periodically, such as at quarterly meetings, and be sure that users understand the responsibilities that go along with having access to the company network.

The Network As Target continue...

In this case, however, you need to be sure that the "hot spare" itself has not been compromised. Some malicious code can remain around for many months before causing problems. This is another good reason to use updated antivirus software on a regular, frequent basis.

Another way to protect servers is to use the tools that the operating system provides to protect some services. For example, you'd be a fool to place a directory on your system disk for use as an anonymous FTP site. The last thing you want is to have someone filling up all the space on your system disk. Most operating systems allow you to set quotas that define how much space a particular user account can use on a server's hard drives. Enforcing quotas can help prevent an attack that consists of consuming all the available space on a disk. In addition, you can set alarms to notify you when quotas are being used up at a rate that is faster than what you see during normal operations. It's then an easy matter to track down the source of the data coming into the server and to terminate the user process.

Additionally, protecting computers should also involve software that detects malicious code. Even home PC users are aware of the value of antivirus programs. There are so many vendors of this software that it would be pointless to attempt to list them here. However, when you do choose an antivirus program, there are some things you should consider when making a purchasing decision. For example, does the vendor respond quickly with updates to the software as new viruses are discovered? Does the software have the capability to remove the virus after it has been discovered? Does the software have the capability to scan floppy disks and files transferred to the computer through the network? Of these, the capability to quickly respond to new threats is perhaps the most important. However, your situation might dictate other factors that are more important. Note also that many firewall products now contain some type of virus-detection mechanism.

Using Tripwire

There are many programs you can use to help determine whether your system has been compromised. Tripwire is a very popular host-based DOS (HDOS) program that can be used for this purpose. Tripwire was originally developed in 1992 by Gene Kin and Dr. Eugene Spafford. The Academic Source Release (ASR) version of Tripwire can be downloaded for noncommercial use from Tripwire's Web site. In addition, Tripwire has created commercial versions of the software, including an enterprise manager program (Tripwire Manager) that uses SSL for communications and simplifies management of multiple servers and workstations.

Tripwire is based on the concept of taking a "snapshot" of system resources, such as files, directories, and, in the case of Windows NT, Registry settings. The information gathered by Tripwire is stored in a secure database and is used to compare a server later to determine whether changes have been made and what those changes were. A policy file allows the network administrator to control the types of data that Tripwire monitors and to prioritize certain events using a rule base. In addition, Tripwire can produce reports that make monitoring the system easier for administrators.

Currently, Tripwire runs on the following operating-system platforms:

• Windows NT 4.0, Windows 2000, Windows 2003, and Windows XP Professional
• Solaris (SPARC) versions 2.6, 7.0, 8.0, 9.0, and 10
• IBM AIX 4.3.3, 5.1, 5.2, and 5.3
• HP-UX 10.20, 11.0, llivl, 1 liuZ
• Several versions of Linux

Some of the things that Tripwire can monitor are specific to an operating system, whereas others (such as file types and sizes) can be monitored on all platforms. For example, here are a few of the items you can use Tripwire to monitor on Unix systems:

• Addition, deletion, or modification of files, along with file permissions, types, and sizes
• Inode number and number of links
• Owner and group IDs for files
• Modification timestamps and access timestamps

In addition, hash algorithms can be used to ensure the integrity of the contents of files. Tripwire supports several kinds of hashing algorithms, such as CRC-32, MD5, and the SHS/SHA algorithm, among others.

For Windows NT systems, the list that can be monitored includes the standard file components and things such as these:

• File attributes, such as archive, read-only, hidden, or offline
• Create and access times
• NTFS Owner SID, NTFS Group SID, and other NTFS attributes
• Addition, deletion, and modification of Registry keys and the values of those keys

These lists are not all-inclusive. For more information about acquiring an evaluation copy of Tripwire, visit the Web site www. . tripwire . com.

User Awareness and Training

Social engineering is a term used a lot lately to describe an easy method for gaining access into your network. Put quite simply, are the users of your network trained in security measures? A quick test is to simply have someone from your help desk call a user and ask him for his password. I would bet that in at least half of the cases the users will give out their passwords. A help-desk person shouldn't have to ask this type of question! Instead, if people at your help desk need to access a user account, they can notify the user that they are changing the password temporarily and will notify the user when to reset the password to a value known only to the user.

A password policy should also be in effect to ensure that common names and words are not used. Yet, one must be careful to avoid making passwords so difficult that users have a hard time remembering them. Most operating systems have the capability to keep a history list of passwords to prevent their reuse within a specified amount of time. You'll also find that you can usually set a minimum and maximum password length.

Social engineering also can involve dumpster diving. How secure are the printouts that you throw in the trash can? Do you have paper shredders (and a security policy dictating their use) in place? Even Hollywood stars know that much useful information can be obtained from a trash can! This goes not just for paper materials. When you decommission old tapes or old computer hard drives, do you take the time to destroy any data that is stored on them? It may be well and good to donate old computers to nonprofit organizations or schools, but it's also a good idea to reformat the hard drives and reinstall the operating systems before you do so. Tapes can be made useless by various means, including bulk tape erasers that zap the contents in just a few seconds.

Staying on Top of Security Issues

Your network will never be secure unless you make an effort to keep up-to-date with the latest discoveries concerning security issues. There are many good sites on the Web that you can use as resources to help you get the latest information as well as advice on how to better secure hosts and networks. Keep in mind that those who would do harm to your network are usually one step ahead of you. It's a continual catch-up game. The quicker you find out about a problem, the quicker you can take precautions to protect your network.

Using Both Hardware and Software Firewalls

Although the Windows Firewall built into Windows XP starting with Service Pack 2 provides stateful packet inspection, it only protects against inbound threats. Consequently, you should not count on it as the only protection between your computer and the Internet.

To provide a greater deal of security, you might want to use both a hardware and a software solution. Use the hardware firewall appliance as the front end of the network by attaching it to your broadband connection. Note that most SOHO and small office firewall appliances include multiport Ethernet switches, and some also include a Wi-Fi AP. Then use a software firewall package on computer(s) in your network.

Whichever you choose, keep in mind that no firewall can provide a complete solution to protect a network from outsiders. New viruses, Trojan horse programs, and the like are being created every day. All antivirus and firewall devices/software should have an update feature that you can use to download new software and virus definitions on a frequent basis. This type of service typically comes free for the first year, and then you can pay a small fee for following years.

How Do You Know That the Firewall Is Secure?

The problem with security is that the environment, either internal or external, is always changing. As soon as a bug in an OS or network application is found and exploited by mischievous persons, someone comes out with a fix. As soon as the fix is applied, something else crops up. When you set up a firewall to protect yourself from those who might do harm to your network, you must perform tests to be sure that it does what you think it does.

The problem with testing, however, is that you already know what you are looking for when you create and execute the test. It's what you don't know that can cause problems. To keep on top of things, you should continue to monitor the data collected by any auditing or logging functions the firewall provides to make sure that it is working as you expect. Look for attempts to breach the firewall and watch for unusual activity. You might find that you can stop an attack before it succeeds. Using other tools, such as Tracert, you might be able to locate the perpetrator and handle the matter using legal means.

No RFCs define what a firewall must do or how it should do it. You can contact several organizations on the Internet to get information about current firewall and security software. Appendix C, "Internet Resources for Network Administrators," contains a list of some interesting sites related to network security and firewalls that might help you decide what kind of protection you need.

Network and Protocol Analyzers Part 4

Capture Triggers

After you create a capture filter, you can begin to capture data based on it by selecting Capture, Start. When using a narrow filter to look for a specific problem that doesn't occur often, you can set up an event to notify you when a matching frame is finally detected instead of having to sit at the console and wait. To set a capture trigger, select Capture, Trigger.

The Network Monitor allows you to monitor overall traffic on the network by watching the graphs displayed in the Capture Window, and it allows you to look at specific frames to determine where problems exist. Similar to a hardware LAN analyzer, a good software LAN analyzer can be a valuable tool for determining network use or for troubleshooting specific protocol problems. Still, to view all network traffic, you'll need another network monitor, such as that included with Microsoft's SMS, or a third-party-product.

Other Software LAN Analyzer Products

The fast microprocessors used in today's desktop and laptop computers allow for a wide range of software products to provide functionality that used to be primarily the domain of hardware-based analyzers. The preceding section looked at the built-in LAN monitoring tools available as part of the Windows operating system. However, a large market exists for software-based LAN analyzers, and they are usually much less expensive to deploy than their hardware counterparts.

Before investing in a software LAN analyzer, you should try before you buy. Following is a list of a few good products that allow you to either download a demonstration version or order a CD that you can use to evaluate the product before making a purchase. Don't buy the first product you look at. Instead, determine whether the documentation is up to par, whether the company provides good technical support, and, most important, whether the product is intuitive and easy to use.

Ethertest LAN Analyzer for Windows—This LAN analyzer from Frontline Test Equipment, Inc. (FTE), runs on systems ranging from Windows 95 to Windows XP. You can download a demo of this product at www f t e com. If you're in the process of deploying Bluetooth technology in your LAN, you might also want to download a demo of FTE's SerialBlue Bluetooth.

Observer, Expert Observer, and Observer Suite from Network Instruments—These products perform everything from simple network protocol analysis to SNMP (Simple Network Management Protocol), RMON (Remote Monitoring) console, and probe reporting. The software also runs on systems ranging from Windows 2000 to Windows Server 2003. Additionally, the Observer product line also includes support for IEEE 802.11a and 802.11b wireless networking.

Wildpackets—An assortment of network analysis tools can be downloaded, ranging from the highly rated EtherPeek LAN analysis tool to AiroPeek for wireless LAN analysis. You can download demos for these and other valuable tools by visiting www . wild p a ck et s .com.

This is only a short list of the large number of products available, and they are not rated as to which is best because it depends on your needs and how your network is laid out. However, you should download the demos listed here so that you can get an idea of what you can expect from a software- based LAN analyzer. If you're going to spend money on such a product, make sure it's an informed purchase.

Hardware Analyzers

This type of instrument can cost as much as tens of thousands of dollars. Hardware analyzers, however, provide functionality in a critical situation that might not be obtainable from a software-based product. A hardware LAN analyzer can be taken to the location where a problem exists and be connected to the network to perform its functions. A hardware instrument will most likely be better able to cope with a high-speed environment, such as 100BASE-T and 1000BASE-T, than a software application that relies on a standard network adapter card to get traffic from the network medium. Hardware analyzers contain special circuitry that is used to perform many functions must faster than can be done via software, and are usually more reliable.

Another thing to consider when comparing hardware to software analyzers is that when you use a PC or a workstation to act as your LAN analyzer, it might be limited as to what the NIC can do. For example, some ordinary adapter cards have built into their firmware a function that automatically discards certain kinds of packets that contain errors. If you are trying to detect what errors are causing problems on your network while troubleshooting, a software product running on a workstation might not be able to help you.

Also, although it's true that network adapter cards can literally see every packet on the network as it zips by, that doesn't mean that the cards are capable of capturing the data and passing it up to higher- level protocols. When a card does capture all frames and pass them up the protocol stack, it is operating in promiscuous mode. Some cards are designed specifically not to do this, so be sure to check the documentation that comes with the one you might want to use on a workstation that will host LAN monitoring software.

Hardware analyzers are expensive because they usually do a very good job and are designed specifically for what they do. Most have built-in disk drives to store captured data, including a floppy disk drive that can be used to exchange data with PC workstations. Be sure that the instrument has enough memory to buffer significant amounts of data. Another feature to look for is a good display so that you can monitor utilization graphically as well as display the contents of individual frames.

A hybrid analyzer that combines the best of the hardware and software products is also available. This type of device implements the capturing and filtering functions in a hardware component that attaches to a workstation, which then provides the display and storage functions. The hardware component has dedicated circuitry and processing power to capture data from the wire, and a software application on the PC is used to filter, calculate, and display the data. This type of device can be external to the PC, although some are implemented as cards that plug into the system's bus.

Develop a Highly Usable VR System - and Do It Yesterday!" Continue...

Phase 2: Hello, I'm Your Avatar

A prototype system was created and demonstrated to trainers and prospective trainees at all three maritime training sites. In use each trainee begins by adopting a role - captain, chief engineer, first mate and so forth. They then put on a lightweight set of combined headphones and microphone to afford communication with other avatars and the trainer. Once a minimum of two trainees have entered the system, the trainer, who has been overseeing this process, starts the training scenario (Fig. 6.1). Avatars are able to communicate with one another by way of (virtual) radio and (virtual) telephone and are able to walk and run, open doors and pick up and operate fire extinguishers.

The trainer (or trainers) have all these facilities but have the God-like powers of being able to watch all trainees simultaneously, set fires and so forth as can be seen in Fig. 3.2. The training itself consists of working through a detailed scenario, usually drawn from a real world incident, which requires the trainees to role play and collectively deal with the problems which arise during the course of playing it out. At the end of the training, the trainer will debrief those involved and may use the play-back facilities of the DISCOVER CVE to illustrate particular points.

Demonstrations of the software and simple hands-on tasks were followed by interviews and questionnaires. Our intention was to give potential end users a clearer impression of what a CVE is, how it could be used, to elicit feedback which could be used to refine requirements. We had also evidently managed to convince our developers of the importance of usability issues, since they were particularly keen to have any problems of this sort identified. However, our intentions were confounded by the very prominence which usability assumed in these initial trials. Eager for early feedback, and understandably reluctant to undertake development which might be misdirected, our technologists delivered a prototype just as soon as the software could be run independently of its development environment. This meant that although a reasonable impression could be gained of the functionality which could be offered, user interaction was in a very immature state. As a consequence, finer grain usability issues, for example the ability to identify the focus of an avatar's gaze, were obscured by larger difficulties such as moving through the environment. Equally users could not be induced to speculate in depth about how the system might be used, or how training delivered through such a medium might relate to existing practice. For example, it is difficult to convince the captain of one of the world's largest passenger vessels of the possibilities of the new medium after difficulty with movement control has "trapped" him for some minutes in a corner of the virtual bridge. However, some indications did emerge of the type of usage envisaged in each training context, and much debate was triggered about the detailed design features which would be necessary to support these.

The developers now urgently required a unified, detailed, concrete design specification which would nonetheless support each intended context of use. This was to be achieved by means of a workshop involving each of the three maritime organizations. (There was only one offshore organization in the project, whose requirements were relatively unified and straightforward.)

Phase 3: Virtual Reality Meets Paper and Pen

At this two-day event, trainers from the three organizations met with the representatives from one of the software developer organizations and two facilitators from the requirements team.

The agenda was very simple: to agree the detailed functionality of the maritime simulator and how it was expected to be used. We adapted elements of Contextual Design (Holtzblatt and Beyer, 1998) to facilitate these processes, principally a variant of the affinity diagram technique, which supports the identification of common themes from a mass of contextual data. We began by asking each training organization to revisit what they wanted of DISCOVER in terms of the "w" words (familiar to user-centred design practitioners), i.e. why, when, who, where and of course, how. As each organization described their needs we recorded each issue or explicit requirement on a Post-IT® note. At the end of the process we had gathered over 400 Post-ITs of which approximately 10 per cent were subsequently discarded as duplicates or irrelevant on closer inspection.

The trainers were then invited to create an affinity model which required them to sort the requirements/issues into logical groups: emerging groupings included the layout and configuration of the virtual ship, the appearance and functionality of the avatars and the context of use of the completed system. Throughout this process the software designer helped ground the requirements in reality. Informal discussion with the three trainers afterwards revealed that they thought that the day had gone well. The use of the Post-Its and their grouping was a familiar technique from other contexts, and had fostered engagement and apparent consensus. At the end of the first day we had succeeded in co-constructing an affinity model and subsequently a communications model and an artefact/physical model (ibid.) of the environment to be created.

Communication with Coders

In contrast to the wireframe being overly defined for the clients when discussing overall structure of the site in Project A, we found that compositional elements of pages were not defined in sufficient detail to communicate with the software development team responsible for implementation. The development teams' approach was to identify logical units within each page so that common software classes and routines could be identified early on. This entailed marking up the prototypes with regions regarded as logical units, and numbering them. Clearly this added another level of detail to the wireframe which we had not initially envisioned when designing it. Since the wireframe was developed in HTML using layers it was not technically possible to annotate the prototype itself, so paper copies of the pages were used and marked up. As development progressed, and the prototype was refined due to client requests and an improved understanding of the user requirements, it became increasingly difficult to maintain a link between the regions marked on the paper copies and the evolving prototype.

Given the lack of fidelity in the prototype required by the software coders, use cases were written to specify the user-system interaction in more detail. Use cases are a software development representation that describes the "dialogue" between a user and system in a task context. For example, in the task context of "Write an e-mail", the dialogue could be: (1) The user creates a new message; (2) The system displays an empty message window; (3) The user gets a recipient from the address book; (4) The system checks the validity of the address, and so on. These use cases were specified by use-case writers and then taken by a test team who developed test plans to better support the implementation effort. These additional specifications referred directly to particular parts of the wireframe — for example, the use cases detailed particular user-system interactions, while the test plans relied on both the wireframes and use cases. Maintaining the consistency between these multiple representations became more difficult as more and more people came to rely on the wireframe.

In terms of our dimensions, our prototype did not allow for sufficient detail in its description when the target audience was the software development team. Moreover, the unchanging paper copies became further out of synch with the evolving prototype as development progressed thus imposing an overhead on the communication between the HCI and development teams. Essentially the development team needed a view of the prototype that was at a greater level of detail than our own.

The same problem occurred again in Project B where the prototype was used as a means of communication between the HCI team and the software coders. As in Project A the prototype was not detailed enough to meet the needs of the coders. Therefore we adopted use cases to further detail the requirements on the functionality. Initially HCI was responsible for specifying the use cases. However, at a later stage the system developers took on this responsibility to make sure the use cases were detailed enough to support them in their work. The use cases together with the wire frame were used to drive the development process and to identify issues that needed to be resolved.