CJIS Cybersecurity in the Age of AI

The Cybersecurity Incident Heard ‘Round the World

Last week was a wake-up call for cybersecurity practitioners, especially those handling sensitive data like CJI.

In case you missed it, researchers using AI models found vulnerabilities in a programming language called PHP that had been considered exceptionally difficult to exploit.

Click here for the full story.

The vulnerability basically lets an attacker completely take over a server. For example, they could launch executed code that sends all of your files to their storage system.

Obviously, if you’re handling CJI, that’s an imposing threat.

But, this isn’t just any cybersecurity exploit. What makes this one such a big deal is that AI can make vulnerabilities once considered impractical to exploit much easier to attack.

What this exploit taught us is that AI agents can help attackers discover and exploit vulnerabilities faster. They can also help defenders find and fix those vulnerabilities before attackers do.

This is important because some systems rely on obscurity or complexity to make attacks difficult. That can make an attacker’s job harder, but it is not a substitute for strong security controls.

If you’re an IT professional responsible for the security of CJI, this is a critical moment for you. Many of the CJI systems I’ve seen rely too heavily on obscurity or complexity to protect their data.

The good news is, cybersecurity best practices still hold. We just have to implement them diligently.

Let’s talk about what you can do as an IT professional to secure your systems in the age of AI.

Security Vectors

There are three major pillars of cybersecurity. All IT professionals know what they are. The problem is that many have ignored pieces of them because they believed the obscurity or complexity of the system was enough to defend against attackers. We'll talk more about that shortly.

First, the locks.

Locks are the most important cybersecurity mechanism that exists.

Think of locks as the thing that governs access at system entry points. Just like locks on your doors at home. The point of a house is to be inside, but you only want certain people in there.

Like your house, software is meant to be used! As IT professionals we build doors for users to enter the system and use it.

Examples of locks in cybersecurity are passwords, encryption keys, and multi-factor authentication.

Locks are used to make sure someone trying to access a part of a system or a piece of data is authenticated as the person they say they are and has authorization to see the thing they want to see.

Even more, we can add locks across the system. For example, we can add a lock for who can access the software, we can add a lock for certain pieces of data, we can add locks for different features, etc…

This is called, “defense in depth”. At every level of exposure, if you’re missing authentication or authorization the lock to that level shouldn’t open.

Locks are the simplest way to secure your system. But are your locks sufficient? More on this in the next section.

Second, the walls.

Let’s use your house as an analogy again, secure software has walls. Walls ensure that people (and now AI agents) are only able to access the system where we allow them to. Any attempt to enter a system outside of the doors we build is completely blocked.

Like locks, walls are built at different levels.

We have walls around the entire application to ensure people (and now agents) can only access at certain entry points. And we have walls within the application to make sure certain parts of the application are separated from other parts.

Many people assume that just having walls around the application is sufficient. If the entire application is walled off with only one entry point and a lock, we can safely assume only authenticated and authorized users will get in, right?

Unfortunately, attackers can find weaknesses in a lock, and AI may help them do so faster. If breaking that lock gives an attacker access to everything in the application, that’s bad!

Now more than ever, it’s important to have walls around all key parts of your systems that contain CJI.

For example, in CaseBase we have different “services”. One service processes audio so we can create transcriptions, another service serves the frontend (UI) to users, another service processes database transactions, etc… Each one of these services has a wall around it.

AND, each one of those walls has a door with a lock only exposed to specific other services in the CaseBase stack.

Third, the maze.

The maze used to be a material factor in determining cybersecurity vulnerabilities. The maze is broken down into two stages.

Stage one is: How likely is an attacker to actually find our application/data? If we have a small app, with few users, and nothing that we believe to be highly valuable will someone even try to breach our system or be able to find it?

Stage two is: How difficult is it for an attacker to understand and exploit our application? An unfamiliar or complex system may slow an attacker down, but complexity alone is not a reliable security control.

The PHP vulnerabilities illustrate the problem. Turning the flaws into working exploits required a complex chain of steps, but researchers used AI to help make that work practical. AI can reduce the time and expertise needed to find and adapt an exploit.

Limiting what data your code returns remains important. But hiding a system or relying on its complexity is not enough on its own.

What Should You Do?

Alright, you’ve heard enough doom and gloom from me. We know the three vectors of cybersecurity, we know how AI changed them, but what should we do about it?

Good news! The principles of good cybersecurity remain the same. We just need to take them more seriously.

You don’t have time to go into every possible thing that can be done to secure your data, so let’s talk about four important things:

#1: Multi-factor authentication

You probably already enforce passwords across your software tools, and have some minimum complexity required. That’s a good start! But are you enforcing the use of multi-factor authentication (MFA)?

Agents are now incredible at exploiting single password entry systems. This is why having a backup is so important. MFA requires users to provide two or more different factors, such as a password and a code generated on their device.

This makes it harder for an attacker to gain access with a stolen password alone. MFA can still be bypassed, so phishing-resistant methods provide stronger protection.

If you don’t have MFA set up for all of your critical data handling systems now, this is the number one most important thing you can do.

#2: Inventory and patch your systems

Keep an inventory of the software and services that handle CJI, including the components and dependencies they rely on. Know who is responsible for keeping each one up to date.

When a critical vulnerability is announced, identify affected systems and apply the vendor’s security update promptly. If an update is not immediately possible, follow the vendor’s and relevant agencies’ mitigation guidance until it can be applied. For the PHP vulnerabilities, the NSA recommends patching and taking affected systems offline when they cannot be immediately updated.

#3: Protect and rotate your encryption keys

As an IT practitioner handling CJI, you probably have a set of encryption keys for your data or the software company managing your tools does. Limit access to those keys, store them securely, and rotate them according to a documented policy and the requirements that apply to your agency.

If a key may have been exposed, respond immediately: restrict access, replace the compromised key, and assess whether affected data needs to be re-encrypted. Rotation alone does not necessarily protect data that was already exposed. For example, AWS KMS key rotation does not re-encrypt existing data or mitigate a compromised data key.

#4: Make your logging and alarms more robust

While it’s crucial to make sure our active cybersecurity defenses are up to snuff, we should expect new vulnerabilities to be discovered, including ones that are difficult to anticipate.

What’s most concerning about this is these vulnerabilities can exist at every layer. The runtime you use, the cloud hosting environment, your own code, or the managed services you use that touch your data.

Because of that, it’s important to log security-relevant activity and set alerts for unusual behavior. Avoid recording sensitive data unnecessarily, restrict access to logs, and retain them according to your agency’s requirements.

You should assume your system will be breached. It’s no longer safe to assume otherwise. The best way to protect yourself is to make sure you can respond as fast as possible.

The most important logs you can add are:

1. Who logged in, when, and where.
2. What data was accessed

At CaseBase, we host our platform in AWS. AWS provides logging and alerting tools that can help teams monitor events such as suspicious web traffic and repeated failed requests. Those are examples of activity worth investigating.

What Next?

The vulnerabilities from last week won’t be the last we hear about. As the capabilities of AI progress it’s certain more and more complex vulnerabilities will be uncovered. As IT professionals handling CJI, it’s our obligation to do everything we can to protect the data we store.

The truth is, everyone is now playing catch up. You cannot wait until something bad happens to your data before you do something. Inventory your current defenses, build a plan to improve them, and at a minimum take the four steps above to start hardening your system.

If you have any questions about securing your CJI data, send me an email at tyler@casebase.co. I’m happy to chat with you about how we secure our data and what you can do to improve your own security posture.