7.1 KiB
| tags | |
|---|---|
|
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection |
8.28 Secure coding
Control
Secure coding principles should be applied to software development.
Purpose
To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.
Guidance
General
The organization should establish organization-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open source software.
The organization should monitor real world threats and up-to-date advice and information on software vulnerabilities to guide the organization’s secure coding principles through continual improvement and learning. This can help with ensuring effective secure coding practices are implemented to combat the fast-changing threat landscape.
Planning and before coding
Secure coding principles should be used both for new developments and in reuse scenarios. These principles should be applied to development activities both within the organization and for products and services supplied by the organization to others.
Planning and prerequisites before coding should include:
a) organization-specific expectations and approved principles for secure coding to be used for both in-house and outsourced code developments; b) common and historical coding practices and defects that lead to information security vulnerabilities; c) configuring development tools, such as integrated development environments (IDE), to help enforce the creation of secure code; d) following guidance issued by the providers of development tools and execution environments as applicable; e) maintenance and use of updated development tools (e.g. compilers); f) qualification of developers in writing secure code; g) secure design and architecture, including threat modeling; h) secure coding standards and where relevant mandating their use; i) use of controlled environments for development.
During coding
Considerations during coding should include:
a) secure coding practices specific to the programming languages and techniques being used; b) using secure programming techniques, such as pair programming, refactoring, peer review, security iterations and test-driven development; c) using structured programming techniques; d) documenting code and removing programming defects, which can allow information security vulnerabilities to be exploited; e) prohibiting the use of insecure design techniques (e.g. the use of hard-coded passwords, unapproved code samples and unauthenticated web services).
Testing should be conducted during and after development (see 8.29). Static application security testing (SAST) processes can identify security vulnerabilities in software.
Before software is made operational, the following should be evaluated: a) attack surface and the principle of least privilege; b) conducting an analysis of the most common programming errors and documenting that these have been mitigated.
Review and maintenance
After code has been made operational:
a) updates should be securely packaged and deployed; b) reported information security vulnerabilities should be handled (see 8.8); c) errors and suspected attacks should be logged and logs regularly reviewed to make adjustments to the code as necessary; d) source code should be protected against unauthorized access and tampering (e.g. by using configuration management tools, which typically provide features such as access control and version control).
If using external tools and libraries, the organization should consider:
a) ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles; b) selection, authorization and reuse of well-vetted components, particularly authentication and cryptographic components; c) the licence, security and history of external components; d) ensuring that software is maintainable, tracked and originates from proven, reputable sources; e) sufficiently long-term availability of development resources and artefacts.
Where a software package needs to be modified the following points should be considered:
a) the risk of built-in controls and integrity processes being compromised; b) whether to obtain the consent of the vendor; c) the possibility of obtaining the required changes from the vendor as standard program updates; d) the impact if the organization becomes responsible for the future maintenance of the software as a result of changes; e) compatibility with other software in use.
Other information
A guiding principle is to ensure security-relevant code is invoked when necessary and is tamper- resistant. Programs installed from compiled binary code also have these properties but only for data held within the application. For interpreted languages, the concept only works when the code is executed on a server that is otherwise inaccessible by the users and processes that use it, and that its data is held in a similarly protected database. For example, the interpreted code can be run on a cloud service where access to the code itself requires administrator privileges. Such administrator access should be protected by security mechanisms such as just-in-time administration principles and strong authentication. If the application owner can access scripts by direct remote access to the server, so in principle can an attacker. Webservers should be configured to prevent directory browsing in such cases.
Application code is best designed on the assumption that it is always subject to attack, through error or malicious action. In addition, critical applications can be designed to be tolerant of internal faults. For example, the output from a complex algorithm can be checked to ensure that it lies within safe bounds before the data is used in an application such as a safety or financial critical application. The code that performs the boundary checks is simple and therefore much easier to prove correctness.
Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality.
More information on ICT security evaluation can be found in the ISO/IEC 15408 series.