ABCDE....DevOps and Privacy, pt 2

Earlier I introduced the idea that DevOps, particularly in the area of privacy could take lessons from trauma medicine, particularly in taking on board ideas from ATLS.

This led to some further ideas about the relationships or analogies between disciplines - something we've already discussed before in the context of surgery, aviation and checklists.

As software engineering is being brought closer and closer to the metaphorical coal-face - we've moved away from requirements up-front to agile and now to "DevOps" where engineering and operations become the same thing we are starting to see the need to move to much more structured and disciplined teams of engineers. If this isn't happening then there are some serious cultural and management problems.

As this shift happens we have to develop techniques to deal with this - as already mentioned checklists and ATLS provide the necessary kind of structures.

By why ATLS in particular? Well, we can draw an analogy between DevOps and trauma medicine in that DevOps operates with extremely short time-scales and in an environment where fixes and patches need to be very quick and leave the system in a stable state where a longer-term patch can be made later.

DevOps is the ER of the software engineering world.

Airmiles and Customer Service

I think we're all used to utterly rubbish customer service from airlines, especially if you have to fly in economy class. No food, no drink, Byzantine terms and conditions, cancellations and subsequent rebookings that cost money (!!!), cramped seating and paying for Wifi on board without refunds if it doesn't work. Oh and good luck if you want to speak to a human, either on the phone or at the airport

Some airlines still have a concept of customer service - SAS and Lufthansa as well as low cost challenger Norwegian at least treat passengers (sorry customers) with some degree of dignity.

I stopped flying Finnair years ago and switched my allegiance to Lufthansa and Norwegian, primary on price. When Norwegian want 600eur to fly a family to Gatwick from Helsinki while Finnair wanted over 2500eur (on a BA flight too!) with effectively the same ticketing terms and conditions. For long haul Lufthansa is my preferred airline - they serve wine and beer with the meal (all included in the price) and have the most professional and hard working cabin crew I've so far come across.

While none of the above are perfect - they could do a HUGE amount more to make the economy experience better - more on that another time.

But what really gets me is that if times are economically tough for airlines, how little they do to actually understand their customer. I mean I used to fly Finnair religiously - their customer service was excellent, food and drink on board, clean aircraft and you could change flights without being punished. Let's be honest here, Finnair were excellent, really, really excellent! I used to change whole itineraries to fly Finnair....

If you want customers then shouldn't you understand why customers aren't flying with you. Isn't this the whole point of customer loyalty programmes?

Below is my Finnair Plus statement - it's been that way for years and not once have I ever been asked why...

So privacy, security and other aspects aside, if you have a customer loyalty card of any sort and change your behaviour, eg: by stopping using that company's services and they never query why, then you were probably never getting any service anyway...

I used to have quite a tally of Finnair points, they all expired or were changed to some newer, more customer friendly scheme, for the benefits of the customer. I was never informed why or when, nor did anyone ever contact me about the change. For a customer loyalty programme you've got to admit that's pretty dire.

Forbes has quite a bit to say about this...

So, if you happen to work in the customer service dept of an airline and wish to discuss the above and how you can win me back as a customer, and a loyal one at that, let me know...

DevOps and the ABC(DE[FG]) of Privacy

Or maybe this should be called the ATLS of privacy perhaps?  ATLS, or Advanced Trauma Life Support is a training programme for dealing with medical trauma incidents and is typically used by first responders such as paramedics to an incident.

Now as we move to a DevOps oriented model - think of a highly integrated Agile with a "right now" delivery timescale - then the way we will have to react to compliance, privacy impact assessments, privacy engineering etc is going to be on the same kind of time-scale. Certainly if we are late or delayed with the PIA then the product is going to be shipped - with some interesting security and privacy consequences certainly!

So, I conjecture it makes sense that we bring our PIA/compliance activities not just to the engineering level but also to the speed of development and operations.

This means that the PIA is going to have to be extremely focused and very strictly run. Effectively we need the DevOps privacy version of the medical ABC.

The question then becomes what is the equivalent to the medical ABC?

As I've stated before, privacy can [must] learn a lot of things from medicine (and aviation) - such as checklists - in that they both work in very agile, unstructured and reactive environments. Privacy in a DevOps situation can not rely upon traditional compliance or work at the usual, relative glacial speed associated with such work.

References

Ian Oliver (2015). Privacy as a Safety Critical Concept. 1st International Workshop on Privacy Engineering. California. (Keynote Talk)

Ian Oliver (2014). Privacy Engineering: A Data Flow and Ontological Approach. CreateSpace. 978-1497569713 (see: http://www.amazon.co.uk/dp/1497569710  )

Second International Workshop on Privacy Engineering (IWPE'16)

Second International Workshop on Privacy Engineering (IWPE'16)
Co-located with 37th IEEE Symposium on Security and Privacy

26 May 2016 - The Fairmont, San Jose, CA

************************************************************

IMPORTANT DATES

Deadline for abstract submission: 18 January 2016
Deadline for paper submission: 8 February 2016
Notification of acceptance: 22 February 2016
Accepted paper camera-ready: 3 March 2016 

************************************************************
 
We are pleased to invite you to participate in the Second International Workshop on Privacy Engineering (IWPE'16).

Privacy engineering research has never been a more timely endeavor. Ongoing news reports regarding global surveillance programs, massive personal data breaches in corporate databases, and notorious examples of personal tragedies due to privacy violations have intensified societal demands for privacy-friendly systems. In response, current legislative and standardization processes worldwide are seeking to strengthen individuals’ privacy by introducing legal and organizational frameworks that personal data collectors and processors must follow. As a result, engineers are increasingly expected to build and maintain systems that preserve privacy and comply with data protection standards in different ICT domains (such as health, energy, transportation, social computing, law enforcement, and public services) and on different infrastructures and architectures (such as cloud, grid, or mobile computing).

Although there is a consensus on the benefits of an engineering approach to privacy, few concrete proposals exist for models, methodologies, techniques and tools to support engineers and organizations in this endeavor. Work that focuses on helping organizations and software developers to identify and adopt appropriate privacy engineering methods, techniques and tools in their daily practices is also missing. Furthermore, it is difficult to systematically evaluate whether the systems developed using privacy engineering methodologies comply with legal frameworks, provide necessary technical assurances, and fulfill users’ privacy requirements.

Clearly, more research is needed in developing methods that can help translate legal and normative concepts, as well as user expectations, into systems requirements. There is also a growing need for techniques and tools to support organizations and engineers in developing and maintaining (socio-)technical systems that meet these requirements. In an effort to close the gaps in research, the topics of IWPE'16 include all aspects of privacy engineering, ranging from its theoretical foundations, engineering approaches and support infrastructures to its practical application in projects of different scales.

Specifically, we are seeking the following kinds of papers:

1.  technical solution papers that illustrate a novel formalism, method or other research finding with preliminary evaluation;
2.  experience and practice papers that describe a case study, challenge or lessons learned in a specific domain;
3.  early evaluations of tools and techniques that support engineering tasks in privacy requirements, design, implementation, testing, etc.;
4.  interdisciplinary studies or critical reviews of existing privacy engineering concepts, methods and frameworks; 
5.  vision papers that take a clear position informed by evidence based on a thorough literature review.

IWPE’16 welcomes papers that focus on novel solutions based on recent developments in privacy engineering. Topics of interest include, but are not limited to:

• Integrating law and policy compliance into the development process
• Privacy impact assessment during software development
• Privacy risk management models
• Privacy breach recovery methods
• Technical standards, heuristics and best practices for privacy engineering
• Privacy engineering in technical standards
• Privacy requirements elicitation and analysis methods
• User privacy and data protection requirements
• Management of privacy requirements with other system requirements
• Privacy requirements implementation
• Privacy engineering strategies and design patterns
• Privacy-preserving architectures
• Privacy engineering and databases
• Privacy engineering in the context of interaction design and usability
• Privacy testing and evaluation methods
• Validation and verification of privacy requirements
• Engineering of Privacy Enhancing Technologies (PETs)
• Integration of PETs into systems
• Models and approaches for the verification of privacy properties
• Tools and formal languages supporting privacy engineering
• Teaching and training privacy engineering
• Adaptations of privacy engineering into specific software development processes
• Pilots and real-world applications
• Evaluation of privacy engineering methods, technologies and tools
• Privacy engineering and accountability
• Organizational, legal, political and economic aspects of privacy engineering

This topic list is not meant to be exhaustive, as IWPE'16 is interested in all aspects of privacy engineering. However, to screen out off-topic papers early in the review process, we request authors to submit an abstract prior to their paper submission. Abstracts of papers without a clear application to privacy engineering will be considered outside the scope of this workshop and may be rejected.

************************************************************

PAPER FORMAT & SUBMISSION GUIDELINES

We solicit unpublished short position papers (up to 4 pages) and long papers reporting technical, research or industry experience (up to 8 pages) on all dimensions of the privacy engineering domain. Each paper, written in English, must follow IEEE Proceedings format. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will attend the workshop to present the paper.

Abstracts and papers must be submitted via EasyChair

All IWPE'16 Papers will be published in IEEE eXplore, which is indexed by EI Engineering Index, ISI Conference Proceedings Citation Index (CPCI-S), Scopus, etc.