How To Manage Federal Taxpayer Information In Microsoft Teams

by Scott Muniz | Jul 22, 2020 | Uncategorized

This article is contributed. See the original author and article here.

Defining FTI and Consequences of Non-Compliance

Originally Authored by:  Miknon Go |Senior Director, Strategic Advisors, AvePoint

It’s not just the Internal Revenue Service (IRS) or federal agencies, every state government has a department responsible for taxation or revenue.

By their very nature, these agencies handle both personally identifiable information (PII) as well as federal tax information (FTI).

PII is any sensitive information that can be used to identify an individual, such as social security numbers, whereas FTI is defined very broadly in Internal Revenue Code 6103 as return information received from the IRS or a secondary source. This includes information on a person’s tax affairs even if it is anonymized and identifiers are stripped out.

Information provided by the IRS must be classified as FTI, but the exact same information obtained in a different manner, may need to be classified as PII.

The sensitivity levels of PII and FTI require that agencies are extremely diligent in the protection of the confidentiality of this information.

Note: there are other types of regulated PII and the strategies provided can be easily modified to address regulations such as the Healthcare Insurance Portability and Protection Act (HIPAA) and others as well.

In fact, Internal Revenue Code 7213 makes it a felony offense for federal and state employees and others who illegally disclose federal tax returns and return information. It is “punishable upon conviction by a fine in any amount not exceeding $5,000, or imprisonment of not more than 5 years.”

Challenges to Compliant Collaboration

Many state agencies are challenged in their handling of FTI by a few key factors. Some are common communication challenges and risks for sensitive data types that aren’t specific to the nature of FTI such as:

• Multiple siloed divisions and agencies;
• Dispersed office locations across the state; and
• The need to work with a diverse range of external collaborators including taxpayers, vendors and contractors.

But perhaps the largest challenge to modernizing collaboration surrounding FTI data is that the unique restrictions and requirements placed on this data preclude the use of powerful collaboration platforms, such as Microsoft 365 (formerly Office 365), unless configured appropriately.

The obstacle to proper configuration often rests with how Microsoft 365 is deployed across the state government. In virtually every case, the entirety of the state’s government leverages a single Microsoft 365 tenant for all their agencies.

This is advantageous as it allows state governments to purchase at scale and enables faster, easier collaboration while removing data silos. It becomes a challenge, however, when agencies with specific data restrictions, like FTI data, require a different set of configuration settings than other agencies.

While Microsoft 365 is incredibly extensible and flexible, there are still certain settings, such as how you provision Groups, that follow a “one tenant, one rule,” architecture. As a result, the central state IT provider is often reluctant to put tighter restrictions on other agencies to support one agency’s use case and the agency handling the sensitive data must find alternative means for collaboration.

But Microsoft 365’s incredibly robust security and compliance features make it the ideal environment to host and protect these sensitive data types. 

FTI Rules and Regulations

As previously mentioned, FTI data is governed by unique rules and regulations that are enforced by strong punitive measures for non-compliance.

The rules and regulations for managing both physical as well as digital FTI data can be accessed in Publication 1075, “Tax Information Security Guidelines For Federal, State and Local Agencies.”

It’s important to note that it’s a detailed document that provides guidelines for a wide range of modern digital systems—in no part of the document does it limit the use of FTI data to older legacy systems such as secure email.

If combing through the 163 pages sounds a bit daunting, we have summarized what we see as the most relevant requirements for any system managing and storing FTI content. The system must be able to:

• Generate a report of all FTI content in the collaboration environment for audits

• Determine everyone in a department or agency who has had access to FTI content

• Leverage encryption that is FIPS 140-2 compliant for data at rest and in motion

• Manage, monitor and control who has access to FTI content, this frequently includes internal employees, contractors cleared by the IRS, and external taxpayers accessing their own FTI content

• Retain all FTI content and associated activity logs for 7 years

LEGAL DISCLAIMER: The information contained in this publication is provided for informational purposes only, and should not be construed as professional advice on any subject matter. We expressly disclaim all liability for actions taken or not taken based on any content herein. All information is provided “as is”, with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of the information.

Current Common Collaboration Scenarios

