Specifications for a consultant

[In response to a LinkeDin query about finding an information security consultant for a 'security compliance project' (whatever that means!), I developed a slightly shorter version of the following advice, extending something I wrote much earlier in relation to finding a contractor/consultant IT auditor. I think the basic principles are quite general and deserve a wider airing, so I'm repeating them here for now. I may yet turn this into a paper for one of the websites or journals if the feedback is positive, provided I ever find the time and energy to continue.]

In preparing to contract with a consultant, there are maybe three or four distinct aspects to consider and document. Some issues blur across the aspects shown, and there may well be other factors you need to consider. Furthermore, answering the rhetorical questions below may involve reviewing other answers, plans etc. - this is an iterative process of Consider - Document - Review - Reconsider ... 

1. Define the work package or project including the business case, the objectives and deliverables, scope, resources, key parameters and ideally the metrics that will be used to determine and drive its success. Perhaps develop an outline or even a detailed project plan. Identify key milestones. Think about how the assignment fits in with others activities, initiatives, strategies, constraints etc. What are the project risks and opportunities, and how will they affect things? [This information would still be needed if the job was to be performed in-house. It is worth investing you and your colleagues' time to get this part right from the outset, and in fact to maintain it as the project proceeds since things often change (particularly the scope and hence the deliverables, but also the resources and timescales and hence the costs: see Val IT).]
   
   
2. Determine what type/s of person or people you want for the assignment. What qualifications and experience matter most? Are you happy with a junior or do you have enough of a challenge to tempt a guru into full engagement? What are the personal characteristics that would particularly suit the job (e.g. drive, resourcefulness, flexibility, creativity, attention-to-detail, wisdom, good dress sense ...), or conversely would be unsuitable? What Myers-Briggs Type Indicator would your ideal person probably have? What kind of person would you personally like to work with - a friend and mentor or self-contained get-the-job-done type? Are you looking for a consultative, assistive or collaborative approach from them, or something more confrontational or challenging? Someone who fits-in with your preconceptions, culture and ways of working, or someone a bit different to stir things up, innovate and introduce change? A team-player, leader or loner? And, talking of team, who will they be working with, and what are their drivers, needs and preferences? [There are plenty of creative possibilities in this section to go well beyond the traditional job specification. Thinking it through, writing it down and discussing it with candidates (both before, at the start and during the job) increases the chances of them doing what you want, and is a good way to identify emerging issues that can be addressed at the earliest opportunity.]
   
   
3. Determine how the project/assignment will be managed and paid-for. How would you like to relate to/manage/deal with the consultant(s)? Do you want them to take the lead, drive the job, report their findings, generate action plans, deliver specific deliverables etc. or do you purely want a lap-dog to do your bidding under your strict guidance? Or something else? Seriously, who's in charge? Are you thinking about someone to organise and coordinate/manage a team of information security pros, or a lone worker? How will the deliverables be assessed for quality, suitability and customer satisfaction? What about those metrics mentioned above: do you want daily/weekly status updates, monthly progress reporting, a completion statement, timesheet and invoice, or what? Do you expect 9-5 attendance on site, 6-8, 24x7, weekends and holidays, off-site working, mixed on/off-site, multi-site, occasional hours or days or weeks, or what? Can the consultant take lunch breaks, tea breaks, holidays, sick days ... or is it full-on nap-under-the-desk stuff?! Will you pay an hourly/daily/weekly/monthly rate for as long as it takes (or up to a certain fixed amount), or agree a fixed price up-front, possibly with initial, interim and final settlements)? If things back-up or go wrong, do you expect the consultant to work additional hours/days/weeks to get them resolved, and if so will you pay (do you have contingency in your budget, and what are the criteria for using it?). How will things be addressed if the consultant is not performing as expected? Who makes the key decisions - you, your boss, a project board/committee or ??. At the end of the assignment, what will happen: will you shake hands and part company, or is there a genuine prospect of further work in the pipeline if everything goes well? This governance and management stuff is another important section, often neglected. If you get this section right, your working relationship with the consultant/s should be much less stressful all round (exactly the same point applies, by the way, to the consultant/s!).
   
   
4. Determine and clarify the broader context. Think carefully about the corporate, business and even industry and social contexts for the job, recognizing that the situation as it is today may change in due course both because of the assignment and despite it. Review the drivers, objectives, timescales, constraints and risks to distinguish those that are genuinely cast in stone from those that have some flexibility. Think about other strategies and parallel initiatives, and how they might or will affect the job. For example, are you at the primitive or more advanced stages of maturity, today, and where do you expect to be in a few months' time? Aside from the identified, discrete deliverables of the project, look for other more subtle changes in the organization if the project is a success (and, for bonus marks, consider the full range of possible outcomes from 'wildly exceeds all expectations' to 'abysmal, abject failure'!). [Note: this is an ongoing activity throughout the assignment but it will help the consultant/s get off to a good start if you have considered it in advance.]

I fully appreciate that one of the main reasons for seeking consultants and contractors is that you are resource constrained, and that addressing all of the above is yet another drain on your valuable time and effort. On the other hand, as an auditor reviewing numerous projects, I usually found myself wishing that the project sponsor, manager or board had paid attention to the items shown - in some cases, not just 'paid more attention', but given them any thought whatsoever! Project governance and management are tricky topics even for highly-experienced, well-qualified professionals, and I urge you to prepare proactively for proper projects because prior planning prevents piss poor performance (or something like that). Do your homework.

Rejected ISO/IEC 27002 control on cloud computing

Suggested text for a new control on cloud computing

Back in February 2011, I proposed to incorporate a new information security control on cloud computing into ISO/IEC 27002 which was being revised by the committee at the time.

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

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

Control objective

To identify and mitigate the information security risks associated with cloud computing.

Implementation guidance

The organization should analyze the information security risks associated with its intended use of cloud computing and specify appropriate risk treatments, normally including specific information security controls such as those outlined below, as part of the process of determining its requirements for cloud services. The following information security controls are not meant to be comprehensive, but suggest typical information security aspects to be taken into account when implementing cloud computing:

a) Selection of cloud service providers: individual cloud service providers may have quite different attitudes and policies towards information security, so the organization’s information security requirements should be taken into account as part of the supplier selection process both specifically (e.g. specifying the information security design as part of the invitation to tender) and generally (e.g. specifying that the providers should have an information security management system certified compliant with ISO/IEC 27001). The organization’s information security control requirements may have to be specified contractually if there is a commercial relationship between the parties, and if not the risks may be substantial. 

b) Technical architecture: the cloud computing architecture (e.g. public, private or hybrid clouds) should be determined as this is likely to affect both the information security risks and the control options available. Security and ownership boundaries and interfaces should be clarified.

