Part Three
Last updated
Last updated
Cloud environments are categorized by deployment models. Public cloud is available to everyone but may have regional limits. Private cloud is used by one organization only, regardless of where its infrastructure is located. The key difference is that private cloud serves a single tenant, while public cloud serves multiple tenants.
The community cloud is between public and private clouds, serving specific organizations, like AWS GovCloud for US federal agencies. A hybrid cloud combines two or more cloud types (private, community, or public) that stay separate but work together through technology, often linking on-premise and public clouds.
Multicloud means most organizations use more than one public cloud service, though it's not a formal model.
Cloud services are categorized by the delivery model: IaaS, PaaS, and SaaS. Each model affects how much security responsibility the user has.
A common challenge in cloud migration is when organizations wrongly think the provider handles security tasks that are still their responsibility, leading to confusion over roles.
Cloud providers offer guides on shared security responsibilities, but how they explain it differs across providers.
Amazon, Microsoft, and Google don't have the same way of showing who is responsible for security in the cloud. However, it's clear that the user's security responsibility goes down as we move from on-premises to IaaS, PaaS, and SaaS. Microsoft provides specific examples of the security duties of the Cloud Customer (us) compared to the Cloud Provider (them), which helped shape the presentation mentioned above.
IaaS, PaaS, and SaaS are popular service models, but there are many others. Some important ones include Function as a Service (FaaS), Container as a Service (CaaS), Desktop as a Service (DaaS), and Identity as a Service (IDaaS).
Amazon's AWS Lambda made Function as a Service (FaaS) popular, also known as Serverless. While not all serverless options are FaaS, the term is widely used. With FaaS, users can run code without managing servers or containers.
The growing use of containers, both in data centers and the cloud, requires better management. Container as a Service (CaaS) is a model that supports quick adoption and scaling of containers. While CaaS is sometimes seen as a part of Infrastructure as a Service (IaaS), it focuses on containers instead of virtual machines. Similarly, Virtual Desktop Infrastructure (VDI) targets desktops, while Desktop as a Service (DaaS) refers to cloud-hosted desktops instead of on-premise setups.
The final service we’ll look at is Identity as a Service (IDaaS). It’s a cloud-based tool for managing user identities, often used for directory services. It helps with single sign-on (SSO) and may speed up the use of multifactor authentication (MFA).
Infrastructure as Code (IaC) is important in cloud environments. It involves defining the operating setup in code, leading to more consistency. This consistent environment makes testing and deployment easier and repeatable. DevOps relies on IaC for a stable setup, enabling faster and automated code deployment.
Despite DevOps, there are still important uses for Infrastructure as Code (IaC). These have grown a lot as cloud providers now offer ways to deploy and set up systems, storage, and networking. AWS CloudFormation is a well-known example of IaC in the cloud.
AWS CloudFormation lets you use a standard way to set up and manage AWS and third-party resources in your cloud. You can use programming languages or a simple text file to automatically and securely create all the resources your applications need across different regions and accounts.
This is an example of infrastructure as code using AWS CloudFormation Designer. It lets you create CloudFormation templates either by writing code or using a drag-and-drop interface. You can write code to fill in the diagram, or drag items in the diagram to generate the corresponding code.
Using templates for quick resource deployment is helpful, but it’s important to make sure they don’t create security problems. A common issue in Infrastructure as Code (IaC) is failing to keep these templates updated with the latest versions and patches.
Doing the same security tasks faster and more often doesn’t automatically make things safer. For example, many organizations scan for vulnerabilities constantly without fixing them. Experts suggest that it’s better and usually cheaper to build security into systems from the start instead of adding it later. Security should be planned early, but it also needs regular updates because threats and vulnerabilities change. It’s also important to keep an eye on access controls for templates since services might use them.
Security misconfigurations aren't new, but their potential harm has increased. This is especially true for breaches linked to public cloud storage, which can be both public and private. Amazon's Simple Storage Service (S3) is the most widely used public cloud object storage.
Amazon has made it harder to accidentally expose stores to the public and added tools to help find exposed storage. However, Kaushik Sen from Upguard points out that as long as S3 buckets can be set to public, there will still be data leaks. He also notes that making it easier to keep S3 storage private doesn't eliminate the chance of it being set to public.
Amazon and Azure have both faced data breaches due to their public cloud storage. Both companies provide clear instructions to help prevent these data leaks.
A key security issue with cloud services is reduced visibility. Detecting problems isn't usually prioritized in new services. However, as cloud services have developed, so have tools for better detection and visibility. While some visibility challenges remain, many have been addressed or can be improved.
Cloud services are rapidly growing, prompting security vendors to create solutions similar to traditional security. Cloud providers want to offer strong security to attract clients and are partnering with third-party security firms. This improved security comes from recognizing challenges and the advancing capabilities of cloud services.
A main reason for limited visibility in public cloud services is that they are shared by many users (multitenant). This makes it hard to monitor network activity. To capture data in a switched network, you usually need special access, like connecting a device or changing settings on a switch. If many customers are using the same switch and want to monitor traffic, it complicates things for cloud service providers.
Cloud services are still multitenant, but providers are improving ways for users to monitor their networks. Different cloud service providers offer varying levels of network access and monitoring capabilities, which can also differ by region.
Most network visibility comes from session or flow-based information. However, some cloud service providers are now also offering direct access to packet data, even if it's more complicated.
Endpoint visibility is easier than network visibility but still has challenges similar to on-premise systems. Common questions include how to collect and store endpoint data, manage data volume, and improve logging for better analysis. The same methods used for on-premise visibility apply here. The main ways to gather data from endpoints are using the system's built-in logging features or installing a third-party agent.
CSPs often provide their own agents designed to connect with their cloud monitoring systems.
To understand threats, we need to know how they use code or data to take advantage of weaknesses in the client. Besides looking at how they first attack, we should also think about what they do afterward. A key action after an attack is lateral movement or pivoting.
Threat Intelligence is becoming more important. While countries, especially in military matters, have always thought about threats, businesses have often overlooked this risk. Recently, there’s been a rise in interest in understanding potential enemies better.
In US defense, TTP stands for Tactics, Techniques, and Procedures. It helps to understand and respond to enemy actions.
A new method for understanding enemy activities has gained popularity quickly. It suggests using intelligence to guide Computer Network Defense (CND) by focusing on the Cyber Intrusion Kill Chain. This approach is based on a paper by three Lockheed Martin security experts: Eric Hutchins, Mike Cloppert, and Rohan Amin, Ph.D. The paper is titled “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains.”
The Intrusion Kill Chain looks at the stages of modern attacks and what signs might show each stage.
The paper includes the following phases:
Reconnaissance
Weaponization (“Build” in the slide above)
Delivery
Exploitation
Installation
Command and Control
Actions on Objectives
Lockheed Martin's Cyber Kill Chain is commonly used in the industry, providing a standard way to discuss campaign details. However, it can feel outdated, especially in post-exploitation areas. The last three phases—Install, C2, and Act—need more detail and attention.
MITRE's ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) improves on the kill chain by breaking down the Install, C2, and Act phases into 10 post-exploitation tactics. This helps provide clearer language and details about attacks and adversary actions, with over 130 techniques described within these tactics.
In 511, we will mainly focus on what attackers do after they exploit a system. This phase is usually easier to detect and provides more actionable insights. If your organization has systems in place to spot data theft, you're already doing well.
Post-exploitation activities are connected. The goal is to steal data, but attackers usually don’t start on a device with direct access to it. Instead, they must move through the organization to find the right data or person. To do this, they need to control the compromised system and have a strong command-and-control (C2) channel for communication, allowing them to act remotely.
To shift to a detection-focused information security strategy, organizations need to see their network traffic clearly. Many struggle with this, as they often only monitor incoming internet traffic but lack visibility within their internal networks.
A key practice is to include visibility analysis in the organization’s cybersecurity strategy. This first step aims to identify where the organization struggles to detect intrusions or malicious activity.
The image shows AutoRuns, a top Windows tool for finding signs of enemy presence. You can get AutoRuns from Microsoft Sysinternals.
Stage 2 refers to a download that gives an attacker more control over a system after they’ve first accessed it. This download allows the attacker to perform better, like encrypting data easily on Windows, which can be difficult without it.
The shellcode sends an HTTP POST request to a fixed IP address and downloads XOR-encoded shellcode hidden in an HTML comment.
The slide shows Wireshark with a packet capture example of HTTP POST-based C2, which we'll discuss later in class.
A key part of modern cyber defense is understanding how attackers move within a system. They usually don't start by attacking the main target but instead compromise other internal systems to reach it. Lateral movement, or pivoting, is crucial in today's attacks. While spotting data theft is important, detecting and stopping attacks before any data is stolen is even better.
From Mandiant M-Trends:
The psexec_command module in Metasploit lets attackers run commands on a hacked system as a Windows service, leaving traces in the Windows event log.
We'll focus on how to strengthen your organization against Metasploit's misuse of Microsoft PSExec and pass-the-hash attacks. Even with these protections, breaches may occur, so we'll provide ways to help you detect such activities better.
Where will attackers try to move? What data are they after? How can they get to it? These questions are important for data visualization. Attackers mainly target data, so knowing where our valuable data is and how to access it is crucial for defense.
Modern attackers mainly aim to steal data. Protecting against data theft is crucial for cybersecurity, making data exfiltration analysis a key defense practice.
If attackers get access to the data, how might they steal it? Knowing how data is commonly stolen helps organizations set up specific monitoring to protect against those methods.
Organizations aiming for better cyber defense should shift to a default deny policy for outgoing traffic. While many already block incoming traffic by default, they usually allow outgoing traffic unless blocked. Although switching to block all outgoing traffic can be challenging at first, it greatly enhances security.
Some examples of potential wins for outbound blocking:
Helps detect internal compromised assets reaching back for C2
Helps detect simplistic data exfiltration attempts
Helps detect some policy violation attempts
Helps detect some assets unwittingly attacking third parties
Blocking outbound traffic by default mainly helps with detection. While it might stop some attacks, skilled adversaries usually find ways to bypass these blocks.
We've only just started to explore modern cyber defense. Key parts include Security Architecture, Network Security Monitoring, and Continuous Security Monitoring.
This approach will create a lot of data that we need to generate, use, and analyze. This is essential for strong defenses against advanced threats. To handle this data effectively, we will need a dedicated Security Operations Center (SOC).
Storing data is easy and cheap, but using it for detection and response is harder. Organizations will need to create a Security Operations Center (SOC) to effectively analyze this data.
To understand what a SOC is, we first need to clarify what it isn't. Some organizations mistakenly think they have a SOC just because they use a SIM/SEM/SIEM system for logs. While a SIM can be part of a SOC, having just a SIM doesn't make a SOC.
Outsourcing 24/7 IDS analysis to a Managed Security Service Provider (MSSP) seems easy and cost-effective, especially with third-shift analysts. However, without strong management and coordination, this often doesn't create a real Security Operations Center (SOC).
A SOC aims to improve detection of security threats and enhance response capabilities. Its main goals include minimizing disruptions from security incidents and reducing the impact of breaches.
Successful SOCs focus on people and processes instead of just products. While products are needed to help staff and improve processes, building a SOC mainly around a product can lead to failure. The best SOCs use custom tools and scripts along with commercial products.
To build and staff a SOC, key roles are needed, including SOC analysts, incident responders, security architects, developers, managers, and operational administrators.
Many organizations find outsourcing a Security Operations Center (SOC) appealing at first. Setting up a full SOC can be expensive, so outsourcing usually costs more in operations but less in initial setup. A common reason for choosing outsourcing is the belief that there aren’t enough skilled employees to monitor security around the clock.
One main reason for outsourcing the SOC to an MSSP is to have analysts available 24/7. The idea is that the MSSP can hire skilled analysts for all shifts due to their larger scale. However, a key challenge is that you usually won’t have an analyst focused only on your data, and you may work with various analysts. The problem is that these external analysts may not fully understand your specific business needs and setup.
You need to keep helping the MSSP and analysts understand your system, and this help may need to be given to each analyst who works with your data. Despite your efforts, the external analysts may still struggle to understand your specific business environment or needs.
Outsourcing parts of a Security Operations Center (SOC) has obvious costs, but there are hidden ones too. When more security tasks are outsourced, internal staff may lack experience and career growth. Additionally, outsourcing security doesn’t remove the organization’s responsibility for breaches. A Service Level Agreement (SLA) can help ensure the third party acts responsibly, but it doesn't free the organization from legal liability.
Incident Response and Forensics usually operate separately from the typical MSSP role, but MSSPs might offer these services for a fee. Whether done internally or outsourced, close coordination with the MSSP is essential.
Don’t let the desire for perfection stop you from making progress. Building a full Security Operations Center (SOC) can seem overwhelming, so don’t expect to create a complete SOC all at once. This approach can lead to failure or lack the needed maturity. Instead, gradually develop SOC capabilities, staffing, and processes over time, and remember that focusing too much on products can lead to poor results.
When creating a SOC that isn’t focused on products, the first step is to outline its main services, like detecting intrusions, responding to incidents, and managing security operations.
The hardest part of building a good SOC is training the staff. Proper detection and response are not simple tasks. Most organizations lack security staff focused solely on these areas, making it tough to quickly develop advanced skills.
Training is essential for effective SOC staff. While external training is valuable, in-house training is crucial for maintaining skills. One effective way to boost team morale and skills is through internal exercises.
Penetration testers attempt to hack systems, while analysts look for attacks and alert responders. Incident response teams deal with breaches. Security teams, developers, and app security experts work to enhance security. These activities can be enjoyable but are best suited for organizations with strong security practices.
A hybrid model combines outsourcing with in-house work. The organization may use an MSSP after staff leaves or as extra support for fewer internal workers or specific SOC tasks.
TheHive Project provides a high-level overview:
SOC and CERT analysts can work together in real time, sharing updates on cases, tasks, and IOCs. Notifications help assign tasks and preview new alerts from sources like emails, CTI, and SIEMs for immediate investigation.
Create cases and tasks with an easy template system. Add metrics and custom fields to track team activity and automate time-consuming tasks. Analysts can log progress, attach evidence, add tags, and safely import ZIP files with malware.
Add observables to cases, import from MISP events, triage, and filter quickly. Use Cortex analyzers for insights to speed up investigations and contain threats. Tag, flag IOCs, track sightings, and feed threat intelligence. Export IOCs to MISP after investigations.
TheHive is a Security Incident Response Platform (SIRP) that imports data from sources like other SIRPs, MISP, SIEMs, email, and more.
TheHive Project describes Cortex:
Cortex helps SOCs, CSIRTs, and security researchers by allowing them to analyze collected data on a large scale using one tool instead of many.
Cortex, a free tool by TheHive Project, helps analyze observables like IPs, emails, URLs, and files. You can use its web interface or automate tasks with its REST API.
In the coming days, you'll handle a lot of data to improve security. Without a SOC, it would be extremely hard to get the needed visibility and analysis.
To improve security, it's crucial to understand normal traffic to spot suspicious activity. A SOC helps detect and respond to threats quickly.
We'll do our analysis using Kibana, which connects to Elasticsearch. To access it, let's open Firefox and go to http://localhost:5602.
In the Discover tab, let's choose the lab-egress index and set the time range to "Last 5 years."
Let's select "Last 5 years" in the Time Range dropdown.
The lab-egress index mainly contains Zeek logs from network data, and there are Kibana dashboards and visualizations available that can be useful.
To access dashboards, let's click on the Dashboard button on the sidebar.
Here are some useful fields for filtering data in the ingested Zeek logs:
event_type: Identifies the Zeek log file that has the data (e.g., bro_http, bro_conn, bro_dns, bro_irc, etc.). Since this is from an older Bro version, it uses the old name instead of Zeek.
source_ip, source_port, destination_ip,destination_port
host: the Host header in an HTTP Request
user_agent: the User-Agent field in an HTTP Request
status: HTTP Server's status code (e.g. 200, 404)
query_type, query_code: the type of DNS request (e.g. A, MX, NS) and associated code (e.g. 1, 15, 2 respectively)
rcode_name, rcode: the DNS server's response type (e.g. NOERROR, SERVFAIL, NXDOMAIN) and associated code (e.g. 0, 2, 3 respectively)
service: shows the highest layer protocol Zeek was able to successfully decode for the traffic
What is the most common service to be communicated with?
Which two of the top 10 destination ports (based on the number of sessions) warrant further review, and why?
What is the most commonly queried non-existent domain?
Which internal IP (10.5.0.0/16) address has downloaded the largest number of executable files?
What is the most common FQDN seen in HTTP traffic?
Identify the most frequently occurring URI in HTTP-based executable downloads.
How many HTTP requests were sent by an internal IP (10.5.0.0/16) that lacked a User-Agent?
Q1) What is the most common service to be communicated with?
Just because communication happens on a certain destination port doesn't mean the service usually associated with that port was used. For example, a backdoor command shell could use port 80, but that doesn't mean it's using HTTP. Zeek is aware of application layers and tries to decode traffic regardless of the port. The highest layer protocol it decodes is recorded in the "service" field of Zeek's conn.log.
Let's perform a search by entering the following search criteria in the search box.
To quickly see the most common values for a field, we can find it under "Available Fields" and click on it to view the "Top 5 values."
This display is very helpful. We can click "Add" to include a field as a column in the data table, or use the + magnifier to filter in a value and the - magnifier to filter it out.
The "in 500/500 record" note after "Top 5 values in..." means we're looking at the Top 5 values from a sample of data, which may not represent the entire dataset.
Let's go to the Visualize tab, we can see a prebuilt visualization for the data we want is: zeek_conn: Top 10 Service
Q2) Which two of the top 10 destination ports (based on the number of sessions) warrant further review, and why?
Let's go to the Discover tab and use this query:
In the Available fields, we can see the destination port field, let's click on it, and then click the visualize button.
And here is the top 10 destination ports:
Most of the Top 10 ports are common. We can look them up online if we don't recognize some. We can also check our local system's /etc/services file to see if they are well-known ports.
Ports 137, 138, and 445 are Microsoft ports and shouldn't be used for outbond connections. Ports 25, 53, 80, and 443 are common public services. The remaining ports are 6000, 65520, and 555. Port 6000 is linked to X11 in /etc/services, so ports 555 and 65520 need more checking.
There is also a prebuilt visualization for this purpose is: zeek_conn: Top 10 Destination Ports (Sessions)
Answer: 555, 65520
Q3) What is the most commonly queried non-existent domain?
In Kibana, let's go to Discover and search to show only DNS information.
NXDOMAIN means that the domain we searched for doesn't exist, according to an authoritative DNS server. This is different from a failed lookup (SERVFAIL), which just means there was a general problem with the DNS service.
NXDOMAIN is a DNS response code. In our Elastic Stack, the data fields are rcode and rcode_name. rcode shows the numeric code for NXDOMAIN, a type 3 error, while rcode_name gives the simple name for this error.
Let's update the search to include a filter for the NXDOMAIN records:
The same results could have been obtained by using the rcode_name field instead of rcode in this search:
In the Available fields, we can find the query field, which shows the top 5 most searched non-existent domains.
Answer: niray.com.cn
Q4) Which internal IP (10.5.0.0/16) address has downloaded the largest number of executable files?
MIME Type, also known as Media Type or Content-Type, is an HTTP header that shows the type of file being sent. Let's use a pie chart to see the different MIME Types that Zeek found in the traffic.
Let's start by creating a new Pie Chart.
First, let's set the metric to count the number of occurrences of each MIME type.
Then choose Split Slices and select Terms as the aggregation, then set this to mime_type.keyword
Then click Apply changes.
The right side of the visualization shows different MIME types; we can see the application/x-dosexec. Let's add this mime type as a filter.
This will add a filter for mime_type.keyword:"application/x-dosexec"
Let's pin the new filter and switch to the Discover tab. Pinning the filter means it will stay active when we navigate to other sections of Kibana.
We need to add a filter to show only the results for our internal IPs (10.5.0.0/16) that are downloading files.
Using destination_ip instead of source_ip can be confusing at first. This is because we are looking at logs from bro_files, where the destination refers to where the file was sent. That's why we use destination_ip.
Now, let's click on the destination_ip field under Selected Fields to see the Top 5 Values.
Answer: 10.5.100.131
Q5) What is the most common FQDN seen in HTTP traffic?
We'll use this query to answer the question.
Now, let's check the Available fields for the "host" field and see the top 5 values.
Answer: storage.conduit.com
Q6) Identify the most frequently occurring URI in HTTP-based executable downloads.
This task is similar to our previous work with executable downloads. This time, we'll look for executable downloads in the bro_http logs instead of the bro_files log. This will help us get the HTTP URI linked to the executables.
Let's go to Discover and filter for the bro_http logs:
MIME Types help us spot executables sent over HTTP, like we saw with the executable download example. In the bro_files log, we filtered for executables using mime_type:"application/x-dosexec". However, this specific field isn’t in the bro_http logs. Instead, there are two fields for MIME Types: orig_mime_types for the HTTP request and resp_mime_types for the HTTP response.
Now, let's check the Available fields for the "uri" field and see the top 5 values.
Answer: /x
Q7) How many HTTP requests were sent by an internal IP (10.5.0.0/16) that lacked a User-Agent?
Let's filter the data to only show HTTP data.
Now filter to show only data sent from our internal IP range (10.5.0.0/16).
Next, we need to filter out entries where the user_agent is empty.
We added AND -user_agent:* to the filter. The AND connects filters, while -user_agent:* excludes entries where the user_agent field has any value. The - negates the filter to remove those entries.
There are 14 cases where internal IPs made HTTP requests without a User-Agent.
Answer: 14
MISP is a platform for sharing and managing threat intelligence, including attack indicators, fraud, vulnerabilities, and counter-terrorism info. You can find it at:
