CHAPTER 8: MARCH: SLIPPING THROUGH THE NET

The impact of politics

In the time line when the core of this research was experienced, the UK political landscape was changing beyond recognition. In the UK public sector, when an election is forthcoming, there is a period of time referred to as ‘purdah’, the period of time from when an election is announced until after the election is held, now more often referred to as the pre-election period. During this time, there is an immediate hold on spend, no new projects get approved and ultimately money gets clawed back on already funded projects. This renders most employees feeling quite ‘stuck’, unable to progress existing plans, uncertain of their future, depending on the political leaning of their organisation and the likely impact a change of government will have on their future and that of their landscape. Stasis exists.

There will be another one in 2015, so bear this in mind if that’s the sector you are in. If you are new in the sector or the role, at such a time, it can be quite bewildering as all your planned time lines for delivery of security improvement programmes change suddenly and come to a grinding halt.

This thread will be picked up again in Chapter 10.

Privacy impact assessments

In November 2007, the UK public sector approach to data handling turned on its access as a result of a government department’s loss of two CDs. The subsequent months brought forth a relentless number of reviews, inquiries and report outputs, all of which came up with relatively similar conclusions surrounding the need to embed better information security culture, awareness, education, data handling, etc. at all levels across the organisation and the public sector as a whole. The resultant data-handling requirements were mandated. In November 2008, a year on, the Information Commissioner held a conference entitled ‘Privacy by Design’ at which he launched the results of some research done. (See www.ico.gov.uk/news/current_top ics/privacy_by_design_conference.aspx.) The end result was the uptake of the habit of undertaking PIAs as described below.

Definitions

Personal data – This is any data from which a living individual can be identified, whether stand-alone or when combined with other data available to the organisation.

Privacy – The definition of privacy goes beyond personal data to include actions that may intrude on an individual’s personal life or affairs. This may include monitoring or screening that will not be held in permanent form.

Benefits of undertaking privacy impact assessment

There are many risks associated with the processes and technology used in the handling of personal data. By identifying risks in the early stages of the project, they can be avoided or mitigated whilst there is still the opportunity to effect change. Changes made at a later stage or after implementation can be costly, both in financial terms and in damage to reputation.

When any new process or system is proposed, consideration should be given to the impact it may have on the privacy of the stakeholders and, where appropriate, a PIA should be undertaken. Equally, a PIA should be undertaken where significant changes to existing processes or technology are proposed. The assessment involves reviewing proposals in the early stages of the project to identify the risks related to privacy for all those it may impact upon, and documenting proposed solutions and ways of mitigating privacy risks.

Risks to the individual

These are loss, damage, access or use by unauthorised persons, and personal data being exposed or getting into the public domain. Also, consideration will need to be given to any activity that may contravene the individual’s rights.

Risks to the organisation

These are damage to reputation, legal/compensation costs, low adoption of scheme by stakeholders, costs to redesign systems for greater compliance, and collapse of the project or withdrawal of support.

Data considered to be high risk

Sensitive data, as defined in the UK Data Protection Act, can be described in brief as covering health, ethnicity, sexuality, offences, political opinion and trade union membership. More usually, these are listed as:

• racial or ethnic origin
• political opinions
• religious beliefs or beliefs of a similar nature
• membership of a trade union
• physical or mental health or condition
• sexual life
• commission or alleged commission of an offence
• proceedings for any offence or alleged offence, or sentence of court.

There should be an expectation that personal contact information is kept confidential, including e-mail addresses, phone numbers and home address. Other information to be considered includes financial information, details of individuals at risk and travel plans, which could also present risks.

Expected outcomes

These can be expressed as:

• identification of privacy risks
• understanding of privacy risks from the stakeholders’ perspective
• identification of alternative options
• understanding of acceptance of the project
• identification of ways to lessen/avoid negative impacts on privacy
• where negative impacts are unavoidable, justification for accepting risks
• documented evidence that privacy has been considered
• dissolution/cessation of the project, if it is clear that it is not going to meet legal obligations or compliance requirements, or if is not going to be possible to maintain the appropriate and expected levels of security and privacy for the individuals’ personal data involved.

All of these can be incredibly important and valuable, depending on who the audience is and who your stakeholders are.

To enable the assessment to take place, the following information must be gathered.

Conducting a privacy impact assessment

All groups who may have an interest in, or be affected by, the project should be identified, with a brief description of their role and the nature of any likely impact.

Carry out an environmental scan. Learn from other projects, whether internal or in the wider external environment. Useful sources include:

• project documentation for previous projects, including LLLs (especially where the project is aimed at replacing existing technology);
• reports, articles and papers in the public domain;
• discussions with others with expertise in the project area or with knowledge of compliance issues;
• when purchasing new technology, discussions with reference sites may provide information on how they have addressed privacy issues.

In most circumstances, for projects which involve personal data, a small-scale assessment will be appropriate. Examples of projects where a small-scale assessment would be appropriate include:

• replacing an existing personal data system by new software;
• design and development of a system where the data held is on a consent basis;
• changes to an existing system, where additional personal data will be collected;
• a proposal to collect personal data from a new source;
• creation or redesign of web forms for collecting personal data;
• development of new procedures for authentication;
• plans to outsource business processes involving storing and processing personal data;
• developing or amending policy statements relating to staff usage of council-provided technology, e.g. mobile phones and laptops.

A full-scale assessment should only be considered where there is likely to be considerable impact on your organisation’s handling of personal data, including one or more of the following activities:

• use of technologies that could impact on privacy;
• use of sensitive personal data (as defined in the Data Protection Act, e.g. race or ethnic origin, health, political opinion, religion, offences, sexuality);
• use of confidential information or information which could be used for identity theft, e.g. bank account details or other financial information;
• use of excessive authentication data, e.g. biometrics (fingerprints or iris scans) or copies of birth certificates or similar documentation;
• publication of unprotected personal data without consent;
• sharing of sensitive data with third-party organisations;
• holding of large quantities of personal data relating to an individual;
• holding personal data relating to a large number of individuals.

Conducting a small-scale privacy impact assessment

The following phases are recommended in the Information Commissioner’s guidance:

• Preparation phase: make arrangements for a consultation exercise. Identify the main stakeholders and develop a consultation strategy/plan. In small-scale projects, this may not need to be formalised.
• Consultation and analysis phase: discuss privacy issues with key stakeholders to enable the identification of the main risks to privacy. This phase also includes the identification of possible solutions. Consultation can, in some circumstances, be on a small scale, e.g. e-mailing key stakeholders for their views.
• Documentation phase: record the outcomes of the analysis, either in report format or by using a checklist, with any relevant documented information attached. Alternatively, risks and solutions can be included in a project risk register, where available.
• Review phase: any recommendations should have a brought-forward time, in which the documentation should be reviewed to ensure that the solutions have been put into effect and to review the success of such measures. Any new aspects to the project should also be reviewed to ensure that they do not impact on privacy.

Compliance with legislation and regulations

In addition to the PIA, the project owner/leader must ensure that the project is compliant with relevant legislation including:

• Data Protection Act 1998
• Human Rights Act 1998
• Regulation of Investigatory Powers 2000 (RIPA)
• Privacy and Electronic Communications Regulations 2003
• Sector legislation and Codes of Practice.

Other legislative considerations in the UK include:

• Anti-terrorism, Crime and Security Act, Section 11 – Retention of Communications Data 2001
• Civil Contingencies Act 2004
• Computer Misuse Act 1990
• Copyright, Designs and Patents Act 1988
• Criminal Justice and Immigration Act 2008
• Defamation Act 1996
• Electronic Communications Act 2000
• Environmental Information Regulations 2004 (EIR)
• Freedom of Information Act 2000
• Government Connect Code of Connection (CoCo)
• Obscene Publications Act 1959 & 1964
• Payment Card Industry Data Security Standard (PCI DSS)
• Waste Electrical & Electronics Equipment (WEEE) directive.

Across the globe, there is a plethora of information-led legislative statutes that apply to organisations, and the ISM role includes the need to identify these and document them for reference and compliance purposes.

There seems to be a tendency for those who bury their security function in ICT to have a very narrow view of what compliance means. It is far beyond complying with a technical control, like a firewall rule set. It is this and so much more – compliance with all policies, procedures and guidelines as required by the legislative, regulatory and statutory frameworks to which your organisation, in whatever sector it is based, is expected to adhere.

Addressing privacy risks

By addressing privacy risks up front in any new system development or process change, your organisation can avoid the risk of falling foul of the applicable data protection legislation:

• Minimising data collection to information necessary for a specified purpose, and restricting its use for that purpose, is an important strategy. If you don’t hold the information in the first place, you can mitigate your risks by not recording it at all.
• Eliminating collection of contentious data is another, i.e. blocking the use of particular information for decision making.
• Non-collection of biometric data for authentication is another.
• Delete or destroy data on completion of transactions for which it was required – this is best achieved through the application of retention and destruction schedules (in conjunction with RM).

It’s important to use your organisation’s complaints process to determine avoidance and mitigation measures. You can easily identify trends when you see what people are complaining about. Ask for a review of a few months’ worth of external complaints, as well as internal user complaints. There is often some gold to be sifted therein. Users can spot when there is too much data being asked for on new forms, or are aware of historic forms where the data is never required or never used in any meaningful way. It needs to be part of your communication strategy to engage in this way as it becomes part of your risk mitigation.

A PIA can be carried out at any point on existing systems, too, so that you have one as evidence of the above considerations having taken place. You could schedule to do this for corporate systems, in particular, throughout the year, and then be able to refer to the outputs and update them annually in case there have been any external legislative or regulatory changes, or internal system or process changes.

Managing a virus outbreak

