Attachment 02 - TIC Ref Arch v2.2 2017.pdf

Trusted Internet Connections (TIC) Reference Architecture Document Version 2.2

Federal Interagency Technical Reference Architectures

June 19, 2017

Federal Network Resilience

TIC Reference Architecture V2.2 i

Revision History

Date Version Description Approved By

4/20/09 1.0 Agency feedback incorporated and released

M.A. Brown, RADM, USN

DAS Cybersecurity &

Communications, DHS

3/24/2011 2.0 Capabilities and architecture updated by the

TIC 2.0 Working Group.

Final version prepared by

DHS.

M. Coose

Director, Federal Network

Security, DHS

9/1/2011 2.0 Final approval by OMB and reference to M-11-11.

M. Coose

Director, Federal Network

Security, DHS

9/16/2013 2.0 Added Appendix H –

Cloud Considerations.

John Streufert

Director, Federal Network

Resilience, DHS

6/9/2017 2.2 Modified Secure communications from

Critical to Recommended

Mark Kneidinger

Director, Federal Network

Resilience, DHS

TIC Reference Architecture V2.2 ii

Table of Contents

ACKNOWLEDGEMENTS

ORIGINAL TIC TECHNICAL ARCHITECTURE STRATEGY TEAM MEMBERS

KEY STAKEHOLDERS

ADVISORS

TIC 2.0 UPDATE PARTICIPANTS

TIC TECHNICAL ARCHITECTURE DOCUMENT TEAM MEMBERS

INTRODUCTION

UPDATES AND CHANGES IN THE TIC 2.0 ARCHITECTURE

SCOPE OF THE DOCUMENT

TIC POLICY REFERENCES

TIC CLARIFICATION

TIC TRUST RELATIONSHIPS

CONCEPTUAL TIC ARCHITECTURE

SECURITY PATTERN FOR EACH CONNECTION CLASS

SECURITY PATTERN #1: EXTERNAL CONNECTIONS

SECURITY PATTERN #2: INTER-AGENCY (INTERNAL PARTNERS) CONNECTIONS

SECURITY PATTERN #3: INTRA-AGENCY (INTERNAL PARTNERS) CONNECTIONS

SECURITY PATTERN #4: TIC SYSTEMS

SECURITY FUNCTIONS, DESCRIPTIONS AND CHARACTERISTICS

SECURITY FUNCTION: PACKET FILTERING

SECURITY FUNCTION: CONTENT FILTERING

SECURITY FUNCTION: PROXY

SECURITY FUNCTION: IDPS

SECURITY FUNCTION: AUTHENTICATION

SECURITY FUNCTION: REMOTE ACCESS

SECURITY FUNCTION: MANAGEMENT

SECURITY FUNCTION: LOGGING

SECURITY FUNCTION: DATA STORAGE

SECURITY FUNCTION: MONITORING

SECURITY FUNCTION: AUDIT

SECURITY FUNCTION: REPORTING

SECURITY FUNCTION: SECURE COMMUNICATIONS

SECURITY FUNCTION: RESPONSE

APPENDICES

APPENDIX A – DEFINITION OF EXTERNAL CONNECTION

APPENDIX B – TIC CAPABILITIES LIST

APPENDIX C – GLOSSARY: COMMON TERMS AND DEFINITIONS

APPENDIX D – ACRONYMS: COMMON ABBREVIATIONS

APPENDIX E – GUIDANCE FOR OCONUS TELEWORK/REMOTE ACCESS CONNECTIONS

APPENDIX F – RECOMMENDATIONS FOR NETWORK TIME PROTOCOLS (NTP)

APPENDIX G – AGENCY DOMAIN NAME SYSTEM (DNS) DEPLOYMENT

APPENDIX H – CLOUD CONSIDERATIONS

APPENDIX I – REFERENCES

TIC Reference Architecture V2.2 iii

Table of Figures

FIGURE 1: CONCEPTUAL MODEL FOR TIC TRUST RELATIONSHIPS

FIGURE 2: CONCEPTUAL TIC ARCHITECTURE

FIGURE 3: TAXONOMY OF A SECURITY PATTERN

FIGURE 4: EXTERNAL CONNECTION SECURITY PATTERN

FIGURE 5: INTER-AGENCY CONNECTION SECURITY PATTERN

FIGURE 6: INTRA-AGENCY CONNECTION SECURITY PATTERN

FIGURE 7: TIC ACCESS POINT FUNCTIONAL BLOCK DIAGRAM

FIGURE 8: TIC SYSTEMS SECURITY PATTERN

FIGURE 9: RELATIONSHIP BETWEEN SECURITY FUNCTIONS AND CONNECTIONS CLASSES

FIGURE 10: CURRENT TIC OCONUS SOLUTION

FIGURE 11: PROPOSED REMOTE ACCESS FOR OCONUS CONNECTIONS SOLUTION

FIGURE 12: GUIDANCE FOR IMPLEMENTING PRIMARY TIME SERVERS

FIGURE 13: DNS ARCHITECTURE

FIGURE 14: D/A UNRESTRICTED-ACCESS DATA

FIGURE 15: D/A RESTRICTED-ACCESS DATA

FIGURE 16: D/A-TO-CSP CONNECTIVITY REQUIREMENTS

FIGURE 17: CSP DATA SEGMENTATION REQUIREMENTS

TIC Reference Architecture V2.2 1

Acknowledgements

This document is the product of ongoing multi-agency collaboration to provide additional guidance for the successful implementation of the Trusted Internet Connections (TIC) Initiative.

A number of agencies have provided resources to support the creation and revision of the TIC

Technical Architecture Document and have made information systems security a priority in their strategic plans. We especially thank the Department of Interior for providing the original template for the document.

