uk There is also a ENGLISH VERSION of this site

Google

Meer artikelen

01 Jul - 31 Jul 2010
01 Jun - 30 Jun 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 28 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jun - 30 Jun 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 28 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 Jun - 30 Jun 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 28 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 Jun - 30 Jun 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 28 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006


Links

Deze site wordt gehost bij
ATN-Networks

Aanbevolen
Genootschap voor Informatie Architecten
Rene Hamberg
Eric Meijer
Bas Varkevisser
Ruth Malan
l-rs.org
Informatiekundig bekeken
Bredemeyer Consulting
Gaudi site
Hans Bot ArchITectuur Bedrijven
Security.nl
Byelex
XR Magazine



Diversen

Powered by Pivot - 1.40.1: 'Dreadwind' 
XML: RSS Feed 
XML: Atom Feed 


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:

  1. Security Management Practices
  2. Access Control Systems
  3. Telecommunications and Networking Security
  4. Cryptography
  5. Security Architecture and Models
  6. Operations Security
  7. Application and Systems Development Security
  8. Business Continuity Planning and Disaster Recovery Planning
  9. Law, Investigation, and Ethics
  10. 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:

  1. Middels logs kunnen rapportages worden gemaakt van trends;
  2. 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).


Meer artikelen: Zie de linkerbalk.

Over Sjaak Laan

Sjaak Laan

Ik ben 45 jaar oud, getrouwd met Angelina, en we hebben 3 kinderen van 12, 7 en 5 jaar oud. Ik woon in Friesland (Drachten).

Ik werk voor Logica als Principal IT Architect. Ik heb 20 jaar IT ervaring.

Ik bezit de volgende certificaten:

ITAC Master Certified IT Architect


CISSP_logo CISSP (Certified Information Systems Security Professional)


TOGAF8_Certified_web TOGAF Certified Architect



Ik ben lid van:


Mijn zakelijke contacten onderhoud ik via Linkedin.

U kunt mij bereiken via sjaak.laan [ a t ] gmail [puntje] com.

Deze site bevat mijn eigen mening, en niet noodzakelijkerwijs die van mijn werkgever of van de klanten waar ik voor werk.