On this page

Security Configuration Review

Security configuration review validates that systems remain aligned with defined security baselines through automated scanning, manual inspection, and deviation analysis. This task establishes the procedures for conducting periodic reviews, documenting findings, and tracking remediation through to completion.

Configuration drift occurs continuously as administrators make changes, applications update settings, and operational pressures lead to exceptions that outlive their justification. A server configured securely at deployment may accumulate dozens of deviations over twelve months. Without systematic review, these deviations remain invisible until an incident exposes them.

Prerequisites

Requirement	Detail
Baseline standards	Documented configuration baselines for each system type (see Access Control Standard, Cryptography Standard)
Scanning tools	Configuration scanning platform deployed and authenticated to target systems
Review schedule	Approved schedule specifying review frequency by system criticality
Access	Read access to target systems; administrative access for remediation
Exception register	Access to existing exception documentation
Time allocation	4-8 hours for automated scan execution; 2-4 hours per system type for manual review

Verify that scanning tools can reach target systems before beginning the review cycle. Authentication failures during scanning produce incomplete results that require re-execution:

# Test scanner connectivity to Windows domain
ansible -i inventory/production.yml windows_servers -m win_ping

# Test scanner connectivity to Linux systems
ansible -i inventory/production.yml linux_servers -m ping

# Verify cloud API access for Azure configuration review
az account show --query "name"

Confirm baseline documents are current. Baseline standards require annual review; do not assess systems against baselines that have not been reviewed within the past twelve months.

Procedure

Define the review scope by selecting system categories and specific instances for assessment. Each review cycle need not cover all systems; instead, rotate through system types to achieve full coverage over the review period. A quarterly cycle covering one-quarter of infrastructure per review provides annual coverage for all systems.
Document scope in the review record:

   Review ID: SCR-2024-Q4-LIN
   Review date: 2024-11-15
   Scope: Linux servers (production)
   Systems in scope: 47
   Baseline: LIN-SEC-STD-v2.3 (reviewed 2024-06-01)
   Reviewer: [Name]

System criticality determines review frequency. Tier 1 systems (identity providers, internet-facing applications, financial systems) require quarterly review. Tier 2 systems (internal applications, file servers) require semi-annual review. Tier 3 systems (development environments, test systems) require annual review.

Execute automated compliance scanning against the defined scope. Configuration scanners compare current system state against baseline templates and report deviations as findings.
For Linux systems using OpenSCAP:

   # Generate compliance report against CIS baseline
   oscap xccdf eval \
     --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
     --results /var/log/scap/results-$(hostname)-$(date +%Y%m%d).xml \
     --report /var/log/scap/report-$(hostname)-$(date +%Y%m%d).html \
     /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

   # Exit code 0 = pass, 1 = failure, 2 = error
   echo "Scan exit code: $?"

For Windows systems using PowerShell DSC:

   # Test configuration against baseline MOF
   $results = Test-DscConfiguration -ComputerName $targetServers -ReferenceConfiguration "C:\Baselines\WindowsServer2022.mof" -Detailed

   # Export findings
   $results | Where-Object { $_.InDesiredState -eq $false } |
     Export-Csv -Path "C:\Reviews\findings-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

For cloud infrastructure using Azure Policy:

   # List non-compliant resources
   az policy state list \
     --filter "complianceState eq 'NonCompliant'" \
     --query "[].{resource:resourceId, policy:policyDefinitionName, state:complianceState}" \
     --output table

Automated scanning typically identifies 60-80% of configuration deviations. The remaining deviations require manual inspection to detect.

