CIS 18 Kontroller

Forklaring på CIS #1: Denne CIS-kontrol kræver både tekniske og proceduremæssige handlinger, samlet i en proces der står for og administrerer opgørelsen af ​​virksomhedens aktiver og alle tilknyttede data gennem hele dets livscyklus. Det knytter sig også til virksomhedsledelse gennem etablering data/aktivejere, der er ansvarlige for hver komponent i en forretningsproces. Virksomheder kan bruge omfattende, omfattende virksomhedsprodukter til at vedligeholde it aktiver opgørelser. Mindre virksomheder kan udnytte sikkerhedsværktøjer, der allerede er installeret på virksomhedsaktiver eller bruges på netværket til at indsamle disse data. Dette inkluderer at gøre en opdagelsesscanning af netværket med en sårbarhedsscanner; gennemgang af anti-malware logfiler, logfiler fra slutpunktssikkerhedsportaler, netværkslogfiler fra switches eller godkendelse logs; og styring af resultaterne i et regneark eller en database. At opretholde et aktuelt og præcist overblik over virksomhedens aktiver er en løbende og dynamisk proces. Selv for virksomheder er der sjældent en enkelt kilde til sandhed, som virksomhedsaktiver er ikke altid klargjort eller installeret af it-afdelingen.Det Virkeligheden er, at en række forskellige kilder skal “crowd-sourced” for at bestemme en høj tillidantal virksomhedsaktiver. Virksomheder kan aktivt scanne regelmæssigt ved at sende en række forskellige pakketyper for at identificere aktiver forbundet med netværk. Ud over aktivkilder nævnt ovenfor for små virksomheder, større virksomheder kan indsamle data fra cloud-portaler og logfiler fra virksomhedsplatforme som f.eks som: Active Directory (AD), Single Sign-On (SSO), Multi-Factor Authentication (MFA), Virtual Private Network (VPN), Intrusion Detection Systems (IDS) eller Deep Packet Inspektion (DPI), Mobile Device Management (MDM) og sårbarhedsscanning værktøjer. Ejendomsbeholdningsdatabaser, indkøbsordresporing og lokal inventar lister er andre datakilder til at bestemme, hvilke enheder der er tilsluttet. Der er værktøjer og metoder, der normaliserer disse data for at identificere enheder, der er unikke blandt disse kilder.

Forklaring på CIS #2: Tilladelsesliste kan implementeres ved hjælp af en kombination af kommerciel tilladelsesliste værktøjer, politikker eller applikationsudførelsesværktøjer, der følger med anti-malware-pakker og populære operativsystemer. Kommercielle softwareopgørelsesværktøjer er bredt tilgængelige og bruges i mange virksomheder i dag. Det bedste af disse værktøjer giver en opgørelse kontrol af hundredvis af almindelig software, der bruges i virksomheder. Værktøjerne trækker information om programrettelsesniveauet for hvert installeret program for at sikre, at det er den nyeste version og udnytte standardiserede applikationsnavne, såsom dem, der findes i Common Platform Enumeration (CPE) specifikation. Et eksempel på en metode, der kan bruges er Security Content Automation Protocol (SCAP). Yderligere information om SCAP kan findes her: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-126r3.pdf Funktioner, der implementerer tilladelseslister, er inkluderet i mange moderne slutpunktsikkerheder suiter og endda indbygget implementeret i visse versioner af større operativsystemer. Desuden samler kommercielle løsninger i stigende grad anti-malware, antispyware, personlig firewall og værtsbaseret IDS og Intrusion Prevention System (IPS), sammen med ansøgningstilladelse og blokering. Især det meste af slutpunktssikkerhed løsninger kan se på navnet, filsystemets placering og/eller kryptografiske hash for en givet eksekverbar for at bestemme, om applikationen skal have lov til at køre på den beskyttede maskine. De mest effektive af disse værktøjer tilbyder tilpassede tilladelseslister baseret på eksekverbar sti, hash eller matchning af regulære udtryk. Nogle inkluderer endda en ikke-ondsindet, endnu ikke godkendt, applikationsfunktion, der tillader administratorer at definere regler for udførelse af specifik software for bestemte brugere og på bestemte tidspunkter af dagen.

