Data destruction - don't forget the printers

Last week my Multi-Function Printer (MFP) gave up the ghost and given its age and the probable cost of repair, I decided to invest in a new one. Despite the fact that it would no longer actually print any more, I'm aware that there is a thriving "repair or spares" market out there and I probably could have got a bit of cash for it intact. However, many modern peripherals of this type store data for spooling print jobs and processing scans and copies. The storage media in the device could still contain details of documents printed, scanned and copied. I know from when I've run multiple-page documents through the document feeder to make multiple collated copies that it will easily store the entire document before churning out the copies. When I think of some of the data that's been through my device, I'm not willing to take the risk of letting it go without taking further precautions.

However, for these type of home/small office devices, the risk is quite low as the storage is integrated into the electronics and as far as I'm aware for this type of device is volatile memory that shouldn't have any data on it once the power is off - the possibility of data remenance in this type of memory is still present though. It is therefore more difficult to interrogate and probably not worth the time of a data thief, given the amount and quality of data they may ultimately expect to get out of it.

Business MFPs used in offices are more likely to be a target as they often contain standard hard drives, storing a lot more data and can be more easily interrogated. Potentially there is a greater reward for the data thief as the information they contain would be more valuable to other parties than what may be contained on a typical home printer. Organisations therefore need to ensure that they don't inadvertently disclose confidential data that has been printed, scanned or copied through these devices by not taking appropriate measures when they are sold or otherwise disposed of.

The case for selling these devices intact is that refurbished office MFPs are still of some value. However, the additional benefit of the office MFP is that the data storage medium can be more easily replaced or appropriately cleansed. This also doesn't have to be a difficult task with many enterprise MFP manufacturers having security documentation (often composed in partnership with organisations such as NIST) for how to ensure that these devices are managed, operated and disposed of securely.

This certainly isn't a new issue and there have been plenty of articles talking about the risks associated with this as well as media reports about the data that has been recovered from devices bought from various organisations. However, My recent MFP replacement prompted me to write this post as these devices are not always appreciated for their data storage capabilities and can be one of the easily missed controls, exposing some of the most confidential information.

Image: renjith krishnan / FreeDigitalPhotos.net

What is the scope of Information Security?

Trying to define the scope of the information security organisation and ensure that the appropriate elements are included is still given much consideration. My view on this is to go back to basics and look at what you are trying to achieve with this function. Information Security is concerned with the Security of Information (shocker!) and in order to achieve this you need to consider what information is; in what forms it is stored, processed and transmitted; and by whom, which mechanism or within what type of environment/container. These factors allow you to assess the vulnerabilities of information in the various formats and situations, what threats are present and therefore what the risk is to that information... this is probably sounding familiar.

When considering the risks around information in IT systems, this includes any piece of IT in your environment from the enterprise level systems management environment to the USB stick on a keyring. These systems will hold information or be capable of holding information which should be classified by the organisation according to its sensitivity. Even devices which don't have an end-user storage capability such as network devices hold device configurations, the disclosure of which to unauthorised parties might compromise the desired obscurity of the network configuration or the intellectual property of the organisation who defined the configuration in the first place.

The "wider than just IT" remit

A key considerations needs to be information in other, non-IT forms: Contracts, financial documentation and HR records on paper are key information assets to the organisation and should be included in any risk assessment. People are the other element for consideration. Who is going to access your information: Employees? contractors? customers? third-parties? Once information has been read then it is transferred to a much more unpredictable storage medium, the human brain. Information that was once in a secure environment within the corporate building becomes "you'll never guess what I've just read about!" on a mobile phone on a train. The reputation of your organisation is therefore an asset at risk. Once in the hands of people, your control over your information is reduced and other controls both IT and non-IT are required to protect the data, from encryption on portable media to awareness training.

In considering the threats and vulnerabilities of information, you need to consider how you manage the information in a number of circumstances, how you control the information assets in your company and how you ensure that your employees, contractors, customers and third-parties are trustworthy enough to have the information, are trained in the importance of information protection and have contractual or legal measures to protect the company from any unauthorised disclosure. You also need to consider the physical environment in which the information is held. It's all very well putting amazing IT controls in place if someone can walk into an office or datacentre and simply stroll away with it.

The ability to respond to adverse events will also act as a key control to reduce risk. The more prepared you are, the faster you can react to any event which threatens the security of information, the more you can limit any damage and the faster you can recover. Incident Management and Business Continuity therefore go hand in hand to address this requirement at different levels. Preparation includes training, good information flows, documented processes, awareness and exercises. Key to this is ensuring that everyone has the ability to identify a security incident and alert the appropriate contact - defining when an incident becomes a security incident is another topic for discussion.

Once all these factors are included with all the IT controls, they must be checked for compliance, which includes not only to internal policies but also to legal and regulatory standards. Many standards with which organisations need to comply will go beyond the IT systems and focus on the information itself, such as data protection legislation.

How the scope pans out

The scope of information security therefore includes elements such as IT Operations, Human Resources, procurement, service management, physical security, incident management, business continuity, legal and compliance. There will be separate departments that implement and manage the controls within the organisation and it is the remit of information security to ensure that the processes they operate take into account the controls required to mitigate the risk and that cooperation is obtained for audit and compliance work. This should be in the form of a working partnership, not a dictatorship.

When you consider particularly the integrity and availbility of information in addition to confidentiality, the scope increases further. As an example, physical security should include not just fences, locks, biometrics and CCTV, but also the physical attributes to maintain the availbility of data such as the ability of the building to resist environmental threats such as extreme weather, the stability of ultilities such as electricity and the resilience of the cooling system in server rooms.

Security can be whatever you make it, and different models will fit different organisations. However, to properly consider all the risks to the information you need to protect, you need to think beyond the IT and look at all the information that is of value to your organisation in any format.

Image: jscreationzs / FreeDigitalPhotos.net

Security Policy: Just carry on as usual

How many times have you questioned the way something is done, either because it may not make sense or might be overly onerous, only to be told that we have to do it that way because the policy says you have to? Do you accept that and carry on or do you question further? Who wrote the policy (and are they even still around)? How did they decide that this was the best course of action? What inflenced their decision in terms of the benefits gained or issues avoided by doing things this way?

It can be easy for policy to become a de facto standard continuing long after the justification for having it in place is no longer there. Additionally, as time goes on, the policy becomes more and more ingrained into the consious of those who follow it that soon nobody questions why any more and new people exposed to the policy are consequently dissuaded from questioning it. This issue is illustrated well by the story of the monkeys in the cage. I like to use this story and I don't know where it originated, so I can't take any credit for it myself. It goes something like this:

There is a cage containing five monkeys. It is a tall cage with a bunch of bananas hanging from the top of the cage out of reach. A ladder in the cage would allow the monkeys to climb up and enjoy the bountiful fruit above. Unsurprisingly, very quickly one of the monkeys starts to climb the ladder to get the bananas and ALL the monkeys get sprayed with ice cold water. The monkey on the ladder quickly retreats and the water stops. Shortly afterwards a second monkey starts up the ladder and all the monkeys get sprayed again and he comes back down empty handed. By the time a third monkey starts up the ladder, the other monkeys pull him down to avoid the ice water spray. Soon none of the monkeys are trying to climb up the ladder as they know what will happen.

One of the monkeys is then replaced by a new monkey who has not witnessed anything that happened to the other monkeys and understandably soon starts up the ladder to get the bananas. Immediately the other monkeys, keen to stay dry, roughly pull him down and implement some physical persuasion to make sure he doesn't try it again. The monkey gets the message and does not try to go up the ladder again. Another of the original monkeys is once again replaced and once again starts to make his way up the ladder. All the other monkeys inflict a beating on the new monkey including, cruicially, the previous new monkey who simply accepts that this is what happens when someone tries to get up the ladder. Perhaps this is something he does to feel part of a new group, whilst not wanting to challenge the status quo without knowing the background and making up for his previous error of judgement in climbing up the ladder himself. When a third original monkey is replaced, the process continues in exactly the same way.

Ultimately all the original monkeys have been replaced and none of the monkeys have ever been sprayed with water. However, none of the new monkeys try to climb the ladder and none of them know why. All they know is "it's just the way we do things around here".

The story illustrates the down-side of policies which are not reviewed with any regularity. I know how easy it can be to let policies stagnate, typically a cost of other business priorities and requirements taking precedent.

The main problem with failing to review and update policies is that your security controls may no longer be applicable to the risks that you face. If you review policies by just reading through the policy to see if anything needs to change, then you're most likely to just say "that sounds about right" and perhaps just change any outdated terminology. This is a false review as it won't address any changes in risk. By reviewing policies from the perspective of a risk assessment done at regular intervals (e.g. after any significant change or incident and at least annually) then you can consider the assets you are trying to protect, the threats against them and therefore the controls that are required to protect them. These new required controls can then be compared to the policy and any gaps reviewed and more appropriate controls applied.

Awareness is another key factor here. By the time all the monkeys have been replaced, the banana acquisition policy may have been updated to remove that crucial ice-cold soaking element. However, if this isn't communicated effectively to the monkeys then they will continue in the belief that the previous policy is still in force, not only depriving themselves of the fruit but continuing to needlessly inflict violence on anyone who tries to climb the ladder.

Another issue with out of date policies is also related to the beating that those poor new monkeys had to take after trying to get up the ladder. The policy was in place, nobody could justify the controls, and questioning or challenging the policy was actively discouraged. Unfortunately this ultimately gives security a bad name and the security department are seen as the bad guys who actively inhibit new ideas and growth. This is converse to the desired stance of security as an enabler to the business, which is how the security plan gets management buy-in, support and of course... funding!

So avoid ineffective controls and a bad reputation by reviewing and updating policies regularly, based on the output of risk assessments and communicating the changes effectively to those concerned. Then nobody needs to get covered with ice cold water, staff can challenge and ask questions without fear of retribution and the business can have all the bananas it can eat.

Image: wandee007 / FreeDigitalPhotos.net

ISO 27001 vs PCI-DSS: Security Management vs Security Controls Standards

I've seen many discussions from people looking to align to ISO 27001 that lead me to believe that there is still quite a misconception about what the standard is and how it works.

For many organisations, the past few years have featured the letters PCI-DSS quite prominently. Brought in to regulate the manner in which credit and debit card data are managed following a number of significant and high-profile losses, the Payment Card Industry Data Security Standard defines in exacting detail the controls that need to be applied to protect the data and how they should be tested and audited. The standard defines specifically the data it needs to protect and applies it to anyone storing, processing or transmitting this data. Consequently, almost all retail companies and any other businesses that accept card payments need to implement it and ensure that any service providers they use also meet the requirements of the standard.

The reason that PCI-DSS is able to be so prescriptive in its security controls and auditing requirements is that there are a significant number of constants in play, regardless of the size of business. The data requiring protection is always the same type (card numbers, cardholder name, expiry date, etc) and the controls for each data type are therefore constant. The threats to the data are the same and the level of impact is only dependent on how many payment cards are being handled. The risk assessment side has already been done in advance and the controls defined to appropriately reduce them. This is all defined regardless of the type of business, size of business or other threats that may be present in wider enterprise of the businesses in question.

Why is ISO 27001 different?

Unlike the security controls-based PCI-DSS, ISO 27001 does not apply to any particular industry sector, type of data being protected or specific risks or threats. It is a security management-based standard that expects the organisations implementing it to work out these factors for themselves and continually assure their effectiveness. You can therefore apply ISO 27001 to a multinational IT services provider, seeking to protect assets including corporate data; client data; research and development data; IT systems; the buildings and datacenters where the data is housed; the staff, contractors & client personnel; and their business reputation. These are all things which have value to the company and which have vulnerabilities of their own, which are subject to threats and which are therefore facing a level of risk from certain internal and external factors.

Conversely, you can also apply ISO 27001 to "Bob's Corner Shop". Bob may run a single shop in which he has assets including himself and a couple of staff, the shop itself, stock/inventory and perhaps a PC on a desk which he uses to keep records of stock levels and maybe customer accounts. These things are still assets to Bob and still have vulnerabilities and threats posed to them. The impact of Bob's PC crashing and having to be rebooted though is somewhat less than the impact to the IT services provider example above losing power to its core IT infrastructure. The risk therefore is different. Bob also needs to consider things like physical and environmental security, but his controls are more likely to be a good lock on the door, a burglar alarm and a modest air conditioning unit - somewhat different to the multi-factor defense in depth biometric controls, 24/7 guard-force monitoring CCTV and complex HVAC systems deployed by the IT company.

The important thing is that the controls you choose to avoid, mitigate or transfer the risk need to be appropriate. A security control is only appropriate if the cost of implementing and running it is less than the cost of the risk it mitigates, should a security event/incident occur. If Bob decides to implement a two-factor biometric access control system for the store and an enterprise-level anti-virus system for his PC, then he'll be spending far more on those controls than the cost of replacing the assets he's trying to protect. If Bob wants to be able to accept credit card payments, then he will most likely chose to pay a fee to a payment processing service, rather than implementing his own PCI-DSS accredited IT network.

It is because of these differences between the various adopters of ISO 27001, their risk levels and appetites, that the controls cannot be prescribed and specific within the standard itself. If ISO 27001 were to mandate controls at the enterprise level, then Bob would never be able to align his business to that standard. Conversely, if the standard were to only implement a door lock and a burglar alarm as the sole physical security controls, this would not appropriately address the risks facing a data centre.

Managing to both ISO 27001 and PCI-DSS is about constantly assessing risk and reviewing measurements of effectiveness which could be taken from audits, events or ad-hoc observations. The main difference between the two is that for PCI-DSS, this is being done by the PCI Security Standards Council who will release updates to the PCI standards in the event that the current controls need updating to address a new set of risks or threats - businesses managing to PCI-DSS will still audit, but just to ensure that they are meeting the defined controls. The risks that might affect the PCI standard will however only be based on new threats or risks only to payment card data rather than an entire enterprise, with any factors that may affect the standard perhaps not occurring very often. The mandate for compliance globally for all organisations handling this data also makes it more difficult to change the PCI-DSS standard too often.

Where PCI-DSS will remain static until the next version is released, the controls implemented for ISO 27001 could change in response to a specific incident, a change of risk profile based on new threats or the change of management risk appetite. Therefire, with support thorough management and down into the organisation, the policies in place for ISO 27001 can bend and flex gradually to deal with changing risks.

ISO 27001 and PCI-DSS sit very well together within an enterprise. The security management to ISO 27001 will assess all risks to the enterprise across all assets and will define appropriate controls to appropriately mitigate those risks to a level within the risk apetite of the company. Provided the ISO 27001 controls defined meet the requirements of PCI-DSS for those systems in scope for handing payment card data, then it fits nicely into the security management system. It may be that the risks assessed for the enterprise mandate stronger controls than PCI-DSS in some areas, in which case an enterprise-wide control will automatically meet the requirements of the PCI-DSS standard. If the risk assessment determines that a lower level of control is required, then provided the systems in scope meet the requirements of the controls in PCI-DSS, all other systems can be managed in line with the lesser enterprise controls.

Photo: Photostock