- Internal attacks
- External attacks
- System malfunction

There is a pervading assumption, that the main source of computer security breach is predicated on external attacks. This is a faulty premise that creates room for lapses in internal security protocols. External attacks usually succeed due to some form of internal lapse in the computer network structure and security policy implementation. Failure can range from - failure to apply relevant software updates, applying patches, updating anti virus software, checking server event logs, Router logs, Firewall logs, Switch logs, user logon privileges etc. The list is endless; to cap it is the role of the enemy within - a member of staff, a contractor, a disgruntled IT Manager who seeks revenge for his abysmal dismissal or layoff or job dissatisfaction.

External attacks used to be the preserve of the very young who joyously celebrate their discovery of hacker tools to deface web sites and announce their arrival into the technological age. This is no longer the situation. External attacks are now coordinated events informed by the demands of corporate espionage, commercial gains and sometimes political objectives. Statistics show, that no one Computer network is free from some form of attack. The question is not, if a computer Network will be attacked; it is when. The moral is, to be ready when the attack happens.

A computer incident response can be triggered not just by an external or internal attack, but also by what I refer to as a system meltdown. Very often we forget that computers are machines, with parts that are susceptible to wear and tear. Computers are machines that run on special codes (programmes and applications) designed by humans with all their imperfections. If the problems do not arise from the wear and tear of the physical aspect of the computer, the problem may arise from outdated updates, outdated antivirus software, the activities of a lazy programmer who has deliberately refused to check his code before packaging the software for consumption.

The point being made here is that not all computer incidents will arise from an external or internal attack. Once this mind set is cultivated, it is thereafter easy to expand the scope of our proactive and reactive steps in response to computer incidents.

Litigation readiness demands the existence of an incident response protocol, if it can be shown through substantive evidence that the security of a computer network is inherently porous, this opens up plausible legal challenges as to alternative possibilities for a computer attack. This makes the job of isolating and locating ownership of an attach on a computer network.

My first caution, in responding to a computer incident is – DO NOT PANIC.

Unnecessary complications have been introduced into an already complex situation because someone panicked and took a wrong course of action. It is no accident that very often when a real or imagined security breach occurs, Computer users, IT teams and management go into panic mode and resort to knee jerk reactions to investigating computer incidents.

Panic results from the absence of a response protocol or the none adherence to an existing protocol. What is a Computer incident response protocol? It is set of formal instructions that proactively describe and prescribe steps to be taken in case of a computer incident. As discussed earlier a computer incident can be an internal attack, external attack or simply a system meltdown. You will notice I used the word formal. The protocol must be in writing and not stored in the brain of the iT manager or Company executive who is hardly in the office.

The evidence of panic when an incident occurs is that no one has the slightest clue on how to proceed with an investigation, on what to investigate and who is to investigate. Ignorant IT staff shouts out instructions for Network and power cables to be pulled from mains sockets an overzealous IT manger begins to access all manner and shape of log files and embarks on exercising his newly acquired command line skills – all of this to the detriment of a properly coordinated investigation.

The proof or otherwise of the existence of a set of facts is based on credible evidence. With computer investigations, credible evidence results from being able to answer the who, when, and how questions surrounding a computer incident. When panic takes over, instead of a coordinated approach to investigating a Computer incident, irreparable damage is done to digital evidence by uninformed internal investigation .

Otherwise credible computer evidence lose their probative value due to ignorant and blind access of suspected accounts. Personal and network shares, security logs, system accounts, computer settings. results in modifying file attributes and a tainted time line of file usage. This leads to problems with determining time chain sequence with respect to when production files and system logs were accessed, modified and created.

It creates legal problems associated with scope of authority and breach of privacy laws. If you have to access the computer of a member of staff to investigate possible breach resulting in a computer incident, you better make sure your scope of authority as disclosed in your letter of employment or contract, grants these investigative powers and that you are well equipped by training to conduct the relevant investigation. Any move to the contrary will introduce legal complications to an already complex situation.

A further implication from the above is associated with the authenticity of digital evidence produced from computers. There are basically two aspects to this issue. Given the ease with which digital documents can be modified and fraudulently manipulated, there is need for some form of assurance that an investigator or examiner has not deliberately or carelessly tampered with digital evidence. Forensic examiners will usually work on an exact duplicate of a file or image acquired from a digital storage device. There exist mathematical algorithms for deciding that a copy of a file is the exact replica of the original. These algorithms come in different flavours – MD5 or SHA1 etc. These algorithms essentially produce matching numbers of the original and duplicate of a file to prove that the original evidence has not being tampered with.

The 2nd leg of this assurance strategy is referred to as chain of custody. In other to rebut any presumption of tampering, the document custodian must show via an appropriate log book a verifiable chain of custody that there was no tampering from evidence extraction, analysis, storage and eventual presentation. Where there is a break in the chain; plausible reasons for such a deviation from the accepted practice must be advanced in the custody report.

Unfortunately, when Panic takes over during a computer incident investigation, there is little or no room for an assurance strategy to be executed. File authentication and chain of custody evidence integrity, become alien and obstructive concepts. Sadly, this hasty and uncoordinated approach to investigation ultimately cost time, money and may amount to a career limiting move for the IT manager or forensic investigator.

Panic also leads to the loss of crucial evidence. When the IT Manager or IT help desk pulls out the network cable and the Power plug on a suspect server or PC, they have also in that one uninformed move closed the door on any chance of collecting vital evidence that is volatile on the computer system especially evidence located in the computer memory technically referred to as RAM (Random Access Memory)

Panic during a computer incident response must be avoided at all cost. All it helps to achieve is complicate matters further. Panic is the product of lack of preparation and the absence of formalised procedures, prescribing steps to be adopted during a computer incident crisis.

How do you avoid Panic? Simple. Take pro-active steps, which are documented and audited from time to time. Pro-active steps include:

- Putting in place an incident response team. The team membership should include IT, Human resources, legal and Management. The management representative should have the authority to make binding decisions at the board level.

- There must be in place a Computer incident response Manual – it does not have to run into a million pages. A functional Manual that is professionally produced by an incident response professional .The dusty health and safety manual with a little modification will not suffice for this purpose.

- The incident response Manual must specifically identify individuals and their deputies to specific assignments in case of an incident.

- A clear reporting ladder must be included in the Manual – who decides that an employee computer should be imaged for investigative purposes? Who decides that the police should be called in if fraud or child porn is found on a suspect computer? Who will be the contact for the company if a 3rd party professional team is called in? When and who will report to management?

- Who carries out the investigation? Do they have the requisite authority? Do they have the requisite training?

The above points do not entirely cover the minute details required for a long term incident response manual. However, they are a good starting point for your incident response protocol. A fuller response manual needs to be produced by a trained security and investigative professional after carrying out a gap analysis.

In conclusion, when a computer incident occurs, do not panic. Panic is no substitute for pro-active preparation. When in doubt call in a professional. Where you already have an Incident response Manual in place, periodically call in an independent professional to audit your state of response readiness.