Part One
Network Security Architecture
Traditional Perimeter Defense and the Crunchy Shell
The idea of "crunchy shell" comes from a 1990 paper by Bill Cheswick, where he described how AT&T’s Bell Labs protected its systems from the Morris Worm. While many networks were affected, Bell Labs wasn’t, thanks to their strong perimeter defenses provided by an application-level security gateway.
For years, security experts focused on protecting the outer layer, but now there's more attention on the weak inner areas.
What about That Soft Chewy Center?
Cheswick's analogy focused on strong outer security ("crunchy shell") to protect weaker internal systems ("chewy center"). But now, relying only on perimeter defenses is unrealistic due to client-side attacks, insider threats, and the rise of cloud and mobile workforces, which make having a clear boundary difficult.
While the "crunchy shell/chewy center" security model is often dismissed today, Bill Cheswick emphasized the importance of protecting internal systems, even if an attacker takes control of the gateway machine and gains root access.
Zero Trust Architecture (ZTA)
Jon Kindervag popularized Zero Trust while at Forrester Research, challenging the outdated "crunchy shell/chewy center" security model in his article, "No More Chewy Centers."
NIST provides guidance on Zero Trust Architectures (ZTA), emphasizing that ZTA views all networks as potentially unsafe. They state that an enterprise's network is just as vulnerable as any other network.
BeyondCorp: Google's Approach to Zero Trust
In 2009, after a major cyberattack called Operation Aurora, Google started a project to change how their employees and devices access internal apps for better security.
The attack took advantage of trust within the system, allowing the attacker to access other systems and applications. This type of movement is common now and should be anticipated. Google's review showed that using a zero trust architecture would improve security. Therefore, BeyondCorp treats all networks as untrusted and controls access to applications by checking and enforcing different levels of access.
A key takeaway for newcomers to zero trust and BeyondCorp is that Google allows all employees to work from any network without needing a traditional VPN. The experience of accessing company resources is mostly the same, whether working locally or remotely, except for possible differences in speed.
ZTA and Modern Architectures
Previous topics discussed zero trust's impact on internal networks. While it greatly improves an organization's security, its use goes beyond just internal security. Zero Trust Architecture (ZTA) can be easier to implement in various scenarios beyond traditional enterprise boundaries.
Cloud services are a clear area where Zero Trust Architecture (ZTA) can be useful, no matter the service type (IaaS, PaaS, SaaS). It's also relevant for securing mobile workers who access company resources from various devices and locations. While these practices may not be new, they are less established than traditional methods, making them a good opportunity to try out ZTA principles.
Key Infrastructure Devices
We believe that people and processes are more important than products and services, but we still need the organization to run efficiently. A key idea in SANS’s Cyber Defense curriculum is the flow model: Prevent → Detect → Respond. With so much data, products are essential for effective security; without them, we couldn't quickly move from detection to response.
Having a license to use products doesn’t mean you should rely on usual third-party setups or support. We emphasize not just the device itself, but how it fits into a strong security plan that follows modern cyber defense principles.
Edge Security Service
Zero-Trust Network Access
Zero trust has gained a lot of attention recently, but its key ideas have been around for years. While it's easy to understand the concept—like following the principle of least privilege and not trusting assets just because they are nearby—putting it into practice is much harder. ZTNA solutions are designed to help us apply these simple zero trust principles effectively.
VPNs have long been known for safe remote access. They check the source of the traffic and, if approved, allow access to internal applications. Although many enterprise VPNs have improved by moving beyond basic username and password authentication, they still aim to give direct network access after passing any authentication checks.
Cloud Access Security Broker (CASB)
Microsoft defines a CASB as a security tool that sits between users and cloud services. It enforces security policies like authentication, encryption, and malware detection, helping protect cloud apps on both authorized and unauthorized applications and devices.
Enterprise users commonly use cloud services today. It's important to know which cloud applications they use and how they use them. Are they using unauthorized cloud services? Is their data stored safely, even in approved services? Has their account been hacked? A Cloud Access Security Broker (CASB) can help answer these questions. Additionally, CASBs can enforce the organization's rules for using cloud services.
CASBs were among the first security tools that added protection for cloud resources and applications. They are still popular but are now seen as part of a bigger SASE or SSE system.
Secure Web Gateway (SWG)
Employees' internet traffic must go through the organization's security systems. It's hard to monitor and control this traffic, but it's expected to see client communications online. While remote work has existed for a while, many more employees are now working from home regularly.
The SWG makes sure all users, no matter where they are, connect to internet apps through a secure web gateway.
Palo Alto describes an SWG in the following way:
A secure web gateway (SWG) protects users from online threats and enforces company internet rules. Users connect to the SWG instead of going straight to a website. The SWG then connects them to the site while filtering URLs, inspecting content, and applying security measures.
Secure Access Service Edge (SASE)
Palo Alto highlights SASE comingling what were previously distinct tools:
A secure access service edge (SASE, pronounced "sassy") is a cloud-based solution that combines networking and security services. It enables companies to offer various security services from the cloud, including web filtering, threat protection, firewall services, DNS security, cloud access security, and data loss prevention.
Combining functions into one solution usually lowers costs and simplifies operations compared to managing different products separately. This isn't just a way for vendors to charge more; there are real, diverse security needs related to users' internet traffic.
Routers and L3 Boundary Protection
Routers
Although a router isn’t a security device, its position is important. While it has some security features, the main reason to focus on it is that it’s usually at the boundary of the network. Here, the router is the last chance to filter or monitor outgoing traffic and the first chance for incoming traffic. It also marks the limit of our control and ownership, although smaller offices may just lease a router.
Router-Based Detection: IPFIX/NetFlow
NetFlow was originally designed to help network engineers troubleshoot performance problems more effectively and quickly find the root cause of these issues.
Before NetFlow, network devices only showed port stats for troubleshooting. With NetFlow, engineers can view more detailed Layer 3 (IP) and Layer 4 (TCP/UDP) data, helping them identify which application or service may be causing problems.
NetFlow is often used by network engineers, but many security professionals may not know about it. While full packet captures are best for detailed traffic analysis, NetFlow offers quick detection at a lower cost.
NetFlow is often used to describe network logging, but other companies besides Cisco call it different names. The public RFC relates more to IPFIX3 (NetFlow v10), which is based on NetFlow v9.
IPFIX/NetFlow Data
NetFlow versions (v5, v9, and v10/IPFIX) give session data, with newer versions allowing for custom user fields. NetFlow records typically include:
Timestamps, start and finish
Source IP address
Destination IP address
ICMP type code (if applicable)
UDP/TCP port numbers (if applicable)
TCP flags (if applicable)
Bytes transferred
Profile Outbound Flows
NetFlow can't show Layer 7 data, so we need full packet capture for that. But even Layer 3/Layer 4 info gives us valuable insights. With NetFlow, we can quickly analyze outbound traffic.
Some items to consider that NetFlow can provide include:
Volume of data transferred
Who sent the data? It’s probably the firewall, since it's doing NAT (Network Address Translation).
Where are we sending data when the destination IP matches GeoIP sources?
What ports are leveraged for communication?
When will the data be sent?
These answers help profile communication and identify unusual outbound behavior.
Routers: Action Items
This section suggests action items for routers that can improve cyber defense. Routers can help us monitor outbound traffic. We recommend checking for “abnormal” connections, persistent outbound connections, the destination IP and service, and the amount of traffic.
The router can block some fake packets, but more advanced security should happen elsewhere.
L3/4 Firewalls and Network Protection
Perimeter SI Firewall
The router is useful because of where it is, but it's not a security tool. The perimeter Stateful Inspection (SI) firewall is usually the first and last security tool seen for incoming and outgoing traffic.
The main job of the perimeter SI firewall in today's businesses is to offer quick basic security. While we have better firewall options now, they can slow things down and add complexity, which can create more vulnerabilities.
The perimeter SI firewall will repeat the router's prevention and detection features, but it should offer more than just basic filters since it works as a specific filter.
Understanding Stateful
The "stateful" in SI firewall means it can track the state of active connections, unlike older static firewalls, which only look at individual packets. Static firewalls decide on traffic based on single packets without understanding the bigger picture, making it hard to create effective rules.
A client sends a request to http://www.google.com. Both the static packet filter and the stateful inspection (SI) firewall let the initial request through. The SI firewall keeps a record of this request. When Google replies, the SI firewall allows the response because it matches the record. The static packet filter, however, has no record and must decide based only on the reply packet. It could allow all traffic from TCP 80, thinking it's a legitimate response, but a better option is to check for the ACK flag to confirm it's a response.
Just checking for the ACK flag and allowing any communication isn't great, and TCP is the easiest. ICMP and UDP are much harder to manage.
Default Deny Inbound
Most organizations block all incoming traffic by default, only allowing specific services that need outside communication. For example,
allow any any -> Web Server TCP/80 TCP/443
allow any any -> DNS Server UDP/53
allow any any -> Mail Server TCP/25
Usually, there’s an automatic rule at the end that blocks anything not specifically allowed.
It works well, but can we make it better? If there's a lot of traffic needing checks from many rules before being dropped, adding a block rule above allow rules might help. However, our main focus is on improving security, not just performance.
Consider the firewall's logging features. Can we log specific rules, like IPs, or just all packets? Some high-volume traffic might not need logging since it's unlikely to be abused. In such cases, we could block or allow that traffic without logging if per-rule logging is available.
Additional Layer 3 Inbound Filtering
To strengthen security, we should add more prevention and detection measures to our rules. You likely don’t want every system or IP to access your website, but you do want legitimate customers and clients to connect to your public systems.
To tell if people using our public services are good or bad, we can start by checking their IP addresses. If they show a private IP address or a bogon IP, they probably aren't legitimate users.
Some organizations use geographical blocking to stop traffic from certain regions or countries. This is usually done with a GeoIP lookup database, such as MaxMind, which offers free options like GeoLite.
Blocking entire countries used to seem odd, but now many organizations do it for detection or blocking. Streaming services often restrict access based on location. GeoIP blocking can be easily bypassed by skilled users (like using a free AWS server), but that doesn't lessen its usefulness.
Remember that block/allow lists change over time, and you might accidentally block some real traffic.
Default Deny Outbound
Most organizations block all outside traffic by default and only allow specific services. However, many allow all outbound traffic unless it's explicitly denied. A key security improvement is to change this to block outbound traffic by default.
Layer 3 Outbound Filtering
For the inbound firewall, we set specific IP addresses that can connect. However, it's not practical to do the same for outbound traffic. Can you list all the destination IP addresses your team should access? Probably not.
We can still use Layer 3 outbound filtering, but instead of a safelist, we'll block certain traffic. This won't focus on individual IPs but will likely use GeoIP or reputation-based filtering.
Layer 4 Outbound Filtering
We can use ACL blocking for our Layer 3 outbound filter, but we can create a safelist for our Layer 4 outbound filter. This is a major improvement for outbound filtering and should be one of the first upgrades to your security setup. What services or ports do internal users need access to?
TCP/80 – from Proxy
TCP/443 – from Proxy
UDP/53 – from DNS Servers
TCP/25 – from Mail Servers
UDP/123 – from NTP Servers
Desktops and servers can't connect directly to the internet. Even if it's hard to do, it's a good goal for us.
Amazon Virtual Private Cloud (VPC)
Each AWS account gets a default VPC in every region, which includes pre-set IPs, subnets, routes, an internet gateway, a security group, and NACL. Amazon says the default VPC is good for quickly starting things like a blog or simple website and can be changed as needed. However, these settings aren’t very secure, even though VPCs offer many ways to improve security.
MITRE Engenuity's CTID comments on VPCs in their mapping of AWS security controls to ATT&CK:
Amazon VPC has strong security features for filtering incoming and outgoing traffic at both the instance and subnet levels. It also offers monitoring tools for checking traffic to keep it secure.
VPC Traffic Filtering
Security Groups are key security controls that act like a stateful firewall at the instance level. Unlike NACLs, Security Groups can only allow traffic, not deny it. If there’s no allow rule, traffic is blocked. When created, they allow all outbound traffic but have no inbound rules, so no outside traffic can reach your instance until you add inbound rules. If you remove all outbound rules, no outbound traffic is allowed.
VPC NACLs allow basic filtering based on IP addresses and ports. While Security Groups are preferred for stronger security, NACLs add an extra layer of protection. They can be used at the VPC or subnet level, helping secure instances with loose security group settings.
Every subnet has one NACL (Network Access Control List). If you don’t specify one, the subnet uses the default NACL, which allows all traffic.
AWS PrivateLink lets you connect privately to other VPCs, AWS services, or on-premises systems without using the public internet. A VPC endpoint is the entry point that enables this private connection.
VPC Detection/Monitoring
We have strong network security monitoring tools at the VPC level. We will explore these in more detail later in the course on Network Security Monitoring (NSM).
VPC Flow Logs let you see network activity at layers 3 and 4 without needing extra software or changing instances, and they don’t slow down the network or EC2 instances. Traffic Mirroring, which we’ll cover later, provides more detailed visibility than VPC Flow Logs because it works at the network interface level.
Amazon VPC: ATT&CK Coverage
This shows part of the MITRE CTID project, focusing on how AWS security controls relate to the 14 main tactics in the MITRE ATT&CK framework. It lists these tactics along with relevant techniques identified by CTID.
The colors for the ATT&CK techniques show if they help with Protection, Detection, Response, or all three.
Web Application Firewalls
The term Web Application Firewall (WAF) can lead to confusion for organizations. Many assume it acts like a regular firewall, expecting it to provide strong protection. This misunderstanding causes people to underestimate the work needed, believing they can just place a WAF in front of web applications and get great security without effort.
WAFs need a lot of work from someone or a team who knows both how web applications can be attacked and how to defend them, as well as a good understanding of the specific web apps.
WAF Capabilities
If the organization understands the effort needed and hires the right staff, a Web Application Firewall (WAF) can offer significant benefits. Unlike traditional security devices like firewalls and intrusion detection systems, WAFs are specifically designed to protect custom web applications. With proper setup, they can be customized to safeguard each application effectively.
WAFs do more than protect web applications; they also offer Virtual Patching. If you find a flaw in your custom web app, and there’s no patch available, your organization needs to fix the code itself.
How long does it take to fix code? It can vary a lot, but WhiteHat’s report shows that, on average, it takes about 112 days to fix flaws in .NET web applications. This means there’s a risk for 112 days if the flaw is public and unpatched.
WAFs can help by using Virtual Patching to block exploit attempts on flaws. It's not a real fix, so the code still needs to be updated, but it reduces risk until then.
WAF Prevention/Detection
Virtual patching mainly prevents attacks, but WAFs also help detect them. Many organizations don’t plan to use WAFs for detection, yet many are used without skilled staff, leading to false positives. Blocking important web applications can reduce the WAF's preventive effectiveness.
Security teams often see this as a failed deployment. While it may be in some ways, a WAF can still be very helpful for detection. Many people have misconceptions about what WAFs do.
WAF Deployments
A Web Application Firewall (WAF) should be placed in front of the web applications it protects. One simple way to do this is to install the WAF directly on the web server. However, this method doesn't work well if you have many servers to protect, as it needs better management.
The module-based WAF has a weakness in web server farms with multiple identical servers for load balancing. A good solution is to use it as a reverse proxy in front of the server farm. Many load balancers can also add WAF features.
A new deployment model is the WAF-in-the-cloud, where a web application firewall (WAF) is hosted in the cloud. This means your web app traffic goes through the cloud, without needing on-site devices or management. It often allows businesses to outsource some web application security to the vendor.
Azure Web Application Firewall (WAF)
Azure WAF can be set up on Azure Application Gateway, Front Door, or CDN. Front Door and CDN speed up app delivery globally.
Microsoft's Application Gateway supports TLS termination, load balancing, session management, content-based routing, and security features. When combined with Azure WAF, it allows customized security policies for different apps and integrates easily with Defender for Cloud and Microsoft Sentinel.
Azure Web Application Firewall: ATT&CK Coverage
The slide shows part of a project mapping Azure security controls to MITRE ATT&CK tactics. It lists 14 adversary tactics and highlights relevant ATT&CK techniques for Azure security.
AWS WAF + AWS Shield
AWS WAF is a web application firewall that protects web apps and APIs by filtering harmful traffic using rules. It allows custom rules and offers prebuilt AWS Managed Rules for added security at no extra cost.
You can add Shield Advanced protection to these resource types:
Amazon CloudFront distributions
Amazon Route 53 hosted zones
AWS Global Accelerator accelerators
Application Load Balancers
Elastic Load Balancing (ELB) load balancers
Amazon Elastic Compute Cloud (Amazon EC2) Elastic IP addresses
AWS Web Application Firewall and AWS Shield: ATT&CK Coverage
The slide shows part of the MITRE CTID project mapping AWS security controls to MITRE ATT&CK. It lists ATT&CK's 14 main tactics and highlights relevant techniques for an AWS security control.
Lab 2.1 - ModSecurity
Objectives
Gain experience with Web Application Firewalls.
Become familiar with ModSecurity logs.
Review ModSecurity in DetectionOnly and in blocking modes.
Understand how both input and output can trigger a block.
Challenges
There is a link on the Firefox bookmark toolbar:
https://localhost:8443/scanners/pilots.php
Browse to the pilot search page, and perform a search for a BSG pilot (for example, Starbuck).
Search for the pilot, Edward "Priest" O'Connor, by his surname, O'Connor, to discover an obvious SQL Injection flaw.
Exploit the SQL Injection flaw to return all rows in the table.
Review the ModSecurity logs to find the SQLi attempt.
Configure ModSecurity to block rather than simply detect attacks.
Confirm general searches for pilots are still successful after ModSecurity reconfiguration.
Determine how the application now behaves when searching for the pilot, Edward "Priest" O'Connor, by his surname, O'Connor.
Attempt to discover/exploit the SQL Injection flaw again using various patterns.
Review the ModSecurity logs to identify the blocked SQLi attempts.
Configure ModSecurity to again Log rather than Block.
First, let's go to the pilot search page and search for a pilot.
A simplified version of the SQL query in PHP looks like this:
Previously, when we submitted "Starbuck," the query looked like this:
Now, let's search for the pilot, Edward "Priest" O'Connor, by his surname, O'Connor, and see what we get:
Using this SQL example, entering O'Connor gave this query:
This query gives a syntax error because MySQL reads the 'O' as the whole input and can't process the rest "Connor';".
Now, we'll use this SQL Injection flaw to return all rows by entering these strings in the form field.
' or 1=1; #
' or 'cylon'='cylon
Let's see why these two attack strings gave us the whole table. Using our basic SQL knowledge, the first attack ' or 1=1; # leads to this query:
The input ' or 1=1; # bypasses errors by completing the SQL query and turning the rest into a comment using #, so it doesn't interfere with the input.
The last submission, ' or 'cylon'='cylon, would create this SQL query:
This input doesn't cause a syntax error or use comments, but it changes the WHERE clause, making the database return the whole table instead of just one row.
Next ,we'll review the ModSecurity logs to find the SQLi attempt.
Now, let's configure ModSecurity to block instead of just log, we'll change SecRuleEngine from DetectionOnly to On in the /etc/modsecurity/modsecurity.conf file, then restart Apache.
Let's run this script to change the settings and restart Apache automatically:
Let's check if pilot searches still work after ModSecurity changes.
The application does still function after reconfiguring ModSecurity.
Let's try finding and using the SQL Injection flaw again.
Basic SQL Injection seems blocked now.
Let's find out how the app responds when we search for the pilot Edward "Priest" O'Connor using just his last name, O'Connor.
Now, let's review the ModSecurity logs to identify the blocked SQLi attempts.
Last updated
