1. NMFS FIS ER eSignature Project Risk Analysis October 1, 2008

2. 9/19/20082 NMFS eSignature Project Timeline Preliminary Schedule 7/25/08-- Stakeholder Communication Plan, which identifies stakeholders, the nature of their interest in NFMS eSignature solutions, their issues or concerns, points of contact and methods for keep relevant stakeholders informed and engaged. 8/27/08--Alternatives Analysis for technical approaches to eSignatures 10/1/08--Risk Assessment of pilots and assignment of assurance levels for pilots 10/15 Business plan (i.e., cost/benefit analysis) and implementation template drafted for Hawaii non-commercial bottomfish e-logbook and West Coast Groundfish logbook according to NMFS procedural directive 32-110-02 10/31/08-Capstone meeting to review draft business plan and implementation plan template prepared according to NMFS procedural directive 32-110-02 with the intent to discuss:  Lessons learned  Next steps for remaining three pilots 12/5/2008--Presentation of preliminary results to stakeholders 12/19/2008--Critique of final project documents.

3. Table of Contents Legal and Policy Context  GPEA  OMB Policy  NIST Technical Guidance E-Authentication Risk Assessment National Marine Fisheries Service Pilot Systems E-signature pilot recommendations based on risk assessment Next Steps

4. Legal and Policy Context for Electronic Authentication The Electronic Signatures in Global and National Commerce (E-SIGN) Act:  legitimates legal standing of e-signatures and contracts and transactions signed electronically. Technology neutral on e- signatures Government Paperwork Elimination Act--Section 1709(1) of GPEA reads:  “electronic signature” means a method of signing an electronic message that—(A) identifies and authenticates a particular person as the source of the electronic message; and (B) indicates such person’s approval of the information contained in the electronic message. E-Government Act of 2002—mostly emphasis on Privacy Impact Assessments

5. OMB e-Authentication Policy Does not proscribe technologies or even assurance levels Definitions from NRC’s Who Goes There? Privacy Implications of Authentication. Attribute describes a property associated with an individual an identity of X” is the set of information about an individual X associated with that individual in a particular identity system Y Identification is the process of using claimed or observed attributes of an individual to infer who the individual is Authentication-- is the process of establishing confidence in the truth of some claim  Individual authentication is the process of establishing an understood level of confidence that an identifier refers to a specific individual  Attribute authentication is the process of establishing an understood level of confidence that an attribute applies to a specific individual  Identity Authentication is the process of establishing an understood level of confidence that an identifier refers to an identity Authorization is the process of deciding what an individual ought to be allowed to do

6. Five Step Process for Determining Desired Assurance Level (OMB Policy)  Conduct risk assessment  Map identified risks to assurance level (Four levels outlined in next four pages)  Select technology based on NIST technical guidance  Validate that implemented system has achieved desired assurance level  Periodically reassess system to assure solution produces desired assurance.

7. 4 Levels of Assurance—Level 1 Little or no confidence--A user presents a self-registered user ID or password to the U.S. Department of Education web page, which allows the user to create a customized “My.ED.gov” page. A third party gaining unauthorized access to the ID or password might infer personal or business information about the individual based upon the customization, but absent a high degree of customization however, these risks are probably very minimal. Some confidence High confidence Very high confidence

8. 4 Levels of Assurance—Level 2 Little or no confidence Some confidence--An agency employee has access to potentially sensitive personal client information. She authenticates individually to the system at Level 2, but technical controls (such as a virtual private network) limit system access to the system to the agency premises. Access to the premises is controlled, and the system logs her access instances. In a less constrained environment, her access to personal sensitive information would create moderate potential impact for unauthorized release, but the system’s security measures reduce the overall risk to low. High confidence Very high confidence

9. 4 Levels of Assurance—Level 3 Little or no confidence Some confidence High confidence—alternate examples from OMB  A patent attorney electronically submits confidential patent information to the US Patent and Trademark Office. Improper disclosure would give competitors a competitive advantage. (I would like to amend this one to be similar to level 2 where we say that additional controls bring this down to moderate)  First Responder accesses a disaster management reporting website to report an incident, share operational information, and coordinate response activities. Very high confidence

10. 4 Levels of Assurance—Level 4 Little or no confidence Some confidence High confidence Very high confidence--A law enforcement official accesses a law enforcement database containing criminal records. Unauthorized access could raise privacy issues and/or compromise investigations.

11. Risk Assessment Process Two criteria for risk assessment process:  Potential harm or impact (Selected examples to follow) Low Moderate High  Likelihood of harm or impact Low < 30 percent Moderate >30 and < 70 percent High > 70 percent