So if these restrictions are preventing state agencies from leveraging Microsoft 365 to handle FTI what are they using? The typical workflow we have seen is:

• States access FTI data through a proprietary application, specific to the IRS 

• Any new content developed with information derived from this application becomes classified as FTI content

• FTI content is often stored in network drives (or even personal hard drives!) and shared through secure email . While this is a compliant system, the collaboration with internal and external users is inefficient. Much of this is a result of the limitations of email attachments: co-authoring is prohibited, large files are difficult to send, versioning creates confusion over a single truth and there is no granular permission access.

• Alternative common collaboration methods include cumbersome secure FTP, costly to maintain proprietary systems, and verbal communications.

 Future State

New Possible Collaboration Scenarios

Now let’s take a second to imagine additional, modern collaboration scenarios that can be enabled by Microsoft 365 and Microsoft Teams such as persistent chat in channels, ad-hoc chat, and an underlying enterprise collaboration management system to store and access files.

What would FTI compliant versions of these scenarios look like?

Ongoing Group FTI Discussion

Use Case: Collaboration and real-time chat for a regular series of collaborators around ongoing initiatives and reoccurring tasks.

Tool: A “Confidential” Team in Microsoft Teams

Advantages: Chat, voice and collaboration can be in context with the relevant documents and specific information stored within the Team. Membership is restricted to those who need access.

Process:

1. A monthly “Confidential” Team is requested and provisioned for the working group.
2. The group uses this “Confidential” Team to discuss and share FTI content
3. Any documents uploaded to the Team is tagged and classified as FTI
4. Any conversation in the Team with FTI will be tagged with “#FTI”
5. At the end of the month, the Team will be archived and a new one provisioned

Non-Sensitive Communication

Use Case: An agency employee that also handles FTI information (agency FTI user) needs to communicate and collaborate regarding non-sensitive information.

Tool: “Non-Sensitive” Team in Microsoft Teams

Advantages: The agency FTI user is now able to communicate with other state employees using the tool they are using, which removes information silos. Any sensitive information is caught and contained.

Process:

1. Agency FTI user requests a new Non-Sensitive Team
2. If a Team member uploads a document or shares something in a Team conversation with PII or FTI the system scans the content and creates a security incident.

Use Case: The agency responsible for handling FTI data needs to communicate with an external taxpayer regarding their FTI data.

Tool: “Confidential” Internal Audit Team and “Confidential” External Audit Team in Microsoft Teams

Advantages: Chat, voice and collaboration can be in context with the relevant documents and specific information stored within the Team. Membership is restricted to those who need access, including specific external users.

Process:

1. Audit working group requests a new “Confidential” Internal and External Audit Teams be provisioned
2. FTI information is captured from the tax system of records and copied into a document
3. Document is uploaded into the Internal Team and tagged/classified as FTI 
4. Audit team discusses the audit in the Internal Audit Team conversation using “#FTI”
5. The taxpayer is added to the External Audit Team
6. Audit Team copies appropriate FTI documents from the external team and tags as FTI
7. Document is then uploaded to the External Team and tagged as External Confidential
8. Any conversation with the taxpayer has the “#FTI” tag
9. Once the audit complete, both Teams are archived

Enabling Technologies

The core technologies enabling these modern collaboration scenarios are of course Microsoft 365 and Microsoft Teams. Microsoft 365 has the most robust security and compliance features available of any collaboration platform today.

The Security and Compliance Center allows organizations to confidently identify, classify, manage and protect all types of sensitive content leveraging sensitivity labels.

These features can be extended and configured uniquely for a specific agency using third-party solutions, which you can see in this table mapping FTI requirements to technical solutions.

Advancing Privacy with Zero-Knowledge Proof Credentials

by Scott Muniz | Jul 22, 2020 | Uncategorized

This article is contributed. See the original author and article here.

Hi everyone – I’m excited to have Daniel Buchner discuss an initiative we’ve been working on (in partnership with Microsoft Research) to develop a new Zero-Knowledge Proof scheme that enhances user privacy and security for digital credential systems.

Cheers,

Pamela

——

