Server Hardening Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

The following keywords are used to express requirement strength in this standard:

• SHALL / MUST: Mandatory requirement. Non-compliance requires an approved exception.
• SHOULD: Recommended requirement. If not implemented, rationale should be documented.
• MAY: Optional requirement.
• MUST NOT / SHALL NOT: Prohibited requirement.

1.1 Purpose

The purpose of this standard is to establish mandatory security hardening requirements for all infrastructure—servers, workstations, and mobile devices—used to support government operations. It covers: authentication and access control (account management, password policy, MFA, privileged access management); operating system hardening (baseline configuration, file system security, patch management); endpoint management (MDM for mobile, encryption, compliance); network security (host firewall, service hardening, time synchronisation); logging and monitoring; encryption (data at rest and in transit); and platform-specific requirements (Linux, Windows, macOS, iOS, Android). It does not replace application-level or network-level controls but complements them so that infrastructure, network, and identity controls together provide defence in depth.

1.2 Scope of Application

This standard applies to:

• Servers: All physical servers in government data centres; all virtual machines hosting government workloads; all server operating systems (Linux, Windows variants); all server roles (compute, storage, database, middleware, identity, management); all management models (internally managed, vendor-operated, or hybrid).
• Workstations and endpoints: All workstations and laptops (Windows, macOS, Linux) used to access government systems or data; critical systems require CIS Endpoint benchmarks Level 1 hardening and full disk encryption.
• Mobile devices: All smartphones and tablets (iOS, Android, government-owned or BYOD) accessing government email or applications; must be enrolled in MDM and comply with device policy (encryption, passcode, compliance checks).

It applies regardless of hosting model—on-premises, government cloud, or vendor-managed—where the government retains responsibility for the security of the asset.

1.3 Definitions and Key Terms

Hardening – The process of configuring a system to reduce its attack surface by disabling unnecessary services, applying least-privilege access, enabling audit logging, and applying security patches in line with risk.

CIS Benchmarks – Consensus-based configuration guidelines for securing systems; CIS Level 1 is the mandatory baseline for government servers in this standard.

Multi-Factor Authentication (MFA) – Authentication using two or more independent factors (e.g. password plus TOTP or FIDO2) to reduce the risk of compromise from stolen or guessed credentials; mandatory for all administrative access.

Privileged access – Access that allows configuration of systems, management of other users, or access to sensitive data; requires stricter controls including MFA, session logging, and Just-In-Time principles where feasible.

STIG (Security Technical Implementation Guide) – DoD-developed configuration baselines; mandatory for internet-facing and classified systems where mandated by government policy.

Full disk encryption – Encryption of entire storage so that data at rest is protected; required for all accessible systems per this standard.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Reduced attack surface – Unnecessary services, daemons, and features are disabled; non-essential packages removed; role-specific security templates applied; host firewall with default-deny.

Strong authentication and access control – Unique individual accounts; no shared administrative accounts; passwords per NIST SP 800-63B; MFA for all administrative access; privileged session logging; immediate revocation upon role change or separation.

Timely patching – Critical and high vulnerabilities remediated within defined timelines (e.g. CVSS 9.0–10.0 within 15 days; 7.0–8.9 within 30 days); compensating controls documented when timelines cannot be met.

Encryption and logging – Full disk encryption; TLS 1.2 minimum (TLS 1.3 preferred) for data in transit and administrative access; comprehensive audit logging with centralised SIEM forwarding; retention per policy (e.g. 90 days online, 7 years archived).

Consistency and compliance – All government servers comply with CIS Level 1 and with NIST/STIG where applicable; evidence is available for audit; exceptions are documented and time-bound.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

Minimum controls (floor for all ministries):

CIS Level 1: All government servers SHALL be assessed against CIS Level 1; critical findings remediated within 30 days or excepted per Vulnerability Management.

• MFA: All administrative access SHALL use MFA (FIDO2/TOTP/push; no SMS as primary).
• Patching: Critical (CVSS 9–10) within 15 days; High (7–8.9) within 30 days per Section 5.3.
• Logging: Critical and high-impact servers SHALL forward audit logs to SIEM; retention 90 days online, 7 years archived per policy.
• Encryption: Full disk encryption for all accessible systems; TLS 1.2 minimum (1.3 preferred) for data in transit and admin access.
• Exception register: All exceptions SHALL be recorded with requirement, justification, compensating controls, owner, expiry, review date.
• Prohibitions:

