Office of Operations
21st Century Operations Using 21st Century Technologies

Transportation Management Center Information Technology Security

Chapter 6. Guidelines for Controlling Software Used within the Network

Traffic Management Centers have a wide range of software applications ranging from vendor-provided software that is specific to managing a single type of Intelligent Transportation Systems (ITS) field device/subsystem, to a custom-developed software platform that integrates all field devices into one system. These may reside on individual server hardware platforms or within one or more Virtual Machines (VM) on servers(s). Advanced adversaries are continuously conducting research and development to identify new vulnerabilities in the applications used by their targets and the infrastructure on which those applications run. Similar to hardware control, software control begins with an inventory to identify what is present on the Traffic Management Center (TMC) network. Center for Internet Security (CIS) Control 2: Inventory and Control of Software Assets provides guidelines on managing software deployed within the TMC and underscores the importance of the removal of unnecessary software, which poses a risk due to potential security flaws or lack of vendor support, as well as determining appropriate separation of high-risk applications from the most critical systems. As an example, if a traffic management software vendor ceases to support upgrades to use the newest Windows operating system, and Microsoft also stops supporting patches for the older operating system, both will be compromised from a security standpoint, which should be addressed before a problem arises. Additionally, TMCs with custom software tend to deploy a test environment and a live-production environment segmented on different parts of the network. In those cases, devices that are moved back and forth between the two networks and should be tracked and regularly checked for accuracy.

Once a baseline is established, maintaining control is equally important. Going forward, continually monitor what software applications are on each computer, and quarantine and/or remove unauthorized applications in a timely manner to maintain control. Quarantining an application may result in administrative rights being altered to restrict users from using the software until further evaluation and approval by TMC Information Technology (IT) staff.

Preventing unauthorized applications from being installed in the first place is a combination of CIS Control 2 (e.g., whitelisting authorized applications) and CIS Control 5: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers (e.g., maintain secure configuration settings for computer operating systems to minimize administrative privileges on what can be added/deleted/changed). These two CIS Controls are considered basic elements to all agencies that should be the starting point of security initiatives. The next two relevant CIS Controls are considered foundational and organizational, respectively. As such, they have more value once basic elements have been covered first. The next control element for software components is CIS Control 7: Email and Web Browser Protections,, begins to address attack elements focused on end users' interactions with Internet-connected applications, which can expose the network and systems to malicious code and/or provide unauthorized access to the network by pilfering passwords through a variety of exploitation methods including social engineering. Two of the most relevant sub-controls of CIS Control 7 for all organizations involves ensuring that only fully supported browsers and email clients are allowed on the network, as well as using domain name system (DNS) filters to block access to known malicious domains. For example, if the agency is not doing business in a capacity that requires access to foreign country web domains, then restricting access to those domains can help prevent unnecessary exposure by reducing the attack surface on the network.

For larger organizations with a mixture of applications developed in-house along with vendor-supported applications, CIS Control 18: Application Software Security provides guidelines for procedural measures to be incorporated to routinely evaluate, monitor and correct exposure risks associated with application development and maintenance; because this is intended for more sophisticated TMC environments, the associated sub-controls are pertinent to group 2 and group 3 organizations. If the organization has sensitive applications or data sources that are passing across or outside the network, and it is desired to encrypt the entire data flow, the use of standardized encryption algorithms is highly recommended (sub-control 18.5).

Cloud Hosting

Relevant Controls for Software

  • CIS Control 2: Inventory and Control of Software Assets NIST RMF Identify.
  • CIS Control 5: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers.
  • CIS Control 7: Email and Web Browser Protections.
  • CIS Control 18: Application Software Security.

As a sub-variation of controlling software in the TMC environment, while cloud computing is increasingly being used for either data storage and/or hosting applications (e.g., Software as a Service (SaaS) or Platform as a Service (PaaS)), CIS Controls do not specifically discuss application hosting in this regard, though it is recommended to use caution regarding storing data in the cloud. When evaluating the option for a cloud computing solution, agencies need to consider the associated risks and challenges that the specific solution may encounter. The National Institute of Standards and Technology's (NIST) Cloud Computing Security Working Group (NCC-SWG) developed a Risk Management Framework (RMF) in a Cloud Ecosystem, which shows a 6-step process with the items specific to cloud-computing highlighted in blue. A wiki page is available online for further information regarding the NCC-SW.10

Three primary cloud service models are the most prevalent:

  1. Software as a Service (SaaS).
  2. Platform as a Service (PaaS).
  3. Infrastructure as a Service (IaaS).

