Rejected ISO/IEC 27002 control for SDLC

Suggested text for a new ISO/IEC 27002 control on integrating security into the systems lifecycle

Back in February 2011, I proposed to incorporate a new information security control statement concerning integrating security into the systems lifecycle into ISO/IEC 27002 which was being revised by the committee at the time.

To set the scene, recall that section 12 of ISO/IEC 27002:2005 covered Information systems acquisition, development and maintenance without mentioning development projects or system lifecycles as such.

See what you make of the donor text I provided in Standards New Zealand's submission to ISO/IEC JTC1/SC27 ...

----------------------------------

Control objective

To take due account of information security throughout the entire IT systems lifecycle.

Implementation guidance

While the exact naming, nature and sequence of activities may vary according to different development methods and lifecycle models, appropriate information security activities should take place throughout the entire systems lifecycle, for example:

a) Business case: key information security risks, issues and control objectives should ideally be identified in the business case for a new IT system, ensuring that sufficient funding is allocated to deliver the necessary security controls.

b) Requirements specification: information security risks relating to the system in its proposed operational environment should be analyzed to identify appropriate risk treatments and specify any associated information security control objectives or high level requirements. 

c) Architecture and design: the organization's information security policies, compliance obligations, relevant standards and any other applicable information security requirements should be taken into account when preparing the system architecture and more detailed functional and technical design specifications;

d) Development: technical and non-technical information security controls (e.g. logical access controls and security operating procedures) and functions (e.g. backup and recovery facilities) should be developed in accordance with the specifications and design;

e) Testing: information security controls and functions should be validated against the requirements during the testing phase. System security testing is often required to increase assurance that the delivered system will be sufficiently robust, resilient, reliable and secure when in operation. Additional unstructured testing may be appropriate to stress the system in an attempt to reveal unintended and previously unrecognized information security vulnerabilities resulting from bugs and flaws in the design;

f) Implementation: technical security controls may need to configured and enabled (e.g. associating access rights with roles and assigning roles to users). Users, administrators and managers may been to be trained on the procedural security controls (such as security monitoring functions and reporting);

g) Operation: the information security controls should of course be used as intended. It may be worthwhile periodically reassessing the information security risks and the effectiveness of the information security controls to determine whether changes are necessary;

h) Maintenance: information security requirements should be taken into account when managing and maintaining the system and its related processes, for example ensuring that changes to the platform, operating system or application software, and/or the business processes do not adversely impact information security or create new risks;

i) Retirement: information that will continue to have value, or that is needed for business or regulatory compliance reasons, should be archived. Any confidential information on media that are to be discarded or recycled must be securely deleted.

Other information

Along with the remainder of ISO/IEC 27002 clause 14, ISO/IEC 27034 provides additional guidance on the information security aspects of the application development process. 

--------------------------------------

In the event, SC27 went with control 14.2 Security in development and support processes ("Objective: to ensure that information security is designed and implemented within the development lifecycle of information systems"), supported by 14.1 Security requirements of information systems and 14.3 Test data.  I'm reasonably happy with these three clauses in ISO/IEC 27002:2013 with two significant exceptions:

1) Some other important controls from the 2005 version were dropped rather than updated - in particular, the control Correct processing in applications which was the only place in the 2005 standard that talked about data validation, has mysteriously evaporated from the 2013 version. I find the committee's decision to drop that control quite bizarre, since a good proportion of the hacking and fraud incidents that hit the news headlines every month are the result of hackers meddling with inadequately validated user inputs to application systems on the web, SQL injection attacks being a very obvious category. I am quite sure that a lot more of these attacks are happening right now, including insider attacks on internal corporate systems handling expenses, procurement, wages and so on - basically all the applications where a rogue employee stands to profit by taking advantage of lax security. It wouldn't be quite so bad if we could rely on audit trails, logs, alerts and alarms,  but we know how ineffective those usually are in practice: even if the functions exist and are correctly configured (a tall order), it is highly unlikely that anyone is actually using them, monitoring and responding to the alerts, reviewing the logs, and following up on issues.  They "don't have the time" for such tedious activities. By the time the auditors finally cotton-on to something amiss, the perpetrators have long since scarpered to a life of luxury in the tropics, with a very good chance that the audit trails and logs are inadequate to prove anything at all even took place.

2) 14.3 Test data has been so watered-down and wordsmithed that it has almost completely lost its intended meaning. My vision in proposing the new control was to recommend that organizations should cease using some version of operational data for testing, instead generating suitable application test data entirely from scratch.  Clearly, to do this properly, they would need to understand their data structures, functions, limits, business logic etc. in sufficient depth to be able to generate meaningful test data, but that level of analysis has huge advantages both for application security and for application architecture, design, functionality, maintenance and support. It also avoids the substantial security and privacy risks associated with various analysts, developers, testers, users and managers gaining access to (some version of) operational data, storing the data securely, updating the data to reflect changes to application etc. (which is really the only issue that the published control lamely addresses). Perhaps most importantly of all from the security perspective, it challenges the implicit assumption that normal operational data provide valid security test cases: I am convinced that this blinkered thinking is a key reason that talented hackers continually break system controls. The development project team and support crew gets stuck in a mind-set and a load of implicit assumptions about how the system will be or is being used and managed. Talented hackers have the knack of thinking along quite different lines, figuring out ways to break or bypass the controls by taking advantage of those assumptions.

Another disappointing outcome for me.  Ho hum.

PS  I also proposed new or changed security controls for:

• SCADA/ICS (industrial control systems)
• The computer suite (mostly physical controls)
• BCM (business continuity management) and
• Cloud computing