Connecticut State Criminal Justice Information System

FAQs

  • What is GFIPM?
    Answer:

    GFIPM stands for “Global Federated Identity and Privilege Management” and is a federal standard published and used within the US Department of Justice and by its federal and state partner agencies. The use of GFIPM is a requirement of the CISS RFP.

    GFIPM federated identity is centered on the exchange of security tokens between trusted identity providers. A service provider (in this case CISS) trusts an Identity Provider to provide security information about a user. This security information is included in a security token with every request made by the user of the service. The security token contains security ‘claims’ about the user. A claim is a ‘statement of truth,’ or a ‘fact,’ about the user that the Identity Provider “claims” to be true. For example, an Identity Provider might claim that a person’s last name is "Smith" and that their first name is "Joe." Since the service being accessed by the user trusts the Identity Provider that is providing the security token, it can make access control decisions based on these facts (claims) provided about the user.

    GFIPM provides a dictionary of claims, referred to as the "GFIPM Metadata." Similar to the NIEM standardization of a criminal justice terminology dictionary, GFIPM provides a dictionary of security related terms (claims) that can pertain to a user. By having a standard dictionary/vocabulary, partnering organizations (a Federation) can have a common language for describing information about users, also known as the users’ "Federated Identity."

    The "Privilege Management" portion of GFIPM is the ability of a service provider to make access control decision- based on the security claims that were provided for that user. A security token might contain a claim asserting that the user is a sworn law enforcement officer, and CISS can restrict access to specific functionality or data by checking to see if the security token contains the Sworn Law Enforcement Officer Indicator with a value of true. Similarly, if CISS is requested to return criminal history data to a user, it will check to see if the user has a claim that states they have ‘View Criminal History Data privileges’ before providing that data to the user.

    A key advantage of using GFIPM’s standard for security within CISS, is that Connecticut will be able to link to and share information with other local, state, and federal CJI jurisdictions without changing anything in CISS or in any local business processes. Through memoranda of understanding (MOUs), the CISS Identity Provider could be trusted by Federations such as the CJIS Federation, and CISS users would have access to CJIS tools such as the N-DEx portal. This is because both N-DEx and CISS are making access decisions based on a standard language that defines security claims (GFIPM).

  • What is the difference between Claim-Based and Role-Based Authorization?
    Answer: Role-based security has been the norm for securing information from unauthorized users for a long time and works well when controls are based on job (and therefore system process) specifications; someone needs access only to the record types and data elements needed to perform their job.

    Role-based security maps jobs to system processes based on business processes and a user’s related responsibilities. Roles are created to mirror the business process and are not easily transferred to another system. The problem with role-based security is evidenced when two or more organizations try to share information. Since there isn’t a standard vocabulary definition for roles, we can’t securely make access decisions based on a person’s role. For example, an ‘analyst’ role in my organization may have different privileges in my organization than an analyst in your organization.

    Between multiple agencies with separate systems, roles are often broadly defined and lack common definition (e.g., analyst), making a security solution problematic, if such a solution is to be applied to users from multiple agencies, multiple states, and federal agencies.

    This is where claims-based security comes in because “claims” are more fine-grained than “roles,” allowing multiple organizations to agree on the meaning of a claim. GFIPM defines a common vocabulary of claims for the criminal justice and law enforcement communities. A claim is a stated fact about a user. Instead of defining a person as an ‘analyst,” you would claim that the person has the privilege to search criminal history and/or criminal intelligence data. You would claim that a person has a specific clearance level, a specific certification, or a specific privilege.

    Claims are fine-grained enough that different organizations know exactly what a claim means. If we can understand each other’s security information, then we can trust each other’s users through claims-based security. CISS is required to provide federated security, since users from all of the agencies from across the State will be using the system. Given that it is impractical, and insecure, to manage all users centrally, a federated security model was required. This is where agencies maintain their own user accounts, as well as maintain the access privileges (security claims) for their own users. Using GFIPM allows the CISS to have a common vocabulary of security claims for all users across all agencies. A useful overview of claims-based security can be found at http://msdn.microsoft.com/en-us/library/ee536164
    Background information can be found at http://www.it.ojp.gov/default.aspx?area=nationalInitiatives&page=1179 and on the GFIPM.NET site at http://www.gfipm.net.
  • I have highly sensitive information that will be included in CISS. Who will be allowed to view this information in CISS?
    Answer: The simple answer is that CISS will implement the same security restrictions that are now used for any documents — paper or electronic. Documents included in the Information Exchanges (IEs) will be assigned claims based on the policies or legislative constraints of the agency that owns that information. Only those individual with claims that match the level set by the agency will be allowed to view documents/information.

    The first building block of the CISS system is the user sign-on and authentication process. The system will be programmed to authenticate users when they log-in, and once logged in, will only allow users to access information for which they are properly credentialed. The system will also audit all use of the system, creating a virtual trail of breadcrumbs for all actions. The key concept in all of this is a token.

    A token is an object within which are claims, telling the system about the credentials of the person logging in. These “claims” are based on one’s credentials (i.e, sworn law-enforcement officer – regardless of actual role or work location) and organizational affiliation. The claims are individualized, so the system will give specific access rights to someone, for instance, who works in the court system, but also has specific police credentials.
  • Who will control the security credentials for a set of information?
    Answer: The simple answer: The owner of the information will control access to any and all information or documents within CISS. Again, the restriction to information/documents will be set by the owning agency and are required to be identified by agency policy or legislation. This control is typically set by the agency’s business staff.

    The owner of the information will provide the governance for access to any of their information or documents accessible through CISS. Again, as noted, the restriction to information/documents will be set by the owning agency and are required to be identified by agency policy or legislation. This control is typically set by the agency’s business staff.
  • Isn’t there the potential for data owners to lose control of the data, with multiple administrators and access points? How will CISS ensure that only the users authorized to view and use the information will have access?
    Answer: There is only one entry point into CISS for searching, which is via the Search Portal within an agency’s SharePoint application. Access to the Search Portal will be restricted by authentication of the user, which is audited and logged. The Search Portal allows users to select a simple or structured search and allows them to refine their search results as necessary. The only other method of entry into or out of CISS is via IEs and these are restricted, contain only data/documents and are limited to system-to-system interaction. There are no other methods of entry into CISS or the data contained within.

    In terms of general security standards, CISS will employ FIPS 140-2 (Federal Information Processing Standard) the computer security and encryption standards used by the CIA and FBI.

    Although there is security, defined by the data owner and executed with the CISS environment, there is always potential for abuse; for instance, a user giving information to unauthorized users. CISS will audit and log every transaction to ensure any abuse will be detected and appropriate action taken. The claims defined for the information/documents will support restricting users from viewing information only at their level.