Tate McCauley

GRC Is Not Boring

2026-07-10T00:00:00Z

GRC Is Not Boring

Ask a room full of security people what they think of GRC, and you can watch the energy leave the room. Governance, risk, and compliance is the part of the field everyone pictures as spreadsheets, screenshots, and a checklist that lands in your inbox once a quarter. It's the work that sounds like homework. If you got into security to break systems or defend them, GRC is the corner you were quietly hoping to avoid.

A year ago, I would have nodded along.

In my first series on this blog, I wrote about seeing security from two sides: the auditor and the analyst, the building inspector and the firefighter. I cast GRC as the inspector. Important, but a step back from the action. Careful, methodical, and if I'm honest, a little dry.

Then I graduated and went to work on the inspector's side of the coin full time, building compliance tooling at Paramify. I expected paperwork. What I found was the most interesting engineering problem I've worked on.

What the Work Actually Looks Like

My week is not spreadsheets. I build tools that reach into dozens of cloud accounts and pull back the evidence that proves a system is configured the way it's supposed to be. I've written agents that wake up on their own, notice a control has started failing, work out what changed, and write up why. The problems underneath are the same ones the rest of security cares about: handling credentials safely at scale, proving a system is actually in the state it claims to be in, and doing it continuously instead of once a quarter.

None of that is homework. It's distributed systems, automation, and increasingly AI. It just happens to live under a label most engineers wrote off years ago.

Why Now

The timing isn't an accident either. Compliance is going through the biggest shift it's had in years, and most of the industry hasn't noticed yet.

For a long time, compliance meant working through a long list of prescriptive controls and writing a document for each one. FedRAMP 20x, the newest version of the U.S. government's cloud authorization program, throws a lot of that out. Instead of asking whether you wrote a policy, it asks whether you can actually demonstrate a security outcome in a way a machine can check.

That one change turns compliance from a writing exercise into an engineering one. If the answer has to be machine-checkable, someone has to build the thing that checks it. That someone increasingly looks like a software engineer, and more and more like an AI agent.

I'll spend a whole post on FedRAMP 20x soon, because it earns one.

Why I'm Writing This

Partly because I think I'm early to something, and early is interesting. Partly because I'm learning as I go. GRC turned out to be a great place to learn, because the problems are real and the field is wide open.

Mostly, though, I want to change a few minds. If you've been avoiding this corner of security, I don't think you're seeing it clearly.

What's Coming Next

Over the next few posts I'll make the case and show my work:

why FedRAMP 20x is the most interesting thing happening in compliance, and what it actually changes
the tools I get to build, and the real problems hiding inside the "boring" work
where all of this goes as it becomes AI-native, and what I've learned trying to build for AI

This kicks off a new series that picks up where The Two Sides of the Cybersecurity Coin left off, this time from inside the GRC side of the coin.

Building a Real-Time Chat App: Lessons from Cloud Architecture

2025-12-31T00:00:00Z

Building a Real-Time Chat App: Lessons from Cloud Architecture

Over the past few months, I took a class on cloud architecture. As a senior in the cybersecurity program at BYU, we don't always spend a lot of time on pure software engineering or complex cloud architecture, so I was curious how the content I learned in this class would tie into the rest of my curriculum.

For the first few weeks, we went over what felt like a million different AWS acronyms. Knowing when to use one type of compute over another felt very theoretical, and I struggled to have a firm grasp on how to leverage these technologies practically. The final assignment was to create a "cookie-cutter" VPC for a hypothetical business using AWS Academy accounts. While useful, the restrictions meant we couldn't implement many features ourselves.

Fortunately, we were given the option to build our own project of a similar scale. I saw this as an opportunity to finally get hands-on and understand how AWS services actually work together.

The Goal: Real-Time Communication on a Student Budget

I decided to build a real-time chat application. It felt like a project that was just complicated enough to be impressive, but simple enough to demonstrate effectively.

I had two main constraints:

Serverless Architecture: I didn't want to manage EC2 instances or worry about patching servers.
Cost: It had to be as cheap as possible (ideally free).

AWS offers a generous (to me) free tier, and since I wasn't expecting thousands of users, a serverless approach using Lambda and DynamoDB seemed perfect. The free tier includes:

API Gateway: 1M messages/month free
Lambda: 1M requests + 400K GB-seconds/month free
DynamoDB: 25GB storage + 25 read/write units free

For the frontend, I stuck to my preferred stack of React + Vite.

The Architecture

