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. The goal is to defend our data and to prevent it from being stolen or compromised. Our stack & all components of that stack are what allows access to the our data. In order to protect our data, we have to defend our stack, so let's look at ways to do that.



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. There are additional hardening measures that can be utilized, but you should be implementing these as a minimum.



1 Browser - User Hits https://3kill.com


Causes A DNS Lookup & Index Page Request


Secure DNS -> For your internal 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 Network -> Web Index Page Request


The request should go through your firewall, NACL and 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


Request should be inspected by a Web Application Firewall (WAF)


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


The webserver returns the /index page


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. There is no legitimate reason to provide hackers with additional information that could be used against you.





5 Request -> User requests login page


User requests the 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. It is the most secure hashing algorithm.

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


The user is logged in & gets the website dashboard page


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 -> Machines


Security measures for physical or virtual machines running web servers


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


Security measures for 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.

Connectivity -> All databases should use TLS / SSL 1.3 for connectivity.





9 Application Integration / Inter Connectivity


Security measures for inter application connectivity


API Access -> Use an API Gateway to centralize traffic rules like rate limiting & blocking malicious clients.

API Access -> All API requests should use TLS & strong API keys, preferably using an OAuth Server.

Direct Access -> All direct access such as cronjobs should run using least privilege accounts & should log all activity. Credentials should not be hard coded.





10 Source Code


Source code security measures


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.




11 Passwords & Security Keys


Security for passwords & 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.





12 Backups


Backup security measures


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.

Backup Restore Testing -> All backups should be tested on a regular basis to ensure restore works properly.




13 Security Posture - Zero Trust


Don't Trust Anyone


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.