This document will be reviewed on an annual basis and will be updated as necessary to incorporate required capabilities and applicable interoperability standards.

Original TIC Technical Architecture Strategy Team Members

Bill Vajda OMB Ed Roback Treasury

Kshemendra Paul OMB David Sczepanski EPA

David Wheelock UCIA Tim Thorpe EPS

Earl Crane DHS Frank Tiller GSA

Alma Cole DHS Brett Moseley NIH

Ken Reynolds DHS Renita Andersen NIH

Mike Kern DHS/US-CERT Scott Cory NIH

Mischel Kwon DHS/US-CERT Mike Milazzo HUD

Brian Done DHS Porter Davis HUD

Dennis Ruff DISA Don Sheehan VA

Damian Hayes DISA Brian Campbell VA

David Sacha DISA Eric Won GSA

John Unekis NOAA Betsy Edwards NASA

Bernie Werwinski NOAA Jerry Davis NASA

Jeff Bugler DISA Ken White NASA

Paul Filios DISA Andrew Good OPM

Tony Bailey DOE James Berry OPM

Jim Sledge DOE Joseph Song OPM

David Elliott EDU Hung Dinh SEC

Harry Feely EDU Evan Trebing SEC

James Albin EDU Bhupinder Singh SEC

Leland Dudek DOI Brad Tesh Smithsonian

Stu Mitchell DOI Bruce Daniels Smithsonian

Matt Raymer DOJ Bob Nicholson SSA

Nathan Rickman DOJ Gerry Barsczewski SSA

Robert Martin DOJ Jack Leipold SSA

Jacob D. (Danny) Toler DOS John Donovan USDA

Sara Nasseh-Mosley DOS Bill Flowers USDA

Douglas Roseboro FAA Chuck Christopherson USDA

Rick Swartz Treasury Dan Crosson USDA

Timothy Clinton Treasury Steve Wilson USDA

Ranny Reynolds Treasury Everett Dowd DOT

Key Stakeholders

Office of Management and Budget (OMB), Office of E-Government and Information

Technology

TIC Reference Architecture V2.2 2

Federal Chief Information Office (CIO) Council

Federal Small Agency CIO Council

Department of Homeland Security (DHS) National Cyber Security Division (NCSD)

Federal Systems Security Governance Board (FSSGB)

DHS Information Systems Security Line of Business (ISS LoB)

DHS United States Computer Emergency Readiness Team (US-CERT)

General Services Administration (GSA) Information Technology Infrastructure Line of

Business (ITI LoB)

All Federal Executive civilian agencies

Advisors

Alan Paller, Director of Research, SANS Institute

Scott Bradner, Technology Security Officer, Harvard University

TIC 2.0 Update Participants

In FY2010, TIC Access Provider (TICAP) representatives from across the Federal government participated in the TIC 2.0 Working Group to provide updates to this architecture document.

Sean Donelan DHS TIC PMO David Elliott EDU

Marilyn Rose DHS TIC PMO Stephen Luhan FBI

Samuel Vazquez DHS TIC PMO Harry Trebing SEC

Matt Coose DHS Evan Trebing SEC

Donald Benack DHS John Heppler SEC

Blake Nguyen DHS Dave Wilson SEC

Kara McKenzie DHS Bhupinder Singh SEC

Alma Cole DHS Gerry Barsczewskie SSA

Brian Done DHS Sean Connelly State

Keith Trippie DHS Ranny Reynolds Treasury

Jack Burriesci DHS Tom Tran IRS

Earl Crane ISIMC NISSC James Maginnis VA

John Migliaccio GSA Don Sheehan VA

Olga Aparicio GSA Georgia Killcrece SEI

William Lakner DOL Russell Griffin SEI

Rana Faisal DOL Rob Moore TIC PMO

Stu Mitchell DOI Neil Paine TIC PMO

Martha Pogue DOT Mike Robinson TIC PMO

Chuck Eng DOT/FAA

TIC Technical Architecture Document Team Members

SRA/Touchstone Consulting Group

The Software Engineering Institute

Blue Glacier Management Group

The MITRE Corporation

TIC Reference Architecture V2.2 3

Introduction

The overall purpose of the Trusted Internet Connection (TIC) Initiative, as outlined in OMB

Memorandum M-08-05, is to optimize and standardize the security of individual external network connections currently in use by the Federal Government, to include connections to the internet. The initiative will improve the Federal Government’s security posture and incident response capability through the reduction and consolidation of external connections and provide enhanced monitoring and situational awareness of external network connections.

Updates and Changes in the TIC 2.0 Architecture

Several new sections and appendices have been added in this version of the TIC Architecture.

They include an update of applicable TIC policy references, additional guidance for securing remote access connections, a clarification of agency responsibilities for securing inter-agency and intra-agency connections, recommendations for network time protocols, and guidance for agency Domain Name System (DNS) deployment. Appendices for glossary and acronyms have also been added to help in clarifying language within the document.

One of the most important updates to the TIC Architecture is a refresh of the TIC Critical

Capabilities for securing TIC access points. The purpose of this update was to enhance the security posture of federal departments and agencies by defining more robust network security defense capabilities by updating, clarifying, adding and removing capabilities as deemed necessary. Recommendations and comments from various agencies and security groups are incorporated into this document and are presented in the revised capability list in Appendix B.

Scope of the Document

The TIC Architecture document is intended as a reference to provide insight and guidance for

Departments/Agencies (D/As) striving to comply with the requirements of the TIC Initiative.

The TIC Architecture document was developed by the TIC 2.0 Working Group. The team consisted of representatives from a diverse group of agencies in order to define end user technical needs and to select approaches to meet those needs. The document is descriptive in nature, recognizing that many organizations face unique challenges that do not lend themselves to “one size fits all” solutions. The document does not prescribe specific solutions. Its intent is to enable agencies to leverage existing capabilities in order to achieve the overall objectives of the TIC Initiative.

