Chapter 22. Operations Security
Solutions in this chapter:
▪ Individual Accountability
▪ Operation Controls
▪ Auditing to Determine What Went Wrong
Summary
Introduction
This chapter looks at operations security. This is not the same as OPSEC (as used in within the military). JP(Joint Publication)JP 1-02 defines OPSEC as “a process of identifying critical information and subsequently analyzing friendly actions attendant to military operations and other activities to identify those actions that can be observed by adversary intelligence systems”.
Rather, organizational Operations Security is about maximizing the Confidentiality, Integrity and Availability of the systems used by the organization using a risk based approach. This is achieved through minimizing the effects of the threats and extent of the vulnerabilities faced by the organization. This leads to reduced asset losses and thus lower risk.
Many standards and frameworks have implemented organizational operations security. ISO 17799 (and subsequently ISO27001/2) has numerous requirements alone these lines such as BCP:
“A Business Continuity Management process should be implemented to reduce the disruption caused by disasters and security failures to an acceptable level through a combination of preventative and recovery controls”.
A large amount of the COBIT framework is dedicated to organizational OPSEC.
The Concepts of Organizational OPSEC (Operation Security)
There are a number of specialist topics in organizational OPSEC and concepts that need to be defined before going into detail. These include:
▪ Trusted Computer Base (TCB) The totality of protection mechanisms within a computer system including hardware, firmware, and software. The combination is responsible for enforcing a security policy.
▪ Malware Management Malware management is more than an Anti-Virus system. Any system that gives administrative control to a user allowing the loading or execution of any software has an increased vulnerability to malware (such as worms, viruses and trojans) and risk from unexpected software interactions. This can lead to the subversion of security controls.
▪ Principle of Least Privilege Never grant users more than the least level of access to a system that is needed for them to be able to complete their roles or jobs. That is, if a user needs Read only access to a file, set their permissions to only allow read access blocking write permissions such that they cannot modify the data.
▪ Privileged operations This type of operation includes the use of:
Operations system control commands
The ability to configure interfaces,
Rights to access audit logs,
The ability to manage user accounts
The ability to configure security mechanisms and controls
The privileges to back up and restore data, etc.
▪ Legal requirements. Adherence to the law and regulatory controls is the foundation or baseline upon which a security infrastructure can be built. At a minimum, it is necessary to adhere to the requirements imposed by law on the organization.
▪ Illegal activities. This involves being able to identify both the criminal and tortuous (see the “Information Systems Legislation” chapter) An organization needs to be able to facilitate attribution. Attribution is the discovery of who is responsible and proving it through the use of evidence. The organization should also be able to support non-repudiation of transactions.
▪ Record retention. The organization's policy needs to define what information is collected, maintained and how long it is to be kept. This aspect of OPSEC is commonly driven by regulatory and legal requirements such as consent to monitoring, and financial controls (eg SEC filing or Tax rules).
▪ Marking. Marking is the process of setting a classification on the data stored on media.
▪ Handling. The transportation of media from one point or place to another securely is the realm of handling. This involves media control from purchase through to storage and lastly destruction.
▪ Storage. Data needs to be stored in secured facilities. These should maintain the temperature and humidity within a controlled range.
▪ MFFT. All media has a MTTF (mean time to failure). This is dictated by the number of times it can be re-used or a time based life.
▪ Destruction. Any media that has reached or exceeded its MFFT needs to be replaced. When destroying the old media, it should first be purged before being destroyed. This process is commonly referred to as sanitation. This involves any number of processes that prepares the media for destruction. This could include wiping hard drives and other magnetic media or degaussing. The idea is to either return the media to its original pristine, unused state or render it permanently unusable and unrecoverable.
▪ PII. Personally Identifying Information (PII) is any information that may be used to identify an individual. This includes information such as a Social Security number (USA), TFN or Tax File Number (Australia), Credit Card and Banking details and other forms of ID.
In addition, there are a number of legal terms associated with operations security. Good corporate governance (and as an offshoot, good IT governance) require that due care and due diligence
▪ Due Care. This involved the use of a reasonable level of care in order to guard the interests of the organization from risk and consequently damage.
▪ Due diligence. This is the practice of activities that are designed to maintain due care within the organization.
Together due care and due diligence make the foundations of governance. Effective governance is often the only way to disprove negligence if an incident ends up as an action in a court of law.
Administrative Management
One of the main administrative controls (an aspect of administrative management) is Human Resources or Personnel management. Security may be a risk based function, but it is one derived from people. People, an organization's personnel, a competitor's staff, the press and public; all are at the end of the day simply people. Without people there is not only no possibility of security, but also not reason for it (positive or negative).
The question that begs to be asked then is why are controls over personnel and human resources in general the last thing that most security professionals care about (ignoring at best social engineering)?
▪ HR Policy. Any organization needs to ensure that they have formalized both job descriptions and any requirements for qualifications associated with a role. These requirements need to be defined and documented.
▪ Pre-employment screening. It is necessary to validate an employee before the job offer is made. It is an unfortunate fact of human nature that many of us are less than truthful. At a minimum, an organization should validate references. For many positions, especially those requiring a high level of trust, the organization should also consider a combination of the following tests:
Reference, education and employment history checks,
Character evaluation,
Background investigation,
Drug testing,
Maintenance and periodic reviews (post hiring), and
Security clearance reviews.
▪ Education, Training and Awareness. For many organizations awareness ends when an employee signs a piece of paper stating that they have read, understood and agree to abide by the organization's policies. From a legal perspective this is insufficient. It is necessary to maintain employee education and awareness. This is covered in greater detail in the chapter, “Assessing Security Awareness and Knowledge of Policy”,
▪ Pre-defined processes for conducting terminations of employees. It is essential that the termination process is planned in advance and defined formally. Listed below are a number of points that should be considered and formalized in policy and procedures. The formalization of these procedures is important. Without formalization it is likely that mistakes will be made that could lead to court action and other damages to the organization. At best, a termination is a stressful time for all involved. Having a predefined process not only limits mistakes, but also reduces the anxiety associated with the process.
Termination pay
Friendly vs. unfriendly terminations
Exit interview
Escorted removal
Adverse termination: e.g., Lock-out computer accounts, change passwords, return keys, badges, and so on.
▪ Acceptable Use Policy. It is essential that the organization communicates the appropriate use of systems and resources to its staff. A failure to do this is likely to lead to inadvertent mistakes at best and willful violations at worst. An employee who breaches the policy has to be aware of it if any action is to be taken against them.
▪ Need-to-Know. Staff should only know what they are required to know for the job. There is no reason for instance, for all staff to know the pay rates of every other staff member. To do this, only provide privileges and access it is when necessary to carry out assigned duties.
▪ Least Privilege. People within the organization should hold just enough privileges to perform duties and no more. A common error in many organizations is to not restrict the capabilities of administrative staff. Consider employees who have different rights such as:
No access beyond job requirements
Group level privileges for Operators
Read Only access to files that should not be changed
Read/Write – usually copies of original data
Access Change – make changes to original data
▪ Separation of Privileges. Limit the ability of staff to carry out activities by subdividing them among multiple subjects. No one staff member should have complete authority over a critical task. An example of this would be separating the ability to back up and restore files. Assign rights to back up operators allowing them to backup files and create a separate group of users who can restore files.
▪ Separation of Duties. It is important to ensure that a single person acting on their own cannot compromise security. As an example most corporate bank accounts require two signatures to be valid.
Job Rotation provides backup/redundancy and well as detection of fraudulent activity
Mandatory taking of vacation in increments of at least one week
A variation to the control of separation of duties is rotation of duties. Rotation of duties is defined as “the practice of limiting the amount of time an operator is assigned to perform a security related task before being moved to a different task with a different security classification”i. Implementing rotation of duties minimizes the opportunities for operators to be able to collude. Similar to separation of duties, the control of rotation of duties is often extremely difficult to put into operation in small organizations. This control can be an extremely effective security control procedure. Where possible, separate duties as follows (that is, do not let an individual who provides one of the tasks below to provide either of the other tasks):
▪ Security administration
▪ Network administration
▪ Application administration
Fraud
Fraud covers an assortment of irregularities and illegal acts distinguished through intentional deception. The legal definition of fraud is a representation about a material fact that:
The stages of fraud can be exemplified by The Fraud Triangle (Figure 22.1). People who commit fraud are normally able to do so due to a combination of opportunity, pressure, and a rationalization.
 |
