To implement the provisions of Section 282.0051(2), F.S., to establish information technology architecture standards to provide for the most efficient use of the state’s information technology resources and to ensure compatibility and alignment with ...

 

AGENCY FOR STATE TECHNOLOGY

RULE NO.: RULE TITLE:

74-5.001 Purpose and Applicability; Definitions

74-5.003 Identity Management

PURPOSE AND EFFECT: To implement the provisions of Section 282.0051(2), F.S., to establish information technology architecture standards to provide for the most efficient use of the state’s information technology resources and to ensure compatibility and alignment with the needs of state agencies.

SUMMARY: The proposed rulemaking adopts new rules related to information technology identity, authentication, and interoperability of information technology resources.

SUMMARY OF STATEMENT OF ESTIMATED REGULATORY COSTS AND LEGISLATIVE RATIFICATION:

The Agency has determined that this will not have an adverse impact on small business or likely increase directly or indirectly regulatory costs in excess of $200,000 in the aggregate within one year after the implementation of the rule. A SERC has not been prepared by the Agency.

The Agency has determined that the proposed rule is not expected to require legislative ratification based on the statement of estimated regulatory costs or if no SERC is required, the information expressly relied upon and described herein: the economic review conducted by the Agency.

Any person who wishes to provide information regarding a statement of estimated regulatory costs, or provide a proposal for a lower cost regulatory alternative must do so in writing within 21 days of this notice.

RULEMAKING AUTHORITY: 282.0051(19) FS.

LAW IMPLEMENTED: 282.0051(2) FS.

A HEARING WILL BE HELD AT THE DATE, TIME AND PLACE SHOWN BELOW:

DATE AND TIME: April 28, 2017, 3:00 p.m.

PLACE: 4050 Esplanade Way, Room 101, Tallahassee, Florida 32399

Pursuant to the provisions of the Americans with Disabilities Act, any person requiring special accommodations to participate in this workshop/meeting is asked to advise the agency at least 3 days before the workshop/meeting by contacting: Scott Jecko at [phone] or at [e-mail]. If you are hearing or speech impaired, please contact the agency using the Florida Relay Service, 1(800)955-8771 (TDD) or 1(800)955-8770 (Voice).

THE PERSON TO BE CONTACTED REGARDING THE PROPOSED RULE IS: Scott Jecko at [phone] or at [e-mail].

 

THE FULL TEXT OF THE PROPOSED RULE IS:

74-5.001 Purpose and Applicability; Definitions.

(1) Purpose. The purpose of the Identity Management rule is to ensure that Identity Management Services provide secure, reliable and interoperable mechanisms for authenticating the identity of devices, application services, and Users that consume state information and application resources.

(2) Applicability. This rule chapter applies to State Agencies.

(3) Definitions.

(a) The following terms are defined:

1. Agent – a non-human application or service acting in the digital environment on behalf of a human user.

2. Applicant – a party undergoing the processes of registration and identity proofing.

3. Assertion – a statement from an attribute provider to a relying party. Assertions may be used to communicate claims, attributes, identifiers, or digital identities.

4. AST – the Agency for State Technology.

5. Attribute – a named quality or characteristic that is claimed to be inherent in or ascribed to someone or something.

6. Authentication – a process of determining the validity of one or more credentials used to claim a digital identity.

7. Authentication Boundary – defines the scope of identities managed within a specific Identity Management service.

8. Authentication Protocol – a defined sequence of messages between a Claimant and the RP or CSP that demonstrates that the Claimant has control of a valid token to establish his or her identity.

9. Bona Fides – evidence that provides insight into an organization’s maturity, legitimacy, stability, and reputation.

10. Boundary – a physical or logical perimeter of an information system.

11. Cabinet Agency(ies) – the Department of Legal Affairs, the Department of Agriculture and Consumer Services, and the Department of Financial Services.

12. Claim – a statement about the user or agent asserting a property of the user or agent without necessarily containing identity information.

13. Claimant – a party whose identity is to be verified using an authentication protocol.

14. Compensating Control – a management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system.

