If you are following Microsoft's guidance on installing SharePoint 2007 with least privilege mode (http://technet.microsoft.com/en-us/library/cc298465(office.12).aspx), your SharePoint farm account should not be added to the local Administrators group. If you add this security practice with following DISA's STIG for the Microsoft Windows operating system, you are likely to see numerous Event ID 560 events filling your Security logs using the SharePoint farm account. Note: You will see this error only if you enable logging of Object Access failures via a GPO or local security policies. In my customer's case , the event dealt with remote access and it trying to query the status of the service. SInce the error was occuring every minute and was associated with the Farm account, it was obviously the Timer service (SPTimerV3) that was causing this. At the end of the error log, there was an access desired Hex code of 0x4.
To resolve the error, we used SC.exe to modify the DACL of remoteaccess.
UPDATE: I have been asked to explain some of my experience with the STIGs and have added that below.
When dealing with DISA STIGs, the category of the particular item is referred to often. The highest category is Cat I, followed by Cat II and finishing at Cat III. For the SharePoint installations that I have worked with, all Category I and most of the Category II items have been applied for both the Operating System and Internet Information Services (IIS). There are SQL Server STIGs as well but I have not seen them affect SharePoint operation. When approaching a SharePoint installation, your life and time will be best spent installing and configuring a working SharePoint environment PRIOR to applying any STIG remediations. I have had instances where SharePoint will not even install when certain STIGs are applied. The SharePoint Products and Technology Wizard performs some actions ( mainly permissions ) that a STIG can revert and it is easier to apply the STIG remediations and check if SharePoint still works rather than figuring out if it is a bad install or a STIG that is causing any errors. As I go through the STIG items, I apply them one at a time and based on their recommended fix I will check the relevant SharePoint items. The biggest thing to watch for is any file or registry permission restrictions. Using PROCMON you can navigate through SharePoint ( mainly CA and the SSP ) and see what files and registry items it is hitting. In almost all cases, the STIG has affected the Central Administration, SSP and the services like SPTimerV3 and Osearch rather than the actually SharePoint sites themselves. The only issue I have seen with browsing the site has been caused when anonymous access has been turned on and the IUSR account ( which is a member of the Guest group ) does not have Logon locally permissions ( the DISA STIG has you remove the Guest group from this permission ).
During your testing, run through all the operations that SharePoint performs with the STIGs applied. Kick off a search crawl, run a profile import, even patch the server if you can with a SharePoint Cumulative Update. Remember that the majority of the problems will come from the infrastructure side of the house and not users hitting the site.