| Figure 22.1 The Fraud Triangleii |
The Fraud Triangle
Most frauds, particularly the really large ones (WorldCom, Enron, etc.), could not have transpired lacking a combination of the right person with the right capabilities. Opportunity provides the possibility of a fraud occurring, and incentive and rationalization can move the individual toward committing a fraud. But the individual requires the ability to distinguish the “opportunity” and to derive benefit from the opportunity. This will then generally occur, not just once, but time and time again.
Frauds are more often discovered due to repeated occurrences.
Opportunity is usually presented through a combination of events leading to a weakness in the internal controls. Some examples include inadequate (or non-existent):
Pressure (or incentive) can face an individual due to a combination of factors such as:
▪ Financial problems
▪ Family breakdowns
▪ Personal vices (gambling, drugs, prostitution, extensive debt, etc.)
▪ Unrealistic deadlines and performance goals being set by the organization
Rationalization transpires when a person learns to justify their activities. They start to see their fraud as being acceptable. The process of rationalizing fraud varies by circumstance and the personality of the individual. Some examples of justifications that have been stated in fraud cases include:
▪ “I really needed the money, and I did intend to return it when I got my paycheck.”
▪ “I'd rather have the company on my back than the IRS.”
▪ “The company has more money than it knows what to do with. My little bit should not have been noticed.”
▪ “Those criminals in head office are bigger crooks than I am.”
▪ “I just can't afford to lose everything. I have worked too hard to get my home and my car. I could not stand to lose everything.”
It is essential to consider controls that minimize the chances and effect of fraud in an organization.
Control Categories
There are many types of controls. The following section will introduce a number of these control categories. When designing a control framework it is necessary to include multiple levels of controls. For instance, either preventative or detective controls alone are unlikely to be effective in stopping attacks.
When these operate together they create an effect that is greater than its sum.
Deterrent (or Directive) Controls
Deterrent controls are administrative mechanisms (such as policies, procedures, standards, guidelines, laws, and regulations) that are used to guide the execution of security within an organization. Deterrent controls are utilized to promote compliance with external controls, such as regulatory compliance. These controls are designed to complement other controls (such as preventative and detective controls). Deterrent and Directive controls are synonymous.
Preventative Controls
Preventive controls include security mechanisms, tools, or practices that can deter or mitigate undesired actions or events. An example of a preventive control would be a firewall. In the domain of operational security, preventative controls are designed to achieve two things:
An example of these controls would include firewalls, anti-virus software, encryption, risk analysis, job rotation and account lock outs.
Detective Controls
Detective controls are designed to find and verify whether the directive and preventative controls are working. Detective controls are designed to detect errors when they. Detective controls operate after the fact. They include logging and forensic controls are used to collate unauthorized transactions such as for the prosecution of the offender, or to lessen the impact of the attack or error on the system. Examples of this category of control include audit trails, logs, CCTV and IDSs.
Corrective Controls
Corrective controls are comprised of the instructions, procedures, or guidelines that are used to overturn the consequences of an incident. Corrective controls are put into practice in order to alleviate the impact of an event that has resulted in a loss and also to respond to incidents in a manner that will minimize risk. Examples include manuals, logging and journaling, incident handling, exception reporting, and fire extinguishers.
Recovery Controls
Recovery controls are designed to recover a system and returned to normal operation following an incident. Examples of recovery controls include system restoration, backups, rebooting, key escrow, insurance, redundant equipment, fault-tolerant systems, failovers, and contingency plans (BCP).
Application Controls
Application controls are designed into applications in order to minimize and detect operational irregularities that may occur within the application. Transaction controls are a type of application control.
Transaction Controls
Transaction controls are utilized in order to afford a level of control over the various stages of a transaction as it is processed. Transaction controls are implemented from the first stages when the transaction is initiated through to when the output is produced. Comprehensive testing and change control are also types of transaction controls. A number of these controls have been included below.
Input Controls
Input controls are used to make certain that transactions are correctly inputted into the system only on one occasion. An element of input control could include the counting of data or the time stamping data with the date it was entered or edited.
Processing Controls
Output Controls
Output controls are designed to protect the confidentiality of output, and to verify the integrity of output using a comparison of the input transaction to the output data.
Change Control
Change control is implemented to preserve data integrity in a system as changes are made to the configuration. Procedures and standards have been created to manage change and the modification of a system and its configuration. Change control and configuration management control is thoroughly described later in this chapter and within other sections of this book.
Test Controls
Test controls are designed to prevent violations of confidentiality and to ensure transactional integrity. Test controls are often included as a component of the change control process. An example of this category of control is the appropriate use of sanitized test data.
Operational Controls
Operational controls include those methods and procedures that afford protection for systems. The majority of these are implemented or performed by the organization staff or outsourced entities and are administrative in nature. Organizational controls may also include selected technological or logical controls.
Hardware Inventory and Configuration
It is important to keep an inventory of hardware and software used and deployed within the organization. to do this, the following control should be implemented:
▪ Hardware Inventory This is an inventory of all assets owned by the organization. It provides an overview of the hardware installed on any automated system and may also be used tracking the ownership and status of an asset.
▪ Hardware Configuration Chart This document provides the detail of the configurations that are deployed on each of the individual systems in use within the organization. This document should contain a detailed breakdown of the components installed on each host.
Patch Management
Patch management is covered throughout the book. Although many people decry the need to catch systems and manage vulnerabilities, without this control no system is likely to remain compromised on the Internet for more than a week. There are many stages to patch management. First the organization needs to identify the patches that it needs to apply. Once a patch has been identified it needs to be tested to ensure that it will work correctly in the environment that it is going to be running in. Many systems run multiple applications and it is not uncommon for patches on one application to cause detrimental effects on another.
The next consideration is the rollout of the patches. This is a relatively simple process when only a small number of machines (such as servers) are involved. In the event that application patches need to be rolled out to user workstations in a variety of different contexts, this can result in significant deployment challenges.
In particular some of the major considerations that need to be addressed include:
▪ Mobile systems such as notebook computers that may only connect to the network over a slow link or only connect at periodic intervals,
▪ Systems that have been powered-off such as user workstations that are being shut down overnight. Newer systems with a power on LAN capability pose less of an issue,
▪ Compromised systems are a serious problem. The systems may need to be patched but the process of the system being compromised may have also rendered patching more difficult.
Roll back procedures also need to be considered as part of the patching process. It is impossible to test all contingencies and there are occasions where it will be necessary to remove a patch after the patch has been installed.
Configuration Change Management (CCM)
Configuration management is the practice of tracking and approving changes to a system. The change process incorporates the identification, control, logging and auditing of all changes made to a system. Change management applies to:
▪ Hardware and software changes
▪ Networking changes
▪ Any other change concerning the security of the organization
Configuration management may be deployed in order to defend a trusted system during the process of design and development. The primary security objective associated with configuration management is ensuring that any change to a system does not unintentionally diminish the security of the system. Change management also acts as a detective control to find unauthorized changes which could be the result of an attack.
For instance, change and configuration management could prevent an previous version of an operating system from being installed and run as a production system. Configuration change management introduces the ability to effectively roll back to a prior version of a system. This is generally deployed when an update to a system is found to be faulty. An additional objective of configuration change management is to make certain that system changes are documented.
There are seven primary phases to operational change management or configuration change management (CCM). These stages are:
1 Requesting the change to be made
2 Conducting an Impact Assessment to determine the effects of the change
4 Building and Testing the system that has been changed in a development environment
5 Implementing the change within the production environment
6 Monitoring the change to ensure that it has been successful
7 Reporting on the status of the change to the system owner and CCM board
This process should be managed by a formal CCM board. This board is not need to be large but should involve multiple parties such as those to whom the change will impact. The final report should be lessons learnt document containing anything that did not work or could have been done better. Small and insignificant changes could be reported using informal processes such as e-mail.
Resource Protection
Resource protection is the concept of defending the organization's resources and assets from a risk that could result in a loss or compromise. Computing resources are defined to include any hardware, software, or data that is owned and used by an organization. Resource protection is intended to aid in the reduction of the risk through lowering the likelihood of damage occurring. Damage could be a consequence of the unauthorized disclosure and/or modification of data. This control is designed to limit the opportunities available to an attacker or through accident that could result in the misuse of the resource and the consequential loss.
Any organization has a number of systems that need to be protected. The following list is a non-comprehensive catalog of those systems and devices that need special attention in any organization. A resource protection list detailing the organization's “crown jewels” should be created at the earliest opportunity. The process used to create this list is called a business impact analysis (BIA).
▪ Communications hardware and software
▪ Boundary devices (including both Firewalls and Routers)
▪ Processing equipment
▪ Password files and databases
▪ Application program libraries
▪ Application source code
▪ Vendor software and licenses
▪ Critical files and kernel files on the operating system and system utilities
▪ Critical files, directories and address tables
▪ Proprietary packages and software (especially source code)
▪ Main and removable storage and other media
▪ Sensitive or critical data that could result in damage to the organization
▪ System logs and audit trails (esp. Security logs)
▪ Incident and Violation reports
▪ Sensitive forms and printouts (including checks and pay slips)
▪ Telephone networks and equipment (e.g., PBX)
Individual Accountability
“Individual accountability is the measurement of whether or not each group member has achieved the groups’ goal. Assessing the quality and quantity of each member's contributions and giving the results to all group members”iii.
Individual accountability is the factor that shows that the organization is acting cooperatively and also demonstrates due diligence and effective governance. “The purpose of cooperative groups is to make each member a stronger individual in his or her own right”iv.
There are numerous methods that may be used to structure and increase individual accountability. Some of these include:
▪ Periodically testing staff to see if they understand the policies of the organization,
▪ Ensuring that controls are enforced fairly throughout the organization.
Individual accountability reduces fraud. By instilling a level of personal accountability and ethical responsibility within the organization's staff, lower rates of incidents can be expected.
Group vs. Individual Accountability
Groups perform as groups when they are treated as groups. If we treat individuals only as individuals, they will not perform as a group.
Controls over accountability need to apply both of the individual and group level. It is common to blame an individual for the failings of a control without looking at the root cause.
Privileged Users
Controls need to be implemented to ensure that a level of accountability and monitoring are assigned to privileged users (such as the root account on UNIX and Administrator accounts in Windows).
Privileged users consist of more than just the administrative user. When setting controls over privileged users consider operator accounts (such as backup operators and those personnel who issue user accounts) and implement both preventative and detective controls at a minimum.
One of the most frequently overlooked areas when considering privileged users is that of network and peripheral equipment. It is common for routers and other network devices to be poorly configured and use insecure access and accounting controls.
Nonrepudiation
There is a definitional distinction between the legal use of the term “nonrepudiation” and the common use that has taken hold within IT. In legal terminology an alleged signatory to a document is at all times able to repudiate a signature that has been attributed to him or her. The basis for a repudiation of a traditional signature may include:
The universal rule of evidence is that if an individual denies a signature (or the creation of a transaction), then it falls upon the party that is relying on the signature to prove that the signature is truly that of the person who has denied it. In legal terminology, the terms “deny” and “repudiate” are synonymous.
The common law trust mechanism developed to prevail over a false claim of non-repudiation is known as witnessing. Witnessing occurs at the time the signature is being affixed. An independent witness to the signing of a document reduces the ability of the signatory to successfully deny the signature as a forgery at a later date through the provision of contradictory evidence.
From organizational perspective the aim is not to remove the ability for an individual to deny a transaction, but rather to ensure that sufficient evidence exists to enable the organization to successfully prove that the transaction or signature was created by the party who were supposed to have created. In order to support non-repudiation, an organization needs to consider the following technical controls:
▪ Digital signatures
▪ Secure timestamps
▪ Secure audit logs
Operational Controls
Operational controls are implemented to protect the day to day running of the organization. These involve everything from hardware controls (such as maintenance) through to controls designed to monitor privileged-entities (there are administrator or system operators who have access to exceptional, high-order functions and capabilities that normal users cannot access).
Operational controls include the monitoring and general review of systems.
Media controls expand on the idea of controls that cover the handling of sensitive information. Secure media should never leave a secured environment. This involves using secure transport to move this type media from one location to another. In a similar fashion, media that is brought into a secure environment must always be thoroughly checked to ensure that it does not contain malicious code such as malware or other hostile applications.
Trusted recovery makes certain that the security of the organization is not breached if a discontinuity (this is a system crash or other system failure) occurs. Trusted recovery needs to incorporate processes that are designed to restart system without compromising the protection scheme that is applied to the system. For instance, CheckPoint Firewall-1 can be started in a manner that allows the passing of packets before the firewall ruleset is applied. This would not be a trusted recovery.
It is also essential to ensure that the system of us after the failure can be recovered and complete a rollback without being compromised subsequent to the failure. Trusted recovery is derived from the US “Rainbow Book” series where it is required for B3 and A1 level systems. A system failure characterizes a severe security risk as security controls that are applied to the system may be bypassed due to the abnormal functioning of the system.
Hardware Controls
All applications and systems run on hardware. This is an obvious statement but one that is often overlooked. The physical controls surrounding hardware and the processes used to maintain those systems are critical to the continued operation of any organization.
Hardware Maintenance
System maintenance necessitates that either physical or logical access to a system is granted to support and operations staff, vendors, or service providers. Maintenance can be performed through a combination of onsite and remote means. From time to time hardware will need to be relocated to a repair site. When transporting hardware systems, controls need to be put in place to ensure the integrity and confidentiality of data.
It may be necessary to conduct background investigations into the history of the service personnel that are repairing the system. Alternatively, supervising and escorting the maintenance personnel off site may be an option. It is essential to always supervise and escort external personnel when they are on-site.
Maintenance Accounts
Many operating systems have been configured with default maintenance accounts (this was a common attack vector against DEC VAX equipment in the 1980’s). Maintenance accounts are generally configured to be supervisor-level accounts. The problem is that they are generally factory preset with widely known user names and passwords that are rarely, if ever changed. It is vital that these maintenance account passwords changed or disabled. If the account is disabled they could be re-enabled if and when the account is needed.
In the event that a maintenance account is used remotely (VPN, SSH, modem and even Telnet) it should be protected using additional controls (such as application firewalls, authentication gateways and other methods).
Diagnostic Port Control
Many systems have diagnostic ports which are designed to allow system administrators to troubleshoot hardware issues or failures through direct access to a port on the machine. Diagnostic ports are generally not well secured and should only be accessible by authorized personnel.
Hardware Physical Control
Is essential that secure systems are contained within an environment that has implemented physical security controls (such as locks and alarms). The following are some examples of possible physical controls:
Protection of Operational Files
It is important to protect operational files. The maintenance of critical data and systems files is commonly known as library maintenance. This process involves using strong backup and restoration procedures that are tested thoroughly. Selecting the “verify” option during a backup is not a control. A control would include a process where a tape is randomly selected from a storage location, restored and verified against the original data or a hash.
On live systems data integrity procedures such as hashing (using software such as AIDES or Tripwire) is essential to ensure the integrity of data.
Some other considerations include:
▪ The protection of Source Code using source safe technology and escrow
▪ The protection of Object Code using code libraries and hashing techniques
▪ Ensuring the integrity of system Configuration Files
Intrusion Detection
To effectively implement any intrusion detection, the system being used to control access to data must be able to identify and authenticate users. This also implements the simplest form of intrusion prevention (users must log on), and is the foundation of auditing. Both NIDS (Network Intrusion Detections systems) and HIDS (Host Intrusion Detections systems) can be implemented.
The initial step in implementing a successful IDS is to create a baseline of normal traffic. This reduces the likelihood of false positives. An IDS that is designed to detect anomalous behavior is known as a behavior‐based IDS. An IDS that works by using a library of signatures (similar to how the majority of anti‐virus software functions) is categorized as a knowledge‐based IDS.
The design and architecture of the network is critical to the successful implementation of an IDS due to the effects of collision domains across the network. The optimum placement of network‐based IDSs remains in more than a science.
Host based IDS can be used to identify attacks that are derived from the host itself (HIDS management can be an issue due to a combination of factors such as cost and correlation management).
Note
SNORT is the defacto standard for intrusion detection/prevention. It is an open source network intrusion prevention and detection system utilizing a rule‐driven language, which combines the benefits of signature, protocol and anomaly based inspection methods.
See www.snort.org/ for more details.
Incident Handling
The term incident is defined as any irregular or adverse event that occurs to any part of the organization. Some examples of possible incidents include:
▪ Compromise of system integrity
▪ Denial of system resources
▪ Illegal access to a system (either a penetration or an intrusion)
▪ Malicious use of system resources,
▪ Any kind of damage to a system.
Some possible scenarios for security incidents are:
1 Any strange process running and accumulating a lot of CPU time.
2 Discovering an intruder logged into a system.
3 Discovering malware has infected the system.
4 Being alerted to a remote site as it is attempting to penetrate the system.
The steps involved in handling a security incident are categorized into six stages:
1 Protection of the system
2 Identification of the problem
3 Containment of the problem
4 Eradication of the problem
5 Recovering from the incident
6 The follow‐up analysis
The actions taken in some of these stages are common to all types of security incidents.
Attackers are not terribly considerate and attacks may occur at any time of the day or night in our permanently connected Internet world. In the case of targeted attacks, an attacker is more likely to attack the site during the organizations off hours (including weekends and public holidays).
It is important to know how long it will take the staff to respond. Earlier in the book we covered time based security. It takes a system administrator 24 hours to respond on a weekend it is unlikely that they will stop an attack. It is also likely that the attacker will have sufficient time to be able to destroy evidence or cover‐up their attack.
Both time and distance are important considerations when considering incident response. Where it is unlikely that the primary contact will be able to respond within a reasonable time frame, a secondary contact must be called in addition to the initial person. It is the responsibility of the employees on the incident call list to establish whether they are able to respond to the incident within an acceptable time frame.
Another important consideration is the press. If a member of the press obtains information concerning a security incident, it is likely that an attempt to gather further information concerning the incident will be made. Worse, they will attempt to obtain this information from personnel on site. These personnel are likely to be involved in responding to the incident when the press calls. Not only does this interrupt the incident process, but providing information to the wrong individuals can have detrimental side effects.
Keep a Log Book
Logging of information is critical in any situation that could end up in court. Any incident has the potential to end up in a criminal trial. At the beginning of an incident the implications remain unknown and the only discovered during the course of the investigation (if at all). A written log should be maintained for all security incidents that are being investigated. This notebook should be kept in a location that is not generally accessible to others and in a format that is not easily altered (i.e. do not take notes using a pencil). Log book should be maintained at least for the minimum statutory period.
Manually written logs are preferable since on‐line logs can be altered or deleted. The types of information that should be logged are:
▪ Dates and times of incident‐related phone calls.
▪ Dates and times when incident‐related events were discovered or occurred.
▪ Amount of time spent working on incident‐related tasks.
▪ People you have contacted or have contacted you.
▪ Names of systems, programs or networks that have been affected.
Inform the Appropriate People
It is important that the appropriate people are informed as soon as an incident is determined. What is more important though is to have a list of these people prior to the incident. Preparation is important.
It is also important to be able to contact people quickly. This means keeping the phone numbers and contact details of key contacts and ensuring that alternate contacts are defined.
Follow‐up Analysis
Post‐incident response is just as important as the procedures used to determine and respond to the incident. Once the incident has been dealt with and systems have been restored to a satisfactory condition (ideally being in a normal mode of operation) a post‐mortem analysis can occur in order to discover what went wrong.
All involved parties (or a delegate from each group) should be present at a meeting to discuss the actions that were taken during the incident. This should culminate in the creation of a lessons learnt document. Where necessary, existing procedures should be evaluated and modified.
The outcome of this process should include a set of recommendations that should be presented to the suitable management representatives. The security incident report needs to be written and distributed to the appropriate parties.
Auditing to Determine What Went Wrong
Unfortunately things go wrong no matter how effective the security controls are. Security is a risk based function. This means it is constrained in all cases by economic constraints. All resources are limited and the cost and benefits need to be weighted. Though we seldom admit it, even human life has a value. When a government looks at the inclusion of a control designed to reduce the loss of life in an industry, this is weighted against the other possible uses of the revenue. For instance, would $10 million annually be better spent on mine controls that save 1-10 lives a year against a one off aid grant of $50 million that would save 5000 starving refugees?
As things go wrong, we need to be able to determine why the failure occurred and to be able to decide if the occurrence was due to a control failure or a one off issue that is unexpected and cannot be reasonably forecasted. This is where logs are critical. Knowing what happened is both a means of being able to assess existing controls (with a motive to improving them) and also providing evidence of due care.
Both incident handling and forensic analysis require some form of audit trail.
Audit Trails
Audit trails help to provide individual accountability for all users in the organization (including privileged users). Following an incident audit trails are useful in aiding incident response personnel in the process of reconstructing events. Correctly monitored they also provide a basic level of intrusion detection and problem identification.
An audit trail is the sum of the records created through the process of recording information concerning events and occurrences into a database or log file. Ideally, logs should not be kept on the source system. By sending logs to an alternate system, privilege users can be excluded from the ability to change or alter logs. Audit trials enable the tracking of the history of modifications, deletions, additions to data on a system allowing for accountability.
Audit logs should at a minimum record:
▪ Transaction time and date
▪ Who processed transaction
▪ Which terminal or system was used
▪ Various security events relating to transaction
Is necessary to have a policy that dictates which events are to be audited and how frequently. This policy should also address data extraction as well as retention periods associated with the logs.
Some considerations that need to be addressed to ensure the secure operations of a logging system include:
▪ Media handling
▪ Controls to ensure protection against alteration or integrity loss
▪ Controls to ensure protection against unavailability of the logging system (both unavailability during audit and more importantly ensuring the capacity and availability to guarantee the logs are not lost)
▪ Sampling or data extraction is the practice of extracting selected data from overall data source in order to assemble a statistically significant representation of the whole.
▪ Record Retention relates to regulatory requirements concerning the storage of records and data. Records must be maintained in accordance with management policies, legal, audit and tax requirements. For privacy reasons, employees and customers need to be made conscious of any data being held by the organization concerning them.
Evidence of Past Incidents
Where an incident has been discovered after the fact, there may not be a great deal of evidence on hand to identify who the party was or how access to the system was obtained. The use of separate logging systems and forensic procedures will help, but the best thing is to have an effective monitoring and response strategy and the capability to discover incidents early.
Monitoring and Logging
Monitoring is a type of active auditing that is based on the constant review of the audited information or the audited asset. Problem identification and problem resolution are primary goals of monitoring. And the main types of monitoring include:
▪ Event monitoring
▪ Clipping Level (baselining)
▪ Hardware monitoring (fault detection, port)
▪ Illegal software/content monitoring (P2P software, Games Copy righted movies and music and Inappropriate content)
The notion of monitoring incorporates monitoring for illegal software installation, monitoring hardware for faults and error states, and monitoring operational events for anomalies. Monitoring is an essential part of the problem identification and resolution process.
Monitoring incorporates the methods, tools, and techniques used to allow for the recognition of security events that might impact the organization's operations or facilities. It expands into the measures needed to be employed in order to successfully recognize the significant elements of an event and to report that information in a suitable way.
Some of the techniques associated with monitoring include:
▪ Intrusion Detection
▪ Audit and Penetration Testing
▪ Violation processing by means of clipping levels
Summary
To be effective it is important that all standards, guidelines and procedures clearly defined in advance and are aligned to the organization's management practices. Operations Security consists of a series of controls that are designed to maintain the security of the organization's resources from design to deployment to disposal.
Maintaining operational security requires a dedicated and directed effort in auditing and monitoring events and ensuring that incidents responded to quickly and effectively.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.