4 måder, du kan sikre infrastruktur og øge fleksibiliteten i en hybrid verden

Sikkerhedsorganisationer er nødsaget til en hastig omstilling af deres tilgange til at sikre infrastruktur i en hurtigt skiftende hybrid verden. 

Beskyttelse af it-infrastruktur som f.eks. datacentre, netværk og pc’er har været grundpillen hos sikkerhedsteams i årtier.

Men tiden har ændret sig med et stigende antal organisationer, der har taget clouden og nye måder at arbejde på til sig. Mange store it-organisationer arbejder nu i komplekse miljøer med public cloud, multicloud eller hybride miljøer med softwareudviklingsteams, der anvender teknikker til kontinuerlig integration/kontinuerlig levering (CI/CD), så de hurtigt kan skabe ny kode. 

Samtidig skiftede ca. halvdelen af de fleste arbejdsstyrker fra sikre kontormiljøer til medarbejdernes eget hjem under COVID-19-krisen, hvor der blev skiftet mellem personlige enheder og virksomhedens enheder på knap så sikre hjemmenetværk.

Disse samme tendenser skaber digitale transformationsprogrammer, men sikkerhed bliver typisk set som en hindring for indsatsen for it-modernisering. Markedskræfter i 2020 har sat skub i disse behov, da organisationer søger måder, hvorpå de kan skabe en mere fleksibel drift, så de kan følge med, hvilket får sikkerhedsorganisationer til at stå over for stigende udfordringer som mangel på dækning af øgede trusler mod forsvarsværkerne, dårlig synlighed og kontrol, manuelle processer og øgede begrænsninger af ressourcer.

Ud over disse behov skal sikkerhedsorganisationer være hurtige til at tilpasse deres tilgang til sikring af infrastruktur i denne hurtigt foranderlige hybride verden. Denne artikel undersøger fire måder, hvorpå sikkerhedsteams kan reagere med nye modeller og fremgangsmåder, der passer bedre til nutidens forretningsbehov:

  1. SaaS-aktiveret sikkerhed. Levering af sikkerhed med tilslutningsmulighed i clouden, skalerbarhed og effektivitet
  2. Udvidet registrering og svar (XDR). Tilbyder større synlighed og kontrol i flere miljøer
  3. Secure access service edge (SASE). Giver lokationsafhængig adgang til virksomhedsressourcer, hvor adgang kontrolleres på baggrund af omfattende oplysninger om selve forbindelsen, aktiviteten og de data, der tilgås
  4. Beholdersikkerhed. Tilbyder en platform til mikrotjenester, der hurtigt kan opdateres og med en konsistent konfiguration

1. SaaS-aktiveret sikkerhed

Et stigende antal sikkerhedskontroller kan bruges som SaaS (software as a service), der ofte refereres til som SECaaS (security as a service). Til forskel fra eksternt drevne sikkerhedstjenester, som f.eks. fjernstyring af sikkerhedshardware lokalt, gennemfører det moderne SECaaS det arkitektoniske skift til sikkerhedsstyring, datalager, analyser og brugergrænsefladekomponenter, der styres fra clouden.

De mest traditionelle sikkerhedsleverandører tilbyder nu adgang til deres produkter i clouden. Komponenter, som f.eks. sårbarhedsscannere, logindsamling og agenter, fortsætter med at blive anvendt lokalt, men funktionerne i centralstyring, konfiguration, datakoncentration, analyser og rapportering, bliver leveret af leverandøren fra et cloudbaseret miljø. Lokale komponenter samt dem, der anvendes i clouden, kommunikerer med leverandørens API over internettet ved hjælp af sikre protokoller, hvilket tillader en samlet visning af hybride miljøer. Systemstyringshandlinger leveres af leverandøren som en standarddel af tjenesten. SECaaS kan derfor reducere sikkerhedsteamets byrde med systemadministration. Eksempler på denne tilgang omfatter SIEM (security information and event management), slutpunktsregistrering og -svar (EDR) samt sårbarhedstest (se figur 1).

Figur 1: Typiske SECaaS-modeller sikrer flere miljøer.

