Back

Develop systems in accordance with the system design specifications and system design standards.


CONTROL ID
01094
CONTROL TYPE
Systems Design, Build, and Implementation
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Initiate the System Development Life Cycle development phase or System Development Life Cycle build phase., CC ID: 06267

This Control has the following implementation support Control(s):
  • Establish, implement, and maintain outsourced development procedures., CC ID: 01141
  • Protect stored manufacturing components prior to assembly., CC ID: 12248
  • Develop new products based on best practices., CC ID: 01095


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • AIs should put in place an adequate level of application system security in respect of their Internet banking system, including any Apps, covering at least application design and development, testing and implementation. In this connection, AIs should make reference to industry sound practices on app… (§ 5.3.1, Hong Kong Monetary Authority Supervisory Policy Manual TM-E-1 Risk Management of E-Banking, v.2)
  • AIs should put in place an adequate level of application system security in respect of their Internet banking system, including any Apps, covering at least application design and development, testing and implementation. In this connection, AIs should make reference to industry sound practices on app… (§ 5.3.1, Hong Kong Monetary Authority Supervisory Policy Manual TM-E-1 Risk Management of E-Banking, V.3)
  • AIs should adopt and implement a full project life cycle methodology governing the process of developing, implementing and maintaining major computer systems. In general, this should involve phases of project initiation, feasibility study, requirement definition, system design, program development, … (4.2.1, Hong Kong Monetary Authority: TM-G-1: General Principles for Technology Risk Management, V.1 – 24.06.03)
  • The FI should ensure secure coding, source code review and application security testing standards are applied during Agile software development. (§ 6.2.2, Technology Risk Management Guidelines, January 2021)
  • The organization should follow the Open Web Application Security Project guide to build secure web applications and web services. (Control: 0971, Australian Government Information Security Manual: Controls)
  • Sound practice is to establish a formal policy to govern end-user developed/configured software. The policy would clearly articulate under what circumstances end-user developed/configured software is appropriate, as well as expectations regarding life-cycle management controls including information … (59., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • Appropriate processes shall be defined for application development which contain specifications for identifying requirements, for the development objective, for (technical) implementation (including coding guidelines), for quality assurance, and for testing, approval and release. (II.6.36, Circular 10/2017 (BA): Supervisory Requirements for IT in Financial Institutions, 14.09.2018)
  • Ensure that automated functionality is developed in accordance with design specifications, development and documentation standards, QA requirements, and approval standards. Ensure that all legal and contractual aspects are identified and addressed for application software developed by third parties. (AI2.7 Development of Application Software, CobiT, Version 4.1)
  • Adopt and maintain standards for all development and acquisition that follow the life cycle of the ultimate deliverable, and include sign-off at key milestones based on agreed-upon sign-off criteria. Consider software coding standards; naming conventions; file formats; schema and data dictionary des… (PO8.3 Development and Acquisition Standards, CobiT, Version 4.1)
  • Obtain and review policies to confirm code reviews are developed according to secure Coding guidelines. (§ 6.3.2.b Bullet 2, Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 2.0)
  • Obtain and review software development processes for any web-based applications. (§ 6.5.a, Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 2.0)
  • Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques. (§ 6.5.b, Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 2.0)
  • Examine the written software development processes to verify that software applications are developed in accordance with the Payment Card Industry Data Security Standard. (Testing Procedures § 6.3.c, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures - Testing Procedures, 3)
  • Obtain and review policies to confirm code reviews are developed according to secure coding guidelines. (§ 6.3.2.b Bullet 2 Testing Procedures, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 2.0)
  • Obtain and review software development processes for any web-based applications. (§ 6.5.a Testing Procedures, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 2.0)
  • Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques. (§ 6.5.b Testing Procedures, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 2.0)
  • Internal software applications and external software applications, including web-based administrative access to applications, must be developed in accordance with the Payment Card Industry Data Security Standard. (PCI DSS Requirements § 6.3 Bullet 1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.0)
  • Develop and maintain secure systems and applications. (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.1 April 2015)
  • Develop and maintain secure systems and applications. (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, v3.2.1)
  • Develop and maintain secure systems and applications. (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2)
  • Develop and maintain secure systems and applications (Requirement 6:, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire A-EP and Attestation of Compliance, Version 3.1)
  • Develop and maintain secure systems and applications (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire A-EP and Attestation of Compliance, Version 3.2)
  • Develop and maintain secure systems and applications (Requirement 6:, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire B-IP and Attestation of Compliance, Version 3.1)
  • Develop and maintain secure systems and applications (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire B-IP and Attestation of Compliance, Version 3.2)
  • Develop and maintain secure systems and applications (Requirement 6:, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.1)
  • Develop and maintain secure systems and applications (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.2)
  • Develop and maintain secure systems and applications (Requirement 6:, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C-VT and Attestation of Compliance, Version 3.1)
  • Develop and maintain secure systems and applications (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C-VT and Attestation of Compliance, Version 3.2)
  • Develop and maintain secure systems and applications (Requirement 6:, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.1)
  • Are software applications developed in accordance with PCI DSS (for example, secure authentication and logging)? (6.3 (c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.1)
  • Develop and maintain secure systems and applications (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
  • Develop and maintain secure systems and applications (Requirement 6:, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.1)
  • Develop and maintain secure systems and applications (Requirement 6, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
  • Internal and external web payment applications should be developed based on secure coding guidelines, such as the Open Web Application Security Project guidelines. Developers should ensure the following common coding vulnerabilities do not exist in any applications: cross-site scripting (XSS) [all p… (§ 5.2 thru § 5.2.10, Payment Card Industry (PCI) Payment Application Data Security Standard, Version 1.1)
  • Standards should be adopted for systems development processes. These standards should apply to designing, developing, testing, implementing, and maintaining programs and systems when the organization develops their own applications. For outsourced application development or acquiring new systems, ag… (§ 5.3.2 ¶ 3, IIA Global Technology Audit Guide (GTAG) 1: Information Technology Controls)
  • Internal programming projects need to be overseen and managed to prevent errors in the programs from impacting the integrity of key systems. (§ 3.1, IIA Global Technology Audit Guide (GTAG) 4: Management of IT Auditing)
  • During system development lifecycle (SDLC) audits, ensure defined coding standards are used for all software programming. (§ 3 (Application Development) ¶ 4, IIA Global Technology Audit Guide (GTAG) 7: Information Technology Outsourcing)
  • Quality Assurance of the system development methodology should include confirming that individuals responsible for developing systems under development are following the methodology. (CF.17.03.02d-1, The Standard of Good Practice for Information Security)
  • The security architecture shall be used throughout the organization to help minimize the diversity of hardware / software in use. (CF.08.01.06a, The Standard of Good Practice for Information Security)
  • The security architecture shall be used throughout the organization to help provide consistent security functionality across different hardware / software platforms. (CF.08.01.06b, The Standard of Good Practice for Information Security)
  • The security architecture should be used throughout the organization to help standardize user provisioning and Access Control to internal business applications (e.g., using Identity and Access Management) and external business applications (e.g., using federated Identity and Access Management). (CF.08.01.06c, The Standard of Good Practice for Information Security)
  • The security architecture shall be used throughout the organization to help integrate security controls at application, computer and network level. (CF.08.01.06d, The Standard of Good Practice for Information Security)
  • The security architecture shall be used throughout the organization to help apply consistent cryptographic techniques. (CF.08.01.06e, The Standard of Good Practice for Information Security)
  • The security architecture shall be used throughout the organization to help implement common naming conventions. (CF.08.01.06f, The Standard of Good Practice for Information Security)
  • The security architecture shall be used throughout the organization to help control the flow of information between different environments. (CF.08.01.06h, The Standard of Good Practice for Information Security)
  • The security architecture shall be applied to the development of business applications (e.g., to help manage complexity and scale, make effective design decisions, and improve the quality and security of business applications). (CF.08.01.07a, The Standard of Good Practice for Information Security)
  • The security architecture shall be applied to help manage the technical infrastructure (e.g., to help in the development of a secure technical infrastructure, and assist in the review and analysis of the existing technical infrastructure). (CF.08.01.07b, The Standard of Good Practice for Information Security)
  • The security architecture shall be applied to major Information Technology projects (e.g., to help deal with complexity, new information risks, and large scale environments). (CF.08.01.07c, The Standard of Good Practice for Information Security)
  • The systems development lifecycle should cover building the desktop application. (CF.17.01.02-3, The Standard of Good Practice for Information Security)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customisation of packages, and defining data structures), which specify mechanisms for ensuring systems comply with good practice for system build (e.g., the use of structured programming… (CF.18.03.01b, The Standard of Good Practice for Information Security)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customization of packages, and defining data structures), which specify approved methods of building systems (e.g., defining competence levels for staff writing or reviewing code, customi… (CF.18.03.01a, The Standard of Good Practice for Information Security)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customization of packages, and defining data structures), which specify methods of managing the use of code samples (e.g., defining acceptable sources for developers to obtain sample code… (CF.18.03.01c, The Standard of Good Practice for Information Security)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customization of packages, and defining data structures), which specify 'secure' methods of making changes to the base code of software packages. (CF.18.03.01d, The Standard of Good Practice for Information Security)
  • Quality Assurance of the system development methodology should include confirming that individuals responsible for developing systems under development are following the methodology. (CF.17.03.02d-1, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be used throughout the organization to help minimize the diversity of hardware / software in use. (CF.08.01.06a, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be used throughout the organization to help provide consistent security functionality across different hardware / software platforms. (CF.08.01.06b, The Standard of Good Practice for Information Security, 2013)
  • The security architecture should be used throughout the organization to help standardize user provisioning and Access Control to internal business applications (e.g., using Identity and Access Management) and external business applications (e.g., using federated Identity and Access Management). (CF.08.01.06c, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be used throughout the organization to help integrate security controls at application, computer and network level. (CF.08.01.06d, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be used throughout the organization to help apply consistent cryptographic techniques. (CF.08.01.06e, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be used throughout the organization to help implement common naming conventions. (CF.08.01.06f, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be used throughout the organization to help control the flow of information between different environments. (CF.08.01.06h, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be applied to the development of business applications (e.g., to help manage complexity and scale, make effective design decisions, and improve the quality and security of business applications). (CF.08.01.07a, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be applied to help manage the technical infrastructure (e.g., to help in the development of a secure technical infrastructure, and assist in the review and analysis of the existing technical infrastructure). (CF.08.01.07b, The Standard of Good Practice for Information Security, 2013)
  • The security architecture shall be applied to major Information Technology projects (e.g., to help deal with complexity, new information risks, and large scale environments). (CF.08.01.07c, The Standard of Good Practice for Information Security, 2013)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customisation of packages, and defining data structures), which specify mechanisms for ensuring systems comply with good practice for system build (e.g., the use of structured programming… (CF.18.03.01b, The Standard of Good Practice for Information Security, 2013)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customization of packages, and defining data structures), which specify approved methods of building systems (e.g., defining competence levels for staff writing or reviewing code, customi… (CF.18.03.01a, The Standard of Good Practice for Information Security, 2013)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customization of packages, and defining data structures), which specify methods of managing the use of code samples (e.g., defining acceptable sources for developers to obtain sample code… (CF.18.03.01c, The Standard of Good Practice for Information Security, 2013)
  • There should be documented standards / procedures for building systems (e.g., program coding, web page creation, customization of packages, and defining data structures), which specify 'secure' methods of making changes to the base code of software packages. (CF.18.03.01d, The Standard of Good Practice for Information Security, 2013)
  • During a new system-build process, patches should be implemented on all Internet-facing machines to ensure they are configured securely before they are connected to the Internet. (Action 1.1.1 ¶ 2, SANS Computer Security Incident Handling, Version 2.3.1)
  • The documented design shall be used to develop the new or changed services. (§ 5.3 ¶ 3, ISO 20000-1, Information Technology - Service Management - Part 1: Service Management System Requirements, Second Edition)
  • Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts. (A.14.2.5 Control, ISO 27001:2013, Information Technology - Security Techniques - Information Security Management Systems - Requirements, 2013)
  • For software systems assigned to Class A, Class B, and Class C software safety classes, the medical device manufacturer shall reference the system requirements in the software development plan. (§ 5.1.3(a), ISO 62304 - 2006 Medical device software - Software life cycle processes, 2006)
  • Principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation efforts. (§ 14.2.5 Control, ISO/IEC 27002:2013(E), Information technology — Security techniques — Code of practice for information security controls, Second Edition)
  • All of the components defined in this document shall be developed and supported following the secure product development processes described in ISA‑62443‑4‑1[12]. (4.5 ¶ 1, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
  • Requires the developer of the information system, system component, or information system service to follow a documented development process that: (SA-15a., StateRAMP Security Controls Baseline Summary High Sensitivity Level, Version 1.1)
  • The organization must ensure that systems security is maintained during the development phase as well as the deployment and maintenance phases. (PE 9, Corporate Information Security Working Group: Report of the best practices and metrics teams; subcommittee on technology, information policy, intergovernmental relations and the census; Government Reform Committee, United States House of Representatives)
  • When application development is performed, does it provide a formal application methodology (Open Web Application Security Project)? (§ I.2.2, Shared Assessments Standardized Information Gathering Questionnaire - I. Information Systems Acquisition Development & Maintenance, 7.0)
  • For cloud computing services, is there a formal development methodology in operation? (§ V.1.22, Shared Assessments Standardized Information Gathering Questionnaire - V. Cloud, 7.0)
  • For cloud computing services, does the formal development methodology include waterfall? (§ V.1.22.1, Shared Assessments Standardized Information Gathering Questionnaire - V. Cloud, 7.0)
  • For cloud computing services, does the formal development methodology include agile? (§ V.1.22.2, Shared Assessments Standardized Information Gathering Questionnaire - V. Cloud, 7.0)
  • For cloud computing services, does the formal development methodology include other methods? (§ V.1.22.3, Shared Assessments Standardized Information Gathering Questionnaire - V. Cloud, 7.0)
  • § 1194.21(a): Software designed to run on systems that have keyboards shall be able to execute functions from the keyboard, if the function/result of performing the function can be seen textually. § 1194.21(b): Applications shall not disrupt or disable activated accessibility features from other p… (§ 1194.21(a), § 1194.21(b), 36 CFR Part 1194 Electronic and Information Technology Accessibility Standards)
  • If the development workstations are NIPRNet connected, as with the production application, STIGed Government Furnished Equipment (GFE) must be used to manage the environment and test the application. A remote terminal solution may be used (e.g., Citrix, Terminal Services (bastion host)). A VPN is on… (Section 5.14.1 ¶ 1 Bullet 2, sub-bullet 1, sub sub-bullet 1, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • Securely designs, builds, and operates databases. (App A Objective 3:6a, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • Evaluate the adequacy of development activities by assessing: ▪ The adequacy of, and adherence to, development standards and controls; ▪ The applicability and effectiveness of project management methodologies; ▪ The experience of project managers; ▪ The adequacy of project plans, particularl… (Exam Obj 5.1, FFIEC IT Examination Handbook - Development and Acquisition)
  • Management should develop procedures specifying the controls needed for the development and acquisition of software. The Management Information System (MIS) should be designed to manage the business; provide timely, accurate, complete, and relevant information; support the strategic goals; ensure th… (Pg 13, Pg 31, FFIEC IT Examination Handbook - Management)
  • Requires the developer of the information system, system component, or information system service to follow a documented development process that: (SA-15a. High Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., FedRAMP Security Controls High Baseline, Version 5)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., FedRAMP Security Controls Moderate Baseline, Version 5)
  • Management should design the entity’s information system and related control activities to achieve objectives and respond to risks. (11.01, Standards for Internal Control in the Federal Government)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., Control Baselines for Information Systems and Organizations, NIST SP 800-53B, High Impact Baseline, October 2020)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., Control Baselines for Information Systems and Organizations, NIST SP 800-53B, Moderate Impact Baseline, October 2020)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161, Revision 1, Appendix A, C-SCRM Level 2 Controls)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161, Revision 1, Appendix A, C-SCRM Level 3 Controls)
  • Verify that the acquisition, development, and use of mobile code to be deployed in the system meets [Assignment: organization-defined mobile code requirements]. (SC-18(2) ¶ 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161, Revision 1, Appendix A, C-SCRM Level 3 Controls)
  • The organization shall implement the cryptographic algorithm and a law enforcement access field (LEAF) creation method in an electronic device that is highly resistant to someone obtaining or modifying the cryptographic algorithm, the device unique identifier (UID), the device unique key (KU), the c… (§ 5 ¶ 1, FIPS Pub 185, Escrowed Encryption Standard (EES))
  • Requires the developer of the information system, system component, or information system service to follow a documented development process that: (SA-15a. High Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • Develop architectures or system components consistent with technical specifications. (T0067, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Follow software and systems engineering life cycle standards and processes. (T0329, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Translate functional requirements into technical solutions. (T0235, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Design hardware, operating systems, and software applications to adequately address requirements. (T0447, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Implement designs for new or existing system(s). (T0488, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Design, implement, test, and evaluate secure interfaces between information systems, physical systems, and/or embedded technologies. (T0359, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Follow recommended security practices to deploy, operate, and maintain tools and toolchains. (PO.3.2, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
  • The organization must apply security engineering principles to the specification, design, development, and implementation of the smart grid Information System. (SG.SA-8 Requirement ¶ 1, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • Develop architectures or system components consistent with technical specifications. (T0067, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Translate functional requirements into technical solutions. (T0235, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Implement designs for new or existing system(s). (T0488, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Follow software and systems engineering life cycle standards and processes. (T0329, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Design hardware, operating systems, and software applications to adequately address requirements. (T0447, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Develop enterprise architecture or system components required to meet user needs. (T0448, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Design, implement, test, and evaluate secure interfaces between information systems, physical systems, and/or embedded technologies. (T0359, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • The organization requires the developer of the information system, system component, or information system service to follow a documented development process that documents, manages, and ensures the integrity of changes to the process and/or tools used in development. (SA-15a.4., Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Deprecated, Revision 4, Deprecated)
  • The organization requires the developer of the information system, system component, or information system service to follow a documented development process that documents, manages, and ensures the integrity of changes to the process and/or tools used in development. (SA-15a.4., Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, High Impact Baseline, Deprecated, Revision 4, Deprecated)
  • Requires the developer of the information system, system component, or information system service to follow a documented development process that: (SA-15a., Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, High Impact Baseline, Revision 4)
  • Requires the developer of the information system, system component, or information system service to follow a documented development process that: (SA-15a., Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • The organization ensures that the acquisition, development, and use of mobile code to be deployed in the information system meets [Assignment: organization-defined mobile code requirements]. (SC-18(2) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Use different designs for [Assignment: organization-defined critical systems or system components] to satisfy a common set of requirements or to provide equivalent functionality. (SA-17(9) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Verify that the acquisition, development, and use of mobile code to be deployed in the system meets [Assignment: organization-defined mobile code requirements]. (SC-18(2) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Require the developer of the system, system component, or system service to follow a documented development process that: (SA-15a., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Use different designs for [Assignment: organization-defined critical systems or system components] to satisfy a common set of requirements or to provide equivalent functionality. (SA-17(9) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Verify that the acquisition, development, and use of mobile code to be deployed in the system meets [Assignment: organization-defined mobile code requirements]. (SC-18(2) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Requires the developer of the information system, system component, or information system service to follow a documented development process that: (SA-15a., Supply Chain Risk Management Practices for Federal Information Systems and Organizations, NIST Special Publication 800-161, April 2015)
  • The organization ensures that the acquisition, development, and use of mobile code to be deployed in the information system meets [Assignment: organization-defined mobile code requirements]. (SC-18(2) ¶ 1, Supply Chain Risk Management Practices for Federal Information Systems and Organizations, NIST Special Publication 800-161, April 2015)