Is the dependence of governments on digital giants a problem?

The recent crit­ic­al fail­ure of Win­dows serv­ers, linked to Crowdstrike’s Fal­con EDR¹, has high­lighted the risks asso­ci­ated with the State’s depend­ence on private soft­ware. Although the French Min­is­ter for the Armed Forces has sought to offer reas­sur­ance², the fact remains that the use of com­mer­cial digit­al ser­vices with­in the State must be sub­ject to a bene­fit-risk ana­lys­is designed to ensure that the gain in effi­ciency out­weighs the con­ces­sions in terms of sovereignty.

The sov­er­eignty of a State is its abil­ity to guar­an­tee its inde­pend­ence from oth­er States. It requires the abil­ity to have at its dis­pos­al the human, mater­i­al and tech­no­lo­gic­al resources and any oth­er com­pon­ent needed to pro­duce the nation’s vital goods and ser­vices. This capa­city is judged either at a sys­tem­ic level or at the level of each pub­lic policy. Sov­er­eignty cov­ers food, fin­ance, mil­it­ary, and now digit­al issues, which are com­mon to all these areas.

Digit­al sov­er­eignty con­cerns many aspects, the main ones being³,⁴:

• Digit­al assets, since it is neces­sary to have basic equip­ment gen­er­ated without secur­ity risk (fibres, anten­nas, serv­ers, fire­walls, routers, etc.) to build a trus­ted inform­a­tion system.

• Digit­al ser­vices, because it is essen­tial to be able to col­lect, pro­cess and return inform­a­tion securely to carry out the State’s sov­er­eign func­tions (digit­al iden­tity, crisis man­age­ment, col­lec­tion of taxes and social secur­ity con­tri­bu­tions, etc.).

Using non-gov­ern­ment solu­tions means that solu­tions already developed else­where can be made avail­able more quickly, enabling the gov­ern­ment to focus its digit­al efforts on its core busi­ness. This is often done for reas­ons of effi­ciency and eco­nom­ies of scale, since a pro­pri­et­ary or open-source solu­tion is some­times used by thou­sands or mil­lions of oth­er organ­isa­tions. Examples include text or spread­sheet edit­ors (vari­ous Office suites), payroll or leave man­age­ment soft­ware (SAP, HR-Access, etc.)⁵ or e‑mail send­ing and receiv­ing soft­ware (Out­look, Thun­der­bird, etc.). This cross-func­tion­al soft­ware is tried and tested and ready to use. Cre­at­ing an intern­al solu­tion for the admin­is­tra­tion would be very costly and prob­ably unsuit­able for man­aging a com­mon digit­al requirement.

The acquis­i­tion of equip­ment via ser­vices also makes it pos­sible to meet needs that would require very sub­stan­tial invest­ment by the gov­ern­ment. And without being able to eas­ily ensure eco­nom­ic oppor­tun­it­ies. This is par­tic­u­larly true when it comes to pur­chas­ing com­puters, print­ers, stor­age bays or net­work equip­ment. These pur­chases offer a guar­an­tee of expert­ise and know-how in rel­at­ively stand­ard com­pon­ents, as well as the pos­sib­il­ity of using ded­ic­ated digit­al assist­ance. This approach offers excel­lent effi­ciency, provided that the hard­ware used is suf­fi­ciently stand­ard­ised to be integ­rated into the administration’s inform­a­tion sys­tem and can be sup­ple­men­ted by addi­tion­al ser­vices: applic­a­tions, super­vi­sion, intru­sion detec­tion, etc.

The use of open-source solu­tions can also offer a sig­ni­fic­ant capa­city for innov­a­tion and respons­ive­ness, as it enables tools and applic­a­tions to be integ­rated rap­idly at a mod­er­ate invest­ment cost. In addi­tion, this approach makes it pos­sible to attract digit­al pro­files keen to con­trib­ute to the open-source com­munity and to offer cit­izens real trans­par­ency about the tools used with­in the gov­ern­ment⁶.

The digit­al solu­tions offered by com­mer­cial com­pan­ies com­ply with European and French reg­u­la­tions. But they may also com­ply with the reg­u­la­tions of oth­er coun­tries on mat­ters relat­ing to the pro­tec­tion of nation­al interests. To illus­trate this risk, we can cite the Pat­ri­ot Act, cre­ated after the 2001 ter­ror­ist attacks, which enables the FBI to force com­pan­ies to give it access to their per­son­al data­bases, even for inform­a­tion stored in Europe. Sim­il­arly, the Cloud Act allows the Amer­ic­an author­it­ies to access data stored by Amer­ic­an com­pan­ies, even if this data is stored in Europe, con­trary to the oblig­a­tions of the RGPD⁷.

Fur­ther­more, com­mer­cial or open-source solu­tions may have vul­ner­ab­il­it­ies; the cor­rec­tion of which may be delayed due to cost, lack of human resources or a vari­ety of oth­er reas­ons. These delays in main­tain­ing secur­ity con­di­tions are not neces­sar­ily known to the com­pany or are not imme­di­ately com­mu­nic­ated to cus­tom­ers. As a res­ult, these solu­tions, which have not been developed by the State, can cre­ate secur­ity vul­ner­ab­il­it­ies without the State ser­vices neces­sar­ily being aware of them. The flaw linked to the use of Moveit trans­fer soft­ware had a major impact on Colorado’s Medi­caid pro­gramme⁸.

In addi­tion, the increas­ing use of digit­al solu­tions developed by private com­pan­ies may increase the State’s depend­ence on private tech­no­lo­gies. This can give private com­pan­ies sig­ni­fic­ant power over how the state oper­ates and may lim­it its abil­ity to con­trol costs and ser­vices. The major change in pri­cing policy for VMWare solu­tions is an example of this⁹.

Finally, the pro­cess of integ­rat­ing non-gov­ern­ment solu­tions into gov­ern­ment inform­a­tion sys­tems requires par­tic­u­larly rig­or­ous man­age­ment of the inter­faces between the vari­ous com­pon­ents, wheth­er soft­ware and/or hard­ware. To this end, inter­op­er­ab­il­ity pro­to­cols must be pre­cisely defined and com­ply with the latest reg­u­la­tions and secur­ity stand­ards, to avoid poten­tial exploit­able vul­ner­ab­il­it­ies. A symp­to­mat­ic example is the use of REST­ful APIs for inter-ser­vice com­mu­nic­a­tions. This can enable seam­less integ­ra­tion and offers a lay­er of secur­ity via authen­tic­a­tion and encryp­tion pro­to­cols. The adop­tion of con­tain­er tech­no­lo­gies such as Kuber­netes or Dock­er should also be care­fully con­sidered. Con­tain­er­isa­tion enables more agile and secure man­age­ment of applic­a­tion deploy­ments¹⁰.

For the State to func­tion as effect­ively as pos­sible, we believe it is import­ant to strike a bal­ance between sov­er­eignty and effi­ciency. We there­fore pro­pose sev­er­al non-exhaust­ive guidelines:

1. Define the ser­vices that can be out­sourced and those that abso­lutely must be provided in-house. This approach con­cerns busi­ness applic­a­tions (tax cal­cu­la­tions for the DGFiP (Dir­ec­tion générale des Fin­ances pub­liques), intern­al secur­ity applic­a­tions for law enforce­ment agen­cies, etc.), as well as the neces­sary tech­nic­al ser­vices (office auto­ma­tion, inter­net brows­ing, oper­at­ing sys­tem, net­work oper­a­tion, etc.).

2. Identi­fy the risks asso­ci­ated with out­sourcing and the meas­ures to be taken to mit­ig­ate them. The aim is to define the actions to be taken to main­tain con­trol of each out­sourced ser­vice with­in the State. To achieve this, it is advis­able to define the organ­isa­tion­al pro­ced­ures for out­sourcing: the play­ers involved, con­trac­tu­al com­mit­ments, veri­fic­a­tion pro­ced­ures, the abil­ity to ensure revers­ib­il­ity, etc. These actions are part of the pro­cess of integ­rat­ing secur­ity into pro­jects and val­id­at­ing them dur­ing the secur­ity approv­al pro­cess¹¹.

3. Pay par­tic­u­lar atten­tion to MCO/MCS pro­ced­ures. The aim of this task is to ensure that intern­al and extern­al solu­tions are updated reg­u­larly, with a view to cor­rect­ing mal­func­tions and secur­ity flaws. The quick­er patches are released, the quick­er applic­a­tions are pro­tec­ted against known flaws and mal­func­tions. This approach ensures that the solu­tions used remain state-of-the-art.

4. Use a DevSecOps approach. At the heart of a neces­sar­ily integ­rated pro­cess, adopt­ing a DevSecOps approach is a means of rein­for­cing secur­ity in the early phases of soft­ware devel­op­ment. It is by integ­rat­ing auto­mated and robust secur­ity tests into the CI/CD (Con­tinu­ous Integration/ContinuousDeployment) pipelines that the main vul­ner­ab­il­it­ies can be detec­ted and cor­rec­ted. This is par­tic­u­larly effect­ive, as it means that a cor­rec­tion can be made before the code reaches the pro­duc­tion envir­on­ment. This approach can lead to sub­stan­tial dif­fer­ences for gov­ern­ment-crit­ic­al applic­a­tions. For these types of applic­a­tion, a secur­ity flaw can have dir­ect con­sequences for digit­al sov­er­eignty¹².

5. Raise aware­ness amongst all parties involved and set up a ded­ic­ated com­mit­tee. The aim of this action is to ensure that every mem­ber of the organ­isa­tion has the neces­sary know­ledge of how the applic­a­tion works and how to take into account the patches repor­ted by the CERTs¹³. In this way, the application’s pro­tec­tion will be bet­ter taken into account and it will be pos­sible to pri­or­it­ise the most sig­ni­fic­ant devel­op­ments for the State. 

6. Rely on a mon­it­or­ing and intru­sion detec­tion sys­tem. SIEM (Secur­ity Inform­a­tion and Event Man­age­ment) is anoth­er tech­nic­al dimen­sion that is essen­tial when set­ting up robust sys­tems. SIEM solu­tions such as ELK Stack or Splunk are essen­tial for ana­lys­ing logs in real time, so as to effect­ively detect abnor­mal beha­viour and pat­terns, which may be the res­ult of inac­tion or a secur­ity breach. This integ­ra­tion of tools with auto­mated response sys­tems can reduce the time taken to react to a threat. This is a decis­ive aspect in lim­it­ing the poten­tial impact on the State’s crit­ic­al infra­struc­tures¹⁴.