Uren en uren beveiligingslogboeken bestuderen is geen manier om een middag door te brengen, maar het is de enige manier om echt te begrijpen wat er is gebeurd tijdens een beveiligingsincident. Inloggen op één apparaat tegelijk is de enige manier om erachter te komen waarom en hoe het verkeer ergens in het netwerk werd geblokkeerd, maar ik zou de resultaten niet vertrouwen.
Log-informatie, netwerkdetectie en een real-time inzicht in de netwerkstatus zijn zo belangrijk voor netwerk veiligheid dat we enorme hoeveelheden gegevens verzamelen van veel van onze systemen in een poging om alles wat er in onze netwerken gebeurt te volgen en te onthouden. Verzamelen is één ding, bruikbaar maken is een andere zaak.
Het configureren van SNMP-traps en syslog-servers is niet erg moeilijk. Het vinden van de spreekwoordelijke speld in de hooiberg kan echter zo vervelend en duur zijn dat IT-afdelingen vaak helemaal afzien van netwerkforensisch onderzoek. We willen uitgebreide logboeken, en vaak zijn we dat ook nodig om uitgebreide logboeken te hebben. Maar net zo vaak blijven die logboeken ongebruikt, onbenut en daarom zinloos.
Een typische workflow voor een beveiligingsincident kan zijn om het incident in het ticketsysteem aan te maken, de relevante e-mailketen aan het ticket te koppelen, een link naar de logserver te kopiëren en vervolgens het ticket te sluiten. Er is weinig anders dat iemand kan doen en toch weinig tijd om iets te doen. Zo zit het tenminste in het systeem en voldoet de IT-afdeling eraan.
Forensisch netwerkonderzoek is buitengewoon belangrijk, maar het is buitengewoon kostbaar vanwege de vereiste vaardigheden en tijd. Hoe verzamelen we specifieke gegevens van elk afzonderlijk apparaat, ongeacht het platform? Hoe zorgen we ervoor dat het juiste informatie is? En wat doen we met al die gegevens als we ze eenmaal hebben verzameld? Netwerkbeveiliging is belangrijk, maar netwerkbeveiliging is geen switchconfiguratie of een firewallmodel. Het is een heel proces en het is niet gemakkelijk.
Ik herinner me dat een leverancier me vroeg wie ons IT-beveiligingsteam leidde. Ik staarde hem blanco aan. In mijn ervaring hadden alleen zeer grote organisaties toegewijd IT-beveiligingspersoneel, laat staan hele teams van hen. Ik antwoordde dat we een afdeling hadden van enkele tientallen mensen, en dat de beveiliging voornamelijk door de netwerkmensen werd beheerd, aangezien beveiliging voor ons ging over firewalls, IPS-apparaten, 802.1x en andere netwerktechnologieën.
Maar we weten dat netwerkbeveiliging veel meer is dan dat. Het gaat om zichtbaarheid. Het gaat om het vermogen om abnormaal gedrag te identificeren, en het gaat om het vermogen om snel te volgen waar en hoe verkeer wordt geblokkeerd in een productienetwerk. Netwerktechnici kennen mogelijk alle opdrachten om logboekregistratie op elk platform in hun omgeving te configureren, en we weten misschien hoe we een ACL in onze slaap moeten configureren. Het proces om op grote schaal gebruik te maken van deze kennis en informatie kan echter kostbaarder zijn dan het beveiligingsincident zelf.
Hier hebben we een heel praktisch voorbeeld van hoe de huidige trends in netwerkautomatisering kunnen bijdragen aan het resultaat van een typische IT-afdeling die worstelt met budgetten, personeel en dagelijkse brandbestrijding. Ik ken een beetje basis Linux-scripting en een beetje Python. Dat zou helpen, en dat zijn zeker goede vaardigheden die iedereen kan leren. Maar de realiteit is dat ik altijd een routerjockey ben geweest. ik ben geen DevOps goeroe, en ik vermoed dat de meeste netwerkingenieurs dat ook niet zijn. Dus hoe kunnen we gemakkelijk aspecten van de DevOps paradigma's zoals automatisering van processen, snellere gemiddelde hersteltijd, kwaliteitsborging en continue levering?
De eenvoudigste en snelste route om daar te komen is door abstracte scripting- en automatiseringsprocessen achter intuïtieve software. Op die manier kunnen netwerkengineers met minimale kennis van scripting het verzamelen van allerlei soorten informatie automatiseren waarvoor vaak afzonderlijk op apparaten moet worden ingelogd en de juiste opdrachten moeten worden uitgevoerd.
Voor een netwerkbeveiligingsanalyse voor een klant zou ik bijvoorbeeld precies willen weten welke soorten ACL's in het hele netwerk zijn geïmplementeerd. Dat betekent dat ik zou moeten kijken naar elke laag 3-interface die ze hebben. In een groot netwerk zijn er waarschijnlijk veel apparaten met laag 3-afsluitingen, dus dit zou zo lang duren en zo foutgevoelig zijn dat de resultaten onbetrouwbaar zijn.
Volwassen software die dat proces abstraheert, zou een ongelooflijk hulpmiddel zijn in de handen van elke beveiligingsingenieur. Zolang het enigszins aanpasbaar is en met verschillende grote platforms werkt, zou dit de tijd en kosten verminderen die nodig zijn om een beveiligingsaudit en post-portem-analyse uit te voeren. Het in kaart brengen van alle laag 3-interfaces en de daarop geconfigureerde ACL's zou een kwestie zijn van een paar muisklikken.
Dit type software moet laag 3-topologieën niet alleen dynamisch in kaart kunnen brengen, maar ook laag 2 visueel in kaart kunnen brengen om poorten te identificeren die zijn geblokkeerd door Spanning Tree en om ARP- en MAC-tabellen te doorzoeken. Dit is ongelooflijk vervelend en tijdrovend om handmatig te doen, tenzij een netwerkteam de luxe heeft van tijd en meerdere DevOps ingenieurs, zou het waarschijnlijk niet eens worden geprobeerd in typisch forensisch netwerkbeveiligingsonderzoek.
Het bestuderen van beveiligingslogboeken en handmatig inloggen op elk apparaat op een netwerk is geen manier om een middag door te brengen, maar er is een betere manier. Software die alle harde delen van netwerkautomatisering abstraheert, kan snel enorme hoeveelheden logbestanden omzetten in zinvolle, bruikbare gegevens en dynamisch de probleemgebieden in een zee van Ethernet lokaliseren. Tegenwoordig wordt de spreekwoordelijke speld in de hooiberg zo veel gemakkelijker te vinden zonder uw IT-budget voor volgend jaar failliet te laten gaan.