Back

Implement security controls when developing systems.


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

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Develop new products based on best practices., CC ID: 01095

This Control has the following implementation support Control(s):
  • Include restricted data encryption and restricted information encryption in the security controls., CC ID: 01083
  • Analyze and minimize attack surfaces when developing systems., CC ID: 06828
  • Require successful authentication before granting access to system functionality via network interfaces., CC ID: 14926
  • Audit all modifications to the application being developed., CC ID: 01614
  • Implement a hardware security module, as necessary., CC ID: 12222
  • Establish, implement, and maintain session security coding standards., CC ID: 04584
  • Establish and maintain a cryptographic architecture document., CC ID: 12476


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)
  • It is recommended that equipment and media accumulating electronic value or software contained in it be provided with a function for protecting the value. (P137.1., FISC Security Guidelines on Computer Systems for Financial Institutions, Ninth Edition, Revised March 2020)
  • A bank needs to incorporate information security at all stages of software development. This would assist in improving software quality and minimizing exposure to vulnerabilities. Besides business functionalities, security requirements relating to system access control, authentication, transaction a… (Critical components of information security 11) c.4., Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • Ensuring that the new applications being purchased/developed follow the Information Security policy (Critical components of information security 11) c.2. Bullet 9, Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • All application systems need to be tested before implementation in a robust manner regarding controls to ensure that they satisfy business policies/rules of the bank and regulatory and legal prescriptions/requirements. Robust controls need to be built into the system and reliance on any manual contr… (Critical components of information security 11) c.3., Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • Recovery measures, user access and data protection controls, at the minimum, should be implemented for such applications. (§ 6.4.3, Monetary Authority of Singapore: Technology Risk Management Guidelines)
  • System owners select security controls for each system and tailor them to achieve desired security objectives. (Security Control: 1634; Revision: 0, Australian Government Information Security Manual, March 2021)
  • Platform-specific secure programming practices are used when developing software, including using the lowest privilege needed to achieve a task, checking return values of all system calls, validating all inputs and encrypting all communications. (Security Control: 0401; Revision: 4, Australian Government Information Security Manual, March 2021)
  • System owners select controls for each system and tailor them to achieve desired security objectives. (Control: ISM-1634; Revision: 1, Australian Government Information Security Manual, June 2023)
  • System owners implement controls for each system and its operating environment. (Control: ISM-1635; Revision: 2, Australian Government Information Security Manual, June 2023)
  • System owners select controls for each system and tailor them to achieve desired security objectives. (Control: ISM-1634; Revision: 1, Australian Government Information Security Manual, September 2023)
  • System owners implement controls for each system and its operating environment. (Control: ISM-1635; Revision: 2, Australian Government Information Security Manual, September 2023)
  • The system owner must implement the system controls before beginning the second stage of the audit. (Control: 0084, Australian Government Information Security Manual: Controls)
  • The design and implementation of security controls should be stated in the information technology security Risk Management Framework. The organization should use the sensitivity and criticality of the involved asset to determine the needed strength for the Information Technology controls. (¶ 23, APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
  • The organization should consider information technology security during all software development stages. (¶ 57, APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
  • An APRA-regulated entity would typically implement secure software development and acquisition techniques to assist in maintaining confidentiality, integrity and availability by improving the general quality and vulnerability profile of the software (refer to Attachment D for further guidance). (48., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • As the first phases of an information asset life-cycle, planning and design controls would typically be in place to ensure that information security is incorporated within the information assets of the APRA-regulated entity, the solutions implemented would typically comply with the information secur… (35., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • The IT security risk management framework would typically enable the design and implementation of the IT security controls. The strength of controls would normally be commensurate with the criticality and sensitivity of the IT asset involved. (¶ 23, APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • Are all user workstations built from a fully hardened base platform to ensure consistency and security across the estate? (Secure configuration Question 16, Cyber Essentials Scheme (CES) Questionnaire, Versions 3.3)
  • security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; (Article 21 2(e), DIRECTIVE (EU) 2022/2555 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive))
  • supporting academic and research institutions to develop, enhance and promote the deployment of cybersecurity tools and secure network infrastructure; (Article 7 2(g), DIRECTIVE (EU) 2022/2555 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive))
  • Allowing the property to be able to securely operate the service on different it platforms as well as the possibility of securely connecting different it platforms and terminating the service. (Section 5.10 Objective, Cloud Computing Compliance Controls Catalogue (C5))
  • Services should be designed and developed to identify and mitigate threats to their security. Those which aren't may be vulnerable to security issues which could compromise your data, cause loss of service or enable other malicious activity. (7. ¶ 1, Cloud Security Guidance, 1.0)
  • Services should be designed and developed to identify and mitigate threats to their security. (7: ¶ 1, Cloud Security Guidance, 1.0)
  • Cloud services should be designed, developed and deployed in a way that minimises and mitigates threats to their security. (7. ¶ 1, Cloud Security Guidance, 2)
  • Identify assurance tasks required to support the accreditation of new or modified systems during project planning, and include them in the integrated project plan. The tasks should provide assurance that internal controls and security features meet the defined requirements. (PO10.12 Project Planning of Assurance Methods, CobiT, Version 4.1)
  • Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes (§ 6.5, 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 by incorporating Information Security throughout the software development lifecycle. (PCI DSS Requirements § 6.3 Bullet 3, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.0)
  • Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: - In accordance with PCI DSS (for example, secure authentication and logging) - Based on industry standards and/or best practices. - Incorporating information securit… (6.3, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.1 April 2015)
  • Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: - In accordance with PCI DSS (for example, secure authentication and logging) - Based on industry standards and/or best practices. - Incorporating information securit… (6.3, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, v3.2.1)
  • Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: - In accordance with PCI DSS (for example, secure authentication and logging) - Based on industry standards and/or best practices. - Incorporating information securit… (6.3, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2)
  • Examine written software-development processes to verify that information security is included throughout the life cycle. (6.3.b, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • Interview software developers to verify that written software-development processes are implemented. (6.3.d, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • Security measures are taken during the development and maintenance of HSM security related components. The manufacturer must maintain development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the … (D7, Payment Card Industry (PCI), PIN Transaction Security (PTS) Hardware Security Module (HSM) - Security Requirements, Version 2.0)
  • Security measures are taken during the development and maintenance of device's security related components. The manufacturer must maintain development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of… (I7, Payment Card Industry (PCI), PIN Transaction Security (PTS) Hardware Security Module (HSM) - Security Requirements, Version 3.0)
  • Incorporating consideration of information security issues during each stage of the software development lifecycle. (6.2.1 Bullet 3, Payment Card Industry Data Security Standard Requirements and Testing Procedures, Defined Approach Requirements, Version 4.0)
  • Is information security included throughout the software development lifecycle? (PCI DSS Question 6.3(b), PCI DSS Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.0)
  • Is information security included throughout the software development lifecycle? (PCI DSS Question 6.3(b), PCI DSS Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.0)
  • Incorporating consideration of information security issues during each stage of the software development lifecycle. (6.2.1 Bullet 3, Self-Assessment Questionnaire D for Merchants and Attestation of Compliance for use with PCI DSS Version 4.0)
  • Incorporating consideration of information security issues during each stage of the software development lifecycle. (6.2.1 Bullet 3, Self-Assessment Questionnaire D for Service Providers and Attestation of Compliance for use with PCI DSS Version 4.0)
  • Security architecture principles shall be applied when developing and implementing security controls, and include security by design (i.e., considering the security requirements of a business application or Information System as part of its overall requirements, to protect itself and the information… (CF.08.01.04a, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include Defense in Depth (i.e., using multiple layers of different types of protection) to avoid reliance on one type or method of security control. (CF.08.01.04b, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include Secure by Default (i.e., setting preselected options to limit the level of inherent vulnerability, such as providing least privilege (e.g., only granting the minimum possible access priv… (CF.08.01.04c, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include default deny (i.e., denying access to Information Systems by default to prevent unauthorized access). (CF.08.01.04d, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include fail secure (i.e., in the event of a system failure, information is not accessible to unauthorized individuals, and cannot be tampered with or modified). (CF.08.01.04e, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include secure in deployment (e.g., by providing complementary tools and guidance to help support System Administrators and users, ensuring configuration is not difficult and software updates ar… (CF.08.01.04f, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include usability and manageability (i.e., security controls should not obstruct users in performing their work and should not be difficult to manage). (CF.08.01.04g, The Standard of Good Practice for Information Security)
  • When building systems development tools, such as integrated development environments, should be configured to help enforce the creation of secure code. (CF.18.03.03c, The Standard of Good Practice for Information Security)
  • Security architecture principles shall be applied when developing and implementing security controls, and include security by design (i.e., considering the security requirements of a business application or Information System as part of its overall requirements, to protect itself and the information… (CF.08.01.04a, The Standard of Good Practice for Information Security, 2013)
  • Security architecture principles shall be applied when developing and implementing security controls, and include Defense in Depth (i.e., using multiple layers of different types of protection) to avoid reliance on one type or method of security control. (CF.08.01.04b, The Standard of Good Practice for Information Security, 2013)
  • Security architecture principles shall be applied when developing and implementing security controls, and include Secure by Default (i.e., setting preselected options to limit the level of inherent vulnerability, such as providing least privilege (e.g., only granting the minimum possible access priv… (CF.08.01.04c, The Standard of Good Practice for Information Security, 2013)
  • Security architecture principles shall be applied when developing and implementing security controls, and include default deny (i.e., denying access to Information Systems by default to prevent unauthorized access). (CF.08.01.04d, The Standard of Good Practice for Information Security, 2013)
  • Security architecture principles shall be applied when developing and implementing security controls, and include fail secure (i.e., in the event of a system failure, information is not accessible to unauthorized individuals, and cannot be tampered with or modified). (CF.08.01.04e, The Standard of Good Practice for Information Security, 2013)
  • Security architecture principles shall be applied when developing and implementing security controls, and include secure in deployment (e.g., by providing complementary tools and guidance to help support System Administrators and users, ensuring configuration is not difficult and software updates ar… (CF.08.01.04f, The Standard of Good Practice for Information Security, 2013)
  • Security architecture principles shall be applied when developing and implementing security controls, and include usability and manageability (i.e., security controls should not obstruct users in performing their work and should not be difficult to manage). (CF.08.01.04g, The Standard of Good Practice for Information Security, 2013)
  • When building systems development tools, such as integrated development environments, should be configured to help enforce the creation of secure code. (CF.18.03.03c, The Standard of Good Practice for Information Security, 2013)
  • Verify security controls are in place to hinder firmware reverse engineering (e.g., removal of verbose debugging symbols). (C.18, Application Security Verification Standard 4.0.3, 4.0.3)
  • Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software. (CIS Control 18: Sub-Control 18.7 Apply Static and Dynamic Code Analysis Tools, CIS Controls, 7.1)
  • Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software. (CIS Control 18: Sub-Control 18.7 Apply Static and Dynamic Code Analysis Tools, CIS Controls, V7)
  • Apply static and dynamic analysis tools within the application life cycle to verify that secure coding practices are being followed. (CIS Control 16: Safeguard 16.12 Implement Code-Level Security Checks, CIS Controls, V8)
  • Leverage vetted modules or services for application security components, such as identity management, encryption, and auditing and logging. Using platform features in critical security functions will reduce developers' workload and minimize the likelihood of design or implementation errors. Modern o… (CIS Control 16: Safeguard 16.11 Leverage Vetted Modules or Services for Application Security Components, CIS Controls, V8)
  • The organization shall implement the identified improvements to the lifecycle processes. (§ 6.2.1.3(c)(2), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • A strength of security function analysis should demonstrate that the security mechanism meets or exceeds the defined minimum strength level. (§ 19.3, ISO 15408-3 Common Criteria for Information Technology Security Evaluation Part 3, 2008)
  • For software systems assigned to Class A, Class B, and Class C software safety classes, the medical device manufacturer shall implement risk control measures in the software to protect against hardware failures and potential software defects in the medical device requirements. (§ 5.2.3, ISO 62304 - 2006 Medical device software - Software life cycle processes, 2006)
  • additional controls to ensure the AI systems remain within required compliance conditions; (§ 6.6.2 ¶ 2 Bullet 3, ISO/IEC 38507:2022, Information technology — Governance of IT — Governance implications of the use of artificial intelligence by organizations)
  • Allocate security and privacy controls to the system and to the environment of operation. (TASK S-3, Risk Management Framework for Information Systems and Organizations, A System Life Cycle Approach for Security and Privacy, NIST SP 800-37, Revision 2)
  • SL 1 – Protect the integrity of the IACS against casual or coincidental manipulation. (7.1 ¶ 1 Bullet 1, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
  • SL 3 – Protect the integrity of the IACS against manipulation by someone using sophisticated means with moderate resources, IACS specific skills and moderate motivation. (7.1 ¶ 1 Bullet 3, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
  • In order to perform these validations the component must contain data that provides a way to differentiate between valid and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a product supplier will have a complete list of eve… (13.8.2 ¶ 2, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
  • Software being developed for classified or unclassified-sensitive information should have security measures implemented during the development process. (§ 2-3.a(4), Army Regulation 380-19: Information Systems Security, February 27, 1998)
  • such device is secured using alternative and effective methods appropriate to the function of such device. (§278g?3e.(b) (1) ¶ 1 (C), United States Code - 15 U.S.C. 278g-3a to 278g-3e, IoT Cybersecurity Improvement Act of 2020)
  • DoDI 8500.01 requires all DoD Information Systems to be categorized in accordance with CNSSI 1253 and implement a corresponding set of security controls and control enhancements (C/CEs) that are published in NIST SP 800-53, regardless of whether they are National Security Systems (NSS) or non-NSS. (Section 5.1 ¶ 1, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • The DISA PPSM office, along with the PPSM Change Control Board (CCB) and Technical Advisory Group (TAG) publish a Category Assignment List (CAL) which lists the PS permitted to cross certain DISN boundaries and Vulnerability Assessments (VAs) for each PS listed. Compliance with VAs is the key to the… (Section 5.15 ¶ 2, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • Design and build, including formal processes to preserve integrity throughout the development life cycle and ensure adequate controls. (App A Objective 6:4d, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • Determine whether management uses applications that were developed by following secure development practices and that meet a prudent level of security. Determine whether management develops security control requirements for applications, whether they are developed in-house or externally. Determine w… (App A Objective 6.27, FFIEC Information Technology Examination Handbook - Information Security, September 2016)
  • Management should use applications that have been developed following secure development practices and that meet a prudent level of security. Management should develop security control requirements for all applications, whether the institution acquires or develops them. Information security personne… (II.C.17 Application Security, FFIEC Information Technology Examination Handbook - Information Security, September 2016)
  • Controls over risks associated with system development and acquisition. (App A Objective 2:7 d., FFIEC Information Technology Examination Handbook - Management, November 2015)
  • Development and acquisition, including secure development. (App A Objective 12:4 c., FFIEC Information Technology Examination Handbook - Management, November 2015)
  • The organization should ensure security controls are implemented into developed software or security controls are already implemented in acquired software. (Pg 2, FFIEC IT Examination Handbook - Development and Acquisition)
  • Operational risk mitigation: Review whether management controls include the following: risk management; transaction monitoring and geolocation tools; fraud prevention, detection, and response programs; additional controls (e.g., stronger authentication and encryption); authentication and authorizati… (AppE.7 Objective 5:4 b., FFIEC IT Examination Handbook - Retail Payment Systems, April 2016)
  • 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)
  • Capture security controls used during the requirements phase to integrate security within the process, to identify key security objectives, and to maximize software security while minimizing disruption to plans and schedules. (T0022, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Incorporate cybersecurity vulnerability solutions into system designs (e.g., Cybersecurity Vulnerability Alerts). (T0124, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Identify components or elements, allocate security functions to those elements, and describe the relationships between the elements. (T0105, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Design and develop cybersecurity or cybersecurity-enabled products. (T0053, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Analyze candidate architectures, allocate security services, and select security mechanisms. (T0307, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Determine the protection needs (i.e., security controls) for the information system(s) and network(s) and document appropriately. (T0484, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Implement security measures to resolve vulnerabilities, mitigate risks, and recommend security changes to system or system components as needed. (T0485, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Collaborate on cybersecurity designs to meet specific operational needs and environmental factors (e.g., access controls, automated applications, networked operations, high integrity and availability requirements, multilevel security/processing of multiple classification levels, and processing Sensi… (T0560, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Implement the security controls specified in a security plan or other system documentation. (T0949, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Processes to instill organizational privacy values within system/product/service development and operations are established and in place. (GV.PO-P2, NIST Privacy Framework: A Tool For Improving Privacy Through Enterprise Risk Management, Version 1.0)
  • Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security feature… (PW.1.3, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
  • Separate and protect each environment involved in software development. (PO.5.1, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
  • Implement and Maintain Secure Environments for Software Development (PO.5): Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained withi… (PO.5, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
  • Design Software to Meet Security Requirements and Mitigate Security Risks (PW.1): Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software's design and architecture should mitigate those risks… (PW.1, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
  • Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components. (PW.4.2, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
  • Coordinate with security policies and system security controls. Client/server contingency solutions should be coordinated with security policies and system security controls. In choosing the appropriate technical contingency solution, similar security controls and security-related activities (e.g., … (§ 5.2.1 ¶ 1 Bullet 4, NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, Rev. 1 (Final))
  • Coordinate with security policies and security controls. Telecommunications contingency solution(s) should be coordinated with network security policies to protect against threats that could disrupt the network. Therefore, in choosing the appropriate technical telecommunications contingency solution… (§ 5.3.1 ¶ 1 Bullet 3, NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, Rev. 1 (Final))
  • Coordinate with security policies and security controls. Server contingency solution(s) should be coordinated with network security policies where similar security controls and security-related activities (e.g., risk assessment, vulnerability scanning) in the production environment should be impleme… (§ 5.2.1 ¶ 3 Bullet 3, NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, Rev. 1 (Final))
  • Development/Acquisition Phase. As initial concepts evolve into information system development, specific contingency solutions may be determined. As in the Initiation phase, technical contingency planning considerations in this phase should reflect system and operational requirements. The design shou… (Appendix F ¶ 5, NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, Rev. 1 (Final))
  • The security engineering principles must include the ongoing secure development training requirements for smart grid system developers. (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)
  • The security engineering principles must include the minimum standard security specifications. (SG.SA-8 Requirement 2, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include the minimum standard privacy specifications. (SG.SA-8 Requirement 3, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include creating a threat model for the smart grid Information System. (SG.SA-8 Requirement 4, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include updating product specifications to include corrections for any discovered threats. (SG.SA-8 Requirement 5, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include the use of secure coding practices for reducing common security errors. (SG.SA-8 Requirement 6, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include testing for validating the secure coding effectiveness. (SG.SA-8 Requirement 7, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include conducting a final security audit before authorizing the system to operate in order to verify the system adheres to the security requirements. (SG.SA-8 Requirement 8, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include creating a documented and tested security response plan for when vulnerabilities are discovered. (SG.SA-8 Requirement 9, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include creating a documented and tested privacy response plan for when vulnerabilities are discovered. (SG.SA-8 Requirement 10, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The security engineering principles must include conducting a root cause analysis to determine the cause of the identified vulnerabilities. (SG.SA-8 Requirement 11, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The organization should develop security controls that mitigate risk; comply with laws, standards, and regulations; and meet specific requirements of the organization. (§ 2.2 ¶ 1, Recommended Security Controls for Federal Information Systems, NIST SP 800-53)
  • When a development system is new, the process applied for selecting security controls is from a requirements definition perspective. The chosen security controls will serve as a security specification and should be incorporated into the system. (§ 3.3 ¶ New Development and Legacy Systems, Recommended Security Controls for Federal Information Systems, NIST SP 800-53)
  • Capture security controls used during the requirements phase to integrate security within the process, to identify key security objectives, and to maximize software security while minimizing disruption to plans and schedules. (T0022, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Incorporate cybersecurity vulnerability solutions into system designs (e.g., Cybersecurity Vulnerability Alerts). (T0124, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Determine the protection needs (i.e., security controls) for the information system(s) and network(s) and document appropriately. (T0484, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Identify components or elements, allocate security functions to those elements, and describe the relationships between the elements. (T0105, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Implement specific cybersecurity countermeasures for systems and/or applications. (T0123, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Implement the security controls specified in a security plan or other system documentation. (T0949, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Design and develop cybersecurity or cybersecurity-enabled products. (T0053, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Analyze candidate architectures, allocate security services, and select security mechanisms. (T0307, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Collaborate on cybersecurity designs to meet specific operational needs and environmental factors (e.g., access controls, automated applications, networked operations, high integrity and availability requirements, multilevel security/processing of multiple classification levels, and processing Sensi… (T0560, 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 design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics. (SA-17(5)(a), 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 internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism. (SA-17(5)(b), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Deprecated, Revision 4, Deprecated)
  • Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and (SA-17(5)(a), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism. (SA-17(5)(b), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and (SA-17(5) ¶ 1(a), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism. (SA-17(5) ¶ 1(b), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Implement anti-spoofing mechanisms to prevent adversaries from falsifying the security attributes indicating the successful application of the security process. (SC-16(2) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and (SA-17(5) ¶ 1(a), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism. (SA-17(5) ¶ 1(b), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Implement anti-spoofing mechanisms to prevent adversaries from falsifying the security attributes indicating the successful application of the security process. (SC-16(2) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Engineer in Security and Develop Controls: 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 norm… (§ 3.2.3.4, Security Considerations in the Information System Development Life Cycle, NIST SP 800-64, Revision 2)
  • The systems used for processing personal data shall be structured in order to meet the security requirements, standards of good practice and governance, general principles provided in this Law and other regulatory rules. (Art. 49, Brazilian Law No. 13709, of August 14, 2018)