Transcript – Opening remarks for DWPride 2017

Good afternoon! I’m Dan Tanham and I’m a deputy director at DWP Digital.

Before we get going today, Shelley’s asked me to say a few words. I’d like to use that opportunity to pass on some advice someone once gave me – I promise it’ll make you feel good.

Just take a second to do two things: smile. And look around. Isn’t that nice!

I could almost leave things there. You are all amazing. I’ve no doubt you’re amazing individuals, at work and at home, but I think you’re especially amazing today for taking the time to come here and be part of something bigger and special.

This is civilisation. Coming together to solve hard problems is really what it’s all about. If we’d never worked this out we’d be beating each other around the heads with rocks for the best cave. (In some ways we still are…).

But I think you all already know this. Diversity and inclusion go hand in hand, in fact I’d go further and say you cannot have one without the other. And I don’t – I really don’t – think it’s too much of a step further to say that today, here (in Yorkshire!), we represent the very pinnacle of civilisation.

Some shout outs:

Creating Inclusive Cultures – born in Leeds with the support of Leeds Council and several commercial partners and now succesfully operating in Manchester and Birmingham is making sure businesses have access to the knowledge and tools they need to build inclusive and diverse cultures.

Our very own Shelley Hardman and Rachel Poole have been nominated for the Civil Service’s diversity and inclusion award for this – the Yorkshire and Humber LGBT* network, now the largest regional network we have.

I’d like to wrap up there by saying an enormous thank you from the Civil Service and to recommend that you spend time today applying balm to the soul by doing two things: smiling and looking around you.

Thank you and enjoy today!

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?

Body heat 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

EVERYTHING HURTS. WHY DOES EVERYTHING HURT?

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.