Deciding how to architect this was the first big challenge. Real-time communication usually requires a persistent connection between the client and server. In a traditional setup, you might run a Node.js server with Socket.io. But in a serverless world, Lambda functions are ephemeral. They spin up, do a job, and die. They can't hold a WebSocket connection open.

The solution was AWS API Gateway v2 with WebSocket support.

graph TD
    Client[React Frontend] -->|WebSocket wss://| APIG[API Gateway]
    APIG -->|Messages| Client
    
    subgraph AWS["AWS Cloud"]
        APIG -->|Connect| Auth[Lambda: Authorizer]
        APIG -->|OnConnect| L_Conn[Lambda: onConnect]
        APIG -->|OnDisconnect| L_Disconn[Lambda: onDisconnect]
        APIG -->|SendMessage| L_Msg[Lambda: sendMessage]
        APIG -->|GetHistory| L_Msg
        
        L_Conn -->|Save Connection ID| DDB_Conn[("DynamoDB: Connections")]
        L_Disconn -->|Remove Connection ID| DDB_Conn
        
        L_Msg -->|Save Msg| DDB_Msg[("DynamoDB: Messages")]
        L_Msg -->|Read Active Users| DDB_Conn
        L_Msg -->|Broadcast via| APIG
        L_Msg -->|Query via GSI| DDB_Msg
    end

1. The Gateway (The "Doorman")

API Gateway acts as the persistent layer. It holds the WebSocket connection with the user. When a user sends a message, API Gateway triggers a Lambda function based on the route selection expression.

The route_selection_expression = "$request.body.action" tells API Gateway to route messages based on an action field in the JSON body. For example:

// Frontend sends: { action: 'sendMessage', message: 'Hello' }
// Frontend sends: { action: 'getHistory' }
// API Gateway routes based on the action field

In Terraform, setting this up was surprisingly concise. Instead of clicking through a hundred console menus, I defined the API protocol explicitly:

# terraform/api-gateway.tf

resource "aws_apigatewayv2_api" "websocket_api" {
  name                       = "${var.project_name}-websocket"
  protocol_type              = "WEBSOCKET"
  route_selection_expression = "$request.body.action"

  tags = {
    Name        = "${var.project_name}-websocket-api"
    Environment = var.stage_name
  }
}

2. The Database (DynamoDB)

I needed two tables:

Connections Table: Stores the connectionId of every user currently online.
Messages Table: Stores the chat history.

I used PAY_PER_REQUEST billing mode for both tables, which is perfect for unpredictable student project traffic. No need to provision capacity or worry about throttling.

One interesting optimization I learned was using Global Secondary Indexes (GSIs). To load chat history efficiently, I needed to grab the last 50 messages sorted by time. DynamoDB is a key-value store, not a relational database, so "SELECT * ORDER BY time" isn't free.

The trick is using a constant partition key. I set messageType='chat' for all messages, which allows me to query all messages sorted by timestamp. The GSI uses messageType as the partition key and timestamp as the sort key:

# terraform/dynamodb.tf

  global_secondary_index {
    name            = "TimestampIndex"
    hash_key        = "messageType"    # Partition key (constant: 'chat')
    range_key       = "timestamp"      # Sort key (allows time-based queries)
    projection_type = "ALL"
  }

This pattern lets me efficiently query: "Give me all chat messages sorted by timestamp, limit 50."

3. The Logic (Lambda)

The hardest part was the logic for broadcasting messages. Since Lambda doesn't "know" who is connected, it has to:

Read all active connectionIds from DynamoDB.
Loop through them.
Post the message back to API Gateway for each connection.

I also optimized for container reuse by creating AWS SDK clients outside the handler function. Lambda containers can be reused across invocations, so this avoids recreating clients on every request—a small optimization that reduces latency and overhead.

Here is a snippet of the broadcasting logic I wrote in Node.js:

// lambda/sendMessage.js

const broadcastMessage = async (apiGatewayClient, connectionsTable, messageData) => {
  // Get all active connections
  const result = await dynamodb.send(new ScanCommand({
    TableName: connectionsTable
  }));

  // Broadcast to all connections
  const broadcastPromises = result.Items.map(async (connection) => {
    try {
      await apiGatewayClient.send(new PostToConnectionCommand({
        ConnectionId: connection.connectionId,
        Data: JSON.stringify(messageData)
      }));
    } catch (error) {
      // If a user disconnected without telling us (410 Gone), clean up the DB
      if (error.statusCode === 410 || error.name === 'GoneException') {
        console.log(`Removing stale connection: ${connection.connectionId}`);
        await dynamodb.send(new DeleteCommand({
          TableName: connectionsTable,
          Key: { connectionId: connection.connectionId }
        }));
      }
    }
  });
  
  await Promise.all(broadcastPromises);
};

