• No results found

System and Services Acquisition (SA)

5.   MANAGEMENT CONTROLS

5.4   System and Services Acquisition (SA)

System and services acquisition controls ensure that appropriate technical, administrative, physical, and security requirements will be included in all specifications for the acquisition, operation, or maintenance of Office of Personnel Management (OPM) facilities, equipment, software, and related services or those operated by external providers of information system services on behalf of OPM.

Policy: OPM shall:

• Allocate sufficient resources to adequately protect organizational information systems;

• Employ system development life cycle processes that incorporate information security considerations;

• Employ software usage and installation restrictions;

• Ensure that third-party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization; and

• Ensure that all information technology acquisitions are processed through the Office of the Chief Information Officer (CIO).

5.4.1 System and Services Acquisition Policy and Procedures (SA-1)

The policies under this control are implemented with the OPM System and Service Acquisition Procedure. System and Service Acquisition procedures shall be developed and disseminated.

The procedures shall be reviewed at least annually and updated as determined necessary.

5.4.2 Allocation of Resources (SA-2)

OPM shall determine, document, and allocate, as part of its capital planning and investment control process, the resources required to adequately protect all information systems. The System Development Life Cycle (SDLC) requires consideration of IT security in budget requests. As a result, programs shall include the capital asset budget planning process and follow a methodology consistent with National Institute of Standards and Technology (NIST) SP 800-65. Office of Management and Budget (OMB) Circular A-11 and Memorandum M-00-07 require that security be built into and funded as part of the system architecture. As a result, each Program Management Office is responsible for security roles as part of the IT investments and capital programming processes. The funding shall include all products, procedures, and personnel (Federal employees and contractors) that are primarily dedicated to or used for provision of IT security for the specific IT investment.

System Owners (SO) shall ensure:

• Mission/business process planning includes a determination regarding information security requirements for the information system;

• The capital planning and investment control process for the information system includes determination, documentation, and allocation of the resources required to protect the information system; and

• Establishment of a discrete line item for information security in organizational programming and budgeting documentation.

• Compliance with OMB Memorandum M-11-11, and OPM policy which requires:

• FY2012, existing physical and logical access control systems shall be

upgraded to use PIV credentials, in accordance with NIST guidelines, prior to the agency using development and technology refresh funds to complete other activities.

Refer to OPM's Capital Planning and Investment Control (CPIC) process and information, which includes IT investment budget planning, by contacting the Chief, IT Investment Management in the CIO office. In addition, refer to the Information Technology System Management available on OPM’s intranet which provides guidance on OPM’s SDLC standard. Lastly,

5.4.3 Life Cycle Support (SA-3)

All federal information systems, including operational systems, systems under development, and systems undergoing modification or upgrade, are in some phase of what is commonly referred to as the System Development Life Cycle (SDLC). Many activities during the SDLC have cost, schedule, and performance implications. In addition to the functional requirements levied on an information system, security requirements must also be considered. When fully implemented, the information system must be able to meet its functional requirements and do so in a manner that is secure enough to protect OPM operations, assets, and individuals. In accordance with the provisions of Federal Information Security Management Act (FISMA), agencies are required to have an agency-wide Information Security Program and that program must be effectively integrated into the SDLC.

The SO shall ensure:

• Management of the information system using a system development life cycle (SDLC) methodology that includes information security considerations;

• The definition and documentation of information system security roles and responsibilities throughout the s SDLC; and

• Individuals having information system security roles and responsibilities are identified.

5.4.4 Acquisitions (SA-4)

The Contracting or Procurement Officer shall work with the SO to include the following

requirements and/or specifications, explicitly or by reference, in information system acquisition contracts based on an assessment of risk and in accordance with applicable federal laws,

Executive Orders, directives, policies, regulations, and standards:

• Security functional requirements/specifications (including requirement for services and products involving facility or system access control shall be in accordance with HSPD-12 policy and the Federal Acquisition Regulation);

• Security-related documentation requirements (including Interconnection Security Agreements (ISA) for services); and

• Developmental and evaluation-related assurance requirements.

The SO shall require in the solicitation documents that appropriate documentation be provided describing the functional properties of the security controls employed within the information system, components or services with sufficient detail to permit analysis and testing of the controls. The SO shall acknowledge that each information system component and service acquired is explicitly assigned to an information system. (Moderate and High)

The SO shall require in the solicitation documents that appropriate documentation be provided describing the design and implementation details of the security controls employed within the information system, components or services (including functional interfaces among control components) with sufficient detail to permit analysis and testing of the controls. (High) 5.4.5 Information System Documentation (SA-5)

