Data Security

Scope

What this is: Protecting data through encryption, secure storage, and access controls.

Competition relevance: Infrastructure hardening, from national stage up. Tasks include encrypting disks, databases, and securing sensitive files.

Why it matters: Data protection prevents information disclosure. Critical for compliance and risk mitigation.

WSOS 2026 alignment: This topic directly supports Section 5: Secure systems protection and defence (implementing encryption to protect confidential data) and Section 4: Secure systems operation and maintenance (managing encryption keys and encrypted storage systems).

Competition area: Core to the infrastructure hardening area, where you implement encryption at rest for databases, file systems, and backups to prevent unauthorised data access.

Offline competence: Use man gpg, man cryptsetup, and database documentation in /usr/share/doc. Encryption tools (GPG, LUKS, OpenSSL) have extensive offline documentation accessible via man pages. Test encryption/decryption locally without network access.

---

Competency Matrix

Level	Expectation
Regional	Set file permissions on sensitive files. Basic understanding of encryption concepts.
National	Implement database encryption at rest. Encrypt sensitive files. Secure key storage.
Squad/Team Selection	Full disk encryption. Encrypted backups. Key rotation procedures.
International	Hardware security modules (HSMs). Encryption performance tuning. Key escrow procedures.

---

Technical Content

Encryption at Rest

File encryption (GPG):

# Encrypt file
gpg --symmetric --cipher-algo AES256 sensitive.txt
# Creates sensitive.txt.gpg

# Decrypt
gpg --decrypt sensitive.txt.gpg > sensitive.txt

Directory encryption (eCryptfs):

# Install
apt install ecryptfs-utils

# Encrypt directory
mount -t ecryptfs /path/to/source /path/to/mount
# Follow prompts for passphrase and cipher

# Auto-mount on boot (add to /etc/fstab)
/path/to/source /path/to/mount ecryptfs defaults 0 0

Full disk encryption (LUKS):

# Encrypt partition (DESTRUCTIVE - wipes data)
cryptsetup luksFormat /dev/sdb1

# Open encrypted partition
cryptsetup luksOpen /dev/sdb1 encrypted_disk

# Create filesystem
mkfs.ext4 /dev/mapper/encrypted_disk

# Mount
mount /dev/mapper/encrypted_disk /mnt/secure

Competition context: Disk encryption usually already configured. Focus on file/directory encryption for specific data.

---

Database Encryption

MySQL/MariaDB encryption at rest:

-- Enable encryption plugin
INSTALL PLUGIN file_key_management SONAME 'file_key_management.so';

-- Configure in my.cnf
[mariadb]
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile
file_key_management_encryption_algorithm = AES_CBC
innodb_encrypt_tables = ON
innodb_encrypt_log = ON

-- Create encrypted table
CREATE TABLE sensitive_data (
    id INT PRIMARY KEY,
    data VARCHAR(255)
) ENCRYPTED=YES;

PostgreSQL encryption:

-- Use pgcrypto extension
CREATE EXTENSION pgcrypto;

-- Encrypt column data
INSERT INTO users (username, password)
VALUES ('alice', crypt('mypassword', gen_salt('bf')));

-- Verify password
SELECT * FROM users
WHERE username='alice'
AND password = crypt('mypassword', password);

Competition context: Database encryption tasks usually specify which tables/columns to encrypt. Follow requirements exactly.

---

Secure Key Management

Key storage best practices:

• Never hardcode keys in source code
• Store keys in separate config files with restricted permissions (600)
• Use environment variables for application keys
• Rotate keys periodically

Example: Secure key file:

# Create key file
openssl rand -base64 32 > /etc/app/encryption.key

# Restrict permissions
chmod 600 /etc/app/encryption.key
chown appuser:appuser /etc/app/encryption.key

# Load key in application
KEY=$(cat /etc/app/encryption.key)

Environment variables (systemd service):

/etc/systemd/system/myapp.service

