Development/Acquisition Phase

Description

Key security activities for this phase include:

Conduct the risk assessment and use the results to supplement the baseline security controls;
Analyze security requirements;
Perform functional and security testing;
Prepare initial documents for system certification and accreditation; and
Design security architecture.

Although this section presents the information security components in a sequential top-down manner, the order of completion is not necessarily fixed. Security analysis of complex systems will need to be iterated until consistency and completeness is achieved.

Control Gates

An Architecture/Design Review that evaluates the planned system design and potential integration with other systems as well as incorporation of shared services and common security controls, such as authentication, disaster recovery, intrusion detection, or incident reporting.
A system Performance Review that evaluates whether the system is delivering, or capable of delivering, to the documented expectation of the owner and whether the system behaves in a predictable manner if it is subjected to improper use. (For example, the ability of the system to maintain availability and data integrity at the expected extreme resource loads.)
A system Functional Review that ensures functional requirements identified are sufficiently detailed and are testable.
Mid-Project Status & Financial Review is important to detect major shifts in planned level of effort to ensure cost-benefit ratios are monitored and effective decisions are continued.
A follow-on review of risk management decisions may be needed if, due to the aforementioned reviews, the system and/or its security controls and/or its requirements change.

Major Security Activities

Assess Risk to System

Agencies should consult NIST SP 800-30, Risk Management Guide for Information Technology Systems, for guidance on conducting risk assessments.

The purpose of a risk assessment is to evaluate current knowledge of the system’s design, stated requirements, and minimal security requirements derived from the security categorization process to determine their effectiveness to mitigate anticipated risks. Results should show that specified security controls provide appropriate protections or highlight areas where further planning is needed. To be successful, participation is needed from people who are knowledgeable in the disciplines within the system domain (e.g., users, technology experts, operations experts). The security risk assessment should be conducted before the approval of design specifications as it may result in additional specifications or provide further justification for specifications.

In addition to considering the security perspective of the system being developed/ acquired, organizations should also consider how the system might affect other systems to which it will be directly or indirectly connected. This may mean that there are inherited common controls to leverage or additional risks that need to be mitigated. In these cases, an enterprise review may be needed to provide a more comprehensive view of threats and vulnerabilities.

A refined risk assessment based on a more mature system design that more accurately reflects the potential risk to the system, known weaknesses in the design, identified project constraints, and known threats to both business and IT components. In addition, previous requirements are now transitioning into system specific controls.

Since this risk assessment is completed at a more mature stage of system development, there may be a need to revisit previously completed security steps, such as BIA or Security Categorization. Development rarely goes as planned, and requirements have a way of changing.

Security categorization provides the initial risk assessment information based on information types.
Additional security controls or compensating controls may be planned or modified based on the risk assessment to ensure required protection for information and information systems.

Implementer’s Tips