This document is applicable to all Federal civilian agencies, but particularly to TIC Access

Providers (TICAPs). A TICAP is the entity responsible for managing a TIC access point’s physical location and corresponding security capabilities. Single Service TICAPs serve as a TIC

Access Provider only to themselves. Multi-Service TICAPs provide TIC services to other agencies through a shared services model.

All other Federal civilian agencies are designated as “Seeking Service” and must acquire TIC services from an approved Multi-Service TICAP. Most Seeking Service Agencies will procure

TIC services through a third party provider such as the GSA NETWORX contract vehicle.

TIC Reference Architecture V2.2 4

Participation and cooperation between the National Cyber Protection Program (NCPP) and the

TIC Initiative is necessary to ensure all external connections are monitored by a National Cyber

Protection System (NCPS) sensor, operationally known as EINSTEIN. NCPP is a distinct program with its own set of requirements, which are not repeated in this document. A TICAP is responsible for interconnection with NCPS components according to the terms and conditions outlined in the memorandum of agreement, interconnection security agreement and service level agreement between the TICAP and US-CERT.

The information in this document is based upon the definitions and requirements in the Federal

Information Systems Management Act (FISMA), National Institute of Standards and Technology

(NIST) guidance and standards, and Office of Management and Budget (OMB) memoranda.

TIC Policy References

The Trusted Internet Connections (TIC) Initiative is derived from the National Security

Presidential Directive 54 and Homeland Security Presidential Directive 23. The TIC Initiative is the first of twelve initiatives in the President’s Comprehensive National Cybersecurity Initiative

(CNCI). The following OMB Memoranda have been published to help agencies comply with the

TIC Initiative1:

OMB M-08-05: Implementation of Trusted Internet Connections (TIC)

OMB M-08-16: Guidance for Trusted Internet Connection Statement of Capability (SOC)

Form

OMB M-08-26: Transition from FTS2001 to NETWORX

OMB M-08-27: Guidance for Trusted Internet Connection (TIC) Compliance

OMB M-09-32: Update on the Trusted Internet Connections Initiative

A comprehensive list of applicable legislation, policies, directives, regulations, memoranda, standards, and guidelines can be found in Appendix I.

1 The OMB memos can be found at the following link: http://www.whitehouse.gov/omb/memoranda/ http://www.whitehouse.gov/omb/memoranda/

TIC Reference Architecture V2.2 5

TIC Clarification

The term “TIC” is used throughout the Federal Government to denote different aspects of the

TIC Architecture; including the overall TIC initiative, a physical TIC access point and a TIC

Access Provider. In order to avoid confusion, this document will minimize use of the term

“TIC” to describe the machinery of the TIC Architecture. “Appendix C – Glossary: Common

Terms and Definitions” and “Appendix D – Acronyms: Common Abbreviations” can be referenced in the Appendices of this document to help clarify content.

TIC Trust Relationships

Conceptually, the TIC Architecture is organized around three zones of trust: an external zone, a

TIC Zone, and a D/A Internal Zone. Although there are generally more security zones within a

D/A network, this document conceptually simplifies the zones associated with network connections.

Figure 1 depicts the target TIC Trust Relationships and is intended to articulate two points. First, the amount of control an agency has over the environment decreases as traffic flows away from the Internal Zone toward the External Zone. Second, as the agency’s level of control decreases, the level of trust an agency places on the relationship between the two entities exchanging traffic also decreases.

Figure 1: Conceptual Model for TIC Trust Relationships

TIC Zone D/A Internal Zone

D/A Systems & Devices

Applications, Data and Servers

Internal D/A Networks

(LAN/MAN/WAN)

Unless Exempted HTTP/HTTPS connections to external systems only allowed via Web Proxy

External Zone

External Systems & Services

Data Flow Policy

MSP, ASP, Business Partners, Other Federal Agencies

VPN

Less Control More Control

D e n y

A ll o wDefault Deny

Default Deny

D/A Remote Agency Sites

D/A Systems

App & Data Servers

SMTP

External Users

Inbound Proxies

Public Services

EINSTEIN

Recommended Intra-zone Data Flow Policy

Recommended Inter-zone Data Flow Policy

Antivirus

Data Filtering

Outbound Proxies

Data Filtering

INTERNET

3G

EXTRANET

WiFi

D/A WAN

EINSTEIN

Remote Connections`

RGFE

Remote Government Furnished EquipmentRGFE:

TIC Remote Access Only Zone

Encrypted Traffic`

Employee/Contractor Only

VPN

Concentrator

Virtual Desktop

IDS/IPS

Two-Factor

Authentication

Data Filtering

Access Restricted to Approved App & Data

Servers

Default Deny

Default Deny

Configuration Check

External Connection Termination Point

Monitored by EINSTEIN

Network Connections & Data Filtered

Full Packet Capture & Storage

TIC Reference Architecture V2.2 6

External Zone: Information systems or components of information systems that are outside of the accreditation boundary established by the organization and over which the organization typically has no direct control for the application of required security controls or the assessment of security control effectiveness.

Internal Zone: Information systems or components of information systems that are within the accreditation boundary established by the organization and for which the organization typically has direct control for the application of required security controls or the assessment of security control effectiveness.

TIC Zone: Border between an organization’s internal infrastructure (users, systems, data) and external resources. Serves as the termination point for external connections and utilizes a standard set of security controls to monitor, authenticate, and filter data flows that enter/exit the TIC access point.

Each zone (External, Internal, and TIC Zone) requires specific security functions applied to the systems and networks in order to provide specific security capabilities. When designing and implementing secure and trusted connections, agencies should consider all of the controls mentioned in the TIC Taxonomy and Associated Security Patterns Section. The security patterns described in this document define level of trust criteria for different connection classes, and therefore guide application of specific security functions and capabilities.

