Basics of Encryption

Introduction:

The incredible growth of the Internet has excited businesses and consumers alike with its promise of changing the way we live and work. But a major concern has been just how secure the Internet is, especially when you're sending sensitive information through it.

Let's face it, there's a whole lot of information that we don't want other people to see, such as:

Credit-card information

Social Security numbers

Private correspondence

Personal details

Sensitive company information

Bank-account information

Information security is provided on computers and over the Internet by a variety of methods. A simple but straightforward security method is to only keep sensitive information on removable storage media like floppy disks. But the most popular forms of security all rely on encryption, the process of encoding information in such a way that only the person (or computer) with the key can decode it.

Computer encryption is based on the science of cryptography, which has been used throughout history. Before the digital age, the biggest users of cryptography were governments, particularly for military purposes. The existence of coded messages has been verified as far back as the Roman Empire. But most forms of cryptography in use these days rely on computers, simply because a human-based code is too easy for a computer to crack.

Most computer encryption systems belong in one of two categories:

Symmetric-key encryption

Public-key encryption

Symmetric Key

In symmetric-key encryption, each computer has a secret key (code) that it can use to encrypt a packet of information before it is sent over the network to another computer. Symmetric-key requires that you know which computers will be talking to each other so you can install the key on each one. Symmetric-key encryption is essentially the same as a secret code that each of the two computers must know in order to decode the information. The code provides the key to decoding the message. Think of it like this: You create a coded message to send to a friend in which each letter is substituted with the letter that is two down from it in the alphabet. So "A" becomes "C," and "B" becomes "D". You have already told a trusted friend that the code is "Shift by 2". Your friend gets the message and decodes it. Anyone else who sees the message will see only nonsense.

Public-key encryption

The main problem in Symmetric is the transmission of private key. If user A wants to send a encrypted file to user B, user B should have user A’s private key.For this user A have to send his private key to user B.The transmission of the private key is vulnerable. For this they came to a new concept called Public-key encryption.

Public-key encryption uses a combination of a private key and a public key. The private key is known only to your computer, while the public key is given by your computer to any computer that wants to communicate securely with it. To decode an encrypted message, a computer must use the public key, provided by the originating computer, and its own private key. A very popular public-key encryption utility is called Pretty Good Privacy (PGP),

To implement public-key encryption on a large scale, such as a secure Web server might need, requires a different approach. This is where digital certificates come in. A digital certificate is basically a bit of information that says that the Web server is trusted by an independent source known as a certificate authority. The certificate authority acts as a middleman that both computers trust. It confirms that each computer is in fact who it says it is, and then provides the public keys of each computer to the other.

A popular implementation of public-key encryption is the Secure Sockets Layer (SSL). Originally developed by Netscape, SSL is an Internet security protocol used by Internet browsers and Web servers to transmit sensitive information. SSL has become part of an overall security protocol known as Transport Layer Security (TLS).

In your browser, you can tell when you are using a secure protocol, such as TLS, in a couple of different ways. You will notice that the "http" in the address line is replaced with "https," and you should see a small padlock in the status bar at the bottom of the browser window.

SSL operation:

Public-key encryption takes a lot of computing, so most systems use a combination of public-key and symmetry. If a ssl session is established the client computer will generate a public key and private key. the server already have a public key(which ssl certificate issued by a CA) and a private key.

SERVER

Client machine

Server Public KEY

Server private KEY

client Public KEY

client private KEY

Once the ssl session enabled, the next process is to exchange the key. We need a public key to decrypt the data encrypted by the private key.

The first process is to exchange the public keys’s.

SERVER

Client machine

Server Public KEY

Server private KEY

client Public KEY

client private KEY

So now the client will have server’s public key, and the server will have client’s public key. So server can decrypt client’s data and client can decrypt server’s data.

SERVER

Client machine

Server Public KEY

Server private KEY

client Public KEY

client private KEY

Server Public KEY

client Public KEY

Now the encryption can be attained.

HOW SSL TECHNOLOGY USES ROOT CERTIFICATES IN THE ENCRYPTION PROCESS

When connecting to a web server over SSL, a visitor's browser decides whether or not to trust the website's SSL certificate based on which CA issued the actual SSL certificate. To determine this, the browser looks at its list of trusted issuing authorities -- represented by a collection of Trusted Root CA certificates added into the browser by the browser vendor.

Like SSL certificates, root certificates also have a public and private key pair used to encrypt and decrypt information that is sent between two devices. The private key of the root certificate is heavily guarded and kept in the certificate provider's secure data center; while the public key of the root certificate is given to browser and application manufacturers to be added to their list of trusted roots. Embedding the public key into the browser or application allows the software to automatically recognize and trust any SSL or client certificate that has been signed by that root certificate.

The more browsers, web servers and applications that a certificate provider embeds their root certificates in, the higher their certificate "ubiquity" is. Certificate ubiquity is a term that essentially means "the percentage of the most popular browsers, web servers, and applications that inherently recognize and trust the providers root certificate." For example, COMODO maintains 99.3% browser ubiquity in the marketplace, which means that all comodo certificates will be recognized and trusted by all the most popular browsers, web servers and applications available today.

Phishing

It is becoming increasingly common to tune in to the news or load your favorite news Web site and read about yet another Internet e-mail scam. An e-mail scam is a fraudulent e-mail that appears to be from a legitimate Internet address with a justifiable request — usually to verify your personal information or account details. One example would be if you received an e-mail that appears to be from your bank requesting you click a hyperlink in the e-mail and verify your online banking information. Usually there will be a repercussion stated in the e-mail for not following the link, such as "your account will be closed or suspended". The goal of the sender is for you to disclose personal and (or) account related information. This type of e-mail scam is also called phishing.

phishing (fish´ing) (n.) The act of sending an e-mail to a user falsely claiming to be an established legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft. The e-mail directs the user to visit a Web site where they are asked to update personal information, such as passwords and credit card, social security, and bank account numbers, that the legitimate organization already has. The Web site, however, is bogus and set up only to steal the user’s information.

How to Spot A Phishing Scam:

At first glance, it may not be obvious to the recipients that what is in their inbox is not a legitimate e-mail from a company with whom they do business. The "From" field of the e-mail may have the .com address of the company mentioned in the e-mail, and the clickable link may also appear to be taking you to the company's Web site, but will in fact take you to a spoof Web site. Looks can be deceiving, but with phishing scams the e-mail is never from who is appears to be!

Key Terms To Understanding phishing:

phishing

The act of sending an e-mail to a user falsely claiming to be an established legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft.

spear phishing

A type of phishing attack that focuses on a single user or department within an organization.

spyware

Any software that covertly gathers user information through the user's Internet connection without his or her knowledge

security

