The Commission on Accreditation for Law Enforcement Agencies, otherwise known as CALEA, for example, promulgates standards considered to be industry best practices for law enforcement and public safety agencies. What also makes these standards incredibly helpful to agencies is that CALEA routinely reviews. During the review process, they include subject matter experts as well as client input, to determine if changes are needed. This makes the accreditation standards a dynamic force in the pursuit of excellence. As our society, communities, and the public safety profession changes with time so do the standards.
Isn’t the end all the actual IT (Information Technology) accreditation standard?
Agencies are involved in an accreditation process are task with developing policies, procedures, and practices that are compliant with the accreditation program that they belong to. To the novice accreditation manager or policy writer, this may seem like an easy task or assignment when in reality, it is the opposite. Accreditation standards only tell you what you have to comply with. However, they do not tell you how to comply with. Compliance is up to the agency. This is a crucial element of the accreditation process because it leaves a lot of latitude to an agency that may not be up to the task. Accreditation standards and accreditation programs have to be developed this way because each state has its own regulatory guidelines as promulgated through their legislature, prosecutorial organizations, case law, etc. It would be impossible for accreditation program to be specific in nature unless it was managed by the State’s Association of Chiefs of Police (e.g., the New Jersey State Association of Chiefs of Police or NJSACOP).
Is a legal review by an attorney really a necessary part of the process?
Legal Review is a process used to determine if a document is legally sound and therefore would hold up in court as a solid piece of evidence.
With the above in mind, it is incumbent upon each agency, accreditation manager, policy writer, and their command review process to make sure that promulgated policy is compliant both with the applicable accreditation standard in addition to state-specific regulatory compliance. Routinely, when I am consulting with a department, I have them reviewed their draft policy with an appropriate legal counsel for legal compliance. This is a critical step in the review process. Keep in mind there are many specialties when it comes to legal representation. For the most part, accreditation managers and policy writers will be dealing with their municipality’s labor attorney. However, in the case of this article, they would have to have any policy that has been developed reviewed by an attorney who specializes in risk management for IT infrastructure. This is an essential step in the process of assuring that any IT promulgated policy will stand a legal test if used against the agency. For example, ransomware has become commonplace in the municipal environment including Police Departments. Insurance companies are becoming better educated in this growing and evolving field. Departments who fall victim to a cyber-attack will inherently become involved in potentially significant damages. Departments to maintain a robust IT policy that is compliant with what is considered to be best practices in the IT field, reviewed and approved by an IT attorney, stands the best chance in recovering monetary losses and having their insurance carrier back their claim in its entirety.
How do I even get started writing an IT policy for my department?
OpSec is a military term that has been adopted by law enforcement organizations to mean information that is vital to operational security and should remain secret.
So, the first question you probably have it, “how do I get started writing an IT policy?” That’s an excellent question and one I hope you spend a lot of time thinking about. With that, I mean, an IT policy is not like your regular operational policy. It can be highly technical, often change due to technological advancement, and contain operational security (OpSec) secrets that cannot be known outside the organization.
What is OpSec, and how should I develop a policy with it in mind?
The first thing you have to realize is that this policy should not and cannot be shared with the public under any circumstance except court order. Many agencies simply release the policies when asked upon in order to comply with state law. However, many do not take into consideration the significance and critical nature of OpSec. The reason why I bring this up is that a policy can be developed in many different ways. A policy can be developed and written in a straightforward manner where all the information is contained within a single document. Policies that provide specific information related to OpSec and where the states open Public records laws are robust in favor of release, I suggest writing a policy that contains OpSec in two parts. The first part would be basic language that contains minimal to no OpSec information. The second part of the policy would be in an appendix that contains all the types and specifications of hardware or software and security agents. This way, the department can easily release the first part of the policy with minimal redaction for transparency purposes and hold back the appendix under the trade secrets clause of many state laws. This process should be established in advance with the department’s municipal records attorney.
Once you’ve decided what message you’re going to use to write the policy next, you need to bring in subject matter experts to assist. I strongly suggest staffing a development team that needs to in-person or virtually through a platform like GoTo Meeting. The ability to confer and discuss practice and procedure is critical in developing both a robust policy and a policy that is easy to follow by the personnel who will be charged with its compliance at the operational level.
What source documents should I look at to develop an IT policy for my department?
CJIS Security Policy is an FBI directive that provides framework for compliance with CJIS security requirements.
Once your team is in place, the first regulatory item I suggest reviewing as a framework is your applicable accreditation standards. Obviously, this is critical in complying with your accreditation program and successfully achieving accreditation. Second, your team should review in its entirety the Federal Bureau of Investigation’s CJIS Security Policy. The CJIS Security Policy provides departments with regulatory material that they must comply with in order to participate in the CJIS program. The focus of this Policy is the control of unauthorized access to records, both digital and physical, that contain Criminal Justice Information (CJI) and Personally Identifiable Information (PII). It is incumbent upon all departments who participate in the FBI’s CJIS program to be compliant with the CJIS Security Policy for all relevant areas, and there are a lot. For guidance and basic CJIS Security Policy interpretation for the local level, accreditation managers and policy writers may reach out to the FBI through established channels posted on the FBI CJIS Security Policy Resource Center website.
What are some of the essential requirements of the CALEA and NJSACOP accreditation standards for IT security?
An accreditation standard that relates to the IT function as promulgated by a public safety or police accreditation commission will typically deal with four (4) essential areas.
The first area has to deal with the backing up of data at rest. Once again, the accreditation standard just states that a department has to have a process for maintaining the security of their central records computer systems to include data back-up, but they do not tell a department how to do that. For other simple standards, it’s easy for a department to come up with their own process but for technical or complicated standards such as IT, standards departments really have to rely upon other best practices in order to develop their policy. Some decisions that should be made in backing up data at rest are as follows:
- Will the back-up data be stored on-site or off-site?
- If the back-up data is stored on-site, is it stored in a manner to protected from fire and water damage or loss?
- If the back-up data is stored off-site, how does it get there? If transmitted electronically, is encrypted? If hand-delivered to a secondary location such as a municipal building, is there a policy that dictates the delivery from point a to point B with no deviation? In the municipal building, is it stored in a fireproof and waterproof vault?
- How often is the data backed-up? Is the back-up incremental back-ups or a mirror image back-up?
- If the back-up data is stored off-site in a cloud, is that cloud CJIS Security Policy compliant and approved? Is the back-up data stored in the continental United States (CONUS)? Does the cloud service provider have redundant locations within CONUS?
As you can see from above, a simple standard that looks like this: a. data back-up (CALEA standard 82.1.6a) has many technical decisions that have to be made, and they can be highly complex.
The three other areas that the CALEA standard covers for the IT function is the storage of data (known in the industry as data at rest), access security, and password audits. As you can see from the example I provided above; you can only imagine how complex and involved the other three areas can be, especially access security. To get a little deeper into the concept and hit upon some of the more critical areas that should be covered, we will review the CJIS Security Policy. Not the entire policy, but some important areas and some areas you might not ordinarily consider.
Should I use the CJIS Security Policy as a framework or reference in developing policy?
The CJIS Security Policy, as prepared by the CJIS Information Security Officer and approved by the CJIS Advisory Policy Board, is a highly technical and in-depth manual of over 232 pages. The manual is definitely not for the layperson. This is why, earlier in the article, I suggested the development of an IT policy team to tackle this project for any department. The current edition of the CJIS Security Policy is dated June 5, 2017 and is version 5.6. Why do I mention this? Because this is a very old document in an IT field. I am not saying the FBI has been neglectful in their responsibilities. The reason why I bring this information up is to inform you that the CJIS Security Policy can and should be looked upon as a considerably complex accreditation standard. Meaning, the FBI provides departments and CJIS users with an informative booklet for both education and for a framework for compliance. Departments should use the CJIS Security Policy much like an accreditation standard. Whenever something changes in the IT function for the department, he/she should always reference the CJIS Security Policy for direction on how to proceed. For example, if the department decides to change the way they manage their public Wi-Fi and want to broadcast an SSID (Wi-Fi network name), they need to consult with the CJIS Security Policy to make sure their security is set up correctly. This is especially important if they do not run different servers for different functions. The co-mingling of programs and operations on a single server is a risk increase for the agency, but so is having multiple servers (access points) to defend. Many states such as New Jersey are lucky because they have a dedicated and extremely knowledgeable CJIS state agency coordinator (SAC) such as the New Jersey State Police, Identification and Information Technology Section, Criminal Justice Information System Control Unit, who can help them to keep in compliance. Agency should always look upon getting advice from their SAC, vendors, network administrator, and others in developing an IT policy.
Are our passwords really critical to access security?
One question I am always asked over and over again is just how vital our passwords with access security. The answer is they are critical. This is why the CJIS Security Policy outlined specifically how an agency is to comply. The FBI requires the following password attributes in order to access CJIS:
- Passwords must be a minimum length of eight (8) characters on all systems
- They must not be a dictionary word or proper name
- They must not be the same as a user ID
- They must expire within a maximum of 90 calendar days
- They must not be identical to the previous ten (10) passwords
- They must not be transmitted in the clear outside of the secure location
- They must not be displayed when entered.
Open Public Record Laws are used by citizens to gain access to government records that normally would not be able to be seen outside an organization.
In this day and age passwords are only an element of access security and they should not be the end-all. Two-factor authentication is now solidly established as an industry-standard, and departments should be transitioning to it. Many departments use a key fob as the 2nd factor of authentication. The use of private smartphones is strongly not recommended due to privacy laws and also open public records laws. The use of any private smartphone for departmental business instantly opens that smartphone privately owned by an officer to discovery and other legal challenges.
Okay, I get it, but what are some little-known but critically important areas of the CJIS Security Policy that I should know in developing IT policy for my department?
By now, you should be thoroughly convinced to not do this alone. If your department does not have the staffing ability or experience for a team, it is always possible for you to reach out to surrounding departments to create a multijurisdictional team. With that said, let’s take a look at some of the lesser-known but critically important areas of the CJIS Security Policy that you should know about.
Auditing: the standard feature for the IT field but almost never used in policing is an audit function. Larger departments do perform audit functions, and they have been commonly known as Inspectional Services. The primary responsibility of the Inspectional Services officer or unit is to take a critical review of essential functions and policies as defined by the Chief of Police or division commanders. These critical reviews are typically placed into a schedule that spreads them out over 3 to 5 years. Critical functions are reviewed more often than noncritical functions, obviously. For the IT function of the department, the critical review should look at both the department’s policy and practice as well as its current infrastructure. First of all, does the policy match the practice? Next, is the policy and practice comply with any applicable accreditation standards and CJIS Security Policy, and lastly, are all practices appropriately documented and outlined? More narrowly defined the audit function of the IT section itself. The IT section needs to have a set policy on what was to be audited (e.g., passwords, user rights, etc.), how often, by whom, and how it is to be documented. An essential feature of an audit is the involvement of someone outside the function so that the integrity of the audit is maintained.
Response Policy and Procedures: as mentioned earlier in this policy in today’s current state of affairs, ransomware, state-sponsored hackers, and intelligence agents, as well as run-of-the-mill malware, is rampant and municipalities especially police departments are increasingly becoming the primary target. Municipalities and police departments must have well-defined procedures (containment) in responding to cases of suspected unauthorized access to their computer systems and networks. The procedures need to identify what needs to be immediately done, who is to be notified (e.g., command staff, State Agency Coordinator, prosecutorial, municipal, legal, and insurance). Next, the policy needs to define the follow-up steps after the breach has been identified and contained. Lastly, departments need a Continuity of Operations Plan (COOP) that is reviewed annually and exercised, which gets them operational again as soon as possible in an uncontaminated state.
Access Security: Access security is a large area that deserves not just its own article but a book. Therefore, I will address specifically cybersecurity. Access security is one of the most important functions of IT staff. Departments need a robust system for the defense of their networks and endpoints. The best approach is using a layered defense system. Think of European castles. Attackers would have to get across an open field, through ground troops, across a mote, and up a wall to breach the fortress. Similarly, networks should be defended from a breach that unauthorized access using multiple layers and multiple tools. The use of military-grade software and agents that looks for Active Persistent Threats (APT) is critical. Software and agents that monitor endpoints and network activity is an essential last line of defense in identifying suspicious outliers that could be an attack taking place. Hackers, especially nation-states and advanced criminals (e.g., organized crime and terrorists), are known to breach a system and to lay low for weeks or months before engaging and actively moving around within the network. They do this to separate their penetration date and point with unusual activity. They hope that network administrators will be unable to connect the dots and catch them, which, unfortunately, most of the time is the case.
In closing, developing IT, policies are not easy and it should involve both subject matter experts and a team approach. The IT industry is dynamic, and ever-evolving and so should include department policy in this area. The use of reference material as a framework is critical as is the review of the policy by both subject matter and experts. The best resource for a department to use is the FBI’s CJIS Security Policy. There are many important areas for policy writers and accreditation managers to focus on such as password protection, network and access security, and auditing. If the department has funding my recommendation would be to focus on both the development of a policy where employees can be held accountable (employees, supervisors, network administrators, etc.) and was building a reliable layered defense system (cybersecurity) to prevent unauthorized access to their electronic systems.
- The Rodgers Group, LLC
- TRG Accreditation +
- Commission on Accreditation for Law Enforcement Agencies (CALEA)
- New Jersey State Association of Chiefs of Police (NJSACOP)
- FBI CJIS Security Policy Resource Center
- FBI CJIS Security Policy
- New Jersey State Police, Identification and Information Technology Section, Criminal Justice Information System Control Unit
- New Jersey Cybersecurity & Communications Integration Cell (NJCCIC)
- NJCCIC Membership: https://www.cyber.nj.gov/membership