MUST NOT use shared or generic administrative accounts.

MUST NOT leave critical or high vulnerabilities unremediated beyond SLA without approved exception.

MUST NOT deploy servers without CIS baseline (or STIG where mandated) and MFA for admin.

MUST NOT grant exception without recording in exception register with compensating controls and expiry.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this standard and is responsible for its maintenance, interpretation, and coordination with other government standards (including Malawi Government IAM, Network Security, Backup and Recovery, and Incident Response Standards).

System Owner – Accountable for risk acceptance and compliance for servers under their responsibility; approves exception requests within their remit.

Security Officer – Validates that hardening controls meet this standard; governs exceptions; supports incident response and audit.

System Administrator – Implements technical hardening (CIS, STIG, patches, MFA, logging); collects evidence for audit; applies change management for config changes.

Vendor or contractor – Implements hardening on vendor-managed servers in accordance with contract and this standard; submits evidence and supports audits as required.

3.2 Compliance Framework

All servers SHALL comply with the following, in order of precedence. Where controls conflict, the more restrictive requirement applies.

Malawian law. Data Protection Act No. 3 of 2024 (security of processing, breach notification); Electronic Transactions and Cybersecurity Act (2016) (cybersecurity, record-keeping).

CIS Benchmarks Level 1 – Mandatory baseline; target 100% compliance.

NIST SP 800-53 Rev. 5 – Moderate baseline for sensitive government systems; applicable control families (e.g. AC, IA, SC, SI) as categorised.

NIST SP 800-63B – Password and authentication lifecycle (passwords, MFA, session management).

DoD STIGs – Mandatory for internet-facing and classified systems where mandated by government policy.

NIST SP 800-88 – Secure decommissioning and media sanitisation.

3.3 System Categorisation

High Impact: Systems processing classified or highly sensitive government data. CIS Level 1 + NIST baseline + enhanced controls (e.g. shorter session timeout, keystroke capture for privileged sessions, strictest patch timelines). Medium Impact: Systems handling sensitive government or personal data. CIS Level 1 + selected NIST controls; MFA and standard patch timelines. Low Impact: Development, testing, or non-sensitive systems. CIS Level 1 baseline; individual accounts and no shared credentials. Internet-facing systems: CIS Level 1 + enhanced monitoring + applicable STIGs; strictest firewall and logging.

3.4 Safe Exception Process

Exceptions to mandatory hardening requirements (e.g. legacy system unable to support MFA, delayed patch due to vendor constraint) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or service name; requirement(s) from which an exception is sought; justification; compensating controls and timeline for remediation; proposed end date; and sign-off from System Owner and Security Officer.

• Request: The System Owner submits an exception request (government form or template), stating the requirement(s), justification, and proposed compensating controls.
• Documentation: Each exception SHALL document: justification; compensating controls and timeline; risk acceptance by the System Owner and validation by the Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: Exceptions SHALL be reviewed at least quarterly; extensions require re-approval.
• Register: All exceptions SHALL be recorded in an exception register and made available for audit.

4. Authentication and Access Control

4.1 Account Management

Unique individual accounts are required for all administrative access; shared or generic administrative accounts are prohibited. Quarterly account reviews are mandatory; access is revoked immediately upon role change or separation. Account creation and revocation follow the Malawi Government IAM Standards where central identity is used; local accounts on servers are minimised and documented.

4.2 Password and Authentication Policy

Passwords SHALL align with NIST SP 800-63B. Standard systems: Minimum length 15 characters; complexity (uppercase, lowercase, numbers, symbols); screening against known breached credentials where feasible; no forced periodic rotation absent compromise indicators; account lockout (e.g. 5 failures → 15-minute lockout); session timeout (e.g. 15 minutes inactivity). High Impact systems: Minimum length 20 characters; lockout (e.g. 3 failures → 30-minute lockout); session timeout (e.g. 10 minutes inactivity). Passwords SHALL be changed immediately upon suspected or confirmed compromise.

4.3 Multi-Factor Authentication

MFA is mandatory for all administrative access. Approved methods: FIDO2/U2F hardware tokens (preferred), TOTP authenticators, approved push-based authenticators. SMS SHALL NOT be used as primary MFA. MFA enrollment grace period: ≤ 30 days from account creation or policy effective date.

