Applied Security
Current Information Sharing Systems and Their Relationship to Each Model
Under each model, existing, operational systems are identified, and it is shown how they map to the four justice information sharing models. The intent is to draw best practices from existing systems and, from those practices, develop the guidelines presented in the next section.
Table 3-1: Operational Examples of the Justice Information Sharing Models identifies examples of each model from the many justice information systems operating in our nation. To review the existing systems, follow the links in the table below.
| Existing System | Sharing Model | |||
|---|---|---|---|---|
| Joint Task Force Model (JTF) | Centralized Information Repository Model (CIR) | Peer Group Model (PG) | Justice Interconnection Services Network Model (JISN) | |
| Federal Bureau of Investigation National Crime Information Center (FBI NCIC) |  |
|||
| Arizona COPLINK | |
|||
| Wisconsin Integrated Justice Information Sharing | |
|||
| National Law Enforcement Telecommunication System (NLETS) | |
|||
| Regional Information Sharing Systems (RISS) | |
|||
| American Association for Motor Vehicle Administrators Network (AAMVAnet) | |
|||
Operational Examples of the Centralized Information Repository (CIR) Model
FBI CJIS/NCIC Case Study
The FBI CJIS/NCIC is an example of the CIR model. The system consists of central databases housed at the CJIS complex in Clarksburg, West Virginia, and interfaces with multiple local, state, tribal, federal, and international criminal justice systems. This “system of systems” provides users with the capability to update and query the CJIS databases.
As described in the model, CJIS, the repository owner, has established security policies to safeguard the system. A security subcommittee composed of system users was established to ensure the establishment of practical security policies, which would provide adequate security for the system while controlling impact on the subscribers. These policies address security issues such as physical security requirements, personal background checks, encryption, Internet access, dial-up access, and audits. Since a system’s security is only as secure as its weakest link, CJIS conducts periodic audits of interface agencies and requires those agencies to establish an internal audit of their subscribers.
The CJIS/NCIC “system of systems” is a very good example of a CIR model as defined by the GSWG.
Introduction
The FBI CJIS Division’s automated identification and information services enable local, state, federal, tribal, and international law enforcement communities, as well as civil organizations, to efficiently access and/or exchange critical information. The CJIS Division System of Systems (SoS) provides advanced identification and ancillary criminal justice technologies used in the identification of subjects.
General policy concerning the philosophy, concept, and operational principles of the CJIS Division SoS is based upon the recommendations of the CJIS Advisory Policy Board (APB) to the Director of the FBI. In its deliberations, the APB places particular emphasis on the continued compatibility of the CJIS Division and state systems; systems security; and the rules, regulations, and procedures to maintain the integrity of the system data. The APB is composed of administrators at the policymaking level from local, state, and federal criminal justice agencies throughout the United States. The APB acts on input from its various subcommittees and working groups to change current procedures, approve changes to current applications, add new files of information, and coordinate these changes with participants. A federal working group and four regional working groups were established to recommend policy and procedures for the programs administered by the FBI CJIS Division. These working groups are also responsible for the review of operational and technical issues related to the operation of, or policy for, these programs.
The systems within the CJIS SoS have evolved over time, individually and collectively, to add new technological capabilities,
embrace legislative directives, and improve the performance and accuracy of their information services. Each of these systems
has multiple segments consisting of hardware and computer software that provide the operating systems and utilities, database
management, workflow management, transaction and/or messaging management, internal and external networking, communications load
balancing, and system security. The increasingly complex requirements of the SoS architecture demand a well-structured process
for its operations and maintenance. Future system enhancements, modifications, or technology refreshments must recognize the interdependencies
between the systems and must be structured in a way that minimizes the operational impact. Each system has been developed and
deployed in the CJIS complex located in Clarksburg, West Virginia. The SoS is in operational service
There are three principal systems in the CJIS SoS. These are the Integrated Automated Fingerprint Identification System, the National Crime Information Center 2000, and the National Instant Criminal Background Check System. The SoS also has other significant systems that provide telecommunications or other information services that support the mission of the three principal systems. Figure 3-5: Federal Bureau of Investigation CJIS System of Systems provides a top-level view of the FBI CJIS SoS, and the interrelationship of each system follows.
- The Integrated Automated Fingerprint Identification System (IAFIS)—IAFIS consists of three integrated segments: the
Identification Tasking and Networking (ITN), the Interstate Identification Index (III), and the Automated Fingerprint Identification
System (AFIS). The ITN acts as a “traffic cop” for the IAFIS, providing workflow/workload management for ten-print,
latent-print, and document processing. The ITN provides the human-machine interfaces, the internal interfaces for communications
within the IAFIS backbone communications element, the storage and retrieval of fingerprint images, the external communications
interfaces, the IAFIS Back-end Communications Element (BCE), and user fee billing. The III provides subject search, computerized
criminal history, and criminal photo storage and retrieval. The AFIS searches the FBI fingerprint repository for matches to ten-print
and latent fingerprints.
Supporting the IAFIS is the CJIS WAN, providing the communications infrastructure for the secure exchange of fingerprint information to and from external systems. The external systems are the state Control Terminal Agencies (CTA), state Identification Bureaus, Federal Service Coordinators, and the IAFIS front-end communications element. Also submitting fingerprint information to IAFIS is another CJIS system called the Card Scanning Service (CSS). The CSS acts as a conduit for agencies that are not yet submitting fingerprints electronically. The CSS makes the conversion of fingerprint information from paper format to electronic format and submits that information to IAFIS by way of the CJIS WAN. Another system providing external communications for IAFIS is the NLETS. The purpose of NLETS is to provide interstate communications to law enforcement, criminal justice, and other agencies involved in enforcement of laws. NLETS supports the legacy, binary synchronous communications protocol to state CTAs. - The National Crime Information Center 2000 (NCIC 2000)—NCIC 2002 is an online computerized index that provides law enforcement and criminal justice agencies with information about individuals, vehicles, property, and other facts that are associated with the investigation of crimes. It also includes locator-type files on missing and unidentified persons. Supporting NCIC 2000 is the Law Enforcement Interconnecting Facilities (LEIF). LEIF provides the networking access for FBI Field Offices, Resident Agencies, and Special Task Forces to the NCIC 2000 and state databases. The NCIC International Project for LEIF will also provide database access to foreign countries. NLETS, mentioned under IAFIS, is also a communications system that supports state access to NCIC 2000.
- The National Instant Criminal Background Check System (NICS)—NICS is a national system
that conducts name searches and provides criminal history records on individuals who are purchasing firearms or transferring
ownership of firearms. The system provides Federal Firearms Licensees (e.g., gun dealers) with a determination as to whether
transferring the firearm to a particular individual would violate Public Law 103-159, the Brady Handgun Violence Prevention Act.
The Brady Handgun Violence Prevention Act of 1993 (P.L. 103-159) required the U.S. Attorney General to establish a system that any licensed gun dealer may contact by telephone or by any other electronic means for information on whether receipt of a firearm would violate state or federal law. This legislation initiated the implementation of the NICS system.
Figure 3-5: Federal Bureau of Investigation CJIS System of Systems
Data Integrity
When information is submitted by a participating agency, it is stored in the CJIS SoS data bank. The submitted information
is then available in response to queries submitted by other participating agencies. The SoS does not alter the information that
is submitted; rather, it stores that information and uses it to respond to queries from participating agencies. The data must
be kept accurate and up to date. Agencies that enter records in the SoS are responsible for their accuracy, timeliness, and completeness.
To facilitate compliance with hit confirmation requirements, the originating agency must be available
The FBI, as the manager of the SoS, helps maintain the integrity of the system through the following: (1) automatic computer edits, (2) automatic purging of records, (3) quality control checks, and (4) periodic validation of all records on file.
The integrity of the data is paramount in importance because law enforcement officials throughout the nation rely on its accuracy and completeness. All security-relevant files (system administration, configuration files, audit files, transaction log, and the security log) must be protected, since a compromise of these files could result in the entire system being compromised. The integrity of the data must be adequately protected at the point of entry into the database while being transmitted to the authorized inquiring party. The system users are restricted to the minimum access needed to function effectively in their duties and to monitor their performance.
The CJIS Division systems process information subject to the provisions of the Freedom of Information Act, Privacy Act of 1974, and meet the conditions of disclosure as described in Title 5, USC, 552.A (b) (vii). Information reviews are ongoing, due to the continual use of filings and related material. The loss or abuse of SoS data could result in the unknowing release of a criminal, the wrongful incarceration of persons, the theft of property, or the loss of lives. The inability to access the SoS would prevent law enforcement officers in the field from making informed judgments and can hamper or endanger ongoing missions. Prior arrest information and indirect access to criminal history records is limited to authorized agencies, only due to the possible misuse of arrest data adversely affecting licensing and/or employment of an individual.
System integrity controls are used to protect the operating system, application executables, and configuration data in the system from accidental or malicious alteration or destruction and to provide assurance to the user that the operation of the system meets expectations and has not been altered.
Data integrity controls are used to protect data from accidental or malicious alteration or destruction and to provide assurance to the user that the information meets expectations about its quality and has not been altered. Data integrity controls include the following:
- Encryption of messages in transit
- Reconciliation routines, such as checksums, hash totals, and record counts of received messages
- Data integrity verification programs for received messages
- Message authentication for received messages
Penetration testing is performed by an independent contractor on a yearly basis. Serious vulnerabilities identified are documented through the Configuration Management process, and corrective actions are taken. The systems may be retested to ensure that the vulnerabilities have been properly addressed.
The CJIS Division SoS is published for public review in the Federal Register.
Physical Security
The FBI-controlled components of the SoS are managed through the restricted access to the FBI CJIS facility and the Division Data Center. The facility is protected by armed guards and officers, vehicle barriers, and cameras, as well as a security alarm system. The guards ensure that all drivers coming into the CJIS complex display their FBI-issued badge and vehicle pass. Passengers and pedestrians are also required to show identification badges. The employee badges must be worn at all times while on the CJIS Division facility. Any visitors coming to the CJIS Division facility must be cleared by the appropriate security personnel prior to their visit.
Security staff is posted at the main entrances of the CJIS facility,
All access to the Data Center areas are controlled by a 24-hour cipher system, and all accesses are monitored by closed-circuit video cameras. Employee identification badges are encoded, allowing or disallowing access to this area. Visitor access to the Clarksburg Data Center is controlled through escort and sign-in. All packages are searched upon entry and departure from the Data Center. Removal of equipment media from the Data Center must be approved in advance.
Physical protection of all hardware components from unauthorized removal is provided by building security measures. Equipment is not allowed to enter or exit the West Virginia facility without being authorized by the FBI security personnel at the ground floor entrance. Individuals removing equipment from the West Virginia facility must have a property removal pass authorized by the CJIS Division, Information Technology Management Section (ITMS), Operations Unit.
Fire Safety Factors
The facility’s fire sprinkler and fire alarm/monitoring systems are both fully supervised systems in that an individual
(Control Operator) is assigned to monitor the system controls
Personnel Security
All personnel who have been entrusted with the management, operation, maintenance, and use of an FBI Automated Data Processing (ADP) system processing, storing, or transmitting sensitive data require the appropriate personnel security approval. Clearance must be obtained prior to any system access. All positions are reviewed by Human Resources personnel to determine sensitivity level, and most system users are authorized access only to information that is needed to perform their specific job.
Identification and Authentication
Identification and authentication and residual information protection are performed at the operating system level, with some additional checks at the database management system (DBMS) level. All operating system-level passwords are stored in unreadable format in authentication repositories on SoS security servers, as well as cached repositories on workstations and other servers.
CJIS SoS has “security-in-depth” in its security functional mechanisms, in that audit and access controls are performed at the operating system, DBMS, and application levels.
Indirect users are identified by their Originating Agency Identifier (ORI), which is maintained in an ORI/Type of Transaction (TOT) table. Direct users require the use of robust authentication techniques, which include robust passwords or two-factor authentication techniques, such as the addition of biometrics, digital signature, or token-based access. Authentication is enabled at the operating system level. A secondary login may be required at the application and database levels.
The systems must meet government standards for the following:
- Password length
- Allowable character set
- Password-aging time frames and enforcement approach
- Number of generations of passwords disallowed for use
- Procedures for password changes
- Procedures for handling password compromise
- Frequency of password changes
- Mechanism of authentication supporting individual accountability and audit trails
- Self-protection techniques for user authentication mechanisms (i.e., passwords are stored encrypted and remote communications connections are protected with link-level encryption at a minimum)
- Invalid access attempt threshold
- Process for verifying all system-provided administrative default passwords have been changed
- Policies that provide for bypassing user authentication requirements and any compensating controls
- Digital or electronic signatures use
Access Control
Logical Access Controls
The CJIS Division SoS maintains an ORI/TOT table and determines whether the submitter is permitted to perform the requested transaction. Access control to limit what the user can read, write, modify, or delete is handled via the transactions that are defined in the Electronic Fingerprint Transmission Standard for submission, modification, deletion, and retrieval. An indirect user is restricted through ORI/TOT validation.
For direct users, user roles are defined with operating system groups, database groups, and/or application-defined groups. The SoS has the capability to use operating systems or layer security products to define asset groups (i.e., files, directories, and users and groups) in order to provide for discretionary access control. Action is planned to implement these features. The FBI CJIS Division System of Systems supports the objects reuse capability. Each communication device has been scripted to manage access paths between devices.
Public Access Controls
Transactions come from authorized end users through CJIS WAN or NLETS. The CJIS WAN is an FBI network that is managed by the CJIS Division. NLETS is a public network for law enforcement officials. Access to and use of SoS records is governed by the Privacy Act.
Data Classification and Privacy
The SoS files contain documented criminal justice information. Since this data is documented criminal justice information, it is sensitive but unclassified. State and federal laws and statutes also determine the requirement for data confidentiality. Disclosure of sensitive judicial system/law enforcement data to unauthorized persons is prohibited by law.
Change Management
The FBI has established three boards that control baseline changes to NCIC 2000, depending upon the scope of the change. All changes to commercial off-the-shelf software loaded on the system are controlled by a Technical Review Board (TRB). This board is called the Pre-Configuration Control Board (CCB) and is chaired by an Information Technology Management Section (ITMS) representative. The TRB is responsible for the change package level of the products and is the first cross-pollination of groups within the CJIS Units to review the problems or changes. The TRB approves and disapproves the changes. Each change is evaluated as to its impact on the change package cost, schedule, and technical merit.
If a change affects another change package, the change is escalated to the Engineering Review Board (ERB). The ERB is responsible for the release-or-build level of the products. The ERB approves, disapproves, defers, or escalates changes. If a change affects another product within the CJIS Division, it is submitted to the CCB. The ERB and CJIS CCB include representatives from appropriate CJIS functional groups: ITMS, Programs Support Section, Programs Development Section, Finance, Facilities, IT Security, Change Management, and Quality Assurance.
The CCB controls changes to the SoS baseline. The CCB evaluates both the technical desirability and ability of CJIS to support proposed requirement changes and the available resources to respond to change requests. This evaluation includes assessments of the impact of requirement changes and engineering changes, as well as cost, schedule, and performance trade-offs. Program change and control procedures are currently in place. All major enhancements to SoS will be approved by the APB and CCB. All changes are recorded, and an up-to-date list of hardware and software is maintained by the Configuration Management Group.
Security Auditing
Indirect User
Each control terminal agency (CTA) is audited at least every three years by the audit staff. The objective of the CTA audits will be to verify adherence to CJIS policy and regulations. An audit may be conducted on a more frequent basis, should it be necessary due to failure to meet APB policy and regulations. In addition to accuracy, completeness, and timeliness requirements, the audit will verify the ability of a CTA to protect its information against unauthorized access and ascertain that all information released is in accordance with applicable laws and regulations.
Direct Users
FBI management conducts an independent review of records and activities to test the adequacy of controls and also to detect and react to any departure from established policies, rules, and procedures. All SoS audit logs are reviewed daily by the assigned system security administrator.
Conclusion
As directed by the Office of Management and Budget (OMB) Circular A-130, Appendix III, “The Security of Federal Automated Information Resources,” the FBI implements the minimum set of security controls identified by OMB Circular A-130. Additionally, because the FBI’s IT systems are identified as “major applications” and a critical infrastructure component under Presidential Decision Directive 63 (PDD-63), they must exceed the minimum NIST standards and guidelines. The identified FBI IT systems process sensitive but unclassified information. The cornerstone of the accreditation package is the system security plan, which is developed following NIST guidance.
Implementation of security controls for the mission critical IT systems, ensuring the confidentiality, integrity, and availability
of these systems, begins in the initial system design phase of the IT project life cycle. Security controls are implemented and
monitored throughout the IT system’s life cycle by continual evaluation by a team of ADPT security specialists and include
the preparation of an IT System Certification & Accreditation (C&A) package, following NIST 800-18 “Guide for Developing
Security Plans for IT Systems” and the National Information Assurance C&A Process requirements. As stated above, implementation
of IT system security controls begins with full implementation of the requirements of OMB A-130 and all other applicable federal
regulatory polices. The implementation of IT security controls then moves to those policies included in the DOJ IT Security Policy
(DOJ Order 2640.2D) and finally to implementation of the policies contained in the FBI Security Policy. Each of these implementation
levels is layered upon the superseding policy. The cumulative implementation of these policies does in fact exceed the basic NIST
standards and guidance, but is necessary and required to ensure that the CJIS Division's IT systems are available to support the
nationwide law enforcement community on a
Operational Examples of the Peer Group (PG) Model
Arizona COPLINK
COPLINK is a data-mining tool that is used to combine case data from multiple agencies, in a defined geographic area, for the purpose of sharing information. As deployed in Arizona between Phoenix and Tucson, it provides an excellent example of a PG model.
Because criminals seldom confine their activities to municipal boundaries and most police agencies lack detailed information about criminal activities outside of their municipalities, it became clear that a system was needed to share crime reports, field interrogations, and field look-out notifications.
It is well known that the further the distance from a crime, the less likely it will be that information from other systems will be of value. If too much unrelated data is provided to investigators, they will soon become overwhelmed by data overload and valuable information will be overlooked.
COPLINK addresses these issues by establishing data collection servers in major population centers. In Arizona, Phoenix will collect data from surrounding cities and the county sheriff. Tucson will do the same for agencies in the southern portion of the state. The combined Phoenix and Tucson repositories, or nodes, will eventually contain information on approximately 60 to 70 percent of the crimes taking place in Arizona.
Inquiries run against the Phoenix node will provide valuable information and possible case leads by showing relationships between people, places, automobiles, organizations, and other associative data. Inquiries against the Tucson node will provide similar relationships by mining data from agencies hosted by the Tucson Police Department.
Trying to share information using a distributed model, with each agency retaining its own information and others using multiple peer group connections, was modeled and rejected because smaller agencies lacked the machine resources to support inquiries from large and/or multiple subscriber agencies.
A peer group connection is maintained between Phoenix and Tucson using an intranet-based VPN. The connection between host municipalities (Phoenix and Tucson) and their surrounding feeder/subscriber agencies provides examples of CIR models and confirmation that some systems consist of more than one information sharing model.
Wisconsin Integrated Justice Information Sharing
The Wisconsin Integrated Justice Information Sharing (WIJIS) program has defined a security architecture that proposes the use of centralized, shared security services to allow sheriff, police, and district attorney peer organizations in Wisconsin to securely exchange information. These services are available through an interagency law enforcement network called BadgerNet. Peer organizations, within a given county, connect to BadgerNet through a VPN connection. BadgerNet provides a statewide PKI to assign and manage encryption keys for all authorized BadgerNet subscribers. Each subscriber is assigned an X.509 certificate that holds a public key. This service allows WIJIS information systems to use strong authentication techniques to confirm the identity and access privileges of information requesters across organizational lines.
The WIJIS architecture further specifies the use of firewalls and IDSs to protect the boundaries of BadgerNet. Wisconsin uses firewalls to enforce access rules across BadgerNet boundaries, such as the interface to “partner” records management systems. Wisconsin uses firewalls in conjunction with IDSs at interfaces that have more exposure, such as their Internet portal.
Operational Examples of the Justice Interconnection Services Network (JISN) Model
National Law Enforcement Telecommunication System (NLETS)
Introduction
NLETS is a value-added network created, in its first form, in 1965 to meet the needs of law enforcement agencies for interstate communication. In 1965, the FBI had recently completed the central repository system called NCIC but had made a conscious decision not to facilitate interstate communication for the states.
The states collaborated to create NLETS so that databases held in each state could be shared for the benefit of law enforcement nationwide. This system was placed in Phoenix, Arizona, only because the Arizona Department of Public Safety (AZDPS) offered the space. NLETS was created and is owned and operated by a consortium of principal members (states, territories, and Washington, DC) that oversee a small paid staff.
Over the years, the system and network have been upgraded multiple times, increasing capacity and expanding services as customer demands increased. The NLETS network, which facilitates over 34 million transactions each month, is a “private” frame relay network, with networking services being purchased from a major network service provider. The NLETS business model fits well within the definition of a JISN model. All of the 50 states, U.S. territories, the District of Columbia, and over 20 federal agencies with a criminal justice component are connected via frame relay to each other. The hub of the system, or the “message switch,” is located in Phoenix, as is the staff that operates NLETS.
NLETS inquiries can originate from any of the over 500,000 devices located in the United States and Canada. The inquiries may be made for any number of types of data accessed via the NLETS system. The formats that are used for the inquiries are standardized by NLETS to ensure compatibility for all users.
The following sections describe Security Practices that best exemplify the methods utilized by NLETS to operate within the JISN model. Topics include data integrity; physical security; personnel security; identification, authentication, authorization, and access control; data classification and privacy; change management; and disaster recovery and business continuity.
Data Integrity
Data integrity, as it passes through the NLETS system, is very important to the officer on the street who is utilizing the information to make decisions that can result in the loss of freedom to citizens. The data must be protected as it leaves the state database where it is held until it arrives at the end user of the information. This is accomplished through security measures such as encryption, VPNs, and firewalls. NLETS utilizes VPNs within the private frame network to protect the data as it passes over NLETS. The data is encrypted at all times as it is carried via the VPN over the private network. The locations from where the data originates and terminates are secure criminal justice locations.
Physical Security
- Network, Infrastructure, and Central Facilities—The network and computing facilities maintained in NLETS space are leased from the AZDPS. These facilities are within the secure property, a walled and guarded complex providing excellent physical security for the central NLETS site. Entry to these areas is restricted to authorized NLETS staff and those escorted persons with a business need-to-access. These areas are controlled within the secured compound by computer-controlled badge access systems, physical locks, and cipher locks.
- Customer Premises—Since NLETS is a distributive system, each Control Terminal Agency (CTA) connected to the NLETS frame relay network must also be secure to ensure the overall security of the NLETS. In this model, the saying that a security system is only as strong as the weakest link is very true. Each CTA is required by policy to house its system within a physically secure location, allowing access to only those authorized persons with business needs for access.
Personnel Security
Access by authorized persons with a business need is an important component of physical security, but it is not the only criteria for access. Prior to allowing unescorted access to NLETS systems and networks, every person must successfully complete a background examination by the AZDPS for NLETS central-site employees or by the CTA at the customer site. This background check should include a name and date-of-birth check of state and federal criminal history files along with a fingerprint examination of state and federal automated fingerprint information systems. Checks that are recommended include employee reference checks along with credit checks of the employee or contractor wishing access. Unescorted access should not be allowed prior to the results of these checks being known. What constitutes a failure in these background checks is the responsibility of the controlling agency, based upon severity of the crime for which a conviction has occurred, along with the amount of time that has elapsed since the offense.
Identification, Authentication, Authorization, and Access Control
The responsibilities related to these important functions fall to each of the over 70 CTAs that provide operational access to NLETS. These CTAs represent over 35,000 criminal justice agencies in the U.S. that have NLETS connectivity. Connectivity to NLETS is currently only available via a CTA connection. Individual practitioner access to NLETS is accomplished by accessing a distributed network access point controlled by the state or federal agency that is connected to NLETS. Each state or federal agency is responsible for ensuring that all practitioners accessing their network be identified and authenticated following NLETS- and NCIC-approved methods. For years, many CTA systems utilized terminal emulation with devices that were permanently “logged in” to the system. Anyone with physical access and knowledge of how to operate the system would have access to that CTA’s information, and through that CTA, they would have access to NLETS and the NCIC systems as well.
Recent technical changes that have been occurring at varying speeds, based on resources within the CTAs, have been implementing robust identification and password systems to ensure appropriate access to the CTA and NLETS systems. Some jurisdictions have also added token devices (“something you have”) to “something about yourself.”
- Physical Connectivity to NLETS—Each request to connect to NLETS is evaluated on an individual basis by the NLETS Technical
and Operations Committee (TOC), made up of technically competent managers from the membership (CTAs) of NLETS. Potential new
customers wishing access to NLETS are required to submit a detailed network diagram and plan that demonstrates their adherence
to the following NLETS security policies:
- The NLETS router that is provided to the customer must be protected from the customer’s Internet connection and Internet traffic by a customer-provided, firewall performing-packet inspection.
- The NLETS router must be isolated from other external network connections coming into the customer site.
- Any IP address routed across the NLETS network must be
NLETS-assigned to the customer but not also routed on the Internet.
Data Classification and Privacy
All data exchanged via NLETS is considered to be for criminal justice purposes only. The data may bring with it the privacy classifications from where the data originated. Each state treats data differently. While some states may be open record states, others may have multiple layers of privacy protection on information that may be public elsewhere. Data classification being shared over a criminal justice system is generally controlled by the Code of Federal Regulations (CFR).
Change Management
All changes to the application are implemented according to NLETS standard methodology for system development. The revised specifications are reviewed by the TOC for appropriateness and impact to the CTAs. All systems are tested after changes are implemented and placed into production.
Disaster Recovery and Business Continuity
NLETS has a mirrored redundant set of hardware and network configurations located within the physically secure Meridian, Idaho, State Police compound. This site can be operational within 15 minutes should a disaster occur in the Phoenix area, taking down the central site. Testing of this facility takes place several times throughout the year, and the backup location is placed into operation for individual CTAs for varying local difficulties that occur throughout the year.
Conclusion
The need for criminal justice agencies to share information has never been more important than it is today. The day of large centralized databases holding hundreds of thousands of records no longer meets the business needs of the new millennium. NLETS is placed to meet these information sharing needs as a critical partner for criminal justice and as a JISN model that works for all who are connected.
Regional Information Sharing Systems (RISS)
Introduction
The Regional Information Sharing Systems (RISS) Program is a national program comprised of six regional intelligence centers operating in mutually exclusive geographic regions that include all 50 states, the District of Columbia, U.S. territories, Australia, Canada, and England. The six centers combined currently serve nearly 6,800 local, state, federal, and tribal law enforcement member agencies by facilitating and encouraging information sharing and communications to support their investigative and prosecution efforts. Typical targets of RISS activities are terrorism, drug trafficking, violent crime, cybercrime, gang activity, and organized criminal activities. Each of the centers, however, selects its own target crimes and the range of services provided to member agencies. Since September 11, 2001, increased emphasis has been placed on anti-terrorism activity, in addition to traditional activities.
RISS operates RISSNET™—the RISS nationwide secure criminal intelligence network for communications and information sharing by law enforcement member agencies. Using Internet technology, RISSNET is a secure private intranet that connects the six RISS centers and their participating law enforcement member agencies, as well as agency systems electronically connected as nodes. The participants may be either single computer connections from a member agency user or node connections of an agency network. Node connections to RISSNET expand the resources and information available to law enforcement users. An important service provided on RISSNET is the availability of secure e-mail among participants. Other important services on RISSNET are the RISS Investigative Leads Bulletin Board (RISSLeads), the RISS Criminal Intelligence Databases (RISSIntel), the RISS National Gang Database (RISSGang), the RISS training Web site (RISSTraining), as well as access to each center’s Web site for additional information and services, such as criminal activity bulletins and publications. RISS has developed a search capability, called RISSSearch, to assist users in locating information that is located on RISSNET. This search capability is currently implemented on all RISS-maintained resources and may be extended to help locate information on node-maintained information as well. Currently, RISS is in the process of implementing RISSLINKS, a data visualization tool. RISSLINKS will provide member agencies with the capability of retrieving data from the RISS criminal intelligence databases in the form of a link chart. The link chart will graphically show all associations of the result of the inquiry.
Firewalls, VPNs, and Other Network Safeguards
The RISS secure intranet (RISSNET) protects information through use of VPNs and multiple firewalls to prevent unauthorized access. A systematic layering of firewalls helps to compartmentalize security. This practice is employed to help contain breaches should they occur and provides an environment that allows the sharing of only necessary components to system users who exist outside a firewall. The analogy most similar to this configuration is a bank. A bank may have locks on the external doors, a more sophisticated lock on the bank’s vault, and locked safety deposit boxes within the safe. Even if a safety deposit box owner were to gain access within a bank vault, he would still only have access to the contents of his own box unless another box owner provided him access to another box.
The VPN technology that RISS employs only allows access after a user is satisfactorily authenticated. Once authentication has been successfully completed, a user is assigned a set of privileges to access resources that exist on RISSNET. The resources are unknown to the public Internet and may only be accessed using specific VPN-client software. The software maintains the resource list only in volatile memory, and a new set of privileges is sent to the user at the start of each VPN-access session. Communications between the client and the RISSNET resource are encrypted with triple Data Encryption Standard (DES) or Advanced Encryption Standard (AES). The key that is used to encrypt the communication is different for each session, as the key negotiation is based on a large key space that uses portions of the key to encrypt each session.
Authentication and Authorization
RISS currently requires a two-factor authentication to allow remote users to gain access to resources protected by firewalls on RISSNET. Authentication to RISSNET resources requires either a smart card or a software-based token along with a passcode required to enable the token. Authorization to RISSNET resources is provided by way of a list of entitlements that a user receives, which is based on a preconfigured account set up by RISS staff. The set of entitlements is sent to the user after authentication. The user’s set of authorized entitlements is maintained on a secure server on RISSNET. The list of entitlements is sent in an encrypted message to the user and is held in system memory until the client software is shut down. There are also time-out parameters, which control how a user must reauthenticate. RISS is currently evaluating allowing a user that has a trusted credential from another system to access RISS resources if the system issuing the credential has been vetted as trustworthy by RISS.
There is a feature of the RISS security systems that identifies all transmission control protocol/Internet protocol network transmissions after a user has been authenticated and received permissions to access resources. This feature is used to allow RISSNET users to access RISS database resources with no further login. The user-usage information is logged in multiple locations to ease the tracking of a user-usage pattern.
Disaster Recovery
RISS has created systems in several areas to ensure continued operation should catastrophic circumstances be experienced in areas where RISS facilities exist. RISS resources exist in a distributed environment. This makes the likelihood that all sites would be affected by a single disaster unlikely. However, there are certain critical areas where RISS has focused its efforts.
RISS performs tape backups of data and maintains them in an off-site secure location. The grandfather-father-son archive approach is used to ensure data integrity. Log files are routinely written to a CD-ROM media for potential future use. RISS has initiated a backup procedure where data is transmitted to a designated sister RISS center for storage and mounting for system access if required.
RISS has created a recovery site for its communications infrastructure to provide backup capability should a catastrophic disaster be experienced at its primary communications hub. RISS has an alternate Internet connection and the capacity to recreate the RISS secure intranet backbone via Integrated Services Digital Network backup.
RISS employs backup power sources to ensure that data is still available should electrical outages occur. All centers utilize UPS backup capability, and the central communications facility has an electrical generator for extended electrical outages.
Security Monitoring and Logging
There are a number of different services that are available on RISSNET, and each is monitored through several mechanisms. The initial logging of any user activity begins when the user attempts to access resources on RISSNET. The RISS gateway firewall records all user session information. Each subsequent firewall that a user traverses records information about what resources a user accessed. Another level of logging occurs at the application level. Detail logs are maintained regarding e-mail access, Web server access, and electronic bulletin board access. The highest-level detail logging of RISSNET resources occurs at the database access level. Information is captured regarding who is in the system and what information they are accessing. These logs are reviewed by various staff on a regular basis depending on the log to be reviewed. All logs are archived for future reference.
RISS staff reviews usage patterns of RISSNET to look for potential abuses. Traffic analyses are looked at regularly to help identify unusual usage. There are also regular reviews of the user database to help identify any unusual accounts that may exist.
Physical Security
All RISS resources are maintained in secure facilities with limited access and monitored alarm security. All visitors must
sign in when entering a RISS facility and be escorted by a RISS staff member for the duration of the time they are there. Equipment
is located in a
Intrusion Detection
RISS employs IDSs at multiple levels to help identify potential security threats on RISSNET. There is an initial IDS that scans for potential threats launched from the Internet and another set of IDS deployments that scan for potential threats that may be launched from the RISSNET frame relay cloud. RISS staff monitors the output from each IDS to determine the validity and severity of all potential security threats.
Data Classification/Privacy
The information maintained in RISS databases is contributed by participating law enforcement member agencies, and the contributing agency maintains ownership of information they contribute. Information may only be disseminated if an agency provides its approval to do so. When queries occur, notification of a hit is provided to the agency that contributed the information regarding who made the query. This allows agencies that have a common interest in an individual to contact each other, thus facilitating a more extensive exchange of information.
The data maintained in the system must meet the requirements set forth in 28 CFR Part 23, including reasonable suspicion of criminal activity. In addition, all information must relate to multijurisdictional criminal activity. Data is reviewed for compliance with this regulation by RISS staff. Additional data checks for 28 CFR Part 23 compliance are done randomly by the Office of Justice Programs, Office of General Counsel, and the Bureau of Justice Assistance. Data contributed to a RISS database by an agency may be retained in the system for a maximum five-year period. After five years, the data must be purged if there has not been a substantial update to it.
The RISS criminal intelligence databases may only be accessed by authorized member agency law enforcement personnel. Dissemination
is based on a
Critical Incident Response
RISS has a policy that centralizes responsibility of investigating all potential intrusions with a central group. Each RISS center or attached node agency connected to RISSNET has the responsibility of reporting potential intrusions to the central group. The policy has laid out procedures that make sure the correct staff is involved in an investigation of possible intrusions, define the scope of the response, determine the appropriate reporting mechanisms, and identify actions necessary to return the system to normal operations.
AAMVAnet
Introduction
The American Association for Motor Vehicle Administrators network (AAMVAnet)
The network is a private network managed by a leading network provider and is an example of the JISN model. All U.S. jurisdictions are attached to the network via a frame relay line, for the majority. They have access to a central database containing the key information (name, date of birth, social security number, and driver’s license number with issuing state) of every U.S. commercial driver. Prior to issuing a new CDL, each state must query the central site to make sure that the person is not already licensed. It is also the state’s responsibility to update the central site information, in real time, with the information of the new CDL when it is issued.
The following sections describe Security Practices that best exemplify the JISN model. Security topics include data integrity, physical security, identification, authentication, authorization, access control, data classification, privacy, change management, disaster recovery, and business continuity.
Data Integrity
Data integrity is of the utmost importance for maintaining, in real time, a distributed database of CDLs nationwide. To maintain a very high level of data integrity, AAMVA is certifying every jurisdiction’s system through a stringent set of structured tests on a test network. Once they pass the certification, jurisdictions are promoted to the production network. Every jurisdiction must also be retested after any major system change.
Physical Security
- Network Infrastructure and Central Database Facilities—The network and computing facilities
are maintained in AAMVA’s
network and system providers’ owned buildings, with controlled access areas separate from general office areas. Entry to
these areas is restricted to only those authorized personnel with current business needs for access. Each controlled access area
has a designated access custodian responsible for determining those individuals to be granted access. These areas are controlled
via
computer-controlled, badge-access systems, physical locks, cipher locks, or other locking mechanisms. The access custodian is also responsible for:- Reviewing and approving access requests based on valid business requirements.
- Maintaining a visitor log of nonroutine accesses.
- Reviewing the approved access list on a periodic basis, at least every quarter, to remove persons who no longer need access. This does not preclude the requirement to immediately remove access for those whose need has expired (i.e., termination or transfer).
- Customer Premises Equipment—The network-provided, customer-premises equipment can be accessed either physically or
remotely through a dial-up connection for maintenance and troubleshooting by authorized AAMVA network provider personnel. Physical
access into the customer facilities housing the AAMVA network provider equipment is governed by customer policy and procedures.
Access to the equipment is controlled at the most basic layer via password. Only authorized AAMVA network provider personnel
have access to the passwords, which are required to be changed at regular intervals. Access via a dial-up connection to customer
premises equipment is accessible only from specific network management hosts and only by authorized support personnel.
Network support personnel access to these management hosts is controlled and revalidated on a regular basis, ensuring that only personnel managing the customer networks have access to these management hosts. In addition, access to the customer routers from the network management host is controlled by an authenticating server, which validates and verifies user accesses. “Telnet” and “SNMP” traffic to the customer router is allowed, but only from the Network Management server hosts.
Identification, Authentication, Authorization, and Access Control
- Systems Network Architecture (SNA) Services and Hosts—All access to SNA services and hosts is controlled by a network
application known as the Service Manager, which:
- Provides the initial connection point into the network for users, devices, and applications.
- Identifies and authenticates the user, device, or application.
- Validates the user, device, or application request for a session, based upon the authorizations profiled in the user, device, or application profile.
- Passes the session request to the destination network, application, or service.
When an application or device requests a session through the network, the Service Manager first validates that the requesting application/device is authorized to access the network and is of the type described in its Service Manager resource profile. Then, the Service Manager checks the application profiles of both the origination and destination applications to ensure that the applications have been authorized to communicate with each other. Finally, the Service Manager will pass the session request to the destination application’s network. - Internet Protocol (IP) Services and Hosts—Access to IP services and hosts is controlled at the network layer via permanent virtual circuits (PVC). There must be a PVC definition between sites before they can have the potential to communicate, with each site providing written authorization for the creation of the PVC. Once the PVC is in place, further access is controlled through the use of access lists and router filters, which reside on each customer premises router and the AAMVAnet intermediate network routers. The general rule for access to IP host and services across AAMVAnet is that access is denied unless explicitly authorized.
- AAMVA Applications—In addition to the general identification, authorization, authentication, and access controls described
above, there are additional levels of each within the AAMVA application message switch application, Network Control Software
(NCS). Each entity communicates only with the NCS, and since there is no direct trading partner to trading partner communication,
the NCS performs all trading partner identification, authorization, and authentication. Each site is known to the NCS by a site
identifier, which is then hard-coded within the NCS to the site’s SNA virtual telecommunication access-method application
logical unit or their IP address and port. The combination of site identifier and logical network information create the unique
identifier for a site.
AAMVA has complete and sole control over allocating site identifiers and authorizing sites to be added to the NCS, as well as authorizing the necessary Service Manager application profile changes required to enable the communication at the higher level. - Physical Connectivity to the VAN—Each request to connect to the VAN is evaluated on an individual basis by several
groups of highly qualified VAN network personnel, including network designers, security teams, and network technical support
personnel. Potential customers are required to submit a detailed network diagram that demonstrates their adherence to the following
VAN security policies.
- The VAN-provided customer premises equipment must be protected from the customer’s Internet connection and Internet traffic by a customer-provided firewall performing stateful packet inspection.
- The VAN-provided customer premises equipment must be isolated from other external network connections coming into the customer site.
- Any IP addresses routed across the VAN must be American Registry of Internet Numbers (ARIN)–registered to the customer and not also routed on the Internet.
- Intrusion Detection Systems—The VAN employs a combination of both host- and network-based tools to perform intrusion
detection to determine whether any initiatives to penetrate network components have been attempted by nonauthorized personnel.
The tools used are leading-edge scan tools from a widely recognized commercial software provider. Maintaining this information
as confidential is, in itself, a facet of the VAN’s security program that protects all customers. In addition to intrusion
detection tools, the VAN employs “ethical hackers,” who probe the VAN in an attempt to uncover weaknesses in security
systems and processes.
Upon occurrence of a security incident, the VAN identifies the level of the potential impact and notifies AAMVA. If specific customers are determined to be at risk, they will be notified. - Security Auditing—The VAN regularly conducts security status checks to ensure that security controls are maintained in place and are functioning in accordance with plan. These initiatives include health checking and vulnerability scanning. Results from these activities are reviewed by each region for closure and for any required follow-up actions.
- Health Checking—Health checking is performed on a regular basis, involving the review and verification of system security
settings, operating system resource security settings and status, and users having security administrative authority or system
authority.
Health checking also includes the verification of network elements to ensure the proper level of security “fixes” are maintained, to ensure only those system processes required are active, to ensure the existence and retention of activity logs, and to verify support personnel accesses.
The local service providers and security personnel perform security status checking on an ongoing basis. During security reviews, the review team, as part of the review process, conducts status checking. - Vulnerability Scanning—Vulnerability scanning is performed by authorized personnel to verify whether controls can be
bypassed to obtain security administrative authority or system authority/access.
Vulnerability scans to test the level of safeguards on network components are performed on a varying frequency based on the risk of compromise, utilizing authorized and leading-edge scanning tools. Vulnerability scans are performed quarterly.
Data Classification and Privacy
All data exchanged within the CDL application is classified and protected under the Commercial Vehicle Safety Act and the Driver Privacy Protection Act (DPPA). These two Acts specify who can access the data and under which conditions. In addition, most states have passed additional legislation to complement or reinforce the DPPA regulation. Therefore, individual jurisdictions have developed their own set of procedures to classify and protect drivers’ data privacy.
Change Management
All changes to the application are implemented according to AAMVA standard methodology for system development. The revised specifications are reviewed and approved by ad hoc working groups composed of state and U.S. Department of Transportation representatives.
All systems (state and central site) are retested and certified after the changes have been implemented. The new programs are then promoted to the production environment after all the certifications have been passed.
Disaster Recovery and Business Continuity
Central-site disaster recovery drills are performed on a yearly basis at a different geographical location than the primary system’s location.
A backup facility for the message switch is also hosted at a different geographical location than the primary facility and can be activated in less than 15 minutes. Testing of the backup facility is completed twice a year.