Signal, Not Noise: AU 3.3.3

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.

Let’s cut through the confusion.

Here’s the plan. We are going to:

Quick Basics

A specific action or occurrence within a system

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

A notification triggered by specific conditions in logs

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

Step 2: Decide When You’re Gonna Review It

Step 3: Get the Right People Involved

Step 4: Review, Tune, Repeat

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

Quick Review Template Example

Greatest Hits of What NOT to Do

Because nothing beats learning from someone else’s faceplant.

Assessment Ready Logging

What the Assessor Is Thinking

Example Artifacts That Say "We've Got This"

What Should You Log?

Windows Servers

Windows Workstations

Network Devices

Cloud Environments (Azure / AWS)

Linux / Unix Systems

Example auditd Rule (Linux)

Example PowerShell Commands (Windows)

Know When to Dial It Back

Wrap Up

Related posts

Is your security posture keeping you up at night?