diff --git a/.readthedocs.yaml b/.readthedocs.yaml
new file mode 100644
index 0000000..2742d87
--- /dev/null
+++ b/.readthedocs.yaml
@@ -0,0 +1,26 @@
+# Read the Docs configuration file
+# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
+
+# Required
+version: 2
+
+# Set the OS, Python version, and other tools you might need
+build:
+ os: ubuntu-24.04
+ tools:
+ python: "3.13"
+
+# Build documentation in the "source/" directory with Sphinx
+sphinx:
+ configuration: source/conf.py
+
+formats:
+ - pdf
+
+# Optionally, but recommended,
+# declare the Python requirements required to build your documentation
+# See https://docs.readthedocs.io/en/stable/guides/reproducible-builds.html
+python:
+ install:
+ - requirements: requirements.txt
+
diff --git a/source/AD_Lab.md b/source/AD_Lab.md
new file mode 100644
index 0000000..ee68a77
--- /dev/null
+++ b/source/AD_Lab.md
@@ -0,0 +1,464 @@
+# Active Directory Lab Setup test
+
+## Introduction
+
+This guide provides a step-by-step walkthrough for setting up a basic Active Directory lab environment. You will learn how to configure a Domain Controller (DC), manage static IPs, create a domain, and join client machines to that domain. Additionally, we will cover DNS record creation and log forwarding.
+
+## Lab Objectives
+
+This lab simulates a typical corporate or homelab infrastructure, enabling you to:
+- Centralize user authentication and management.
+- Regulate user access to devices.
+- Establish a secure process for network and computer access.
+
+This lab integrates concepts from **Networking**, **Infrastructure**, and **Security**.
+
+## Requirements
+
+To complete this lab, you will need the following:
+
+1. **GlobalProtect**: To access the SDC Environment.
+2. **Windows Server 20XX**: To act as our Primary DC.
+3. **Windows Server 20XX**: To act as our Secondary DC for fault tolerance.
+4. **Windows 1X**: To act as a client machine.
+5. **Windows 1X**: To act as another client machine.
+6. **Linux**: To act as our Splunk Server for log forwarding and AD-based authentication.
+
+**Note on Fault Tolerance:** Having a secondary DC is crucial for redundancy and backup, as services can fail unexpectedly.
+
+These Windows VMs should be generated from a template. If not, ensure you have four VMs that can communicate with each other, preferably on the same VLAN.
+
+All these Virtual Machine's are going to be left in a setup phase, meaning you will be spending time download packages, setting passwords, etc.
+
+## Primary Domain Controller
+
+Let's begin by configuring our first VM, which will serve as the Primary Domain Controller (PDC). For this guide, we are using a **Windows Server 2019** virtual machine.
+
+
+1. Start the Windows Server 2019 - PDC virtual machine. You should be greeted with the Windows Setup screen.
+
+*Image of the Windows Setup screen.*
+
+
+
+2. Click Install Now.
+
+
+
+
+
+3. For the operating system, select Windows Server 2019 Standard Evaluation (Desktop Experience) and click Next.
+
+> **Note:** Choosing an option without "Desktop Experience" will result in a command-line-only interface (PowerShell).
+
+
+
+
+
+4. Accept the license terms (EULA) and click Next.
+
+
+
+
+
+5. Select Custom: Install Windows only (advanced).
+
+> The "Upgrade" option is not applicable here since we are performing a clean installation.
+
+
+
+
+
+### Loading VirtIO Drivers (Proxmox)
+
+If you are using Proxmox or a similar KVM-based hypervisor, you will need to load VirtIO drivers for the installer to recognize the virtual hard disk.
+
+
+1. Click Load Driver.
+
+> **Note:** These drivers are necessary for virtualized hardware to perform correctly. In our lab template, the driver disk is pre-mounted. If you're setting up a VM from scratch in a Proxmox environment, you'll need to mount the VirtIO driver ISO yourself.
+
+
+
+
+
+2. Click Browse.
+
+
+
+
+
+3. Locate the virtual CD drive, which should be labeled something like virtio-win-x.x.xxx.
+
+
+
+
+
+4. Navigate to the vioscsi folder, then select the folder corresponding to your OS version (e.g., 2k19 for Windows Server 2019), and finally select the amd64 folder. Click OK.
+
+
+
+
+
+5. The installer should find the Red Hat VirtIO SCSI pass-through controller driver. Select it and click Next to install it.
+
+
+
+
+
+### Partitioning and Installation
+
+
+1. After the driver is installed, you will see the virtual drive. Select it and click New.
+
+
+
+
+
+2. Allocate the maximum available space for the new partition. Windows Setup may create a small, separate "System Reserved" partition; this is normal. Click Apply and then OK.
+
+
+
+
+
+3. Select the largest partition (marked as "Primary") and click Next to begin the Windows installation.
+
+
+
+
+
+
+
+4. Windows will now install. This process may take some time.
+
+
+
+
+
+5. Once the installation is complete, the VM will restart, and you will be prompted to set a password for the local Administrator account. Choose a secure password and complete the setup.
+
+*No photo taken; but if you need help, reach out!*
+
+
+
+### Post-Installation Setup
+
+Okay, now at this point of the setup, you have been interacting with this VM through the browser, through the Console tab. If that is your preference, you can continue to do this lab in that experience, but in my personal preference, I very much enjoy either my own machine and to RDP into client (specifically for Windows).
+
+I recommend you to use RDP instead of the browser in case of compatibility issues and overall better user experience.
+
+The following steps will explain you how to connect this device to the internet, setting an IP and enabling remote desktop.
+
+So first, now that your VM has finished setting up, let's login to your Administrator account you just setup for yourself.
+
+You might notice that your machine although you assigned virtual i/o drivers before hand is still having internet connectivity issues.
+
+That is okay, we will resolve that right now.
+
+
+1. Go ahead and open file explorer and navigate to the same virtio-win virtual CD Drive.
+
+
+
+
+
+2. Scroll through the drive.
+
+
+
+
+
+3. Find virtio-win-gt-x64.msi and run that installer.
+
+
+
+
+
+4. Proceed with next and accept the EULA.
+
+
+
+
+
+5. After accepting the EULA, you will be prompted with installing many different features. The feature we are looking to add is marked as "Network". Once you select it, click next.
+
+
+
+
+
+6. Then click install.
+
+
+
+
+
+7. A Windows Pop-up will occur asking if you want to make your PC discoverable. You can click yes.
+
+
+
+
+
+
+
+Now you the red internet icon you are seeing at the bottom, should have disappeared and your machine should look like you have internet now.
+
+A way to make sure your machine is reachable through the Internet, Open up Command Prompt.
+
+
+1. Use Win + R or Windows Key and type "run" into Search to open the Run Page.
+
+
+
+
+
+2. The program we want to open is cmd.exe. Click OK.
+
+
+
+
+
+3. Now that we have the Command Prompt open, lets ping a well known source that is reliably online, Google. Type into your command prompt ping google.com.
+
+Expected results are 4 packets sent with 100% received and 0% loss
+
+
+
+
+
+Now that we are aware this device is able to reach the actual Internet, now lets figure its local ip address to RDP into the machine.
+
+
+1. In the same command prompt box type in ipconfig.
+
+
+
+
+
+Now that you see all these addresses, the one we are looking for is IPv4 Address, for my current machine its `192.168.1.116`
+
+This IP address is specific to this Virtual Machine and the way
+
+Now you need to understand that this IP address is local to the "Router" you are connected to. In your case we provision a virtual pfSense router to your pod that has an IP Address to the router, typically formatted in `172.16.x.x`, meaning that is your external address. But locally when you are connected to that LAN of this network, you are accessible as `192.168.1.116`, but externally your machine is reached as `172.16.x.116`. The `x` part in that external address will depend on your pod number, typically represented as `10xx_windows_ad_splunk_lab`. taking that `xx` in the pod number will be part of your WAN address. Even if you still cannot find out what your pod number is, you can remote into your virtual router and look at the WAN address that first comes up (If it says `172.16.1.1`, click enter to refresh the page and a different WAN should appear)
+
+This was a bit of a tangent and very surface level understanding on how the router connects, I hope I will shorten it and explain it better later.
+
+If you think you understand how to access the machine externally, try pinging your Windows VM from your own device while connected to the GlobalProtect VPN. If this still does not work and you cannot ping your virtual machine from your physical machine, check the IP address and make sure you understand how we are getting each octet of the address.
+
+### Enabling Remote Desktop Access
+
+
+1. If you can ping your machine from your physical machine, you should now know the address of the machine and can access it externally. Go back to Proxmox and open the console for the Windows VM one more time to enable Remote Desktop.
+
+> **Note:** You can access the machine using either the External IP of your VM or the actual Computer Name if you know it. You might encounter issues regarding Network Level Authentication, which must be disabled in the Remote Desktop settings.
+
+
+
+At this point of the lab, you should have a ready Windows Server 2019 Machine and have an understanding of how the networking works within your deployed pod. This next part of the lab will now focus on setting up your domain and will be more hands-on and less of a tutorial.
+
+### Server Manager Configuration
+
+
+1. Open Server Manager and browse around to see what features are available in this Server edition of Windows.
+
+> From the Server Manager, you can see many different features typically not available on Home and even Pro editions of Windows.
+
+
+
+### Setting Computer Name and Static IP
+
+
+1. Change the Computer name to something more recognizable so you can type in a name instead of remembering the IP Address when remoting in.
+
+> For the sake of this lab environment, we will have a consistent naming system for all clients. Rename your Windows VM to **FirstInitialLastName-DC01** (e.g., **JMama-DC01**) and then click **Apply**.
+
+
+
+
+2. Before restarting your computer, set a static IP for your machine to ensure that when you restart, the IP doesn't change and you can still remote back into the machine.
+
+> **Tip:** If you are unsure about all the settings you need for the IPv4 configuration, running `ipconfig` in Command Prompt will help guide you with the current network settings.
+
+
+
+
+3. After you set the computer name and static IP for your machine, restart your VM through Windows to ensure all settings are applied.
+
+> This restart ensures that both the computer name change and static IP configuration take effect properly.
+
+
+
+### Installing Server Roles and Features
+
+
+1. Now that you have browsed around, locate the Manage > Add Roles and Features button at the top right of Server Manager.
+
+Install the following server roles and features:
+- **Active Directory Domain Services**
+- **Active Directory Federation Services**
+- **Active Directory Lightweight Directory Services**
+- **Active Directory Rights Management Services**
+- **DNS Server**
+
+
+
+
+2. Proceed through the Add Roles and Features Wizard, accepting any dependency services that are required.
+
+> **Note:** The wizard may prompt you to install additional features that are dependencies for the roles you selected. Accept these to ensure proper functionality.
+
+
+
+
+3. Once the feature installation completes, restart your server.
+
+> After restarting, your Server Manager may show red indicators - this is normal and expected at this stage.
+
+
+
+### Promoting to Domain Controller
+
+
+1. We are going to configure this server step by step to handle all the issues. Open the AD DS tab and promote this machine to being a Domain Controller.
+
+> **Note:** You will likely see a yellow message saying "configuration required" - this is what we're addressing now.
+
+
+
+
+2. When you attempt to promote this machine to a Domain Controller, an Active Directory Domain Services Configuration Wizard should appear. Work through the wizard.
+
+> Continue through the initial setup screens of the configuration wizard.
+
+
+
+
+3. When it comes to choosing your domain, use a similar naming style as we used for the machine names. Create a new forest and set your domain to FirstInitialLastName.soc (e.g., tphao.soc).
+
+> **Important:** This domain name will be used throughout your other DNS services like Splunk later in the lab.
+
+
+
+
+4. Continue through the wizard and complete promoting this VM to being a Domain Controller.
+
+> Follow the remaining prompts in the wizard, accepting the default settings unless you have specific requirements.
+
+
+
+### Post-Promotion Configuration
+
+
+1. Once promotion is complete, a restart will occur where the Group Policy Client gets installed. You should see a user appear with the first part of the root domain you chose (e.g., JMama\ADMINISTRATOR).
+
+> Log in with the password you set beforehand - this is now your Administrator account for your Domain.
+
+
+
+
+2. Now that you have completed the domain setup, you can explore your domain by opening Active Directory Users and Computers.
+
+> Right-click and manage the new domain you created. You can see default created organizational units (OUs), users, group policy objects, etc.
+
+> Let's open up the folder called Users and create a user inside there. I am going to call mine Test and use this as an account to test if my clients join the domain successfully and I can login under this domain.
+
+
+
+### Lab Progress Check
+
+At this point in the lab, you should be proud of what you have accomplished:
+
+- ✅ Deployed a Windows Server 2019 Virtual Machine
+- ✅ Loaded necessary drivers for Virtual Hard Disk and Virtual Networking
+- ✅ Utilized the virtual router and 1:1 NAT to remotely access your machine
+- ✅ Set static names and IP addresses for VM stability
+- ✅ Installed Windows Server features like Active Directory Domain Services
+- ✅ Promoted the VM to a Domain Controller
+- ✅ Created a domain for clients to join
+
+### Final Verification
+
+
+1. As a final check before continuing, open PowerShell and run the following command to verify domain membership:
+
+```powershell
+Get-CimInstance Win32_ComputerSystem | Select-Object Domain, PartOfDomain
+```
+
+Your results should look similar to this:
+
+```
+Domain PartOfDomain
+------ ------------
+tphao.soc True
+```
+
+
+
+### What's Next?
+
+We are going to proceed with adding clients to this domain and joining Windows 10 client machines to our newly created domain!
+
+## Windows Client - 1
+
+Now that you are experienced in deploying virtual machines in our environment, the instructions will be less guided and focus on specific goals and objectives.
+
+### Windows 10 Installation
+
+
+1. Start up one of your two Windows 10 virtual machines and proceed with completing the installation on the VM.
+
+> Follow the standard Windows 10 installation process. The steps should be familiar from the Windows Server installation you just completed.
+
+
+
+### Client Configuration
+
+
+1. Once Windows 10 boots, set a static IP for this machine to ensure network stability.
+
+> Use a different IP address than your Domain Controller, but within the same subnet (e.g., if your DC is `192.168.1.116`, use `192.168.1.117` for the client).
+
+> Note for the DNS settings, set your primary DNS to be the same IP as your domain controller!
+
+
+
+2. Set a common name for this PC following our naming convention: FirstInitialLastName-client01 (e.g., JMama-client01).
+
+> This naming convention helps maintain consistency across your lab environment and makes it easier to identify different machines.
+
+
+
+### Joining the Domain
+
+
+1. Now we are going to join the domain we created earlier (e.g., JMama.soc). Locate the field where you can join this computer to that domain.
+
+> **Hint:** Look in the System Properties under "Computer name, domain, and workgroup settings." You'll need to change from a workgroup to a domain.
+
+
+
+2. When prompted for credentials during the domain join process, use your Domain Administrator account.
+
+> Use the domain administrator credentials you set up on your Domain Controller (e.g., `JMama\Administrator`).
+
+
+
+### Domain Login Testing
+
+
+1. If configured correctly and joining the domain was successful, log out and log back in using the test account we created on the Domain Controller.
+
+> Switch from the local machine login to the domain login. You should be able to select your domain from the login screen and use the test account credentials.
+
+
+
+2. If you forgot your test account password, resetting it on the Domain Controller is easy - simply right-click the user in Active Directory Users and Computers and select "Reset Password".
+
+> This demonstrates the centralized user management capability of Active Directory.
+
+
+
+
+### What's Next?
+
+Congratulations! You now have a Windows 10 client successfully joined to your Active Directory domain. This client can now authenticate against your Domain Controller and access domain resources based on the permissions you configure.
diff --git a/source/Splunk.md b/source/Splunk.md
index 2fc1f03..0885ec8 100644
--- a/source/Splunk.md
+++ b/source/Splunk.md
@@ -54,6 +54,8 @@ Splunk is a log aggregator used to centralize logs and data. At the SOC we are u
Double click on the .msi file you downloaded and follow the instructions to install.
## How to setup the Splunk Universal Forwarder
-
+The Splunk Universal Forwarder is installed on endpoint devices to gather logs and send them back to your Splunk Server.
+Download the correct Splunk Universal Forwarder for the endpoint device.
+- GO to Splunk to download the SUF
## How to setup a Splunk Deployment Server
diff --git a/source/Splunk_Lab.md b/source/Splunk_Lab.md
index 3fe0d8a..460d6c9 100644
--- a/source/Splunk_Lab.md
+++ b/source/Splunk_Lab.md
@@ -1,192 +1,225 @@
# Welcome to the Splunk Lab
## Overview
-In this lab we will teach you how to setup your own Splunk server. You will also learn how you can forward logs from different endpoint devices to your Splunk logs, aka ingesting logs. After you get comfortable ingesting logs we will also be generating our own log sources and learning how we can ingest those logs too.
+
+In this lab, we will teach you how to set up your own Splunk server. You will also learn how you can forward logs from different endpoint devices to your Splunk logs, aka ingesting logs. After you get comfortable ingesting logs, we will also be generating our own log sources and learning how we can ingest those logs too. At the end of this lab, you should be comfortable with operating between different operating systems, familiarity with terminal, and how to parse different types of logs across different operating systems.
### Technologies you will use
-- Splunk Enterprise
+
+- Splunk
- Splunk Universal Forwarder
- Linux - Debian
- Windows
- Sysmon
-As more and more people complete the beginner lab we will start working on a more advanced lab for people interested in learning more about Splunk.
+As more people complete the beginner lab, we will start working on a more advanced lab for people interested in learning more about Splunk.
## Lab Structure
-1. We give you a task. We want you to figure out as much as you can by yourself so the instructions will be very minimal.
-2. If you get stuck on a task feel free to take a look at the hints section.
-3. Don't be discouraged as we also share the answers.
-
-## Setup
-You have 2 options for this lab. To follow along this lab you can either use the SDC cloud or use your local machine to build the lab. I recommend the SDC cloud as it is simpler than trying to install your own virtual machine on your own computer.
+1. We give you a task. We want you to figure out as much as you can by yourself, so the instructions will be very minimal.
+2. If you get stuck on a task, feel free to take a look at the hints section.
+3. Don't be discouraged, as we also share the answers.
-### Cloud instance
-
-1. First you will need to download and install [Pritunl](https://client.pritunl.com/#install)
+## Setup
-2. Next contact the Student Data Center to get VPN credentials
+To follow along with this lab, you can use the Student Data Center to provision your virtual machines and get comfortable with the remote/cloud environment. Setting this up locally on your own hardware is possible, but these instructions will not outline the setup there.
-3. Import the profile provided to you by the MC Hill bot. Dont enter a profile url
+1. Start reading through [Getting Started](https://wiki.cppsoc.xyz/en/latest/getting_started.html).
-4. Once Imported, connect to the sdc_vpn and use the credentials given to you
+2. Request Login Credentials (AD) from a Student Director.
-5. Open up a web browser and navigate to https://kamino.calpolyswift.org/#/
+3. Login to [Kamino](https://kamino.sdc.cpp).
-6. Register an account and login
+4. Create a pod based off our Template: `SOC intro splunk lab - Splunk Lab 2025`.
-7. Create a pod
+5. Provisioning these pods takes a bit of time; refresh the page periodically to see if 3 Virtual Machines and 1 pfSense Router are created.
-8. In a new tab navigate to https://elsa.sdc.cpp/
+6. Login to [Proxmox VE](https://proxmox.sdc.cpp) to see your provisioned virtual machines in detail.
-9. Login using the account you created in step 6
+ > After you log in, we recommend changing your view mode at the top left to 'Pool View' to better see the VMs and Resource Pool Assigned to you.
-10. Power on the VMs provided
+7. Power on the VMs provided to you.
You are now ready to start the lab.
+## Tips
-### Local Instance
+> **Tip #1: Slow Download Speeds?**
+> The SDC is running into internet speed issues depending on where your Virtual Machine is being hosted. In more detail, depending on your Virtual Machine's location, your download speeds over the WAN might be at kb/s when downloading packages, etc.
+>
+> A cool workaround we have at the moment is that the LAN is not speed-limited at all. If you have a machine that is on the same network (Your Laptop or PC connected to GlobalProtect VPN), you can use a command-line utility called `scp` (Secure Copy) to actually copy files through your remote shell over to the target machine. This will make more sense for Task #1 specifically, but this is your introduction to the `scp` command.
-1. Download and install Virtual Box or Vmware Player
-2. Download the Debian ISO file
-3. Create a new VM using the Debian ISO file
-4. Start the VM
-Install Splunk on a debian machine.
+> **Tip #2: External Accessibility**
+> On top of that, with that pfSense router provisioned to you, your VMs in your resource pool are 'externally' accessible! 'Externally' in quotes because anyone on the GlobalProtect VPN can access it if they know the subnet and IP of your machines. This is not 'externally' as in on the WAN of the GlobalProtect router. So using the `scp` command-line in combination with knowing how the router is configured will allow you to do many more things outside of the 'Proxmox Virtual Environment', but allow you to SSH into your Virtual Machines and or RDP into your Windows Clients.
+## Task 1 - Setting up Splunk Enterprise Server
-## Task 1 - Setting up Splunk Server
-After you complete the setup of the lab, we will now work with the vm called "debian".
+After you complete the setup of the lab, we will now work with the VM called "server-debian-clone".
-The task is to create our very own Splunk server. When I say create I simply mean install the Splunk Enterprise Trial. So see if you can install that on the debian vm.
+The task is to create our very own Splunk server. When I say create, I simply mean install the Splunk Enterprise Trial. So see if you can install that on the Debian VM.
-If you are stuck or donno where to start check the hints. Good luck!
+If you are stuck or don't know where to start, check the hints. Good luck!
### Hints
-
+
+
Hint 1
-You can download the installer at https://www.splunk.com/
-
You will need a Splunk account.
+You can download the installer at https://www.splunk.com/.
+You will need a Splunk account.
-
+
Hint 2
-We need a way to install the package we just downloaded. In debian we can use the dpkg command to install packages.
+We need a way to install the package we just downloaded. In Debian, we can use the `dpkg` command to install packages.
-
+
Hint 3
-Just because you installed it doesnt mean its running.
+Just because you installed it doesn't mean it's running.
### Answer
-
+
Answer
-
+
You sure?
-Download the Splunk Enterprise Trial with the command below
-
-
-wget -O splunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb "https://download.splunk.com/products/splunk/releases/9.2.1/linux/splunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb"
-
-
-Navigate to the folder you downloaded the file and run the command
-
-dpkg -i plunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb
-
-
-Navigate to the folder /opt/splunk/bin and run
-
-cd /opt/splunk/bin
-./splunk start
-
-
-Open up firefox and browse to localhost:8000
-Login with the user account you created when installing Splunk
+
+1. **Download the Splunk Enterprise Trial:**
+ Use the following command to download the installer:
+ ```bash
+ wget -O splunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb "https://download.splunk.com/products/splunk/releases/9.2.1/linux/splunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb"
+ ```
+ > **Note on slow downloads:** If `wget` is slow, you can download the file on your local machine and use `scp` to transfer it to your VM. For example:
+ > ```bash
+ > scp ./splunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb root@172.16.x.xxx:/path/on/vm
+ > ```
+
+2. **Install the package:**
+ Navigate to the directory where you downloaded the file and run:
+ ```bash
+ dpkg -i splunk-9.2.1-78803f08aabb-linux-2.6-amd64.deb
+ ```
+
+3. **Start Splunk:**
+ Change to the Splunk binary directory and start the service:
+ ```bash
+ cd /opt/splunk/bin
+ ./splunk start
+ ```
+ You will be prompted to accept the license and create an administrator account.
+
+4. **Access Splunk Web:**
+ Open a web browser on your VM and go to `http://localhost:8000`. Log in with the credentials you just created.
+
+## Task 2 - Forwarding Logs from a Windows Machine to your Splunk Server
+Congratulations! If you made it this far, that means you successfully set up your own Splunk server!
-## Task 2 - Forwarding Logs to Splunk
-Congratulations if you made it this far that means you successfully setup your own Splunk server!
+If you haven't already, I encourage you to explore the UI of Splunk. It will be quite a lot to absorb at first, but I promise you, as you keep using Splunk, you will get used to the UI.
-If you havent already, I encourage you to take explore the UI of Splunk. It will be quite a lot to absorb at first but I promise you as you keep using Splunk you will get used to the UI.
-
-Now that we set up a Splunk server we need to figure out how we can ingest logs into it. We ingest logs using something called the Splunk Universal Forwarder. This is a tool installed on an endpoint device that tells the computer which logs to send and where to send them.
+Now that we have set up a Splunk server, we need to figure out how we can ingest logs into it. We ingest logs using something called the **Splunk Universal Forwarder**. This is a tool installed on an endpoint device that tells the computer which logs to send and where to send them.
Task 2 is to install the Splunk Universal Forwarder on the Windows Client and see if you can query the logs using the Splunk Search App.
-If you are able to see data when searching index=main you have successfully completed the task.
+If you are able to see data when searching `index=main`, you have successfully completed the task.
### Hints
-
+
+
Hint 1
-You can also download the Splunk Universal Forwarder at https://www.splunk.com/
-
You will need a Splunk account.
+You can also download the Splunk Universal Forwarder at https://www.splunk.com/.
+You will need a Splunk account.
-
+
Hint 2
Did you configure your Splunk server to listen?
Did you open up firewall ports?
-
+
Hint 3
-When you install the Splunk Universal Forwarder in the customize option make sure you are installing with the local account. Using a virtual account may not send logs due to permission issues.
+When you install the Splunk Universal Forwarder, in the customize option, make sure you are installing with the local account. Using a virtual account may not send logs due to permission issues.
### Answer
-
+
+
Answer
-
+
You sure?
-Download the Splunk Universal Forwarder. You can either log into the Splunk website with your account and download the windows version. Or do the same with this command
-
-
-wget -O splunkforwarder-9.2.1-78803f08aabb-x64-release.msi "https://download.splunk.com/products/universalforwarder/releases/9.2.1/windows/splunkforwarder-9.2.1-78803f08aabb-x64-release.msi"
-
-
-Navigate to the folder you downloaded the file and run the msi file
-Agree to the license and install using custom options. Make sure to choose option local account. Select any logs you want to forward. Input the IP address of the Splunk server and use the default ports.
-
-Open up Windows Firewall and open up outbound ports for TCP AND UDP for 8089 and 9997.
-
-On your Splunk Server login using the credentials you created and go to Settings->Forwarding and Receiving and nder the Receive Data section click on +Add New. Enter 9997 as listening port and save.
-
-Go to your Splunk Search Head and search index=main.
-You should see data in this index after a few minutes.
-
-
+
+1. **Download the Splunk Universal Forwarder:**
+ You can either log into the Splunk website with your account and download the Windows version, or use this command:
+ ```powershell
+ Invoke-WebRequest -Uri "https://download.splunk.com/products/universalforwarder/releases/9.2.1/windows/splunkforwarder-9.2.1-78803f08aabb-x64-release.msi" -OutFile splunkforwarder-9.2.1-78803f08aabb-x64-release.msi
+ ```
+
+2. **Install the Forwarder:**
+ - Navigate to the folder where you downloaded the file and run the `.msi` installer.
+ - Agree to the license and install using custom options.
+ - Make sure to choose the **local account** option.
+ - Select any logs you want to forward.
+ - Input the IP address of the Splunk server and use the default ports.
+
+3. **Configure Firewall:**
+ - Open up Windows Firewall and create outbound rules for TCP and UDP for ports `8089` and `9997`.
+
+4. **Configure Splunk Server:**
+ - On your Splunk Server, log in and go to `Settings` -> `Forwarding and Receiving`.
+ - Under the "Receive Data" section, click on `+Add New`.
+ - Enter `9997` as the listening port and save.
+
+5. **Verify Data Ingestion:**
+ - Go to your Splunk Search Head and search `index=main`.
+ - You should see data in this index after a few minutes.
+
+
+
+## Task 3 - Forwarding Logs from a Ubuntu Client to your Splunk Server
+
+With this task, it will be similar in its function with the previous forwarder task. Your goal is to install a forwarder on a client, but this time, Linux-based.
+
+There will be less of a GUI to use, unlike Windows, so you will be mainly operating out of your terminal.
+
+I have removed the hints from this section but will give you the short rundown of what you need:
+
+- Find a `.deb` package from [splunk.com](https://download.splunk.com) for a Universal Forwarder (UF) for a Debian-based machine.
+- The installation steps will be similar to installing your Splunk Server, like reading through the EULA and starting the forwarder.
+- You will also need to make `iptables` rules, similar to how you created firewall rules on Windows, to communicate with your Splunk Server.
+
+Good Luck!
+
+If you struggle with this, that is okay. That was the goal of this task, and instead of walking you through it, you can ask a Student Director for help!
+
+## Task 4 - Generating Custom Log Sources
-## Task 3 - Generating Custom Log Sources
-If you come this far pat yourself on the back!
-You essentially now have a good understanding on how logs are ingested into Splunk and you know how to query the data.
+If you have come this far, pat yourself on the back! You essentially now have a good understanding of how logs are ingested into Splunk, and you know how to query the data.
+Task 4 is to install Sysmon and ingest the logs Sysmon generates into Splunk.
-Task 3 is to install Sysmon and ingest the logs Sysmon generates into Splunk.
+If you enjoyed this lab and want to learn more, feel free to reach out to us on Discord!
-
-If you enjoyed this lab and want to learn more feel free to reach out to us on Discord!
+## Task 5 - Custom Indexes
-## Task 4 - Custom Indexes
-Wow you really must like Splunk if you came this far ;)
-Notice how all your indexes are being sent to main by default. Imagine ingesting 100s of log sources into main. How messy does that look. It would also be a nightmare querying specific data and very inefficient.
+Wow, you really must like Splunk if you came this far! ;)
-Task 4 is to create a new index and change the behaviour of the Universal Forwarder.
-Let create an index called Sysmon and forward the Sysmon logs to this index called Sysmon instead of main.
+Notice how all your indexes are being sent to `main` by default. Imagine ingesting hundreds of log sources into `main`. How messy does that look? It would also be a nightmare and very inefficient to query specific data.
+Task 5 is to create a new index and change the behavior of the Universal Forwarder. Let's create an index called `sysmon` and forward the Sysmon logs to this index instead of `main`.
+## What's next?
-## Whats next?
-Congratulations you have completed the Splunk Lab!
+Congratulations, you have completed the Splunk Lab!
-Hope you enjoyed the lab! If you want to work on more Splunk stuff or like what you see at the SOC, I encourage you to get involved and start working on your own cool project :). You are now dubbed Splunk Pro!
+Hope you enjoyed the lab! If you want to work on more Splunk stuff or like what you see at the SOC, I encourage you to get involved and start working on your own cool project :). You are now dubbed a Splunk Pro!
Stay tuned for a more advanced Splunk Lab where we plan to tackle the following questions:
--How do I scale my Splunk deployment?
--How do I make my Splunk server more resilient?
--How do I increase search performance?
\ No newline at end of file
+- How do I scale my Splunk deployment?
+- How do I make my Splunk server more resilient?
+- How do I increase search performance?
diff --git a/source/Volunteers.md b/source/Volunteers.md
index 8dacfec..997a4c7 100644
--- a/source/Volunteers.md
+++ b/source/Volunteers.md
@@ -20,4 +20,31 @@ All Cal Poly Pomona students are welcome to volunteer at the Security Operations
**How can you start?**
- Join our discord server -> [Join](https://discord.gg/yYGXJmb3d2)
-- Visit the SOC on campus -> Building 98 5C-15
\ No newline at end of file
+- Visit the SOC on campus -> Building 98 5C-15
+
+---
+
+## 📚 Contribute to Our Documentation!
+
+**Why is documentation important?**
+- Documentation helps us keep a clear, detailed record of our work and processes.
+- It empowers students to learn and improve their understanding of how the SDC and SOC operate.
+
+**How can you help?**
+- Take initiative! Help us write and improve documentation to support our organization and your peers.
+- Our GitHub Organization ([cpp-soc](https://wiki.cppsoc.xyz/)) is public and open for contributions via pull requests.
+
+**Getting Started:**
+1. **Fork or create a new branch** from `main` or `master`.
+2. **Create or edit a Markdown file** in
+ ```
+ documentation/source/
+ ```
+3. **For new pages:**
+ - Update
+ ```
+ documentation/source/index.md
+ ```
+ so your page appears in the sidebar!
+4. **Adding images:**
+ - If you can't add images directly to RTD Source, you can host them at [cppsoc.xyz](https://cppsoc.xyz).
diff --git a/source/getting_started.md b/source/getting_started.md
new file mode 100644
index 0000000..96b813b
--- /dev/null
+++ b/source/getting_started.md
@@ -0,0 +1,28 @@
+# Getting Started Guide
+
+## Introduction
+
+Hello everyone! I am creating this page to help improve your start process at either the **Student Security Operations Center (SOC)** or the **Student Data Center (SDC)**.
+
+All operations done on either side will require you to connect to our VPN to access any resources we host.
+
+## VPN Access Setup
+
+1. **Request Access**: Please fill out this Microsoft Form for User Access to our VPN. [Form](https://forms.cloud.microsoft/r/5BtvPPTJku)
+2. **Install VPN Client**: If you have never logged in to Kamino, please install Palo Alto's GlobalProtect application. We are now completing authentication using Cal Poly Pomona's SSO. [GlobalProtect](https://vpn.connect.cpp.edu)
+3. **Initial Connection**:
+ - After installing the application, you will be prompted with the following windows 
+ - When asked to enter our Portal Address use: `mgmt.sdc.cpp.edu`
+ - This will prompt you to login using Cal Poly SSO
+
+> Note: Access to the Management VPN Portal depends on when you submitted the User Access Request through Microsoft Forms.
+
+## Accessing Kamino
+
+1. Once you are given access to Management Portal, head over to [https://kamino.sdc.cpp](https://kamino.sdc.cpp)
+2. This is only available when you are connected to the VPN
+3. Use your Active Directory (AD) Credentials to Login
+
+If you do not have credentials or do not remember the details, ask a Student Director to help resolve this for you.
+
+---
\ No newline at end of file
diff --git a/source/index.md b/source/index.md
index 11c3f52..22dbfb0 100644
--- a/source/index.md
+++ b/source/index.md
@@ -7,6 +7,9 @@ Here lies the documentation of the Student run Security Operations Center at the
:maxdepth: 2
Volunteering Opportunities
+Getting Started (Updated August 2025)
Splunk
Splunk Lab
+AD + Splunk Lab
+Missile Map
```
\ No newline at end of file
diff --git a/source/missile_map.md b/source/missile_map.md
new file mode 100644
index 0000000..7206807
--- /dev/null
+++ b/source/missile_map.md
@@ -0,0 +1,132 @@
+# How the Student SOC Implemented Missile Map!
+
+## Background
+
+After a major rebuild of the infrastructure at the Student Data Center, the Student Security Operations Center (SOC) found that many legacy monitoring processes no longer applied. One critical need was auditing GlobalProtect VPN activity to understand who was connecting to the network and from where. The SOC wanted better visibility into VPN usage and potential anomalies, especially given the changes post-rebuild. To achieve this, they leveraged Splunk SIEM for log collection and even integrated a special map visualization to track user VPN connections geographically.
+
+## Initial Challenges with VPN Log Queries
+
+In the beginning, querying the GlobalProtect VPN logs in Splunk for *"successful"* logins led to confusing and misleading results. The initial Splunk query was intended to filter for successful connection events, but it ended up including a huge volume of logs from around the world – even places like Russia, Africa, and Asia – suggesting hundreds of thousands of VPN login attempts. This was obviously alarming and pointed to something being off with the query or the logs forwarded.
+
+The root issue was that the log fields were ambiguous. Some events were being marked with fields: action or status with *"success"* even when the login actually failed. For example, certain logs showed an action field of *"success"* but, upon inspecting details, the same log would contain an error message like *"Authentication failed: Invalid username or password
+"*. In some cases, the username field (`src_user`) was literally set to `"success"`, which clearly was not a real user account but rather a misinterpreted field. These were false positives that made it look like users from all over the globe were connecting, when in reality they were failed login attempts or automated brute-force attempts being logged in a misleading way.
+
+
+
+
+To illustrate the problem, the SOC’s first query was roughly:
+
+```splunk
+index="netfw" sourcetype="pan:globalprotect" status=success
+| iplocation src_ip
+| eval start_lat=lat, start_lon=lon, end_lat=34.0597, end_lon=-117.8200
+| stats count by start_lat, start_lon, end_lat, end_lon, src_ip
+```
+
+This attempted to find any logs with the term *"success"* and map their source IP locations. However, it swept up events that were not true successes. The resulting visualization showed an explosion of connection lines from virtually every continent, which was not an accurate picture of actual VPN usage. As shown below, the initial query’s output (on a world map) was cluttered with false-positive connections:
+ *Note: image below was taken on 9/13 and I restricted the view to up to 9 hours for the purposes of proper and useful visualization*
+
+
+The team investigated a few suspicious log entries to understand why they were being counted as successful. They found, for instance, logs where the user field was set to “success” and the action was “success” as well – yet further details in the log indicated a bad password. In contrast, a truly successful login log would show a real username and no such error. The screenshot below compares a suspicious log vs. a clean log in Splunk: the left side event is flagged as *"success"* but is actually a failed login attempt (with an error in the details), whereas the right side is a genuine successful VPN connection event.
+
+*Comparison of a suspicious "success" log (left) vs. a genuine successful login log (right)*
+
+
+Below is a proper login where an individual logged out and fields are marked properly, redacted parts are PII.
+
+
+This initial hurdle highlighted that not all *"success"* logs were equal. The SOC needed a better way to filter the data so that only true successful VPN connections would be visualized.
+
+## Portal Types Overview
+
+While auditing the GlobalProtect logs to solve the above mystery, the team discovered that logs referenced multiple “portal” types. GlobalProtect has a concept of portals and gateways, and the logs contained a field (`portal`) that could take on values like `gp-user`, `gp-user-portal`, `gp-mgmt`, `gp-mgmt-portal`, etc. Through careful analysis and by correlating with known VPN URLs, the SOC deciphered the meaning of each:
+
+* **`gp-mgmt-portal`**: This corresponds to the main GlobalProtect management portal – essentially the web interface or SSO login portal used by authorized users. In our case, this is the portal at `mgmt.sdc.cpp.edu` that staff would normally use to authenticate (it uses single-sign-on/SAML for authentication). It handles the user login process (authenticating credentials via SSO) before the VPN tunnel is established.
+* **`gp-mgmt`**: This refers to the GlobalProtect gateway management process that takes over after a user is authenticated. Once you successfully log in via the portal, the system uses `gp-mgmt` to actually set up the VPN connection (assign an IP, establish the tunnel, etc.). In short, `gp-mgmt` events are part of establishing the connection once credentials are validated.
+* **`gp-user-portal`**: This turned out to be a secondary (and deprecated) user portal that does not use SSO. In our environment this was the URL `vpn.sdc.cpp.edu`, which presents a simple username/password login screen. It was legacy and supposed to be retired, but our audit revealed it was still running. Essentially, `gp-user-portal` logs indicate someone using this older portal login page (likely with a local account credential). We only discovered its significance when we noticed logins coming from external universities and unexpected locations – those users were accessing this portal during special events.
+* **`gp-user`**: Similar to `gp-mgmt` above, `gp-user` refers to the connection process initiated via the user portal. If someone logs in through the `gp-user-portal` (the old login page), the system then generates `gp-user` events to handle the VPN connection setup for that session.
+
+The SOC initially assumed only one portal was relevant (the main SSO portal `mgmt.sdc.cpp.edu`) and perhaps also the campus-wide VPN (`vpn.connect.cpp.edu` managed by central IT). The log analysis, however, exposed that two different portal interfaces were in play for the Student Data Center: the expected SSO portal and the forgotten legacy portal. This discovery was pivotal – it explained why there were logs of connections from places and organizations that didn’t line up with our usual user base. Those turned out to be external participants (for instance, students from other universities) who were given access during events like SWIFT competitions or tryouts, using the legacy portal that was opened up for them.
+
+## Security Concerns with the Legacy Portal
+
+Uncovering the existence of `vpn.sdc.cpp.edu` (the `gp-user-portal`) raised immediate security concerns. This portal uses only a basic username/password authentication without the protection of single sign-on or multifactor, and it was exposed to the internet for the sake of external user access. As a result, it had become a target for brute-force login attempts. The Splunk logs clearly showed automated attacks hitting this portal – the source of the “success” noise was largely bots or malicious actors trying to guess passwords on the public-facing login page.
+
+Having a deprecated portal publicly accessible is a risk, but at the time the SOC faced a dilemma: they needed this portal to remain available during certain external events (where non-Cal Poly users needed VPN access to participate, and those users could not use our SSO). During events like the SWIFT tryouts, the legacy portal was intentionally left open so outside participants could log in with credentials we provided them. This was a temporary necessity that unfortunately expanded our attack surface.
+
+The screenshot below shows what the `vpn.sdc.cpp.edu` login interface looks like – a simple login form without SSO. This simplicity is exactly what makes it a brute-force target, as any internet user can reach this page and attempt to log in:
+
+*Legacy VPN Portal login page (vpn.sdc.cpp.edu) with basic username/password prompt*
+
+
+### Brute-force exposure
+With just a username and password field and no second-factor or SSO, bots around the world constantly probed this portal. The SOC observed many login attempts from foreign IPs (which initially masqueraded in the logs as “successful” due to the logging quirk). This underscored the importance of a plan to either better secure this portal (rate limiting, MFA, or network restrictions) or fully decommission it as soon as external-event needs allow.
+
+## Improved Log Fingerprinting for True Successes
+
+To filter out the noise and focus only on truly successful VPN connections, the SOC refined their Splunk queries using a more reliable field: `event_id`. By examining the available event identifiers in the GlobalProtect logs (Splunk makes it easy to see distinct field values, as shown below), they found that one specific event code consistently corresponds to a completed VPN login. The `event_id` field value `gateway-connected` is logged only when a GlobalProtect client has successfully connected to the gateway (i.e., the VPN tunnel is fully established)[1]. This is exactly the kind of event they wanted to track.
+
+*Splunk interface showing sample event_id field values (including "gateway-connected")*
+
+According to Palo Alto Networks’ documentation, a `gateway-connected` event “indicates a GlobalProtect client successful connection for tunnel or non-tunnel mode”[1] – in other words, a real VPN session. Armed with this knowledge, the SOC adjusted their Splunk search to zero in on those events and ignore the rest. They also narrowed the search to the relevant portals (`gp-mgmt` and `gp-user`, which are the ones that produce the gateway connection logs after authentication).
+
+The refined Splunk query looked something like this:
+
+```splunk
+index="netfw" sourcetype="pan:globalprotect" (portal="gp-mgmt" OR portal="gp-user") event_id="gateway-connected" src_user=*
+| iplocation src_ip
+| eval start_lat=lat, start_lon=lon, end_lat=34.0597, end_lon=-117.8200
+| stats count by action, src_user, src_ip, start_lat, start_lon, end_lat, end_lon
+```
+*As of 9/23, 'sourcetype' was no longer a applicable field to search by or to be included when we searched on Splunk. It could be fixed, but below is the refined search query.
+```splunk
+index="netfw" (portal="gp-mgmt" OR portal="gp-user") event_id="gateway-connected" src_user=*
+| iplocation src_ip
+| eval start_lat=lat, start_lon=lon, end_lat=34.0597, end_lon=-117.8200
+| stats count by action, src_user, src_ip, start_lat, start_lon, end_lat, end_lon
+```
+
+Let’s break down what this does:
+- **Base search**: We search the firewall logs (`index="netfw"`) of type `pan:globalprotect` for events where the `portal` field is either `gp-mgmt` or `gp-user` (i.e. the connection-establishment stage for either portal) and `event_id="gateway-connected"`. We also ensure `src_user=*` to pick up only events tied to a user account (excluding any system or empty entries).
+- **Geo IP lookup**: Using Splunk’s `iplocation` command on the source IP (`src_ip`) populates latitude (`lat`) and longitude (`lon`) fields based on geo-IP data.
+- **Define map coordinates**: We then create `start_lat`/`start_lon` from the looked-up coordinates (the user’s approximate location), and set a fixed `end_lat`/`end_lon` corresponding to our campus’s CLA Building location (roughly 34.06 N, -117.82 W in Pomona, CA). This essentially prepares the data for mapping an arc from the user to the campus.
+- **Stats aggregation**: Finally, we use `stats count by ...` to group events. In practice, for visualization we might not even need the count, but this method ensures we have one line per unique combination of user and location. The `action` field (which in these events should indicate "success/allow") can also be included just for reference.
+
+With this refined “fingerprint” query, false positives disappeared. Only genuine successful VPN connection events were returned. The volume of events was now sane (e.g., dozens per day instead of thousands) and the sources were all expected user locations. This was the “silver bullet” the team was looking for to get clean data for visualization.
+
+## Missile Map Implementation (Geographic VPN Visualization)
+
+Having obtained clean data on successful VPN connections, the SOC proceeded to implement the Missile Map visualization in Splunk. Missile Map is a Splunk app/visualization that displays data as arcs on a world map[2] – much like the “cyber attack” maps often seen in security dashboards. Each arc requires a starting and ending coordinate. In our case, the starting point is the geographic location of the user’s IP address, and the ending point is the fixed location of Cal Poly Pomona’s CLA Tower (representing our data center).
+
+We configured the Missile Map by providing it the fields it expects (our query already yielded `start_lat`, `start_lon`, `end_lat`, `end_lon` for each event)[3]. We chose a fixed color for the arcs and set the map’s center/zoom to focus on the areas of interest. Every time a new VPN login occurs and meets our query criteria, the dashboard displays a new arc from the user’s city to campus. Because all arcs share the same destination (Pomona, CA), the visualization looks like a set of missiles or arrows converging on a single point – hence the name “Missile Map.”
+
+We also included additional context in the data points if needed. For example, we could label arcs with the username or mark if an event came from the legacy portal vs the main portal (using different colors or labels). In this case, since we filtered out the legacy portal’s unsuccessful noise and only tracked actual connections, most arcs represent valid user sessions. If any unusual connection does appear (say, a valid login from an atypical country), it stands out prominently on the map for further investigation.
+
+Below is a placeholder for what the final Missile Map dashboard looks like. The real visualization shows a world map with arcs originating from various user locations (across the U.S. and occasionally abroad) all terminating at the CLA Building location in California:
+
+*Missile Map visualization of VPN connections (each arc from user’s geolocation to campus)*
+
+*Figure: The Missile Map in Splunk showing successful VPN connections. Each arc represents a user VPN session connecting from the origin (determined by IP geolocation) to the campus network (destination fixed at CLA Building coordinates). We can see, for example, connections coming from other parts of California, some from out-of-state (perhaps students traveling or out-of-state participants during events), and so on. The map gives an immediate sense of where users are connecting from and can reveal patterns (like clusters of connections from an unexpected region).*
+
+By integrating this Missile Map, the Student SOC significantly improved its situational awareness. Rather than combing through text logs, analysts can glance at the dashboard and spot if something looks off (such as an arc from an unusual country or an unusually high number of arcs at once which might indicate a surge in usage or an event).
+
+## Data Anomalies & Lessons Learned
+
+Throughout this project, a few anomalies were discovered in the data, underscoring lessons for the team:
+- **Geo-IP mismatches**: On a few occasions, the user’s IP address and the provided geolocation did not line up. For example, one user’s IP traced to a Southern California ISP, yet the latitude/longitude from `iplocation` placed the point in New York. In another case, a user’s IP was clearly from Florida, but the geo lookup showed a location in Illinois. These discrepancies might be due to outdated GeoIP data, VPN exit nodes, or how GlobalProtect reports location (possibly using a different source of geo info). It was a reminder that GeoIP isn’t 100% accurate – we saw “Florida user connecting from Illinois” which prompted us to double-check those cases manually.
+- **False success logs**: We learned that not all log fields mean what one might assume at face value. The presence of *"success"* in a log message or an action field did not always indicate a successful login. This was a critical lesson: always validate using reliable fields (in our case, `event_id="gateway-connected"` was the reliable indicator of success).
+- **Legacy portal noise**: The fact that a deprecated portal was still running led to a lot of noise in the logs. This taught us the importance of maintaining an accurate inventory of active services. If something is supposed to be retired but isn’t, it can both pose a security risk and muddy your monitoring data. We’ve since communicated this to the infrastructure team. The plan is to properly decommission or lock down `vpn.sdc.cpp.edu` when external events are not happening, and to explore more secure ways to grant guest access when they are.
+- **Visualization value**: Implementing the Missile Map has proven the value of visualization in security operations. Issues that were not obvious from raw logs became very clear when plotted geographically. For instance, seeing a line from an unexpected country immediately raises a flag to investigate if that was a legitimate user or something that slipped through.
+- **Continuous tuning**: Finally, we recognize that our queries and dashboards will need continuous tuning. As a next step, we might incorporate additional filters (for example, excluding any log where `src_user` equals `"success"` just as an extra sanity check, or updating our GeoIP database to the latest version to improve accuracy). We’re also considering setting up alerts for unusual patterns, such as multiple VPN connections from one foreign country in a short time or connections from countries where we normally have no users.
+
+## Summary
+
+The Student SOC’s implementation of the Missile Map was a success – both in terms of the technical Splunk solution and in the lessons learned along the way. We now have a clear, real-time view of VPN login activity, and we’ve hardened our approach to analyzing logs (focusing on the right markers and understanding the data better). This project not only helps us audit VPN usage but also has improved our security posture by highlighting an overlooked exposure and by giving us a tool to spot abnormal connection locations at a glance. The journey involved unraveling confusing logs, learning the ins and outs of GlobalProtect portals, and ultimately integrating an innovative visualization to make sense of it all. The result is an informative documentation and a powerful operations dashboard that can be used by future Student SOC members to monitor and investigate VPN activities efficiently.
+
+---
+
+[1] [Event Descriptions for the GlobalProtect Logs in PAN-OS](https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/logging-for-globalprotect-in-pan-os/event-descriptions-for-the-globalprotect-logs-in-pan-os)
+
+[2, 3] [GitHub - lukemonahan/missile_map: Missile Map Splunk visualisation](https://github.com/lukemonahan/missile_map)
+
+*AI used to improve language and markdown
\ No newline at end of file