3 things to know about how the CJIS Security Policy applies to your agency and your RMS software
Data Security and CJIS Compliance are daunting topics, especially to those without much experience with the “deep end of the pool” of computers. But a little bit of knowledge goes a long way towards keeping your agency compliant.
With more than a decade of experience with the CJIS Security Policy and having spent several years as EFORCE®’s TAC (we have an ORI through our home State of Utah, and thus a TAC), I’ve helped our customers successfully complete their CJIS Compliance Audits. EFORCE® is also audited tri-annually as well, and we’ve passed every one of those audits.
Working with agencies over the years, I’ve seen most agencies struggle with the same things. This article will cover some information that has helped those agencies with passing their audits and more importantly, staying secure and compliant between audits.
What is CJI, Really?
This seems to be a major source of confusion for agencies during their audits. Understanding the difference between Criminal Justice Information (CJI) and Personal Identifying Information (PII) is crucial to ensuring that you are compliant. Also, if you have a system in which you’re not entering any CJI into, you can save you and your auditor time and headache.
The FBI CJIS Security Policy defines CJI as, “all of the FBI CJIS provided data necessary for law enforcement and civil agencies to perform their missions including but not limited to biometric, identity history, biographic, property, and case/incident history data.” (FBI CJIS Security Policy, Section 4.1, Page 20)
At surface level, that seems to cover all information that you would encounter in a Law Enforcement Software system; information about people, and their involvements with the Police. But there’s a key phrase that most folks gloss over: “FBI CJIS provided data”. To boil this down, this means: information that your agency obtained from the FBI via databases like NCIC. Most States have also extended this definition, through their own policies, to include their own State databases (TLETS in Texas, UCJIS in Utah, etc.).
Many people confuse the terms for CJI and PII. PII is of course information that we want to keep secure and private. But the important distinction is that it does not come from databases belonging to the FBI or the State.
To best understand this, let’s examine a scenario in which you make a traffic stop. You collect the driver’s license and run them through NCIC and your State Databases, receiving a return. In this scenario, let’s examine what is CJI and what is PII. Remember our definition is data provided by the FBI and the State. So, the person’s name, date of birth, OLN, height, weight, etc. is PII, not CJI. We know this information because the driver told us, or we saw it on the card itself. Whether or not the driver is wanted, etc. is CJI, because we only know that information because it came from NCIC.
Understanding the difference between PII and CJI, and the rules for handling each type of sensitive information will save your agency a lot of frustration come audit time.
The FBI CJIS Security Policy, Simplified
Weighing in at a whopping 253 pages, the FBI CJIS Security Policy is a beast. But if we reduced the entire policy to one sentence it might read, “Your agency has to be careful with how you store, share, and access certain information.”
Your auditor will be primarily looking at the policies, procedures and hardware your agency uses to safeguard CJI in your care. When it comes to your software system, the auditor is going to look at the security of CJI “at rest” and “in transit”. In other words, “How are you protecting the CJI you’re storing, and how are you controlling who can access it and how they access it?”
Long story short, you need to protect your data storage device (your server) and you need to encrypt (or scramble) the CJI as it moves through the internet to the device that you’re accessing it from (like the laptop in your car). That encryption must be certified to meet the Federal Information Protection Standard (FIPS) 140-2 encryption standard. Most agencies use a firewall that’s FIPS 140-2 certified to accomplish this.
To better understand that, let’s compare your agency’s handling of CJI to a bank’s handling of money. The mint produces the money and delivers it via armored transport. The Bank keeps the money secure in their vault with a sturdy door and lock, and by limiting the people who can open the vault. When they need to move money from their vault to a business, they again use an armored truck to protect the money in transit.
It’s the same with your agency. Like the mint, your State/Federal Databases deliver CJI to you. Like the bank’s vault, your server stores that CJI. Your firewall does double duty, both as the lock protecting the vault, and the armored truck transporting the data to and from your server. You also safeguard the CJI in your care by regulating the people who can access that CJI. The FIPS 140-2 standard regulates the amount and the type of “armor” that the “truck” needs to have.
There’s a lot to the policy, but that’s the cliff notes version.
“CJIS Certified” is a Myth that Vendors use to Sound Good
This one comes straight from the mouth of Jeff Campbell, Deputy ISO for the FBI’s CJIS Division. There’s no such thing as “CJIS Certified Software”, or for that matter, “CJIS Compliant Software”. Some software vendors claim that they are in fact certified or compliant, but you need to recognize that the hardware their software is installed on is usually the determining factor.
Unless their software is certified by the National Institute of Standards and Technology (you can ask for their certificate as verification), to say that their software is blessed with the magical touch that “no matter where you put it, you’re good” is just not true. Your software has to “live” somewhere. There’s a computer somewhere with the code and files that makes the software work.
Their software is just one piece of the puzzle. Like I said before, your auditor cares more about the place that information is stored, and who has access to it than the application itself. Don’t get caught in this trap. The only entity that can say you or your software is CJIS compliant is your State’s CJIS Auditor’s Office.
Conclusion
While our software isn’t “CJIS Certified”, we definitely have the knowledge and experience to get you setup in a compliant way. Whether you install your software on a server at your agency, on a Government Cloud Server solution like Azure or AWS, or in our hosting center, helping you store that data in a compliant way is our top priority.
We’d love the opportunity to talk more about how we can help you do that. Feel free to call us at 888-570-4943, x. 3 or send an email to [email protected].