SECaaS-løsninger bruger så vidt muligt API’er, supplerende links med andre værktøjer som f.eks. SOAR (security orchestration, automation and response). Integration med virtualiseret infrastruktur og cloudplatforme giver mulighed for, at arbejdsmængder kan overvåges af sikkerhedstjenesten for at identificere ubeskyttede instanser og automatisere udbedring ved at instruere cloudtjenesten om at anvende en agent eller isolere trusler, indtil de rette forholdsregler tages. Dette sikrer en altid aktiv sikkerhed ved at aktivere beskyttelse fra det øjeblik, hvor arbejdsmængden er funktionel.

API-baseret kommunikation mellem agenterne og SECaaS-administrationslaget giver mulighed for automatiseret opgradering af agenter, hvilket yderligere reducerer kravene til sikkerhedsteamet. Mange SECaaS-løsninger indeholder flere beskyttelsesfunktioner inden for én implementeringskomponent, hvilket minimerer omkostningerne ved at implementere flere agenter.

Disse løsninger er typisk udviklet til clouden, beholdere og mikrotjenester, hvilket giver traditionelle og mere fleksible implementeringsmodeller mulighed for at blive beskyttet af den samme løsning med fælles politikker og rapportering. Konsolidering af værktøjer reducerer kompleksitet, øger dækningen, skaber konsistens og forenkler implementeringen, vedligeholdelsen og driften, hvilket giver sikkerhedsteamet mulighed for at fokusere på vigtige initiativer.

På trods af de potentielle fordele kan implementering af SECaaS skabe udfordringer i form af produktudvikling og afhængighed af serviceudbyderen. Cloudadministrerede løsninger har ikke nogen veldokumenterede oplysninger om løsninger lokalt og har muligvis færre funktioner, særligt sammenlignet med mere udviklede løsninger lokalt fra den samme leverandør.

Derudover introducerer SECaaS-modellen en tredjepart, tjenesteudbyderen, med adgang til konfigurationsdetaljer og systemlogfiler. Disse data og de medarbejdere, der har adgang til disse data, er muligvis placeret på steder uden for en organisations grænser for datasuverænitet. Identiteten af tjenesteadministratorerne og deres aktiviteter vil være uigennemsigtige for kunden, samt meget af den daglige drift, sikkerhedskopier, forretningskontinuitet osv. Derudover er administrationsportalen nødvendigvis synlig på internettet, og platforme bliver ofte betjent i udnyttede miljøer med flere kunder. Denne situation kan forstyrre traditionelle tilgange til sikkerhed og compliance, da der skabes huller i synligheden og den direkte kontrol af driften op i mod ansvar for levering og ressourcer. Tjenesteudbyderen skal gøre interne kontroller synlige sammen med sikkerhedsattestation og bevis på overvåget compliance med branchestandarder. Men kunden, der licenserer løsningen, er stadig ansvarlig for sikkerheden. Derfor bør kunder anvende den rette due diligence under købsprocessen og afholde regelmæssige gennemgange af compliance med leverandøren.

2. Udvidet registrering og svar

Det er generelt accepteret, at absolut forhindring af sikkerhedshændelser er umuligt. Derfor skal sikkerhedsteams sikre registrering og aktiv respons.  For at lykkedes med det skal de bruge værktøjer, der kan indsamle detaljerede oplysninger, transportere oplysningerne tilbage til en central konsol, supportere hændelsesanalyse med interaktive spørgsmål om enhedernes tilstand og i sidste ende ændre systemernes tilstand til at afbryde angreb.  Selvom det endnu ikke er almindeligt anvendt, er EDR-værktøjer (slutpunktsregistrering og -svar) en effektiv og veletableret tilgang til systemforsvar og er en vigtig del af værktøjspakken til komplekse undersøgelser og svar.

EDR-værktøjer har brister, hvad angår synlighed. EDR anvendes typisk udelukkende på virksomhedsleverede slutbrugerenheder. Angriberne kan dog fokusere på mere sårbare områder, som f.eks. netværksforbundne enheder (lagersystemer, printere og netværksprogrammer), BYOD-systemer (bring-your-own-device), cloudbaserede systemer og klynger med IoT-enheder (internet of things), der nu er tilsluttet netværk. Derudover er andre angrebsvektorer som f.eks. e-mail ikke synlig på operativsystemets brugergrænseflade, hvor EDR normalt findes. Niveauet af overvågning af sådanne systemer, baseret på de logfiler, de genererer, er typisk ikke så detaljerede som EDR-funktioner.