Within any organization, the threat from internal sources remains the highest probability of occurrence. Improprieties by employees [system developers] who are also privileged system users are a real threat, especially since such employees may have active accounts within the system. Practices should include independent audits of the system and its supporting processes. Continuously monitoring internal sources and using integrity-based tools to ensure configuration audit and control may be of use by providing an automated central audit log collection, correlation, and analysis tool.
It is a good idea to monitor the National Vulnerability Database (http://nvd.nist.gov) for known component vulnerabilities and build in controls to mitigate them. These would then need to be tested.
When dealing with a system having multiple owners (sometimes across different domains), it is important to identify and address shared and inherited risks.
Depending on the rigor needed and the complexity of the system, it may be important to follow the data flow/information sharing beyond the first interface. Failure to do so may result in inheriting unknown risks.
Other inherited risks may be evaluated through the supply of materials for the system. Supply chain risk should be understood and evaluated to mitigate potential use of fraudulent, pirated, unlicensed or intentionally compromised material.

Select and Document Security Controls

The selection and documentation of security controls corresponds to step 2 in the NIST Risk Management Framework. The selection of security controls consists of three activities: the selection of baseline security controls (including common security controls); the application of security control tailoring guidance to adjust the initial security control baseline; and the supplementation of the tailored baseline with additional controls based on an assessment of risk and local conditions. An organization-wide view is essential in the security control selection process to ensure that adequate risk mitigation is achieved for all mission/business processes and the information systems and organizational infrastructure supporting those processes.

The security control selection process should include an analysis of laws and regulations, such as FISMA, OMB circulars, agency-enabling acts, agency-specific governance, FIPS and NIST Special Publications, and other legislation and federal regulations that define applicable specifics to the security controls selected.

As with other aspects of security, the goal should be cost-effective implementation that meets the requirements for protection of an organization’s information assets. In each situation, a balance should exist between the system security benefits to mission performance and the risks associated with operation of the system.

The security controls allocated to individual information systems are documented in the system security plan as described in NIST Special Publication 800-18. Security plans provide an overview of the security requirements for the information systems within an organization and describe the security controls in place, or planned, for meeting those requirements. The plans also describe the rationale for security categorization, tailoring, and supplementation activities, how individual controls are implemented within specific operational environments, and any use restrictions to be enforced on information systems due to high-risk situations. Security plans are important because they document the decisions taken during the security control selection process and the rationale for those decisions. They are approved by appropriate authorizing officials within the organization and provide one of the key documents in security accreditation packages that are instrumental in authorization decisions.

System Security Plan – specification of security controls that identify which, where, and how security controls will be applied.

Security controls and associated specifications should reflect appropriate levels of protection to the system in line with the security control selection criteria.
Significant decisions should consider any possible secondary risks that may result should the decision influence previously considered security controls and protections identified during the risk assessment.

Once formulated, security control requirements will be incorporated into the system security plan.
The risk assessment is a primary tool to identify if the tailored security controls are effective to address an organization’s risk tolerance

Implementer’s Tips

Addressing security requirements in a matrix format allows the developers and security engineers to review implementation per major system component and can facilitate gap analysis, ensuring proper risk analysis and control implementation.
Information security requirements should be stated in specific terms. For complex systems, iterations of the requirements analysis may be needed. If so, planned reviews should occur at major SDLC milestones.
Any new functional requirement may have security implications. Introducing additional risk or weakening existing security controls is more likely if a specific security analysis is not performed for each added functional requirement. Then it is possible for undocumented risk to enter the system.
More detailed “attack prevention” requirements will also help to ensure that security controls and methods are tested prior to release. If a documented requirement exists, then it is assumed that a test case will need to be developed and executed.
Security controls are not one-dimensional and should be addressed as appropriately on multiple components throughout the system. For example, if your system is composed of SQL servers, Web Sphere, and a mainframe, then assessments may need to be planned for all, some, or none, depending on the system. Documenting this during this stage decreases the level of effort during testing.
Agencies should initiate disposition planning during this phase and plan for disposal/transition throughout all phases of the life cycle. This activity is best done as part of the requirements phase so full resource requirements for disposal are understood and planned for. Disposition procedures can provide value throughout the life cycle, as hardware and software becomes obsolete or damaged in other phases.

Design Security Architecture

With the increase in shared service providers and the centralization of some key security services within agencies, it is becoming more important to plan these services and understand how they will be integrated into the system.

An enterprise alignment of the system should ensure that the initiative fits the agency’s future plans and does not conflict or unnecessarily provide redundant services. In addition, as the system matures and more decisions are made as to services utilized, the EA should be reviewed for optimal integration. At the system level, security should be architected and then engineered into the design of the system. This may be accomplished by zoning or clustering services either together or distributed for either redundancy or additional layers of protection. Security designing at the system level should take into consideration services obtained externally, planned system interconnections, and the different orientations of system users (e.g., customer service versus system administrators).

Another example would be a system auditing strategy that should be developed to enable an accurate trace or reconstruction of all priority and high-risk work flows. The audit strategy should include various audit records from several different components including (but not limited to) the Web application, databases, mainframe, and Web servers. The goal should not be to capture as much audit information as possible but to capture only what is needed to provide enough information to investigate potential security breaches and system failures.

This activity may be performed when reviewing from an IT development view the known bottlenecks and single points of failures. Minimal security requirements as well as requirements and constraints determined early in the process should provide the architects with a set of assumptions and constraints to build around.

This activity can provide the most value for the system in lowering the total cost of ownership by planning the systems core components in a secure way.

Schematic of security integration providing details on where, within the system, security is implemented and shared. Security architectures should be graphically depicted and detailed to the extent the reader can see where the core security controls are applied and how.
Listing of shared services and resulting shared risk.
Identification of common controls used by the system.

The security architecture becomes a key component of the system documentation that should be reviewed and maintained as major changes or significant control gates (milestones) are reached.
Significant results from assessments, security testing, and reviews should be examined for potential feedback on effectiveness.

Enterprise Architecture should provide insights into other like systems or services where integration is optimal.
System security plans will document the summary of the security architecture approach or strategy.
Security requirements analysis will provide the majority of the information at the detailed level. This will enable the architect to review the information, apply it theoretically at the system level, and determine if the controls will work as intended or if there are gaps or unnecessary redundancy.

Implementer’s Tips

Security architecting can provide effective compensating controls when there are issues with implementing minimal security requirements with the system’s design specification. Security architectures will also identify common controls that the system will inherit as well as who has responsibility for those common controls.
Demonstrating the logic behind the security of this system will help in determining the need for additional controls.
Risks accepted by the system that may have downstream, adverse affects on the enterprise can be identified and raised as issues during the architectural review. Enterprise risk culminating from all individual system risk should be expressed and tracked through the agency Enterprise Architecture process.

Engineer in Security and Develop Controls

During this stage, security controls are implemented and become part of the system rather than applied at completion. Applying security controls in development should be considered carefully and planned logically. The intent is to integrate the controls so that challenges with system performance are known early. Additionally, some security controls may limit or hinder normal development activities.

For new information systems, the security requirements identified and described in the respective system security plans are now designed, developed, and implemented. The system security plans for operational information systems may require the development of additional security controls to supplement in-place controls or the modification of controls that are deemed to be less than effective.

During this task, decisions are made based on integration challenges and trade-offs. It is important to document the major decisions and their business/technology drivers. In cases where the application of a planned control is not possible or advisable, compensating controls should be considered and documented.

Implemented controls with documented specification for inclusion into the security plan.
List of security control variations resulting from development decisions and tradeoffs.
Potential assessment scenarios to test known vulnerabilities or limitations.

Security control application may undergo changes as a result of functional and user testing. Changes should be documented.

Security requirements analysis should be reviewed and updated if change is needed.
Security architecture strategy should be reviewed and updated if change is needed.
Specific configurations should be documented or referenced in the system security plan.

Implementer’s Tips

Documenting security deviations from initial security requirements at this stage will encourage solid risk planning and reduce time later in backtracking business justifications. In addition, it demonstrates evidence of risk planning.

Develop Security Documentation

While the most prominent document is the System Security Plan, documentation supporting it may include:

Configuration management plan
Contingency plan (including a Business Impact Assessment)
Continuous monitoring plan
Security awareness, training and education (SATE) plan
Incident response plan
Privacy impact assessment (PIA)

Development of these documents should consider the maturity of the security services being documented. In some cases, these documents may contain only known requirements, common controls, and templates. Filling in these documents should begin as early as possible during the project.

At this stage, it is important to solidify the security approach, the proper scope, and an understanding of responsibilities. For example, the DR plan may be covered by the connected General Support System, and SATE may be outsourced to a shared service provider. In this case, the plans may focus on the system specifics and may reference key points from an in-place service-level agreement.

Documenting as the system development progresses can provide cost savings and enhance decision-making capabilities through a comprehensive approach that allows early detection of gaps.

Additional security documentation supporting the system security plan.

These documents will need to be updated toward the end of user acceptance testing to ensure that they are accurate.

System security documentation should align with:

Security requirements analysis
Security architecture
Business impact assessment, and
Security categorization.

Implementer’s Tips

Security operations should not be driven by documentation of compliance but based on system need and described in compliance with security guidance.
For major systems that are large in size, complex in design, or politically sensitive, it is best to assign a point of contact POC) to each document and initiate development with a meeting on the document’s scope, expectations, and level of granularity.

