Advice for Parents - Photos in school

Being married to a teacher and having a number of teachers in my family I'm sad to say that I've seen a number of over zealous Headteachers particularly in primary schools who get a little bit carried away quoting the data protection act at Parents, almost always incorrectly.

It normally happens like this :-

Parent whips out a camera to take a picture of little Johnny as he crosses the finish line at the school sports day.  Headteacher comes running over citing all sorts of data protection related reasons why Parent can't take a photo of little Johnny.  Parents get annoyed and frustrated, upset that the Headteacher is denying them the opportunity to take photos of their child.  

This kind of frustration is shared by many parents who unknowingly forego the opportunity to take photos/videos because of an over aggressive and ignorant application of the Data Protection Act.

So... what does the Information Commissioners Office "ICO" actually have to say on the matter.  Well as you might expect they have issued a specific guidance note on just this topic.  A note that on occasion I have actually sent to headteachers so they are aware of what the rules are.

"Recommended Good Practice

The Data Protection Act is unlikely to apply in many cases where photographs are taken in schools and other educational institutions. Fear of breaching the provisions of the Act should not be wrongly used to stop people taking photographs or videos which provide many with much pleasure.

Where the Act does apply, a common sense approach suggests that if the photographer asks for permission to take a photograph, this will usually be enough to ensure compliance.

Photos taken for official school use may be covered by the Act and pupils and students should be advised why they are being taken.

Photos taken purely for personal use are exempt from the Act."

Yes you read that correctly.  Photos taken purely for personal use are exempt from the Act.  So what typically happens is a head assumes that because THE SCHOOL(!) may have data protection issues to deal with when taking photos of pupils and students, that those same rules may apply to Parents taking photos for personal use.

The ICO guidance even gives specific examples for complete clarity.

"Examples

Personal use:

A parent takes a photograph of their child and some friends taking part in the school Sports Day to be put in the family photo album. These images are for personal use and the Data Protection Act does not apply.

Grandparents are invited to the school nativity play and wish to video it. These images are for personal use and the Data Protection Act does not apply.

Official school use:

Photographs of pupils or students are taken for building passes. These images are likely to be stored electronically with other personal data and the terms of the Act will apply.

A small group of pupils are photographed during a science lesson and the photo is to be used in the school prospectus. This will be personal data but will not breach the Act as long as the children and/or their guardians are aware this is happening and the context in which the photo will be used.

Media use:

A photograph is taken by a local newspaper of a school awards ceremony. As long as the school has agreed to this, and the children and/or their guardians are aware that photographs of those attending the ceremony may appear in the newspaper, this will not breach the Act

"

The only way I can see a school can enforce the none taking of photos at any school event is if somehow the parents have signed up to some sort of contract that prohibits it.  That is different (and I am not a lawyer).  If someone starts swinging the Data Protection Act at you and tells you to switch off your camera.  Well at least you know where you stand now.

Guidance paper quoted can be downloaded from the ICO here.

Documentation in a Business Environment

Documentation is just as important as correctly securing a technology, without it the details can stay inside peoples heads, which can lead to it being forgotten or easily leaving an organisation.  Let’s look at how to do it, so it is both useful and meets our compliance or regulatory requirements.

Before looking any further it is important to understand the different types of documentation, so you can understand what a standard such as PCI DSS is actually requires from you:

Policy: Policy is management’s way to direct staff to do something, or to set expectations for something such as a certain level of control.    An information security policy is the starting point of an organisations commitment to managing security risks. 

Procedure: A procedure is defined as a detailed description of the steps necessary to perform specific operation.  To take this further a procedure is how you as a business are going to implement the desired level of control.  This can be seen as the business response to the management objective set in a policy.  A procedure can also be the operation of a specific control.  In some cases a specific procedure to detail the correct way a set of actions should be performed.

Standard: A standard is a set of rules or specifications that, when implemented together define a software or hardware asset.  The make it compliant blog has already completed a guide on defining configuration standards; this forms a really good basis for a standards document (but I may be biasedJ).  A key point to note with standards is there should be a defined exception handling and authorisation process; because we all know that it is not always possible to implement every detail all the time. 

Guidelines:  These are suggested actions or recommendations related to an area of a policy that may supplement a procedure.  Unlike a standard, implementation of guidelines may be at the reader’s discretion.  For example a policy statement may state that employees are required to wear identification at all times, a guideline may outline that the acceptable wearing is either on a neck tie or a pass holder; often directing the user where to request or find supplies of these.

Form: A policy may state a requirement for records to be maintained of control implementation, the best way to record this is through the completion of a form.  A procedure would define the level of detail required to be completed within a form and the required management authorisations to be captured.  Forms can be paper based or electronic, but they are useless if they are not maintained.

Presenting an auditor or assessor with a good set of structured documentation is an excellent way to start presenting your business as meeting the spirit and intent of many compliance and certification requirements.  If your documentation is a mess, one’s first impression is that your environment is going to reflect this. 

Some believe that having a 100 page policy document is not a good move, and some will argue if it is the one source of information people always know where to look.  I think that this is never going to be resolved, especially here.  The truth is it doesn’t really matter as long as the target audience can navigate it and understand it, and the key to this is referencing. 

A policy document should identify supporting procedure documentation when required; a procedure should identify the applicable standards, and so on.  If you have a 100 page policy document you should reference procedures as you go.  If you have independent documentation, then these can be referenced at the end. 

Assigning an owner to a document is a requirement to show that controls are owned, this creates accountability within the business.  Controls are only ever implemented when people are informed and aware of their responsibilities..  This is why hierarchy is important in documentation, and assignment of responsibilities starts at the executive level, tone at the top is important to ensure that staff at all levels understand the business requirements, especially for security.  A simple responsibilities matrix across the documentation of a business can be an excellent tool to help capture and define accountability and responsibility.

Make it clear who the target audience for the document is, make sure it is available to them, they know where to find it and can reference it easily.  Making documentation that is applicable to the staff and can be maintained by them is important.  Documentation for compliance is not a one off exercise; it must be demonstrably maintained during the year. 

Documentation should also identify the expected frequency of the control’s operation and associated reporting criteria.  The reporting criteria should include metrics that allow the effectiveness of the control(s) to be measured.  Having good management information about compliance before assessments ensures that there are no surprises.  If there has been notification about control failure or a noted issue, management can prepare a response. 

Management of exceptions is especially important when dealing with a control based assessment such as PCI DSS, if a control is not in place non-compliance must be noted.  The PCI DSS allows for compensating controls to be noted to assist in areas of non-compliance; however these are not just documentation. The compensating controls should produce evidence to show that you have been managing the risk, and will continue to do so once the assessment has finished.

Documentation should also identify where management information on controls are reported.  Not all information is required at Executive level. To ensure effective sponsorship and engagement in information security only relevant information should be provided.  Control failure tolerances should be defined this too can impact on reporting lines.  Some people only need to know about failure.  The most important part is that someone knows and is taking the necessary action.  This is the control owners’ responsibility to delegate, either to individual functions or the governance structures of a business, such as a security committee or risk committee. 

Restricting root shell and root user access through sudo

One of the issues I’ve encountered a number of times in assessments of Linux and AIX environments is the provision of excessive permissions using sudo. This article is an attempt to highlight those issues and provide some guidance as to practical resolution.

It is typical in a secured Windows environment that the administrator username is not used for standard business and that those users who require elevated privileges are members of the “Domain Admins” Organisation Unit.  The generic windows administrator account would be renamed, given a randomised long and complex password which would then be physically secured and access restricted.  In Windows, audit trails can be maintained against each user and users do not execute commands as other users.  This is somewhat different in a Linux environment.

In Linux, it has become more standard to use sudo to substitute user and do commands. Sudo in its default implementation is generally in place as (example from CentOS)

wheel ALL = (ALL) ALL

In Red Hat and CentOS, the members of the wheel group are provided full sudo privileges. In Ubuntu or Debian this would be the members of the sudoers group or the admin group.

The above means that a user who is a member of the wheel group can execute ALL commands as ALL users from ALL terminals. In other words, a member of the wheel group can masquerade as other users or can drop to a root shell and no longer have a full audit trail against him.

Users often drop to a root shell to avoid typing sudo before any command. Dropping to a root shell is usually done doing su -, sudo –i, sudo –s, sudo bash etc. In order to prevent sudoers from dropping to a root shell, the shell commands can be removed from the executable files available to the users. This can be done by editing the sudoers file as follows:

Cmnd_Alias SHELLS

SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, /usr/local/bin/tcsh, usr/bin/rsh, /usr/local/bin/zsh

Cmnd_Alias SU

SU = /usr/bin/su

wheel ALL = ALL, !SHELLS, !SU

In the above members of the wheel group can execute all commands on all systems except those commands listed in SHELLS and SU. Sometimes it is necessary for users to drop to a shell when performing administrative functions. Using the above, you could have a configuration with 1 or 2 users permitted to have root abilities with other domain admins having the above.

admin ALL = (ALL) ALL

wheel ALL = ALL, !SHELLS, !SU

Limit access to the admin group in the same way you might limit access to the administrator account in Windows.

Valuing data - should we have a minimum value?

How much is your data worth, do you know and how do you work it out?
One of the points I tried to make during my breach disclosure presentation at AthCon'12 was the need for some regulated standard for the value of personal data.  I wanted to state the importance of setting a value for data so that the value can be used to help estimate how much protection it needs.


For example - if you are the proud owner of 1961 E-type Jag a quick shufti on autotrader will tell you that these are valued at around £129,000, and a '72 model around £100k less at £27,000.
Ok, where am I going with this little de-tour into classic cars?  Within a few clicks of a mouse I've got a rough idea of what my asset is valued at.  If I wanted to, I could fill out the forms on one of the many comparison sites and get a quote for car insurance, a few clicks later and I know how much a third party is going to charge me to accept the risk of damage/theft/fire etc...


If only information security was that simple, but it isn't.  The threats we have to manage change daily, risk mitigation is complex and often a seemingly unachievable, endless battle.  The risk focused CISO could easily be forgiven for finding themselves in a spin.  Buzzwords are a plenty, opinions can vary, and technology is only half the battle! 
To make things worse it is hard to value data.  As is often said, you wouldn't spend a £100 to protect an asset valued at £1.  But how do we know how much data is worth?  The problem with data is its worth different things to different people.  We can't just use a "market" valuation in the same way we can with the great e-type.  Your customer data may be hugely valuable to you in some instances and of no value to you in others.  However it is always of value to the customer in terms of their privacy.  That is the regulators responsibility to uphold.  Even if the customer doesn't care, the regulator is responsible to make sure that there are some principles that are adhered to.  We know personal data is worth less than sensitive data in respect to the Data Protection Act and there is a maximum fine of £500,000 from the ICO.  Sometimes it feels like that is about as much as we have to work with.  No comparison sites, no defined minimum value.  Confused?(.com)


One of the reasons I think the PCI DSS got traction in its early days was that the data was given a value, $25 per card if memory serves me correctly, based on the cost of re-issuing a card.  Couple this with the cost of any fraud committed and then perhaps a fine for none compliance and value can be quantified.  If you store 100,000 card numbers, that data (then) would be worth at least $2.5m+.  From here the business case for a security standard is born.  


Personal data on the other hand seems to be something of a quandary.  If we review the monetary penalty notices by the ICO you will start to see what I mean.
Recently there was a fine issued to Brighton and Sussex University Hospitals for £325,000 for not controlling the destruction of highly sensitive data properly.  Circa 70,000 records with highly sensitive medical data were lost.  So this equates to £4.60 per record.  Which seems very low for information related to an individuals sexual health and preference.


A £90,000 fine was issued to Central London Community Healthcare NHS Trust for the loss/inappropriate transmission of 59 faxes containing information relating to medical diagnosis and palliative care info (£1525 per fax).


Looking at the less sensitive data is even less helpful.  When a gambling industry worker sold over 65,000 records from an online bingo company for in the region of £25,000 (according to the ICO) he received a conditional discharge and was ordered to pay £1,700 as well as £830.80 costs.


The case of the bingo-bandit highlights a significant problem.  The organisation who had the data stolen couldn't/didn't determine the perpetrator and the punishment levied against the buyer wasn't really proportionate to the value the data had to him.


If the ICO were able to set a minimum value for a personal record and a minimum value for a sensitive record they could then set expectations of what reasonable controls are for that data.  This could then be based on the data's minimum value.  In the event of a loss of that data, the ICO could say X records multiplied by value A is my starting point.  Then apply a distress factor, and perhaps a responsibility factor (how well controlled, etc etc) - this would then give people and indicator.  These factors in the multiplier could be used to dictate behaviours.  E.g. organisations that come forward openly, and demonstrate transparency should be rewarded (in my opinion) as this allows the situation to be dealt swiftly and with in the interests of the data subject at the centre.

BYOD - Bring Your Own Disaster!

BYOD - perhaps we should call it "Bring Your Own Disaster!"


There have been lots of good reasons for not letting people connect what ever they like to the enterprise network.  These have not changed, in fact there are more threats to the corporate computing environment than ever before with ever simpler attack vectors.  However the BYOD brigade have charged on.  Want an iPad for email, fine, sign off the risk, non-corporate laptop, sign here ______.  What concerns me is not executives signing off risk, that of course is their decision, its whether they understand the risk in the first instance.


It seems strange at a time when information security is apparently so high on the corporate agenda that BYOD has as much traction has it does.  Does this show us that perhaps the non- infosec executive management still have the "attacks come from the outside" mind set?  Successful breaches almost always seem to include some form of end user device being used to attack the rest of the network.  They can be an easy target, and one authorised to access other services.  Why try to attack the data at rest when you can attack a vulnerable PC/user and steal the authorised credentials.  This can happen even without BYOD policies!  


Who's asset is it anyway?
The question of who owns the underlying asset is a really important one.  If an employee owns that device the enterprise can't really tell them what to do with it.  This will make data management policies almost impossible to police.  The data belongs to the enterprise, the device to the staff member, the staff member is almost certainly going to be able to do whatever they like with that device.  If devices get lost / stolen then the data compromised and used fraudulently I can't see too many judges looking fondly on.  "So, you let them copy this information on to their personal tablet/laptop/smartphone".  I'm not a lawyer but I could see this being a legal mine field around duty of care.


No real cost saving.
As IBM have discovered their BYOD initiative hasn't seen the cost savings expected. I suspect this is down to the well known fact that the cost of tin is always out weighed by support costs.  Non-standard builds, non-standard software / hardware is a support teams worst nightmare.
If you add to this security requirements, suddenly network architecture has to be much more defensive from scratch.  Really, all endpoint devices should be considered untrusted, perhaps even the network itself can't be trusted so more and more checks and policy must be applied. IT and Infosec can't even assume that they'll be able to install product on the devices so have to look for more and more agent-less technologies, endpoint analysis is required to see what on earth has been plugged in, network access control will have to be deployed to do quarantining of unknown / suspicious devices, all internal systems will require additional hardening and firewalling, multiple patch regimes to adhere too, and on, and on, and on.


To have a successful BYOD roll out requires an incredibly well locked down, hardened architecture with extensive internal firewalling the like that many organisations don't operate at the moment.  This sort of approach slows down delivery of services to "the business" because it simply takes longer.  Not helpful when the IT function is still trying to prove it is relevant as senior execs hear they can just move everything to the cloud.


Imagine malware that can detect whether it is plugged into the home network or the office one and operates intelligently based on that decision.  Whilst at work, it sniffs credentials, hoovers up data and does as much as it can with as much stealth as it can muster.  When it realises it has been plugged into the home network with a nice big internet connection and no real firewall / IDS it starts to transfer that data to the criminals unbeknown to the entity it stole it from...


The BYOD culture reminds me of those days in primary schools where the kids all bring a toy in to play with.  Everyone is impressed by the cool toys on display, and the older kids get to show off their latest action figures and video games but not a great deal of work gets done by anyone.  


BYOD - here to stay but probably for all the wrong reasons.