In this, Part 2 of the tutorial, you'll learn how to configure agents (or clients) to authenticate themselves to that log relay and send their logs securely to the SIEM server.

Overview​

Before diving in, review these steps to get an idea for what's ahead:

1. Create a certificate for your client
   • Use the CA (Certificate Authority) you created in Part 1 to generate and sign a certificate for each client
2. Install and configure the software necessary to handle mTLS on your client machine
3. Install your SIEM agent and configure it to use the log relay you've created

Certificate preparation​

First, we need to create a certificate to be used by the device you want to monitor. On the machine you're using as your certificate authority (CA), perform the following steps:

1. Create the key

   openssl genrsa -out agent-hostname.key 4096
   chmod 600 agent-hostname.key
   

This gives you a file called <agent-hostname>.key. Hold onto that.

1. Create a CSR (Certificate Signing Request) for the key

   Use the following command, making sure to replace agent-hostname and YourOrg with the names of the device to be monitored and the name you want to represent your "organization".

   NOTE

   This command uses the name of the file you created in the previous step. Remember to copy that exactly and provide it in the -key parameter of the command.

   openssl req -new \
       -key agent-hostname.key \
       -out agent-hostname.csr \
       -subj "/C=US/O=YourOrg/CN=agent-hostname"
   

2. Use the CSR to create and sign a certificate for the host to be monitored.

   Remember to replace agent-hostname and mtls-ca with the names of the host to be monitored and the name of your certificate authority, respectively.

   This command includes several flags (parameters), so click here for a quick breakdown of the whole command if you're interested:

   Flag	Meaning	Purpose in This Command
   openssl x509	Invokes the OpenSSL X.509 certificate utility.	Used to create, inspect, or sign X.509 certificates.
   -req	Treats the input as a Certificate Signing Request (CSR).	Tells OpenSSL to read and sign the CSR specified by -in.
   -in agent-hostname.csr	Specifies the input CSR file.	Reads the certificate request from agent-hostname.csr.
   -CA mtls-ca.pem	Specifies the CA certificate to use for signing.	Uses mtls-ca.pem as the issuing Certificate Authority certificate. Change this to the name of your CA's .pem file.
   -CAkey mtls-ca.key	Specifies the private key corresponding to the CA certificate.	Uses mtls-ca.key to cryptographically sign the new certificate. Change this to the name of your CA's .key file.
   -CAcreateserial	Creates a CA serial number file if one does not already exist.	Generates a file (typically mtls-ca.srl) to track certificate serial numbers issued by this CA.
   -out agent-hostname.crt	Specifies the output certificate file.	Writes the signed certificate to agent-hostname.crt.
   -days 825	Sets the certificate validity period in days.	Makes the issued certificate valid for 825 days from the time of signing. You can change this duration or omit it if you want. However, if you don't provide a value, it will expire after 30 days by default.
   -sha256	Uses SHA-256 as the message digest algorithm for signing.	Signs the certificate using a SHA-256 hash, which is a widely accepted secure algorithm.
   \	Shell line-continuation character (not an OpenSSL option).	Allows the command to be split across multiple lines for readability while being executed as a single command.

   openssl x509 -req \
       -in agent-hostname.csr \
       -CA mtls-ca.pem \
       -CAkey mtls-ca.key \
       -CAcreateserial \
       -out agent-hostname.crt \
       -days 825 \
       -sha256
   chmod 644 agent-hostname.crt
   

3. Copy the key and certificate to the system you want to monitor.

   These are the files that end with .crt and .key.

   These files were created on the machine that's acting as your certificate authority, but they need to be on the machine you want to enroll in monitoring. So, use whatever tool works best for you to transfer them to that device. You could copy them to a USB drive, use SCP, or whatever you prefer.

Install and configure stunnel​

In Part 1 of this tutorial, we set up a log relay and used HAProxy to simultaneously terminate TLS and forward packets to the Wazuh server. We likewise need a tool to terminate TLS on the host to be monitored. For that, we're going to use Stunnel.

Install and configure the Wazuh agent​

Now that stunnel is set up, you're ready to install the Wazuh agent on your device! Start by following the official Wazuh documentation to install the agent on your machine.

Once the Wazuh agent is installed, you just need to edit the ossec.conf configuration file and replace the server address with 127.0.0.1. When that is properly configured, Wazuh will send all logs to the local port where Stunnel is listening and ready to route to the log relay through TLS. Here is a sample of the server section of the Wazuh agent configuration that will show you what that should look like:

<server>
  <address>127.0.0.1</address>
  <port>1514</port>
</server>

Summary & Conclusion​

Congratulations! With these steps completed, you should have successfully enrolled a new device with Wazuh, allowing it to send logs through your secure log relay using mTLS.

Now, you're using a configuration that reduces exposure while providing you with better endpoint visibility.

Quirks of this setup​

One quirk of this setup is all the agents you enroll this way will display the IP address 127.0.0.1 in the Wazuh manager. I'm sure there is a workaround that can fix this, but I haven't found a way to do that yet because it hasn't been important to me.

