IT-incidenter

Doping, hacking och politik

Publicerat: 
2016-10-04
12 september startade en gruppering som kallar sig Fancy Bears HT en kampanj för att avslöja att flertalet olympier dopar sig. Följande text publicerades på Twitter.
 
 
 
WADA (World Anti-Doping Agency) har ett system som heter ADAMS, vilket atleter och personal använder för dopingkontroller. Atleterna har genom detta system möjlighet att rapportera in vart i världen de befinner sig. Detta ska göras i block om tre månader, för att WADA ska ha möjlighet att göra dopingtest på atleterna. 
En TUE står för Therapeutic Use Exemption och är ett sätt för atleterna att söka dispenser för medicin som behövs för diverse medicinska åkommor. Det har framkommit för att kunna reglera vissa substanser men ändå inte begränsa atleter som behöver medicin.
 
För att få tillstånd för medicin behöver denna styrkas av läkare och ett antal blanketter behöver skickas in till sitt specifika förbund för den idrotten som atleten tillhör. Förbundet godkänner eller avslår sedan användandet av preparaten och skickar detta till WADA.  Själv har jag diabetes och iom detta behöver jag en TUE för insulin då denna medicin är klassad som doping. Detta tillstånd beviljades då på 4 år vilket är det längsta perioden som WADA ger undantag för medicinering.
 
Fancy Bear har gått ut med att de tänker avslöja olympier och de hävdar att de gör så genom att publicera ett stort antal TUE för att påvisa flertalet länder och idrottare använder sig av legal doping. De gör det genom att ansöka för en TUE och genom detta kunna dopa sig utan att åka fast.
 
WADA hävdade tidigt att grupperingen som utfört attacken var ryssarna via en grupp som kallas APT 28 [2]. De ska ha kommit över ett konto som användes vid de olympiska spelen i Rio. Detta genom att ha utfört en spear phishing attack mot en anställd och genom detta fått full tillgång till ADAMS. Genom detta har de kunnat ladda hem ett stort antal TUE. 
 
APT 28 är enligt FireEye [3] en gruppering från Ryssland som koncentrerar sig på att spionera på strategiska mål för att stjäla information som gynnar en regering. 
 
Detta uttalande har gjort i två omgångar där de första gången utpekade ryssarna och att det troligtvis använt sig av en spear phishing attack. I det senaste uttalandet är inte längre ordet kanske utskrivet utan de benämner det som en attack. 
 
WADA har även tidigare haft ett intrång [4] då kontot till Yuliya Stepanova, visselblåsaren som avslöjade att Ryssland systematisk dopar atleter. Bakgrunden till denna attack säges sig vara att komma över Yuliyas rapportering i ADAMS. Vilket ger tillgång till exakt vart hon befinner sig. 
 
Fancy Bears hävdar sig tillhöra den lössatta grupperingen Anonymous. Kollar vi upp twitter kontot som skapats för Fancy Bear ser vi att det följer vita huset, demokraterna och även Hillary Clinton. 
 
Som WADA skriver är det skrämmande att medicinskdata tillhörande ett stort antal atleter publiceras av grupperingen. Men det som är mer skrämmande är att WADA inte har säkrat upp sitt system och att hacket tillåts i denna omfattning. 
 
Det är även svårt att analysera informationen för att se om det verkligen var ryssarna som hackade WADA. De gick tidigt ut med grupperingen APT 28. Hur de har kommit fram till den informationen har inte delgivits. I senaste pressreleasen har de inte heller namngivit ryssarna som skyldiga[5]. Är det här ett försök att skadereglera efter anklagelserna om statligt sponsrad doping från rysk håll eller bara något annat?
 
 
 
 

 

Skribent(er): 
Petter Stymne

Kort om APT ProjectSauron

Publicerat: 
2016-08-16 16:35

Förra veckan gick flera stora anti-virusföretag med information om att en ny APT-plattform identifierats under hösten 2015 som döpts till ProjectSauron av Kaspersky respektive Remsec av Symantec. APTn misstänks ha varit aktivt sedan 2011. Aktivitet har identifierats i bland annat Ryssland, Kina, Iran, Rwanda, Belgien och även en organisation i Sverige har blivit drabbad. Infektionsvektorn är dock inte känd och den har endast setts användas för att angripa Windows-baserade operativsystem.

ProjectSauron är en modulär plattform som används för cyberspionage, där fler moduler laddas ner vid behov. Plattformen gör det möjligt för en angripare att ta kontroll över ett system och röra sig över nätverk. Modulerna kan exempelvis användas för att lyssna på kommandon över nätverk, öppna bakdörrar, spela in knapptryckingar genom keylogger-moduler samt för att stjäla filer. Det finns närmare 50 olika moduler som ProjectSauron kan utnyttna. För att kommunicera utnyttjar ProjectSauron ett flertal vanliga kommunikationsprotokoll, där DNS-protokollet används i stor utsträckning för att exfiltrera data men även för att rapportera ”status”.

