Tag: patch management

23 May 2012

Patch deployment – now or later? (with interactive poll!)

We recently saw an examination finding that recommended that “Critical Patches be deployed within 24 hours of notice (of patch release)”.  This would seem to contradict the FFIEC guidance in the Information Security Handbook that states that the institution:

Apply the patch to an isolated test system and verify that the patch…

(1) is compatible with other software used on systems to which the patch will be applied,

(2) does not alter the system’s security posture in unexpected ways, such as altering log settings, and

(3) corrects the pertinent vulnerability.”

If this testing process is followed correctly, it is highly unlikely that it will be completed within 24 hours of patch release.  The rational behind immediate patch release is that the risk of “zero-day exploits” is greater than the risk of installing an untested patch that may cause problems with your existing applications.  So the poll question is:
[poll id=”2″]
Regardless of your approach, you’ll have to document the risk and how you plan to mitigate it.  A “test first” approach might choose to increase end-user training and emphasize other controls such as firewall firmware, IPS/IDS, and Anti-virus/Anti-malware.  If you take a “patch first” approach you may want to leave one un-patched machine in each critical department to allow at least minimal functionality in case something goes wrong.  You should also test the “roll-back” capabilities of the particular patch prior to full deployment.

I’ll be watching to see if this finding appears in other examinations, and also to see if the guidance is updated online.  Until then, because of the criticality of your applications and the required up-time of your processes, I believe a “test-first” approach that adheres to the guidance is the most prudent approach…for now.  However you manage it though, be prepared to explain the why and how to the Board and senior management.  Not only are the results expected to be included in your annual Board report, it may help to explain repeat future examination findings if your current approach differs from examiner expectations.

16 Feb 2012

FDIC changing annual IT report to Board?

Based on recent examination findings, it would appear that the FDIC is changing what they expect to see in the annual information security report to the Board of Directors.  The requirement for the report is established in the FFIEC Information Security Handbook where it states that a written report to the board should describe the overall status of the information security program, and that at a minimum, the report should address:

  • The results of the risk assessment process
  • Risk management and control decisions
  • Service provider arrangements
  • Results of security monitoring and testing
  • Security breaches or violations, and management’s responses
  • Recommendations for changes to the information security program

However in a recent examination the institution was written up because the FDIC did not believe the report contained enough detail.  They stated that “Board reporting should be expanded and include detail at a minimum for the following areas:

  • The information security risk assessment
  • Service provider agreements
  • Results of testing, audits, examinations or other reviews of the program
  • Any security breaches, violations, or other incidents since the previous report and management responses
  • A summary of information security training provided to employees since the last report
  • Status of the patch management program
  • Status of the Business Continuity Plan and testing results
  • Customer Awareness Program efforts and plans
  • Any recommendations for changes to the information security program”

I’ve highlighted the changes between the original guidance and the examination finding.  I’m not surprised at the training findings, as I have previously identified both employee and customer training as likely 2012 trends.  Nor am I particularly surprised by the inclusion of the status of the BCP and testing results.  This has been a requirement and an area of increased regulatory focus for a couple of years.  However it would appear that examiners may now prefer the BCP status update to be a part of the information security update report to the Board.

The inclusion of a patch management status report was a bit surprising though, as in the past this was not reported separately but simply included as one of your many risk management controls.  Perhaps they are looking for more control detail now?  (I plan to address patch management in a future post.)

I was also a bit baffled by the exclusion of “Risk management and control decisions” from the list of findings.  I had also identified the “Management” element as a probable area of increased regulatory scrutiny in 2012, so I’ll keep an eye on future examination findings to see if this actually represents a shift in focus or simply an oversight by the examiners this time.  (Of course a third possibility is that the examiner felt that the “risk management and control decisions” were present and properly documented, but given the other findings I doubt that was the case.)