Difference between revisions of "Cybersecurity Framework for Mobile Credentials"

Latest revision as of 16:36, 27 February 2024

Full Title

A cyber security analysis of privacy enhancing mobile credentials issued to residents by a sovereign entity for the purposes of granting access to controlled privileges with identity assurance appropriate to the value of the license granted.

Author: Tom Jones

Current Version date: 2023-03-01

Context

Following in the model of the evolving NIST cyber security framework, this analysis will begin with a full system risk model, including the risk of alienating an already anxious public given the insecurity of existing digital databases.

This paper is designed for three purposes:

1. To guide the development of standards in this area,
2. To help the current generation of architects, developers and testers using mobile credentials,
3. To be a model use case for future NIST standardization.^[1]

It is planned that a future document like this one will address credentials that are created by commerce and industry.

System Risk Model

In line with the NIST effort to integrate Cybersecurity with Enterprise Risk Management^[2] While NIST indicates that cybersecurity risk receives proper attention, this document presumes that Cybersecurity risk and Conduct Risk are the primary problems in any enterprise that employs Mobile Credentials as a integral part of any primary service offering must place these two threats as the top consideration. The principal reason that Conduct Risk is included here is that in many organizations security spending is minimized to maintain current profit reporting and thus the two are intimately co-mingled. The terms risk profile, risk appetite and risk tolerance used in the NIST document are subsumed here in the term Conduct Risk. For an executive summary on enterprise risk please see thee NIST document. The other term user here, Risk Register is defined in OMB Circular A-11 as a repository of risk information including the data understood about risk over time. If your enterprise does not have risk defined in such a registry, there is no chance that you can make good choices about risk. An Enterprise for the purposes of this paper will be any organization that has at least one risk registry and so can make informed risk decisions. All of the concepts of the NIST document are included by reference including: communicating risk, consistently identifying threats and risks, estimating likelihood and impartial, calculating risk exposure, establishing and using risk reserves, monitoring risk, reporting risk and integrating with other partner and Enterprise systems.

Conduct Risk covers all of the consequences of decisions made by management. or Mobile Credentials many of these will be difficult value judgments such as the level of assurance of strong identification versus the harm of not allowing access to a needed resource, for example, the risk imperfect patient identity versus the need for immediate care, either of which could lead to death, or the risk of allowing a person with an impairment of any sort to drive a motor vehicle versus the risk of preventing that individual from getting to work to earn a living for their family. By far the most common conduct risk is exposed by the tradeoff between paying for strong cybersecurity versus paying good dividends or advancing some program that could provide immense benefit to a large part of the population. The best protection for managers facing these decisions is a strong risk analysis that was consulted when the decision was made.

When new programs are put into place a good risk and threat analysis should be completed before important decision points, such as when the system architecture is signed off and before significant new or changed designs are deployed to unwary populations of any sort. It is unacceptable to defer cybersecurity analysis till after deployment. In the US military this an integral part of what is known as acquiring "Authority to Operate".

Audience

All risk decisions need to start (in the corporate world) at the board of directors. This means that at least the executive summary of any risk document (including this one) is addressed to that level of control. But immediately after management, the system architect must be aware of the risk and include mitigates for the threats in every design. At the end of the day, the security of the system will reside with the policies and procedures that are followed by the programmers and the builders. Once they have completed their task, the finished product also needs to be evaluated and documentation prepared that can be reviewed by the final audience, the auditors and pen testers.

Taxonomy

Some of the terms needed for this framework are in the Audience section above, others are:

1. Identity is used sparingly in this document as it applies to a real-world natural person as they are in the real world.
2. Identifier is a digital sequence of encoded symbols that is used to tie a digital presence to some identity, natural or otherwise.
3. User is the digital presentation of that natural person.
4. Delegate is any digital presentation that can make authoritative statements for that natural person.
5. Wallet is a digital instance running on a user-controlled device that is trusted to hold user secret data.
6. Personally Identifiable Information (PII) is any information that can be used to identify the holder.
7. Credential is a document binding a user identifier to a collection of attributes and licenses that can be entered into a digital wallet and the user considers to be private.
8. Trust is mentioned in the Cybersecurity Framework only the extent that the Zero Trust Architecture should apply. However, it is critical here.

Gaps in Managing Cybersecurity Risks

The effect of uncertainty on Enterprise mission and business objectives may then be considered an “enterprise risk” that must be managed. ^[2] That is the stated goal, but the result is most often just the creation of a check list that the enterprise can complete and then claim that they are secure. Clearly that approach is not working and a new one is required. To be secure any cybersecurity framework needs to be baked into the development process starting when the architecture is created up to the point where customer documentation is created. The followup steps are well considered in the framework.

