In this article we explore control A.14.1 Security Requirements of Information Systems. This can be thought of as a control that not only governs procurement processes for new systems, but that also sets criteria for new systems that can be tested before go-live. We will take a look and how ISO 27001 defines this control, and how organisations can demonstrate compliance with it through their business as usual (BAU) processes.
So firstly what does security requirements of information systems actually mean? Well, in short this control aims to ensure that security requirements for new systems are assessed, defined and measured. When an organisation identifies the requirement for a new system, the requirements of the system are often captured in the form of functional and non-functional requirements.
This sets the bar for what the organisation expects the system to be able to look like and feature. The organisation can then measure the system against these requirements to ensure it is fit for purpose before procuring or building it. It is during this process that security requirements should be identified, let’s look at an example.
Imagine your organisation is looking at a new HR system. They need the system to be able to record all employee records, as well as allowing the employee to be able to edit their own information. But as well as these functional requirements, they also need the employees records to be secured at all times and only accessible by authorized personnel.
These can be captured in the form of non-functional requirements, and can be as prescriptive or non-prescriptive as required but they should always be measurable. For example, this may be captured as “the system MUST be capable of interfacing with our authentication system (Active Directory)”, or “the system MUST authenticate each user via policies defined by the organisation”.
Once the organisation has a defined set of functional and non-functional requirements that include security requirements, the organisation can determine whether this is a system or application that will be developed in-house, outsourced or procured perhaps as a managed service. Regardless of the route taken, the organisation must base their decision to proceed with a new system on its ability to meet these requirements.
So, how would this work in terms of a business process? Well, often requirements for new systems require input from multiple sources – the end user, the technical function supporting the system and ideally from security experts.
The end user would define the “what do I want it to do?” functional requirements, the technical function would define “how would this work with our current architecture?” requirements and the security function would define the “how would this work in a secure manner?” requirements. A process should be devised such that each function provides input to the requirements captured, and provides feedback on any suppliers that may respond during the tender phase.
Before a new system is built or procured, the organisation should be happy that it meets the requirements defined and does not result in an unacceptable level of risk. To ensure the organisation can demonstrate it has performed this process, the results may be documented to provide an audit trail. In terms of policy, the organisation may mandate these requirements within a systems management policy or equivalent such that all employees are aware of the need to engage security when introducing a new system.