Error handling was crucial. I also implemented:

Message length validation (1000 character limit)
Handling of malformed JSON
Fallback to Scan if GSI query fails

4. Message History (The getHistory Route)

A major feature I initially overlooked was loading chat history when users connect. The getHistory route uses the same sendMessage Lambda function but handles a different action. When triggered, it:

Uses the GSI to efficiently fetch the last 50 messages
Automatically loads when users first connect
Returns messages sorted by timestamp (newest first)

This route is triggered when the frontend sends { action: 'getHistory' }. The Lambda queries the Messages table using the GSI with messageType='chat' and sorts by timestamp, then returns the results to the client. Without this, users would only see messages sent after they joined—not ideal for a chat app.

5. Security: The Authorizer

Security was a critical consideration. I implemented server-side validation in both the authorizer and onConnect Lambda (defense in depth):

Username validation: 2-20 characters, alphanumeric plus spaces/hyphens/underscores
XSS pattern detection: Blocks <script>, javascript:, and other injection patterns
Query string validation: The authorizer validates usernames from query strings before connections are established, preventing malicious usernames from even reaching the connection handler

The authorizer runs before any connection is established, so invalid usernames are rejected at the gateway level.

Infrastructure as Code: Why Terraform?

I wanted to use this project to learn Terraform, and it turned out to be the best decision I made.

In the AWS Console, if you delete a Lambda function by mistake, you have to remember exactly how you configured the permissions, the environment variables, and the triggers. With Terraform, I just ran terraform apply and my entire infrastructure, database, permissions (IAM), API routes, and functions, was rebuilt in minutes.

An obstacle that came up that I was not expecting was how to manage Terraform state across devices. I use a different computer at home than when I am at school, which quickly led to issues with tracking the state when switching devices.

What I came up with was using an S3 bucket as a remote state. I also created a DynamoDB table that would track if someone was actively making changes and apply a state lock. It might not be the most relevant thing for a solo developer, but it was simple enough to implement and felt like the "correct" way to engineer it.

# terraform/backend.tf
# Note: Bucket name is an example - use your own unique bucket name

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "chat-app/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock" # Handles the locking
    encrypt        = true
  }
}

IAM Permissions: The Hidden Complexity

Getting components to talk to each other requires very specific IAM permissions. Here's a brief example of what the Lambda functions need:

# Example IAM policy for sendMessage Lambda
# Note: In production, use specific ARNs instead of wildcards where possible
{
  "Effect": "Allow",
  "Action": [
    "dynamodb:PutItem",
    "dynamodb:GetItem",
    "dynamodb:DeleteItem",
    "dynamodb:Scan",
    "dynamodb:Query",
    "execute-api:ManageConnections"
  ],
  "Resource": [
    "arn:aws:dynamodb:us-east-1:123456789012:table/Connections",
    "arn:aws:dynamodb:us-east-1:123456789012:table/Messages",
    "arn:aws:execute-api:us-east-1:123456789012:*/@connections/*"
  ]
}

Each Lambda needs explicit permissions for every AWS service it touches, and the resource ARNs must be precise (not wildcards where possible for security).

The Frontend: Balancing Design and Development Speed

I admit, I am a sucker for frontend design. Even though this was a cloud architecture project, I wanted it to look good—but I also didn't want to spend days tweaking CSS when the real learning was in the backend architecture.

This is where AI tools like Cursor, V0, and Figma AI became force multipliers for a solo developer:

Design exploration: I used V0 to generate a "warm minimalism" UI based on Radix UI components. Instead of starting from a blank canvas, I could iterate on something that already looked professional.
Infrastructure boilerplate: Writing Terraform IAM policies is tedious and error-prone. I'd prompt Cursor with "Give me a Terraform policy that allows this Lambda to write to this specific DynamoDB table," turning 20 minutes of documentation hunting into 30 seconds of code review.

This experience taught me something valuable: AI tools are best used for generating boilerplate and exploring design options, not for understanding complex system interactions. I still needed to deeply understand WebSocket lifecycles, DynamoDB access patterns, and IAM permissions to debug when things went wrong.

Building a Robust WebSocket Connection: The Frontend's Role in a Serverless Architecture

