Ved å sende PCI DSS ekstern sårbarhetsskanning

I mitt første TechRepublic-innlegg om betalingskortindustriens sikkerhetsstandard (PCI DSS), beskrev jeg trinnene selskapet vårt tok for å oppnå innledende etterlevelse ved å passere eksterne skanninger og fylle ut et spørsmålsutvalg for egenvurdering. I mitt andre innlegg om PCI DSS skrev jeg om å lykkes med å takle årsakene til ekstern sårbarhetsskanningsfeil. Som jeg antydet den gang, endringer i systemene dine og skannealgoritmene, kombinert med det stadig utviklende trusselandskapet, betyr at det å gi skanninger aldri kan tas for gitt.

Og det er det bevist for oss de siste månedene. Vi klarte å fikse to skanningsfeil, men har ikke mindre enn tre utestående problemer. Jeg ventet på at alle skulle bli løst før jeg skrev dette, men tenkte at jeg kunne ventet en stund på den måten. Dessuten er realiteten i IT at vi ikke får spikret alt over natten.

Fast: Svak hasjfunksjon for et SSL-sertifikat

Min ledetråd til dette var det ikke-standard portnummeret som skanningen mislyktes på: 4433. Dette var nummeret vi valgte da vi eksperimenterte med SSL VPN på SonicWALL-ruteren vår (fordi vi bruker standard 443 til andre formål). Det aktuelle sertifikatet var sannsynligvis en innebygd selvsignert som følger med enheten, men det var ikke nødvendig å undersøke i dybden. Siden vi ikke har distribuert SSL VPN på SonicWALL, var løsningen enkel - bare slå av SSL VPN-tjenesten.

Fast: SSL / TLS-protokollinitieringsvektor for informasjonsgjennomgang for informasjonsutvikling

Denne gangen visste jeg at problemet lå på Exchange-serveren vår fordi referansen var til port 443, som vi ruter dit for bruk med Outlook Web Access (OWA). Den fulle beskrivelsen av problemet så skremmende ut, og jeg forsto det fortsatt ikke etter å ha lest det flere ganger. Med tanke på den gode gamle Google, trakk jeg frem det jeg trodde ville være nøkkelfraser å bruke som søkeord. Disse inkluderte referanser til:

  • SSLv3 / TLSv1
  • "BEAST" -angrepet
  • Sikkerhetsoppdatering MS12-006
  • Blokker chiffer
  • PCI DSS

Jeg fant snart relevante diskusjoner og artikler. En mulig løsning var å bare tillate TLSv1.1. Denne Stack Exchange-artikkelen advarte om at "begge sluttpunktene må støtte TLS 1.1 før du kan opprette en TLS 1.1-forbindelse", så jeg var redd for at bare å deaktivere TLS 1.0 på Exchange-serveren kunne stoppe noen nettlesere som kobler seg til OWA.

Beskrivelsen av feilen henviste til en registerreparasjon kjent som "post-splitting løsning." Da fant jeg en Microsoft-artikkel som varsler om problemer med fiksen. Å bra.

Jeg bestemte meg for å sette kursen mot å deaktivere TLS 1.0 og se om noe brøt som et resultat. Da jeg lette etter detaljer om hvilke registernøkler som skulle endres, kom jeg over et par anbefalinger for et verktøy som heter IIS Crypto. Som du ser i figur A, har IIS Crypto en spesifikk PCI-knapp for å bruke en forhåndsdefinert innstillingsmal. Figur A

IIS Crypto-verktøy

Selv om andre mennesker syntes å ha en god opplevelse med IIS Crypto, tok jeg fremdeles en forsiktig tilnærming. Jeg tok skjermbilder av IIS Crypto før jeg gjorde noen endringer og etter å ha klikket på PCI-knappen, men før jeg brukte endringene. Jeg tok også sikkerhetskopi av HKLM \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ schannel registernøkkel, da det er her IIS Crypto ville gjøre betydelige endringer.

