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.
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.
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.
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.
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.
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.
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:
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.
These can be expressed as:
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.
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:
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:
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:
The following phases are recommended in the Information Commissioner’s guidance:
In addition to the PIA, the project owner/leader must ensure that the project is compliant with relevant legislation including:
Other legislative considerations in the UK include:
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.
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:
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.
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).
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?
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.
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.
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.
3.146.221.144