c) Security design: the system architecture and design specifications should specify the information security controls necessary to address the identified risks, whether this is documented as a discrete security design specification, or integrated into other system design specifications.

d) Authentication of users, systems and services: authentication controls must be designed to work properly in an essentially untrustworthy shared network and computing environment, normally requiring the use of strong cryptographically-based authentication techniques.

e) Confidentiality controls: suitable logical access controls must be incorporated in order to protect both the data and the cloud services from inappropriate and/or unauthorized access. The design must take account of privileged functions and rôles used to administer, manage and control cloud services, databases, data sets and data files, interfaces, security controls etc., many of which are likely to be within the domain of the cloud and network service providers rather than the user organization. Data encryption or anonymization may be necessary. Access controls must also adequately segregate data belonging to different organizations sharing the same clouds. The right to control access is normally determined by ownership, so ownership of data and cloud services, equipment etc. should be clearly identified.

f) Interfacing: cloud computing may not be appropriate for all the IT systems and processes in an organization, for example if the associated information security risks cannot be sufficiently mitigated, or if there are no suitable cloud services available. Therefore it is likely that information will pass across interfaces between non-cloud and cloud-based IT systems, and possibly between distinct clouds in some architectures. Information security risks associated with the interfaces should be determined and suitable controls specified e.g. applying authentication controls and data integrity checks on both sides of an interface.

h) Availability: while the distributed, geographically dispersed nature of cloud computing may appear to reduce the risks associated with physical security incidents at specific locations, this is by no means certain as there may be critical nodes, servers and network links within or associated with the cloud. Controls such as resilience and reliability, backups, redundancy and failover measures and incident management procedures should be specified and incorporated into the design, and where appropriate agreed with the cloud service providers, in order to achieve sufficient availability. Availability of the cloud services may also be an issue, for example if a service provider pulls out of the market or ceases trading – this is basically the same issue as with all suppliers.  If cloud services are critical for the organization’s operations, business continuity arrangements are probably required.

i) Compliance and assurance: if the organization is subject to information security compliance obligations (such as privacy, governance and other information security-related laws), these may have implications on the cloud services and service providers. Furthermore, although the organization may specify its information security requirements on cloud service providers, compliance or assurance measures (such as security tests, reviews and audits) may be justified in order to ensure that the obligations are being fulfilled. Extended access may be necessary to obtain forensic evidence following information security incidents (e.g. privileged access to system security logs and audit trails in the cloud). Legal and jurisdictional aspects of the arrangements with cloud service providers must be addressed during the contracting/procurement process in order to forestall possible problems later (such as the service provider unilaterally withdrawing or changing the service or excluding the organization, taking control of or deleting or changing the organization’s data, denying responsibility for or failing to notify the organization about information security incidents, failing to license essential intellectual property etc.).

Other information