Etter å ha brukt endringene, advarte IIS Crypto at en omstart var nødvendig. En omstart var ikke praktisk den gangen, så jeg dro til dagen og sjekket hjemmefra at jeg fremdeles kunne få tilgang til OWA fra IE9 og Safari. Jeg hadde også sparket av en PCI-rescan, som gikk.

Mislykket: FTP-problemer med FileZilla Server

Her går historien litt nedover. Skanningen rapporterte flere FTP-relaterte feil på en Windows 2003-server som kjører FileZilla Server. Ser vi på de tilgjengelige innstillingene i FileZilla Server, så det ut til at FTP over SSL / TLS (eller FTPS) ville være veien å gå. Selv om FileZilla kan generere et SSL-sertifikat, vil dette nesten sikkert mislykkes i skanningen også, så vi trengte å installere vårt nylig kjøpte jokertekst-SSL-sertifikat.

Det var ikke enkelt å importere sertifikatet til FileZilla (fra mitt synspunkt), men vi kom dit. Jeg vil ikke gå i detalj fordi det til slutt ikke hjalp.

Etter å ha importert sertifikatet og oppgradert til den nyeste versjonen av FileZilla Server, passerte vi skanningen! Dessverre oppdaget vi at kundene våre ikke lenger kunne få tilgang til FTP-nettstedet. Å innse at dette hadde vist seg å være en av disse "trygge, men unyttige" rettelsene, gravde jeg litt dypere i å prøve å forstå sikker FTP. Dette er hva jeg fant:

Dette StackExchange-innlegget gjør det klart at (a) sFTP er forskjellig fra FTPS (b) FTPS er "vanskelig å gjøre med brannmurer" og (etter noen meninger) uansett ikke veldig bra. FTPS er det FileZilla Server tilbyr. Videre er dette StackExchange-innlegget enig i at sFTP er veien å gå sammenlignet med FTPS, men det ser ikke ut til å være mulig å konfigurere med FileZilla-server.

Vår strategi med denne er å vente fordi heldigvis denne FTP-serveren kommer til å bli trukket tilbake i ikke altfor fjern fremtid.

Mislyktes: SSL VPN-apparat og IPSec VPN

Tilbake i 2009 gjorde produsenten av vårt SSL VPN-apparat (Billion) firmwareendringer for å få systemet til å passere PCI-skanninger. I 2012 feilet apparatet igjen med fire nye problemer relatert til sikkerheten til SSL og TLS. Etter flere ukers korrespondanse konkluderte Billion at maskinvaren ikke kunne støtte de nødvendige endringene for å løse disse problemene. For å bli kompatibel igjen, må jeg bytte ut Billion-apparatet. Én jobb lagt til oppgavelisten.

For en stund tilbake begynte vi å bruke IPSec VPN-funksjonen på SonicWALL NSA 240 for å tilby en alternativ metode i tilfelle problemer med SSL VPN. Ironisk nok har også dette nå blitt offer for en PCI-skanningssvikt på grunn av bruken av en forhåndsdelt nøkkel (PSK) med Aggressive Mode. Det virker som om de eneste alternativene mine for å fikse dette er å bytte til hovedmodus (som krever at VPN er sted-til-side) eller å bruke sertifikater i stedet for PSK. Jobb nr. 2 for oppgavelisten.

Sammendrag

Ekstern sårbarhetsskanning er en god risikostyringspraksis for enhver organisasjon, uansett om de er nødvendige for PCI DSS-samsvar. Trinnene som trengs for å passere skanningene er imidlertid ikke alltid enkle, og aktiviteten må betraktes som pågående snarere enn en engangsøvelse.

Nyhetsbrev om innovasjon

Vær kjent med smarte byer, AI, Internet of Things, VR, AR, robotikk, droner, autonom kjøring og mer av de kuleste teknologiske nyvinningene. Leveres onsdager og fredager

Registrer deg i dag

© Copyright 2021 | mobilegn.com