The needs that lead to a consideration of new acquisitions arise from an organization’s day-to-day Business objectives and business operations. Investment and work process analyses articulate these needs and may recommend process changes, procurement of a new system, or both. If procurement of a new system is an option, the organization enters Pre-Systems Acquisition.

Analysis of system needs:

Business objectives, Business, or Enterprise Investment Analysis.

Objective:

Review key Business objectives or business processes (collectively, work processes), changes in the operational environment, and gaps in capability to determine the need for a new system.

Typical Artifacts:

Investment/work process analysis report documenting business environment, work flows, data and. participants, and work environment or threat environment, operations (and description of missing capabilities); plan for an alternatives and other activities to identify and refine potential solutions; initial security risk assessment related to investment analysis report.

Software Security Actions:

Identify and document threats, given the information in the investment/work process analysis report.

Consider how threats may evolve over the life of the system, including potential vulnerabilities in the work processes that could be exploited.

Identify high-priority risks and establish security evaluation criteria to support a high-level assessment of Business objectives and work process alternatives and risk mitigation options as these processes are refined.

Identify organizations that may influence security requirements and processes, and establish points of contact.

Pre-Systems Acquisition

The goal of Pre-Systems Acquisition is to mature a system solution concept to the degree that.

A suitable acquisition strategy can be developed.

Capability need and solution constraints can be adequately expressed in a Request for Proposal (RFP), such that the offerors can scope and estimate the cost and schedule for the necessary work tasks.

The acquirer understands enough about the solution to plan and prepare for supplier monitoring.

The degree of maturation expected in Pre-Systems Acquisition will depend on the complexity of the system to be acquired and the level of technology, cost, and schedule risk deemed acceptable.

Activities performed during Pre-Systems Acquisition include Refine Concepts, Develop and Assess Technology, Create Acquisition Documentation, Prepare for Supplier Selection, Select Supplier, Establish Contract, and Prepare for Supplier Monitoring. These activities are listed below, along with software security actions the acquirer should perform to lay the foundation for secure software development.

Pre-Systems Acquisition activities

Objective:

Analyze and document (a) user demographics and needs, (b) required capabilities, quality, and performance, (c) concepts of operation, maintenance, and evolution, (d) interfaces with other systems and organizations, including interface stability, and (e) concept-related risks.

Typical Artifacts:

Operational, capabilities descriptions, market research and technology assessment, initial integrated architecture description, initial system threat assessment, technology development strategy, systems engineering plan, test and evaluation strategy.

Software Security Actions:

Establish a software security function, led by an experienced software security professional, within the program office. Prepare charter, effort, schedule, and resource requirements.

Continue to identify threats and vulnerabilities in the emerging operational environment and solution space.

Apply security evaluation criteria to concept refinement activities and artifacts.

If COTS or other non-developmental items are identified as part of candidate solutions, research the items’ current and potential security risks.

Document the approach to continuously identify, specify, and manage software security risks throughout the life cycle.

Hold technical interchange meetings with stakeholders to begin developing an understanding of potential software security issues.

Develop and Assess Technology

Objective:

Develop new or unproven hardware and software technologies to an acceptable maturity level for the acquisition.

Typical Artifacts:

Technology readiness assessment, cost analysis, interoperability and supportability assessment, revised integrated architecture description, system threat assessment, SEM, SIM, and test master plan.

Software Security Actions:

Continue security activities identified for Refine Concepts.

Identify software quality attributes, including security, in candidate system architecture descriptions.

Begin to select and define security properties to monitor throughout the life cycle.

Hold technical interchange meetings with stakeholders to specify software-related system-level security requirements.

Ensure these requirements are traceable to verification activities.

Ensure cost analyses consider costs associated with building in and verifying security.

If software technology development has produced prototype or demonstration systems, ensure appropriate plans exist to “productize” the prototype (i.e., to develop robust software for the operational system) and that these plans include security.

