Tag: test

Tapes met data 800.000 mensen verloren tijdens oefening

  door

In de Verenigde Staten zijn tijdens een “disaster recovery” oefening verschillende back-up tapes met de gegevens van 800.000 burgers kwijtgeraakt. Na de oefening door IBM werden de tapes naar Iron Mountain gestuurd, maar kwamen daar niet aan. Op de tapes stonden namen, adresgegevens, social security nummers, rijbewijs- of identificatienummers, zorgverzekering en informatie van de werkgever (bron).

Een opmerkelijk bericht, als je het mij vraagt. Is de basis van een oefening niet dat het wel eens verkeerd zou kunnen gaan en dat je juist oefent om in geval van echte nood over de juiste “disaster recovery” maatregelen te beschikken? We analyseren de oefening en trekken de “lessons learned” zodat we goed voorbereid zijn.

Een basis principe daarbij is dat je een dergelijke oefening nooit uitvoert met daadwerkelijke gegevens. Nee, voor de oefening maak je gebruik van fictieve gegevens (of op zijn minst zorg je ervoor dat de gegevens versleuteld zijn…hoewel dat zeker niet de voorkeur heeft, fictief is in dit geval toch echt beter).

Maar goed, de tapes zijn opgestuurd en onderweg kwijt geraakt. We kunnen in ieder geval de les trekken dat we dergelijke gegevens of tapes niet zomaar versturen. Ik stel me zo voor dat ze gewoon in een doosje zijn gestopt met een adressticker erop. Ja ja. Mooie “disaster recovery” strategie is dat. In geval van nood wil je toch zeker weten dat de gegevens op een andere plek nog voorhanden zijn. Verzending via een reguliere poststroom lijkt me dan niet de veiligste oplossing.

Al snel zullen we denken dat we natuurlijk ook gewoon lege tapes zouden kunnen versturen om helemaal geen risico te lopen. Maar dat werkt niet. Nee, we willen juist testen of we nog bij de gegevens kunnen na een incident. We willen dus wel degelijk dezelfde hoeveelheid gegevens hebben, maar dan wel gerandomiseerd (zie ook de opmerking daarover op Security.nl).

Een positief aspect is dat men in ieder geval oefent. Er zijn nog genoeg organisaties die de op papier geweldige “disaster recovery” strategie nooit in de praktijk testen en dan na een incident de deksel lelijk op de neus krijgen. Daarbij kunnen we dan weer onderscheid maken in organisaties die helemaal niet stil staan bij dat testen (ze weten het gewoon niet) of die organisaties die weten dat ze moeten testen maar daarvoor niet goed zijn ingericht.

Er wordt nog wel eens te makkelijk gedacht over de “disaster recovery”. Het proces staat op papier, de plannen staan in de kast en klaar zijn we. Helaas wijkt de test omgeving totaal af van de productie omgeving en echt testen kunnen we dus niet. Jammer, want er wordt veel geld aan uit gegeven zonder dat we enige zekerheid hebben.

Het is nu maar te hopen dat de gegevens van de 800.000 mensen ook echt verloren is geraakt en niet in verkeerde handen is gekomen. Op de tapes stonden immers namen, adresgegevens, social security nummers, rijbewijs- of identificatienummers, zorgverzekering en informatie van de werkgever. Gegevens waarmee identiteitsdiefstal een peulenschil wordt.

Negeren Windows updates nekt CheapTickets.nl

  door

Gisteren hadden we het nog over de FBI-topman die graag een tweede internet wil omdat daar dan de kritieke systemen onderling veilig kunnen communiceren. Daarbij gaf ik ook al aan dat er naast zware technische aanvallen ook de simpelere aanvallen en fouten zorgen voor beveiligingslekken. Nu wil ik niet direct beweren dat CheapTickets tot de kritieke systemen moet worden gerekend, maar het onderbouwd wel het idee dat er nogal wat schort aan de basis van beveiliging bij bedrijven.

Door een niet gepatchte test-webserver lagen de gegevens van 715.000 klanten van CheapTickets.nl voor het grijpen, waaronder wachtwoorden en paspoortnummers. De Windows Server 2003 omgeving was niet up-to-date, waardoor een aanvaller via een lek uit 2009 toegang kreeg tot een back-up, met daarin de eerder genoemde gegevens, maar ook zaken als volledige naam, adres, woonplaats, maaltijdvoorkeur en telefoonnummer.

In een verklaring laat CheapTickets weten dat het om een testomgeving ging met consumentengegevens die gedurende de periode 2008 tot 2009 werden verzameld. De gegevens zouden inmiddels offline zijn gehaald. (bron)

Voor al die organisaties die besluiten om nog maar een dure firewall aan te schaffen moeten we natuurlijk eerst even op de rem gaan staan. Voordat je investeert in nog een technische maatregel moeten we eerst eens goed kijken naar de organisatorische en procedurele maatregelen.