While decentralized identity standards and technologies can be used in a wide array of use cases, ranging from authentication with Decentralized Identifiers (DIDs) to decentralized apps via DID-encrypted personal datastores, one of the initial use cases many of the decentralized identity ecosystem are focused on is the use of DIDs for Verifiable Credentials (VCs). Credentials are signed assertions from a DID owner (known as ‘Issuers’) to another entity they’re attesting some fact or proof about (known as ‘Subjects’). At the Subject’s election, they can choose to prove the facts contained in a credential by submitting credential proofs to other parties who can independently validate them (known as ‘Verifiers’). These credentials can stand for just about anything, from airplane tickets to diplomas, but the core concept is the same:

1. The Issuer signs a credential for the Subject using the cryptographic keys associated with the Issuer’s DID.
2. The Subject takes possession of Issuer-signed credential and stores it in their DID Wallet for use with Verifiers who may need proof of the facts the Issuer is attesting to.
3. The Subject provides the signed credential, or some derived proof thereof, to a Verifier who validates the credential and uses the data it presents in its evaluation.

Credential use cases pose privacy and personal safety challenges

To understand the issues that arise in common credential use cases, let’s examine a real-life set of scenarios related to work history and job skills:

Publishing a resume on a career networking app is something hundreds of millions of people do every year. This represents an open disclosure of work history the user wants others in the wider business community to be aware of. The expectation of privacy for this information is inherently low, as the user intends for this information to be widely known and verified by all who see it. For this use case, we need a credential mechanism that can verify signed statements by an issuer that are verifiable by observers.

Once a user has shared their career-related credentials, verifiers may need to periodically check the current status of work history credentials (e.g. an employee leaves one job for another). These sorts of status checks on credentials are often programmatically run at intervals, which may occur when the user is not actively engaged in an app, outside of normal waking hours, or when the user is not connected to the internet. This use case underscores the need for a feature that allows verifying parties to check the status of a credential without requiring the user to connect to the site and perform an interactive task.

Similarly, interviewing for a new job can be stressful, and in many cases individuals do so while currently employed. While a user may not care if observers are able to validate the past work history they list on career networking sites, prospective employers often want to validate current employment, which likely includes checking the active status of the current employment credential an applicant presents. If the prospective employer is a competitor of the user’s current employer, any check for active status that alerted the company to their employee’s intentions could cause problems for the applicant. As such, we need a credential scheme that  allows parties to verify active status of a credential without disclosing any information about the credential or its holder to the issuer.

Some credential schemes can expose users to privacy and personal safety risks

Equipped with a general awareness of how DID-based credentials are issued and used, and an understanding of the privacy concerns that arise in real-life credential use cases, it’s important to understand that credentials can come in different forms. Basic credentials are plaintext data objects that include one or more ‘claims’ an Issuer signs using the cryptographic keys linked to their DID. The same credential object is then presented to external parties who can see all the properties and values it contains. Basic credential schemes often incorporate revocation mechanisms where Verifiers ‘phone home’ to Issuers to check the status of a specific Subject’s credential (e.g. is a driver’s license active), providing Subject-identifying data in the process. Other credential schemes utilizing zero-knowledge features avoid some of these issues, but often introduce other tradeoffs, like requiring users to be involved in interactive flows to prove credential status.

The following privacy and tracking issues often arise from these types of credential schemes:

1. Presenting the same credential bytes to multiple verifiers enables them to track its trail of usage. Schemes that try to remedy the presentation of the same credential bytes to multiple Verifiers by fetching unique copies of credentials just-in-time still disclose time of use and other trackable metadata to Issuers.
2. Exposing raw credential values to Verifiers can needlessly expose sensitive information. For example: disclosing a Subject’s specific date of birth can have negative effects, especially when proving their age is greater than a certain threshold would suffice.
3. Status check mechanisms that disclose Subject-identifying information enable Issuers to track how a Subject is using a credential. This is often the case in credential schemes that ‘phone home’ to check on credentials using a credential ID or other specifically identifying data.

There is also a set of desirable features existing credential schemes often lack:

