DigiNotar kwam in opspraak, toen bleek dat de digitale certificaten die het uitgaf voor websites, niet waterdicht waren. Hackers konden hierdoor frauduleuze certificaten uitgeven. OPTA, als toezichthouder, was gedwongen DigiNotars certificaten in te trekken en het bedrijf te verbieden nieuwe uit te geven. Geen certificaatbeheer meer, einde DigiNotar! Andere digitale certificatenverstrekkers (Certificate Authorities / CA) zoals Comodo en GlobalSign zijn ook gehackt. Oftewel, de digitale certificatenwereld ligt onder vuur.
Digitale certificaten, waar dienen die eigenlijk voor? Een digitaal certificaat is een computerbestand, dat fungeert als digitaal paspoort voor de eigenaar van dat bestand. Digitale certificaten worden uitgegeven en beheerd in een speciaal systeem: een Public Key Infrastructure (PKI) . Een CA beheert het certificaat voor de eigenaar die het certificaat gebruikt in communicatie met een andere partij. Het certificaat is de identiteit/paspoort van de eigenaar en de CA waarborgt de integriteit en authenticiteit ervan.
Als er een hack plaatsvindt bij diegene die deze identiteiten waarborgt, welke persoon of organisatie heeft dan nog vertrouwen in de identiteit van de partij waarmee het communiceert via het internet? Immers, het certificaat waarmee de andere partij zich digitaal identificeert, kan vervalst zijn , waardoor deze partij een heel andere partij kan zijn dan wat de argeloze persoon/organisatie denkt.
Digitale certificaten worden onder andere in het internetbankieren en bij digitale overheden gebruikt. Misbruik hiervan kan enorme gevolgen hebben zoals te zien was bij de getroffen Iraniërs met hun Google-accounts.
DigiNotar was gehackt. Heeft zo'n organisatie dan geen veiligheidsvoorschriften waaraan het moet voldoen om een hack als deze te voorkomen? De automatisering van de CA's worden geacht aan bepaalde normen te voldoen. Jaarlijkse toetsingen zijn verplicht. Deze toetsingen worden gedaan door grote accountantskantoren zoals PricewaterhouseCoopers (PwC) en KPMG, dieitT-auditors in dienst hebben om de automatisering binnen de CA-organisatie te beoordelen.
Normen, hm… nu word ik nieuwsgierig. Als software tester ben ik ook dagelijks bezig te onderzoeken of bepaalde software aan specifieke normen of specificaties voldoet.
Wat zijn deze certificeringsnormen?
Er zijn twee grote digitale certificeringsorganisaties, een Europese en een Amerikaanse.
Het ETSI (European Telecommunications Standards Institute) vervaardigt globaal toepasbare ICT-standaarden. Standaarden voor CA's zijn hier een onderdeel van.
Het Amerikaanse Webtrust is een geregistreerd merk van de CICA (Canadian Institute of Chartered Accountants), gebaseerd op de Trust Services Principles and Criteria van de CICA en AICPA (American Institute of Certified Public Accountants) en heeft speciale certificeringsprogramma's voor de CA's.
DigiNotar was kennelijk geaccrediteerd conform de ETSI 101 456 (policy requirements CA's) en WebTrust CA – Extended Validation (EV) Certificaten standaarden. Het mag derhalve EV SSL certificaten uitgeven, die automatisch door browsers worden herkend als afkomstig van een vertrouwde uitgever. DigiNotar stond (!) ingeschreven bij de Nederlandse toezichthouder OPTA als leverancier van gekwalificeerde certificaten en voldeed aan het speciaal door de overheid opgezette stelsel voor elektronische communicatie: PKIoverheid. Wat is nu het verband tussen de PKIoverheid, de CA's en de ETSI- en Webtrust-standaarden?
PKIoverheidcertificaten zijn ontworpen voor betrouwbare elektronische communicatie binnen en met de Nederlandse overheid. De uitgevers van de PKIoverheid-certificaten moeten voldoen aan bepaalde eisen, waaronder
1) certificering tegen TTP.NL schema (toetsing ETSI normen, NL wettelijke besluiten en regelingen);
2) een goedkeurende auditverklaring;
3) registratie bij de OPTA.
Prima, maar waar komt een tester bij deze certificering van pas? Dit kan ik het beste uitleggen aan de hand van de voorlopige (!) resultaten uit het interim-rapport van Fox-IT. Dit Nederlands digitaal forensisch onderzoeksbureau was op 30 augustus ingeschakeld door de Nederlandse overheid (Govcert) om de DigiNotar-breach te onderzoeken. Uit het interim-rapport van Fox-IT kwamen vijf voorlopige bevindingen naar voren die ook zeker tijdens een audit naar boven hadden moeten komen:
1) het ontbreken van een kritische scheiding van CA-bedrijfsonderdelen;
2) het ontbreken van adequate authenticatie CA-domeinen;
3) gedateerde en ongepatchte software op de CA-servers;
4) geen antivirus-bescherming op onderzochte servers;
5) geen veilige centrale netwerk logging.
Bij bestudering van vooral de ETSI Normen (ETSI TS 101 456) constateer ik dat alle vijf bevindingen gevonden zouden moeten zijn tijdens de jaarlijkse audit. Immers alle vijf bevindingen zijn afwijkingen van de betreffende (deel)beleidsnormen die in het ETSI TS 101 456-document uitvoerig worden beschreven. Hierdoor voldeed DigiNotar niet aan ETSI TS 101 456. DigiNotar had eigenlijk geen bestaansrecht meer om deel te nemen aan de PKIoverheid.
Nu ga ik PwC, de betreffende auditor niet beschuldigen. Immers, DigiNotar zelf had ervoor moeten zorgen dat het voldeed aan deze ETSI normen. Maar op DigiNotars site was(!)te zien dat PwC in 2008 nog een audit uitgevoerd voor de EV-SSL certificaten en is de ETSI certificering geldig tot 2013, met een jaarlijkse controle. Kennelijk is hier iets mis gegaan.
Hoe kan dit audit-proces verbeterd worden?
Een audit is een momentopname en volgens de wet is de geldigheid van een accreditatie vier jaar met een jaarlijkse verplichte audit. Gezien de security-bevindingen, is het wellicht een idee, naast de jaarlijkse audit, een securitytest meerdere malen per jaar door een onafhankelijke partij zoals een securitytester te doen? Deze kan dan de CA-infrastructuur testen op mogelijke breaches, om hacks zo te voorkomen.
Men kan hiervoor een periodieke security-regressietest uitvoeren. Hierbij wordt, afhankelijk van frequentie, maar vooral ook van risico, de zwaarte bepaald. Bijvoorbeeld wekelijks testen op de meest voorkomende securityrisks, maandelijks een zwaardere regressietest en per kwartaal de zwaarste, waarbij de hele CA-infrastructuur grondig wordt doorgelicht. Hierbij is er alleen een probleem, toegang krijgen en hebben tot de zwaar beveiligde (!) CA-servers. Die heeft een tester niet zomaar. Wellicht is dit alleen mogelijk wanneer de securitytester gecertificeerd is (minstens Certified Ethical Hacker – het ECCCouncil biedt CEH training programma's aan die bij aangesloten opleidingsinstituten in Nederland gevolgd kunnen worden) is. Deze securitytester moet de CA-infrastructuur goed kennen en aan de eisen van de PKIoverheid voldoet om toegang te hebben tot de CA-infrastructuur.
De securitytester zal vooral veel samen werken met de CA-beveiligingsofficier om o.a. specificaties, toegang tot de beveiligde CA-server en contacten met CA-medewerkers te krijgen om zo een goed beeld te krijgen van de CA-infrastructuur. Hierop kan dan de hier bovengenoemde security regressietests op afgestemd worden. Security is, gezien het DigiNotar-incident, van levensbelang voor een CA.
Om miscommunicatie te voorkomen moet er regelmatig overleg plaatsvinden tussen de CA-directie, CA-beveiligingsofficier en security tester. Daarnaast dienen de securitytestrapporten, ten behoeve van de transparantie, ook toegankelijk te zijn voor de klanten van de CA, zoals bv. PKIoverheid, banken en andere instellingen en vanzelfsprekend de auditor.
Gebrek aan transparantie heeft DigiNotar genekt, geef de onafhankelijke security tester daarom 24/7 toegang tot de beveiligde centrale netwerklogging, zodat deze mee kan kijken of er breaches gebeuren. De tester kan dan direct rapporteren aan de stakeholders (twee ogen-principe).
Let wel, deze stappen maken een security test niet goedkoop, het is wel een investering die zich later terugbetaalt. Een CA kan, met medewerking van een securitytester, een breach sneller opsporen, elimineren en erover direct communiceren met haar stakeholders. Dit verhoogt de transparantie, het sneller vinden van bugs/breaches en het allerbelangrijkste: het brengt weer vertrouwen in het certificeringsproces.
Een heel andere rol die een tester kan spelen bij het certificaatbeheer van de PKIoverheid is bij het toetredingsproces van een certificaatverstrekker tot de PKIoverheid. Een van de onderdelen hiervan is het uitvoeren van een acceptatietest 'Aanmaken CSP (Certificate Service Provider) certificaat door de CSP en Getronics' (Programma van Eisen Deel 2: Toetreding tot en toezicht binnen de PKI voor de overheid, v.3.1, 1-7-2011). Een technische test, die productie-like het signing script en sleutelceremonie doorloopt,waarna het testcertificaat door de Policy Authority (PA) van de PKIoverheid wordt gecontroleerd. Dus zowel testinspanning bij de Certificaatverstrekker en bij Getronics. Hiermee kunnen technische fouten in het productielike proces gevonden worden, die zo nog verbeterd kan worden alvorens voor goedkeuring naar PKIoverheid wordt gezonden. Essentieel hierbij is dat de tester voldoet aan de volgende eisen: technische kennis van het aanmaken van een certificaat en gecertificeerd zijn in een voor deze branche toepasbare testmethode.
Testexpertise (in- en extern) kan, naar mijn mening, ook gebruikt worden bij de procesketen van certificaatbeheer. Hieronder valt het al besproken aanmaken, maar ook het proces van veranderen en revoken van een PKIoverheidcertificaat (en andere deelprocessen).
Dit kunnen proces-acceptatietests zijn, maar ook reviews van procesbeschrijvingen horen onderdeel te zijn van het takenpakket van een geschikte tester.
Kortom, genoeg zaken (en wellicht nog meer) waarbij een tester nuttig kan zijn ten behoeve van de audit, veiligheid en kwaliteitsborging van digitaal certificaatbeheer.
Digitaal certificaatbeheer gaat vooral om vertrouwen. Door een gezamenlijke transparante aanpak van CA, overheid, auditor en tester zou dit vertrouwen weer hersteld kunnen worden.
Testen moet een integraal onderdeel zijn van digitaal certificaatbeheer. De investering is laag, het bespaart geld en in het geval van DigiNotar, heel veel geld en reputatieschade.
Gezien de campagne van webwereld valt er nog veel te verbeteren. Als eerste moeten bedrijven en overheid het oude beveiligingsprincipe Security through obscurity los laten. Dus niet meer de klokkenluiders die zwakke en onduigdelijke beveiliging aan de kaak stellen vervolgen.
Gratis advies is namelijk niet altijd verdacht en uiteindelijk minder pijnlijk/schadelijk dan de put te dempen nadat het kalf verdronken is. Een proces is tenslotte zo sterk als de zwakste schakel en niet zelden dwingen vreemde ogen meer. Auditors en testers werken uiteindelijk alleen maar een lijstje af. Een lijstje dat niet zelden incompleet is.
Beste meneer Dekkinga,
uit uw reactie merk ik op dat u mijn artikel niet juist gelezen hebt.
Een goede tester werkt niet uiteindelijk alleen maar een lijstje af.
Een goede tester zal juist een toegevoegde waarde hebben.
een voorbeeld:
Een goede tester zal o.a., bij onjuiste of onvolledige requirements, dit melden aan het team zodat dit verbeterd kan worden en dit het ontwikkelproces niet verder verstoord. Testers er vroeg bij betrekken is daarom geen overbodige luxe.
@Cordny … maar op basis waarvan kun jij als tester concluderen of requirements onjuist of onvolledig zijn?
In die zin heeft de heer Dekkinga gelijk dat testers zich in eerste instantie vooral toespitsen op een vertaling van de requirements naar een vorm van testen.
Pas bij ervaren testers met domeinkennis, die goed zijn in bijv. exploratory testing, zullen vaak ook de niet beschreven onderdelen getest worden. De klokkenluiders zoals door de heer Dekkinga benoemd zijn vaak van dit soort testers. Op basis van ervaring en fouten uit het verleden, weten ze precies waar de zwakke punten van een product zouden kunnen zitten, iets waar de tester die net van school af komt nog geen weet van heeft.
@Pavake
als je mijn artikel gelezen hebt, zie je dat ik het heb over exploratory testers met domeinkennis (zie oa productie-like testen van aanmaken certificaat)
Dit zijn duidelijk geen schoolverlaters, waar ik dus ook nooit over gesproken heb in dit artikel.
Het testen van digitale certificaten geldt dus vooral voor de ervaren exploratory testers met domeinkennis.
@Cordny
Dit had ik niet zo uit je artikel gehaald, maar ik ben het in dat geval wel met je eens.
/off topic/ hieruit blijkt maar weer eens hoe belangrijk het is dat je allemaal dezelfde taal spreekt. Bij productie-like testen heb ik niet direct het beeld van exploratory testing. Dit is dan ook de reden dat mijn huidige werkgever al het personeel dat regelmatig met testen te maken heeft op dezelfde cursus heeft gestuurd. Hierdoor spreken we nu allemaal dezelfde taal, wat helpt bij het voorkomen van dit soort misverstanden
Ik denk dat in zijn algemeenheid te weinig wordt gekeken naar de operationele veiligheid van IT oplossingen bij organisaties. Voor zover ik het meemaak richten de audits zich vooral op het voldoen regelgeving, standaards en best practices.
In het geval van DigiNotar twijfel ik ernstig of een test door een Certified Ethical Hacker veel toegevoegde waarde zou hebben gehad. Zoals het artikel schetst was het hier heel erg mis in de inrichting, de processen en procedures. Iets wat de auditor wellicht zelfs gemerkt en gerapporteerd heeft, maar waar DigiNotar onvoldoende opvolging aan heeft gegeven. Voor zover ik auditors ken (ook bij PWC en KPMG), vinden ze altijd! verbeterpunten. Daar worden ze immers voor betaald en ze willen volgend jaar weer een betaalde audit uitvoeren. Dus zelfs als er niets te vinden is, dan vinden ze toch verbeterpunten. En met het zooitje van DigiNotar, hoefden ze niet ver te zoeken. Het zou mij ook zeer verbazen als hun audits niet hadden uitgewezen dat er bij DigiNotar van alles mis was. En als DIgiNotar al een lange neus trekt naar de compliancy auditors, waarom zouden ze dan wel luisteren naar een operationeel security tester.
Laten we voor dit specifieke geval blij zijn dat daar geen belastinggeld aan uitgegeven is. Het zou hier pure verspilling zijn.
In bijna alle andere gevallen, waar organisaties de boel enigszins tot redelijk op orde hebben, daar zijn pentratie tests als aanvulling op een traditionele audit zeer zinvol. Als bestaan, opzet en werking is aangetoond in de traditionele audits, kan de penetratietester onderzoeken of het ook operationeel voldoende robuust is.
@cordny
Verschil tussen een goede en slechte tester zit vaak in de ervaring. Nu hebben verschillende bedrijven begin dit jaar ICT-ers omgeschoold naar tester en niet altijd tot wederzijdse teveredenheid. En alle prachtige testmethodieken ten spijt blijven we geconfronteerd worden met ‘hidden features’ waar kwaadwillende gebruik van maken.
Leuk dat je vertrouwen stelt in instanties maar het is toch net als wetenschap. Soms heeft de nar hier toch gelijk en valt de hele theorie om. Dit stel je min of meer ook zelf in je afsluiting. Want je kunt wel een prachtig gecertificeerd slot hebben maar als een inbreker sleutels gaat kopieeren is deze toch nutteloos.
@PavaKe
Je hebt gelijk wat betreft het gebruik van dezelfde taal. Alleen, ik heb het artikel geschreven voor alle Computablelezers, en niet alleen voor de lezers die de testtermen kennen, de stof is al moeilijk genoeg..
Maar bedankt voor je feedback
@Cor Rosielle
Bedankt voor je reactie.
Auditors hebben wat dat betreft dezelfde neus als goede testers, beide vinden altijd verbeterpunten.
Ik vind dat ze elkaar goed aanvullen en ik ben het met u eens dat, zoals ikzelf ook al aangaf, bij volwassen organisaties (incl. overheid!), pentests als aanvulling op een traditionele audit zeer zinvol zijn. Zeker wat betreft operationele robuustheid; gezien de huidige ontwikkelingen moet de infrastructuur van deze organisaties een hack kunnen detecteren en tegenhouden. Dus gebruik van ervaren(!) specialisten in pentests en audits is hier van wezenlijk belang.
Uw quote: ‘En als DIgiNotar al een lange neus trekt naar de compliancy auditors, waarom zouden ze dan wel luisteren naar een operationeel security tester’
Zoals ik al beschreven heb, laat de rapporten van audits en pentests inzichtbaar zijn voor de klant, dan had DigiNotar de breach niet kunnen verbergen en moeten ze wel de raad van de auditor en pentester opvolgen en de klant informeren, zodat actie kan worden ondernomen.
@edekkinga
Bedankt voor de reactie, ik ben het hiermee eens, maar voorkomen, dmv audits en pentests (door ervaren pro’s), dat iemand inbreekt is altijd beter dan dat de inbraak daadwerkelijk plaatsvindt en er media-aandacht aan wordt besteed, toch? Vertrouwen moet immers gewaarborgd blijven.
@Redactie
Naar aanleiding van een deel van de discussie tussen de auteur en mezelf:
Is er al eens overwogen een begrippen/definitielijst te maken vanuit jullie blad, zodat we in het Nederlandse ict-wereldje dezelfde taal gaan spreken?
In dit geval was het een vrij specifieke term, maar ook termen als ‘de cloud’ of ‘de business’ zijn zeer globaal, waardoor menigmaal spraakverwarring ontstaat.
@redactie
off topic, (maar volgens mij geen geschikte thread hiervoor…) … het woordenboek; Onderstaande zou een goed begin kunnen zijn 😉
https://www.computable.nl/artikel/ict_topics/storage/4212938/1277017/big-data-big-confusion.html
Maar wikipedia met dergelijke informatie vullen -en- hergebruiken is natuurlijk ook een optie. Voordeel hiervan is dat er al een bestaande structuur is.