(imported topic written by amerriam91)
Does anyone out there have a doc that speaks to how Bigfix Patching covers the PCI patch guidelines?
At least in a vague manner. I need to create some docs and it would be much easier if someone has already done some legwork.
(imported comment written by tratz91)
Section 6 of the PCI DSS, “Develop and maintain secure systems and applications”, calls out several patching requirements. The BigFix solution can help address all of these patching-related requirements if properly configured and used.
Section 6.1 requires that all system components and software have the latest vendor-supplied security pateches installed - with relevant patches installed within one month of release. Providing that the BigFix Enterprise Security (for Windows) and other related platform patching sites are subscribed to on your BigFix platform, you are well-covered from an operating system perspective and for anything Microsoft covers via its Microsoft Update service. However, caution should still be taken regarding other applications that may not be included in BigFix-provided site fixlets. For example, Adobe Acrobat Reader is covered via BigFix. Less common software, however, such as “Widget X from Mom & Pop Publishing” are likely not covered. You would need to develop a custom site for your enviornment to keep track of less-common or internally developed software versions that are deployed. Once you have this information being collected and available, you can then maintain fixlets to report back when a system is not at the expected rev. level and to enable appropriate remediation actions.
Section 6.2 requires the establishment of a process to identify newly discovered security vulnerabilities and to update internal standards accordinly in reaction to those discoveries. There is a vulnerabilities site in BigFix that helps address this requirement. As with 6.1, however, it will only be relevant to defined areas of your system where BigFix currently checks for vulnerabilities. If you have deployed less-common or internally-developed systems/applications that BigFix does not detect vulnerabilities for, you may want to create custom BigFix content to help evaluate conditions that would indicate a vulnerability exists. This should show your PCI assessor an appropriate level of due dilligence, but it can be a very high-maintenance process to maintain and is not necessarily an effective security control. Another approach is to implement a holistic vulnerability management process in your envrionment that makes use of a PCI-council-approved vulnerablity scanner. Solutions such as Qualys, and others that have exposed APIs, will enable you to integrate BigFix in to the vulnerability management process by allowing BigFix to augment its built-in vulnerability management featues by taking a central command and control post for managing vulnerability scans and data via a focused vulnerability scanner.
Section 6.3.1 requires that patches are tested prior to production deployment. The use of BigFix’s robust site management and delegated adminstrative control features makes achieving this requirement a snap. Simply create policy fixlets that automatically subscribes system assets to appropriate custom sites based on defined crtieria for your envrionment. An example of such sites may be “production”, “pilot”, “test”, “development”, etc. Once your site structure is defined, delegate the ability for appropriate people, based on good segregation of duties principles, to deploy patches to each site. By only allowing a fixlet for patch X to be initially applicable to the development or test site(s) and enabling only those adminsitrators to create a custom copy of that fixlet in the pilot site upon successful testing, you can manage a bottom-up deployment process that conforms to best-practices and PCI-compliant patch deployment processes. Rinse and repeat for moving things from pilot to production.
Section 6.4 requires that change control procedures are followed for all system and software configuration changes - this would include patching. BigFix, while not a change control tracking platform, does provide solid auditing and tracking of actions taken. By incorporating procedural steps for your admins to follow, such as a defined naming convention for fixlets, tasks, and actions (or just using the comments sections), you can tie back an action to an approved change. If you wanted to manage change via BigFix in a more controlled-workflow manner, you could also take the approach outlined above for patch testing. Place all change fixlets in a common Change Control site. This would require a change control site admin to move fixlet content from the holding pen to other sites for approved actions to be taken. This may not be a good approach in every envrionment, but it does allow for tighter integration of BigFix in to the overall change control process.
I hope this is helpful. The above are written based on observations stemming from first-hand BigFix management and PCI compliance management. I apolgize ahead of time for any spelling mistakes; this was typed quickly and directly in to the post window.