Huller i synligheden kan håndteres ved at introducere registrerings- og svarteknologier, der er specifikke til hvert område, hvor hvert værktøj tilbyder detaljeret registrering, undersøgelse og ændring af tilstanden. Netværksregistrering og -svar tilbyder f.eks. analyser af netværkstrafik og integration med netværkskontrolenheder for håndhævelse af svar. Desværre er flere uafhængige specialistteknologier svære at håndtere på en effektiv måde. Dette skaber siloer med synlighed og kontrol, hvor angriberne har mulighed for at skjule sig i revnerne mellem disse systemer.

Ideelt set vil en universel registrerings- og svarfunktion, der ikke kun omfatter forskellige zoner, herunder slutpunkt, netværk og cloud, men også samler oplysningerne, give analytikere mulighed for at spore aktiviteter, der passerer mellem zonerne, og give et enkelt punkt til kontrol af svar. Denne koncentration af synlighed og kontrol indeholder også en platform til analyser, kunstig intelligens og automatisering.

Sikkerhedsleverandører har udviklet udtrykket XDR (extended detection and response - udvidet registrering og svar) for at beskrive et universelt, integreret DR-værktøj med X, der refererer til ”extended” (udvidet) eller ”overalt” dækning. I øjeblikket er der ikke nogen standarddefinition for XDR, der skal medtages i en XDR-løsning, og hvor meget vægt det skal lægge på behandling af logfiler, threat intelligence, analyser og automatisering. XDR som koncept risikerer at blive devalueret som en løsning, når marketingteams har en tendens til at anvende det til alt. Der er dog bred enighed om, at et XDR-system skal nedbryde siloer med information og give mulighed for effektive svarfunktioner. Den sammenlignelige manglende udvikling af XDR er en af udfordringerne ved indførelse. Den utopiske vision af universel registrering og svar kan højst sandsynligt ikke opnås ved en enkelt implementering. Praktiske betragtninger kan forhindre resultatet i at være helt universelt, selvom målet med at øge registrerings- og svarfunktioner stadig kan betale sig.

Der er også andre komplekse forhold ved at sikre, at organisationen har analyseressourcerne og -ekspertisen til at svare på den angivne indsigt. For at kunne bruge oplysningerne effektivt skal sikkerhedsteams have en detaljeret viden om systemernes adfærd og mulige angrebsteknikker. Maskinlæring ser til dels lovende ud inden for dette område og er en funktion, der bruges mere og mere som supplement og endda til erstatning for signaturbaserede registreringer. Det er også nødvendigt at have en plan og de rette godkendelser til de svarhandlinger, der muligvis er påkrævet.

Samling af registrering og svar har en tendens til at fremhæve valget af en enkelt leverandør til alle komponenter, men sikkerhedsorganisationer står ofte over for komplekse valg mellem de bedste og integrerede pakker med værktøjer, leverandørvalg og -administration samt overgang fra eksisterende værktøjer.

XDR kræver en tydelig langsigtet strategi. Organisationer skal vælge teknologier, leverandører, tjenestepartnere med langsigtede planer. De kan starte med at fokusere på de mest udviklede elementer i XDR, de elementer, der har den højeste risiko, der skal dækkes, og de steder, hvor de eksisterende værktøjer giver mindst nyttig indsigt. Det fører typisk til en indledende koncentration på slutpunkter. Når EDR kører effektivt inden for grænserne for synlighed, kan der udvides til XDR.

3. Secure access service edge

Traditionelle sikkerhedskontroller har en tendens til at være koncentreret omkring et koncept med pålidelige og ikke-pålidelige zoner og systemer, der er håndhævet af et stærkt defineret forsvarsværk. Adgang gives som regel baseret på pålidelige brugere, med minimal gennemgang af aktivitet, efter der er givet netværksadgang. Indførelse af en fundamental anderledes tilgang til virksomhedens sikkerhedsarkitektur er et grundlæggende trin for en transformeret virksomhed.

