Include controls in the system

Overview

Image: Overview

You should already know about identifying threats to a system, determining risk category, and identifying appropriate controls. This resource will help you to include controls in the system within an information technology environment.

In this topic you will learn how to:

  • develop a security plan and procedures to include in a management system
  • develop a security recovery plan
  • implement system controls to reduce risks in human interaction with the system.

This topic contains:

  • reading notes
  • activities
  • references
  • topic quiz.

As you work through the reading notes you will be directed to activities that will help you to practise what you are learning. The topic also includes references to aid further learning and a topic quiz to check your understanding.

Download a print version of this whole topic: Include controls in the system(185KB 2810.doc).

Reading notes

Image: Reading notes

Develop security plan and procedures to include in the management system

Managing system security is an ongoing process that requires planning and long-term implementation. In previous readings we have looked at the process of performing a risk analysis on a computer system so that we can identify and protect the system against possible risks.

To recap, the process is briefly defined as follows:

The seven steps to risk analysis

When conducting a risk analysis, seven steps may be used.

  1. Define the boundary, scope, and methodology
  2. Identify and Value Assets
  3. Identify Threats and Determine Likelihood
  4. Measure Risk
  5. Select Appropriate Safeguards
  6. Implement and Test Safeguards
  7. Accept Residual Risk

In this topic we will look at selecting and applying appropriate safeguards - in particular developing security plans, recovery plans and putting in place system controls.

What is a security plan?

An essential element in any organisation's security strategy will be to develop a Security Plan.

There are many elements to network security including people, hardware software policies and procedures. A security plan co-ordinates all these security measures to make sure there are no security gaps in the system.

A good example of the process of evaluating security and creating a security plan can be found in the Microsoft document "Security Guide for Small Business" available online at

An organisation's security plan should be tailored to the organisations needs. Some of the factors to consider in the process of setting up a security plan may include the following:

  • Services: Each service carries its own security risk. Consider the importance of each service in allocating resources to its protection
  • Usability: Too much security can make the system cumbersome to access and use - a balanced view needs to be considered.
  • Cost: Security can be expensive depending on the security level an organisation wants to achieve. However, risk of loss must also be considered. For example, revenue-generating systems such as web servers may not be able to operate after a security breach. Therefore, the loss of this revenue must be considered against the cost of implementing security measures.

Creating a security plan

We will discuss five steps that may be followed when creating a security plan:

  • inventory
  • risk assessment
  • checklist
  • evaluation
  • finalise Security Plan
Step 1: Inventory

In this step, the physical and information assets are identified. To record your findings, you can create a spreadsheet. Document individual items you want to protect.

Some of the areas you need to address include the following:

  • For hardware, name the item and record its specifications.
  • For software, name the applications usedin the organisation. Ensure that you record license details (For example MS Client Access Licenses (CALs)).
  • System interfaces: Look at internal and external connectivity, RAS, VPNs, ISDN, VOIP, and so on.
  • Information type: The essential services that the system is designed to run. May include accounting/sales data, production designs, client information, and so on.
  • Critical/confidential information: degree of importance to maintain security
  • Processes: What protocols are in place - how is security verified? For example, there could be a patented process.
  • Owner:Note who is responsible for carrying out actions and procedures. Who can claim ownership?
Step 2: Risk assessment

Once you have identified the elements that need to be considered in the security plan, you need to analyse the risks to assets, process information and so-on in order to allocate resources appropriately.

Generally this will involve assigning either a low, medium or high risk rating. To arrive at this rating you can start by looking at two factors:

  • Probability - how likely is it that a threat will occur?
  • Impact - what effect will this threat have on the organisation?

Probability and impact of occurrence are typically used to set the level of security needed. Put simple you can use this formula:

Probability × Impact = Security Risk Level

This is illustrated in the following diagram:

Image: Illustration showing relationship between impact and risk. Combinations of increasing risk impact and probability are multiplied to come up with an increasing risk level.

Figure 1: Illustration of process for multiplying impact and probability to arrive at a final Security Risk Level.

Sample scenario:

Consider this small scenario:

The Sales Department performs a full data backup of the CRM (Customer Relations Management) system onto tapes. These tapes are then stored in a locked fireproof safe next to the CRM database server.

To assign a security risk level to this situation, you may consider the following:

  • Probability: What is the likelihood that both the server and the fireproof safe can be stolen at the same time, low/1, medium/2 or high/3?
  • Impact: What will be the impact to the organisation if theft occurs:low/1, medium/2 or high/3?

Youmight say that the probability of both being stolen is medium (or a value of 2) but the impact on the organisation would be high (value of 3).

