CHAPTER 1: AUGUST: PULLING A TEAM TOGETHER

It’s not a project …

The most important thing to remember from this book may very well be that there should be no more information security projects, but rather programmes. What we, as information security professionals, are delivering, ultimately, are programmes of change across our organisations. All the security breaches that have dogged the second decade of the 21st century appear to have been as a result of operating at odds with the importance of the key elements of security (i.e. maintaining the integrity, confidentiality and availability of information assets). This book will not repeat detailed definitions of information security per se – there are many, many resources available out there to do just that. In particular, the reader is referred to the 10 domains of the common body of knowledge (CBK) for information security, maintained by the International Information Systems Security Certification Consortium ((ISC)²). But for the sake of clarity, here is a quick reminder of what are considered to be information assets.

This book is designed for a readership that appreciates operating in a paradigm that knows and understands something of the expectations of information security – i.e. that the task at hand is very much more about the people and the processes involved in information asset protection, than it is about the information technology used to support these. In fact, it is often the case that the ISM is not a technical expert in any of the technologies being used, or intended to be deployed, across the network of the organisation for which they are providing security advice. The ISM needs to know about the requirements and how best to achieve them, and to understand all sorts of peripheral issues, rather than the specifics of each and every technology. It simply isn’t possible, and in many cases, this is why it is necessary to have IT security administrators, security architects and many other roles, as well as the ISM – i.e. the responsibility should not rest in just one individual.

Whilst it is true that the role and its functions started out in technology, as data security has matured into information security, the skills and role profile have matured too. For an organisation to benefit from the possible outcomes of dealing with the plethora of information-related challenges being faced on a daily basis, the ISM role needs to be one with a broader reach and a broader skillset.

So, the idea in these chapters is to provide an insider’s view of what it is really like to operate as an ISM, in a real organisation dealing with everyday challenges, through the role of ‘project manager’ on a programme of change, in order to highlight all the various incidents and issues that arise on an almost daily basis – many of which often go unnoticed. Consider reading this book as the equivalent of a training ground of things to watch out for, in case you ever find yourself blinkered and starting to miss the smaller things. This is very much akin to missing the flapping of the proverbial butterfly wing and, thus, not spotting the fact that something much more critical is coming down the track at you, as a result of having missed the small detail earlier on.

When you are set the task of delivering a particular project, your team members will always be a significant part of the success or failure of that project. One of the key failures of security change management is that it is perceived as a project, and, thus, by its very nature is assumed to have a beginning, a middle and an end. Whereas security is something that needs to be baked into an organisation and, thus, embedded into its fabric – and this very action means that it lends itself more to a programme than a project in order to allow for the reality of there being no real end, as it will ultimately be constantly changing in order to adapt to the information risks that present themselves along the journey.

When an organisation has a constant project focus, it seems that there are meetings about meetings, project plans and reports to be maintained constantly, usually at the expense of doing the actual job that needs to be done. It’s a very difficult path to be struck, between playing the political animal and delivering on the requirements of the job. It is better if the ISM stays focused on actually seeking to implement controls that will provide the best protection possible for the information assets of the organisation employing them.

Another key challenge continues to be the issue of finding information security ‘buried’ in IT, when the clue is in the ‘information’ bit, rather than the ‘security’ bit, as it were. The realm of information security is across all aspects of the organisation and its operations. Therefore, you need to have a degree of influence and oversight across all elements of operations that rely on information sources in order to deliver and progress. What, in reality, does that leave out?

Make friends and influence people

By now, most organisations should already have information security best practices implemented to some degree in the organisation. However, there are still many who have it buried in IT in such a way that the struggle to implement the necessary safeguards is an ongoing one, and new projects are set up to try and achieve compliance with external legislation, regulations, standards, contracts or government-led requirements that must be adhered to. In order to be truly effective, these initiatives require constant explanation as to why you need to be linked into various activities and other change-related projects that you may stumble upon along the way.

It also requires a level of listening. At this stage, in so many organisations, there have been many, many change programmes. This can lead to fatigue being experienced, so people can tend to be resistant to any further attempts at delivering on change programmes. Therefore, it is often the case that the best way to ease the forward momentum required is to allow people a short period of time to get off their chest those issues that they feel are blocking progress at the present time. Early scheduling of introductory meetings helps to get this listening phase out of the way. The ISM cannot afford to be either a wallflower or a shrinking violet! You need to be out there, amongst the people, as it were! Often, once you have heard the issues, you can implement solutions that you already had in mind, as they are usually not difficult. Or, indeed, you can usually manage to point out to people how there are already controls and safeguards in place that may not have been adequately explained thus far, but that are likely to be appropriate for providing protection.

There is a level of commitment required to delivering on the change in order for people to start to buy into believing that things are going to be different. The ISM has to be seen to realise some quick wins as early as possible in the life cycle of the intended change programme. Actually, the ISM has to be seen to live and breathe security in all that they do, day in and day out: always wearing their employee (or equivalent) badge; always encrypting their data; always backing it up, etc. If you consider all the controls we ask our users to bear in mind on a daily basis, the ISM really must be seen to be doing them, and doing them well and with ease in order to prove that security need not be a hindrance and to evidence that it has both value and meaning. You also need to have almost a superpower of awareness, into which we will continue to delve in the forthcoming chapters.

It is always helpful to ensure that you have adequate background information on the organisation and its cultural make-up and challenges, including what’s worked before and what hasn’t in the realm of change management, given how much ‘transformation’ everyone has been going through for more than a decade now. You will need help in galvanising the resources, communicating the changes, etc., including those folk in human resources, training, corporate communications, etc. You’ve got to make links and friends across the entire organisation, way beyond the expected IT/ICT restrictions.

In larger organisations, there are usually people responsible for the issuance of corporate policy, who also need to be positively engaged. If this is not the case, some level of governance review of policy must occur at your information security management forum (ISMF) meetings, which you should schedule on a regular basis. All updated documentation should be required to have some level of management sign-off prior to release into the operational environment.

Writing policy in isolation from people will render it doomed to failure, so it is vital that this work is done in conjunction with key stakeholders. You need a wide portfolio of support across the organisation. With any element of security change to your secure infrastructure, amendments to policies, procedures or controls are usually required, and it is vital that these are done in order for them to be embedded into the fabric of the organisation and accepted as things that become part of the disciplinary process if they are not followed. There need to be obvious and active consequences for failures to adhere to policy. The ISM cannot administer this, as that is tantamount to marking your own homework. This is why, in particular, you need to have engagement with colleagues in human resources. They need to understand the requirement to ensure that employees have job responsibilities identified for information security and that they are measurable within their annual personal development plans (or whatever your equivalent is). This may also require the input of colleagues from training to ensure that relevant learning objectives are measured by individuals and updated annually.

An interesting source of assistance is the ICT help/service desk – or whatever it is called in your organisation. Get the management of it on side early. Understand how many people are normally operating it and establish what their level of understanding is with regard to information security issues. Is it, for example, that they get increased calls for password resets after significant holiday periods (Christmas, summer, etc.)? What other key issues are they constantly receiving queries on? You need to identify these key elements and frame them in language that explains them as being part and parcel of delivering good information security for your organisation. This will enable them to be able to see where you are coming from (your paradigm), and hopefully they will understand better when you are setting about a change agenda that is likely to ultimately involve increased help-desk calls, as a result of confused users not quite understanding the message received. This is so often the case, usually in spite of you having spent painstaking hours explaining the changes to their managers, and to them, through e-mail notifications, newsletters and intranet bulletins, etc. – i.e. doing all that you can! You can further help the help desk by providing them with cheat sheets and FAQs to make sure that they have the right answers to hand for each phase of your security change programme. This will help both their understanding and the level of service they are giving to the user population – a win-win all round.

Befriend the installations team, too. Depending on your organisational set-up, you may have the luxury of still having one based internally; otherwise, it may be an outsourced function. Either way, it is valuable to get to know the teams who are actually going out to your various office locations and having interaction with your users. They should be able to provide some level of interesting feedback with regard to how your infrastructure is being used ‘in the wild’, looked after (or not), treated, handled, managed, etc. They may have many war stories they can recount that will provide you with a wealth of information regarding the reality of your user base in terms of their level of PC literacy, and such knowledge can pay dividends when it comes to key changes you may wish to implement further down the line.

Make friends with the database administrators (DBAs) too. They hold great insights into the systems that they guard, with regard to user behaviour, incidents and experiences. Equally, the DBAs will need to be kept abreast of back-up and recovery strategies and requirements, and will need to ensure that they have documented their activities and best practice with regard to system management for the systems for which they are responsible. Such input and resources will be invaluable to the ISM.

You need to make sure you are closely aligned with the other compliance functions in the organisation: data protection, freedom of information, risk, ethics, legal, records management and information governance. These may be separate or combined functional resources. If you are lucky, you will have some responsibility in all these areas. Whilst this can sound daunting, it is ultimately where the profession is heading, as oversight of all the elements of information asset protection provides the best chance of ensuring you can provide the required amount of IA for all involved.

External providers may also be important to the delivery of a successful infrastructure security change programme, i.e. kit providers, and recycling and destruction providers. We will return to the latter, in particular, in Chapter 3.

The corporate communications team is a really important strand in all this. If you are lucky, it will be large enough to have marketing and communications people amongst its number on a permanent basis and will be well used to structuring messages (both good and bad) and understanding the kind of tone and delivery that suits your organisation. You are going to be expecting a change in behaviour from all your users (or at least that’s what you should be aiming for) and, thus, you need to engage with them from a number of vantage points – i.e. what’s worked in the past, what hasn’t and, thus, what might work in the future as part of your communications roll-out. You need a theme, a strap line, a motto, an avatar, etc. All these elements can make your programme of activity appear more real, tangible and visible across the organisation. The users need to feel that they are part of something. Belonging is a core human need in Maslow’s Hierarchy (the middle layer) and is no less important for us security people to be aware of.

There’s always a need for a ‘list’ (well, if it’s good enough for Santa Claus!)

There are some key fundamentals that you also need to have as ‘stock-in-trade’ information to hand, and this list grows over time, the more interaction you have with your organisation. Here are some examples.

How many users are there?

You may find that you need to get to the bottom of why there are so many potential systems with a list of employees in them. The staff directory that you may find through an intranet may have different records to what Outlook^® appears to hold. What you need, at least in one instance, is one version of the truth for the user population that needs to be managed in terms of policy, standards and controls, and information asset handling, which leads to your next data set requirement.

How many assets require protection in your organisation?

So often, information asset protection is utterly misunderstood and considered far too narrowly. It is one thing to have a CMDB – an ITIL element that is supposed to contain all the components of an information system. But the focus may only be either corporate PC assets or corporate IT systems, and they are rarely as up to date as they could be – it depends on how centralised or otherwise your procurement processes may be. However, there are many spreadsheets being operated locally that need to be taken into account. There are USB sticks that need to be included; there are mobile devices that need to be considered; and there are all the laptops and their contents. The task is actually enormous, in fairness. The reality is that a CMDB may not always contain the full picture. Over and above the actual hardware assets are software assets. You need to have visibility of software licensing in terms of numbers and renewal status, for legal and regulatory compliance reasons. Then you need to cross-reference this with other record sets, including your RM system – or equivalent (if you have one) – to capture the information assets that need to be protected and to start to appreciate the level of sensitivity of those information assets.

Another niggle arises when it transpires that some of the service areas/departments/teams no longer exist, so the configuration database fields containing this information will be out of date. If you are using that as part of your selection criteria for delivering system updates, upgrades and so on, it will mean some machines are neglected.

Part of asset management is, obviously, disposal. However, this is an area that can be very uncoordinated across the organisation and so it must be within the ISM’s eye line to join together the various strands of requirements and provide a more holistic view of the life of an asset throughout its life cycle.

For example, mobile devices (PDAs, phones, etc.) and laptops (notebooks, netbooks, etc.) may get reallocated from one user to another within a department locally. However, the change may not get notified to the IT department that initially released the configured item and noted it on the CMDB. So the organisation may end up with the potential of having inadvertently exposed information assets by not following an appropriate data-wiping procedure as part of the transfer of assets process – probably because it never occurred to them that there would need to be any kind of process! This is why there are still instances of laptops and mobile phones being sold on e-Bay and the recipient finding organisational data still on there. Not only is it embarrassing, but it is a breach of the UK Data Protection Act and, therefore, displays illegal behaviour by the data controller – the owner of the asset that contained the information that needed to be protected throughout its life cycle.

Another risk that manifests itself in this space is that, given the opportunity to replace your ‘estate’, your users can be very creative in making claims as to how many assets they have or need to have available to them. Old PCs have an interesting habit of ending up being reactivated! However, the users may not realise that this can create licensing issues and poor performance from old machines that have not been appropriately updated and maintained along the pathway of regular IT management. But rest assured that teams have a capacity for stashing old equipment in their cupboards when they don’t know what the appropriate disposal process is (or choose not to pay attention), so they don’t tell ICT and the CMDB ends up less accurate or up to date than it should be.

What about USB devices? These are mobile, too, don’t forget! Central control on ordering and delivering USB devices would allow for visibility of their usage. However, because the devices are so small and so portable, they are not considered in this way. Users, historically, have had a great deal of free will with regard to the purchase or usage of these devices across the organisation. But they, too, need to be managed throughout their life cycle, particularly when you consider the nature of information often saved on to them and passed around, balanced with the capacity to be left lying around, lost in the back seat of taxis or left in suits for dry cleaning. The list of errors in this space is endless and depressing.

The end-of-life process should also include servers. They need to be managed when they are being reassigned or repurposed, as do routers and switches. All equipment needs to be accounted for, in terms of both its identification on the asset management database and its compliance status in relation to an up-to-date operating system, software, connectivity, etc.

So the ISM has a lot to pay attention to – keep thinking about that butterfly flapping its wings.

Of the assets identified, how many servers are there?

Your organisation may refer to a ‘server farm’, and you need to know how large this is, how much of it is internal and how much may be outsourced and, thus, managed externally. This will become more important, the more you try and get your head and hands around specific issues relating to patch and vulnerability management. Addressing the challenges of protecting systems is an element of maintenance that should be occurring as part of business as usual (BAU) operation. However, sadly, it appears too often to be the case that as it is not explicitly annotated as part of various individuals’ full-time roles, it is not happening as standard. Information security is, in so many cases, not ‘baked into’ the organisation, as has been described in so many articles, papers, blogs and books over the last decade. This is something that must be discovered and addressed as part of the ISM’s programme of change action.

What about information assets?

Over and above identifying hardware and software, there is a need to identify information assets. This is best done by the ISM, in conjunction with the records manager and/or the information governance manager, taking a proactive stance and providing the user base with a checklist for consideration. This should cover:

• how the information is stored;
• what volume of data constitutes the information assets;
• how legislative requirements are met (data protection, freedom of information, retention periods, etc.);
• who it is shared it with;
• whether these colleagues are inside or outside the organisation;
• how many people there are;
• on what devices the information is stored;
• what kind of impact there would be if there was a loss of the information assets.

What version (or versions) of anti-virus is (are) running and how often is it (are they) being updated?

Again, there may be many questions that could be asked in this area, but you need to know the basics to get you started. There are still IT people out there, in organisations that should know better, who believe that Linux, Unix and platforms other than Windows^® do not require anti-virus updating. No computing environment is immune.

How many systems administrators are there?

You need to know this, so that you know, from your point of view, the size of one of your key audiences. Then you need to know across how many platforms, corporate systems, etc. are those system administrators (sysadmins) stretched? You need to know how many people have administrator access to how many different systems – and not always accept the reasons for this! Nor should you accept that there may still be passwords that are unchanged from the most obvious. You also need to be able to log each user to the IP address of the PC that the user registered at – access control management needs to happen across a number of layers of the open systems interconnection (OSI) model stack.

There are reasons why issues like this keep featuring in the ‘top 20 critical’ lists of security controls that need to be implemented to achieve a baseline of best practice in terms of security management across your organisation.

It is also worth gauging how long they have worked for the organisation. Over a period of time, sysadmins can become quite personally involved with their systems, in the sense of feeling a great deal of ownership of them and responsibility for them. This may need to be tempered with a requirement to look outward enough to see and understand the increasing levels of threat over time. If ongoing education and attendance at various workshops, conferences, etc. has not been part of your sysadmins’ role, then they may not be aware of the scale of system management required and the need to be making swift and deep changes to configuration, sufficient to provide a greater level of protection.

How often are systems updated?

Obviously, this is meant to be the start of a much larger conversation around patch and vulnerability management. And much like anti-virus updating, it’s not just Windows^® that needs patching. Every platform can be exploited by an attacker and, therefore, the more protected you are, the less vulnerable you will potentially be.

How many exceptions (deviations) to policy are there?

Identifying this can tell you a lot about the current organisational culture and view of information security. If there are too many exceptions being sought, either the security policies have been written too harshly or impractically, or management and/or the users are not taking the requirements seriously enough and are seeking to demote the intentions by finding ways around policy requirements, rather than seeking to mitigate gaps in compliance.

All exceptions to policy need to be made on the basis that they will only be agreed to for a period of time, rather than being allowed to remain unchallenged on an ongoing basis.

When were access controls last reviewed?

Every organisation appears to have retired accounts that are still showing as active on their system, so there is always somewhere you can start to tidy things up. So you need to correlate the number of users (identified employees) with the number of active accounts and manage these. System users are often not cleansed out of systems, and this won’t help if you have any migration requirements. Early review of last usage and deleted users will be a helpful strand of work.

Retiring old accounts still seems to suffer from a lack of timely co-ordination with management and HR input, and yet it seems like such an easy issue to resolve. Somewhere along the line, it clearly is not perceived as being of enough importance to warrant the much-needed attention required to bring it up to the expected level of security control to provide true IA. Obviously, the more these kinds of scenario can be automated or dealt with by online forms, the better. The ISM can usually assist in smoothing the process through ensuring these kinds of suggestions are made and followed through.

Another usual finding with regard to user access control is that of copying users’ accounts, rather than creating appropriate, new role profiles, and ensuring that the new user being created on the system has a clean instance. Given the volume of ageing or non-retired accounts, this is another aspect that needs close review and ongoing management.

Then you find out that agency staff may not come through the HR route, as departments can employ people directly for part-time contract requirements. This may mean that those users are not part of the leavers’ process either. There are a lot of different types of worker these days, and you need to capture the different routes through which they may join the organisation, so that their before, during and after journey of employment can be tracked and managed throughout the life cycle. Without a level of co-ordination, weaknesses arise.

What level of information security awareness is there across the organisation?

By now, most organisations have delivered some level of user information security awareness briefings to their employees at least once. The trick is to plan to do this more than once and to ensure that for every employee attending a session, an acceptable usage statement is captured that can be retained in their personnel file. The statement needs to capture whether they are considered to be a remote user or not, and this should then tie them to some assets. Background verification checks may need to be carried out for some individuals, too, and these should also be retained in personnel files. These checks should then be linked to their training profile and to confirmation that policies have been ‘read and understood’.

How is incident management addressed?

You need to be able to identify:

• what an incident is;
• what its impact might be – on the organisation or on an individual to whom it might relate;
• what it looks like for different audiences;
• what people should be looking out for;
• how this can be communicated, and to whom.

As the ISM, you have a significant part to play in ensuring that the mechanisms are in place for everyone to be able to report incidents, so that these can be captured and reviewed in order to assess whether there is policy change required or behaviour change, or both. Joining up incident management across the organisation will go a long way towards addressing risk management. Incidents need to be added to performance management reporting, so that visibility is achieved across an appropriate management layer.

What about team and company communications?

‘It’s the little things’ is an oft-used phrase. When you discover that different departments are using their own banner at the bottom of their e-mails, some of which are referring to the e-mail scanner used and some are not, your task as the ISM has to be to attempt to bring some order and structure to the situation, with appropriate reasoning for needing to do so. As I said before, the ISM has to live and breathe security in all its manifestations, so integrity of information and output is one of the cornerstones and this is a manifestation of it operating in error. As a starting point, the e-mail system should be applying banners, so individuals should not feel the need to create their own. However, in the absence of automation, a standard piece of text should be provided that is applicable across the organisation.

A key pick-up from this small example of an ISM-related task is that consistency of delivery is what drives security home for the users. When they understand why it is that a change is required, and how, in particular, it could be applied to their own personal environment, this makes it more meaningful. Security through obscurity can be a valuable approach for achieving defence in depth – the less you display about the products you use and the versions you are up to, the less an attacker may know about your likely vulnerabilities.

What about other projects going on in your organisation at the same time?

It is very important to be mindful of these because busy employees will be being distracted and pulled in all directions with a multitude of priorities. The trick for the ISM is to show how information security is part and parcel of all that busy work, not an extra in isolation. So you need to have eyes and ears across the landscape to pick up on plans and changes, as well as invites to existing teams and projects, so that you have visibility of what’s coming up and can ensure that security considerations are being included from the earliest possible point.

Project management

So we’ve seen the importance of finding the people who have a vested interest in delivering positive change and those who are going to be helpful, for various reasons. With your immediate team, which will probably be made up of predominantly IT-based skills, you may find it necessary to explain information security ‘from scratch’ to them in the way that you want to see it implemented across the organisation. It really has developed beyond firewalls and anti-virus software, although we obviously must also still apply these technologies. I’ll come back to this under BAU in Chapter 2.

IT people should appreciate why it is that you are getting involved in so many elements outside their domain – because you are following the information train and know about the need to protect it.

There are many risks that can befall a programme of activity. You need to know who will authorise ongoing expenditure on your project and who will require any budget monitoring reports. Finance people certainly need visibility of the appropriate reporting on a monthly basis or your project spend may very well disappear, so start with yourself. It is helpful to know where the spend is going and is part of the expanding profile of skills required of the ISM role.

Always check the small print – suppliers can try and pull a fast one with larger customers as they don’t believe that the ‘small print’ is, in fact, being checked. Always check the following:

• Do the hours of work tally with the quoted costs?
• Do the people coming and going in your organisation have the authority to be there?
• Has the job they were contracted to do been done properly?

The bottom line is – don’t assume anything, check everything.

There are always a number of key activities that need to have taken place prior to the delivery of a milestone. Now, I don’t want to make this chapter a regurgitation of any kind of PRINCE2^® methodology, but there are basics that get applied and then people seem to end up unaware or lost in terms of responsibility, accountability and participation.

So, it is important at the outset to have explained your management style and your expectations with regard to the commitment of all the participants.

Also, check people’s holiday commitments! You can have the best plan in the world and it all goes Pete Tong (Cockney rhyming slang for ‘wrong’!) as a result of a key player not being available at a critical time within the delivery phase. A key milestone may, thus, be missed, especially if that individual is, in fact, unaware of the critical nature of their input.

These are just a few of the key fundamentals that you need to have as ‘stock-in-trade’ information to hand – and that the author needed to have to hand in month one of the project, in order to progress. This list grows over time, the more interaction you have with your organisation.

Chapter summary

This chapter has introduced the essence of a programme of work carried out in a real organisation some time ago, through the mechanisms of highlighting some of the key starting points to be considered if you find yourself in the role of ISM – either part-time or full-time.

Imagine, if you will, that each element outlined above occurred in real time, but is being described in an active tense sense of work that needs to be done. One learns over time that information security is ultimately all about risk management.

A key lesson to learn is to try and reframe your activity as more of a programme of change than a project, as these are notoriously viewed as determinedly having an end – and security should never be seen as such. It’s more a ‘never-ending story’!

The next chapter progresses the programme of activity through some interesting experiences and scene setting for the ongoing programme of change being delivered for a particular organisation. The hope is that you, too, can see the clear lessons and links as they may apply in your organisation.