In the computer industry, refers to techniques for ensuring that data stored in a computer cannot be read or compromised by any individuals without authorization.

Phishing e-mails will contain some of these common elements: (view screen capture above from Eudora)

1. The "From Field" appears to be from the legitimate company mentioned in the e-mail. It is important to note, however, that it is very simple to change the "from" information in any e-mail client. While we're not going to tell you how, rest assured it can be done in a matter of seconds!

2. The e-mail will usually contain logos or images that have been taken from the Web site of the company mentioned in the scam e-mail.

3. The e-mail will contain a clickable link with text suggesting you use the inserted link to validate your information. In the image you will see that once the hyperlink is highlighted, the bottom left of the screen shows the real Web site address to which you will go. Note that the hyperlink does NOT point to the legitimate Citibank Web site URL.

In this instance, the text you click is "here", However, this may also state something like "Log-in to Citibank" or "www.citibank.com/secure" to be even more misleading. This clickable area is only text and can be changed to anything the sender wants it to read.

Additionally, you may spot some of these elements that did not appear in this particular scam:

Logos that are not an exact match to the company's logo, spelling errors, percentage signs followed by numbers or @ signs within the hyperlink, random names or e-mail addresses in the body of the text, or even e-mail headers which have nothing to do with the company mentioned in the e-mail.

Who Is Behind the Phishes & Why

The people behind phishing e-mails are scam artists. They literally send out millions of these scam e-mails in the hopes that even a few recipients will act on them and provide their personal and financial information. Anyone with an e-mail address is at risk of being phished. Any e-mail address that has been made public on the Internet (posting in forums, newsgroups or on a Web site) is more susceptible to phishing as the e-mail address can be saved by spiders that search the Internet and grab as many e-mail addresses as they can. This is why phishing is profitable for scammers; they can cheaply and easily access millions of valid e-mail addresses to send these scams to.

Common (Phish) Sense

After reading this far, we hope that you will be able to spot a phishing e-mail without too much difficulty. The e-mail represented above is just a sample; phishing e-mails can appear to be from any bank, PayPal, eBay, credit card companies, an online retail store — basically from anywhere a person may have registered for an account, and usually would have supplied financial information when registering.

The golden rule to avoid being phished is to never ever click the links within the text of the e-mail. Always delete the e-mail immediately. Once you have deleted the e-mail then empty the trash box in your e-mail client as well. This will prevent "accidental" clicks from happening as well. If, for some really odd reason you have this nagging feeling that this could just possibly be a legitimate e-mail and nothing can convince you otherwise, you still need to adhere to the golden rule and not click the link in the message. For those truly worried that an account may be in jeopardy if you do not verify your information, you need to open your Web browser program of choice and type the URL to the Web site in the address field of your browser and log on to the Web site as you normally would (without going through the e-mail link as a quick route). This will provide you with accurate information about your account and allow you to completely avoid the possibility of landing on a spoof Web site and giving your information to someone you shouldn't.

Now that you know how to avoid being phished, there is still the question of what to do about phishing e-mails should you be a recipient of them. First of all, you can visit the Web site of the company from whom the e-mail appears to be from and take the time to notify them of the suspicious e-mail. Many companies do want to know if their company name is being used to try and scam people, and you'll find scam and spoof reporting links within some of these Web sites. Additionally, you can report phishing to the Federal Trade Commission (FTC), and depending on where you live, some local authorities may also accept Internet phishing scam reports. Lastly, you can also send details of a phishing scam to to the Anti-Phishing Working Group who is building a repository/database of common scams to help inform people of the risks.

The New Phish - Spear Phishing

As with all malicious code, once a small percentage of the population starts to catch on, the perpetrators find ways to make the attack a little different, and this case, make the phish harder to net. The newest type of phishing scam is one that focuses on a single user or a department within an organization. The Phish appears to be legitimately addressed from someone within that company, in a position of trust, and request information such as login IDs and passwords. Spear phishing scams will often appear to be from a company's own human resources or technical support divisions and may ask employees to update their username and passwords. Once hackers get this data they can gain entry into secured networks. Another type of spear phishing attack will ask users to click on a link, which deploys spyware that can steal data.

Did You Know...

The word phishing comes from the analogy that Internet scammers are using e-mail lures to fish for passwords and financial data from the sea of Internet users. The term was coined in 1996 by hackers who were stealing AOL Internet accounts by scamming passwords from unsuspecting AOL users. Since hackers have a tendency to replacing "f" with "ph" the term phishing was derived.

Linux History

The history of computer operating systems starts in the 1950s, with simple schemes for running batch programs efficiently, minimizing idle time between programs. A batch program is one that does not interact with the user at all. It reads all its input from a file (possibly a stack of punch cards) and outputs all its output to another file (possibly to a printer). This is how all computers used to work.

Then, in early 1960s, interactive use started to gain ground. Not only interactive use, but having several people use the same computer at the same time, from different terminals. Such systems were called time-sharing systems and were quite a challenge to implement compared to the batch systems.

During the 1960s there were many attempts at building good time-sharing systems. Some of these were university research projects, others were commercial ones. One such project was Multics, which was quite innovative at the time. It had, for example, a hierarchical file system, something taken for granted in modern operating systems.

The Multics project did not, however, progress very well. It took years longer to complete than anticipated and never got a significant share of the operating system market. One of the participants, Bell Labs, withdrew from the project. The Bell Labs people who were involved then made their own operating system and called it Unix.

Unix was originally distributed for free and gained much popularity in universities. Later, it got an implementation of the TCP/IP protocol stack and was adopted as the operating system of choice for early workstations.

By 1990, Unix had a strong position in the server market and was especially strong in universities. Most universities had Unix systems and computer science students were exposed to them. Many of them wanted to run Unix on their own computers as well. Unfortunately, by that time, Unix had become commercial and rather expensive. About the only cheap option was Minix, a limited Unix-like system written by Andrew Tanenbaum for teaching purposes. There was also 386BSD, a precursor NetBSD, FreeBSD, and OpenBSD, but that wasn't mature yet, and required higher end hardware than many had at home.

Into this scene came Linux, in October, 1991. Linus Torvalds, the author, had used Unix at the University of Helsinki, and wanted something similar on his PC at home. Since the commercial alternatives were way too expensive, he started out with Minix, but wanted something better and soon started to write his own operating system. After its first release, it soon attracted the attention of several other hackers. While Linux initially was not really useful except as a toy, it soon gathered enough features to be interesting even for people uninterested in operating system development.

Linux itself is only the kernel of an operating system. The kernel is the part that makes all other programs run. It implements multitasking, and manages hardware devices, and generally enables applications to do their thing. All the programs that the user (or system administrator) actually interacts with are run on top of the kernel. Some of these are essential: for example, a command line interpreter (or shell), which is used both interactively and to write shell scripts (corresponding to .BAT files).