15. Credential - a set of data presented as evidence of a claimed digital identity.

16. Credential Service Provider (CSP) – a trusted entity that issues or registers subscriber tokens and issues electronic credentials to subscribers.

17. Credentialing – a process to bind an established digital identity with a credential.

18. Cryptography or Cryptographic – the practice and study of techniques for secure communication in the presence of third party adversaries.

19. Digital Identity – an attribute set that can be uniquely distinguished in a given context and can be used for a digital interaction.

20. Entity – any organization providing or using identity services.

21. Federation – an association comprising any number of credential service providers and identity providers.

22.Identity Assurance Level – the degree of confidence that an individual, organization, or device is who or what it claims to be.

23. Identity Management (IDM) Service – a registration, credentialing, authentication, identity proofing, or attribute management service that may be utilized by more than one relying party or system.

24. Identity Proofing – the process by which a CSP and a Registration Authority collect and verify information about a person for the purpose of issuing credentials to that person.

25. Identity Provider – an entity that creates, maintains, and manages trusted identity information.

26. Interoperability – the ability of independent systems to exchange meaningful information and initiate actions from each other, in order to operate together for mutual benefit. In particular, it envisages the ability for loosely-coupled independent systems to be able to collaborate and communicate.

27. Multifactor Authentication – authentication using two or more different factors. Factors include something one knows (e.g., password or personal identification number), something one has (e.g., cryptographic identification device, token), or something one is (e.g., physical location, biometric).

28. Open Standard – standards made available to the general public and are developed (or approved) and maintained via a collaborative and consensus driven process. Open Standards facilitate interoperability and data exchange among different products or services and are intended for widespread adoption.

29. Organization – an entity of any size, complexity, or positioning within an organizational structure.

30. Personal Information – see Sections 501.171(1)(g)1. and 817.568, F.S.

31. Registration – a process that establishes a digital identity for the purpose of issuing or associating a credential.

32. Registration Authority (RA) – a trusted entity that establishes and vouches for the identity or attributes of a subscriber to a CSP.

33. Relying Party (RP) – an agent or user that relies on an identity assertion or claim.

34. Security Control – the management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.

35. Standard – a published statement on a topic specifying characteristics, usually measurable, that must be satisfied or achieved in order to comply with the Standard.

36. State Agency(ies) ‒ any official, officer, commission, board, authority, council, committee, or department of the executive branch of state government; the Justice Administrative Commission; and the Public Service Commission. The term does not include university boards of trustees or state universities, the Department of Legal Affairs, the Department of Agriculture and Consumer Services, or the Department of Financial Services as defined in Section 282.0041(23), F.S. (See Cabinet Agency(ies)).

37. Subscriber – a party who has received a credential or token from a CSP.

38. Token – something that the claimant possesses and controls that is used to authenticate the claimant’s digital identity.

39. Token Assurance Level – the degree of confidence that an individual, organization, or device has maintained control over what has been entrusted to him or her (e.g., token, identifier) and that the token has not been compromised (e.g., tampered with, corrupted, modified).

40. Token Control – the process of ensuring, through the use of a secure authentication protocol, that the token has remained in control of and is being presented by the identity that the token was issued to and has not been modified.

41. Transaction – a specialized interaction that involves an exchange of some kind.

42. Trust Criteria – set of benchmarks used to measure identity providers and token provider technical and operational controls with respect to registration and issuance, tokens, token and credential management, the authentication process, and assertions.

43. Trust Relationship – arrangements that ensure confidence. The overall approach of governing these trust relationships are referred to as federation.

44. User – an individual human being (see Agent).

45. Verifier – an entity that verifies the claimant’s identity by verifying the claimant’s possession and control of a token using an authentication protocol.

Rulemaking Authority 282.0051(19) FS. Law Implemented 282.0051(2) FS. History-New          .

 

74-5.003 Identity Management.

(1) Assessment. Each State Agency shall:

(a) Identify all current State Agency owned or managed Identity Management (IDM) services that authenticate access to state managed data and application resources.