Conduct manual configuration review for settings that automated tools cannot assess. Automated scanners verify that settings match expected values; they cannot evaluate whether security architecture decisions remain appropriate or whether compensating controls function correctly.
Manual review categories include:

   +--------------------------------------------------------------------+
   |                         MANUAL REVIEW SCOPE                        |
   +--------------------------------------------------------------------+
   |                                                                    |
   |  +-------------------+  +-------------------+  +----------------+  |
   |  | Access Control    |  | Network Security  |  | Data Protection|  |
   |  |                   |  |                   |  |                |  |
   |  | - Service account |  | - Firewall rules  |  | - Encryption   |  |
   |  |   permissions     |  |   currency        |  |   key ages     |  |
   |  | - Group           |  | - Unused open     |  | - Backup       |  |
   |  |   memberships     |  |   ports           |  |   encryption   |  |
   |  | - Privilege       |  | - Segmentation    |  | - Certificate  |  |
   |  |   assignments     |  |   effectiveness   |  |   validity     |  |
   |  +-------------------+  +-------------------+  +----------------+  |
   |                                                                    |
   |  +-------------------+  +-------------------+  +----------------+  |
   |  | Logging           |  | Patch Currency    |  | Authentication |  |
   |  |                   |  |                   |  |                |  |
   |  | - Log retention   |  | - Security        |  | - MFA          |  |
   |  |   compliance      |  |   updates >30     |  |   enforcement  |  |
   |  | - Audit coverage  |  |   days old        |  | - Session      |  |
   |  | - Alert           |  | - Critical        |  |   timeouts     |  |
   |  |   configuration   |  |   patches >14     |  | - Failed       |  |
   |  |                   |  |   days old        |  |   login        |  |
   |  |                   |  |                   |  |   thresholds   |  |
   |  +-------------------+  +-------------------+  +----------------+  |
   |                                                                    |
   +--------------------------------------------------------------------+

Review service accounts by examining actual permission assignments:

   # List service account permissions in Linux
   getent passwd | grep -E "svc-|service" | cut -d: -f1 | while read user; do
     echo "=== $user ==="
     groups $user
     find /etc /var -user $user -ls 2>/dev/null | head -20
   done

   # Audit service account permissions in Active Directory
   Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, MemberOf |
     Select-Object Name, @{N='Groups';E={$_.MemberOf | ForEach-Object { (Get-ADGroup $_).Name }}}

Record manual findings in the same format as automated findings to enable unified tracking.

Analyse all findings to identify actual deviations requiring action. Not every finding represents a genuine security issue. Some deviations are intentional (documented exceptions), some are false positives (scanner misconfiguration), and some are informational (settings that differ from baseline but do not reduce security).
Classify each finding:

   Finding classification:

   TRUE_POSITIVE    - Genuine deviation requiring remediation
   EXCEPTION        - Documented exception with compensating control
   FALSE_POSITIVE   - Scanner error or misconfiguration
   INFORMATIONAL    - Deviation without security impact

For a representative review of 47 Linux servers, finding distribution might appear as:

   Findings summary - SCR-2024-Q4-LIN

   Total findings:           312
   True positives:           89  (29%)
   Documented exceptions:    41  (13%)
   False positives:          67  (21%)
   Informational:           115  (37%)

   True positives by severity:
     Critical:   3
     High:      17
     Medium:    42
     Low:       27

False positives require scanner tuning to prevent recurrence. Document each false positive pattern and update scanner configuration:

   # OpenSCAP tailoring file - exclude false positives
   tailoring:
     rules:
       # Server uses central logging; local retention not required
       - id: xccdf_rule_auditd_data_retention_max_log_file
         selected: false
         reason: "Central syslog configured; FP per exception EXC-2024-017"

Prioritise true positive findings for remediation based on severity, exploitability, and system criticality. A high-severity finding on a Tier 3 development system warrants lower priority than a medium-severity finding on a Tier 1 identity provider.

Remediation timeline by priority:

Priority	Criteria	Remediation window
P1	Critical severity on Tier 1 system	48 hours
P2	High severity on Tier 1, Critical on Tier 2	7 days
P3	Medium severity on Tier 1, High on Tier 2	30 days
P4	Low severity on Tier 1/2, any on Tier 3	90 days

Generate remediation tickets with sufficient detail for implementation:

   Ticket: REM-2024-1847
   Finding: SSH MaxAuthTries set to 6, baseline requires 3
   System: srv-app-prod-03.example.org
   Severity: Medium
   Priority: P3
   Remediation: Set MaxAuthTries 3 in /etc/ssh/sshd_config
   Verification: sshd -T | grep maxauthtries
   Due date: 2024-12-15
   Assignee: [Name]

Execute remediation for prioritised findings. For P1 and P2 findings, remediation proceeds immediately through the emergency change process. For P3 and P4 findings, remediation follows standard change management.
Apply configuration changes following the documented baseline:

   # Remediate SSH configuration
   sudo sed -i 's/^MaxAuthTries.*/MaxAuthTries 3/' /etc/ssh/sshd_config
   sudo sshd -t  # Validate configuration syntax
   sudo systemctl reload sshd

   # Verify remediation
   sshd -T | grep maxauthtries
   # Expected output: maxauthtries 3