While I spent most of my time architecting the backend, I quickly realized the frontend needed to be just as sophisticated. In a traditional server setup with Socket.io, the server handles much of the connection lifecycle. In a serverless world, the frontend carries more responsibility.

The Reconnection Challenge: When Lambda Functions Come and Go

WebSocket connections can drop—users close their laptops, switch networks, or Lambda cold starts cause temporary delays. Unlike a traditional Node.js server that maintains long-lived connections, API Gateway needs the client to be resilient.

I implemented automatic reconnection with exponential backoff: wait 3 seconds after the first failure, then 6, then 12, up to a maximum of 5 attempts.

// Exponential backoff: 3s, 6s, 12s, 24s, 48s
const delay = reconnectInterval * Math.pow(2, reconnectCountRef.current - 1)

But there's a React-specific gotcha: WebSocket event handlers can capture stale state if you're not careful. I used useRef to store the WebSocket instance and callback functions, ensuring handlers always have fresh data—a pattern I had to learn the hard way after messages started duplicating.

State Management: The Frontend as the "Memory"

Remember how Lambda functions are stateless? The frontend needs to maintain its own state too. When a username changes, the WebSocket must reconnect with new credentials. But React's useEffect can fire multiple times during renders, so I had to carefully clean up old connections before creating new ones.

This was a good reminder: serverless doesn't mean stateless everywhere, you're just moving where that state lives.

Message Validation & Error Handling

The frontend validates every message it receives. Just because it came over the WebSocket doesn't mean it's trustworthy. Each message must have a valid timestamp, username, and message content. Invalid messages are silently filtered out rather than crashing the UI.

// Validate message before adding to state
if (!message.timestamp || !message.username || !message.message) {
  console.warn('Received invalid message format:', message)
  return // Skip this message
}

Automatic History Loading

When a user connects, the frontend automatically requests the last 50 messages from the server. This happens immediately after the WebSocket connection opens, before the user even types anything. The Lambda function uses that DynamoDB GSI we discussed earlier to efficiently fetch recent messages sorted by timestamp.

Connection Status UX

The UI shows real-time connection status: connecting, connected, disconnected, or error. This transparency was crucial during development—seeing "error" immediately told me if my backend deployment failed. In production, it helps users understand when they've lost connectivity.

The frontend turned out to be more complex than I expected. Managing WebSocket lifecycle, handling reconnections, validating data, and providing good UX feedback required more state management logic than a simple chat interface might suggest.

The Missing Features You Don't Think About

When building a real-time chat app, there are several features that seem obvious in hindsight but aren't immediately apparent:

Message history loading: Users expect to see previous messages when they join. The getHistory route and GSI pattern make this efficient.
Stale connection cleanup: Users can disconnect without properly closing the WebSocket (closed browser, network issues). Handling 410 Gone errors and cleaning up the database prevents memory leaks.
Server-side username validation: Never trust the client. The authorizer validates usernames before connections are established, preventing XSS and injection attacks.
Route-based message routing: Using the action field in the message body allows a single WebSocket connection to handle multiple types of operations (sendMessage, getHistory, etc.).

What I Learned

Building this app bridged the gap between the "million acronyms" I learned in class and actual engineering.

State is hard in Serverless: You take for granted that a server knows who is connected. In Lambda, you have to build that "memory" yourself using a database.
Testing WebSocket Lambda functions is challenging: You can't easily test WebSocket connections locally. I had to deploy to AWS to test, which slowed down the development cycle. I created test scripts using event payloads to simulate API Gateway invocations, but they still required the full infrastructure to be running.
Modern Dev Tools: Combining Terraform for the backend and AI-assisted coding for the frontend allowed me to build a project that would have taken a team of three a few weeks to build in just a fraction of the time.

The Art of Triage

2025-10-16T00:00:00Z

The Art of Triage: Prioritizing Threats in the SOC

In a busy Security Operations Center (SOC), the biggest challenge isn't just investigating alerts—it's knowing which ones to investigate first. When I started at Big West Oil, my Taegis XDR dashboard was a constant flood of information. If you try to treat every "High" severity alert with the same level of panic, you'll burn out in an hour and, worse, you'll miss the truly critical threat hiding in the noise.

This is the most essential and stressful skill of a SOC analyst: the art of triage.

It's not a simple checklist. It's a rapid-fire decision-making process that balances a few key questions to determine the answer to the most important one: "What do I have to work on right now?"

1. How Bad is the Threat? (Severity)

This is the most obvious starting point. My tools did a lot of the initial work for me. Taegis XDR would flag an alert as "High," "Medium," or "Low" based on the nature of the detection.

