NIST 800-171

Signal, Not Noise: AU 3.3.3

May 5, 2025May 5, 2025By 0 comments0 likes

Let’s talk about practice 3.3.3. – Review and update logged events.

[a] Determine if a process for determining when to review logged events is defined.
[b] Determine if event types being logged are reviewed in accordance with the defined review process.
[c] Determine if event types being logged are updated based on the review.

 

Let’s cut through the confusion.

This isn’t just another log review. It’s about making sure you’re even catching the right events. This one’s about tuning what you log in the first place.

Here are the controls in the Audit and Accountability (AU) domain and how 3.3.3 fits in.

  • AU 3.3.1: Make logs.
  • AU 3.3.2: Make sure they have the right stuff in them.
  • AU 3.3.3: Review and adjust what you’re logging. (We are here.)
  • AU 3.3.4 – 3.3.9: Handle log failures, correlation, timestamps, protection, etc.

AU 3.3.3 is the one that keeps the other controls sharp. It’s about deciding what gets logged so that when you need to respond or investigate, you’ve got the data that matters, not just a lot of noise.

Here’s the plan. We are going to:

  • Break down what AU 3.3.3 really means. Spoiler: It’s not log review. It’s log tuning.
  • Show how to operationalize it without overcomplicating things.
  • Share pitfalls and how to prevent them.

Quick Basics

 

If you know this, just humor me. I see these terms confused in assessments nearly every single time.

Event

A specific action or occurrence within a system

Example

A user logs into a system      

How It’s Used

The raw activity that happens.

Log

A record of one or more events stored in a file or system

Example

Log entry showing timestamp, username, IP address of login

How It’s Used

Used for auditing, troubleshooting & investigations. 

Alert

A notification triggered by specific conditions in logs 

Example

Alert triggered after 5 failed login attempts within 1 minute

How It’s Used

Used to notify admins of unusual or potentially malicious behavior.

  • Step 1: Make a List of Events You’re Logging

    Start with your systems—Windows servers, Linux boxes, cloud platforms, network gear. For each one, list the event types you’re logging right now. Pro tip: This doesn’t have to be perfect out of the gate. Even a rough inventory is better than staring at a blank page.

  • Step 2: Decide When You’re Gonna Review It

    • Annual review? Bare minimum. • Quarterly for crown jewels? Better. • After an incident or new system rollout? Pick Me! Pick Me! Write down the schedule. Not just in your head. Put it in a doc, set a recurring calendar reminder, tie it to change management. Do whatever you need to do to get it done.

  • Step 3: Get the Right People Involved

    Bring in: • Security folks • IT ops (they know the systems) • Compliance or GRC • Business owners (because they’ll call you when you break something)

  • Step 4: Review, Tune, Repeat

    Here’s what you’re looking for in the review: • Are we logging what we need to? (Think: Authentication events, CUI access, admin changes.) • Are we logging stuff that’s just filling up storage? (Think: Debug logs you haven’t used since 2019.) • Has anything changed? (New systems? New threats? Big incidents?) Adjust as needed: Add events you’re missing. Turn down the noise on logs that don’t add value. Confirm retention periods.

  • Step 5: Keep Evidence (Because If It’s Not Documented, It Didn’t Happen)

    • Save meeting minutes or review checklists. • Keep change tickets or config snapshots when you update log settings. • Archive SIEM configs, alerts, rules—anything that shows what changed and why. When the assessor asks, this is what proves you’re not just winging it.

Quick Review Template Example

System/Platform

Event Types Logged

Changes Needed?

Notes

Windows Servers

Logins, policy changes, object access

Yes

Add PowerShell logging, remove debug logs

Linux Servers

Auth events, sudo usage, SSH attempts

No

–

Azure

Sign-ins, conditional access, admin changes

Yes

Add API access logging

AWS

IAM changes, EC2 actions, S3 access

Yes

Tune down noisy S3 event types

Network Devices

Config changes, ACL mods, VPN logins

No

–

Greatest Hits of What NOT to Do

Because nothing beats learning from someone else’s faceplant.

You’ve got your process in place and your event types reviewed. Now, let’s talk about where things go sideways.

Here are 7 pitfalls I see defense contractors fall into when trying to meet 3.3.3.

Set It and Forget It Syndrome 1
The Problem: You configure logging when the system goes live and never touch it again. Threats evolve. Your environment changes. But your logs stay frozen in time. Prevent It: • Calendar those reviews (annually, quarterly, post-incident). • Tie logging reviews to change management. • Link threat intel to your logging updates.
Drowning In Noise 2
The Problem: “If some logging is good, ALL logging must be better.” So, you log everything. Now your SIEM is bloated, your analysts are buried, and you still miss the real threats. Prevent It: • Focus on quality over quantity. • Use severity levels and filters. • Test your alerts. If they’re firing on garbage, tune them.
Forgeting the Humans 3
The Problem: Security and IT make all the logging decisions without asking the people who actually use the systems. Prevent It: • Pull business owners into your reviews. • Validate logging assumptions against real workflows. • Build use cases that reflect how systems are actually used.
Documentation Black Hole 4
The Problem: You’ve done the reviews, made the changes—but can’t prove any of it. Prevent It: • Use templates for logging reviews. • Keep before/after configs, screenshots, or SIEM exports. • Log the rationale: why you did or didn’t change something.
Confusing Log Reviews with Event Type Reviews 5
The Problem: You think reviewing the logs themselves (e.g., daily log analysis) is the same thing as reviewing what you’re logging (AU 3.3.3). It’s not. Prevent It: • Separate log reviews from logging configuration reviews. • Different schedules. Different goals. Different artifacts.
Killing Performance with Over-Logging 6
The Problem: You crank up logging to 11, but your systems grind to a halt. Prevent It: • Test under load. • Monitor system performance alongside logging changes. • Build a dial-back plan for high-stress periods.
Inconsistency Across Systems 7
The Problem: You’ve got tight logging on Windows servers—but barely anything on Linux, network gear, or cloud. Prevent It: • Build cross-platform baselines. • Map equivalent events across systems. • Use consistent terminology to avoid gaps.