Nätverk som är air-gappade kan också bli angripna av ProjectSauron genom en specifik modul. Denna modul gör det möjligt att från ett air-gappat system flytta data till ett system som är anslutet till internet genom förflytta data med flyttbart USB-media. USB-mediat partitioneras på ett sådant sätt att den inte identifieras av operativsystemet korrekt, vilket medför att data från ett isolerat system kan förflyttas obemärkt och därefter exfiltreras från ett internetanslutet systemet.

ProjectSauron har kunnat agera obemärkt under flera år av tack vare flera olika egenskaper. ProjectSauron körs i många fall inte aktivt utan fungerar som en ”sovande-cell” och väntar på nätverkskommandon för att aktiveras, vissa moduler kör även endast i minnet vilket försvårar upptäckt. För kommunikation används vanligt förekommande kommunikationsprotokoll för att exfiltrera data och skicka statusuppdateringar och på så sätt döljer sig den aktiviteten enkelt bland normal nätverkstrafik.
 

Hur kan man skydda sig?
ProjectSauron förändras beroende på mål, så klassiska signaturer är troligen inte användbara. Men både Kaspersky och Symantec har tagit fram ett antal IoC:er (Indicators of Compromise) utifrån de fall de har undersökt för att identifiera ProjectSauron.
https://securelist.com/files/2016/07/The-ProjectSauron-APT_IOCs_KL.pdf
http://www.symantec.com/content/en/us/enterprise/media/security_response...

Skribent(er): 
Tiina Loukusa Hyttnäs

Om digitala bevis

Publicerat: 
2016-04-06 23:30

En nyligen utgiven doktorsavhandling avseende digitala bevis väckte mitt intresse häromdagen. Avhandlingen ”Om informationstekniskt bevis” av Jonas Ekfeldt tar bland annat upp aspekter gällande korrekt terminologi, felkällor vid framtagning och värdering av digitala bevis samt rättsväsendets behov av nya kunskaper för att kunna behandla digital bevisning på rätt sätt.

En avhandling av denna typ kan även ha ett värde utanför rättsväsendet. Det kan gälla allt från så enkla saker som vilka forensiska verktyg och tekniker som används, hur bevisinsamlingsuppdrag bör formuleras och vilken kompetens som krävs av en forensiker, till hur rättsväsendet ser på olika former av digitala bevis.

Det finns givetvis många former av digitala bevis. I allmänhet tänker vi som arbetar med säkerhet ofta på ett antal fokusområden, exempelvis

• Hur ska vi analysera ett angrepp mot ett av våra egna IT system
• Vad händer om en av våra användare utsätts för dataintrång
• Vad händer om en av våra användare eller kunder tapparsin dator eller mobil

Det finns alltså ett behov av både säkerhetsanalyser och forensiskt kunnande långt utanför den rättsliga arenan. Det händer givetvis också att en verklig händelse leder till polisanmälan och att underlag från berörda IT system lämnas ut i händelse av att en förundersökning inleds.
Inom polisen och de rättsvetenskapliga institutionerna är situationen delvis annorlunda

• Digital information kan användas för spaning (masttömning och samtalslistor)
• En misstänkts dator, dataminnen och mobiler kan undersökas för att ge bevisning
• En misstänks dator eller hemnätverk kan matchas mot spår av dataintrång
• En misstänkts konton kan matchas mot aktiviteter i ett IT system
• Vid behov får man söka hjälp av teleoperatör, bank eller annan berörd organisation

Det är alltså mer vanligt att denna typ av forensiska undersökningar koncentreras till den misstänktes egendom och att resultaten kommer att ifrågasättas av den misstänkte. Exempelvis kan en misstänkt hävda att utrustningen var utlånad, stulen eller fjärrstyrdes varvid en forensisk undersökning ofta tar med dessa aspekter redan vid genomgången.

Det finns redan generella tekniker för att undersöka en misstänkts dator. Exempelvis används normalt en väldefinierad teknik för att klona hårddisken från en beslagtagen dator för att minska risken att forensikern påverkar IT systemet och för att kunna ge en annan expert vid ett senare tillfälle samma möjligheter att gå igenom materialet. Det är också ganska vedertaget vad en forensisk undersökning i dessa fall syftar till, exempelvis att gå igenom bilder, dokumentet, kontakter och meddelanden som skulle kunna knytas till ett misstänkt brott. Givetvis är det viktigt att uppdragsformuleringen är rätt från början, likaså att forensikern väl skiljer mellan egna observationer och egna slutsatser.

Flera av de slutsatser som dras i dessa avseenden i avhandlingen är förhoppningsvis redan naturliga för de som arbetar med granskningar och revisioner av IT system, exempelvis att man måste beskriva vilket uppdrag som erhållits, vilka eventuella omständigheter som ska påvisas (jämför användning av kontrollmål vid en revision), vilken terminologi som använts i det aktuella sammanhanget, vilka observationer som gjorts (vilket data eller loggposter som selekterats fram), vilka slutsatser som kan dras och hur säkra dessa slutsatser är. Detta är i sig inget konstigt, men de skräddarsydda kurser som finns för forensiker tar inte alltid upp dessa aspekter i önskad omfattning.
En annan aspekt är att utvecklingen inom IT området är fortsatt snabb och att rättsväsendet i någon mening alltid måste finna sig i att vara lite grann på efterhand.

Vad finns det då för slutsatser att dra för oss som arbetar med säkerhet av avhandlingen?

För mig var den viktigaste punkten nog att stämma av terminologi och tankesätt mot de som gäller inom det svenska rättsväsendet. Flera av de kunskaper vi har kommer utifrån och är antingen givna av de professionella organisationer vi personligen tillhör eller av de organisationer som tillhandahåller IT produkter eller anvisningar för säker användning av IT produkter. Flertalet av dessa organisationer är givetvis utländska. Vi är därmed vana att arbeta i blandad miljö med både svensk och engelsk terminologi och i de flesta fall även en områdesspecifik fackterminologi.
De rättsliga regler och säkerhetsprinciper vi lärt oss är ofta mer eller mindre globala. Det är då värdefullt att läsa en avhandling på svenska som dessutom utgår från svenska rättsregler även om det tekniska djupet i avhandlingen inte tillför något egentligt nytt. När vi exempelvis använder en forensisk programvara eller följer en undersöknings och rapporteringsmall så är underlagen normalt på engelska och det är då värdefullt att ha ett dokument som använder mer eller mindre vedertagna svenska begrepp eller som avhandlingen kanske snarare avsåg att göra – att redogöra för vilken osäkerhet som finns i dessa begrepp, vilka felkällor man bör ta hänsyn till vid sammanställning av utredningar och hur man ska presentera utredningar med minst risk för juridiska missuppfattningar.

Även sammanställningen i avhandlingen av rättsfall och lagar som berör digitala bevis eller IT system var av ett visst intresse. Samtidigt blir varje sammanställning av denna typ relativt begränsad avseende hur mycket som kan skrivas om varje fall. Det ligger i sakens natur att domar och förundersökningsprotokoll ofta ger en mer detaljerad och kompletterande bild av hur digitala bevis samlas in, används och slutligen värderas.

Min slutsats är avhandlingen hursomhelst är väl värd att laddas hem och ägnas några timmars läsning av den som är intresserad av ämnesområdet även enbart ur ett mer renodlat säkerhetsperspektiv.

Länk till avhandlingen Om informationstekniskt bevis: http://su.diva-portal.org/smash/get/diva2:900594/FULLTEXT05.pdf

Skribent(er): 
Tomas Forsberg

RSAC2016 - Lösenfrasknäckning, samt Hackerspårning med hjälp av Sysinternals SysMon

Publicerat: 
2016-03-24

I början av månaden gick RSA Conference USA 2016 av stapeln i San Francisco. Jag och Mikael var där och höll vår presentation angående mitt/vårt arbete med lösenfrasknäckning med hjälp av Markovkedjor. Vi fick bra respons och många frågor efteråt, och det kändes som att åhörarna tyckte det var intressant, nydanande och att de kommer att få inspiration av vår metod för knäckning av långa lösenordsfraser. Åtminstone kommer de nog tänka till lite extra innan de väljer sin nästa lösenordsfras.

Vår session fick dessutom privilegiet att vara en av de tre som presenterades under rubriken "Agenda & Tracks" på förstasidan på konferensens site, dessutom strax jämte keynotetalaren Sean Penn, bara en sån sak… Nu har de precis ersatt både Sean och oss med andra rubriker, men vi fick pryda huvudsidan i ungefär tre veckor, däribland hela den vecka som konferensen pågick.

Mer information om vårt arbete med knäckning av lösenordsfraser kan hittas via referenserna [2] samt [3]. Rapport finns nu även publicerad på International Association For Cryptologic Research [4].

Givetvis fanns även en hel del andra sessioner som var mycket intressanta, och en av dem som jag kände kunde ha stor praktisk nytta i mitt arbete såväl som privat, var en genomgång av Sysinternals-svitens relativt nya tillskott ”SysMon” (1,5 år gammalt, men ny version ute nyligen). Denna sessions titel var “Tracking Hackers on Your Network with Sysinternals Sysmon”, och jag tänkte här försöka återberätta de intressantare delarna med hjälp av egna ord, kommentarer och tester.

Sysinternals

För den som inte känner till Sysinternals [7], så var det ett företag som skapade en mängd praktiska och kraftfulla freeware-systemverktyg för Windows med hjälp av operativsystemets mestadels odokumenterade nativa API, vilket gör att de ofta kan trolla mer med avancerade funktioner i Windows än verktyg som använder de mer officiella API:erna. Företaget är sedan en bra tid tillbaks uppköpt och en del av Microsoft TechNet, men de lyckades vid övertagandet förhandla fram att hela deras svit skulle vara fortsatt gratis och fritt att använda.

SysMon

Ett av de senare verktygen de tagit fram är alltså SysMon [8], och dessutom släpptes en ny version strax innan RSA-konferensen, så huvudutvecklaren Mark Russinovich var där och presenterade verktyget och dess nya features samt gav en del tips om det.

SysMon är i princip det enda verktyget i sviten som behöver installeras, och det körs sedan som en service som startar automatiskt vid varje systemstart, och loggar vissa systemaktiviteter som kan vara typiska vid exempelvis intrång och/eller malware. Dessa loggar skrivs till en egen sökväg i Windows eventlog, och kan vara till god hjälp både för att upptäcka och spåra konstiga processer/malware samt vid forensikarbete efter ett eventuellt intrång eller virusangrepp.

Aktivitetstyper som kan loggas: (alla är inte påslagna i defaultinstallationen)

1 Process Create
Detaljerad information om startade processer, såsom full kommandorad, processens ID och GUID, filens hashvärde (SHA1 som default, men det går att aktivera andra), användare etc.

2 File Creation Time Changed
När en process i efterhand ändrar tiden för skapande av en fil. Utan filtrering kan detta ge många false positives då exempelvis komprimeringsprogram och webbläsare kan ändra denna tidsstämpel för att den ska matcha originalfilens, men det är även ett vanligt sätt för hackare och malware att dölja sina spår.

3 Network Connection
Loggar nya nätverksanslutningar över såväl UDP som TCP. Här sparas bland annat vilken process som initierade anslutningen, vilket protokoll, IP, port som användes hos såväl mottagare som avsändare, samt i förekommande fall dnsnamn och portnamn.

4 Sysmon Service State Change
Loggning vid ändring av körstatus på själva SysMons service. Här kan man alltså se om och när SysMon stängts av eller satts igång.

5 Process Terminated
Processens ID och GUID, samt aktuell tid anges här för en process som avslutats.

6 Driver Loaded
Loggar laddade drivrutiner med information om vilken avbild som använts, dess hashvärde(n), samt om den är signerad och i sådant fall av vem.

7 Image Loaded
Logg över vilka moduler (dll-filer) som laddas av olika processer. Logghändelsen innehåller information om processens ID, GUID samt sökväg till avbild, den laddade modulen och dess hashvärde(n) samt om den är signerad och i sådant fall av vem.
Denna loggning är avstängd i grundinställningarna och bör användas med försiktighet då det även vid vanlig användning skapas väldigt många sådana här event. På 2,5 minuter loggades 480 händelser när jag testade denna funktion. Denna loggning kan vara bäst att använda för att med hjälp av config-filen filtrera på och bevaka någon speciell process eller modul.

8 CreateRemoteThread
Loggar när en process skapar en tråd i en annan process. Detta är vanligt att angripare/malware gör för att exempelvis använda sig av andra processer för att hålla sig dolda eller eskalera sin behörighet. Dock finns det också legitim användning även av denna metod.
Loggar innehåller diverse information om källprocess, målprocess, samt vilken adress i minnet tråden startades på.

9 RawAccessRead
Skapar loggar över direktläsning av diskar/volymer. Detta är vanligt bland malware i försök att kringgå filsystemets normala säkerhetsskydd för filer etc.  

255 Error
Om något fel inträffar i själva SysMon loggas det som en händelse av denna typ.

Sökning av hashvärden i Virustotal

En fils beräknade hashvärde kan ses som ett (i princip) unikt globalt ID för filen. Ett mycket användbart sätt att använda de hashvärden som sparas i SysMons loggar, är att göra en sökning på dem på exempelvis siten virustotal [10], för att få en indikation på om det aktuella programmet är pålitligt eller ej.

Nedan visas ett exempel på en sökning av en process startad av taskeng.exe (som normalt startar schemalagda uppgifter):

I eventet på bilden ser vi en hel del information om den startade processen, såsom användare som startade den, vilken sökväg den startades på, vilken kommandorad den startades med, information om den överordnade processen etc. Enligt denna information i eventet kan man skapa en hypotes om att det antagligen är en schemalagd uppdatering för Flash som startats, men eftersom vi är misstänksamma av oss vill vi bekräfta detta. I eventet hittar vi även hashvärden för processens fil, något av dessa använder vi i nästa steg för att på virustotal.com verifiera filens ursprung, samt om den kan vara skadlig.

SHA1-värdet som är markerat i bilden ovan klistrar man enkelt in på virustotal (fliken "Sök"/"Search") enligt bild nedan:

Just denna fil verkar enligt virustotal rätt ofarlig enligt sökresultatet:

Sökresultat visar att den aktuella filen inte är flaggad som direkt farlig

Man kan även exempelvis se på fliken "File Detail" att filen tillhör Flash Player Update Service, och är signerad av Adobe/Verisign, vilket ytterligare bekräftar vår initiala hypotes.

Filen är signerad av Adobe/Verisign, och tillhör Flash uppdateringstjänst.

Om man nu anser att ett program som Flash är pålitligt och oskadligt (!?), så kan man nu pusta ut och avfärda sin misstänksamhet mot denna processtart.

Installation/konfiguration

Installationen av SysMon sker genom att, efter nedladdning/uppackning, som administratör köra exempelvis kommandot:

sysmon –accepteula –i

Detta installerar SysMon med defaultkonfiguration, vilket innebär att endast SHA1-hashvärden beräknas för de filer som förekommer i loggarna, samt att loggning av nätverksanslutningar (eventID 3) och modulladdning (eventID 7) är avstängda. Med -accepteula slipper man dessutom popuprutan med licensavtalet, vilket vi antagligen sett förut då det är samma för samtliga sysinternalsverktyg.

Det finns ett fåtal ytterligare alternativ man kan sätta antingen direkt vid installationen, eller efteråt med nedanstående kommando.

sysmon –c [alternativ]

med de alternativ man vill ha (om man inte ger ytterligare alternativ visas nuvarande konfig).

Exempel kan vara att man vill att alla stödda typer av hashvärden (sha1, sha256, md5, imphash) skall visas för de filer som förekommer i eventen, vilket fås av kommandot

sysmon –c –h *

för att aktivera loggning av nätverksanslutningar lägger man till –n

för att aktivera loggning av modulladdningar lägger man till –l (med eventuell påföljande lista på målprocesser att övervaka, för att slippa överflödsinformation)

Konfigurationsfil och filtrering

För att ha större kontroll och lättare kunna göra mer avancerade inställningar, speciellt filtrering, är det dock smidigare att först skapa en konfigurationsfil som man sedan laddar genom kommandot

sysmon –c [sökvägtillkonfigfil].xml

Filen skall vara i xml-format, och här ges ett exempel med en del mer eller mindre användbara filter (gjorda mest för illustration), några kopierade från [6].
 

<Sysmon schemaversion="2.01">
 
  <!--Inkludera alla typer av hashvärden-->
  <HashAlgorithms>*</HashAlgorithms>
 
  <EventFiltering>
 
  <!--Logga bara inkommande anslutningar eller till port 443-->
    <NetworkConnect onmatch="include">
      <Initiated condition="is">false</Initiated>
      <DestinationPort condition="is">443</DestinationPort>
    </NetworkConnect >
 
    <!--Logga bara trådinjektioner i lsass eller winlogon-->
    <CreateRemoteThread onmatch="include">
      <TargetImage condition="image">lsass.exe</TargetImage>
      <TargetImage condition="image">winlogon.exe</TargetImage>
    </CreateRemoteThread >
 
    <!--Strunta i att logga start av moduler signerade av Microsoft-->
    <ImageLoad onmatch="exclude">
      <Signature condition="contains">microsoft</Signature>
      <Signature condition="contains">windows</Signature>
    </ImageLoad>
 
    <!--Ignorera filtidsändringar gjorda av chrome och 7zip-->
    <FileCreateTime onmatch="exclude">
      <Image condition="end with">chrome.exe</Image>
      <Image condition="contains">7zip</Image>
    </FileCreateTime>
 
    <!--Stäng av loggning av avslutade processer (för att vi inkluderar ingenting)-->
    <ProcessTerminate onmatch="include" />
 
  </EventFiltering>
</Sysmon>

 

Man kan filtrera på vilka fält man vill i eventen, och villkoren kan vara exempelvis vad fältet ska innehålla, sluta med, vara lika med, vara lägre/högre än m.m.

För att helt sätta på eller stänga av loggning av en händelsetyp, använder man ”exclude” respektive ”include” utan att specificera några filter. Det känns kanske fel att stänga av all loggning genom att skriva ”include”, men det är ju för att listan på händelser man ska inkludera är tom (se sista regeln i exempelfilen ovan).

Konfigurationsfilen är riktigt användbar om man vill sålla bort ointressanta händelser (false positives), eller enbart vill leta efter/övervaka en mycket specifik händelse.

För mer info och detaljer om konfigurationsfiler rekommenderas framför allt Marks slides [6] från RSA-konferensen.

Central loggning/övervakning

Windows eventloggar är inte är särskilt skyddade mot manipulering/radering om nu en angripare väl tagit kontroll över den lokala datorn, så för att skydda loggarna och dessutom för att få en central övervakning/loggning så är det relativt enkelt att integrera med exempelvis Splunk eller Microsoft OMS för att skicka iväg och spara loggarna centralt. Vid en sådan setup kan man bland annat skapa dashboards och larm baserat på informationen från SysMons loggar från samtliga datorer i nätverket, och exempelvis korrelera händelser från olika datorer för att skapa larm etc. Hur man skapar en sådan setup är något beroende av det övervakningsprogram man valt, men det finns länkar och mer info om integrering med Splunk eller OMS i bland annat [6] och [9].

Slutsats

Som de flesta andra i Sysinternals svit, är Sysmon ett verktyg med stor användbarhet för Windowsanvändare/administratörer/säkerhetsspecialister etc.

SysMon är ett intressant verktyg bara att köra lokalt, men det har ännu större potential om man i en företagsmiljö installerar det på samtliga datorer och sätter upp en nätverksspännande övervakning. Då kan dess loggar användas för exempelvis central larmning och dashboards, och vara till oerhörd stor hjälp vid såväl upptäckt som spårning/forensisk utredning vid incidenter som malware eller hackerintrång som spridit sig via nätverket, vilket inte är helt ovanligt för APT exempelvis.

Även om vi säkerhetsfolk brukar gilla ordentlig loggning så kan det ibland gå till överdrift, så lite tid och tanke bör nog läggas på att konstruera en konfigurationsfil som filtrerar bort vissa händelser för att inte överflöda loggutrymmet med ointressanta loggar.

Slutord och rekommendation blir: Installera och testa SysMon, för en vacker dag kommer även du den bäste att råka ut för någon slags incident som detta verktyg kan vara till god hjälp vid.

Referenser/länkar:

[1] – RSA Conference USA 2016, http://www.rsaconference.com/events/us16

[2] – Session: Linguistic Passphrase Cracking, https://www.rsaconference.com/events/us16/agenda/sessions/2396/linguistic-passphrase-cracking

[3] – Post Passwords 2015 - Phraser release on Github (earlier blogpost related to our talk), http://www.simovits.com/blogg/post-passwords-2015-conference-phraser-release-github

[4] – International Association For Cryptologic Research, Report 2016/246 - Linguistic Cracking of Passphrases using Markov Chains, https://eprint.iacr.org/2016/246

[5] – Session: Tracking Hackers on Your Network with Sysinternals Sysmon, https://www.rsaconference.com/events/us16/agenda/sessions/2461/tracking-hackers-on-your-network-with-sysinternals

[6] – Slides: Tracking Hackers on Your Network with Sysinternals Sysmon, https://www.rsaconference.com/writable/presentations/file_upload/hta-w05-tracking_hackers_on_your_network_with_sysinternals_sysmon.pdf

[7] – Sysinternals website, www.sysinternals.com or https://technet.microsoft.com/sysinternals/

[8] – SysMon info & download, https://technet.microsoft.com/sysinternals/sysmon

[9] – SysMon/Splunk integration, http://blogs.splunk.com/2014/11/24/monitoring-network-traffic-with-sysmon-and-splunk/

[10] – Virustotal search, https://www.virustotal.com

Skribent(er): 
Peder Sparell

Statliga myndigheter ska rapportera allvarliga IT-incidenter från april 2016

Publicerat: 
2015-12-21

I tidigare blogginlägg har regeringens initiativ inom informations- och cybersäkerhetsområdet belysts. Regeringen har nu tagit beslutet att från den 1 april 2016 införa regler för att förbättra samhällets informationssäkerhet och krisberedskap1. Reglerna styr obligatorisk rapportering för statliga myndigheter, till exempel avseende störningar i driftmiljöer till följd av hackerattacker.

Bakgrund

I takt med ökad användning av IT i samhället ökar även sårbarheter. Idag sker ingen systematisk identifiering eller hantering av allvarliga IT- incidenter som har påverkat enskilda användare eller samhällsviktig verksamhet. Det bedöms finnas ett stort mörkertal då många incidenter inte upptäcks2. Följdeffekterna då organisationer drabbas riskerar att bli stora eftersom aktörer inte informeras så att de kan hinna agera i tid. Informationsbristen och denna saknade helhetsbild av samhällsläget försvårar beslutsfattande då beroenden och totala effekter ska bedömas. I ljuset av detta bedöms det därför nödvändigt att införa regler för obligatorisk inrapportering av incidenter som allvarlig påverkar myndigheters verksamhet.

Reglerna införs genom förordningen om krisberedskap och bevakningsansvariga myndigheters åtgärder vid höjd beredskap (2015:xxx). Förordningen blir offentlig när den kungjorts i svensk författningssamling.

Mervärdet med ett system för IT-incidentrapportering

Vilka fördelar förväntas då en enhetlig rapportering av incidenter ge?

  • Förbättring av samhällets informationssäkerhet och krisberedskap
  • Förtydligande av statens ansvar för informationssäkerhet
  • Möjlighet att agera förebyggande: varna aktörer och reducera konsekvenserna av inträffade incidenter
  • Statistiskt underlag för analys och samlad lägesbild över IT-incidenter i samhället
  • Återkoppling och stöd till aktörer
  • Möjlighet till riktade förebyggande insatser, lärdomar av incidenter, samt minskning av  mörkertalet
  • Minskad risk för att kopplingar mellan IT-incidenter förbises på grund av bristande information

Regler för rapporteringen

För att uppnå önskat resultat med systemet krävs en struktur för rapporteringen: När den ska ske, vad som ska omfattas i rapporteringen, och vilka krav som ska ställas på förfarandet. Myndigheten för samhällsskydd och beredskap (MSB) har givits uppdrag av regeringen att ta fram föreskrifter för detta, vilka nu remitteras3. Föreskrifterna beskriver bl.a.:

  • Definitioner av IT-incidenter: störningar i mjuk och hårdvara, driftmiljöer, dataförlust eller dataläckage
  • Kategorisering av möjliga orsaker: brister i produkter, externa attacker, mänskligt fel vid användning, intern eller extern händelse (t.ex. säkerhetskopiering eller strömavbrott)
  • Inrapportering inom 24h efter upptäckt
  • Rapportinnehåll (t.ex. beskrivning, kategorisering, skadebedömning och omfattning)
  • Kompletteringskrav om uppgifter som behövs för att klarlägga hur IT-incidenten kan påverka säkerheten i den informationshantering som myndigheten ansvarar för, eller i tjänster som myndigheten tillhandahåller åt en annan organisation
  • Myndighetsansvar för rapportering även om utkontraktering sker

Föreskrifterna är nationella, och omfattar endast statliga myndigheter. När det s.k. NIS-direktivet ska genomföras i svensk rätt kommer rapporteringskrav även gälla vissa andra aktörer t.ex. privata företag.

Värt att notera är att det är regeringens förordning (2015:xxx) som styr vad som är rapporteringspliktiga incidenter.  

Vilka instanser ska rapporteringen ske till

Inrapportering ska ske till MSB, med undantag för vissa uppgifter. Det som exempelvis rör rikets säkerhet eller för system som behöver skyddas mot terrorism rapporteras till Säkerhetspolisen eller Försvarsmakten.

Vilka konsekvenser får detta för myndigheter

MSB gör bedömningen att påverkan blir störst för de myndigheter som idag inte bedriver systematiskt informationssäkerhetsarbete. Processer och rutiner kan behöva anpassas, exempelvis då verksamhet utkontrakterats. Dock förväntas inte kostnader bli alltför höga, då exempelvis enbart rapportering av allvarliga incidenter omfattas, och mängden rapporteringsinformation är anpassad efter skyndsamhetskravet på 24 timmar. Detta gäller under förutsättning att organisationen redan idag arbetar systematiskt med informationssäkerhet.     

Referenser

[1] http://www.regeringen.se/pressmeddelanden/2015/12/regeringen-infor-krav-pa-it-incidentrapportering-for-statliga-myndigheter/

[2] https://www.msb.se/Upload/Om%20MSB/Lag_och_ratt/Konsekvensutredningar/Konsekvensutredning%202015-5108.pdf

[3] https://www.msb.se/Upload/Om%20MSB/Lag_och_ratt/Remisser/Remiss%20f%C3%B6reskrifter%20%20allm%C3%A4nna%20r%C3%A5d%20it-incidentrapportering%202015-5108%20%282%29.pdf

 

 

Skribent(er): 
Filip Crona

Statliga myndigheter ska rapportera allvarliga IT-incidenter från april 2016

I tidigare blogginlägg har regeringens initiativ inom informations- och cybersäkerhetsområdet belysts. Regeringen har nu tagit beslutet att från den 1 april 2016 införa regler för att förbättra samhällets informationssäkerhet och krisberedskap1. Reglerna styr obligatorisk rapportering för statliga myndigheter, till exempel avseende störningar i driftmiljöer till följd av hackerattacker.