Remember Conficker? It was painful if you experienced it in your organisation – and the instant response, as with any major virus outbreak, is to keep quiet. But you need to take action, so you have to get people involved, in particular, in locking down the offending machine(s) and patching like crazy! Given that your users can just as easily leak information to the outside as anyone else, handling communications becomes part of your ISM role and needs to be done very carefully. Upwards management amongst you and your teams internally, as well as across a large organisation, takes staging and resourcing, too.

Obviously we’ve talked about the requirements for patch management and vulnerability assessments, and when an outbreak like this occurs, it is literally your chickens coming home to roost, as it is the most obvious result of the lack of housekeeping that needed to have been done. The first patch for Conficker was issued in October 2008, so to be experiencing it in your network in 2010, and to be exposed, was pretty embarrassing and told quite a tale in itself. Whilst the inner child in you desperately wants to shout from the rooftops ‘I told you so’, it obviously isn’t the polite, politically correct or job-enhancing response, so tread lightly!

We found, through some rapid network analysis, that there were many devices showing they had the hotfixes for Conficker applied. But it was hard to gauge whether the data being presented was wholly accurate and whether all the servers and other hosts were present, given there was a gap between the known total number of devices and the number of devices analysed. (Back to my Chapter 1 checklist of tasks – it is vital that you have that inventory of your estate accurate and up to date at all times, for just this kind of eventuality.) The scan across the network only picks up what is visible in the configuration management system and, thus, if it is not visible, it is not captured and the network may be exposed.

NT4 had no patch against Conficker because, of course, it was on Microsoft’s planned unsupported software listing and, therefore, there were no plans to bother with it. So, at the time, if you were still hosting NT4 machines (and they still exist out there to this day), then they were, and are, ‘at risk’ of virus exposure.

The IPS was generating warnings from a host network obfuscating behind the proxy and DNS. This is odd behaviour and indicative of the creative nature of the malware itself. Finding the host was the first task, as it was sending out replication messages across the network for as long as it was allowed to broadcast a signal.

So, what do you do if a significant part of your estate has not yet been updated? It transpired that there were, in fact, quite a number of servers that had not been audited because the anti-virus system had been turned off. The anti-virus technology stops communicating if it is not updated, and the users needed to be set up in appropriate groups to have their local machines updated. In spite of these glaring compounded risks, decisions needed to be made urgently in order to get to a position where the anti-virus system could be put back on, across the whole network.

Whilst turning off the technical solution may solve one problem, for a short period of time, it may invariably create another risk. In panic mode, there will always be impractical considerations with regard to what could be done manually and technically, so your role as ISM is to maintain a level head and manage the teams and resources necessary to achieve a satisfactory outcome for all.

Applying hotfixes across a WAN can be tricky, but is part of your solution set and again requires some planning in order to ensure that users leave their machines in the appropriate ‘switched on’ state to allow for the application of the hotfix. This relates back to our discussion in Chapter 5 about needing to be aligned with the IT folk addressing ‘green’ IT, whereby they would be seeking to ensure that machines were switched off every evening. Co-ordination and communication were going to be required in order to achieve the desired outcome on this one (as with all other tasks and challenges).

Other information security tasks this month

Maintain a lively and trustworthy intranet presence

You need an interactive intranet that is regularly updated with useful information – FAQs and guides, as well as policy documentation – so that people know that there is a trusted source of information. Seed this with an equivalent RSS feed of daily news items that reflect issues that are bound up in good information security practice, or are evidence of why it needs to be in place. Most breaches are reflective of ‘there but for the grace of whoever you worship go the rest of us’. Often it is only a matter of time – no one can be complacent and the larger your organisation, the greater the risk of an ill-informed user making a human error – without meaning or malice, it’s just the reality of the law of averages.

Things we were asked for included ‘Instant Astrologer’ and access to ‘www.mates.com’ … um, really?

Inventory management (again)

I thought I’d heard it all with the dictaphones query, until I was asked what we were doing about camcorders! Somewhere, in the many lists of things you need to keep juggling and spinning as an ISM, you need to have an overview, for each team, section, department and directorate, of what their function is and what type of equipment that means you should expect them to need to use. This kind of information could already be being gathered by your colleagues in the RM area, as it should be being picked up under ‘what media do you use to capture, use, share, store information?’ Either way, you need to be able to research the requirements and to help design the most appropriately secure solution.

Security awareness theme

This month’s information security theme could pick up on any subject of your choice. In this particular example and with experience from the chapter, tackling anti-virus best practice would be the obvious choice! As long as you encourage the users to ensure that they update their own anti-virus product on their home machines, they will appreciate, from the tip of the iceberg, the scale of the effort you will be applying across your whole organisation when it comes to protection mechanisms.

Chapter summary

This chapter has, in particular, focused on the mechanisms that constitute a PIA process. This has been done in order to help assist the ISM with appreciating the role they play in steering the organisation to conduct, such assessments and keeping track of the results on an ongoing basis.