CHAPTER 3: OCTOBER: COMPLIANCE MAY BE ONLY SKIN DEEP
Introduction
The experience that is behind the writing of this book is that of usually swooping in at the last minute, with about six weeks to deliver a compliance state for an organisation. However, most organisations tend to realise very quickly that saying you’ve done it (security) doesn’t necessarily mean that you are it (secure). The capacity to successfully fill in forms and ‘get through’ audits is staggering, when balanced with the gap between the contents of the verbiage and the reality of the infrastructure and operation across the organisation. It may be that ‘compliance is only skin deep’ and you have to actually dig below the rhetoric, then formulate a plan to achieve the stated claims of compliance and ensure that the level of required security is embedded across the organisation.
The ‘business’ is always seeking to understand what the return on investment will be for any security-related spend. Cost-benefit analysis in the security arena is notoriously tricky, and often fruitless. Some would see us as being ‘ambulance chasers’ – we are constantly coming along after an incident has occurred (a breach, a loss, etc.), being asked to fix things after they have gone wrong, swooping in to solve the oversights of others. Or, we could be seen as being fundamentally insurance salespeople, advising that a particular approach (policy) is taken that would reduce risk and protect the organisation in the event of an incident arising, whilst not being clear on the level of likelihood, even though the impact may, indeed, be very tangible. There has been a sufficient volume of data breaches and incidents of loss in the last few years to provide a plethora of real examples to share with your organisation, with the stance of ‘there, but for the grace of whoever you worship, goes us’. In other words, if we don’t implement the following security-related controls and safeguards, this could happen to us, and we wouldn’t want that, would we?
Information security policy
A key cornerstone of the work of the ISM is building an appropriate information security policy suite of documentation. The first big hurdle is to ensure that the intended audience understands that a ‘security policy’ is, in fact, not a single document in itself, but a suite of related policies, procedures and guidance that gets built up over a period of time, and is reviewed and added to constantly. It is an ongoing task, as maintaining records and documentation is always hard work and so often is rarely afforded the continual attention necessary to be meaningful.
As a career ISP, invest in books on this particular subject. There are many good ones out there, some of which have been mentioned in the reference section at the end of this book. One good resource in particular is Thomas Peltier. He describes the ‘tiers of policy’ and places the key information security policy as a Tier 1 policy that applies to the whole organisation. Tier 2 policies exist underneath this, addressing specific subject-related matters (personnel security, business continuity, access control, etc.). Tier 3 policies are considered to be application or system specific. The larger your organisation, the more documentation you can see needs to be built up to create your ISMS. This requires a significant overhead in terms of maintenance to ensure that the resources you are providing for the organisation, which need to be followed in order to maintain the security of the information assets that are being created, stored, processed, entrusted to everyone and shared widely, are appropriately protected.
Policy creation needs to be risk assessed, as do any requested, planned or intended changes to existing policies. There may be impacts on users, business processes or technologies, and these need to be captured, addressed and understood by all parties. Different teams need to be engaged, depending on the scope of the policy (procedure or guidance), to form either a change control or a governance review level, so that you are not left writing your documentation suite alone in a vacuum.
The outputs have to live and breathe, and be used by everyone in order to evidence compliance. Otherwise, there will constantly be references in audits to policy not being adhered to, and this will give the appearance of insecurity when, in reality, it may be that the policy was written wrongly and needs to be changed to meet the working practices of the organisation more appropriately.
One way of forcing the agenda is to ensure that employees sign off on the information security policies most directly applicable to them. For example, they should certainly be signing off in terms of ‘I have read and understood …’ on electronic communications usage (e-mail, blogging, social networking, instant messaging, etc.) and remote/home/mobile working. This should be tied in with their personnel file and, if possible, ensure that all employees are provided with a personal information security plan for each year, which will include merit for attending annual awareness briefings, adherence to policy, application of password changes, etc. You should be able to see that this can then be linked to your requirements for metrics and measurements, so that you can start to evidence the effectiveness of the whole security policy piece to senior management. You are obviously aiming for a near 100% coverage of all full-time employees, including some level of coverage of those ad hoc workers.
From your point of view, as ISM, you need to have input from legal, personnel, facilities management, IT, etc. – depending on the circumstances and intentions of the policy documentation itself – at both the creation and the review stages, prior to release and implementation. This means having a planned programme of delivery of documentation across a time line that may have to be agreed with these parties and a line item on the agenda of the ISMF, or equivalent, that reviews the latest documents ready for revision, approval or issue.
Policy documents themselves need to be short and punchy, direct and to the point. They are a clear statement of the stance an organisation is taking on a particular technology, people or process issue. They should be supported by procedural documents, or controls or standards. Organisations have different terminology for their chosen structure of documentation and, wherever possible, you need to resonate with this, so that you are seen to be in keeping with ‘house style’. Security policy documentation should not be being buried in the bowels of IT.
As a note of caution, be wary of ‘death by policy’. It is easy to fall into the trap of creating a policy for each and every situation (or assuming one should be written), rather than ensuring that there is a higher-level, all-encompassing one that is technology agnostic, supported by appropriate procedural documents, control standards or good practice guides. There are those who use a perceived lack of ownership of doing things right as a way of halting progress, i.e. waiting for responsibility to be decided. If you are bound by an incessant need to follow protocol, it may be that this will hamper momentum. Hence, there is a need for brevity in the writing of the documentation and enforcement of the written word as much as possible.
Managing corporate anti-virus
The average computer user knows that they should have an anti-virus program – and they even know that they should update it regularly, even if they don’t! So there is certainly no excuse for an organisation that supports a large number of users to not be doing something effective in this space. However, there are many different products on the market and, because of the complexity of system designs (back to the OSI stack, I’m afraid), it is possible that conflicts could arise between the chosen corporate anti-virus program and a departmental application. Experience of this can render your systems exposed, as it may be that, rather than progress with a planned update to a new more secure version of a corporate anti-virus, you have to ‘roll back’ to an older and, by implication, less-secure version, in order to maintain the functioning of existing corporate applications. This is usually as a result of conflicts that are known about by the third parties who are supplying the corporate applications where the conflict resides. As I have said before, we should not have to put up with this in the IT industry, but it seems to be part of some kind of unspoken set-up that is maintained, but that is ultimately costing us all dearly and is rendering our information assets ill-protected.
Greater complexity has not brought greater security, that’s for sure. Bruce Schneier, security guru of note, wrote about this in 2007 (see www.wired.com/politics/security/commentary/securitymatters/2007/05/securitymatters_0503) and again in 2008 (see www.schneier.com/blog/archives/2008/03/security_produc_1.html).
Standard build and image
The implementation of a standard build of machine is an IT strategy deployed in order to ensure that all desktops, laptops, etc. are managed across the infrastructure in a holistic manner (having been purchased through one procurement agreement from one provider) and in adherence with all the required security-related policies. Rolling out a new ‘image’ on that ‘standard build’ may be needed as an approach as a result of a lack of financial resources available to you, when simply replacing the machines would no doubt be the easier option.
Depending on the size of your estate, this can obviously take a great deal of time to achieve for all machines and you need to work out a process for this. Deploying upgraded software across the network would be the most sensible, i.e. using a technological solution, rather than a people-based solution (one where you would need to visit each machine), but there are many organisations that still have a long way to go in terms of gaining efficiencies from the deployment of technologically appropriate solutions.
In spite of your best laid plans, because of the vagaries of different systems, the standard build approach may not work on every single machine, for every single instance, as the combination of different applications can cause conflicts in system operation. So, having spent time developing the ‘image’ you want to use for all desktops to be rolled out, what do you do when it has issues? In the case of the real situation in the background of this book, we found that macro settings in certain corporate systems caused problems with image roll-out; more because, in fact, once one user has a bad experience, it can taint it for many others. Part of the difficulty can be that, whilst the intended conflicting system may be on a replacement programme, there may be a time lag between the implementation of the new, non-conflicting system and the present day and, thus, your users have to remain frustrated by system glitches.
You need to be able to manage the communication very carefully and ensure that you resolve any niggles very quickly. The implementation of a new ‘image’ across your machines may be required in order to roll out security-based enhancements and this will quickly be used as the excuse for anything that goes wrong. Any negativity needs to be nipped in the bud swiftly, so that future security enhancements are not hampered by any lingering memories of poor performance caused by bad press.
Microsoft® Baseline Security Analyser (MBSA) proved to be a very valuable tool in the arsenal of available technologies to help identify the security state of assets. MBSA is a software tool released by Microsoft to determine security states by assessing missing security updates and less-secure security settings within Microsoft® Windows® and Windows® components, such as Internet Explorer, SQL server and Microsoft® Server macro settings. As we were finding macro settings’ issues with corporate applications, this was a good place to start. Knowing the volume of machines that needs to be kept up to date is a starting point (we mentioned this in Chapter 1 as being one of those key questions that needed answering). Having a view of the spread of their security status is extremely valuable. Your resources may be stretched too thinly to be able to achieve full compliance with all policy requirements in one delivery, so to be able to prioritise machines against their security status makes the task all the easier and you can justify your approach on the basis of the evidence you have gathered.
Software licensing has to be managed in this process, too. This is also a key issue when rolling out new images. You need to know the current status of the number of licences for each application and what the requirements are in each team, section, department, directorate, etc. – not just from an operational point of view, but obviously from a legal point of view, too. Compliance with all requirements and knowledge of the maintenance level, length of licence and number of users, concurrent or otherwise, are all information elements required for managing the software assets in your estate.
Password management (again)
In Chapter 2, we focused quite a bit on password management, but, as with all elements of information security management, they are ongoing and repeat regularly. With the roll-out of the password change segment of the security change programme, it was necessary to deal with various devices and users, and manage both the human and the technological responses to the change. In order to achieve this, support was required to ensure that centralised control of the estate (mobile or otherwise) was possible, so that equipment could be recalled. This was important in order to ensure that upgrades were applied, rather than allowing users not to respond to communications requesting product returns.
As part of the communication, it was necessary to visit various teams, departments and directorates, and deliver briefings to the management meetings and regular update sessions that were carried out as part of their monthly activities. Getting information security on to the agenda as often as possible is hugely valuable, so that people can hear what your plans are and what is forthcoming in the programme of change. But, more importantly it is an opportunity to listen to the employees and hear what their concerns are, particularly when you learn things like they are still writing down their passwords! Or that they don’t have enough lockable cabinets, but I’ll come back to that one later in the book.
Consumerisation
Consumerisation has been building as an industry theme during 2011, but I have certainly been dealing directly with it since at least 2009. Users have wanted to have all the capabilities and facilities of their own mobile devices for quite some time. However, they lack the appreciation of how, for example, in some instances doing so would be breaking motoring laws – you are not supposed to be operating a mobile device whilst driving.
As an organisation, you usually have a wide range of obligations that must be seen to be adhered to and these are supposed to be documented, if you are following an ISO27001 ISMS framework. Even if you are not, you need to know the legislative landscape within which you are operating and to be able to explain to your user population that their home experience may well be different (faster, etc.) than their work experience of technology, but that this is necessary in order to manage an infrastructure often operating across a wide area network and a vast number of individuals.
Third-party management
There are a number of layers to third-party management. You may have many third-party software suppliers providing a spread of products to your organisation. Depending on the nature of these, not all of them will be directly security related, and there are still many providers of IT within the industry who are well behind the understanding curve when it comes to information security. So, the role of the ISM is to be the educator in these circumstances; to be aware of the contract terms and conditions, the intentions of the purchase and the expectations of the delivery, all within the bounds of protecting the information assets that the system is ultimately designed to support, process, store, share, transmit, etc.
So when we found we had a third party e-mailing zip files with patches for their products, which were being quarantined as unrecognised files, it led to a couple of different responses. As a public sector supplier, the query had to be whether e-mailing security updates in the clear (unencrypted) was the most appropriate approach. They should have known better and been providing a more secure support service. It presents a negative image of security when government-related providers still have a tendency to ‘talk the talk’, but not ‘walk the walk’, in all cases.
Audit log management
Audit logs are rarely reviewed – why is this? Who looks at these and who should look at these? How often? What’s the value?
The perception is that the volume of data being generated may simply be too great to actually analyse with any degree of value. However, in some cases, system owners do not know whether they are being maintained or whether anything of value is being generated. This has to be another area for the ISM to get their arms around.
There are many levels of audit log to be tracked and some level of prioritisation is probably worthwhile. Start with the systems that contain the most sensitive information assets and seek to provide the best protection for them first. Thereafter, target those systems that have logs that provide management with data that helps focus resources – system log ins, failed attempts, intrusion prevention systems (IPSs), intrusion detection systems (IDSs), firewalls, routers and switches. There is a wealth of data to be gathered and analysed in order to get a true picture of your day-to-day levels of vulnerability and needs for patch management, updating and maintenance.
Vulnerability management
Managing the running of vulnerability scans is a vital part of any ongoing ISM role and it is alarming to read vulnerability reports from external providers where the results are so often the same:
- SANS top 10 or top 20 vulnerabilities identified (therefore, known vulnerabilities are not being addressed with known solutions).
- Defence in depth helps, but needs to be maintained – firewalls and reverse proxy units functioning as expected, but with those managing them not feeling supported internally. Time is not always allowed to ensure these are maintained appropriately – both technically and also in terms of the skill sets required of those responsible for managing the machines. This is an important point for an ISM to be aware of in order to help influence either budget spend or resource planning for future training needs analysis for those in positions of system admin for security-related tools and technologies.
We will return to this issue in Chapter 6.
Cloud Computing
As you become part of a wider connected network, if any part of your own internal infrastructure or remote locations and users are not following the necessary security protocols and controls that you have sought to implement in order to secure information assets appropriately, it may be that you, yourself, are considered to be a vulnerability. Such architecture vulnerabilities need to be identified on an ongoing basis, with plans in place to rectify, modify, deter, react and protect the information assets in your care.
Such Cloud implications are not yet fully understood, and the potential ramifications of the constant and persistent interconnectedness we are all facing will work themselves out over time. We can but hope that it is not at the expense of users, citizens or their personal data.
Project management
When it comes to managing a large infrastructure-related project, where a great deal of investment is required due to consistent lack of spend over an extended period of years, plural, the ISM is often faced with a constant need to justify the requirements. This is, in itself, distracting from the day job of actually making the required changes. Frankly, playing politics in an organisation can be utterly tedious. However, there are times when it is a necessary evil that must be embraced! Too often, the cry goes up that ‘IT doesn’t understand the business’, and you, as the ISM, don’t want to be tarred with this same brush.
If you lack management support or understanding, taking the battle outside your immediate arena may be required. You need to find the right audiences and language to achieve the hoped-for aims. Always provide options, and in many ways, seek to embed the one you want in amongst options that you know your audience will never approve! Make sure that you learn what works in terms of management speak, too.
Benchmarking against other peers is helpful in order to provide management with reassurance as to your actions. Become a member of any regional groups, so that you can discuss issues, threats, vulnerabilities, experiences, risks, etc. with your peers. This helps to keep you up to date, informed and able to converse with certainty in terms of expectation amongst industry counterparts.
Security awareness theme
Each month, consider focusing on a subject suitable for the time of the year and harnessing your information security endeavours to that. It helps to keep the subject at the forefront of everyone’s considerations and ensures that you are baking information security into the DNA of your organisation, embedding it into best practice and slowly, but surely, changing the culture for the better.
Always use whatever news stories have appeared during the month. There is no shortage of these, day in and day out, that should be crossing your desk as the ISM, but they may not be crossing the mind’s eye of the average user. In fact, there are many stories that appear in the news that are not deliberately presented to the public by the media as being an information security-related story. But you can ‘find’ the security element – be it a personnel issue, a physical security issue, a technical security issue or an information-specific security issue. Let your creative juices flow!
This month’s information security theme could pick up on the fact that October ends with Halloween, a holiday celebrated around the world. Given the volume of malware, spyware and spooky tales to tell in the world of security, there’s enough to hang your ISM hat on, if you are creative enough!
Chapter summary
This chapter dealt with a number of standard subject areas that will be part of the ISM activities on a day-to-day basis, and also introduced the idea of creating security awareness themes for each month, so that you are making the subject live and breathe throughout the organisation on a monthly and changing basis, ensuring that the messaging does not get stale.