The problem with “why wouldn’t you…?”

When I was only a year or so past graduation I had an opportunity to help define a new business proposition: finding ways in which malicious insider behaviour could be identified using the data already available to our client.

I distinctly remember the afternoon following our first half-day workshop with the client team in which we’d been figuring out how we could have spotted insider activity based on real historical cases. As I briefed back to my senior manager to show him where we’d got to, he jumped in with a “why wouldn’t you just do X?” question.

His proposal was a good one and I fumbled for a response as to why we hadn’t found that answer. I felt stupid and like I’d wasted my and our client’s time, but was frustrated because what we’d done that morning was collaborative, intellectually rigorous good work. We’d just found a different answer.

It was a form of phrasing often used by this manager and I quickly realised a very poor one. Fast forward to today and I still see this form used inappropriately all the time.

What’s wrong with it?

It’s a lazy and disempowering way to issue an intellectual challenge.

Firstly, it’s a proposal, not a genuine question. Most often in my experience it is meant as “what about doing X?”.

Second, because it’s a proposal, not a question, it can be quite disempowering, particularly from “senior” people. The time for this kind of proposal is before the team have to invested a bunch of work finding their own answer, not afterwards.

Thirdly, it’s aggressive. The framing of the proposition is essentially challenging the responder, in the short time it takes to comprehend the proposal hidden in the question, to find quality arguments against the proposal.

It’s incredibly easy to find yourself making proposals in this way (I certainly do). Should it exist as a tool in your toolbox? Of course, but use it judiciously.

And if you find yourself frustrated and on the receiving end of this kind of “question”, consider doing what I did: learn to spot the question and reframe it, with something like “I don’t know, that’s not what we came up with but I’ll be sure to fold it in to the next discussion”.

We could all be a bit more like Aethelflaed – come and celebrate Women in Digital this Wednesday

Last year's event

Two days to go until our Women in Digital event!

I’m very excited about Wednesday – we’re hosting another Women in Digital event in my home town of Leeds.

Last year’s event made a big splash. The women I work with every day came back energised, optimistic and boasting a new and strong professional network. The event itself became a bit of a springboard for leaders at DWP (and in digital in general) to channel the surging energy of the year’s historic events and movements such as #TimesUp,  #MeToo and the statutory requirement for large organisations to make public their gender pay gap.

I am so incredibly proud of how boldly, clearly and loudly the voices of some of those who attended last year have been heard. Many have become successful role models for women with a career in digital, helping in turn these women to be role models.

And since then, the equality narrative has evolved. What had been at its core a debate about equality between two genders (men and women) has now turned into something with even bigger consequences.

There is still so much to do

Women are still the largest single group on the wrong side of the pay gap. However, this is not true when it comes to things like ‘covering’ at work, where it is the group made up of LGBTQ people who are most affected. See this excellent report from Deloitte University in the USA from 2013 for more.

This year the event will expand its horizon towards tackling an (even) bigger challenge. Perhaps it can be summarised with the question “what if by working towards equality for all genders, we can also work to a more inclusive and effective workplace for everyone?”

The challenges ahead of us – successfully delivering Brexit, delivering critical government services that meet citizens’ heightened expectations, responding to an economy being reshaped by technological advances such as Artificial Intelligence (the “fourth industrial revolution”) – mean that we need to nurture leaders who can lead across boundaries more than ever, and find ways to build inclusive environments in which people can bring all of themselves to bear to the benefit of us all.

Leading across boundaries

This week I learned about the story of Aethelflaed, Lady of the Mercians. 1,100 years ago she led across boundaries to great effect. It would be a crying shame, but not a surprise, if you too hadn’t come across her story – I’d encourage you to read some of it here.

In these times of great opportunity and challenge, in this month of Pride and with a spirit of excited optimism, I’ll be thinking this week of how we can all channel a bit of Aethelflaed. See you on Wednesday!


Starting a conversation – carbon paper for data

What if companies that used your data made it available for your use? What if they did it in a way that made it easy for you, or other organisations that you authorised, to understand and exploit your digital footprint?

Bodyheat eating robots

Imagine going to the gym to find out that the 20 minutes you did on the rowing machine contributed to a stockpile of electrical energy that the gym then sold on to the National Grid.

Or imagine Your Data was the bodyheat that you give off. As you walk around going about your business, thousands of tiny robots swarm around you gobbling up the bodyheat and feeding it back to the robot mothership.

It would feel like we’d crossed a line, tipping the balance of who gets value from being a person away from, well, people and rendering us little more than intensively farmed fungii grown in caves to support our super-evolved overlords.

And the thing about data is that, unlike body heat or kinetic energy, it can be copied and shared. You do not have to click twice on a button for two people to know you clicked on the button.

So on the one hand we have industries farming the byproduct of people’s everyday comings and goings, and on the other the fact in spite of the relative cheapness of doing so, these same industries coveting this data as though it were a finite resource, when in fact it isn’t.

When you consider that this kind of data is gathered by businesses facilitating day-to-day activities that are necessary or socially-necessary, it starts to seem like the game is rigged.

Facebook is a very pure example of this. They’ve created the best kind of gym (for them): we are compelled to go there; all our friends spend time there, and when we get there not only is the kinetic energy we generate using the equipment sold on at a profit, but so is our body heat, our sweat and information gleaned from the conversations we have while we’re in there – all absorbed by the swarm of tiny creepy robots.

Levelling the playing field: beginning a conversation

Creepiness aside, I’m concerned by just how stacked the deck is. I’m beginning a series of conversations with leaders in data, privacy and industry to see if we can bring some healthy balance to this system of use-data-exploitation-use. I’m starting with this:

What if companies that gathered and used your data made it systematically available for your use?

This would need to be protected by 1. strong digital identities and unlocked by an open, 2. community-curated ontology and a standards-based approach to 3. explicitly-consensual data sharing.

For me, this would begin to restore balance. The way I see it, only one half of the business/person relationship is realising value from our data. Organisations opening up this value to the user (the creator) of this data or their delegates would have, I believe, very interesting consequences, drive innovation and unlock unrealised potential in the sharing economy.

Combined with increasing levels of savviness in the UK population and the increasing sophistication of digital services, this could be the beginning of people taking back control of their data and a new era for technology enablement.

The generic snow sports trip

Day 1 — Saturday

Get up at ridiculous o’clock to catch the budget flight to Geneva/Innsbruck/Turin.

Try not to get irrationally annoyed with fellow British skiers for being too loud/quiet/arrogant/ignorant.

Find bus, hopefully having explained with sufficient clarity which resort you’re aiming for. Hope there isn’t a stag do/uni reunion group on the bus with you. Eventually, begrudgingly, join in with their singing.

Check in, drop bags off and set out to find ski rental shop. Queue for skis/boards. Be falsely modest about ability, correct yourself and fork out another 20EUR for the best available kit.

Enjoy some beers/wine/jaegermeister before getting early night ready to “smash the pistes”.

Day 2 — Sunday

Wake up with mild hangover, half dress in thermals and head down to breakfast, for which footwear is apparently considered optional by some.

Waffle down cereal (with strange milk), a pain au chocolat and some baguette with delicious butter.

Join queue for lift passes, cry slightly at cost and Get! On! The! Snow!

Relearn how it all works. Feel smug about how amateur others look. Feel humbled by ESF and the locals.

Sweat, explore and be merry.

Day 3 — Monday

See Sunday, with less queuing, one fewer layer of clothing and slightly more technique.

You’re nailing this.

More drinking.

Day 4 — Tuesday


Ski/board like a drunken housespider.

Question whether ski trips are worth it. Do you even really enjoy skiing? Are you getting too old for this?

Early night.

Day 5 — Wednesday

How have the Olympic team scouts missed you all these years? You’re incredible, or you will be soon. No piste can conquer you, and you must say, you look dashing doing it too.

The pain is gone (must be improved technique) so let’s hit the aprés tonight!

Day 6 — Thursday

Was yesterday a dream?

Sore head, stickier/icier snow than is reasonable given the price of lift passes and — obviously — piss poor weather.

Nearly the end of the week so perfect time to try some jumps at the park.

How are those teenagers so bold?? How are they still alive??

Hit the aprés with the elation of having cleared not one but several of the smaller jumps and know you are lord of all you survey.

Day 7 — Friday

Last proper day.

Up and out earlier than your body would normally allow, but glad to be on it.

Usually sunny with perfect powder.

Everything clicks. This is bliss. Maybe quit your day job and alternate winter/summer seasons?

Day 8 — Saturday

Get up at ridiculous o’clock to catch the flight home.

Try not to get irrationally annoyed with fellow British skiers for being too loud/quiet/arrogant/ignorant.

Briefly feel nostalgic and comforted at being home on touchdown. Prepare for a day of queuing, waiting and coping with public transport.

Resolve to book next year’s trip in summer to get a good deal on lift passes, knowing it’s about as likely as mastering a front flip 360 the XL tabletop jump at the snow park, but still…one day.

Five real things about security in agile

Things we’ve learned along the way

These are things that with the benefit of hindsight, if I ruled the world, we would stay very true to from day 1.

Yes defence is hard, yes attacks will eventually succeed and yes the “threat landscape” is ever-changing, but we’re also developing services in a way that gives us the best chance of making this harder and harder for attackers too.

Note that it should be taken that the “what” of your security work should seriously consider the excellent guidance from CESG NCSC. #shamelessplug.

1. The attack model is effective as a set of tests

…otherwise you’re going to overlook even the things you know.

Since security events frequently are in “the long tail”, these cannot be exhaustive. But once a credible attack is understood, it should be encoded as a test.

This way we can ensure regression against a specific attack, and where the tested part of the codebase changes, the developer will need to think about how to rewrite the test appropriately. The security team can then review the tests cases as a smaller codebase.

This should be used to capture the “misuse cases” against each story to ensure that decisions that were made for security reasons are not lost as the service evolves. We’ve found that it is usually possible to articulate these quite clearly as “Given…when…then…” statements.
Given that a user’s machine has been compromised with man-in-the-browser malware
When they attempt to log in and additional POST fields are detected
Then their account should be labelled as potentially compromised

Hire proper penetration testers to help you build the tests. I say hire, because what really matters is that the security team build familiarity with how the service works as much as what it does. “Working software over comprehensive documentation.”

2. Put security controls in the build

…to avoid missing the point.

Or more specifically, this is a specific way of ensuring that the environment developers work in is as similar to production as possible. This allows the attack model to be played on an individual build as effectively as it would be on staging or production. This has potential architectural implications, and indeed it may be expensive in high-assurance environments.

By way of an example, let’s take the implementation of layer 7/”next generation”/web application firewalls performing validation of an HTTP payload between microservices. There are many ways to implement this functionality, many of which take the form of (very good) appliances.

However, what we’re really after here is a validation routine that only just lets through appropriate traffic as well as to focus the attention of our security team. If we implement the validation functionality either in code/configuration accessible by the developer we have a better chance of succeeding in our first goal, and the security team have a better shot at spotting changes than having to read through the whole codebase to spot a change to the message format.

This helps even if you choose to implement the real firewall functionality differently across environments – ultimately we’re talking here about the quality of the validation configuration.

3. Don’t put security controls in business processes

…of the intention will be lost upon first contact. Seriously.

Or if you need to, be really sure you’re going to revisit them, remembering how the control works and why the control matters.

An example could be asking auditors in a large firm to avoid working on their own cases or those of their friends/family.

This is often done (and accepted) due to the scale of a service at a given time. It’s very intuitive (and – for a given point in time – correct) to say “hey, there are only 100 users, the impact or probability and therefore the risk of this going wrong are low”. However, as you scale it’s extremely difficult to stay on top of these, particularly where managers and users have the freedom to innovate how they use your service.

At the very least be explicit about where these controls exist – at the least in a list somewhere – and revisit it frequently in your prioritisation meetings.

4. Focus on getting good at monitoring

…so you might have a chance at spotting it happening and dealing with it.

Collecting and storing logs is easy. Getting value from all that data in the form of detection of security events is hard. The system evolves, attack methods are varied and validation of events take time.

Whatever your approach to detection, practice. Remember “the attack model is effective as a set of tests”? Well run them. Make sure you’re plugged into a safe environment on which to run them in. If the team has got it right, this environment should be close enough to the real thing to make this practice meaningful.

Practice on production too – test new attack hypotheses, investigate the small things sometimes and – most importantly – get really close to the people doing dev and ops because they’re going to be manning the guns with you when things get real.

5. Build trust in security through empathy

…or it will be sidelined, ineffective and even risk success.

Too many people have been burnt by bad security. Too many times has security been considered too late, or often in the final throes of governance has the chief security architect held up a red card.

The remedy to this is simple – as a security team fly in the face of traditional assurance practices by showing that there’s skin in the game and by being transparent.

Because security matters so much in the services we build, it must be understood by the whole team. If a threat cannot be explained a counter to it cannot be delivered. If a risk is overcooked, the psychological impact of it, and other risks, will be lessened with time.

I have learnt to take a very harsh default position with anyone with “security” in their name – you have about 3 interactions to demonstrate that you’re there to actually explain security and help deliver before you’re mentally tarred with the “enterprise” brush of doom.