12. Categories of Harm and Impact from Risk Assessment Inconvenience, distress or damage to standing or reputation Financial loss Agency liability Harm to agency programs or public interest Unauthorized release of sensitive information Civil or criminal violations

13. Impact Examples for NMFS (Source: OMB Policy) Potential impact of unauthorized release of sensitive information:  Low—at worst, a limited release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in a loss of confidentiality with a low impact (i.e., limited adverse effect on organizational operations if one fishers’ logbook is accessed by another unauthorized fisher)  Moderate—at worst, a release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in loss of confidentiality with a moderate impact (i.e., serious adverse impact on organizational operations if fishers become less compliant with reporting requirements if believe that their competitive information will be released accidently).  High—a release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in loss of confidentiality with a high impact (i.e., severe or catastrophic adverse effect on organizational operations, which might include compromising future law enforcement activities).

14. Impact Examples for NMFS (Source: OMB Policy) Potential impact of inconvenience, distress, or damage to standing or reputation:  Low—at worst, limited, short-term inconvenience, distress or embarrassment to any party, where NMFS and one or two parties know of a problem, but is not known to the general public.  Moderate—at worst, serious short term or limited long-term inconvenience, distress or damage to the standing or reputation of any party, which might involve one-time negative press reports for the agency.  High—severe or serious long-term inconvenience, distress or damage to the standing or reputation of any party (ordinarily reserved for situations with particularly severe effects or which affect many individuals, like when NFMS loses credibility across a whole region or for stewarding a particular species of fish.)

15. Impact Examples for NMFS (Source: OMB Policy) The potential impact of civil or criminal violations is:  Low—at worst, a risk of civil or criminal violations of a nature that would not ordinarily be subject to enforcement efforts. This might include failure to report or under-reporting or misreporting catch.  Moderate—at worst, a risk of civil or criminal violations that may be subject to enforcement efforts. Example include impersonation in e-logbook transactions and repudiation of the transaction or signature to escape accountability. Because of the intricate set of regulatory and reporting relationships NMFS has with users that might be subject to civil or criminal action, there are a set of mitigating controls that reduce the impacts to low. (Question is whether this belongs here, on the pilot pages or both places)  High—a risk of civil or criminal violations that are of special importance to enforcement programs. No known NMFS example.

16. Assurance Level Impact Profiles Potential Impact Categories for Authentication Errors 1 2 3 4 Inconvenience, distress or damage to standingLow Mod Mod High or reputation Financial loss or agency liability Low Mod Mod High Harm to agency programs or public interests N/A Low Mod High Unauthorized release of sensitive information N/A Low Mod High Civil or criminal violations N/A Low Mod High Potential Impact Categories for Authentication Errors OMB E-authentication Policy

17. NIST Special Publication 800-63 Revisions from draft emphasized further that technology alone does not mitigate risk. Authentication technology works with policy and process to produce authentication solution Totality of authentication solution mitigates risks Does not proscribe technical solutions, but provides an array of options for each level of assurance

18. NIST Special Publication 800-63 Authentication solutions for specified assurance levels Level 1  No identity proofing requirement at this level  Anonymous credential OK  Some assurance that the same claimant is accessing the protected transaction or data.  Wide range of available authentication technologies to be employed and allows any of the token methods of Levels 2, 3 or 4, including PINS.  May also use tunneled passwords and challenge/response protocols

19. NIST Special Publication 800-63 Level 2  Identify proofing and registration provides sufficient assurance for relatively low risk business transactions with low probabilities of moderate impact from risk assessment.  Anonymous credential OK  A wide range of available authentication technologies can be employed at Level 2.  Any of the token methods of Levels 3 or 4, including passwords, are allowable  Successful authentication requires that the claimant prove through a secure authentication protocol (i.e., tunneled password protocol like SSL or TLS) that he or she controls the token.

20. NIST Special Publication 800-63 Level 3  Multi-factor remote network authentication.  Identity proofing procedures require verification of identifying materials and information.  Level 3 authentication is based on proof of possession of a key or a one-time password through a cryptographic protocol.  Requires cryptographic strength mechanisms that protect the primary authentication token  A minimum of two authentication factors is required.  Requires that the claimant prove through a secure authentication protocol that he or she controls the token, and must first unlock the token with a password or biometric, or must also use a password in a secure authentication protocol

21. NIST Special Publication 800-63 Level 4  Based on proof of possession of a key through a cryptographic protocol.  Level 4 is similar to Level 3 except that only “hard” cryptographic tokens are allowed  FIPS 140-2 cryptographic module validation requirements are strengthened, and subsequent critical data transfers must be authenticated via a key bound to the authentication process.  By requiring a physical token, which cannot readily be copied and since FIPS 140-2 requires operator authentication at Level 2 and higher, this level ensures good, two factor remote authentication.  Strong cryptographic authentication of all parties and all sensitive data transfers between the parties.