Background​

I've been running Wazuh as the SIEM for my homelab for two years now, but have only ever been able to consistenty monitor machines that lived inside my homelab. I have always really wanted to be able to monitor logs from my personal devices even when I'm away from home. This is important to me because being unable to monitor logs generated when I'm away from home creates a huge blind spot in my security posture.

At one point, I tried to solve this problem by using Tailscale to connect my remote devices directly to the Wazuh server, but I didn't like that method very much because it required me to keep Tailscale on all the time. Since I use other VPNs, that didn't work well for me, as Tailscale and the VPNs would conflict with one another.

I eventually decided I would need to make the log ingestion ports publicly accessible, but I wanted to do as much as I could to reduce the risks associated with that exposure, at which point I decided to set up mTLS. In this blog, I'll show you how to do that as well.

Why use mTLS?​

To answer the question of why I used mTLS, I'll first explain what mTLS is. Cloudflare's website states it this way:

"mTLS ensures that the parties at each end of a network connection are who they claim to be"

This means that when a remote device connects to the server, both the server and the device authenticate one another to ensure they can trust one another. Another excerpt from Cloudflare's explanation of mTLS says:

"mTLS is often used in a Zero Trust security framework to verify users, devices, and servers within an organization. . . Zero Trust means that no user, device, or network traffic is trusted by default, an approach that helps eliminate many security vulnerabilities."

These security benefits are massively helpful when you're exposing a service publicly. In the case of log collection, they make it possible for a server to receive logs from anywhere, but not from just anyone. They also make it possible for a device to be just as careful about where it sends logs.

Because a SIEM collects all kinds of information (including some potentially sensitive information) from the endpoints it monitors, I find it super important to enforce these zero trust principles in the connection between the server and its agents. With that, let's jump into how to set it up!

Tutorial Overview​

Before your fingers hit the keyboard, begin with the end in mind by reviewing this list of steps.

1. Set up PKI (Public Key Infrastructure)
   • Create a CA (Certificate Authority)
2. Configure relay server and HAProxy
   • Pick and install an OS
   • Apply security hardening
   • Configure HAProxy
3. Networking + DNS setup

Diagram​

This is a rough visual diagram of the setup you'll configure. Hopefully this helps you picture what we're trying to accomplish.

Prerequisites​

These are the resources/things you'll need to set this up.

1. Your own domain OR a machine with a static public IP address
   • I know this prerequisite can be discouraging if you don't already have one, but I HIGHLY recommend getting one. It'll open up your home-labbing opportunities so much, and it's not very expensive.
   • If you do not have your own domain and don't want to purchase one, you have the option of setting up your log relay on a server with a static public IP address such as a VPS in AWS, Linode, or similar cloud-hosting service. However, this is not my recommended method, and I would strongly suggest purchasing a domain. (It'll probably be cheaper than the alternative anyway).