TIC Reference Architecture V2.2 7

Conceptual TIC Architecture

Figure 2 depicts the conceptual TIC Architecture. The graphic illustrates three different models that Federal civilian agencies may employ to reduce and consolidate their external network traffic via a secure and trusted connection: (1) Agency Multi-Service TICAP, (2) Agency Single

Service TICAP and (3) Managed Trusted IP Service (MTIPS) TICAP (via approved NETWORX

Vendor).

Figure 2: Conceptual TIC Architecture

Seeking Service Agency

Seeking Service Agency

Seeking Service Agency

NETWORX

TIC

Seeking Service Agency

TIC #1

G2G Internal Federal Connection

IDS FW

External Systems

Remote Government Furnished Equipment

Remote

Connections e.g. VPN

Business Partners

TIC #2 E

E

MULTI-SERVICE TICAP

TIC #1

IDSFW

TIC #2E

E

SINGLE SERVICE TICAP

ISP A

InterTIC & InterAgency Traffic Intra-Agency Traffic TIC Client TrafficExternal Traffic

Remote Government Furnished Equipment

Remote

Connections e.g. VPN

E

Remote

Connectio n

E.g. V

PN

MTIPS TICAP

ISP B

ISP C

The Architecture classifies all agency network connections according to four connection classes:

External, Inter-Agency, Intra-Agency, and TIC System. Regardless of the agency’s reduction and consolidation model, note how all external connections are secured through a TIC access point. The connection classes are explained in further detail in the next section of this document, TIC Taxonomy and Associated Security Patterns.

TIC Reference Architecture V2.2 8

Security Pattern for each Connection Class

Each of the four connection classes in Figure 2 requires a unique security pattern in order to build a necessary level of trust between connections. Each security pattern consists of specific security functions, capabilities, guidelines, and characteristics. The patterns describe collections of systems operating under a common security policy (i.e., same level of security) and the same security functions may span multiple security patterns. Figure 3 illustrates the Taxonomy of a

Security Pattern; specifically the relationship between a Connection Class, the Security

Functions necessary to support that Connection Class, and the resulting TIC Capabilities attained when those Security Functions are met.

Figure 3: Taxonomy of a Security Pattern

Connection

Class

Security

Function

Security

Function

Security

Function

Security

Function

TIC Capabilities, Guidelines and Characteristics

The taxonomy of a security pattern consists of three major components:

Connection Class: A telecommunications class or pattern for data/information flow into and out of D/A information systems, networks, or components of information systems and networks. As demonstrated in Figure 2, the four Connection Classes are: External, Inter-Agency, Intra-Agency, and TIC-System. Each connection class requires a unique security pattern in order to build a necessary level of trust.

Security Function: The operations that must be performed and functionalities that must be provided in order to secure a connection class. TICAPs are responsible for managing these security functions by meeting the appropriate TIC Capabilities outlined in

Appendix B. Security Functions are explained in more detail in the next section of this document, Security Functions, Descriptions and Characteristics.

TIC Capabilities: The tasks, configurations, requirements and specifications that must be delivered to provide specific security function(s). Many capabilities may contribute to the performance of multiple security functions. Appendix B provides a complete list of the TIC Capabilities and correlates each capability to its associated Security Function.

Each capability is categorized as Critical or Recommended. All Critical capabilities must be satisfied to be compliant with the TIC Architecture. Recommended capabilities are best practice guidelines, and while not currently required for compliance, are strongly suggested as best practices. Appendix B contains the complete list of TIC Capabilities.

TIC Reference Architecture V2.2 9

Security Pattern #1: External Connections

External Connection Class Definition: A physical or logical connection between information systems, networks, or components of information systems and networks in which one is inside and the other outside of the specific Certification and Accreditation (C&A) boundaries established by the D/A, where:

(a) The D/A does not have control over the application of required security controls or the assessment of security control effectiveness on the outside information system, network, or components of information systems or networks; or

(b) The D/A, notwithstanding control over the application of required security controls or the assessment of security control effectiveness, has specific reason to believe that the external system has a substantially reduced set of security controls or an increased threat posture relative to the internal system; or

(c) The connection could be used to establish a connection with an external system that is not routed through an approved TIC.

Further clarification is available in Appendix A, which provides the OMB-approved “Definition of External Connection.”

Corresponding Security Functions: Each TICAP must demonstrate that external connections are secured by a TIC access point providing four specific security functions:

a. Packet Filtering (Critical)

b. Content Filtering (Critical)

c. Proxy (Critical)

d. Intrusion Detection and Prevention System (IDPS) (Critical)

Figure 4 below indicates the four security functions that are associated with the External

Connections security pattern. NCPS Monitoring is highlighted to indicate that agencies must participate in and work with the NCPP to ensure all external connections are monitored by an

NCPS device.

TIC Reference Architecture V2.2 10

Figure 4: External Connection Security Pattern

National

Cyber

Protection

System

External Networks & Systems

TIC

D/A 1 Internal Networks & Systems D/A 2 Internal Networks & Systems

Proxy

Remote

Connections

(e.g. VPN)

IDPS

Content Filtering

Packet Filtering

[G2G]

Systems

Security Operations Center (SOC)

Functions

Staff

NCPS Monitoring

Logging

Monitoring

Audit

Reporting Data Sorage

Secure Comms

Management Response

Authentication

Remote

Government

Equipment &

Sites

Inter-Agency Traffic Intra-Agency Traffic TIC Client TrafficExternal Traffic

External

Connections

O th e r T ra ff ic

S

M T

P T ra ff ic

H

T T

