5.3.1.1.  Project Scopes and Objectives

The project scopes and objectives can influence the style of analysis and types of deliverables of the security risk assessment. The scopes of a security risk assessment may cover the connection of the internal network with the Internet, the security protection for a computer centre, or even the information security of the whole department. Thus, the corresponding objectives may want to identify the security requirements such as protection when connecting to the Internet, to identify potentially risky areas in a computer room, or to assess the overall information security level of a department. The security requirements should be based on business needs, which are typically driven by the senior management, to identify the desired level of security protection in the B/D.

5.3.1.2.  Background Information

It refers to any relevant information that can provide initial ideas to the consultant about the assessment. For example, the historical and current information of the system under study, the related parties, brief information about the last assessment, or the near future changes which may affect the assessment.

5.3.1.3.  Constraints

Constraints like time, budget, cost, technology and other restrictions should also be considered. This may affect the project schedule and the available resources to support the assessment. For example, it may be necessary to perform the assessment at non-peak office hours or even at non-office hours.

5.3.1.4.  Roles and Responsibilities of Stakeholders

Roles and responsibilities of all parties involved should be carefully defined. A team or group of individuals representing a variety of disciplines with assigned responsibilities is recommended to best accomplish the assessment. Depending on the availability and requirements, some or all of the following members may be included:

• System or information owners

• IT security officers

• Computer operational staff

• System or network administrators

• Application or system developers

• Database administrators

• Users or senior users

• Senior management

• External contractors

5.3.1.5.  Approach and Methodology

The assessment approach or methodology analyses the relationships among assets, threats, vulnerabilities and other elements. There are numerous methodologies. Generally, they can be classified into two main types : quantitative and qualitative analysis.

To be more useful, the methodology chosen should be able to produce a quantitative statement about the impact of the risk and the effect of the security problems, together with some qualitative statements describing the impact and appropriate security measures for minimising these risks. Details of the two analysis methods will be explained in subsequent sections.

5.3.1.6.  Project Size and Schedule

One of the most important tasks is to prepare a project schedule stating all major activities that will be performed in the assessment study. The planned project size such as project cost and the number of staff involved can directly affect the project schedule. This project schedule can be used for progress control and project monitoring.

5.3.1.7.  Data and Tools Protection

Throughout stages of the security risk assessment, a tremendous amount of data and system configurations will be collected where some of them may contain sensitive information.

Therefore, the assessment team should ensure all the collected data are stored securely. File encryption tools and lockable cabinet/room should be arranged at the planning stage to prevent unauthorised access to the sensitive data.

Besides, the assessment tools should also be properly maintained, controlled and monitored to avoid misuse. Such tools should only be run by the subject experts within the assessment team to avoid potential damages to the system. These tools should also be removed immediately after use unless there is proper control to protect them from unauthorised access.

At the end of the assessment process, a security risk assessment report will be compiled to document all the risk findings. Any unauthorised access to such information, especially before rectification, may pose immediate threats to the B/D concerned. Hence, it is crucial that the assessment team enforces proper protection on the security risk assessment report during and after the documentation process. Senior management should also be reminded to treat the security risk assessment report in strict confidence. Lastly, the assessment team should also return all requested data or documents to the B/D concerned.

5.3.2.1.  General Control Review

This method is to identify any potential risks or threats in general controls being put in place for the current environment by examining the systems manually through interviews, site visits, documentation review, and observations, etc.

This may include, but is not limited to, the following:

• Departmental IT security organisation, in particular staff roles and responsibilities

• Management responsibilities

• IT security policies

• Human resource security, including security awareness training

• Asset management

• Access control, such as password policy, access privileges

• Cryptography

• Physical and environmental security

• Operations security

• Communications security

• System acquisition, development and maintenance

• Outsourcing security

• Security incident management

• IT security aspects of business continuity management

• Compliance

The following methods can be considered in collecting the information:

• Site Visits : visit to the data centre, computer rooms, and office environment should be arranged to identify physical security risks. In addition, assessment team should record down on-site observations about system operations and end user behaviours (e.g. the use of password-protected screensaver) in order to verify if relevant security policies are followed accordingly.

