image

Security Tip van de Week: Incidenten kun je managen

maandag 4 maart 2013, 11:51 door Unit 10 Forensics, 5 reacties

In de Security Tip van de week geeft elke week een andere professional, expert, onderzoeker of lezer een security tip. Persoonlijke tips, variërend van het veilig configureren van Windows, een handige security tool of het juist instellen van een firewall, waarmee de tipgever zijn systeem, applicatie of netwerk veiliger maakt.

Heb jij ook een leuke, originele, maar bovenal goede security tip die niet mag ontbreken, stuur dan een mail naar redactie@security.nl.

Deze week de Security Tip van Huub Roem

Incidenten kun je managen!

Je wordt een keer slachtoffer van een hack, malware, fraude of integriteitsbreuk. Het is niet de vraag of dat gaat gebeuren, de vraag is alleen wanneer het gaat gebeuren. Ben je dan in staat om het onverwachte incident te detecteren, er op te reageren en te acteren?

De afgelopen weken is maar weer eens gebleken hoe kwetsbaar we zijn. Het beschikbaar krijgen van de gekopieerde data van één tentakel van het ‘Pobelka’ botnet zegt iets over de kwaliteit van monitoren en detectie bij individuen en organisaties en over mandaten en capaciteit van ons reactievermogen van overheidsorganisaties bij dergelijke incidenten.

We komen in het veld als forensisch onderzoekers vaak IT-omgevingen tegen waarbij data als logbestanden niet, gedeeltelijk of na lang wachten pas beschikbaar krijgen omdat de verantwoordelijke beheerder net met vakantie is en deze net over het benodigde token of wachtwoord beschikt.

Anderzijds komen we ook omgevingen tegen waarbij teveel –niet relevante- data beschikbaar gesteld wordt om te analyseren. In deze tip van de week besteed ik graag aandacht voor de aanwezigheid van deze belangrijke indicatoren van een onverwachts incident.

Forensic Readiness

Inzet van ‘Forensic Readiness’ helpt organisaties onverwachte incidenten te managen, hierbij is het belangrijkste doel de business niet te verstoren, maximale potentie uit digitaal bewijsmateriaal te halen en de reductie van reactietijd, doorlooptijd van een incident en reductie van kosten van een onderzoek. Daarnaast wordt in Forensic Readiness de juridische aspecten voorbereid m.b.t. legitiem gebruik en privacy.

Eerste stap op weg naar Forensics readiness is het definiëren van incidenten die mogelijk plaats kunnen vinden waarbij digitaal bewijsmateriaal gewenst is. Vervolgens stel je vast welke bronnen kunnen dienen als bewijsmateriaal. Bepaal welke gegevens je kan en mag opslaan volgens wet- en regelgeving en eigen beleid van organisatie. Doel is dat de bronnen voldoende sporen bevatten om als bewijsmateriaal geclassificeerd te kunnen worden.

Creëer georganiseerd sporen

Organisaties zullen, als basis voor monitoring en detectie, hun IT-omgeving dusdanig moeten inrichten dat gebruik is te herleiden tot personen, plaatsen en tijden. Dit begint bij registreren van relevante verkeersgegevens van alle IT-componenten die in het belang zijn van de continuïteit van de business. Classificeer hierbij de informatie en de bijbehorende systemen en creëer een auditrail door de hele IT-keten.

De basis voor incident response en digitaal forensisch onderzoek ligt in het beschikbaar krijgen van data en verkeersgegevens als logbestanden in het bijzonder.In de praktijk kost het veel inspanning en tijd deze data beschikbaar te krijgen. Dit betekent dat organisaties dus niet of nauwelijks zelf actief monitoren en detecteren. Organiseer de sporen als opstap naar forensic readiness!

Logbestanden organiseren

Het doel van het aanleggen van logbestanden kan door kwetsbaarheden nader worden geduid en zullen in veelal kort omschreven kunnen worden als ‘het reduceren van de impact bij grote ICT verstoringen’.

