Bulletin Board - Document Comments

Bulletin Board - Review and Comment

Step 1 of 3: Comment on Document

There are 3 steps in the submission process. You must complete all three steps in one session, otherwise your comments will be lost.

1. Use this Protected Document icon to open a comment box.

2. Type your feedback and then click the"Save Comment" button in the lower-right of the comment box.

3. Do not open more than one comment box at the same time.

4. When you have finished making comments, go to step 2 by clicking on the “Save and Continue” button at the very bottom of this page.

Important Information

During the comment process you are connected to a database. Like internet banking, the session that connects you to the database may time-out due to inactivity or if you close your browser or go to a different tab/window and try to come back.

To ensure that your comments are received:

  1. DO NOT jump between web pages/applications while logging comments.

  2. DO NOT log comments for more than one document at a time.

  3. DO NOT leave your submission unfinished. If you need to take a break, submit your current set of comments now and return later to make a further submission. You will receive a copy of your comments so that you can see what you have already said.

  4. DO NOT exit from the interface until you have completed all three steps of the submission process.  Simply saving a comment in the comment box does not mean it is submitted and if you exit the system, you will not be able to retrieve it later.

When you finalise your submission in step 3 your comments will be emailed to the Document Author with a copy to you, and to policy@mq.edu.au for record keeping purposes.

Vulnerability Management Policy

Section 1 - Purpose

(1) The purpose of this Policy is to establish a consistent and timely approach to identifying and mitigating vulnerabilities in IT Resources.

Scope

(2) This Policy applies to all Macquarie University (the University) Staff and Third-Parties involved in Security Vulnerability management activities.

Top of Page

Section 2 - Policy

(3) University Staff involved in Security Vulnerability management activities should monitor internal and external resources (e.g., Security Vulnerability scanning solutions, vendors’ newsletters/articles, vendor Security Vulnerability notifications, threat intelligence reports, findings from assurance testing, post incident reviews, ad-hoc notifications) for up-to-date intelligence regarding Security Vulnerabilities and Patches.

(4) IT Resources that have reached their End-of-Life support by vendors should (where practicable):

  1. be decommissioned;
  2. be updated to a vendor-supported version;
  3. be replaced with an alternative solution supported by a different vendor; or
  4. if the previous options are unavailable, be appropriately isolated (e.g., via network segmentation) with additional security controls applied (e.g., additional monitoring and alerting), to mitigate risks to an acceptable level.

(5) If Security Vulnerability management activities are outsourced, a Service Level Agreement (SLA) should be in place to require the Third-Party to undertake Security Vulnerability management activities in accordance with this Policy.

Asset Discovery

(6) An automated method of asset discovery should be used at least fortnightly to support the detection of IT Resources for subsequent Security Vulnerability scanning activities.

Security Vulnerability Scanning

(7) A Vulnerability Scanner, with an up-to-date Security Vulnerability database, should be used for Security Vulnerability scanning activities in accordance with the requirements set out in the ‘Security Vulnerability Scanning Schedule’ section of this Policy.

(8) A Security Vulnerability scan should be performed if there is any significant change to the IT Resource. The scan should encompass the scope of the change.

Patch Management

(9) Patches, where released by a vendor, should be deployed according to the Patching Schedule section of this Policy.

(10) Emergency Patching (e.g., out-of-band vendor Patch releases) should be conducted according to the Security Vulnerability’s risk rating, per the ‘Security Vulnerability Risk Rating Assessment’ section of this Policy.

(11) IT Resources that are unable to be patched should have mitigative controls applied (e.g., additional monitoring and alerting), to mitigate risks to an acceptable level.

(12) A rollback and contingency plan, including backup and restore procedures, should be developed for Patches to critical IT Resources.

(13) Patches should be tested prior to implementation into the production environment In situations where Patches cannot be tested prior to deployment the Change Advisory Board will determine whether the Patch should be implemented.

(14) An automated mechanism should be used to confirm and record that Patches have been successfully installed.

Compliance and Exemptions

(15) Exemption from this Policy must be sought from the Chief Information Security Officer (CISO).

(16) Breaches of this Policy by Staff will be managed in accordance with the applicable provisions of the Staff Code of Conduct and other relevant policy instruments.

