Redenen om te backuppen
30 August 07 - 12:04
Aandachtsgebied: default -
Link naar dit artikel
Elk bedrijf doet aan back-ups. Ik heb echter meerdere ervaringen met backups die niet deden wat ervan verwacht werd.
Er zijn drie redenen om data te back-uppen:
-
In geval van een technische storing of een gebruikersfout worden files gewist. Deze files dienen te worden teruggezet;
-
Na een disaster dient een recovery te kunnen worden uitgevoerd;
-
Sommige data dient lang bewaard te blijven: ook wel archivering genoemd.
Elk van de drie redenen zal ik hieronder toelichten.
Gewiste- of beschadigde files
In geval van een gebruikersfout (iemand gooit een mailtje of een belangrijk Word bestand weg), kan het nodig zijn om een file te restoren. Ook na een virusuitbraak kan het nodig zijn data te restoren.
Backups van dit soort files dienen dan ook regelmatig gemaakt te worden (meestal dagelijks). Het verdient ook aanbeveling de back-ups bij de hand te hebben gedurende de dag, dus niet in een uitwijkcentrum op twee uur rijden afstand.
Let op: alle data op gesynchroniseerde disks op een andere plaats opslaan werkt hier niet! Als men een filetje weggooit, of een filetje krijgt een virus, dan is op de gesynchroniseerde disk het filetje ook niet meer bruikbaar.
Uiteraard is er altijd een periode waar dataverlies kan optreden: als iemand 's morgens een brief heeft geschreven, en per ongeluk geeft gewist voordat 's nachts een back-up wordt gemaakt, dan is de file verdwenen. Er zijn overigens technische oplossingen om dit soort situaties te voorkomen (zoals altijd een on-line kopie bewaren van elke file), maar voor normale toepassingen zijn deze oplossingen vaak te duur en te ingewikkeld.
Disaster recovery
In geval van een catastrofe, zoals een brand, overstroming, instorting of ontploffing zijn de fysieke gegevensdragers niet langer beschikbaar. Er dienen back-ups te zijn om de oorspronkelijke situatie (op een andere plek) te herstellen.
Het is daarom belangrijk backups te hebben van niet alleen de data, maar ook van de Operating Systems, en van de (papieren) procedures om de machines weer op te bouwen. Ook is het goed om een uitwijkcentrum te hebben, en een mogelijkheid om snel aan vervangende hardware te komen.
Back-ups voor disaster recovery dienen op een veilige plaats te zijn opgeslagen, zodat ze niet vernietigd of beschadigd raken bij de calamiteit. De vuurwerkramp heeft ons geleerd dat een afstand van tenminste 5 km dient te worden aangehouden (dus niet bij de buren opslaan!).
Het is cruciaal dat de restore procedure in zijn geheel tenminste jaarlijks wordt getest, inclusief het opbouwen van hardware!
Archivering
In de archiefwet staat dat bedrijven en instellingen dienen vast te stellen hoe lang historische data bewaard moet worden. Zo houdt de belastingdienst een periode van 7 jaar aan.
Er moeten back-upvoorzieningen zijn die de data opslaat voor de vastgestelde bewaartermijn. Uiteraard dienen de back-ups op een veilige plaats te worden opgeborgen, onder klimatologisch verantwoorde omstandigheden.
In dit artikel ga ik in de specifieke eisen die aan archivering moeten worden gesteld.
Backup en de business eisen
Het heeft geen zin om data te back-uppen die niet restored kan worden. Ik heb hiervan meerdere voorbeelden in de praktijk gezien.
Eén voorbeeld ging om een server met een dermate ingewikkelde filestructuur, dat het back-uppen wel ging, maar waarbij het restoren van de machine enkele weken zou gaan duren. Dit was onacceptabel voor de business.
Een tweede voorbeeld was bij een bedrijf dat slechts een deel van een hele keten was. Het bedrijf kon wel data restoren, maar dit kon alleen als de ketenpartners ook allemaal een paar dagen terug in de tijd zouden gaan. Uiteraard is dit niet mogelijk.
Een zeer lezenswaardig artikel is "The TAO of Back-up". Klik op de pijltjes voor het hele verhaal.
De 10 security domeinen
16 August 07 - 10:49
Aandachtsgebied: default -
Link naar dit artikel
De International Information Systems Security Certification Consortium, ook bekend als de (ISC)2 is de organisatie die het CISSP examen ontwikkelt en uitvoert.
CISSP staat voor Certified Information Systems Security Professional. Eind 2006 waren er in Nederland ongeveer 500 CISSP gecertificeerden.
De (ISC)2 heeft een zogenaamde Common Body of Knowledge (CBK) opgesteld waarvan elke CISSP diepgaande kennis moet hebben. De CBK bestaat uit 10 domeinen, te weten:
- Security Management Practices
- Access Control Systems
- Telecommunications and Networking Security
- Cryptography
- Security Architecture and Models
- Operations Security
- Application and Systems Development Security
- Business Continuity Planning and Disaster Recovery Planning
- Law, Investigation, and Ethics
- Physical Security
Zoals u ziet behelst IT security veel meer dan alleen maar Cisco Access-lists of PKI infrastructuren. Natuurlijk zijn dit wel security onderwerpen (respectievelijk domein 2 en 4), maar het terrein is veel breder. In latere artikelen zal ik ingaan op elk van de tien domeinen.
Log analyse - gebruik logging informatie
02 August 07 - 13:51
Aandachtsgebied: default -
Link naar dit artikel
Voor een klant ben ik bezig met het implementeren van een Loganalyse oplossing. Hierbij wordt de logging van alle server- en netwerk systemen verzameld op één systeem. Vanaf dit systeem kan over loggegevens worden gerapporteerd en kan de logging worden gebruikt voor analyse.
Er zijn twee redenen om logs te gebruiken:
- Middels logs kunnen rapportages worden gemaakt van trends;
- Logs kunnen dienen bij het onderzoeken van incidenten, waarbij ze zelfs als bewijs kunnen dienen als iemand de (bedrijfs)regels heeft overschreden.
Loganalyse oplossingen worden ook vaak ingezet als hulp bij het voldoen aan SOX, COBIT of BASEL-II vereisten, of om aan te tonen dat aan alle eisen van de Code voor Informatiebeveiliging is voldaan.
Hoewel loganalyse systemen ook aan alerting kunnen doen (als er in de logging iets verdachts gebeurt, of een threshold wordt overschreden kan er alarm worden geslagen), is loganalyse iets anders dan monitoring. Ik pleit ervoor om beide zaken te scheiden, omdat ze andere doelstellingen hebben.
Monitoring systemen, zoals IDS systemen of SNMP gebaseerde systemen (zoals Microsoft MOM of HP-Openview) zijn real-time systemen. Zodra er iets gebeurt, moet meteen een alarm afgaan. Logsystemen dienen voor het achteraf analyseren van zaken en hoeven dus niet real-time analyse te doen.
Logoplossingen vallen onder de SIEM (Security Information and Event Management) oplossingen. Er zijn grofweg twee soorten oplossingen te koop: Software die op een server draait en complete appliances. Net Report is een voorbeeld van een software oplossing, Loglogic van een appliance. Snare levert beide.
Het gaat meestal om grote hoeveelheden data (gigabytes per dag is geen uitzondering voor een gemiddelde omgeving), die specifieke eisen stellen aan opslag, bandbreedte en doorzoekbaarheid.
Rapportages
Rapportages over logging kunnen dienen om snel een overzicht te krijgen van gebeurtenissen. Een aantal voorbeelden zijn:
- Het aantal poortscans die de firewall de afgelopen tijd heeft gehad;
- Welke stations hebben meer dan 5 on-succesvolle inlogpogingen gedaan;
- Wat is de top 10 van websites die bezocht worden;
- Het aantal e-mails dat per dag intern- en extern wordt verstuurd;
- Wat is het account waarvan het vaakst het password werd gewijzigd.
Op basis van de rapportages kan besloten worden tot een incidentonderzoek.
De rapportages worden gemaakt vanuit een database, die wordt gevuld met geaggregeerde logdata. Net Report heeft een aantal voorbeeldrapportages online staan, zie Report and Dashboard Samples.
Onderzoeken van incidenten
Omdat alle logging van alle systemen en netwerkcomponenten centraal zijn opgeslagen, kan eenvoudig een compleet overzicht worden verkregen van incidenten. Hiervoor is meestal een systeem ingericht dat alle ruwe data bevat (en een grote harde schijf). Voordat de ruwe data op schijf wordt weggeschreven, wordt een index gemaakt op tijd en op woorden, zodat later in de logging gezocht kan worden.
De opslag van de core logging moet voldoende garantie geven over de authenticiteit en integriteit van die logging, zodat het als bewijslast kan dienen in onderzoeken. Aannemelijk moet gemaakt worden dat de logging niet is ‘bewerkt’. Dit gebeurt meestal middels encryptie en elektronische handtekeningen (hashes).