2. Access to two or three separate machines (virtual or physical)
   • One will be your SIEM server (I'll use Wazuh in my examples), one will be the certificate authority (CA) for your PKI, and the other will be the relay that receives and forwards your logs to the SIEM server.
   • Note: You can technically run the CA on one of the other two servers, but it's a little risky to combine them.
3. An endpoint you want to monitor
   • If you just want to set this up as a PoC, you can use any physical or virtual machine. However, it is designed with mobile devices like personal laptops in mind. They're the ones that will get the most use from a setup like this.

Step 1 - Set up PKI (Public Key Infrastructure)​

Let's start by creating your certificate authority. Your certificate authority is critical in issuing and signing certificates that will be used in mTLS. Here, it's important to understand that your certificate authority isn't necessarily a machine. It's essentially a CA private key and a CA certificate.

Your CA private key and CA certificate are just files and they can live anywhere you want. Often, it's a good idea to store them encrypted in an offline container like a USB drive. However, you will need a machine to access them any time you want to issue or sign a new certificate, so you can keep them on the machine you'll be using to sign and issue certificates. It's up to you how you want to handle it, but the latter option is likely appropriate for a homelab setup.

To create them, use these commands:

1. Create your CA private key:

   openssl genrsa -out mtls-ca.key 4096
   chmod 600 mtls-ca.key
   

   This will generate a file called mtls-ca.key.

   This key does NOT need to be copied anywhere else, and you should only copy it if you have to back it up and if you're extremely careful to protect it.

2. Create your CA certificate (Change "YourOrg" and "relay-mtls-ca" to the names you prefer.)

   This command includes several flags (parameters), so click here for a quick breakdown of the whole command if you're interested:

   Flag	Meaning	Purpose in This Command
   openssl req	Invokes the OpenSSL certificate request utility.	Used to create and process certificate requests and self-signed certificates.
   -x509	Outputs a self-signed X.509 certificate instead of a CSR.	Creates a self-signed Certificate Authority (CA) certificate directly, rather than generating a certificate signing request.
   -new	Generates a new certificate request or certificate.	Creates a new certificate rather than processing an existing one.
   -noenc	Skips encryption of the private key.	Prevents OpenSSL from prompting for a passphrase when using the private key. Use this only if you are comfortable storing the CA private key unencrypted.
   -key mtls-ca.key	Specifies the private key file to use.	Uses mtls-ca.key as the private key associated with the new CA certificate. Change this to the name of your CA private key file if different.
   -sha256	Uses SHA-256 as the message digest algorithm for signing.	Signs the certificate using a SHA-256 hash, which is a widely accepted secure algorithm.
   -days 3650	Sets the certificate validity period in days.	Makes the CA certificate valid for 3,650 days (approximately 10 years). You can change this duration if you want.
   -out mtls-ca.pem	Specifies the output certificate file.	Writes the generated CA certificate to mtls-ca.pem. Change this to your preferred certificate filename if desired. But know that this tutorial assumes you named it this way.
   -subj "/C=US/O=YourOrg/CN=relay-mtls-ca"	Specifies the certificate subject non-interactively.	Sets the certificate's Distinguished Name (DN) without prompting for input. In this example, the country is US, the organization is YourOrg, and the common name is relay-mtls-ca. Replace these values with your desired information.
   \	Shell line-continuation character (not an OpenSSL option).	Allows the command to be split across multiple lines for readability while being executed as a single command.

   openssl req -x509 -new -noenc \
       -key mtls-ca.key \
       -sha256 \
       -days 3650 \
       -out mtls-ca.pem \
       -subj "/C=US/O=YourOrg/CN=relay-mtls-ca"
   chmod 644 mtls-ca.pem
   

   This will create a file called mtls-ca.pem, which is your new CA certificate. It is an X509 certificate, which you specified in that command when you ran openssl req -x509...

3. Create your relay server's private key

   openssl genrsa -out relay.key 4096
   chmod 600 relay.key
   

4. Create a CSR (Certificate Signing Request) configuration file

   • Create a file called relay.req.conf and copy/paste these contents to that file.
   • Be sure to replace "YourOrg" and "example.com" and the entries under alt_names to match what you want them to.

   [req]
   distinguished_name = req_distinguished_name
   req_extensions     = req_ext
   prompt             = no
   
   [req_distinguished_name]
   C  = US
   O  = YourOrg
   CN = lr.example.com
   
   [req_ext]
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = lr.example.com
   DNS.2 = wazuh-relay.example.com
   

5. Generate the CSR for your relay server

   openssl req -new \
       -key relay.key \
       -out relay.csr \
       -config relay.req.conf
   

6. Sign the relay's certificate

   openssl x509 -req \
       -in relay.csr \
       -CA mtls-ca.pem \
       -CAkey mtls-ca.key \
       -CAcreateserial \
       -out relay.crt \
       -days 825 \
       -sha256 \
       -extfile relay.req.conf \
       -extensions req_ext
   chmod 644 relay.crt
   

7. Create your relay server's "PEM bundle"

   NOTE

   A "PEM bundle" is a file with a .pem extension that combines a certificate and a private key. This is useful because some tools/services, like the ones we'll be using in this guide, require both to be bundled into a single file.

   cat relay.crt relay.key > relay.pem
   chmod 600 relay.pem
   

Congratulations! If you followed the steps outlined above, you should now have a Certificate Authority ready to use.

Make sure it all worked​

Before we move on, let's quickly stop to make sure you've done everything correctly so far. You should have all of the following files:

If those all look good, it's a good idea to verify that all your certificates were created correctly and that your relay certificate was properly signed with the Certificate Authority (CA) you just created.

Verify the CA Certificate​

Display information about your CA certificate:

openssl x509 -in mtls-ca.pem -text -noout

You should see information similar to:

Issuer: C=US, O=YourOrg, CN=relay-mtls-ca
Subject: C=US, O=YourOrg, CN=relay-mtls-ca

Because this is a self-signed CA certificate, the Issuer and Subject values should be identical.

Verify the Relay Certificate​

Display information about your relay certificate:

openssl x509 -in relay.crt -text -noout

Verify that the certificate contains the hostname you specified:

Subject:
    C=US
    O=YourOrg
    CN=lr.example.com

Also verify that the Subject Alternative Name (SAN) section contains the DNS names you configured:

X509v3 Subject Alternative Name:
    DNS:lr.example.com
    DNS:wazuh-relay.example.com

If the SAN section is missing, clients performing hostname verification may reject the certificate.

Verify That the Relay Certificate Was Signed by Your CA​

Run:

openssl verify -CAfile mtls-ca.pem relay.crt

Expected output:

relay.crt: OK

If you receive any errors, verify that:

• You used the correct CA certificate.
• The relay certificate was signed using the corresponding CA private key.
• The CA and relay certificate files were not modified after creation.

Verify the Certificate Chain​

You can also confirm that the relay certificate's issuer matches your CA:

openssl x509 -in relay.crt -noout -issuer
openssl x509 -in mtls-ca.pem -noout -subject

The issuer reported by relay.crt should match the subject reported by mtls-ca.pem.

If all of the checks above succeeded, congratulations! Your Certificate Authority and relay server certificate are all looking good, and you're ready to move onto the next step.

If anything above didn't look right, don't worry! Just go back through the steps carefully and read each step thoroughly to make sure you didn't miss something.z

Step 2 - Set up HAProxy to relay logs from your monitored devices to Wazuh​

Now, we'll set up HAProxy. This service will perform the dual function of authenticating clients wanting to connect to the Wazuh server and forwarding logs to the server.

Putting HAProxy in between clients and the Wazuh server this way helps reduce the risk of your server being overwhelmed or compromised. If you were to expose your SIEM directly to the rest of the world, an attacker might try perform a denial of service attack by overwhelming the server with traffic. Or, they might attempt to send fake logs to the server to hide normal activity.

So, let's see the setup steps.

1. Pick a place to install it

   • HAProxy needs to run on a server somewhere, so that could be a physical or virtual machine. To preserve the goal of separation, it shouldn't be running as a service on the same machine or operating system that's running your Wazuh server. So, you might create a lightweight VM to run this service. Once you have one installed, proceed to the next steps.

2. Install HAProxy

   • This guide assumes you're using an OS with the apt package manager. If not, adjust commands to match your package manager.

   sudo apt update
   sudo apt install -y haproxy
   

3. Install the certificates you created in Step 1

   NOTE

   First, you'll need to find a way to get your certificates onto the server that will host HAProxy. Do this whatever way works best for you, such as by using SCP (Secure Copy) or with a USB stick.

   All you need to do is copy the files you created in the previous steps (relay.pem and mtls-ca.pem) to the server that will host HAProxy. One you have them copied to the server, use the following commands below to organize them.

   sudo mkdir -p /etc/haproxy/certs
   sudo chmod 700 /etc/haproxy/certs
   sudo cp relay.pem mtls-ca.pem /etc/haproxy/certs/
   sudo chmod 600 /etc/haproxy/certs/relay.pem
   sudo chmod 644 /etc/haproxy/certs/mtls-ca.pem
   

4. Configure HAProxy Modify the file /etc/haproxy/haproxy.cfg and add the following contents at the bottom of the file, making sure to replace <WAZUH_MANAGER_IP> with the IP address of your Wazuh server:

   frontend wazuh_agent_1514_in
       bind 0.0.0.0:1514 ssl crt /etc/haproxy/certs/relay.pem ca-file /etc/haproxy/certs/mtls-ca.pem verify required
       mode tcp
       option tcplog
       timeout client 2m
       default_backend wazuh_manager_1514
   backend wazuh_manager_1514
       mode tcp
       timeout server 2m
       server wazuh_manager <WAZUH_MANAGER_IP>:1514 check
   

5. Validate the configuration and reload HAProxy

   sudo haproxy -c -f /etc/haproxy/haproxy.cfg
   sudo systemctl reload haproxy
   

If the results of the first command in the last step returned "Configuration file is valid" and you were able to successfully restart the haproxy service, you should now have a functioning HAProxy log relay!

This relay is configured to do the following:

1. Handle mTLS authentication by validating the identities of clients wanting to connect to the Wazuh server
2. Attest to its own identity when clients attempt to validate it
3. Forward logs from successfully authenticated clients to the Wazuh server on port 1514

Step 3 - Configure DNS and Networking​

This relay should be publicly accessible so you can receive logs from your monitored devices wherever they go. The steps to set that up will depend on where you're hosting this relay. If you're hosting it at home, for example, you may want to set up port forwarding at your firewall to forward traffic on TCP ports 1514 and 1515 to the log relay.

Next, you will want to configure an entry with your DNS provider to give your log relay a URL so you can more easily tell your devices where to send their logs. For example, you could set "lr.yourdomain.com" to point to your log relay's public IP address, and you're good to go!

You're now ready to move onto part 2 of this tutorial, where you'll learn how to connect a client (also known as an "agent") to Wazuh through your log relay.

If you're using your computer for work, you should be even more careful to protect the information on your computer. In this tutorial, we'll cover how to encrypt your hard drive.

Full disk encryption > encrypted home folder > no encryption​

Full disk encryption is better than just an encrypted home folder, but an encrypted home folder is better than nothing.

The best way to protect your computer's files offline is to enable full disk encryption. This ensures that all (or MOST) of your operating system and files are encrypted. However, full disk encryption of Linux systems is best performed during the installation of the operating system. And if you're reading this, I'm guessing you probably already have Linux installed, and you didn't enable full-disk encryption when you set it up. That's okay! In this tutorial, we'll cover the next best thing: encrypting your home folder and swap partition.

Preparation​

Installing the tools​

First, install ecryptfs-utils and cryptsetup.

sudo apt update && sudo apt install -y ecryptfs-utils cryptsetup

User configuration​

The user whose home folder is to be encrypted needs to be logged out during this process, and the one performing the encryption needs to be a sudoer (administrative user). If you already have another sudoer account on your computer, you can skip to the next step.

To set up a new sudo-enabled account on Ubuntu, open Settings > System > Users. Then click on Unlock... in the top right corner and type in your password.

Next, click Add user and create the user. Make sure to make the user an administrator!

After creating the new user, log out of your user session.

Migrating to an encrypted home folder​

At this step, you should:

1. Be logged in as a sudo-enabled user
2. Not be logged in as the user whose home directory is to be encrypted
3. Have a backup of the home directory to be encrypted

If that's true for you, go ahead and open a terminal and run this command. (Replace <user> with the name of the user whose home directory you want to encrypt):

sudo ecryptfs-migrate-home -u <user>

You'll be prompted for a password. Type the password of the target user (not the user you're logged in as.)

