Trust Zones will create cross domain issues that reduce overall security posture

[mbellotti]

Thank you for the opportunity to comment on the draft guidance for TIC 3.0. My name is Marianne Bellotti and I'm the Principal Engineer for System Safety at Rebellion Defense. Prior to that I ran the Platform Services teams at the cybersecurity company Auth0. I have worked in the federal government as a member of United States Digital Service (USDS), where my primary responsibilities were rescuing critical systems and advising policy makers at the Office of the Federal CIO (OFCIO). My comments reflect my own views and not those of my current or former employers.

CISA implementation guidance for TIC 3.0 trades problems with choke points for problems with Cross Domain Solutions.
​
As a member of USDS from 2015 to 2019, I personally witnessed how TIC 2.0 created brittle, insecure, and difficult to scale computer systems. While I am pleased to see CISA follow through with its commitment to make TIC 3.0 more agile through use cases and regular updates, CISA's TIC 3.0 vision repeats many of the mistakes that ultimately crippled TIC 2.0.
​
Most critically, TIC 3.0 continues to focus on boundaries. This makes TIC 3.0 backward looking, undermines the initiatives around “Zero Trust” networks elsewhere in government and impedes the progress of other policies (specifically, identity management and CISA's own Continuous Diagnostics and Mitigation) that should be viewed as complementary.
​
CISA inaccurately reflects the foundational principles of Zero Trust networks. Zero Trust networks ignore the network boundary, and focus security on the relationship between the data being accessed and the user doing the accessing. Networks using these principles build up tooling to verify the user's identity across multiple factors, some of which the user supplies themselves (e.g. passwords and one time security tokens), some of which the system passively collects about the users (e.g. the device's registration, IP address location, time of day, etc.).
​
The advantage of embracing this approach is that it leverages federal initiatives that have a track record of success, like Homeland Security Presidential Directive-12 and Personal Identity Verification (PIV), as well as concepts of data security levels that federal employees have been comfortable with for decades.

Low-Medium-High "Trust Zones" are a foreign concepts, poorly defined, and easily conflated and confused with FISMA and FedRAMP standards with similar names. By contrast, federal workers have been comfortable working with the concept of data access levels for decades. Public Trust, Confidential, Secret, Top Secret, even informal determinations like Sensitive But Unclassified (SBU), For Official Use Only (FOUO), Law Enforcement Sensitive (LES), Sensitive Security Information (SSI), Critical Infrastructure Information (CII) are terms that easily translate across agencies. CISA TIC 3.0 guidance should leverage that common language to help agencies define their network security strategy around two questions:

What type of user should have access to this data?
How does the system verify the entity accessing this data is allowed to?
​
CISA's implementation guidance for TIC 3.0 does not consider that while federal networks are progressively distributed across traditional networks, cloud products, and mobile/remote environments, they are ALSO co-owned. Agencies do not do their work on systems that are isolated from employees of other agencies. For example, the majority of users on the State Department's Consular Consolidated Database (CCD) are DHS employees. The missions of most federal agencies require them to share data with one another. None of the documents released by CISA for TIC 3.0 take this reality into account.
​
This isn't just a minor issue. I know from experience engineering interactions between high side and low side domains and HIPAA compliant environments that focusing security controls on the boundaries of the hosting environment, rather than on the protection of the data itself, creates problems with safely sharing data between domains.

In 2012 at the C&ESAR conference in France, Joe Loughry of Oxford University presented a paper entitled Information Asymmetry in Classified Cross Domain System Accreditation that documented how the obligations of multiple agency domain owners to validate security standards of systems that needed to share data across classification level produced information asymmetry that ultimately drove up the costs of evaluating appropriate risk, and encouraged ineffective and redundant testing.
​
And yet: such data sharing is necessary everywhere in government.
​
The TIC 3.0 policy should reflect that IT-savvy workers are not the main users of government computer systems. Good computer security is usually an abstract concept to professionals from other disciplines, and they think nothing of bypassing security controls when those controls interfere with their ability to execute on the agency mission. Given no appropriate way to share data securely between their systems, they email it to each other in clear text. They save it onto physical mediums and pass it through fences. They maintain shockingly old computers (think actual floppy drives) for the purpose of downloading data from one domain and loading it into another. The TIC 3.0 Reference Architecture and Security Capabilities should more seriously consider the challenge of agency networks with different "Trust Zones" interacting by either providing a process for agencies to review how other agencies have defined and accounted for Trust Zones, or by eliminating the concept of Trust Zones altogether.

Historically, agencies have resisted sharing justifications behind similar security determinations--like Authorization to Operate (ATO) and Plan of Action and Milestones (POAM)--with other agencies. CISA should be careful not to underestimate the challenge coordinating across Trust Zones will represent. I would strongly urge CISA to abandon the concept and use TIC 3.0 policy as an opportunity to transition the federal government away from boundary focused security. By leveraging the adoption of PIV/CAC cards, better identity management, and improved device and system inventories, TIC 3.0 could eliminate guerilla data sharing tactics.

