Posts on randomsecurity.dev

SRECon 2025 EMEA

Tue, 18 Nov 2025 00:00:00 +0000

AI attacks is something that has been talked about in the media, but defending against them hasn’t been part of the discussion. I was able to talk about practical defenses against these attacks at SRECon 2025 in Dublin, Ireland:

RSA 2023 Conference

Mon, 01 May 2023 00:00:00 +0000

I was honored to present at this year’s RSA Conference on Key Distribution, a topic that everyone will be looking into in the near future. The talk video can be found here:

Armed to Boot: an enhancement to Arm's Secure Boot chain

Thu, 26 Jan 2023 10:08:30 -0500

We began the process of cryptographically signing our UEFI firmware as a way to mitigate rogue firmware. While our existing solution is platform specific for our x86 AMD server fleet, we did not have a similar one for UEFI firmware signing for Arm.

Here’s what we did: Armed to Boot: an enhancement to Arm’s Secure Boot chain

Hardwear.io 2022 - Armed to Boot

Fri, 08 Jul 2022 08:08:30 -0500

We’ve learned a lot about UEFI vulnerabilities over the last few years. Methods to circumvent protections via exploitation or maintain persistence have become more common. While the industry has been able to address this in a few ways, they have been primarily x86-based. So…what about Arm?

Below is our presentation from the Hardwear.io hardware security conference on a novel approach to signing UEFI firmware within the Arm ecosystem:

GSA 2022 Silicon Leadership Summit

Fri, 27 May 2022 08:01:30 -0500

I was again honored to be on a panel of distinguished leaders in the silicon security field at the GSA 2022 Silicon Leadership Summit. We discussed the benefits of the changing security industry from closed proprietary models to open collaborative innovation, how AI/ML models collaborate across end-to-end systems, and open source integration and continuous security testing practices across the industry.

CAPEC User Summit - Hardware Security

Fri, 04 Mar 2022 08:17:30 -0500

I was honored to be on a panel of hardware security experts, presenting at the CAPEC User Summit. Topics discussed were mapping new attack patterns to hardware and different migitation methods.

I’ve posted the video below:

Redefining Firmware Security

Thu, 16 Sep 2021 18:17:30 -0500

I was fortunate to be asked by the CEO of Axiado, Gopi Sirineni to co-author a paper called Redefining Firmware Security. The paper details existing ways companies leverage CPU vendors for forming a hardware root of trust (HRoT) and the improvement made by using Axiado silicon to authenticate board components.

Enjoy!

Secure Memory Encryption Testing

Mon, 14 Dec 2020 13:45:18 -0600

Earlier this year, I presented at the Linux Security Summit on how we’ve implemented secure memory encryption within our AMD EPYC edge machines. Enabling this feature is something that is fairly easy to do, but testing that it works was something that I briefly discussed during the presentation, but also something that I want to elaborate on further here. Before I get into the actual test, I’ll give a brief overview of what memory encryption is doing in the background.

Anchoring Trust

Tue, 17 Nov 2020 08:17:30 -0500

New blog post on some of the hardware security features my team has been working on regarding moving trust anchors to silicon.

Anchoring Trust: A Hardware Secure Boot Story

LatinX and Cyber Security

Wed, 11 Nov 2020 10:37:30 -0500

I recently had the privilege of interviewing Ray Espinoza of cobalt.io for Latin History and National Cyber Security Awareness Month. Ray is a stalwart in the security community with a resume that most people would drool over.

Here’s the video. Enjoy!

Creating a Serverless Blog with Cloudflare and Hugo

Wed, 15 Jul 2020 19:23:52 -0500

I hate having to rebuild stuff. I’ve rebuilt this blog a total of 4 times, with 3 of those time related to bad application/server updates. This blog was previous hosted on a Digital Ocean virtual machine(VM) running a popular headless Node.js CMS called Ghost. A failed droplet migration killed this blog once, which was recovered with a backup and some DNS changes. The last time was a Ghost CLI update (to upgrade Ghost) that wiped my config, to which I had to recover again on 06/28/20. At that point, I was fed up and decided to modernize the blog once and for all.

Linux Security Summit 2020

Mon, 06 Jul 2020 21:34:17 -0500