Conduct Testing (Developmental, Functional, and Security)

Systems being developed or undergoing software, hardware, and/or communication modification(s) must be tested and evaluated prior to being implemented. The objective of the test and evaluation process is to validate that the developed system complies with the functional and security requirements. Testing of security controls is based on technical security specifications for those controls supplemented by the assessment procedures detailed in NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems.

The process focuses on specificity, repeatability, and iteration. For specificity, the testing must be scoped to test the relevant security requirement as it is intended for use in its environment. For repeatability, the testing process must be capable of the execution of a series of tests against an information system more than once (or against similar systems in parallel) and yield similar results each time. For iteration, each system will be required to execute functional tests in whole or in part a number of successive times in order to achieve an acceptable level of compliance with the requirements of the system. To achieve this, functional testing will be automated to the degree possible, and the test cases will be published, in detail, to ensure that the test process is repeatable and iterative. The use of automated testing tools and integration of the NIST Security Content Automation Protocol (SCAP) should be accomplished prior to the commencement of security control test and evaluation activities. Any security functionality not tested during the functional or automated testing will be carefully examined to ensure compliance with the requirements during the explicit security control test and evaluation.

Only test or “stub” data should be used during system development. Absolutely no operational, security-relevant, or personally identifiable information (PII) should reside within any system or software during development.

Documentation of test results, including any unexpected variations discovered during testing.

All test results are returned to developers for configuration-managed updates. Unexpected results may require the customer to clarify the nature of the requirement.

Security requirements analysis may be impacted and require updating.
Changes may impact the security architecture and require updating.
The system risk assessment may need updating to accurately reflect current mitigations.

Implementer’s Tips

In an effort to reduce redundant functional and security testing activities, it is recommended that functional test plans include general security features testing (to the greatest extent possible).
Preliminary testing of basic security controls during functional testing may reduce or eliminate issues earlier in the development cycle (e.g., mandatory access controls, secure code development, and firewalls). Preliminary testing is considered development-level testing, not certification and accreditation (C&A) testing but if no changes occur, reuse test results to the maximum extent possible in the C&A.
For systems of high visibility and sensitivity, independent development testing may be recommended.
Preliminary testing enables cost and schedule risk mitigation.
Preliminary testing may be done at component or security zone level to ensure that each component or security zone is secure as an entity.
Capture the process and results of all security testing that occurs throughout the life cycle for evaluation, issue identification, and potential reuse.
Source code should be periodically reviewed using automated tools or manual spot check for common programming errors that have a detrimental impact on system security including: cross-site scripting vulnerabilities, buffer overflows, race conditions, object model violations, poor user input validation, poor error handling, exposed security parameters, passwords in the clear, and violations of stated security policy, models, or architecture as part of the software development QA process.