Voor het '2023 TruRisk Research Report' analyseerden onderzoekers meer dan 13 biljoen incidenten binnen het Qualys Cloud Platform. Zij kregen hiermee inzicht in kwetsbaarheden op apparaten, in de beveiliging van webapplicaties en in misconfiguraties van cloud-omgevingen en on-premise apparaten. De studie leverde vijf 'risicofeiten' op.
- Risicofeit #1 – Snelheid is essentieel om tegenstanders te slim af te zijn
De belangrijkste les hier is dat patches sneller geïmplementeerd moeten worden. Gemiddeld duurt het 30,6 dagen om ‘weaponized’ kwetsbaarheden te patchen. Weaponized betekent dat er een proof of concept bestaat waarmee een aanvaller deze kwetsbaarheid kan misbruiken. Cybercriminelen maken al binnen gemiddeld 19,5 dagen misbruik van ontdekte kwetsbaarheden. Beveiligingsteams staan dus op achterstand in hun strijd tegen aanvallers.
Omdat er continue nieuwe kwetsbaarheden in it-middelen aan het licht komen, moeten cio’s en ciso’s weten welke daarvan kritiek zijn (en welke niet) en waarom. Het is echter vaak tijdrovend en moeilijk om kwetsbaarheden toe te wijzen aan een met naam genoemde aanvaller (attribution). Gemiddeld is er na 95 dagen al een kwaadwillende persoon of groep actief met de kwetsbaarheid nadat deze is gepubliceerd en 74,3 dagen nadat deze is gepatcht. Bovendien blijkt dat attribution niet altijd leidt tot snellere patching.
- Risicofeit #2 – Automatisering is verschil tussen succes en mislukking
Uit het onderzoek blijkt dat automatisering van het patchproces de enige manier is om de voorsprong van cybercriminelen ongedaan te maken. Datagestuurde patchautomatisering vervangt handmatige (en dus tijdrovende en foutgevoelige) taken en zorgt ervoor dat bedreigingen minder lang de tijd hebben om schade aan te richten.
Het onderzoek laat ook zien dat geautomatiseerde patches 45 procent vaker en 36 procent sneller worden uitgevoerd dan handmatige patches. Automatisering is dus niet alleen handig; het is een belangrijke verdedigingsfunctie voor kritieke bedrijfsmiddelen. Geautomatiseerde patches hebben bovendien een gemiddelde reparatietijd van 25,5 dagen, terwijl handmatige patches 39,8 dagen in beslag namen. Bovendien is de patch-rate voor geautomatiseerde patches 73 procent, vergeleken met vijftig procent voor handmatige patches.
- Risicofeit #3 – Initial access brokers (iab’s) richten pijlen op wat organisaties negeren
Cybercriminelen hanteren de strategie van verdeel en heers. Sommigen van hen zijn gespecialiseerd in de back-end, waar bijvoorbeeld ransomware op grote schaal wordt ingezet. Anderen houden zich bezig met de front-end en richten zich op het binnendringen van kwetsbare it-middelen. Deze specialisten staan ook bekend als initial access broker (iab). Uit het onderzoek blijkt dat organisaties de kwetsbaarheden die iab’s misbruiken sneller moeten patchen.
Iab’s maken dankbaar gebruik van het feit dat kwetsbaarheden op veel plekken voorkomen. Zij nemen meestal randapparatuur op de korrel, maar benutten in feite elke mogelijkheid die snel en gemakkelijk toegang biedt naar het netwerk en de it-middelen van een organisatie. Iabs zoeken naar misconfiguraties zoals standaardwachtwoorden en verkrijgen hiermee toegang tot systemen. Zij proberen ook geldige inloggegevens te achterhalen, bijvoorbeeld door diefstal, aankoop, phishing-aanvallen en social engineering. Met geldige accountgegevens zijn zij succesvoller omdat ze hiermee nagenoeg alle beveiligingsmaatregelen omzeilen.
De belangrijkste les van hier is dan ook: geef prioriteit aan het patchen van iab-kwetsbaarheden. Dit geeft aanvallers geen kans om geld te verdienen en het beschermt kritieke it-middelen tegen ransomware en andere bedreigingen.
- Risicofeit #4 – Misconfiguraties komen nog steeds veel voor in webapplicaties
Volgens het onderzoek komen misconfiguraties nog steeds veel voor in webapplicaties. Dat brengt risico’s met zich mee, zowel voor de eigenaren van persoonsgegevens als voor de organisaties die deze opslaan en verwerken met onveilige webapplicaties.
De onderzoekers namen ook de bevindingen mee van de Qualys Web Application Scanner. Deze scant wereldwijd 370.000 webapplicaties en correleert de gegevens met de top tien van het Open Worldwide Application Security Project, een opensourceproject rond computerbeveiliging. De scans brachten meer dan 25 miljoen kwetsbaarheden aan het licht, waarvan een krappe derde betrekking heeft op misconfiguratie. Hierdoor kunnen cybercriminelen malware verspreiden via ongeveer 24.000 webapplicaties.
Bij misconfiguraties gaat het om verkeerd ingestelde controles voor het beschermen van webapplicaties. Dit is het niet wijzigen van standaardinstellingen voor machtigingen of wachtwoorden. Ook past men vaak instellingen niet aan die het mogelijk maken dat te veel informatie gedeeld wordt tussen applicaties.
Daarnaast kunnen webapplicaties die misbruikt worden ook zelf ingezet worden als instrument van aanvallers via webmalware. Een onderzoek van Qualys bracht bijna 65.000 gevallen van malware aan het licht in de dataset van 200.000 webapplicaties. Hierbij voegden aanvallers aangepaste broncode toe om browsers van klanten te infecteren en zodoende betaalkaartgegevens te achterhalen, inloggegevens te stelen, cryptovaluta te delven en gebruikers naar sites op een zwarte lijst te sturen.
De les van hier is dat cio’s en ciso’s serieus werk moeten maken van een oud en hardnekkig probleem: onveilige webapplicaties.
- Risicofeit #5 – Misconfiguraties in infrastructuur openen deur voor ransomware
Misconfiguraties zijn fouten in instellingen van apparaten en applicaties die onbedoeld door een interne partij worden gemaakt; ze vormen een groot deel van de zwakke plekken in webapplicaties en zijn een van de belangrijkste redenen voor datalekken.
Naast de instellingen van cloud-infrastructuren zoals Amazon Web Services, Google Cloud Platform en Microsoft Azure, moeten cio’s en ciso’s ook aandacht hebben voor misconfiguraties binnen infrastructuren op locatie. De meest voorkomende misconfiguraties die in het rapport genoemd worden hebben betrekking op wachtwoordinstellingen, gebruikersmachtigingen en protocollen voor Windows-updates.
De les nu is dat sommige configuraties weliswaar standaard correct ingesteld zijn, maar vele dus niet. Het goede nieuws is dat een toenemend aantal organisaties bewust omgaat met configuratie-instellingen. De onderzoekers keken naar zestien instellingen die standaard verkeerd geconfigureerd zijn. In de helft van de gevallen pasten organisaties deze instellingen proactief aan om veiliger te zijn.
Een goed voorbeeld doet goed volgen, hopelijk.
Vijf risicofeiten.
en open deuren.
1 billion is overigens een miljard en geen biljoen.
Open deur omdat als je bijvoorbeeld wacht met patchen je een langere periode kwetsbaar bent 🙂
Of als patchen veel werk kost, dat het dan vaak eerder wordt uitgesteld 🙂
Keuzes, want automatiseren is ook werk.
Moeilijk om het makkelijker te maken.
En dan weer consultant nodig als het kapot gaat.
Een gewogen risico is de kans afgezet tegen de impact, verhaal is namelijk heel helder als het gaat om de feiten. En patchen is een risico doordat het om een verandering gaat welke tot een uitval van diensten kan leiden. Zo is er nogal wat functionaliteit geprogrammeerd op ‘security flaws’ in open source libraries om even wat zout in een open wond te wrijven. En de ‘bugdoors’ schijnen er nog weleens opzettelijk in gezet te worden volgens de eigenaar van GitHub waardoor de transparantie van open source ook alleen maar om een marketingverhaal gaat.
Volgens mij is het proces van code wijzigingen, dat je een voorstel doet voor het wijzigen.
Dat je daarna een merge request doet, waarbij de wijziging regel voor regel tegen de bestaande code wordt gecheckt door diegene die zich verantwoordelijk voelt voor de code. Een soort moderator.
Natuurlijk zitten boeven overal, maar doen die ook de merges, dus de foute code na review in de baseline zetten, zodat die beschikbaar is voor gebruikers van die code..
Voorbeelden van die “functionaliteit geprogrammeerd op ‘security flaws'” of bugdoors ?
Da’s de theorie aangaande een formeel change management want als de druk opgevoerd wordt dan worden veranderingen ook nog weleens doorgedrukt. Het probleem met een review op de code is het gebrek aan resources want er zijn voldoende voorbeelden van ‘security flaws’ en ‘bugdoors’ in code. De eigenaar van GitHub wijst vooral op de open source libraries welke onderdeel worden van een oplossing. Want een statistisch risico is meer code, minder mensen en een grote druk om te leveren aangezien de moderator niet meer de afdeling ICT is. De business dicteert de klok als het om zoiets als ‘agile’ gaat en een slimme CI(S)O zal dat risico terug managen.
Bij nader inzien zijn er natuurlijk zat voorbeelden van “functionaliteit geprogrammeerd op ‘security flaws'”.
Gebruik je een library waarin een vulnerability zit krijg je die mee en die wordt niet reviewed, alleen als het een review betreft van de library zelf.
Maar geef maar voorbeelden van bugdoors (an intentional backdoor implemented by a product maker/vendor when they believe they need backdoor access on demand) in opensource en dat die ook misbruikt worden.
Het mooie van pure opensource t.o.v. closedsource is dat de business niet dicteert en dat je niet stiekem backdoors kunt inbouwen.
Je kunt zien wie wanneer welke code in welke release heeft gemaakt of gewijzigd.
De beheerders die de code gebruiken houden de CVEs is in de gaten en eigenaar van de code is niet anoniem en approved de mergerequest.
Regelmatig updaten tbv de patch loont dus en een OTAP straat ook mbt het testen of het in jouw omgeving ook blijft werken.
Ja en zomaar code gebruiken die je ergens vandaan plukt is natuurlijk een risico. Lijkt me niet dat business dat wil.
Fijn dat er ingezien wordt dat er zat voorbeelden zijn van functionaliteit geprogrammeerd op ‘flaws in security’ want dan hoef ik niet meer het voorbeeld van Heartbleed te noemen en lessen die eruit getrokken werden. Door het staan op de schouders van reuzen worden lemen voeten niet altijd goed gezien. Want review en onderhoud zijn twee verschillende dingen als we kijken naar alle open maar verweesde code.
Voorbeelden van ‘bugdoors’ zijn er genoeg want meer transparantie in de code maar minder tijd om deze te controleren opent een deur naar services. Risicofeit #6 gaat om de resources, de business wil resultaat!
Een hoop FUD, maar geen voorbeelden van bugdoors in opensourcecode dus. Net zoals weapons of mass destruction wat lastig te vinden waren.
Wel een voorbeeld van een patchbare vulnerability. Euh, toch maar patchen dan ?
Het enige dat door mij ingezien wordt is de code 🙂
Voorbeelden genoeg van ‘bugdoors’ want niet zo lang geleden hadden we Solarwinds als het om de malafide code voor toegang tot systemen gaat, wat kan er mis gaan als hackers toegang tot de source code krijgen?
Een vertrouwde bron met vergiftigd water is als weapons of mass destruction want 99,999% consumeert open source als executable code. De praktijk is dan ook weerbarstiger dan de theorie want uiteindelijk kun je beter naar het netwerk kijken dan de code.
Een hoop FUD, maar geen voorbeelden van bugdoors in opensourcecode dus.
https://thenewstack.io/solarwinds-the-worlds-biggest-security-failure-and-open-sources-better-answer/
https://www.linuxfoundation.org/blog/blog/preventing-supply-chain-attacks-like-solarwinds :
samenvattend:
– Solarwindws softare is geen opensource
– geen review want de aanvallers hadden control over de build environment.
– geen transparantie in het proces na ontdekking kwetsbaarheid
– MS windows
Je komt dus met 1 voorbeeld en dat is niet juist.
Het laat precies de nadelen van closed source code zien.
Bij opensource code gaat het gaat om aantal partijen :
– eigenaars van de code. Die schrijven zelf en reviewen merge requests.
– de contributors van code. Die schrijven en een sturen merge requests naar eigenaars mbt evt wijzigingen. Features en patches.
– de gebruiker van de code. Die bouwt of installeert het programma. Die bepaalt in hoeverre die de code vertrouwt
– de gebruiker van het programma. De bepaalt in hoeverre die het programma vertrouwt.
De gebruikers van code en programma kijken normaalgesproken niet intensief naar de broncode.
Daarvoor zijn ze gebruiker.
Ook al is de code open, ze beschouwen het voor grootste deel als blackbox.
Daarom is gedrag monitoren mbt resources en netwerk welkome aanvulling.
Net als kwetsbaarheden in de gaten houden.
De theorie zegt niet dat iedereen elke regel code moet kunnen begrijpen, maar geeft een best practice voor de gebruikers.
Regelmatig patchen op basis van publiek bekende kwetsbaarheden.
Niets mis mee.
“Gebruik je een library waarin een vulnerability zit krijg je die mee en die wordt niet reviewed, alleen als het een review betreft van de library zelf.” – reactie op 6 juli 2023 om 12:44
Linus’s Law van “Given enough eyeballs, all bugs are shallow” gaat blijkbaar niet op want Dino zegt feitelijk dat ’trusted code’ gebaseerd is op een aanname. Hoe fijn dat Dino het zelf al heeft over transparantie in het proces in plaats van de code want de welkome aanvulling (tip?) om het gedrag/netwerk te bewaken gaat vooral om het erkennen van de risico’s. De eyeballs die ‘bugdoors’ ontdekken zijn tenslotte vaak de security onderzoekers.
Oja, de eigenaar van de code bepaalt middels een licentie wat de gebruiker er mee mag doen. En het gekozen governance model stelt regels over de contributie, het meritocratisch model is als een bazaar want veel open source projecten hebben het karakter van een hobbyclub wat leidt tot een zeer hoge frequentie aan patches waarvan vaak onduidelijk is of het om bugfixes of features gaat. En het is goed dat CVE in de gaten gehouden wordt maar uiteindelijk blijf je afhankelijk van de eigenaar van de code zoals we zagen met Heartbleed.
Theorie en praktijk had Dino het 6 juli 2023 om 12:44 ook over een formeel change proces, best practices met OTAP straten leren me dat je bugfixes en features van elkaar moet scheiden. De security fixes zijn weer een andere spoor als we kijken naar het gewogen risico want het is de business die zorgt voor de inkomsten als we kijken naar een change window. Want de downtime telt, gepland of ongepland als ik kijk naar de service levels in diensten met boeteclausules.