Guide til cybersikkerhed og DMS-robusthed hos bilforhandlere

1. Modellér forhandlerens reelle angrebsflade

DMS'et står sjældent alene. Det udveksler kunde-, køretøjs-, pris-, reparations-, reservedels- og regnskabsdata med CRM, OEM-portaler, finansieringsudbydere, websites, telefonsystemer, diagnoseværktøjer og regneark. Afdelingsnetværk omfatter kontorenheder, værkstedsudstyr, wi-fi, printere, kameraer og leverandørers fjernadgang. Hver identitet og grænseflade er en del af driftsgrænsen.

Begynd med en oversigt over aktiver og dataflows. Registrér ejer, formål, brugere, administrator, interneteksponering, autentificering, integrationer, datafølsomhed, leverandør og afhængighed af genopretning. Medtag sovende grænseflader og robotkonti. Ukendte ældre forbindelser er særligt farlige, fordi de kan beholde brede rettigheder, efter deres forretningsformål er ophørt.

ENISA analyserede 4.875 hændelser til Threat Landscape 2025. I delmængden af cyberkriminalitet udgjorde ransomware 81,1 %, mens ransomware-relaterede brud udgjorde 15,2 % af alle hændelser. [1] Disse nævnere er forskellige og må ikke sammenblandes. Den driftsmæssige læring er, at forhandlere har brug for både forebyggelse og evnen til genopretning.

2. Gør identitet til sikkerhedens kontrolplan

Kræv phishingresistent multifaktorgodkendelse, hvor den er tilgængelig, særligt for administratorer, e-mail, fjernadgang og økonomi. Centralisér login, hvor det er praktisk, og blokér delte brugerkonti. Servicekonti skal have ejere, snævre rettigheder, roterede hemmeligheder og må ikke bruges interaktivt. API-legitimationsoplysninger skal opbevares i en hemmelighedstjeneste, ikke i scripts eller tickets.

Indfør en proces for tiltrædelse, rolleændring og fratrædelse, der afspejler personaleomsætning og rolleændringer hos forhandleren. Deaktivér adgang straks ved fratrædelse, fjern gamle afdelingsrettigheder ved overførsel, og gennemgå privilegeret adgang regelmæssigt. Adskil muligheden for at oprette en leverandør, godkende betaling, eksportere kundedata og ændre sikkerhedsindstillinger.

Overvåg usædvanlige loginplaceringer, umulige rejser, masseeksporter, ændringer af rettigheder, deaktiverede logge og masseændringer af poster. Advarsler skal have ejere og handlingsplaner for respons. Opbevar revisionslogge uden for rækkevidde af den konto, der overvåges, og synkronisér tiden på tværs af systemer, så undersøgere kan rekonstruere hændelser.

3. Reducér teknisk eksponering og integrationsrisiko

Opdatér først internetvendte og udnyttede sårbarheder med udgangspunkt i aktivernes kritikalitet og trusselsdokumentation. Fjern ikke-understøttet fjernstyringssoftware, og luk ubrugte porte. Segmentér diagnose- og værkstedsudstyr fra økonomi- og identitetstjenester. Leverandøradgang bør være tidsbegrænset, godkendt og overvåget.

Beskyt integrationer som produktionssoftware. Validér skema og autorisation, brug idempotens til at forhindre dobbelte finansielle hændelser, begræns de data, der returneres, og beskyt webhook-slutpunkter mod forfalskning og genafspilning. Brug separate legitimationsoplysninger for hvert miljø og hver partner. Én altomfattende integrationskonto undergraver rolledesignet.

4. Udform genopretning omkring forhandlerens drift

Definér recovery point objective, recovery time objective og maksimal tolerabel nedetid for modtagelse af leads, værkstedsplanlægning, reservedele, fakturering, udlevering af køretøjer og løn. Afhængigheder er vigtige: Genopretning af DMS'et uden identitet, DNS, dokumentlager eller en OEM-forbindelse genskaber måske ikke en brugbar tjeneste.

