avs Online

It's time for the quarterly blog post! (In reality, people who want to follow me probably do so via Twitter.)

Sometime last autumn, I finally got around to finalising my e-pamphlet on security in agile product management. I wrote the article, Software security in agile product management, for two kinds of people:

1. CISOs who, one day, get a visit from a guy whose business card says he's a "coach", wearing hipster horn-rimmed glasses, and hear that your R&D is going to be agile from now on.
2. Product Owners, who would like to go beyond the security features and actually help the teams to create secure code.

The former group tends to be of the opinion that having security in agile product development is hard. My argument is that it is not, if you are running a mature agile process. Scrum needs to be seen as an engine that consumes backlog items and produces working code, and if you feed software security activities into that engine, it will be reflected as a quality in the end product. This, of course, requires that the engine doesn't leak, or that it doesn't have some sort of ghost inputs.

The part that is of interest to Product Owners looks at bringing software security into a Leffingwellian "backlog feeder" system. The focus is on security requirements elicitation and getting non-functional security requirements in. It is important to make all security work visible on the backlog so not doing it will be an explicit decision, and also to make the cost of security visible.

(The rest of this post has nothing to do with security.)

The article was also a try to use Adobe InDesign to produce an e-book simultaneously with a PDF. If you have a high resolution display, say, a proper monitor, iPad, or a colour printer, I would recommend getting the PDF. It turns out that the HTML and EPUB exports leave a lot to be desired. I fed the HTML inside the e-book container to a validator and apparently the output doesn't even validate. Getting the pictures into their right places with respect to the text flow required manual (!) editing of the HTML. I spent significant time cleaning up the document XML representation in InDesign, and I have to say that the usability leaves a lot of room for development.

It appears that the support for reflowable and flexible documents is pretty hard to add into an application geared towards print production. This is visible not only in the e-book support but also in their newer products such as Muse (code name), where the designer is supposed to know the web page dimensions in pixels. I wish we finally got rid of "best viewed in 1024x768" footnotes and "we have detected you are using a mobile phone, would you like to view our mobile site" popups.

If I were the InDesign Product Owner, I'd probably beef up the document structure view of InDesign so that the document could be edited in the "DOM domain" (for logical structure) and a number of "layout domains" (for output in print PDF, reflowable HTML5, e-books, etc.).

I recently had the opportunity to speak about Privacy by Design at a Nixu seminar. I didn't really realise that the slides were available before being tweeted by @aukia. The tweet mentioned STRIDE+4, and I thought that I'd break my half-year blog silence by explaining what that idea was all about.

STRIDE is a Microsoft-originated security threat analysis method, essentially a pimped-up CIA model that approaches the target from various threat perspectives (S stands for spoofing, T for tampering, etc.) I find it a very useful and easily approachable threat analysis tool for architectural design and implementation.

My favourite way of applying STRIDE is to a data flow diagram that shows software components, data flows between them, and the bearers or storage media for those data flows. The idea is to evaluate each of the STRIDE aspects for each data flow. Its main benefit over a more freeform threat analysis is that it has a distinct end - once you've applied STRIDE to each data flow, you know you're done. Also, being slightly checklist-ey, it helps a non-security practitioner to cover all the main aspects. After some successful whiteboard-DFD STRIDE sessions, I began to think whether it would be possible to extend STRIDE into privacy and data protection world.

Privacy and security may have slightly deviating management and governance targets, privacy being more affected by legislation and often driven by the legal department and security by business continuity and functional security requirements. However, the closer you get to the architecture and code, the closer these two become. First, in order to actually enforce privacy controls, you have to apply security. Privacy folks speak of notice, choice, consent and controls, and security and secure software is what makes the controls work. Second, on the code level, it will no longer be separate corporate departments who would take care of security and privacy - they will converge in the same code repository, implemented by the same developers.

This led me to think whether I could extend STRIDE by bringing in those privacy aspects that could be analysed on the data flow level. Not all of them suit this level of analysis. The underlying business case could be hostile to privacy targets, in which case no amount of data flow level fiddling will save the day. However, I believe there are at least four aspects which can be easily done as a STRIDE extension. For the lack of a new acronym, I decided to call this STRIDE+4.

These plus-four are:

• Consent: For each outgoing data flow, ask whether we have a plausible argument that the user has given a permission to send the given data. As an example, if the user has clicked on a share button in a photo gallery app, it is plausible to assume that the user indeed wants to share the image. However, we might not be able to argue that the user has given a permission to share the GPS coordinates in the EXIF metadata, unless this was evident from the UI.
• Data minimisation: For each outgoing data flow, ask whether the data is the minimum that is technically required to enable the business logic. Do not send data which does not have a clear technical need to be sent.
• Jurisdictional boundaries: For each data flow, ask whether it is possible that the data flow will ever cross a jurisdictional or contractual boundary (for example, exits EU/EEC, or is sent to a service which is not under your ToS/privacy policy). If either end is mobile, this brings in an additional twist.
• Deletion and retention: For each data flow that is to a data storage, ask whether we have a deletion or retention policy, and how do we enforce it.

There are many more privacy principles, such as a requirement for the user to be able to check and rectify data, for data being accurate, and for the collection having a valid purpose. However, it is a bit difficult to bring these in on the data flow level. Even the ones in this set aren't pure data flow issues; they have UX and policy aspects. Even so, data flow analysis is the level on which they can be detected.

One aspect that privacy practitioners probably spot is the lack of "notice" which usually is paired with "consent". I've decided to leave it out from the +4 for a reason. I feel that it is intellectually more honest to ask the designers to build a plausible argument for user being aware of data being shared than referring to the service ToS where the "notice" has been buried in legalese on page 36 of 45. This way, there is no easy way out.

Many of the questions in both STRIDE and the +4 extension end up as being business case judgment calls. There are technical restrictions, business reasons, and all sorts of other real world impediments that may make it impossible to address every finding. But at that point STRIDE+4 has already fulfilled its purpose: the issue has been identified, discussed, and a conscious decision has been made.

I needed to get semi-authentic Commodore 64 colours for a job, and thought that perhaps someone else needs them too. Here's the Commodore 64 colour palette in RGB as an Adobe Swatch Exchange (.ase) file.

The palette is taken from Philip Timmermann's excellent page on VIC-II colours. The colours will probably look a lot less vivid than you remember, for two reasons: 1) in PAL YUV, the original C=64 colour space, your telly just clipped the oversaturated colours, and this palette here is normalised to fit into the RGB gamut, and 2) if you use this in a CMYK job, there are out-of-gamut colours even in this RGB palette. Given the variety of 1980s family TVs that C=64s were hooked to, probably no-one saw the same colours anyway, so don't sweat it.

It is sometimes interesting to peek behind the references in various reports. Often one will find an entirely different fact that had been quoted. This is a story of one such occasion.

The European Commission are currently seeking comments to a report produced by a telco systems provider, on "Availability and Robustness of Electronic Communications Infrastructures". I was going through the pages, making notes on various missing or poorly commented items (systems monoculture, open source, information systems warfare), when I noticed the single occurrence of the term "open source" in the document. You can find it as Footnote 75 on page 78 of the report. It says (emphasis mine)

77% of subject matter experts confirm that open source software negatively impacts reliability and security. IEEE Communications, Quality and Reliability (CQR), "Proceedings of European Experts Workshop on Hardware & Software," Berlin, Germany, 11 October 2006.

Now, as a practicing open source security guy, I did not buy this. So, I wondered, what does the reference actually say? A quick Google search turned out this page of proceedings, especially these two slide sets.

There is no mention of open source in the slide set that is titled "proceedings", so I turned my attention to the one labeled "issues voting". It appears that the participants of this workshop (17 in total, of which seven came from the corporation that the authored the Commission report), did indeed conduct a poll on how they felt open source affected security. On slide 16, the big question is popped -

Open Source Software contributes to better reliability and security (emphasis mine)

- and the results are in: 77% vote yes, 23 % vote no.

This is exactly why open source is good. If you are curious, you can always go to the source. Hopefully the Commission will, too.

Sitting at RSA Europe, listening to Bruce 'BT' Schneier's keynote. Even though the picture implies handwaving, there was really none: it was Mr. Schneier's usual good stuff - nothing new though, but it was nice to see the man in real life.

In the beginning of his keynote, Schneier discussed whether safety is part of security or vice versa, and (being a security guy) decided that security is a superset of the two. This gives me a rare excuse to blog what I've been lately thinking about the difference between the two, and quality. I try to be brief.

Anyone who has stumbled upon quality engineering knows a bunch of varying definitions for quality. Usually, the definition goes along the lines that if a product fulfills its defined specifications, it is of high quality. (Hence, even a crappy product can have high quality if it was specified to be crap. There are other definitions such as those defining quality as the lack of negative externalities, but I am not using them here, although I like thinking in externalities.)

Then, if you have a look at various papers trying to define security, it is often defined as a system that fulfills its specifications in a hostile environment and under attack - or failing that, fails gracefully. So, security builds on the definition of quality and extends that with a notion of robustness.

What I believe is the key finding here is that safety is also often defined through a system that fulfills its specifications while misused in any foreseeable way - or again, fails gracefully. (What is important here is to note that safety engineering looks at purposeful, if not outright malicious, misuse, not only accidental misuse - which was the reason why Schneier classified safety as a subset of security.)

Therefore, both security and safety are special cases of quality. What's the difference? In most cases, security engineering tries to protect assets that have a (relatively) easily defined financial value, such as data confidentiality or system accessability. Safety, on the other hand, aims to protect wetware, which (even though many economists try) is very hard to place a dollar value on.

There are some crossovers, though. Obviously for example fire damage to physical assets (which is addressed by safety engineering) is easily transferred into megabucks, but what is interesting that security engineering also has areas such as privacy that may affect the flesh-and-blood target in ways that cannot easily be given a financial valuation.

Anyway, this is where I currently am with my thoughts on the relation of security and safety. I'll get back to this when I have thought more of it.