Run a Linux server like an admin: users, permissions, patching, services, SSH, firewall and logs, then virtual machines, containers, disk encryption, SELinux and scheduled jobs, each turned into a control you can prove.
120 min 500 XPSkills: Linux users and sudo, Permissions, SSH hardening, Linux logging, Virtualization and containers, Disk encryption
What you'll be able to do
›Navigate the Linux filesystem and inspect ownership and permissions
›Manage users, groups, and sudo access using least privilege
›Harden SSH access and configure host firewall rules from a baseline
›Review Linux packages, systemd services, logs, scheduled jobs, and audit evidence
›Secure a KVM host, containers, disk encryption, and SELinux, and tell snapshots from backups
Brief
Imagine taking responsibility for a shop whose locks have not been checked for a year. Priya faces that problem with web01.
She is the shop's first information technology (IT) and security worker. web01 is the Linux server running the shop.
Her manager needs it made safer before an auditor arrives in three weeks. An auditor checks whether claims have supporting evidence.
Follow Priya through files, accounts, access, updates, running programs, network connections, firewall rules and logs. Logs record system activity.
For each area, learn what to inspect, what a good result looks like and what proof to keep.
You do not need to memorise every command. You need to know what to look at, what good looks like, and what proof to keep.
1. Find your way around: the filesystem tree
Think of one building with labelled rooms. Linux arranges files in one filesystem tree, starting at /, called root.
Other disks also appear within this tree. Unlike Windows drive letters such as C: and D:, these paths share one starting point.
A path names a file or folder location. /etc holds configuration, the settings controlling the server. /home holds personal folders.
/var/log holds activity records. /usr holds installed programs. /tmp is shared temporary workspace. /root is the administrator's private folder.
/boot holds startup files, including the kernel, the core software managing the machine.
Someone who can change /etc files may change server behaviour. Someone who can erase /var/log may hide their actions.
To answer who can change configuration, first inspect who can write to /etc.
One tree, many rooms. /etc and /var/log are the two an auditor cares about first.
2. Users, groups and sudo
Think of staff badges and team membership. Linux gives people and programs user accounts, then uses groups to share access.
Each account has a user identifier (UID), a number. UID 0 is root, the account with full administrative power.
/etc/passwd lists accounts, their UIDs, home folders and shells. A shell is a program that accepts commands. Anyone can read this file.
/etc/shadow stores password hashes, one-way calculated values used to check passwords. It should be restricted, commonly to root and the shadow group.
If everyone can read hashes, attackers can copy them and guess passwords offline, without contacting the server. That is a serious finding.
Do not use root for daily logins. Approved administrators sign in with named accounts and use sudo for authorised administrative commands.
sudo means substitute user do. Access may come through the sudo group, or wheel on some systems, according to configured rules.
This supports logging actions against named people. Check logging is configured. id alice shows Alice's group membership.
If Alice belongs to the sudo group and has administrative access, she should appear on the approved administrator list.
id shows group membership; ls -l proves /etc/shadow is not readable by everyone.
3. Permissions in depth
Think of a cupboard with separate keys for its owner, a team and everyone else. Linux permissions specify what each can do.
Run ls -l to inspect them. In -rwxr-x---, the first character gives the type: - for a file, d for a directory.
A directory is a folder. The next three groups of characters describe owner, group and others, in that order.
r means read, w means write and x means execute a program. For directories, x permits traversal, or passing through them.
Directory read lists names. Directory write permits changing entries when combined with appropriate traversal rights. A - means that permission is absent.
Numeric modes use read = 4, write = 2 and execute = 1. Add each group separately.
rwx gives 7, r-x gives 5 and --- gives 0. Thus rwxr-x--- is 750. chmod changes these permission modes.
A private configuration file often uses 640: owner reads and writes, group reads, others have no access. Ownership must also be correct.
Special bits add behaviour. Set user ID (setuid) makes an executable run with its owner's effective identity, subject to system restrictions.
A root-owned setuid program can grant powerful operations. Keep these programs on a short reviewed list. s appears in the owner execute position.
Set group ID (setgid) similarly changes an executable's effective group. On directories, it makes new entries inherit the directory's group.
The sticky bit restricts deletion in shared directories such as /tmp. Normally, only the file owner, directory owner or root can delete entries.
t marks the sticky bit. umask removes permission bits from defaults for newly created files and directories.
With typical creation defaults, umask 027 produces files with 640 and directories with 750. Programs can request more restrictive permissions.
World-writable means others have write permission. Run find /etc -perm -o+w to list matching paths. A healthy baseline expects no matches.
Add 4, 2 and 1 per part to turn letters into the number admins type.
4. Packages and patching
Think of buying sealed supplies from a trusted shop. Linux repositories provide software packages with checks that help detect tampering.
A repository is a software source. A package bundles software for installation. Trusted repositories use signed metadata and, on some systems, signed packages.
Debian and Ubuntu use apt. Red Hat style systems use dnf. These package managers check trusted signatures as part of software verification.
apt update refreshes available package lists. dnf check-update checks available updates. Neither command installs the updates.
apt upgrade or dnf upgrade installs available new versions under the tool's rules. Refreshing a list alone does not patch the server.
Test updates on a test server before production, the system serving real users. Record package versions before and after installation.
Normally reboot after a kernel update to run the new kernel. Unattended upgrades can apply security fixes automatically within your patching schedule.
A monthly patching claim needs evidence. Keep dated /var/log/apt/history.log or dnf history records and a report of security updates still waiting.
Update the list, test, upgrade, reboot if needed, and keep the record.
5. Services and processes with systemd
Think of shop equipment running behind the scenes. A service provides background functionality, such as a web server or remote login.
A process is a running program. On many Linux systems, systemd manages services and their processes. Some services run continuously; others do not.
Secure Shell (SSH) provides encrypted remote login. systemctl status name shows service state. systemctl start name and systemctl stop name change it now.
systemctl enable name and systemctl disable name control normal startup at boot. Disabling does not necessarily stop a running service.
Run systemctl list-units --type=service --state=running to list running services. Investigate any service with no explained purpose.
Stop and disable unnecessary services after checking dependencies. Hardening means reducing unnecessary access and features that attackers could misuse.
systemd stores activity in its journal, a log collection. journalctl -u sshd shows entries for the sshd service. Service names vary.
Priya sees two failed root password attempts from outside. Alice then signs in normally using a key from the office network.
systemctl tells you what runs; journalctl tells you what it has been doing.
6. SSH hardening
Think of remote login as a front door that strangers can also reach. SSH protects the connection, but needs careful settings.
The server settings are in /etc/ssh/sshd_config. PermitRootLogin no blocks direct root login. Administrators use named accounts and sudo instead.
PasswordAuthentication no disables password authentication. PubkeyAuthentication yes enables public key authentication, which proves possession of a private key.
Review other authentication methods too when enforcing keys only. MaxAuthTries 3 limits authentication attempts per connection, not across all connections.
X Window System version 11 (X11) forwarding carries graphical application traffic. X11Forwarding no disables it where it is unnecessary.
A key pair resembles a padlock and its matching key. Put the public part in ~/.ssh/authorized_keys on the server.
Keep the private part on your laptop, ideally protected by a passphrase. The server verifies possession without receiving the private key.
After changes, run sshd -t to check configuration syntax. Restart the service only after resolving errors. Keep an existing session open.
Test a second login before closing the original session. A mistake can otherwise lock you out.
For evidence, run sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'. This prints selected effective settings. Account-specific rules may need additional checks.
Five lines in sshd_config turn an open door into a locked one.
7. Host firewall basics
Think of a door attendant checking an entry list. A host firewall filters network traffic on the server itself.
Ubuntu offers Uncomplicated Firewall (ufw). Modern Linux commonly uses nftables for underlying packet filtering, checking pieces of network traffic against rules.
Default deny blocks incoming traffic unless an allow rule permits it. A port is a numbered network service endpoint.
web01 needs public web traffic on port 443. Allow SSH on port 22 only from the office network, 10.0.4.0/24.
The /24 describes a network range sharing its first 24 address bits. Keep database port 3306 unreachable from the internet.
Use ufw default deny incoming, then ufw allow 443/tcp. Transmission Control Protocol (TCP) provides ordered, reliable network connections.
Add ufw allow from 10.0.4.0/24 to any port 22 before ufw enable. Confirm your management connection will remain allowed.
Run ufw status verbose. Keep its current rules and default policy as evidence, rather than relying on an old change request.
Default deny, then allow only what the server exists to do.
8. Logging and auditing
Think of a diary whose pages must survive a break-in. Logs record events, but local copies alone are vulnerable.
Login and sudo records commonly go to /var/log/auth.log or /var/log/secure on Red Hat style systems. Configuration varies.
Services also write to the systemd journal. auditd, the audit service, records selected events such as account-file changes or privileged program execution.
An attacker with root access can erase local records. Forward logs promptly to a central log store that ordinary server administrators cannot alter.
Retention means how long records are kept. Follow your policy, often one year in this example.
Keep clocks aligned with Network Time Protocol (NTP), which synchronises time over a network. timedatectl helps check synchronisation status.
An eight-minute clock error can prevent matching server events with firewall events. Alert on repeated failed logins and new sudo group members.
Ship logs off the server, keep time in sync, and alert on the few events that matter.
9. A hardening baseline mapped to controls
Think of a safety checklist used for every shop branch. A baseline lists the required settings for each type of server.
Center for Internet Security (CIS) benchmarks are public security configuration recommendations. Adapt them to your business and operational needs.
Governance, risk and compliance (GRC) connects technical settings to oversight and obligations. Map each baseline requirement to a control and supporting evidence.
A control is a safeguard addressing risk. Disabling root SSH login supports privileged access control. Prove the effective setting with sshd -T.
Security updates within 14 days support patch management. Use package history as evidence. No world-writable /etc paths supports configuration management.
Use find output to support that check. Repeat checks on a schedule, not only once a year.
A failed check becomes a finding, a recorded problem with an owner and due date. Priya finds late patches and world-writable configuration.
These red rows identify work early. Attach evidence and track corrections rather than treating the table alone as a failed audit.
Each baseline line maps to a control and a command that proves it.
Part 2, 10. Virtualization basics
Think of one big house split into flats. Each flat has its own door and kitchen, but they share the same walls and foundations.
A virtual machine (VM) is a whole computer made of software. Many VMs can run on one physical server, called the host.
A hypervisor is the software that splits the host into VMs and keeps them apart. A type 1 hypervisor runs straight on the hardware.
A type 2 hypervisor runs as an app on a normal desktop system. Servers use type 1; laptops for testing often use type 2.
On Linux, the Kernel-based Virtual Machine (KVM) turns the kernel itself into a type 1 hypervisor. QEMU (Quick Emulator) supplies the virtual hardware.
A container is lighter. It packages an app and its files but shares the host's kernel instead of carrying its own.
That makes containers quick to start, but the walls are thinner. A flaw in the shared kernel can affect every container on it.
Priya moves web01 into a VM on a new host called host01. Now host01 is the most important machine: whoever controls it controls every VM.
VMs each bring their own system; containers share one kernel.
Part 2, 11. Managing virtual machines
Think of a photo of your desk before you tidy it. You can put things back, but the photo is stored in the same room.
virsh is the command line tool for KVM. virsh list --all shows every VM and whether it is running or shut off.
A snapshot saves a VM's state at one moment so you can roll back, for example before patching. virsh snapshot-list web01 lists them.
A snapshot usually sits on the same storage as the VM. If that storage fails, the VM and its snapshots are lost together.
So a snapshot is not a backup. A backup is a copy on separate storage, and a restore test proves it works.
Old snapshots also slow the VM down and keep old data around. Set a short life, such as seven days, and delete them after.
A template is a clean, hardened VM image used to build new VMs. Patch and review the template, or every new VM starts out weak.
Shut-off VMs still need patching. test01 may be off today and online next month with year-old software.
Snapshots are a quick undo, not a copy you can rely on after a disaster.
Part 2, 12. Containers on Linux
Think of office cubicles. Each worker has a private desk, but they share one building, one power supply and one front door.
Linux builds containers from two kernel features. Namespaces decide what a container can see, such as its own processes and network.
Control groups (cgroups) decide how much it can use, such as central processing unit (CPU) time and memory. Without limits, one container can starve the rest.
An image is the packaged template a container starts from. Use images from trusted sources, keep them small and rebuild them when patches arrive.
Rootless containers run under a normal user instead of root. If an attacker escapes, they land as that user, not as the host's administrator.
The --privileged option removes most of the walls and hands the container the host's devices. Treat it as giving the app root on host01.
A read-only root filesystem stops an attacker from quietly changing the app's files inside the container.
For evidence, list running containers with their options, such as podman ps and podman inspect. Docker uses the same ideas with docker in front.
Namespaces and cgroups are the walls. --privileged knocks them down.
Part 2, 13. Storage and disk encryption
Think of a filing cabinet with drawers you can resize, locked with one key. Linux storage is built in similar layers.
A physical disk, such as /dev/sda, is split into partitions. sda1 might hold /boot and sda2 the rest.
Logical Volume Manager (LVM) pools disk space into a volume group, then carves logical volumes from it. You can grow a volume without rebuilding the disk.
Linux Unified Key Setup (LUKS) encrypts a partition. Without the key, the data looks like random noise, even if the disk is stolen.
Mounting attaches a volume to a folder in the tree, such as /srv. /etc/fstab lists what to mount at boot; /etc/crypttab lists what to unlock.
Mount options add safety. noexec on /tmp stops programs from running there, and nodev and nosuid remove other risky tricks.
For evidence, lsblk -f shows the layers and marks encrypted ones as crypto_LUKS. cryptsetup status shows an unlocked volume.
Old disks must be wiped or destroyed before they leave. Keep a dated record of how each one was disposed of.
Disk, partition, lock, pool, volume, folder: each layer has its own check.
Part 2, 14. Scheduled jobs: cron and timers
Think of an alarm clock someone else set in your house. It goes off every night, and you never noticed it was there.
cron runs commands on a timetable. Each user can have a crontab, a table of jobs, and the system has more in /etc/cron.d.
*/5 * * * * means every five minutes. The five fields are minute, hour, day of month, month and day of week.
systemd timers do the same job in a newer way. systemctl list-timers shows each timer, when it runs next and which service it starts.
Attackers love scheduled jobs. A job that downloads and runs a script every few minutes brings them back even after you clean up.
Review every user's crontab, /etc/cron.d and the timers list. Any job without a known owner and purpose needs an answer.
Limit who may create cron jobs with /etc/cron.allow. Send job output to the logs so you can see what ran.
The red line is the one nobody can explain. That is your finding.
Part 2, 15. Mandatory access control: SELinux and AppArmor
Think of a hotel key card. Even the manager's card only opens the doors it was programmed for.
Normal permissions let a file's owner decide who gets in. Mandatory access control adds rules from the system that even root programs must follow.
Security-Enhanced Linux (SELinux) is used on Red Hat style systems. AppArmor does a similar job on Ubuntu and Debian.
Both have modes. Enforcing blocks and logs. Permissive only logs. Disabled does nothing at all.
A web server that is broken into should still be unable to read /etc/shadow. Enforcing mode stops it; permissive mode only writes a note.
getenforce prints the SELinux mode. aa-status shows which AppArmor profiles are in enforce mode.
People switch to permissive to fix a broken app, then forget to switch back. Check the mode on a schedule and keep the output.
Only enforcing actually stops anything. Permissive is a warning light.
Part 2, 16. Kernel and boot settings
Think of the building's main fuse box. A few switches there change how safe every room is.
sysctl reads and sets kernel settings. Saved settings go in files under /etc/sysctl.d so they survive a reboot.
net.ipv4.ip_forward = 0 stops a server from acting as a router unless that is its job. accept_redirects = 0 ignores sneaky route changes.
kernel.kptr_restrict = 2 hides kernel memory addresses that attackers use to plan attacks.
Kernel modules are add-ons, such as a driver for Universal Serial Bus (USB) storage. Block ones you do not need in /etc/modprobe.d.
The bootloader starts the kernel. A GRand Unified Bootloader (GRUB) password stops someone at the console from booting into a root shell.
For evidence, print the live values with sysctl and compare them with the baseline, not only with the saved file.
Live values first, saved files second: the kernel only obeys what is loaded.
Part 2, 17. Central identity, time and logs
Think of a company with one front desk for badges, one clock on the wall and one safe for the visitor book.
With many servers, local accounts get out of hand. Joining a central directory gives each person one account that can be switched off in one place.
Tools such as SSSD (System Security Services Daemon) or realmd join Linux to a directory. Leavers then lose access to every server at once.
chrony keeps the clock in line with trusted time sources using Network Time Protocol (NTP). chronyc tracking shows how far off the clock is.
rsyslog or journald forward logs to the central store. Check that the forwarder runs and that recent events arrive on the other side.
These three services support many controls at once: access removal, reliable timelines and evidence that survives a break-in.
One directory, one clock, one log store for every server.
Part 2, 18. Collect the evidence with one script
Think of a pilot's pre-flight checklist. The same checks, in the same order, every time.
Priya writes a read-only script that runs her baseline checks and saves the output with the date and server name.
It prints sshd -T settings, ufw status, getenforce, lsblk -f, pending updates and the timers list. It changes nothing.
She saves the output and records a hash, a fingerprint that changes if anyone edits the file.
A scheduler runs it weekly on every server. The auditor can rerun it and get the same kind of result.
Failed lines become findings with an owner and a due date. The next run shows whether they were fixed.
Repeatable, read-only and fingerprinted: evidence an auditor can trust.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The shadow anyone can read
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
Priya runs ls -l /etc/shadow and sees -rw-r--r--. A colleague says this is fine because the passwords inside are hashed. She wants to set it back to owner read and write, group read, others nothing.
Term bank, not all of these are right
othersowner640644
1.1Which group of users can currently read the file but should not? (one word)
1.2What three-digit number should she use with chmod? (a number)
Task 2: Updated but not upgraded
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
A ticket says "web01 patched, ran apt update". The scanner still shows a critical kernel flaw. Priya learns nobody installed anything, and even after installing, the old kernel would still be running.
Term bank, not all of these are right
apt upgraderebootapt updaterestart sshd
2.1Which apt command actually installs the new versions? (two words)
2.2What must happen after a kernel update for it to take effect? (one word)
Task 3: Knock knock, it's root
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
The journal shows hundreds of Failed password for root lines from addresses all over the world. sshd_config still says PermitRootLogin yes and PasswordAuthentication yes. Admins already have key pairs.
Term bank, not all of these are right
nopublic keysyeslonger passwords
3.1What value should PermitRootLogin be set to? (one word)
3.2What do admins use instead of passwords to sign in? (two words)
Task 4: The open database
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
ufw status verbose shows Default: allow (incoming) and the database port is reachable from the internet. The server only needs to serve web pages to everyone and SSH to the office.
Term bank, not all of these are right
deny3306allow443
4.1What should the default incoming policy be? (one word)
4.2Which port number should be closed to the internet? (a number)
Task 5: The diary that went missing
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
After a break-in, Priya finds /var/log/auth.log has been emptied. Logs were only kept on web01. Its clock was also eight minutes behind the firewall's, so even the firewall timeline does not line up.
Term bank, not all of these are right
central log storentplocal backup folderdns
5.1Where should logs be sent so an attacker on the server cannot erase them? (three words)
5.2Which time sync protocol keeps server clocks aligned? (one word)
Task 6: The snapshot that was the backup
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
host01's disk fails. Every virtual machine snapshot was stored on that same disk, and the ticket says "backups: daily snapshots". Nothing can be brought back. Nobody had ever tried bringing a snapshot back on another machine either.
Term bank, not all of these are right
storagerestore testsnapshotchecksum
6.1A real backup must be copied to separate what? (one word)
6.2Which check proves a backup can actually be used? (two words)
Task 7: The container with no walls
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
A monitoring container on host01 was started with an option that gives it every device and kernel power. An attacker who broke into the app inside it read files on the host. Another container ate all the memory and froze the other apps.
Term bank, not all of these are right
--privilegedcgroupsnamespaces--rm
7.1Which start option removed the container's isolation? (one word)
7.2Which kernel feature limits a container's CPU and memory? (one word)
Task 8: Logged but not stopped
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
The baseline says SELinux is on, and the audit log shows hundreds of denied entries for the web server. Yet the web server read files it should never touch. A colleague says the logs prove the control works.
Term bank, not all of these are right
enforcinggetenforcepermissivesestatus-off
8.1Which SELinux mode actually blocks the access? (one word)
8.2Which command prints the current SELinux mode? (one word)
Task 9: The job nobody scheduled
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
Every five minutes web01 downloads and runs a script from an unknown address. It runs as the web server's account, www-data. The service list looks clean, so Priya checks the scheduled jobs instead.
Term bank, not all of these are right
crontimerservicesocket
9.1Which tool's table holds per-user scheduled jobs on Linux? (one word)
9.2Which systemd unit type also runs jobs on a schedule? (one word)
Task 10: The disk that left the building
Scenario sim+50 XP
Read the brief and answer both questions.
Incident brief
An old disk from host01 was sent for recycling and later sold online. The customer database on it was readable by anyone. Priya wants every new data disk encrypted and mounted automatically at boot.
Term bank, not all of these are right
luks/etc/fstabgpg/etc/hosts
10.1Which Linux disk encryption format should she use? (one word)
10.2Which file lists the filesystems to mount at boot? (a path)
Labs
150 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Write web01's agreed baseline before changing the server. Use YAML Ain't Markup Language (YAML), a structured text format. Use booleans, true or false values, for switches. Use numbers for counts and ports.
A colleague suggests leaving password login on "just in case". The requirements say keys only, so do not follow that advice.
Agreed requirements for web01
Direct root login over SSH: not allowed.
Password login over SSH: not allowed. Public key login: required.
Maximum login attempts per connection: 3.
Firewall default for incoming traffic: deny.
Allowed ports: 443 for everyone, 22 only from 10.0.4.0/24.
/etc/shadow mode: 640.
Priya's colleague prepared six statements for the auditor. Accept only the ones that are true and backed by the evidence described. Reject the rest and pick the single root problem.
Reason codes: weak-permission means a file or folder is open to the wrong people. Not-applied means a change was claimed but never really took effect. Wrong-evidence means the proof does not show what is claimed. Log-risk means logs could be lost or erased.
Verdicts are accept or reject. Every rejection needs one reason code from: weak-permission | not-applied | wrong-evidence | log-risk.
Statements for the auditor
LX-1 | /etc/shadow is -rw-r--r--, which is fine because the passwords are hashed.
LX-2 | Patching is done: the ticket shows apt update ran on Monday. No upgrade or reboot is recorded.
LX-3 | Root login is disabled: sshd -T prints permitrootlogin no.
LX-4 | The firewall is safe: the change request from last year says default deny. No current ufw status output is attached.
LX-5 | Logs are kept for one year in /var/log on web01 only.
LX-6 | find /etc -perm -o+w returned no files on today's scheduled run, and the output is attached with a timestamp.
Priya now runs web01 as a virtual machine on host01, and a few small apps run in containers. Write host01's baseline as YAML before she changes anything.
A developer asks to keep one container privileged "because it is easier". The requirements say no privileged containers, so leave that out of the baseline.
Agreed requirements for host01
Containers: must run rootless. Privileged containers: not allowed.
Container root filesystem: read-only.
Virtual machine snapshots: deleted after 7 days. Snapshots never count as backups.
Backups: copied to separate storage, with a restore test on record.
Data disk encryption: LUKS.
SELinux mode: enforcing.
Scheduled jobs reviewed every month: cron and timers.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Checks
Rootless, unprivileged, read-only containers
Short-lived snapshots, not counted as backups
Backups on separate storage with a restore test
Encrypt the data disk
Keep SELinux enforcing
Review both kinds of scheduled job
Next on your path · IT Fundamentals
Windows Administration and Security
Look after Windows like an admin: registry, UAC, Active Directory, Group Policy, NTFS, updates, PowerShell, Defender, BitLocker and event logs, then Hyper-V, virtualization based security, tiered admin, remote access and application control, each tied to a control you can prove.
