building gov-e-services in estoniaIDU0450

Andres KüttFebruary 25, 2015

Chief Architect, Information System Authority

introduction

structure of today

∙ Six ≈ 30 minutes sections, punctuated by your chance to talk∙ This thing depends on your contribution!∙ Respect the time of others

I might have information.But I do not have the answers, only more questions.

2

andres kütt

∙ Building software for money since 1993∙ Been an architect for the past ≈ 10 years∙ ≈MSc (UT, Statistika), MBA (EBS), MSc (MIT)∙ Currently architect of Estonianinformation system

∙ Skype, banks, public sector + someconsulting in the past

3

today

∙ Introduction∙ Foundations of e-government∙ Estonian e-government architecture∙ Organisational infrastructure for e-services∙ Information security concerns∙ Understanding the ecosystem∙ Joining the ecosystem∙ Development and procurement

4

foundations of e-government

foundations of e-government

The following points must not be violated when building ane-government service

∙ Simply because they form the foundation of the entire country∙ But also because doing so will make building the service verycomplex

6

trust between parties

An externally guaranteed trust framework between citizens,businesses and the government is a prerequisite of e-governmentservices.

∙ Information systems involved are too complex to comprehend,thus the need for explicit trust

∙ There has to be an external (e.g. cryptographic) guarantee to thetrust keeping it from gradual deterioration

∙ Only wealthy countries can afford not to have that trust: IRS lost$5.2 billion to identity theft in 2013. Translated via GDP this wouldmean e6 million annual loss in Estonia.

∙ Among other things this assumes no party (e.g. media) is activelytrying to disrupt that trust

7

ubiquitous electronic identification

On the internet, nobody knows you are a dog

∙ The assurance level of services provided is dependent on theassurance level of the electronic ID∙ The British way can only go so far∙ For simple cases e-mail is sufficient∙ Digital signature requires a PKI-based solution

∙ Ubiquity stems from people using various e-services on a dailybasis and realising their benefit. It is needed so that∙ electronic service can become dominant∙ the users are acquainted with the risks involved∙ the users actually find it convenient to use it

8

”breathing room”

The players must have the ability and capability to change theiroperating model with reasonable effort

∙ By definition: if everything is in place, any change would goagainst the well-established rules∙ Stability means things happening tomorrow the way they happen today∙ Innovation means the exact opposite

∙ Many of the decisions underpinning our e-government would beimpossible to execute in a well-controlled environment∙ Risk management processes alone would be a sufficient deterrent∙ This is mental to a large extent: what do people have to loose?

∙ A certain level of chaos is needed for progress

9

critical levels of critical competences

Without the following competences, it is not feasible to build ane-government as they are neigh to impossible to outsource

∙ Ability to procure development∙ Basically, one must be able to act as a responsible customer∙ Vendor management is big part of it∙ Ability to provide input and validate the output

∙ Ability to procure operations∙ Operating the service means controlling the data, this is important!∙ Weak operations lead to low service levels and loss of trust

∙ Information/cyber security∙ Who will work out your electronic identity scheme?∙ Whose cryptography do you trust (and can you make your own)?∙ How do you protect your service?

To sustain the e-government, the ability to absorb IP is needed10

relatively small scope

Too big things get too complex too rapidly

∙ Complexity increases exponentially as elements are added∙ When we double the size, complexity gets squared (roughly)∙ The ability to develop e-services is depends on system complexity∙ Larger countries have more people, agencies, processes etc., thusthe following gets much more complex∙ integrating the systems∙ getting approvals∙ inflicting change

∙ Whenever possible, assemble larger systems from clearlyencapsulated smaller ones

11

collaboration

Collaboration between engineers and decision-makers is crucial

∙ No sane official goes ”let’s integrate all information systems usingXML-based messaging”

∙ Engineers like to build, officials like to sustain∙ Building things requires at least∙ thorough understanding of the business∙ legal support and understanding of the legal system∙ ability to work with the democratic process

∙ Therefore, collaboration between parties is an absolute must

12

discussion point