• Identifying the risks including the (financial and reputational) cost and likelihood of occurrence. The biggest problem with a checklist is that it looks like something that happens after the product is completed and ready for deployment.
  • Compliance with all regulations, including the ability to report on who had access to what and when. In some cases, like the SEC, that access must be fast and complete to assure that disclosure laws were followed.
  • Since such access discloses personal information, all such log must be accessed only on a need-to-know basis or be appropriately anonymized.
  • Engagement with appropriate Enterprise officials would include, for example, the Chief Information Security Officer (CISO) as well as the Chief Privacy Officer (CPO). Also, the cost, both financial and reputational, must be factored into the design.
  • Personal risk includes not only evaluating the people with access, but also the speed with which a terminated employee can be removed from access and only granting least-privilege access.
  • Separation of duties requires that no one person can make a change to the code base without another person validating that change.
  • Code builds that are signed and released to the public must be made by a person who is not one of the coders and only from approved code.
  • Documentation of all changes by the person making the change, all code build paths, including creation of a complete bill of materials that show who made a decision to take a dependency on external code.
• Providing all of the members of the identity ecosystem with details that allow then to trust the system is critical.
  • Users have traditionally been the hardest of the entities to encourage to take a critical view of incoming messages.
  • Phishing of user credentials has become the most common attack against system integrity but is not included in the NIST Framework.
  • In spite of user's proclivities there are still security people that would try to educate the user rather than to make the system secure.
  • Any zero-trust architecture should not rely on user choices except where they have been able to display useful choices to the user.
• Zero trust is mentioned in the Cybersecurity Framework, but missing from the analysis and, based on reports, missing from most deployments.
  • Microsoft reports^[3] that 93% of ransomware incident response engagements revealed insufficient controls on privilege access and lateral movement. More so than malware, attackers need credentials to succeed in their operations. The successful human operated ransomware infection of an entire organization relies on access to a highly privileged account.
  • In 2008 Tom Jones initiated the "Protected Admin" account effort that shipped in Vista as "User Account Control" as the largest Mandatory Integrity deployment in history. Unfortunately it is still common practice, particular in Linux circles to create admin tools that allow all access to all admins. Somehow this practice needs to be called out and brought to a swift end or continued attacks against highly valued targets will coninue.

Determination of Potential Threats

Cybersecurity risk is not inherently good or bad. Rather, it represents the effects of uncertain circumstances, so risk managers should consider a broad array of potential positive and negative risks. ^[2]

The most common form of threat analyses are based on (1) looking at the data flows to see the point where attacks can be perpetrated. See the wiki page on Threat Models and (2) looking that the exploits that have been accumulated, for example at MITRE ATT&CK reports^[4] and best practices. ^[5] The former is forward looking, and the latter is backward looking. Both views are valuable.

These analyses need to be performed at both the end of the design phase and before the product is release to the customer. The result must be a result of a review by all the parties involved within the Enterprise. Not all of the risk will be fully mitigated at the end of the analysis phase, but the remaining ones need to be within the range acceptable to management.

Identify the Context

The scope of this Framework is any sovereign entity that needs to identify its residences for legally determined obligations, privileges or benefits. In many cases businesses will be involved as providers of goods or services to any of the parties described below. While the current draft of the NIST Framework only includes the word trust to the extent that the Framework needs to accommodate the Zero Trust Architecture mandate, for mobile credential to have any value as the move from location to location, there must be some level of trust ascribed to, not only, the credentials, but also to the devices and entities that are involved the transaction.

The diagram below was taken from the Kantara Privacy Enhanced Mobile Credential document to identify the parties involved.

Ecosystem Context

Prepare for an unbelievably long list of entities that must all work in Harmonie to create the desired results. At its core the result is seemingly simple. A resident has possession of a mobile computing device with some sort of network connection that can contain the means to participate in determining the identity of the holder who is either the resident, or a delegate that can act as a stand-in for that resident. Even within the sovereign entity itself there are competing goals, for example: the Department of Motor Vehicles (DMV) might be fee based and see every identifier cost as a need to find a corresponding user fee, while the Department of Health (DoH) is trying to find identifier methods that will reduce overall costs.