4.4 Privileged Access Management

Just-Enough-Access and Just-In-Time principles are enforced where feasible. Privileged and non-privileged accounts are separate. Privileged session logging is mandatory; keystroke capture is required for High Impact systems. Privileged access is reviewed quarterly per IAM Standards.

5. Operating System Hardening

5.1 Baseline Configuration

Unnecessary services, daemons, and features are disabled; non-essential packages are removed; role-specific security templates are applied. FIPS 140-2/3 is enforced where required by policy. Baseline is documented and managed per Malawi Government Configuration Management Standards; changes follow Change Management.

5.2 File System Security

Separate partitions are used for OS, temporary, variable, and user data where feasible. Temporary filesystems are mounted with noexec, nosuid, nodev (Linux). Mandatory access control (SELinux/AppArmor on Linux) is enforced; least-privilege permissions are applied throughout.

5.3 Patch Management

CVSS 9.0–10.0: Remediation within 15 days. CVSS 7.0–8.9: Within 30 days. CVSS 4.0–6.9: Within 90 days. Zero-day exploits: emergency patching with expedited testing. Compensating controls are documented when timelines cannot be met. Patching follows Malawi Government Vulnerability Management Standards and Change Management where applicable.

6. Network Security (Host)

6.1 Host Network Configuration

Host-based firewall with default-deny policy; explicit allow rules documented and approved. IP forwarding and source routing are disabled unless required for role. Alignment with Malawi Government Network Security Standards (segment placement, perimeter and internal firewalling).

6.2 Service Hardening

All administrative access is encrypted (SSH, RDP with TLS, etc.). Telnet, FTP, SMBv1, SNMP v1/v2c are disabled. Services run with minimal privileges and are bound to required interfaces only. TLS 1.2 minimum (TLS 1.3 preferred) for in-transit data; AEAD cipher suites; weak algorithms (RC4, DES, 3DES, MD5) disabled.

6.3 Time Synchronisation

Authenticated NTP where supported; redundant time sources; accuracy maintained within 100 ms so that logs and certificates are reliable.

7. Logging and Monitoring

Comprehensive audit logging is enabled (system, auth, network, privilege events). Logs are protected from modification and are forwarded to centralised SIEM; minimum retention 90 days online, 7 years archived per policy. Immediate alerts are configured for authentication failures, privilege escalation, and compromise indicators. Logging format and retention align with Malawi Government Logging and Evidence Standards.

8. Encryption

Data at rest: Full disk encryption for all accessible systems; database encryption for sensitive data; keys managed via approved HSM/KMS per Malawi Government Secrets Management and PKI Standards where applicable. Data in transit: TLS 1.2 minimum, TLS 1.3 preferred; AEAD cipher suites; weak algorithms disabled. Backups are encrypted per Malawi Government Backup and Recovery Standards.

9. Platform-Specific Requirements

9.1 Linux Servers

CIS Benchmark compliance is mandatory. SELinux or AppArmor is in enforcing mode; kernel hardening via sysctl as per CIS. SSH is hardened (Protocol 2, key-based auth, strong ciphers); auditd (or equivalent) is configured for system, auth, network, and privilege events.

9.2 Windows Servers

CIS Benchmarks and Microsoft Security Baselines are applied. BitLocker with TPM is mandatory; Defender real-time protection is enabled. LAPS is implemented where local admin accounts are used; PowerShell logging (Module, Script Block, Transcription) is enabled. RDP is hardened with NLA, MFA, TLS 1.2+; Advanced Audit Policy is fully enabled.

10. Operational Security, Vendor Compliance, and Documentation

Operational security: Continuous monitoring and file integrity monitoring; regular vulnerability scanning per Vulnerability Management Standards; encrypted backups with restoration testing per Backup and Recovery Standards; incident response readiness and forensic capability per Incident Response Standards; secure decommissioning per NIST SP 800-88. Vendor compliance: Evidence submission is mandatory; regular assessments and audits; defined remediation timelines. Documentation and reporting: System Security Plans where required; CMDB accuracy; regular compliance reporting; defined evidence retention periods.

11. Endpoint and Mobile Device Hardening

11.1 Workstation and Laptop Hardening

