Hvert år, mange, tror jeg det, sett noen ambisiøse mål, for eksempel å gå ned i vekt. Å, at dette er meg, vi snakker om sikkerhet. Så målene på IB er satt. Anta å redusere antall hendelser per dag fra 23 til 18 eller 17%. Det ser ut til å være et vakkert og nødvendig mål, men for å oppnå det, er det nødvendig å lage en rekke trinn. Og siden jeg nevnte vekttap, så la oss prøve å sammenligne disse to prosessene mellom seg selv.
Så, vi vil gå ned i vekt. Hvis du tror mange treningseksperter, vil det første trinnet på denne banen bli beregnet kalorier. Ja, det er ubehagelig å se at sandwich-spise sandwich med doktorgrads pølse inneholder nesten halvparten av hele daglige kalori-normen. Det antas at dette ikke bare danner vanen til oss, men spiller også en psykologisk rolle, som synes å se de mange ekstra kaloriene, vi vil begynne å bekymre oss for det og forsøke å redusere nummeret deres. Men det er nødvendig nødvendig.
Det samme problemet og metriske Ib. Når vi begynner å telle alle våre shoals, ubesvarte spam, savnet phishing, ubehagelige sårbarheter, innrømmet lekkasjer, nedetid, farlig design i applikasjonskoden, ulåste porter på ITU, etc., så begynner vi å danne et betinget kompleks av mindreverdighet. Og hvis vi fortsatt bestemmer seg for å visualisere alle hendelser i form av dashboards og rapporter om Ib, så blir situasjonen enda verre. I hovedsak blir vi bedt om i vår ensartethet. Og hvis resultatene fra applikasjonen for strømstyring, se bare deg (på en eller annen måte få personer bruker "Share" -funksjonen i slike programmer), ser IB-rapportene din guide, og den begynner å stille spørsmål vi er veldig redde.
Jeg tror det er derfor jeg ikke ofte ser godt implementerte prosjekter for måling og visualisering av IB (og dårlig også). Og i fjor deltok jeg i de ti beste prosjektene for å designe eller revisjons SOCOS (Cisco er aktivt engasjert i slike prosjekter). De liker ikke å vise resultatene av sitt arbeid, som i Ib ikke alltid er så positiv.
Men tilbake til målingene av din "dårlige oppførsel" (i om du spiser, eller i Ib). Det er ubehagelig å innse at vi gjør noe galt, men det er nødvendig, og det er fra dette at implementeringen av IB-måleprogrammet begynner. Det er imidlertid også viktig å vite hva og hvordan man måler. La oss gå tilbake til vekttap. Her anser vi kalorier, men er det viktig? Det er viktig å anta at vi spesielt spiste og hvor mye disse kaloriene var "dårlige" eller "gode". Og også betingelsene der vi spiste alt. Anta at vi reduserte vår 500 kalori diett. Greit? Det virker ja. Du kan skrive den til din ressurs. Og hvis vi har redusert aktivitet på samme "500 kalorier"? Det viser seg ingenting i essens og har ikke endret seg. På diagrammet vil det se vakkert ut, men i virkeligheten ... og jeg tar ikke situasjonen ennå i beregningen når noen bevisst manipulerer tallene.
Med hendelser alt det samme. I seg selv betyr nedgangen i antall hendelser ikke noe. Årsaken til dette kan være:
- Redusere Coating Zone Monitoring
- Revisjon av begrepet hendelse
- Gjemmer hendelser.
Og du kan også ha en reduksjon i det totale antall hendelser, men veksten av kritiske hendelser. Og til slutt kan du bare angripe deg, noe som indikerer nedgangen i aktiviteten til angriperne, men ikke om kvaliteten på ditt beskyttelsessystem. Og ja, det kan være resultatet av arbeidet ditt og outsourcing soc, så vel som andre divisjoner i selskapet (for eksempel det). Derfor betyr bare ett siffer noe - det er nødvendig å forstå sitt miljø, samt sammenligne det med andre innsamlede eller beregnede tall.
Og derfor er det så viktig å måle tilstrekkelig mange forskjellige indikatorer, hvorav deretter velge ønsket - for forskjellige oppgaver, på forskjellige tidsperioder, for ulike målgrupper. Tross alt er beregninger forskjellige - operasjonelle, taktiske og strategiske. Og i noen tilfeller, med et stort antall nivåer av IB Hierarkiet i organisasjonen, kan det være executive-beregioner, etc. Derfor må lanseringen av IB-måleprogrammet huskes at det er nødvendig
- Måle alt. Seinere
- Måle de riktige tingene. Seinere
- Ta de riktige tingene
Men begynn med måling av alt (vel, eller mye).
Og her nærmet jeg meg tidspunktet for hvilket dette lange notatet ble skrevet. Jeg bestemte meg for å bukke seg for den trendy referansen, kalt hitability av IB (på russisk), og lansere en ny telegramkanal av IB-beregninger (Cyber Security Metrics). Jeg vil dele en enkelt metrisk i IB hver dag med sin korte beskrivelse, formler, datakilder, restriksjoner, etc. Faktisk er dette selvfølgelig ikke en guitability, men hvordan å kalle det, vet jeg ikke. Først tenkte jeg på å lukke metrisk katalog umiddelbart og legge den på Github, men tiden til å gjøre det umiddelbart og alt, nei. Men i deler syntes det meg ganske løfteoppgave. På dagen på metrikken - Ved utgangen av året vil det være 250 forskjellige beregninger fra forskjellige domener IB - Svar på hendelser, styring av sårbarheter, rødt lag, personvern, finansforvaltning, IB-overvåking, etterlevelse, etc. I motsetning til sin nåværende kanal "Post Lukatsky", har den nye, inkludert muligheten for kommentarer og diskusjoner, slik at du kan diskutere hver metrisk, dele erfaringer etc.
Så velkommen til den nye telegramkanalen, som vil bli en jevnlig fylt metrisk katalog på IB.
Kilde - Blog Alexei Lukatsky "Bedrift uten fare."
Mer interessant materiale på cisoclub.ru. Abonner på oss: Facebook | VK |. Twitter | Instagram |. Telegram | Zen | Messenger | ICQ Ny | YouTube | Puls.