Linus did not write these programs himself, and used existing free versions instead. This reduced greatly the amount of work he had to do to get a working environment. In fact, he often changed the kernel to make it easier to get the existing programs to run on Linux, instead of the other way around.

Most of the critically important system software, including the C compiler, came from the Free Software Foundation's GNU project. Started in 1984, the GNU project aims to develop an entire Unix-like operating system that is completely free. To credit them, many people like to refer to a Linux system as a GNU/Linux system. (GNU has their own kernel as well.)

During 1992 and 1993, the Linux kernel gathered all the necessary features it required to work as a replacement for Unix workstations, including TCP/IP networking and a graphical windowing system (the X Window System). Linux also received plenty of industry attention, and several small companies were started to develop and distribute Linux. Dozens of user groups were founded, and the Linux Journal magazine started to appear in early 1994.

Version 1.0 of the Linux kernel was released in March, 1994. Since then, the kernel has gone through many development cycles, each culminating in a stable version. Each development cycle has taken a year or three, and has involved redesigning and rewriting large parts of the kernel to deal with changes in hardware (for example, new ways to connect peripherals, such as USB) and to meet increased speed requirements as people apply Linux to larger and larger systems (or smaller and smaller ones: embedded Linux is becoming a hot topic).

From a marketing and political point of view, after the 1.0 release the next huge step happened in 1997, when Netscape decided to release their web browser as free software (the term 'open source' was created for this). This was the occasion that first brought free software to the attention of the whole computing world for the time. It has taken years of work since then, but free software (whether called that or open source) has become not only generally accepted but also often the preferred choice for many applications.

Social phenomenon

Apart from being a technological feat, Linux is also an interesting social phenomenon. Much through Linux, the free software movement has broken through to general attention. On the way, it even got an informal marketing department and brand: open source. It is baffling to many outsiders that something as successful as Linux could be developed by a bunch of unorganized people in their free time.

The major factor here is the availability of all the source code to the system, plus a copyright license that allows modifications to be made and distributed. When the system has many programmers among its users, if they find a problem, they can fairly easily fix it. Additionally, if they think a feature is missing, they can add it themselves. For some reason, that is something programmers like to do, even if they're not paid for it: they have an itch (a need), so they scratch (write the code to fill the need).

It is necessary to have at least one committed developer who puts in lots of effort. After a while, however, once there are enough programmer-users sending small changes and improvements, you get a snowball effect: lots of small changes result in a fairly rapid total development speed, which then attracts more users, some of which will be programmers. This then results in more small changes and improvements sent in by users, and so on.

For operating system development specifically, this large group of programmer-users results in two important types of improvements: bug fixes and device drivers. Operating system code often has bugs that only occur rarely and it can be difficult for the developers to reproduce them. When there are thousands or more users who are also programmers, this results in a very effective testing and debugging army.

Most of the code volume in Linux is device drivers. The core functionality, which implements multitasking and multiuser functionality, is small in comparison. Most device drivers are independent from each other, and only interact with the operating system core via well defined interfaces. Thus, it is fairly easy to write a new device driver without having to understand the whole complexity of the operating system. This also allows the main developers to concentrate on the core functiionality, and they can let those people write the device drivers who actually have the devices.

It would be awkward just to store the thousands of different sound cards, Ethernet cards, IDE controllers, motherboards, digital cameras, printers, and so on that Linux supports. The Linux development model is distributed, and spreads the work around quite effectively.

The Linux model is not without problems. When a new device gets on the market, it can take a few months before a Linux programmer is interested enough to write a device driver. Also, some device manufacturers, for whatever reason, do not want to release programming information for their devices, which can prevent a Linux device driver to be written at all. Luckily, with the growing global interest in Linux such companies become fewer in numbers.

What it is

Linux is a Unix-like multitasking, multiuser 32 and 64 bit operating system for a variety of hardware platforms and licensed under an open source license. This is a somewhat accurate but rather brief description. I'll spend the rest of this article expounding on it.

Being Unix-like means emulating the Unix operating system interfaces so that programs written for Unix will work for Linux merely by re-compiling. It follows that Linux uses mostly the same abstractions as the Unix system. For example, the way processes are created and controlled is the same in Unix and Linux.

There are a number of other operating systems in active use: from Microsoft's family of Windows versions, through Apple's MacOS to OpenVMS. Linux's creator, Linus Torvalds, chose Unix as the model for Linux partly for its aesthetic appeal to system programmers, partly because of all the operating systems he was familiar with, it was the one he knew best.

The Unix heritage also gives Linux the two most important features: multitasking and multiuser capabilities. Linux, like Unix, was designed from the start to run multiple processes independently of each other. Implementing multitasking well requires attention at every level of the operating system. It is hard to add multitasking to an operationg system afterwards. That's why the Windows 95 series and MacOS (before MacOS X) did multitasking somewhat poorly: multitasking was added to an existing operating system, not designed into a new one. That's also why the Windows NT series, MacOS X, and Linux do multitasking so much better.

A good implementation of multitasking requires, among other things, proper memory management. The operating system must use the memory protection support in the processor to protect running programs from each other. Otherwise a buggy program (that is, most any program) may corrupt the memory area of another program, or the operating system itself, causing weird behavior or a total system crash, with likely loss of data and unsaved work.

Supporting many concurrent users is easy after multitasking works. You label each instance of a running program with a particular user and prevent the program from tampering with other user's files.

Portable and scalable

Linux was originally written for an Intel 386 processor, and naturally works on all successive processors. After about three years of development, work began to adapt (or port) Linux to other processor families as well. The first one was the Alpha processor, then developed and sold by the Digital Equipment Corporation. The Alpha was chosen because Digital graciously donated a system to Linus. Soon other porting efforts followed. Today, Linux also runs on Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 and CRIS processors. (See kernel.org for details.)

Most of those processors are not very common on people's desks. For example, S/390 is IBM's big mainframe architecture. Here, mainframe means the kind of computer inside of which you can put your desk, rather than the kind that fits on your desk.

Some of those processors are 32 bit, like the Intel 386. Others are 64 bit, such as the Alpha. Supporting such different processors has been good for Linux. It has required designing the system to use proper modularity and good abstractions and this has improved code quality.

The large variety of supported processors also shows off Linux's scalability: it works everything from very small systems, such as embedded computers, handheld devices, and mobile phones, to very large systems, such as the IBM mainframes.

Using clustering technology, such as Beowulf (beowulf.org), Linux even runs on supercomputers. For example, the US Lawrence Livermore National Laboratories bought a cluster with 1920 processors, resulting in one of the five fastest supercomputers in the world with a theoretical peak performance of 9.2 teraFLOPS or 9.2 trillion calculations per second. (LWN article).

Using Linux

