Management

Outsourcing

14 netelige vragen voor een Saas-provider

9 januari 2014

”In negen van de tien gevallen zult u hetzelfde antwoord krijgen van een SaaS-provider op de vraag of hij de vertrouwelijkheid van de data afdoende waarborgt en waaruit dat dan wel blijkt. De applicatie- en dataservers staan opgesteld in een rekencentrum dat gecertificeerd is volgens ISO/IEC27001, ISAE3402, SIC 1&2, CSA Cloud Control Matrix of anderszins. Maar wat zegt dat eigenlijk? “Strikt genomen weinig”, constateert IT-consultant John Hermans van KPMG. “Voor bijna alle certificeringen geldt dat ze geen de facto minimum beveiligingsniveau definiëren. Feitelijk zijn het checklists van zaken waarvoor iets geregeld moet zijn. Er wordt bijvoorbeeld gesteld dat er zwemvesten moeten zijn, maar daarmee is nog niet gezegd dat die niet van lood mogen zijn”.

Ook Rhett Oudkerk Pool van het beveiligingsadviesbedrijf Kahuna relativeert het belang van certificeringen. “De meeste certificeringen zijn hoofdzakelijk papieren exercities. Vaak wordt uitgegaan van eigen risico-inschattingen, met als gevolg dat een aanbieder voor risico’s die hij niet onderkent ook niets hoeft te doen.”

Er is dus alle reden om door te vragen als een SaaS-provider met certificeringen of audit reports schermt. Maar wat moet je dan vragen? En wat moet je vinden van de antwoorden? AutomatiseringGids vroeg het aan een aantal insiders, zoals SaaS-providers, beveiligingsdeskundigen en juristen. De issues waarmee ze op de proppen kwamen, lopen sterk uiteen.

Uitputtend is de vragenreeks ongetwijfeld niet, maar ze kreeg wel de zegen van de geïnterviewden. Dit alles wel met de steeds weer terugkerende kanttekening dat er ook een zekere relatie zal moeten zijn tussen de gewenste mate van beveiliging en de ‘gevoeligheid’ van gegevens die aan de SaaS worden toevertrouwd. Of zoals een van de geïnterviewde SaaS-providers het formuleert: “Welke hacker is geïnteresseerd in de boekhouding van een MKB-bedrijf met acht medewerkers?”

1) Zijn de processen in de SaaS-organisatie gecertificeerd?

Welke certificering is van toepassing? En in hoeverre zijn de door deze certificering geadresseerde risico’s ook de risico’s die er voor de gebruiker organisatie toe doen? Gescreend personeel en kooien rond de fysieke servers zijn mooi, maar niet erg relevant als je je vooral zorgen maakt over online hackers uit de Oekraïne. Hermans: “De klant zal zich ervan moeten vergewissen of de gebruikte normenkaders voldoen aan zijn vereisten; worden hier de punten geaddresseerd die hij wil dat een cloudprovider dekt? Voor een aantal maatregelen geldt dat ze al werden gebruikt in de tijd toen er nog geen sprake was van cloud; die zullen bepaalde cloudgebonden bedreigingen dus niet afdekken.”

De meeste normenkaders waarnaar SaaS- en hostingproviders verwijzen geven vooral aan wát er moet worden geregeld, maar niet hoe. Dat geldt bijvoorbeeld voor PCI-DSS (een standaard voor dataverwerking in de betalingsverwerking) en de ‘ICT-Beveiligingsrichtlijnen voor webapplicaties’ van het Nationaal Cyber Security Center (een voor overheids-IT geldend normenkader). Specificeren hoe zaken geregeld moeten zijn, zou ook niet goed werken omdat het de cloudondernemers zou beperken in hun mogelijkheden om het beter of goedkoper te doen dan de concurrentie.

Een gevolg is echter wel dat ook als een SaaS-provider aan een gerespecteerd normenkader voldoet, dat voornamelijk betekent dat er aan van alles gedacht is. In het gunstigste geval borgt het dat er processen zijn om de beveiliging te managen in een online wereld die doorlopend in beweging is en waarin telkens nieuwe gevaren de kop op steken. Maar in welke concrete maatregelen en voorzieningen dat heeft geresulteerd, blijft vaak onduidelijk. Naar die maatregelen informeren zal misschien niet de ultieme zekerheid bieden, maar het kan wel verschillen tussen overwogen providers aan het licht brengen.