Once the command finishes, you'll see a few informational messages. Basically, they say:

1. You need to immediately log into the user whose home folder was just encrypted, before the next reboot.
2. The script automatically backed up the user's home folder so it can be restored if something went wrong.
3. The script generated a mount passphrase for the home directory. Hopefully, you'll never need to use it, but you can use it to decrypt the home folder if it ever fails to decrypt at boot-up.
4. You should also encrypt your swap partition. (More on this below.)

Log back in as the user whose home folder was just encrypted, open a terminal, and run this command:

ecryptfs-unwrap-passphrase

When it prompts you for passphrase: , type in your user's password. Then, you'll see a random string of characters. This is your mount passphrase, and you should save it somewhere safe like a password manager.

Encrypting the swap partition​

When you install Ubuntu with full disk encryption, your swap file is encrypted too. Lenovo has a pretty good explanation of swap files and it includes this quote:

"A swap file is a file on your computer's hard drive that is used as virtual memory. It is an extension of the computer's physical memory random-access memory (RAM) and acts as a temporary storage space for data that doesn't fit in the RAM."

That means data from your home folder could get loaded into the swap file temporarily, which might leave it vulnerable to attack. So, encrypting your swap partition is a solid way of making sure your encrypted data stays encrypted.

Before running this command, I recommend you alter the script slightly, and I'll show you why.