Oprethold uforanderlige eller isolerede sikkerhedskopier, der er beskyttet af legitimationsoplysninger adskilt fra produktionsadministrationen. Test genopretning til et rent miljø, og verificér datakonsistensen, ikke blot at filerne findes. Registrér forbrugt tid og manuelle trin. Opbevar leverandørkontakter og licensoplysninger i en offline beredskabspakke.

Forbered kontrollerede procedurer for nedetid: hvordan kunder verificeres, arbejde registreres, udlevering af køretøjer godkendes, reservedele registreres, papirblanketter beskyttes, og transaktioner afstemmes efter genopretning. Øv med afdelingsledere. Manuel kontinuitet er ikke en tilladelse til at omgå svindel- og databeskyttelseskontroller.

5. Betragt leverandører som en del af kontrolmiljøet

Bed om dokumentation, der står mål med risikoen: hosting og dataresidens, kryptering, identitetskontroller, revisionslogge, sikker udvikling, sårbarhedshåndtering, uafhængig erklæring, tilgang til penetrationstest, hændelseshistorik, underdatabehandlere, kontinuitet, tilbagelevering og sletning af data. Et certifikat er nyttigt, men svarer ikke på, om en forhandler har konfigureret MFA eller for brede rettigheder.

Kontrakter bør definere hændelsesunderretning, samarbejde, bevissikring, genopretningsmål, ændringer af underdatabehandlere og støtte ved ophør. Kortlæg fjerdeparter, der væsentligt kan forstyrre tjenesten. Revurdér ved fornyelse og efter større ændringer i arkitektur eller ejerskab.

For personoplysninger kræver GDPR artikel 32, at dataansvarlige og databehandlere bruger foranstaltninger, der er passende i forhold til risikoen, herunder efter omstændighederne kryptering, robusthed, genopretning og regelmæssig test. [2] Dette er risikobaseret, ikke en fast tjekliste.

6. Forstå NIS2 og køretøjsregler uden at overdrive

NIS2 er direktiv (EU) 2022/2555, så medlemsstaterne gennemfører det i national ret. Anvendelsesområdet afhænger af sektor, enhedstype, størrelsesregler, nationale valg og udpegning. Fremstilling af motorkøretøjer fremgår af bilag II, og visse cloud-, managed service- og digitale udbydere er omfattede kategorier. En almindelig bilforhandler er ikke automatisk omfattet, blot fordi den sælger eller servicerer køretøjer. [3]

Selv når en forhandler er uden for det direkte anvendelsesområde, kan OEM- eller leverandørkontrakter videreføre krav. Omfattede enheder får forpligtelser til styring, risikohåndtering og hændelsesrapportering efter national gennemførelse. Kontrollér den juridiske enhed og gældende national lovgivning i stedet for at stole på en opsummering på EU-niveau.

UNECE-regulativ nr. 155 og 156 omhandler køretøjscybersikkerhed og styring af softwareopdateringer i typegodkendelsesrammen. [4] De vedrører primært producenter og godkendte køretøjstyper, ikke certificering af enhver forhandlers DMS. Forhandlere kan dog understøtte kontrollerede softwareopdateringer, dokumentation for kampagner og eskalering af hændelser i den bredere bilindustrielle kæde.

Hvor Omnetic passer ind

Omnetics dokumenterede moduler forbinder CRM, køretøjets livscyklus samt workflows for lager, prissætning og inspektion. Færre ukontrollerede overleveringer kan forbedre det driftsmæssige overblik, men konsolidering koncentrerer også afhængighed og skal beskyttes tilsvarende. Produktdokumentationen omtaler API'er, webhooks, eksterne identifikatorer og planlagte eksporter uden at offentliggøre et komplet katalog over sikkerhed eller grænseflader.

Før valg bør I bede Omnetic dokumentere hosting, dataresidens, kryptering, RBAC, MFA eller 2FA, revisionslogge, isolering af sikkerhedskopier, genopretningstest, hændelsesvilkår, sårbarhedshåndtering, underdatabehandlere og integrationssikkerhed. Validér konfiguration og ansvar i det påtænkte land og den påtænkte pakke.