The operating system itself is pretty boring to most people. Applications are necessary so to get things done. Traditionally, Linux applications have been the kinds of applications used with Unix: scientific software, databases, and network services. Also, of course, all the tools programmers want for their craft.

Much of such software seems rather old-fashioned by today's desktop standards. User interfaces are text based, or they might not exist at all. Indeed, most software has usually been non-interactive and has been of the command line, batch processing variety. Since most users have been experts in the application domain, this has been good enough.

Thus, Linux first found corporate employment as a file server, mail server, web server, or firewall. It was a good platform for running a database, with support from all major commercial database manufacturers.

In the past few years Linux has also become an interesting option on the user friendly desktop front. The KDE (kde.org) and Gnome (gnome.org) projects develop desktop environments and applications that are easy to learn (as well as effective to use). There is now plenty of desktop applications which people with Windows or MacOS experience will have no difficulty using.

There is even a professional grade office software package. OpenOffice (openoffice.org), based on Sun's StarOffice, is free, fully featured, and file compatible with Microsoft Office. It includes a word processor, spreadsheet, and presentation program, competing with Microsoft's Word, Excel, and Powerpoint.

Linux distributions

To install Linux, you have to choose a Linux distribution. A distribution is the Linux kernel, plus an installation program, plus some set of applications to run on top of it. There are hundreds of Linux distributions, serving different needs.

All distributions use pretty much the same actual software, but they are different in which software they include, which versions they pick (a stable version known to work well or the latest version with all the bells and whistles and bugs), how the software is pre-configured, and how the system is installed and managed. For example, OpenOffice, Mozilla (web browser), KDE and Gnome (desktop environments), and Apache (web server) will all work on all distributions.

Some distributions aim to be general purpose, but most of them are task specific: they are meant for running a firewall, a web kiosk, or meant for users within a particular university or country. Those looking for their first Linux experience can concentrate on the three biggest general purpose distributions: Red Hat, SuSE, and Debian.

The Red Hat and SuSE distributions are produced by companies by the same names. They aim at providing an easy installation procedure, and for a pleasant desktop experience. They are also good as servers. Both are sold in boxes, with an installation CD and printed manual. Both can also be downloaded via the network.

The Debian distribution is produced by a volunteer organization. It's installation is less easy: you have to answer questions during the installation the other distributions deduce automatically. Nothing complicated as such, but requiring understanding of and information about hardware most PC users don't want to worry about. On the other hand, after installation, Debian can be upgraded to each new release without re-installing anything.

The easiest way to try out Linux is to use a distribution that works completely off a CD-ROM. This way, you don't have to install anything. You merely download the CD-ROM image from the net and burn it on a disk, or buy a mass-produced one via the net. Insert disk in drive, then reboot. Not having to install anything on the hard disk means you can easily switch between Linux and Windows. Also, since all Linux files are on a read-only CD-ROM, you can't break anthing by mistake while you're learning.

Build a Floppy Firewall

Here's how to turn an unused PC into a packet-filtering firewall using a package called floppyfw. The firewall boots off a single floppy, runs completely in RAM, and uses ipchains for the filter rules. It also does IP masquerading, port forwarding, and can log to a remote host using syslog. All this in a machine with as little as 8 MB of RAM and no hard drive!

It is a Linux "screening router with firewall capabilities". It boots a Linux kernel and comes with a minimal set of tools to get the job done. If you think about it, that's actually a feature. If a bad guy were to get into your firewall machine somehow, there won't be much for him to use against you. And since we're running completely on a RAM disk, a simple reboot from the floppy will restore the system to its original state.

As with many Linux projects, floppyfw has a do-it-yourself aspect. But I'll show you where I found a set of almost-ready-to-run filter rules, so you can quickly set up your own firewall.
Hardware

You probably have a suitable machine sitting around (or enough parts to build one). You will need a 386 or better, with:
At least 8-MB RAM
3.5" floppy drive
Video card
Keyboard
video monitor

Note that if you're going to run "headless", you'll only need the keyboard and monitor for setup and testing.

Install a pair of network cards. The following types are supported by floppyfw:
3Com 3c509
NE2000 compatibles
Tulip-based
Intel EtherExpress PCI

Make sure each card has its own IRQ and memory address. That's simple to set if your network cards have jumpers on them. I used a pair of 3Com 3c509 cards. The first time I booted the machine, both cards came up at IRQ 10 and 0x300. I fixed that problem using a DOS utility from 3Com called 3C5X9CFG.EXE. Make a bootable DOS floppy, copy the utility onto it, and (with both cards installed) run it. Select a card, then auto-configure to have it choose a new IRQ and memory address. Do this for both cards, and remember to save the new settings. I found 3C5X9CFG.EXE on EtherDisk 4.3; the newest EtherDisk is available on the 3Com Web site: http://www.3com.com.

Software
Making the floppyfw boot floppy is simple. Download the latest stable image from:
http://www.zelow.no/floppyfw/download/
(As of this writing, 1.0.5 is the current image). Then write the image to a floppy:
# dd if=floppyfw-1.0.5.img of=/dev/fd0 bs=72k

Configuration:
This floppy disk is in DOS (FAT) format. Before you can boot it, you'll need to take it to some other machine and edit the config files. I prefer to use Linux mtools, like this:
$ cd /tmp
$ mcopy a:config
$ vi config
$ mcopy config a:

If you need to use another operating system, I understand you can edit these files with NotePad.
There are actually five floppyfw configuration files:
config (main configuration)
firewall.ini (filter rules)
modules.lst (additional ip_masq modules)
syslinux.cfg (kernel boot parameters)
syslog.cfg (syslog config, such as /etc/syslog.conf)

You probably won't need to touch syslinux.cfg or modules.lst at all. So I'll discuss the main file, config. In the interest of clarity, I've stripped out most of the comments. Most of the values are fairly obvious anyway, except maybe for the switches near the end of the file:
OPEN_SHELL controls shell access (/bin/ash) at the console. If your machine has less than 12MB of RAM, set ONLY_8M to "y". USE_SYSLOG determines whether syslogd runs or not, and SYSLOG_FLAGS are the flags passed to syslogd when it does start.

Listing 1 contains my config file. By the way, I wasn't able to get DHCP to work with my cable provider. They seem to have some funky, non-standard DHCP server. Instead, I set things up as if I had a static IP address. It's been working for two years without a problem. Your mileage may vary.

Filter Rules:
Now, let's have a look at firewall.ini. The original file that floppyfw comes with only sets up basic masquerading and rejects a couple of ports. Because we're building a firewall, we need to modify it. However, creating a comprehensive set of filter rules can be a big job. Logically, we want to close off all the ports and only create openings for services we want to use. I was relieved to find that most of this work has already been done by someone else.