De vragen die gesteld moeten worden zijn bijvoorbeeld:

  • Waarom was de Windows server niet up-to-date?
  • Waarom was de test omgeving gekoppeld aan het internet?
  • Waarom werd er gebruik gemaakt van echte gegevens en niet van fictieve gegevens?

Beantwoorden we die vragen dan zijn we op weg om de echte oorzaken van een dergelijk incident te achterhalen. De gevolgen mogen zich dan uitten in een security incident, de oorzaken liggen (zoals bij veel incidenten) buiten dit vakgebied.

Het betreft hier onder andere tekortkomingen in ontwikkeling en beheer. Misschien goed om toch nog eens te duiken in standaarden als de ITIL-processen en als we nog eens Googlen op best practices voor ontwikkeling en beheer dan vinden we ongetwijfeld ook nog wel wat slimme tips.

De lessen die wij zelf natuurlijk trekken is dat we updates sneller testen en doorvoeren, dat we de OTAP-omgevingen scheiden van de productie omgevingen en van het internet, dat we persoonsgegevens niet langer bewaren dan strikt noodzakelijk en dat als we dan toch willen testen we gebruik maken van fictieve gegevens. Doen we dat, dan zijn we al weer een aardig stuk op weg en had in ieder geval dit incident voorkomen kunnen worden.

Maar ja, misschien ook een goede les voor al die klanten. Beveiliging is een kwaliteitsaspect. Dan moet je niet gek opkijken dat je bij een prijsvechter een minder goede beveiliging kunt verwachten. Ze moeten het geld toch ergens vandaan halen en dat doen ze onder andere door weinig te investeren in informatiebeveiliging.

Helaas geldt dat niet alleen voor CheapTickets maar ook voor andere organisaties. De basis van beveiliging is (nog lang) niet op orde, maar met de huidige bezuinigingen en met de concurrentiestrategie die veel organisaties op dit moment voeren, wordt er niet geïnvesteerd in informatiebeveiliging en kunnen we dergelijke incidenten meer en meer verwachten.

Ontwikkel, test, acceptatie en productie

  door

De afgelopen dagen zijn we ingegaan op de eisen die we stellen aan de informatievoorziening en de onderliggende informatiesystemen. Daarna zijn we ingegaan op de risicoanalyses voor die informatiesystemen. Allemaal heel erg belangrijk, maar helaas zijn we er niet met het eenmalig uitvoeren van dergelijke stappen. Onze omgeving, de dreigingen maar ook de componenten zijn continue aan ontwikkeling en wijziging onderhevig. Een patch of een update van een component is van groot belang om dat component up-to-date te houden, maar een dergelijke update kan ook weer risico’s met zich meebrengen.

We willen niet dat een patch of update onze informatievoorziening platlegt en stellen daarom de volgende vraag:

Vindt de ontwikkeling/wijziging van informatiesystemen plaats conform de stappen: ontwikkel, test, acceptatie en productie (OTAP procedure, change management)?

Ontwikkeling van nieuwe informatiesystemen of wijziging van bestaande informatiesystemen doen we niet in de productie omgeving. We weten immers nooit zeker hoe dit zal samenwerken met de andere componenten in ons netwerk. We werken daarom met verschillende stappen om een wijziging doorgevoerd te krijgen.

We beginnen uiteraard met het ontwikkelen van de systemen en zodra we denken dat die systemen een vorm van leven beginnen te krijgen gaan we onze ontwikkelingen testen. Werkt het, doet het wat het moet doen, beïnvloedt het andere componenten, voldoet het aan de eisen van beschikbaarheid, integriteit en exclusiviteit en ga zo nog maar even door. Dat doen we niet in de productie omgeving omdat we te weinig zekerheid hebben over de werking van het systeem. Nee, we doen dat in een afgescheiden testomgeving zodat er niets met de productie gebeurt als het fout gaat.

Zijn we er eenmaal zeker van dat het systeem aan alle (technische) eisen voldoet dan gaan we over naar de acceptatie van dat nieuwe systeem. Niet dat we nu pas in overleg gaan met de gebruikers trouwens, want als het goed is ontwikkelen we omdat daar een behoefte aan is. Die behoefte wordt juist gesteld door de gebruikers. Zij hebben echter minder zicht op de achterliggende techniek (en dat hoeft ook helemaal niet) maar zij kunnen wel de functionaliteiten bekijken. Is dit systeem inderdaad wat ze willen? Moet het nog bijgeschaafd worden?

We zitten nog steeds niet in de productieomgeving. Het kan best zijn (en dat is meestal zo) dat we de stappen ontwikkelen, testen en accepteren verschillende malen moeten doorlopen voordat het systeem of de wijziging doorgevoerd kan worden in de productieomgeving.

Hier ontstaat natuurlijk altijd een spanningsveld. De gebruikers willen het nieuwe systeem zo snel mogelijk gaan gebruiken en patches willen we zo snel mogelijk doorvoeren omdat we anders wellicht grote risico’s lopen. Toch is het van belang om goed zicht te houden op de OTAP-stappen. Het middel mag immers niet erger zijn dan de kwaal.