4

The ISO/IEC 27000-series of standards lay out how to create and manage an information security management system (ISMS). The ISO/IEC 27001 document provides the main body of the standard and is augmented by a number of sector-specific guideline documents.

The 27001 document includes a lengthy Annex listing a full list of 114 controls, grouped into 14 clauses and 35 categories, against with an ISMS can be audited.

Control A.9.4.5, ‘Access control to program source code’ states the following:

Access to program source code shall be restricted.

Does this mean that ISO 27001 is incompatible with free/open source software, for which the source code is not and can not be restricted?

Is there any way of waiving this, or would any such software produced by an organisation just have to be excluded from the scope of any 27001 certification?

08915bfe02
  • 179
  • 5
  • It should be "The ability to make modifications to the source code for the binary shall be restricted" –  Nov 21 '19 at 16:25
  • I don't think this is applicable to FOSS. I think it is applicable to source code owned by the organization. All controls implicitly apply to the scope and to nothing else. If you don't own it, you can't control the risks. – M S Sripati Dec 20 '21 at 12:03
  • GitLab (gitlab.com) is an open source project that recently went through ISO 27001 certification. Their blogs and compliance pages do a great job describing their journey through ISO 27000 / SOC 2 certification. – Jeff Jancula Feb 09 '22 at 16:39

2 Answers2

6

"Access to program source code shall be restricted." does not mean that nobody should be able to access the source code but that it is defined who can access and change the code. The main point is not to have the source code secret but to prevent unauthorized and unaudited changes to the source code.

And this is true for using open source too: one should not simply import and use some code or patches from somewhere without somehow making sure that the code is actually having the expected behavior and only this, i.e.that it does not contain any backdoors and no critical bugs etc. This "somehow making sure" does not mean to audit everything yourself but might also mean to trust upstream distributions and maintainers to do the right thing. How much to trust upstream or how much to review code yourself of course depends on both who is the upstream and how critical the code is which uses third party code.

But blindly using npm, cpan, pip etc to install modules can be dangerous and is against the spirit of using and writing secure code, see Small World with High Risks: A Study of Security Threats in the npm Ecosystem or Malicious Modules — what you need to know when installing npm packages.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
1

Focus of the 27001 Standard

The ISO/IEC 27001 Security Standard is applicable to all sorts of organizations, its focus is on the management system, so to be in compliance with the Standard the organization is no expected to apply all the 114 controls, but to systematically apply a risk management strategy focused on the security of the processes and assets in scope.

In fact, there is the Statement Of Applicability (SoA), where the organization declares which controls will be applied, with a short explanation of how is a selected control to be implemented, and for those inapplicable controls, a justification, so, if the organization is aligned with FOSS, this should be explained and documented in the SoA. This documentation should back up the selection of this control or its exclusion.

The spirit of the A.9.4.5 control

The spirit of this specific control, as stated in the ISO/IEC 27002 standard (which explains every one of the 114 controls) is:

... to prevent the introduction of unauthorized functionality and to avoid unintentional changes as well as to maintain the confidentiality of valuable intellectual property.

So, this control is meant to protect the source code against unauthorized changes and protect intellectual property.

If the control is selected to be implemented, there are several guidelines that can be applied even if the organization embraces FOSS, for example:

  • source code should not be held in operational (production) systems.
  • source code should be managed according to established procedures, (in the case of FOSS, these procedures should also exist and be enforced).

If the organization uses FOSS, there should still be things like version control, change control and order in the use of the source code. That's what this control is about.

All these guidelines are to be considered, not necessarily adopted or implemented. Every organization defines which controls to apply and how to do it.

Conclusion

The important thing for being in compliance of this standard is to self explain and comply to the decisions the organization make regarding each control. So, the ISO 27001 Standard can be compatible with FOSS, how compatible depends on the consistency of the policy and procedures applied by the organization.

Having said that, it is clear that the authors of the Standard did not have Free/Open Source Software in mind when they wrote the norm, probably the organizations for which these standards were built in the first place were not focused on FOSS, but the standard can be adopted by an organization oriented to use FOSS.

In the ISO27001 Standard, there is an absence of other terms that recently grew in notoriety, like cloud computing, Internet of Things or cybersecurity. The standard is complemented with other documents of the ISO 27000 family that are being developed after the main standard, hopefully FOSS will be included in one of the latter documents.

ram0nvaldez
  • 204
  • 1
  • 2
  • 9
  • None of the popular information security/risk management frameworks (NIST RMF, NIST CSF, COBIT5, ISO 27001) specifically address FOSS nor should they in my opinion. – fpmurphy Jul 09 '20 at 05:32
  • I, agree, but at least they shouldn't be hostile to it. – ram0nvaldez Jul 09 '20 at 13:09