A "High" alert, like a potential ransomware signature or a known command-and-control (C2) callback, is almost always going to jump to the top of the list. A "Low" alert, like a single failed login, is less concerning on its own. But this is just the first piece of the puzzle.

2. Where is it Happening? (Asset Criticality)

This, I learned, is the most important question. An alert's true priority is a combination of its Severity and the Criticality of the asset it's on.

To be an effective analyst, you must understand the business. Is the alert on a critical domain controller or a server hosting the company's financial data? Or is it on a guest laptop on the public Wi-Fi?

A "Medium" severity alert on a domain controller is infinitely more urgent than a "High" severity alert on an intern's old laptop. This is where my GRC background from FJ Management gave me a massive head start. I already understood the "crown jewels" of the business. This let me see an asset as more than just an IP.

3. What's the Context? (Correlation)

No alert exists in a vacuum. A single, isolated alert is rarely a five-alarm fire. The real danger is in the pattern. This is where my investigative skills from the previous week came into play.

Is this "Unusual Login" alert an isolated event? Or was it preceded by a "Phishing Email Clicked" alert and followed by a "Malicious PowerShell Command" alert, all from the same user?

That chain of events tells a story. My job in triage was to quickly see if an alert was a standalone event or one chapter in a much scarier story. This is what triage is all about: using my tools and business knowledge to separate the signal from the noise, fast.

The Final Decision

In just a few minutes, I had to make a call. Was this a false positive I could close? Was it a minor issue I could investigate when I had time? Or was this a true positive on a critical asset—a "drop everything and call my manager" moment?

Getting this right is the core of the job. It's what stops a small intrusion from becoming a front-page data breach.

What's Coming Next

This daily act of balancing GRC context with SOC threats led to the biggest insight of my entire internship. Next week, I'll share that "Aha!" moment—how my audit experience made me a better analyst, and how my time in the SOC made me a better auditor.

This is part of a series about my cybersecurity internship experiences. Read the previous posts to catch up on the journey so far.

The Digital Detective: A Day in the Life of a SOC Analyst

2025-09-19T00:00:00Z

The Digital Detective: Investigating with Darktrace and Taegis XDR

Moving into the Security Operations Center (SOC) at Big West Oil meant shifting from theory to practice. My daily work revolved around two core platforms: Taegis XDR for alerts and endpoint data, and Darktrace for network visibility. My job was to be a digital detective, using these tools to investigate the constant stream of potential threats.

Every day brought a new set of puzzles. While each case was unique, the investigative process followed a clear, structured path.

The First Clue: The Alert

An investigation always started with a single alert in Taegis XDR. I saw a wide variety of them, but the most common were related to user activity:

Potential Phishing Attempts: A user account suddenly trying to access a known malicious domain.
Password Spraying: A series of failed login attempts against multiple accounts from a single IP address.
Unusual Login Attempts: A successful login from a geographic location where we have no employees.

These alerts were the first clue—the "tip-off"—that something was wrong. My job was to figure out if it was a real threat or just a false alarm.

Building the Case File

Once an alert came in, I would immediately begin to build context around it. My investigation process involved three key questions:

Who and What is Involved? Taegis XDR would show me the associated user and their device. The first step was understanding the context. Is this a server that should have very predictable behavior, or is it a developer's laptop with more varied activity?
Are There Other Clues? I would then pivot to look for other alerts or events associated with that same user or device. A single unusual login might be a false positive. But an unusual login, followed by a "Potential Phishing" alert, followed by a "Malicious Process Detected" alert starts to paint a very clear picture of a compromise.
Is This Behavior Expected? By combining these pieces of evidence, I could usually determine if the activity was expected or not. An engineer on vacation in Europe might trigger an unusual login alert, which is expected behavior. That same alert on a random Tuesday from an accountant's account is a major red flag.

Delivering the Verdict

After gathering the evidence, I had to deliver a verdict. If the activity was deemed legitimate, I would document my findings and close the alert, sometimes tuning the rule to reduce future noise.

If it was a real threat, I would immediately escalate it to my manager. From there, we would work together to determine the next steps for containment and remediation. This hands-on process of finding the signal in the noise was the core of my role as an analyst. It was a thrilling challenge to piece together disparate logs and alerts to uncover the full story.

What's Coming Next

Investigating alerts is one thing, but knowing which ones to investigate first is a completely different skill. Next week, I'll cover "The Art of Triage" and how a SOC analyst prioritizes threats when everything seems urgent.

