Welke beveiligingslekken kun je negeren?
Niet elk beveiligingslek dat wordt ontdekt is te misbruiken door een aanvaller, maar hoe weet je nu welke lekken je direct moet patchen, en welke je kunt negeren? "Onderzoekers zijn er niet over uit welke aankondigingen echt tot te misbruiken lekken leiden," zegt onderzoeker Thomas Ptacek. Als het gaat om aankondigingen van een vendor, dan denkt men vaak dat de lekken eenvoudiger te misbruiken zijn, terwijl dit in het geval van een advisory van een onderzoeker moeilijker wordt geacht.
Ptacek schat dat 80% van alle aankondigde lekken te misbruiken is, en dat 10 tot 15 procent in echt iets gevaarlijks ontwikkeld kan worden. Volgens David Maynor zorgt niet elk lek ervoor dat bedrijven een nieuwe security tool moeten kopen of alles moeten laten vallen om te gaan patchen.
"Alleen omdat je een lek vindt, wil dat nog niet zeggen dat het ook te misbruiken is. Niet alle software lekken zijn beveiligingslekken, en alleen omdat een aanvallers misbruik van een lek kan maken, betekent dit nog niet dat hij er schade mee kan doen." Wat dat betreft is er geen eenduidige oplossing wat bedrijven wel en niet moeten patchen. "Ondernemingen moeten bij elke advisory van het ergste uitgaan," gaat Ptacek verder. Maynor voegt er nog aan toe dat het nooit kwaad kan om patches te installeren.
Die situaite-bokito is een mooi voorbeeld van
beveiligingslekken negeren.
Het personeel van die dierentuin waarschuwde de bezoekers al
dat ze de aap niet moesten uitdagen, omdat ze diep in hun
hart wisten dat ze een klein beveiligingslek hadden.
Alleen was de kans heel klein dat die debiele aap dat
beveiligingslek zou uit buiten. En waarschijnlijk zou het
dan te veel kosten om het te dichten.
Maarja tja, toch wist die aap uiteindelijk uit te breken. En
dat gaat Blijdorp meer kosten, dan het dichten van dat
beveiligingslek.
Als ik hoofd beveiliging was geweest in Blijdorp, dan had
die aap nooit kunnen uitbreken.
tja, jij bent niet het hoofd beveiliging in Blijdorp helaas, hierdoor zag de aap
toch kans om te ontsnappen.
Ik begrijp niet goed waarom iemand een dergelijke stelling durft in te
nemen. Vroeger toen ik op school zat wist ik ook precies hoe zaken zouden
moeten zijn, daarna ontdek je dat iets simpels als het verbreden van een
waterwering (grachtje in de dierentuin) toch best wel wat voeten in de
aarde heeft en niet ineens kan worden uitgevoerd. Denk aan tijdelijke
afrastering van de verblijven op een veilige manier, kost geld en tijd,
graafwerkzaamheden die 'het aanzien van het verblijf' aantasten en dus
indirect ook omzet en dus geld kunnen kosten.
Voor dergelijke types geld toch altijd het verhaal van het kalf en de put.
Wees er nou niet zo trots op dat je wel weet hoe het hoord. daar zijn er
meer van.
Mijns inziens ligt het o.a. aan:
Wat voor data wil je beveiligen, patienten gegevens van een ziekenhuis zijn
belangrijker dan je postzegel verzameling die je met de wereld wil delen.
Wat zijn de gevaren van de vulnerabilty ( volledig access op je server en
netwerk of het tijdelijk niet bereikbaar zijn van je webspace)
Hoeveel werk en hoe moeilijk is het om via het lek binnen te dringen.
Het antwoord op dit onderwerp is voor iedereen dus anders.
wordt bij het accepteren van een lager beveiligingsniveau.
Als die kosten-baten-analyse niet nodig zou zijn, dan koos iedereen toch
voor een systeem, dat niet overgenomen kan worden door derden of door
derden kan worden vervuild.
producten die ik zelf gebruik. Overige lekken kunnen
interessant zijn, maar voor mij niet relevant.
Dan kijk ik naar de ernst van de lekken. De ernstigste lees
ik door om te bepalen:
- of het lek in mijn situatie gevaarlijk kan zijn,
- of er een patch beschikbaar is (een patch voor een Fedora
Firefox-rpm is er meestal later dan de patch van Firefox
zelf) en
- of er een workaround is.
Heel veel lekken en fouten treden niet altijd in elke
situatie op. Daarom kan je er moeilijk iets algemeens over
zeggen.
In principe had er niet eens gegraven te hoeven worden, ze
konden het ook low-budget doen, door bijvoorbeeld nog elders
aan de overkant van het water, een paar lijntjes schrikdraad
extra te plaatsen.
Dat schrikdraadje wat je op de televisie zag, notabene in
het midden van die gracht, zag er wel heel erg armoedig
uit.
Lekker makkelijk om kritiek te hebben, als je niet gehinderd
wordt door enige kennis van zaken. Er lag schrikdraad, en
tot nu toe was die afdoende gebleken. Het feit dat er 1 aap
zo sterk is gebleken dat die ene schrikdraad niet meer
voldoende is, zegt meer over die aap dan over de beveiliging
of het gebrek eraan.
Maar zoals altijd: beste stuurlui en wal en dergelijke.
Terug on-topic:
Ik vind het nogal naief om te roepen dat niet alle
beveiligingslekken gedicht hoeven te worden, omdat er van
een aantal geen misbruik gemaakt zou kunnen worden. Het feit
dat er nu een lek is, waar nog geen misbruik van gemaakt kan
worden, wil niet zeggen dat er morgen, overmorgen of in de
nabije toekomst er geen misbruik van gemaakt kan worden.
Dit soort uitspraken geeft mensen een vals gevoel van
veiligheid: men krijgt het idee dat het allemaal wel meevalt
met de problemen en lekken die brakke software met zich
meebrengt, en zal minder snel geneigd zijn om patches te
installeren omdat dat toch alleen maar lastig is...
Kortom: als je een lek hebt, moet je die patchen (uiteraard
na testen, zoals eerder geopperd).
Nee, die hoofdbeveiliging moet op nonactief worden gesteld, als hij dit probleem niet aan de kaak had gesteld bij de directie.
Gek genoeg geldt dit ook in onze business. Als ze met een site 5 miljoen kunnen verdienen, het kost een miljoen om te maken en nog eens 2 miljoen om 'm fatsoenlijk te beveiligen. Het risico dat het gebeurd is klein en als het gebeurd kopen ze het met een miljoen af.
Simpel rekensommetje.. 4 miljoen winst zonder beveiliging en geen probleem. 3 Miljoen winst zonder beveiliging als het mis gaat. En maar 2 miljoen als alles beveiligd zou zijn. Een beetje, op winst gerichte, directie hoeft hier niet lang over na te denken.
Dan kun je best principes hebben maar ik vrees dat je dan toch aan het korste eind trekt. Je zult het dan ook niet lang volhouden in deze business. Van principes kan ik m'n vaste lasten niet betalen in ieder geval. Van m'n salaris wel.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