When you run the script to encrypt your swap partition as-is, you're likely to encounter a message stating:

“swapon: cannot open /dev/mapper/cryptswap1: No such file or directory”

This isn't necessarily a bad thing, and the script hasn't necessarily failed. There is a call within the script that runs systemctl restart cryptsetup.target after modifying /etc/crypttab. However, it does so without first calling systemctl daemon-reload. According to freedesktop.org:

“systemd-cryptsetup-generator is a generator that translates /etc/crypttab into native systemd units early at boot and when configuration of the system manager is reloaded.”

Therefore, the changes won't take full effect until either a reboot or manual re-run of the generators. So, you have two options:

Option 1 (recommended): Modify the script:​

First, locate the script with this command:

which ecryptfs-setup-swap

Then, open it in your editor of choice. (for example: sudo nano /usr/bin/ecryptfs-setup-swap) and add systemctl daemon-reload above systemctl restart cryptsetup.target near the end of the script as shown in the screenshot below:

Once you've modified and saved the script, you're ready to run it! Use this command to run it:

sudo ecryptfs-setup-swap

Option 2: Restart after running the script​

If you run the script without modifying it, you'll encounter a message stating:

“swapon: cannot open /dev/mapper/cryptswap1: No such file or directory”

After encountering that message, reboot your computer and your swap partition should be successfully encrypted. To verify that it worked, see the next section.

Verifying successful encryption​

To verify that your home folder and swap partition were successfully encrypted, run these two commands. (Again, replace <username> with your username)

findmnt --target /home/<username> | column -t

sudo dmsetup table /dev/mapper/cryptswap1

Clean-up​

If you've gotten through all those steps and were able to verify successful encryption, you're in great shape! In case you haven't already, you'll just want to make sure you can still read/write to your new home directory just to make sure it works. If that looks right, you can go ahead and delete the backup folder you created, as well as the one the script automatically created for you.

rm -rf /home/tailoredsec.HYSCiPFk

Why are some criminals good detectives?​

I read a LinkedIn post recently in which the poster argued pretty vehemently that anyone who thinks hacking is an important skill for cybersecurity is seriously mistaken. He drew an analogy to accounting and said that no accountant needs to be good at committing fraud in order to detect it. At first, I was intrigued by his argument and wanted to understand how it could make sense. But the longer I thought about it, the more I felt like he was making the wrong argument. I don't think it's really about knowing how to commit crime; It's about knowing how criminals think.

I regularly attend penetration testing workshops taught by a Penetration Tester who works for AWS (Amazon Web Services). In these workshops, he explains pentesting concepts and walks through techniques for finding and remediating vulnerabilities in applications. Sometimes, he also shares stories of vulnerabilities he has found in real-life engagments and lessons they taught him.

In one recent workshop, he explained how he found a cross-site scripting vulnerability in an application and demonstrated how he could inject malicious code into the web page by using <script> HTML tags. When he reported this vulnerability to the application developers, their response was to write code that 'sanitized' user input by erasing any instances of the tag <script> from user input, like so:

function sanitize($input) {
    return str_replace(['<script>'], '', $input);
}

The developers failed to consider the myriad of other methods a hacker might use to inject malicious code to their website, such as enclosing the malicious code in another type of HTML tag, or using any of the following variations on the <script> tag:

• <SCRIPT>
• <ScRiPt>
• <scr<script>ipt>

What this example demonstrates is not that the developers didn't know HOW to hack. I'm sure any one of them would have been capable of writing a malicious script and injecting it into the web page... But it's clear that none of them were thinking like hackers. They didn't consider the mindset of an attacker who, upon meeting an obstacle, immediately looks for creative ways to evade the obstacle.

Detecting crime vs preventing it​

To refer to the LinkedIn post I mentioned at the beginning, I'll give the author some credit... He may be onto something when he says 'you don't need to know how to commit crime to detect it.' But then again, cybersecurity isn't just about detecting cybercrime, is it?... It's also about preventing cybercrime!

After all, what good is it to 'detect' theft if you can't prevent it from occurring in the first place? If you can't do that, the theft will likely continue. You can't stop someone from breaking a rule until you know how they're breaking it. For example, maybe someone has been stealing snacks from your vending machine, and you want to stop it. You might assume that they're shaking or tilting the machine - and decide to anchor the machine to the ground. But if all they're doing is attaching a string to their money so they can pull it back out after purchasing a snack, your 'theft detection' hasn't done you any good.

An adversarial mindset informs & improves defensive tactics​

Knowing how to hack may not make you significantly better at 'detecting' cybercrime... but knowing how to think like a hacker can certainly make you a better defender! Employing an adversarial mindset (thinking like an attacker) helps you consider tactics, techniques, and procedures an attacker might use against you. Jayson E. Street once shared the following:

"Every place that I tried to secure. I first assessed how I would steal from it."

When defenders can learn how to think like attackers, they'll be much more prepared to proactively prevent intrusions and reduce vulnerabilities. And I can't think of a better way to learn how a hacker thinks than learning how to hack.

So yes, hacking skills are important for cybersecurity. And not every security professional needs to be good at hacking, but we definitely need hackers to help us stay ahead in the perpetual game of cat and mouse that keeps us all on our toes every day.

You may have heard of so-called ethical hackers... But what makes them different? And how clear is the line between them and 'the bad guys'?

Hint: It's not as clear as you might think 😉...

Isn't hacking stealing? a.k.a. BAD??​

That is a fair question that highlights a need to define 'hacking'. While many equate hacking with stealing, I prefer another common definition for hacking:

Manipulating technology to make it behave in a way that differs from its original design.

I believe this is a more helpful definition than 'being bad and breaking into computers and stealing stuff,' which seems to be the most commonly implied definition by modern media outlets.

This is a more helpful definition because it still effectively conveys a clear meaning, but it also promotes a broader understanding of what it means to hack. It also removes some of the unnecessary stigma around the term.

To reiterate, no. Hacking is not (necessarily) stealing.

Of course, hacking can involve stealing... I think it's pretty clear that manipulating a computer to reveal sensitive information without proper authorization falls under the larger definition of hacking that I mentioned earlier. So is that ever okay, and if so, when?

'Ethical' vs 'Unethical'​

While most of the world will probably always see hackers as nasty bad guys that break into computer systems, we in the security community have a more nuanced perception of hackers, often classifying them as 'white-hat' or 'black-hat' based on whether they have permission to do their hacking.

We'll often call someone a 'white-hat hacker' if we deem their actions to be ethical (watch out for that word... we'll talk about it more), but even with our nuanced perceptions, it's often difficult to label someone's actions as purely 'ethical' or 'unethical'.

But what is ethical?

The dilemma​

One doesn't have to spend much time researching the topic of 'ethics' to find out that it's quite subjective. One of the most generic definitions you'll find for 'ethical' behavior is:

"conforming to generally accepted standards of conduct"

So it sounds like ethical behavior is behavior that conforms to generally accepted standards of conduct. But doesn't that change wherever you go? Different countries have different laws and cultures, and even different communities in the same region have unique customs. For example, here in the United States, it's perfectly acceptable in many areas to carry a gun in public places. However, there are many countries throughout the world - and even some places in the U.S. - where such behavior is strictly prohibited.

