How does Santa comply with Data Protection Laws?

As a father, I'm naturally keen to protect the Personally Identifiable Information (PII) of my children. Not long after the birth of my son was the infamous incident when Her Majesty's Revenue and Customs (HMRC) lost the PII of every family in the UK with a child under the age of 16... Not a great start.

Another organisation with data on my children is the large North-pole based company run by Santa Claus. Given that he has lists of who has been naughty and nice, and in the assumption that this is a binary definition where everyone falls onto one list or the other, with no scope to fall into a neutral category in-between, these lists must contain the personal data on all children in the world. A further assumption is that the data includes obviously names and addresses of the kids in order to label and subsequently deliver their presents. Data gathered on children in order to put them on one list or the other must include habits and activities throughout the preceding year as well as personal gift preferences in case they ultimately end up on the "nice" list by Christmas Eve.

Data held by Santa on children from the UK is subject to legislation including the UK Data Protection Act 1998. Given that International Law dictates that the North Pole does not fall into the jurisdiction of any one country, Santa is required to demonstrate that appropriate controls are in place to protect this information as it is exported out of the EU. The lack of any national jurisdiction over Santa's organisation also means that he is not subject to any specific local legislation and the onus is therefore entirely on him to put the appropriate controls in place to protect the data.

Data aggregation and data destruction are issues here. Given the PII of every child is held by Santa, the exposure of one or both lists in their entirety would be a significant breach, as demonstrated in the video "Santa gets hacked!". Does Santa keep multiple lists, perhaps segregated by country or ideally smaller geographical areas, to reduce the risk of exposing all data in one go? On the data destruction side, one must presume that once a belief in Santa has gone then a presence on either list is no longer required. The Data Protection Act requires that PII is only held for as long as it is needed, although the aforementioned video suggests that adults and children alike might be affected by a data breach of this kind. I would like assurances that my own data is not only no longer on Santa's systems, but that any logical and physical storage media is appropriately disposed of when no longer needed.

Given my understanding that the storage and processing of this data is all performed at the north-pole and not outsourced or off-shored to another organisation or country, the storage and processing of the data is less of a concern than the transmission and transport of it, particularly around Christmas.

Firstly, the delivery mechanisms for the letters to Santa are somewhat varied. Although the postal service is an acceptable mechanism for delivering this information, the destination address seems quite hazy and the risk of loss mid-delivery is therefore quite high. For those who choose to post their lists by placing them up their chimney stack and using special Santa-magic for transmission, I have concerns over the unknown elements of that delivery mechanism and what controls are in place to protect the data en route. Given that these lists are subsequently found still up the chimney 100 years later, more current data could be exposed in the same way.

Secondly, on Christmas eve Santa sets off with this sleigh and the delivery list. Does this list contain only the information required to deliver the correct presents to the appropriate households or is he taking all the PII around with him? As he enters each house, does he take the list with him or leave it in the sleigh? If the latter, he's leaving himself open to data theft while he's casually downing the latest mince pie and glass of sherry. He may think that the list is safe on the roof, but people got up there to set-up the inflatable Santa and light-up sleigh, so there must be access of some sort.

Finally, is it fair to assume that Santa is moving with the times and now takes the list with him on a smart phone or tablet? The risk of losing a device like this is surely greater than the risk of losing paper records of millions of children. Does he link up to the North Pole to get last minute list updates about those children who won't go to bed on Christmas Eve, moving them from the "nice" list to the "naughty" list during his travels... and is he doing it over your wifi?!? What policies around the use of mobile devices is in place and how are communications between the sleigh and Santa HQ protected? Encrypting the data and doing so from every country he delivers to might create further problems around cryptographic export controls and he may have instead opted for the easier life of sending it in the clear!

Anyway, that's enough from me for this year... I need to get my Freedom of Information request over to the North Pole before tomorrow night. Have a Merry Christmas and a Happy New Year.

Image: luigi diamanti / FreeDigitalPhotos.net

Stable systems leave us unprepared for incidents

Many years ago I worked on the shop floor of a national retailer. When the tills failed for one reason or another, there was a manual process that had to be quickly rolled out. Out came the pocket calculators, hand-written receipts and manual credit-card imprinters. At the time, this was not an uncommon occurrence and all the staff consequently knew what they had to do. The process took a bit longer but we were quite sleek at keeping the traffic moving through the shop, even the time it happened the Saturday before Christmas

Nearly 20 years on and I'm not sure that this would necessarily still be the case. As the IT supporting these services becomes more stable, the instances of outages happen less often and there is less working knowledge of what needs to be done when a failure occurs. Only through training and practice can businesses be sure that their staff know what to do in the event of an incident. Without this, organisations risk losing business due to not being able to sell their goods and services at the time when people want to buy them. The expectations of customers to be able to buy what they want when they want to and be processed as fast as possible are certainly far greater now than they were in the early nineties, and there are more alternative options now for them to make their purchase.

It was an article in The Register which made me consider this as a topic to cover. Although not a recent finding, the article comments on the outcome of the investigation into the crash of Air France flight 447 in 2009 which concluded that after a failure of the autopilot, the pilots did not have sufficient skills and experience to fly the plane manually. This issue resulted in the fight plunging into the Atlantic ocean with the tragic loss of all 228 people on board. The report highlights that as pilots become so dependent on the autopilot, using it for many of the tasks in the flight, that when it is suddenly and unexpectedly not available to them that skills to pilot a plane the "old fashioned" way, may be somewhat rusty.

This highlights the importance of incident training and business continuity exercising. A business continuity event or crisis is something that no business wants to think will happen to it but as I've mentioned in previous posts, there are many external and uncontrollable factors that can introduce this scenario. Don't just test IT failover or run the generators... Test and exercise the people who will be expected to take the reigns, assume "manual control" and make difficult decisions in a short time-frame that may ultimately save costs, reputation and in many cases... lives.

Image: bk images / FreeDigitalPhotos.net

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

Event Correlation: There is no such thing as BAU

BAU or Business as Usual is a term that is used to define a number of different things depending on the nature of your business. For projects going through new implementations or changes, the progress through transition, transformation and testing ultimately leads to the point where it is supported by the normal business and technical management processes that will keep it going until the next major change. More generally, BAU is used to describe the steady state of any process, service or infrastructure, the point at which there are no exceptional changes or problems and where it can easily "tick over" in the same way day after day.

BAU can however lead you into a false sense of security. Achieving a steady state of operation should make it quicker and easier to identify issues which arise. However, problems occur when you start to consider regular issues or low-level low-impact incidents which occur on a daily basis, as normal or part of the BAU operation. Once you do that, you may be ignoring the signs of a larger problem which is bubbling away under the surface.

There are a number of shows on TV now that dissect significant incidents and disasters to examine how they were caused. Typically, these incidents are things that are in the public conscious, were heavily reported in the news at the time and either threatened or took lives. Incidents such as plane crashes, train accidents, ferries sinking or industrial accidents of some kind are all subjects of these shows. The key point made by all of these programmes is that these things don't just happen without any warning signs and cannot be attributed to a single issue or failing. These types of incident are a chain of events which have come together to cause a far more significant incident or disaster. The reason that these issues are not identified in time to prevent a disaster is that they are each only visible to different people, have no correlation or visibility in a holistic fashion and more often are not considered to be issues because they are just things that happen as part of Business as Usual.

For a plane crash, the programme wil talk about a number of minor factors which could contribute to an accident: the maintenance team not following proper procedures in order to get their job done quicker, the ground crew who ignore an issue with the plane, the fuel truck driver who incorrectly tries to convert litres to gallons, the pilots who don't get enough sleep and are not fully alert, the air traffic controller working long hours with too many planes to mange, the airport with out-of-date equipment to facilitate landings, the company that transports dangerous materials on the flight without appropriate controls or the airline that pushes for faster turnarounds to make or save more money. These are all typical findings but are all either treated as normal events and not given the visibility at a level that can assess the overall risk to the flight itself. It's not until after the event does someone (typically the team investigating the crash) put all the pieces together to lead up to the event. By then it's too late.

The same applies in information security. Events don't just occur and incidents don't happen without warning, however there are often minor issues which are ignored as "acceptable failings" such as the patches that don't get applied in time, the ongoing virus detections which are quickly handled by the AV and not investigated, that one ID that always seems to log failed access attempts, the documentation not completed during changes as it holds the process up too much and demands from customers and management to respond faster and achieve more in less time. On their own, these are things that may just be treated as BAU occurrences, but may actually be symptoms of a larger problem bubbling away under the surface. The only way you're going to identify the true risk posed by the aggregation of these events is to firstly have visibility of them and secondly to understand how these individual issues might ultimately cause a larger problem. This is where event correlation is important.

There are plenty of options for Security Information and Event Management (SIEM) tool sets to correlate event data from the many technical sources within your environment. The signature of a security event can comprise information from many sources in the network which individually may not seem significant. However, SIEM tools are only part of the solution and although they can sift though potentially millions of alerts and log entries to give a concise and actionable picture of technical events, this then needs to be combined with other information to give you a correlation at a higher level. Process failings and incidents which are not detected through technical measures are also elements which can contribute to a security incident and it may be that a low-level correlated event from your SIEM system, combined with additional information gathered externally, indicates a more significant threat that you are facing. Security management standards such as ISO 27001 define the importance of measuring the effectiveness of all you security controls, not just the technical ones, as an ineffective manual or procedural control can just as easily contribute to a security incident. The human element can not only be the weakest link but is typically also performing the types of controls where failings and effectiveness shortfalls are far more difficult to detect due to no technical monitoring being in place.

The upshot is that it is important to know your operating environment and have an overall view of both minor incidents that may currently be treated as 'normal' as well as the effectiveness of all your controls, both technical and procedural. Only by being able to correlate the risk of each event and though an understanding of how even if individually the risk of each one is negligible, the combined risk is perhaps intolerable, will you be able to predict and prevent the big incidents or disasters.

Photo: David Castillo Dominici