All right my question was not clear... so for people using Policy Auditor 5.x or 6.x, do you tailor your benchmarks manually for Microsoft patches in order to disable superseeded patches or do you use another means to do it ?
1 of 1 people found this helpful
The Policy Auditor Microsoft patch benchmarks do not need to be manually tailored as MS patches are superceded the Policy Auditor MS patch benchmarks are updated to audit the needed patches as appropriate. PA MS patch checks look at the actually files involved not just the MSI install database.
Maybe we have something not configured correctly or there is something I do not understand, as it is still a new product for us, but if I do a view on the 2010 Microsoft Patches Benchmark all the bulletins are enabled.
All the automated tasks are running correctly and we have not integrated MVM/Foundstone in epo. Audit engine content in repository is 1071.
The rules in the benchmark being enabled is only part of the process. The benchmark needs to be include in an Audit that is assign to devices. I am not sure what level of training or experince that you have with Policy Auditor, but you may want to review the documentation about how Policy Auditor works. It can be used without the MVM/Foundstone interface and most use it that way. You have to deplay the McAfee agent and the Policy Auditor agent to devices that you wish to audit and create an Audit definition associated with those devices before you can get any results returned to the ePO console.
Considering PA classes barely run once every 1-2 years, I do not have formal training.
I have created a few audits for our lab: one for the 2011 and 2010 os patches as well as one for baseline security safeguards based on a benchmark I created. So I am familiar with creating audits. When you create an audit you add activated benchmarks, assign and schedule. There is no customization step for the checks that are part of the benchmark when creating the audit.
So when does the magic happen ?
Thanks for posting the document but I can't access it.
The processing of audits is a multi-step process and fairly complex. Here are the details of how Policy Auditor results are handled from the creation of the audit to the ability to display the results on the ePO console. Before you start using Policy Auditor you have to use ePO to deploy the McAfee Agent (MA) and then deploy the Policy Auditor agent that will run under control of MA. The following assumes that you have MA and the PA plug-in installed on the systems that you want to audit.
Here are the Policy Auditor processing steps:
- Get a benchmark and rules: pull McAfee supplied content, import third-party content or use the PACC Tool to create a benchmark and import it.
- Use the Benchmark Editor and activate the benchmarks that you plan to use.
- Create and save an audit with the New Audit action using at least one benchmark for the systems that you select and save it.
- At this point ePO policies are created for all the devices involved in the audit and an association is created between the benchmark/audit/device and the initial status is “No Results”.
- At the next device ASCI expiration, every 60 minutes by default, the device fetches the ePO policy, one or more of which will be from the PA Audit and will include the benchmarks and content required to run the audit.
- At this time and on the expiration of the policy enforcement interval (by default every 5 minutes), the PA plug-in checks if any audit results are about to expire or expired and will run those audits if the Policy Auditor Agent General ePO policy that is assigned to that device defines the current time period as a whiteout period (the default is any time is a whiteout period and they are no blackout periods).
- At the end of the audit, which can take many minutes depending on the audit and the load on the device, but normally the audit runs in a 5 minutes or less, the audit results are queued to MA.
- At the end of next ASCI interval after the audit results were queue, MA sends the audit result event(s) to the ePO server.
- The ePO server parser reads the audit results events and inserts the data in the PA unprocessed results table.
- The “PA: Process Audit Results” ePO system task has one or more subtasks that look at the PA unprocessed results table every 5 minutes.
- If there are unprocessed results to process, the data is inserted it into the appropriate PA results tables and any findings are inserted into the PA unprocessed finding table. The subtask then checks the PA unprocessed results table again.
- If there are no unprocessed results, sleep for 5 minutes.
- The “PA: Process Findings” ePO system task has one or more subtasks that look at the PA unprocessed findings table every 5 minutes.
- If there are unprocessed findings to process, process the findings data and insert it into the appropriate PA findings table. The subtask then checks the unprocessed finding table again.
- If there are no unprocessed findings, sleep for 5 minutes.
Note that after step 5 the displayed results in the audits panel will change from “No Result” or whatever the previous status was to a pass, fail or some other status and after step 6 the finding will be visible in the results displays and queries also.
So, it could take 2 hours and 10 minutes to see all the audit results and findings to show up in the ePO PA tables and the PA console views in the worst case. There is also a case where it could take 3 hours and 10 minute. The 3 hours wait can occur if you deploy the PA agent right after an ASCI has expired. In this case, the expiration of the next ASCI will update the ePO device properties and one of the items updated will be the fact that the device has PA on it. The PA policies are only sent to devices that have the PA plug-in on them, the first ASCI will set this fact, and the second ASCI will send the audit related ePO policies and the third ASCI would return the audit results event.
If you want to speed this up you can do that by using an ePO waking up on the devices after step 1 (creating or modifying the audit). This will cause the device to contact the ePO server and get the audit content or changes in the ePO policies and the device will run the audit. Note, if this is a newly install PA plug-in you need to wake the device up twice. During step two, the audit scan is running and can take seconds to hours depending on the device and the benchmarks. Also each audit, regardless of how many benchmarks are used, creates one audit event. If 2 audits are assigned to the same device, then when the first audit is complete, an audit event is queued to MA and could be sent if an ASCI expired while the second audit scan continued on. The second audit results in this case would need the ASCI to expire or another wake-up call.
After step 2 is complete, audit scan completed and event data queued to MA, you could issue another MA wake-up to cause MA to send the queued audit events (and any other point product events) to the ePO server.
After step 3, audit event has been sent to ePO, you can force the 5 minute wait in the Process Audit Results task to expire by running the “PA: Process Audit Results” system task. Whenever this task is started it will cause the waiting subtasks to end and will start a new set of subtasks and those subtasks will immediately look for unprocessed results.
After step 4, process unprocessed audit results, you can force its 5 minute wait in the Process Findings task to expire by running the “PA: Process Findings” system task. Whenever this task is started it will cause all the waiting subtask to end and will start a new set of subtask and those subtask will immediately look for unprocessed findings.
Assuming you waited long enough for the audit scans to complete before issuing the agent wake-ups, this is the fastest way to get PA audit results and findings from devices into the ePO database. Any other behavior you see would be something to be concerned about.
All of these processing steps add to the scalability of the ePO/Policy Auditor system but can be confusing in the instant gratification world that we live in and that most demos are done in. There are good reasons for each one of these processes and associated delays but when looking at the entire end to end process it can be confusing and hard to explain what you are seeing.