Negeren Windows updates nekt CheapTickets.nl

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

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.