Cloud computing including SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service), enables convenient, on-demand, network access to a shared pool of configurable computing resources (networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Service providers are able to offer specialist applications to multiple customers on distributed cloud platforms. Offsetting the advantages, cloud computing creates novel information security risks concerning the confidentiality, integrity, availability, control and ownership of information assets, particularly where cloud services are provided by independent and often physically remote organizations through the Internet. 

The business case for adopting cloud services should incorporate information security aspects. Strong information security controls can support the business requirements and enable the organization to reap the benefits of cloud services, but the costs of specifying, providing, using, managing and maintaining the controls must be taken into account in order to avoid them being under-funded and hence inadequate in practice. 

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

In the event, the ISO/IEC JTC1/SC27 working group responsible for the standard rejected the proposal, declining to cover cloud computing explicitly in ISO/IEC 27002.  Admittedly, other SC27 projects on the drawing board at the time were destined to produce separate cloud computing security standards, and there was a bit of a bun-fight between the proponents of various approaches. 

As eventually published at the end of last year, ISO/IEC 27002:2013 barely mentions cloud computing as such, apart from a throwaway line casually tagged-on to the end of 15.1.3 "Information and communication technology supply chain as addressed here includes cloud computing services."  

Yes, that's it. Cloud computing security dismissed as a mere example of an ICT supply chain security concern.

Personally, I think SC 27 missed a golden opportunity to at least outline some of the key infosec risks and recommend a few baseline controls for cloud computing, perhaps a cut-down, wordsmithed, committee-approved version of the text I provided but rather more than those 13 blink-and-you'll-miss-em words.

Things have moved on apace since I wrote the suggested control text three years ago. If I was writing it again today I would probably change a few things here and there. This is a perennial problem with developing standards in such a dynamic context, one that highlights the often glacial pace of international standards bodies. The world doesn't stand still for ISO/IEC!

I'm looking forward to the ISO27k cloud computing security standards.  When they eventually emerge, I trust the wait will prove worthwhile.

OK, that concludes my miniseries of bloggings about suggested controls that didn't make it into the 2013 versions of ISO/IEC 27001 and 27002. 

6th April update: I've just been reading through the comments on the Committee Draft of ISO/IEC 27017 - an ISO27k cloud computing security standard.  Although ~100 pages is a lot of feedback on a CD standard, roughly two-thirds of the comments have been accepted, implying that the project is moving along nicely.  I really should check whether the CD takes account of the issues noted above.  So much to do, so little time ...

PS  I also proposed new or changed security controls for:

• SCADA/ICS (industrial control systems)
• The computer suite (mostly physical controls)
• SDLC (software development life cycle) and
• BCM (business continuity management)

What are KPIs?

Krag and I have discussed this question from time to time and, although we are broadly aligned in our thinking, we haven't yet totally resolved our differences ... which makes the exchanges fun.

With that in mind, I always wonder what someone really means when they talk about KPIs. To some, Key Performance Indicator has a very specific and particular meaning, although I suspect if we assembled a dozen such people in a room to discuss it, we'd soon end up realizing that we have more than a dozen different interpretations! 

To others (including me, as it happens), KPI is a generic, blanket term for a class or type of metric that satisfies the criteria implied by the term: 

• Key implies that the metric itself is especially important, crucial or vital even, given that there are many many different ways to measure and assess things but most of them are of limited value. Picking out the few things that truly matter is a core issue in metrics. 'Spam volume' is an example of a metric that is both narrow and shallow, whereas 'email risk level' is a much broader, deeper and richer metric, and is far more likely to be considered key (even if we happen to be talking specifically about metrics relating to spam filtering). However, the criticality and value of metrics does depend on the contexts or situations being measured and the perspectives and information needs of their users. It is conceivable that 'spam volume' may be considered a KPI for the anti-spam controls, but that's a narrow perspective. Key may also refer to the performance, in the sense that the KPI is an indicator concerning an important issue; 
• Performance is a distinctly ambiguous word, implying concern for the process and/or its outcome. Are we measuring key activities (typically in order to assess and improve the efficiency of the process) or its outcomes (typically to assess and improve the effectiveness of the process), neither or both? I have seen KPI used in several different senses, although usually it is not totally clear (perhaps not even to the person discussing it!) which one is meant; 
• Indicator generally means simply a metric or measure but it may imply imprecision or approximation. A typical car's fuel gage, for instance, gives a fairly vague indication of the amount of fuel in the tank, whereas the equivalent metric on an aircraft tends to be much more precise, accurate and reliable, for obvious reasons. The car's fuel gage may not tell you how many litres remain but if it heads into the red zone, you know you need to find a filling station soon. Indicator often also implies a forward-looking or predictive rather than purely historical measure. 'Trends' are common examples, used to manage various aspects of information security where precision is nice but not vital (e.g. supporting security investment or resourcing decisions). 

As far as I'm concerned, then, a KPI is generally a predictive metric concerning some critical outcome of an important process. In the information security context, KPIs are most likely to measure core security processes such as risk assessment, and key controls such as authentication and access control. Efficiency is secondary to effectiveness, in that security failures resulting from ineffective controls can lead to serious and potentially very damaging incidents, whereas inefficient controls are merely a bit wasteful (that's actually a strong bias, one worth challenging in situations where security becomes onerous for information users and administrators, perhaps so onerous that they bypass or disable the controls sending us back to square one!).