Forklaring på CIS #4: Der er mange tilgængelige sikkerhedsbaselines for hvert system. Virksomheder bør starte med disse offentligt udviklede, kontrollerede og understøttede sikkerhedsbenchmarks, sikkerhedsvejledninger eller tjeklister. (Fx CIS Benchmarks). Virksomheder bør udvide eller justere disse basislinjer for at tilfredsstille virksomhedens sikkerhedspolitikker og industriens og myndighedernes lovgivningsmæssige krav. Afvigelser af standardkonfigurationer og begrundelse bør dokumenteres for at lette fremtidige gennemgange eller revisioner. For en større eller mere kompleks virksomhed vil der være flere sikkerhedsbaseline-konfigurationer baseret på sikkerhedskrav eller klassificering af data på virksomhedens aktiv. Her er et eksempel på trinene til at bygge et sikkert baselinebillede: 01 Bestem risikoklassificeringen af ​​de data, der håndteres/lagres på virksomhedens aktiv (f.eks. høj, moderat, lav risiko). 02 Opret et sikkerhedskonfigurationsscript, der angiver systemsikkerhedsindstillinger, så de opfylder kravene til beskyttelse af de data, der bruges på virksomhedens aktiv. Brug benchmarks, såsom dem, der er beskrevet tidligere i dette afsnit. 03 Installer basisoperativsystemsoftwaren. 04 Anvend passende operativsystem- og sikkerhedsrettelser. 05 Installer passende softwarepakker, værktøj og hjælpeprogrammer. 06 Anvend passende opdateringer til software installeret i trin 4. 07 Installer lokale tilpasningsscripts til dette billede. 08 Kør sikkerhedsscriptet oprettet i trin 2 for at indstille det passende sikkerhedsniveau. 09 Kør et SCAP-kompatibelt værktøj for at registrere/score systemindstillingen for basislinjebilledet. 10 Udfør en kvalitetssikringstest. 11 Gem dette basisbillede på et sikkert sted. Kommercielle og/eller gratis konfigurationsstyringsværktøjer, såsom CIS Configuration Assessment Tool (CIS-CAT®) https://learn.cisecurity.org/cis-cat-lite, kan implementeres til at måle indstillingerne for operativsystemer og applikationer af administrerede maskiner til at lede efter afvigelser fra standard billedkonfigurationer. Kommercielle konfigurationsstyringsværktøjer bruger en kombination af en agent installeret på hvert administreret system, eller agentfri inspektion af systemer gennem fjernlogning på hvert virksomhedsaktiv ved hjælp af administratorlegitimationsoplysninger. Derudover bruges nogle gange en hybrid tilgang, hvorved en fjernsession startes, en midlertidig eller dynamisk agent implementeres på målsystemet til scanningen, og derefter fjernes agenten.

Forklaring på CIS #5: Legitimationsoplysninger er aktiver, der skal opføres og spores ligesom virksomhedsaktiver og software, da de er det primære indgangspunkt til virksomheden. Der bør udvikles passende adgangskodepolitikker og vejledning om ikke at genbruge adgangskoder. Konti skal også spores; enhver konto, der er i dvale, skal deaktiveres og til sidst fjernes fra systemet. Der bør være periodiske revisioner for at sikre, at alle aktive konti spores tilbage til autoriserede brugere af virksomhedens aktiv. Se efter nye konti tilføjet siden tidligere gennemgang, især administrator- og servicekonti. Der bør lægges stor vægt på at identificere og spore administrative eller højtprivilegerede konti og servicekonti. Brugere med administrator- eller anden privilegeret adgang bør have separate konti til disse højere myndighedsopgaver. Disse konti vil kun blive brugt, når de udfører disse opgaver eller får adgang til særligt følsomme data, for at reducere risikoen i tilfælde af, at deres normale brugerkonto kompromitteres. For brugere med flere konti bør deres basisbrugerkonto, der bruges dagligt til ikke-administrative opgaver, ikke have nogen forhøjede rettigheder. Single Sign-On (SSO) er praktisk og sikkert, når en virksomhed har mange applikationer, herunder cloud-applikationer, hvilket hjælper med at reducere antallet af adgangskoder, som en bruger skal administrere. Brugere anbefales at bruge adgangskodehåndteringsprogrammer til sikkert at gemme deres adgangskoder, og de bør instrueres i ikke at opbevare dem i regneark eller tekstfiler på deres computere. MFA anbefales til fjernadgang. Brugere skal også automatisk logges ud af systemet efter en periode med inaktivitet og trænes i at låse deres skærm, når de forlader deres enhed, for at minimere muligheden for, at en anden i fysisk nærhed omkring brugeren får adgang til deres system, applikationer eller data.