Documentation of information systems involves the collection of detailed information (e.g., functionality, system mission, unique personnel requirements, type of data processed,

architectural design, system interfaces, system boundaries, hardware and software components, system and network diagrams, asset costs, and system communications and facilities). Service provider documentation would include Memorandum of Understanding/Agreement (MOU/A), Interconnection Security Agreements (ISA), and Service Level Agreement (SLA) where applicable.

The SO shall obtain, protect as required, and make available to authorized personnel adequate documentation for the information system. Administration documentation is to include: secure configurations, installation, operation, effective use, and maintenance of security functions, and known vulnerabilities regarding configuration and administrative functions. User documentation shall include: user-accessible security functions and their use, methods for user interaction so users are able to use the system in a more secure manner, and user's security responsibilities for the information and information system. The SO shall document the attempt to obtain

information system documentation when such documentation is either unavailable or nonexistent.

The SO shall obtain, protect as required, and make available to authorized personnel, vendor, manufacturer, or service provider documentation that describes the functional properties of the security controls employed within the information system. The documentation will include a high-level design of the information system in terms of the subsystems and implementation details of the security controls with sufficient detail to permit analysis and testing. (Moderate and High)

The SO shall obtain, protect as required, and make available to authorized personnel, vendor, manufacturer or service provider documentation that describes the security-relevant external interfaces to the information system. The documentation will include sufficient detail to permit analysis and testing of the controls. (High)

5.4.6 Software Usage Restrictions (SA-6)

Compliance with software contractual and copyright usage restrictions is imperative. The distribution of approved software must be tracked and controlled for software to ensure contractual agreements and copyright laws are not violated.

The SO shall ensure:

• OPM uses software and associated documentation in accordance with contract agreements and copyright laws;

• Employment of tracking systems to manage and control the distribution of software and associated documentation protected by quantity licenses; and

• Control and documentation of the use of peer-to-peer file sharing technology to ensure it is not used for unauthorized distribution or reproduction of copyrighted work.

5.4.7 User-Installed Software (SA-7)

User-installed software, including downloaded software, can contain viruses and other types of malicious code. In addition, such software can alter the equipment configuration causing

malfunctions, cause the loss of data, expose data and cause costly support calls. Users should be warned about such risks and be instructed to refrain from installing any software on equipment without proper approval.

OPM prohibits the installation of unapproved software by users within the Computer User Responsibilities (Form 1665). Software shall be requested and approved by OPM Managers and Supervisors prior to installation by system administrations and computer support personnel.

The SO shall ensure annual assessments of computers and networks are conducted to verify installed software has the appropriate licenses and remove software that does not have appropriate licenses.

5.4.8 Security Engineering Principles (SA-8)

The application of security engineering principles is primarily targeted at new development information systems or systems undergoing major upgrades and is integrated into the system development life cycle (SDLC). The organization applies for legacy information systems,

security engineering principles to system upgrades and modifications to the extent feasible, given the current state of the hardware, software, and firmware within the system. See "National Institute of Standards and Technology (NIST) Special Publications 800-27 Rev. A - Engineering Principles for Information Technology Security" for more details on security engineering

principles.

The SO shall ensure use of security engineering principles in the specification, design, development, implementation, and modification of the information system. (Moderate and High)

5.4.9 External Information System Services (SA-9)

An external information system service is a service that is implemented outside of the

authorization boundary of the organizational information system (i.e., a service that is used by, but not a part of, the organizational information system). Some examples of external information system services are: joint ventures, business partnerships, outsourcing arrangements (e.g.,

contracts, interagency agreements, lines of business arrangements), licensing agreements, and/or supply chain exchanges. The responsibility for adequately mitigating risks arising from the use of external information system services remains with OPM SOs and Authorizing Officials (AO) where applicable.

AOs require an appropriate chain of trust be established with external service providers when dealing with the many issues associated with information security. A chain of trust requires the organization establish and retain a level of confidence, that each participating provider of services external to the organization, in the potentially complex consumer-provider relationship, provides adequate protection for the services rendered to the organization. The extent and nature of this chain of trust varies based on the relationship between the organization and the external provider. (e.g., the organization employs compensating security controls or accepts the greater degree of risk when a sufficient level of trust cannot be established in the external services and/or service providers.)

The external information system services documentation includes government, service provider, end user security roles and responsibilities, and any service-level agreements. Service-level agreements define the expectations of performance for each required security control, describe measurable outcomes, and identify remedies and response requirements for any identified instance of noncompliance.