(b) Based on an assessment schedule developed by the agency, the agency shall perform and maintain an assessment that documents the gaps between requirements of the IDM rule and existing IDM services, applications, architectures and capabilities currently in place. At a minimum, the assessment must: identify any plans, target dates, and resources necessary to achieve compliance with each requirement of the IDM rule, and document any compensating controls or risk acceptance for requirements that are not applicable or cannot be met.

(c) Establish or identify a primary IDM service within each authentication boundary that complies with the requirements of this rule.

(d) Establish trust relationship criteria for any resources of the relying party being made available through a trust relationship.

1. Using the Federal Information Processing Standards (FIPS) Publication No. 199 (February 2004), which is hereby incorporated into this rule by reference and may be found at: http://www.flrules.org/Gateway/reference.asp?No=Ref-06498, evaluate the criticality and sensitivity of the resources that will be made available by the relying party through the trust relationship to users with credentials issued by the trusted identity provider and credential service provider.

2. Define a minimum level of Identity proofing to be performed by the identity provider when enrolling users to obtain credentials issued by the trusted identity provider.

3. Define a minimum token assurance level and token control that is appropriate for the resources, data or services of the relying party being accessed by users through the trust relationship.

4. Define the documentation (bona fides) required to provide evidence of the trusted identity providers’ and credential service providers’ ability to meet the requirements of the criteria.

5. Define end-user requirements to meet the privacy, confidentiality, and security criteria for the resources being made available by the relying party through the trust relationship.

6. Define the criteria for the protocol and data exchange format between the relying party and the trusted credential service provider.

7. Define the audit, accountability, and logging criteria for the trusted identity provider and credential service provider.

8. Evaluate the identity provider and credential service provider to ensure compliance with the established criteria for the resources being made available through the trust relationship.

9. Document trust relationship criteria evaluations and make the documentation available to AST upon request.

10. Provide access to established trust relationship criteria for eligible users of resources of a relying party.

a. Establish interoperability between IDM services that will be used to provide access to resources of a relying party that meet the requirements of this rule and the requirements set by the relying party trust relationship criteria.

b. Implement compensating controls for IDM services that are unable to comply with a specific requirement due to the specific nature of a service or its environment. Compensating controls may include, but are not limited to, requiring users to utilize a compliant IDM service to access a non-compliant IDM service or application.

c. Submit assessments to AST upon request.

(2) Interoperability.

(a) Third Party Authentication. Relying Parties must be capable of accepting external users authenticated by trusted third-party Identity Providers.

(b) Standardized Credentials. Identity Provider services must be consumable by more than one Relying Party and must utilize one or more of the following Standards:

1. The Kerberos Network of Authentication Service Version 5, The Internet Society, 2005;

2. The OAuth 2.0 Authorization Framework, Internet Engineering Task Force, October 2012;

3. OpenID Standard Connect Version 1.0, The OpenID Foundation, 2013;

4. Organization for the Advancement of Structured Information Standards (OASIS) PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification, Version 2.4, Technical Committee, April 14, 2015;

5. Assertions and Protocol for the OASIS Security Assertion Markup Language, Version 1.1, Security Services Technical Committee; 2013;

6. Authentication Context for the OASIS Security Assertion Markup Language, Version 2.0, Security Services Technical Committee, 2005;

7. OASIS Web Service Security: Simple Object Access Protocol (SOAP) Message Security, Version 1.1, Web Services Security Technical Committee, February 1, 2006;

8. Universal Authentication Framework, Version 1.1, The FIDO Alliance, October 2016;

9. Universal 2nd Factor Overview, Version 1.1, The FIDO Alliance, September 2016;

10. OASIS Web Service Federation Language, Version 1.2, May 22, 2009;

11. Web Services Policy 1.2 – Framework (WS-Policy), World Wide Web Consortium (W3C), April 25, 2006;

12. OASIS WS-SecureConversation, Version 1.3, OASIS Technical Committee, March 1, 2007;

13. OASIS Web Services Security Kerberos Token Profile, Version 1.1.1, The Technical Committee, May 18, 2012;