De in data- en cloudkwesties gespecialiseerde advocaat Mirjam Elferink van het kantoor KienhuisHoving wijst er op dat het bij verklaringen van conformiteit wel zaak is om even goed te kijken wie de certificering (formeel een ‘third party mededeling’ of TPM) afgaf. Als het om een ISO- of NEN-certificering gaat, moet die partij geregistreerd staan bij de Raad voor Acreditatie. Een registratie van geaccrediteerde certificatie-instellingen staat online op http://www.rva.nl/search/.

Voor andere certificeringen volstaan andere registraties, zoals NBA in geval van Standaard 3402, NOREA voor Richtlijn 3402 en IFAC voor ISAE 3402.

Andere relevante vragen zijn:

  •  Zijn deze certificeringen end-to-end? Zo nee, welke processen worden niet gedekt?
    Hermans: “ISO 27001 bijvoorbeeld is een datacenter-norm die van voor de cloud dateert. Typisch cloudeigen zaken zoals hypervisor-functionaliteit (waardoor storage-capaciteit van niet bewust geselecteerde derden kan worden ingezet) zijn daarin dus niet voorzien. Als je wilt dat je gegevens niet buiten Europa, of buiten Zwitserland, worden opgeslagen, dat zal ISO 27001 je daar geen zekerheid over verschaffen.”
  • Heeft de certificering betrekking op alle locaties? Certificeringen gelden doorgaans slechts voor één bepaald datacenter.
  • Hebben eventuele hostingpartners of IaaS-diensten waarvan de SaaS-provider gebruik maakt, eveneens een serieus te nemen certificering?
  • Verplicht de SaaS-provider zich ertoe deze certificering regelmatig te updaten, zodat klanten erop kunnen vertrouwen dat de stand van de beveiliging gelijke tred houdt met de stand van de (hacking-)techniek?

2) Blijf ik eigenaar van de data die ik in uw ­SaaS-omgeving opsla?

Sommige SaaS-providers behouden zich het recht voor om van alles te doen met uw data. De redenen lopen uiteen van de vrijheid willen hebben om diverse klanten samen te comprimeren, tot het recht om er Data Mining op toe te passen. Aan de klant het oordeel of hij dergelijke secundaire bewerking van zijn data al dan niet bezwaarlijk vindt.

Sander de Jongh, datacentermanager bij online boekhoudprogramma Twinfield, wijst op nog een heel andere reden om van je SaaS-provider een expliciete erkenning te vragen van het principe dat de data van de opdrachtgever zijn en blijven. “De meeste SaaS-leveranciers hebben geen juridische en financiële maatregelen getroffen om te voorkomen dat de SaaS-infrastructuur – met daarop klantenbestanden en -data – bij een eventueel faillissement als onderdeel van de totale boedel eigendom wordt van de [door de curator vertegenwoordigde] schuldeisers”.

3) In welk land worden de data opgeslagen?

Bij deze vraag denkt iedereen onmiddellijk aan de Amerikaanse PATRIOT-act. Niet helemaal onterecht, vindt De Jongh, “maar het is niet het enige om op te letten. Ook binnen Europa verschillen de regels met betrekking tot het inzien van bestanden en het offline halen van data van land tot land. In Nederland geldt een relatief terughoudend klimaat, waar de autoriteiten niet snel zullen ingrijpen op een informatiesysteem van een bedrijf. Maar in sommige andere landen is er weinig voor nodig om offline te worden gehaald of te worden geconfronteerd met een beslaglegging.”

4) In welke datacenters worden de data opgeslagen?

Kennis van de locatie waar de bestanden zich bevinden, kan van belang zijn voor het kunnen uitoefenen van het auditrecht. Maar er is nog een andere reden om te willen weten waar uw provider uw gegevens opslaat. Elferink: “In geval van een beslaglegging wilt u kunnen aangeven waar de deurwaarder moet zijn, om de servers en tapes met uw data op te halen.”

Een actie die overigens problematisch kan uitpakken als de afgenomen dienst gebaseerd is op een multitenant database, waarin de gegevens van diverse gebruikers in een complexe structuur met elkaar ‘vermengd’ zijn.

Als de SaaS-provider geen concrete serverlocatie kan noemen – wellicht omdat hij gebruik maakt van een gedistribueerde publieke cloudinfrastructuur – dan wordt lastig antwoord te krijgen op vragen als:

  • Wie mogen onder welke voorwaarden bij het datacenter naar binnen?
  • Is het personeel gescreend?
  • Wordt er (eventueel door middel van camera’s) geregistreerd wie het datacenter binnengaat?
  • Staan de servers binnen het datacenter in een eigen kooi, waarvoor een apart – door de provider zelf geaccordeerd –sleutelregime geldt?