Forklaring på CIS #7: Et stort antal sårbarhedsscanningsværktøjer er tilgængelige til at evaluere sikkerheden konfiguration af virksomhedens aktiver. Nogle virksomheder har også fundet kommercielle tjenester, der bruger fjernstyrede scanningsapparater for at være effektive. At hjælpe standardisere definitionerne af opdagede sårbarheder på tværs af en virksomhed, er det at foretrække at bruge sårbarhedsscanningsværktøjer, der kortlægger sårbarheder til en eller flere af følgende brancheanerkendte sårbarhed, konfiguration og platformsklassificering skemaer og sprog: Common Vulnerabilities and Exposures (CVE®), Common Configuration Enumeration (CCE), Open Vulnerability and Assessment Language (OVAL®), Common Platform Enumeration (CPE), Common Vulnerability Scoring System (CVSS) og/eller Extensible Configuration Checklist Description Format (XCCDF). Disse ordninger og sprog er komponenter i SCAP. Hyppigheden af ​​scanningsaktiviteter bør stige i takt med diversiteten i en virksomhed aktiver stiger for at tage højde for de forskellige patch-cyklusser for hver leverandør. Fremskreden sårbarhedsscanningsværktøjer kan konfigureres med brugerlegitimationsoplysninger til autentificering ind i virksomhedens aktiver og udføre mere omfattende vurderinger. Disse kaldes “godkendte scanninger.” Ud over scanningsværktøjerne, der tjekker for sårbarheder og fejlkonfigurationer på tværs af netværket kan forskellige gratis og kommercielle værktøjer evaluere sikkerhedsindstillinger og konfigurationer af virksomhedsaktiver. Sådanne værktøjer kan give finmasket indsigt til uautoriserede ændringer i konfigurationen eller utilsigtet indførelse af sikkerhed svagheder fra administratorer. Effektive virksomheder forbinder deres sårbarhedsscannere med problembilletsystemer der sporer og rapporterer fremskridt med at rette sårbarheder. Dette kan hjælpe med at fremhæve ubegrænsede kritiske sårbarheder for den øverste ledelse for at sikre, at de bliver løst. Virksomheder kan også spore, hvor lang tid det tog at afhjælpe en sårbarhed, efter at have identificeret, eller der er udstedt et plaster. Disse kan understøtte intern eller brancheoverholdelse krav. Nogle modne virksomheder vil gennemgå disse rapporter i IT-sikkerhedsstyring udvalgsmøder, som samler ledere fra IT og forretningen om at prioritere afhjælpningsindsats baseret på forretningspåvirkning. Når en virksomhed vælger, hvilke sårbarheder der skal rettes, eller patches der skal anvendes forstærk NISTs Common Vulnerability Scoring System (CVSS) med data vedr. sandsynligheden for, at en trusselsaktør bruger en sårbarhed, eller den potentielle påvirkning af en udnyttelse til virksomheden. Oplysninger om sandsynligheden for udnyttelse bør også være periodisk opdateret baseret på de seneste trusselsoplysninger. For eksempel udgivelsen af en ny udnyttelse, eller ny efterretning vedrørende udnyttelse af sårbarheden, bør ændre den prioritet, hvorigennem sårbarheden skal overvejes til patch. Forskellige kommercielle systemer er tilgængelige for at give en virksomhed mulighed for at automatisere og vedligeholde denne proces på en skalerbar måde. De mest effektive værktøjer til sårbarhedsscanning sammenligner resultaterne af den aktuelle scanning med tidligere scanninger for at bestemme, hvordan sårbarhederne i miljøet har ændret sig over tid. Sikkerhedspersonale bruger disse funktioner til at udføre sårbarhed trend fra måned til måned. Endelig bør der være en kvalitetssikringsproces for at verificere konfigurationsopdateringer, eller at patches er implementeret korrekt og på tværs af alle relevante virksomhedsaktiver.

Forklaring på CIS #8: De fleste virksomhedsaktiver og -software tilbyder logningsfunktioner. Sådan logning bør være aktiveret, med logs sendt til centraliserede logningsservere. Firewalls, proxyer og fjernbetjening adgangssystemer (Virtual Private Network (VPN), dial-up osv.) bør alle konfigureres til detaljeret logning, hvor det er en fordel. Opbevaring af logdata er også vigtig i i tilfælde, hvor en hændelsesundersøgelse er påkrævet. Desuden skal alle virksomhedsaktiver konfigureres til at skabe adgangskontrol logfiler, når en bruger forsøger at få adgang til ressourcer uden de relevante privilegier. For at vurdere, om en sådan logning er på plads, bør en virksomhed med jævne mellemrum scanne gennem sine logfiler og sammenlign dem med virksomhedens aktivbeholdning samlet som en del af CIS Control 1, for at sikre, at hvert administreret aktiv er aktivt forbundet til netværket genererer periodisk logs.

