Cybersecurity For The Stack
A typical cloud web application is usually architected similar to the diagram below where there's a load balancer, virtual machines running webservers & a database tier. If the web application is hosted on-prem it usually follows a similar architectural model. We have to defend what we know & we know our stack, so let's defend it.
Defend The Stack
Defending the stack requires that you defend & protect every layer of the software stack. Let's look at cybersecurity defenses for each of those layers in this example & cover what you should implement.
1 Browser - User requests URL https://3kill.com causing DNS lookup & Request Index Page
Secure DNS -> If you control the users, you should ensure that they are using Secure DNS which is DNS over TLS or DNS over HTTPS to protect against DNS poisoning / spoofing attacks.
DNSSEC -> You should be using DNSSEC on your domain name registrar to protect against DNS poisoning / spoofing attacks.
2 Request -> Firewall / NACL / Security Group For Inspection
Firewall -> You should be using DDoS protection.
Firewall / NACL / Security Group -> In most situations, the Firewall / NACL / Security Groups should only allow inbound traffic ports 80 & 443. Insecure http traffic on port 80 should be redirected to port 443.
Geo Blocking -> You should geo block internet traffic from global undesirable regions that shouldn't be using your application.
DNS Sink Holing -> You should be using DNS Sink Holing to prevent malicious requests from within your own infrastructure.
Data Exfiltration -> You should be monitoring outbound ports and limiting data sent.
3 Request -> Load Balancer / WAF For Inspection
Web Application Firewall (WAF) -> You should be using a Web Application Firewall (WAF) to inspect https traffic for known exploits.
SSL / TLS 1.3 -> You should be using TLS 1.3 for faster & more secure connectivity.
4 Request -> Web Server - Website Index Page Returned
Security Headers -> You should be implementing the OWASP Top Ten Security Headers in your webserver to prevent known exploits.
Mask Errors -> You should mask all application error messages. A failure shouldn't expose software used in your underlying infrastructure.
Mask Application Details -> You should mask as many application details as possible such as webserver version, language used, database, etc.
5 Request -> User requests login page & logs in
Form Validation -> You should be validating all form fields on the front-end collection & back-end on submission.
Password Length -> Password length is more important than complexity. We recommend at least 15 characters in length.
Password Hashes -> User password should be hashed & verified against stored hash using Argon2id.
Multi-Factor Authentication (MFA) -> All users should be using MFA. Many users utilize the same passwords on multiple websites & there's a good chance it is already leaked. MFA will help secure access to sensitive data.
MFA Hardware Keys -> All admin users should be using hardware MFA keys because they are un-phishable.
CSRF Tokens -> All application requests should use cross site request forgery (CSRF) tokens for every request.
6 Website -> Dashboard Page Returned
Encrypt Data -> Any sensitive data should be encrypted using AES 256-bit GCM or XChaCha20-Poly1305 & should be stored at rest encrypted as well.
Encryption Keys -> Data encryption keys should be stored separately from encrypted data & should themselves be encrypted using the Data Encrypt Key / Key Encryption Key model.
User Access -> Application user access should be restricted based on security level.
User Access -> Out dated or unused user accounts should be deleted.
7 Webserver -> Virtual Machines
Anti-Virus -> All servers or virtual machines should be running anti-virus & endpoint protection software.
Isolated Subnets -> All servers or virtual machines should be running on their own subnet / vlan.
Restrict Access -> All servers or virtual machines should restrict ssh / rdp access.
SIEM -> All server logs should be sent to a Security Information & Event Management (SIEM) system for review.
Restrict IAM Roles -> All servers or virtual machines should have restricted security roles to reduce the blast radius.
FIPS -> All servers or virtual machines should be using strict FIPS 140-2 secure alogrithms.
Patching -> All servers or virtual machines should be patched with security updates on a regular basis.
8 Databases
Isolated Subnets -> All databases should be running on their own subnet / vlan.
Restrict Access -> All databases should restrict access as tightly as possible.
Data Encryption -> All sensitive data should be encrypted at rest.
Patching -> All databases should be patched with security updates on a regular basis.
9 Source Code
Secure Repository -> All source code should be stored in secure repositories.
Source Code Security Scanning -> All source code should be routinely scanned for security vunerabilities.
10 Passwords & Security Keys
Encryption Key Management -> All passwords & security keys used by the application should be stored in a key management system & rotated on a regular basis.
Default Passwords -> All default passwords should be changed to strong passwords.
11 Backups
Encrypted Backups -> All backups should be encrypted and stored encrypted as well with limited admin access.
Secure Backup Vault -> All backups should be stored in time protected backup vaults that do not allow for deletion by anyone.
12 Security Posture - Zero Trust
Cybersecurity Training -> Staff should be trained on phishing & social engineering.
Multi-Factor Authentication (MFA) -> Staff should use MFA on all accounts, preferably physical hardware keys.
Physical Security -> Physical building security & door access should be restricted.
Building Security -> Physical building security cameras should be monitored.
Zero Trust Security -> Use a zero trust security model.