Can Estonian levels of trust be built elsewhere?

13

estonian e-government architecture

architecture of estonia

Agency Agency AgencyAgency

Electronic identity

Citizens/Officials/Enterprises

Delivery channels

Integration

Infrastructure

Fina

nce

and

port

folio

man

agem

ent

Info

rmat

ion

secu

rity

Information System Registry

15

electronic identity

∙ Implemented using PKI, CA service provided externally∙ The certificates live on a chip (smart card or SIM)∙ Digital signature legally equivalent to the physical one∙ Millions of signature and authentication events annually∙ Depends on the personal id-code of the citizen

16

channels

∙ Central service portal eesti.ee with 800+ services accessible∙ Main challenge: maintaining service ownership∙ No central UI/UX guidelines although a recommended web sitetemplate exists

∙ Hundreds of individual contact points∙ Mobile is very small

17

integration

∙ Distributed service bus called x-road∙ All communication happens peer to peer∙ x-road provides standardised∙ channel crypto∙ access control∙ service discovery∙ audit logging∙ identity management∙ protocol support

∙ Massive deployment, 1000+ usable services∙ Constantly developed, version 6 getting ready to roll∙ De facto enables once-only and privacy

18

infrastructure

∙ Being expanded rapidly, currently only network∙ Government cloud is a combination of∙ private cloud∙ public cloud∙ data embassies

∙ Security and service availability major drivers: we no longer canrun this country without e-services

∙ Scalability and cost are also becoming an issue

19

discussion point

How to make the agencies cooperate with each other?

20

organisational infrastructure for e-services

The main point of democracy is preventing concentration of power

22

problems in architecting a country

How to govern software architecture in a democratic country?

∙ Democracy rules out authoritative approach∙ The solution depends heavily on context∙ National culture∙ Structure of a country: municipalities, type of federation etc.∙ Nature of the architecture layers

Anybody seeking to build e-services (or do architecture) in publicsector must be able to rely on their soft power

23

In private sector, budget surplus means profit.In public sector, budget surplus means taxes collected in vain

24

architecture governance

EIFITL Founded

AndmevaraMember of

Ministry of Interior

Owns

CyberneticaMember of

SMIT Governed

by

Ministry of FinanceRMIT Governed

by

Ministry of JusticeRIK Governed

by

KEMIT Ministry of Environment

Governed

by

RIASupplies

software to

ASO

Ministry of Education

HITSAFounded

EEnet

Is part

of

Part of

Cooperates

CERT-EE Part of

GOV-CERT

Part of

MoEA

Governed by

RIKS

Founded

Informatics Counsel

GathersRISO Part of

ITAOPart of

25

architecture of estonia

Agency Agency AgencyAgency

Electronic identity

Citizens/Officials/Enterprises

Delivery channels

Integration

Infrastructure

Fina

nce

and

port

folio

man

agem

ent

Info

rmat

ion

secu

rity

Information System Registry

26

funding

∙ The carrot part of moving a donkey∙ Used to support policies and architectural decisions includinginformation security

∙ Drives desirable behaviours like service management∙ Covers SF and parts of central budget∙ Gives input to architecture development by initiating projects andfunding change

∙ Can be used to drive reduction of technical debt

27

information security

Security is an emergent property of a system

∙ Cybersec deals with architectural mistakes of the past, securitycannot be bolted on

∙ Three main areas:∙ Protection of information systems crucial for the country∙ Protection of private data. Data is the new oil!∙ Defense/security aspect of things

∙ Based on ISKE, a measure-based approach adapted from Germany

28

riha

RIHA is a central repository of information on information systems ofEstonian government

∙ Some policies rely on a central repository of metadata:∙ Once Only Principle™∙ Enforcement of x-road for information exchange∙ But also funding decisions, open data initiatives etc.

∙ Currently relies on manual data entry but being moved to an opendata based approach

29

not pictured: eu

EU is becoming increasingly active in the electronic services field

∙ Large number of policies being developed require input andproduce pressure

∙ Our position is a massive challenge∙ small size means many policies are too large∙ advanced services mean increased chances of SEPA-like situations∙ our mindset towards privacy, trust, service development etc. is verydifferent from most of Europe

∙ lack of people means driving topics is a disproportionate burden

30

discussion point

How can anything get done in this context?

31

information security concerns

what is information security?

Both safety and security are emergent properties of a system

∙ A system (not just software!) behaves safely or securely after it isbuilt. Therefore:∙ System safety/security must be by design, it cannot be added later∙ Safety and security cannot be fully predicted

∙ Safety and security are two aspects of the same thing∙ Rapidly increasing system complexity a real factor here

All software is insecure until proven to be sufficiently so

33

safety by design: an example

Korea is about to replace all of their ID-codes

∙ Their system was designed to assume the id-code is secret∙ Additional measures were designed to be weak for improved usability∙ Short near-plain-text passwords stored on device (\me rolls eyes)

∙ Over the years, ≈80% of the population had their ID-codes stolenthrough various breaches

It is not about Korean infosec being bad, it is about their systembeing designed to assume it to be impossibly good.

34

security of the cloud

Think very carefully about storing sensitive information in the cloud

∙ The cloud provider can and will use your data whichever way theyplease. Read the EULAs

∙ Even if they don’t, you can’t tell should there be a breach∙ Even if there is no breach, you are not alone in there∙ Usefulness of encrypted data must degrade faster than security ofthe encryption method used

You have no control whatsoever over who does what with your dataonce it is stored in the cloud

35

on cyberwar

Very nasty business, getting nastier all the time

∙ Completely changes the way people can express their patriotism∙ For years, there has been a black market of exploits, botnets,electronic bounty and various related software

∙ Now governments are mixing in and the business is booming∙ New threats require very different response methods

Technology is driving a rapid change in the nature of war

36

discussion point

Can there be privacy on the internet?

37

understanding the ecosystem

All services exist in an ecosystem of people and organisationspursuing ever greater value gained per unit of effort spent

39

data flows

Where does your data come from and where does it go?

∙ What is the source of your data? Answer to this question answersthese others:∙ Who do you depend on for your service?∙ Who owns the data you use?∙ Whom do you need to please for your service to prosper?∙ How sensitive is the data?

∙ What is the destination of your data? Answer to this questionanswers these others:∙ Who depends on your service, i.e. who will be sad if your service dies?∙ Who has the potential to leak your data?∙ Who is willing to support your service?

40

system flows

Where does your system come from, where does it live and wheredoes it go in the end?

∙ What is the source of your system?∙ Whose capabilities do you need to reckon with in system design?∙ Who do you need to explain your design to?∙ Where will the IP be created?

∙ Where does your system live?∙ Who will need to live with whatever you design?∙ Who will control your system?∙ Who is responsible for operational security?

∙ Where does your system go?∙ What are the archival requirements?∙ What is the expected age of your system?∙ Who will be responsible for migrating data out of your system?

41

multitude of stakeholders

The stakeholder situation is complex in public sector

∙ The number of stakeholders is larger, as there is more regulation∙ Stakeholders are separated by higher organisational boundaries∙ Stakeholder flexibility is severely limited∙ Money is seldom a leverage∙ Some of the stakeholders can have massive influence on youpersonally

42

mapping the ecosystem

Mapping your ecosystem in five easy steps:

1. Draw a bubble for each stakeholder ignoring their classes2. Starting from the one most interesting to use, ask for each pair ofstakeholders:∙ What does stakeholder A get from stakeholder B?∙ What does stakeholder B get from stakeholder A?

3. If A gets anything from B, we draw a line from B to A and annotate4. Validate the picture by asking about each stakeholder: where dothey get whatever it is they are giving away?

5. Analyse the picture to detect feedback loops, ”gategeepers” etc.

43

discussion point

Where does an ecosystem end?

44

joining an ecosystem

understand the ecosystem

1. Map your ecosystem as described previously2. Identify resources your service needs