Dette bør være præget af det brancheanerkendte koncept med nul tillid (zero trust), hvor tillid pålægges de individuelle ressourcer frem for hele netværk. SASE-arkitekturen giver mulighed for et cloudleveret, servicebaseret og placeringsuafhængigt tilstedeværelsespunkt for at give mulighed for sikker adgang for distribuerede programmer, tjenester, brugere og enheder. Den kan beskytte både traditionelle og digitalt transformerede miljøer for brugere, hvor de er i begge verdener (se figur 2).

Figur 2. SASE-arkitektur giver mulighed for et cloudleveret, tjenestebaseret og placeringsuafhængigt tilstedeværelsespunkt.

SASE udskifter konceptet med begrænsede adgangspunkter på et forsvarsværk for et virksomhedsnetværk med et virtuelt forsvarsværk for virksomhedsbrugere og eksterne brugere, med adgangsbeslutninger, der er baseret på politik, identitet, enhed og databevidste sikkerhedskontroller.

I stedet for at basere adgangsbeslutninger på initieringen af en ekstern netværkstunnel til et pålideligt virksomhedsnetværk – ved brug af en kombination af bruger og enhed og ved at give adgang til alle interne ressourcer – er adgangsbeslutninger baseret på individuelle tilslutninger, der besluttes på det tidspunkt, hvor de skal bruges. Beslutninger afhænger af identitet, enhedsprofil, tid, bruger, målkontekst og placering – hvem, hvor, hvad, hvornår og hvordan. Angribere kan muligvis få adgang til en enhed på et netværk, men de har ikke så stor mulighed for at flytte til siden, når hver handling og adgang bliver udfordret og genvurderet.

Der er forskellige tilgange til SASE. Nogle involverer slutpunktsagenter, nogle bruger softwaredefinerede wide area-netværksteknikker, andre er tættere forbundet med netværk, der leverer indhold. SASE-arkitektur kombinerer flere kontroller, som f.eks. krypteret indholdsinspektion, sandboxing, filtrering, forhindring af tyveri af legitimationsoplysninger og forhindring af tab af data plus kontekstafhængig autentificering og godkendelse. Disse kontroller er kombineret i ét sammenhængende system via en ensrettet, centraliseret politik. SASE-hændelseslogfiler kan kombineres med avancerede funktioner til adfærdsregistrering og -svar, som f.eks. XDR, for at give mulighed for end to end-overvågning for alle aktiviteter på tværs af arkitekturen, hvilket forstærker organisationens muligheder for at registrere og blokere angreb, når de finder sted. SASE-arkitekturer er typisk hostet i clouden, hvor der bruges en SECaaS-tilgang, der udnytter de fordele, der kommer derfra.

SASE er ikke en lille implementering på et enkelt produkt. Det kræver en strategisk tilgang, hvor traditionelle arkitekturer og investeringer gennemarbejdes, og hvor konventionelle forbindelser til internetserviceudbydere og virtuelle cloudbaserede wide area-netværk, som f.eks. MPLS, udskiftes med et cloudbaseret grundlæggende element og SD-WAN. Et skift til FWaaS (firewall as a service) er et andet element, der er typisk for denne strategi, hvor firewalls for hardware og forsvarsværker lokalt flyttes til en grundlæggende cloudløsning.

Koncentrationen af sikkerhedskontroller og politikker i SASE-arkitekturen, med tæt integration mellem komponenter, kan afveje evnen til at integrere med individuelle komponenters ydeevne. Det er muligvis ikke praktisk at indføre den bedste fremgangsmåde på tværs af hele arkitekturen. Med det tempo, hvorved de generelle leverandører indfører SASE, og tilsynekomsten af innovatører, betyder dog, at individuelle funktionelle forhindringer skal være kortvarige og bør blive opvejet af bredere fordele, som kan opnås af arkitekturen som et hele.

4. Beholdersikkerhed

