De overeenkomsten tussen ISDN en cloud misconfiguraties

Midden jaren 90 werd ISDN als technologie geïntroduceerd. Een technologie die veel betekent heeft voor de ontwikkeling van het internet. Een technologie trouwens, welke het verbazingwekkend lang heeft volgehouden.

Gegevensoverdracht via de telefoonlijn was destijds baanbrekend. Nu is de technologie dusdanig verouderd, dat in 2017 bekend is gemaakt dat de telecomaanbieders gaan stoppen met het aanbieden van ISDN. Er zijn inmiddels natuurlijk goedkopere en snellere oplossingen op de markt, zoals DSL en glasvezel internet of VoIP.

De meeste bedrijven en consumenten maken al lang geen gebruik meer van ISDN. Maar er zijn apparaten en systemen die dat nog wel doen. Denk bijvoorbeeld aan oude pinautomaten, alarmsystemen, in liften en faxen (nog zo’n technologie welke zijn langste tijd gehad heeft).

Ik begin dit blog over ISDN, omdat deze technologie in het bouwen van netwerken op branch locaties veelal werd gebruikt als backup of als ad hoc data verbinding naast de voice communicatie. Ook werden pinttransacties slim over het beschikbare D-kanaal mogelijk waardoor optimaal gebruik werd gemaakt van de ISDN technologie. Even voor het geheugen, dit was de tijd dat je voor een internetverbinding thuis nog afhankelijk was van je vaste telefoonlijn (Plain Old Telephone System [POTS]) en modem.

Tel daarbij op de overige nadelen van analoog, zoals verlies van audiokwaliteit bij telefonie, een trage verbindingsopbouw en het feit dat bij een internetverbinding niet kon worden getelefoneerd.

Dankzij de ISDN techniek had je twee digitale kanalen over een enkele lijn met verschillende telefoonnummers. ISDN werd daarmee als dé opvolger van POTS en dial-up modems gezien.

Onvoorziene kosten

Het verreken model ging per maandabonnement met daar bovenop de belkosten (per sessie een opstartprijs en een prijs per minuut dacht ik). Omdat, zoals aangegeven, ISDN gebruikt werd voor back-up of data connecties (al dan niet ad-hoc) was een correcte configuratie van de routers (met ISDN interface) kritisch.

Zo herinner ik mij heftige klantdiscussies na hoge ‘spookrekeningen’ (en dat zagen ze vaak pas achteraf per maand of kwartaal), omdat de configuratie van de gateway niet goed was, of omdat de beoogde ad-hoc verbinding toch zeer frequent of permanent gebruikt werd doordat er verkeer (bijvoorbeeld een ping of andere heartbeat) werd aangeboden waarvoor een connectie opgebouwd werd. Of de back-up lijn schakelde wel op, maar nooit meer af. Dit kon enerzijds serieus in de papieren lopen, maar ook zorgde dit voor een discussie over de oorzaak en schuldvraag.

Was het de onbekendheid van de nieuwe techniek, was het onzorgvuldigheid van de configuratie, waren het de nieuwe mogelijkheden? Feitelijk maakt het niet zoveel uit, maar de conclusie is dat kansen en risico’s dicht bij elkaar lagen.

Onvoorziene risico’s (en kosten)

Met de snelle adoptie van de cloud technologieën gebeurd in mijn ogen voor een deel weer hetzelfde als in de jaren 90.

Cloudomgevingen zijn complex en bestaan uit duizenden assets van verschillende leveranciers, waarbij ze elk verschillende standaardinstellingen en methoden hebben voor het instellen van autorisaties. Vaak is er verwarring over de grenzen van beveiliging tussen interne organisaties en cloudleveranciers. Waren cyberaanvallen in de jaren 90 nog afwezig, of veel onschuldiger, is dat nu wel anders en wordt iedere misconfiguratie in je architectuur vrijwel direct afgestraft.

Cloudomgevingen zijn ook zeer dynamisch en vereisen nieuwe benaderingen om cyberaanvallen te voorkomen. Cloudbeveiliging gaat over het sluiten van open ramen en deuren vanwege zwakke autorisaties en verkeerde configuraties.

Een voorbeeld van een vergelijkbare cloud bedreiging is de zogenaamde Denial-of-wallet aanval. Deze richt zich op cloudtoepassingen en microservices met als doel het gebruik van resources veel verder te brengen dan het toegewezen budget, wat uiteindelijk resulteert in een denial-of-service-situatie.

Verkeerde configuraties en zwakke machtigingen vormen de grootste bedreiging voor cloudomgevingen. Een gebruiker of een team kan eenvoudig instellingen opgeven die onvoldoende beveiliging bieden voor hun cloudgegevens, omdat de cloudomgeving zeer dynamisch is. Er is weinig tot geen standaardisatie tussen verschillende cloudplatforms. Fouten zijn vaak onbedoeld, zoals het hebben van eenvoudige of standaard machtigingen voor DevOps of ontwikkelteams en vervolgens vergeet men de machtigingen te wijzigen nadat het systeem in productie is genomen.

Aangezien de grootste bron van kwetsbaarheden menselijke fouten kan zijn, vereist cloudbeveiliging opleiding en strenge inspectie om ervoor te zorgen dat configuratie pas geactiveerd worden nadat er volledig inzicht is in de risico’s.

Net als bij de komst van ISDN

Digitale transformatie brengt meer data naar de cloud en voegt nieuwe niveaus van flexibiliteit toe en verhoogt tegelijkertijd het tempo van innovatie. Tegelijkertijd heeft cloud computing echter nieuwe beveiligingsrisico’s geïntroduceerd. De traditionele aanpak van monitoring om te controleren op anomalieën is op zichzelf niet voldoende. Tegenwoordig moeten beveiligingsteams standaard zwakke machtigingen en verkeerde configuraties in de cloud voorkomen om het risico op een cyberaanval te verminderen.

Gelukkig zijn hiervoor goede tools in de markt verkrijgbaar welke voor multi-coud omgevingen de risico’s continue analyseren en het security beleid afdwingen. En natuurlijk ook oplossingen om cloudomgevingen veilig en efficiënt in te richten.