Er din tjeneste sikker? Tror du, at du vil bestå en revision? Antager du, at din adgangsstyring er skudsikker? Måske har du ret, men hvis du er ærlig over for dig selv, ved du, at sikkerhed altid er værd at dobbelttjekke, og det er derfor, jeg skriver dette - for at dele min mening og erfaringer.
Arbejder i miljøer ud over små og mellemstore virksomheder, har jeg indset, at sikkerhedsaspekter ofte overses, selv i større virksomheder. Der er muligvis nedskrevet politikker et eller andet sted i et ikke-administreret Microsoft SharePoint, men hvad er dokumenterne gode til, hvis de hverken håndhæves eller overvejes, når du installerer eller ændrer enheder i infrastrukturen? Jeg har også mødt enhedsproducerende virksomheder, der syntes at have begrænset fokus på sikkerhedsaspekter. Selvom løsningen af en sådan virksomhed udmærker sig i pris, funktioner eller begge dele, kan man sommetider simpelthen ikke træffe en positiv beslutning for det firma, hvis det fra starten er klart, at løsningen ikke er i overensstemmelse med sikkerhedspolitikker.
I denne artikel vil jeg vise et par punkter i sikkerhedsspørgsmål, der ofte overses; måske vil du endda lære et par ting her, før en ond revisor lærer dig om det.
Standard brugernavn / standardadgangskode
Fra det øjeblik du tager en enhed ud af kassen eller installerer software på en server, har udvikleren normalt en "fabrikskonto" på plads, som ofte er baseret på et standardbrugernavn og en adgangskode til at logge ind allerførste gang (det er også muligt, at der slet ikke er adgangskodebeskyttelse). På dette stadium har du et par muligheder afhængigt af sikkerhedsniveauet eller de politikker, du skal overholde. Mulighed 1 er at have en generisk admin-konto med en tilpasset adgangskode for at forhindre angreb fra folk, der udnytter din enhed ved hjælp af websider som “standardadgangskodelisten ”. Mulighed 2 indebærer, at enhver administrativ bruger får sit eget brugernavn og vælger en adgangskode, som kun han eller hun er opmærksom på. For at opsummere dette kan man sige, at mulighed 1 forhindrer folk uden for det administrative hold i at få adgang til din enhed, og mulighed 2 forhindrer angreb fra holdet, så længe adgangskoden ikke deles med nogen.
Samfundsteknologi
Selv om Social Engineering er en del af de fleste informationsfølsomhedsuddannelser, fejler mange medarbejdere stadig, når de testes på et Social Engineering-angreb. En social ingeniør kan være en mand eller en kvinde, der foregiver at være en del af teamet eller organisationen og vil virtuelt eller fysisk engagere brugere til at dele kritisk information såsom loginoplysningerne. Der er ingen tekniske konfigurationer, der helt kan forhindre, at dette sker, så længe du ansætter mennesker og ikke robotter, men du kan træne medarbejdere, der håndterer vigtig information og kører oplysningskampagner.
Gæstekonti
I nogle scenarier har udvikleren implementeret gæstekonti eller offentligt rum, der kan bruges eller ses uden at logge ind. Hvis du ikke bruger disse funktioner, skal du være opmærksom på dem og deaktivere disse gæstekonti for at forhindre brugere i at få adgang til data, som de er ikke beregnet til adgang.
Usikre protokoller og tjenester
Ofte er standardkonfigurationen at have alle tilgængelige protokoller aktiveret. Mange af disse er dog ikke sikre (såsom HTTP, FTP, Telnet, SNMP) og bør deaktiveres permanent. Hvis det er muligt, skal du bruge det sikre alternativ til en protokol. Hvis en protokol kun midlertidigt er påkrævet - for eksempel når du laver en sikkerhedskopi via FTP - og der ikke er noget sikkert alternativ til rådighed, kan du aktivere den i løbet af opgaven og derefter igen deaktivere tjenesten.
Logs
Enhver ændring og handling skal logges på en ordentlig måde; denne funktion kaldes ofte auditlog eller brugerlog. I nogle tilfælde er det muligt, at en enhed rydder sin log, når den genstartes, eller at loggen kan slettes eller ændres manuelt. For at forhindre dette kan du arbejde med en syslog-server, hvor disse logoplysninger gemmes væk fra selve apparatet og kan kontrolleres efter et muligt angreb.
Kryptering
Kryptografi er et sæt teknologier til at skjule information. Når det er muligt, skal der bruges en krypteringsfunktion, så data ikke kan lække, når de overføres. En fælles løsning til kryptering er AES (Advanced Encryption Standard).
Adgangskodestyrke og ændringsfrekvens
I bedste fald skal et gemt kodeord indeholde tilfældige specialtegn, tal, store bogstaver såvel som normale bogstaver og skal være så længe som muligt. Det skal ikke følge et mønster på tastaturet og for at forhindre det brute-force angreb, bør ikke indeholde ord, der kunne findes i en ordbog. Adgangskoden skal ikke skrives fysisk ned og bør bestemt ikke ende på en post-it-note, der sidder fast foran på skærmen eller under tastaturet. Hvis der er aktive politikker, der håndhæver en adgangskode, der er ret vanskelig at huske, skal du bede din informationssikkerhedsofficer om adgangskodestyringssoftware, der er godkendt i din organisation.
Ændringsfrekvensen - eller ændringen af adgangskoder generelt - er et emne, der kan diskuteres, men hvis det er en politik at ændre adgangskoden hver tredje måned, så skal det bare gøres. Det giver stadig mening at gøre det, selvom ændring af adgangskoder tilskynder brugerne til at vælge svagere adgangskoder for at huske dem bedre. Levetiden for en adgangskode er cirka mindre end 100 dage, og det er fordi det ville tage cirka 100 dage at knække et kodeord med en normal styrke.
Resumé
Disse punkter er kun mine tip, og selvfølgelig skal du altid konsultere informationssikkerhedspersonalet i din organisation og først kontrollere, om der er aktive politikker. Hvis du har feedback eller føler, at jeg har overset et vigtigt emne, er du velkommen til at skrive en kommentar nedenfor, så kan vi arbejde på yderligere færdiggørelse sammen.
Tak for læsningen og held og lykke med revisionen.
Dette indlæg blev oprindeligt udgivet på en Radical Logic-bloggen i oktober 2011, men er nu blevet overført her, da den gamle platform ikke længere vedligeholdes.
Foto kredit: Nicolas Raymond / Athena Stock