Forklaring på CIS #9: Browserbeskyttelse  Cyberkriminelle kan udnytte webbrowsere på flere måder. Hvis de har adgang til udnyttelse af sårbare browsere, kan de lave ondsindede websider, der kan udnytte disse sårbarheder, når de gennemses med en usikker eller ikke-patchet browser. Alternativt kan de forsøge at målrette mod et hvilket som helst antal almindelige webbrowser-tredjeparter plugins, der kan give dem mulighed for at tilslutte sig browseren eller endda direkte ind operativsystemet eller applikationen. Disse plugins er ligesom enhver anden software inden for et miljø, skal gennemgås for sårbarheder, holdes ajour med seneste patches eller versioner, og kontrolleret. Mange kommer fra upålidelige kilder, og nogle er endda skrevet til at være ondsindede. Derfor er det bedst at forhindre brugere i bevidst eller utilsigtet installation af malware, der muligvis gemmer sig i nogle af disse plugins, udvidelser og tilføjelser. Simple konfigurationsopdateringer til browseren kan gøre det meget sværere for malware at blive installeret ved at reducere evnen til installere tilføjelser/plugins/udvidelser og forhindre specifikke typer indhold fra automatisk udføres. De fleste populære browsere anvender en database med phishing- og/eller malware-websteder beskytte mod de mest almindelige trusler. En bedste praksis er at aktivere dette indhold filtre og tænd for pop op-blokkere. Pop-ups er ikke kun irriterende; de kan hoster også indlejret malware direkte eller lokker brugere til at klikke på links ved hjælp af sociale tekniske tricks. For at hjælpe med at håndhæve blokering af kendte ondsindede domæner, skal du også overveje abonnere på DNS-filtreringstjenester for at blokere forsøg på at få adgang til disse websteder på network level. E-mail beskyttelse E-mail repræsenterer en af ​​de mest interaktive måder, mennesker arbejder med virksomhedsaktiver på; træning og opmuntring til den rigtige adfærd er lige så vigtigt som det tekniske indstillinger. E-mail er den mest almindelige trusselsvektor mod virksomheder gennem taktik såsom phishing og Business Email Compromise (BEC). Brug af et spam-filtreringsværktøj og malware-scanning ved e-mail-gatewayen reducerer antallet af ondsindede e-mails og vedhæftede filer, der kommer ind i virksomhedens netværk. Indledning af domænebaseret meddelelsesgodkendelse, rapportering og overensstemmelse (DMARC) hjælper med at reducere spam og phishing-aktiviteter. Installation af et krypteringsværktøj at sikre e-mail og kommunikation tilføjer endnu et lag af bruger- og netværksbaseret sikkerhed. Udover at blokere baseret på afsender, kan det også betale sig kun at tillade visse filtyper, som brugerne har brug for til deres job. Dette vil kræve koordinering med forskellige forretningsenheder for at forstå, hvilke typer filer de modtager via e-mail til sikre, at der ikke er en afbrydelse af deres processer. Siden phishing-e-mail-teknikker hele tiden udvikler sig for at komme forbi Something Posing som Mail (SPAM) filter regler, er det vigtigt at træne brugere i, hvordan man identificerer phishing, og at give IT-sikkerhed besked, når de ser en. Der er mange platforme, der præsterer phishing-tests mod brugere for at hjælpe med at uddanne dem i forskellige eksempler og spore  deres forbedring over tid. Crowd-sourcing af denne viden til at underrette IT-sikkerhed teams af phishing hjælper med at forbedre beskyttelsen og detekteringen af ​​e-mail-baserede trusler.

