For many organisations having any form of information security system is new, and that can make it a little challenging. It means that you are having to graft your new systems onto what you already have, which is tricky. However, there will come a point that the next system you need isn't one you had before you system, its new and so the very best thing to do is build your information system into it from the ground up. Just like a product where you want to design quality into the product at the start so it's cheaper and easier to manufacture, you want to build in your ISO27001 information security system to any new processes and systems that you develop, from the ground up. That's the purpose of Annex Clause 14 System acquisition, development, and maintenance Requirement in your ISO27001 Information Security Management System and it goes across the entire lifecycle of your information security systems.
A.14.1 Security requirements of information systems
The first section of clause 14 has 3 requirements in it and it's objective is "To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks." In other words, think about what you are doing before you do it, especially in public networks. Here are the 3 requirements:
- 14.1.1 - Information security requirements analysis and specification: here the standard is looking for you to build your information security requirements into any new systems that are implemented (including purchased) or that are upgraded. Which makes sense, why would you add anything new that doesn't comply to your ISMS requirements? The key is to have a process to check and make sure it meets your needs.
- 14.1.2 Securing application services on public networks: Here the standard wants you to ensure that anything you put out over a public network is secure specifically from any fraudulent activity, contract dispute and unauthorized disclosure and modification. i.e. make sure it can't be messed with.
- 14.1.3 - Protecting application services transactions : this requirement is about when you transmit something then it needs to be protected to make sure it gets to where it's meant to, that it's not mis-transmitted, partially transmitted, corrupted, intercepted, shown somewhere it's not, in other words only the intended recipient should be able to see it and they should see all of it.
A.14.2 Security in development and support processes
In the second part of Annex A14 of ISO27001 there requirement is all about ensuring that the information security management system requirements are designed and implemented within the development lifecycle of information systems. i.e. don't make it an afterthought that never really works, design it in form the start. As you can imagine this is tricky and needs some thinking and ISO have 9 steps you need to think about which actually outline a typical development cycle.
- A.14.2.1 Secure development policy – make sure you have a top level policy about your development program for software and systems
- A.14.2.2 System change control procedures – make sure you have procedures in place for how you will control the changes that absolutely will be made to your software and systems not just in development but over it's lifecycle.
- A.14.2.3 Technical review of applications after operating platform changes – When you do make changes ensure that you review the impacts on your systems , especially business critical ones to look for adverse impacts you didn't expect, especially around security but also normal operating expectations.
- A.14.2.4 Restrictions on changes to software packages – make sure that only those who are allowed to change software can and that changes are really required. When changes do happen, make sure they are controlled.
- A.14.2.5 Secure system engineering principles – You need to document out your processes for engineering security in your systems, (and people need to know about them) and these need to be used when developing new processes and systems.
- A.14.2.6 Secure development environment – make sure you have a development are for your software and systems that is secure to avoid tampering in any way and it needs to cover the lifecycle of your development cycle .
- A.14.2.7 Outsourced development – Just because you outsource it doesn't mean you don't control it, you need to supervise and monitor that outsourced development to ensure it meets the requirements you have set for your information security management system.
- A.14.2.8 System security testing – You have documented your security requirements; it makes perfect sense that you would test them to ensure that they work right? ISO think so and that's the requirement here, do security testing during your development process.
- A.14.2.9 System acceptance testing – You need to develop a set of acceptance criteria for any new (or upgraded) information system and you need to apply it to ensure the system meets your requirements.
A.14.3 Test data
The final element of Annex 14 for ISO27001 information security management systems is that you need to have test data, more specifically you need to that you protect that data being used.
- A.14.3.1 Protection of test data – the single requirement is that any data you have decided to be used as test data does need to be selected carefully, protected and controlled and again that's through the entire life cycle of the system.
Throughout Annex Clause 14 for ISO27001 Information Security Management Systems the theme really is design information security in to your software and system from the start. The more embedded it is the more chance that it has to be successful. Test it as you go to ensure that it's delivering what you need and like any design process document what you change, when you change and why you change it, importantly document the benefits of those changes which in turn allows you to easily test the change does what you want and stays within your information security requirements.