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/29/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  Commerce/NOAA/NMFS policies E-Authentication/e-signature Risk Assessment Process National Marine Fisheries Service Pilot Systems Summary assessment of E-signature pilots based on the risk assessment process 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: OMB 04-04, December 6, 2003 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. Commerce/NOAA/NMFS policy & guidelines Department of Commerce, National Oceanic & Atmospheric Administration, National Marine Fisheries Service NATIONAL MARINE FISHERIES SERVICE POLICY DIRECTIVE PD 32- 110, September 7, 2006, Information Management : USE AND IMPLEMENTATION OF ELECTRONIC SIGNATURES NATIONAL MARINE FISHERIES SERVICE INSTRUCTION 32-110-01, JUNE 25, 2007, Information Management: Use and Implementation of Electronic Signatures, NMFSPD 32-110. EVALUATION AND IMPLEMENTATION OFELECTRONIC SIGNATURES –PROCEDURAL DIRECTIVE

7. Five Step Process for Determining Desired Assurance Level (OMB Policy) First two steps are the primary focus for this presentation  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.

8. 4 Levels of Assurance—Level 1 (examples from OMB 04-04) 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

9. 4 Levels of Assurance—Level 2 (examples from OMB 04-04) 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

10. 4 Levels of Assurance—Level 3 (examples from OMB 04-04) 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

11. 4 Levels of Assurance—Level 4 (examples from OMB 04-04) 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.

12. Risk Assessment Process (Criteria from OMB 04-04, but range for likelihood proposed) 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

13. 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

14. Impact Examples for NMFS 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).

15. Impact Examples for NMFS 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.)

16. Impact Examples for NMFS 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.  High—a risk of civil or criminal violations that are of special importance to enforcement programs. No known NMFS example.

17. 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 04-04 * Risk analysis is to some extent a subjective process, in which agencies must consider harms that might result from, among other causes, technical failures, malevolent third parties, public misunderstandings, and human error. Once risks have been identified, there may also be ways to adjust the business process to mitigate particular risks by reducing the likelihood that they will occur. (page 8, OMB M 04-04)

18. NIST Special Publication 800-63: Electronic Authentication Guideline 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

19. 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

20. 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.

21. 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

22. 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.

23. 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)

24. 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.

25. 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

26. 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)

27. 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 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 Identification Number, required by Debt Collection Improvement Act, provides significant confidence that the party is who they claim to be.  Existing permit holders may have considerable value in the system; for example, they may own fisheries quota that has significant market value that they will not want to jeopardize. but renewals are processed in the context of a rich ongoing relationship among the permit holder, the permit holder's partners in business transactions, and the agency, and deceptions with respect to an individual's identity would be difficult to sustain in this context.  New permit applications generally involve processing rigor commiserate with the value of the permit. This may involves confirming vessel ownership with the US Coast Guard, verifying participation in prior fisheries through previously submitted state or federal fish tickets or logbooks, confirmation of business ownership, etc. 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

28. 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: √ low to moderate  Unauthorized release of sensitive information: √ low  Civil or criminal violations: √ low to moderate Likelihood of harm or impact: low Presumed Assurance level: 1

29. Hawaii Longline Logbook: Summary Risk Assessment Users and functionality  Mid-size vessels (vicinity of 70ft) that have GPS, VMS, and sophisticated fish-finding technology where the operator of the fishing vessel is the end-user.  Some have e-logbook software onboard integrated with track plotting systems.  This e-logbook application includes a unique identifier via a hardware dongle which could be used to identify data from the vessel.  E-Logbook Vendor Certification Guidelines are in the approval process that would allow a vendor to promote an e-logbook application as NMFS-approved for e-logbook compliance.  Functionality would be creation/maintenance of the e-logbook record, storage of the e-logbook records on portable media (floppy, cd, memory stick), and physical transfer of the portable media to NMFS... or, alternatively, email transmission of e-logbook records to NMFS Transactions  Data sensitivity requirements include the Privacy Act, Magnuson-Stevens Fishery Conservation and Management Reauthorization Act, FOIA, Halibut Act and the Trade Secrets Act  Up to 200 vessels with the possibility of daily reporting per vessel over time. Might start with reporting with each landing, about every several week per vessel. 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 Identification Number, required by Debt Collection Improvement Act, provides significant confidence that the party is who they claim to be. Potential impact:  Inconvenience, distress or damage to standing or reputation √ low  Financial loss or agency liability: √ low  Harm to agency programs or public interest: √ low  Unauthorized release of sensitive information: √ low  Civil or criminal violations: √ low to moderate Likelihood of harm or impact : low Presumed Assurance level: 1

30. West Coast Federal Fixed Gear Logbook: Summary Risk Assessment Users and functionality  Some technologically advanced vessels in the 65-70 foot range, but also some small vessels, perhaps as small as sixteen feet, fishing with rod and reel and potentially no technology aboard.  Current conceptual design anticipates vessels hosting e-logbook software on a PC onboard the vessel and reporting as required (at the end of a day or trip) via email from the vessel, or alternatively, reporting by email from home after completion of a day-trip.  Combinations might be accommodated; perhaps capturing the data on a PC, saving it to portable media such as a memory stick, taking the memory stick home after the day-trip, and transmitting the file from home via email.  Near to real-time information on catch and bycatch is required as an element of National Standard 1 (NS1). Transactions  Data sensitivity requirements include the Privacy Act, Magnuson-Stevens Fishery Conservation and Management Reauthorization Act, FOIA, Halibut Act and the Trade Secrets Act  Approximately 500 vessels. Conceptual design would have these vessels reporting daily when they fish. These vessels may fish for up to nine months per year, so transactions volumes could approach 500/day and 135,000/year. 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 Identification Number, required by Debt Collection Improvement Act, provides significant confidence that the party is who they claim to be.  Users have "trusted relationship" with NMFS based on prior relationship that involves confirming vessel ownership with the US Coast Guard, verifying participation in prior fisheries through previously submitted state or federal fish tickets or logbooks, confirmation of business ownership, etc. Potential impact:  Inconvenience, distress or damage to standing or reputation √ low  Financial loss or agency liability: √ low  Harm to agency programs or public interest: √ low  Unauthorized release of sensitive information: √ low  Civil or criminal violations: √ low Likelihood of harm or impact: low Presumed Assurance level: 1

31. West Coast E-Fish Ticket: Summary Risk Assessment Users and functionality  The trawl fleet (whiting) is most technology sophisticated fleet in the Northwest Region, but, by regulation fish tickets are reported by processors.  Whiting processors are large permanent shoreside facilities which will be completely comfortable with this type of technology. If/when e-ticket technology expands to other fisheries it is important to recognize that some processors are in the "white van fleet", without a fixed base of operations or any technology beyond a cell phone.  Near to real-time information on catch and bycatch is required as an element of National Standard 1 (NS1). Transactions  Data sensitivity requirements include the Privacy Act, Magnuson-Stevens Fishery Conservation and Management Reauthorization Act, FOIA, Halibut Act and the Trade Secrets Act  In the Northwest Region the states have existing fish ticket programs (actually 26 of them). These were originally developed for revenue purposes, but the fish tickets have become multi-purpose documents, functioning as a receipt between buyer and seller, as a record of catch (and sometimes of effort) for fisheries management, as documentation of participation in a fishery, as a record of gross profit for calculation of crew shares, as documentation of value for economic analysis, and of course the original purpose of government tax records.  The current whiting fishery fish ticket volume is 40 boats for up to 20 days of fishing, for a ceiling of approximately 800 transactions. The potential of e-ticket transactions would eventually approach the total volume of fish tickets on the West Coast. (which is ????). 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 Identification Number, required by Debt Collection Improvement Act, provides significant confidence that the party is who they claim to be.  Users have "trusted relationship" with NMFS based on prior relationship that involves confirming vessel ownership with the US Coast Guard, verifying participation in prior fisheries through previously submitted state or federal fish tickets or logbooks, confirmation of business ownership, etc. Potential impact:  Inconvenience, distress or damage to standing or reputation √ low  Financial loss or agency liability: √ low  Harm to agency programs or public interest: √ low  Unauthorized release of sensitive information: √ low  Civil or criminal violations: √ low Likelihood of harm or impact: low Presumed Assurance level: 1

32. NMFS Risk Mitigation Through E-Authentication (in process) 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

33. Recommended eSignature Solution Framework for NMFS (in process) 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) ?

34. Next Steps for Analysis (in process) 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  ?