Patch Management - Significant Deficiency? 2186



  • Hello,
    For the last two years, we have had a deficiency when it comes to applying security patches. A sound policy went in place at the beginning of this year, but it was not followed and it failed in almost every instance we tested. Would a prudent auditor consider this a significant deficiency?
    Thanks



  • [analogy]
    The auditor says there is no door to a house. So weather and insects enter without being stopped.
    The problem is noted so a solid oak door is put in, but there is a doorstop jammed in the door, so it is always open. Thus, the same weather and insects enter unrestricted. [/analogy]
    Controls that don’t function (or controls that are tested and fail) essentially are in the same category. They should be noted (written up).
    In the view of some auditors, if a problem been noted and it’s still a weakness, it would be a negative reflection on management.



  • We dont require prudent auditors to notice this as an SD. Ensuring system security is of paramount importance.
    Clearly an SD. Best way out will be to simply follow the documented process 🙂



  • Do the ‘what if’ test. If this control fails then what other controls will prevent a material misstatement occuring on the account?
    If the answer is ‘none’ then does that not make this a material weakness?
    If the answer does point to another control then the question is when will this other control be triggered? Will it detect any error, only significant one or only material ones? This will make it either a non-SOX deficiency, a deficiency or a significant deficiency.
    Any control failure cannot be viewed in isolation and must be viewed in the context of the whole and quantified to evaulate the extent of the deficiency. In this case I would suggest that should be done ASAP.



  • ^ adding to the several good thoughts expressed above. You may or may not be performing some of the items outlined here. 🙂

    1. Security patching is one of the most critical aspects for IT security and most likely is on the Audit checklist for SOX 404 compliancy. Patching extends to EVERY product, (e.g., beyond Windows and Office updates). An inventory of all software should be established and monitoring against vulnerability tracking sites (e.g., Secunia, FRsirt, etc.). Below is an example of an unpatched Adobe vulnerability circulating:
      copy to browser and add www
      adobe.com/support/security/advisories/apsa07-04.html
    2. Microsoft updating can be automated using WSUS 3.0 (latest versions) so that this portion can work reliably and automatically for all servers and workstations. WSUS allows you to pilot test first for issues and then deploy. That fruits of that project alone would make a difference in better protecting your organization.
    3. Often, many of today’s security patches are ‘zero day exploits’ and documented vulnerabilities already circulating in-the-wild. This is especially true of the IE and Office based security updates we see each ‘Patch Tuesday’. Also, some security patches are reverse engineered by ‘the bad guys’ and put to work soon after updates are issued. Even if SOX didn’t require this, patch management needs to take a very high priority in IT Security, to protect the confidentiality and reliability of information. For example, three of the Microsoft October updates have working exploits:
      Paste to browser - no www required
      isc.sans.org/diary.html?storyid=3480
    4. Recommendations:
    • Examine and evaluate why the patch management standards aren’t working
    • Look for ways automation can help you (WSUS, SMS, etc)
    • Develop a formal plan to correct deficiencies and monitor it closely
    • Ensure management backs the needed work and devotes resources to this needed project (e.g., SOX is more about management’s responsibility in identifying and addressing key risk concerns)
    • If proper priorities are given to patch management to remedy the current issues, most likely the external auditors could note this but provide favorable comments on proactively addressing concerns.


  • Agree with Wrightlot here. Deficiency must be evaluated further for impact before being designated as SD. A Prudent auditor needs to look at other controls before making a judgment here.
    For example if you have good application level controls and ITGC around access and change management then you have more ground to consider it as D then an SD. Just an example.
    I have one more concern here. What about a deficiency which has been identified (and communicated) twice and has not been remediated, does that suggest something about the control environment as such? Wont this have a bearing on the overall evaluation?


Log in to reply