Create Acquisition Documentation

Objective:

Develop strategy and plan for acquisition, considering key cost, schedule, and performance constraints, and risk. Also, develop and secure approval of documents required by law for the type of system to be acquired.

Typical Artifacts:

Acquisition strategy and acquisition plan; documents required for compliance with statutory and regulatory requirements; threshold and objective values for performance, quality, cost, and schedule parameters (for Corporate, these compose the Acquisition Program Baseline); acquisition risk management plan.

Software Security Actions:

Ensure that the acquisition strategy and plan accommodate security activities and resource requirements.

Review compliance with security-related statutory and regulatory requirements.

Define and incorporate security parameters into the Acquisition Program Baseline.

Prepare for Supplier Selection.

Objective:

Develop Request for Proposal
(RFP) and supplier selection process.

Typical Artifacts:

RFP, with technical requirements, instructions to offerors, statement of work, requirements for contractual deliverables (management and technical), evaluation criteria, and other conditions related to the proposal; and SSP, identifying organization and responsibilities of the source selection team, evaluation criteria, and detailed procedures for proposal evaluation.

Software Security Actions:

Ensure that the RFP

Requires offerors to apply robust software engineering practices for all software regardless of origin and to demonstrate in the proposal their intent and ability to do so specifies technical and management requirements and standards for software security, expected contractor support for government-led security reviews and audits, and expected government participation in contractor-led security reviews.

Requires delivery and update of a preliminary software/ system security plan covering all offeror’s team members with software responsibility.

Specifies content and delivery schedule and media for software artifacts to be produced during System Acquisition.

Identifies government access required to contractor artifacts and facilities for security reviews requires that the offerors identify and estimate the work tasks and costs associated with interacting with government security organizations throughout the life cycle.

Ensure that the source selection team includes a software security expert who will participate in proposal evaluation to identify strengths, weaknesses, and risks associated with security-related technical and management practices and deliverables and corresponding cost and schedule estimates.

Develop a strategy and plan for evaluating, during supplier selection, the offerors’ ability and intent to meet critical security requirements.

Select Supplier

Objective:

Select the proposal that represents the best value.

Typical Artifacts: Strengths, deficiencies, significant weaknesses, and risks of each proposal as documented against the evaluation criteria defined in the RFP and per the SSP; clarification requests; cost realism analysis; ability of offerors to meet technical requirements; initial and final proposals; and source selection decision and rationale.

Software Security Actions:

Ensure software security expert reviews proposal sections with software security implications.

Before competitive range is established and as needed, prepare security-related clarification requests to be submitted to offerors.

After competitive range is established and if discussions are permitted, prepare for discussions on security deficiencies, weaknesses, or risks related to offerors’ approaches.

Establish Contract

Objective:

Finalize the contract and complete preparation for supplier monitoring.

Typical Final contract

Software Security Actions:

Review and approve contractor plans for mitigating security-related weaknesses and risks identified in the winning proposal.

Identify and plan for security-related review activities.

Prepare for Supplier Monitoring

Objective:

Document plan for supplier monitoring activities along with resource needs (quantity and area of expertise). Identify resources to be used for each activity, artifacts to be produced (e.g., review comments), and plan for approving, using, and archiving these artifacts. Identify and document known risks.

Typical Artifacts: Supplier monitoring plan and updated acquisition risk management plan.

Software Security Actions:

Include in supplier monitoring plan activities for a software security expert to review evolving artifacts and participate in relevant system and software reviews.

Ensure acquisition risk management plan incorporates software security risk.

Define approach to monitor the evolving system and operational context and manage emerging software security risks.

Conduct software kick-off workshop for security (may be included as part of an overall workshop to address quality attributes in a software context).

In defining a framework for government involvement in software security, ensure change control boards have a standing member who is a security specialist and include evaluation of software security implications and risks.

Systems Acquisition