Een goed begin is in ieder geval een centrale logging op te zetten in de vorm van een Syslog Server en service en een archiveringscyclus in te richten, liefst een off-site backup, maar wel op afroep snel beschikbaar kan zijn. Vooral als je als organisatie niet actief monitort is het veilig bewaren van mogelijk bewijsmateriaal vanuit onderzoeksperspectief gewenst.

Er zijn tal van syslog producten beschikbaar, zowel opensource als betaald, bijvoorbeeld Syslog-ng of Kiwi Syslog. Voor monitoring en detectie kan je de datastreams visualiseren door deze beschikbaar te maken in Logzilla, Splunk, Librato of Papertrail en creëer je eigen dashboard door de data van de bronnen te correleren en regels, drempelwaardes en alerts in te stellen.

Punten van aandacht:

  • Neem als uitgangspunt voor monitoring dat je te maken krijgt met grote incidenten, denk aan de beschikbare opslagcapaciteit en verwerkingssnelheid
  • Borg integriteit van brondata
  • Documenteer de architectuur, de logprocedures en het archiveringsproces
  • Zorg dat alle IT componenten in de bron op de juiste tijd geconfigureerd zijn, bij voorkeur UTC/GMT met gebruik van NTP protocol, maar in ieder geval in gelijke tijdzone en denk aan ‘daylight saving time’.
  • Creëer een veilige omgeving en denk na over aspecten als bewaartermijn, juridische toelaatbaarheid en beschikbaarheid (ook op zon- en feestdagen!)
  • Overleg met je onderzoekafdeling of externe forensisch expert hoe de overslag , overdacht en bewijsmateriaal beschikbaar gesteld kan worden

Klein zakelijke gebruikers en thuisgebruikers met een NAS station kunnen deze meestal ook als Syslog Server inzetten voor centrale logging.

Niet alleen techniek

Forensic readiness gaat zeker niet alleen over techniek, maar vooral ook over mensen, processen, juridische aspecten en governance. Het creëren van bewustzijn door voorlichting en training aan direct betrokkenen bij een mogelijk incident en ontwikkeling van beleid en procedures bevorderen de mogelijkheden van effectief en efficiënt incident response en digitaal forensisch onderzoek.

Huub Roem is eigenaar en consultant van Unit 10 Forensics en in die hoedanigheid primair actief met digitaal forensisch onderzoek en incident response. Dit artikel is geschreven op persoonlijke titel van de auteur en reflecteert niet noodzakelijk de zienswijze van Security.NL.

Reacties (5)
04-03-2013, 13:35 door Anoniem
Zorg dat alle IT componenten in de bron op de juiste tijd geconfigureerd zijn, bij voorkeur UTC/GMT met gebruik van NTP protocol, maar in ieder geval in gelijke tijdzone en denk aan ‘daylight saving time

Wat is het nu?

OF je hebt UTC, OF je hebt lokale tijden met DST. UTC heeft geen DST namelijk.

Bovendien zegt dit nog niets. Je hebt systemen die skewing gebruiken en dus de klok niet direct goed zetten, en je hebt systemen die ineens geen tijd meer synchroniseren of alleen bij opstarten. Zomaar effe NTP instellen zonder elke week te controleren of er nog steeds contact gelegd wordt met deze NTP server is dan ook belangrijker dan het instellen.
Zeker in omgevingen waarin je Windows gebruikt (hele brakke NTP implementatie) en dubbel zo erg als deze gevirtualiseerd worden.
04-03-2013, 21:51 door Erik van Straten
Door Anoniem:
Door Huub Roem: Zorg dat alle IT componenten in de bron op de juiste tijd geconfigureerd zijn, bij voorkeur UTC/GMT met gebruik van NTP protocol, maar in ieder geval in gelijke tijdzone en denk aan ‘daylight saving time
Wat is het nu?

