<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Capstone on </title>
    <link>/series/capstone/</link>
    <description>Recent content in Capstone on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 06 Oct 2026 23:45:18 -0400</lastBuildDate>
    <atom:link href="/series/capstone/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Evaluating Models with EvidenceForge</title>
      <link>/posts/capstone/eval_with_evidenceforge/</link>
      <pubDate>Tue, 06 Oct 2026 23:45:18 -0400</pubDate>
      <guid>/posts/capstone/eval_with_evidenceforge/</guid>
      <description>Benchmarking Models with EvidenceForge Alright, so previously we did some hardware benchmarking to validate that our selected models could reasonable run on my current hardware. Those tests all went well, which was good, but now we are getting into the real meat and potatoes of this project. Evaluating these models security reasoning skills. How are we going to go about doing that? Well, I&amp;rsquo;m glad you asked. Enter, EvidenceForge. EvidenceForge is an open-source project from Cisco Talos that can generate synthetic security telemetry from scenario definitions, keeps the generated evidence separate from the answer key, and gives me a much better basis for comparing local models than a few improvised chat prompts.</description>
    </item>
    <item>
      <title>Building llama.cpp with CUDA</title>
      <link>/posts/capstone/llama_cpp_cuda/</link>
      <pubDate>Tue, 06 Oct 2026 23:43:21 -0400</pubDate>
      <guid>/posts/capstone/llama_cpp_cuda/</guid>
      <description>Using llama.cpp with CUDA and Testing Local Models Howdy there everyone and welcome back to the next leg of my capstone journey. Which involves actually spinning up some locally hosted models and testing them out. Over the next while, we&amp;rsquo;re going to be deploying a few models, seeing how they run on my old RTX 2060 laptop, benchmarking their security reasoning skills and their ability to call tools from a MCP server.</description>
    </item>
    <item>
      <title>Deploying Shuffle as My SOAR Solution</title>
      <link>/posts/capstone/shuffle_soar/</link>
      <pubDate>Tue, 06 Oct 2026 23:41:40 -0400</pubDate>
      <guid>/posts/capstone/shuffle_soar/</guid>
      <description>Introduction Last time, we deployed Security Onion which will be our SIEM of choice for this project. Now we need a SOAR (Security Orchestration Automation and Response) solution. Which brings us to Shuffle, an open-source SOAR platform we can use to build playbooks containing predefined actions for responding to suspicious activity. Before we get going, I&amp;rsquo;m deploying Shuffle on a recently created Ubuntu server VM using Docker Compose. Versions listed below.</description>
    </item>
    <item>
      <title>Deploying Security Onion</title>
      <link>/posts/capstone/security_onion/</link>
      <pubDate>Tue, 06 Oct 2026 23:38:51 -0400</pubDate>
      <guid>/posts/capstone/security_onion/</guid>
      <description>Introduction Alright, time to get down to some serious business. From this point forward, all of my blog posts will be in support of my master&amp;rsquo;s degree capstone. I may be a little less chatty than I normally am for a while as my main focus is just getting these rolled out in a timely fashion. These posts will still go over what we&amp;rsquo;re deploying and how we&amp;rsquo;re doing it and there&amp;rsquo;s going to be a little more information on things like version numbers and any issues we run into or anything during deployment.</description>
    </item>
  </channel>
</rss>
