Back

Develop new products based on secure coding techniques.


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):
  • 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)
  • The OWASP Application Security Verification Standard is followed when developing web applications. (Security Control: 0971; Revision: 7, Australian Government Information Security Manual)
  • 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, The AD_offical_Name should be: 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)