I am a student working on my semester project and it's about developing a SIEM solution with Big Data tools to be used in a SOC (security operations centre) and I know that collecting logs can be used whether for Analysis, Auditing or Compliance. Looking up for the difference between compliance and audit, it still seems rather vague to me.
-
1[This](https://en.wikipedia.org/wiki/Security_information_and_event_management#Alerting_Examples) is [easily googleable](https://www.sans.org/reading-room/whitepapers/auditing/successful-siem-log-management-strategies-audit-compliance-33528). – Tom K. Mar 20 '18 at 12:43
-
Possible duplicate of [Log information for SIEM auditing in Linux](https://security.stackexchange.com/questions/71228/log-information-for-siem-auditing-in-linux) – Tom K. Mar 20 '18 at 12:45
3 Answers
The way this was explained to me at a very basic level is the following:
Auditing refers to seeing who did what, when where, this could include systems and people. You'll probably hear the terms "audit logs" which refers to a series of logs that indicate who worked on a system, when and what they did.
Compliance refers to ticking (or not) a series of boxes after doing your audit. Think of compliance as the following question "Do my actions tick all the boxes?" Eg. Is access to your customer data restricted to privileged users only? You then do an "audit" (investigate the access logs) and if no unauthorised users can query the data, your are then compliant, hence you you pass some Compliance.
How do you link them together in a SIEM? Depending on what data you capture and the Compliance Standards you can simply query your data and then start ticking boxes to check the compliance.
This is a very basic explanation from a technical level. Compliance and auditing are slightly different when we are talking about legal, financial auditing and compliance.
- 719
- 6
- 14
@Florin Coada has one good explanation. I like to think of it as this:
Compliance deals with the state of things. Auditing deals with actions taken on things.
Compliance looks ahead, auditing looks back.
Let's say that there is a security issue - a terminated employee's account is not deleted in time and is accessed. Data is leaked.
Compliance would look at this and say, "Do we have processes in place to prevent this? What are these processes? Do they fill this list of requirements? Are our requirements accurate?"
Auditing would look at this and say, "Was the process followed? What was the result of this? Who had responsibility for action X and was that done in a timely manner?"
Another way to think of this, not from the security incident perspective, is to say that Compliance sets the rules and Auditing checks adherence to the rules. Under this, Compliance would say, "Your documentation for this system needs to be stored in this system, in this way." Auditing would say "Is your documentation for this system stored in ways that Compliance has mandated?"
- 2,768
- 2
- 9
- 14
When speaking of Compliance and Auditing one always has to define the respective scope. A system, a process or a control can't just be compliant. It always is compliant with something.
To quote from Wikipedia:
Regulatory compliance describes the goal that organizations aspire to achieve in their efforts to ensure that they are aware of and take steps to comply with relevant laws, policies, and regulations.
One of the most impactful laws in the US that is a typical example for how companies establish internal policies for Compliance with certain sections of said law, is the Sarbanes–Oxley Act of 2002. If you search the interwebz or this site for "sox compliance" you will find a lot of good examples for how it influences companies and especially you will find a lot of recommendations for policies that will help achieving compliance with SOX.
How can a SIEM be helpful in this case? It provides logs following specified rules - and therefore in some form proves - if the written compliance policies are actually enforced and therefore if the processes in question in fact are compliant with the law or regulation.
This will typically checked with an Audit. An audit is a "test" if someone or something is compliant with something. For example, a company wants to get its ISMS ISO/IEC 27001 certified. The implementation and the compliance with ISO/IEC 27001 shows a company's commitment to information security to customers and governments and gets (preferably) regularly audited by another independent, external entity.
Back to your question: a SIEM can provide data for an audit like that. What is more important, a SIEM makes it more easy to determine if you are complying with the policies or laws that you are claiming to comply with. The auditor can check if there is just an internal policy that says "Do X because law Y says so." or if it is actually done.
Why is it easier to determine, if you have a SIEM? Because a lot of frameworks ask you to implement some form of automated data analysis and/or logging of e.g. security events. A SIEM does exactly that.
TL;DR:
A SIEM is a system that provides data and automatically analyses it with a given set of rules. An audit is needed to determine, if all prerequisites for the achievement of compliance are met. A SIEM can help with that determination, because it makes it easier to check, if internal policies are actually enforced.
- 7,913
- 3
- 30
- 53