Issue area |
Description |
Commentary |
Start earlier |
The organisation compressed efforts into a ‘what can we get away with’ mentality, with a two-month window, and did the ‘minimum’ to gain connection to a secure network infrastructure. This left ICT workers overstretched, stressed and behind on their normal day jobs. It left users bewildered by the scale of change to their desktop/working environment and frustrated by the number of niggles that needed to be ironed out through the process of change. A number of the niggles were as a result of mistakes made by the overworked ICT project team members, compounded by a rudderless systems team and servers that had suffered appalling neglect over an extensive period of time (plural years). |
If a project looks too difficult to do, it probably is – but fear is not a good-enough reason to not start the processing of action sooner. Invariably, there will be resources available to provide the appropriate advice as to how best to tackle the ‘whole elephant’, and they need to be engaged sooner and relied on more heavily initially for skills transfer.
Bottom line: start earlier and provide more management support for the project team. Ensure knowledge is gained in the subject area early enough to appreciate the scale of the task. |
Working together – including bringing the ‘customer’ in early on the project. But not engaging everyone! |
Once the team were galvanised, and empowered sufficiently that they felt their contribution was both valued and welcomed, their activity level increased significantly and had a hugely positive impact on the ultimate success of the project.
Bringing the customer in early on the project was hugely beneficial. |
In reality, most projects are really not isolated activities and so there is always a need to engage across all team members and keep people informed, even if they are not on a specific project team.
Also, provide the project team with a feeling of engagement, which means they have something that binds them together. (OK, so ours was partly sweets, but it helped!) |
Holiday management |
Active project management requires rigorous attention to any ongoing reduction in people days available to a project, particularly during known busy holiday periods (i.e. July, August and December).
This has to be calculated in terms of actual number of days lost in any one week; if you are running a project in a compressed timeframe, this is unsustainable. The worst loss in one week was 32 days … |
You would have thought this was blindingly obvious … However, managing single points of failure becomes an impossible task if the project manager has no influencing capabilities over the project team members’ managers – or there is no active management support that affords team members the time to do their tasks properly, rather than on top of their day jobs. So set ground rules and boundaries in week one and make sure commitments are adhered to and priorities appreciated. |
Loss of momentum |
On several occasions, a loss of momentum (LoM) was experienced. This was as a result of the culture of seeing this as such an entirely separate project from BAU, even though all the snags that have been stumbled upon are as a result of BAU misconfigurations. In particular, there was an LoM from a successful extension application (i.e. an external deadline extension); there was an LoM during the summer holiday period and there was a further LoM as a result of having gained the compliance approval without continuing to close down the items on the snag list. |
Ensure management support is consistent and sustained. |
Project funding availability |
Without the injection of the executive-approved funding, this project would not have succeeded. The funding was only granted following significant effort by the externally recruited ISM, their preparation of various business case justification documents and delivery of executive briefings and presentations. |
Ensure that those charged with the task of delivering a significant project are adequately resourced and, if not, that only those with the necessary skills are put in front of executive management, with the ability to speak in a language that will resonate appropriately. |
Understanding wider implications |
Somewhere along the line, you have to understand that IT works on a ‘seven-stack layer’ and deep security infrastructure improvement projects usually deliver across all seven layers in order to provide the requisite level of protection for the nature of information traversing the network. |
Ensure vision of impact and likely coverage is captured at the outset and ongoing, as the landscape and requirements continue to be changed and formalised. |
Interpretation of requirements |
This relates to the ‘start earlier’ lesson learnt, because actually an earlier start would have afforded the adoption of the preferred solution, which is the application of all the requirements to the whole network, rather than to a segment. Either way, the technical solution adopted, in conjunction with external consultant advice provided at the time, left the organisation with a lot of work to do to maintain the current compliance expected.
This also relates to ‘lack of technical skills’ (below), as without the necessary internal skills to see the likely pitfalls, there was an element of ‘the blind leading the blind’. |
Ensure the right skill sets are available at the earliest opportunity. (Bit of a chicken and egg situation, this one, because if you don’t know you need to know a certain skill, then you don’t know, do you? Donald Rumsfeld, anyone?) |
Lack of documented processes |
Because people didn’t follow existing documented processes, where they were available, things were made up and guessed at which, under pressure, creates mistakes which take more time to be addressed. (See also ‘bottom-up decision making’.) The pace and scale of change meant that actions were taken ‘on the fly’. |
Ensure documented procedures are available for all known BAU tasks in all areas – and where they don’t exist, build them into the project as deliverables. All changes need to be raised through the change request process, so that they are appropriately tracked. |
Lack of server management |
Servers are not patched and kept up to date. There is no tangible ownership and day-today housekeeping of the server ‘farm’. The state of the servers, their lack of ownership and proper management, puts the accuracy, integrity and availability of those information assets (including users’ and citizens’ data) at risk on a daily basis.*
Lack of server management meant that servers were not up to date enough to be repurposed, so new kit had to be purchased at short notice and rolled out in a hurry, without the requisite security hardening applied, which was then (thankfully) picked up as a vulnerability that had to be addressed. So double the work was done, which could be ill afforded. This led to tasks taking longer than expected and each security control element was more laborious and more long-winded that it would otherwise have been. |
Ensure patch management is a responsibility and active role within the infrastructure management.
The servers, at the end of the day, are the custodians of the crown jewels of data that the organisation has a responsibility to protect. |
Lack of SLAs |
Service level agreements (SLAs) need to be in place between service areas and ICT, and internally between teams in ICT, to support each other and provide an appropriately expected level of service in response to requests (rather than just ignoring things or ‘shrugging shoulders’). |
Documented SLAs help everyone to have their expectations set and hopefully met (and sometimes even exceeded!) |
Lack of data ownership, management and prioritisation by users |
ICT ends up being responsible for issues that are, in essence, not of their own making, but are the responsibility of the users.
There are also links with green IT work, because just adding another server into your farm should not be the answer every time. |
Data cleansing is required – particularly when migrating to new systems. It is better to cleanse than to take erroneous data with you. There are links here with file management – and training in it is required.
Implementation of a proper RM file plan structure on the servers is required (it is appreciated that this is easier said than done!)
Users must be encouraged to take more responsibility for the data that they are, let’s face it, creating on a day-to-day basis. |
Lack of role profiles |
User access rights are currently not adequately managed and this needs to be addressed, so that groups of users can be migrated together, in the future, on the basis of their expected access rights, permissions, mappings, etc. |
Less user disruption is possible if the role profile exercise has been undertaken to identify who is doing what function, where, and what system access they require to do that job – on the basis of applying the ‘need to know’ principle. |
Lack of service desk management commitment |
There was a need to ‘pump’ out messages to the users across the whole organisation that the service desk would be experiencing an increase in volume of calls as a result of a specific project workload and to be patient. This was difficult to achieve without the proper involvement of representation from the service desk itself. |
Ensure that a) the service desk is appropriately staffed to deal with project ebb and flow, and b) that the users are communicated with en masse, so that they are aware that whilst they may be ‘screaming’ for resolution, there may, in fact, be an operational priority that exceeds their own immediate needs. |
Ensure kit is ordered in a timely manner |
There was a significant risk of time line slippage as a result of delays in ordering the large volume of PCs required to deliver this project – in spite of knowing that it was a requirement from the outset and knowing the suppliers lead time in advance. |
Ensure orders are placed as early as possible within the project – even though it makes the figures look scary initially (i.e. lots of spend up front) – but at least you can then plan the roll-out of equipment in the sure and certain knowledge that you actually have it available to you. |
Desktop ‘image’ problems |
Systems were included on the desktop image that were not needed – and some were missed out. It is not clear who did the user acceptance testing and why this happened, given that someone on the ‘customer’ side signed off the image as appropriate. This is symptomatic of ‘bottom-up decision making’ – see below. |
Ensure that the service area properly signs off on user acceptance testing of whatever is intended to be implemented for them. |
Lack of recognition of and reference to data protection and security issues in contracts |
There were issues consistently with regard to third-party suppliers not being adequately bound by appropriate contractual arrangements that addressed privacy concerns (data protection and security). |
Ensure all third-party suppliers are bound by appropriate contractual arrangements that address privacy concerns (data protection and security). Engage with procurement personnel to ensure this is addressed in contracts, as well as at a local level. |
Lack of software licensing management |
ICT staff and responsible information asset owners were unable to be clear about who had access to what software at their desktop (or what they should have access to). |
Ensure that you have an adequate configuration management system that captures all hardware, software and information assets, so that these can be appropriately identified, managed, secured and controlled. |
Windows® takes scripts literally |
An intelligent ICT developer wrote a script to copy all the users in A–J only, but Windows® thought it was smarter than the programmer (!) and copied only all the files beginning with A through to J, rather than everything under the user beginning with A through to J. And, randomly for a user, it picked up a six-year-old e-mail signature block and other users couldn’t see their .pst files or their address books for quite some time. |
Ensure time is available to understand the ramifications of the written word in script language, from a development point of view – but also ensure there is time to test system upgrades. |
Embedding passwords in systems is a bad idea |
Embedded passwords need to be identified as early as possible as, once you enforce a password management policy that requires a change every 90 days, a great deal of overhead is then added where these exist.
Passwords have been embedded in Access® databases and also in externally provided applications. |
Ensure that applications and systems across the organisation have been identified and addressed within the required password rules. |
User migration issues – corrupted privileges and excessive permissions |
FAF = file and folder – permissions were a huge issue in managing user migration from one area of the network to another.
User moves created a mismatch in server datasets and locations, for mapping drives and shares.
Corrupted privileges in the shared and home areas, as a result of the way the user migration took place, meant that operations staff could not resolve issues as they normally would, as they did not have the requisite rights. This was going to take some time to unravel, time that was not being allowed for within the day jobs of project team members. |
When undertaking a large-scale system or server migration project, wherever possible, encourage service areas to create a new, clean file structure for the shared area of the service and teams – identifying who needs access to which folders.
Apply new permissions from the top down (cascading them across the folder structure). |
Lack of technical skills |
Translation of security issues across existing technical disciplines proved difficult without an IT or InfoSec officer in post dealing with ICT colleagues on a day-today basis. There was no knowledge transfer of understanding risks, implications and impacts going on, and without this or allowing for these skills to develop over time, it was difficult for many ICT members to appreciate the potential scale of the challenge. |
Ensure that there are those capable of horizon scanning across the ICT landscape within which you are operating – both technically and from a security point of view – so that the two end up more in synch than in competition with each other. There really is no need for divisiveness in the delivery of ICT strategy and ensuring security is baked in alongside this. |
Back-up/restore issues |
Problems arose when restoring .pst files. This was a technical resource issue on the servers and needed to be addressed in order to ensure that the project team could successfully migrate larger numbers of users during later phases of the project. |
Regularly test support applications available to ensure that they operate as expected. It sounds so obvious when you type that and read it cold – but in the reality of a busy ICT team, it is easy to see how the obvious can get missed and forgotten – so make a note! |
Storage copy issues |
Problems were experienced with the infrastructure in place to provide storage for users, as security issues meant that it was necessary to do manual copies and restores. Again, this added project delays and needed to be resolved prior to rolling out more widely for the intended mass user migration. |
As per the previous comment, ensure that available resources operate as expected – without security conflicts – as these are exactly the kinds of issue that turn people off to security. They assume that it is going to slow up their system or cause problems, rather than solving them. |
Lack of SLAs |
SLAs need to be in place between service areas and ICT, and internally between teams in ICT, to support each other and provide an appropriate, expected level of service in response to requests (rather than just ignoring things or ‘sloping shoulders’). |
Ensure documented SLAs exist as these help everyone to have their expectations set, and hopefully met (and sometimes even exceeded!) |
Lack of controlled user registration and deregistration |
There was a need to ensure that all users on the network were appropriately authorised to be there and were captured in terms of their systems and building access, and that this was monitored and controlled throughout their employment, right through to their eventual departure. There was also a need to put in place mechanisms for addressing long-term sickness, career breaks, etc. |
Ensure that there is a ‘new starter’ form and a ‘leavers’ form (and a process to support these) on the intranet (or equivalent). More devices are being added to the environment all the time (often directly by the employee) and these need to be factored into a ‘leavers checklist’, in particular. |
Cloning live user data on test servers |
Test servers were, in the main, clones of the data that was held on the live servers, wholly in contravention with industry standard best practice, the Data Protection Act and the British Standard BSI BIP0002:2003 – Guidelines for the use of personal data in system testing. |
Adhere to industry standard best practice – the Data Protection Act 1998 and the British Standard BSI BIP0002:2003 – Guidelines for the use of personal data in system testing, ensuring that live data is not used in test situations. |
Lack of privilege management |
ICT users and generic accounts were not reviewed in order to justify their creation. This relates to the need for role profiles. |
Ensure that users are provided with the access to the systems they need on a ‘least privilege’ and ‘need to know’ basis, rather than on the basis of copying the last-known easy user to hand. |
Bottom-up decision making |
As a result of the lack of clear senior ICT management support for the project, its mandated requirements and its basic good housekeeping expectations with regard to information security management, the project team consistently had to make, in some cases, significant infrastructure decisions that should have been done through a management risk assessment process. This left everyone feeling exposed – but ultimately something had to be done. Inaction was not a sustained option. senior information risk ownership needs to mean something. |
Ensure executive management understand their responsibilities with regard to the required protection of information assets for which they have responsibility within their organisation. Ensure the role of senior information risk owner is carried out by someone who understands information risk management requirements. |
Never miss the blindingly obvious! |
Direct Internet access affected all Web-based systems. Making changes to firewall rule sets had significant impacts on users and consequentially on the service desk in supporting calls as a result of disquiet. |
Ensure good communication is provided in a staged and phased manner in order to pre-plan events and ensure everyone is ready for the potential impact of system and infrastructure changes. |
Lack of policy enforcement |
This was a significant issue across many areas. In particular, however, as a direct result of a lack of enforcement, users were able to download whatever they wanted, whenever they wanted it. This had, in some instances, brought viruses into the machines and the network and created maintenance and management issues in terms of supporting the desktops and laptops. Without a definitive (rather than ‘infinitive’!) software library in place to be able to refer to, it was impossible to categorically state to a user what was and what was not acceptable in terms of software downloads. |
Ensure clear policy statements are available, as well as appropriate supporting user guidance. Also ensure that metrics and measurements are in place to ensure that policies are being adhered to and user enforcement is evident – as are the consequences of not following policy. |