Forklaring på CIS #10: Effektiv malwarebeskyttelse omfatter traditionel endpoint malware-forebyggelse og detektionssuiter. For at sikre, at malware IOC’er er opdaterede, kan virksomheder modtage automatiserede opdateringer fra leverandøren for at berige andre sårbarheds- eller trusselsdata. Disse værktøjer administreres bedst centralt for at give sammenhæng på tværs af infrastrukturen. At være i stand til at blokere eller identificere malware er kun en del af denne CIS-kontrol; der er også en fokus på centralt at indsamle loggene for at understøtte alarmering, identifikation og hændelse respons. Da ondsindede aktører fortsætter med at udvikle deres metoder, er mange det begynder at tage en “living-off-the-land” (LotL) tilgang for at minimere sandsynligheden for bliver fanget. Denne tilgang refererer til angriberadfærd, der bruger værktøjer eller funktioner, der findes allerede i målmiljøet. Aktivering af logning i henhold til sikkerhedsforanstaltningerne CIS Control 8, vil gøre det væsentligt nemmere for virksomheden at følge begivenhederne til forstå, hvad der skete, og hvorfor det skete.

Forklaring på CIS #11: Datagendannelsesprocedurer bør defineres i datahåndteringsprocessen beskrevet i CIS Control 3, Databeskyttelse. Dette bør omfatte sikkerhedskopieringsprocedurer baseret på dataværdi, følsomhed eller krav til opbevaring. Dette vil hjælpe med at udvikle backup frekvens og type (fuld vs. inkrementel). En gang i kvartalet (eller hver gang en ny backupproces eller teknologi introduceres), et testhold bør evaluere en tilfældig stikprøve af sikkerhedskopier og forsøge at gendanne dem på et testlejemiljø. De gendannede sikkerhedskopier skal verificeres for at sikre at operativsystemet, applikationen og dataene fra sikkerhedskopien alle er intakte og funktionelle. I tilfælde af malwareinfektion bør gendannelsesprocedurer bruge en version af backup, der menes at være før den oprindelige infektion.

Forklaring på CIS #12: Virksomheder bør sikre, at netværksinfrastruktur er fuldt dokumenteret og arkitektur at have leverandørsupport til patches og funktionsopgraderinger. Opgrader End-of-Life (EOL)-komponenter før den dato, hvor de ikke understøttes eller anvendes afhjælpende kontrol for at isolere dem. Virksomheder skal overvåge deres infrastrukturversioner og konfigurationer for sårbarheder, der ville kræve, at de opgraderer netværket enheder til den seneste sikre og stabile version, der ikke påvirker infrastrukturen. Et opdateret netværksarkitekturdiagram, inklusive sikkerhedsarkitekturdiagrammer, er et vigtigt fundament for infrastrukturstyring. Det næste er at have fuldført kontostyring til adgangskontrol, logning og overvågning. Endelig infrastruktur administration bør kun udføres over sikre protokoller, med stærke autentificering (MFA for PAM) og fra dedikerede administrative enheder eller out-ofband netværk. Kommercielle værktøjer kan være nyttige til at evaluere regelsættene for netværksfiltreringsenheder til afgøre, om de er konsekvente eller i konflikt. Dette giver en automatiseret fornuft kontrol af netværksfiltre. Disse værktøjer søger efter fejl i regelsæt eller adgangskontroller Lister (ACL’er), der kan tillade utilsigtede tjenester gennem netværksenheden. Sådan værktøjer skal køres, hver gang der foretages væsentlige ændringer i firewall-regelsæt, router ACL’er eller andre filtreringsteknologier.

Forklaring på CIS #13: De fleste virksomheder behøver ikke at opstille et Security Operations Center (SOC) til opnå situationsfornemmelse. Dette starter med den første forståelse af kritisk forretning funktioner, netværks- og serverarkitekturer, data- og datastrømme, leverandørservice og forretningspartnerforbindelse og slutbrugerenheder og konti. Dette oplyser udvikling af en sikkerhedsarkitektur, tekniske kontroller, logning, overvågning og reaktionsprocedurer. Kernen i denne proces er et trænet og organiseret team, der implementerer processer til hændelsesdetektion, analyse og afbødning. Disse kapaciteter kunne udføres internt eller gennem konsulenter eller en administreret tjenesteudbyder. Det burde virksomhederne overveje netværk, virksomhedsaktiver, brugerlegitimationsoplysninger og dataadgangsaktiviteter. Teknologi vil spille en afgørende rolle for at indsamle og analysere alle data og overvåge netværk og virksomhedsaktiver internt og eksternt til virksomheden. Virksomheder bør omfatte synlighed til cloud-platforme, der måske ikke er på linje med lokale sikkerhedsteknologi. Videresendelse af alle vigtige logfiler til analytiske programmer, såsom sikkerhedsoplysninger og Event Management (SIEM) løsninger, kan give værdi; de giver dog ikke et komplet billede. Ugentlige loggennemgange er nødvendige for at justere tærskler og identificere unormale hændelser. Korrelationsværktøjer kan gøre revisionslogfiler mere nyttige til efterfølgende manuel inspektion. Disse værktøjer er ikke en erstatning for dygtig informationssikkerhed personale- og systemadministratorer. Selv med automatiserede loganalyseværktøjer, menneskelige ekspertise og intuition er ofte påkrævet for at identificere og forstå angreb. Efterhånden som denne proces modnes, vil virksomheder skabe, vedligeholde og udvikle en viden base, der vil hjælpe med at forstå og vurdere forretningsrisici, udvikle en intern trusselsefterretningskapacitet. Trusselsefterretninger er indsamlingen af ​​TTP’er fra hændelser og modstandere. For at opnå dette vil et situationsbevidsthedsprogram definere og vurdere, hvilke informationskilder der er relevante for at opdage, rapportere og håndtere angreb. De fleste modne virksomheder kan udvikle sig til trusselsjagt, hvor uddannet personale manuelt gennemgå system- og brugerlogfiler, datastrømme og trafikmønstre for at finde uregelmæssigheder.

