It-Säkerhetspolicy

Hej!

Jag håller på med ett projektarbete och skulle behöva hitta någon med bra tips och spåna kring innehållet i en säkerhetspolicy...

Det jag undrar är egentligen hur ni skulle välja att sätta upp en sådan, hur man ska gå tillväga efter att ha analyserat företagets behov och tillgångar.

Är verkligen inte ute efter facit, utan mer en öppen diskussion med människor, än att läsa 250 artiklar med spridda ändamål.

Det är ett litet företag med 25 anställda, har en databas med kundregister etc. Ett projekt inom företaget som är känsligt och viktigt att hålla från utomstående.

/har redan lagt upp vad som är viktiga punkter. Så som kommunikation, programanvändning, externa enheter etc...etc...

Tackar för svar.... pis

Incidenthantering kan vara viktigt. Det handlar om vad de anställda ska göra om de upptäcker att de håller på att bli attackerade. Detta beror helt på vad du anser är viktigt och vad som passar företaget, men att ha en syslogserver och möjligheter att kunna stänga av nätet för utomstående tycker jag är bra. Splunk är bra för loghantering och enkelt att arbeta med.

Kryptering är givetvis en självklarhet, men implementationen är viktig. Är ingen expert på databashantering men salt och peppar bör appliceras på all data samt väldigt strikta regler på vad och vem som får hämta datan. Att vara bakom en separat brandvägg behövs.
Backups ska göras så många gånger som det behövs, dvs efter varje specifik mängd adderad data.

Social engineering är något många glömmer. Se till att endast de som verkligen behöver rättigheter ska ha det! Fundera väldigt länge på användarhierarkin och låt varje användare fatta sina egna beslut, det innebär att uppdrag inte ska skickas vidare för att tas hand av en annan användare. Får en användare inte göra en sak så ska det vara ett nej, inget annat.
Att ha denna hierarkistege dold är viktigt, så publicera inte vem som är vad öppet på nätet.

De enheter som är öppna mot nätet ska inte vara ansluta mot det interna nätverket. Det ska vara separata enheter för det. Att vara anslutet mot nätet öppnar upp för så himla många attackvektorer.

Det verkar som du har koll på det andra, t.ex externa enheter och kommunikation. Men vill du ha mer specifika tips på det jag skrivit ovan så hojta till.

Lycka till med ditt projektarbete för övrigt!

Jag skulle satsa på att separera den känsliga informationen (databasen och det hemliga projektet) och placera denna på separat enhet.

Det kan göras på lite olika sätt, men grunden ligger i att du helt enkelt har olika säkerhetspolicy för de "känsliga" datorerna och de "normala" datorerna.

Ha "airgap" mellan den känsliga miljön och den okänsliga.
Alternativt kan "airgappet" utgöras av en så kallad "Data diode", en enhet eller brandägg som tillåter trafik att flyta i endast en riktning, från den okänsliga miljön till den känsliga.

På så sätt så kan man ha en relativt slapp IT-säkerhetspolicy för de datorer som inte ingår i den känsliga miljön, och ha en relativt hård IT-säkerhetspolicy för de känsliga datorerna.
Man kan också med olika 802.11x autensiteringar, och switchkonfigurationer, göra så att man kan via en bootmeny boota in i antingen den okänsliga eller den känsliga miljön, varav du har stark autensitering för den känsliga miljön.

En fördel med att separera den känsliga och okänsliga miljön är att du inte behöver så mycket säkerhet i den okänsliga miljön. I den okänsliga miljön kan du typ ge användarna fulla rättigheter, typ adminrättigheter, och om det är viktigt att datorerna fungerar så satsa på ett "skrivskyddat" windowsystem istället - lite som en live-CD - alla ändringar försvinner vid omstart.
I den känsliga miljön bör du ha det ordentligt nedlåst, i stort sett det enda som ska gå göra på dem känsliga datorerna, är just känsliga saker.

Ha en tydlig varning när man är inloggad i den känsliga miljön, så att inte en användare råkar ta den känsliga miljön för att vara den okänsliga.

Se till att kryptera de känsliga datorerna med FDE (heldiskkryptering).
Ha inte "skärmlås" på de känsliga datorerna, istället, satsa på att vid inaktivitet (säg 5 minuter) köra kommandot 'shutdown /s /f /t 10 /c "Rör på musen för att återaktivera datorn"', och när aktivitet återfås, 'shutdown /a'.
detta kan enkelt implementeras via lokal schemaläggare eller via en gruppolicy.
Om användaren är inaktiv i säg 5 minuter och inte rör på musen inom 10 sek efter att varningen dyker upp så kommer datorn att avsluta windows och sedan stängas av.
Detta gör att ev krypteringsnycklar nollas och att datorn förblir krypterad.

Stäng av funktionen "lås datorn" & "Logga ut" med en gruppolicy. Tvinga användarna att stänga av datorn för att säkra den.

Jag skulle inte säga att .Chloe's råd är så vettigt med att man inte ska få skicka vidare ärenden. Det är ju just det som är nödvändigt om användaren ifråga inte har rättigheter. Men man bör inte själv skicka vidare ärendena, utan den som ringer eller vill ha något gjort måste i så fall gå vidare själv.

Ex: Kund ringer och
"Hej. Jag skulle vilja ändra faktureringsadressen. Går det bra?"
"Nej, tyvärr, jag har inte behörighet att ändra i kundregistret, men du kan ringa våran chef, på 08-xxxxxx så fixar han det åt dig."

Det är då Chefens ansvar att verifiera kundens identitet.

Det man dock INTE bör göra, är att anställda själva ringer upp chefen och ber han göra vad som nu krävs. Problemet som uppstår då, är att chefen kan tro att man redan verifierat kundens identitet, men så har man inte gjort det = man är offer för SE.
Viktigt att tydliggöra vad för verifieringar de anställda med behörigheter skall göra om någon ringer och vill ha något gjort.

En annan sak: Tillåt aldrig hemlig information att lämna företagets väggar. Anse information som en användare sett med sina ögon, som "läckt". Med andra ord, ge inte behörigheter till anställda du inte litar på. Förvänta dig om att en oärlig anställd kan tänkas ta med sig information hem med penna+papper eller huvudet. Det kan inget loggsystem eller liknande i världen upptäcka.

Om en anställd gjort något dumt och ska få en reprimand, dra in alla behörigheter till den känsliga miljön i FÖRVÄG. Med andra ord, dra in behörigheterna innan den anställde ifråga märker att han gjort något dumt och kommer få en reprimand. Till exempel: En användare har haft för mycket svinn i kassan denna månaden. Han skall nu få en skriftlig varning och löneavdrag.
INNAN du ens påtalar svinnet eller informerar om att han kommer få varning/löneavdrag, så ta bort alla behörigheter ur den känsliga systemet för honom/henne, sedan ge varningen/löneavdraget.

Just anställda som får påbackning är sådana anställda som kan få för sig att medvetet läcka företagets info för att sabba.

Fysisk IT-säkerhet är viktigt också. Lås in känsliga datorer, papper, saker m.m. Gärna med passersystem. Skrivare och sådant bör låsas in också och bara de som har rätt att se känslig information, ska kunna komma in i skrivarrummet, annars finns risken att känslig information blir liggande så obehöriga kommer åt den.
Om andra anställda som inte har behörighet till den känsliga miljön behöver kunna skriva ut, ha en "okänslig" skrivare som inte är åtkomlig från den känsliga miljön.

Fast nu har du missuppfattat vad jag menade med "inte får föra vidare uppdraget". Givetvis ska inte chefen säga åt kunden att ringa en person som har ansvar för det utan chefen i detta fall ska säga att h*n inte har befogenheten att ändra kundens befogenheter, sen ska aldrig hierarkistegen exponeras då det öppnar upp för SE-attacker.

Ett enkelt nej och sen kan chefen internt föra över uppdraget till den som har ansvaret. Allt kunden ska få veta är att chefen inte har de rättigheterna, inget mer.

Läs rubrikerna i ISO 27002 och kolla att du inte missar något.
Du kommer nog få tips på detaljer av andra här på flashback men försök att hålla policyn som en policy och om det behövs lägger du till detaljer i regler och rutiner.
/aleph0

Det är en stor och knepig fråga eftersom en säkerhetspolicy är en väldigt individuell policy efter behov, krav samt hur situationen ser ut i en organisation.
Den kan se väldigt annorlunda ut beroende på vilka lagar som kan tänkas gälla, vilka behov företaget har, vilka kunder företaget har samt hur situationen ser ut på företaget (de som pysslar med utveckling har ofta väldigt annorlunda behov än en strikt administrativ plats för sekretessbelagda uppfigter t ex).

