The Peer Group (PG) Model
Introduction
The Peer Group (PG) model represents a broad category of justice information sharing in which two or more independent organizations work together to provide each other information access and use. The sharing organizations can be similar in function, such as the sheriffs’ offices in adjacent jurisdictions, or quite different, such as a local police department and the state office of taxation. The PG model is becoming more prevalent in integrated justice systems. It is one of the most challenging models in terms of information security issues because there is often no single authority for setting policies and procedures. Instead, information security is a cooperative effort. Participating organizations must be convinced that the information they share will be adequately protected once it leaves the boundaries of their computing and network systems. Further, organizations must be confident that opening up their information systems for others to access will not compromise their own information confidentiality, integrity, and availability. In some cases, one or more of the peers will have connections to other external information systems. If security is not properly addressed, connections may be inadvertently created between these external systems and other unknowing members of the peer group. In these situations, a peer group member may find himself having to trust organizations that one of his peers trusts.
Figure 3-6: The Peer Group Model
The PG model is represented in Figure 3-6: The Peer Group Model. The organizations represented in this figure—police, courts, and corrections—have been selected for illustration purposes. These are the organizations typically involved in a horizontally integrated criminal justice program—one that follows the justice workflow from arrest to trial to incarceration. In general, the PG model can include a large number and variety of peers participating in information sharing and exchange.
The flow of information within the Peer Group Model involves:
Query to/from a peer organization—A person or a computer program in one organization may request information from another organization on a query basis. For example, a sheriff may want to query court case dispositions prior to serving a warrant to determine the risk of approaching the subject of the warrant. The corrections personnel may want the scheduling software to query the court calendar to produce a report on the prisoners that must be prepared for an appearance. An important security concern in this information flow is mutual identification and authentication to verify the identities and subsequent access privileges of both the information requestor and provider.
Update to/from a peer organization—More complex information sharing tasks may require that updates be performed between peer organizations. For example, information from police arrest documents may electronically follow an arrestee to the corrections facility. This requires the police system to initiate an update to the jail system. This information flow has stronger security requirements than the query since one of the peer organizations will change its production database as a result. Identification and authentication is important, as is data integrity, to ensure that only authorized parties make changes and that information is not inappropriately modified.
Notifications—Notifications are typically exchanged between peers
to facilitate workflow. For example, a police officer may want to receive
a notification when a “client” has been released on parole. This
may require the corrections or court system to generate a message to a user
of the police system. One common mechanism used to transmit notifications
is
The peer organizations that share information must agree on joint security policies and practices to protect this flow of information and convince each other that the risk of opening up their systems to outside use is manageable. As the number of organizations that share data increases, the number of interfaces between systems and the security complexity increases.
Security Guidelines for the Peer Group (PG) Model
In the PG model, there may be many peer group relationships. The peers must establish electronic trust among the organizations sharing information. For simplicity, we will focus our discussion on two peers. Figure 3-7: Security Practices to Support a Query and Update in the Peer Group Model and 3-8: Security Practices to Support Notifications in the Peer Group Model overview the security practices and mechanisms applicable to an information interchange between two justice organizations communicating as peers.
In Figure 3-7, agency Bob—an information consumer—is querying the database owned by agency Alice—an information provider. The agencies are using a VPN to communicate. This allows the two agencies to use the connectivity options provided by public networks (e.g., the Internet) but still secure their information exchanges. Agency Alice considers her shared data to be extremely sensitive and takes some additional steps in order to secure its production database. She does not provide direct query access to the destination agency. Instead, she publishes the subset of information that she wishes to share to an extract database located in the firewall DMZ (see Section 2-7, Firewalls, VPNs, and Other Network Safeguards). The rule table in the firewall will prevent outside access to the production database. Further, the rule table will limit extract database access to subscribers with network addresses from agency Bob. Agency Alice is also running an IDS that monitors its connection to the public network for attack patterns. In addition to examining network message content, the IDS monitors the extract database server to alarm potential integrity compromises in the shared data. Finally, Alice’s system administration staff periodically runs audits on passwords to ensure that the users registered to access the shared information are employing strong passwords.
Figure 3-7 also illustrates a host-to-host connection established through the VPN to support an update to the production database. Agency Alice decided that rather than try to establish identities for outside authorized users on its production database, it would only trust one update-enabled user: agency Bob’s server. This level of electronic trust implies that Alice also trusts the security practices that Bob has implemented to protect his server, including disciplines such as authentication, authorization, and physical security. The firewall and VPN software enforce the policy that only Bob’s authenticated server can get the access required to update Alice’s production database.
In Figure 3-8, Alice and Bob have chosen secure e-mail as the mechanism to send notification among users and justice applications. By secure, they mean that messages are encrypted so that unauthorized individuals cannot read the contents and digitally signed so that the receiver is certain that the sender is genuine. In the example portrayed in Figure 3-8, encrypted e-mail is especially important because the notification may transit a wireless network en route to a user in a patrol vehicle. Wireless networks, whether they are based on cellular protocols such as cellular digital packet data or local area network protocols such as WiFi (IEEE 802.11), are notorious for security vulnerabilities. By using secure e-mail, agencies Alice and Bob have implemented an “end-to-end” encryption strategy and do not have to worry about the integrity of the network hops that the message may transit. In order to support encryption and digital signature, Alice and Bob users must participate in a common PKI (see Section 2-3).
Figure 3-7: Security Practices to Support a Query and Update in the Peer Group Model
Figure 3-8: Security Practices to Support Notifications in
the Peer Group Model
Peer Group Security Disciplines
The remainder of this section provides guidelines under each of the security disciplines.
Personnel Security
The key to peer-to-peer information sharing security lies not only in the technical aspects of securing critical data and systems. It is also critical that the persons accessing the data have been proven, via a standardized and accepted method among all peers, to be suitable and trustworthy to receive and utilize the data in a manner consistent with the provider’s policies and procedures.
Peer-to-peer sharing in the law enforcement specific community is generally straightforward. Each law enforcement agency follows a fairly standard background check methodology to ensure that those persons hired meet a minimum set of qualifications allowing them access to information, property, firearms, etc. These background checks generally include full name and date-of-birth inquiries into national and state systems, along with fingerprint-based checks looking for criminal history records that the applicant might not disclose on an employment application. While these checks are generally not adequate for military clearances, they are generally sufficient for most personnel-related information sharing in the justice community.
Other justice partners may conduct very limited reference checks prior to employment. The local or municipal courts may not conduct any background check process prior to allowing the employee access to court databases. In many cases, the information contained at that level is public, and access need not be strictly controlled. The issue is complicated as gateways to information sharing are created. The data being accessed at a peer’s location may be at a higher level, requiring differing rules for access and use. A law enforcement agency may allow the municipal courts access to their database, but they would want to be sure that access is strictly limited to that data that they would allow the public to see, unless it was understood that personnel screening has been sufficient to comfortably allow unfettered information sharing. The key is communication between the peers, setting appropriate parameters that are spelled out for both information sharing partners to meet.
In many cases the law enforcement entity in a peer-to-peer relationship is called upon to conduct some of the personnel screening efforts. Many times the criminal history check, both name and fingerprint, is forwarded to the law enforcement partner for completion via their interface with state and national systems. However the peer-to-peer personnel screening issues are handled, communication (along with procedure reconciliation efforts between all peers desiring to share information) is crucial to the success of this aspect of the model. One peer mandating procedures to another peer seldom results in success.
Firewalls, VPNs, and Other Network Safeguards
As multiple organizations are involved, planning becomes paramount in coordinating network security. Each organization involved in the peer model may have different firewalls in place or no firewall in place. An effort should be made to identify capabilities of all participating systems and define the necessary requirements to allow the exchange of information between systems. If possible, DMZs should be created to allow areas where information can be exchanged without exposing other secure systems on an agency’s internal network that will still be protected by a firewall. The scope of the opening of information sharing channels using a firewall should be limited to the specific information exchange requirements. A set of policies laid out in a memorandum of understanding should be defined early in the development of the PG model to address system responsibilities and procedures for addressing potential vulnerabilities or breaches. VPN technology may be employed, depending on the sensitivity of the data. However, VPN-client access should be limited to the specific resources that are needed by the user to perform their authorized duties. Client-based VPNs should have realistic time-out parameters to close network sessions that are not in use.
Critical Incident Response
Implementation of the Computer Security Incident Response Capability (CSIRC) in this environment is a greater challenge than in the CIR model and requires additional planning and cooperation between agencies as well as additional coordination of efforts. The success of the response will depend largely upon the ability of two or more CSIRCs in different locations being able to coordinate their communications, command, and control across a physical distance. It is critical that the peers agree upon a standard set of response rules that will be implemented in all participating peer agencies.
Regular review and coordination of the plans and capability will be necessary to ensure that attacks against the peer entity can be detected, reported, and investigated. This is especially true when the attack involves probes against different points within the peer-to-peer structure. In this case, a single peer may only see part of the overall attack, and there is a risk that the attack may go undetected. To prevent this, peer-to-peer information sharing networks need to establish clear lines of communications to an agreed-upon reporting and coordination point, where security incident information can be collated, processed, and distributed back to the CSIRC at the various peer locations.
Physical Security
The PG model is illustrated by the sharing of justice information between two or more independent organizations. Because there is not a central authority to promulgate policies and procedures for physical security, it is necessary that each independent organization adopt physical security practices to protect computing and network systems of all organizations using the network.
From a physical security prospective, a major threat is unauthorized physical access to the shared network by someone seeking to gain information from one or more of the participating organizations. Each participating organization should also implement policies to secure information in electronic and printed form. Organizations using the PG model should designate someone from their organization to meet periodically with members from other organizations to discuss security measures and concerns that may impact all users of the PG model.
Identification and Authentication
Because of the complexity of cross-organizational user management, the participating peer group organizations may choose a simple password authentication mechanism. For example, the participating agencies may agree upon the following practices and precautions to promote strong I&A:
- Monitoring software is regularly run on the database extract server to check the strength of passwords. Users with simple passwords are required to change them at their next logon.
- Users are required to change their passwords at regular intervals.
- Users join and leave each organization regularly. This requires the security administrators to add and delete new users from external organizations. For example, when a new user joins agency Bob, the agency Alice administrator may need to give that user access to the extract database. There are several approaches to accomplishing this task. If the agencies are large and there is a large turnover in staff, Alice and Bob may consider an enterprise management security approach that automates external user administration. In the example provided, Alice and Bob administrators can take a simpler approach and use secure e-mail to communicate the need to add a new external user to any of their systems.
Based on budget constraints and the sensitivity of the shared information, the participating agencies may choose to take the next step in terms of I&A rigor: one-time password hardware tokens (see Section 2-1).
Authorization and Access Control
To simplify user privilege administration, the peer organizations can use role-based access control (RBAC). A simplified RBAC privileges list—specifying four roles—might look something like Table 3-2: Sample Roles and Privileges. As indicated in the previous example, agency Alice administrators are required to register and maintain external users on an “extract database” server (not her production database). When agency Bob adds a new user in the “sworn officer” role, a registration request is automatically forwarded to the agency Alice system administrator. Alice’s administrator will add the new user into the sworn officer role on the extract database server. Using this procedure, each agency’s administrators maintain control over the systems they own.
Table 3-2: Sample Roles and Privileges
| Role | Privileges | Object |
|---|---|---|
| Sworn Officer (agency Bob user) | Query only | Alice’s extract database |
| Bob’s Server | Query and update | Alice’s extract database |
| Court Clerk (agency Alice user) | Query and update | Alice’s extract database |
| System Administrator | All, including privilege allocation and revocation | Alice’s extract database |
Data Classification
The PG model should have a security policy that creates consistent definitions that all peers agree upon for each confidentiality, integrity, and/or availability level. For example, all open criminal investigation data might be labeled confidential, high-integrity, and high-availability. The policy should also include procedures for handling each of the different levels of sensitive or critical information. For example, confidential information might require encryption during storage and data transfer. Information collected must be labeled as it comes in to indicate the applicable levels.
When peers request information, an authorization check should be performed to verify the peer meets requirements for access to the information as indicated by the classification levels.
Public Access, Privacy, and Confidentiality
The PG model should have a security policy that includes procedures for handling information subject to privacy laws. Information collected should be labeled as it is transmitted to indicate its privacy requirements, such as obtaining the subject’s consent before disclosure outside the justice system. An authorization check should be performed to verify the recipient meets requirements for use and dissemination of the information.
Intrusion Detection
PG models often involve connectivity between one or more “trusted networks” and provide full or limited access to internal network resources within firewall boundaries. The level of risk provided by these network connections can be greatly reduced by firewall rule-sets that tightly limit what internal resources are available to approve outside users.
The old saying, “A chain is only as strong as its weakest link,” still applies, regardless of how well firewall rule-sets are established. If a network with inadequate security is allowed to attach to a network with adequate security, the result will be two networks with inadequate security.
Networks with inadequate security can host attacks using spoofed credentials of individuals authorized to update and/or query sensitive data on peer networks. Peer group connections increase vulnerability in all situations where security is not centrally managed and evenly applied. Even when security is centrally managed, the increased traffic volume that can come from peer connections can increase risk.
The decision to deploy an IDS must balance perceived vulnerabilities against the cost of implementing and properly using the system. When accessing vulnerabilities, the user must consider the risks and security profiles of all networks requesting peer group connectivity. The decision should also consider that the security profiles of connecting systems are subject to being changed without notice.
Disaster Recovery and Business Continuity
The PG model must have a disaster recovery and business continuity plan. This becomes vitally important as the dependence upon the information from other organizations grows. The plan may include having spare equipment in stock or signing agreements between organizations for hot- or warm-site support in the event of a disaster. The plan may also include alternate methods for transferring the information to subscribers, such as secure e-mail, couriers, registered mail, and phone support, depending on the time requirements.