Er is geen software zonder bugs, toch? Hoewel dit een algemeen gevoel is, gaan we ervan uit dat software geen fouten bevat in ons dagelijkse digitale leven. We vertrouwen erop dat identiteitsproviders (IDP's) authenticatie goed uitvoeren, besturingssystemen perfect voldoen aan hun specificaties en financiële transacties altijd uitvoeren zoals bedoeld. Sterker nog, we vertrouwen software met onze fysieke veiligheid door op vliegtuigen gaan, het besturen van een auto die actief corrigeert hoe we ons aan de rijbaan houden of onze afstand tot de auto voor ons, of het ondergaan van bepaalde operaties. Wat maakt dit mogelijk? Of anders gezegd, waarom vallen er geen vliegtuigen uit de lucht door slechte software?

Softwarekwaliteitsborging leent van wetenschappelijke en technische tools. Een manier om de kwaliteit van software te waarborgen en te verbeteren, is door er bekendheid aan te geven en zoveel mogelijk mensen te stimuleren om te proberen het te breken.

Een andere is het gebruik van ontwerppatronen of raamwerken met een goede architectuur die geworteld zijn in engineering. Hoewel bijvoorbeeld niet elk softwareproject onder hetzelfde controleniveau kan worden geplaatst als de Linux-kernel, die al tientallen jaren onder de loep wordt genomen, kunnen softwareprojecten de broncode openen om kritisch onderzoek uit te nodigen of code indienen voor audits in de hoop een deel van de de veiligheidsgaranties.

En natuurlijk wordt er getest. Of het nu statisch, dynamisch of real-time is, uitgevoerd door de ontwikkelaar of door een toegewijd team, testen is een belangrijk onderdeel van softwareontwikkeling. Bij kritieke software is testen meestal een geheel apart project dat wordt uitgevoerd door een apart team met specifieke expertise.

Testen is goed, maar pretendeert niet volledig te zijn. Er zijn geen garanties dat we alle bugs hebben gevonden, omdat we niet weten welke bugs we niet kennen. Hebben we al 99% van de Linux-kernelbugs gevonden? 50%? 10%?

De 'absolute' bewering

Het onderzoeksveld van formele methoden zoekt naar manieren om u te verzekeren dat er geen bugs zitten in een bepaald stuk software, zoals uw effectenmakelaar of certificeringsinstantie. Het basisidee is om software te vertalen naar wiskunde, waar alles goed gedefinieerd is, en vervolgens een echt bewijs te leveren dat de software foutloos werkt. Op die manier kunt u er zeker van zijn dat uw software foutloos is, net zoals u er zeker van kunt zijn dat elk getal kan worden ontleed tot een vermenigvuldiging van priemgetallen. (Merk op dat ik niet definieer wat een bug is. Dit zal een probleem blijken te zijn, zoals we later zullen zien.)

Formele methodetechnieken worden al lang gebruikt voor kritieke software, maar ze waren buitengewoon reken- en inspanningsintensief en werden daarom alleen toegepast op kleine stukjes software, zoals een beperkt deel van chipfirmware of een authenticatieprotocol. In de afgelopen jaren zijn geavanceerde stellingbewijzen zoals Z3 en pik hebben het mogelijk gemaakt om deze technologie in een grotere context toe te passen. Er zijn nu formeel geverifieerd programmeertalen, besturingssystemen en samenstellers die 100% gegarandeerd werken volgens hun specificaties. Het toepassen van deze technologieën vereist nog steeds zowel geavanceerde expertise als enorm veel rekenkracht, waardoor ze voor de meeste organisaties onbetaalbaar zijn.

Grote cloudproviders voeren formele verificatie uit van hun fundamentele stapels om een ​​hoog niveau van beveiligingsgarantie te bereiken. Amazone en Microsoft hebben toegewijde onderzoeksgroepen die samenwerken met technische teams om formele verificatiemethoden op te nemen in kritieke infrastructuur, zoals opslag of netwerken. Voorbeelden zijn onder meer AWS S3 en EBS en Azure-blockchain. Maar het echt interessante feit is dat er de afgelopen jaren cloudproviders zijn geweest proberen commoditiseren formele verificatie om aan hun klanten te verkopen.

Misconfiguratie definitief oplossen?

Vorig jaar bracht AWS twee functies uit die gebruikmaken van formele verificatie om problemen aan te pakken die hun klanten al lang hebben geplaagd, namelijk netwerk- en verkeerde configuratie van identiteits- en toegangsbeheer (IAM).s. Netwerktoegang en IAM-configuraties zijn complex, zelfs voor één account, en die complexiteit neemt drastisch toe in een grote organisatie met gedistribueerde besluitvorming en governance. AWS pakt dit aan door zijn klanten eenvoudige controles te geven - zoals "S3-buckets mogen niet worden blootgesteld aan internet" of "Internetverkeer naar EC2-instanties moet door een firewall gaan" - en door te garanderen dat ze in elk mogelijk configuratiescenario worden toegepast.

AWS is niet de eerste die het misconfiguratieprobleem aanpakt, zelfs niet voor AWS-specifieke problemen zoals open S3-emmers. Leveranciers van Cloud Security Posture Management (CSPM) pakken dit probleem al een tijdje aan, analyseren de configuratie van Virtual Port Channel (VPC) en IAM-rollen en identificeren gevallen waarin privileges te laks zijn, beveiligingsfuncties niet correct worden gebruikt en gegevens kunnen worden vrijgegeven naar het internet. Dus, wat is er nieuw?

Nou, hier komt de absolute garantie om de hoek kijken. A CSPM-oplossing werkt door een bekende-slechte of bekende-goede lijst met verkeerde configuraties te maken, soms context uit uw omgeving toe te voegen en dienovereenkomstig resultaten te produceren. Netwerk- en IAM-analyzers werken door elk potentieel IAM- of netwerkverzoek te onderzoeken en te garanderen dat ze niet zullen resulteren in ongewenste toegang volgens uw specificatie (zoals "geen internettoegang"). Het verschil zit in de garanties over valse negatieven.

Hoewel AWS beweert dat het op geen enkele manier iets heeft gemist, zeggen CSPM-leveranciers dat ze altijd op zoek zijn naar nieuwe verkeerde configuraties om te catalogiseren en te detecteren, wat een erkenning is dat ze deze verkeerde configuraties niet eerder hebben ontdekt.

Enkele tekortkomingen van formele verificatie

Formele verificatie is geweldig voor het vinden van goed gedefinieerde problemen, zoals geheugenbeveiligingsproblemen. Het wordt echter moeilijk om logische bugs te vinden, omdat daarvoor moet worden gespecificeerd wat de code eigenlijk zou moeten doen, en dat is precies wat de code zelf doet.

Om te beginnen vereist formele verificatie het specificeren van goed gedefinieerde doelen. Hoewel sommige doelen, zoals het voorkomen van toegang tot internet, eenvoudig genoeg lijken, zijn ze dat in werkelijkheid niet. De documentatie van de AWS IAM-analyzer heeft een hele sectie definiëren wat "openbaar" betekent, en het zit vol kanttekeningen. De garanties die het biedt zijn slechts zo goed als de wiskundige beweringen die het heeft gecodeerd.

Er is ook de kwestie van dekking. AWS-analyzers dekken slechts een paar grote AWS-services. Als u verkeer naar uw netwerk leidt via een uitgaand verbindingskanaal, zou de analysator het niet weten. Als een service toegang heeft tot twee IAM-rollen en deze kan combineren om te lezen uit een vertrouwelijke openbare bucket en naar een openbare bucket te schrijven, zou de analysator het niet weten. Desalniettemin biedt formele verificatie voor een goed gedefinieerde subset van het misconfiguratieprobleem sterkere garanties dan ooit tevoren.

Om terug te komen op de hierboven gestelde relatieve voordeelvraag, het verschil is dat de IAM en netwerkanalysator beweren dat de lijst met gedetecteerde problemen volledig is, terwijl CSPM beweert dat de lijst elke misconfiguratie dekt die tegenwoordig bekend is. Hier is de belangrijkste vraag: moet het u iets kunnen schelen?

Moeten we ons zorgen maken over absolute garanties?

Overweeg het volgende scenario. U bezit een CSPM en kijkt naar het AWS-netwerk en de IAM-analyzer. Als je de resultaten van de twee vergelijkt, realiseer je je dat ze exact dezelfde problemen hebben geïdentificeerd. Na enige moeite lost u elk probleem op die lijst op. Als u alleen op uw CSPM vertrouwt, zou u het gevoel hebben dat u zich nu op een goede plek bevindt en zou u beveiligingsmiddelen elders kunnen inzetten. Door AWS-analyzers aan de mix toe te voegen, weet je nu — met AWS-garantie — dat je goed zit. Zijn dit dezelfde resultaten?

Zelfs als we het voorbehoud van formele verificatie negeren en aannemen dat het 100% van de problemen oplost, zou het meten van de voordelen ten opzichte van op detectie gebaseerde services zoals CSPM een oefening zijn voor elke individuele organisatie met haar eigen beveiligingsrisicobereidheid. Sommigen zullen deze absolute garanties grensverleggend vinden, terwijl anderen waarschijnlijk vasthouden aan bestaande controles.

Deze vragen zijn niet uniek voor CSPM. Dezelfde vergelijkingen kunnen worden gemaakt voor SAST/DAST/IAST-tools voor het testen van webapplicaties en formeel geverifieerde software, om maar een voorbeeld te noemen.

Ongeacht de keuzes van individuele organisaties, zou een opwindend neveneffect van deze nieuwe technologie een onafhankelijke manier zijn om te beginnen met het meten van de fout-negatieve percentages van beveiligingsoplossingen, waardoor leveranciers worden aangezet om beter te worden en ze duidelijk bewijs krijgen waar ze moeten verbeteren. Dit is op zichzelf al een enorme bijdrage aan de cyberbeveiligingsindustrie.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://www.darkreading.com/edge-articles/are-100-security-guarantees-possible-