Is the dependence of governments on digital giants a problem?

The recent crit­i­cal fail­ure of Win­dows servers, linked to Crowdstrike’s Fal­con EDR¹, has high­light­ed the risks asso­ci­at­ed with the State’s depen­dence on pri­vate 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 dig­i­tal ser­vices with­in the State must be sub­ject to a ben­e­fit-risk analy­sis designed to ensure that the gain in effi­cien­cy out­weighs the con­ces­sions in terms of sovereignty.

The sov­er­eign­ty of a State is its abil­i­ty to guar­an­tee its inde­pen­dence from oth­er States. It requires the abil­i­ty to have at its dis­pos­al the human, mate­r­i­al and tech­no­log­i­cal resources and any oth­er com­po­nent need­ed to pro­duce the nation’s vital goods and ser­vices. This capac­i­ty is judged either at a sys­temic lev­el or at the lev­el of each pub­lic pol­i­cy. Sov­er­eign­ty cov­ers food, finance, mil­i­tary, and now dig­i­tal issues, which are com­mon to all these areas.

Dig­i­tal sov­er­eign­ty con­cerns many aspects, the main ones being³,⁴:

• Dig­i­tal assets, since it is nec­es­sary to have basic equip­ment gen­er­at­ed with­out secu­ri­ty risk (fibres, anten­nas, servers, fire­walls, routers, etc.) to build a trust­ed infor­ma­tion system.

• Dig­i­tal ser­vices, because it is essen­tial to be able to col­lect, process and return infor­ma­tion secure­ly to car­ry out the State’s sov­er­eign func­tions (dig­i­tal iden­ti­ty, cri­sis man­age­ment, col­lec­tion of tax­es and social secu­ri­ty con­tri­bu­tions, etc.).

Using non-gov­ern­ment solu­tions means that solu­tions already devel­oped else­where can be made avail­able more quick­ly, enabling the gov­ern­ment to focus its dig­i­tal efforts on its core busi­ness. This is often done for rea­sons of effi­cien­cy and economies of scale, since a pro­pri­etary or open-source solu­tion is some­times used by thou­sands or mil­lions of oth­er organ­i­sa­tions. Exam­ples include text or spread­sheet edi­tors (var­i­ous Office suites), pay­roll 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 test­ed and ready to use. Cre­at­ing an inter­nal solu­tion for the admin­is­tra­tion would be very cost­ly and prob­a­bly unsuit­able for man­ag­ing a com­mon dig­i­tal requirement.

The acqui­si­tion of equip­ment via ser­vices also makes it pos­si­ble to meet needs that would require very sub­stan­tial invest­ment by the gov­ern­ment. And with­out being able to eas­i­ly ensure eco­nom­ic oppor­tu­ni­ties. This is par­tic­u­lar­ly true when it comes to pur­chas­ing com­put­ers, print­ers, stor­age bays or net­work equip­ment. These pur­chas­es offer a guar­an­tee of exper­tise and know-how in rel­a­tive­ly stan­dard com­po­nents, as well as the pos­si­bil­i­ty of using ded­i­cat­ed dig­i­tal assis­tance. This approach offers excel­lent effi­cien­cy, pro­vid­ed that the hard­ware used is suf­fi­cient­ly stan­dard­ised to be inte­grat­ed into the administration’s infor­ma­tion sys­tem and can be sup­ple­ment­ed by addi­tion­al ser­vices: appli­ca­tions, super­vi­sion, intru­sion detec­tion, etc.

The use of open-source solu­tions can also offer a sig­nif­i­cant capac­i­ty for inno­va­tion and respon­sive­ness, as it enables tools and appli­ca­tions to be inte­grat­ed rapid­ly at a mod­er­ate invest­ment cost. In addi­tion, this approach makes it pos­si­ble to attract dig­i­tal pro­files keen to con­tribute to the open-source com­mu­ni­ty and to offer cit­i­zens real trans­paren­cy about the tools used with­in the gov­ern­ment⁶.

The dig­i­tal solu­tions offered by com­mer­cial com­pa­nies com­ply with Euro­pean 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 inter­ests. To illus­trate this risk, we can cite the Patri­ot Act, cre­at­ed after the 2001 ter­ror­ist attacks, which enables the FBI to force com­pa­nies to give it access to their per­son­al data­bas­es, even for infor­ma­tion stored in Europe. Sim­i­lar­ly, the Cloud Act allows the Amer­i­can author­i­ties to access data stored by Amer­i­can com­pa­nies, 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­a­bil­i­ties; the cor­rec­tion of which may be delayed due to cost, lack of human resources or a vari­ety of oth­er rea­sons. These delays in main­tain­ing secu­ri­ty con­di­tions are not nec­es­sar­i­ly known to the com­pa­ny or are not imme­di­ate­ly com­mu­ni­cat­ed to cus­tomers. As a result, these solu­tions, which have not been devel­oped by the State, can cre­ate secu­ri­ty vul­ner­a­bil­i­ties with­out the State ser­vices nec­es­sar­i­ly being aware of them. The flaw linked to the use of Moveit trans­fer soft­ware had a major impact on Colorado’s Med­ic­aid pro­gramme⁸.

In addi­tion, the increas­ing use of dig­i­tal solu­tions devel­oped by pri­vate com­pa­nies may increase the State’s depen­dence on pri­vate tech­nolo­gies. This can give pri­vate com­pa­nies sig­nif­i­cant pow­er over how the state oper­ates and may lim­it its abil­i­ty to con­trol costs and ser­vices. The major change in pric­ing pol­i­cy for VMWare solu­tions is an exam­ple of this⁹.

Final­ly, the process of inte­grat­ing non-gov­ern­ment solu­tions into gov­ern­ment infor­ma­tion sys­tems requires par­tic­u­lar­ly rig­or­ous man­age­ment of the inter­faces between the var­i­ous com­po­nents, whether soft­ware and/or hard­ware. To this end, inter­op­er­abil­i­ty pro­to­cols must be pre­cise­ly defined and com­ply with the lat­est reg­u­la­tions and secu­ri­ty stan­dards, to avoid poten­tial exploitable vul­ner­a­bil­i­ties. A symp­to­matic exam­ple is the use of REST­ful APIs for inter-ser­vice com­mu­ni­ca­tions. This can enable seam­less inte­gra­tion and offers a lay­er of secu­ri­ty via authen­ti­ca­tion and encryp­tion pro­to­cols. The adop­tion of con­tain­er tech­nolo­gies such as Kuber­netes or Dock­er should also be care­ful­ly con­sid­ered. Con­tainer­i­sa­tion enables more agile and secure man­age­ment of appli­ca­tion deploy­ments¹⁰.

For the State to func­tion as effec­tive­ly as pos­si­ble, we believe it is impor­tant to strike a bal­ance between sov­er­eign­ty and effi­cien­cy. We there­fore pro­pose sev­er­al non-exhaus­tive guidelines:

1. Define the ser­vices that can be out­sourced and those that absolute­ly must be pro­vid­ed in-house. This approach con­cerns busi­ness appli­ca­tions (tax cal­cu­la­tions for the DGFiP (Direc­tion générale des Finances publiques), inter­nal secu­ri­ty appli­ca­tions for law enforce­ment agen­cies, etc.), as well as the nec­es­sary tech­ni­cal ser­vices (office automa­tion, inter­net brows­ing, oper­at­ing sys­tem, net­work oper­a­tion, etc.).

2. Iden­ti­fy the risks asso­ci­at­ed with out­sourc­ing and the mea­sures to be tak­en to mit­i­gate them. The aim is to define the actions to be tak­en 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­i­sa­tion­al pro­ce­dures for out­sourc­ing: the play­ers involved, con­trac­tu­al com­mit­ments, ver­i­fi­ca­tion pro­ce­dures, the abil­i­ty to ensure reversibil­i­ty, etc. These actions are part of the process of inte­grat­ing secu­ri­ty into projects and val­i­dat­ing them dur­ing the secu­ri­ty approval process¹¹.

3. Pay par­tic­u­lar atten­tion to MCO/MCS pro­ce­dures. The aim of this task is to ensure that inter­nal and exter­nal solu­tions are updat­ed reg­u­lar­ly, with a view to cor­rect­ing mal­func­tions and secu­ri­ty flaws. The quick­er patch­es are released, the quick­er appli­ca­tions are pro­tect­ed against known flaws and mal­func­tions. This approach ensures that the solu­tions used remain state-of-the-art.

4. Use a DevSec­Ops approach. At the heart of a nec­es­sar­i­ly inte­grat­ed process, adopt­ing a DevSec­Ops approach is a means of rein­forc­ing secu­ri­ty in the ear­ly phas­es of soft­ware devel­op­ment. It is by inte­grat­ing auto­mat­ed and robust secu­ri­ty tests into the CI/CD (Con­tin­u­ous Integration/ContinuousDeployment) pipelines that the main vul­ner­a­bil­i­ties can be detect­ed and cor­rect­ed. This is par­tic­u­lar­ly effec­tive, as it means that a cor­rec­tion can be made before the code reach­es the pro­duc­tion envi­ron­ment. This approach can lead to sub­stan­tial dif­fer­ences for gov­ern­ment-crit­i­cal appli­ca­tions. For these types of appli­ca­tion, a secu­ri­ty flaw can have direct con­se­quences for dig­i­tal sov­er­eign­ty¹².

5. Raise aware­ness amongst all par­ties involved and set up a ded­i­cat­ed com­mit­tee. The aim of this action is to ensure that every mem­ber of the organ­i­sa­tion has the nec­es­sary knowl­edge of how the appli­ca­tion works and how to take into account the patch­es report­ed by the CERTs¹³. In this way, the application’s pro­tec­tion will be bet­ter tak­en into account and it will be pos­si­ble to pri­ori­tise the most sig­nif­i­cant devel­op­ments for the State. 

6. Rely on a mon­i­tor­ing and intru­sion detec­tion sys­tem. SIEM (Secu­ri­ty Infor­ma­tion and Event Man­age­ment) is anoth­er tech­ni­cal 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 analysing logs in real time, so as to effec­tive­ly detect abnor­mal behav­iour and pat­terns, which may be the result of inac­tion or a secu­ri­ty breach. This inte­gra­tion of tools with auto­mat­ed response sys­tems can reduce the time tak­en to react to a threat. This is a deci­sive aspect in lim­it­ing the poten­tial impact on the State’s crit­i­cal infra­struc­tures¹⁴.