CHAPTER 2: SEPTEMBER: STREET TRASH

Building your house from the sky down

Bono (U2), Spring 2011

Introduction

So, now that your team is up and running, you have your reporting in place and people understand what is expected of them, you are starting to get noticed and the programme of change is under way.

You have learnt a vast amount about the organisation already – if you have all the answers to the questions asked in Chapter 1, that is! No doubt, there are many people surprised at how interested you are in such a wide variety of issues. This is precisely how it should be. The ISM is interested in the security of information in all its forms, in all its locations, in all its transactions across the organisation and beyond. Remember, implementing and maintaining information security is not solely about focusing on bits and bytes – it requires the triad of people, process and technology-based solutions, controls and safeguards. Part of your ISM role is being able to express the importance of the tasks you are undertaking in executive management speak – so this is the language of risk and financials, not bits and bytes. The focus needs to be both strategic and service orientated, explaining security in pragmatic terms.

In Chapter 1, we looked at the requirement to know how many users there are across the organisation and how to manage them throughout the life cycle. Then you learnt that you need to check for duplicates of users in the various system resources. This may have arisen as a result of data entry errors when inputting the names originally. Not every system resource may be directly linked to a central Active Directory, or equivalent, and, therefore, there are IT administrators managing a multiplicity of systems with different directories of users. These need to be synchronised, so that the users do not lose any access rights or connectivity as a result of any data migration or server infrastructure changes carried out by IT.

Incompatible software

There are still many organisations finding that they are in relationships with third-party software suppliers that provide products that apparently cannot be upgraded, as to do so would, in all likelihood, cause incompatibilities and configuration errors. This means that any security patching or upgrading, which should have been done, has not been carried out for fear of affecting the currently working system’s performance. These are large software providers continuing to deliver substandard products, in terms of not having inbuilt security, to large organisations in both the public and private sectors. This is in spite of the length of time that this has been an industry-relevant mantra that should amount to best practice. Many available and widely used systems are having to be made backwards compatible by internal IT teams, rather than being patched to a future state of security. Given the number of users this can impact in some organisations, it can leave hundreds of PCs not patched to today’s expected security levels. It is unacceptable to continue to tolerate or support this situation.

It seems there are people across the IT industry who do not fully understand the OSI model – the seven-stack layer (see Table 1). Security needs to be happening across many of these layers, all at the same time, which requires a great deal of consideration and configuration management. People selling products may not appreciate this sufficiently to understand the impact of what they are going to be leaving an organisation with. There will then be a great deal of maintenance and support required afterwards to get the product, as sold, to deliver the benefits, as anticipated, and usually for a cost that was not factored in. This needs to be addressed and the ISM continues to need to have eyes in the back of their head to watch out for potential problems from all angles!

Table 1: OSI model (source: Wikipedia Commons)

In the UK public sector, given the austere times and recession-based environment that has been circling overhead like a black cloud since 2010, there is the madness of a central government approach to developing authentication systems, which is taking a great deal of time to get right, given its importance. Meanwhile, local government bodies have had to develop and implement their own, as they could not wait for the centralised system to be implemented. Yet more cost and integration issues will arise over time as the achievement of standardisation and centralisation is sought in an attempt to reduce overheads. In the meantime, the duplication of effort in terms of software, technology and policy requirements is significant, and the users are ultimately part of the fallout as they end up having to manage a number of authentication devices to access different systems and conflicting set-ups. I have often had to suggest to users that they will need a Lara Croft-style lock-and-load belt in order to contain their various authentication dongles, USB devices, mobile phones, PDAs and access cards.

This is, of course, almost the antithesis of achieving good security as the users will psychologically want to keep all their kit and equipment together in one safe place; but, in doing so, they may expose themselves to a greater degree of threat than the organisation is comfortable with, in terms of managing the risk. In your day job, as ISM, you will have to solve many of these conundrums, which require constant reassurance and ‘fleet-of-foot’ responses to questions and queries from the user base – and often slightly different answers for management.

Remote workers

Another conundrum within this space is identifying and clarifying who is a remote or homeworker. You need to know:

• Are all remote users remote?
• Are all homeworkers working from home?

Your ‘remote-working policy’ or equivalent really needs to contain appropriate definitions of mobile workers, in as many scenarios as possible, in order to ensure that the setup they are using is the most appropriate (safe, secure and reliable) one and the one that can be best supported.

Possible ways of categorising the different types of roles are provided in Table 2. The original source of this helpful approach was a white paper written by Siemens Enterprise Communications on contact centres.

The examples provided in Table 3 are for public-sector-type roles and organisations, but can be easily tailored to your requirements.

Table 2: Role categorisation

Table 3: Examples of public sector roles

Note: some office-based and flexible office-based staff may be required (or wish) to work from home/elsewhere, so appropriate provisions still need to be made. These may or may not extend to full ICT service access. The whole premise is one of flexibility in delivery.