Én tendens i den aktuelle programudvikling er segmenteringen af programmet i en samling af mikrotjenester for at håndtere kompleksiteten og afhængigheden af monolitiske programmer. Denne tilgang har også den ønskede sikkerhedsegenskab ved isolering af fejl. Arkitekturen sammen med implementeringsteknikken til kontinuerlig integration og CI/CD ser de mikrotjenester, der er implementeret i beholdere, der indkapsler al koden og alle afhængighederne i et enkelt billede.

Disse billeder gennemgår jævnligt udviklings- og implementeringsgentagelser. Samtidig med at programstrukturen forenkles, er selve beholdermiljøerne komplekse, med flere lag af abstraktion (billeder, beholdere, hosts, kørsler af beholder, registreringsdatabaser og arrangør), der kræver specialiserede værktøjer til at fortolke, overvåge og sikre.

Ikke-udviklede implementeringer af arkitekturer med mikrotjenester kan have nogle af de samme sikkerhedsproblemer som monolitiske programmer. Indarbejdningen af f.eks. forældede, ikke-rettede, sårbare komponenter og biblioteker eller miskonfiguration kan skabe problemer med flere beholdere i programmet. Den hurtige udvikling og implementering af programmer tager typisk dage frem for måneder, men den er ofte i konflikt med traditionelle sikkerhedstilgange som gennemgang af kode, indtrængningstest og kvitteringer for omfattende ændringer.

Sikkerhedsorganisationer skal sikre, at sikkerheden er indbygget i CI-/CD-processen og understøtter hurtige udviklingscyklusser. Dette kræver integration med imlementeringsværktøjerne og at nå længere ud end selve beholderne i hele beholderens livscyklus. Ved at gøre det kan brug af nogle af de indbyggede egenskaber af beholdere og hurtig implementering føre til en mere robust sikkerhed. Brug af f.eks. den automatiserede test og implementering, der er indbygget i CI/CD, kan understøtte langt mere rettidig implementering af programrettelser med en højere tillid til, at de er blevet testet grundigt, hvilket sikrer en nem rute til afbrydelse af evt. ændringer. Bedste fremgangsmåder omfatter:

  • Sikring af kilden. En CI-/CD-proces er en attraktiv måde for angribere at implementere kode på, eftersom hvis de kan ændre kilden, vil CI/CD se det som leveret til produktion. Derfor skal de komponenter, som beholderne er konstrueret fra, komme fra pålidelige kilder med stærke adgangskontroller og integritetskontroller på komponenterne.
  • Inkorporering af de seneste versioner. Brug af ældre, sårbare komponenter i beholderafbildninger er en af de største årsager til beholdersårbarheder. Systemet skal kontrollere for og inkorporere de seneste versioner.
  • Kontinuerlig scanning efter sårbarheder. Inkorporeringen af scanning efter sårbarheder i CI-/CD-pipelinen kan tilføre tillid til, at de seneste komponenter er blevet inkorporeret og konfigureret korrekt.
  • Uforanderlighed. Denne tilgang siger, at ingen ændringer i kørende beholdere, er acceptabel. Dette kræver, at der kun foretages opdateringer via den registrerede, versionerede implementeringsproces, hvilket sikrer konsistens og gentagelsesnøjagtighed. Det betyder også, at ændringer på kørende beholdere i sagens natur er mistænkelige.
  • Hostsikkerhed. Brug af simple, beholderspecifikke operativsystemer plus brugen af og test af benchmarks med bedste fremgangsmåder minimerer angrebsoverfladen.
  • Administration af hemmeligheder. Beholdere kræver hemmeligheder som API-nøgler, legitimationsoplysninger og certifikater til autentificerings- og godkendelsesaktiviteter. Disse følsomme oplysninger bør aldrig opbevares inden i beholderkilder. De bør i stedet opbevares i et separat lager og kun gøres tilgængelige, når det er nødvendigt, til de rette beholdere og programmer.
  • Overvågning og svar. Overvågning kan udføres både inde i beholderen og af det underliggende operativsystem. Koncentrationen af beholdere i en enkelt, simpel opgave kan hjælpe med overvågning af adfærd. Den beholderbaserede tilgang kan også hjælpe med svar ved at blokere forbindelser eller sætte en enkelt komponent på pause.