1. Generate uncorrelatable versions of a credential for each Verifier, without contacting the Issuer – a credential scheme should enable a Subject to generate uncorrelatable versions of a credential that doesn’t expose them to tracking by Issuers or Verifiers.
2. Empower Subjects to only disclose the minimum necessary facts – instead of disclosing all the data a credential contains, or precise data values, a scheme should allow Subjects to prove any subset of facts a credential contains, at varying levels of granularity. For example: if a Subject has a credential that contains their exact age, among other things, the Subject should be able to generate a proof that only includes the fact that they over a certain age, without disclosing their date of birth.
3. Enable credential status checks that don’t divulge Subject-identifying information to Issuers – Verifiers should be able to derive the status of a credential without divulging to the Issuer any information about the Subject or specific credential they’re checking.
4. Enable Verifiers to check the status of a credential offline – Verifiers should be able to check the status of credentials based on proofs that can be cached for use when disconnected from the internet.
5. Credential status checks shouldn’t require manual user participation – Subjects should not have to be actively connected to verification systems for Verifiers to check the status of a credential. For example: if a bank needs to run a monthly automated check for the status of a homeowner’s fire insurance policy, and that check runs at odd hours, the homeowner should not have to be involved in any way. (Some schemes require a user to engage software on their device to facilitate status checks for Verifiers, which makes many valid business scenarios infeasible.)

To summarize, existing credential schemes generally exhibit the following profile of issues, which we would like to solve:

Zero-Knowledge Proofs can enhance privacy and personal safety

The privacy and personal safety issues surrounding credential schemes have been known to members of the identity community for decades. Many past initiatives and groups have worked on solutions for these issues (including Microsoft’s U-Prove developments in the late aughts), but until the advent of cryptocurrencies and decentralized identity systems, there was not a pressing business need that required wide-scale deployment of solutions to these problems. In the years since, countless developers, academics, and organizations have been working on new schemes that incorporate a number of advanced cryptographic techniques to overcome the challenges outlined in the sections above. The most promising of these techniques are recent innovations in Zero-Knowledge Proofs cryptographic schemes, or ZKPs for short. ZKP schemes come in many flavors, each with unique trade-offs, features, and performance profiles, which can be tailored to particular use cases and requirements.

As we considered the wide range of scenarios we wanted to tackle, we felt we could make contributions in the area of privacy preserving credentials that could help advance the ecosystem. To that end, we began a joint initiative with our colleagues in Microsoft Research to develop a ZKP credential scheme that accounts for the range of features and use cases we seek to enable (as enumerated in the sections above). The following are notable technical details about the scheme we’ve been working on:

• The scheme is based on a transparent SNARK construction, Spartan (to be presented at the 40^th Annual International Cryptology Conference), that does not require a trusted setup and offers faster prover and verification times than most equivalent schemes, with proof sizes that are smaller (when utilized for this purpose) than all schemes in this family, with the exception of Bulletproofs.
• The scheme supports a range of statement types, including predicate proofs, range checks, set membership, etc.
• For the encoding of zero-knowledge claims, the scheme employs Rank-1 Constraint Satisfiability (R1CS).
• Proving cost scales linearly with the number of R1CS-encoded constraints included in a program.
• Status checks can be proven with the user out-of-band, without requiring Subject interactivity.

From how credentials are issued, all the way through their revocation, we believe this scheme can fulfill the requirements we have laid out and address the issues we’ve identified. In the end, we believe we should be able to overcome the negatives we listed earlier and produce an implementation that exhibits the following profile:

We have contributed the whitepaper detailing our ZKP credential construction to the DIF ZKP credentials initiative, and will begin development of an open source reference implementation in DIF later this summer. We’d like to thank DIF, the wider community, and all those who have been working to advance privacy preserving credential technologies. Please join us in DIF and contribute to this initiative – it’s important that the identity community gets this right, and we need your help to do it.

Daniel Buchner
Decentralized Identity / Microsoft Identity

Image/Icon Credits:

prettycons from www.flaticon.com

Freepik from www.flaticon.com

Becris from www.flaticon.com

Smashicons from www.flaticon.com

Geotatah from www.flaticon.com

Monkik from www.flaticon.com

Darius Dan from www.flaticon.com