Thus, it seems that ethicality depends a lot on external factors - and those factors vary greatly between different places and contexts. The dilemma is: it's hard to know what's ethical and unethical depending on where you are. (BUT, that doesn't mean it's not important, and I'll talk about why near the end of this post.)

Ethics vs Morals​

What would you say is the difference between ethics and morals? That's a question that had me thinking hard... and it seems like it's had that effect on others as well. Many dictionaries list ethical and moral as synonyms! But that's really interesting to me, because one such dictionary defines 'moral' as:

conforming to a standard of right behavior | (as opposed to wrong behavior)

But who decides what's right and wrong? As a religious person, I personally believe God is essentially the one that dictates that, so it's certainly not up to 'the masses' to determine what's right and wrong. Even if everyone in the world thinks something is right, that doesn't make it right.

Even if you don't believe in God, I think you'll agree that other people don't get to decide what's right and wrong for you. And if you don't believe God decides what's right and wrong, I'm willing to bet you probably believe you are the one who decides what's right and wrong. (Technically, you might even say that's what I'm doing, because I make decisions based on what I believe God would want me to do.)

Therefore: if ethics pertain to what's socially acceptable/unacceptable, and morals pertain to what's right/wrong, then I don't think ethics and morals can be the same thing. Ethics and morals may align sometimes, but they're not the same thing. You may disagree, and that's fine! But that's not really the point I'm trying to make here. I'm setting the background for something much more important. For the purpose of this blog, I will stipulate that:

• Ethics are interpreted by other people.
• Morals are interpreted by you - and only you.

The importance of intention​

I'm sure you've heard phrases like these before:

• "It was not my intention to..."
• "I didn't mean it that way."

These phrases are both referring to the concept of 'intention'. Intention refers to the purpose or goal someone has in mind when performing an action. When making a decision between right and wrong, intention can influence interpretation greatly. This is why the concept of 'white lies' exists. A white lie is a lie that is told with righteous intention. While most people generally consider lying to be wrong, they recognize that the intention behind a lie bears significant weight when determining whether lying is the right or wrong thing to do.

With ethics, however, intention doesn't seem to hold quite as much weight. I'll admit that intention seems to have some significance when it comes to ethics, but not as much as morals. Why? I think it's partially because it's much easier for one person to decide whether something is acceptable or unacceptable than it is for multiple people to agree on such a decision.

Why does this matter?: I think this is important to understand because - while I believe you should make ALL decisions based on what you think is right (morally correct) - you would be foolish to ignore what other people might interpret as ethical (socially acceptable).

Why do ethics matter?​

Imagine that you're at a dinner party with a family that has invited you to their home. (And let's assume - for the purpose of this exercise - that you want to be there.) You, as their guest, are expected to behave a certain way. If you do not follow their rules and customs, you risk offending them. Offend them badly enough, and you may just get kicked out of the house.

The fact that what you did offended the family does not make it wrong. But their interpretation of your actions as unacceptable still affected you negatively.

That leads me to the first reason that ethics matter: Other people will probably attempt to punish you if they think your actions are unacceptable. You don't get to decide what other people think is right and wrong, and you shouldn't expect them to care about what you think is right and wrong.

Reason number 2 that ethics matter: You get to help decide what's ethical in your community. I won't focus much on this one because it doesn't pertain much to my argument, but I'll say this... If ethics is something interpreted by the people around you, you play a role in deciding that as a group. It's in your best interest to contribute to the development of your community's ethical standards such that they agree with your own.

Are you an 'ethical' hacker?​

I've already mentioned how security professionals have terms like 'white hat hacker' and 'black hat hacker.' A white hat hacker is someone who hacks only with permission from the person/entity they're hacking, and generally has good intentions. A black hat hacker hacks without permission and generally has malicious intentions.

But what about the in-between? What about people who hack without permission but with good intentions? (or at least benign intentions...) Most would consider them 'grey hat hackers'. Are they ethical or not?

Well, if you agree that ethics are determined by other people, then you can only consider yourself an ethical hacker if your hacking is acceptable to others. That may differ from your beliefs about what it means to be an 'ethical hacker.' From my conversations with other hackers, it seems to me that most of them consider themselves 'ethical' hackers because they never hack with malicious intention, even if they sometimes hack without permission. However, I want to warn against this kind of thinking. Many hackers who think this way have gotten themselves arrested over the years, and it's caused them a world of hurt.

Stories of grey-hat hackers who got in trouble​

Here are some cautionary tales just to drive the point home.

• Alberto Daniel Hill from Montevideo, Uruguay. He found a weak login page on a medical provider's website and hacked it practically by accident. He notified the medical provider in an effort to help them fix it, but he was later arrested and spent 9 months in prison. Listen to his story in this podcast.
• Martin Gottesfeld, from Andover, Massachusetts. He hacked a hospital (It's a little hard calling him a grey-hat hacker because that's pretty messed up. But he swears he thought he was doing the right thing.) in protest of the hospital's treatment of a 15-year-old patient. Listen to the story in this podcast.

Conclusion​

Are you an ethical hacker?... You don't get to decide.

Only other people can decide that for you.

Since only other people can decide whether you're an ethical hacker, I would say grey-hat hackers should be very careful considering themselves 'ethical hackers.'

If you're interested in hacking, that's awesome! I think it's an incredibly rewarding hobby, and you should totally give it a shot. But if you want my advice... You'll do well to keep your hacking ethical.

Resources for learning ethical hacking​

Check out these awesome resources that will help you learn hacking safely and ethically!

• TryHackMe
• HackTheBox

