Sikkerhetsbegivenhetsleder - Security event manager

SEM ( Security Event Management ) og tilhørende SIM og SIEM er datasikkerhetsdisipliner som bruker datainspeksjonsverktøy for å sentralisere lagring og tolkning av logger eller hendelser generert av annen programvare som kjører på et nettverk.

Oversikt

Forkortelsene SEM , SIM og SIEM har noen ganger blitt brukt om hverandre, men refererer generelt til produktets forskjellige hovedfokus:

  • Loggstyring : Fokuser på enkel innsamling og lagring av loggmeldinger og revisjonsspor
  • Sikkerhetsinformasjonsadministrasjon ( SIM ): Langtidslagring samt analyse og rapportering av loggdata.
  • Security Event Manager (SEM): Sanntidsovervåking, korrelasjon av hendelser, varsler og konsollvisninger.
  • Sikkerhetsinformasjon og hendelsesadministrasjon ( SIEM ): Kombinerer SIM og SEM og gir sanntidsanalyse av sikkerhetsvarsler generert av nettverksmaskinvare og applikasjoner.

Hendelseslogger

Mange systemer og applikasjoner som kjører på et datanettverk genererer hendelser som lagres i hendelseslogger. Disse loggene er i det vesentlige lister over aktiviteter som har skjedd, med registreringer av nye hendelser som blir lagt til på slutten av loggene når de skjer. Protokoller , som syslog og SNMP , kan brukes til å transportere disse hendelsene når de oppstår, til loggingsprogramvare som ikke er på samme vert som hendelsene genereres på. Jo bedre SEM-er gir et fleksibelt utvalg av støttede kommunikasjonsprotokoller for å tillate det bredeste spekteret av arrangementssamling.

Det er gunstig å sende alle hendelser til et sentralisert SEM-system av følgende årsaker:

  • Tilgang til alle logger kan gis gjennom et konsistent sentralt grensesnitt.
  • SEM kan gi sikker, rettsmedisinsk lydlagring og arkivering av hendelseslogger (dette er også en klassisk loggstyringsfunksjon).
  • Kraftige rapporteringsverktøy kan kjøres på SEM for å bryte loggene for nyttig informasjon.
  • Hendelser kan analyseres når de treffer SEM for betydning, og varsler og varsler kan umiddelbart sendes ut til interesserte etter behov.
  • Relaterte hendelser som forekommer på flere systemer kan oppdages, noe som ville være veldig vanskelig å oppdage hvis hvert system hadde en egen logg.
  • Hendelser som sendes fra et system til et SEM forblir på SEM selv om det sendende systemet mislykkes eller loggene på det slettes ved et uhell eller med vilje.

Sikkerhetsanalyse

Selv om sentralisert logging har eksistert i lang tid, er SEM-er en relativt ny idé, pionerer i 1999 av et lite selskap som heter E-Security, og utvikler seg fortsatt raskt. Nøkkelfunksjonen i et verktøy for sikkerhetshåndteringsadministrasjon er muligheten til å analysere de innsamlede loggene for å markere hendelser eller atferd av interesse, for eksempel en administrator eller superbrukerpålogging , utenfor normal arbeidstid. Dette kan omfatte vedlegg av kontekstuell informasjon, for eksempel vertsinformasjon (verdi, eier, plassering osv.), Identitetsinformasjon (brukerinformasjon relatert til kontoer som det refereres til i tilfelle som for- / etternavn, arbeidsstyrke-ID, ledernavn osv.), og så videre. Denne kontekstuelle informasjonen kan utnyttes for å gi bedre korrelasjons- og rapporteringsmuligheter, og blir ofte referert til som Metadata. Produktene kan også integreres med verktøy for ekstern sanering, billettering og arbeidsflyt for å hjelpe til med prosessen med løsning av hendelser. Jo bedre SEM-er vil gi et fleksibelt, utvidbart sett med integrasjonsmuligheter for å sikre at SEM vil fungere med de fleste kundemiljøer.

Regulatoriske krav

SEM selges ofte for å tilfredsstille amerikanske regulatoriske krav som for eksempel Sarbanes-Oxley , PCI-DSS , GLBA .

Standardisering

Et av de største problemene i SEM-rommet er vanskeligheten med å analysere hendelsesdata konsekvent. Hver leverandør, og faktisk i mange tilfeller forskjellige produkter fra en leverandør, bruker et annet proprietært hendelsesdataformat og leveringsmetode. Selv i tilfeller der en "standard" brukes for en del av kjeden, som Syslog , inneholder standardene vanligvis ikke nok veiledning for å hjelpe utviklere i hvordan de kan generere hendelser, administratorer for hvordan de skal samles riktig og pålitelig, og forbrukere for å analysere dem effektivt.

Som et forsøk på å bekjempe dette problemet er et par parallelle standardiseringsarbeid på gang. For det første oppdaterer The Open Group sin XDAS- standard fra 1997 , som aldri kom forbi utkaststatus. Denne nye innsatsen, kalt XDAS v2, vil prøve å formalisere et hendelsesformat, inkludert hvilke data som skal inkluderes i hendelser og hvordan de skal uttrykkes. XDAS v2-standarden vil ikke inkludere leveringsstandarder for hendelser, men andre standarder som utvikles av Distribuert Management Task Force kan gi en innpakning.

I tillegg utviklet MITER innsats for å forene hendelsesrapportering med Common Event Expression (CEE), som hadde noe bredere omfang da det forsøkte å definere en hendelsesstruktur samt leveringsmetoder. Prosjektet gikk imidlertid tom for finansiering i 2014.

Se også

Referanser

Eksterne linker