• Group Discussions : group discussions or workshops can be facilitated by the assessment team to gather information about the existing security environment (controls and risks) of the B/D or information systems. The discussion can be any format and topic, depending on the target information to be gathered.

• Multi-level Interviews : on-site interviews with key persons or representatives at different levels may also be conducted to verify previously obtained information, and to improve the accuracy and completeness of the collected information.

• Questionnaires : questionnaires or checklists are effective tools to identify the potential risks. Questionnaires can be customised and developed by the security consultants to tailor for the environment.

For example, multi-level interviews may involve different categories of staff such as:

• Senior management : who decides strategies such as scope and objective of the assessment.

• Line management : who needs to understand the main business processes and procedures that would be affected by the strategic security changes.

• Human resources personnel : who need to identify specific controls for hiring, terminations and transfers of staff related to systems security and usage rights.

• Operational and technical personnel : who provide technical and operational information.

For a high-level assessment or a design-phase assessment, the use of site visit and questionnaires methods may not be applicable or feasible. Hence, security assessment team should focus information collection from activities such as group discussion and multi-level interviews.

Annex A shows a list of general questions for security risk assessment.

5.3.2.2.  System Review

This review is to identify any vulnerabilities and weaknesses of network or systems. It will focus on operating system, administration and monitoring tools in different platforms.

Examples are:

• System files or logs

• Running processes

• Access control files

• User listing

• Configuration settings

• Security patch level

• Encryption or authentication tools

• Network management tools

• Logging or intrusion detection tools

Assessment team should also spot if there is any abnormal activity such as intrusion attempt.

To collectively gather the above information more efficiently and comprehensively, automated scripts and/or tools can be tailored to run on the target host to extract specific information about the system. Such information will be useful in the later stage of risk analysis.

Technical vulnerability tests such as vulnerability scanning and penetration testing should be performed to identify the vulnerabilities and weaknesses of network or systems when necessary. Before conducting the vulnerability scanning and/or penetration testing, the assessment team should agree with the B/D on the scope, possible impact and fallback/recovery procedure. This should be based on the Business Continuity Plan and Disaster Recovery Plan if mission critical systems are involved.

Vulnerability scanning at network, hosts and systems should be performed to cover at least the following where appropriate:

• Network level probing/scanning and discovery

• Host vulnerability tests and discovery

• System/application (including web system/application) scanning

The assessment team should review whether patches or compensating measures have been applied for all applicable known vulnerabilities including but not limited to all relevant security alerts issued by the Government Computer Emergency Response Team Hong Kong (GovCERT.HK).

For Internet-facing web applications processing classified information, websites with input fields or mission critical systems, web penetration testing should also be performed.

For details on vulnerability scanning and/or penetration testing, please refer to Clause 5.3.3.3 – Vulnerability Analysis.

5.3.3.1.  Asset Identification and Valuation

All assets included within the scope of security risk assessment, both tangible and intangible, such as information, services, reputation, hardware and software, communications, interfaces, physical assets, supporting utilities, personnel and access control measures must be identified.

Data classification is a key input to the assessment process and each asset can be classified into different categories. For example, an asset can be grouped under a process, an application, a physical asset, a network or a certain kind of information. The purpose is to show the importance of these assets to the systems or areas under assessment.

It should be noted that the asset valuation approach will be different and will depend on the analysis method adopted. The risk analysis methods are explained in Clause 5.3.3.6 – Risk Results Analysis.

Values of assets can be expressed in terms of:

• Tangible values such as replacement costs of IT facilities, hardware, software, system data, media, supplies, documentation, and IT staff supporting the systems.

• Intangible values such as goodwill and improved service quality.

• Information values, e.g. confidentiality, integrity and availability.

• Data classification of the information stored, processed, or transmitted by the asset.

The output of asset identification and valuation process is an inventory checklist of assets with their corresponding values, if any, in terms of their tangible values, intangible values, or information values in terms of confidentiality, integrity and availability. The more specific values the assets are needed, the more time is required to complete this process.

The output checklist may include the following items, but not limited to:

• Name and type of the information assets.

• Physical location of the assets.

• Storage media and retention period before information stored/processed is destroyed.

• Nature of information stored/processed such as backup or original copy.

• Indicator showing the importance/values of the assets such as the sensitivity levels, operation needs or criticality.

• Incoming/outgoing information flow such as information transmission mode via email, dial-up modems or other telecommunication links.

• Software installed.

• Development and maintenance costs.

• Values of each identified assets.

5.3.3.2.  Threat Analysis

A threat is a potential event or any circumstance with the potential to adversely impact the information assets, systems and networks, in terms of confidentiality, integrity and availability. Threat analysis may need to be occasionally revised to reflect any new potential threats to the information asset.

Examples of sources of threats are:

• Human errors

• Disgruntled employees

• Malicious or careless personnel

• Misuse of systems and computer resources

• Computer fraud

• Theft

• Industrial espionage

• Environmental disasters

Threat analysis is to identify the threats and to determine the likelihood of their occurrence and their potential to harm systems or assets. System errors or control logs can be a good source of data, which can be converted into threat event information and statistics.

Threats can be categorised into three main types:

• Social threats : directly related to human factors, can be intentional or unintentional, such as human errors, results of omission or negligence, theft, fraud, misuse, damage, destruction, disclosure and modification of data.

• Technical threats : caused by technical problems such as wrong processes, design flaws, breakage of communication paths like cabling.

• Environmental threats : caused by environmental disasters such as fire, water damage, power supply, and earthquake.

5.3.3.3.  Vulnerability Analysis

Vulnerability is a weakness in operational, technical and other security controls and procedures that could be exploited by a threat, allowing assets to be compromised. Examples are the interception of data transmission and the unauthorised access of information by third parties. Vulnerability analysis is to identify and analyse the vulnerabilities of the system and environment. It is important to systematically measure these vulnerabilities.

Each vulnerability can be assigned with a level or degree (e.g. high, medium, low) to indicate its importance. Key and critical assets must first be identified.

Vulnerability identification will concentrate on identifying vulnerabilities, with the assistance of automated tools or programs, over the network using one of the following methods:

1. Vulnerability Scanning

   Assessment team can perform vulnerability scans, using an automated vulnerability scanning tool, to quickly identify known vulnerabilities on the target hosts or network devices. Similar to an anti-malware solution, scanning tools are installed on assessment team’s computer and require regular updating on the vulnerability signature files before use. Based on user requirements, a single or group of hosts/networks will be scanned for known vulnerable services (e.g. system allows anonymous File Transfer Protocol (FTP), sendmail relaying) to identify existence of any vulnerability.

   Since a large amount of system requests could be generated from the automated vulnerability scanning tool, the system and network performance of the target groups for scanning may be impacted during the vulnerability scanning process. The assessment team should devise a plan with the system and network administrators to minimise possible service interruption during the vulnerability scanning.

   Furthermore, it should be noted that some of the potential vulnerabilities identified by the automated scanning tool may not represent real vulnerabilities in the context of the system environment. For example, some of the “vulnerabilities” flagged by the automated scanning software may actually not vulnerable as there may already be compensating control in place. Thus, this test method may produce false positives and require professional judgment by the assessment team to determine the validity of the identified vulnerability.

   Network vulnerability scanning is a good method to collect vulnerability information within a short period of time. In contrast to penetration testing, network vulnerability scanning is non-intrusive and does not attempt to exploit the identified vulnerability. Therefore, a penetration testing may be adopted if a more in-depth security analysis is required.

   For applications such as web applications or mobile applications, application vulnerability scanning should be performed to discover security vulnerabilities before they are exploited.

2. Penetration Testing

   Penetration testing can be performed internally or externally. It involves manual process supplemented with automated tools, which may be installed on a portable computer, to scan the network or system to create a network map of connected workstations and servers, and to identify vulnerabilities from either inside or outside the network and system under study by attempting to penetrate them.

   Penetration testing may also involve user interviews and the use of different hacking techniques to test the system or network. The level of details and types of hacking have to be thoroughly planned and agreed before proceeding. Hacking may stop after gaining access to a particular system, or after further in-depth analysis for the system being penetrated. Advice from vendor or security assessment team should be sought before deciding to perform hacking or not. Legal matters should be settled beforehand when dealing with external ethical hacking.

   The objectives of the penetration testing include, but are not limited to the following:

   • To identify security weaknesses by testing system’s ability to withstand intentional attempts.

   • To test and validate the efficiency of security protection and controls.

   • To test the defensive ability to detect and respond to attacks.

   Typical steps of a penetration testing are depicted in the Figure 3 below:

   

   Figure 3 — Typical Steps of a Penetration Testing

   B/Ds should pay special attention to penetration testing because the tests may bring impacts to the systems similar to real-world attacks, such as service disruption, unauthorised access or unauthorised data modification, etc. Thus, before conducting a penetration testing, B/Ds should consider the following security concerns:

   • The scopes and objectives must be clearly defined; machines / systems outside the scope shall never be tested.

   • The vendor should discuss and agree with the owner on suitability and impact of intrusive attacks and denial of service (DoS) attacks.

   • The vendor performing the penetration test shall sign a non-disclosure agreement to protect the privacy or confidentiality of the data in the system.

   • Only acquire the service from vendors with good credibility and track record. Consider to conduct background checks and qualification checks on the vendors to see if they possess necessary experience and expertise.

   • Latest full system backup of the target systems must be available because the penetration tests may impact the integrity of the data in target system.

   • Clearly define the “capture-the-flag” situation, such as placing a file in a designated directory, acquiring the password of some testing accounts, accessing designated web pages which should have proper access control, etc. Production data shall never be modified or deleted.

   • Provide contact list to vendor for emergency contact, such as system owner, IT administrators. The staff will be the contact points for the vendor to report any emergency situation arisen during the tests.

   • Get the contact list of the vendor so that B/D can stop all tests promptly, if necessary.

   • Inform and alert the security monitoring vendor prior to the penetration testing unless it is intended to assess the effectiveness of the monitoring capability of the vendor.

   • Get in advance the source IP addresses of the machines going to perform the testing so that it could be determined if an attack is genuine by examining and comparing the intrusion detection/prevention system logs.

   • Consider to arrange the penetration tests to be conducted at non-peak working hours.

   • Ensure the vendor will not modify any user data even if the vendor can successfully access the user data.

   Examples of penetration testing are:

   • Remote Internet firewall penetration tests: Internet Protocol (IP) address probing, Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) probing, protocol-based DoS attacks such as Internet Control Message Protocol (ICMP) flooding, Domain Name Service (DNS) spoofing, service-based penetration tests such as sendmail, brute-force password attacks and mail bombs.

   • On-site firewall penetration tests: packet sniffing, IP address spoofing, source-routed packets and session hijacking.

   • Telephony penetration tests: brute-force password attacks and war-diallers.

   • Application penetration tests: include but not limited to configuration and deployment management testing, authentication testing, identity management testing, session management testing, error handling etc.

   Tight access control on these automated tools shall be implemented to limit any unauthorised access and usage. As these tools are able to launch simulated attacks such as DoS attacks to your system or network, they should be closely monitored by the security assessment team and the system administrators when being used.

   For more details on penetration testing, please refer to the Practice Guide for Penetration Testing.

5.3.3.4.  Assets/Threats/Vulnerabilities Mapping

Mapping threats to assets and to vulnerabilities can help to identify their possible combinations. Each threat can be associated with a specific vulnerability, or even multiple vulnerabilities. Unless a threat can exploit a vulnerability, it would not be a risk to an asset.

The range of all possible combinations should be reduced prior to performing risk results analysis. Some combinations may not make sense or are not feasible. This interrelationship of assets, threats and vulnerabilities is critical to the analysis of security risks. Factors like project scope, budget and constraints may also affect the levels and magnitude of mappings.

5.3.3.5.  Impact and Likelihood Assessment

Given the assets, threats and vulnerabilities, it is now possible to identify the impact and likelihood.

1. Impact Assessment

   Impact assessment, (or impact analysis or consequence assessment) is to estimate the degree of the overall harm or loss that could occur. Examples of impact are on revenues, profits, cost, service levels and government’s reputation, damage to the confidentiality, integrity and availability of the concerned system. It is necessary to consider about the level of risk that could be tolerated and how, what and when the assets could be affected by such risks. The more severe the consequences of a threat, the higher the risk.

2. Likelihood Assessment

   Likelihood assessment is to estimate the frequency of a threat happening, i.e. the probability of occurrence. It is necessary to observe the circumstances that will affect the likelihood of the risk occurring. In general, the likelihood of a threat exploiting a system’s vulnerability can be measured in terms of different circumstances such as its accessibility and its number of authorised users. The accessibility of a system can be affected by many factors such as physical access control, system configuration, network type, network topology and network interfaces. The system with Internet connection is more likely to have its vulnerabilities exploited than an internal system. Also, the former one may have a large number of authorised users (i.e. the public) than the latter internal system, which has limited number of users. A system with one user is clearly less likely to be exploited than a system with several hundreds or thousands of users. As more people can gain access to the system, it is more difficult to ensure that each individual user performs only those functions he or she is permitted to do. Normally, the likelihood of vulnerabilities exploited increases with the number of authorised users.

   The likelihood can be expressed in terms of the frequency of occurrence such as once in a day, once in a month and once in a year. The greater the likelihood of a threat happening, the higher the risk. For example, if there had been a well-known vulnerability in application software, the likelihood of an intentional social threat exploiting this vulnerability is high. If the systems affected is very critical, then the impact is also very high. As a result, the risk of this threat is high.

   For each identified risk, determine its impact and likelihood to give an overall estimated level of risk. Assumptions should be clearly defined when making the estimation.

5.3.3.6.  Risk Results Analysis

Risk results can be analysed using different methods and ways: Qualitative & Quantitative Methods, and Matrix Approach.

1. Qualitative & Quantitative Methods

   Qualitative method is to use descriptive, word scales or rankings of significance/severity based on experience and judgement. Examples are past experience, market research, industry practice and standards, surveys, interviews and specialists’/experts’ judgements. This method requires a subjective assignment of categories, e.g. levelling using high, medium or low, ordinal ranking from 1 to 5, or degree of importance from least to most significant etc. Qualitative measure is more subjective in nature.

   For instance, the value of an asset can be expressed in terms of degree of importance, e.g. least significant, significant and most significant.

   Quantitative method is to use numerical information to arrive at percentages or numerical values. An example is the cost/benefit analysis. But this method requires more time and resources than the qualitative method, as every possible element (i.e. asset, threat or vulnerability) has to be categorised and considered.

   For example, the value of an asset can also be expressed in terms of monetary value such as the purchase costs or maintenance costs. Threat frequency can be expressed in terms of rate of occurrence, e.g. once a month or once every year.

   Normally, a qualitative method is used for initial screening while a quantitative method is used for more detailed and specific analysis on some critical elements and for further analysis on high-risk areas.

