Hardening is a pipeline, not a checklist
The JD says "harden connections and network security across the infrastructure" — and BGP hardening is named separately as the core skill. This page is the rest of the discipline: hosts, network, TLS, and the scan → patch → verify loop you already run at Penske under PCI DSS.
Secure the sessions first
Full treatment on the BGP page. The 30-second version: GTSM/TTL-security, TCP MD5 or TCP-AO authentication, prefix limits with restart, default-deny inbound/outbound filters, RPKI at the edge, BFD for fast failover, and communities for policy (RTBH for attacks). In an interview, that list — with one real story about a session that got rescued — beats an hour of theory.
RHEL and RHCOS, locked down
SELinux, enforcing
Never "just disable it to make it work." Diagnose with ausearch, fix with booleans/policy or context relabeling. RHCOS ships enforcing by default — that's the baseline, not the goal.
Firewall & exposure
firewalld/nftables default-deny, zone separation, SSH on restricted networks, minimal package footprint, no unused services. On RHCOS this lives in MachineConfigs — config drift is a build artifact, not a weekend script.
Access & audit
SSH keys, no root login, sudo + centralized auth (LDAP/AD), MFA, session logging, auditd rules for the interesting syscalls. Your LDAP/winbind + Entra ID SAML history is exactly this.
RHEL: OpenSCAP profiles (CIS, STIG) applied via Ansible at scale — your monthly patching automation. OpenShift: the Compliance Operator runs CIS OpenShift scans continuously. The pattern to state: define the profile → automate enforcement → scan to prove it → report to management. That's the PCI DSS loop you already run with Nessus findings.
Trust nothing by default
- VLANs per trust zone — DC services, app tiers, management (oob), DMZ, storage — with ACLs at the L3 boundary
- Micro-segmentation inside the cluster — OVN-Kubernetes NetworkPolicies: default-deny, then allow the flows that exist
- East-west visibility — if you can't see a flow, you can't policy it: netflow/IPFIX + Splunk (your existing stack)
- Management plane isolation — out-of-band management, jump hosts, and no management on the data VLAN
- 802.1X / NAC where ports matter; at minimum, port security on edge switches
TLS 1.2+ only, modern cipher suites, HSTS on public edges, short-lived certs with automated renewal (cert-manager in-cluster), and mTLS where service-to-service identity matters. Cert expiry is the silent outage — on OpenShift, cluster certs expire on a schedule; you monitor and renew them like any other SLA.
Scan → patch → verify → report
This is your Penske story, and it is the exact operating rhythm a hardening owner needs:
- Scan — Tenable Nessus across the estate; classify critical/high vs the noise
- Prioritize — exploitability × exposure, PCI DSS impact first
- Patch — Ansible Automation Platform across RHEL/Oracle Linux; operators + CVO inside OpenShift; change-controlled for production
- Verify — rescan until findings close; smoke-test the apps behind the hosts
- Report — weekly posture to management; the metric that keeps funding the work
The 90% story
Automated monthly Linux patching with Ansible, cutting manual effort by more than 90%. That's not a bullet point — it's proof you convert hardening from heroics into repeatable automation. Say it with the number.
Detection stack
CrowdStrike (you deployed it to 1,000+ Linux hosts) + LogicMonitor/Dynatrace/Splunk: prevent, detect, respond. NinjaOne adds the RMM layer for endpoints — same discipline, different tool.
Questions to answer out loud
How would you harden a fresh RHEL server today?
Minimal install → CIS/STIG profile via OpenSCAP or Ansible roles → SELinux enforcing + firewalld default-deny → SSH keys, no root login, centralized auth + MFA → auditd + monitoring agent + EDR (CrowdStrike) → join patch pipeline → add to Nessus scope → prove it with a clean scan. Every step automated, so the hundredth server costs the same as the first.
BGP hardening — what's your actual checklist?
TTL security (GTSM), TCP-AO/MD5 on every session, loopback peering where possible, BFD, maximum-prefix with restart, strict inbound/outbound prefix filters (default-deny), RPKI at internet edges, communities for policy, RTBH for attacks, and logging + table diffs around every change. Then the operational part: every peer documented, every filter in version control.
Someone says "just disable SELinux." What do you do?
Push back and diagnose: ausearch -m avc shows the denial; the fix is a boolean, policy addition, or context relabel — not weakening the whole host. Permissive mode temporarily to isolate the issue, then back to enforcing with the right policy. Disabling SELinux in a PCI DSS environment is a finding waiting to happen, and it's a signal the person doesn't understand the security model.