System Process Flowchart / Information
Systems Security (Revised
07/2003)
Information Systems Security (ISS) Policy. The FAA is required by law, Federal Information Security Management Act of 2002 (FISMA), OMB Circular A-130, and other federal standards to provide security for all agency information that is collected, stored, processed, disseminated, or transmitted using agency or non-agency owned information systems. ISS measures ensure that the correct functioning of information processing systems is protected from threats to integrity, availability, and confidentiality. FAA has relatively few information systems which process "classified" information (i.e., information related to national security). However, almost all agency information systems, including the Air Traffic Management system, process "sensitive" information subject to federal information security requirements. Sensitive information is information that if disclosed, altered, forged, or rendered unavailable or unreliable, could result in any of the following:
- Seriously inhibited system operation;
- Serious and widespread delays;
- Damage to the public perception of Air Traffic Control; or
- Expenditure of significant resources by the FAA or users to reestablish NAS operations;
- Be an unwarranted invasion of personal privacy;
- Reveal a trade secret or privileged or confidential commercial or financial information;
- Be detrimental to the security of transportation.
Given the broad scope of legislation and FAA policy requirements, ISS is a principal concern for virtually every acquisition program, both operational and administrative.
Two-Track Approach for Achieving Information Systems Security. The FAA has a two-track approach for achieving agency-wide information security. First, there is a focused effort to develop economy of scale ISS standards for all information systems in the NAS.
A-ll NAS face similar threats and require protection. Otherwise, in such a highly interconnected "system of systems" as the NAS, a threat whose attack is unsuccessful in one area could simply move on to another. Second, individual systems are designed to be compliant with NAS ISS standards, while at the same time being tailored to design requirements and security vulnerabilities that may be highly system-specific.
The second set of activities are intended to ensure individual systems are compliant with NAS Technical Architecture standards and tailored to specific vulnerabilities and system design features. ISS activities occur throughout the acquisition management lifecycle, and are especially important in the early phases when requirements are defined and acquisition programs are initiated. Activity begins in earnest during Investment Analysis, when the Requirements Document (RD) is defined and candidate solutions are developed sufficiently to establish cost, schedule, performance, and benefits baselines. ISS requirements and costs must be included in these documents. During Solution Implementation, actual hardware, software, and facility components are designed and acquired that satisfy ISS requirements. The new capability is tested at the end of Solution Implementation to compliance with ISS requirements. When the system is certified as
ISS-compliant, it becomes eligible for an In-Service Decision. During In-Service Management, ISS activities focus on maintaining and operating systems to minimize information security concerns, and on upgrading performance as needed for protection against emerging or previously undefended vulnerabilities. In particular, COTS products often harbor ISS vulnerabilities that are discovered only after the products are released. All COTS product vendors must be continuously monitored for announcement of these vulnerabilities, and appropriate corrections must be implemented according to vendor recommendations. In some instances, product upgrades may be developed as new threats are identified .
The FAA ISS Program policy is contained in FAA Order 1370.82, as amended (intranet.faa.gov/aio). This order supersedes FAA Order 1600.54B
(FAA Automated Information System Security Handbook). For additional information regarding ISS policy and guidance, Contact AIS-1. The FAA Certification and Accreditation Program policy contained in the FAA ISS Handbook,
. For more information contact AIS-300.
The following activities are executed during the AMS lifecycle management process so that appropriately secure information systems are acquired and operated.
ISS Work Activities During Investment Analysis
Activity: Gain Familiarity with ISS Elements of NAS Technical Architecture
ISS-1 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Security systems engineering member of the
Investment Analysis Team |
|
|
|
Description:
The Investment Analysis Team must be thoroughly familiar with Information System Security elements of the NAS Technical Architecture. This architecture constitutes the "baseline" of existing and planned FAA capability, and contains the transition plan for reaching the future NAS configuration.
|
Activity: Gain Familiarity with FAA Security Policy and Process
ISS-2 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Security systems engineering member of the
Investment Analysis Team |
|
|
ISS Policy, FAA Order 1370.82
ISS Handbook
(Intranet Only)
NIST Special Pub 800-12 (et al)
|
Description:
The
Investment Analysis Team must become thoroughly familiar with Information
System Security Policy ( Order 1370.82) and the ISS Process
Handbook, and applicable guidance and standards issued by the National
Institute of Standards and Technology (NIST) in fulfillment of their
responsibilities specified in FISMA. As
Investment Analysis proceeds, the Investment Analysis Team uses these
processes to tailor ISS requirements for the candidate solutions under
consideration.
|
Activity: Conduct or Receive a Threat Stipulation
ISS-3 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Office
of Security & Investigations
and Office of Information Systems Security |
Threat
Stipulation |
Designated
Approving
Authority, ISS Manager,
Certification and
Accreditation Agent (AIS-300
for AIS-1),
Product Team
Lead, and a
system end-user
representative |
ISS
Handbook,
FAA NAS System Protection Profile,
|
Description:
The
Office of Security &
Investigations (ASI) provides a physical
and personnel security "Threat Stipulation" for all FAA and NAS
information systems. The "Threat Stipulation" is an intelligence
assessment. It addresses the likely threats to FAA information systems
(i.e., those persons or organizations deemed likely to have a motive to
attack FAA/NAS systems) and the likely mechanisms
that these threats could use. Be sure to contact ASI to determine what needs
to be done. The Office of
Information Systems Security (AIS) provides guidance on cyber-threats to FAA
information systems and how to address them in risk analysis and system
requirements.
|
Activity: Interpret / Tailor Security Policy and Requirements
ISS-4 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Security
systems engineering member of the Investment Analysis Team with support from
the Office of Information Systems Security |
ISS requirements for candidate solutions |
Line of Business
ISSM and AIS-
300
|
ISS
Handbook
FAA NAS System Protection
Profile
|
|
Description:
Based on the Threat Stipulation, the Investment Analysis Team tailors
Information System Security requirements and drafts candidate solutions to
be evaluated. The nature of the tailoring depends on:
- The anticipated user community
(e.g., FAA users only or other government or non-government users);
- The relative sensitivity of
the information and functionality being threatened (e.g., highly
sensitive or innocuous);
- The system architecture and
intended platform safeguards; and
- Pertinent ISS environmental
factors (e.g., power reliability problems).
|
Activity: Incorporate ISS Requirements into Initial Requirements Document
ISS-5 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
| Security
systems engineering member of the Investment Analysis Team
|
ISS
requirements for the initial Requirements Document |
ISSM,
PTL |
ISS
Handbook
FAA NAS System Protection
Profile
NIST SP
800-30
Security Risk Management
Systems Engineering
Manual Section 4.10 Risk Management |
Description:
The Investment Analysis Team works with the Sponsoring organization to
incorporate preliminary Information System Security requirements in the
Initial Requirements Document. These initial requirements are the basis for
development and evaluation of alternative solutions to mission need. At this
stage, ISS requirements may be high-level and incomplete, but they must
reflect the security of the FAA. Section
3 of the NAS System Protection Profile provides security objectives which
must be considered in association with the high level system design and
potential vulnerabilities and threats.
|
Activity: Evaluate ISS Capability of Candidate Solutions to Mission Need
ISS-6 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Security
systems engineering member of the Investment Analysis Team |
Evaluation
of the ISS capability of candidate solutions to mission need |
|
ISS
Handbook
NIST SP 800-12
NIST Computer
Security Handbook |
|
Description:
The Investment Analysis Team defines, analyzes, and evaluates a
number of candidate solutions to mission need during Investment Analysis. As
part of this evaluation, the Investment Analysis Team develops an
Information System Security technical description of hardware, software, and
communications in sufficient detail to allow potential vulnerabilities to be
identified and assessed.
Evaluating
the ISS capability of each candidate solution involves the following four
steps which are described in detail in the ISS Handbook, :
- Vulnerability identification
and assessment,
- Risk assessment,
- Risk mitigation plan,
- Residual risk assessment
These steps are conducted to the appropriate
level of detail which is less than the vendor will
perform during Solution Implementation, but sufficient to gain confidence in
the ISS capability of each candidate solution to meet the security
requirements developed in the Initial Requirements Documents (ISS-6).
|
Activity: Incorporate ISS Requirements into Final Requirements Documents
ISS-7 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
IAT
systems engineering specialist with assistance by the Office of
Security & Investigations and Office of Information Systems
Security |
Final
ISS requirements for each candidate solution
Residual Risk Assessment |
ISSM,
AIS-300 |
ISS
Handbook FAA NAS System Protection
Profile NIST SP
800-30 Security Risk Management
FAA Systems Engineering Manual
Section 4.10 Risk Program |
Description:
By the end of the Investment Analysis, the Investment Analysis Team will
have defined a set of final requirements (including Information System
Security requirements) for each candidate solution. The final Requirements
Document for each solution reflects the final set of ISS requirements that
will be satisfied during Solution Implementation. A Residual Risk Assessment
identifies any remaining ISS risks that will not be protected against
by the candidate solution. These residual risks must be explicitly
acknowledged and accepted by the operators of the system at the Investment
Decision. These residual
risks must be considered during any preplanned product improvements or other
system upgrades and enhancements.
|
Activity: Incorporate ISS Cost,
Schedule, Performance,
Benefits into Acquisition Program Baselines
ISS-8 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Security
systems engineering member of the Investment Analysis Team |
Acquisition
Program Baseline containing ISS performance, costs, schedule, and benefits for
each candidate solution |
|
ISS
Handbook |
Description:
The Investment Analysis Team develops an Acquisition Program Baseline for
each candidate solution that sets out the performance, cost, schedule, and
benefit baselines to be achieved. Information System Security performance,
cost schedule, and benefit factors must be included in these
draft APBs.
|
ISS Work Activities During Solution Implementation
The
following Information System Security activities are drawn from the ISS
Handbook. Initial ISS activity turns ISS requirements into a sound
implementation strategy and detailed planning. Then ISS activity supports
program execution as the product is designed, acquired, tested, and deployed to
the field.
|
PT systems
engineering specialist working with the Office of
Security & Investigations and Office of Information Systems
Security
|
ISS requirements
in the System Specification
|
Specification
Control Board
|
ISS
Handbook
FAA NAS System
Protection Profile
|
|
Description:
The Product Team develops a System Specification, which includes Information
System Security requirements, as a prelude to seeking a vendor through the
source selection process. The Product Team may choose to include residual
ISS requirements from Investment Analysis as options in the System
Specification to allow vendors to bid system designs that meet these
requirements as part of a Best Value award by the FAA. If so, satisfaction
of these residual requirements must be identified as an evaluation factor in
the Screening Information Request. Requirements
met by other NAS or infrastructure systems such as telecommunications and
corresponding engineering and development tasks are deleted from the
tailored Security Requirements list and Integrated Program Plan task list in
accordance with the results of the risk analysis and decision by the DAA,
ISSM, C&A Agent, PTL, and end user representative.
Often, the residual ISS requirements are stated in a lower level of
detail than previously written. The
NAS System Protection Profile provides more detailed requirements that can
be tailored to meet the system requirements.
|
Activity: Develop ISS Implementation Strategy for the ASP
ISS-10 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Description:
The Product Team defines the tasks needed to implement Information System
Security requirements, and records them in the Integrated Program Plan.
|
Activity: Award Prime Contract
ISS-12 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Description:
A Screening Information Request is issued after completion of program
planning and approval of the System Specification. The Product Team may use
Information System Security compliance and quality as an evaluation factor
in the award. In any case, the winning proposal must be capable of
satisfying all ISS requirements in the System Specification (ISS-9).
|
Activity: Complete ISS Portion of System Design
ISS-13 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
Description:
After contract award, the prime contractor implements most Information
System Security activities with the Product Team overseeing contractor
activity. The Product Team ensures the emerging design is fully compliant
with ISS requirements in the System Specification through such activities as
the Preliminary Design Review, Critical Design Review, and test and
evaluation.
|
Activity: Complete Final System Description
ISS-14 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
|
Prime contractor
|
Final system
description
|
PT leader or
designated official
(e.g., QRO)
|
|
Description:
The contractor prepares the final "as built" technical description
of the system. Among other items, the technical description defines the
capability of the system in response to ISS requirements in the System
Specification.
|
Activity: Conduct Information Security Testing
ISS-15 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
|
PT test
specialist
System
security engineer
|
Information
Security Test Report Certification request
|
PT leader
Certification
and Accreditation Agent (AIS-300 for AIS-1)
|
ISS Handbook
|
Description:
Near the end of development, the system undergoes a battery of testing to
ensure it complies correctly and completely with each Information System
Security requirement in the System Specification. In addition, the system as
a whole is subjected to Security Test and Evaluation (ST&E) to assess
compliance with ISS specifications and its overall resistance to attack on
information security. The information security test report contains the
results of ST&E, as well as all test plans and procedures. The report
also identifies types of testing that have not been done (e.g., due to cost
or complexity), but which could nonetheless be of concern to the FAA, such
as the effects of electromagnetic interference, radio frequency jamming, and
communications message flooding. The
results of ST&E are provided with the rest of the evolved Security
Certification & Accreditation Package (risk analyses).
|
Activity: Approve the Sensitive Application Certification (SAC) Report
ISS-16 |
Responsible
Agent |
Product |
Approval
Authority |
Tools and Aids |
|
Security engineer
|
|
Designated
approving authority
|
ISS Handbook
|
|
Description:
The Designated Approving
Authority (DAA) certifies the new system as ISS-compliant and ready to enter
operational service via signing the Authority To Operate (ATO) certificate
(template in ISS Handbook) with the ISSM, AIS-1, PTL and a user
representative. The ATO becomes the cover sheet for the SCAP that contains:
- Security requirements and
high-level ISS design documents;
- ISS assurance measures
(including all ISS test procedures and results);
- Security Plan for development,
operations and maintenance; and
- Operations and training
materials pertaining to system ISS capability.
The report also thoroughly discusses residual ISS
risks present in the system at the time of the In-Service Decision.
|
ISS Work Activities During In-Service Management
The
following Information System Security activities are drawn from the ISS
Handbook. They are executed during In-Service Management when activity shifts to
operating and maintaining the new capability in the field. There may also be
product upgrades or pre-planned product improvements to resolve residual ISS
requirements or respond to emerging threats or vulnerabilities.
|
PT leader
|
Product upgrades
|
Designated
In-Service decision maker
|
|
Description:
As new vulnerabilities emerge or as residual requirements are resolved, the
Product Team develops product upgrades that can be fielded incrementally. In
some cases, the upgrades can be executed though available sustainment
funding and the Product Team need not return to the JRC. When additional
funding is required, the Product Team prepares for a re-baselining
Investment Decision to obtain approval and funding for the upgrade.
|
|