OF je hebt UTC, OF je hebt lokale tijden met DST. UTC heeft geen DST namelijk.
Huub bedoelt, neem ik aan, dat de voorkeur is dat datum/tijd in log entries in UTC staat (dan kan er geen twijfel bestaan welke van beide mogelijke 02:30 tijdstippen op de laatste zondag van oktober bedoeld wordt). Is dat niet mogelijk, zorg er dan in elk geval voor dat alle devices in dezelfde tijdzone ingesteld staan, en op hetzelfde moment tussen zomertijd/wintertijd en vice versa schakelen.

Overigens schrijft Windows records in de eventlog met datum/tijd in UTC. Echter, door EventViewer worden die gegevens getoond in lokale tijd, en dat leidt tot een vreemde gewaarwording: als je gedurende de wintertijd naar events kijkt die in zomertijd zijn gelogd (en andersom), lijken de tijdstippen 1 uur fout. Zo lijkt het of ik op bijvoorbeeld 2012-10-24 mijn computer om 07:00 heb opgestart, maar dat was toch echt 08:00 (NL zomertijd). Vanaf maandag 29 oktober kloppen de tijdstippen - omdat het nu nog wintertijd is. Na zondag 31 maart is dat weer precies andersom...

N.b. vanzelfsprekend kan de datum verspringen bij tijdstippen minder dan 1 uur vóór of na middernacht, wees daar bedacht op als je oudere logs analyseert!

Ook de datum/tijd (creation, last modification, last access) van bestanden en mappen op NTFS filesystems wordt in UTC geschreven maar in local time getoond in bijv. verkenner. Dit geldt echter niet voor FAT en FAT32 filesystems (altijd local time).

Daardoor kunnen bestanden, die je vanaf een NTFS schijf naar een met FAT32 geformatteerde USB memory stick gekopieerd hebt, exact één uur nieuwer of ouder lijken dan hun bronnen op genoemde NTFS schijf. In gecomprimeerde bestandsformaten (zoals ZIP) wordt ook vaak local time gebruikt.

Zie http://www.kalender-365.nl/zomertijd_en_wintertijd.html voor zomer/wintertijd schakeldatums in de komende jaren.
05-03-2013, 10:25 door KwukDuck
Zucht...
Het creëren van bewustzijn door voorlichting en training aan direct betrokkenen bij een mogelijk incident en ontwikkeling van beleid en procedures bevorderen de mogelijkheden van effectief en efficiënt incident response en digitaal forensisch onderzoek.

Dit.... proberen we nu al vele jaren en heeft nog nooit gewerkt, op geen enkel vakgebied en ik zou niet weten waarom dat nu opeens anders zou zijn.
De 'nieuwe' generatie die geborden wordt met een tablet in de hand zal mischien iets bewuster om gaan met deze zaken maar het zal heel minimaal zijn en niets af doen aan de noodzaak voor een professionele uitrol en onderhoud van je IT zaken.

Voor veel bedrijven zijn de kosten van het basis systeem beheer vaak al veel te hoog , ik zie het niet gebeuren dat bedrijven nu opeens de knip gaan los trekken voor consultants, incident managers, nog een extra systeembeheerder, noem maar op.

Lijkt bijna op een commercieel praatje.
05-03-2013, 13:27 door Anoniem
Door Erik van Straten:
Overigens schrijft Windows records in de eventlog met datum/tijd in UTC. Echter, door EventViewer worden die gegevens getoond in lokale tijd, en dat leidt tot een vreemde gewaarwording: als je gedurende de wintertijd naar events kijkt die in zomertijd zijn gelogd (en andersom), lijken de tijdstippen 1 uur fout.

Ook de datum/tijd (creation, last modification, last access) van bestanden en mappen op NTFS filesystems wordt in UTC geschreven maar in local time getoond in bijv. verkenner.

Ja dit is een bekende bug in de Windows routines voor UTC naar local time conversie.
De GNU libc routines, die o.a. in Linux gebruikt worden, doen dat wel goed.
Bij de conversie van UTC naar local wordt er gekeken naar de tijd offset zoals die was op het moment van de timestamp
die je aan het converteren bent, ipv naar de offset zoals die NU is (wat Windows doet, en dat is dus fout).
05-03-2013, 18:19 door [Account Verwijderd]
[Verwijderd]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.