This is part of a series about my cybersecurity internship experiences. Read the first post to understand the context of my journey through both GRC and Security Operations roles.

From Auditing Firewalls to Defending Them

2025-09-11T00:00:00Z

From Auditing Firewalls to Defending Them

For the first part of my internship, I was the building inspector. I reviewed blueprints (policies), checked the structural integrity of systems, and even tested the emergency response plans by running a phishing simulation. My work was in the world of Governance, Risk, and Compliance, the strategic "why" behind security.

Now, it was time to wee the other side of the coin.

I transitioned from my role at the parent company, FJ Management, to a more direct, hands-on position as a Cybersecurity Analyst at one of its subsidiaries, Big West Oil. I was moving from planning and assessing to defending in real-time.

A Familiar Map, A New Battlefield

What made this transition so unique was that I wasn't walking in blind. During my time as an auditor, one of my first projects involved reviewing the firewall rules and security posture of the very company I was now joining. I had already seen the blueprints.

As an auditor, my questions were strategic: Does this policy effectively reduce risk? Is it documented correctly? Is it essential for the business?

Now, as an analyst staring at an XDR (Extended Detection and Response) platform, I was watching the live traffic flowing through those same firewalls. My questions became immediate and tactical: Is that packet an attack?

Connecting the "Why" to the "What"

This immediate connection between my two roles was a game-changer. When I saw an alert for suspicious traffic coming from a specific network segment, I didn't just see an IP address. I remembered the conversations from my audit about why that segment was configured the way it was and what critical business assets it housed.

This experience provided the context, the "why" that made the real-time data, the "what" more meaningful. I understood that the alerts weren't just random noise they were potential threats to the very systems whose defenses I had previously been tasked with inspecting.

This experience immediately began to bridge the gap between the two sides of the cybersecurity coin. The rules and policies I had been auditing were no longer abstract concepts. They were the digital barriers I was now responsible for defending on the front lines.

What's Coming Next

But make no mistake, the transition wasn't seamless. Knowing the 'why' didn't automatically teach me the 'how.' Moving into an analyst role was like learning a new language, one filled with a new vocabulary of tools, queries, and investigative techniques.

Next week, I’ll take you inside my day-to-day as a "Digital Detective," sharing what it was like to grapple with that learning curve, investigate real alerts, and hunt for threats in a sea of data.

This is part of a series about my cybersecurity internship experiences. Read the first post to understand the context of my journey through both GRC and Security Operations roles.

The Human Element: I Phished My Own Company (For Science!)

2025-09-03T00:00:00Z

The Human Element: I Phished My Own Company (For Science!)

After auditing the machines and software pipelines, my focus shifted to the most complex and unpredictable part of any security system: people. Upper management at FJ Management wanted to know how our teams would hold up against a sophisticated, targeted spearphishing attack. My manager gave me the project, and I was given permission to (ethically) attack my own companies.

The goal wasn't to play "gotcha" or to get anyone in trouble. It was to gather data and see how we could build a stronger, more resilient security awareness culture.

Step 1: Building the Attack Plan with OSINT

To make this a true test, we decided to use as little inside information as possible. The goal was to simulate what a real attacker would do. That meant my first step was Open-Source Intelligence (OSINT) gathering.

Using LinkedIn profiles, I pieced together an organizational chart for our target groups at FJ Management and its subsidiaries. I identified key individuals, their job titles, and their roles within the company. This public information would become the foundation for creating highly specific and believable phishing lures.

Step 2: Crafting the Bait with AI

With our targets identified, it was time to craft the bait. We used the open-source tool Gophish to manage the campaigns. For the emails and landing pages, I turned to AI.

Based on the job titles I found, I created 15 bespoke and targeted emails. For example, an email to someone in finance might reference a fake update for an invoice, while a message to an IT-adjacent role might be about another user who is having issues. The AI helped me write convincing copy for each scenario.

To make the attacks even more realistic, we registered several typosquatted domains that looked nearly identical to our real ones—a classic trick where a capital 'I' can look just like a lowercase 'l', making the fake domain almost impossible to spot at a glance. These domains hosted AI-designed fake landing pages that were nearly identical clones of a SharePoint or Microsoft 365 login portal.

Step 3: The Launch

I’ll admit, it was nerve-wracking to hit "send." These weren't generic, typo-filled phishing emails. They were carefully crafted attacks aimed at my own colleagues. But I reminded myself that we were doing this to help protect the company in the long run we were a sparring partner, not a real opponent.