[Service]
Environment="ENCRYPTION_KEY=base64encodedkey"
ExecStart=/usr/bin/myapp

---

Backup Encryption

Encrypted backups with tar and GPG:

# Create encrypted backup
tar czf - /important/data | gpg --symmetric --cipher-algo AES256 > backup.tar.gz.gpg

# Restore
gpg --decrypt backup.tar.gz.gpg | tar xzf -

Automated encrypted backups:

backup-encrypt.sh

#!/bin/bash
DATE=$(date +%Y%m%d)
tar czf - /var/www | gpg --symmetric --cipher-algo AES256 --passphrase-file /root/.backup_passphrase > /backups/www-$DATE.tar.gz.gpg

---

Data Loss Prevention

Prevent sensitive data in logs:

# Python example: Redact sensitive data
import re
import logging

class SensitiveDataFilter(logging.Filter):
    def filter(self, record):
        # Redact credit card numbers
        record.msg = re.sub(r'\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b', '[REDACTED]', record.msg)
        # Redact passwords
        record.msg = re.sub(r'password[=:]\s*\S+', 'password=[REDACTED]', record.msg, flags=re.IGNORECASE)
        return True

logger = logging.getLogger()
logger.addFilter(SensitiveDataFilter())

File permissions audit:

# Find world-readable sensitive files
find /etc /var -type f \( -name "*pass*" -o -name "*key*" -o -name "*secret*" \) -perm -004 2>/dev/null

# Fix permissions
chmod 600 /etc/app/database.conf

---

Competition Strategy & Marking

What gets marked:

• Files encrypted correctly (can decrypt and read)
• Database encryption enabled (SHOW VARIABLES output)
• Key files have correct permissions (ls -l screenshot)
• Encrypted backups created successfully

Evidence and reporting requirements:

• Screenshot of encrypted file showing .gpg extension and unreadable content (cat or hexdump)
• Successful decryption test proving encryption works (gpg --decrypt output)
• Database configuration file showing encryption parameters enabled
• SHOW VARIABLES LIKE '%encrypt%' output for MySQL/MariaDB
• ls -l output showing 600 permissions on key files with correct ownership
• Encrypted backup creation command history and resulting file
• Test restore from encrypted backup proving data integrity
• Documentation of encryption passphrases (securely stored for competition duration)
• Written explanation of encryption algorithm used and key length
• Clear naming: database_encryption_enabled.png, keyfile_permissions_600.png

Time allocation:

• File encryption: 10 minutes
• Database encryption: 15-20 minutes
• Key management setup: 10 minutes

Time-boxed drill suggestion: 45-minute data encryption sprint: Given a database server and sensitive files, encrypt specific files with GPG (AES256), enable database encryption at rest for specified tables, create encryption key file with correct permissions (600, root-only access), create an encrypted backup of a directory, test decryption of both file and backup, and document all steps with screenshots showing encrypted state and successful decryption.

---

False Flags / Wrong Paths

Common Traps

Losing decryption keys If you lose the passphrase/key, encrypted data is unrecoverable. Document passphrases securely during competition.

Performance impact Database encryption can slow queries. Test app functionality after enabling encryption.

Wrong encryption scope Task may specify encrypting specific tables, not entire database. Read requirements carefully.

---

Practice Checklist

• Can encrypt files with GPG
• Can configure database encryption (MySQL/PostgreSQL)
• Can set correct permissions on key files (600)
• Can create encrypted backups
• Understand key storage best practices
• Can decrypt encrypted data (verify encryption works)
• Can identify sensitive data in logs and redact it

---

References

Primary references:

• WSOS 2026: the sections this page supports are listed under Scope
• Competition stage roadmap: See ../../00-roadmaps/ for module-specific guidance

Related topics in this knowledge base:

• Cross-reference related topics as appropriate

External resources (for offline preparation):

• Tool documentation: man pages, —help flags, /usr/share/doc
• Maintain offline copies of key references and tool documentation