Log Management and SOX 929
I am trying to define the scope of Log Management in SOX.
My understanding and doubts in the subject are:
- need to have logging enabled spl Audit logging in all systems related financial applications ( i doubt if its only financial systems).
- Need to have back-up of logs and archiving at safe place for the duration ( is it 7 years for SOX act???).
- Integrity of logs- you should be able to recover logs of any timefrom archives of the decided duration. ( do we need to do some kind of backup and recovery test for this on periodic basis).
- Does SOX mandates real time monitoring of logs also.
Since I have an IT background i am looking for answers from auditors perspective or from someone whos has gone through SOX audit in IT. Our auditors are one of the big four.
Thanks in Advance,
Denis last edited by
calvin - first of all there is no SPECIFIC requirement in SOX regarding any IT control - rather there is a more general requirement (in COSO) that financial systems be controlled which is what has led many projects to rely on COBIT.
That said what you describe is mostly best practice. Monitoring of logs is essential - but frequency needs to be appropriate in accordance with the business needs. Some logs may require real time monitoring, for others monthly review may be enough.
ugogirl last edited by
I’ve seen logs defined and used as part of key IT general controls.
for example, lets say a review of the automated anti-virus software log is performed daily. This can be done online. how do you prove that the review took place and corrective action (if required) was taken? the client implemented a paper log to offer as proof. this requires the staff to maintain a paper log and obtain management approval at specific frequencies as defined by the control. a paper log has been used to record entries (daily, weekly, monthly, quarter–what ever the frequency of the control) that a review has occured and any exceptions found…plus the follow up help desk ticket (where more details of exceptions can be found)
during an audit, the paper log can be compared to the history of the automated log (if kept) and help desk tickets.
You get to define the key IT general controls and frequency that makes the most sense.
thanks Dennis and ugogirl,
What i have a problem is with monitoring of logs. The logs around are simply overwhelming. From Firewall, SAP, DB, Email, Antivirus the list is just too much. Now since the question that how much has been settled by Ugogirl ( by defining the frequency) the question of how many still remains.
What is considered a minimum set of logs to be monitored from the perspective of IT controls compliance ( from the auditors perspective). Does it need to be all out on all systems…or i can restrict myself to some systems…like SAP, DB, email and antivirus…does n/w devices logs are to be included like firewall and routers…does ADS, DNS and other Windows logs need to be monitored too.
Can someone guide me from the auditors perspective.
ugogirl last edited by
There is not a minimum set of logs the external auditor will require. Each company has to decide what their controls are and the frequency that works for them. This is where you have to make the determination. It is also easy to get carried away with too many logs. Automation of logs will help a lot.
We established written policies and procedures for IT which included their controls. If the control was a log or a review of a log then that was spelled out. It is also spelled out if there was a management review of the log on some periodic basis. For example, lets say the antivirus log is reviewed daily for exceptions or potential threats. Then management may review this on a weekly basis.
I think people can share examples which may give you some idea of the approach they have taken. Nobody can give you the exact answer you are looking for unfortunately. A lot depends on the environment, processes, and controls in place.
In the spirit of sharing, below are some examples (this is only a subset) of paper logs that we are maintaining. These may be overkill for some environments but they are what we are using. Generally, the naming standard for the log includes the frequency.
Annual 3rd Party Internal and External Vulnerability Assessment Scan Log
Annual Enterprise Network Architecture and Design Review Log
Annual Firewall System Restore Log
Annual Email System Restore Log
Annual Windows Print and File Server System Restore Log
Daily Anti-Virus Exceptions Log
Daily Email Back-up Log
Daily Windows Print and File Server Back-up Log
Inventory of Hardware, OS, Patches
Quarterly Contractor Terminated User’s Audit Log-Network
Quarterly Domain Admin Password Change Log
Quarterly Employee Terminated User’s Audit Log-Network
Quarterly Firewall Back-up Log
Quarterly Firewall ID Review Log
Quarterly Firewall Password Change Log
Quarterly Firewall Patch OS Assessment Log
Quarterly Internal and External Vulnerability Assessment Scan Log
Quarterly Review of Inventory of Hardware, OS, Patches Log
Quarterly Switch and Router Backup Log
Quarterly Switch and Router Password Change Log
Quarterly Switch and Router ID Review Log
Quarterly Switch and Router Patch OS Assessment Log
Weekly Microsoft Security Monitoring and Intrusion Detection Log
Weekly Network Infrastructure Security Monitoring and Intrusion Detection Log
It was a good answer and the list was a good example.
This spirit of sharing is something which has made this forum vibrant and dynamic.
AJ last edited by
I am trying to construct an approach to tie-up log-management and compliance (Note: i’m not mentioning SOX in specific but generalizing to compliance which includes SOX, HIPAA, GLBA for the sake of elucidating some contra arguments which in turn will be educational for me as well as the others)
Let me reiterate, this argument is basically what Calvin has posted above, but here i have tried to build a bigger picture of the demand for software products that aid in achieving compliance ‘nirvana’.
If you take any organizations there is a plethora of heterogeneous systems and applications that are constantly generating logs. So now there could be many reasons (as quoted >> below) for the user/admin/mgmt to go for products like Log Analyzers (could be EventLog Analyzers or Firewall Log Analyzers…if u need to know more about them…ask google :idea: )
1 >> out of curiosity
2 >> out of concern for security
3 >> out of necessasity for compliance (duhhhh :twisted: )
4 >> out of fear from going to prison
5 >> and more…
Each of the above reasons needs to be met. Its easy to evaluate for reasons 1 and 2 but Reason 3 is like ‘writing on water’ as to what needs to be expected from an IT product standpoint.
UgoGirl has partly helped me understand that strong reporting is an essential requirements in such products. But i find a scope creep in the list provided by UgoGirl, in the sense that LogManagement must now also include Vulnerability Assessment , User Management (what is now a hot market called Identity Access Management) and security tools at large.
So I need the help from the ‘compliance’ experts in this forum about the validty of my above argument. Expecting a lively discussion and information sharing from everyone.
Denis last edited by
AJ maybe you need to take a step back.
Log management isn’t truly a requirement in it’s own right so it would be easy to overdo it. The reason that logs are popular is that they can provide good documentary evidence of/for control activities. The regular review of logs is a control that can address certain key risks, but is not the only possible control, indeed in many cases it will be the ‘detect’ partner of other ‘prevent’ controls.
I guess what I’m trying to say is that it is a means to an end, but not the end itself. When you start looking at controls over controls you may be going too far.
AJ last edited by
I do understand that Log Management is just one among a whole lot of other control techniques, and it would be wise to say that it is more a part of an enterprise forensic tool. But i also see the value that logs provide in building tools which would aid the mgmt to generate reports which can be provided to external auditors.
I guess i have been able to build the story around the subject of this post :?: .
So now to take my argument further, Say, I am a public listed company which understands the benefits that compliance provides to me as well as my stakeholders, and i use log monitoring or management software as part of the internal control techniques (like documentation, approvals, auditing, separation of duties, testing…). What would be the type of reports that I would need to realise from this product so that i can make the job of my external audito easy.
I will go further and help you come up with suggestions by stating some reports which i personally feel is essential in a log management products (which i will call Log Analyzers),the required SOX report list is as below :
User Logon/Logoff Report : Sec 302 (a)(4) and (D) - log-in/log-out monitoring
Logon failure report
Audit Log Access report
Object Access report
System Event report
Account Mgmt report : sec 302 (a)(6)
Audit policy changes : sec 302 (a)(5)
User/Application/Directory or file access : sec 302 (a)(5)
So to cut a long post short :lol: , what i would want the compliance ‘guru(s)’ in this forum to do is to help novice users like me and the rest with their suggestions as to what kind of compliance reports should an IDEAL log management product generate so that it makes life easy for the public organizations when they are approached by an external auditor or the SEC…