ISO 27001 insists application security must start with secure coding practices

Key takeaways

 

• ISO 27001/27002 updates from October 2022 define guidelines for developing secure code. 
• Developer security education needs to focus on practical issues based around the most common software security weaknesses.
• Motivating and empowering developers to create secure code remains the biggest challenge.

Winston Churchill once said, “Those that fail to learn from history are doomed to repeat it.” If Churchill were a chief security officer today, he might say, “Those that don’t learn to write secure code are doomed to repeatedly get the same vulnerabilities.” Software security testing can uncover those vulnerabilities, but the time and money it costs organizations to fix them could be saved by writing secure code in the first place.

Research shows that developer security education is lacking. But that must change. Not only would organizations benefit from teaching developers secure coding principles – if they want to comply with the current ISO 27001/27002 standards, they are required to do so. Updated in October 2022, the ISO guidelines clearly stipulate that “secure coding principles should be applied to software development” and lay out an extensive set of requirements that apply to writing secure code. 

The ISO standard separates secure coding requirements into three phases (planning, during coding, and review and maintenance), also calling for implementing these practices throughout the software development life cycle (SDLC). Further, ISO says to apply secure coding principles not just for in-house development but for open-source, third-party, and outsourced code as well. To do this, organizations need to be aware of the real-world threats they face and understand how software weaknesses can open the door to attackers.

Phase 1: Planning and before coding

The ISO 27002 document advises that the planning phase be used to draw up principles and expectations for secure coding for both in-house and outsourced development. Organizations should pay special attention to establishing developer competence in creating secure code. This will likely require developer training.

The standard also advises that development tools be regularly updated and properly configured to help enforce the coding standards. This includes defining strict access rights to ensure the privacy and security of code while it’s being written. Threat modeling should play an integral role in the architecture and design of the application. This could entail defining use cases where the system is attacked or otherwise compromised.

Phase 2: During coding

The ISO standard mandates defining “secure coding practices specific to the programming languages and techniques being used” and “prohibiting the use of insecure design techniques.” Acknowledged reference resources showing the risks of insecure coding include the Common Weakness Enumeration (CWE) list of the top 25 most dangerous software weaknesses, as identified by the SANS Institute. For web applications, the industry yardstick is the OWASP Top 10 list of the most critical web application security risks, compiled by the Open Web Application Security Project.

Secure coding practices (and the dangers of not following them) span all levels of development. Some are language-independent, others, such as those related to proper memory management, only apply to C or C++, and others still apply to interpreted rather than compiled languages. Crucially, some are specific to web applications. 

An overriding best practice is to thoroughly validate any input retrieved from the user or an external source. Failure to validate incoming data opens the door to many attack scenarios. For example, in SQL injection, the attacker includes SQL commands in an input field or parameter in order to execute database commands. Similarly, in cross-site scripting (XSS), attackers include malicious JavaScript in inputs in order to execute script in the user’s browser (or even on the server, for Node.js applications). Trusting all inputs can also lead to server-side request forgery (SSRF), where attackers can cause a web server to send a request to a supplied URL, usually leading to a malicious site. 

Other weaknesses result from failed or insecure authentication of users. One cardinal rule is not to store passwords in a program where they can be read by an attacker. Instead, passwords should be stored in an external encrypted file or (preferably) only as hashes. Other errors include improper access control and failure to encrypt sensitive data. This can expose private, financial, or corporate data. Failure to encrypt sensitive personal data is not only a weakness, but it also can be illegal. ISO recommends applying the principle of least privilege, that is granting only the lowest level of access required to do a job.  

Other recommendations from ISO include pair programming and peer code review so that all code is documented and checked by multiple developers.  

As an ongoing check, the ISO standard requires static application security testing (SAST) during development to verify that the code does not contain any of the identified security weaknesses and, later in the SDLC, dynamic application security testing (DAST). If any weaknesses are found, they can be mitigated at this testing stage. Ideally, these tools can be integrated into the development environment so that security testing becomes just another step in development. 

Phase 3: Review and maintenance

After deployment, the organization should keep monitoring for new threats, comparing these with its production applications, and respond, as needed, with updated coding standards. Attack logs can be a resource for determining necessary code adjustments to protect against new emerging threats. Regular vulnerability scanning and penetration testing can also reveal weaknesses that need to be eliminated from existing and future code.

Developer education

In the end, deploying secure applications depends on developers who are both able and willing to write secure code. This is hampered both by inadequate security training offered to developers (or demanded of developers, in most organizations) and by the way that security is still often treated as an isolated concern. That separation can lead developers to believe that security simply isn’t their responsibility.

“Organizations need to put a lot of effort into developer education,” said Invicti CISO and VP of Information Security Matthew Sciberras. While the CWE and OWASP Top 10 lists are useful as training checklists, educational sites such as Invicti Learn can be more effective in helping developers learn to write secure code. Invicti Learn explains the most critical vulnerabilities and configuration errors that can open web applications to attacks and provides guidance to remedy and prevent them.  

Even more challenging is motivating and empowering developers to take the extra time and effort to shore up weaknesses in their code. Often, developers are caught between reworking code for security reasons and meeting deadlines. “More important than education is convincing developers that security works in their favor so they don’t treat it as a chore,” said Sciberras. “Attitude is often the biggest problem.”

Embedding a security mindset into development

Developer education and coding standards are the keys to producing a secure, robust application – and also the keys to complying with ISO 27001. And, as the ISO standard points out, even after deploying the application, constant vigilance must be maintained to fend off new attacks. Thinking even further, though, secure coding practices may never be fully realized until organizations revamp their approach to security so that security thinking becomes integral to all aspects of development, from the initial planning and design through long after the app is deployed and running.