P (S

T ra ff ic

Security Pattern #2: Inter-Agency (Internal Partners) Connections

Inter-Agency Connection Class Definition: Connections that allow for the flow of network traffic between D/As in support of mission objectives and business operations.

Interconnections among D/As may be considered "internal connections" when all D/As involved in the interconnect are fully behind TIC access points and the following four criteria are met:

All of the D/As’ external connections route through a TIC access point

All of the D/As’ other connections (Intra-Agency, Inter-Agency) are consistent with the definition of an external connection in sections (4.1) and (4.2) in Appendix A

All D/As perform packet screening to ensure that only authorized traffic is permitted to flow between the interconnected D/As

All D/As maintain the ability to suspend/temporarily deactivate the connection in the event that suspicious activity is detected

It is also recommended that all D/As monitor the connection at the point of ingress into their

C&A boundary using the following security functions: content filtering, IDPS, and authentication.

TIC Reference Architecture V2.2 11

In an instance where there is reasonable doubt as to whether a connection is “internal” or

“external”, the traffic must be considered “external” and routed through a TIC access point.

Additional guidance for managing risk of information systems, including consideration factors agencies should employ when establishing direct control, is further articulated in Appendix A.

Corresponding Security Functions: Federal civilian agencies secure their inter-agency connections with the following security functions:

a. Packet Filtering (Critical)

b. Content Filtering (Recommended)

c. IDPS (Recommended)

d. Authentication (Recommended)

Figure 5 below indicates the four security capabilities that are associated with the Inter-Agency

Connections security pattern.

Figure 5: Inter-Agency Connection Security Pattern

National

Cyber

Protection

System

External Networks & Systems

TIC

D/A 1 Internal Networks & Systems D/A 2 Internal Networks & Systems

Remote

Connections

(e.g. VPN)

IDPS

Packet Filtering

Systems

Security Operations Center (SOC)

Functions

Staff

NCPS Monitoring

Logging

Monitoring

Audit

Reporting Data Sorage

Secure Comms

Management Response

Authentication

Remote

Government

Equipment &

Sites

Inter-Agency Traffic Intra-Agency Traffic TIC Client TrafficExternal Traffic

G-2-G

Connections

O th e r T ra ff ic

S

M T

P T ra ff ic

H

T T

P (S

T ra ff ic

Content Filtering

Proxy

[G2G]

TIC Reference Architecture V2.2 12

Security Pattern #3: Intra-Agency (Internal Partners) Connections

Intra-Agency Connection Class Definition: Secure connections that link D/A systems, networks, or components to the D/A enterprise. These resources reside outside of the enterprise security perimeter but become part of the enterprise security perimeter via required security services such as authentication and virtual private network (VPN). Since these resources are considered a logical extension of the internal network, these types of connections are also referred to as

“internal connections.” Further clarification about the distinction between External connections and Intra-Agency connections can be found in Appendix A.

Connections which meet the following criteria can be classified as Intra-Agency connections and will NOT typically be considered “external connections”. As a result, they would not be required to route through a TIC access point, though may do so at the D/A’s discretion:

Dedicated secure point-to-point connections that link information systems, networks, or components of information and systems and networks of a single D/A under a single certification and accreditation authority, provided that the connections do not access the globally-addressable internet

Connections established through VPN technology utilizing security controls that at a minimum are compliant with FIPS 140-2 and NIST 800-53 and are audited and monitored by the D/A

Corresponding Security Functions: Federal civilian agencies secure their Intra-Agency connections with the following security functions:

a. Packet Filtering (Critical)

b. IDPS (Recommended)

c. Authentication (Recommended)

Further details regarding Remote Access connections can be found in Appendix E – Guidance for Remote Access Connections.

Figure 6 depicts the three security capabilities that are associated with the Intra-Agency

TIC Reference Architecture V2.2 13

Figure 6: Intra-Agency Connection Security Pattern

National

Cyber

Protection

System

External Networks & Systems

TIC

D/A 1 Internal Networks & Systems D/A 2 Internal Networks & Systems

IDPS

Packet Filtering

Systems

Security Operations Center (SOC)

Functions

Staff

NCPS Monitoring

Logging

Monitoring

Audit

Reporting Data Sorage

Secure Comms

Management Response

Authentication

Remote

Government

Equipment & Sites

Inter-Agency Traffic Intra-Agency Traffic TIC Client TrafficExternal Traffic

Remote Connections

O th e r T ra ff ic

S

M T

P T ra ff ic

H

T T

P (S

T ra ff ic

Content Filtering

Proxy

[G2G]

Remote

Connections

(e.g. VPN)

Security Pattern #4: TIC Systems

TIC System Connection Class Definition: TIC systems are components and services that support the overall security operations and policies of the TIC access point, including components that collect, normalize, and analyze log data as well as those involved in incident response and reporting. This includes overall management of TIC components as well as capabilities associated with managing a Security Operations Center (SOC), and a Network Operations Center

(NOC). Periodic validation of TIC operations and security posture is required.

The Functional Block diagram (Figure 7) is intended to show the relationship between the components and systems that exist at a TIC access point. All functions and services contained in this diagram are included as Critical TIC Capabilities and are elaborated in more detail in

Appendix B. This graphic is not intended to be an engineering schematic but rather an illustration of the components and services included in a TIC system.

TIC Reference Architecture V2.2 14

Figure 7: TIC Access Point Functional Block Diagram2

ICD 705 (DCID6/9)

Physical Controls

NIST 800-53 MEDIUM

Physical Controls

NIST 800-53 HIGH

Physical Controls

Infiltration Controls for

External Services

(DMZ/Inbound)

Exfiltration Controls for Internal Services

(DMZ/Outbound)

TIC Operator

Workstations

Secure

Response

Channel

National Cyber

Protection System

(EINSTEIN)

Prepared By:

Federal Network Security

US Dept of Homeland Security

Last Updated: January 20, 2011

Access Controls for

Telework

Connections

Access Controls for

Dedicated External

Connections

SCIF

TIC Operations Center

(NOC/SOC)

TIC Access Point

Access Controls for

Dedicated Internal

Connections

TIC Management

Systems

30 Min max

TIC Hosted

Application Services

Extended Access

Service

* Refer to TIC Reference Architecture, Appendix A, “Definition of External

Connection”

* External Networks

(public, semi-public and private networks, including the Internet)

* External Partners

(non-TIC agencies, mission partners)

* Internal Partners

(TIC agencies, mission partners with closed networks)

* Internal Networks

(Agency LAN/WAN including closed inter-office VPNs)

* Specialized Access Networks

(Not connected to Internal Networks)

Telework Users

(VPN or Virtual Desktop remote access)

Unrestricted Access Services

(No, or very low, Content Access

Restrictions)

Corresponding Security Functions: Securing a TIC system depends on a D/A’s ability to provide a mix of management and security operations functions. Security capabilities for TIC systems protect the TIC layer itself and specify monitoring, logging and reporting capabilities that the TIC access point must provide. Each TICAP must demonstrate that TIC systems and components meet the following security functions:

a. Management

i. Physical Controls

ii. TIC Configuration

iii. Authentication

b. Remote Access

c. Secure Communications

d. Data Storage

e. Logging

f. Response

g. Monitoring

h. Audit

i. Reporting

2 Many of the terms and acronyms used in Figure 7 are defined in Appendix C or spelled out in Appendix D.

TIC Reference Architecture V2.2 15

Figure 8 depicts the management and security capabilities that are associated with TIC system

Figure 8: TIC Systems Security Pattern

National

Cyber

Protection

System

External Networks & Systems

TIC

D/A 1 Internal Networks & Systems D/A 2 Internal Networks & Systems

Proxy

Remote

Connections

(e.g. VPN)

IDPS

Content Filtering

Packet Filtering

[G2G]

Security Operations Center (SOC)

Functions

NCPS Monitoring

Logging

Monitoring

Audit

Reporting Data Sorage

Secure Comms

Management Response

Authentication

Remote

Government

Equipment &

Sites

Inter-Agency Traffic Intra-Agency Traffic TIC Client TrafficExternal Traffic

TIC Systems

O th e r T ra ff ic

S

M T

P T ra ff ic

H

T T

P (S

T ra ff ic

Systems Staff

TIC Reference Architecture V2.2 16

Security Functions, Descriptions and Characteristics

Based upon the concepts developed in previous sections, this section provides a brief description of each security capability for future reference. Selected applicable characteristics associated with each capability are listed in the tables below the respective heading. These characteristics are not new requirements, but highlights of existing NIST guidance and standards set forth in

NIST Special Publication 800-53, 800-53A and subsequent publications, federal laws, standards and guidelines.

When securing external connections, the first four security functions are mandatory and are performed “by the TIC access point.” For Inter-Agency and Intra-Agency connections, these security functions are recommended, but would not be required to route through a TIC access point. The last 10 security functions all relate to securing the TIC systems and components themselves. These functions are performed “on the TIC access point.” The mandatory security functions below can be traced to one or more TIC Critical Capabilities in Appendix B.

Figure 9: Relationship Between Security Functions and Connections Classes

Security Pattern

External

Connections

Inter-Agency

Connections

Intra-Agency

Connections

TIC

Systems

S ec u ri ty F u n ct io n s

Packet Filtering M M M

Content Filtering M R

Proxy M

IDPS M R R

Authentication R R M

Remote Access M

Management M

Logging M

Data Storage M

Monitoring M

Audit M

Reporting M

Secure

Communications

M

Response M

M= Mandatory Security Function R= Recommended Security Function

TIC Reference Architecture V2.2 17

Security Function: Packet Filtering

a) NIST Guidance:

Packet Filter: Firewalls that are only packet filters - also known as stateless inspection firewalls

- are essentially routing devices that provide access control functionality for host addresses and communication sessions. Unlike more advanced filters, packet filters are not concerned about the content of packets. Their access control functionality is governed by a set of directives referred to as a rule set. Packet filtering capabilities are built into most operating systems and devices capable of routing; the most common example of a pure packet filtering device is a network router that employs access control lists (NIST 800-41 rev1).

Stateful Inspection: Stateful inspection improves on the functions of packet filters by tracking the state of connections and blocking packets that deviate from the expected state. This is accomplished by incorporating greater awareness of the transport layer. As with packet filtering, stateful inspection intercepts packets at the network layer and inspects them to see if they are permitted by an existing firewall rule. Unlike packet filtering, stateful inspection keeps track of each connection in a state table. While the details of state table entries vary by firewall product, they typically include source IP address, destination IP address, port numbers, and connection state information.

Three major states exist for Transmission Control Protocol (TCP) traffic - connection establishment, usage, and termination (which refers to both an endpoint requesting that a connection be closed and a connection with a long period of inactivity). Stateful inspection in a firewall examines certain values in the TCP headers to monitor the state of each connection.

Each new packet is compared by the firewall to the firewall’s state table to determine if the packet’s state contradicts its expected state. For example, an attacker could generate a packet with a header indicating it is part of an established connection, in hopes it will pass through a firewall. If the firewall uses stateful inspection, it will first verify that the packet is part of an established connection listed in the state table (NIST 800-41 rev1).

Deep Packet Inspection: A newer trend in stateful inspection is the addition of a stateful protocol analysis capability, referred to by some vendors as deep packet inspection. Stateful protocol analysis improves upon standard stateful inspection through adding basic intrusion detection technology - an inspection engine that analyzes protocols at the application layer to compare vendor-developed profiles of benign protocol activity against observed events to identify deviations. This enables the identification of unexpected sequences of commands, such as issuing the same command repeatedly or issuing a command that was not preceded by another command on which it is dependent. These suspicious commands often originate from buffer overflow attacks, denial of service (DoS) attacks, malware, and other forms of attack carried out within application protocols such as Hypertext Transfer Protocol (HTTP). Another common feature is input validation for individual commands, such as minimum and maximum lengths for arguments. For example, a username argument with a length of 1000 characters is suspicious -even more so if it contains binary data (NIST 800-41 rev1).

TIC Reference Architecture V2.2 18

b) Selected Packet Filtering Characteristics:

Common Characteristics Source

Firewall policies should only permit appropriate source and destination IP addresses to be used.

SP 800-41 Rev

1 (paragraph

4.1.1)

Traffic with invalid source or destination addresses should always be blocked.

SP 800-41 Rev

1 (paragraph

4.1.1)

Traffic with an invalid source address for incoming traffic or destination address for outgoing traffic (an “external” address) should be blocked at the network perimeter.

SP 800-41 Rev

1 (paragraph

4.1.1)

Traffic with a private destination address for incoming traffic or source address for outgoing traffic (an “internal” address) should be blocked at the network perimeter.

SP 800-41 Rev

1 (paragraph

4.1.1)

Incoming traffic with a destination address of the Packet Filtering device should be blocked unless the firewall is offering services for incoming traffic that require direct connections - for example, if the firewall is acting as a proxy.

SP 800-41 Rev

1 (paragraph

4.1.1)

Organizations should also block traffic containing IP source routing information, which allows a system to specify the routes that packets will employ while traveling from source to destination.

SP 800-41 Rev

1 (paragraph

4.1.1)

Organizations should also block traffic containing directed broadcast addresses, which are broadcast addresses that are not in the same subnet as the originator.

SP 800-41 Rev

1 (paragraph

4.1.1)

The Packet Filtering device should be able to use IPv6 addresses in all filtering rules that use IPv4 addresses.

SP 800-41 Rev

1 (paragraph

4.1.2)

The administrative interface should allow administrators to clone

IPv4 rules to IPv6 addresses to make administration easier.

SP 800-41 Rev

1 (paragraph

4.1.2)

If the layer 3-5 device can filter based on DNS lookup of domain names, it needs to use AAAA (IPv6 address records) records in the same way as A records (those used for IPv4 addresses).

SP 800-41 Rev

1 (paragraph

4.1.2)

The Packet Filtering device needs to be able to filter ICMPv6, as specified in RFC 4890, Recommendations for Filtering ICMPv6

Messages in Firewalls.

SP 800-41 Rev

1 (paragraph

4.1.2)

SSL VPN devices should be configured so they log sufficient details regarding successful and failed login attempts to support troubleshooting and incident response activities.

SP 800-113

(Section 4.3.6)

TIC Reference Architecture V2.2 19

Security Function: Content Filtering

Content filtering is the process of monitoring communications such as email and Web pages, analyzing them for suspicious content, and preventing the delivery of suspicious content to users.

Two common types of content filtering are spam filtering software and Web content filtering software (NIST SP800-114).

Spam – unsolicited email – is often used to deliver spyware and other forms of malware to users

(NIST SP800-114).

Web content filtering software typically works by comparing a Web site address that a user attempts to access with a list of known bad Web sites (NIST 800-114).

b) Selected Content Filtering Characteristics:

Content filtering should be done as close to the content receiver as possible.

SP 800-41 Rev 1

Section 5.2.2

All content filtering products that are used should be kept up-to-date to ensure that their detection is as accurate as possible.

SP 800-114 Section

5.4.3

In general, rules are defined to forward, quarantine, park, clean, block, or delete any data passing through the server depending upon the results of the scan. Typical items that would be caught by the filter and possible actions taken on them could be as follows:

a) Email that contains suspicious active content (e.g., ActiveX, JavaScript) is stripped of the active code and forwarded to the recipient.