5) Hoe is de authenticatie geregeld?

Enkel een naam en wachtwoord voor beveiliging van echt serieuze zaken geldt tegenwoordig als onder de maat. Two-step verification, een tweede bewijselement in de vorm van uitvoer van een code-calculator, een ge-sms-te toegangscode of een biometrisch gegeven, biedt een betere bescherming. Dat een degelijke vorm van toegangsbeveiliging in de SaaS-praktijk nog weinig wordt toegepast, is volgens Timo van Noppen, kwaliteitmanager van onder meer Exact, niet alleen de schuld van de aanbieders. “Exact Online biedt de mogelijkheid van two-factor authentication, maar klanten blijken daar nauwelijks in geïnteresseerd. Ik schat het gebruik op minder dan 1 procent.”

6) Hoe is de verbinding tussen de gebruiker en de servers van de SaaS-providers beschermd?

Voor de communicatie gelden de volgende eisen:

  • Webtoegang moet minimaal beveiligd zijn op basis van het bekende https-protocol.
  • Bestanduitwisseling is pas veilig als er sprake is van wederom https,ftps, sftp, SCP of WebDAV (FTP en RCP zijn niet veilig).
  • Voor de uitwisseling van remote shell opdrachten mag u SSH2 verwachten (telnet is niet versleuteld).
  • Remotedesktop kan worden versleuteld met de protocollen radmin en RDP (VNC wordt ontraden).

En als er dan inderdaad gebruik wordt gemaakt van een van bovenstaande versleutelende protocollen, hoe lang is dan de gebruikte encryptiesleutel? Veel providers vinden 128 bits genoeg, maar steeds meer aanbieders schakelen door naar 256 bits. Google besloot een paar weken geleden zelfs zijn versleuteling op te voeren van 1024 naar 2048-bits RSA. Ingevolge de wet van Moore mogen we verwachten dat ze binnen twee jaar behoefte krijgen aan 4096 bits, wat vooralsnog niet binnen de geldende standaarden is voorzien.

7) Op welke wijze is in de ­architectuur van de SaaS-applicatie rekening gehouden met beveiliging?

De wijze waarop de aanbieder zijn dienst heeft opgezet, is van groot belang voor de veiligheid. Vragen op dit vlak zijn ­bijvoorbeeld:

  • Is er sprake van een logische veiligheidszonering? Waarbij de data niet op een server staan die rechtstreeks met het internet in verbinding staat ? Het frontend van de SaaS-site staat per definitie met internet in verbinding, maar dat hoeft niet te gelden voor de servers waarop de databases staan; die kunnen ook in een lokaal ‘192.###-net’ achter de frontserver schuil gaan. Zo’n opstelling verkleint het ‘attack surface’ en is ook eventueel ook op basis van IaaS (online gelease virtuele servers) in te richten.
  • Zitten de data van alle klanten van de SaaS in één grote gezamenlijke database, of is er voor elke klant van de SaaS een separate database? Wat bij deze vraag het uit beveiligingsoogpunt bezien gewenste antwoord zou moeten zijn is overigens discutabel. Alle klanten gezamenlijk op basis van één grote database bedienen levert schaalvoordelen op en wordt wel gezien als het centrale dogma van SaaS. Maar er zijn ook SaaS-aanbieders die (zoals bijvoorbeeld Reeleezee) achter hun multitenant voorkant aan de achterkant toch wel werken met één database per klant.
    Oudkerk Pool ziet zelfs reden om te pleiten voor een aparte applicatie-instantiëring voor elke klant. Alle software bevat namelijk fouten. Hoe complexer de software, hoe meer fouten. Multitenant-programmeren is complexer, je mag dus meer (beveiligings)-fouten verwachten, redeneert Oudkerk Pool. Waar nog bijkomt dat multitenant programmering relatief nieuw is, zodat de best design-practices ook nog niet al best zijn. Het feit dat de data van diverse gebruikers in een multitenant-applicatie ‘dichter op elkaar’ zit, vergroot volgens Oudkerk Pool zowel de kans op beveiligingsfouten als de potentiële impact er van. Ook zijn multitenant-databases voor hackers attractiever, omdat er met één hack meer te halen valt.
    Exploitanten van multitenant-SaaS-omgevingen zijn het met deze van analyse van beveiliger Oudkerk Pool overigens allerminst eens. Wilko Stronks van boekhoud-SaaS Reeleezee: “Alle echt succesvolle SAAS-aanbieders werken met nieuwe software die als multitenant-software is ontworpen en onvergelijkbaar beter is voorbereid op bedreigingen in continuïteit of security. Aanbieders als Reeleezee, Twinfield en Exact Online hebben met dergelijke multitenant-applicaties nu al tien jaar ervaring, het is onzin dat als onveilig in de hoek te zetten.”
  • Is de als SaaS online gezette applicatie van meet af aan voor SaaS-gebruik ontwikkeld, of gaat het om een oorspronkelijk voor on premises gebruik bedoelde applicatie, waar achteraf van een webinterface aan is toegevoegd?
    Stronks, zelf exploitant van zo’n van meet af aan als SaaS-opgezette applicatie, vreest dat het achteraf naar cloudniveau brengen van de beveiliging als regel problematisch zal zijn en blijven. “Ja, je kan natuurlijk proberen om je oude toepassing door een hostingbedrijf met veel ‘hosting-pleisters’ te laten drijven, maar het blijft gerommel.”
  • Worden de gegevens versleuteld?
  • Zo ja, hoe worden de encryptiesleutels opgeslagen? Lokaal? Op een aparte server? Of wordt de encryptiesleutel voor elke sessie opnieuw door de eindgebruiker aangeboden? De laatste oplossing is technisch gezien veiliger. In de praktijk betekent het wel dat de toegang tot applicatie voor de eindgebruiker weer iets lastiger wordt, wat wellicht de kans vergroot op een slordiger omgang met wachtwoorden.

