Thank you, Mr. Chair; and thank you to the committee and Alex.
With me is my colleague John O'Brien, director of security and reliability engineering at the Canadian Digital Service. Before CDS, John was with the Communications Security Establishment as a technical lead for malware analysis and automation, or put more simply, John knows how the bad guys operate.
For those of you who are less familiar with CDS, we're a digital consultancy in government, for government. We're part of the Treasury Board Secretariat and we work side by side with Mr. Benay's organization. CDS was established only 18 months ago, with a mandate to help this government improve how it designs and delivers digital services by providing direct, hands-on help to federal departments to make digital services faster, simpler, more accessible and secure. In the process, we help build capacity in those departments to do modern service design and delivery.
For example, we've been working with Veterans Affairs Canada to improve how veterans and their families find and access benefits; with Immigration, Refugees and Citizenship Canada to help newcomers to Canada reschedule their citizenship tests online; with the Royal Canadian Mounted Police to help victims report cybercrime and online fraud; with our colleagues in Mr. Benay's office to make connections to government websites more secure; and with the Canada Revenue Agency to help Canadians with low income file their taxes and access related benefits.
I'm American.
Before I arrived in Canada last spring, I had the privilege of leading a similar initiative in the U.S. to bring new tools, practices and approaches into government to better serve the public. In 2013, I was a presidential innovation fellow. We were told on our first day as fellows that it was a bait-and-switch program, and sure enough, many of us who signed up for six-month fellowships stayed for four years.
My colleagues and I went on to create the service delivery unit called 18F in the aftermath of the failed initial launch of healthcare.gov. I served as 18F's first director of delivery and then as executive director. I'm also a former lawyer.
As Mr. Benay pointed out, digital isn't just about bringing services online. As our U.K. colleague Tom Loosemore once put it, digital is about “Applying the culture, practices, processes and technologies of the Internet era to respond to people's raised expectations.”
Technology is not without its challenges, but it's not usually the hard part. We only half joke at CDS that we're a change management office disguised as a digital service office half the time.
How do we go about designing and developing government digital services that are both easy to use and secure? There are lots of answers to that question, but I want to touch on five important practices that CDS tries to demonstrate in every project we take on, and that historically have been more the exception than the rule in government, but that is changing rapidly.
Those practices are, first, to apply research and design practices that put people first, not rules and processes; second, to deliver and improve continuously; third, to assume there will be failures and to be good at reacting to them; fourth, to work in the open; and finally, to have strong feedback loops between delivery and policy.
In regard to the first, CDS relentlessly focuses on the people who use government services. In practice, this means working with users continuously to find out what they need, not just what government needs from them. We know that among those needs, security and privacy are critical and non-negotiable. To meet those needs, we factor them into how we build and deliver services from the outset, and continuously throughout deployment and development. This allows us to test our assumptions with the people who will use the service. If you've never witnessed user research, it can be eye-opening and profoundly humbling. It lets us develop a mutual understanding about what data is actually necessary to complete a service transaction and provide a first-rate experience.
By engaging with users early on and throughout the design of a service, we're able to develop an ever-improving understanding of their specific needs, concerns and preferences, including what and how much personal data we need to deliver a great service, how long we need to retain that data, and how we can provide assurances about how we will handle it, and when appropriate, delete it.
Talking directly and often to the people we serve is critical to building in privacy and security from the start, which brings me to the second point about how we work.
We develop digital services iteratively, employing practices and tools that enable continuous, incremental improvement. How does this promote more secure systems? The Canadian Centre for Cyber Security publishes a list of the top 10 IT security actions organizations can take to minimize the likelihood and impact of a cyber intrusion, and one of their key messages is to keep your systems patched and up to date, such as the regular updates you make to your phones from Apple, Google or BlackBerry.
This seems simple, but it's an issue for organizations everywhere. To do this well and in a timely way, services need to be built in such a way that frequent improvements are the norm, not the exception. The harder it is to make changes to your system, the longer it will take to create and disseminate fixes when a vulnerability is discovered.
Some government systems in operation today deploy changes only a few times a year, other than urgent patches, and even a simple change request can take more than a year to work its way through the long queue, get coded, and survive a lengthy, manually driven gauntlet of review, compliance tracking, testing, staging, and perhaps a little silent prayer before it goes live.
By contrast, most of the websites that you interact with every day, built by companies like Amazon, Google and Shopify, release dozens or hundreds of changes every day, safely, quickly and painlessly, into the public. This process is commonly referred to as continuous delivery, and it's how we build things at CDS, too. Updating systems to improve reliability, to fix problems, and to adapt to users' changing needs and expectations is easier, faster and more reliable this way. Making this model of continuous delivery and improvement the norm in government is both a problem of technical debt and a problem of delivery practice. Modernizing our systems and how we manage changes to those systems is the single-most effective thing we can do to improve the security posture of those systems.
This brings me to my third point. Continuous delivery enables you to act quickly when something goes wrong—not if, but when. In a perfect world, every system would be 100% secure. Of course, we don't live in that world. Cybersecurity best practice is to make the rational assumption that failures and breaches will happen, and to plan accordingly. Leading organizations make the most of the lessons learned after every such incident, large or small, to improve their resilience. We conduct blameless post-mortems after incidents, creating an environment where staff feel psychologically safe and confident in being fully open and honest about errors and mistakes. We learn more and improve more by acknowledging failures than by hiding them. It's healthier for organizations to encourage discovering and surfacing the root causes of failures than for people to fear being blamed for circumstances outside their control.
Fourth, we've all witnessed the blowback against organizations that stay silent about security incidents or other kinds of project failures for far too long. This is one reason why we work in the open—that is, in full view of the team, and whenever possible, the public. Building our services in the open by default reduces risk. This might seem counterintuitive. It is a stubborn myth that secrecy is good for security. In practice, developing software in the open allows others to contribute to, stress-test and critique our work. It provides more incentives for everyone to get the code right instead of taking shortcuts that might not be exposed in a tightly held environment. It gives us the opportunity to discuss openly the decisions we're making and the potential trade-offs. It allows us to create a culture of learning from mistakes, and it shares our work with others—a perk of which we've been the beneficiary many times already.
The U.K. government encapsulates this in a simple design principle, “Make things open: it makes things better”. The same principle appears in our government's digital standards.
This brings me to my final point about how we go about delivering secure, easy-to-use services to the public. Mike Bracken, who led the U.K.'s government digital service through its first four years, once wrote that “in an analog world policy dictates to delivery, but in a digital world delivery informs policy. This is what agile means for Government and its services”.
Working with and listening to our users, putting working prototypes in front of them as quickly as possible, and continuously improving those services is the best way to not only learn what works for our users, but also learn which policies are working, how others are not, and how we should update them to keep pace with modern expectations. This is somewhat of a shift from traditional policy development, which is often divorced, organizationally, from implementation. Everything is figured out months, maybe even years, before it lands at the people who will be impacted by it, at which point, unsurprisingly, it may sometimes miss the mark.
We believe that the practices CDS employs and promotes every day, practices encouraged by the digital standards, are the best way to meet public expectations for better, more integrated services that are also more secure and more responsive to the privacy needs of Canadians.
Having done this in two countries, I feel certain of this: change is hard, and it doesn't happen overnight. However, we're making headway in meeting the public's expectations for user-friendly, efficient, secure service delivery, and we look forward to making more and greater progress.
Thank you. I'd be happy to answer your questions.