2. Matrix Approach

   A matrix approach can be used to document and estimate the three major needs of security protection: confidentiality, integrity and availability in three different levels of severity (high, medium, low). The risk level can be ranked based on the criticality of each risk elements. Risk interpretation should better be limited to the most significant risks so as to reduce the overall effort and complexity.

   Table 1 shows a sample Risk Ranking Matrix of a particular threat on a particular function or asset. For the Impact and Likelihood columns, a value is assigned to each entry indicating the status (3-high, 2-medium and 1-low). As the risk level is the multiplication of the Impact’s and the Likelihood’s values, it will thus has a value ranging from 1 to 9 (9 – high, 4 & 6 – medium, 1 to 3 — low) excluding 5, 7 and 8 since the multiple of the above two values (Impact’s & Likelihood’s) cannot be 5, 7 or 8. With this matrix, it is possible to classify each threat into one overall risk level.

   Table 1 — A Sample of Risk Ranking Matrix

   Risk Categories	Impact (High, Medium, Low)	Likelihood (High, Medium, Low)	Risk Level = Impact X Likelihood (High, Medium, Low)
   Confidentiality	3	2	6
   Integrity	3	1	3
   Availability	2	1	2
   Overall	3	2	6

   Remarks for Table 1:

   High Impact

   Most significant: major loss and seriously damaging the organisation; severe, catastrophic, or serious long-term damage/disruption
   e.g. DoS; unauthorised access to system

   Medium Impact

   Significant: medium loss which would be detrimental to the organisation; serious short-term, or limited long-term damage/disruption
   e.g. intruder may gather system critical information to gain unauthorised access or launch further attacks

   Low Impact

   Least significant: low loss which would cause little or no damaging to the organisation; limited and short-term damage/disruption
   e.g. intruder may gain non-critical information for processing

   High Likelihood

   Expected to occur in most circumstances

   Medium Likelihood

   Should occur occasionally

   Low Likelihood

   Could occur at specific time or in exceptional circumstances

   High Risk Level

   A low tolerance to risk exposures, i.e. requiring the highest security protection

   Medium Risk Level

   A medium tolerance to risk exposures

   Low Risk Level

   A high tolerance to risk exposures

   Overall Result

   Equal to the highest security risk level in various risk categories

   This matrix can be further extended by classifying sub-categories for risk exposures and with more weighted, numerical values for risk levels.

   Once the risk level is identified, a list of technical, operational and administrative requirements can be produced for each identified asset. This provides a basis for making decisions to accept, reduce, avoid or transfer the risk as risks cannot be completely removed as shown in Table 2.

   Table 2 — List of Risk Options

   When	Options	Description
   - Consequences/likelihood are low - Usability or other factors overweigh security	Accept risk	To bear the liability
   - It is a high risk and cannot be accepted.	Reduce risk	To reduce the consequences or the likelihood, or both
   - The risks are too high or too costly to be reduced and is unmanageable	Avoid risk	To use alternative means or not to proceed with the task that would cause the risk
   - Another party is willing to accept the risk - Another party has greater control over the risk	Transfer risk	To shift the responsibility for the risk to other party either partially or fully

   For any of the options selected, recommendations on how to proceed with the selected option have to be made to management. Besides, safeguards and security controls have to be suggested if it is decided to reduce risk.

   Priority should then be given to each risk to indicate its significance and potential impact. Normally the higher the security risk level, the higher priority should be given. In other words, higher priority risks are usually unacceptable and require more attention from management.

5.3.4.1.  Common Types of Safeguards

Safeguards can be quick fixes for problems found on existing system configurations or planned enhancements. Safeguards can be technical or procedural controls.

In general, safeguards can be classified into three common types:

• Barriers : keep unauthorised parties completely away from accessing critical resources.

• Hardening : make unauthorised parties difficult to gain access to critical resources.

• Monitoring : help to detect and respond to an attack promptly and correctly.

Examples of safeguards:

• Develop/enhance the departmental IT security policy, guidelines or procedures to ensure effective security.

• Re-configure operating systems, network components and devices to cater for the weaknesses identified during the security risk assessment.

• Implement password control procedures or authentication mechanism to ensure strong passwords.

• Implement encryption or authentication technology to protect data transmission.

• Enhance physical security protection.

• Develop security incident handling and reporting procedures.

• Develop staff awareness and training programs to ensure compliance with security requirements.

5.3.4.2.  Major Steps of Identifying & Selecting Safeguards

The selection of appropriate security safeguards is not simple. It requires knowledge and technical skills on the system. The cost of managing risks needs to commensurate with the risk exposure. That is, the cost of reducing risk on a specific asset should not exceed the total value of that asset.

Below are several major steps of identifying and selecting safeguards:

• Select appropriate safeguards for each targeted vulnerability.

• Identify the costs associated with each safeguard such as the development, implementation and maintenance costs.

• Match safeguard/vulnerability pairs to all threats, i.e. develop a relationship between these measures and the threats.

• Determine and quantify the impact of the safeguard, i.e. the extent of risk that can be reduced after applying the selected safeguards.