There are MANY more, but these are the two that I've used for the most part and I have thoroughly enjoyed them.

Priorities​

With the recent surge in the capabilities and prevalence of

Whenever I use GenAI to create something, I have two main priorities:

1. Security​

   • You should treat AI like a stranger, and you shouldn't share information with it that you wouldn't share with a stranger.

2. Accuracy​

   • AI has a remarkable ability to produce inaccurate content with astounding confidence. Carefully-crafted prompts can help you increase your chances of getting good results.

Because those two things are so important to me, I avoid sharing overly-specific information in my interactions with AI. This originally came from my desire to preserve privacy and security, but I found that it yielded unexpected improvements in the area of accuracy as well.

The power of abstraction​

I recently watched a video interview in which computer scientist David J. Malan explained how the internet is built on layers upon layers of patterns and ideas, which he calls abstraction.

In the video, he talks about how everything we see on the internet comes from from data like 1s and 0s. That data follows certain patterns that allow it to become something much more rich and meaningful. Thanks to that technology, millions of different kinds of people and machines can communicate with one another in a way they can all understand. I highly suggest watching the 1-minute clip from that video below.

By taking a similar approach to communicate with AI, using patterns instead of specific data, I have been able to achieve greater security and accuracy.

Examples​

Here are two examples of how I've recently used this strategy to achieve desirable results with AI.

1) Manipulating a graph​

I recently had to alter the structure of a large graph with tons of nodes with relationships between them. Essentially, my task was to take something that looked like this:

and turn it into this:

It seems like it wouldn't take too long, doesn't it? Well, the tricky part is the graph I had to alter looked more like this:

As I'm sure you can imagine, I knew that it would be impossible for me to do that task unaided. I would surely end up taking tons of time and committing countless errors along the way. So of course, I thought "Hey, I'll get AI to help!" But I couldn't just share the data with ChatGPT. First of all, it was way too much data to share with it directly, and second, the data was sensitive, so I had to protect the actual data in the graph.

To solve these problems, I asked AI to write a Python script to edit the data for me! I'm learning Python, but my skills aren't to the point where I could do this myself, and I knew that AI would be able to write and iterate upon the script much more quickly than I could. Here's what the process looked like:

1. To start, I came up with an abstract example of the type of graph I wanted the script to alter (like the simplified examples I showed above). These simplified examples had all the sensitive information stripped out, with just enough structure to help the AI know what I needed it to do.
2. I crafted a descriptive prompt explaining the type of data I was working with, included the example data, and carefully explained exactly the types of changes I wanted it to make, and the ones I wanted it not to make. In this explanation, I made sure to use patterns wherever possible to keep my instructions generalized.
3. I tested the script and gave feedback, describing the results enough to help the AI understand what went wrong, and kept what worked.

After a little back-and-forth with the AI as I tested the script, I was able to achieve exactly what I needed with 100% accuracy, in a fraction of the time it would have taken me to do it myself, and without compromising the confidentiality of the graph data.

2) Organizing an email list​

In another project recently, I had to take an unorganized list of 1800 email addresses and group them by domain. The list contained individual email addresses — in no particular order — of people that worked at different organizations. I needed to figure out which email addresses belonged to which organizations, and group them together by organization.

So, once again, I went to AI for help. And instead of giving it the raw data, I asked it for a Python script to help me organize the data. Here's how I did it:

1. I gave the AI an example of the data I had with a general explanation.
   • "I have a spreadsheet with 1800 email addresses. They're all in a column titled email. . ."
2. I included a thorough explanation of what I wanted with another example of the outcome data.
   • ". . . I want you to write a Python script to organize the emails by domain. The output file should have 1 column titled domain and another column called emails with the email addresses belonging to that domain separated by semicolons. For example: email1@test.com; email2@test.com; email3@test.com
3. And then I went back and forth with the AI to give it feedback.
   • In this particular example, I actually got exactly what I wanted on the first try! The iteration came later when my requirements changed, but I was able to simply follow the other steps again to revise my results to fit my needs.

The Process​

This process I've developed has become one that I regularly follow in my work with AI. Here's how I would break it down:

1. Create an abstract model of your desired outcome.
   • Give the AI somewhere to start. This helps it get the structure and format right, and helps you protect the specific details of your important data.
   • If you're manipulating existing data, give it examples of the before and after (again, like you saw with my example above.)
2. Craft a descriptive prompt that uses patterns to outline requirements.
   • It's a good idea to give lots of guidance. The more guidance you give, the more reliable your results will be. Luckily, you can edit your prompt and try again if the AI doesn't give you the results you want the first time.
3. Give feedback and work with the AI to revise your strategy
   • AI probably won't get it right on the first try. Keep working at it! Tell it what went wrong and what you want it to change. As you make small tweaks, you'll see improved results very quickly.

I encourage you to try out that process for yourself! I'm confident that it'll help you increase your productivity, security, and accuracy in your use of GenAI. Lastly, I'll include some bonus tips below that help me when I work with AI.