Is the dependence of governments on digital giants a problem ?

The recent cri­ti­cal fai­lure of Win­dows ser­vers, lin­ked to Crowdstrike’s Fal­con EDR¹, has high­ligh­ted the risks asso­cia­ted with the State’s depen­dence on pri­vate soft­ware. Although the French Minis­ter for the Armed Forces has sought to offer reas­su­rance², the fact remains that the use of com­mer­cial digi­tal ser­vices within the State must be sub­ject to a bene­fit-risk ana­ly­sis desi­gned to ensure that the gain in effi­cien­cy out­weighs the conces­sions in terms of sovereignty.

The sove­rei­gn­ty of a State is its abi­li­ty to gua­ran­tee its inde­pen­dence from other States. It requires the abi­li­ty to have at its dis­po­sal the human, mate­rial and tech­no­lo­gi­cal resources and any other com­ponent nee­ded to pro­duce the nation’s vital goods and ser­vices. This capa­ci­ty is jud­ged either at a sys­te­mic level or at the level of each public poli­cy. Sove­rei­gn­ty covers food, finance, mili­ta­ry, and now digi­tal issues, which are com­mon to all these areas.

Digi­tal sove­rei­gn­ty concerns many aspects, the main ones being³,⁴ :

• Digi­tal assets, since it is neces­sa­ry to have basic equip­ment gene­ra­ted without secu­ri­ty risk (fibres, anten­nas, ser­vers, fire­walls, rou­ters, etc.) to build a trus­ted infor­ma­tion system.

• Digi­tal ser­vices, because it is essen­tial to be able to col­lect, pro­cess and return infor­ma­tion secu­re­ly to car­ry out the State’s sove­rei­gn func­tions (digi­tal iden­ti­ty, cri­sis mana­ge­ment, col­lec­tion of taxes and social secu­ri­ty contri­bu­tions, etc.).

Using non-govern­ment solu­tions means that solu­tions alrea­dy deve­lo­ped elsew­here can be made avai­lable more qui­ck­ly, enabling the govern­ment to focus its digi­tal efforts on its core busi­ness. This is often done for rea­sons of effi­cien­cy and eco­no­mies of scale, since a pro­prie­ta­ry or open-source solu­tion is some­times used by thou­sands or mil­lions of other orga­ni­sa­tions. Examples include text or spread­sheet edi­tors (various Office suites), pay­roll or leave mana­ge­ment soft­ware (SAP, HR-Access, etc.)⁵ or e‑mail sen­ding and recei­ving soft­ware (Out­look, Thun­der­bird, etc.). This cross-func­tio­nal soft­ware is tried and tes­ted and rea­dy to use. Crea­ting an inter­nal solu­tion for the admi­nis­tra­tion would be very cost­ly and pro­ba­bly unsui­table for mana­ging a com­mon digi­tal requirement.

The acqui­si­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 govern­ment. And without being able to easi­ly ensure eco­no­mic oppor­tu­ni­ties. This is par­ti­cu­lar­ly true when it comes to pur­cha­sing com­pu­ters, prin­ters, sto­rage bays or net­work equip­ment. These pur­chases offer a gua­ran­tee of exper­tise and know-how in rela­ti­ve­ly stan­dard com­po­nents, as well as the pos­si­bi­li­ty of using dedi­ca­ted digi­tal assis­tance. This approach offers excellent effi­cien­cy, pro­vi­ded that the hard­ware used is suf­fi­cient­ly stan­dar­di­sed to be inte­gra­ted into the administration’s infor­ma­tion sys­tem and can be sup­ple­men­ted by addi­tio­nal ser­vices : appli­ca­tions, super­vi­sion, intru­sion detec­tion, etc.

The use of open-source solu­tions can also offer a signi­fi­cant capa­ci­ty for inno­va­tion and res­pon­si­ve­ness, as it enables tools and appli­ca­tions to be inte­gra­ted rapid­ly at a mode­rate invest­ment cost. In addi­tion, this approach makes it pos­sible to attract digi­tal pro­files keen to contri­bute to the open-source com­mu­ni­ty and to offer citi­zens real trans­pa­ren­cy about the tools used within the govern­ment⁶.

The digi­tal solu­tions offe­red by com­mer­cial com­pa­nies com­ply with Euro­pean and French regu­la­tions. But they may also com­ply with the regu­la­tions of other coun­tries on mat­ters rela­ting to the pro­tec­tion of natio­nal inter­ests. To illus­trate this risk, we can cite the Patriot Act, crea­ted after the 2001 ter­ro­rist attacks, which enables the FBI to force com­pa­nies to give it access to their per­so­nal data­bases, even for infor­ma­tion sto­red in Europe. Simi­lar­ly, the Cloud Act allows the Ame­ri­can autho­ri­ties to access data sto­red by Ame­ri­can com­pa­nies, even if this data is sto­red in Europe, contra­ry to the obli­ga­tions of the RGPD⁷.