b) Spam email and phishing attempts may be deleted or tagged as suspicious.

c) Extra-large files might be held for delivery during off-peak hours.

SP 800-45 Version 2

Section 6.2.2.1

Another key feature of content filtering packages is the scanning of outbound data. A lexical analysis can be performed that scans email messages for words and phrases that might be viewed as inappropriate for use in organizational email.

SP 800-45 Version 2

Section 6.2.2.1

TIC Reference Architecture V2.2 20

For maximum effectiveness, content filtering should be performed on all incoming and outgoing messages and conducted in the same locations as malware scanning - on the firewall/mail relay/mail gateway, mail servers, and end users’ hosts.

SP 800-45 Version 2

Section 6.2.2.1

Security Function: Proxy

Proxy: A proxy is an information system that “breaks” the connection between client and server.

The proxy accepts certain types of traffic entering or leaving a network, processes it, and forwards it. This effectively closes the straight path between the internal and external networks, making it more difficult for an attacker to obtain internal IP addresses and other details of the organization’s internal network. Proxy servers are available for common Internet services; for example, a Hypertext Transfer Protocol (HTTP) proxy used for Web access and a Simple Mail

Transfer Protocol (SMTP) proxy used for e-mail (NIST 800-44 Ver2).

Other definitions include:

A server that sits between a client information system, such as a web browser, and a real server. It intercepts all requests to the real server to see if it can fulfill the requests itself. If not, it forwards the request to the real server; or