Forklaring på CIS #14: Et effektivt træningsprogram for sikkerhedsbevidsthed bør ikke bare være en dåse, én gang års træningsvideo kombineret med regelmæssig phishing-test. Mens årlig træning er behov, bør der også være hyppigere, aktuelle beskeder og notifikationer vedr sikkerhed. Dette kan omfatte beskeder om: stærk adgangskodebrug, der falder sammen med en medierapport om adgangskodedump, stigningen i phishing i skattetiden eller øget bevidsthed om ondsindede e-mails med levering af pakke i løbet af ferien. Træning bør også tage højde for virksomhedens forskellige regulerings- og trusselsposition. Finansielle virksomheder kan have mere compliance-relateret træning i datahåndtering og brug, sundhedsvirksomheder om håndtering af sundhedsdata og handlende for kreditkortdata. Social ingeniøruddannelse, såsom phishing-tests, bør også omfatte bevidsthed taktik, der retter sig mod forskellige roller. For eksempel vil økonomiteamet modtage BEC forsøger at udgive sig som ledere, der beder om at overføre penge eller modtage e-mails fra kompromitterede partnere eller leverandører, der beder om at ændre bankkontooplysningerne for deres næste betaling. For mere omfattende behandling af dette emne er følgende ressourcer nyttige for opbygge et effektivt sikkerhedsbevidsthedsprogram:

Forklaring på CIS #15: De fleste virksomheder har traditionelt brugt standardtjeklister, f.eks. dem fra ISO 27001 eller CIS Controls. Ofte styres denne proces gennem regneark; dog er der nu online platforme, der tillader central styring af dette behandle. Fokus for denne CIS-kontrol er dog ikke på tjeklisten; i stedet er den tændt det grundlæggende i programmet. Sørg for at besøge årligt, som relationer og data kan ændre sig. Uanset virksomhedens størrelse, bør der være en politik om revision tjenesteudbydere, en opgørelse over disse leverandører og en risikovurdering forbundet med deres potentielle indvirkning på virksomheden i tilfælde af en hændelse. Det burde der også være sprog i kontrakterne for at holde dem ansvarlige, hvis der er en hændelse, der påvirker virksomheden. Der er tredjeparts vurderingsplatforme, der har en beholdning på tusindvis af tjenesteudbydere, som forsøger at give et centralt syn på branchen, for at hjælpe virksomheder træffer mere informerede risikobeslutninger. Disse platforme har ofte en dynamik risikoscore for tjenesteudbydere, baseret (normalt) på passive tekniske vurderinger, eller beriget gennem andre firmaers tredjepartsvurderinger. Når du udfører anmeldelser, skal du fokusere på de tjenester eller afdelinger hos udbyderen, der er støtte virksomheden. En tredjepart, der har en administreret sikkerhedsservicekontrakt, eller retainer, og har cybersikkerhedsforsikring, kan også hjælpe med risikoreduktion. Det er også vigtigt at afvikle tjenesteudbydere på en sikker måde, når der er kontrakter afsluttet eller afsluttet. Nedlukningsaktiviteter kan omfatte bruger og service kontodeaktivering, afslutning af datastrømme og sikker bortskaffelse af virksomhedsdata inden for tjenesteudbydersystemer.