Der kan også opstå udfordringer ved administrationen af beholdere. Antallet af beholdere, der kan være, og den hastighed, hvorved de kan oprettes og trækkes tilbage, kan være betydelige udfordringer for systemer, der prøver at overvåge dem, og for analytikere, der prøver at fortolke systemets adfærd.

Forenkling af udviklingsopgaven ved at opdele den i et sæt af veldefinerede mikrotjenester kan dog forbedre sikkerheden af programlaget, men kompleksiteten af infrastrukturen, der kræves for at understøtte den pågældende arkitektur i stor skala, kan dog være af betydelig størrelse. Platforme til administration af hemmeligheder kan f.eks. være svære at integrere, mens der skal gøres plads til behov for hastighed og skalerbarhed, når der er hundredvis eller endda tusindvis af mikrotjenester.

Organisationsmæssige problemer skal tages hånd om, når sikkerhedsfunktionen skifter fra at være en separat handling, der arbejder i udvidede tidsrammer på store, sjældne implementeringer, til én, der er tæt integreret med eller delegeret til udviklings- og implementeringshandlingen, som kræver automatisering af processer og hurtige beslutninger.

Containerisering, der udføres godt, kan forbedre sikkerheden, men infrastrukturens kompleksitet stiger også, hvilket kræver strategi, pleje, opmærksomhed og ressourcer.

Få sikkerhedskontrollerne til at fungere

Under flytningen til fjernarbejde i 2020 indførte sikkerhedsteams eksisterende kontrol af forsvarsværker som en nødvendighed og var med i kapløbet om at implementere eller øge kapaciteten for fjernadgang samt knap så strikse krav og kontroller. Med medarbejdere, der brugte deres egne enheder i fælles hjemmemiljøer på tværs af offentlige netværk, har angribere forsøgt at udnytte disse ændringer med tematiserede phishingangreb til at stjæle data og afpresse organisationer med ransomware. Her kan du se, hvordan disse sikkerhedsstrategier kan hjælpe med at håndtere disse sårbarheder:

  • SaaS-aktiveret sikkerhed. Sigter efter at tillade det samme adgangsniveau og den samme sikkerhed, uanset om du arbejder inden eller uden for organisationens traditionelle forsvarsværk. Det kan også tilbyde nogle endnu mere nuancerede, detaljerede autorisationsbeslutninger og indholdsinspektion, end det er muligt med VPN-teknologier.
  • Secure access service edge. Understøtter sikkerhedsteamet, som også arbejder hjemmefra, ved at give dem adgang til sikkerhedsadministrationsværktøjer, der er udviklet til at fungere på tværs af internettet. Denne cloudbaserede tilgang giver sikkerhedsteams mulighed for at administrere værktøjer eksternt og supportere adskillige ændringer i systemer og programmer.
  • Udvidet registrering og svar. Udvider synligheden på tværs af miljøet fra slutpunkter via netværk til cloudsystemer. Denne tilgang spiller også en rolle i effektiv registrering og svar uden behov for fysisk interaktion. Selv grundlæggende slutpunktsregistrering og -svar har en rolle i ekstern undersøgelser af og svar på angreb.

Ændringer i 2020 skabte også et hidtil ukendt behov for hurtig implementering af programmer på tværs af næsten alle brugstilfælde, inklusive online videokonferencer, sundhedstjenester, offentlige hjælpeprogrammer, finansielle tjenester og online bestilling og levering.

Klargøringen af clouden til mikrotjenester har understøttet meget af udvidelsen mod hurtig udvikling og CI/CD. Derfor er beholdere og alle aspekter af sikkerhed omkring dem utrolig relevant.

SECaaS er en nøglekomponent i klargøring af clouden for disse nye programmer. Derudover kan XDR hjælpe med at sikre de slutpunkter, der bruges af udviklere og administratorer, og tilbyde overvågnings-, undersøgelses- og svarfunktioner til infrastruktur, efterhånden som den indføres og lanceres. SASE kan også spille en rolle i på effektiv vis at kontrollere adgangen til nye systemer.

Konklusion

Løbende ændringer til teknikker til levering af infrastruktur understøtter den digitale ændring og opfylder behovene for fleksibel systemlevering og ændringer til brugsmønstre. Disse tendenser kræver ændringer til den måde, sikkerhedskontroller implementeres på. Samtidig kæmper organisationer med mængden af information, de allerede modtager, og bruger betydelige ressourcer på vedligeholdelse af de eksisterende systemer.