Endpoints (workstations, laptops) running Windows, macOS, or Linux that access government systems or data are configured per security baseline: CIS Endpoint Benchmarks Level 1 as minimum for critical systems. Controls include:

Encryption – Full disk encryption (BitLocker, FileVault, LUKS) is required for endpoints holding government or personal data.

OS hardening – Unnecessary software removed; application install controlled (approved list or central install); automatic updates enabled; screen lock and automatic lock after inactivity (e.g. 15 minutes).

Network and firewall – Host firewall enabled with default-deny; application firewall configured; network segmentation and VPN for remote access.

Patch management – Patches applied per Vulnerable Management Standards; critical/high within 15-30 days.

Antivirus and EDR – Antivirus or Endpoint Detection and Response (EDR) enabled and updated; real-time protection active.

11.2 Mobile Device Management (MDM)

Mobile devices (smartphones, tablets) that access government email or applications must be enrolled in MDM and comply with device policy per Malawi Government Email Standards. MDM enforces:

Device passcode/PIN – Minimum 6 digits or equivalent complexity; automatic lock after inactivity (e.g. 5-10 minutes).

Encryption – Full device encryption enabled.

Compliance enforcement – Devices are periodically evaluated for compliance; non-compliant devices are denied access or prompted to remediate (e.g. apply pending update, disable jailbreak).

Remote wipe – Capability to erase data remotely if device is lost or stolen.

App policy – Where supported, app allow/block lists configured; company apps managed; personal app install restricted on high-risk systems.

MDM Integration: For government-owned mobile devices, IT enrolls devices automatically. For BYOD (if permitted), users self-enroll and accept policy; access to government resources is conditional on compliance. Non-compliant devices are denied email and sensitive application access.

11.3 Lost or Stolen Device Response

When a user reports a mobile device as lost or stolen:

Immediate containment – IT initiates remote lock/wipe via MDM; email access and application sessions are revoked; push credentials are rotated.

Risk assessment – Security Officer assesses data exposure based on device encryption status, last known location, and data classifications handled.

Incident – If sensitive or personal data may be exposed, security incident is opened per Incident Response Standards.

Resolution – Device is not recovered within a defined time (e.g. 24-48 hours), assume data is compromised; all secrets on device (e.g. certificates, oauth tokens) are rotated; user is issued replacement device.

11.4 Endpoint and Mobile Asset Management

When an endpoint or mobile device is decommissioned, reassigned, or returned:

Collection – IT retrieves device; accounts and MDM enrollment are revoked.

Data sanitisation – Device is sanitised per NIST SP 800-88 (clear, purge, or destroy):

• Clear: Overwrite all data using approved tool (e.g. secure erase, multiple passes).
• Purge: Use cryptographic erase where supported (e.g. if device has self-encrypting drive).
• Destroy: Physical destruction if appropriate for classification or age.

Documentation – Sanitisation method, date, and evidence are documented.

Disposal – Devices with residual data are never resold; hardware is recycled via certified e-waste vendor.

Asset inventory – Asset record is updated; disposed devices are marked end-of-life.

11.5 BYOD Policy

On-policy BYOD is permitted for government email and approved applications per Malawi Government Email Standards. Policy:

Enrollment and compliance – Devices must be enrolled in MDM; must maintain current OS and patches; must meet compliance checks (encryption, passcode, no jailbreak).

Access scope – BYOD devices access government email and approved apps only; sensitive data systems may restrict to government-owned devices.

Privacy boundaries – IT can view compliance status and remotely wipe; IT cannot access user's personal data on BYOD unless authorized for incident response.

Support – User is responsible for device health and security; IT provides minimal support (enrollment, wipe, compliance troubleshooting).

Return or offboarding – When user separates, BYOD enrollment is revoked; user is prompted to unenroll themselves; if left enrolled, device is remotely wiped.

12. Decommissioning and Media Sanitization

When infrastructure assets (servers, workstations, storage devices, mobile devices) reach end-of-life or are decommissioned, all data must be securely removed before the hardware is disposed or reassigned. This section defines mandatory sanitization procedures per NIST SP 800-88 and Data Protection Act (2024).

12.1 Sanitization Overview and Compliance Drivers

Secure media sanitization prevents unauthorised recovery of government or personal data from disposed hardware. NIST SP 800-88 defines three sanitization approaches:

Clear (Logical Overwrite): Overwrite all data using software tools (e.g., `shred`, `secure erase`). Effective for most media; must verify overwrite completion.

Purge (Cryptographic Erase): Use the device's built-in cryptographic erase (e.g., `ATA Secure Erase`, self-encrypting drives with key destruction). Faster and more thorough than logical overwrite; requires verification that encryption keys are destroyed.

Destroy (Physical Destruction): Physically dismantle or destroy the media (shredding, incineration, crushing). Required for classified data or when overwrite is unreliable.

Choice of method depends on data classification, media type, and cost. All methods require evidence (date, method, person responsible) for audit and compliance.

12.2 Decommissioning Procedure

When a server, workstation, or storage device is decommissioned:

Procedure:

Identify data and retention – Review what data is on the asset; determine if it must be retained per records schedule, Data Protection Act, or FOI requirements.

Backup if required – If data must be retained, back it up per Backup and Recovery Standards before sanitization.

Revoke access – Revoke user accounts, service principal accounts, and credentials (SSH keys, API tokens, certificates) from the asset. Perform through IAM or configuration management.

Network isolation – Remove the asset from network (disconnect cables or set to isolated network if virtual).

Sanitize media – Apply appropriate sanitization method:

• Clear: Use approved tool (e.g., `shred` on Linux, `cipher /w` on Windows, or vendor-provided secure erase). Overwrite at least once; verify completion and document method and time.
• Purge: Use device's built-in cryptographic erase if available (e.g., `hdparm --security-erase` for self-encrypting drives). Verify that encryption keys are destroyed; document method.
• Destroy: Use certified physical destruction vendor if media cannot be reliably overwritten. Retain certificate of destruction.

Documentation – Record sanitization method, date, person responsible, and evidence (e.g., logs, certificate). Retain for audit (minimum 2 years or per policy).

Hardware disposal – Hardware with properly sanitized media may be resold, recycled, or redeployed. Hardware that cannot be sanitized is physically destroyed via certified vendor.

Asset inventory update – Update CMDB or asset register: mark asset as decommissioned, retired, or destroyed; link to sanitization evidence.

12.3 Sanitization SLA and Criticality

Critical systems (containing classified or sensitive personal data): Sanitization must occur within 5 business days of decommission; purge or destroy method strongly preferred over clear.

High-impact systems (containing government operational data): Sanitization within 10 business days; clear method acceptable if media is verified.

Medium and low impact: Sanitization within 30 days; clear method acceptable.

If device cannot be sanitized before disposal, it must be physically destroyed.

12.4 Platform-Specific Sanitization Guidance

Linux Servers:

Use `shred -vfz -n 3 /path/to/file` or `dd if=/dev/zero of=/dev/sdX bs=1M` to overwrite partitions.

For encrypted disks, ensure encryption keys are destroyed; `cryptsetup close` and securely delete key material.

Windows Servers:

Use `cipher /w` to overwrite free space; confirm via `cipher /c` listing before disposal.

For BitLocker-encrypted disks, suspend BitLocker and verify encryption keys are removed from TPM or escrow.

For SSD, if supported, use vendor's secure erase utility (e.g., Kingston or Intel SSD Toolbox).

Mobile Devices:

Use MDM remote wipe capability (per Section 11.3) if device is still responsive.

For unresponsive devices, use device manufacturer's secure erase tool if available; otherwise, physical destruction.

Cloud-hosted Assets (Virtual Machines, Cloud Storage):

For cloud provider-managed assets (AWS EC2, Azure VMs, GCP instances), rely on provider's data sanitization guarantees at decommission (documented in service agreement).

For customer-managed encryption (e.g., EBS encrypted with customer-managed CMK), delete encryption keys before terminating instance; verify deletion in KMS audit logs.

For cloud storage buckets, delete all objects and the bucket; verify in audit logs.

12.5 Sanitization Evidence and Audit

All sanitization activities are documented and evidence is retained:

• Log or report: Date, system/asset identifier, person who performed sanitization, method (clear/purge/destroy), start and completion time.
• Verification: Screen capture, output log, or certificate showing sanitization completion.
• Retention: Sanitization evidence is retained for a minimum of 2 years and made available for audit (per Data Protection Act and Electronic Transactions and Cybersecurity Act record-keeping).
• Exception: If sanitization is waived (e.g., device physically destroyed before data is overwritten; emergency decommission), exception process is followed (System Owner and Security Officer approval; documented with justification).

