for en måned eller to siden havde jeg en diskussion med en læge om obskure sygdomme — ofte omtalt som sebraer. Mens jeg overvejede disse sebras i forbindelse med effektive data mining strategier til medicinsk diagnose, gjorde han et interessant punkt. En af de ting, de lærer nye læger, er udtrykket “når du hører hoveder, tænk hest, ikke Sebra.”Princippet er ret simpelt-oddsene er, at patienten har den mere almindelige diagnose end en sjælden, usandsynlig. Et simpelt, men illustrativt eksempel ville være følgende (stjålet fra en læge familiemedlem):
en ung kvindelig patient præsenterer en tre ugers historie med hovedpine, træthed og intermitterende feber, men var historisk sund. Den fysiske eksamen var umærkelig og bortset fra lejlighedsvis feber, det eneste symptom på note var, at hun var bleg i farven. Sebra kunne have været meningitis eller en hjernesvulst — og den uerfarne praktiserende læge ville bestille tusindvis af dollars af tests og udsætte patienten for flere procedurer. Men et rutinemæssigt blodtal viste, at hun simpelthen var anæmisk — hesten — og bare havde brug for ekstra jern. Reglen: tænk hest uden at udelukke sebras.
dette princip om, hvordan vi som mennesker har tendens til at overkomplicere ting, resonerer med mig, men for en helt anden sektor, der har været fremtrædende i nyhederne om sen cybersikkerhed.
for at overveje dette problem, lad os diskutere tre lignende vira af computersorten, også kendt som computerorm.
vores første orm kaldes “kode rød”. Dette var en virus, der kunne udføre vilkårlig kode en gang på værtens system. Derudover ville ormen inficere en server og vise følgende meddelelse:
og selvfølgelig ville ormen se ud til at sprede sig og finde andre infectable værter i unpatched maskiner. En patch til denne sårbarhed var blevet tilbudt en måned før Code Reds angreb, men få institutioner installerede det. Dette forårsagede betydelig hovedpine og forlegenhed for IT-afdelinger i flere sektorer.
vores anden orm er Nimda. Nimda kunne overføre sig til en computer fem forskellige måder, herunder e-mail. Det blev en af de første orme, der kunne udføre sin kode, selvom værten ikke åbnede den inficerede e-mail. Nimda stoppede føderale domstolsarbejdere fra at få adgang til domstolsfiler elektronisk, og de inficerede retsdokumenter skulle rengøres en efter en. Nimda, ligesom kode rød, udnyttet en allerede lappet vinduer sårbarhed. Alligevel forårsagede det betydeligt bredere skader på grund af de mange indgangspunkter og hurtig spredning.
vores tredje orm er Vannacry. Ligesom med de sidste to orme, Microsoft havde tilbudt en patch, der ville have beskyttet mod truslen. Der er dog en smule detaljer her, der er relevant: en patch blev ikke oprindeligt udstedt til operativsystemet. Der var en vis bruger frustration med dette, men det skal bemærkes, at
brugeren havde valget mellem at betale “løsepenge” eller miste adgangen til deres filer permanent. Samtidig ville ormen fortsætte med at forsøge at sprede infektionen til andre maskiner, der havde den upatchede sårbarhed. Heldigvis var der en “dræb-kontakt”, som en smart ondsindet forsker identificerede og aktiverede, og meget af ormens potentiale blev aldrig realiseret.
da jeg var færdig med dette indlæg, begyndte en ny løsepenge-udnyttelse kaldet Petya at inficere systemer over hele kloden. Per TechCrunch, ” alt ved denne situation indikerer, at masser af regeringer og virksomheder over hele verden ikke tog Vannacry alvorligt, undlod at lappe deres systemer og betaler nu prisen.”
som Brian Krebs sagde, ” organisationer og enkeltpersoner, der endnu ikke har anvendt vinduerne opdatering til den evige blå udnytte bør lappe nu. Der er dog tegn på, at Petya kan have andre tricks i ærmet for at sprede sig inde i store netværk.”Dette antyder, at Petya simpelthen kan være åbningssalven, alt sammen som følge af dårlig patching praksis.
den røde tråd bag alle disse udnyttelser er, at systemer ikke straks blev lappet og derfor blev udsat for disse orme. Disse var faktisk forebyggelige problemer. Men hvad der gør dette virkelig interessant er, at de første orme var i 2001, og den sidste var i 2017. Hvordan er det, at 16 år senere, vi oplever det samme problem?
i slutningen af 1990 ‘erne og begyndelsen af 2000’ erne, da vi byggede OpenTable, overvejede vi aldrig spørgsmål om cybersikkerhed, da vi var så fokuserede på hyperscaling af virksomheden, og de kendte trusler var minimale. Imidlertid, lidelse gennem Nimda og Code Red fik mig til at vågne op. Jeg gik til vores bestyrelse på OpenTable og orienterede dem om de nye trusler i cyberrummet, og hvordan vores netværk kunne være sårbart over for det. Det vil direkte påvirke stabiliteten, skalerbarheden og integriteten af vores forretning, og derfor bør vi investere i at gøre det mere sikkert. Jeg fortalte for en sikkerhedsplan med fokus på at gøre sikkerhedsgrundlaget godt, og det blev finansieret. Mens sikkerhed forblev et løbende problem, og jeg er sikker på, at det bekymrer de OpenTable folk i dag, blev det i det væsentlige en løst proces, og vi var i stand til at bygge videre på et stabilt fundament.
kernen bag den grundlæggende tilgang var enkel. Patch dine systemer i tide, kontrollere, hvad der kan ses af internettet og korrekt tilladelse systemer. En bruger skal have minimumstilladelser til at opnå det, de har brug for. Denne grundlæggende tilgang forhindrer bemærkelsesværdigt en enorm mængde sikkerhedseksponering. Dette er den” hest ” tilgang.
denne følelse blev gentaget i en nylig O ‘ Reilly Security podcast, “Dave Levis on the tenacity of solvable security problems”. “For tyve år siden, da jeg begyndte at arbejde i sikkerhed, havde vi et defineret sæt af ting, vi var nødt til at håndtere løbende. Efterhånden som vores miljøer udvides med ting som cloud computing, har vi taget det centrale sæt bekymringer og ganget dem plus, plus, plus. Ting, som vi burde have gjort godt for 20 år siden — som patching, asset management — er blevet langt værre på dette tidspunkt. Vi har vokset vores sikkerhedsgæld til uhåndterlige niveauer i mange tilfælde. Mennesker, der er ansvarlige for at lappe, ender med at overføre denne pligt til den næste juniorperson i kø, når de bevæger sig fremad i deres karriere. Og at junior person til gengæld sender det videre til hvem der kommer op bag dem. Så, patching har tendens til at være noget, der er shunted til vejkanten. Som følge heraf fortsætter problemet med at vokse.”
historiens moral er, at vi er nødt til at vende tilbage til det grundlæggende for at stoppe denne mangel på fremskridt på et kritisk område. Da jeg var Chief Information Officer (CIO) i Chicago, brugte jeg betydelig tid og kræfter på at opbygge et cybersikkerhedsprogram. Desværre, på alle regeringsniveauer, der er et område, der forbliver underbemandet, undertænkt og underressourcer. Da vi innoverer og flytter til flere digitale systemer, er det et af de mest kritiske spørgsmål, som regeringen skal regne med.
på trods af de åbenlyse fordele ved en hestetilgang til sikkerhed, da CIO i konstant blev spærret af leverandører, der tilbyder højt specialiserede systemer til meget specifikke brugssager. Jeg nægtede at gøre disse typer af Sebra udgifter, når jeg ikke engang kunne dække for hesten. Så vi startede et program med fokus på fundamentet og byggede derfra, når det var praktisk.
agenturer skal overveje disse grundlæggende cyberhygiejnetrin som et fundament for at gøre kritiske fremskridt:
- Hold dig opdateret om patching og gør det til en afdelings — /agenturprioritet-det er kedeligt, men det er effektivt.
- korrekt tilladelsessystemer med de nødvendige minimumstilladelser.
- Brug altid SSL til internettrafik. https://https.cio.gov/
- agenturets direktør har brug for en senior cybersikkerhedsressource, der forstår teknologi.
der er ingen undskyldning for at lade historien gentage sig. Den dårlige praksis for ti år siden bør ikke fortsætte med at plage organisationer i dag, og den mest effektive måde at forhindre morgendagens cyberangreb er at satse på hesten.