Building a Company Security Culture

Security is not just a technical problem - it’s an organizational one. Most breaches involve some combination of misconfigured systems, untrained users, inadequate policies, or poor incident response. This note covers the human and process side of security: how organizations assess risk, protect data, train users, respond to incidents, and manage BYOD devices.

---

Risk Assessment

Threat Modeling

Security involves identifying what you’re protecting, who might attack it, and how - then prioritising controls based on likelihood and impact.

Threat model questions:
  1. What are our high-value assets?      (user data, IP, payment info, credentials)
  2. Who are likely threat actors?        (opportunistic bots, insiders, targeted APTs)
  3. What are the attack vectors?         (email, web, physical, supply chain)
  4. What's the impact of compromise?     (financial, reputational, legal)
  5. What controls reduce that risk?      (technical + procedural + physical)

Risk = Likelihood × Impact - focus controls where both are high.

Vulnerability Scanning

Vulnerability scanners enumerate services, check configurations, and match findings against known CVE databases (NVD, vendor advisories).

Scanner	Type	Best for
Nessus	Commercial	Enterprise-scale, compliance reports
OpenVAS	Open source	Self-hosted; full-featured; credentialed scans
Qualys	SaaS	Continuous cloud scanning
Nikto	Web-focused	Quick web server config checks
nmap + scripts	Network	Service discovery + NSE vuln scripts

# Quick network scan with nmap vulnerability scripts
nmap -sV --script vuln 192.168.1.0/24

# Nmap service version detection on a single host
nmap -sV -p 22,80,443,3306,5432 target.example.com

# OpenVAS command-line scan (after setup)
gvm-cli socket --gmp-username admin --gmp-password pass \
  --xml "<create_task><name>Full Scan</name>...config/target IDs...</create_task>"

Note

Credentialed vs uncredentialed scans: Uncredentialed scans see what an external attacker sees - open ports and exposed services. Credentialed scans (with valid OS/application credentials) find internal misconfigurations, outdated packages, and weak permissions invisible from the outside. Run both.

Penetration Testing

Penetration testing goes beyond scanning - it’s active exploitation to verify that defences actually hold.

Phase	What happens
Reconnaissance	Passive (OSINT) + active (port scans) info gathering
Scanning/enumeration	Service versions, share names, usernames, DNS records
Exploitation	Attempt to exploit found vulnerabilities
Post-exploitation	Lateral movement, privilege escalation, data access
Reporting	Findings, severity ratings, remediation steps

Types of engagements:

• Black box - tester has no prior knowledge (simulates external attacker)
• Grey box - tester has some info (e.g., one set of credentials) - most common
• White box - full knowledge of systems (most thorough; used for deep audits)
• Purple team - attackers and defenders collaborate to improve detection

# Metasploit quickstart for authorised testing
msfconsole
use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST <your_ip>
set LPORT 4444
run

# Run with --legal-check equivalent: ALWAYS have written authorisation before testing

Caution

Always get written authorisation. Penetration testing without explicit written permission is illegal in most jurisdictions. “Bug bounty” scope documents, signed statements of work, or formal engagement letters are required.

---

Privacy and Data Handling Policies

Data Classification

Classify data before establishing controls - controls must match the sensitivity of what’s being protected.

Classification	Examples	Typical controls
Public	Marketing materials, press releases	No restrictions
Internal	Employee directory, internal docs	Authenticated access only
Confidential	Business strategy, contracts, source code	Need-to-know + encryption at rest
Restricted	Customer PII, payment card data (PCI), health records (HIPAA)	Strict ACLs + encryption + audit logging + legal compliance

Regulated Data Categories

Regulation	Data type	Key requirement
HIPAA	Protected Health Information (PHI)	Strict access controls, audit trails, breach notification within 60 days
PCI DSS	Payment card data (PANs, CVVs)	No storage of CVV; encrypt PANs; quarterly scans; annual pen test
GDPR	EU personal data	Consent + right to erasure + data minimisation + breach notification in 72h
FISMA	Federal IT data (US gov)	Data must remain on US soil; mandatory security programs
CCPA	California residents’ personal data	Right to know, delete, opt-out of sale

# Search for PCI data patterns in files (grep for card-like patterns)
grep -rE '[0-9]{4}[- ]?[0-9]{4}[- ]?[0-9]{4}[- ]?[0-9]{4}' /var/data/ 2>/dev/null

# Check for SSN-like patterns
grep -rE '[0-9]{3}-[0-9]{2}-[0-9]{4}' /var/data/ 2>/dev/null

Principle of Least Privilege

Users and processes should have access only to what they need - no more.

# Review which users have sudo access on Linux
grep -E '^[^#]' /etc/sudoers /etc/sudoers.d/* 2>/dev/null
getent group sudo wheel

# Audit which users have login shells (should be minimal)
awk -F: '$NF !~ /nologin|false/ { print $1, $NF }' /etc/passwd

# Audit files owned by a specific user
find / -user alice -type f 2>/dev/null

# Find world-writable files (overly permissive)
find /etc /var /usr -type f -perm -o+w 2>/dev/null

Data Access Policy Elements

A good data access policy defines:

• Who can request access (role + justification required)
• What exactly is requested (specific datasets, not broad access)
• Why (linked to specific task or project)
• When access expires (time-boxed; no permanent access to sensitive data)
• How access is provisioned and revoked (automated via IAM where possible)

---

Data Destruction

When devices are decommissioned or data is no longer needed, secure destruction prevents recovery.

Method Selection

Device being reused internally or sold?
  → Use software wiping (NIST 800-88 compliant)

Device going to unknown parties or out of your control?
  → Physical destruction (shredding, degaussing)

High-sensitivity data (classified, regulated)?
  → Physical destruction + certificate of destruction

Large volumes, no staff/capacity?
  → Outsource to certified vendor (NAID AAA certified)

Methods Compared

Method	How it works	Data recoverable?	Device reusable?
Standard format	Erases the filesystem path - not the data	✅ Yes (easily)	Yes
Overwriting / wiping	Overwrites all sectors with zeros (or random data)	Unlikely (with 1+ pass)	Yes
Low-level format	Sector-by-sector zero-fill	Very unlikely	Yes
Degaussing	Strong magnetic field destroys magnetic media	No	No (renders drive inoperable)
Shredding	Industrial shredder reduces to fragments	No	No
Drilling	Holes through platters	Partial (undamaged areas)	No
Incineration	Complete thermal destruction	No	No

# Secure wipe entire disk with shred (Linux) - NIST 800-88 compatible
# WARNING: completely destroys all data - cannot be undone
shred -v -n 3 -z /dev/sdX   # 3 random passes + final zero pass

# NIST 800-88 compliant wipe with nwipe
nwipe --method=gutmann /dev/sdX    # 35-pass Gutmann method
nwipe --method=dod_e /dev/sdX     # DOD 5220.22-M 7-pass (common standard)

# Verify disk is zeroed after wipe
dd if=/dev/sdX bs=512 count=1 | xxd | head  # should show all zeros

Note

SSDs require different handling. Traditional overwriting is unreliable on SSDs due to wear levelling - the controller may write to different physical blocks. Use the manufacturer’s Secure Erase command (hdparm --security-erase) or ATA Secure Erase, or resort to physical destruction for regulated data.

---

Security Training and Culture

Why Culture Matters

Technical controls fail when users route around them. The goal of security culture is making the secure path the easy path - so users don’t have to choose between convenience and security.

Key failure patterns:

• Password complexity rules so onerous that users write passwords on sticky notes
• No clear channel to report suspicious activity → users don’t report
• Security training as a checkbox → users don’t internalise lessons
• “Security is IT’s job” attitude → users feel no ownership

Effective Security Training Elements

Element	Why it works
Short, scenario-based modules	Contextual learning sticks better than abstract rules
Simulated phishing exercises	Hands-on recognition practice; immediate feedback
Clear reporting channels	Low-friction path to report concerns → more reports
Recognising/rewarding good behaviour	Positive reinforcement builds habits
Justifying policies	”Why” makes policies feel reasonable, not arbitrary
Regular refreshers	Threat landscape evolves; people forget

Simulated Phishing Programs

# GoPhish - open-source phishing simulation platform
# Install and run
wget https://github.com/gophish/gophish/releases/download/v0.12.1/gophish-v0.12.1-linux-64bit.zip
unzip gophish-v0.12.1-linux-64bit.zip
./gophish   # Admin UI at https://localhost:3333

# Configure:
#   - Sending profiles (use internal relay or test domain)
#   - Landing pages (capture form submissions - no real data stored)
#   - Email templates (simulate realistic phishing)
#   - User groups (import from CSV/LDAP)

Measure: click rate, credential submission rate, report rate. Trend should be: ↓ click/submit, ↑ report.

Tooling for Users

Reducing friction for users reduces security risk:

Problem                        Solution
─────────────────────────────────────────────────
Many passwords to remember  →  Password manager (Bitwarden, 1Password)
Sharing files with partners →  Company-approved file sharing (not personal email)
Remote work security        →  VPN + endpoint management
Phishing detection          →  Browser warning systems + Safe Links (M365)
Strong 2FA                  →  TOTP app or hardware key (not SMS)

---

Incident Response

The Incident Response Lifecycle

1. PREPARATION      Define IR team, playbooks, communication procedures
                    Ensure logging, monitoring, and alerting are in place

2. DETECTION        IDS/IPS alert, SIEM correlation rule fires, employee report,
                    external notification (threat intel feed, vendor, regulator)

3. ANALYSIS         Determine: Is this a real incident? What systems affected?
                    What data is involved? What is the attack chain?

4. CONTAINMENT      Short-term: isolate affected systems to stop spread
                    Long-term: implement temporary fixes while preparing remediation

5. ERADICATION      Remove malware, close the entry point/vulnerability,
                    reset compromised credentials

6. RECOVERY         Restore systems from known-good backups, verify clean state,
                    monitor closely for signs of re-infection

7. POST-INCIDENT    Document in detail, conduct post-mortem,
                    update playbooks and controls

Containment Strategies

Incident type	Containment approach
Malware infection	Network isolate the host; preserve disk image before cleaning
Compromised credentials	Immediately revoke/reset; check for lateral movement
Data exfiltration	Block exfil destination IPs; audit what was accessed
Ransomware	Isolate immediately; do not pay without legal/executive approval
Insider threat	Revoke access, preserve evidence with HR/Legal involvement
Web application attack	Block attacking IP, disable vulnerable endpoint, patch

# Isolate a Linux host at the network level (emergency containment)
# Block all traffic except from incident response workstation (10.0.0.100)
iptables -I INPUT ! -s 10.0.0.100 -j DROP
iptables -I OUTPUT ! -d 10.0.0.100 -j DROP

# Collect volatile forensic data BEFORE shutdown (order of volatility)
# 1. Running processes
ps auxf > /tmp/ir_processes.txt
# 2. Network connections
ss -tulpan > /tmp/ir_netconn.txt
netstat -nltp >> /tmp/ir_netconn.txt
# 3. Open files
lsof > /tmp/ir_openfiles.txt
# 4. Memory (requires avml or LiME kernel module)
# avml /tmp/memory.lime
# 5. Disk image
dd if=/dev/sda of=/mnt/ir-share/disk.img bs=4M status=progress

# Compute hash for evidence integrity
sha256sum /mnt/ir-share/disk.img > /mnt/ir-share/disk.img.sha256

Chain of Custody

Every piece of forensic evidence must have documented provenance:

For each item of evidence, document:
  - What: description, make/model/serial, file hashes
  - Who:  who collected it, who has handled it (every transfer documented)
  - When: date/time of collection and every transfer
  - Where: where was it found, where is it stored
  - How:  collection method (disk image, physical seizure, log export)

Chain of custody breaks = evidence potentially inadmissible in court or HR proceedings.

Regulated Data in Incidents

If an incident involves regulated data, breach notification timelines apply:

Regulation	Notification to	Deadline
GDPR	Supervisory authority	72 hours of becoming aware
HIPAA	HHS + affected individuals	60 days of discovery
PCI DSS	Card brands + acquiring bank	Immediately upon discovery
State breach laws	Affected residents	Varies (30–90 days typically)

Caution

Legal and PR teams must be involved immediately in significant incidents. IT must not communicate externally about breaches without legal review - premature or inaccurate disclosures create additional liability. Document everything.

---

BYOD - Bring Your Own Device

The BYOD Security Challenge

BYOD saves costs but transfers device control from IT to the employee. IT can no longer guarantee:

• Timely OS patching
• Absence of personal malware or jailbreaking
• Separation of corporate and personal data
• Control over what apps are installed

Threat Vectors

Threat	How it manifests
Lost/stolen device	Corporate data on personal device; no remote wipe capability
Jailbroken/rooted device	Bypass OS security controls; any app can access any data
Personal malware	Malware installed via personal app store infects corporate data
Insecure Wi-Fi	MITM on open hotspot; corporate traffic intercepted
Data leakage	Employee copies corporate data to personal cloud (iCloud, Dropbox personal)
Data portability	Employee leaves, takes company data on personal device

BYOD Policy and Technical Controls

MDM (Mobile Device Management) is the enforcement mechanism for BYOD policies:

MDM Capabilities:
  Enrolment:    Device registers with MDM server (Intune, Jamf, MobileIron)
  Profiles:     Push Wi-Fi/VPN configs, email settings, certificates
  Policies:     Enforce screen lock PIN, min OS version, encryption
  Apps:         Push required apps; restrict certain apps; containerise work apps
  Remote wipe:  Selective wipe (corporate data only) or Full wipe
  Compliance:   Block non-compliant devices from accessing corporate resources

# Microsoft Intune (via Graph API) - check device compliance
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?filter=complianceState eq 'noncompliant'" \
  --headers "Authorization=Bearer $TOKEN"

# List non-compliant devices and trigger wipe
# (Done via Intune portal or Graph API wipeDevice action)

Key policy elements:

Policy	Requirement
Minimum OS version	Devices below threshold blocked from corporate access
Screen lock	Required; PIN/biometric; max 5 min timeout
Encryption	Full-device encryption required
MDM enrolment	Required before accessing corporate email/VPN
Jailbreak/root detection	Jailbroken devices auto-blocked
Acceptable use	Corporate data not copied to personal cloud storage
Exit procedure	Corporate data wiped on termination/resignation

Tip

Prefer containerisation over full MDM for BYOD. Full MDM on personal devices can give IT access to personal data, which creates privacy concerns and resistance. App containerisation (via Microsoft Intune App Protection Policies or a managed work profile on Android) keeps corporate data isolated to a separate, IT-managed container - without touching personal apps or data.

---

Security Infrastructure Design - Reference

A concise reference for the key decisions when designing security infrastructure for a small-to-medium organisation:

Area	Minimum viable	Better
Authentication	Strong passwords + MFA (TOTP)	LDAP/AD + RADIUS + MFA; hardware keys for admins
External web	HTTPS (TLS 1.2+), WAF	HTTPS + WAF + DDoS protection + CSP headers
Internal web	HTTPS + auth required	HTTPS + SSO + VLAN isolation
Remote access	VPN (WireGuard/OpenVPN)	VPN + MFA + certificate auth + network segmentation
Firewall	Implicit deny + allow-list	Stateful + IDS/IPS + application awareness
Wi-Fi	WPA2-PSK (long passphrase)	802.1X / EAP-TLS with client certs
Endpoint	AV + disk encryption (BitLocker/FileVault)	AV + EDR + disk encryption + binary allowlisting + MDM
Monitoring	Centralised syslog	SIEM with correlation rules + alerting
Incident response	Written IR plan + designated contact	IR plan + retainer + tabletop exercises + documented runbooks