[Autogenerated] requirement 10.6 now wants you to do something with
all the data that's being written to the logs.
There's something it wants you to do is obviously to review them on again.
DSS is showing its age here because the note to the
requirements suggests that log harvesting passing on alerting
tools may be used to meet this requirement.
You know, in the current decade,
where log files could be gigabytes sized very quickly.
But the concept of not using automated TLS is pretty inconceivable.
There isn't an explicit testing procedure for 10.6 the tests error.
Giving for each of the sub requirements on the first of
requirement is that the important logs and events should be
reviewed at least once a day.
The next requirement going to look at is that less important.
Logs and events review less frequently than one us today.
Now splitting log reviews in to what's important and what's less
important was quite a recent change in the standard.
It came in response to how people typically round there
seems on their security operations teams.
It's important to understand the intent of this requirement here,
which is the operations team should be able to prioritize important events
that may indicate an attack against card all the data,
so a minimum on a daily basis, these four things need to be reviewed.
Firstly, any security events.
Secondly, logs from systems that store process or transmit cardholder data.
Thirdly, blog from critical systems such as directory servers and finally,
logs from any component that exist to provide a security function like a
firewall on to test this requirement is being fulfilled.
The QoS A will check that the log reviews are required by a policy
and will interview people responsible for log reviews and event
response and also watch them working.
So,
having split the requirement to categorize logs and
events as important and less important, of course,
those less important things also need to be reviewed,
and how frequently need to be reviewed is up to the organization.
The standard uses the term periodically,
which I know really upset some people because they want the
standard to tell them exactly how frequently these less
important log should be reviewed.
Although I find that these error also the people who say
they want the standard be more is spaced,
so look periodically equates to risk based how frequently logs
for less important systems need to be viewed is based on the
organization's risk assessment.
And so the first thing that the US will check is that risk assessment to
understand how frequently organization has decided periodic is.
They will then want to look at the policies and procedures to
see that those policies and procedures support the log reviews
based on the risk assessment on.
Finally, they'll talk with people who actually do the reviews unsurprising.
The last sub, Rick want to of 10.6,
is to actually follow up on things that the log reviews suggest.
A not normal or expected.
Okay,
so the exact was the standard uses are follow upon anomalies and exceptions.
But I guess most of us now think of a set of correlated log
entries that generate an event for investigations,
the sort of thing that we should look at in terms
of how a modern soccer operate.
This requirement is very basic,
but the core principle that standard is looking for is that if someone or
some system detects science of suspicious behavior,
that this suspicious behaviors investigated,
the testing procedures also pretty basic.
It's not looking for evidence of event to reality.
The log of actions taken,
which you might expect normally in a modern day security
operation center the accessible walk to first e.
Check that there's a policy and procedures to follow up on
anomalies and exceptions found in the logs.
Then they'll interview people on observe them to see how events are followed up.