For bulk remediation across multiple systems, use configuration management:

   # Ansible playbook for SSH hardening remediation
   - name: Remediate SSH MaxAuthTries
     hosts: affected_servers
     become: yes
     tasks:
       - name: Set MaxAuthTries to 3
         lineinfile:
           path: /etc/ssh/sshd_config
           regexp: '^MaxAuthTries'
           line: 'MaxAuthTries 3'
         notify: reload sshd

     handlers:
       - name: reload sshd
         service:
           name: sshd
           state: reloaded

Document each remediation action with before and after states:

   Remediation record:
   Ticket: REM-2024-1847
   Action date: 2024-11-18
   Before: MaxAuthTries 6
   After: MaxAuthTries 3
   Verified by: [Name]
   Change ID: CHG-2024-4521

Process findings that cannot be remediated as exceptions. Some deviations exist for valid operational reasons: legacy application compatibility, vendor support requirements, or risk acceptance decisions. These require formal exception documentation rather than remediation.
Exception requests require:

   Exception request - EXC-2024-089

   Finding: TLS 1.0 enabled on srv-legacy-fin-01
   Baseline requirement: TLS 1.2 minimum

   Business justification:
   Legacy financial application (vendor: FinCorp) requires TLS 1.0
   for integration with banking partner. Vendor roadmap shows TLS 1.2
   support in version 4.2, scheduled Q2 2025.

   Compensating controls:
   - Network segmentation restricts access to finance subnet only
   - WAF in front of application blocks known TLS 1.0 attacks
   - Enhanced logging on all TLS 1.0 connections
   - Monthly review of connection logs for anomalies

   Risk acceptance:
   Residual risk: Medium
   Accepted by: [Name, Title]
   Acceptance date: 2024-11-20
   Review date: 2025-03-01

Exceptions require periodic review. Set review dates based on the expected duration of the exception condition:

Exception duration	Review frequency
Under 6 months	At expiry
6-12 months	Quarterly
Over 12 months	Monthly
Permanent	Quarterly

Generate the review report consolidating all findings, remediations, and exceptions. The report serves as both operational record and compliance evidence.

+------------------------------------------------------------------------------+
|                    SECURITY CONFIGURATION REVIEW REPORT                      |
+------------------------------------------------------------------------------+
|                                                                              |
|  Review metadata                                                             |
|  +------------------------------------------------------------------------+  |
|  |  ID: SCR-2024-Q4-LIN          |  Date: 2024-11-15                      |  |
|  |  Scope: Linux production      |  Systems: 47                           |  |
|  |  Baseline: LIN-SEC-STD-v2.3   |  Reviewer: [Name]                      |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
|  Findings summary                                                            |
|  +------------------------------------------------------------------------+  |
|  |                                                                        |  |
|  |  Total: 312          True positives: 89        Exceptions: 41          |  |
|  |  False positives: 67                           Informational: 115      |  |
|  |                                                                        |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
|  Remediation status                                                          |
|  +------------------------------------------------------------------------+  |
|  |                                                                        |  |
|  |  Remediated: 72      |  In progress: 14      |  Exception: 3           |  |
|  |                                                                        |  |
|  |  Overdue: 0          |  Compliance: 96.2%                              |  |
|  |                                                                        |  |
|  +------------------------------------------------------------------------+  |
|                                                                              |
|  Next review: 2025-02-15                                                     |
|                                                                              |
+------------------------------------------------------------------------------+

Store the report in the designated compliance repository with retention per organisational policy (typically 7 years for audit evidence).

Verification

Confirm review completion against each success criterion:

# Verify automated scan coverage
echo "Systems in scope: 47"
echo "Systems scanned: $(cat scan_results/*.xml | grep -c 'target-address')"
# Expected: counts match

# Verify remediation completion for closed tickets
az boards query --wiql "SELECT [ID], [State] FROM WorkItems
  WHERE [Tags] CONTAINS 'SCR-2024-Q4-LIN' AND [State] = 'Closed'" \
  --output table

# Re-scan remediated systems to confirm fixes
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /var/log/scap/verification-$(hostname)-$(date +%Y%m%d).xml \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

Compare verification scan results against original findings:

Verification summary:
Original true positives:     89
Remediated and verified:     72
New exceptions documented:    3
Pending remediation:         14 (within SLA)
Regression findings:          0

The review cycle completes when all true positive findings are either remediated (verified by re-scan), documented as exceptions (with approval), or tracked as pending (within remediation SLA).

Troubleshooting

