Vulnerability Assessment Audit Checklist for ISO27001/17799

  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • warning: Illegal string offset 'data' in /home/priandoyo/smashingpasswords.com/includes/tablesort.inc on line 110.
  • warning: Illegal string offset 'data' in /home/priandoyo/smashingpasswords.com/includes/tablesort.inc on line 110.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.
  • : Function ereg() is deprecated in /home/priandoyo/smashingpasswords.com/includes/file.inc on line 649.

Vulnerability Assessment Audit Checklist
A four-stage vulnerability management system should be developed. It should ensure that vulnerabilities are identified, that a decision is made as to how to react to those vulnerabilities, that there is careful testing prior to patching and that actions are tracked so that success (or otherwise) can be monitored. This system should:

Prioritize high-risk systems.
Prioritize high-risk vulnerability. The SANS Top 20 are, by consensus, the most common and most often exploited vulnerabilities. They should be dealt with first.
Define roles and responsibilities with respect to vulnerability management, including monitoring and identifying (for all of the software and hardware) the vulnerabilities and release of patches, risk assessment, identifying the urgency with which the patch needs to be deployed, carrying out the actual update (refer to control A.12.5.1) and dealing with any coordination. There should be absolute clarity about accountability, and individual responsibilities should be clearly written into job descriptions.
Identify, for each of the software and other technology items, the relevant source of information about vulnerability identification (possibly through Bugtraq or CVE) and patch release (usually the vendor website, or through use of an appropriately configured automatic update facility), and this information should be regularly reviewed and, where necessary, updated.
Ensure that there are set steps, within a predetermined time line (such time line to be developed in the light of a process-level risk assessment), for identifying the risks of proceeding and of not proceeding with any given patch, for deciding what steps should be taken and for implementing that decision – which should usually be to install the patch unless there are good reasons not to.
Allow, under certain emergency circumstances, the patch to be installed following the incident response process (see Chapter 25) rather than the change management one; any such decision should be properly tracked and all the records updated appropriately.
Ensure that, where necessary (the risk assessment process drives this), and prior to implementation, patches are tested and evaluated to ensure that there are no side effects on other systems.
Allow, in circumstances where a patch for an identified vulnerability is not yet available or the side effects of implementing it are not acceptable, the organization to adopt alternative controls, such as turning off services that are affected by it, modifying firewalls or other access controls, increasing user awareness to detect and respond to attacks or increased monitoring of activity to identify an attack on the vulnerability.
Ensure that there is always an audit log of activity in relation to vulnerability management.
Provide for regular monitoring and review of the vulnerability management process, not just through the internal audit function to ensure that it is working according to specification but also by the information security adviser to ensure that the specification remains adequate in the light of the organization’s evolving risk assessment and risk treatment plan, in the changing security environment.

Free Download AttachmentSize
VulnerabilityAssessmentAuditChecklist.xls17 KB

Trackback URL for this post:

http://www.smashingpasswords.com/trackback/97

User login

Who's online

There are currently 2 users and 337 guests online.

Online users

  • fgrzzzxaw
  • dzequkou

Who's new

  • bettye6983uepjr
  • cruz7190jpzqfyyrj
  • fredrickreiderpuws
  • brandintnmlqxnoes
  • ncecarynlyghkdjeoaxy