Policy Auditor Processing Steps and Audit “States”

Version 1

    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:

     

    1. 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.
    2. Use the Benchmark Editor and activate the benchmarks that you plan to use.
    3. 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”.
    4. 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.
    5. 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.
    6. 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.
    7. 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.

     

    Here is a further complication, what happens when Policy Auditor SCAP content is updated? When will new or updated content that is checked into the ePO / PA server be used at the devices that have the older version of the content?

     

    Any content associated with a NEWLY CREATED PA audits will be sent to the assigned devices at the next MA ASCI. This will include any OVAL checks that have been updated but only those checks that are referenced by the newly created or newly added assignment for the devices.

     

    The updated content for existing audits is sent to devices two ways. If a benchmark has been updated AND that updated benchmark is activated so it will be used, then all content associated with that benchmark is sent to all devices that have that benchmark assigned to them on the next MA ASCI after the benchmark is activated.

     

    If the benchmarks being used are NOT changed (and therefore there is no need or way to activate the benchmark since it is already activated), then the updated content (the OVAL checks) will be sent to the device on the next MA ASCI AFTER the “PA: Benchmarks and Checks Synchronization” system task has run. The default for this task is to run every 7 days. So it may take 7 days before the devices fetch the updated content.

     

    An example may describe this better. Create an audit that includes the “MS Windows Bulletin 2011” and “MS Windows Bulletin 2010” with frequency of 7 days and no blackout periods on one device. The audit for this will run soon after it is saved, let’s says it runs on December 1st.

     

    On 12/2 the “PA: Benchmarks and Checks Synchronization” system task has runs and since no updated content has been receive since the PA audit policies were created, nothing is changed.

     

    On 12/3 updated content is received and this includes an updated “MS Windows Bulletin 2011” with an updated MS11-001 patch check and a new patch check for MS11-002. Furthermore it also includes an update to a patch check MS10-005 that is referenced by the existing “MS Windows Bulletin 2010” benchmark but that benchmark has not changed.

     

    On or about 12/8 the PA agent will run the audit the second time, but since the “MS Windows Bulletin 2011” was not activated and the “PA: Benchmarks and Checks Synchronization” system task has not run the audit that is run will use exactly the same OVAL checks that were fetched by the agent on 12/1.

     

    On 12/9 the “PA: Benchmarks and Checks Synchronization” system task will run and it will update the PA audit related policy to include the updated MS11-001 and MS10-005 patch checks for the audit definitions in use. The next MA ASCI after this task runs will fetch the updated content for this two patch checks.

     

    Then, on or about 12/15 the PA agent will run the audit the third time and will use the two updated checks.

     

    At any point if the updated “MS Windows Bulletin 2011” is activated, that process will cause the update MS11-001 patch check and the new MS11-002 patch check to be included in the ePO / PA audit related policies. But the activation of the updated “MS Windows Bulletin 2011” will have no effect on the updated MS10-005 patch check. Running the “PA: Benchmarks and Checks Synchronization” system task would affect the updated MS10-005 patch check as well as the updated MS11-001 patch check.

     

    This is a bit complicated but is consistent with the store and forward architecture of ePO that allows for the scalability needed to handle 10’s of thousands of devices from one ePO server.

     

    We also get questions about how to determine what state an audit is in, similar to:  “Can you track the status of an audit (started, in-progress, complete) on the client workstation?”. The short answer is no, not really. The only status or state that really matters for the audit of a system is are the benchmark results current or expired on the ePO server.

     

    How the benchmark results transitions from “no result” or expired result to current result is a very complicated process. You can read the detailed steps involved in a Policy Auditor audit defined earlier in this document and better understand why. A bit longer answer is that there are a lot of states that a given audit can be in for a given system (some of them at the same time because there is an ePO state and a state on the audited system). Here are the states that I can think of during normal day to day processing, if various system task or ePO services have been stopped or crashed, other states can exist:

     

    • audit defined, but not fetched by the system,
    • audit available on the system, but results are current and have not expired – the audit will not run on the system until it is about to expire,
    • audit available on the system and expired but a blackout period is active – the audit will not start during a blackout period,
    • audit available on the system and actively running,
    • audit has recently run and results are queued to MA but not yet returned to ePO,
    • audit results have been returned to ePO but waiting to be processed in the PA unprocessed table,
    • audit results are current on the ePO and current on the system,
    • audit result are expired on ePO but current on the system.

     

    It seems like it should be simple but it is not because state or status is related to your viewpoint. Are you looking at the results for a system as then exist in the ePO database for an Audit that already has results and the audit definition has not change, or for a newly defined audit or for an changed audit definition. The processing is this complex so that auditing processing can be highly scalable and self-managed.

     

    Another common question is:  “Is there any way to kick off an audit on a client workstation (other than “Run Audits” from ePO console) ?”.

     

    Yes, there are a couple of ways to cause audits to run sooner than the normal processing. Through the ePO console here are the steps:

     

    1. Check the desired audit and use the “Run Audits” action – this creates a policy that the agent will fetch on the next ASCI that tells the agent to expire the results that is has.
    2. Go to the system tree and do a “Wake Up Agents” action on the systems that you want the audit to run on ASAP – this forces the MA ASCI period to expire and the agent will fetch the “Run Audits” policy as well as other policies. The audit will begin to run assuming the system is in a Policy Auditor whiteout period.
    3. Give the agent some time to complete the audit, a few seconds to a few minutes depending on how large the audit is and the speed of the system, then do another “Wake Up Agents” action on the device – this forces the MA ASCI period to expire and so that MA will forward the audit results to ePO.
    4. At the point the ePO event parser will insert the raw audit results in the Policy Auditor unprocessed results table. You can see this on a refresh of the “PA: Unprocessed Audit Results by Audit” dashboard assuming they have not already been process. The “PA: Process audit results” system task look for raw audit results in the unprocessed results table every 5 minutes. If you want to cause that period to expire run the “PA: Process audit results” system task and the unprocessed result will be process immediately.

     

    At this point you will be able to see the results for the system that just completed its audit.

     

    If you have console access to the system, you could also use the PA Agent debug console and the run the audit manually and then use the McAfee Agent Monitor to force the system to send the audit results then go to step 4 above. The PA Agent debug console can be run from the install directory of the PA agent using enginemain –u (windows) or enginemain –n for UNIX. Use this interface to list the audit, select it and run it.