I started with the ipchains example file from Robert L. Ziegler's Web site:
http://linux-firewall-tools.com/linux/faq/index.html
Ziegler is also the author of Linux Firewalls (New Riders Publishing, ISBN: 0735709009). His rules are very well commented, explaining in detail what each set is intended to do. When I actually needed to open ports, these comments were invaluable.
The ipchains rules I started with are available here:
http://linux-firewall-tools.com/ftp/firewall/rc.firewall.ipchains

I recommend reading through the entire file first; you don't want to use it as is! There are even some sections with alternative paragraphs, marked with the word "OR". One or the other of the paragraphs is meant to be used, but not both. To activate a section, simply uncomment it.
With a file this large and a limited amount of space on the floppy disk, it might be useful to delete the sections you think you will never use. Of course, it's probably also wise to keep a spare original around just in case. Once you've got a working configuration written to floppy, you should make a few copies of that too, in case the original wears out.

The firewall.ini provided in Listing 2 is one I've modified for floppyfw. To avoid making too many global edits and possibly damaging one or more rules, I made some simple variable substitutions near the top of the file, passing values from floppyfw variables into the appropriate variables used by Ziegler. In a few cases, when there wasn't a handy variable to use, I set the value directly.

Listing 2 should give you an idea what I did to open ports to allow clients on my internal network to access the usual essential services: DNS, SMTP, POP, NNTP, TELNET, SSH, FTP, HTTP, and WHOIS. Note that I typically wouldn't have opened the POP port, but I use fetchmail to retrieve mail from a remote provider. If you're nervous about someone snooping your mail while it's being pulled down, fetchmail has a neat feature that lets you first establish an SSH connection and then download your mail over that. In that case, you wouldn't need to open the POP port.
Logging

If you use the default syslog.cfg file, floppyfw will very happily log everything to the console. I run my firewall machine headless (i.e., without a monitor or keyboard), so that wasn't very useful to me. I want to analyze the log to keep an eye on what's happening.