An agent that acts on behalf of a requester to relay a message between a requester agent and a provider agent.

b) Selected Proxy Characteristics:

When a proxy is used, each successful connection attempt actually results in the creation of two separate connections.

SP 800-94

The proxy may reject client requests that appear to be invalid (which could include some forms of attacks) and log information regarding these requests.

SP 800-94

HTTP proxies should be configured on the firewall to block all inbound scripts and Java applications.

TIC 2.0 WG,

FY2010

Security Function: IDPS

Intrusion Detection: Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of potential incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices (NIST 800-94).

TIC Reference Architecture V2.2 21

Intrusion Prevention: Intrusion prevention is the process of performing intrusion detection and attempting to stop detected potential incidents. Intrusion Detection and Prevention Systems

(IDPSs) are primarily focused on identifying potential incidents, logging information about them, attempting to stop them, and reporting them to security administrators. In addition, organizations use IDPSs for other purposes, such as identifying problems with security policies, documenting existing threats, and deterring individuals from violating security policies. IDPS technology has become a necessary addition to the security infrastructure of nearly every organization (NIST 800-94).

b) Selected IDPS Characteristics:

Detects attacks and other security violations that are not prevented by other security measures by monitoring and analyzing events to identify undesirable activity.

SP 800-94

Recording information related to observed events.