Once an attacker is on the network, boundaries and perimeters become useless concepts. CISA should assume that many well-resourced attackers can get onto the network one way or another. The Trusted Internet Connection program needs to abandon its reliance on network perimeters, and move on to a focus on data protections.
​
Less secure approaches are considered High Trust under TIC 3.0
The breakdown of Trust Criteria provided by CISA presumes that because agencies have a higher level of control over a given environment, that the environment is more trustworthy than a managed one.

Specifically, the TIC draft 3.0 guidance incorrectly implies that private data centers inherently provide better security than mature cloud hosting options. Just because an agency’s ownership of a data center gives them the theoretical option of doing things correctly, that does not mean the agency is doing things correctly. OPM's data was kept on an environment that would match CISA’s description of High Trust. In 2013, the VA's CISO testified to Congress that a similar High Trust environment at the VA had been hacked by foreign-sponsored organizations at least 8 times. Having control over the physical environment, significant visibility, and the ability to continuously validate compliance did nothing to prevent these breaches.
​
The decision to own data centers or host through a cloud provider should be primarily a financial one, not a matter of security. Some agencies do operate at a scale that makes maintaining their own data centers the cheaper and more efficient solution, but most do not. It is disheartening to see CISA publish new cybersecurity guidance in 2020 that promotes the false narrative that even poorly maintained and unsupported private data centers are more secure than commercial cloud options. For most agencies, most of the time, commercial cloud hosting will offer a higher security environment,
​
Email should not be an afterthought
Data access control is an especially important issue when you consider that many agencies are moving their email to cloud providers. These email accounts integrate with file sharing and other data storage solutions. None of the security controls CISA proposes for email in its draft guidance reflect this reality. When a government email account is compromised at an agency that uses Office 365 or Google Apps, the attacker then has access to other systems. Even for agencies that do host their own email, an email account is often used as a form of identity and access method for a wide variety of other systems.

The industry best practice is multi-factor authentication, a concept that CISA’s guidance relegates to an example of Strong Authentication instead of a first class security control in its own right. If CISA’s intention with the Strong Authentication capability was to encourage the use of multi-factor authentication, then this section should be revised to make that more explicit. CISA should also consider restating the importance of this control in its section on email for reasons described above.
​
Keep TIC Guidance On Topic
CISA should keep TIC focused on security controls, and avoid tacking on other controls from other areas. While I certainly agree that backups, resilience, and use of shared services are all best practices that should be encouraged, their inclusion in TIC 3.0 will make the program unnecessarily complex and the documentation more difficult to update over time. TIC 2.0 included similar off-topic advice around access to SCIFs, backup power, accessibility, etc. The effect of these unnecessary extras was to limit the scope of solutions that could be said to be “TIC friendly”. Agencies were reluctant to conclude that any control listed in official documentation from DHS was not relevant.
​
CISA should strive for policy documents that are lean and stay on topic. While these extras may be well intended, they make it more difficult to communicate about objectives and establish consensus around what compliance looks like., This extends the life of old methods that we know to be less secure, and results in brittle policy that is difficult to change.
​
TIC 3.0 should not be business as usual
The current drafts contain several sections in which TIC 2.0 and TIC 3.0 are conflated. The historical section of the Program Guidebook switches to the present tense when describing restricting external network connections. Since TIC 3.0 no longer requires this, I hope this is just a typo.
​
Worse, the illustration of a TIC 2.0 system on page 12 of the Reference Architecture (RA) describes External and Internal networks as Low Trust and High Trust zones. These concepts did not exist under TIC 2.0 and incorporating them in this way will encourage CIOs and CISOs to apply TIC 2.0 principles instead of modernizing their security approach to match the distributed shape of their networks.
​
In general, the visuals in the RA fail to convey that the intent of TIC 3.0 was to replace single points of inspection/failure with continuous monitoring across the whole environment. If federal workers use these illustrations as a guide, they are likely to create more choke points that inconvenience legitimate users while letting attackers slip through.

[jakerella]

During my 2.5 years with the United States Digital Service I have had the pleasure of talking with Marianne on a number of technical topics. She is dedicated to helping make technology work better for the American people. I share all of her concerns about about the TIC 3.0 draft guidance and I highly encourage the team responsible for this document to take her comments under strong consideration. The implementation as described will result in less security, not more.

[spoon16]

There is no value in more poorly drafted technology policy.

I am a principal software engineer who has worked for Microsoft and Netflix. From 2016 to 2017 I worked as a Digital Services Expert at USDS.

@mbellotti is an exceptionally talented technologist and her well articulated concerns should be addressed by the team responsible for this document.

[ChaenyE]

I agree with all the comments left by @mbellotti. I had the pleasure of serving with USDS at DHS for a year-and-a-half. I was a web team lead at BIA under DOI for 9 years and at CFPB for 1.5 as well.

The issues with how the TIC was defined caused significant issues with collaboration and applicable data sharing for every effort we tried at the aforementioned agencies.

This inefficiency made it difficult for us to deliver the services that our constituents needed. Now at the state level we still look to Federal guidance to help create the IT security rules to keep our states safe. We are also pushing to have data sharing agreements between departments so that we can have more accurate reporting of our services and the impact on our constituents.

Please move the guidance toward more cloud appropriate "security around the data asset" configurations that will make it easier to deliver the services people need, securely and more easily for practitioners.

Thanks!