We started seeing results almost immediately. People clicked.

Even many who didn't click reached out to our security team to comment that it was the most convincing phishing attempt they'd ever encountered. That feedback alone was a huge win—it meant our simulation was realistic.

The Surprising Results

Here’s where our test differed from a standard phishing campaign. When an employee clicked the link and landed on our fake page, there was no obvious "You've Been Phished!" message. We tracked the click, but we didn't harvest credentials. Our primary goal was to see what happened next. Would they report it?

We found that while employee training was generally effective, the combination of specific details gathered from OSINT and the polished, AI-generated landing pages gave us a significant degree of success. Some people who clicked never realized that it was a spearphishing attack. Others did realize after they entered their credentials but were hesitant to report their mistake to the security team.

My key takeaway was that the "human firewall" is not a pass-fail system. It's a dynamic defense that needs to be tested with realistic, modern threats. By acting like a real attacker, we gained invaluable data on how to better train and equip our team for the real thing.

What's Coming Next

My time in the GRC world, from auditing mergers to testing our human defenses, gave me a strategic view of security. Next week, I'll describe my transition to the other side of the coin: moving to the front lines as a Cybersecurity Analyst at Big West Oil.

This is part of a series about my cybersecurity internship experiences. Read the first post to understand the context of my journey through both GRC and Security Operations roles.

From Pipelines to Policies: Auditing Modern Application Development

2025-08-27T00:00:00Z

From Pipelines to Policies: Auditing Modern Application Development

When I was assigned to the Maverik application change management audit, I’ll be honest, I had no idea what a "CI/CD pipeline" was.

Over the course of two months, my task was to answer the question: "How do we make sure that new code, from a developer's keyboard to our live applications, is built and deployed securely?"

To find the answer, I couldn't just read a policy document. I had to learn what was actually happening in the development process, starting by interviewing the development teams themselves.

The Digital Assembly Line

Through my conversations with developers, I learned that the CI/CD (Continuous Integration/Continuous Deployment) pipeline is like an automated assembly line for software. At Maverik, this assembly line was powered by a tool called Jenkins. A developer commits code, and Jenkins takes over, automatically building, testing, and preparing it for release.

My role was to walk the entire length of this assembly line. Each step of the process provided a level of assurance that the code was secure, had been reviewed by QA, and was ready to end up in production. I had to learn the entire application change management process from start to finish and see if each step was being followed correctly.

From Conversation to Configuration Files

The most crucial part of the audit was verifying that security was truly built into the process, not just an afterthought. The developers told me they used a suite of tools like Snyk to scan for vulnerable dependencies and SonarQube to check for bugs and security issues in their own code.

But in an audit, "trust but verify" is the rule. It wasn't enough to hear that they were using these tools. I had to prove it.

This is where I had to roll up my sleeves and learn to read Jenkins configuration files. Sifting through code, I could directly verify the claims from my interviews. I looked for the specific lines that initiated the Snyk and SonarQube scans and checked the settings to confirm the pipeline would actually fail if a high-severity vulnerability was found. I was connecting the dots between a conversation with a developer and the technical enforcement in a config file.

Connecting Code to the Committee

This technical deep dive was only one piece of the puzzle. I also learned how this automated process fed into the larger governance structure. Every significant change had to be approved by a Change Advisory Board (CAB).

The logs and reports from the Jenkins pipeline—proof that the code was tested and passed all its security scans—served as the evidence presented to the CAB. I saw how a technical control, like a SonarQube scan configured in a Jenkins file, provided the assurance a high-level governance body like the CAB needed to make a risk-informed decision. I even got to see how this process was adapted for emergencies, ensuring security wasn't abandoned when things needed to move fast.

My Key Takeaway

Auditing a CI/CD pipeline taught me that a modern auditor is a translator. You have to speak the language of developers and understand their tools, then translate that technical evidence into the language of risk and compliance for management and governance bodies. You are the bridge between the configuration file and the committee meeting. This experience proved that GRC isn't a separate world; it's a critical lens through which to view and validate the technology itself.

What's Coming Next

Next week, I'll shift my focus from auditing the machines to testing the people. I'll share the story of how I was given permission to (ethically) phish my own company to test our human defenses.

This is part of a series about my cybersecurity internship experiences. Read the first post to understand the context of my journey through both GRC and Security Operations roles.

What I Learned Auditing a Corporate Merger

2025-08-20T00:00:00Z

What I Learned Auditing a Corporate Merger