Different combinations of physical, managerial, procedural, operational and technical based safeguards may be required. An analysis may be required to determine the optimal combinations for different circumstances.

A single safeguard may reduce risk for a number of threats. Several numbers of safeguards may act to reduce risk for only one threat. Hence, the integration of all safeguards shows the overall gross risk reduction benefit as a whole.

The effects of using different safeguards should be tested before implementation. Hence, this selection process may need to be performed several times to see how the proposed changes affect the risk results.

However, there are also other factors that have to be considered other than those identified in security risk assessment.

For example,

• Organisational factors like department’s goals and objectives.

• Relevant statutory, regulatory and contractual requirements.

• Cultural factors such as social custom, beliefs, working styles.

• Quality requirements such as safety, reliability, system performance.

• Time constraints.

• Supporting services and functions.

• Technical, procedural and operational requirements and controls.

• Existing technology available in the market.

6.3.1.1.  Project Scopes and Objectives

Audit scopes and objectives should be clearly defined and established. User requirements should be identified and agreed with security auditors before proceeding.

Examples of security audit scopes are:

• Internet security

• General security of an internal network

• Mission-critical systems

• Hosts security

• Network server’s security such as web servers, email servers etc.

• Network components and devices such as firewalls, routers etc.

• General security of a computer room

• Network services such as directory services, mailing services, remote access services

Some audit objectives are listed below for reference:

• To provide evidence of compliance with the system security policy.

• To examine and analyse the safeguards of the system and the operational environment.

• To assess the technical and non-technical implementation of the security design.

• To validate proper or improper integration and operation of all security features.

6.3.1.2.  Constraints

The period allowed for auditing should be adequate and sufficient enough to complete all tests. Sometimes the systems or networks have to be off-line or not in live production when performing the audit. Possible service interruption may occur. Backup and recovery of existing configuration and information must be performed before starting the security audit.

6.3.1.3.  Roles and Responsibilities

Similar to conducting a security risk assessment, the roles and responsibilities of all parties involved should be carefully and clearly defined. Typical members involved can be referenced to “Clause 5.3.1.4 Roles and Responsibilities of Stakeholders”.

In particular, the security auditors, after their appointment, should plan for pre-audit by:

• Identifying and verifying the current environment via documentation, interviews, meetings and manual review.

• Identifying the significant areas or operations that are related to the audit.

• Identifying the general controls that may have effects on the audit.

• Estimating and identifying the resources required such as the auditing tools and manpower.

• Identifying any special or additional processing for the audit.

A security audit must be properly controlled and authorised before proceeding. A communication channel must be established between B/Ds and the security auditors.

On the other hand, there are two major areas that should be considered beforehand:

• Independence of Security Auditors

  It is required to consider whether the appointed security auditor is appropriate for the nature of the planned security audit. An independent and trusted party should be chosen to ensure a true, fair and objective view. The hiring of internal or external security auditors should be carefully planned, especially when dealing with classified information. The selection of auditors and conduct of audits shall ensure objectivity and impartiality of the audit process. Auditors shall not audit their own work.

• Staffing

  The audit should be performed by auditors with sufficient skills and experience accompanied by system administrators. Roles, responsibilities and accountabilities of each involved party should be clearly defined and assigned.

8.4.3.1.  Progress & Status of Actions

There are different progress and status of actions:

• Actions not yet started

• Completed actions

• Actions being undertaken with a target completion date

• Reasons for actions not being taken

• Alternative actions if different from recommendations

8.4.3.2.  Follow-Up Actions

Some follow-up actions are suggested for considerations:

• Review the implementation plans, documentation and time frames for planned actions.

• Find the underlying reasons why the action was not taken.

• Establish additional steps or tasks to handle the technical, operational or managerial difficulties.

• Find alternative recommendations due to unexpected environmental or requirement changes.

• Determine the “closing” of recommendations when they are proved to be successfully implemented and tested, to be no longer valid, or to be unsuccessful even after further actions.

• Assess the effectiveness of the corrective actions.

• Report accomplishment, status and progress to management.

• Escalate to management whenever applicable, especially when implementation of key recommendations is inadequate or delayed.

* ENDS *