Technical Vulnerability Management

Objective: To prevent exploitation of technical vulnerabilities.

This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.

12.6.1 Management of technical vulnerabilities 2907

Control 2908

Information about technical vulnerabilities of information systems being used should be obtained in a 2909

timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures 2910

taken to address the associated risk. 2911

Implementation guidance 2912

A current and complete inventory of assets (see 8) is a prerequisite for effective technical 2913

vulnerability management. Specific information needed to support technical vulnerability 2914

management includes the software vendor, version numbers, current state of deployment (e.g. 2915

what software is installed on what systems), and the person(s) within the organization responsible 2916

for the software. 2917

Appropriate, timely action should be taken in response to the identification of potential technical 2918

vulnerabilities. The following guidance should be followed to establish an effective management 2919

process for technical vulnerabilities: 2920

a) the organization should define and establish the roles and responsibilities associated with 2921

technical vulnerability management, including vulnerability monitoring, vulnerability risk 2922

assessment, patching, asset tracking, and any coordination responsibilities required; 2923

b) information resources that will be used to identify relevant technical vulnerabilities and to 2924

maintain awareness about them should be identified for software and other technology 2925

(based on the asset inventory list, see 8.1.1); these information resources should be 2926

updated based on changes in the inventory, or when other new or useful resources are 2927

found; 2928

c) a timeline should be defined to react to notifications of potentially relevant technical 2929

vulnerabilities; 2930

d) once a potential technical vulnerability has been identified, the organization should identify 2931

the associated risks and the actions to be taken; such action could involve patching of 2932

vulnerable systems and/or applying other controls; 2933

e) depending on how urgently a technical vulnerability needs to be addressed, the action taken 2934

should be carried out according to the controls related to change management (see 12.1.2) 2935

or by following information security incident response procedures (see 16.1.5); 2936

f) follow the patch management procedures: 2937

1) if a patch is available from a legitimate source, the risks associated with installing the 2938

patch should be assessed (the risks posed by the vulnerability should be compared with 2939

the risk of installing the patch); 2940

2) only approved patches from the IACS vendor that have been tested and/or evaluated 2941

should be installed in the production environment to ensure they are effective and do 2942

not result in side effects that cannot be tolerated; if no patch is available, other controls 2943

should be considered, such as: 2944

i) turning off services or capabilities related to the vulnerability; 2945

ii) adapting or adding access controls, e.g. firewalls, at network borders (see 13.1 ); 2946

iii) increased monitoring to detect actual attacks; 2947

iv) raising awareness of the vulnerability; 2948

g) an audit log should be kept for all procedures undertaken; 2949

h) the technical vulnerability management process should be regularly monitored and 2950

evaluated in order to ensure its effectiveness and efficiency; 2951

i) systems at high risk should be addressed first. 2952 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.

j) an effective technical vulnerability management process should be aligned with incident 2953

management activities, to communicate data on vulnerabilities to the incident response function 2954

and provide technical procedures to be carried out should an incident occur; 2955

k) define a procedure to address the situation where vulnerability has been identified but there is 2956

no suitable countermeasure. In this situation, the organization should evaluate risks relating to 2957

the known vulnerability and define appropriate detective and corrective actions. 2958

Other information 2959

Technical vulnerability management can be viewed as a sub-function of change management and 2960

as such can take advantage of the change management processes and procedures (see 12.1.2 2961

and 14.2.2). 2962

Vendors are often under significant pressure to release patches as soon as possible. Therefore, 2963

there is a possibility that a patch does not address the problem adequately and has negative side 2964

effects. Also, in some cases, uninstalling a patch cannot be easily achieved once the patch has 2965

been applied. 2966

If adequate testing of the patches is not possible, e.g. because of costs or lack of resources, a 2967

delay in patching can be considered to evaluate the associated risks, based on the experience 2968

reported by other users. The use of ISO/IEC 27031 can be beneficial. 2969

12.6.2 Restrictions on software installation

2970

Control 2971

Rules governing the installation of software by users shall be established and implemented. 2972

Implementation guidance 2973

The organization should define and enforce strict policy on which types of software users may install. 2974

The principle of least privilege should be applied. If granted certain privileges, users may have the 2975

ability to install software. The organization should identify what types of software installations are 2976

permitted (e.g., updates and security patches to existing software) and what types of installations are 2977

prohibited (e.g., software that is only for personal use and software whose pedigree with regard to 2978

being potentially malicious is unknown or suspect). These privileges should be granted having regard 2979

to the roles of the users concerned. 2980

Software installation on IACS devices must be carefully managed because a new application or an 2981

update of an existing application may interfere with the system performing its intended task. Only 2982

system administrators and lead IACS support engineers should have the privileges to install 2983

software. Operators and other end users should not be given the privileges to perform this task. 2984

Other information 2985

Uncontrolled installation of software on computing devices can lead to introducing vulnerabilities and 2986

then to information leakage, loss of integrity or other information security incidents, or to violation of 2987

intellectual property rights. 2988

12.7 Information systems audit considerations