Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm assigned to write procedural documentation for the SIEM use cases for the IT asset owners. For example, the procedures for selecting events indicating unauthorized access to user-mail box. I have researched the problem and found corresponding Events Id associated with this event.

This is the easy part, but my friends in my team argue that I would be also responsible against ensuring audit trail requirements e.g change in security audit policy (removing from auditing) by disgruntled admins to cover tracks for illegal / unauthorized actions.

I believe that system owners are responsible for audit control implementation and review of the resulting audit logs. Auditors are responsible for identifying gaps in implementation.

The most I can do is to specify the requirements (e.g log all events with an event id between 1001-5 for source ms-exchange store, category(logon,access request,object moved etc) and the required logging level.

I want to know who is responsible that audit configuration is as per requirement stated by us (the operations team)?

UPDATE

If i rephrase my question I would ask something like this..."who is best suited to maintain audit trails of user action?" Auditors or owners

share|improve this question
    
I'm quite confused - could you clarify what the question is? Where the line is drawn for what? Are you auditing against a specific regulatory regime? And I don't understand what your friends are asserting. –  Mark C. Wallace Jan 9 '13 at 14:13
    
@Mmark I'm sorry for the confusion, english is not my first language let me re-explain. My friends says to ensure change in audit requirements and verifying at the system level is your responsibility as SOC analyst. My point is that any diversions from the said audit requirement is task of audit , system or GRC teams not the operations. There is no specific regulatory requirements it just some auditing that needs to be turned on to operate SOC. –  Saladin Jan 9 '13 at 14:26
2  
I'm not sure this question will necessarily be answerable for you here. We could tell you what the best practice would be from a security standpoint, but each organization handles roles and responsibilities differently according to its needs and culture. –  Iszi Jan 9 '13 at 16:36
    
@lszi I agree but do you know of an organizations that slips off the responsibility of enuring compliance of audit requirements to a team (e.g SOC team) responsible for monitoring like 3000+ eps and daily storage of 60 GB events. Is it not recipe for management carrying lawsuits claims.... –  Saladin Jan 9 '13 at 17:04
    
I wish I still retained enough of any of my foreign languages to write this well; the subject is complicated. –  Mark C. Wallace Jan 9 '13 at 17:10

1 Answer 1

up vote 3 down vote accepted

In the past I performed the function of an auditor. (for legal reasons, I cannot call myself an auditor, but the fundamental function of an auditor is to compare expected behavior with actual behavior, and that's what I did). @Iszi is correct that different institutions will have different understandings of RACI. If I were an auditor visiting your facility the first finding would be that your management hasn't described that responsibility matrix. In traditional auditing, one does not hold people responsible where there is no policy. (Modern risk based auditing can operate a bit differently, but I think that's outside the scope of this question).

Based on the evidence presented, I believe you are correct. The procedural document should describe the procedure for system auditing, including the events to be audited, and the procedure for reviewing the audit logs. If the goal is merely to comply with an audit regime, that is sufficient.

If the goal is to improve security, reduce the organization's exposure to risk, decrease the number of incidents and decrease the damage done in any individual incident, then your organization needs to go further. Your system audit procedures are based on assumptions about the assets your protecting, and the threats to that asset. Threats and assets change more frequently than eventid's. Your management should have a mechanism to update the audit procedures. Audit review is not an end; it is a tool to reduce risk, reduce incident frequency and severity. Management should establish a periodic review of audit activities and to adjust those audit activities to better support the organization's business goals.

(I recognize that I've used the term "audit" in two contexts, and that it could be confusing. I'm assuming that you are writing procedures for capturing and analyzing system event logs (system audit). This is separate from external audit and review, which might be called independent audit)

As @Iszi says, each organziation will differ, but I believe that in the general case: System Aministrators/SOC staff are responsible for daily/continuous review of audit logs as described in the procedural document you're writing.

System Owners/System Management is Accountable for the results of audit (generally measured as the time to detect an incident, the % of incidents detected on internal vs external evidence, and the average time to resolve an incident). Management is also responsible and accountable for managing the audit process, which includes ensuring that the audit procedures are updated to match business needs.

This gets a little more complicated if we outsource security monitoring to a SOC; the system manager/owner should still be accountable, but they have delegated responsibility. If I were reviewing such an arrangement, I'd look for an SLA for Security that included the RACI you're looking for.

share|improve this answer
    
I appreciate your indepth answer to my question. Very informative indeed. Let me explain further. In my arrangement (love the use of word) we already have the GRC team and have IS policies in places including one dealing with the workstation and configuration changes. You are very correct about how audit role should be seen, it is a mean to the end. I forgot to mention that these audit procedures are derived from SIEM use-cases (business problem the company wants to solve). These use-cases will eventually change with changing threat landscape / profile. The SOC is internal. –  Saladin Jan 9 '13 at 17:28
    
I'm still not sure how could business owners can delegate such responsibility ; they are risk owners any threat aspiring due to change in audit procedures / configuration they would be held responsible. We as SOC team at its best can monitor these changes but hardly ever regulate , enforce or comply them. –  Saladin Jan 9 '13 at 17:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.