Ubuntu 22.04 STIG

Option A: Azure Portal

• Open the Azure Marketplace and search for "Ubuntu 22.04 LTS STIG-Hardened SecureAnyCloud".
• Select the image and click Create.
• Configure the basics:
• Subscription: Select your Azure subscription.
• Resource Group: Create a new group or select an existing one.
• Virtual Machine Name: Enter a name for your VM.
• Region: Select your preferred Azure region.
• Size: Standard_B2s is recommended.
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• Click Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:ubuntu-22-04-stig:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-ubuntu-22-04-stig-vm \
  --image sac1647283583153:ubuntu-22-04-stig:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Run these commands on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-ubuntu-22-04-stig-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks for one, your client is not offering the key you supplied at create time. The STIG sshd hardening tightens session timeouts and auth-try limits (see Step 7). The connection model is the same as on every other SecureAnyCloud image: key only, injected by Azure at first boot.

The raw DISA STIG profile includes rules (sudo_remove_nopasswd, sudo_remove_no_authenticate) that remove the NOPASSWD tag from every sudoers entry, so that sudo always demands re-authentication. This build deliberately excludes those rules from automated remediation. The reason is simple.

This image, like every SecureAnyCloud image, has no password on any account. Access is by SSH key only. If the NOPASSWD-removal rules had been applied, sudo would ask for a password that does not exist. That would permanently lock you out of root on the account Azure creates for you, with no recovery path and no console password. That is not re-authentication. It removes administrative access outright.

Confirm it yourself:

sudo -n true && echo "sudo works, no password prompt" grep -A1 'User rules for' /etc/sudoers.d/90-cloud-init-users

Expected output:

sudo works, no password prompt
# User rules for azureuser azureuser ALL=(ALL) NOPASSWD:ALL

The full list of excluded rules ships on the image:

cat /usr/share/sac/stig/skip-rules.txt

Expected output:

xccdf_org.ssgproject.content_rule_grub2_password xccdf_org.ssgproject.content_rule_grub2_uefi_password xccdf_org.ssgproject.content_rule_is_fips_mode_enabled xccdf_org.ssgproject.content_rule_sudo_remove_no_authenticate xccdf_org.ssgproject.content_rule_sudo_remove_nopasswd

The exclusions fall into three groups, five rules in total:

Rule group Why it is excluded

sudo_remove_nopasswd, sudo_remove_no_authenticate Would strip passwordless sudo from your SSH-key-authenticated account, as described above. There is no password anywhere on this image to re-authenticate with.

grub2_password, grub2_uefi_password The upstream remediation script for these rules reads a boot loader password interactively from a terminal. In an automated build it would hang indefinitely instead of failing cleanly. Skipping it does not affect normal boot. GRUB password protection guards editing boot entries at the console, not booting the default entry.

is_fips_mode_enabled Full FIPS 140 kernel mode. Enabling it correctly needs a reboot-and-verify cycle that this build does not perform. On Ubuntu, the certified FIPS kernel and crypto packages are also an Ubuntu Pro entitlement. FIPS is not enabled on this image.

None of these exclusions requires an Ubuntu Pro subscription. They are applied with the free, open source SCAP Security Guide tailoring mechanism described in Step 10.

The build-time compliance report ships on the image. It is generated after a reboot, so it reflects a real running boot, not a snapshot taken mid-build:

cat /var/log/sac/stig/build-remediation-score.txt ls -la /var/log/sac/stig/ oscap info --profiles /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml | grep -i stig

Expected output. The exact score varies from build to build as upstream STIG content and the base image evolve. This is the measurement from this build, not a fixed target:

96.7 build-remediation-report.html build-remediation-results.xml build-remediation-score.txt xccdf_org.ssgproject.content_profile_stig:Canonical Ubuntu 22.04 LTS Security Technical Implementation Guide (STIG) V2R7

Copy the HTML report to your workstation to read it:

echo "from your workstation: scp azureuser@<vm-ip>:/var/log/sac/stig/build-remediation-report.html ."

What the remaining gap is made of. This build measures 96.7% across 213 rules that were actually checked (pass or fail). The STIG profile selects 230 rules in total. The rest are informational, manual-review-only or not applicable, and they do not count for or against the score. Every rule that does not pass falls into one of these buckets:

Bucket Rules Why it does not pass

Single-disk architecture partition_for_dev_shm Wants /dev/shm on its own mount with dedicated options. This is a single-OS-disk cloud image, so there is nowhere for a second mount to live. The rule is not applicable here and is not a defect.

The excluded rule groups from Step 3 (cascading checks only) No separately failing rule beyond the five explicitly skipped. They show notselected, not fail, and are not counted in the 213.

Firewall not configured at the OS level set_ufw_default_rule, ufw_rules_for_open_ports ufw ships installed but inactive by design. The Azure Network Security Group is the network boundary for this image (see Step 9). Enable and configure ufw yourself if you also want OS-level filtering.

Environment-specific, no domain configured sssd_certification_path_trust_anchor, sssd_offline_cred_expiration These need a site-specific answer: your own certificate trust anchors and credential-caching policy for a real LDAP or AD domain. This image has no domain join.

Content limitation, verified false negative package_prelink_removed, chronyd_run_as_chrony_user Checked directly on this build: prelink is not installed, and chronyd runs as the _chrony system user (the Debian and Ubuntu naming convention, _chrony rather than chrony). Both controls are satisfied. The automated OVAL check in this content release does not correctly detect the Debian-family naming and state on Ubuntu 22.04. These rules still count in the score.

Read the HTML report for the full rule-by-rule detail.

cat /etc/os-release uname -rm sudo apt-get update -qq sudo apt-get -s -o APT::Get::Always-Include-Phased-Updates=true dist-upgrade | grep -c '^Inst ' || echo 0 test -f /var/run/reboot-required && echo "reboot required" || echo "no reboot required"

Expected output:

PRETTY_NAME="Ubuntu 22.04.5 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.5 LTS (Jammy Jellyfish)" ID=ubuntu ID_LIKE=debian UBUNTU_CODENAME=jammy 6.8.0-1064-azure x86_64 0 no reboot required

APT::Get::Always-Include-Phased-Updates=true matters. Ubuntu's phased update rollout can otherwise hold back a subset of updates, including security-relevant ones, on an individual machine without reporting a failure. This image is built and verified with phased updates always included. A result of 0 therefore means fully patched.

systemctl is-enabled unattended-upgrades.service
systemctl is-enabled apt-daily.timer
systemctl is-enabled apt-daily-upgrade.timer grep -E '^(APT::Periodic)' /etc/apt/apt.conf.d/20auto-upgrades

Expected output:

enabled enabled enabled APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";

unattended-upgrades applies security updates automatically on your VM, as a stock Ubuntu image does. The STIG hardening does not disable this.

Confirm AppArmor, the root account, the SSH policy and the STIG audit kernel argument:

aa-status --enabled && echo "AppArmor enabled" systemctl is-enabled apparmor.service
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|maxauthtries|clientaliveinterval)' grep -o 'audit=1' /proc/cmdline

Expected output:

AppArmor enabled enabled root L 02/09/2026 0 99999 7 -1 permitrootlogin without-password passwordauthentication no kbdinteractiveauthentication no maxauthtries 6 clientaliveinterval 600 audit=1

audit=1 is also written into /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT, not only applied to the current boot entry. Ubuntu's update-grub reads this file on every kernel update, so the setting carries forward with no separate persistence step.

grep CMDLINE_LINUX_DEFAULT /etc/default/grub

STIG hardening must not break the cloud-init and Azure agent paths that provision your VM. Confirm that both still work:

systemctl is-active walinuxagent 2>/dev/null || systemctl is-active waagent
systemctl is-enabled walinuxagent 2>/dev/null || systemctl is-enabled waagent cloud-init --version cloud-init status --long df -h / free -h

free -h reports 0B of swap by design. Azure manages swap on the ephemeral resource disk through waagent, not on the OS disk. A swap file baked into a Marketplace image fails certification.

This image does not enable ufw by default. It ships installed but inactive. The Azure Network Security Group is already the network boundary for this VM. A second default-deny layer that failed to permit SSH would lock customers out, as the sudo issue in Step 3 would have. Confirm what is listening:

ss -tlnH | awk '{print $1, $4}'
sudo postconf -h inet_interfaces

Expected output:

tcp 127.0.0.1:25 tcp 0.0.0.0:22 tcp 127.0.0.53%lo:53 tcp [::1]:25 tcp [::]:22 loopback-only

The only externally bound listener is SSH on port 22 (IPv4 and IPv6). Postfix (local mail for cron and system tooling) and the systemd-resolved DNS stub are both loopback-only. Postfix ships on the base Ubuntu image bound to all interfaces. This build restricts it to loopback-only, so it cannot accept mail from the internet and local mail delivery for system tools keeps working.

To add OS-level filtering on top of the NSG, run:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Review these commands before you run them. Enabling ufw without first allowing SSH can lock you out, as an NSG misconfiguration would. Keep an existing SSH session open and test access from a second session before you disconnect.

The scanner and policy content ship on the image, so you do not depend on SecureAnyCloud's own report. Validate the datastream and check the timer:

oscap ds sds-validate /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml && echo "datastream valid" systemctl list-timers stig-verify.timer --no-legend test -f /var/lib/sac/data/stig-firstboot.done && echo "firstboot completed"

stig-verify.timer runs an audit-only re-scan of your own instance a few minutes after every boot, and weekly after that. It writes a fresh report to /var/log/sac/stig/verify-report.html, verify-results.xml and verify-score.txt. It never remediates, so a scheduled job cannot silently change your running configuration.

To run a full scan by hand, use the same tailored profile the build used. The jammy oscap predates --skip-rule, so this image ships an XCCDF tailoring file that excludes the five rules from Step 3:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/sac/stig/tailoring.xml \
  --profile xccdf_sac_profile_stig_automation_safe \
  --results /tmp/my-scan-results.xml --report /tmp/my-scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml echo "exit code: $? (0 = every rule passed, 2 = some rules failed -- normal, 1 = a genuine scanner error)"

To scan against the raw, untailored DISA STIG profile instead, run the command below. It also evaluates the five rules from Step 3, so read what they do before you run any generated fixes:

sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig \
  --results /tmp/my-raw-results.xml --report /tmp/my-raw-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml echo "exit code: $? (0 = every rule passed, 2 = some rules failed -- normal, especially against the raw profile, 1 = a genuine scanner error)"

The upstream bash and Ansible remediation content for this profile ships alongside the scanner. You can review it and apply further hardening deliberately:

ls /usr/share/sac/stig/remediation/bash | head -5

Review additional fixes before you apply them. They can disable services, tighten sshd further or change mount options. Treat the block below as a reference, not as something to paste and run:

sudo oscap xccdf generate fix --profile xccdf_org.ssgproject.content_profile_stig \
  --fix-type bash /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml > /tmp/my-fixes.sh less /tmp/my-fixes.sh
# review every line before running anything