Friday 21 February 2014

Updated Privacy Checklist

So while we're on the subject, here's the checklist I'm currently using as an "aide-mémoire" (I like that term):


It is divided into three parts corresponding to what needs to be established on presentation of the case, what needs to be made during the audit (and this can be repeated as necessary) and what needs to be established to close the audit.

The three "phases" don't necessarily correspond to the underlying process but are more structural to reflect the different phases an audit progresses through. The sign-in only corresponds to the point where a privacy audit team takes over responsibility for the audit; similarly sign-off only corresponds to the point where a privacy audit team wishes to start handing over the results.

Anyway, this is one particular version and the actual implementation is context dependent upon your local management, processes, tools, techniques and system under audit. Modify as required!




Wednesday 19 February 2014

Privacy Engineering and Checklists

A colleague brought to my attention a publication from the PbD community on the subject of privacy engineering [1]. Overall the paper I think gives a good introduction into what privacy engineering could be. I say "could by" because PE needs a huge amount of work, from all angles including the deeper mathematical basis as well as basic, software engineering, process, management etc. The current definition given above is:
"...privacy engineering is the discipline of understanding how to include privacy as a non-functional requirement in systems engineering. While privacy may also appear as a functional requirement of a given system (such as the TOR anonymity system), for most systems, privacy is ancillary to the primary purpose
of the system."
Not bad but quite a few of these non-functional requirements become very awkward functional requirements very quickly as the development proceeds.

The part that particular interests me is regarding checklists:
"The checklist approach to privacy protection has been debated. Checklists have become important safety elements in airplane and medical procedures and are quite common in security auditing. However, their utility for privacy remains questionable. It might be possible to design privacy checklists for frequent and standardized use cases, but the breadth of potential projects makes a standard checklist for everything an unlikely tool."
The above cites an earlier article on this blog about moments that changed how particular industries approached safety. There exists possibly a better article on checklists which explains the rationale behind their use.

Partly the paragraph is correct, the utility of checklists in privacy needs to be established, but, given what a checklist is and what is should be designed to achieve is independent of the area. Indeed the next statement that it might be possible to design privacy checklists for frequent and standardised use cases is exactly the cases where checklists do come into their own. Often repeated, critical phases of design - patterns if you like - are the areas where mistakes are frequently made; things are forgotten etc.

There are NO standard checklists - at least not for the expected usages hinted in the paper. If we compare with the WHO surgical checklists which work in similar, very open, high volatility environments there is a capitalised statement on the bottom of the checklist:
THIS CHECKLIST IS NOT INTENDED TO BE COMPREHENSIVE. ADDITIONS AND MODIFICATIONS TO FIT LOCAL PRACTICE ARE ENCOURAGED.
Ignore at your peril.

Indeed the checklist in privacy WILL NOT give you a standardised approach NOR will it give you the tool for checking your system. It WILL give you a list of things that you should remember to complete at particular relevant points. A checklist should be independent of your processes and partially independent of what ever tooling and techniques are being applied to the problem at hand. Furthermore, if the various items on a checklist are not completed it is not an indication that the process can not continue but rather a warning that important facts might not have been established.

For example, on aircraft take-off there is a checklist item for the setting of flaps. This item may not necessarily specify the specific flap settings as this might vary by many conditions and the item can be ignored (and the flaps not set) and take-off can proceed - though this might be a particularly bad idea as in the Spanair Flight 5022 case.

Interestingly in the paper checkilsts seem to be positioned against privacy impact assessments. I could better imagine that in the privacy checklist an entry "PIAs performed" is included, possibly with further qualifications as necessary. It might be considered that such an entry is superfluous - who would forget to do the PIAs? I agree, pilots would never forget to lower flaps prior to take-off or a surgeon forget to check that the he is set up for the correct procedure to be performed....

Maybe the term checklist isn't the best and this is where some confusion arises. At Great Ormond Street hospital the term "Aide-Mémoire" is used to reflect the function of the checklist and avoid the confusion with the "tick-box mentality" and confusion with process.

Privacy is a very wide area without well established and standardised use cases or at least not at the level of detail that say aviation is as is pointed out in the paper we lack. Indeed it is this lack of standardisation that makes the integration of checklists or aide-mémoires much more important.

Some of our experiences with checklists in this area can be found in an earlier posting entitled: Flying Planes, Surgey and Privacy. [2]


References

[1] Shapiro, Cronk, Cavoukian (2014) Privacy Engineering: Proactively Embedding Privacy, by Design.

[2] Ian Oliver, Tomi Kulmala (2013) Flying planes, Surgery and Privacy.


Monday 17 February 2014

Airbus Aircraft Operational Philosophy

I'm reading the Airbus Flight Crew Training Manual for the A320/A321 aircraft at the moment. If anything, to get an understanding of how such things are written and presented. Aircraft are fairly complex systems and as I've already talked about in this blog, many ideas are directly applicable to privacy, security, software engineering etc if we only take time to learn.

Aside: If anyone does own an A320 or equivalent simulator and would like to offer me some time flying (simulated or otherwise) then YES PLEASE!!!.  OK, back to reality now...

A few things struck me as being particularly relevant such as The Operational Golden Rules:
  1. The aircraft can be flown like any other aircraft
  2. Fly, navigate, communicate - in that order
  3. One head up at all times
  4. Cross check the accuracy of the FMS
  5. Know your FMA at all times 
  6. When things don’t go as expected - take over 
  7. Use the proper level of automation for the task
  8. Practice task sharing and back-up each other
Nothing too surprising there, other than they're stating the obvious.

That's the great thing about the obvious, completely missable...

Note the emphasis on getting the job done without requiring anything other than basic aviation skills; or in our case basic software engineering skills. The emphasis on cross-checking, task sharing and delegation, the use of appropriate techniques and technologies and the note that when things don't go as expected - take over!

As an idea to start off...
  1. There is nothing special about this system under development
  2. Plan, code, test - in that order
  3. Be aware of the wider engineering and requirements context
  4. Cross check your system with its original goals
  5. ...
The learnings here to our privacy engineering world are deep and profound. Just as an exercise to the reader, look at the procedures being followed for any engineering task and could these be placed into a simple set of operational golden rules as above? There's an interesting comparison waiting to be drawn here...that will have to wait for the moment.




Wednesday 5 February 2014

Writing...

Despite writing supposedly being cathartic...ha!...writing anything, from an academic paper to a forthcoming book is not a linear stream of word but a moulding of multiple, parallel, concurrent streams of conciousness into something appearing a whole.

I thought of the analogy with moulding a piece of clay into a work of art...and it works until you realise that piece of clay is probably a piece of s*** that you're holding. At which point you throw it away, wash your hands and feel disgusted and what you've done...

...and then feel more disgusted as to the time you've wasted and the work you've put in and what you've thrown away...warts and all...

It is at that point that you realise that somewhere in that piece of p** was a nugget of gold. So it's on with the rubber gloves to fish out that "clay", find the piece of gold (which may have just been a flash of sunlight if the first place), clean it off and continue with the moulding of your writing until you've achieved something that you're happy to abandon in public view. Just hoping that you've managed to wash off all the smell...

Hemmingway got it right:
The first draft of anything is shit. 


...anyway I'm off to read Pirsig and walk the dog...maybe simultaneously....