Symptom	Cause	Resolution
Scanner returns zero findings	Authentication failure or empty scope	Verify scanner credentials; confirm target inventory is populated; check scanner logs for connection errors
Scan duration exceeds 4 hours	Network latency or system overload	Reduce parallel scan threads; schedule scans during off-peak hours; segment scope across multiple scan jobs
Same false positives recur each cycle	Tailoring file not applied	Verify tailoring file is referenced in scan command; confirm scanner loaded tailoring at execution
Findings missing severity ratings	Baseline lacks CVSS mappings	Update baseline with severity definitions; manually assign severity based on control importance
Remediation breaks application	Configuration change impacts functionality	Roll back change; investigate dependency; document as exception if remediation not feasible
Exception approval delayed	Risk owner unavailable	Escalate to deputy risk owner; extend remediation SLA with documented justification
Report generation fails	Data format inconsistency	Validate all finding records have required fields; correct malformed entries before regenerating
Verification scan shows regression	Remediation reverted or ineffective	Check configuration management for conflicting changes; verify remediation was applied to correct system
Scanner misidentifies operating system	Outdated scanner signatures	Update scanner content packages; verify target system returns accurate identification strings
Cloud API rate limiting during scan	Too many concurrent API calls	Implement request throttling; spread scan across longer time window; request API limit increase
Compliance percentage calculation wrong	Exception weighting incorrect	Verify exception status correctly categorised; confirm compliance formula excludes documented exceptions from denominator

Remediation dependencies

Some findings have dependencies that require ordered remediation. Disabling legacy protocols may break applications; tightening firewall rules may block required traffic. Always verify application functionality after remediation and maintain rollback capability.

Security checklist template

The following template provides a structured format for documenting manual review findings alongside automated scan results.

Security Configuration Review Checklist

Review ID: _______________    Date: _______________
Scope: _______________        Reviewer: _______________
Baseline: _______________     System(s): _______________

IDENTITY AND ACCESS CONTROL

[ ] Local administrator accounts disabled or renamed
    Finding: _______________________________________________

[ ] Service accounts use least privilege
    Finding: _______________________________________________

[ ] No shared accounts in use
    Finding: _______________________________________________

[ ] Guest accounts disabled
    Finding: _______________________________________________

[ ] Account lockout configured (threshold: ___ attempts)
    Finding: _______________________________________________

AUTHENTICATION

[ ] Password policy enforced (minimum length: ___ characters)
    Finding: _______________________________________________

[ ] MFA enabled for administrative access
    Finding: _______________________________________________

[ ] Session timeout configured (maximum: ___ minutes)
    Finding: _______________________________________________

[ ] Failed login logging enabled
    Finding: _______________________________________________

NETWORK SECURITY

[ ] Host firewall enabled with default deny
    Finding: _______________________________________________

[ ] Only required ports open
    Open ports: _______________________________________________
    Justified: [ ] Yes  [ ] No

[ ] Remote management restricted to management network
    Finding: _______________________________________________

[ ] ICMP restricted appropriately
    Finding: _______________________________________________

ENCRYPTION

[ ] Data at rest encrypted
    Method: _______________________________________________

[ ] Data in transit uses TLS 1.2+
    Finding: _______________________________________________

[ ] Certificates valid and not expiring within 30 days
    Expiry dates: _______________________________________________

LOGGING AND MONITORING

[ ] Security event logging enabled
    Log destination: _______________________________________________

[ ] Audit policy captures authentication events
    Finding: _______________________________________________

[ ] Log retention meets policy (minimum: ___ days)
    Current retention: _______________________________________________

[ ] Logs protected from tampering
    Finding: _______________________________________________

SYSTEM HARDENING

[ ] Unnecessary services disabled
    Running services: _______________________________________________

[ ] Security updates current (last applied: _______________)
    Missing critical updates: _______________________________________________

[ ] Removable media controls enforced
    Finding: _______________________________________________

[ ] Boot security enabled (Secure Boot / TPM)
    Finding: _______________________________________________

CONFIGURATION MANAGEMENT

[ ] System enrolled in configuration management
    Platform: _______________________________________________

[ ] Baseline applied and compliant
    Compliance: ___% (___/___) checks passing

[ ] Change history available
    Last change: _______________________________________________

SUMMARY

Total items reviewed: ___
Compliant: ___
Non-compliant: ___
Exceptions: ___

Critical findings requiring immediate action:
1. _______________________________________________
2. _______________________________________________
3. _______________________________________________

Reviewer signature: _______________    Date: _______________

Security Configuration Review

Prerequisites

Procedure

Verification

Troubleshooting

Security checklist template

See also

Thanks for the feedback!

Help us improve