• The first risks are systemic and a result of this broad distribution of the responsibilities for a resident to be authenticated to the service provider of the resources desired by that resident and controlled, at some level, by that sovereign entity.
• If users find the digital state ID hard to use or expensive or inconvenient or untrustworthy, the uptake of Mobile Driver's Licenses or other state IDs will be poor, unless there is some mandate to use those mobile credentials.
• If verifiers find that some issuers are not willing or able to meet strong authentication criteria in granting credentials, they are likely to stop accepting credentials from that issuer. For example, DigiNotar was a private issuer approved to issue Dutch certificates. On September 3, 2011, after it had become clear that a security breach had resulted in the fraudulent issuing of certificates, the Dutch government took over operational management of DigiNotar's systems. That same month, the company was declared bankrupt.^[6]
• Governments around the world have been implicated in data breaches, this article lists the 10 largest at that time. As a result, if breaches and prosecution of people based in data held in government data bases, many people do not trust government agencies any more data than they are required to.

Issuer Context

• For this Framework the Issuer of record is the sovereign Entity that needs to track residents for a wide range of purposes. Typically, the sovereign entity will create some department that takes broad responsibility to engage directly with the resident and any delegate to create the account of that resident with the sovereign entity.
• See wiki page on State Mandated Identification contains some history plus a listing of the 135 Washington state agencies that keep information on residents for one reason or another. While there is an effort to combine some of these databases and identifiers, there is much institutional resistance to giving up control and very little money to enable it.
• For health care records, which are protected in the US by the HIPAA legislation, the data base software is subjected to rigorous testing before it can be used, but this is the exception rather than the rule. No plan to require the sovereign states in North America to testing of their identification or data protection is under consideration.
• Some sovereign states have sold their information on users to private companies. In a 2020 CBS 11 News investigation, the I-Team found the Texas Department of Motor Vehicles made more than $3 million in 2019 selling drivers' personal information. The Texas DMV sold the information to more than 2,700 government agencies and private companies, according to DMV records.On 2021-06-18 Texas passed a bill to stop this practice.
• Many issuers have to meet mandates that define the Ceremony necessary to grant a credential to a nature person. There is a similar process for identification of legal entities.
• ISO 18013-5 and other standards define some goals for issuers that include assurance as to the security and privacy of the wallet that holds the license. Yet there is no standard way, besides in-person credentialling, that can give the issuer any information about the identity of the wallet, the device holding the wallet or the holder of the device.

Device Context

• The device held by the user will come with some capabilities that need to be securely communicated to the issuer and the verifier if the information reported is to be considered part of the identification process. The device itself typically will contain some sort of identifier which needs to be considered as PII as it is so closely associated with the user.
• It takes only a small amount of user attribute data to uniquely Identify people. Most phone can track us in a manner that clearly shows our behavior and where we live. Even simple data like birthdate, zip code and gender typically shown on anonymized health records will have an 80% chance of uniquely identifying a person.^[7]
• Ensure that device trackers (like the smartphone tracer) are turned off.
• The user's device is uniquely able to test that the holder of the device and the subject identified are the same at the time that the authentication is being requested. While the obvious approach would be for the wallet to be trusted by the verifier of the credentials and the proof of presence of the holder, the approach currently be taken by ISO is to have the issuer determine if the wallet can do that and include that assurance in the credential issued to the user on that device. The ability of this complex solution is yet to be tested in any meaningful way even though it is in use today to validate the holder for credit transactions.
• Attacks to discover credentials stored on the device. Any valuable credential will have non-exportable keys. The best protection of a credential will require some sort of user gesture to use the credential to prove user intent.
• Install a program or script that can run as user^[5] and:
  • destroy or modify policy or cookies for an unrelated function, (Cross origin access is typically blocked on smartphones.)
  • discover other sites that the user can access,
  • track users access to other sites for clues,
  • discover other user accounts that can be attacked from the device,
  • proxy other data communications channels,
  • read, filter, modify or block data sent to other sites,
  • stage data that can be executed or sent to other sites,
  • read email that provides information about other functions the user can access.

Wallet Context

• For this Framework the Wallet of record is (nearly always) created by some private Enterprise that needs to have the skills available to create the application that runs on the mobile device. This represents the code as it is available for download into the user devices.
• Each wallet download will likely require the generation of an instance identifier or public key that can be reported when the wallet gets information from an issuer or supplies information to a verifier. Even the signing of a message to either of these entities will result in the sharing of a public key, which, if reused, can be a very good tracker for the user that owns the wallet instance and the information contained therein.
• Each device used to access protected content will need to acquire its own wallet and identifier that will then need to be correlated with the other devices to give the user a consistent user experience across all devices.
• When wallets are delivered to the user from sites that already have user accounts, like Google, Apple, Meta and Microsoft, the opportunity for cross correlation of user attributes and behaviors is greatly enhanced.
• Second and third world economies that have little history of electronic payments are more susceptible to aggregation of user data as evidenced by the two large providers in China, Alipay and WeChat Pay.
• See the Kantara draft solution for proving the identity of the wallet to the verifier as well as the binding of the credential holder to the wallet holder.