Security level is then set by the following.

Probability (2)× Impact (3) = High Security Risk Level (6)

Assigning these values is a matter of judgement but if in doubt, always opt for the higher level.

Information risk:

When performing a security risk assessment, you need to consider not just physical assets, but also information and data.

  • Information confidentiality: Confidentiality risk refers to the impact of intrusion on information assets, such as client information, passwords, databases and so on.
  • Information integrity: What might the impact be if inaccurate data is used to make business or management decisions? The release of inaccurate data to clients, regulators, shareholders, the public and so on, could lead to a loss of business, possible legal action or public embarrassment.
  • Information availability: This term also refers to business disruption risk. What would the probability and impact be if a system was rendered inoperable following a security attack?
Step 3: Checklist

A security plan will endeavour to cover all risk areas within an organisation. Following on from the previous step of conducting a risk analysis, you can use a practical tool such as a checklist begin to apply your findings to specific assets. Download this sample checklist (59 KB 2810_checklist.doc) as a guide for addressing security risks in an organisation.

We will use this checklist again in the next step. Note that this is a very short list. Typical organisations would add many items to each section of this list for implementation on their own systems.

Step 4: Evaluation

A checklist such as the one above provides the opportunity to respond with a positive or a negative answer. The questions aim to provide an overview to ensure that all aspects of security have been covered in the procedures already in place.

Where a negative result is given to questions in the checklist, your security plan will need to focus on the negative results,as this will show an area that needs improvement in the organisation.

Step 5: Finalise Security Plan

The negative results discovered by applying the checklist are then used to formulate the Security Plan. Typically, target dates for actions and events are set where possible, as well as the person responsible for meeting that target date. Like all business plans, the Security Plan must be reviewed, approved, and added to the Management System.

Download this Sample Security Plan (70KB 2810_sample_secplan.doc). You may want to use this as a model when you are developing your own plans. You can also perform a general web search for the term "network security plan" to look for other examples from organisations on the web.

For a comprehensive overview of creating a security plan, it is strongly recommended that you download the Australian Government Information and Communications Technology Security Manual from: This provides authoritative guidelines for IT security management for Australia. Look at the section on "Developing an SSP" (System, Security Plan).

Activity 1

To practise developing a security plan, complete Activity 1—Develop security plan, located in the Activities section of the Topic menu.

Develop a security recovery plan

Preparing and guarding against security threats and managing security risks are essential first steps for an organisation. However, there will always be incidents where threats occur and systems are at risk. An organisation also needs to have plans in place for performing a quick and thorough recovery after a security event.

In this section, we will discuss issues that will lead us to develop a Security Recovery Plan. This can also be called handling security incidents.

The security policy defines the rules to regulate an organisation’s efforts to manage and protect computing resources.

Security response procedures

These procedures address actions that must be performed to restore the network system to its pre-attack,operational status. Security recovery guidelines must be developed at management level to respond to such security breaches.

Redundancy policy

This police ensures that key system components that have been compromised can be replaced by fully operational systems.

Some examples:

  • If a production server is suspected of a security breach, it must be taken off-line immediately for investigation. The Redundancy Policy ensures that a replacement server can take the place of the main production server.
  • It is not always practical to have a replacement server on standby. Instead, server-mirroring can be used where a backup server is maintained to support the primary server, should it become unavailable.
  • Data files on the primary server can be automatically backed up to the backup server periodically. In the event of a security risk, security breaches on the primary server can also be backed up automatically to the backup server.

Security investigation steps

It might seem logical to replace the suspected server with another; however, there is a good chance that the same attack could be deployed against the replacement server. As such, a security investigation must occur immediately and may include the following eight steps:

Step 1: Determine security intrusion attributes
  • Which attacks were used to gain access?
  • Which systems and data were accessed?
  • What was done to the systems or data following unauthorised access?
  • How was the intrusion detected?
  • Was the intrusion in progress when it was detected?
  • Who or which IDS (Intrusion Detection System) software detected the intrusion?
Step 2: Analyse the compromised system
  • The compromised system must be taken off-line immediately and investigated.
  • If this is not possible, the compromised system must be backed up immediately to be tested on another computer similar to the compromised system hardware
  • The Redundancy Policy would have established the availability of this hardware.
Step 3: Analyse other network systems
  • This is probably the most difficult process. However, this action must be performed to ensure that the security breach is not multi-system - that is, not confined to a single system.
  • The best way to approach this is to get the assistance of system users where their duties depend on the peak performance of their systems. Look for anomalies in the system they are using.