The reason for spending some time on this, and providing resources, is that it keeps coming up in meetings and discussions as to who is captured under what category. Therefore, your best bet is to make sure that you have a clear remote (home/mobile) working policy that addresses this, so that you can keep referring to it as the central source of guiding principles to which you will adhere when you structure solutions to suit the needs of these roving users. We will be returning to this in Chapter 4.

Consumerisation will make this an even more important task, as you will need to have identified, specifically, what type of technology each of these users is operating in order to carry out their roles. You also need to clarify whether the devices are their own or whether they belong to the organisation, as there are clear impacts with regard to protecting the information, keeping the devices up to date and operating safely and securely.

Another aspect to this is that the increasing drive for achieving mobile and remote working for employees, to reduce organisational infrastructure overheads, may be exposing the organisation to greater risks in maintaining compliance with various regulatory, legislative and standards-based requirements. For example, if you had a number of payment card industry (PCI) users operating from home on an organisationally secured laptop, but taking credit card details over the telephone, potentially writing them down, faxing or e-mailing them, would you be happy or not? The reality is that there should be display screen equipment (DSE) related health and safety check going on in every home or remote environment where your user may be operating. However, it is appreciated that this is a potentially significant undertaking and, at present, in most cases there is only lip service being paid to knowledge and visibility of the circumstances in which your potentially classified information assets are being handled whilst not within your immediate scope of control.

User acceptance testing

User acceptance testing is vital and needs to be built into all change processes. Getting the right users at the right time in your programme plan can be a challenge. Going back to your Chapter 1 answer set, you need to know what users have access to which systems and try and create yourself some kind of ‘uber’ set of users – a control group, if you will – that represents the most likely and most used combinations of software and applications across the organisation. This is so you can call on them to test your newly configured desktop or laptop build, if you are rolling out new platforms or upgrading existing ones. Again, whilst this may appear to be a very IT-focused task, all roads so often lead back to a perception of any issue being the fault of security that it really is better to be involved and fully cognisant of what is going on than be the last to know. For too long, security has had a bad rap, being seen more as an inhibitor than an enabler and so the more that can be done to improve this perception, the better will be the information protection results overall.

Business as usual

There are many tasks explicitly described as security related that, in reality, need to be (by now) appreciated as being part of BAU for ICT (IT). In other words, they are not solely in the remit of the ISM or administrator. These include:

• access control
• anti-virus/malware
• back-up
• business continuity
• disaster recovery
• incident management
• patch management
• vulnerability assessments.

These need to be explained to your IT team, so that there is an understanding of ownership and responsibility for tasks. (I am assuming you do not necessarily have the luxury of many teams of people who will be addressing each element individually. In all likelihood, there are fewer people doing more tasks these days, and this is very much appreciated.)

In brief, for each area:

• Access control – IT needs to manage the process of setting up new users, deleting old ones or changing role profiles.
• Anti-virus/malware – IT needs to ensure that there are up-to-date signatures and fully managed and licensed products on all nodes of the network – servers, desktops, laptops, etc.
• Back-up – IT needs to ensure that back-ups are taking place and that restores are tested on a regular basis.
• Business continuity – IT needs to ensure that it has a plan itself, just as every other organisational department needs to have a plan.
• Disaster recovery (DR) – IT needs to make sure that it has fully engaged all sections or departments in the organisation in the exercise of carrying out business impact analysis on the systems, so that there is clarity of expectations with regard to incident management.
• Incident management – IT is a great starting point for capturing incidents that are occurring across the infrastructure and the users. The ISM should work closely with IT staff to identify and categorise incidents in order to investigate them and learn lessons for improvement.
• Patch management – IT needs to ensure that it is applying patches in a timely manner across the whole infrastructure in order to maintain risk reduction.
• Vulnerability assessments – IT needs to ensure that it is carrying out assessments on the infrastructure in order to maintain an awareness of the level of threat and to be mitigating it accordingly.

The role of the ISM is to set up the framework – the policies, procedures and guidelines – and to create and deliver security awareness sessions to communicate and explain all these. Thereafter, everyone else has to actually do their part, continually, not just immediately after the first rush of enthusiasm following the launch of the framework. This is an ongoing task, and not a project with an ending, hence the earlier references to a programme, rather than a project focus being more appropriate.

Information ownership

In a great many organisations, there is a large divide between IT security and roles that address information governance topics, including data protection, freedom of information and RM. Given that the focus of an ISM is that of protecting information assets and enabling business initiatives with security enhancements and implementation, and that of an information governance manager is knowing when, within the bounds of legislative and regulatory requirements, to share, disclose, save, store or publish information, if the two are not working hand in glove, this way madness lies! It is vital to have a close working relationship. In an ideal world, the aim should be for a coalescence of the roles (teams, if you are so lucky), and this will actually provide the organisation with the best overall approach to protecting its information assets, keeping them safe, secure and reliable over time. We’ll return to this in Chapter 9.

Physical security

The longer you are in an organisation, the more physical security starts to take shape as a really valuable mechanism for providing visual aids for the way in which you need to evidence the change that people need to embrace. Every day, you should be able to identify an event that has happened, or an example of an event that is likely to happen, just by doing a tour of your buildings. The following is a real (true) story.

Figure 1: Confidential waste

Top tip – always have a camera facility available to you! I’m old school, so I carry a proper camera in my handbag at all times (where allowed) whilst on sites. Obviously, most mobile devices have photographic capability these days, so this is not hard to achieve either way. You are then able to capture, visually, the ‘wrong’ behaviour that you are seeing, so that you can ‘play’ it back to your user population to explain what it is that you want to see done differently.

By using the example and photograph in the above incident whilst delivering user information security awareness briefings, it made it all the more real for everyone, as the location was so close to a regional newspaper that anyone else could have taken the bag straight there instead and, irrespective of how dull the contents were, the story is in the act itself.

Side issues were raised as a result of talking about this one small incident to a wide audience. For example, other locations had to wait too long for their collection of confidential waste, which meant that there were often times when quite a considerable collection of bags could be found. This is the equivalent of the jars of sweets in a candy store – they are designed to be tempting, and so present an opportunist thief with a target. Then there are the constant examples of keys left in cabinets, doors left open that shouldn’t be, etc. We will return to this later on.

Other physical security issues transpired during the month, which really started to highlight the need for broadening the scope of coverage and understanding. It is often the case that facilities management deals with physical security and there is little communication with ICT, or wherever information security is housed in the organisation. However, 2011 saw a lot of discussion around the need for convergence of these two key functions, in an attempt to address these gaps. Having spent many years implementing ISO27001 ISMSs, I couldn’t see the need, as it implied that people had not been doing ISO27001 properly, given that physical security is an embedded and expected requirement. It is important, either way, to watch out for exits and entrances and put yourself in the mind of a would-be criminal. Consider how you might gain access to your building and, in so doing, what you can see and what you could walk out with. It doesn’t have to hold obvious value at the time, but may have a sell-on value that you have not currently considered.

It is extremely important to live and breathe security visibly and physically, as well as electronically and technically, so that your user population sees it in action and believes that it is being taken seriously all the time.

Password management

Here is another tale from the trenches.

The whole implementation of the above seemed to have a new challenge every day, over the first week of its implementation. There were server password reset traumas – servers that had not been rebooted in years needed to be safely downed and then restored and, when doing so, there were often no skills available to deal with the technologies faced. Unknown passwords on systems for which the original developer was no longer employed meant that resetting these was pretty much impossible.

The same was true for legacy applications that needed to be kept running, but no other maintenance could take place as nothing could be changed if you could not log on to the server. Integrated applications had complications, too, and PCs that had to be ‘always on’ needed to be identified. So they were forced, at least once, to reset to the new password configuration, so that as many configuration items as possible were in compliance with the new password policy rolled out across the infrastructure.

The ISM’s task is usually to implement the sleekest, most polished form of policy suite for all circumstances, which simply may not always be possible. There are many scenarios you cannot have imagined in advance when you are writing policy documentation in isolation of the real business of the organisation. So there is real value in wide communication during the life cycle of the policy suite – from the formulation stages and delivery through to the implementation stages.

Laptop management

Why do users have laptops that they never connect to the network? Laptop users need to be reminded to connect their equipment to the network when important updates are occurring in order to be appropriately maintained. No excuses! If a user is not prepared to do this, then they should not be provided with the equipment. This kind of requirement must be embedded as part of their contract of employment and job working conditions. Laptops should be connected for updating purposes on a specified regular basis and, if this does not occur, there must be some mechanism of recourse and recall in place, so that the users can see that policy is enforced and, thus, the rules have meaning and are adhered to.

You also have to ask yourself the question ‘why do some people have laptops at all?’ What do you do when you know that there is a laptop that has been plugged in as new two weeks ago, but it has a monitor plugged into it ‘because the resolution is better’, and a keyboard and a mouse? Why not have a PC? There are some people who will always have a desk and office-based role. Even though, in most procurement processes, it is apparently ‘easier and quicker’ to purchase a new laptop, this really needs to be resolved in order to ensure that an appropriate desktop is provided that is attached to the network in the right way. Otherwise, it leaves the user with the difficulty of having to find a safe place to store their laptop every evening – or worse still, having to take it outside the organisation (presenting risk in itself) when there is really no need.

The lesson learnt so far is that however large or small your organisation is, and no matter how available technological solutions for inventory management are, there seem to be ongoing challenges with identifying all configuration items, managing them and protecting them appropriately. Again, this is unacceptable and we really must be doing better. The ISM needs to be taking on much more of an ‘enforcer’ role to ensure that people do not lose focus on the tasks in hand, however manifold they may appear.

Chapter summary

This chapter has reviewed a number of key chunks of activity that the ISM should be spearheading in their organisation, depending on the level of maturity of the ISMS in place.

In reality, in order to ensure that the asset base of the organisation is at an appropriately secure level, significant investment is often required to continue to roll out security-based change requirements. Part of the challenge for the ISM is to develop the right communication channels across the organisation, in order to best leverage existing resources to deliver the desired end result.