Börja med att ta in information om företaget, personalen, etc för att se vilka behov som finns för att lösa deras uppgifter. En säkerhetspolicy får aldrig stå i vägen utan helst vara helt transparent för de uppgifter som skall lösas och inte hinda de anställda mer än vad som behövs i det dagliga arbetet.
Kika också på om särskilda avtal eller lagar behöver tas i beaktning (sekretessuppgifter, persondata, särskilda avtal med kunder, etc) och se till så policyn speglar dessa.

En bra policy skall vara enkla procedurer för att visa vad som gäller för nya anställda, skall ge IT-administratörer ett ramverk att hålla sig inom när chefer eller kunder kommer och vill spara pengar eller ta genvägar och vara något att använda vid audits eller kontroller av verksamheten från tredjepart. Den måsta såklart förankras med alla delar av verksamheten som berörs innan den implementeras och bör innehålla reguljär testning av incidenthantering så det inte bara är en pappersvikt som snabbt kommer bli föråldrad allt eftersom organisationen förändras.
En dålig policy är ofta onödigt komplicerad och svårförstålig som gör att anställda ignorerar delar eller hela för att kunna sköta sina arbetsuppgifter. Se gärna till att regler som kan upprätthållas på teknisk väg också görs så vilket skapar mindre frågor och problem för de anställda (ex. en lösenordspolicy om minsta antal tecken eller byte av lösenord varje x månad skall framtvingas av systemet och inte vara något den enskilda användaren behöver hålla koll på).

ISO 27002, som föreslagits ovan, är en bra början att kika på.

Lycka till!

.Chloe:
Det är ju det som är grejen med SE-attacker. Man ringer upp någon, som inte har behörighet. Denna personen måste föra vidare uppdraget internt, varför denna person gör en bristfällig verifiering.
Personen som tar emot uppdraget tror att korrekt verifiering mot kund är gjord.

Och så är systemet "övertaget".

I mitt exempel: Kunden måste ju få ändra sin faktureringsadress. Har kunden kommit till "fel person" (en som inte har behörighet) i supporten måste ju kunden lotsas rätt.
Antar att du menar istället att "om support inte har behörighet att ändra faktureringsadressen så ska kund inte få ändra den över huvud taget" eller?
Då blir det lite problem med kunder som flyttat t.ex.


Det är detta jag menar.

Exempel:
Kund ringer kundsupport
KundsupportA säger "Visst, jag ordnar det".
KundsupportA har ej behörighet att ändra adressen, varför KundsupportA lägger upp ett internärende.
ChefB har behörighet att ändra faktureringsadressen varför han utför internärendet, trots att KundsupportA inte verifierat att det är rätt kund som ringer.
Att utföra ärendet trots att man sagt nej blir också fel då kanske kunden lägger upp och betalar för en eftersändning helt i onödan.


Då är detta bättre:
Kund ringer kundsupport.
KundsupportA säger "Nej jag har tyvärr ingen behörighet att ändra faktureringsadressen, men du kan gärna ringa våran chef som har den behörigheten, du når han på 08-xxx-xxx".
Kund ringer ChefB.
ChefB pratar nu direkt med kund, och har då själv ansvaret att verifiera kunden, precis som om kunden ringt ChefB direkt utan att gå vägen via KundsupportA.


Förstår du nu skillnaden?
Risken för SE-attacker blir mindre om man begränsar behörigheterna och sedan INTE låter anställda ta beslut själv utan har man inte behörighet skall kunden lotsas till en som har behörighet.

Felet många gör också, är att ge behörighet till sådana som inte vet hur man verifierar kunden, varför det blir fel ändå. BARA de som vet exakt vad som kan gå fel, och hur man verifierar en kund (säkerhetskoder m.m.) skall ha behörighet att ändra i systemet.


Så med andra ord, man SKA kunna exponera hierkaistegen UTAN att sårbarheter uppstår. Annars har man "security by obscurity", med andra ord att säkerheten hänger på att ingen vet vem som har behörighet att ändra i systemet.

Snarare ska säkerheten hänga på att de som faktiskt har behörighet, vet hur man hanterar personer som vill ha saker och ting gjort, vad som ska verifieras, vilka kontrollfrågor som ska ställas etc...