Fur­ther­more, com­mer­cial or open-source solu­tions may have vul­ne­ra­bi­li­ties ; the cor­rec­tion of which may be delayed due to cost, lack of human resources or a varie­ty of other rea­sons. These delays in main­tai­ning secu­ri­ty condi­tions are not neces­sa­ri­ly known to the com­pa­ny or are not imme­dia­te­ly com­mu­ni­ca­ted to cus­to­mers. As a result, these solu­tions, which have not been deve­lo­ped by the State, can create secu­ri­ty vul­ne­ra­bi­li­ties without the State ser­vices neces­sa­ri­ly being aware of them. The flaw lin­ked to the use of Moveit trans­fer soft­ware had a major impact on Colorado’s Medi­caid pro­gramme⁸.

In addi­tion, the increa­sing use of digi­tal solu­tions deve­lo­ped by pri­vate com­pa­nies may increase the State’s depen­dence on pri­vate tech­no­lo­gies. This can give pri­vate com­pa­nies signi­fi­cant power over how the state ope­rates and may limit its abi­li­ty to control costs and ser­vices. The major change in pri­cing poli­cy for VMWare solu­tions is an example of this⁹.

Final­ly, the pro­cess of inte­gra­ting non-govern­ment solu­tions into govern­ment infor­ma­tion sys­tems requires par­ti­cu­lar­ly rigo­rous mana­ge­ment of the inter­faces bet­ween the various com­po­nents, whe­ther soft­ware and/or hard­ware. To this end, inter­ope­ra­bi­li­ty pro­to­cols must be pre­ci­se­ly defi­ned and com­ply with the latest regu­la­tions and secu­ri­ty stan­dards, to avoid poten­tial exploi­table vul­ne­ra­bi­li­ties. A symp­to­ma­tic example is the use of RES­T­ful APIs for inter-ser­vice com­mu­ni­ca­tions. This can enable seam­less inte­gra­tion and offers a layer of secu­ri­ty via authen­ti­ca­tion and encryp­tion pro­to­cols. The adop­tion of contai­ner tech­no­lo­gies such as Kuber­netes or Docker should also be care­ful­ly consi­de­red. Contai­ne­ri­sa­tion enables more agile and secure mana­ge­ment of appli­ca­tion deploy­ments¹⁰.

For the State to func­tion as effec­ti­ve­ly as pos­sible, we believe it is impor­tant to strike a balance bet­ween sove­rei­gn­ty and effi­cien­cy. We the­re­fore pro­pose seve­ral non-exhaus­tive guidelines :

1. Define the ser­vices that can be out­sour­ced and those that abso­lu­te­ly must be pro­vi­ded in-house. This approach concerns 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 enfor­ce­ment agen­cies, etc.), as well as the neces­sa­ry tech­ni­cal ser­vices (office auto­ma­tion, inter­net brow­sing, ope­ra­ting sys­tem, net­work ope­ra­tion, etc.).

2. Iden­ti­fy the risks asso­cia­ted with out­sour­cing and the mea­sures to be taken to miti­gate them. The aim is to define the actions to be taken to main­tain control of each out­sour­ced ser­vice within the State. To achieve this, it is advi­sable to define the orga­ni­sa­tio­nal pro­ce­dures for out­sour­cing : the players invol­ved, contrac­tual com­mit­ments, veri­fi­ca­tion pro­ce­dures, the abi­li­ty to ensure rever­si­bi­li­ty, etc. These actions are part of the pro­cess of inte­gra­ting secu­ri­ty into pro­jects and vali­da­ting them during the secu­ri­ty appro­val pro­cess¹¹.

3. Pay par­ti­cu­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 upda­ted regu­lar­ly, with a view to cor­rec­ting mal­func­tions and secu­ri­ty flaws. The qui­cker patches are relea­sed, the qui­cker appli­ca­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 Dev­Se­cOps approach. At the heart of a neces­sa­ri­ly inte­gra­ted pro­cess, adop­ting a Dev­Se­cOps approach is a means of rein­for­cing secu­ri­ty in the ear­ly phases of soft­ware deve­lop­ment. It is by inte­gra­ting auto­ma­ted and robust secu­ri­ty tests into the CI/CD (Conti­nuous Integration/ContinuousDeployment) pipe­lines that the main vul­ne­ra­bi­li­ties can be detec­ted and cor­rec­ted. This is par­ti­cu­lar­ly effec­tive, as it means that a cor­rec­tion can be made before the code reaches the pro­duc­tion envi­ron­ment. This approach can lead to sub­stan­tial dif­fe­rences for govern­ment-cri­ti­cal appli­ca­tions. For these types of appli­ca­tion, a secu­ri­ty flaw can have direct conse­quences for digi­tal sove­rei­gn­ty¹².

5. Raise awa­re­ness among­st all par­ties invol­ved and set up a dedi­ca­ted com­mit­tee. The aim of this action is to ensure that eve­ry mem­ber of the orga­ni­sa­tion has the neces­sa­ry know­ledge of how the appli­ca­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 prio­ri­tise the most signi­fi­cant deve­lop­ments for the State. 

6. Rely on a moni­to­ring and intru­sion detec­tion sys­tem. SIEM (Secu­ri­ty Infor­ma­tion and Event Mana­ge­ment) is ano­ther 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 ana­ly­sing logs in real time, so as to effec­ti­ve­ly detect abnor­mal beha­viour 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­ma­ted res­ponse sys­tems can reduce the time taken to react to a threat. This is a deci­sive aspect in limi­ting the poten­tial impact on the State’s cri­ti­cal infra­struc­tures¹⁴.