What really happens to the digital infrastructure when two giant companies merge? Even though Maverik's acquisition of Kum & Go happened in 2023, the process of securely integrating their technologies is a marathon, not a sprint. I joined the ITGC internal audit team at FJ Management (Maverik's parent company) in 2025, stepping right into the middle of this challenge.

The Great Tool Inventory

My first task was to be a fly on the wall in the discussions about the great "tool inventory." It was my job to listen and learn as senior members of the team analyzed the massive ecosystem of security tools each company used. It was like looking at two different toolboxes, both filled with wrenches and hammers, but from different brands and with different features.

I was amazed to learn just how many different SaaS tools can be pieced together to protect every little aspect of a company's security posture.

The Firewall Dilemma: A Lesson in Business vs. Security

The most interesting part of the audit was witnessing a classic debate unfold in real time. The situation was simple: Kum & Go used a different brand of firewalls than Maverik.

The Security Problem

For the security team, managing two different firewall systems was a major headache. It meant:

Double the training
Slower response time
Higher chance of misconfigurations that could leave a gap for attackers

The Business Problem

From the business side, the firewalls they had were working just fine. The idea of spending a significant amount of money to replace perfectly functional equipment was, to put it mildly, not popular.

As an intern, I had a front-row seat to one of the most fundamental challenges in our field: showing the business why a necessary security change is worth the cost.

My Key Takeaway

My biggest lesson from this project wasn't about which firewall brand was better. It was that cybersecurity is as much about communication and business acumen as it is about technology.

The best security tool in the world is useless if you can't articulate its value and get the business to support it. You have to learn to speak the language of risk and efficiency, not just the language of tech.

This experience was a great introduction to the world of GRC, and it helped shape how I view the role of a security professional.

What's Coming Next

Next week, I'll shift from high-level strategy to the nuts and bolts of modern development as I share my experience auditing a CI/CD pipeline.

This is part of a series about my cybersecurity internship experiences. Read the first post to understand the context of my journey through both GRC and Security Operations roles.

The Two Sides of the Cybersecurity Coin

2025-08-13T00:00:00Z

The Two Sides of the Cybersecurity Coin

If you ask the average person what they think about cybersecurity, they'll probably imagine a hacker in a hoodie, scrolling walls of green text right out of The Matrix, or a news story about a data breach. While these things might be part of cybersecurity, they only focus on one side of the coin.

Over the past eight months, I had the opportunity to see the other side of cybersecurity. Through two very different internships, I experienced two distinct perspectives on security: first as an Internal ITGC Auditor for FJ Management, and then as a Cybersecurity Analyst for Big West Oil.

Over the next 10 weeks, I'm going to share experiences and lessons that I learned.

Side A: The Building Inspector (Governance, Risk, and Compliance)

My journey began in the world of Governance, Risk, and Compliance (GRC). A good way to think of this role is like being a building inspector for a bustling city. The buildings are already standing and operational, and my job was to come in and ensure everything was up to code.

I wasn't designing from scratch; I was examining ongoing business and technical processes—reviewing the 'structural integrity' of a firewall's rules, checking the 'fire exits' of a CI/CD pipeline, and ensuring the 'safety plans' (policies) were being followed in real-time. It's the critical work of finding hidden risks in active systems before they lead to a collapse.

This is the "why" behind the rules.

Side B: The Firefighter (Security Operations)

Then, I flipped the coin and moved to the front lines as a Cybersecurity Analyst. If GRC is the building inspector, then Security Operations (SecOps) is the city's firefighter. They are the ones watching for the first sign of smoke, responding to alarms in real-time, and rushing to the scene of a crisis.

This is the world of XDR platforms, threat monitoring, and incident response. It's about asking "Is there a fire right now?" and "How do we put it out?" This is the tactical, reactive work that contains damage.

This is the "how" of cybersecurity.

Why Seeing Both Sides Matters

So, why does seeing both matter? A building inspector who has never been to a fire doesn't fully grasp the real-world consequences of a failed inspection. A firefighter who doesn't understand the building's layout or its hidden safety flaws might struggle to respond effectively.

My time in auditing gave me a deep appreciation for why the rules existed for our ongoing processes, which made me far more effective when I was on the front lines, tasked with defending those same processes.

What's Coming Next

I hope you'll follow along as I share specific stories and insights from these roles.

Next week, I'll dive into my first major project: auditing the security integration of a corporate merger.

This is the first post in a series about my cybersecurity internship experiences. Stay tuned for more insights from both the GRC and Security Operations perspectives.