Verifier Context

• For this Framework the Verifier of record will be the Entity that the holder of the wallet approaches. This is the primary identity that the user understands to be the owner of the resource that they want to use. This could be the state police, the local airport or a car rental agency.
• As a rule, the Verifier is only concerned with its own survival and so is bound only by legal and conduct liability. Where the issuer is a sovereign entity, it has the authority it needs to constrain the actions of the verifier, but it is seldom the issuing authority of the sovereign entity that is charged with protection of the user's privacy.

Verifier Provider

• For this Framework the Verifier Provider is a software or hardware provider of services used by the Verifier to complete their evaluation. This Entity does not handle user information itself but does provide software or hardware that does. Certification of these products would be required in health or first responder cases and perhaps others in the future.

Verifier Service

• For this Framework any Verifier Service is an Entity that handles user private information (PII). An example might be a restaurant payment service that also handles user private information like age to allow liquor consumption, or a protection service for a nuclear reactor that verifies access to the site.

Identify the Risks

This section needs to take two approaches to risk identification: Backward looking at existing attack models and Forward looking at an analysis of the design. In either case a data flow diagram is needed to identify where the attacks can occur. The three point diagram above should would for this framework where attack can occur at any of the three entities or at any of the three communications channels between any two entities. In all cases the three entities may have some internal structure which exposes other vulnerabilities that are not within the purview of this framework.

Backward Looking Evaluation

This type of evaluation looks at the current attacks against security to determine if the framework can mitigate known attacks.

Forward Looking Evaluation

This type of evaluation looks at a specific solution using a risk-based analysis to identify vulnerability points of the design and implementation of the solution.

Monitor, Evaluate and Adjust

Reality has a way of not matching with the expectations of the analysis phase. What that means is that risk evaluation and analyses must continue throughout the product life cycle.

References

1. ↑ National Institute of Standards and Technology, NIST Cybersecurity Framework 2.0 Concept Paper: Potential Significant Updates to the Cybersecurity Framework of cyber security frameworks. (2023-01-19) https://www.nist.gov/system/files/documents/2023/01/19/CSF_2.0_Concept_Paper_01-18-23.pdf
2. ↑ ^{2.0 2.1 2.2} Kevin Stine (NIST) + 3, Integrating Cybersecurity and Enterprise Risk Management (ERM) NISTIR 8286 https://csrc.nist.gov/publications/detail/nistir/8286/final or as https://doi.org/10.6028/NIST.IR.8286
3. ↑ Microsoft Digital Defense Report FY 2022 (2023-02) https://clouddamcdnprodep.azureedge.net/gdc/gdcenvlPz/original?ocid=eml_pg368957_gdc_comm_mw&mkt_tok=MTU3LUdRRS0zODIAAAGJ76j1OsglpNjDc7WwmvZ6kgSAHl8q5MDiaMx3H01xVimXS021PRpnqbP_HXPKK450Xro55nRPh7rECbHt9AFpn_ws0rrLfepfAstFYGtY6CUTDxHMcAkPjlgW
4. ↑ MITRE ATT&CK https://attack.mitre.org/
5. ↑ ^{5.0 5.1} MITRE, Best Practices for MITRE ATT&CK® Mapping (2023-01) https://www.cisa.gov/uscert/sites/default/files/publications/Best%20Practices%20for%20MITRE%20ATTCK%20Mapping.pdf
6. ↑ Nicole van der Meulen, DigiNotar: Dissecting the First Dutch Digital Disaster. Journal of Strategic Security. 6 (2): 46–58. (2013-06) doi:10.5038/1944-0472.6.2.4. ISSN 1944-0464.
7. ↑ Latanya Sweeney, Simple Demographics Often Identify People Uniquely https://dataprivacylab.org/projects/identifiability/paper1.pdf

Other Material

• See also the wiki page on Wallet Requests for messages between the verifier and the wallet.
• This page is kept updated at https://tcwiki.azurewebsites.net/index.php?title=Cybersecurity_Framework_for_Mobile_Credentials