My name is Dave [inaudible], and I'm your instructor for this class. This is course to understanding and implementing the 110 NIST, 800-171 requirements. As you know, there are 14 requirements families in this state of 171. In this video, we'll take a look at requirement family 3.3: Audit and Accountability. For audit and accountability, we need to understand what CUI is managed, who has access to it, where it's stored and processed, and how it's used. We need to enable logging, protect logs, and ensure that logs are reviewed for anomalous and suspicious behavior, and we need to remember that physical assets that have CUI also need to have that same level of audit and accountability, and that may require manual methods. In this particular requirement family, there are nine requirements. Let's jump right in and take a look at each one. The first requirement is 3.3.1: Create and retain system audit logs and records to the extent needed to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. This is a basic requirement, and according to this quote, ''an event is any observable occurrence in a system which includes unlawful, or unauthorized system activity''. You need to define events that should be logged, again, non-prescriptive, they don't tell you what events to log. They leave that up to you and you need to define the information to capture in those logs such as timestamps, IP addresses, user identifiers, etc. All the individual discrete pieces of data that you would need to be able to identify a process in the event of unlawful or unauthorized access to CUI. Again, not prescriptive, they don't tell you exactly what you need. They give you some guidance, but they're not telling you exactly what to do, and then you need to review those logs regularly. They do point to NIST special publication 800-92 for additional guidance on security log management. I would strongly recommend as you think about how to build the logging, you need to be in compliance with this family of requirements that you take a look at 800-92. 3.3.2: Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions. This is another basic requirement, ensure the logs contain the information required to identify the actions of an individual or a process. Remember, this also includes processes that have access to CUI. The good news is on a lot of the controls in this family, these can be easily accomplished through the tools built in the most modern operating systems like Windows. It's really just a matter of determining what information you need and then ensuring that logging is captured and it's stored securely somewhere. Let's take a look at 3.3: Review and update logged events, a derived requirement. This really boils down to occasionally reviewing what you're logging, the events in the data you're logging to make sure that the types of intra-tracking, as well as the individual pieces of data that go along with those events to identify them, continue to meet your needs over time. Things change, organizations change, you need to review that, and make sure that over time you're collecting the right information you need. 3.4: Alert in the event of an audit logging process failure. Drives fail, drives run out of space, that sort of thing, software fails. You need to build in to your systems a way to ensure that if logging stops for whatever reason, you have a way to know that. 3.3.5: Correlate audit record review, analysis and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. This is a derived requirement, and it really boils down to ensuring that you may have different types of systems, with different types of logging that you're correlating those logs, you're analyzing the aggregated logs to make sure that there aren't trends or patterns or some information across all those logs that might be missed, if you're only looking at one log or a handful of logs individually. It's thinking about that as an ecosystem and making sure that you're looking at all of that information for trends and patterns that could be indicative of exposure or loss of CUI. 3.3.6: Provide audit record reduction and report generation to support on-demand analysis and reporting, so another derived requirement. This is about being able to provide summary data from detailed logs from reporting and analysis, and it can include machine learning, data mining, and other techniques like that, so that someone doesn't necessarily have to sit down and review all the detailed logging records to log reduction, you can provide summaries especially from a management perspective, would provide the information that's necessary. Then 3.7, Provide a system capability that compares and synchronizes internal systems clocks with an authoritative source to generate timestamps for audit records, and this is a derived requirement. It's really making sure that across all your logging, you have uniform time stamps, so that the logging records match up, and they may suggest the timings is expressed in Coordinated Universal Time or local time with an offset for UTC. Our second to last one, 3.3.8, Protect audit information and audit logging tools from unauthorized access, modification and deletion. This is a derived requirement, includes all information needed to audit activity, and really is saying you need to make sure that now you have the log records secure, but the tools to access those log records, they're secure, and frankly, there's logging around that to know who's using them so that someone can't go in and alter or delete critical logs that might ultimately be needed in an investigation if CUI is exposed. Then finally, 3.3.9: Limit management of audit logging functionality to a subset of privileged users. Because log records could be critical in the event of a breach, you want to make sure that only trusted users have led privileged access. This is a derived requirement, and again, you just want to make sure that only a limited pool of trusted users have access to the logs, and the tools to manage those logs. That gets us through all the requirements of 3.3. Thank you and I'll see you in the next video.