8) Wordt de applicatie ook regelmatig door onafhankelijke deskundigen op veiligheid getest?

Waar geprogrammeerd wordt, worden fouten gemaakt. De belangrijkste manier om je tegen de eventuele beveiligingsgevolgen van fouten in de programmacode te wapenen is volgens Van Noppen (Exact) het door derden laten test van de code. “Bij zo’n test wordt de code geïnspecteerd en beproefd op het voorkomen van bekende missers, waar onder ten minste die van de OWASP Top 10.” Omdat behalve de software zelf (nieuwe versies) ook de bedreigingen aan verandering onderhevig zijn laat Exact z’n SaaS-applicatie jaarlijks testen.

9) Laat de SaaS-provider systematisch ­penetratietests uitvoeren?

Bij penetratietesten wordt een ethical hacker gevraagd of het hem lukt in de webomgeving van de provider binnen te komen. Het is een gebruikelijke manier om na te gaan in hoeverre alle beveiligingsmaatregelen en -procedures effectief zijn. Vrijwel elke serieuze SaaS-provider zal melden daar gebruik van te maken.

Toch is er wel reden om op zo’n bevestigend antwoord nog even door te vragen. Sommige partijen gebruiken penetratietesten namelijk routinematig om na te gaan of men in de uitvoering van de voorgenomen maatregelen niet ergens een steekje liet vallen (configuratiefouten identificeren).

De meer serieuze penetratietest echter zal vooral gericht zijn op lacunes in het grotere plan van de beveiliging, om na te gaan of het voor hackers niet al te makkelijk is om slimmer of beter geïnformeerd te werk te gaan dan de beveiligers voor denkbaar hielden.

Voor de hand liggende vervolgvragen zijn hier:

  • Wie doet de penetratietest en met welke frequentie?
  • Zijn de rapportages van de penetratietests ook voor klanten toegankelijk?

Antwoorden op vragen die de redactie hierover bij verschillende SaaS-providers uitzette, lopen sterkt uiteen; van ‘eventueel in antwoord op een auditverzoek’ tot ‘een globale samenvatting van een aantal van de dagelijks uitvoerde pentests wordt dagelijks op onze login-portal geplaatst’.

10) Biedt de SaaS-provider buitenstaanders (zoals hackers) een structuur voor melden van door hen gesignaleerde ­gebreken in de beveiliging?

Sommige SaaS-providers belonen hackers voor het vertrouwelijk melden van manco’s in de beveiliging. De hoogte van de beloning in het kader van zo’n ‘responsible disclosure policy’ zal van geval tot geval verschillen, maar de basisgedachte is dat ze moet opwegen tegen verleiding om online te gaan opscheppen over de eigen hacker-scherpzinnigheid. Een grote site als Google Play zal daarom voor het belonen van hackers hoger bedragen moeten uittrekken dan een SaaS van mindere naam en faam. Naast de financiële beloning krijgen aanbrengers van informatie over beveilingsmanco’s na het verhelpen van het gebrek alsnog hun reputatie-credits in de vorm van een vermelding.

Maarten Dokter van research data management-SaaS Labficiency ziet de aanwezigheid van een responsible disclosure-sectie op de site van SaaS-provider als een aanwijzing dat er realistisch wordt omgegaan met het ervaringsfeit dat beveiliging in de praktijk altijd mensenwerk is.

11) Wordt er aan intrusion detection ­gedaan?

Intrusion detection berust op het kunnen herkennen van activiteiten die kenmerkend zijn voor hackers. Oudkerk Pool: “Kahuna beschikt over een database met use cases van hackers. Doordat we deze trucs kennen, kunnen we ook de daarbij te pas komende activiteiten herkennen. Een eenvoudig voorbeeld: als je al een tijdje merkt dat vanaf een bepaald verdacht IP-adres herhaaldelijk tevergeefs contact wordt gemaakt, dan moet je in de gaten houden of er niet op enig moment uitgaand verkeer naar dat adres is.”

12) Worden security events op een gedegen wijze gelogd en gerapporteerd?

Beveiliging en toegang zijn geen statisch gegeven. Het is een goed gebruik om veranderingen die met toegang en beveiliging te maken hebben, zoals het aanmaken van accounts, systematisch te loggen. Daarvoor zijn diverse beheerapplicaties beschikbaar die met uiteenlopende acroniemen, zoals SEM en SEIM, worden aangeduid. Van belang voor de SaaS-opdrachtgever is volgens Oudkerk Pool vooral of de gebruikte beheerapplicatie een API biedt waarmee de beheerinformatie – liefst real time – naar zijn voor beveiliging verantwoordelijke medewerker kan worden gepushed. Verder kan het uiteraard nuttig zijn om te informeren wat wel en vooral wat niet wordt gelogd?

13) Welke mate van aansprakelijkheid aanvaart de SaaS-Provider?

Het voorkomt een hoop problemen als contractueel wordt vastgelegd, hoe de aansprakelijkheid is geregeld wanneer er onverhoopt toch wat misgaat. Het gaat om vragen als:

  • Dekt de SaaS-provider – bij dataschending – mijn aansprakelijkheid in het kader van Wet Bescherming Persoonsgegevens? De Wet Bescherming Persoonsgegevens (Wbp) eist dat de eigenaar van privacygevoelige bestanden in geval van systeeminbraak kan laten zien dat hij – rekening houdend met de stand van de techniek en de kosten – ‘passende maatregelen’ had getroffen om misbruik van de gegevens te voorkomen. Dat betekent dat de klant, en niet de de SaaS-provider, de primaire verantwoordelijke draagt voor de bescherming van gegevens. Als volgend jaar de meldplicht datalekken in werking treedt gaat de boete voor het eventueel niet tijdig melden van een datadiefstal dus niet naar de SaaS-provider (de ‘bewerker’ in termen van het CBP), maar naar het bedrijf dat de persoonsgegevens verzamelde. Volgens Elferink (Kienhuis- Hoving) levert dat voor de SaaS-opdrachtgevers minstens twee aandachtspunten op:
    • Heeft de SaaS-provider een expliciet een intern proces gedefinieerd voor het onmiddellijk aan de opdrachtgever melden van data-lekken? En is die gang van zaken ook geborgd in de leveringsvoorwaarden of het contract?
    • Aanvaart de SaaS-provider – zonder allerhande escapes – de verplichting om een in het kader van Wbp aan de klant opgelegde boete of dwangsom aan de klant te vergoeden? De vraag om een bepaling die dat regelt, laat zich niet wegwuiven met de vaststelling dat de klant in geval van nalatigheid of opzet van de SaaS-providers toch altijd een civiele procedure kan op beginnen. Elferink: “Natuurlijk, kan dat, maar dan moet je die nalatigheid van de provider wel eerst aantonen, wat in de praktijk meestal niet eenvoudig is. Vooraf vastleggen is veel effectiever.”
  • Om overeenkomstige redenen ziet Elferink in een SaaS-overeenkomst ook graag geregeld dat de provider enigerlei vorm van aansprakelijkheid voor gevolgschade op zich neemt. “Aanbieders proberen gevolgschade vrijwel altijd uit te sluiten, vaak met het argument dat die moeilijk is vast te stellen en in theorie ook onbeperkt kan oplopen. Maar dat is natuurlijk onzin; daarover kun je afspraken maken,” zegt ze. Bijvoorbeeld:
    • Vraag of hij zich tegen aansprakelijkheid voor gevolgschade heeft verzekerd en tot welk bedrag. Als dat een redelijk bedrag is, dan kun je afspreken dat dat de bovengrens voor de aansprakelijkheid wordt.
    • Wie af wil zijn van de lastige discussie over de hoogte van eventuele gevolgschade kan een contractuele boete bij datadiefstal afspreken.

14) Hoe is de beveiligingscultuur?

Uiteindelijk is beveiligen mensenwerk. Als de techniek in orde is, maar de medewerkers gaan er slordig mee om, dan is het resultaat nog steeds onveilig (zoals onder meer de Diginotar-casus liet zien). Van Noppen van Exact raadt daarom aan te peilen in hoeverre een overwogen SaaS-provider de beveiligingscultuur onder z’n medewerkers actief onderhoudt, met vragen als:

  • Wat doen jullie aan security-awareness? Denk aan cursussen, discussiefora op intranet, et cetera.
  • Is er een formeel beveiligingsbeleid geformuleerd? Mogen we dat zien? Is het helder en concreet geformuleerd?

100 procent veilig?

Vrijwel alle SaaS-providers beweren dat absolute zekerheid inzake data-beveiliging niet mogelijk is. Maar op deze op het eerste gezicht redelijk geloofwaardige stelling, valt wellicht toch nog wel iets af te dingen. Sommige high-end providers bieden online storage-oplossingen waarbij de gegevens uitsluitend in versleutelde vorm bij de provider zijn. Dat gaat dus aanmerkelijk verder dan het gebruik van versleuteling voor alleen het datatransport. Als de provider niet over de decryptiesleutel beschikt – zogeheten zero-knowledge encryption – dan kunnen hackers via hem nooit bij de werkelijke informatie komen, tenzij ze via een parallele inbraak bij de eindgebruiker aan de sleutel weten te komen. Maar in dat geval is de cloudprovider niet de enige die zich onvold--oende beveiligde.

Zero-knowledge encryption biedt in die zin toch 100 procent veiligheid aan de kant van de provider. Een probleem is echter dat een SaaS-aanbieder – anders dan een storage-provider – van deze technologie geen gebruik kan maken, want de essentie van SaaS is dat er behalve opslag van data ook verwerking plaatsvindt, en versleutelde data zijn niet kenbaar en dus ook niet verwerkbaar. (Voor de fijnproevers: ja, er bestaan versleutelingen waarbij de doorzoekbaarheid behouden blijft, maar daarbij worden wel consessies gedaan aan het geboden niveau van beschermen en bewerking is en blijft dan toch nog steeds een probleem.)

Toch is het niet zo dat encryptie bij SaaS niet toepasbaar zou zijn. Er wel degelijk zijn applicaties denkbaar waarbij de gegevens ‘in rusttoestand’ slechts in versleutelde vorm worden weggeschreven, pas als een record wordt opgevraagd, wordt er ontsleuteld. Om direct na de transactie weer in versleutelde vorm te worden weggeschreven. Het zal duidelijk zijn dat de SaaS-provider in zo’n geval de decryptiesleutel zal moeten kennen, het is dus geen zero-knowledge encryptie.

Encryptie van de storage achter de SaaS lijkt Hermans (KPMG) ‘een behoorlijk degelijke oplossing tegen hackers’, maar of het uiteindelijk ook bescherming biedt tegen instellingen als de NSA betwijfelt hij. “Ook in de encryptie-software kunnen natuurlijk weer backdoors zijn ingebouwd.” Tenzij deze open source is? “Ja, dan kom je wel een heel eind in de richting van absolute beveiliging. Wat betreft de clouddimensie van het systeem, want bij een technisch waterdicht beveiligde infrasstructuur blijft theoretisch natuurlijk altijd nog hacking mogelijk via de werkplekken van degenen die de applicatie gebruiken. Bijvoorbeeld door via social engineering en/of keyboardlogging encryptiesleutels te achterhalen.

Voor dit artikel werd gesproken met:

Maarten Dokter (Labficiency, SaaS-provider)
Mirjam Elferink (KienhuisHoving, Advocatenkantoor)
John Hermans (KPMG, Consultancy)
Sander de Jongh (Twinfield, SaaS-provider)
Evert Lammerts (Lucipher, Iaas-technologie)
Timo van Noppen (Exact, SaaS-provider)
Rhett Oudker Pool (Kahuna, beveiligingsprovider)
Wilco Stronks (Reeleezee, SaaS-provider)

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!