I presented last week with my co-worker Brian at the Linux Security Summit on Securing Memory at Scale. It was an extension of our company blog post on enabling memory encryption with our AMD EPYC 7xxx series chips. The presentation was pre-recording due to COVID, so I uploaded it here for y’all:

Google Next '19'

Fri, 12 Apr 2019 10:37:30 -0500

My co-presentation from Google Next ‘19 on Migrating DDOS Controls to Google Cloud:

Kubernetes on an Intel NUC

Mon, 18 Apr 2016 18:29:09 +0000

With the recent rise of microservices, there has been a lot of documentation on Kubernetes and how to build it on various cloud platforms (AWS, GCE, etc). Since I run a small lab in my house I figured it would be beneficial to show you how to do a clustered Kubernetes install using small Intel NUC devices.

Based on CoreOS.

Why? Link to heading

This is used for building small clusters based on spare servers, or in this case Intel NUC units, without incurring compute charges from cloud providers.

Docker Cheat Sheet

Mon, 18 Apr 2016 18:13:19 +0000

First, my apologies for not updating in a while. For those who follow my Github site you’ll see that I have been updating that more frequently than my blog. With that said, I made a commit a while ago for a Docker Cheat Sheet that has helped a few of you out. For those that way to see it, go to the lnk below:

Docker Cheat Sheet

Open vSwitch Cheat Sheet

Mon, 28 Dec 2015 06:39:29 +0000

Before I begin, for those unfamiliar with Open vSwitch, please check out my friend David Mahler’s YouTube page for comprehensive introductory videos.

Over the past year I’ve spent some time compiling troubleshooting documents and procedures for all things cloud (OpenStack, SDN, Open vSwitch, etc). I wanted to make a series on ‘cheat sheets’, or common day to day configuration/troubleshooting commands and techniques for different cloud components.

First on the list is Open vSwitch (aka OVS), which has become an integral part of OpenStack networking. It provides the ability to replicate many of the features of a traditional layer 2 switch, while providing advanced features that allow organizations to scale their cloud environments quickly.

VXLAN Offload

Sun, 08 Mar 2015 01:04:21 +0000

It’s been a while since I last posted due to work and life in general. I’ve been working on several NFV projects and thought I’d share some recent testing that I’ve been doing…so here we go :)

Let me offload that for ya! Link to heading

In a multi-tenancy environment (OpenStack, Docker, LXC, etc), VXLAN solves the limitation of 4094 VLANs/networks, but introduces a few caveats:

VXLAN

Sat, 07 Mar 2015 01:04:21 +0000

VLANS circa 1998 Link to heading

It’s amazing that a technology that is over 16 years old is still widely used today. Why? Because it works in most cases (small/medium datacenters, single/dual tenant design, etc). However, due to the growth of cloud computing, the need for secure, scalable virtual networks has changed. Although some solutions exist today to help facilitate some of the isolation concerns, such as QinQ, they fail to address the increasing issue with scale. Virtual Extensible Local Area Network (or VXLAN) extends the VLAN concept of a layer 2 (L2) domain but allows it to sit on top of (overlay) your existing network. It uses MAC-in-UDP encapsulation to create tunnels (VXLAN Tunnel Endpoints or VTEPS) across a layer 3 (L3) transport to extend your L2 domain with great flexibility. This would allow for hosts to live in two disparate networks yet still operate as if they were attached to the same L2 domain. This also solves the VLAN limitation of 4096 VLAN ID’s as VXLAN supports over 16 million VXLAN id’s. I’ll provide a quick overview on how this technology works, some of the misconceptions surrounding it, as well as current adaption methods.

Openstack scripts

Mon, 17 Nov 2014 21:17:18 +0000

I’ve updated my Git repo with some of the deployment scripts I’ve used for my Brix/NUC lab setup. Read and enjoy!

Self Healing OpenStack Control Plane with Kubernetes

Fri, 07 Nov 2014 01:04:21 +0000

I presented, along with Shixiong Shang and Randy Tuttle from CloudPerceptions, at the OpenStack Summit in Austin, TX regarding using Kubernetes as the underlay for building a ‘self-healing’ OpenStack control plane:

Openstack with IPv6

Tue, 19 Aug 2014 14:19:00 +0000

Openstack….now with lots of addresses! Link to heading

After being inspired to update my IPv6 experience in my previous post, I figured it was time to start enabling IPv6 within my Openstack lab environment. It’s surprisingly easy as it’s similar to many dual-stacked environments that support IPv4/IPv6 today. The following is a basic Openstack Icehouse single node install with a Single Flat Network (I’ll explain shortly), dual-stacked topology. Sound good? Let’s get started!

IPv6 "Sage"

Sun, 03 Aug 2014 22:56:49 +0000

Free Stuff Motivates Me Link to heading

I’ll admit it. Anytime I see a challenge where one can win free schwag I dive into it head first. When I saw that one could win a free t-shirt by completing the Hurricane Electric IPv6 Certification course , I became dead set on getting my hands on a new shirt. Little did I know it would not only be fun and re-teach me some concepts, but also give me motivation on testing IPv6 within Openstack. This isn’t going to be a primer on IPv6 so, if needed, go to the Wikipedia article to brush up concepts beforehand. So let’s get into how to complete the certification.

Openstack Juno on Centos 7

Wed, 25 Jun 2014 16:03:24 +0000

First, sorry for the delay in posting. I’ve been busy in rebuilding my lab (4 times) to accommodate parallel testing. In the meantime, I wanted to quickly share my experience with the latest Openstack release: Juno. As of this writing there is a repo available for Ubuntu but for this install I’m using Centos 7 via RDO and the Packstack installer. Why? Because it’s freaking easy….aside from a few minor changes depending on the configuration you choose (single node, multi-node, vlan, vxlan, etc). So let’s get started.

Openflow

Sun, 20 Apr 2014 16:10:29 +0000

Huh? Link to heading

With the recent advances in virtualization and abstracted computing, software-defined networking (SDN) has become a reality. Although decoupling the network control out of physical network devices into a central or clustered service has been the primary focus of SDN, the discussion around Openflow and SDN being the same is a bit of a misnomer. Before I talk about Openflow concepts and deployments strategies, let’s break down a bit of what Openflow is, the difference between SDN and Openflow, and it’s messaging scheme.

Devstack single NIC configuration

Fri, 28 Mar 2014 22:21:21 +0000

I made a post recently on setting up Openstack for development using Devstack but failed to mention some other tips on how to build a lab out of anything. I’m a big fan of the Gigabyte Brix PC kit systems, with the caveat being that they only have a single NIC. You could connect a wireless USB adapter but there is a much easier way to have multiple networks….

Old fashioned bridging….the joy Link to heading

Yes….bridging and VLANS still work…and fairly well within a Linux system. First install the dependencies:

Openstack in 20 minutes

Fri, 28 Feb 2014 14:58:56 +0000

Openstack for the lazy Link to heading

If you are like me, you do a lot of testing. I have built and rebuilt Openstack single (all in one) and multi-node installations hundreds of times. With Devstack, you have the ability of creating an Openstack single node instance within minutes. While the default settings should suffice for most, I’ll add some additional details that may help with all of the testing you wish to accomplish.

NTP reflection attacks

Tue, 11 Feb 2014 12:31:26 +0000

The buzz Link to heading

There has been a lot of traction in the news lately regarding a ’new’ DDOS attack vector in regards to network time protocol (NTP) based attacks. NTP reflection is similar in nature to DNS reflection in that it is a UDP-based protocol that can be persuaded to return a large reply to a small request. To give a little background on this type of attack I’ll explain how it works. A reflection attack works when an attacker can send a packet with a spoofed source IP address. The attacker sends a packet apparently from the intended victim to a random server on the Internet that will reply immediately. Because the source IP address is spoofed to look like the victim IP, the remote Internet server replies and sends data to the victim. The result is two-fold: the real source of the attack is hidden and unknown and, if several servers are used, the attack can be amplified. The amplification becomes more severe when the attacker sends spoofed packet that elicits a large reply from the server(s) in question. This attack can turn a small amount of bandwidth that the attacker uses to generate the attack into a massive bandwidth attack from server(s) globally.

Ghost Blog

Wed, 08 Jan 2014 18:30:52 +0000

New look, same scrutiny. Link to heading

I figured it was time to move away from WordPress onto a faster platform, so I decided to give Ghost a try. It is coded in Node.js and uses Markdown as it’s formatting syntax. Editing is facilitated using a split screen display, so it’s hard to fudge things up.

A big shoutout to Lars for hosting the previous blog for nearly a year.