14. OASIS Web Services Security Rights Expression Language (REL) Token Profile, Version 1.1.1, The Technical Committee, May 18, 2012;

15. OASIS Web Services Security SAML Token Profile, Version 1.1.1, The Technical Committee, May 18, 2012;

16. OASIS Web Services Security: SOAP Message Security, Version 1.1.1, The Technical Committee, May 18, 2012;

17. OASIS Web Services Security Username Token Profile Version 1.1.1; The Technical Committee, May 18, 2012;

18. OASIS Web Services Security X.509 Certificate Token Profile, Version 1.1.1, The Technical Committee, May 18, 2012;

19. OASIS WS-SecurityPolicy, Version 1.3, OASIS Standard incorporating Approved Errata 01, The Technical Committee, April 25, 2014;

20. OASIS WS-Trust, Version 1.4, The Technical Committee, April 25, 2012;

21. X.509 PKI, An Internet Attribute Certificate Profile for Authorization, Networking Working Group, April 2002;

22. X.509 PKI, Certificate Management Messages over CMS, Network Working Group, April 2000;

23. Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, Networking Working Group, March 1999;

24. Internet X.509 Certificate Request Message Format, Network Working Group, March 1999;

25. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, Network Working Group, June 1999;

26. Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile, Network Working Group, June 2004;

27. Internet X.509 Public Key Infrastructure Qualified Certificates Profile, Network Working Group, January 2001;

28. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), Network Working Group, August 2001;

29. W3C SOAP Version 1.2 Part 1: Messaging Framework (Second Ed.), April 27, 2007.

(c) Standardized Data Exchanges. Identity Provider services must use one or more of the following Standard Data Exchange Formats:  Extensible Markup Language (XML); JavaScript Object Notation (JSON); Resource Description Framework (RDF).

(d) Documented Processes: Identity Providers and Relying Parties must use documented business policies and processes in conducting their digital identity management functions, including internally and in Transactions between Identity Providers and Relying Parties.

(e) Third Party Compliance: State managed or third party service providers that provide digital identity management functions to the State must comply with each of the requirements specified in this Standard that apply to the consumers of that service.

(f) User Redress: Identity Providers must provide mechanisms for redress of complaints or problems arising from identity Transactions or the failure of the identity provider to comply with each of the requirements specified in this Standard. These mechanisms must be easy for Relying Parties to find and access.

(g) Accountability: Identity Providers must satisfy the requirements specified in this Standard, by documenting compliance auditing, validation, and verification.

(3) Privacy.

(a) Data Minimization: Identity Providers providing Claims or Attributes must not provide any more personal information than what is requested. Where feasible, Identity Providers must provide technical mechanisms to satisfy information requests of variable granularity, to support data minimization.

(b) Purpose Limitation: Relying Parties must limit the personal information that is collected, used, transmitted, or stored to the specified purposes of that transaction.

(c) Attribute Minimization: Relying Parties requesting Attributes must request only Attributes necessary for a transaction. Where feasible, Attributes shall be used, transmitted and stored in the form of Claims instead of actual Attribute values.

(d) Credential Limitation: Relying Parties must not request a user’s credentials unless necessary for the Transaction and then only as appropriate to the risk associated with the Transaction or to the risks to the parties associated with the Transaction.

(e) Data Storage Risk: Relying Parties must protect all stored Personally Identifiable Information in accordance with  Chapter 74-2, F.A.C.

(f) Usage Notice: Relying Parties must provide concise, meaningful, and timely communication to Users describing how they collect, generate, use, transmit, and store and retain personal information.

(g) User Data Control: Identity Providers and Relying Parties must provide mechanisms to enable Users to access and correct Personal Information, unless prohibited by Chapter 119, F.S.

(h) Third-Party Limitations: Wherever Users make choices regarding the treatment of their Personal Information, those choices must be communicated effectively by Identity Providers or Relying Parties to any third-parties to which it transmits the Personal Information.