Information security requirements must be incorporated in contractual documents that involve the acquisition, development, and/or operation and maintenance of computer resources. These requirements must be applied at the beginning of a project or acquisition and in all follow-on contracts or purchasing agreements involving the acquisition of computer resources. Computer resources include hardware, software, maintenance, and other associated IT products and services.

Contractors fill a vital role in OPM operations and they too have a responsibility to protect the information they access. Contractors must adhere to the same rules and regulations as

government employees to ensure the security of the information in their charge.

The SO shall ensure:

• Providers of external information system services employ adequate security controls in accordance with applicable laws, Executive Orders, directives, policies, regulations, standards and guidance (Reference CA-6).

• Government oversight and user roles and responsibilities with regard to external information system services is defined and documented.

• Security control compliance is monitored.

5.4.10 Developer Configuration Management (SA-10)

It is important that information system configuration management plans are developed and maintained to control changes to the system during design, development, implementation, and operation.

The SO shall ensure requirement of information system developers/integrators to:

• Perform configuration management during information system design, development, implementation, and operation;

• Manage and control changes to the information system;

• Implement only organization-approved changes;

• Document approved changes to the information system; and

• Track security flaws and flaw resolution. (Moderate and High) 5.4.11 Developer Security Testing (SA-11)

The SO shall require that information system developers/integrators, in consultation with associated security personnel (including security engineers):

• Create and implement a security test and evaluation plan;

• Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and

• Document the results of the security testing/evaluation and flaw remediation processes.

Developmental security test results are used to the greatest extent feasible after verification of the results. In addition, recognizing that these results are impacted whenever there have been

security-relevant modifications to the information system subsequent to developer testing. Test results may be used in support of the security authorization process for the delivered information system.

5.4.12 Supply Chain Protection (SA-12)

The SO shall ensure protection against supply chain threats by employing the use of information technology procurement procedures and approved federal acquisition contracts as part of a comprehensive, defense-in-breadth information security strategy. (High)

Examples to reduce supply chain threats include:

• Stockpiling information system components and spares to avoid the need to use less trustworthy secondary or resale markets in future years.

• Reviewing supplier claims with regard to the use of appropriate security processes in the development and manufacture of information system components or products.

• Using trusted shipping and warehousing to reduce opportunities for subversive activities or interception during transit, such as using geographically aware beacons to track shipment diversions or delays.

• Using a diverse set of suppliers for information systems, information system components, information technology products, and information system services.

• Employing standard configurations for information systems, information system components, and information technology products.

• Minimizing the time between purchase decisions and required delivery of information systems, information system components, and information technology products, the organization limits the opportunity for an adversary to corrupt the purchased system, component, or product.

• Performing independent analysis and penetration testing against delivered information systems, information system components, and information technology products.

A defense-in-breadth approach helps to protect information systems (including the information technology products that compose those systems) throughout the system development life cycle (SDLC) (i.e., during design and development, manufacturing, packaging, assembly, distribution, system integration, operations, maintenance, and retirement). This is accomplished by the identification, management, and elimination of vulnerabilities at each phase of the life cycle and the use of complementary, mutually reinforcing strategies to mitigate risk.

5.4.13 Trustworthiness (SA-13)

The intent of this control is to ensure that organizations recognize the importance of

trustworthiness and making explicit trustworthiness decisions when designing, developing, and implementing organizational information systems. Trustworthiness is a characteristic or

property of an information system that expresses the degree to which the system can be expected to preserve the confidentiality, integrity, and availability of the information being processed, stored, or transmitted by the system.

Trustworthy information systems are systems that are capable of being trusted to operate within defined levels of risk despite the environmental disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of operation. Two factors affecting the trustworthiness of an information system include: (i) security functionality (i.e., the security features or functions employed within the system); and (ii) security assurance (i.e., the grounds for confidence that the security functionality is effective in its application).

Appropriate security functionality for the information system can be obtained by using the Risk Management Framework(RMF) (Steps 1, 2, and 3) to select and implement the necessary management, operational, and technical security controls necessary to mitigate risk to organizational operations and assets, individuals, other organizations, and the Nation.

Appropriate security assurance can be obtained by: (i) the actions taken by developers and implementers of security controls with regard to the design, development, implementation, and operation of those controls; and (ii) the actions taken by assessors to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system.

The SO shall ensure information systems meet a level of trustworthiness (determined through acquisition, security engineering principles, security function isolation, risk assessment, Security Assessment and Authorization, and continuous monitoring) equivalent to the Federal Information Processing Standard (FIPS 199) security categorization and acceptable to the Authorizing Official (AO), Chief Information Security Officer (CISO), and CIO. (High)