13. Verification and Evidence Baseline (Audit-Ready Hardening)

To make this standard auditable, ministries and system administrators SHOULD maintain evidence that, at minimum, demonstrates:

• CIS/STIG: Assessment results; baseline documentation; critical finding remediation or exception.
• MFA and authentication: MFA enforcement config; account review and revocation records.
• Patching: Patch and vulnerability remediation records; exception register where timeline not met.
• Logging and encryption: SIEM forwarding and retention; full disk encryption and TLS config.
• Exception register: All exceptions with requirement, justification, compensating controls, owner, expiry, review date.
• What internal audit checks: (1) Sample of servers for CIS/MFA/logging; (2) patch and exception timeliness; (3) exception register validity.
• Sampling approach: Quarterly sample of servers per ministry; annual review of exception register.
• Escalation path: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

13.1 Compliance Reporting

14. Legal Compliance and Training

14.1 Legal and Related Standards

Data Protection Act (2024): security of processing applies to data on servers, endpoints, and mobile devices; breach notification if device is compromised or data lost/stolen. Electronic Transactions and Cybersecurity Act (2016): cybersecurity and record-keeping. Related standards: Malawi Government IAM Guide; Malawi Government Network Security Guide; Malawi Government Backup and Recovery Guide; Malawi Government Incident Response Guide; Malawi Government Vulnerability Management Guide; Malawi Government Logging and Evidence Guide; Malawi Government Secrets Management Guide; Malawi Government PKI and Certificate Management Guide; Malawi Government Email Guide.

14.2 Training

System administrators and security staff are trained on this standard, on CIS/STIG application, on MFA and patch procedures, and on incident response for server compromise. System owners are aware of categorisation and their responsibilities. Training is refreshed when the standard or tools change.

15. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.8, A.9, A.12, A.13, A.14, A.15
• NIST SP 800-53 Rev. 5 – families CM, AC, SI, SC, PL
• Benchmarks – CIS Server/Workstation Level 1

Refer to `ISO27001_Mapping.md` and `Multi_Framework_Mapping.md` for the complete mapping tables.

16. Appendices

Appendix A: Related Standards

Malawi Government IAM Standards. Malawi Government Network Security Standards. Malawi Government Backup and Recovery Standards. Malawi Government Incident Response Standards. Malawi Government Vulnerability Management Standards. Malawi Government Logging and Evidence Standards. Malawi Government Secrets Management Standards. Malawi Government PKI and Certificate Management Standards. Malawi Government Configuration Management Standards. Malawi Government Change Management Standards.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Hardening: CIS (or STIG) assessment results; baseline configuration documentation; evidence of disabled unnecessary services and host firewall default-deny.
• Authentication: Evidence of MFA for administrative access; password policy configuration; account review and revocation records.
• Patching: Patch and vulnerability remediation records; evidence of critical/high patch within target timelines; compensating control documentation where applicable.
• Logging and encryption: Evidence of SIEM forwarding and retention; full disk encryption and TLS configuration; backup encryption per Backup and Recovery Standards.
• Exceptions and audit: Exception register with requirement, justification, compensating controls, and review/expiry dates; audit trail of changes to hardening config.
• Appendix D: Templates (Minimum)

D.1 Hardening Attestation (Template)

• Server/asset identifier and owner
• System tier (Critical/High/Medium/Low) and internet-facing? (yes/no)
• Baseline applied (CIS/STIG) with version/date
• Exceptions in place (yes/no) and register references
• Sign-off (System Administrator + Security Officer as required)

D.2 CIS/STIG Assessment Summary (Template)

• Tool/method used and assessment date
• Summary of critical/high findings
• Remediation plan (owners + dates)
• Re-assessment date and closure evidence

References

Data Protection Act No. 3 of 2024 (Malawi).

Electronic Transactions and Cybersecurity Act (2016) (Malawi).

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.

NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.

NIST SP 800-61, Computer Security Incident Handling Guide.

NIST SP 800-88, Guidelines for Media Sanitization.

CIS Benchmarks (Linux, Windows).

DoD STIGs (where applicable).

Microsoft Security Baselines.

OpenSSH Security Guidelines.