PLAN GUIDELINES SECTIONS:
1. GENERAL
2. ROLES AND RESPONSIBILITIES
3. DATA SECURITY ENGINEERING PROCESS
4. DATA SECURITY ENGINEERING ADMINISTRATION
5. DATA SECURITY ENGINEERING ACTIVITES
6. DATA SECURITY ENGINEERING TRAINING
Security engineering is a discipline that focuses on the tools, processes, and methods required to design, implement, and test ETSs to ensure that they remain dependable once deployed. In the context of the Smart Lane Project, it is to ensure that the control and monitoring of the related transportation infrastructure continues unimpeded. Since transportation infrastructure is vital to commerce, public safety, and national defense, it is imperative that the infrastructure be designed and built to survive threats against it. With the increasing use of (and dependency on) computer technology comes new vulnerabilities to the transportation infrastructure to intentional and unintentional threats, primarily due to the sophisticated ways hackers have learned to disrupt networks and software programs.
Due to the recommended distributed responsibility for the implementation of security engineering, many parts of the Smart Lane project engineering organization will have roles and responsibilities in this area. Listed below are recommended starting points for defining organizational responsibilities in the security engineering domain.
The JPA ED will have the following roles and responsibilities:
1. Approve the data security engineering-related processes, policies and operating procedures developed by the Integrator for the Smart Lane Project.
2. Participate in project design reviews and provide approval for security-related features of project requirements, design, implementation, and testing.
3. Coordinate with industry groups to maintain a knowledge base of present and emerging threats against Information Technology (IT) and transportation assets.
Systems engineering personnel for the Smart Lane Project shall have the following roles and responsibilities:
1. Monitor the adherence of the systems and software engineering to this Data Security Plan.
2. Offer technical assistance in the area of security engineering.
3. Provide regulatory guidance for security-related requirements in conjunction with JPA management staff.
4. Conduct threat analysis with support, as required, from security engineering.
5. Facilitate vulnerability analysis with support, as needed, from security engineering and software engineering.
6. Ensure that security engineering requirements and processes are passed down to project subcontractors.
7. Manage risk analysis to determine the vulnerabilities to be addressed.
The Integrator Project Manager shall have the following roles and responsibilities:
1. Create and maintain security engineering check lists to aid in the performance of the security work.
2. Prepare the test plans, and manage test execution of security evaluation and/or accreditation testing.
3. Design and implement countermeasures in accordance with security engineering guidelines and/or policies.
4. Review and evaluate software during design and development phases to identify additional vulnerabilities.
Since the Smart Lane Project is principally a networked computer system, security engineering should focus on the various processes and methods to protect these networks, computer systems (i.e., hardware and software), and data. These areas are generally addressed under the umbrella of information security. Awareness and practice of information security is imperative to maintain the 24/7 operation of the Electronic Toll System (ETS) in light of potential threats, including those from new technologies.
This document is intended to provide guidance for the overall Smart Lane Project security engineering processes, as well as serve as a template for tailoring project-specific security engineering plan.
Security engineering methodologies need to be applied throughout an organization and project to be effective. Security must be incorporated into the system design throughout the engineering process or the ETS might be vulnerable to any external threat. Similarly, focusing security awareness in only a portion of the Integrator’s organization might result in the security mechanisms being applied topically, rather than integrated directly into the design.
From a project life-cycle perspective, it is important to consider security issues and practices during all phases of the project. Ignoring security issues during the system design and development phase could result in costly rework or less effective external solutions to meet security certification requirements. Security engineering is an integrated discipline to be used during the system design, development and deployment process. It can be significantly more expensive, and have severe schedule impacts, to attempt to remediate security issues late in the project life-cycle.
Similarly, it is important to distribute awareness and practice of security engineering across the JPA organization and Integrator staff. Concentrating all responsibility for design, development, implementation, and testing of security-related functionality in a specialized organization or individual will not yield a robust solution. Security engineering affects all engineering disciplines and responsibility should be distributed across the engineering organization in more detail.
Another dimension of the security engineering scope to consider is project type. Since security engineering is partly based on risk analysis, it is logical to assume that projects might require varying degrees and applications of security engineering. High Occupancy Toll (HOT) lane projects are particularly vulnerable because they utilize a distributed system with many touch points exposed to the public and there is a revenue collection component. The trend of providing public access to transportation IT via the Internet, and advances with intelligent vehicles, also increase the security risk over traditional system design projects.
Security engineering is fundamentally risk management – identifying possible vulnerabilities that might be exploited by potential threats and thereby adversely impact the ETS operation, and then determining practical solutions to protect the ETS against such threats. This process has been formalized into the threat-vulnerability-countermeasures methodology. With this process, potential threats to the system are identified, the system is analyzed to determine vulnerabilities to potential threats, and countermeasures are designed to mitigate the vulnerabilities to those threats.
The challenge for the JPA in this process is to determine the extent to which each identified vulnerability should be addressed. It is impractical, both from an affordability and operational impact standpoint, to completely address all vulnerabilities within a system. The goal is to assess the affect on the system mission, along with the probability of the threat, and then design countermeasures whose cost and affect on system operation are proportional. The approach should minimize the vulnerabilities most likely to occur, rather than necessarily protect against all conceivable threats.
A threat analysis will be part of the Integrator system design and development process. Threats should be viewed as part of the system’s operational context. Vulnerabilities and countermeasures should be integral considerations to the design, development and implementation of the ETS and security evaluation, and accreditation must be part of the system integration and testing phases.
The most effective security solution is one where all of the engineering disciplines participate. Thus, the greatest asset in operating a secure system is creating awareness by the designers, operators, and users. The ED should ensure that security concerns are included in the criteria used to assess the quality and completeness of the Smart Lane Project.
While most of the security engineering effort will be performed by the Integrator engineers tasked with the design, development and implementation of the ETS, the JPA will use consultants that are responsible for ensuring the quality and compliance of the security engineering work performed.
The security engineering process will be managed by engineering reviews, audits against applicable policies/standards, and measurement via appropriate metrics. Integrator personnel will bear this management responsibility.
In order to integrate security engineering practice across all of the Integrator engineering disciplines, all project design reviews should address security engineering aspects. It is recommended that the Integrator security engineering staff prepare checklists to include in the system design review procedures, in order to assist other engineering disciplines in properly addressing the security domain in their reviews. It is also suggested that the Integrator security engineering staff attend Preliminary Design Reviews (PDRs) and Detailed Design Reviews (DDRs) to properly assess system security issues.
The JPA will approve policy and guidelines developed by the Integrator to govern the execution of security engineering activities. While security engineering plans based on this document are a primary form of governance, it is also good practice to develop additional technical guidelines/policies to ensure uniform compliance with proven best practices as well as flow-down of applicable regulatory requirements.
The JPA will approve Integrator developed security engineering guidelines. Integrator engineering staff shall conduct their security engineering efforts in accordance with these guidelines. In addition, project activities shall comply with any security engineering guidelines or other security engineering governance as discussed previously in this document.
The Integrator may tailor their security engineering process via the project security engineering guidelines. For instance, the verification process will often be adjusted based on whether the project has external interfaces that are required to conform to formal security policies or regulations. Security verification to industry standards should be conducted for interoperability with external systems or the public. Practices dealing with Internet connectivity may also be modified in cases where the project system does not directly connect to public networks.
Comprehensive identification and accurate assessment of threats to a system is critical to developing a cost-effective security policy. Without an accurate threat model in place, systems could be overprotected, which might cause system design countermeasures for potential vulnerabilities that never materialize. Two threat model aspects will be discussed; identification of threats, and assessing the capability and probability of the threats.
Threats must first be identified before meaningful security engineering can be conducted. A matrix will be developed by the Integrator that presents all of the threats that are identified, which will be used later in the process by the Integrator staff. Personnel performing threat identification shall consider potential threats to the system in the following potential categories:
· Human Threat – This is a deliberate or accidental act by any person, whether they are authorized to have access to the system or not. It will be useful to further categorize these threats as internal and external to the JPA. Examples may include user errors, unauthorized access attempts, data sabotage, etc.
· Technical Threats – This is a malicious or accidental attack by external software or network. Common examples would include viruses, worms, Trojans, network level Denial-of-Service (DOS) attacks, etc.
· Physical Threats – This is the malicious or accidental damage to a system through physical acts. Examples may include hardware sabotage or failure. These types of threats primarily affect system availability, as opposed to privacy or confidentiality. This category also normally includes acts of war or civil disturbance.
· Natural/Environmental Threats – These are natural or manmade events that damage or impair a system. Common examples include fire, flood, storms (including lightning), and earthquakes.
Sources of threat identification include:
· Law Enforcement – The JPA security engineering staff should establish an ongoing working relationship with federal, state, and local law enforcement agencies to obtain general and specific threat information.
· Professional Organizations – Computer security organizations such as the SANS Institute (SysAdmin, Audit, Network, and Security) and CERT maintain extensive databases of threats and vulnerabilities, and countermeasures.
· Operations History – Operational histories are valuable sources of threat information in the analysis of incidents in existing systems.
· Design Engineers – The same hardware and software engineers that design the system often have the capability to identify threats to the system so these threats can be mitigated.
· Hacker Web Sites/Publications – Spying on potential attackers is effective, but time consuming (the signal-to-noise ratio is quite poor).
Once threats are identified, project personnel shall assess the possibility of various threats to damage or otherwise undermine the ETS. The possibility can refer to skill in the case of human threats, sophistication of technical threats, and severity of natural threats. In addition to estimating the possibility of a threat, personnel shall also attempt to assess the probability of the threat occurring. Important factors to consider are the possible motivation of the attacker and the perceived value of the target system. For example, it is highly unlikely that an attacker would launch a highly sophisticated technical attack requiring national technical assets against a target system with no substantial financial or national security value.
Vulnerability assessment identifies the consequences to the system from a specific threat, should that threat occur, and predicts the impact to the JPA.
Once threats are identified via threat analysis, system vulnerabilities to those threats must be determined. These vulnerabilities are often comprised of a first and second order effect. The first order effect is the immediate result of a successful attack (i.e., the attacker gaining access to a valid user account via the threat of password guessing). The secondary effect is the consequence to the system function or users (i.e., the compromised user’s information being altered or stolen).
The Integrator shall create and maintain a threat management matrix that correlates a system vulnerability to specific system components (e.g., a software module). Using this matrix, engineering staff can easily identify which vulnerabilities need to be reassessed as software or hardware is redesigned or modified.
The Integrator shall prepare an assessment of the impact to the ETS and/or the business operations that rely on the system in the event that a vulnerability is exploited by a threat. These impact assessments shall include, at a minimum, interruptions to the system services provided by the JPA, potential civil liabilities incurred as a result of the vulnerabilities, regulatory and/or statutory failures, and the impact to operating budgets.
The final stage of vulnerability assessment shall weigh the vulnerabilities identified based on the threat probability and impact assessment. This assessment will be conducted by the entire Smart Lane Team. The goal is to provide a prioritized list of potential vulnerabilities. Vulnerabilities that are the result of high probability threats having significant impacts to the Smart Lane Project operation and/or public safety should be weighted more heavily.
Once the vulnerabilities are ranked, Integrator staff should incorporate additional system requirements into the trace matrix that address the threats and vulnerabilities that present potential risks to the ETS.
The final basic activity under the security engineering process is the design of the countermeasures within the software that address the vulnerabilities to the identified threats. This work will be performed by the Integrator software engineers.
Successfully integrating security engineering into the I-680 Smart Lane Project will require the Integrator to adopt security architecture. The security architecture will provide structure and cohesiveness to a security design, in the same manner that software and hardware architectures are necessary to organize the design and implementation of the respective engineering solutions.
Security architectures are typically constructed around security guidelines or policies. These guidelines and policies are often derived from an underlying formal security model, although many are merely expressions of security strategy based upon empirical data (i.e., best practices information) rather than a rigid mathematical model. Whatever the genesis, security guidelines/policies are necessary to provide guidance to the software engineer(s) developing the security design.
Once the architecture is defined, the Integrator shall identify candidate solutions to address specific vulnerabilities. These solutions shall conform to the security policies and architecture. This phase of the security engineering process is similar to any other engineering design trade study.
It is important to consider not only the capability of a candidate countermeasure to address the vulnerability, but any potential side effects on system operation as a result of the security design. It is easy to adopt invasive countermeasures that effectively address vulnerabilities, but also unacceptably impact normal system operation. Security engineering is, like any other engineering discipline, a compromise between technical function, affordability and mission. The Integrator shall incorporate into the ETS the selected countermeasure designs into the software and hardware requirements where applicable.
Comprehensive and accurate testing of a design is necessary to ensure that it is robust. Verification and testing of a security design is typically separated into two activity types referred to as assurance and evaluation. Assurance is the process of determining whether the system will function as designed, and evaluation is the process of proving it to others.
Security assurance is a process consisting of the traditional engineering techniques of analysis, inspection, and testing to verify that the Smart Lane ETS is secure. By integrating security requirements into the system, and component requirements and specifications as presented throughout this plan, JPA and consultant staff will confirm that the Integrator has taken all appropriate steps that are identified in the Data Security Plan. (See Verification Plan.)
JPA and their consultations will perform the security evaluation. Relying party evaluation uses the current system engineering staff to define and accept the results of the testing program. In the case of the Smart Lane Project, the relying party would be the JPA and its consultant representatives. The organization responsible for conducting and reviewing the testing would be the JPA’s ED and the consultants.
In cases where part, or all, of the system security requirements are dictated by other state or federal agencies, the relying organization may be the agency that created the requirements or that is charged with administering the regulations. This form of evaluation will be planned and conducted similarly to system-level acceptance testing.
Third party evaluations are performed by third party organizations with no financial or operational interest in the outcome of the evaluation testing. These evaluations can also involve certification, also referred to as accreditation, by the third party to previously established standards or processes. This aspect of evaluation is addressed in the following section.
It is recommended that the JPA develop security engineering guidelines and evaluation criteria for the I-680 Smart Lane Project since this project includes the following characteristics:
· The I-680 Smart Lane Project provides direct public electronic access, either via the Internet or by dedicated devices/protocols (i.e., FasTrak);
· This Project will connect to other regional toll facilities or state/federal systems via public infrastructure (i.e., the Internet, wireless communication, etc.); and
· The I-680 Smart Lane Project will connect to external systems that, in turn, offer public access.
Furthermore, JPA staff should work towards mandating evaluation guidelines for the I-680 Smart Lane Project to be used as the basis for all future Smart Lane projects that are under the jurisdiction of the JPA in the region and that are interconnected with other internal or external tolling and information systems or devices.