Top of Page

Section 3 - Procedures

Security Vulnerability Scanning Schedule

(17) The table below outlines the Security Vulnerability scanning schedule that applies to all IT Resources:

IT Resource Category

Examples

Security Vulnerability Scanning Frequency
Internet facing IT Resources
Servers, firewalls, websites, online portals.
Daily
Non-Internet facing IT Resources
Workstations, routers, switches.
Fortnightly
End-User Applications
Office productivity suites, web browsers, their extensions, email clients, PDF software, Adobe Flash Player.
Weekly
Other Applications
Collaboration tools, project management software, accounting and finance software, design tools.
Fortnightly

Patching Schedule

(18) The table below outlines the Patch application timeframe that apply to all IT Resources. Patches should be assessed for critically, in the context of the University, before being implemented.

IT Resource Category

Examples

Patch Application Timeframe
Internet facing IT Resources
Servers, firewalls, websites, online portals.
Within 2 weeks, or within 48 hours if:
  1. a vendor assesses the Security Vulnerability as critical; or
  2. a working exploit exists.
Non-Internet facing IT Resources
Workstations, routers, switches.
Within one month
End-User Applications
Office productivity suites, web browsers, extensions, email clients, PDF software, Adobe Flash Player.
Within 2 weeks
Other Applications
Collaboration tools, project management software, accounting and finance software, design tools.
Within one month

Vulnerability Risk Assessment

(19) A risk assessment must be conducted on vulnerabilities as they are published or advised by software and infrastructure vendors.

(20) The risk rating of a particular vulnerability is calculated by assessing the risk factors in Table 1 below.

Table 1: Risk Factors

Risk factor

Risk rating = 1

Risk rating = 2

Risk rating = 5
Exposure
Local subnet
Campus network
Public access
Asset at risk
Public
Controlled
Confidential
Exploitation
Non-trivial
Not-public
Demonstrable
Execution
User interaction
Authenticated
Unauthenticated
Scope
1-5 systems
6-10 systems
> 10 systems

(21) The following Risk Rating calculation is used to determine the risk that a vulnerability poses to the University:

Risk rating = Exposure factor + Asset at risk factor + Exploitation factor + Execution factor + Scope factor

Table 2: Risk Rating – severity and notification and response requirements

Risk Rating

Severity

Description

Notification

Response
> 17
Critical
The exploitation of the vulnerability presents an imminent threat with the potential of:
Exposing confidential information to unauthorised parties
Disrupting the operation of critical systems
Damage to the University’s reputation
CIDO
Resolved in 48 hours
10 - 16
High
The exploitation of the vulnerability presents a likely threat with the potential of:
Exposing bulk controlled information to unauthorised parties
Disrupting the operation of important systems
IT Directors and Chief Information Security Officer
Resolved within one month
1 - 10
Medium - Low
The exploitation of the vulnerability presents a likely threat with the potential of:
Exposing a small amount of controlled information to unauthorised parties
Disrupting the operation of systems with limited users
System Owner and Chief Information Security Officer
Resolved during normal Patching cycle
Top of Page

Section 4 - Guidelines

(22) Nil.

Top of Page

Section 5 - Definitions

(23) The following definitions apply for the purpose of this Policy:

  1. End-of-Life (EoL) means the point when a manufacturer ceases to provide updates, Patches and technical support for a product.
  2. IT Resource means any device or software that has value to the University and consequently needs to be suitably protected, including hardware (e.g., laptops, desktops, servers, network equipment, phones, printers, storage devices), and applications (e.g., cloud/desktop/server based).
  3. Patch/Patches means a software update design to resolve Security Vulnerabilities in IT Resources.
  4. Patching means the process of applying patches (i.e., updates) to IT Resources to fix known Security Vulnerabilities.
  5. Security Vulnerability means a weakness in an IT Resource that can be exploited for malicious purposes.
  6. Staff means an individual employed by the University.
  7. Third-Party means an individual or organisation working under contract with the University.
  8. Vulnerability Scanner means an automated software tool that identifies and reports on known Security Vulnerabilities, to detect and report on potential exploits.