So, I set up one of my internal Linux machines as a log host. To do this, make sure that your log host starts syslogd with the -r option to allow it receive messages over the network. (On a Red Hat system, for example, you'll need to edit /etc/rc.d/init.d/syslog). Then, set up your syslog.cfg, making sure to change the 192.168.1.2 to your log host's IP address. See Listing 3 for syslog.cfg.

Once you've got these few files configured and written to the floppy, you can boot up from the floppy and test some things. Make sure your internal machines can all talk to each other. Also, check whether you can access each external service for which you've opened a port. Keep an eye on /var/log/messages if you're logging remotely or on the firewall console screen if you're not. These should provide clues as to what's working. You may need to fine tune your firewall rules a bit. Just be sure to write any changes back to the floppy, or they'll be lost.

Do keep an eye on your log file. When you finally put your firewall into service, you might be surprised to see how many people are doing port scans and other strange things. Isn't it nice to have a firewall?

Simple Security Scripts from Simple Commands

For many systems administrators, the task of system security is very daunting and time consuming. I discovered early in my career that even though my work as a systems administrator never seemed to end, I could not neglect the responsibility of system monitoring and security. I started with some of the freeware options, such as Portsentry from Psionic:
http://www.psionic.com/
and Saint from World Wide Digital Security:
http://www.wwdsi.com/
and Sys Admin magazine March 2001:
http://www.sysadminmag.com/articles/2001/0103/0103b/a2.htm

I really like both of these tools, however, I wanted to have more control and flexibility with my system security and notification.

As I sifted through my never-ending supply of logs each day, I thought there must be a better way. I then realized that I was going about this task all wrong. I was neglecting my own knowledge, skill, and expertise in favor of other programs.

Through experience, I found out that when a system is cracked most crackers follow a certain modus operandi. They usually change binaries so their presence and activities are undetected. I also found out that specific files are altered and hidden directories can and usually are created.

I decided to go about the protection and detection of my system in the following ways. Nonetheless, I realize that, much like someone who wishes to enter a building, there is only so much you can do to prevent a cracker from entering your system. If the perpetrator wants on your system bad enough, they will get in. I implemented a four-tier warning program created from simple UNIX commands and anchored by Portsentry.

Tier One
I wanted to be alerted if anyone scanned my inet services or, in other words, to be alerted if someone was “checking the doors” for security holes. As most administrators do, I implemented TCP Wrappers, with a twist. I added the following to my /etc/hosts/deny:

ALL: ALL: spawn ( \
echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
Host\: %c\n\
Date\: $(date)\n\
" /bin/mail -s "From tcpd@$(uname -n). %u@%h -> %d."
admin@somewhere.com)

This script will generate an immediate notification to an account of your choice, preferably on a different system. Here’s a detailed explanation of how the script works:

• ALL: — ALL means to deny every and any IP address unless over ruled by the /etc/hosts.allow file.
• spawn — Spawn or create the actual notification.
• echo -e “\n\ — Starts the notification with a new line and then create a heading of “Connection Refused”.
• By — Uses the command uname to identify the system.
• Process — Will identify which process your system is being probed for or by (ftp, portmap, etc.).
• Host — Tries to detect the host the intrusion originates from.
• Date — The date of the attempt and the last line simply emails an account of your choice the notification in the proper format. An example follows:

TCP Wrappers: Connection Refused
By: workstation1.somewhere.com
Process: portmap (pid 321)
Host: xxx.xx.xx.xx
Date: Wed Dec 13 04:51:22 IST 2006

This script provided me with instant notification of any attempts on my system and also a log of this attempt should I need it in the future. When administering a large number of systems or a system that is probed continually, it’s wise to set up an account on a system specifically for handling security issues.

Tier Two
I also wanted to track changes in specific files and binaries using md5cksum or cksum as a fingerprint. You will want to run the script the first time on a system that has never been on a network or that you know has never been tampered with:

#!/bin/sh
/usr/bin/md5sum /etc/passwd > /root/ck_sum.txt
/usr/bin/md5sum /etc/services >> /root/ck_sum.txt
/usr/bin/md5sum /bin/ps >> /root/ck_sum.txt
/usr/bin/md5sum /bin/netstat >> /root/ck_sum.txt
/usr/bin/md5sum /bin/ls >> /root/ck_sum.txt
/usr/bin/md5sum /usr/bin/top >> /root/ck_sum.txt
/usr/bin/md5sum /etc/inetd.conf >> /root/ck_sum.txt
/usr/bin/md5sum /usr/bin/md5sum >> /root/ck_sum.txt
/usr/bin/md5sum /bin/rpm >> /root/ck_sum.txt
/usr/bin/md5sum /bin/ck_sum.scp >> root/ck_sum.txt
echo "Report from someworkstation" > /root/ck_sum.out
/usr/bin/diff /root/ck_sum.txt /root/ck_sum.org >>
/root/ck_sum.out
mail -s "check sum from someworkstation" admin@somewhere.com
< /root/ck_sum.out

The script starts by running md5sum on what I consider my important binaries and files, including the script itself. The output looks like this;

849813023732aef68bb4df674d628f2f /etc/passwd
63a1913bc0d1d39927b40628d6a98ecd /etc/services
6d16efee5baecce7a6db7d1e1a088813 /bin/ps
b7dda3abd9a1429b23fd8687ad3dd551 /bin/netstat
f482ae701e46005a358a01c139f1ae74 /bin/ls
6afa152b929c0ab6ddd0a321254f139f /usr/bin/top
3509dee17211e59dec058e30a50c79e3 /etc/inetd.conf
908162ab85e1e3668a235e223aad7d0e /usr/bin/md5sum
eb3fc42223173db0888cee7aec96f413 /bin/rpm
146fc45ab3af038bf592b271556b7cd5 /bin/ck_sum.scp

The first time I run the script, I save the file as ck_sum.org (for original) and save it on another system, just in case.

The line echo "Report from someworkstation" > /root/ck_sum.out starts the log with a nice heading. I then use the basic UNIX command diff to compare the ck_sum.org to the file I just created, ck_sum.out. I again mail the log to a system used for log checking. If nothing has been altered, the file should only contain:

"Report from someworkstation"

Remember that any administration on the system may cause changes in the files your are checking. For instance, when I add a user, my /etc/passwd file changes. I will then need to recreate ck_sum.scp by re-running my script.

Tier Three

I also wanted to track changes in all files. I realize most of the systems I administer have a relatively small number of users. However, I run this even on the systems that have many users and just omit the home or user directories. I call this script file_check, because I use the script for just that purpose. I again implement basic UNIX commands, this time focusing on the find command (man find).

I actually have two different scripts: the first checks for changes daily, and the second checks weekly. However, you can use any time frame that fits your needs. Here is the script for checking files that were altered in a 24-hour period followed by the breakdown of the script:

#Script to find changes in files on the system
#Omitting the /proc dir
find / -mtime -1 -exec ls -ld {} \; grep -v /proc >
/tmp/1days 2>/dev/null &
# find starting at the root dir "/"
# -mtime is the time the file was last modified
# -1 is the time less than one day of modified time
# -exec ls -ld, execute listing of files in long format and
# also list directories but not content.
# {}
# grep -v /proc omits the /proc dir
# > /tmp/1days pipes the output to this file
# >/dev/null pipes any errors to /dev/null

To use the script for a time period other than a single day, simply change the “-1” to whatever time period you wish. For example, here is my command when I look for changes that have happened in the last week:

find / -mtime -7 -exec ls -ld {} \; grep -v /proc >
/tmp/1days 2>/dev/null &

I use cron to schedule the run time of the script and to email the files to me. Then I check for any files I do not think should have changed in the last day.

In tier three, I also start checking the logs without examining each log individually. I use a script called log-checker, which uses the UNIX command grep, or egrep if you prefer to query logs for keywords (man grep or man egrep). The entire script is only five lines long:

#!/bin/sh
grep refused /var/log/secure > /root/secure.txt
/usr/bin/last >> /root/secure.txt
grep auth /var/log/messages >> /root/secure.txt
mail admin@someworkstation.com < /root/secure.txt

I simply grep for keywords such as “refused”, “auth”, and “connection” in my logs, dumping the output into a file called secure.txt:

/bin/grep refused /var/log/secure > secure.txt
/bin/grep auth /var/log/messages >> secure.txt
/bin/grep connection /var/log/messages >> secure.txt

I also add /usr/bin/last >> secure.txt for good measure to see who has been on the system since the last log. Finally, I have the log emailed to myself, mail admin@somewhere.com <>

Tier Four

In the fourth tier, I installed Portsentry to anchor my entire security logging methodology. I edited portsentry_config.h by uncommenting the line starting with WRAPPER_HOSTS_DENY, and adding the path to the hosts.deny file to enable the use of the program with TCP Wrappers.

Although I like programs like Portsentry, Saint, etc., I appreciate that with a few simple UNIX commands, I can keep a eye on my systems and have several tiers of protection.

THE THREAT POSED BY

PORTABLE STORAGE DEVICES

Strategies and solutions to combat corporate data theft

In a society where the use of portable storage devices is commonplace, the threat that these devices pose to corporations and organizations is often ignored. This white paper examines the nature of the threat that these devices present and the counter-measures that organizations can adopt to eliminate them.

Introduction

In an on-demand society where individuals can easily access portable music players, PDAs, mobile phones and digital cameras, technological innovation has responded to personal needs with the development of electronic devices that include data storage capabilities. There is, however, a downside to this modern-day scenario – the misuse of these devices in a corporate environment can spell disaster to a corporation! The statistics are not encouraging; for instance, the 2005 CSI/FBI survey reports that “theft of proprietary information is up from [US] $168,529 in 2004 to [US] $355,552 in 2005” (Gordon et al., 2005).

2005 CSI/FBI computer crime and security survey

“Theft of proprietary information up from $168,529 in 2004 to $355,552 in 2005.”

Today, corporations who recognize the extent of the data theft problem are enacting security policies that regulate the use of portable storage devices in the corporate environment. But is a security policy alone the best solution to mitigate the risks posed by portable storage devices? And what are the real risks associated with the uncontrolled use of portable storage devices?

The rise of portable storage devices

In the last ten years data storage technology has broken all the barriers that used to bind it to large devices that stored limited amounts of data. These technological breakthroughs have:

Increased data storage and data transfer speeds exponentially
Increased device portability through a substantial reduction in physical device size
Increased device availability by the development of mass-appeal low-cost products
Simplified the connectivity method to computer systems.

A typical example is the Apple iPod released in October 2005. This device can store up to 60 GB of data – as much as the typical corporate workstation’s hard drive. In practice, this translates to millions of proprietary, financial, consumer and otherwise sensitive corporate records!

Transferring data from one computer system to another is nowadays a non-technical, highly efficient, inconspicuous task. This effectively puts corporations in harm’s way, since the misuse of portable storage devices can expose corporate networks to a number of dangerous issues which might have an impact on corporations in a variety of ways.

Why do corporations require protection?

Statistics demonstrate that 98% of all crimes committed against companies in the U.K. had an insider connection (Computer Crime Research Center, 2005). Data theft, legal liabilities, productivity losses and corporate network security breaches are all dangers that corporations have to face if malicious insiders or careless employees misuse portable storage devices at their workplace.

Scotland Yard

“98% of all crimes against companies in the U.K. had an insider connection.”

Data theft

The actual act of stealing corporate data by insiders is quite simple in itself and today software that is easily available for download automates the whole process. Insiders only need to plug in the portable storage device on a corporate workstation and all data, including sensitive data is automatically copied, without any additional user intervention. This automated process, commonly known as ‘pod slurping’, is able to copy whole databases and other confidential records to a portable storage device in a matter of a few minutes.

Serious Organized Crime Agency (SOCA) – U.K.

“…one of the big threats still comes from trusted insiders. That is, people inside the company who are attacking the systems.”

Data theft does not limit itself to corporate insiders. Outsiders can use social engineering techniques to manipulate unsuspecting employees into using media or portable storage devices on the corporate network workstation. Seeded with malware, these devices open backdoors in the corporate perimeter defense, allowing hackers easy access to corporate data. A well publicized example was an experiment conducted in 2006 by the Training Camp, a UK-based training institution (Sturgeon, 2006). This involved the distribution of promotional CDs to office workers. However, apart from the advertised material, these CDs contained a script that tracked and advised The Training Camp when the CD was used. Notwithstanding the fact that the CD contained an advisory note to check their company’s security policy before running it, 75 out of the 100 CDs distributed were used on the corporate network. This experiment underscores the fact that employees, acting in good faith, can bypass the best perimeter security, exposing corporations to serious repercussions. Corporations typically accumulate a wide array of data that can be stolen. This includes:

• Blueprints and engineering plans
• Tenders, budgets, client lists, emails and pricelists
• Credit card and other financial information
• Software source code and database schemas
• Medical or other confidential personally identifiable records
• Classified, restricted or personal information
• Scripts, storyboards, print material, photographic, video or animated film
• Score sheets, lyrics, sound files and other forms of phonographic material.

U.S. Secret Service & CERT Coordination Centre

“Respondents identified current or former employees and contractors as the second greatest cyber security threat, preceded only by hackers.”

The data stolen can be sold to competitors or used by the insiders, their criminal associates or hackers to commit a wide range of crimes ranging from identity theft to extortion and blackmail.Employees
leaving the company to work with a competitor may also use the data acquired to gain an edge over their previous employer or directly discredit the image of that company.

Surveys conducted by the U.S. Secret Service and CERT Co-ordnination centre concluded that: “Respondents identified current or former employees and contractors as the second greatest cyber security threat, preceded only by hackers” (Keeney et al., 2005). This is further corroborated in the CSI/FBI survey which indicates that 68% of respondents claimed losses due to security breaches
originating from insiders (Gordon et al., 2006).

2006 CSI/FBI Computer crime and security survey

“68% of respondents claimed losses due to security breaches originating from insiders.”

Legal liabilities

When confidential information is ‘lost’ or illicit/objectionable data is introduced on the corporate network through portable storage devices, corporations might become legally liable for any information that is stolen or illicitly introduced. Liabilities can impact the corporation’s assets significantly under different laws in different countries; under HIPAA (USA) the wrongful disclosure of individually identifiable health information, can be penalized with a maximum fine of $250,000 and 10 years imprisonment. The table below outlines a list of laws and the country in which they are applicable.

Country Laws

U.S.A. Sarbanes Oxley Act, Gramm-Leach-Bliley Act, USA PATRIOT Act, Title 21 of the Federal Regulations Part 11 (21 CFR Part 11), Federal Information Security Management Act, HIPAA

E. U. Data Protection Directive, Privacy and Electronic Communication Regulations; EU Annex 11, Computerized Systems;

U.K. Turnbull Guidance Act [1999], Companies Act, Data Protection Act, Freedom of Information Act, Money Laundering Regulations 2003

Japan Personal Information Protection Act 2003

Canada Personal Information Protection and Electronic Document Act (PIPEDA)

Australia The Federal Privacy Act (Privacy Act 1988)

Productivity loss

The corporate network can be misused by untrustworthy employees who use portable storage devices to bypass perimeter security personal files. These could include part-time work orhobby related material to be carried out during working hours. The problem grows to an exponential level when video games are transferred to the workplace. Video games are addictive, require constant user input and through multiplayer capabilities these can be a means of enticing and distracting more than one employee.

Corporate network security breaches

The usage of portable devices at work can also impact corporate network security through the intentional or unintentional introduction of viruses, malware or crimeware that can bring down the corporate network and disrupt business activity. Law enforcement agencies today acknowledge that “…one of the big threats still comes from trusted insiders. That is, people inside the company who are
attacking the systems” (Ilett, 2006).

U.S. Federal Trade Commission

“Disgruntled employees gaining access to customer lists and other information is proving a growing danger.”

Commonly used countermeasures

There are only a few countermeasures that corporations can adopt to prevent unauthorized portable device use. Banning portable storage devices on the corporate premises and the physical blocking of computer access ports are common practices. The deployment of Windows Group Policies is also utilized. These countermeasures however have a number of shortcomings:

• Most portable storage devices are small and easily concealable, therefore it is difficult to ensure
  that no-one has brought in a banned device.
• The inability to discriminate between legitimate devices and devices that should be denied access
  to resources.
• The overhead in manpower required to enforce these countermeasures.

The only really effective solution to counter portable device threats is by deploying a software solution that protects the corporate network perimeter against unauthorized device usage – a solution that
allows you to discriminate between legitimate and illegitimate use of devices, in compliance with the custom security policies set up by the corporation.

GFI Software offers a permanent solution which helps you protect your corporation against portable storage device threats. This is GFI EndPointSecurity – the effective counter measure against the enemy within! GFI EndPointSecurity allows you control entry and exit of data via portable storage devices, allowing you to prevent users from taking confidential data or introducing viruses and trojans to your network. GFI EndPointSecurity allows you to actively manage user access to media players (including iPod and Creative Zen), USB sticks,CompactFlash, memory cards, PDAs, Blackberries, mobile phones, CDs, floppies and more.

To read more and to download a trial version, visit
http://www.gfi.com/endpointsecurity/.

Conclusion

The uncontrolled use of portable storage devices by corporate insiders is a definite threat to the security and stability of every business. Malicious insiders and gullible employees who fall for social
engineering practices are the weakest link in the corporate security chain. Relying on user voluntary compliance to the corporate device usage policy is not a solution – you must deploy software
countermeasures that thwart this risk. GFI EndPointSecurity is a real alternative to corporate turmoil. It ensures business continuity by allowing portable device access to legitimate users whilst keeping corporate business sheltered from unauthorized data transfers to and from portable devices. With GFI EndPointSecurity, corporations are permanently protected!

BEST PRACTICES FOR SECURITY

INCIDENT RESPONSE

Are you prepared to make the best decisions and responses to security incidents in your business?

Picture this scenario: you arrive to work on Monday morning to find problems on your network. You can't log in, some servers seem to be down, and the phone is going crazy. You consider the possibility of two causes :

some fault has occurred and needs fixing you network is ( or has been ) under attack

What you do next is critical. Every decision you now make means a huge difference to the productivity of your business. This paper presents a short list of what needs to be done to address this situation: you have a security problem, it may be malicious hackers, or it could an entirely accidental problem.

Security Incidents . A definition
An IT security incident is a violation of IT security policy, acceptable use policy or of standard procedures

Which covers a lot of events, but most frequently amongst small to medium enterprises:

malware attacks

• virus ( becoming rare )
• worms
• trojan horses

Denial of Service ( DoS )

• as a side-effect of malware attack
• as a deliberate, intelligent attack

Intruders, intelligent agent attacks

• insiders
• outsiders
• ex-insiders

Email

• advertising - SPAM
• scams: phishing, Nigerian, stock market
• malware-carrying: trojans
  

Operational incidents

• system failures: crashes, environmental failure
• operator error
  

Prevention is always best, in other words: cheapest. Prevention is generally more economical, less stressful, and incurs less downtime however it requires a very full understanding of the security landscape and prevention systems such as anti-malware tools, and good processes. But eventually, the inevitable happens and the cost of recovery is directly related to the amount of fore-planning applied.

It has been estimated that in 2006, New Zealand businesses will lose a total amount of $140-240 million due to security incidents (Ref). This is a very high figure (dodgy statistics warning!) which must be close to the entire IT security revenue figure for New Zealand.

Detecting Incident Occurrence Detection is not always easy, often detection is through observing the side-effects of a security incident (eg. High network traffic). Major incidents are frequently announced by statements such as "that's funny", or "Uh oh" ...

Intrusion detection tools are generally good analysis tools, sometimes useful for tactical alerting. Always good to have in your toolkit.

Assessing the situation
Assess the situation as soon as possible after detection. Ask yourself (and anyone else in the vicinity) the following questions:

• what is the business impact of the incident?
• if the affected system(s) are isolated then what is the impact to business?
• how much effort will it take to resolve?
• this estimate can be re-evaluated later
• estimate for repair-in-place
• estimate for offline rebuild from scratch
• estimate to recover from backups ( you do have backups, don't you? )
• is there enough people with enough expertise available?
• if not, think about calling someone - either additional internal resources, or external providers
• document everything include dates and times, include contact information
  

Identifying the people to handle the incident
An incident team for a small to medium enterprise is almost always two people. One will be the technical lead who will perform the bulk of the remedial work, and the other will be a backup person reporting to management and recording the actions taken. Further people may be involved depending on the size of the organisation, usually in the reporting chain rather than in direct involvement. These may include:

• the IT manager
• the CEO/CIO/CTO
• Media relations
• Legal
• Law enforcement

Always get help if you feel the situation is getting out of hand. For example, in one case an incident involving malware infection dragged on for two weeks before someone was called in to diagnose the problem and resolve it within an hour. Get equipment and software tools if required. For example:

• new workstations, servers, switches/routers, firewalls
• IDS tools
• Anti-virus, Anti-spam tools
• Preparation is the key to saving time here. It is always good to have an incident toolkit ready with software tools on a CD or USB stick.

Forming a plan for resolution
Make a plan, not necessarily written, but at least well communicated. Include the following basic steps:

1. Contain the problem
Potentially by isolating the affected systems

2. Do No Damage
make backups of the affected system(s)
decide if preservation of evidence or critical data is required, if so then backups and correct procedures are critical

3. Resolve the problem
rebuild systems from scratch?
load backup data?
re-secure the affected system(s) as soon as possible

These steps may be reiterated as the resolution process continues. During resolution the following must be continuously performed:

• record all actions taken, and document as much as practical
• updated estimated RTO times
• report to management and other interested parties

Keep other people in the organisation up to date with expected RTO times and any issues that are outstanding. Discretion needs to be applied here : avoid public dissemination of sensitive information ( such as what type of system failed ), and be very cautious as to attributing blame.

Return to Operation
After the incident has been resolved the systems can be returned to operation, but only after they have been tested and re-secured to prevent any re-occurrence. Identify and mitigate all vulnerabilities that were exploited After return to operations, monitor the system closely to make sure all systems are restored to normal.

Report to management and other interested parties that the system has been restored.

Preventing Reoccurrence
This is by far the most crucial area, unfortunately it is often overlooked. Many problem would not occur if prevention measures had been put in place following the first occurrence.

Review the Causes

• Was the incident caused by a failure in one or more of the following?
• Technical controls?
• Environmental systems?
• Human factors?
• Management & budget constraints?

Review Resolution

• Could the incident have been detected earlier?
• Could the incident have been resolved quicker?
• Did you need more resources?
• Was reporting adequate?
• Would simulations and rehearsals help in resolving similar incidents?
• Would it help to have better incident response plans?

Create a Final Report
... and keep it short and to the point. 1-2 pages is the norm. In the final report detail the incident causes, how it was detected, the handling process, and provide an executive summary.

The key is to prevent re-occurrence.
Scenarios

Think about how you would handle each of the following hypothetical situations:

Scenario 1
The company's web server slows down then stops responding. High network traffic causes you to suspect a Denial of Service attack. Points to address:

• How will you identify the source of the traffic?
• Should you shutdown the corporate web server?
• How will you stop the traffic?
• How will you prevent it from reoccurring?

Scenario 2
The organisation starts receiving complaints about spam originating from its network The administrator identifies the source as the company.s web server Points to address:

• How would you validate the source of the spam?
• How would you respond to complaints regarding the spam?
• How would you isolate and repair the web server?
• How would you prevent reoccurrence?

Scenario 3
A new Trojan/worm is released on the Internet - it distributes itself through Email attachments and downloads malicious code from an Internet FTP server. A number of people in your organisation have opened such attachments. Points to address:

• How do you identify infected systems?
• How could you prevent the malware entering the enterprise before antivirus signatures
  were updated?
• How would you prevent further spread?

Scenario 4
An employee at your site mentions that his bank account has been cleaned out by hackers in Estonia. He has been using online banking from his company workstation. Points to address:

• Could you confirm whether or not his password was stolen?
• How would you report this incident?
• Would you warn other employees?

Scenario 5
The database administrator finds a strange directory on a database server, created by root 6 weeks ago. Points to address:

• How will you identify the source of the attack?
• How will you preserve the system?
• How will you identify what has changed on the system?
• How will you recover the system?

Scenario 6
A network intrusion detector identifies that someone has downloaded malware from a webmail account.

• How will you identify the person involved?
• How will you make sure their workstation is unaffected?
• How will you prevent it from reoccurring?

References
1. A survey conducted by the Employers and Manufacturers Association (Northern). Press release 6 December 2005. http://www.nzherald.co.nz/topic/story.cfm?c_id=137&ObjectID=10358566