MTG: Linux Remediation — Kickoff & Scope Alignment

Details

Date: 2026-06-02
Type: Kickoff / Scope Alignment
Attendees:

Objective

Align on the scope of Linux remediation and establish a common understanding of the current gaps around credentials, inventory, lifecycle automation, and ownership — particularly for research systems — so we can define clear roles and next steps.

Agenda

1. Context & Problem Statement

  • Lack of standardized Linux credentials (local accounts, SSH keys, service accounts)

  • Need for a Linux standard in general

  • No reliable or complete inventory of Linux systems

  • Significant gaps for research-hosted systems

  • Inconsistent or missing ownership capture at system creation

  • Limited automation for Linux onboarding/offboarding

  • Systems not consistently enrolled in:

    • Monitoring

    • Patching

    • CMDB

    • Vulnerability scanning (e.g., Tenable)

2. Scope & Objectives

In scope:

  • Credential standardization and lifecycle

  • Authoritative inventory

  • Automated enrollment into monitoring, patching, CMDB, and vulnerability scanning

  • Owner captured at system inception

Desired end state:

  • Standardized credentials across all Linux systems

  • Authoritative, auditable inventory

  • Automated enrollment pipeline (monitoring, patching, CMDB, Tenable)

  • Owner captured and validated at system inception

Out of scope: (define during meeting)

3. Current-State Review

  • How Linux systems are provisioned today (enterprise vs. research)

  • Where onboarding/offboarding breaks down

  • How systems end up missing from CMDB, Tenable, monitoring, or patching

  • Known failure points and inconsistencies

4. Identity & Credential Management

  • Current credential patterns in use (or lack thereof)

  • Gaps in standardization and lifecycle control

  • Expectations for credential creation, rotation, and removal

5. Roles & Responsibilities

Operational ownership for:

  • Linux platforms

  • Credential management

  • Inventory / CMDB accuracy

  • Vulnerability scanning enrollment

Clear accountability vs. shared responsibility (RACI-level discussion)

6. Existing Tools, Automation & Processes

  • Applicable Azure automation/runbooks

  • CMDB and monitoring capabilities

  • Tenable onboarding expectations

  • What can be reused vs. what is missing

7. Lifecycle Triggers

System lifecycle events:

  • Build, rebuild, decommission

User lifecycle events:

  • Joiner, mover, leaver

What actions should automatically occur:

  • Owner capture

  • Credential setup

  • Enrollment into monitoring, patching, CMDB, Tenable

Additional Points of Consideration

8. Network Access Control (NAC / 802.1X)

  • Are Linux systems enrolled in NAC for posture assessment?

  • Unenrolled systems are invisible to policy enforcement

  • Should 802.1X machine authentication be part of the enrollment baseline?

9. SSH Key Governance

  • Who inventories authorized_keys across hosts?

  • Are there orphaned keys from departed staff?

  • Is there a CA-signed SSH certificate model vs. static key distribution?

  • Key rotation policy — does one exist? Is it enforced?

10. Certificate Lifecycle

  • Are Linux hosts using machine certificates for authentication?

  • Who manages issuance, renewal, and revocation?

  • Integration with enterprise PKI or separate CA?

11. Configuration Drift & Hardening Baseline

  • Are systems baselined against CIS benchmarks or DISA STIGs?

  • How is configuration drift detected? (AIDE, OSSEC, Ansible diff)

  • Research systems especially tend to skip hardening — define a minimum viable profile

  • Is there a standard image or golden build?

12. Privileged Access & Sudo Audit

  • Who has root or sudo, and how is that reviewed?

  • PAM integration with AD/LDAP for centralized authorization

  • Break-glass account procedures

13. Log Aggregation & SIEM Enrollment

  • Systems missing from monitoring are likely missing from SIEM

  • Syslog/journald forwarding should be part of the enrollment checklist

  • Audit logging (auditd) configuration standards

14. Research System Exception Process

  • Research needs flexibility, but "exception" ≠ "invisible"

  • Define a lightweight compliance tier with mandatory minimums:

    • Inventory registration

    • Patching (even if deferred cadence)

    • Vulnerability scanning

    • Owner assignment

  • Exception request and review process

15. Decommission Verification

  • How do you confirm a system is actually gone?

  • Cleanup checklist: DNS records, DHCP leases, firewall rules, CMDB entries, Tenable agents, monitoring agents, SSH keys, certificates

  • Who triggers decom and who validates completion?

16. Success Criteria & Metrics

  • What does "remediated" mean? Define measurable outcomes:

    • Percentage of Linux systems in CMDB

    • Time-to-enroll for new builds

    • Credential compliance rate

    • Tenable coverage percentage

  • Reporting cadence and ownership of metrics

Discussion

Meeting notes here.

Decisions

*

Action Items

Action Owner Due

Related