In the first, the end-user agency only gets access to the software (e.g., webmail client, maintenance management software, etc.) without regard for the computing hardware required to run it in the cloud. SaaS typically offers limited capabilities for integration with other data, systems, and platforms, and tends to lead toward vendor lock-in, and little flexibility to customize the application for the TMC. Subscribing to travel-time and crowd-source data streams is a common use of SaaS for TMCs, where the agency is able to receive the data streams and store the data locally to mitigate vendor lock-in, integration, or the need for customizations.

For a PaaS environment, the agency begins to take a more active role in picking the hosting environment with control of the applications that are deployed but very little control of the underlying servers, processors, and storage equipment. For an IaaS, an agency gains more control of the operating system, the selection of the hardware, and limited control of the network that connects their selected applications and devices together. The TMC's traffic management software generally requires a great deal of customization to integrate legacy field devices, protocols, and TMC-specific elements (video walls, video distribution systems, access controls) and a wide array of telecommunication connection options, not to mention agencies that share data and controls with other public agencies. Picking a cloud service model is a balance between control/integration flexibility and how much the agency can maintain/administer safely and securely on their own.

Figure 9 is circular graphic showing 6 steps of a risk management framework for a cloud ecosystem.
Figure 9. Flowchart. Cloud consumers' view of the Risk Management Framework applied to a cloud ecosystem. (Source: Managing Risk in a Cloud Ecosystem, NIST.)

Beyond choosing a cloud service model, there are several other elements that agencies need to consider when implementing a cloud-hosted environment. For instance, if the systems will be subject to the Federal guidance of FedRAMP due to the content being stored/shared, then the following guidelines need to be adopted by the organization:

  • FedRAMP:
    • Per an Office of Management and Budget (OMB) memorandum dated December 8, 2011, any cloud services that hold Federal data must be FedRAMP authorized.11 This memorandum also references NIST Special Publication 800-53 Recommended Security Controls for Federal Information Systems and Organizations and 800-53A regarding building effective security assessment plans.12
    • An agency official is responsible for making risk-based decisions to grant a cloud service provider with the Authority to Operate (ATO) along with the determined categorical NIST Federal Information Processing Standards (FIPS) 199 impact level of the applications/services.13
    • It also references NIST SP 800-144 Guidelines on Security and Privacy in Public Cloud Computing.14 One key aspect involves maintaining accountability over the privacy and security of data and applications implemented in public cloud computing environments.
    • While these are the most applicable to TMCs, Federal agencies will need to abide by the broader list of referenced requirements to ensure compliance.
  • Public cloud or GovCloud:
    • GovCloud platforms are operated by employees who are U.S. citizens on U.S. soil, and intended for hosting sensitive controlled unclassified information.
    • GovCloud U.S. regions are only accessible to U.S. entities, and these systems are restricted to root account holders who pass a screening process; agencies must confirm that they will only use a U.S. Person (green card holder or citizen as defined by the U.S. Department of State) to manage and access root account keys to the U.S. regions.
    • GovCloud is not an automatic requirement for TMCs looking to deploy systems in the cloud but is worth considering the value when an agency places more emphasis on trusting a third-party to maintain a key platform for them.
    • Evaluate geographic diversity/availability for data storage in primary and secondary sites, and whether the organization can maintain control of where the data resides (in country or abroad for Public cloud providers).
    • Evaluate the cloud providers support for protection against Internet attacks (e.g., Distributed Denial of Service (DDoS)) and other threats that the organization already protects against on the physical network.
    • Evaluate cloud administrators access to the system data and whether an appropriate level of staff vetting is in place based on the level of access and/or risk.

10TWiki, "NIST Cloud Computing Collaboration Site." Retrieved from: https://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/CloudSecurity. [Return to footnote 10]

11Steven VanRoekel, Executive Office of the President "Security Authorization of Information Systems in Cloud Computing Environments Memorandum," 2011. Retrieved from: https://www.fedramp.gov/assets/resources/documents/FedRAMP_Policy_Memo.pdf. [Return to footnote 11]

12NIST, "SP 800-53A Rev. 4 Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans," 2014. Retrieved from: https://csrc.nist.gov/publications/detail/sp/800-53a/rev-4/final. [Return to footnote 12]

13NIST, "FIPS 199 Standards for Security Categorization of Federal Information and Information Systems," 2004. Retrieved from: https://csrc.nist.gov/publications/detail/fips/199/final. [Return to footnote 13]

14NIST, "SP 800-144 Guidelines on Security and Privacy in Public Cloud Computing," 2011. Retrieved from: https://csrc.nist.gov/publications/detail/sp/800-144/final. [Return to footnote 14]

You may need the Adobe® Reader® to view the PDFs on this page.

Office of Operations