The goal of Systems Acquisition is to design, develop, and deliver an initial system capability. As the contractor team conducts its engineering activities, the acquirer evaluates the progress and outcomes of these activities, including interim artifacts. This is especially critical for large, complex systems in which there are many variables and risks. For a non-functional attribute such as software security, it is particularly important to remain vigilant throughout Systems Acquisition, because changes in requirements, the environment, and cost and schedule constraints can overwhelm efforts related to such “invisible” attributes.

Note:

For some types of systems, especially those with complex hardware development, system-level activities may not correspond directly with software activities. For example, with iterative software development methods, some software items may complete design during early system design, while other software items may not start design until system design is complete.

Activities performed during Systems Acquisition include Monitor System Design; Monitor System Implementation, Integration, and Verification; and Monitor Delivery and Validation of Initial Capability. These activities are listed below, along with software security actions the acquirer should perform to prevent, or identify and mitigate, security issues.

Systems Acquisition activities

Monitor System Design

Activity Description

Objective:

Ensure the design for the system, including all hardware, software, interfaces, and operations and sustainment concepts, is adequate to support implementation.

Typical Artifacts: Evolving software and system artifacts (e.g., architectures, requirements, designs, software, hardware, verification and review records, plans, measures, review presentations, change requests, assurance cases and evidence).

Software Security Actions:

Review/audit software artifacts against security cr
iteria.

Review security-related artifacts, e.g., use and abuse cases, assurance cases, SSP, certification and accreditation plans. Ensure these artifacts are updated and matured as the system evolves.

Conduct biweekly technical interchange meetings during system design to ensure an adequate and sustained focus on security.

Ensure adherence to security plans and modification of plans if necessary.

Continue to identify, manage, and track security risks and issues identified through contractor and government reviews. Identify risks associated with Dependencies between systems.

Multiple administrative control points

Operations for individual systems and systems of systems.

Impact of changing system states and operating environment.

Volatility (architecture, requirements, design, code, staff, plans, procedures).

For software developed using iterative approaches, ensure each iteration (increment, build, spiral) includes a security risk evaluation.

Evaluate proposed upgrades and changes to non-developmental items (e.g., COTS and reuse) for continuing suitability with respect to security criteria.

Re-evaluate security artifacts and activities as the operational context, system definition, and threat environment change.

Monitor System Implementation, Integration, and Verification.

Objective:

Implement and integrate the system and verify that it is ready for production (for high-quantity systems) or build activities and integration into the operational environment.

Typical Artifacts: Evolving software and system artifacts (e.g., architectures, requirements, designs, software, hardware, instructions and procedures, verification and review records, certification and accreditation records, assurance cases and evidence, plans, measures, review presentations, change requests).

Software Security Actions:

Continue security activities initiated previously.

Monitor changes to system and software artifacts driven by requirements changes, iterative development, and deficiency reports for security impacts.

Review delivery and installation processes for security risks.

Review test plans and test equipment to ensure they will adequately address security requirements, given changes to system and software artifacts.

Review operator, user, and maintenance manuals and associated processes for security risks.

Ensure security-related configuration management and control practices are established and ready for use in the operational environment and maintenance facility, review regression testing procedures, and participate in C&A activities.

Monitor Delivery and Validation of Initial Capability

Objective:

Ensure the system (or first increment of capability) is acceptable for use in the operational environment.

Typical Artifacts: System hardware and software; installation and configuration management procedures and report; acceptance report; verification/validation records; operator, user, and maintenance manuals; system security plan; other deliverable documentation; deficiency reports; C&A report; and assurance cases and evidence.

Software Security Actions:

Review artifacts.

Monitor installation process to ensure appropriate configuration of deployed system. Document and resolve security risks and issues.

Monitor initial operations and early defect reports and change requests. Monitor change procedures, if applicable, for security risks and issues.

Ensure security-related configuration management and control practices are applied, and participate in C&A activities.

https://www.bestitdocuments.com/Samples