Assessment Ready Logging

Alright, you’ve tuned your logs, updated your events, and you’re feeling good. But are you ready to face the assessor?

You’ve done the work, but can you prove it?

What the Assessor Is Thinking

  • Are you actively managing what gets logged?
  • Do you review event types regularly?
  • Can you show me that you made changes based on risk, system updates, or incidents?

Assessors aren’t just checking if logs exist, they want to see you tuning and improving.

 

Example Artifacts That Say "We've Got This"

Artifact
What It Shows
Review Process Document
Your formal method for how/when you review event types.
Meeting Minutes or Checklists
Evidence that reviews happened. Dates, names, decisions made.
Change Tickets or Config Snapshots
Proof that logging settings were updated based on those reviews.
Logging Matrix
Shows systems vs. logged event types. Bonus points for updates over time.
Policy References
How your logging ties into overall security policies and risk posture.

What Should You Log?

Well, it depends, but here’s the golden rule:

Log what helps you detect, investigate, and respond to security events. Nothing more, nothing less.

Here are some examples, REMEMBER that these aren’t going to work for every company, these examples are meant to get you thinking about what you need to do in your environment.

Let’s break it down by system type:

Windows Servers

 

Category

Event IDs / Details

Authentication

4624 (logon success), 4625 (logon failure), 4672 (special logon)

Account Changes

4720 (account created), 4726 (deleted), 4732 (group membership)

Policy Changes

4719 (audit policy changes), 4739 (account policy changed)

Object Access

4656/4663 (access to files/folders with CUI)

Process Tracking

4688 (process creation), 4689 (termination)

PowerShell

4103, 4104 (script block logging)

Pro Tip: Enable command line logging for admin accounts, you need to know what’s being run. 

Windows Workstations

  • Failed logons: (4625)
  • USB insertions/removals: (4663 for device objects)
  • Software installs/uninstalls: (11707, 11708)
  • Group changes: (4728-4735)

These are your front lines. You want visibility into user behavior and device activity.

Network Devices

  • Admin logins
  • Configuration changes
  • Access Control List (ACL) updates
  • Interface up/down status
  • VPN connections/disconnections

Syslog is your friend here. Ship logs to your SIEM.

Cloud Environments (Azure / AWS)

 

Category

What to Monitor

Authentication

Azure AD sign-ins, MFA events, AWS IAM logins

Policy changes

Conditional access in Azure, IAM policies in AWS

Resource access

S3 bucket access (AWS), SharePoint/OneDrive (M365)

Security group / firewall changes

Azure NSG changes, AWS Security Group changes

CloudTrail / Audit logs

Monitor for disabling/modifying CloudTrail (AWS)

Pro Tip: Cloud-native logs like Azure Monitor and AWS CloudTrail are gold mines—just make sure they’re enabled and you’re reviewing them.

Linux / Unix Systems

 

Category

What to Monitor

Authentication

/var/log/auth.log or /var/log/secure

sudo usage

Who ran what with elevated permissions

SSH access

Successful and failed attempts

Account modifications

useradd, usermod, passwd changes

File access

auditd rules for sensitive directories

Config changes

Changes to system settings or services

Pro Tip: Use auditd for detailed file access and system call tracking.

Example auditd Rule (Linux)

Track access to a CUI directory:

# Add to /etc/audit/rules.d/cui.rules

-w /path/to/cui_directory -p warx -k cui_access

This captures write, attribute change, read, and execute actions.

Example PowerShell Commands (Windows)

Enable detailed auditing for Windows Servers:

$auditCategories = @(

    “Account Logon”,

    “Account Management”,

    “Detailed Tracking”,

    “DS Access”,

    “Logon/Logoff”,

    “Object Access”,

    “Policy Change”,

    “Privilege Use”,

    “System”

)

 

foreach ($category in $auditCategories) {

    auditpol /set /subcategory:”$category” /success:enable /failure:enable

}

 

# Enable PowerShell script block logging

Set-ItemProperty -Path “HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging” -Name “EnableScriptBlockLogging” -Value 1

Know When to Dial It Back

Logging too much? Here are some examples of things you may want to tune.

Event Type

Recommended Log Level

Authentication failures

Always log

Successful logons

Only for admin accounts

Routine system messages

Filter or summarize

Debugging data

Off in production

Wrap Up

AU 3.3.3 is about making sure you’re logging the right things, not everything.

  • Log what matters.
  • Tune out the noise.
  • Review regularly.

Leave a Reply

Your email address will not be published.

Social Share Buttons and Icons powered by Ultimatelysocial