Fire vigtige teknologier kan styrke en organisations sikkerhedsstrategi til håndtering af udfordringerne, understøtte transformationen og udvikle en platform til fremtidige udviklinger:

  • SaaS-aktiveret sikkerhed for at give en visning på tværs af traditionelle organisationsmæssige forsvarsværker og for at overføre byrden af vedligeholdelse af sikkerhedsadministrationsværktøjer til en tjenesteudbyder
  • Udvidet registrering og svar (XDR) for at give en mere detaljeret synlighed i og kontrol over miljøer
  • Secure access service edge (SASE) for at konsolidere eksisterende kontroller og give mulighed for placeringsafhængig adgang til ressourcer, med detaljeret kontrol over den adgang, der gives i en tilgang med nul tillid
  • Beholdersikkerhed for at tilbyde en platform til mikrotjenester, der hurtigt kan opdateres og med en konsistent konfiguration

Indførelse af disse brede tilgange hjælper organisationers sikkerhedsteams med at øge dækningen og synligheden af sikkerhedsrelaterede hændelser, hvilket giver dem mulighed for at koncentrere sig om at administrere sikkerhedsresultater i stedet for at bruge tid på at administrere platforme, hvilket er tidskrævende og distraherer dem fra at udføre deres egentlige job.

Om DXC i sikkerhed

DXC Technology, der er anerkendt som førende inden for sikkerhedstjenester, hjælper kunder med at undgå potentielle angrebsveje, reducere cyberrisiko og forbedre trusselsregistrering og hændelsessvar. Vores rådgivningstjenester, der består af eksperter, og 24x7 administrerede sikkerhedstjenester, understøttes af 3.000 eksperter og et globalt netværk af sikkerhedsdriftscentre. DXC tilbyder løsninger, der er skræddersyet til vores kunders forskellige sikkerhedsbehov, med områder inden for specialisering i cyberforsvar, digital identitet, sikret infrastruktur og databeskyttelse.

Find ud af, hvordan DXC kan hjælpe med at beskytte din virksomhed midt i den store digitale forandring på dxc.technology/security.

Om forfatterne

Dr. Rhodri Davies er DXC Technologys arkitekt inden for sikkerhed og servicehandlinger, med mere end 20 års erfaring inden for området. Han arbejder i afdelingen Managed Security Services hos DXC, hvor han koncentrerer sig om de teknologier, der kræves for at sikre DXC’s kunder, og den måde, disse teknologier håndteres dagligt for at kunne tilbyde en effektiv tjeneste.

Mike Dutton, senior sikkerhedsarkitekt for DXC Managed Security Services i Australien, har næsten 10 års erfaring hos DXC og har været involveret i næsten alle DXC’s administrerede sikkerhedstjenester, med fokus på sikkerhed i clouden. Han sikrer, at DXC vælger de relevante og effektive sikkerhedskontroller for at hjælpe kunder med at nå deres mål med digital transformation.

Yahya Kharraz er informationssikkerhedsarkitekt hos DXC Technology med en bred erfaring inden for sikkerhed, fra tekniske løsninger til sikkerheds- styring og -risici. Han har en solid erfaring inden for slutpunkts- og infrastruktursikkerhed og brænder for cloud, udvikling af webprogrammer, automatisering og kodning. Som en del af hans faglige interesse udforsker og evaluerer han konstant de helt nye teknologier.

Dirk Thys er i øjeblikket rådgiver inden for sikkerhed og compliance hos DXC Technology. Han er også lead-arkitekt/-udvikler med ansvar for hærdning af og sikkerhed i forbindelse med Platform DXCTM i hele verden. Dirk arbejder tæt sammen med partnere og leverandører for at opnå DXC’s virksomhedsmål og opfylde kundernes krav. Han har haft adskillige førende roller inden for it-drift, -udvikling, -projekter og -programmer og har administreret platformssikkerhedsteams med ansvar for levering af tjenester inden for styring af compliance for mere end 600 kunder i hele verden.