Develop new products based on secure coding techniques.

Back

CONTROL ID
11733

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 and maintain a coding manual for secure coding techniques., CC ID: 11863
Configure software development tools in accordance with organizational standards., CC ID: 16387
Address known coding vulnerabilities as a part of secure coding techniques., CC ID: 12493
Standardize Application Programming Interfaces., CC ID: 12167
Include all confidentiality, integrity, and availability functions in the system design specification., CC ID: 04556
Include the relationships and dependencies between modules in the system design specification., CC ID: 04559
Establish, implement, and maintain a security policy model document., CC ID: 04560

SELECTED AUTHORITY DOCUMENTS COMPLIED WITH

App 2-1 Item Number III.4(1): All programming must be based on the specifications in the program design documents. This is a control item that constitutes a relatively small risk to financial information. This is an IT general control. App 2-1 Item Number III.4(2): The organization must ensure all p… (App 2-1 Item Number III.4(1), App 2-1 Item Number III.4(2), Appendix 1 Correspondence of the System Management Standards - Supplementary Edition to other standards)
T10: During the program development phase, the organization shall ensure the software quality. This is accomplished by developing software in accordance with specifications and using a standardized and automated software development process. T10.3: The organization should use secure programming tec… (T10, T10.3, FISC Security Guidelines on Computer Systems for Banking and Related Financial Institutions, 7th Edition)
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)
The OWASP Application Security Verification Standard is followed when developing web applications. (Security Control: 0971; Revision: 7, Australian Government Information Security Manual, March 2021)
Secure-by-design and secure-by-default principles, use of memory-safe programming languages where possible, and secure programming practices are used as part of application development. (Control: ISM-0401; Revision: 6, Australian Government Information Security Manual, June 2023)
SecDevOps practices are used for application development. (Control: ISM-1780; Revision: 0, Australian Government Information Security Manual, June 2023)
Secure-by-design and secure-by-default principles, use of memory-safe programming languages where possible, and secure programming practices are used as part of application development. (Control: ISM-0401; Revision: 6, Australian Government Information Security Manual, September 2023)
SecDevOps practices are used for application development. (Control: ISM-1780; Revision: 0, Australian Government Information Security Manual, September 2023)
The organization should ensure software developers use secure programming practices, that include designing software to use the lowest privilege level necessary. (Control: 0401 Bullet 1, Australian Government Information Security Manual: Controls)
The organization should ensure software developers use secure programming practices, that include denying Access by default. (Control: 0401 Bullet 2, Australian Government Information Security Manual: Controls)
The organization should ensure software developers use secure programming practices, that include checking the return values of all system calls. (Control: 0401 Bullet 3, Australian Government Information Security Manual: Controls)
The organization should ensure software developers use secure programming practices, that include validating all inputs. (Control: 0401 Bullet 4, Australian Government Information Security Manual: Controls)
The organization should ensure software developers use secure programming practices, that include following secure coding standards. (Control: 0401 Bullet 5, Australian Government Information Security Manual: Controls)
The organization should implement secure software development techniques, especially for sensitive or critical software assets. (Attach D ¶ 1, APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
The organization should consider the following when designing secure software: what privileges the software executes in; software modularization; where the software is located; and what security standards and guidelines the software specifications are written for. (Attach D ¶ 2(a), APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
software defence techniques against known vulnerabilities; and (Attachment D 2(d)(iii)., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
Implement secure software (Attachment G Control Objective Row 7, APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
Implementation controls minimise risk of new vulnerabilities from system change, systems are secure by design (Attachment G Control Objective Row 11, APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
A regulated institution would normally implement secure software development techniques for software assets, with a focus typically on the more sensitive or critical software assets. This will assist in maintaining confidentiality, integrity and availability by improving the general quality and vuln… (Attachment D ¶ 1, APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
Software developers should use secure programming practices, including designing software to use the lowest privileges, deny access by default, and validate all user input. (§ 3.5.27, Australian Government ICT Security Manual (ACSI 33))
Financial institutions should implement measures to protect the integrity of the source codes of ICT systems that are developed in-house. They should also document the development, implementation, operation and/or configuration of the ICT systems comprehensively to reduce any unnecessary dependency … (3.6.2 73, Final Report EBA Guidelines on ICT and security risk management)
Code should be minimized to the functionality necessary for the service/device to operate. (Provision 5.6-6, CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements, ETSI EN 303 645, V2.1.1)
When the device is not a constrained device, it shall have a mechanism available which makes brute-force attacks on authentication mechanisms via network interfaces impracticable. (Provision 5.1-5, CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements, ETSI EN 303 645, V2.1.1)
Programming policies for each programming language used (e. g. regarding buffer overflows, hiding internal object references towards users) (Section 5.11 BEI-01 Basic requirement ¶ 1 Bullet 3, Cloud Computing Compliance Controls Catalogue (C5))
Applications must be developed based on secure coding guidelines in order to address common coding vulnerabilities of the software development process. (PCI DSS Requirements § 6.5 Bullet 2, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.0)
Address common coding vulnerabilities in software-development processes as follows: - Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. - Develop applications based on secure coding guideline… (6.5, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.1 April 2015)
Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: - Code changes are reviewed by individuals other than the originating code author, and by individuals… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.1 April 2015)
Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: - Code changes are reviewed by individuals other than the originating code author, and by individuals… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, v3.2.1)
Address common coding vulnerabilities in software-development processes as follows: - Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. - Develop applications based on secure coding guidelines. (6.5, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, v3.2.1)
Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: - Code changes are reviewed by individuals other than the originating code author, and by individuals… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2)
Address common coding vulnerabilities in software-development processes as follows: - Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. - Develop applications based on secure coding guidelines. (6.5, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2)
Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities: (6.5 (c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire A-EP and Attestation of Compliance, Version 3.1)
Is all custom code reviewed prior to release to production or customers to identify any potential coding vulnerability (using either manual or automated processes as follows: - Are code changes reviewed by individuals other than the originating code author, and by individuals who are knowledgeable a… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.1)
Is all custom code reviewed prior to release to production or customers to identify any potential coding vulnerability (using either manual or automated processes as follows: - Are code changes reviewed by individuals other than the originating code author, and by individuals who are knowledgeable a… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities: (6.5(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
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 Service Providers, Version 3.1)
Is all custom code reviewed prior to release to production or customers to identify any potential coding vulnerability (using either manual or automated processes as follows: - Are code changes reviewed by individuals other than the originating code author, and by individuals who are knowledgeable a… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.1)
Do software-development processes address common coding vulnerabilities? (6.5 (a), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.1)
Is all custom code reviewed prior to release to production or customers to identify any potential coding vulnerability (using either manual or automated processes as follows: - Are code changes reviewed by individuals other than the originating code author, and by individuals who are knowledgeable a… (6.3.2, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities: (6.5(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: (6.5.c, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
Examine written software-development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows: - Code changes are reviewed by individuals other than the originating code author, and by i… (6.3.2.a, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
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)
The build of critical desktop applications should be subject to approved methods of developing desktop applications (e.g., when creating macros and similar user defined routines in spreadsheets, databases, and other desktop applications). (CF.13.04.07a, The Standard of Good Practice for Information Security)
The system development methodology should be kept up-to-date to include new and emerging development techniques (e.g., Rapid Application Development, agile software development, extreme programming, and Joint Application Design). (CF.17.01.05a, The Standard of Good Practice for Information Security)
The system development methodology should be applied by development staff in practice. (CF.17.01.08a, The Standard of Good Practice for Information Security)
The build of critical desktop applications should be subject to approved methods of developing desktop applications (e.g., when creating macros and similar user defined routines in spreadsheets, databases, and other desktop applications). (CF.13.04.07a, The Standard of Good Practice for Information Security, 2013)
The system development methodology should be kept up-to-date to include new and emerging development techniques (e.g., Rapid Application Development, agile software development, extreme programming, and Joint Application Design). (CF.17.01.05a, The Standard of Good Practice for Information Security, 2013)
The system development methodology should be applied by development staff in practice. (CF.17.01.08a, The Standard of Good Practice for Information Security, 2013)
Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. (1.1.7, Application Security Verification Standard 4.0.3, 4.0.3)
Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. (5.3.8, Application Security Verification Standard 4.0.3, 4.0.3)
Multi-tenant organizationally-owned or managed (physical and virtual) applications, and infrastructure system and network components, shall be designed, developed, deployed and configured such that provider and customer (tenant) user access is appropriately segmented from other tenant users, based o… (IVS-09, Cloud Controls Matrix, v3.0)
Establish and maintain a secure application development process. In the process, address such items as: secure application design standards, secure coding practices, developer training, vulnerability management, security of third-party code, and application security testing procedures. Review and up… (CIS Control 16: Safeguard 16.1 Establish and Maintain a Secure Application Development Process, CIS Controls, V8)
Secure coding principles should be applied to software development. (§ 8.28 Control, ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection â Information security controls, Third Edition)
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives. (A1.2 ¶ 1, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with Revised Points of Focus â 2022))
SL 2 â Protect the integrity of the IACS against manipulation by someone using simple means with low resources, generic skills and low motivation. (7.1 ¶ 1 Bullet 2, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives. (A1.2, Trust Services Criteria)
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives. (A1.2 ¶ 1, Trust Services Criteria, (includes March 2020 updates))
Environmental protections, software, data backup processes, and recovery infrastructure are authorized, designed, developed, implemented, operated, approved, maintained, and monitored to meet the entityâs availability commitments and system requirements. (A1.2, TSP 100A - Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy)
Adopt secure development practices for in-house developed applications utilized by the Licensee and procedures for evaluating, assessing or testing the security of externally developed applications utilized by the Licensee; (Section 4.D ¶ 1(2)(e), Insurance Data Security Model Law, NAIC MDL-668, Q4 2017)
Developers working for the institution follow secure program coding practices, as part of a system development life cycle (SDLC), that meet industry standards. (Domain 3: Assessment Factor: Preventative Controls, SECURE CODING Baseline 3 ¶ 1, FFIEC Cybersecurity Assessment Tool, Baseline, May 2017)
Adopt secure development practices for in-house developed applications utilized by you for transmitting, accessing, or storing customer information and procedures for evaluating, assessing, or testing the security of externally developed applications you utilize to transmit, access, or store custome… (§ 314.4 ¶ 1(c)(4), 16 CFR Part 314, Standards for Safeguarding Customer Information, Final Rule, Amended February 15, 2022)
Calls for an organization to adopt an SDLC for the purposes of integrating information security within the scope of an audit process. (CC-1.1, Federal Information System Controls Audit Manual (FISCAM), February 2009)
Utilize different programming languages to write code, open files, read files, and write output to different files. (T0404, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
Direct software programming and development of documentation. (T0324, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
Read, interpret, write, modify, and execute simple scripts (e.g., Perl, VBScript) on Windows and UNIX systems (e.g., those that perform tasks such as: parsing large data files, automating manual tasks, and fetching/processing remote data). (T0403, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
Verify minimum security requirements are in place for all applications. (T0508, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization's requirements. (PW.5.1, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
Create Source Code by Adhering to Secure Coding Practices (PW.5): Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria. (PW.5, NIST SP 800-218, Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities, Version 1.1)
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)
Direct software programming and development of documentation. (T0324, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)â, July 7, 2020)
Read, interpret, write, modify, and execute simple scripts (e.g., Perl, VBScript) on Windows and UNIX systems (e.g., those that perform tasks such as: parsing large data files, automating manual tasks, and fetching/processing remote data). (T0403, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)â, July 7, 2020)
Utilize different programming languages to write code, open files, read files, and write output to different files. (T0404, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)â, July 7, 2020)
Develop secure code and error handling. (T0077, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)â, July 7, 2020)
Ensure Use of Secure Information System Development Processes: Primary responsibility for application security, during early phases, lies in the hands of the development team who has the most in-depth understanding of the detailed workings of the application and ability to identify security defects … (§ 3.1.3.5, Security Considerations in the Information System Development Life Cycle, NIST SP 800-64, Revision 2)
Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle (PR.PS-06, The NIST Cybersecurity Framework, v2.0)
To further incentivize the adoption of secure software development practices, the Administration will encourage coordinated vulnerability disclosure across all technology types and sectors; promote the further development of SBOMs; and develop a process for identifying and mitigating the risk presen… (STRATEGIC OBJECTIVE 3.3 ¶ 4, National Cybersecurity Strategy)
Adopt secure development practices for in-house developed applications utilized by the licensee. (Section 27-62-4(d)(2) e., Code of Alabama, Title 27, Chapter 62, Sections 1-11, Insurance Data Security Law)
Adoption of secure development practices for in-house developed applications utilized by such licensee and procedures for evaluating, assessing or testing the security of externally developed applications utilized by such licensee; (Part VI(c)(4)(B)(v), Connecticut General Statutes, Title 38a, Chapter 697, Part VI, Section 38a-38, Insurance Data Security Law)
Secure development practices for an application that a licensee uses and was developed in-house. (§ 8604.(d)(2) e. 1., Delaware Code, Title 18, Chapter 86, Sections 8601-8611, Insurance Data Security Act)
Adopt secure development practices for in-house developed applications used by the licensee and procedures for evaluating, assessing, or testing the security of externally developed applications used by the licensee; (§431:3B-203(2)(E), Hawaii Revised Statute, Volume 9, Chapter 431, Article 3B, Sections 101-306, Insurance Data Security Law)
Adopting secure development practices for in-house developed applications used by the licensee. (Sec. 18.(2)(E), Indiana Code, Title 27, Article 2, Chapter 27, Sections 1-32, Insurance Data Security)
Adopt secure development practices for in-house developed applications utilized by the licensee, and procedures for evaluating, assessing, and testing the security of externally developed applications utilized by the licensee. (507F.4 4.b.(5), Iowa Code, Title XIII, Chapter 507F, Sections 1-16, Insurance Data Security)
Adopt secure development practices for in-house developed applications used by the licensee and procedures for evaluating, assessing, or testing the security of externally developed applications used by the licensee. (§2504.D.(2)(e), Louisiana Revised Statutes, Title 22, Chapter 21, Sections 2501-2511, Insurance Data Security)
Adopt secure development practices for applications developed and used by the licensee and procedures for evaluating, assessing or testing the security of externally developed applications used by the licensee; (§2264 4.B.(5), Maine Revised Statutes, Title 24-A, Chapter 24-B, Sections 2261-2272, Maine Insurance Data Security Act)
Adopting secure development practices for in-house developed applications utilized by the licensee. (Sec. 555.(4)(b)(v), Michigan Compiled Laws, Chapter 5A Sections 550-565, Data Security)
adopt secure development practices for in-house developed applications utilized by the licensee; (§ 60A.9851 Subdivision 4(2)(v), Minnesota Statutes, Chapter 60A, Sections 985 - 9857, Information Security Program)
Adopt secure development practices for in-house developed applications utilized by the licensee; (§ 83-5-807 (4)(b)(v), Mississippi Code Annotated, Title 83, Chapter 5, Article 11, Sections 801 - 825, Insurance Data Security Law)
Adopt secure development practices for in-house developed applications utilized by the licensee. (§ 420-P:4 IV.(b)(5), New Hampshire Revised Statutes, Title XXXVIII, Chapter 420-P, Sections 1-14, Insurance Data Security Law)
Each Covered Entity's cybersecurity program shall include written procedures, guidelines and standards designed to ensure the use of secure development practices for in-house developed applications utilized by the Covered Entity, and procedures for evaluating, assessing or testing the security of ex… (§ 500.08 Application Security (a), New York Codes, Rules and Regulations, Title 23, Chapter 1, Part 500 Cybersecurity Requirements for Financial Services Companies)
Each covered entity's cybersecurity program shall include written procedures, guidelines and standards designed to ensure the use of secure development practices for in-house developed applications utilized by the covered entity, and procedures for evaluating, assessing or testing the security of ex… (§ 500.8 Application Security (a), New York Codes, Rules and Regulations, Title 23, Chapter 1, Part 500 Cybersecurity Requirements for Financial Services Companies, Second Amendment)
Adopt secure development practices for in-house developed applications utilized by the licensee; (26.1-02.2-03. 4.b.(5), North Dakota Century Code, Title 26.1, Chapter 26.1â02.2, Sections 1-11, Insurance Data Security)
Adopt secure development practices for in-house developed applications utilized by the licensee and procedures for evaluating, assessing, or testing the security of externally developed applications utilized by the licensee; (Section 3965.02 (D)(2)(e), Ohio Revised Code, Title 39, Chapter 3965, Sections 1-11, Cybersecurity Requirements For Insurance Companies)
adopting secure development practices for in-house developed applications used by the licensee and procedures for evaluating, assessing, and testing the security of externally developed applications used by the licensee; (SECTION 38-99-20. (D)(2)(e), South Carolina Code of Laws, Title 38, Chapter 99, Sections 10-100, Insurance Data Security Act)
Adopt secure development practices for internally developed applications utilized by the licensee and procedures for evaluating, assessing, or testing the security of externally developed applications utilized by the licensee; (§ 56-2-1004 (4)(B)(v), Tennessee Code Annotated, Title 56, Chapter 2, Part 10, Sections 1-11, Insurance Data Security Law)
Adopt secure development practices for applications that are developed in-house and utilized by the licensee. (§ 601.952(3)(b)5., Wisconsin Statutes, Chapter 601, Subchapter IX, Sections 95-956, Insurance Data Security)