How to use this checklist
Run the commands on each in-scope server and keep the output with the date and the hostname: an assessor treats a dated record as evidence and an undated one as an anecdote. Where a command shows a gap, the fix belongs in your remediation plan, and the next run of the same command is the proof that it was closed.
The checklist covers the technical half of a NESA pack only. Which of the risk-based controls apply to you depends on your risk assessment, and the management families, M1 to M6, are policy and process work that no command can show. The NESA overview explains who has to comply, how the standard is organised and how a programme runs.
A NESA technical checklist for a Linux server
These are the twenty controls in the v2.1 catalog that a Linux server can produce evidence for: the ones SecAI maps to automated or partial evidence from the host. A further sixteen receive supporting evidence only and are left out here. Each entry quotes the requirement, gives read-only commands that show where a server stands today, and says what SecAI records continuously and how far that goes. None of them changes configuration or installed software; the package-manager checks only refresh their package lists so the answer is current. Most need sudo, because what they read is visible only to root.
T1.2.1 Inventory of Information and other Associated Assets
- Why
- Priority P1, always applicable. The standard: "The entity shall maintain an inventory list of all its information assets." For a server that means the machine, its operating system, the software installed on it and the addresses it holds, kept current.
- Verify
- Debian and Ubuntu
hostnamectl ip -brief address dpkg -l | grep -c '^ii'Rocky Linux and AlmaLinuxhostnamectl ip -brief address rpm -qa | wc -lThe last line counts installed packages; drop the count to get the list itself. An inventory is evidence only while it is current, so the date it was taken matters as much as what it contains. - How SecAI sees drift
- Partial coverage. System, operating system and network inventory is collected continuously for every monitored server, and installed software is inventoried from the package manager. The control covers information assets in general, which is broader than the systems SecAI sees.
T3.1.1 Configuration Management
- Why
- Priority P1, always applicable. The standard: "The entity shall develop recommended configuration settings for common information technology products." For a Linux server that means a written baseline, your own or a published benchmark, and evidence that each server matches it. The hardening guide lists a baseline setting by setting, each with the command that checks it.
- Verify
- Any distribution
sudo sshd -T | grep -E "^(x11forwarding|maxauthtries|allowtcpforwarding|permitemptypasswords) "sshd -T prints the settings the SSH daemon is actually using after every include file is read, which is what to compare with the baseline, rather than the file you remember editing. - How SecAI sees drift
- Partial coverage. Secure configuration is observed continuously on each server: SSH settings, root login, password authentication and permissions. SecAI observes configuration; it does not own or enforce your baseline.
T3.1.6 Controls Against Malware
- Why
- Priority P1, always applicable. The standard: "The entity shall protect its information assets from malware." On a Linux server the malware that matters in practice is a web shell in a site's files, a miner started from a temporary directory, and anything hiding itself from the tools you would use to find it.
- Verify
- Any distribution
cat /etc/ld.so.preload 2>/dev/null sudo ls -la /tmp /var/tmp /dev/shm/etc/ld.so.preload normally does not exist. A library listed there is loaded into every dynamically linked program, which is a common way to hide. An executable in one of the world-writable temporary directories deserves an answer to who put it there. - How SecAI sees drift
- Partial coverage. Web shell candidates in web-served directories are found by content rules and screened by AI, processes running from the world-writable temporary directories are flagged whether or not their file has been deleted, and hidden processes, an ld.so.preload entry, new kernel modules and immutable system files are reported. SecAI is not a general-purpose antivirus and does not scan arbitrary files on demand.
T3.1.7 Information Backup
- Why
- Priority P1, always applicable. The standard: "The entity shall backup copies of its information and software." The evidence an assessor accepts is a backup that runs on a schedule and a restore that was actually tested.
- Verify
- Any distribution
systemctl list-timers --all sudo crontab -l ls /etc/cron.d /etc/cron.dailyA backup tool that is installed but attached to no timer or cron entry is not a backup. Neither command can show that a restore works; only a restore test can. - How SecAI sees drift
- Partial coverage. The agent reports whether a backup job is scheduled on the host, which tool provides it and how its last run ended, and a tool attached to no schedule is reported as such. Whether the backup restores, is complete and is held off-site cannot be seen from the host and needs a restore test.
T3.2.2 Logging
- Why
- Priority P1, always applicable. The standard: "The entity shall produce, store, protect and analyze logs that record activities, exceptions, faults and other relevant events." On a server the first question is whether the logs survive a reboot at all.
- Verify
- Any distribution
ls -d /var/log/journal journalctl --disk-usage grep -hE "^(Storage|SystemMaxUse|MaxRetentionSec)=" /etc/systemd/journald.conf /etc/systemd/journald.conf.d/*.conf 2>/dev/nullIf /var/log/journal does not exist and Storage is not set to persistent, the journal is kept in memory and lost at every reboot. That is the default on Rocky Linux and AlmaLinux, where rsyslog, if installed, keeps its own files under /var/log. Retention is whatever SystemMaxUse and MaxRetentionSec allow, so set the figure your policy names. - How SecAI sees drift
- Partial coverage. Security-relevant events are collected from each host and kept in the platform. How long logs are kept on the host, and whether they can be altered there, is not verified and needs its own evidence.
T3.2.3 Monitoring System Use
- Why
- Priority P1, always applicable. The standard: "The entity shall monitor networks, systems and applications for anomalous behavior and shall take appropriate actions to evaluate potential information security incidents." An assessor wants two things: monitoring on every in-scope server, and evidence that someone acts on what it finds. The list of in-scope servers set against the servers actually reporting is the evidence; any gap between the two is a finding.
- How SecAI sees drift
- Automated evidence. Whether each in-scope server is reporting, and when it last reported, is recorded continuously, and every detected event is recorded with its severity, server and time.
T3.2.4 Clock Synchronization
- Why
- Priority P3, applicable based on risk. The standard: "The entity shall synchronize clocks of all relevant information systems with an agreed accurate time source." Without it, timestamps from two servers cannot be put on one timeline during an incident.
- Verify
- Any distribution
timedatectl chronyc sources -v # where chrony keeps the time timedatectl timesync-status # where systemd-timesyncd does"System clock synchronized: yes" and "NTP service: active" are the two lines to show. The sources should be the time source your organisation agreed, not whatever the image shipped with. - How SecAI sees drift
- Partial coverage. The agent reports whether each server's clock is synchronised, which NTP service provides it and its configured sources. It does not verify that changing the time is restricted to authorised staff.
T3.3.2 Management of Technical Vulnerabilities
- Why
- Priority P1, always applicable. The standard: "The entity shall obtain, evaluate and act upon information about technical vulnerabilities of information systems being used." The evidence is what is outstanding on each server, and a record that it was dealt with in the time your policy sets.
- Verify
- Debian and Ubuntu
sudo apt update apt list --upgradable [ -f /var/run/reboot-required ] && echo "reboot required"An empty list means nothing is pending. A pending reboot means a fixed kernel or library is installed but not yet running. The reboot-required file is written by a hook that ships with unattended-upgrades (on Ubuntu, also with update-notifier-common); without them, nothing records a pending reboot.Rocky Linux and AlmaLinuxsudo dnf check-update --security sudo needs-restarting -rcheck-update exits with 100 when security updates are available and 0 when there are none. needs-restarting comes with yum-utils, which a minimal installation does not include. - How SecAI sees drift
- Automated evidence. Every installed package is matched against published vulnerability data every 12 hours, for each machine, by severity.
T4.1.1 Network Controls
- Why
- Priority P1, always applicable. The standard: "The entity shall ensure that all networks and network devices are adequately managed, controlled, and protected." On the server itself that is the host firewall: present, active, and actually filtering.
- Verify
- Debian and Ubuntu
sudo ufw status verbose # if ufw manages the firewall sudo nft list ruleset # what the kernel is enforcingAn active firewall with no rules that drop anything is a firewall in name only, and nft list ruleset is where that shows.Rocky Linux and AlmaLinuxsudo firewall-cmd --state sudo firewall-cmd --list-allSeveral official cloud images of Rocky Linux and AlmaLinux are built without firewalld, so on a cloud server the provider firewall may be the only filter. SecAI does not see the provider firewall. - How SecAI sees drift
- Partial coverage. The presence and state of host firewall tooling is observed, including a firewall that is active but filters nothing. SYN floods, connection exhaustion, UDP floods, scanners and HTTP floods detected at the host count as supporting evidence.
T4.1.2 Security of Network Services
- Why
- Priority P2, applicable based on risk. The standard: "The entity shall identify the security features, service levels, and management requirements of all network services and include these requirements in any network services agreement, whether these services are provided in-house or outsourced." On a server that starts with what is listening, and why.
- Verify
- Any distribution
sudo ss -tulpnEvery line is a service accepting connections, with the process behind it. Anything bound to 0.0.0.0 or [::] answers on every network the server is attached to unless a firewall stops it. - How SecAI sees drift
- Partial coverage. Services bound to network ports are inventoried continuously, which shows what is exposed. The configuration of the services themselves is not assessed.
T5.2.1 Identity Management
- Why
- Priority P1, always applicable. The standard: "The entity shall manage the full lifecycle of the identities." On a server: every account that can log in belongs to a named person or a documented service, and accounts of people who have left are gone.
- Verify
- Any distribution
getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}'Lists every account with a login shell: name, user ID and shell. Each one should match a person or a documented purpose. - How SecAI sees drift
- Partial coverage. Local accounts and group membership are inventoried, and changes to passwd, group and shadow are detected. Approving the lifecycle itself remains a process control.
T5.2.2 Access Rights
- Why
- Priority P1, always applicable. The standard: "The entity shall implement a formal access control procedure to manage the provision, modification, and removal of access rights to information and other associated assets." The procedure is yours to write. On a server, its footprint is the account list and its history: who was added, who was removed, and when.
- Verify
- Debian and Ubuntu
sudo grep -hE 'useradd|userdel|usermod' /var/log/auth.log* | tail -n 50Every account added, removed or changed, with a date. Each line should match a request in your access procedure.Rocky Linux and AlmaLinuxsudo journalctl _COMM=useradd _COMM=userdel _COMM=usermod --no-pager | tail -n 50 - How SecAI sees drift
- Partial coverage. The local account inventory of every server is observed and each change to it is recorded with a timestamp, which is the evidence that provisioning and removal happened and when. Whether each change was requested and approved is the procedure's own record, which SecAI cannot see.
T5.2.3 Privileged Access Rights
- Why
- Priority P1, always applicable. The standard: "The entity shall restrict and control the allocation and use of privileged access rights." On a Linux server that is sudo: who holds it, through which group or file, and on what conditions.
- Verify
- Debian and Ubuntu
getent group sudo sudo grep -rhvE '^[[:space:]]*(#|$)' /etc/sudoers /etc/sudoers.d/Rocky Linux and AlmaLinuxgetent group wheel sudo grep -rhvE '^[[:space:]]*(#|$)' /etc/sudoers /etc/sudoers.d/The second command prints every rule that is not a comment. Each line granting ALL should name a person or a group you can account for, and a NOPASSWD line deserves a written reason. - How SecAI sees drift
- Partial coverage. sudoers configuration, setuid binaries and file capabilities are observed, and every change to them is reported.
T5.3.1 Secure Authentication
- Why
- Priority P1, always applicable. The standard: "The entity shall implement secure authentication technologies and procedures." For SSH the expectation is keys rather than passwords, and no direct root login.
- Verify
- Any distribution
sudo sshd -T | grep -E "^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|pubkeyauthentication) ""passwordauthentication no" and "permitrootlogin no" (or "prohibit-password") are what an assessor expects to see for remote administration. - How SecAI sees drift
- Partial coverage. Failed and successful SSH authentication is recorded with source address and method, and the SSH settings for passwords and root login are observed. Multi-factor authentication is not reliably visible from the host and is marked manual.
T5.3.3 Remote Access
- Why
- Priority P1, always applicable. The standard: "The entity shall use appropriate authentication methods to control access of remote users." The evidence is who connected, from where, and how.
- Verify
- Any distribution
sudo journalctl --since "7 days ago" | grep -E "sshd(-session)?\[[0-9]+\]: Accepted"Each line names the account, the source address and the method, publickey or password. From OpenSSH 9.8 the session process logs as sshd-session, which is why the pattern matches both names. - How SecAI sees drift
- Partial coverage. Remote access over SSH is recorded with source and method, and the remote-access configuration on the host is observed. Access through anything outside the monitored servers, such as a VPN concentrator, is not.
T5.3.4 Use of privileged utility programs
- Why
- Priority P4, applicable based on risk. The standard: "The entity shall restrict and control the use of utility programs that might be capable of overriding system and application controls." On Linux those are setuid and setgid binaries, and binaries carrying file capabilities.
- Verify
- Any distribution
sudo find / -xdev \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null sudo getcap -r / 2>/dev/nullCompare the list with what your packages install; anything else needs an owner and a reason. -xdev keeps find on the root filesystem, so repeat it for other mounted filesystems. getcap is in libcap2-bin on Debian and Ubuntu and in libcap on Rocky Linux and AlmaLinux. - How SecAI sees drift
- Partial coverage. setuid and setgid binaries and file capabilities are inventoried, and changes to them are reported.
T8.1.2 Information Security Event Reporting
- Why
- Priority P1, always applicable. The standard: "The entity shall provide a mechanism for employees, contractors, and third parties to report observed or suspected information security events through appropriate channels in a timely manner." Most of this is a human reporting channel. The technical half is that what the servers detect is recorded where a person will see it.
- How SecAI sees drift
- Automated evidence. Detected incidents are recorded with severity, affected server and time, which is the technical half of event reporting.
T8.2.5 Information Security Incident Documentation
- Why
- Priority P2, always applicable. The standard: "The entity shall document all information security incidents." An assessor wants a dated record for each incident: what was seen, on which system, and what was done about it.
- How SecAI sees drift
- Automated evidence. Incidents are documented with severity, server and time, and every action taken, automatic address blocks included, is recorded with its outcome and time.
T8.2.7 Collection of Evidence
- Why
- Priority P3, applicable based on risk. The standard: "The entity shall establish and implement procedures for the identification, collection, acquisition, and preservation of evidence related to information security events." The procedure is yours to write. The server's part is that the record of what happened still exists when you need it, which is why the logging entry above matters here too.
- How SecAI sees drift
- Partial coverage. Incident history is retained and can be exported, and file integrity events give dated technical evidence of what changed. Forensic soundness, chain of custody and preservation are process controls SecAI does not perform.
T9.1.1 ICT readiness for business continuity
- Why
- Priority P2, always applicable. The standard: "ICT readiness shall be planned, implemented, maintained, and tested based on business continuity objectives and ICT continuity requirements." The plan, its objectives and its tests are yours. The technical core an assessor looks for on a server is a backup that exists, runs on a schedule and has been restored at least once.
- Verify
- Any distribution
systemctl list-timers --all sudo crontab -l ls /etc/cron.d /etc/cron.dailyThe same check as Information Backup above: a backup tool with no timer or cron entry is not readiness. Keep the date and outcome of your last restore test with the plan. - How SecAI sees drift
- Partial coverage. The agent reports whether a backup job is scheduled on each server, which tool provides it and how its last run ended. The continuity plan, recovery objectives and restore tests are documents and exercises a host agent cannot observe.
NESA compliance: the overviewThe full hardening baselineHow CVE matching worksPrivileged access monitoring
What the checklist cannot show
Twenty controls is the whole of what a Linux server can evidence, not the whole of NESA. Sixteen more receive supporting evidence only, and the rest depend on documents, approvals, training records, contracts, physical security or a restore test, none of which a host can observe. SecAI reports those as manual verification required or out of scope, and keeps the manual ones in its coverage figure rather than dropping them.