∙ Identify existing services using RIHA∙ Using RIHA, identify data elements not yet exposed as services∙ Using system analysis, identify data elements you need, cannot collectand that do not exist in any dataset

∙ Talk to people in the know

3. Negotiate with stakeholders4. Change your service design and repeat

46

negotiating access

Access to existing services is technically trivial but might involve alot non-technical activities

∙ Make sure you have a legal basis for getting the data∙ Understand the SLA1 of the service and compare it to yours∙ If necessary, establish an explicit SLA stating contact persons, contactprocedure, notification rules etc.

∙ Understand the related infrastructure: test environments, testusers, monitoring hooks etc.

∙ Understand the data quality∙ Get in touch with the service operator and request access toservice producing evidence you may actually have it

1Service Level Agreement47

negotiating development

If a service is not there (or is not satisfactory) but the data is, theother party must do work

∙ Prepare for a delay of at least 6 to 18 months∙ In government, people need a good reason to do things∙ Common good is usually not a sufficient reason∙ A legal requirement is a much better one but not always sufficient (!)∙ Personal contacts on a high level are most reliable

∙ You must have a very clear understanding of your needs∙ Prepare to be countered:∙ What is it exactly that you need?∙ I cannot do this because it is illegal\immoral\dubious\inconvenient∙ It is prohibitively expensive∙ It is going to take five years∙ We do not have the data

48

negotiating business process

If the data is not there, a business process is needed to collect it

∙ Only do this if really desperate∙ All data collection in Estonia must have a legal basis∙ Some political mandate∙ A law requiring collection of the data∙ Agency statute permitting the collection∙ Dataset statute describing the data collected∙ RIHA documentation with technical detail

∙ The other agency must do a lot:∙ Changes in their software∙ X-road interface to make the new data available∙ Business processes handling data collection data via all channels∙ Handling of older registry entries without the data

49

Minimal latency of any government agency is 9 months:nothing happens unless it is on the Work Plan

and there is budget for it

50

discussion point

How to make another agency see the big picture?

51

development and procurement

the operators

Never ignore people who need to live with whatever you build

∙ It is just a decent thing to do∙ They are also in position to completely ruin your day∙ It is a really bad sign when you do not know who these people are∙ Make sure you understand the non-functional requirements∙ NFR is a contract between developers, testers, security and operationson what constitutes an ”OK” system

∙ Therefore it needs to be constructed in collaboration∙ Never change the NFR for your project without consulting everybody

53

the procurement process

Procurement process is always heavily prescribed

∙ There are usually several process options to choose from∙ Pick carefully the one most suitable to your situation based on∙ How well-defined are your requirements∙ How narrow is the bracket of technical competences necessary∙ What is the operating model of the service going to be∙ What amount of how significant IP is going to be created

∙ The people executing the procurement and designing the servicemust cooperate tightly

54

financing

Make sure you understand the financing model very well

∙ Money usually comes with a catch. Find it.∙ People giving you money will look closely at how you spend it∙ Be ready to pay back every dime should you fail to walk the line

55

change perspective

Look at things from the tenderers perspective

∙ What information would you need to put in a reasonable offer?∙ What might your interests be?∙ What would cause them to join/leave the tender process?

56

play your part

It takes a surprising amount of effort to spend money

∙ The more money is to be spent, the more detailed the tenderpaperwork needs to be

∙ All deliveries must be accepted∙ Very seldom is the specification enough, usually additional inputfrom the beneficiary is necessary

∙ Operations support can be considerable for training, deploymenttesting, environment setup etc.

∙ Training, data migration, marketing etc. also need resources∙ Much of this applies to other stakeholders as well, engage theecosystem early

57

discussion point

What are the key success factors of successful public sectorprocurement?

58

license

theme

Get the source of this theme and the demo presentation from

http://github.com/matze/mtheme

The theme itself is licensed under a Creative CommonsAttribution-ShareAlike 4.0 International License.

cba

60

contents

The contents of the slides is lidecensed under a Creative CommonsAttribution-NonCommercial-ShareAlike 4.0 International

cbna

61

Questions?

62