Topic-specific policy 11/11: secure development

The final topic-specific policy example from ISO/IEC 27002:2022 is another potential nightmare for the naïve and inexperienced policy author. 

 

Policy scoping

Despite the context and presumed intent, the title of the standard's policy example ("secure development") doesn't explicitly refer to software or IT. Lots of things get developed - new products for instance, business relationships, people, corporate structures and so on. Yes, even security policies get developed! Most if not all developments involve information (requirements/objectives, specifications, plans, status/progress reports etc.) and hence information risks ... so the policy could cover those aspects, ballooning in scope from what was presumably intended when the standard was drafted.

Even if the scope of the policy is constrained to the IT context, the information security controls potentially required in, say, software development are many and varied, just as the development and associated methods are many and varied, and more poignantly so too are the information risks. 

 

Policy development

Your homework challenge, today, is to consider, compare and contrast these five markedly different IT development scenarios:

1. Commercial firmware being developed for a small smart actuator/sensor device (a thing) destined to be physically embedded in the pneumatic braking system of commercial vehicles such as trucks and coaches, by a specialist OEM supplier selected on the basis of lowest price. 
2. A long-overdue technical update and refresh for a German bank's mature financial management application, developed over a decade ago by a team of contractors long since dispersed or retired, based on an obsolete database, with fragmentary documentation in broken English and substantial compliance implications, being conducted by a large software house based entirely in India. 
3. A cloud-based TV program scheduling system for a global broadcaster, to be delivered iteratively over the next two years by a small team of contractors under the management of a consultancy firm for a client that freely admits it barely understands phase 1 and essentially has no idea what might be required next, or when.
4. A departmental spreadsheet for time recording by home workers, so their time can be tracked and recharged to clients, and their productivity can be monitored by management.
5. Custom hardware, firmware and autonomous software required for a scientific exploration of the Marianas trench - to be deployed in the only two deep-sea drones in existence that are physically capable of delivering and recovering the payload at the extreme depths required.

You may have worked in or with projects/initiatives vaguely similar to one, maybe even two or three of these, but probably not all five - and these are just a few random illustrative examples plucked from the millions of such activities going on right now. The sheer number and variety of possibilities is bewildering, so how on earth can one draft a sensible policy?

As is the way with ISO27k, the trick is to focus on the information risks. Based on your experience, web research, consulting competent colleagues and advisors, studying software engineering and development books, methods and standards, searching security guidelines for established good practices, reading IT audit reports, checking your help desk records and post-incident reports for software-related incidents and chatting with team leaders and managers who have suffered through some of them, etc., systematically build up a general picture of the kinds of incidents that have, can, typically or might just happen in your situation. Start sifting out the aspects that matter most - risks in the red zone of your probability-impact graphic, the top right quadrant of your risk matrix, or simply the top few entries on a ranked list or catalogue of risks. Those risks are obvious candidates for your policy to address, in some way - but you're not home and dry yet. 

Planning policy implementation

How do you propose to treat the risks, in fact? What controls do you already have in this area, and how are they working out in practice? Is it feasible to introduce a raft of security changes in one hit, or will things need to be phased in gradually over a period, with management support, training, new technologies and more? What changes are needed first, and why? How will they be planned, executed, monitored and controlled? What will business managers make of the emerging proposal, and why should they  support and authorise it?  

True, this is starting to look more like strategy than policy development but actually the two are (and often should be) closely linked. Your policy need not be perfect and totally comprehensive at the outset. There are definite benefits in starting small, letting the policy and supporting practices evolve flexibly as the organisation gradually adapts, learns and matures. Ideally, the policy should be as much empowering and motivating, as it is controlling and constraining, on the basis that the future is highly uncertain, the risks unclear, and the policy audience is both smart and trustworthy (we hope!).

As usual, here's a $20 generic policy template if the standard's suggested topic-specific policy isn't enough to get you going - a pump-primer as it were.

The template policy covers acquisition of commercial software as well as bespoke in-house or contracted out development, and two distinct but related aspects:

1. The need for information security and quality assurance controls to protect both the development and acquisition process and the associated information assets.
   
   
2. The activities necessary to identify and take due account of information security requirements for the IT system, application, or indeed information service being developed or acquired.

 

Policy implementation

Preparing a policy, however fantastic it may be, is necessary but not sufficient. There's more to do. What does it mean, in fact, to 'implement' a policy? Policy implementation may involve:

• Making those who are affected by the policy, particularly those who are expected to do or not do certain things to comply with it, aware of the expectations or obligations, perhaps training, encouraging and supporting them to act accordingly.
• Preparing procedures and guidance amplifying and explaining the policy in more practical terms, translating management's formal direction into plain language that makes sense in the operational business context e.g. 
• How should workers 'keep up to date with security patches'?
• Why is it necessary? It's reasonable for workers to question why they have to do anything different, and ask what's in it for them. 
• What - if anything - do they need to do, or not do? 
• When should things happen, checking for updates for instance? Are there to be regular activities, proactive or reactive things, both, or something else?
• Who is expected to comply with the policy? What about the assurance aspects such as checking/measuring, reporting and achieving adequate compliance? 
• Who is expected to own and maintain the policy and associated procedures etc. Also how and when?
• Adjusting existing working practices both directly and indirectly affected by the policy, emphasising any important control elements (such as the appropriate people being informed when security-related patches are released, promptly patching high priority servers) and if possible integrating other aspects through more subtle adjustments (e.g. casually mentioning security patching as an example during worker orientation training).
• Putting in place complementary/supporting controls, not least those specified in the policy e.g. patch management systems, identification and quarantining of unpatched systems, patch testing for BYOD and corporate systems, patch delivery and follow-up ...
• Operating the policy routinely, gradually becoming part of business-as-usual (hopefully! If it doesn't, it clearly isn't working as intended, suggesting the need to review and revise).
• Providing compliance incentives or rewards, supplementing noncompliance penalties. This can be a surprisingly motivational approach - perhaps something as simple as a few words of encouragement and thanks to people or teams that make a genuine effort to comply.
• Building on, strengthening or supplementing the policy where appropriate, in the light of experience, as the policy and related processes and controls mature.
• Updating the policy as things change, including cross-references to other relevant policies and procedures.

 

Policy development procedure/checklist

There's clearly quite a lot to do beyond drafting and approving the policy itself. I guess you could develop a policy about implementing policies (!), but more useful might be a generic procedure or checklist reminding people of what should happen - perhaps something simple along the lines of the bullet points above. It needn't even be documented as such, provided those involved know what needs to be done and do it, routinely, reliably, efficiently and effectively: would further documentation and control add net value i.e. deliver business benefits exceeding the associated costs of yet more red tape? If so, go ahead. If not, well you've reached the end of the line and there are almost certainly more important things to do.

After a short breather to gather my thoughts, I'll wrap up this blog series about the 11 'topic-specific' information security policy examples coming soon in the next release of ISO/IEC 27002. 

The end is nigh!