Bakgrund

I takt med ökad användning av IT i samhället ökar även sårbarheter. Idag sker ingen systematisk identifiering eller hantering av allvarliga IT- incidenter som har påverkat enskilda användare eller samhällsviktig verksamhet. Det bedöms finnas ett stort mörkertal då många incidenter inte upptäcks2. Följdeffekterna då organisationer drabbas riskerar att bli stora eftersom aktörer inte informeras så att de kan hinna agera i tid. Informationsbristen och denna saknade helhetsbild av samhällsläget försvårar beslutsfattande då beroenden och totala effekter ska bedömas. I ljuset av detta bedöms det därför nödvändigt att införa regler för obligatorisk inrapportering av incidenter som allvarlig påverkar myndigheters verksamhet.

Reglerna införs genom förordningen om krisberedskap och bevakningsansvariga myndigheters åtgärder vid höjd beredskap (2015:xxx). Förordningen blir offentlig när den kungjorts i svensk författningssamling.

Mervärdet med ett system för IT-incidentrapportering

Vilka fördelar förväntas då en enhetlig rapportering av incidenter ge?

  • Förbättring av samhällets informationssäkerhet och krisberedskap
  • Förtydligande av statens ansvar för informationssäkerhet
  • Möjlighet att agera förebyggande: varna aktörer och reducera konsekvenserna av inträffade incidenter
  • Statistiskt underlag för analys och samlad lägesbild över IT-incidenter i samhället
  • Återkoppling och stöd till aktörer
  • Möjlighet till riktade förebyggande insatser, lärdomar av incidenter, samt minskning av  mörkertalet
  • Minskad risk för att kopplingar mellan IT-incidenter förbises på grund av bristande information

Regler för rapporteringen

För att uppnå önskat resultat med systemet krävs en struktur för rapporteringen: När den ska ske, vad som ska omfattas i rapporteringen, och vilka krav som ska ställas på förfarandet. Myndigheten för samhällsskydd och beredskap (MSB) har givits uppdrag av regeringen att ta fram föreskrifter för detta, vilka nu remitteras3. Föreskrifterna beskriver bl.a.:

  • Definitioner av IT-incidenter: störningar i mjuk och hårdvara, driftmiljöer, dataförlust eller dataläckage
  • Kategorisering av möjliga orsaker: brister i produkter, externa attacker, mänskligt fel vid användning, intern eller extern händelse (t.ex. säkerhetskopiering eller strömavbrott)
  • Inrapportering inom 24h efter upptäckt
  • Rapportinnehåll (t.ex. beskrivning, kategorisering, skadebedömning och omfattning)
  • Kompletteringskrav om uppgifter som behövs för att klarlägga hur IT-incidenten kan påverka säkerheten i den informationshantering som myndigheten ansvarar för, eller i tjänster som myndigheten tillhandahåller åt en annan organisation
  • Myndighetsansvar för rapportering även om utkontraktering sker

Föreskrifterna är nationella, och omfattar endast statliga myndigheter. När det s.k. NIS-direktivet ska genomföras i svensk rätt kommer rapporteringskrav även gälla vissa andra aktörer t.ex. privata företag.

Värt att notera är att det är regeringens förordning (2015:xxx) som styr vad som är rapporteringspliktiga incidenter.  

Vilka instanser ska rapporteringen ske till

Inrapportering ska ske till MSB, med undantag för vissa uppgifter. Det som exempelvis rör rikets säkerhet eller för system som behöver skyddas mot terrorism rapporteras till Säkerhetspolisen eller Försvaret.

Vilka konsekvenser får detta för myndigheter

MSB gör bedömningen att påverkan blir störst för de myndigheter som idag inte bedriver systematiskt informationssäkerhetsarbete. Processer och rutiner kan behöva anpassas, exempelvis då verksamhet utkontrakterats. Dock förväntas inte kostnader bli alltför höga, då exempelvis enbart rapportering av allvarliga incidenter omfattas, och mängden rapporteringsinformation är anpassad efter skyndsamhetskravet på 24 timmar. Detta gäller under förutsättning att organisationen redan idag arbetar systematiskt med informationssäkerhet.     

Referenser

[1] http://www.regeringen.se/pressmeddelanden/2015/12/regeringen-infor-krav-pa-it-incidentrapportering-for-statliga-myndigheter/

[2] https://www.msb.se/Upload/Om%20MSB/Lag_och_ratt/Konsekvensutredningar/Konsekvensutredning%202015-5108.pdf

[3] https://www.msb.se/Upload/Om%20MSB/Lag_och_ratt/Remisser/Remiss%20föreskrifter%20%20allmänna%20råd%20it-incid3

 

Skribent(er): 
Filip Crona