best-practice

Best practice

Event logs voor netwerkbeveiliging en compliance

Heeft iemand die ongeautoriseerde wijzigingen aangebracht in uw Active Directory-beleid of toegangsbeheerlijsten (ACL's) voor een folder op een server die intellectueel eigendom van het bedrijf bevat? Heeft iemand ongeautoriseerde toegang gekregen tot data die wettelijk is beschermd, zoals persoonsgegevens met AVG? Probeert iemand je interne systemen te hacken? Wat als uw compliance officer u vraagt om SOX rapporten?

Elke dag genereren computernetwerken over de hele wereld records aan data over de digitale activiteiten die plaatsvinden. Sommige zijn routine. Andere zijn indicatoren van een afname van de netwerkstatus of hack pogingen en inbreuken op het netwerk. Logbestanden bevatten een schat aan informatie om te zien hoe en wanneer de organisatie blootstaat aan hackers, malware, schade, datalekken en wettelijke aansprakelijkheden. Log data moeten worden verzameld, opgeslagen, geanalyseerd en gemonitord om te voldoen aan en om te kunnen rapporteren over wet- en regelgeving zoals AVG, Sarbanes Oxley, Basel II, HIPAA, GLB, FISMA, PCI DSS, NISPOM. Dit is vaak een complexe taak omdat logs van veel verschillende bronnen afkomstig zijn. Logbestanden zijn ook vaak in verschillende formaten en in enorme volumes. Maar weinig organisaties hebben een goede strategie voor logboek management om een goede controle uit te kunnen oefenen en hun netwerk te beveiligen.

In reactie hierop zal dit artikel vereisten voor Event en Logboek Management (ELM) en de best practices bespreken om de netwerkbeveiliging en compliance te verbeteren.

Waarom gecentraliseerde Event en Log Management (ELM) belangrijk is.

Elk systeem in uw netwerk genereert een soort log. In feite wordt een logboekvermelding gemaakt voor elke gebeurtenis of transactie die plaatsvindt op een machine, apparaat of stuk hardware - zie het als uw "recordjournaal". Microsoft-gebaseerd systemen genereren Windows Event Logs en UNIX-servers en netwerkapparaten gebruiken de systeemlogboek- of syslog-standaard. Web applicatie servers zoals Apache of IIS, evenals load balancers, firewalls, proxyservers of contentbeveiligingsapparaten genereren W3C/IIS-logs.

Gecentraliseerd log management moet een belangrijk onderdeel zijn van uw compliance initiatieven zijn. Met gecentraliseerde logs heeft u controle en zich op de toegang tot bestanden, ongeautoriseerde activiteiten door gebruikers, beleidswijzigingen en andere kritieke activiteiten. Denk aan controles op bestanden of folders die eigendoms informatie of bij wet beschermde persoonsgegevens bevatten, zoals intellectual property, werknemersgegevens, patiëntinformatie of financiële dossiers. Een gecentraliseerde strategie voor log management moet het toezicht houden op event logs, syslog- en W3C-logs. Dit is belangrijk omdat informatielekken zowel van interne als externe bronnen komen. Windows-event logs geven u bijvoorbeeld inzicht in mogelijke schadelijke activiteiten die worden uitgevoerd door ontevreden werknemers, terwijl Syslog-management u controle geeft over uw netwerkperimeter.

Windows-systemen hebben verschillende event logs die consistent moeten worden gemonitord. Van deze logboeken is de security log de belangrijkste. Het biedt belangrijke informatie over wie er is aangemeld bij het netwerk en wat ze doen. Veiligheid logs zijn belangrijk voor IT, DPO's en security managers om te begrijpen of er een beveiligingslek bestaat in de beveiligingsimplementatie.

Syslog is een indeling voor log berichten en logboektransmissieprotocol dat als standaard is gedefinieerd door de Internet Engineering Task Force (IETF) in RFC-3164 met conceptverbeteringen in RFC-5424. Netwerkapparaten, UNIX- en Linux-systemen en veel software en hardware platforms, implementeren  syslog als een standaard logboekindeling en -middel om die logs te verzenden en te verzamelen in een gecentraliseerde opslagplaats voor log management. Met behulp van Syslog-informatie kunt u zeer gedetailleerde informatie vastleggen over de status van een apparaat of een aantal apparaten. De informatie kan worden gesorteerd en geparseerd om atypisch gedrag te zien door middel van wijzigingen in operationele of prestatiepatronen. Deze wijzigingen kunnen wijzen op een enkel of meerdere problemen. Opslag van Syslog-log data kan ook nalevingsinspanningen door auditlogboeken te verstrekken om gebeurtenissen op te sporen die van invloed kunnen zijn op de netwerkbetrouwbaarheid en de bescherming van gegevens. Dit is belangrijk omdat het de controle over alle informatie aan auditors bewijst.

Op dezelfde manier bieden W3C-logboeken ook informatie over gebruikers- en serveractiviteiten. Deze controlelogboeken moeten ook worden gecontroleerd, omdat ze waardevolle informatie bieden die u kunt gebruiken om ongeautoriseerde pogingen te identificeren om bijvoorbeeld uw webserver in gevaar te brengen. IIS-logboekbestanden zijn een vaste (wat betekent dat het niet kan worden aangepast) ASCII-indeling, die meer informatie registreert dan andere logbestandsindelingen, inclusief basisitems, zoals het IP-adres van de gebruiker, gebruikersnaam, aanvraagdatum en -tijd, servicestatuscode, en het aantal ontvangen bytes. Bovendien bevat de IIS-logboekbestandsindeling gedetailleerde items, zoals de verstreken tijd, het aantal verzonden bytes, de actie en het doelbestand.

Door een gecentraliseerde oplossing voor log management te implementeren, kunt u eenvoudig de vaak overweldigende hoeveelheid logboekinformatie beheren die door uw systemen wordt gegenereerd. Real-time toegang tot log data stelt u in staat om die ene "naald in een hooiberg" te filteren en te lokaliseren gebeurtenis die de oorzaak kan zijn van een inbreuk op de beveiliging.

Hoeveel log data is er?

Elke dag produceren uw servers en andere netwerkapparaten 10's van duizenden logboekvermeldingen. In feite verzamelt de gemiddelde onderneming tot 4 GB aan log data per dag. Meer dan 95% van de gegevens in de logbestanden bestaat uit gedetailleerde registratie van elke succesvolle gebeurtenis of transactie die op het systeem plaatsvindt. Bijvoorbeeld; een servercrash, gebruiker log ins, het starten en stoppen van toepassingen en bestandstoegang.

Veel beheerders zijn verrast om te horen dat "eenvoudige" logbestanden kunnen resulteren in zo'n grote hoeveelheid gegevens die worden verzameld en vervolgens opgeslagen. Het is de perceptie van deze meestal routinematige gegevens die de kern vormt van de het niet vastleggen, opslaan en analyseren van de logboekgegevens die constant worden gegenereerd. U moet nooit het belang onderschatten van de gegevens in deze bestanden.

Wanneer u handmatig logboekgegevens verzamelt en controleert, moet u zich ervan bewust zijn dat hoe meer servers u logboekgegevens produceert, de kans op bewustzijn en het lokaliseren van een beveiligingsgerelateerd of nalevingsprobleem in de loop van de tijd exponentieel afneemt.

Beveiliging binnen de perimeter

Netwerkbeveiliging staat altijd voorop in de IT-strategie van elke organisatie. Meestal richt deze strategie zich op de buitenkant van het netwerk om ongeautoriseerde toegang of aanvallen van kwaadwillende partijen te voorkomen, die niet aan de organisatie zijn gekoppeld.

Hoewel algemene netwerkveiligheid essentieel is, moet ook naar de interne aspecten gekeken worden? Een nieuwsgierige werknemer die wil kijken naar vertrouwelijke financiële gegevens van het bedrijf en  toegangsmachtigingen wil wijzigen? Of een ontevreden werknemer die een achteringang naar een server heeft gemaakt en op het punt staat terabytes aan klantgegevens te verwijderen? Hoewel dit slechts incidenten kunnen zijn, is het toch goed om er op voorbereid te zijn? Het potentieel voor een beveiligingsinbreuk is net zo waarschijnlijk van een interne bron als van buitenaf. Sterker nog, het is zelfs meer waarschijnlijk dat het van binnenuit komt. Zoals we in de samenvatting hebben besproken, is de kans op aansprakelijkheid aanzienlijk wanneer sommige onbevoegde individuen toegang krijgen tot gegevens die door wetgeving als beschermd worden beschouwd.

Door een ELM-strategie op te stellen voor het monitoren van de netwerkbeveiliging van Windows-event logs en van interne activiteiten buiten het bereik van normale bedrijfsactiviteiten vallen, kunt u onregelmatigheden lokaliseren en isoleren voordat ze tot een probleem leiden.

Compliance: bereid je voor op het ergste

Uw organisatie kan al dan niet worden geconfronteerd met naleving van de regelgeving. Als u een privé-entiteit bent, doet u dat hoogstwaarschijnlijk niet. Dit mag u echter niet beletten te begrijpen wat de wettelijke eisen zijn. Gebruik maken van deze standaarden kan u voorzien van een blauwdruk voor uw eigen interne beveiligingsplannen en log management strategie.

Zo kan het niet naleven van Sarbanes-Oxley bijvoorbeeld leiden tot hoge boetes en wettelijke aansprakelijkheid voor functionarissen in het bedrijf. Veel van de log management vereisten van andere wetgeving- en branchespecifieke initiatieven voor beveiliging en naleving, overlappen met die van Sarbanes-Oxley. Als gevolg hiervan kijken alle publieke en veel particuliere bedrijven naar die standaard voor begeleiding bij het bouwen van een log managementstrategie.

Een snelle beoordeling van elk van de onderstaande standaarden biedt u een overzicht om elk van hen te begrijpen en hoe ze uw log management strategie kunnen beïnvloeden.

 

Sarbanes-Oxley

In Sarbanes-Oxley staat de uitdrukking "interne controles" in sectie 404 van de wet centraal bij nalevingsinspanningen.

De jaarverslagen van overheidsbedrijven moeten het volgende bevatten:

 

[...] een verslag van de interne controle, dat –

  1. het management de verantwoordelijkheid heeft een adequate interne controlestructuur en -procedures voor financiële verslaglegging op te zetten en te handhaven; en
  2. een beoordeling bevatten over de procedures en de doeltreffendheid van de interne controlestructuur voor de financiële verslaglegging, vanaf het einde van het meest recente boekjaar van de uitgevende instelling.

Verschillende misvattingen gaan over wie en wat door deze vereisten wordt beïnvloed. Ten eerste is Sarbanes-Oxley alleen van toepassing op beursgenoteerde organisaties van meer dan $ 75 miljoen, of bij particuliere bedrijven die door grote bedrijven worden overgenomen. Ten tweede zijn het niet alleen de financiële gegevens zelf of de rapportage van die data waarmee Sarbanes- Oxley zich bezighoudt als het gaat om "falen van de controlestructuur". Het is veel breder.

Vanwege de inherente verschillen in netwerkconfiguraties, bedrijfsmodellen, markten en de voorkeuren van auditors, moeten de best practices die later in dit document worden voorgesteld, als uitgangspunt worden gezien. De onderstaande zijbalk vat enkele van de IEP-vereisten die moeten worden opgenomen in uw audit- en compliance strategieën samen.

Hoewel deze suggesties gericht zijn op Sarbanes- Oxley, kunnen ze ook worden gebruikt bij het voldoen aan de vereisten van Basel II, GLBA, HIPAA, PCI en anderen.

In de meeste gevallen zal dit deel uitmaken van een grotere compliance strategie, dus zorg ervoor dat u uw auditspecialisten raadpleegt voor meer informatie die relevant is voor naleving in uw specifieke branche.

Basel II

In vergelijking met Sarbanes-Oxley is Basel II iets minder bekend. Het doel van Basel II is het internationaal bevorderen van meer stabiliteit in de financiële stelsels Voor onze doeleinden hier, richten we ons op Basel's "operationeel risico", dat aan interpretatie onderhevig is. Het is mogelijk dat Sarbanes-Oxley compliance hiervoor een goed uitgangspunt is. Inspanningen door management- en auditteams van uw groep vereisen interpretatie van de geavanceerde meting Approach (AMA), een deel van het Basel II-akkoord.

 

GLBA

Wat IT compliance betreft, richt de Amerikaanse Gramm-Leach-Bliley Act (GLBA) zich op de bescherming van klantgegevens door financiële instellingen. Veel van de GLBA overlapt met de eisen van Sarbanes-Oxley, maar de GLBA heeft ook tanden. De gevolgen van niet-naleving kunnen civiele stappen omvatten die zijn ingesteld door de Amerikaanse procureur-generaal. De wet is toegankelijk via de website van de Federal Trade Commission op: http://www.ftc.gov/privacy/privacyinitiatives/glbact.html

 

HIPAA

HIPAA is voor bedrijven in de gezondheidszorg die actief zijn in de Verenigde Staten. De eisen van HIPAA zijn vergelijkbaar met die van GLBA's, omdat ze het bestaan benadrukken van een betrouwbaar auditspoor om de persoonsgegevens van medische patiënten te beschermen. HIPAA bestaat uit twee belangrijke regels: de Privacy- en Beveiligingsregels. Elk van deze heeft zijn eigen vereisten voor implementatie en rapportage. volgens de Centers for Medicaid en Medicare, naast het bouwen van IT-infrastructuur en strategieën om te beschermen tegen "bedreigingen of gevaren voor de beveiliging of integriteit van de informatie," moeten voorbereidingen worden getroffen voor onderzoek naar mogelijke inbreuken op de beveiliging. Een audittrail moet "voldoende informatie kunnen verschaffen om vast te stellen welke gebeurtenissen zich hebben voorgedaan, wanneer zij zich hebben voorgedaan, en wie (of wat) hen heeft veroorzaakt."

 

FISMA

Opnieuw geldig als u in de VS actief bent. De Federal Information Security Management Act (FISMA) is bedoeld om de kritieke informatie-infrastructuur van de Amerikaanse overheid te beschermen. Het stelt minimumbeveiligingsnormen vast voor informatie- en informatiesystemen en biedt bij de beoordeling en selectie van de passende controles ter bescherming daarvan. Elk federaal agentschap en zijn contractanten zijn verplicht om beleid te ontwikkelen, te documenteren en uit te voeren dat voldoet aan de FISMA-normen. Het National Institute of Standards and Technology (NIST) heeft een speciale publicatie 800-53 uitgegeven om richtlijnen te geven voor het selecteren en specificeren van beveiligingscontroles voor informatiesystemen ter ondersteuning van de uitvoerende agentschappen van de federale overheid.

 

NISPOM

Ook in de VS. De vereisten in hoofdstuk 8 van het National Industrial Security Program Operating Manual (NISPOM) zijn van belang voor overheidsinstanties én particuliere aannemers met personeel dat toegang heeft tot gevoelige en gerubriceerde data. In de handleiding staat dat beveiligingsaudits betrekking hebben op het herkennen, vastleggen, opslaan en analyseren van informatie met betrekking tot beveiligingsrelevante activiteiten. De controlerecords kunnen worden gebruikt om te bepalen welke activiteiten hebben plaatsgevonden en welke gebruiker of welk proces verantwoordelijk voor hen was.

 

PCI-DSS

De Payment Card Industry (PCI) Data Security Standard is ontwikkeld door MasterCard en Visa en wordt afgedwongen door American Express en stelt gedetailleerde vereisten bedrijven die gevoelige creditcardgegevens van consumenten verwerken. Elke entiteit die PCI-DSS implementeert, moet in een jaarlijks PCI-DSS-auditrapport aantonen dat ze aan de standaard voldoen, of ze kunnen de mogelijkheid worden ontzegd om creditcard informatie te verwerken of op te slaan. In deel 10 van de norm worden controle-informatie en vereisten voor log files gedefinieerd.

 

Monitoring en waarschuwingen van event logs

Meer informatie over onze tools voor Log Management.

Meer informatie

Neem contact op met ons team

Praat met een van onze experts.

Meer informatie

Aanbevolen procedures voor event- en log management

Best Practice #1: Definieer uw auditbeleidscategorieën

De term controlebeleid, in Microsoft Windows lexicon, verwijst eenvoudig naar de types security events van uw servers en werkstations die u wilt vastleggen in de logs van security events . Op Microsoft Windows NT®-systemen moet u handmatig het auditbeleid instellen op afzonderlijke servers en werkstations, maar in Windows 2000® of Windows 2003® Active Directory® domeinen, waarvoor Groepsbeleid is ingeschakeld, kunt u uniforme controlebeleidsinstellingen koppelen voor groepen servers of het hele domein. Voor een samenvatting van de belangrijkste registratiecategorieën die u wilt inschakelen, raadpleegt u de tabel "BASELINE ELM STRATEGY FOR SECURITY, COMPLIANCE AND AUDIT".

Best Practice #2: Alle log records automatisch centraal consolideren

Standaard zijn Windows-event logs en Syslog-bestanden gedecentraliseerd, waarbij elk netwerkapparaat of systeem zijn eigen event log activiteiten registreert. Om een breder beeld te krijgen van trends in het netwerk, hebben netwerk beheerders die zijn belast met netwerkbeveiliging en compliance-georiënteerde initiatieven een nodig om deze records samen te voegen tot een centraal data archief voor volledige monitoring, analyse en rapportage. Het verzamelen en opslaan van logboekgegevens is van cruciaal belang, omdat sommige nalevingsnormen gegevens bewaren voor 7 jaar of langer verplichten! Automatisering kan hier echt helpen omdat het tijd bespaart en de betrouwbaarheid van de log data garandeert. Denk eraan:

  1. Wanneer de gearchiveerde log files worden opgehaald, moet dit een betrouwbare kopie van de data zijn - er kan geen discussie zijn over de integriteit van de gegevens zelf. Naarmate het menselijke element wordt verwijderd met automatisering, wordt het niveau van gegevensbetrouwbaarheid verhoogd.
  • Het aantal machines, gebruikers en beheerders in de onderneming; en overwegingen zoals bandbreedte en concurrerende bronnen kunnen het verzamelen van logs zo bemoeilijken dat een geautomatiseerde oplossing de enige manier is om ervoor te zorgen dat elke gebeurtenis wordt verzameld. Want u kunt er niet voor zorgen dat elk evenement met succes is vastgelegd met een handmatig proces.
  • In een typische installatie configureert een netwerkbeheerder een ELM-hulpprogramma om 's nachts (of periodiek) event log records te verzamelen van servers en werkstations in hun netwerk. Dit proces omvat het opslaan en wissen van de actieve event log files van elke systeem, het lezen van log events uit de logbestanden in een centrale database (bijv. Microsoft SQL of Oracle) en ten slotte het comprimeren van de opgeslagen log files en deze centraal op een beveiligde server op te slaan.

    Het bewaren van uw log data in twee indelingen, zoals databaserecords en gecomprimeerde platte bestanden, biedt een duidelijk controlevoordeel. Event log data in platte bestanden comprimeren extreem goed, vaak tot 5% van de oorspronkelijke grootte. Daarom kost het in termen van opslagkosten heel weinig om gearchiveerde log data vele jaren bij te houden als een auditor deze ooit nodig heeft. Platte bestanden zijn echter een zeer slecht medium voor analyse en rapportage, dus het houden van een actieve werkset gegevens (vaak 60 tot 90 dagen) in een database maakt het mogelijk om ad-hoc rapportage en geplande rapportage beschikbaar te maken voor recente gebeurtenissen. Zoek naar een ELM-tool die een eenvoudig mechanisme biedt voor het snel opnieuw importeren van oudere opgeslagen log files terug in uw database als ze ooit nodig zijn. Het is onze ervaring dat de meeste uren van werknemers bij een audit zijn gewijd aan het eenvoudig achtervolgen van platte bestanden en het proberen om dezelfde soorten gegevens uit allemaal te extraheren. Data klaar hebben staan in een centrale database vermindert de kans op verloren uren wanneer een auditor komt kloppen.

    Best Practice # 3: Event management- Realtime waarschuwingen en meldingsbeleid

    De meeste organisaties hebben een heterogene IT-omgeving, met een brede mix van besturingssystemen, apparaten en systemen. Hoewel uw omgeving misschien vooral op Windows desktop leunt, wilt u misschien ook de optie hebben om meer te kiezen dan alleen Windows event log monitoring. Syslog support is belangrijk voor routers, switches, IDS en firewalls, maar ook voor UNIX- of LINUX-systemen.

    De meeste softwareproducten vereisen het gebruik van agents om realtime monitoring van logbestanden uit te voeren. Als een factor uw keuze voor een oplossing beïnvloedt, moet dit de oplossing zijn. Als u kunt kiezen voor een implementatie zonder agents die vereist zijn voor een monitoring oplossing, doe dat dan. Dit bespaart veel kopzorgen bij de eerste implementatie, naarmate uw netwerk groeit en bij het voortdurende onderhoud van uw netwerk monitoring oplossing.

    Bij het ontwikkelen van een log monitoring plan heeft elke organisatie andere regels over wat voor soort gebeurtenissen ze moeten bewaken. IT-afdelingen zullen zich vaak richten op beveiligingsgebeurtenissen als enige indicator van eventuele problemen. Tijdens het bewaken van logs met beveiligingsgebeurtenissen is essentieel, andere event logs kunnen ook problemen met toepassingen, hardwareproblemen of schadelijke software aangeven. Alle gecontroleerde events moeten ten minste traceerbaar zijn op hun oorsprongspunt. De "BASELINE IEP-STRATEGIE VOOR BEVEILIGING, NALEVING EN AUDIT" zijbalktabel in de bovenstaande sectie biedt het startpunt voor uw implementatie van log management.

    Afhankelijk van uw vereisten en de flexibiliteit van de ELM-oplossing die u implementeert, moet u een methodologie definiëren voor continue bewaking op basis van hoe vaak u logboeken wilt controleren op gebeurtenissen die van belang zijn in realtime. Elk gedefinieerde gebeurtenis wordt met een regelmatig interval gepolsteerd en genereert een waarschuwing of melding wanneer een interesse wordt gedetecteerd.

    Het aantal geconfigureerde gebeurtenissen, het aantal doelsystemen en de pollfrequentie bepalen de hoeveelheid bandbreedte die tijdens een pollingcyclus wordt verbruikt. Als u al op de hoogte bent van de gebeurtenissen die van belang zijn op bepaalde systemen die u wilt monitoren, configureert u dat.  Als u uw event monitoring voor de eerste keer instelt, kunt u beter beginnen met het inschakelen van alle gebeurtenissen en het configureren van een hogere pollfrequentie. Naderhand kunt u dan de frequentie verlagen.

    Best Practice #4: Rapporten genereren voor belangrijke belanghebbenden: auditors, security- of compliance functionarissen en management

    Rapportage is een gebied waar u bijzondere aandacht aan moet besteden. Het biedt u belangrijke data over beveiligingstrends en bewijst compliance. Rapportage kan u helpen de noodzaak te onderbouwen om beveiligingsbeleid te wijzigen op basis van gebeurtenissen die of hebben geresulteerd in gecompromitteerde beveiliging.

    Elke ELM-oplossing die u implementeert, moet de volgende vragen beantwoorden:

    • Welke rapportindelingen zijn beschikbaar?
    • Hoeveel van uw werk al voor u is gedaan in voorverpakte log rapporten die bij de gebeurtenis worden geleverd
    • Bent u gebonden aan een bepaald formaat? Spelen HTML en de beschikbaarheid van dat HTML-rapport voor meerdere gebruikers een rol?
    • Kunnen aangepaste filters eenvoudig worden teruggeroepen voor herhaald gebruik?
    • Uit welke gegevensbronnen kunnen rapporten worden gegenereerd? Bevat het EVT, tekst, Microsoft Access en ODBC?
    • Is de oplossing compatibel met uw oplossing voor het archiveren van gebeurtenissen?

    Meer informatie over logboekbeheer

    Monitor alles in uw netwerk

    Start uw gratis evaluatie van WhatsUp Gold