22. NIST Special Publication 800-63 Tokens are something that the user possesses and controls that may be used to authenticate the claimant’s identity. The user authenticates to a system or application over a network. A token shall include some secret information and it is important to provide security for the token. The three factors often considered as the cornerstones of authentication:  Something you know (for example, a password)  Something you have (for example, a cryptographic key or smart card)  Something you are (for example, a voice print or other biometric)

23. NIST Special Publication 800-63 Hard token – a hardware device that contains a protected cryptographic key. Authentication is accomplished by proving possession of the device and control of the key. Soft token – a cryptographic key that is typically stored on disk or some other media. Authentication is accomplished by proving possession and control of the key. The soft token shall be encrypted under a key derived from a password known only to the user, so knowledge of a password is required to activate the token. One-time password device token - a personal hardware device that generates “one time” passwords for use in authentication. Password token – a secret character string that a claimant memorizes and uses to authenticate his or her identity.

24. NIST Authentication Mapping (Token Type) Level 1Level 2Level 3Level 4 Hard crypto token √√√√ Soft crypto token √√√ Zero knowledge password √√√ One-time password device √√√ Strong password √√ PIN √ Note: This is not the assurance level for the authentication solution; just the token

25. Thoughts on Strong Passwords “People either choose not to use or make errors in systems that are not designed with their limits in mind; this can result in compromises to privacy.” (NRC Report Finding 4.1)

26. National Permits Systems: Summary Risk Assessment Users and functionality  Range from large multinational corporations to small family businesses.  Generally technologically sophisticated,  Technology presumably makes record-keeping and reporting less burdensome Transactions  Data sensitivity-varied by can include Privacy Act data and business confidential data  Volume-- ?? Not in grid?? Mitigating control processes  both parties to the transaction (typically the fisher and the fish processor) are permitted entities and each has some responsibility for accurate and complete record-keeping and reporting  Verification of name and Tax Idenfication Number will provide significant confidence that the party is who they claim to be. Potential impact:  Inconvenience, distress or damage to standing or reputation √ low to moderate  Financial loss or agency liability: √ low to moderate  Harm to agency programs or public interest: √ low to moderate  Unauthorized release of sensitive information: √ low to moderate  Civil or criminal violations: √ low to moderate Likelihood of harm or impact: Generally low to moderate Presumed Assurance level: 2

27. Hawaii Non-Commercial Bottomfish Logbook: Summary Risk Assessment Users and functionality  Non-commercial means recreational and subsistence.  No commercial software vendors are currently addressing this market.  NMFS is developing a web-based application for online reporting at the end of a day-trip.  Users are expected to report at the end of the day when they return to a place where they have computer/internet access. Transactions  Data sensitivity-varied by can include Privacy Act data and confidential data as defined by the Magnuson- Stevens Fishery Conservation and Management Reauthorization Act  Volume–users might range from 50 to 5,000 vessels with the potential of multiple reports per vessels and an unknown number of trips per year Mitigating control processes  It may be possible to validate some registrants through NPS.  There is a strong need for the information and little leverage for enforcement. Potential impact:  Inconvenience, distress or damage to standing or reputation √ low  Financial loss or agency liability: √ low  Harm to agency programs or public interest: √ moderate  Unauthorized release of sensitive information: √ low  Civil or criminal violations: √ low to moderate Likelihood of harm or impact: low Presumed Assurance level: 1

28. NMFS Risk Mitigation Through E-Authentication Policy  A  B Business process  ID proofing through NPS registration process  Mitigating controls from pilot section of wiki Technology  Data encryption (SSL or VPN) for confidentiality  User name/password to validate user identity May combine technologies or all three above to increase assurance level of solution

29. Recommended eSignature Solution Framework for NMFS NMFS policy, processes and technology provide a strong foundation for eSignature solutions eSignature technology does not assume all risk mitigation, as existing policy and process create a comprehensive authentication solution. Assuming any E-Authentication solution will work within existing risk mitigation processes,NMFS can use PIN and/or password for eSignature and E- Authentication for level 2 assurance for:  NPS  E-logs  Trip/Fish Tickets  Planned systems (subject to possible reanalysis) ?

30. Next Steps for Analysis This report contains a set of recommendation for assurance levels and potential e-authentication solutions Per OMB policy, check periodically that eSignature and e- authentication solutions provide desired assurance level Review and revise risk assessment for e-government applications as necessary when impact or probability of risks change Next Steps for Team  ?