Forklaring på CIS #16: For version 8 samarbejdede CIS med SAFECode for at hjælpe med at udvikle procedurerne og sikkerhedsforanstaltninger for denne opdaterede Application Software Security Control. Imidlertid, applikationssoftwaresikkerhed er et stort emne i sig selv, og så (i overensstemmelse med principper for de overordnede CIS-kontroller), fokuserer vi her på de mest kritiske sikkerhedsforanstaltninger. Disse blev afledt af et ledsagende papir om applikationssoftwaresikkerhed SAFECode udviklet (refereret nedenfor), som giver en mere dybdegående behandling af emnet og er i overensstemmelse med SAFECodes eksisterende indhold. SAFECode udviklede en tre-trins tilgang til at hjælpe læserne med at identificere hvilke Development Group (DG) de passer ind som en modenhedsskala for udviklingsprogrammer. De tre CIS IG-niveauer, der blev brugt inden for sikkerhedsforanstaltningerne, inspirerede deres tilgang til nedenstående generaldirektorater: Udviklingsgruppe 1 • Virksomheden er i vid udstrækning afhængig af hyldevare eller Open Source Software (OSS) og pakker med kun lejlighedsvis tilføjelse af små applikationer eller websteder kodning. Virksomheden er i stand til at anvende grundlæggende operationelle og proceduremæssige bedst praksis og styring af sikkerheden af ​​dets leverandørleverede software som følge af efter vejledningen fra CIS Controls. Udviklingsgruppe 2 • Virksomheden er afhængig af en eller anden tilpasset (in-house eller entreprenør-udviklet) web og/eller native kodeapplikationer integreret med tredjepartskomponenter og -kørsler on-premises eller i skyen. Virksomheden har en udviklingsstab, der søger bedste praksis for softwareudvikling. Virksomheden er opmærksom på kvaliteten og vedligeholdelse af tredjeparts open source eller kommerciel kode, som det afhænger af. Udviklingsgruppe 3 • Virksomheden foretager en større investering i tilpasset software, som den kræver for at køre sin forretning og betjene sine kunder. Det kan hoste software på sin egen infrastruktur, i skyen, eller begge dele, og kan integrere et stort udvalg af tredjeparts open source og kommercielle softwarekomponenter. Softwareleverandører og virksomheder, der leverer SaaS bør betragte Development Group 3 som et minimumskrav. Det ideelle programsikkerhedsprogram er et, der introducerer sikkerhed så tidligt i softwareudviklings livscyklus som muligt. Håndtering af sikkerhedsproblemer skal være konsistent og integreret med standard softwarefejl/fejlhåndtering, i modsætning til en separat proces, der konkurrerer om udviklingsressourcer. Større eller mere modne udviklingsteams bør overveje praksis med trusselsmodellering i designfasen. Sårbarheder på designniveau er mindre almindelige end kodeniveau sårbarheder; dog er de ofte meget alvorlige og meget sværere at rette hurtigt. Trusselsmodellering er processen med at identificere og adressere applikationssikkerhed designfejl, før kode oprettes. Trusselsmodellering kræver specifik træning, teknisk og forretningsmæssig viden. Det udføres bedst gennem intern “sikkerhed champions” i hvert udviklingsteam, for at lede trusselsmodelleringspraksis til det teamets software. Det giver også værdifuld kontekst til downstream-aktiviteter, såsom root årsagsanalyse og sikkerhedstest. Større eller kommercielle udviklingsteams kan også overveje et bug bounty-program hvor enkeltpersoner betales for at finde fejl i deres ansøgninger. Sådan et program er bedst bruges til at supplere en intern sikker udviklingsproces og kan levere en effektiv mekanisme til at identificere klasser af sårbarheder, som processen har brug for at fokusere på. Endelig udgav NIST® i 2020 sin Secure Software Development Framework (SSDF), som samlede, hvad industrien har lært om softwaresikkerhed over sidste to årtier og skabt en sikker softwareudviklingsramme til planlægning, evaluere og kommunikere om softwaresikkerhedsaktiviteter. Virksomheder, der køber software eller tjenester kan bruge denne ramme til at opbygge deres sikkerhedskrav og forstå, om en softwareudbyders udviklingsproces følger bedste praksis. Dette er nogle applikationssikkerhedsressourcer:

Forkaring på CIS #17: Selvom en virksomhed ikke har ressourcer til at udføre hændelsesberedskab inden for en virksomhed, er det stadig vigtigt at have en plan. Dette vil omfatte kilderne til beskyttelse og detektioner, en liste over, hvem der skal tilkaldes for at få hjælp, og kommunikationsplaner om, hvordan man formidler information til ledelse, medarbejdere, regulatorer, partnere, og kunder. Efter at have defineret hændelsesresponsprocedurer, hændelsesresponsteamet eller en tredjepart, bør deltage i periodisk scenarie-baseret træning, arbejde gennem en række af angrebsscenarier finjusteret til de trusler og potentielle påvirkninger, virksomheden står over for. Disse scenarier hjælper med at sikre, at virksomhedens lederskab og tekniske teammedlemmer forstå deres rolle i hændelsesresponsprocessen for at hjælpe med at forberede dem til at håndtere hændelser. Det er uundgåeligt, at trænings- og træningsscenarier vil identificere huller i planer og processer, og uventede afhængigheder, som derefter kan opdateres ind i planen. Mere modne virksomheder bør omfatte trusselsefterretninger og/eller trusselsjagt ind i deres hændelsesresponsproces. Dette vil hjælpe teamet med at blive mere proaktivt, identificere nøgleangribere eller primære angribere til deres virksomhed eller industri for at overvåge eller søge for deres TTP’er. Dette vil hjælpe med at fokusere detektioner og definere reaktionsprocedurer til identificere og afhjælpe hurtigere. Handlingerne i CIS Control 17 giver specifikke, højprioriterede trin, der kan forbedres virksomhedssikkerhed, og bør være en del af enhver omfattende hændelse og reaktion plan. Derudover anbefaler vi følgende ressource dedikeret til dette emne:

Forklaring på CIS #18: Penetrationstest starter med rekognoscering af virksomheden og miljøet, og scanning for at identificere de sårbarheder, der kan bruges som indtastninger i virksomhed. Det er vigtigt at sikre, at alle virksomhedens aktiver bliver opdaget, der er i rækkevidde, og ikke kun stole på en statisk liste, som kan være forældet eller ufuldstændig. Dernæst vil sårbarheder blive identificeret i disse mål. Udnytter disse sårbarheder udføres for at demonstrere specifikt, hvordan en modstander enten kan undergrave virksomhedens sikkerhedsmål (f.eks. beskyttelse af specifikke følsomme data) eller opnå specifikke modstridende mål (f.eks. etablering af en hemmelig kommando og Kontrol (C2) infrastruktur). Resultaterne giver dybere indsigt gennem demonstration, ind i de forretningsmæssige risici ved forskellige sårbarheder. Dette kan være imod fysisk adgangskontrol, netværk, system eller applikationslag, og inkluderer ofte sociale tekniske komponenter. Penetrationstest er dyre, komplekse og medfører potentielt deres egne risici. Erfarne folk fra velrenommerede leverandører skal udføre dem. Nogle risici omfatter uventet nedlukning af systemer, der kan være ustabile, udnyttelser, der kan slettes eller korrupte data eller konfigurationer, og outputtet af en testrapport, der skal være beskyttet sig selv, fordi den giver trin-for-trin instruktioner om, hvordan man bryder ind i virksomhed til at målrette kritiske aktiver eller data. Hver virksomhed bør definere et klart omfang og regler for engagement for penetration testning. Omfanget af sådanne projekter bør som minimum omfatte virksomhedsaktiver med den højest værdsatte informations- og produktionsbehandlingsfunktionalitet. Andet systemer med lavere værdier kan også testes for at se, om de kan bruges som omdrejningspunkter at kompromittere højere værdimål. Indgrebsreglerne for penetrationstest analyser bør som minimum beskrive tidspunkter på dagen for testning, varighed af test(s), og den overordnede testtilgang. Kun få personer i virksomheden bør vide, hvornår en penetrationstest udføres, og et primært kontaktpunkt i virksomheden bør udpeges, hvis der opstår problemer. Stadig mere populær for nylig er at have penetration test udført gennem tredjeparts juridiske rådgivere for at beskytte penetrationstestrapporten fra offentliggørelse. Sikkerhedsforanstaltningerne i denne CIS-kontrol giver specifikke, højprioriterede trin, der kan forbedres virksomhedssikkerhed, og bør være en del af enhver penetrationstest. Derudover har vi anbefale brugen af ​​nogle af de fremragende omfattende ressourcer dedikeret til dette emne for at understøtte planlægning, styring og rapportering af sikkerhedstest: