ISO 27034 – Application Security – Truth and Lies
**Full Disclosure — I have been working in both software and system development for over 25 years and have been lucky to bring solutions to both enterprise and carrier markets. I am currently the CTO of EdTech company that builds solutions using a secure-by-design approach. My background includes research where I was awarded 5 patent grants for technology in carrier networks. This includes over 20 years of ISO/IEC standards experience as an expert , editor, and HoD for Canada. **
I have been working on this project for more years than I care to remember and want to share my insiders view of this project and some real dangers this standard poses to innocent buyers of the vendors who “claim” conformance to this standard. Given that there is a full project review underway the time is right for making this standard for the masses. This includes helping vendors to find affordable methods for developing and maintaining secure software.
The Bases for this Standard
This project started from the Ph. D of the lead editor. At the time of writing, 2008, the security landscape was very different than it is now and applications meant different things in different sectors of the development and engineering sectors including the technologies used to develop them. With a lead editor that only sees this through the lens of his Ph D and not the industry need, it is very difficult to develop something that is not complex and that can provide a means for any organization to develop secure software. If you know ISO rules, you will quickly realize that this clashes completely with ISO rules for consensus based approach.
BTW, the editor has a great “intro” course he will provide any willing participant who wants to spend 3 hours of their life and 400 Powerpoint slides to educate you to the base concepts of this standard. I am not kidding you when I say many ISO delegates need to drink during these sessions. Keep in mind, this slide deck is 400 slides with lots of detail. You need to understand these concepts to implement this standard. Which gives you a little sense to level of complexity and serious skills need to do this work.
The Standard
As this project was focused on securing web applications and that was the premise of the Ph. D these concepts got embedded into the standard.
I will not breakdown each part of standard in detail but only provide that there is Overview and Concepts and many supporting documents. In total there are 8 parts which will set you back about 1200 Euros ($1750 CDN) to buy the entire collection. It details a framework for securing applications however development details are not provided. This part is 80 pages which gives you a sense to the level of complexity. Several parts are just XML so don’t purchase those unless you really need them. If you have bought those in error, I apologize for this. Basically, the following are some key aspects that are not considered.
ISO/IEC 27034 is not intended to be used for the following:
– Development standard for software applications
– Application project management standard or similar
– A Software Development Lifecycle (SDLC) standard
ISO/IEC 27034 does not provide any guidance on the following:
– Guidelines for technologies such as cloud, AI, physical, or network security
– Controls for measurement (metrics) nor considerations
– Secure coding strategies for any programming language
– Mandatory requirements in any form
I highlight these due to fact that industry has adopted this series was explicitly for the reasons above. This includes that many multi-national corporations hold “certifications” for it! Did I mention that there are no requirements in this standard as it is a framework only. It is anyone’s guess what they are claiming or what specific requirements they actually meet. SAP provides lots of documentation on their implementation of their SDLC using this standard. However, with no requirements and the fact that it does not cover an SDLC makes one a little puzzled to what exactly are they claiming to do. If someone can figure this out please share, I would love to know.
The base concept of an Application Security Control (ASC) is defined as a control to mitigate the risk. This can in essence be anything the only requirement is the format. The vendor unilaterally gets to decide this control including how it is measured. For example, they can create a ASC that states that failed logins are allowed with no further action or mitigation. This is a valid ASC and the buyer would be tasked with understanding what this means for a risk scenario.
The author will tell you that these are driven by the buyer but how many companies buying software will write these for the software they purchase when they don’t even know the technology or have the necessary capabilities of cyber for software development? Again, as stated above the vendor generates these with no requirements or minimums.
Other concepts build on how you then take these and put them into a governance model however this does not currently align to ISO/IEC 27002 which has defined requirements for software development. The editor will argue it does even as Part one is over 12 years old and 27002 was just published last year.
The Challenge and Risks
As you can tell this blog is born out of frustration with this project and how we have created a model of security by obscurity. A standard that pertains to do one thing but does not really move the needle on developing secure code or software. With the need to show that you’re secure, ISO has become a go to for organizations who want to demonstrate a gold standard and this is where the risk of exposure exists.
For any company that is looking to use a vendor that makes these claims you need to do your homework and determine what have they really implemented and does it align to other standards such as ISO/IEC/IEEE 12207:2017 Systems and software engineering Software life cycle processes for secure software development. You may also want to reference and research the following standards:
– Governments movement to Secure-by-Design
– European Union Cyber Resilience Act (CRA)
– NIST Secure Software Development Framework
This is but a small sample to provide detailed guidance on creating secure software driven by industry and regulators. Software can be secure but it takes structure and due diligence on the part of the vendor. This needs a governance infrastructure which requires process, procedure, and a risk management framework. It is not a “one and done” but embedded and part of a companies culture.
Implementation will be very sector specific as many sectors might have a regulatory requirements they must meet. If you are unaware of market requirements get to know them fast, and as always in the software world it is a case of buyer beware. Standards such as ISO 27001 and NIST Cyber Framework provide lots of details on how to implement such a framework.
If you are looking to buy software from a vendor who claims implementation or a certification to ISO 27034, you must require the full disclosure of the ASCs including the testing results. If they claim this is not an easy task or if they don’t provide them you would have grounds to question what they are really doing and do they really have secure software.
Based on the current state of cyber insecurity, we know that current vulnerabilities and compromises can be fully traced back to the approaches used and considered at development time. There are ways to secure software but many organizations are just not equipped to implement them from either a governance or skill set perspective. For example, ISO 27002 has a requirement for ensuring staff skills but this concept does not exist in 27034 nor is any guidance for implementing a ASC for this control provided. We also know based on the quickly changing landscape for technology this is a moving target so keeping your developers and engineers current to cyber risks is critical. And no, using a cloud provider is not going to fix this as they are dealing with these same issues of resources and talent. You cannot transfer risk, you must be willing to accept it or mitigate it.
The most risk here is this model is being proposed for other projects in both the ISO/IEC. The problem is that the approach has not changed only the names to append new concepts such as “IoT”, “Cloud”, and “AI”. It does not consider any specifics of these technologies the editor again insists these concepts apply to anything and everything. Which if your engineer you would probably disagree with. The potential exposure is increased significantly when not considering the development and implementation risks for any of these new technologies.
The Future
This project is currently under review and is the perfect opportunity for you to be heard on this topic. If you have an opinion on this standard please reach out to me. Does it work, does it not work. Especially, if you have worked in software development in startup or similar. Would like to understand your approach to development and what you consider the options for securing your products.