(i) User Notification of Changes: Identity Providers and Relying Parties must, upon any changes to a service or process that affects the prior or ongoing collection, generation, use, transmission, storage, or retention of users’ Personal Information, notify those users in writing within 30 days, and provide them with compensating controls designed to mitigate privacy risks that may arise from those changes, which may include seeking express affirmative consent of users in accordance with relevant law or regulation.

(j) User Option to Decline: Users must have the opportunity to decline registration; decline credential provisioning; decline the presentation of their credentials; and decline release of their attributes or claims.

(k) Optional Information: Relying Parties must clearly indicate to Users what Personal Information is mandatory and what Personal Information is optional prior to the Transaction.

(l) Data Retention and Disposal: Relying Parties must limit the retention of Personal Information to the time necessary for providing and administering the functions and services to users for which the information was collected, and adhere to all applicable legal and record retention requirements . When no longer needed, Personal Information must be disposed of accordance with all applicable legal and record retention requirements. 

(m) Attribute Segregation: Wherever feasible, identifier data must be segregated from attribute data.

(4) Security.

(a) Security Practices. Agencies, State Managed, and Third Party Identity Providers must apply all Standards identified in Chapter 74-2, F.A.C., for systems that support their identity functions and services.

(b) Data Integrity: The confidentiality and integrity of identity, token, and credential data must be protected while the data is at rest and during transit.

1. Identity, token, and credential data must be encrypted at rest via utilization of secure cryptographic methods, based on 256 bit (or greater) Advanced Encryption System (AES) algorithms.

2. Identity, token, and credential data must be protected during transit via x.509 public key infrastructure (PKI), utilizing digital certificates, certificate signatures, and asymmetric or symmetric encryption algorithms. The x.509 Standard identifies required fields and values to be used in the certificate.

3. Applicants must be able to verify that the RA is a trusted source.

4. RAs must be able to verify the identity of an applicant.

5. Claimants must be able to verify that the CSP is a trusted source.

6. CSPs must be able to verify that the claimant is who they claim to be.

7. CSPs must track the credentials issued to each Subscriber.

8. RPs must be able to verify that the Credential presented by the Subscriber is from a trusted CSP.

(c) Token Control: Identity services that authenticate a user (or agent) must prove, through a secure authentication protocol, that the user (or agent) is presenting the appropriate token(s). Token Control is best demonstrated by a user providing token value through the authentication protocol (e.g., password, personal identification number, or biometric data).

(d) Multifactor Authentication: Identity services or verification services that authenticate a User must offer authentication mechanisms which augment or are alternatives to a password. Examples include a physical thing a User carries with them (computing device, USB token, mobile phone, key fob), biometric authentication, or any combination of these.

(e) Key Management: Identity Providers that use cryptographic solutions as part of identity management must implement key management policies and processes that address the following:

1. Generating keys for different cryptographic systems and different applications.

2. Generating and obtaining public keys.

3. Distributing keys to intended users, including how keys should be activated when received.

4. Storing keys, including how authorized users obtain access to keys.

5. Changing or updating keys, including rules on when and how keys should be changed.

6. Addressing compromised keys.

7. Archiving, revoking, and specifying how keys should be withdrawn or deactivated.

8. Recovering keys that are lost or corrupted as part of business continuity management.

9. Logging the auditing of key management-related activities.

10. Instituting defined activation and deactivation dates, and limiting the usage period of keys.

(f) Security Logs: Identity Providers and Relying Parties conducting digital identity management functions must log their Transactions and security events, in a manner that supports system audits, security investigations and regulatory requirements. Timestamp synchronization and detail of logs must be appropriate to the level of risk associated with the environment and Transactions.

Rulemaking Authority 282.0051(19) FS. Law Implemented 282.0051(2) FS. History-New           .

 

NAME OF PERSON ORIGINATING PROPOSED RULE: Eric Larson, Interim Executive Director

NAME OF AGENCY HEAD WHO APPROVED THE PROPOSED RULE: Eric Larson, Interim Executive Director

DATE PROPOSED RULE APPROVED BY AGENCY HEAD: March 29, 2017

DATE NOTICE OF PROPOSED RULE DEVELOPMENT PUBLISHED IN FAR: January 17, 2017