Cloud gebaseerde oplossingen tegen ddos aanvallen versus privacy clienten


  • Bijna aan de top
  • 204 reacties
Op het onderwerp van dit topic werd ik gisteren getriggered door een tweakers topic.

Het topic haalde de afhankelijkheid aan van 16 Europese banken van een aanbieder die oplossingen aanbiedt om ddos aanvallen te pareren. Daarnaast stond binnen de tweakers gemeenschap een discussie over de wenselijkheid dat dergelijke oplossingen regelmatig cloud gebaseeerd zijn opgezet. De consequentie hiervan kan zijn (dit is kort door de bocht) dat onze transactiegegevens, voordat ze in het SNS domein en in de database van de SNS bank terchtkomen, eerst het domein van de cloudaanbieder passeren.

Ten eerste vond het CPB (de organisatie van wie het rapport werd aangehaald) het onwenselijk dat meerdere (Nederlandse) banken zo afhankelijk werden van een aanbieder. Bijkomend risico is verder dat deze ene aanbieder veel inzicht kan krijgen in het betalingsverkeer. Zou een dergelijke aanbieder zijn positie hierin verkeerd gebruiken dan kan dat een kwetsbaarheid voor onze bankensector betekenen. Een andere vraag die we ons kunnen stellen is hoe we in het licht van PSD2 om moeten gaan met het gegeven dat onze transactiegegevens het domein van een dergelijke cloudbased aanbieder passeren.

In relatie met het bovenstaande heb ik voor de SNS bank enkele vragen:
(1) Aannemende dat SNS een ddos-pareer oplossing gebruikt, is deze cloud gebaseerd of is het een oplossing in eigen beheer en bevindt ze zich binnen het eigen SNS bank domein.
(2) Indien cloud gebaseerd, wordt een populaire aanbieder als Cloudflare of Akamai gebruikt?
(3) Indien cloud gebaseerd, conflicteerd deze opzet niet met de PSD2 richtlijn en zou dan geen toestemming nodig zijn van de klanten dat hun betalingsgegevens het clouddomein passeren?

7 Reacties

Inhoudelijk kan ik er niet teveel op ingaan, maar in de algemeenheid geldt het volgende; bij een DDOS-mitigatie hoeft het versleutelde verkeer tussen ons en jouw browser (ssl oftwel "het slotje") niet ontsleuteld te worden. Aanvalsverkeer kan herkend worden aan specifieke patronen, en uitgefilterd. Het resterende deel wordt ongeopend doorgegeven aan de volgende schakel in de keten. Dit werkt zowel bij cloud- als onpremise diensten zo. Daarna wordt het verkeer (intern) pas ontsleuteld en wordt er op inhoud gecontroleerd en desgewenst gefilterd. (een zogenaamde applicatieve aanval die bv 1000x probeert in te loggen of zich richt op bv formulieren is namelijk geen DDOS en wordt op andere manieren gefilterd, dat doet een WAF; web application firewall)

Wat DDOS mitigatie betreft; besef dat je, om een aanval af te slaan, méér bandbreedte nodig hebt dan de aanval zelf. Dat kan bij zware aanvallen een enorme hoeveelheid bandbreedte zijn, en dus een prijzig plaatje worden.

NB: Ik zie dat in de discussie inderdaad ook deze punten worden genoemd. De verwarring ontstaat doordat in het rapport DDOS en ALA (application layer attacks) in één hoofdstuk worden genoemd. Voor zover ik kon zien in het rapport is niet bekend, welke diensten er afgenomen worden en kan er dus helemaal niets gezegd worden over de "inzage van het betalingsverkeer".
Om eerlijk te zijn vond ik het al verbazingwekkend dat een instantie als het CPB zich zo diep in de materie had ingegraven. Ik verwacht dat ze deskundigen geconsulteerd hebben op wiens kennis dit rapport kon worden gefundeerd. Ik heb trouwens de berichtgeving over ddos aanvallen redelijk gevolgd (zie ook links onderaan) en ben mij bewust welk een stress er op een server setup wordt gezet. Ik meen te hebben gelezen dat tweakers twee (of meer) redundante IP's heeft waarnaartoe traffic kan worden geleid. Zou ondanks de mitigratie-service een IP volstromen dan kan verkeer omgeleid worden. Dus ja, voorbereid zijn op ddos aanvallen loopt in de papieren.

Onderstaande statement uit het rapport is denk ik desondanks niet onwaar:

Inzage in dataverkeer is nodig om goed en fout verkeer tijdens een Application Layer Attack (ALA) zoveel mogelijk te scheiden. Bij versleuteld dataverkeer – zoals betalingsopdrachten – is in het dataverkeer kijken alleen mogelijk indien diegene die de mitigatie uitvoert, decryptiesleutels bezit. Bij mitigatie door derden worden decryptiesleutels afgestaan. Er vindt dus een afweging plaats tussen betere bescherming en de vertrouwelijkheid/het delen van gegevens van klanten. Dit is onder voorwaarden, opgesteld door De Nederlandsche Bank in de regeling outsourcing, toegestaan. Daarnaast moet vanwege inzicht in persoonsgegevens in het kader van de AVG ook een bewerkersovereenkomst worden gesloten.

