All right now we've talked about the basic security requirements, and now we're going to talk about the derive security requirements for auditing and accountability. So first of all, we're gonna review and update audited events. One of the things that you'll notice its administrators have A.
They tend to go back in review audit logs when an event has happened, as opposed to proactively. So what we want is a regular schedule that we can use to go in. Review these audited events to make sure we're still auditing the things that need to be or we can update those requirements. But we need to review this on a regular basis.
We also want to make sure that we're notified
in the event of an audit process failure, meaning, if we're tryingto audit a specific activity and for some reason, the audit logs full and that can't be documented or there's some sort of failure in the audit process. We need to be notified
3.35 Correlate audit review analysis and reporting process is for investigation and response to indications of inappropriate, suspicious or unusual activity, meaning we need a process in place. We need to make sure that audit logs air reviewed
and then they're analyzed. And then what? The information.
Ah, that we learned from there then becomes reported or processed as a report. And many times people set up audit logs based on the default settings.
And in some instances, those default settings could even generate so much audit activity that I can't really sit through that information and find out what's meaningful. As a matter of fact, there have been there was a retail store I won't name names. Ah, that had a huge compromise of over 80
credit card numbers lost. That's a tremendous amount of numbers, but they had auditing in place. They had a data loss prevention system. But what happened is it wasn't configured, at least in my opinion, very well, because thousands and thousands of audit entries
and it was like looking for a needle in a haystack. When you have those really significant events,
um, so along with that, provide audit reduction and report generation so that we can have on demand analysis. Once again, these audit logs, especially in a large enterprise, can generate a lot of activity.
Not all of it's meaningful. So how do we sift through that? Look for security related events,
and also how do we handle? There's escalated security events. So we have two core like that provided information system capability that compares and synchronizes internal system clocks with an authoritative source of time server to generate time stamps for audit records.
You know, um, many operating systems now, rather than allowing users to configure date in time, they pull that information down from an Internet time server
that provides us consistent, safer audit loads, but also for our investigations. If we have evidence we want admissible in court, we need a, um,
a legitimate and trusted time Serves
all right 3.38 Protect audit information and audit tools from unauthorized access modification in deletion. You know, an attacker loves to scrub away or loves to clean up their tracks afterwards,
so we want to make sure that our log files are protected two right ones media and making sure the tools that would modify
ah those accounts or generate reports based on their zone it logs. We need to make sure that they're secured and protected, and that access is extremely limited. Toe authorized individuals
All right, 3.39 Limit management of audit functionality to a subset of privileged users on Lee. A few very select users should have the privilege of managing the audit function. Users shouldn't be able to turn on and turn off all the day war
modifier, restrict what's being audited that should be set up. My system of network administrator, security administrator and regular users should not
be able to modify that. So, basically, uh, with their drive security requirements were working on making sure we utilize thes audit logs, and we protect the integrity in the sanctity of what's in those articles.