Information is usually recorded locally, and might also be sent to separate systems such as centralized logging servers, security information and event management (SIEM) solutions, and enterprise management systems.

SP 800-94

Notifying security administrators of important observed events. This notification, known as an alert, occurs through any of several methods, including the following: e-mails, pages, messages on the IDPS user interface, Simple

Network Management Protocol (SNMP) traps, syslog messages, and user-defined programs and scripts. A notification message typically includes only basic information regarding an event; administrators need to access the IDPS for additional information.

SP 800-94

Producing reports. Reports summarize the monitored events or provide details on particular events of interest.

SP 800-94

Detects a wide range of network attacks, including pings/port scans, login attempts, viruses, backdoor, buffer overflows and other types of exploits.

SANS Institute -

Combining IDPS &

Vulnerability

Management

Provides reports and logs suspected events for review and analysis after the fact.

SANS Institute -

Combining IDPS &

Vulnerability

Management

Intrusion Prevention Systems must build on Intrusion

Detection System functionality by adding the ability to

“block” the attack.

SANS Institute -

Combining IDPS &

Vulnerability

Management

TIC Reference Architecture V2.2 22

Provides central management and distribution of rules / actions.

SANS Institute -

Combining IDPS &

Vulnerability

Management

Records information related to observed events. SP 800-94

(paragraph 2.2)

Real-time alerts should also be set up to notify administrators when important events occur on the firewall.

SP 800-41 Rev 1

(paragraph 5.2.3)

Security Function: Authentication

The information system uniquely identifies and authenticates users (or processes acting on behalf of users). Users are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization in accordance with security control AC-14. Authentication of user identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multifactor authentication, some combination thereof (NIST

800-53 Rev 3).

Some Information Systems verify the identity of each user attempting to run the information system. Although this is usually done to prevent unauthorized access to the information system, it may also be done when access is not a concern so that the information system can be customized based on the user’s identity. Common authentication methods include the following:

External Authentication: The information system may use an external authentication service, such as a directory server. Although the information system may contain some records related to authentication, the external authentication service is likely to contain more detailed authentication information.

Proprietary Authentication: The information system may have its own authentication mechanism, such as user accounts and passwords that are part of the information system, not the operating system (OS).

Pass-Through Authentication: Pass-through authentication refers to passing OS credentials (typically, username and password) unencrypted from the OS to the information system.

Host/User Environment: Within a controlled environment (e.g., managed workstations and servers within an organization), some information systems may be able to rely on previous authentication performed by the OS (NIST 800-86 Section

7.1.2).

TIC Reference Architecture V2.2 23

b) Selected Authentication Characteristics:

Authentication of user identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multifactor authentication, some combination thereof.

NIST SP 800-53-

Rev 3

The information system employs multifactor authentication for local and remote system access that is NIST Special

Publication 800-63 compliant.

NIST SP 800-53

Rev 3 (User

Identification &

Authentication)

The organization employs automated mechanisms to facilitate the monitoring and control of remote access methods.

NIST SP 800-53-

Rev 3

The organization controls all remote accesses through a limited number of managed access control points.

NIST SP 800-53

Rev 3 Excerpt

(Remote Access)

The organization permits remote access for privileged functions only for compelling operational needs and documents the rationale for such access in the security plan for the information system.

NIST SP 800-53

Rev 3 Excerpt

(Remote Access)

The identification and authentication policy and procedures are consistent with: (i) FIPS 201 and Special Publications 800-73, 800-76, and 800-78; and (ii) other applicable federal laws, directives, policies (e.g. OMB M-11-11), regulations, standards, and guidance.

NIST SP 800-53

Rev 3 Excerpt

(User

Identification &

Authentication)

The information system typically uses either shared known information (e.g., Media Access Control [MAC] or

Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication

Protocol [EAP], Radius server with EAP-Transport Layer

Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks.

NIST SP 800-53-

Rev 3

TIC Reference Architecture V2.2 24

The organization manages information system authenticators for users and devices by:

a. Verifying, as part of the initial authenticator distribution, the identity of the individual and/or device receiving the authenticator.

b. Establishing initial authenticator content for authenticators defined by the organization.

c. Ensuring that authenticators have sufficient strength of mechanism for their intended use.

d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators.

e. Changing default content of authenticators upon information system installation.

f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators (if appropriate).

g. Changing/refreshing authenticators (Assignment:

organization-defined time period by authenticator type).

h. Protecting authenticator content from unauthorized disclosure and modification

i. Requiring users to take, and having devices implement, specific measures to safeguard authenticators.

NIST SP 800-53-

Rev 3

The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

NIST SP 800-53-

Rev 3

Restrict Access to Authentication Data. Authentication data should be protected with access controls and one-way encryption to prevent unauthorized individuals, including system administrators or hackers from obtaining the data.

NIST SP 800-14

Section 3.11.2

Security Function:…