In hoeverre Application Layer Attacks nu al aan de orde van de dag zijn kan ik helemaal niet beoordelen. Mijn indruk (die nagenoeg niets zegt:$) is dat we in de regel met SYN flood attacks te maken hebben, gedistribueerd of niet. [Speculatie]Mijn indruk is dan ook niet dat CPB met deze statement refereert aan ervaringen uit het veld maar eerder anticipeert op de vorm die een toekomstige golf van ddos aanvallen kan aannemen[/speculatie]. Zelf lees ik de uitspraak meer als een angst voor een mogelijke toekomst. Maar is de statement van het CPB een correcte, is voor het ondervangen van ALA decryptie nodig of springt ze in conclusies?

Mochten ddos aanvallen een ALA karakter gaan krijgen, dan vraag ik mij trouwens af of we überhaupt nog geholpen gaan zijn met het zoeken naar bescherming in collectiviteit (of dit nu bij een Nederlandse stichting vandaan komt of bij een Amerikaanse service boer). Als ik er vanuit ga dat een ALA vlot heel organisatie specifiek wordt, dan heeft het delen van informatie minder zin.

PS
Hierbij de link naar het CPB rapport, dat is wat directer. Een ander link die ik geïnteresseerde lezers niet wil onthouden is een verslag van de tweakers crew over een grote ddos aanval (dns amplification attack) in januari van dit jaar (op meerdere sites waaronder verschillende banken, overheidsinstanties (als DigiD en de Belastingdienst) en tweakers, leest als een jongensboek, vakjargon blijft binnen de perken. Tweakers maakt voor haar bescherming tegen ddos aanvallen trouwens gebruik van NaWas (Nationale Wasstraat), een oplossing van NBIP, een Nederlandse Stichting. Nawas werd trouwens ook in het rapport van het CPB genoemd.
Application attacks zijn in de regel niet zo volumineus, omdat de aanvaller dan juist onder de radar wil blijven. Dit soort aanvallen zijn vaak heel specifiek op de specifieke website toegespitst, waarmee het dus minder van toepassing is of je een cloud of on-premise oplossing gebruikt; je zult hoe dan ook je eigen filters moeten samenstellen. (denk hierbij aan het aanvallen van bepaalde zwakheden in een bepaald CMS, een server platform, etc etc, die zullen per dienstverlener anders zijn). Dergelijke aanvallen hebben vaak tot doel om te hacken, terwijl een DDoS maar 1 doel heeft: onbeschikbaarheid forceren.

Voor zover mijn kennis reikt heb je voor het mitigeren van een applicatieve aanval (ALA) de inhoud van het verkeer nodig, en moet je dus decrypten.
De zin "Bij versleuteld dataverkeer – zoals betalingsopdrachten – " vind ik ook wel opvallend; het is immers al jaren zo dat de Nederlandse banken de volledige website SSL aanbieden. En tegenwoordig gaan we hard naar de situatie toe waarbij simpelweg alle websites SSL worden aangeboden.
Met jou kwam ik gisteren tot de conclusie dat het niet heel waarschijnlijk is dat (momenteel) een 3rd party service provider iets kan betekenen voor het ondervangen van ALA's. Wat je zegt het volume is te klein om op te triggeren, en door de encrypted data is een service provider niet in staat patroonanalyses uit te voeren.

Het ondervangen van ALA's moet dus plaatsvinden binnen het domein van de organisatie die het doel van de aanval is omdat die na decryptie in staat is analyse uit te voeren op datainhoud of afwijkend gedrag van de ontvangende software.

We zitten dus op dit punt op dezelfde bladzijde:8. Wat in mijn achterhoofd wel blijft dreinen is wat CPB heeft bewogen om de statement te maken waarvan ik in mijn vorige post een quote geef. We kunnen misschien de conclusie trekken dat het CPB even het onderscheidingsvermogen heeft gemist en alle aanvallen op een hoop heeft gegooid.

Die conclusie zou ik bijna trekken wanneer ik in het tweakers-artikel niet een referentie heb zien staan naar een hoogleraar die iets anders lijkt te beweren:

Hoogleraar aan de Universiteit Twente Aiko Pras, die onderzoek doet naar ddos-aanvallen, wijst op de risico's: "Amerikaanse bedrijven zoals Akamai krijgen steeds dieper inzicht in ons betalingsverkeer, terwijl wij kennis kwijtraken." Waarschijnlijk doelt hij op de analyse van tls-verkeer door Akamai voor de detectie en mitigatie van aanvallen.

Voor de lezer: TLS verkeer is de opvolger van SSL en is een encryptie conventie die de communicatie tussen computers op het internet moet beveiligen. Wat met deze uitspraak wordt bedoeld is mij niet duidelijk, zou Akamai informatie kunnen afleiden uit encrypted data (onwaarschijnlijk) of wordt een Akamai meer gevraagd dan we hier nu inschatten. Ik zal eens een vraagje bij de tweakers redactie neerleggen of ze deze alinea nog iets verder kunnen toelichten.

Zonder meer info vertrek ik vanuit de veronderstelling dat geen decryptie en inhoudelijke analyse plaatsvindt van inhoudelijke data bij de 3rd party service provider. Mocht ik wat meer info krijgen dan meld ik dat. Ik kan trouwens begrijpen dat SNS terughoudend is om info over haar beveiligingsopzet via een klantenforum te delen. Mocht hierop een vervolg moeten komen, dan zou dit onderwerp naar de Klantenraad moeten worden geduwd.
Een derde partij kan, al dan niet in de cloud, natuurlijk prima ALA's mitigeren. Het zijn alleen 2 compleet verschillende services. Een DDOS aanval bevat immers vele ongeldige requests. Mitigeren op applicatie aanvallen doe je daarna pas, want daarvoor kijk je naar de geldige requests.
Het is maar net welke dienst je wilt afnemen als klant.

Overigens is "inzicht in het betalingsverkeer" natuurlijk op velerlei manieren uit te leggen. Alleen al de reden dat dienstverleners de hulp inroepen van Akamai, geeft aan dat hun dienst als "cruciaal" wordt gezien. En op het moment dat er gemitigeerd wordt, kan Akamai natuurlijk wel aan het volume doorgelaten verkeer zien hoeveel legitiem verkeer een dienstverlener te verwerken krijgt.
Daaruit kan je dus ook de verhoudingen tussen gelijksoortige dienstverleners (zoals banken) afleiden.
Hoi leden,

We gebruiken ook cloud based bescherming. De vragen die in dit topic gesteld worden, stellen we zelf ook als we een product afnemen. Vanwege veiligheidsredenen wijden we hier niet verder over uit. Ik hoop dat jullie begrip hebben voor het feit dat we geen informatie delen over hoe we de privacy van onze klanten bewaken.
MarcelR schreef:

Mitigeren op applicatie aanvallen doe je daarna pas, want daarvoor kijk je naar de geldige requests. Het is maar net welke dienst je wilt afnemen als klant.

Technisch zal uiteindelijk alles wel mogelijk zijn, wel moet de derde partij dan de gelegenheid krijgen om dicht op de workflow en de data van de klant te kunnen komen. Of dit al zo verstrekkend gebeurd, dat vraag ik mij dus af. Het vraagt ook van de klant veel inzicht in wat er wel en wat niet aan de derde partij wordt gevraagd. De drempel blijft dus best wel hoger dan voor het behandelen van een volumeaanval.

In reactie op het onbevredigende tweakers artikel heb ik bij tweakers een reactie in een forumtopic achter gelaten, hierin was ik trouwens niet de enige. In deze reactie heb ik alleen los gerefereerd aan een discussie op een bankforum waarin we toch wat vraagtekens hadden gezet bij het item zelf en we benieuwd zijn naar een nadere toelichting vanuit het CPB om haar bevindingen in het rapport wat meer te duiden. De door tweakers in het item genoemde hoogleraar is al door tweakers verzocht om nadere informatie. Persoonlijk ben ik wat meer geïnteresseerd in hoe dat CPB rapport tot stand is gekomen. Of the record verwacht ik hierop niet direct een vervolg. Stilletjes hoop ik dat tweakers uiteindelijk bij het CPB op de koffie gaat.

Dennis schreef:

We gebruiken ook cloud based bescherming. De vragen die in dit topic gesteld worden, stellen we zelf ook als we een product afnemen. Vanwege veiligheidsredenen wijden we hier niet verder over uit. Ik hoop dat jullie begrip hebben voor het feit dat we geen informatie delen over hoe we de privacy van onze klanten bewaken.

Goed dat je dit met ons deelt. Ik heb er begrip voor dat op dit forum niet verder op de details kan worden ingegaan. Het lijkt mij wel een (deel)onderwerp voor de klantenraad om mee te nemen in de informatie uitwisseling over hoe PSD2 op SNS bank en haar klanten ingrijpt. Een vraag die hierbij aan de orde kan komen is of de derde partij voor haar rol informatie zal moeten decrypten.

Een andere vraag is of bij de toestemming van de Nederlandse bank ook het belang van de PSD2 richtlijn is verdisconteerd. Ik refereer hierbij aan de volgende passage uit het CPB rapport:

Inzage in dataverkeer is nodig om goed en fout verkeer tijdens een ApplicationLayer Attack (ALA) zoveel mogelijk te scheiden. Bij versleuteld dataverkeer – zoals betalingsopdrachten – is in het dataverkeer kijken alleen mogelijk indien diegene die de mitigatie uitvoert, decryptiesleutels bezit. Bij mitigatie door derden worden decryptiesleutels afgestaan. Er vindt dus een afweging plaats tussen betere bescherming en de vertrouwelijkheid/het delen van gegevens van klanten. Dit is onder voorwaarden, opgesteld door De Nederlandsche Bank in de regeling outsourcing, toegestaan. Daarnaast moet vanwege inzicht in persoonsgegevens in het kader van de AVG ook een bewerkersovereenkomst worden gesloten.

Reageer

    • :D
    • :?
    • :cool:
    • :S
    • :(
    • :@
    • :$
    • :8
    • :)
    • :P
    • ;)