Step 4: Secure communication
  • For convenience and speed, it may be tempting to use internal e-mail communication to inform and collect additional information. Do not use this method!
  • Given the security vulnerabilities of internal e-mail tools such as MS-Outlook or MS-Outlook Express, secure communication may be better maintained via personal face-to-face communication.
Step 5: Log all communication
  • Gather as much information as possible from the failed system, other users, and so on. This document must be saved and stored on an independent storage device such as on a laptop that is not connected to the system.
Step 6: Collect and protect information

All information about the compromised system and intrusion must be recorded. If needed, this information can later be used as evidence for prosecution. Information to be collected includes

  • network log files
  • user files
  • IDS reports
  • analysis results
  • backup tapes to identify system status before and after the intrusion.
Step 7: Execute short-term containment strategy
  • Temporarily shut down the compromised system.
  • Disconnect the compromised system from the network.
  • Disable access to the compromised file systems that may be shared with other networks.
  • Disable system services if possible.
  • Change passwords or disable accounts.
  • Monitor system and network activities.
  • Verify the integrity of redundant systems to ensure that data have not been compromised.
Step 8: Eliminate all means of intruder access
  • Change all passwords that the attacker may have used to gain access.
  • Identify and remove any changes to the system that the intruder may have made.
  • Restore executable programs and binary files from original distribution media.
  • Improve protection mechanisms.

Develop System Recovery Plan

Information gained from the above exercises can be used to develop a System Recovery Plan. Like the Security Plan, this is also an action document. So the System Recovery Plan will read like the Security Plan, including

  • What constitues a security incident?
  • What needs to be done?
  • Where are the resources needed?
  • Who will be responsible for doing it?
  • What alternative course(s) of action are there?
  • Who needs to be informed of security incidents?
  • How are security incidents documented and recorded?

Tips for writing a Recovery Plan

To be effective, the plan must be in writing, must be understandable, and must be accessible to those who need it.

Visit the Intranet Journal website and look at the article called "Introduction to disaster recovery planning" at This article addresses strategies for preparing Disaster Recovery Plans (DRP) for IT organisations. It contains a good set of tips for preparing your documentation, such as a System Recovery Plan.

Activity 2

To practice developing a System Recovery Plan, complete Activity 2—Develop Security Recovery Plan, located in the Activities section of the Topic menu.

Implement system controls to reduce risks in human interactions with the system

We will now focus on implementing system controls to reduce risks in human interaction with the system. As the name suggests, this is not about what a user should or should not do. Rather, it is about placing controls into the system so that any harm to the system is minimised as users access the system.

System control types

System controls are typically one of two types:

  • distributed: domain-based controls
  • centralised: AAA-based servers such as RADIUS(RemoteAuthentication Dial In User Service) or TACACS+ (TerminalAccess Controller Access-Control System) servers (AAA stands for authentication, authorization and accounting protocol)

System hardening

System hardening describes the process of implementing better security controls, both on servers and workstations.

As an example, operating systems are typically developed by manufacturers to meet the needs of a wide audience. This means that for a particular business need, the workstation may be running too many unneeded services. System hardening in this case would consist of turning off services that are not relevant to an organisation.

System hardening is a way to ensure that only the needed services are running on the workstation, thus reducing security risks.

Hardening recommendations

Here is a list of recommendation that may be implemented to harden an organisation's networked system:

1Harden any host that is to be shared on the Internet or even on a LAN.

2Never connect an out-of-the-box operating system on a LAN because OEMs (Original Equipment Manufacturers) prepare MS-Windows for a wide audience. Such systems must to be stripped down to the minimum needed for business operations.

3Never connect a Windows server or a workstation that was previously on the Internet to a trusted LAN.

4Turn off all unneeded ports. Use the command line tools "nmap" or "netstat –a" to check for open ports on a machine.

5Turn off all unneeded services.

6Install recommended patches and upgrades.

7Install and maintain a good antivirus application.

8Install personal firewalls on workstations.

9Do not run high-visibility services such as Web, mail, file sharing, etc. on workstations unless a business need mandates them.

10Do not use services that have more secure versions. For example:

  • Use SSH instead of Telnet
  • Use IMAP instead of POP3
  • Use Secure FTP instead of FTP

11Use strong passwords.

System hardening workstations

Centralised system controls are typically implemented by trained IT professionals. Risks due to human interaction with the system are better managed in that way.

Workstations represent a bigger challenge due to their comparatively larger numbers within any organisation and the various work-tasks required to be performed on them. Some recommendations for system hardening a workstation follow: