James Stewart2017-07-20T09:56:04Zhttp://jystewart.net/feed/atom/WordPress.comJames Stewarthttps://jystewart.net/<![CDATA[Getting past off-shoring]]>http://jystewart.net/?p=16792017-07-20T09:56:04Z2017-07-20T09:53:22ZContinue reading "Getting past off-shoring"]]>One of the factors many organisations (including governments) agonise over when deciding whether to use public cloud services is whether or not services and data can be stored “off shore”. It’s not a topic we tend to discuss very well.
“Off shore” usually means stored in data centres in other countries but can sometimes mean in facilities within the originating country but operated by foreign-owned companies. For UK organisations looking at infrastructure as a service that conversation is dissipating now that the three biggest players all have UK data centres, but switching to UK data centres is really just dodging the issue rather than looking at how and why decisions are made.
It was great to hear Ian McCormack from NCSC addressing offshoring in his spot in the keynote at the AWS Public Sector Summit in DC recently.
“It’s often said to us that due to the global nature of a service it’s somehow inherently less secure than if exactly the same service was hosted on a datacentre in the UK. But actually that just doesn’t stand up to technical security outside of particular national security type applications.” – Ian McCormack, NCSC
For the vast majority of applications from the vast majority of organisations, the physical location is not a factor in confidentiality or integrity. There may be compliance requirements that force decisions on you, or there may be performance reasons to choose particular geographies, but not security.
That said, the topic comes up so often that it seems worth breaking down some thoughts on how you might approach the issue if you want to really consider the risks. Which hosting companies you use, who they’re owned by, and where their various assets are hosted should be considered within your overall risk assessment.
A risk model is only as good as your understanding of the service it’s protecting. Before starting on anything you should make sure you have a solid grasp of the service expectations, what its impact on other services is, and so on. That will help you understand any trade-offs that need to be made, and also help understand whether any offshoring concerns might be coming from.
The following thoughts are based on a set of conversations over the past couple of years. They’re far from comprehensive, but I’m regularly in situations where I find people who don’t know where to start with breaking down these issues and it seemed worth sharing even some sketchy thoughts.
The context, then the risks
Before getting into detail on the particular risks, it’s worth first considering the scenarios where the location of data might be important.
Are you solely concerned about data security, or are your concerns about making sure your services keep working in the unlikely event that all network connections out of the UK fail?
If that unlikely event is a real consideration for you would you need to get your services back up and running immediately, or will backups that let you rebuild locally be sufficient? Most of the time it’s going to be more important that you’re running in multiple locations than whether one of those locations is in your home country.
Once you understand your context, you can go into the next level of detail. Roughly speaking there are three areas of risk that people are concerned about when they trust their services to a third party, regardless of the classification of that data.
Confidentially and integrity risks if staff in those companies can access their data through their administrative roles
Confidentiality risks should a foreign government issue a legal order that the company hand over data from your service
Confidentiality, integrity or availability risks should a hostile state-sponsored organisation use access to the network or physical proximity to a data centre to attack your service
There is also a further risk that we don’t often discuss, which is that the availability of services will be disrupted due to the complexity of international network routing.
It’s worth noting that I’m assuming you are using a robust cloud provider and are applying good practices to your cloud usage so that the chances of other customers affecting your services are very small.
Staff accessing data
The risks relating to staff at cloud companies accessing your data are similar whether your data is entirely contained within the UK or is stored elsewhere.
Before worrying about where the data is, you should be thinking about what impact comes with disclosure of the data. For much of what we do simply being careful about how we use a tool will minimise that impact. For example, if we’re using a project management tool we shouldn’t include personal data or credentials in what we store.
When you do have data that needs to be restricted then many infrastructure as a service providers will share information about the measures they take to make it very difficult for their staff to access customers’ data. Increasingly details of those measures are available publicly. Those measures apply whether the data is stored in the UK or outside it.
Legal orders
Non-UK ownership of companies, or non-UK residence of data centres is a reality of most modern internet services. There have been a number of legal cases around the world over the past few years beginning to test to what extent governments can compel companies to provide their customers’ data to law enforcement agencies or litigants in certain cases.
The full ramifications of those cases are still unclear and the legal situation will continue to vary significantly from jurisdiction to jurisdiction, but there are other things we should consider before getting into the detailed legal situation.
Once again, we need to understand the risk associated with a court granting access to the data we have in a service. That will largely depend on the way any data that is disclosed will be handled and what guarantees we have offered to our users. Access to a very specific record granted via a warrant and committing the accessing parties to hold the information carefully, is very different from a court allowing various parties to hold full copies of a database without protection.
We then need to consider the likelihood of such an order and the practicalities of fulfilling it. These cases are extremely rare and likely to remain so.
For governments, in the very rare circumstance where such situations did arise, most foreign governments are likely to use diplomatic channels to address requests of this sort that touch on government-owned data. Not to do so would risk a diplomatic incident and that is rarely worthwhile. Those diplomatic channels give us an opportunity to find other ways to address the situation.
Regardless of whether you’re a government, where your data is stored on third-parties’ servers that doesn’t mean it’s entirely out of your control. Just because your data rests on someone else’s server doesn’t mean you can’t encrypt it and store the keys elsewhere, or take other similar steps.
Hostile interference
There are always risks that hostile actors will want to interfere with your service, and that’s something that should be considered as part of the general threat modelling and risk assessment for a system regardless of where it’s hosted.
Infrastructure security is incredibly important but far too often people focus on that at the cost of application security, which is where the easiest to exploit vulnerabilities are usually found. Regardless of where an application is hosted you should be managing the application security appropriately. With that, you should be taking appropriate and proportionate steps to maintain the integrity of the data in your services. For example, when using large-scale public cloud services you should implement industry standard encryption of your network traffic, and thinking about how you’d detect tampering with your data at rest.
It is possible that certain types of attacks will be easier if data is in another country, particularly disruption to the availability of a service. If your service is genuinely critical, you should already have plans to make it resilient against network outages, for example by deploying software you run to multiple “regions” or by ensuring that your software-as-a-service providers do similarly.
It’s also worth noting that there are limits to what you can reasonably prepare for or protect against.
One example of where an organisation has thought ahead about that and set out to be realistic, is the threat model for UK-OFFICIAL. The UK government accepted the possibility that determined and highly capable foreign governments may be able to access some data and services:
“This model does not imply that information within the OFFICAL tier will not be targeted by some sophisticated and determined threat actors (including Foreign Intelligence Services) who may deploy advanced capabilities. It may be. Rather, a risk based decision has been taken not to invest in controls to assure protection against those threats, i.e. proportionate not guaranteed protection.”
Conclusion
For the vast majority of what any of us do, considerations about where to host your data and services come down to good architectural practices: are our services designed to be resilient, fault-tolerant and responsive enough to meet users’ expectations?
In some cases being comfortable hosting services off-shore brings very real advantages, not just because it gives us access to a wider market of suppliers but also because it allows for geographical resilience, or for better services to those based outside the UK.
The main thing that’s important whatever we’re doing is to maintain awareness of what we’re using and how. In a cloud-centric world that no longer means understanding every server, but having a good sense of where companies you’re dependent on are owned and operated and for high-availability services how their network connectivity is provided.
]]>0James Stewarthttps://jystewart.net/<![CDATA[A few thoughts from ITEM]]>http://jystewart.net/?p=16572017-06-30T11:04:09Z2017-06-30T11:04:09ZContinue reading "A few thoughts from ITEM"]]>A couple of weeks back I made my first visit to Ukraine, to keynote the (outdoor!) ITEM conference in Dnipro.
It was one of those trips where you don’t really feel like you see the place. Due to flight troubles (the culmination of many frustrations with Ukrainian Airlines) I arrived at my hotel in Dnipro at 3am, and departed at 5.30 the next morning.
That, combined with delivering two talks, hosting two Q&A sessions, being interviewed for two different video shows, and being on a panel meant the whole day is a bit hazy in my memory, but a few things stand out.
The hotel
“Menorah center” general view, Golden Rose synagogue, from wikipedia
With such a short visit, I didn’t get much time in the hotel, but it still stands out as one of the more distinctive I’ve visited. Set inside the Menorah Center, the biggest multifunctional Jewish community center in Europe, the building was huge and rather imposing!
My talks
My keynote was about how to get started with digital transformation. I told some of the GDS story and highlighted some examples from elsewhere, but primarily exhorted the audience to start, and start small. Throughout my time in government, and in several consulting engagements since I’ve been frustrated by the assumption that to make big change you have to start out big. The mission should be bold, the vision should be big, but the first steps and initial team should be small.
I also gave a short talk exploring some of the themes about open source, open standards, and what I’ve learned about leadership from exploring those topics. There’s a separate blog post or two in that, which I should get to at some stage.
The diversity panel
I’d initially been inclined to turn down ITEM’s invitation as their website gave me the impression that they weren’t doing much to encourage diversity. I was delighted to be proven wrong.
While primarily white, the audience had more of a gender mix than I’d expected and there were a number of children present. There was also a wider range of speakers than the initial announcements had suggested and the organisers had laid on childcare – particularly important for a weekend event.
It was sobering to see the context in which that was happening during our panel. After the panelists had all said our bit, the moderator asked the audience to raise their hands if they thought lack of diversity was an issue in the Ukrainian IT industry. Not a single hand went up.
Estonia
I didn’t realise when I gave my customary shout-out to the Estonian government in my talk that the next speaker was from their E-Residency programme.
The E-Residency team were sponsoring the event, which was the first time I’ve seen a government sponsor a tech event of this kind in another country. It was also striking how international the team representing e-residency were.
It seems Ukraine is a big source of e-residents, in part because running a business and moving money around in Estonia is much simpler than in Ukraine. It’s clear that Estonia’s reach in the region is significant, and their work remains fascinating to watch.
Future of Ukrainian IT
Several people approached me during the event to ask about how they win more outsourcing business. It was apparent that a lot of the IT sector in Ukraine is built around being an outsourcing provider, but that is being squeezed as cost of living goes up and western companies want to move away from traditional outsourcing.
While quite a few startups were present (and it’s difficult to draw inferences from such a short visit) there’s also not nearly such a large local economy as in India and so not quite the same opportunity to transition to providing products to a growing local market.
I encouraged those I spoke to at least move from talking “outsourcing” to a clearer presentation of whether they’re providing a product or a partnership, and to make those partnerships more agile. But there are no easy answers and with so many countries vying to rebuild their economies around tech, many of these companies could be facing a challenging transition.
Going back, seeing more
It’s been a real privilege over the last few months to get insights into digital and tech in such different contexts: Canada, Philippines, Australia and now Ukraine.
For Ukraine, 26 hours really isn’t long enough to see very much and I’m hoping there’ll be a chance to go back and see a bit more before long!
I was asked to speak about compliance at Salford Centre for Professional Development‘s event on GDPR, and used it as an opportunity to try to encourage everyone to think beyond compliance.
Slides are on speakerdeck, but as usual they probably don’t make much sense out of context. So here’s a quick write-up to capture the gist.
If compliance is our goal we’ll always be playing catch-up
While organisations have been starting to wrap their heads around GDPR, the Conservative party have included a clause in their manifesto saying that if elected:
“we will bring forward a new data protection law, fit for our new data age, to ensure the very best standards for the safe, flexible and dynamic use of data and enshrining our global leadership in the ethical and proportionate regulation of data”
The GDPR has been seen as a once in a generation change in how data protection works, but it’s unlikely that will remain true. The ways in which we generate data, the ways in which it can be exploited, and the debate around what’s acceptable are moving quickly and that is finally part of the political debate.
When it comes to managing data, it’s all too common for compliance to become the end in itself.
Recent changes to information security risk management in government (eg. the new classification policy and the updated Security Policy Framework) were in part made to address the fact that meeting certain “baseline control set” requirements had taken the place of making sensible security decisions in context. At its worst that meant people had to bend the rules to respond to security incidents rapidly.
I also used the example of the Digital by Default Service Standard, noting that I rarely saw any correlation between the time people spent preparing for an assessment and the likelihood of success. The people who were successful were the ones who invested time in their users and service design, not preparing for assessment.
If organisations want to be on the front foot, they can’t allow current regulation to set their level of aspiration. Instead we have the transition to new regulation as a force for wider transformation.
GDPR puts the focus on users. We should all be doing that already.
GDPR gives individuals a lot of new rights, to be informed, to be able to restrict processing, to understand automated processes, and so on.
The way those rights will be interpreted in law is yet to be determined, but organisations that have really invested in understanding their users will be in a far better position to shape and defend their approach than those who allow corporate policy to ignore users.
And if we actually respect our users, get close to them and have a conversation with them we’re more likely to be able to find new opportunities and build their trust and loyalty.
We should try and go beyond GDPR’s expectation that policies will be explained in “plain English”. Or at least not fall into the trap that that solely means applying better writing to sign-up forms and privacy policies. I cited If’s “New Digital Rights” work as an example of actually applying design thinking to the relationship with users around data.
Understand our organisations
There are all sorts of trade-offs that everyone’s going to have to face in meeting GDPR’s requirements. Hold on to data for potential future analysis, or dispose of it to reduce your liabilities? How much consent should you ask of your users? And so on.
It would be foolish to try and balance those trade-offs without understanding our organisations’ purpose, but all too often people are asked to do just that. People responsible for GDPR compliance need to push that conversation, to make sure that decisions are made in the context of overall value.
That also means finding ways to express that purpose and the way in which it’s being worked out right across the organisation. I cited the design principles we created at GDS as a tool for that. Principles like that give people a common frame of reference, and create a better environment for constructive challenge.
Better cultures, better feedback loops
Most organisations are going to struggle with GDPR compliance not because they’re doing anything nefarious, but because data has sprawled all over their organisations.
The reasons for that vary, but a common pattern is that people have one or two core tools that are theoretically their core data stores, but those stores are inflexible and so people create parallel systems (usually spreadsheets) in order to get their jobs done. Over time it gets less clear which the authoritative data set is, and more and more copies emerge.
Spreadsheets are an important tool and usually the easiest way to do some simple analysis, but they’re not the best choice for long term data storage. Their use is the sort of thing a purely compliance approach would try to stomp out, but doing that without an alternative won’t help.
Those charged with compliance should instead try to get to grips with the real causes of that information sprawl and help create feedback loops that limit it. Make sure that data stores have clear custodians who can adapt them to help people get their jobs done. Create channels where people can be open about the workarounds they’ve had to create and can have a grown up debate about the right way to manage that data in the future.
Not only will that focus reduce the risk that everyone works around compliance (cause they still need to do their jobs), there’s a really good chance that organisations will get more efficient if a culture is created that’s rich with feedback loops and includes empowered custodians.
That all applies to security, too
People are understandably worried about the risk of “data breaches” after a range of high profile incidents, and the GDPR increases the expectation that people will respond clearly and quickly.
For too many organisations, the biggest risk they have around data breaches is simply not knowing what data they hold, or where it is. Exactly the same principles around providing great tools and developing feedback loops are what’s needed there too.
There is an important place for discussions of specific technical security measures, like encryption, data minimisation, sharing, and so on. And it’s important that people understand the divisions in responsibility between their teams, software as a service providers and others. But none of that’s of much use unless we know the real data flows of the organisation.
Finding that out and improving it will work best in the context of recognising that people can be the strongest link in security, making sure that we have a security culture that recognises that most people are trying to do “the right thing” and supports them in doing it.
It also means practicing. My favourite clause in GDPR seems to recommend “game days” which seems like a very positive idea:
Regulation isn’t aspiration
Everyone will have to comply with GDPR, but if that’s all we focus on we’ll always be playing catch-up.
Educating staff about compliance may be important, but if that’s where it stops it’s unlikely to be transformative.
Instead, organisations should focus on understanding their users, providing the right data services for them, and building internal product ownership and feedback loops that make sure staff can contribute to improving data management over time.
There are a lot of hard challenges coming in working out what’s possible with data, with privacy and with consent. We need to free up organisations’ capacity to work on that, not on the endless cycles of compliance.
]]>1James Stewarthttps://jystewart.net/<![CDATA[What’s next?]]>http://jystewart.net/?p=16322017-03-25T12:14:00Z2017-03-25T12:14:00ZContinue reading "What’s next?"]]>It’s been nearly two months since I left GDS. It’s high time I talked a bit more about what’s next for me.
For the most part I spent February trying to slow down. I finished some books, watched some films, and had coffee with lots of friends. But I can’t switch off completely, so I spent a very pleasant morning doing a little mentoring for Matt’s accelerator and preparing for sessions at OpenGov Leadership Forum Philippines, Cloud Expo Europe and CyberUK In Practice.
March has been another change of gears. I spent some time helping FutureGov work through plans for an exciting new project. I then had a couple of days in Toronto sharing experiences and advice with the Ontario government. Then it was Manila, where I spent a day talking with regional governments about cloud and leadership. And quick stops at Cloud Expo Europe, and CyberUK In Practice (chairing a panel on cloud security).
I’ve decided that my next phase is going to be a spell of independent consulting. It wouldn’t be right to dive straight into one big thing after the intense experience of building and sustaining GDS. And I quite like the thought of a bit more variety. I’m already seeing how much the lessons learned at GDS can help all sorts of other organisations.
I want to help organisations who are trying to integrate internet-era technology and thinking into their strategy. To help people approach security as a positive agent for change. To bring together cross-disciplinary teams and adopt continuous delivery. The sort of things we did at GDS, but in a few different contexts.
So… if you think I could help you, do get in touch. I’m London based, but happy to travel for the right project.
(To keep up the travel theme, I’m also planning a trip to Perth, Australia in May to speak at YOW! West. If you know of anyone round there who’d like some of my time, I have a few days free around the conference and would love to use them productively).
]]>0James Stewarthttps://jystewart.net/<![CDATA[Enterprise-ready SaaS Features]]>http://jystewart.net/?p=16282017-03-24T10:35:44Z2017-03-24T10:35:44ZContinue reading "Enterprise-ready SaaS Features"]]>In my last post on Cloud-native organisations I said:
“we should be clear about the principles that apply and help our people understand what we need to watch out for when choosing technology.”
As the responsible people in an organisation we need to be thinking about things like:
We need to be confident that when people leave our organisation we retain access to information on the work they’ve been doing
We need to be sure that the sensitive information we handle in our organisation can only be accessed by authorised people
Where we have time-sensitive business commitments, we need to be confident that third-party software will be available for us to use when we need it
The specifics like how important that is, what types of information, etc. will be context sensitive.
Being clear about those concerns, and then translating them into the sort of features we need (eg. good archiving tools, single-sign-on integration, etc) helps us think about what’s really essential and then be clear with the market about what we need and why.
Approaching it with those two steps–what is important to my organisation, and then what might that mean in terms of features–helps us in a few ways. It:
Helps us work out when these things become important – is it whenever someone uses a tool, or is it when they’re used for certain purposes?
Lets us consider which measures are best dealt with through product features, and which are about how we shape our processes or use our tools
Provides space for innovative approaches as we’re free to consider what we’re trying to achieve, not how we expect it to be done
That said, most of the time the basics we want are covered by pretty standardised, common features.
(As an aside: it’s worth recognising that these are all things we’d think about regardless of who provides our software, it just happens that they come into focus for many people when thinking about “cloud”)
Catching up on blog posts recently I was delighted to discover “The Enterprise Ready SaaS Feature Guides” (via Tomasz Tunguz). It’s very much a supply-side resource that covers those basic implementation requirements, and well worth anyone making software decisions (whether supply-side or buyer-side) taking a look.
]]>0James Stewarthttps://jystewart.net/<![CDATA[Cloud-native organisations]]>http://jystewart.net/?p=16232017-03-20T16:18:59Z2017-03-20T16:18:59ZContinue reading "Cloud-native organisations"]]>I spoke recently at the OpenGov Leadership Forum in Manila and at Cloud Expo Europe. At both I started to explore a theme from my final GDS blog post: cloud-native organisations.
“Cloud” is a nebulous term. At the start of both talks I explained that, while there are formal definitions that I’ve found useful, for me it’s just a useful term for starting a conversation about what’s currently happening at the collision point of “the internet” and “computing tools”. Most of the time for technology, I don’t draw a distinction between the impact of cloud, agile, devops and a number of other inter-related movements.
I talked in both settings about the work that we did in GDS and across government, of which the “Cloud First” policy was a significant part. They were both short talks and I was struggling for time. I should have gone into quite a bit more detail about GDS’ work when speaking in Manila.
For Cloud Expo Europe I drew out several lessons from the work in government. The primary lesson was that changing how we approach technology changes how we think about what government does.
Learning from the government journey
I’ve talked before about how there’s a real opportunity to be much clearer about what needs to be bespoke and what we can consume. There are a set of areas where organisations think they have special requirements for their core technology. Most of the time that’s not true.
That is important, but the more transformative change is that as a set of technologies becomes more accessible it becomes part of our normal toolkit.
A much lower barrier to entry for technology lets cross-disciplinary teams incorporate technology development into policy and service design, and to iterate it in an operational setting. A set of traditional barriers are no longer necessary. Those cross-disciplinary teams–given freedom to meet their goals–are where we will get performance and innovation.
Today’s technology world
I went on to talk about some general trends in the technology world, once again citing Stephen’s Developers are the new Kingmakers. Top-down decision making isn’t enough to handle the pressure organisations are facing to change, or the scale of opportunities available through open source and cloud technologies.
What we see with the mature end of devops, and in much of the thinking behind “cloud native” architectures, is a strong focus on the team as the unit of delivery. And the team as the unit of responsibility. There are a set of architectural practices that support independent teams. They work where organisations set clear goals and principles.
Too often when we talk about “cloud” we either talk about infrastructure-as-a-service, or we talk about software-as-a-service. By and large they’re treated as very different things, but there are some common principles here that ought to be applicable to IT adoption more generally.
Software-as-a-service–particularly software that’s offered via a “freemium” model–allows a complete shift from a world where every new productivity tool has to be evaluated by a central IT department. People are expecting tools at work at least as good as those they have at home, and often will just adopt what they need whether the central department likes it or not.
As with many things we associate with cloud, that’s not new (though the scale has changed). It’s what we have been calling “Shadow IT”. With the shift to cloud we have the opportunity to change our approach.
In the talks, I cited the “Cloud Security Principles” as an example of how being more explicit about the things we care about lets us empower more people to make good decisions.
Those principles are an early illustration of how we should be thinking about cloud tools (IaaS or SaaS) in general. We should be clear about the principles that apply and help our people understand what we need to watch out for when choosing technology. Then we can help scale the use of the tools they find most useful.
There’s a lot more to do to take the thinking in those principles and really open it up to a wide audience, but they work very well as an indicator of direction.
To illustrate what that should be letting us do, I stole a line I loved from a recent Netflix blog post. A goal of all “cloud adoption” efforts should be to give people more control of how they meet their goals.
The real challenge
As with almost everything, the real challenge for organisations is about leadership. Organisations face many challenges and it’s easy to fall back on locking things down as a way of reducing the perceived risks. That’s rarely the most productive approach.
Leaders need to focus on being open: about the real objectives, about the principles that guide how the organisation approaches issues, and about any particular risks.
Management needs a set of practices that understand what’s happening in the organisation, but that’s to keep things on course not to lock them down.
When thinking about cloud-adoption people seem to often get caught up in questions about catalogues of services and new lists of approved tools. Those things may be useful, but we would be better off spending more time explaining how we create a well-aligned, enabling environment before we get down into those sorts of details.
Update: Kush quite rightly pointed out that I didn’t go into anything specific about what to do next. In Manila, there were a set of roundtable conversations where we could begin to get into that. In London, I really just wanted to get people thinking. More blog posts to come…
]]>1James Stewarthttps://jystewart.net/<![CDATA[Clarifying our Cloud First commitment]]>http://jystewart.net/?p=16052017-02-06T10:30:54Z2017-02-06T10:30:54ZContinue reading "Clarifying our Cloud First commitment"]]>This was my final post on the Government technology blog
The government technology landscape has shifted significantly since we made our commitment to Cloud First nearly 4 years ago. Departments have become more mature in their uptake of cloud services and with this maturity comes a need for further guidance. To support this need, we’ve added further clarification to our cloud guidance and policy and we’ll continue to expand this content in the coming months.
From Cloud First to Cloud Native
While working on the new guidance, internally we’ve begun to move away from the phrase “Cloud First” and instead begin to think in terms of “Cloud Native.” Cloud First is the policy we’ve agreed, but it’s not our aspiration.
Cloud Native is one of those terms that has a lot of different definitions, with the more narrow definition encompassing patterns for application design, deployment and operation. We use the term more broadly to include the flexible adoption of Software as a Service (SaaS) applications, which are often loosely coupled and quite task specific.
Cloud Native is not just about considering cloud before other options, it’s about adapting how we organise our work to really take advantage of what’s on offer and what’s emerging.
The need to take advantage of new cloud developments
As the world of cloud technologies continues to accelerate, we should absorb new developments into how we work. Leading organisations are rapidly embracing new tools like “serverless” computing. Some are also investing more in retraining staff so they can get to grips with these new opportunities. We need to make sure the government keeps pace.
At the infrastructure and application level we should expect our applications to be resilient, flexible and API-driven. We should have the tools and practices in place to manage and secure a distributed range of tools accessed over the internet.
We should empower everyone in an organisation to help us become more effective in technology by letting any staff member trial new SaaS applications. Our management and security practices should support this approach. We should look for an API-centric approach that will let us easily integrate new SaaS applications into the rest of our architectures.
A decade of industry growth in the public cloud, and nearly 4 years of our Cloud First approach have given us examples of teams or organisations doing these things, often within government. We need to make them our default. For example DWP Digital has moved telephony to a cloud based service, with nothing in the offices except a phone and a wide area network connection.
Unless we adapt how we adopt technologies and focus on core outcomes and principles we won’t be able to meet the growing expectations of our users’ (including our staff), and we won’t be preparing for even deeper changes that are likely to come as we deal with ever growing volumes of data, and a proliferation of devices and sensors.
What Cloud Native means for government architecture
To become Cloud Native, we need to focus on the digital outcomes we need and how to achieve them. It’s with this focus, for instance, that the National Cyber Security Centre produced the Cloud Security Principles and some guidance on protecting bulk personal data. But in the remit of security, we still have work to do in getting a better understanding of what different providers offer and where we place our trust.
To truly become cloud native, we need to transform how we monitor and manage distributed systems to include ever more diverse applications. We need to deepen our conversations with vendors about the standards that will help us manage these types of technology shifts. We need to continue to ensure we always choose cloud providers that fit our needs, rather than basing our choices on recommendations.
Over the coming weeks we’ll be blogging more about what this means in practice, and GDS will be hiring a new Chief Technical Architect to take forward this work. If you work for government, we’d like to hear your thoughts on what cloud native means to you.
]]>0James Stewarthttps://jystewart.net/<![CDATA[Trust and privacy: sharing lessons]]>http://jystewart.net/?p=15972017-01-27T16:00:39Z2017-01-27T16:00:39ZContinue reading "Trust and privacy: sharing lessons"]]>This was originally posted on Government Technology
Back in November Emma Pearce blogged about using big data following the first in a series of data seminars we’re running. We’ve now held our second session, hosted by Facebook, which focussed on trust and privacy.
Stephen Deadman, Deputy Global Chief Privacy Officer at Facebook, welcomed us for a talk and Q&A. Facebook is often held up as an example, both positive and negative, due to their profile and size.
Having come across the work Stephen’s team are doing to explore attitudes and opportunities around privacy, I was keen to explore what government can learn from their work and what the areas of overlap are likely to be, both as practitioners and regulators.
How Facebook works
In 2010 Facebook set up a dedicated team to oversee their privacy programme. The team was tasked with creating strategic guidance for how Facebook operates.
The team links together engineering, operations and policy teams to help the company navigate the outside world, ensuring they meet European standards of compliance and those of the rest of the world. They provide tools and training to make sure that teams are able to start from a solid foundation, and can also embed a small number of specialists where products merit it.
Over the years Facebook has expanded and now owns several other popular brands such as Instagram and WhatsApp.
Facebook faces some common misconceptions about how they work. One example was the new WhatsApp policy update: users commented that it was rolled out without much consideration. Stephen told us that it had been in development for over 18 months, with the team carefully considering a whole range of factors including timing, legal aspects, user experience and more.
The assumption that such decisions are made overnight can make it difficult for an organisation to get off on the right foot for a conversation with users about what the changes mean. One of the ways to move away from those misconceptions is to make their work more transparent.
Transparency
Facebook has 1.8 billion users worldwide and transparency of data is a global problem. For 18 months Facebook have been working with CtrlShift to improve this and the final report on their work was published in May. That work was what had first drawn our attention to Stephen and his team.
It can be very hard to get a clear understanding of user attitudes to data sharing and privacy, with different accounts varying widely. We discussed the fact that we commonly see headlines about “only X% of people trust organisation Y with their data” but there aren’t good benchmarks of what level of trust we should expect. The research and global roundtables backing the CtrlShift report are a really useful effort to look at themes in this area.
One of the main links drawn from the work is the need for deeper design thinking that can move the conversation about transparency and regulation past false binaries. Stephen used the analogy of car design – there are a great deal of safety regulations out there which all car manufacturers must abide by, but the designers are still free to design and iterate around those safety features to make an individual, desirable end product.
This design thinking can be applied to getting businesses around the world to adopt transparency solutions. In the past regulations have been good at stopping bad things, but not so good at setting a baseline for best practice.
Governments need to make sure that laws and regulations are abided by, but encourage and enable a cycle of continuous improvement: research, iterate, feedback.
Gaining trust
Other companies are also striving to improve their transparency. For example, when a new update comes through for an Apple product, users are presented with a lengthy policy document. But how many people actually read it?
Could it be that terms and conditions just aren’t designed for consumers and aren’t communicated in a way that they would understand?
But how do you get this right? Laws change and new features are introduced and companies should be sharing this information but when they do it leads to more questions and distrust from users. It’s an ongoing issue with no simple answer.
Facebook conduct assessments to check the privacy impact of every product and use a tool to track projects at every stage of their creation and implementation (a bit like our service assessments), but it’s an ongoing battle.
Stephen talked about the idea of the passive consumer – it can be hard to get them involved and educated about the use of their data but it is their fundamental right to see it. For the private sector putting data in the hands of the consumer allows them to get more involved.
Lessons from around the world
Drawing from experiences developing this research, Stephen pointed to a willingness to think differently in Asia, and in particular Singapore. A commitment has been made to digitise the state which means a fundamental change of thinking and making data a key part of society. There is always a degree of tension between those who are creating the good tech stuff and those who want to protect rights. But by putting it at the forefront of thinking that debate is going to be far more productive.
We discussed the importance of integrated multi-disciplinary approaches there. As the possibilities of technology and service design accelerate we need to consider new, more flexible approaches to regulation but unless that’s shaped by teams with the right mix of skills we won’t be able to strike the right balance. As government is the custodian of a lot of data and the provider of a lot of services, we have the opportunity to bring together our work as practitioner and regulator to help inform that balance.
Stephen finished by encouraging us to continue to recognise that data is a good thing and should be nurtured. We could learn a lot from the infrastructure being put in place in Singapore and by working closely with industry experts to see how they are using data in interesting ways. We need to ease the nerves around this issue and explain why it is helpful. We can use this to create critical design patterns which can be shared and reused.
The main lesson: great services with greater control leads to happier citizens.
]]>0James Stewarthttps://jystewart.net/<![CDATA[The internet is ‘ok’]]>http://jystewart.net/?p=15922017-01-20T16:47:23Z2017-01-20T16:47:23ZContinue reading "The internet is ‘ok’"]]>Originally posted on Government technology
When different parts of the public sector share services and exchange data it’s important that we can rely on the basic security of each other’s technology, and that the data will maintain its integrity as it moves around. It is an important part of ensuring that there’s a clear layer of trust between everyone involved in the interaction.
For the past few years a lot of government (and wider public sector) services have relied on the Public Services Network (PSN) to provide assurance of that IT security. As a high-performance network operated by multiple vendors, the PSN provides assured connections for a wide range of public sector organisations.
As we move more and more of our systems to public cloud services the expectation that we’ll communicate over the PSN can cause confusion and adds complexity for public sector organisations and our suppliers.
At a recent meeting of the Technology Leaders Network, we reviewed our position and it was clear that everyone agreed we could just use the internet.
For the vast majority of the work that the public sector does, the internet is ok. We’ve got some advice in our network principles.
We’ll often need to deploy the sort of security measures described above, along with a host of other measures to ensure basic application-level security, but as my colleague Shan Rahulan said during the meeting we increasingly need to do that even when services are on the PSN. This then opens up the question of whether the extra layer of complexity is really helpful.
So that means we’re on a journey away from the PSN.
Of course, it’s not going to happen immediately. Organisations that need to access services that are only available on the PSN will still need to connect to it for the time being. They’ll need to continue to meet its assurance requirements, and in fact they should make use of the practices that covers when reviewing all their core IT.
But from today, new services should be made available on the internet and secured appropriately using the best available standards-based approaches. When we’re updating or changing services, we should take the opportunity to move them to the internet.
What happens next?
There’s quite a bit of work to do across the public sector to prepare for these changes and we’re not quite ready to provide a full timeline. We’ll be staying in touch with users of the network and commercial providers to make sure that those who need to make decisions get clear information.
My colleague Mark Smith, Head of PSN, has been working with data scientists in GDS and the National Cyber Security Centre (NCSC) to prototype other ways of providing assurance data that will help organisations establish trust. He’ll introduce that soon in a blog post and is doing some deeper discovery work to ensure we have great options for organisations to verify that their networks meet a set of basic standards.
GDS, NCSC and Crown Commercial Service (CCS) will be working together to ensure that as we update the ways in which we buy network services we have the widest possible range of suppliers and the right options to make sure we get the highest quality connections.
We’ll be working with the Tech Leaders Network and the wider PSN community to ensure that common issues are clearly identified and that wherever possible we work together to provide common solutions.
We’ll also be working with colleagues in the Cyber and Government Security Directorate and others across the public sector to make sure that we are able to collaborate on upgrading older systems that need new protections and share good practices. That’s a clear part of the National Cyber Security Strategy and this move just adds some more focus to plans already underway.
]]>0James Stewarthttps://jystewart.net/<![CDATA[Our commitment to better Open Source practices]]>http://jystewart.net/?p=15872016-12-14T15:38:44Z2016-12-14T15:38:44ZContinue reading "Our commitment to better Open Source practices"]]>This was originally posted on Government technology
We committed to sharing what we’ve learnt over the past few years about bringing open source and related working practices into government, to working collaboratively with other governments to develop common practices and policies, and particularly to making sure that open source plays a big role in our growing international collaboration around Digital Marketplace and procurement reform.
The OGP roundtable session discussing the commitment and the draft policy were a good start to involving a lot more governments in that work, and to see the support we have from a number of influential open source foundations and companies.
The summit
I attended the summit alongside Paul Maltby, and Sir Eric Pickles in his position as the Prime Minister’s Anti-Corruption Champion. It was great to experience the many themes around openness and transparency coming together with an impressively diverse agenda and group of attendees. With so many significant global political moments having occurred over the past year the mood was naturally very reflective.
At GDS, our day-to-day focus on open source and open standards in government ensures that the UK government can control its own technology and provide efficient foundations for great services. The summit was a helpful reminder that it’s also important that we keep thinking about the ways that open source culture and code work to make sure that the systems and algorithms we develop are as transparent as possible and enable new forms of accountability, participation and collaboration.
On a more immediate level it was good to learn a bit more about what other countries are doing, such as our French hosts’ OpenFisca which is a set of open source tools to simulate tax and benefits systems and a big step toward a significantly more transparent social security system.
What we’re going to do
The first deliverable of the group is an open source contribution policy template which will continue to be developed over the coming months. We’ll be helping to refine the template so we can all contribute to other work in a similar way.
We’re aiming to model open source collaboration across governments in a new phase of work on Digital Marketplace that will build on our work with Australia earlier in the year. The Digital Marketplace team will share more about those plans soon and we committed to sharing what we learn with the OGP community.
There are many other ways in which we can collaborate with other governments and with the wider open source community. We’re looking forward to continued conversations with the other governments, foundations, companies and NGOs that took part in the sessions.
