Skabe teststandarder for dine etiske hacker - dummies

En fejlkommunikation eller glidning i dine teststandarder kan sende systemerne nedbrud under dine etiske hacking tests. Ingen vil have det til at ske. For at undgå uheld skal du udvikle og dokumentere teststandarder. Disse standarder skal omfatte

Når testene udføres, sammen med den overordnede tidslinje
Hvilke tests udføres
Hvor meget viden om de systemer, du erhverver på forhånd
Hvordan testene udføres, og fra hvilken kilde IP-adresser
Hvad du gør, når der opdages en større sårbarhed

Tid dine tests

Dette gælder især ved udførelse af etiske hackingstest. Sørg for, at de tests, du udfører, minimerer forstyrrelser i forretningsprocesser, informationssystemer og mennesker. Du vil undgå skadelige situationer, som f.eks. Misligholde tidspunktet for test og forårsage et DoS-angreb mod et e-handelssted med høj trafik midt om dagen eller udføre adgangskodeprøvning i midten af natten.

Selv om der er mennesker i forskellige tidszoner, kan der opstå problemer. Alle på projektet skal være enige om en detaljeret tidslinje, før du begynder. At have gruppemedlemmernes aftale sætter alle på samme side og sætter de rigtige forventninger.

Din testtidslinje skal indeholde specifikke kortfristede datoer og tider for hver test, start- og slutdatoer og eventuelle specifikke milepæle i mellem. Du kan udvikle og indtaste din tidslinje i et simpelt regneark eller Gantt-diagram, eller du kan inkludere tidslinjen som en del af dit oprindelige klientforslag og kontrakt. Din tidslinje kan også være arbejdsopdelingsstrukturer i en større projektplan.

Kør specifikke tests

Du har måske fået ansvaret for at udføre en generel penetrationstest, , eller du vil muligvis udføre specifikke tests, som f.eks. Krakning af adgangskoder eller forsøger at vinde adgang til en webapplikation. Eller du kan udføre en social engineering test eller vurdere Windows på netværket.

Men du tester, du vil måske ikke afsløre testens specifikationer. Selv når din leder eller klient ikke kræver detaljerede registreringer af dine tests, skal du dokumentere, hvad du laver på et højt niveau. Dokumentering af din test kan hjælpe med at eliminere enhver mulig fejlkommunikation.

Du kan kende de generelle tests, du udfører, men hvis du bruger automatiserede værktøjer, kan det være umuligt at forstå hver test, du udfører fuldstændigt. Dette gælder især, når softwaren du bruger, modtager opdateringer og opdateringer i realtid fra sælgeren hver gang du kører den.Potentialet for hyppige opdateringer understreger vigtigheden af at læse dokumentationen og de filer, der følger med de værktøjer, du bruger.

Blinde versus videnvurderinger

At have en vis viden om de systemer, du tester, kan være en god ide, men det er ikke påkrævet. Men en grundlæggende forståelse af de systemer, du hakker, kan beskytte dig og andre. At erhverve denne viden bør ikke være svært, hvis du hakker dine egne interne systemer.

Hvis du hakker en klients systemer, skal du muligvis grave lidt dybere ind på, hvordan systemet fungerer, så du er bekendt med dem. Det betyder ikke, at blinde vurderinger ikke er værdifulde, men den type vurdering du udfører afhænger af dine specifikke behov.

Den bedste fremgangsmåde er at planlægge ubegrænset angreb, hvor enhver test er mulig, muligvis endda herunder DoS-test.

Overvej, om testene skal udføres, så de ikke er opdaget af netværksadministratorer og administrerede sikkerhedstjenesteudbydere. Selvom det ikke kræves, bør denne praksis overvejes, især for social engineering og fysiske sikkerhedstest.

Placering

De tests du udfører dikterer, hvor du skal køre dem fra. Dit mål er at teste dine systemer fra steder, der er tilgængelige for ondsindede hackere eller medarbejdere. Du kan ikke forudsige, om du vil blive angrebet af nogen indenfor eller uden for dit netværk, så dække alle dine baser. Kombiner eksterne tests og interne test.

Du kan udføre nogle tests, som f.eks. Adgangskodekrav og netværksinfrastrukturvurderinger fra dit kontor. For eksterne hacks, der kræver netværksforbindelse, skal du muligvis gå væk fra webstedet eller bruge en ekstern proxyserver. Nogle sikkerhedsleverandørers sårbarhedsscannere køres fra skyen, så det ville også fungere.

Endnu bedre, hvis du kan tildele en tilgængelig offentlig IP-adresse til din computer, skal du blot tilslutte til netværket på firewallens udside for at få et hackers syn på dine systemer. Interne test er nemme, fordi du kun har fysisk adgang til bygningen og netværket. Du kan muligvis bruge en DSL-linje eller et kabelmodem, der allerede er til rådighed for besøgende og lignende brugere.

Svar på sårbarheder, du finder

Bestem før tiden, om du vil stoppe eller fortsætte, når du finder et kritisk sikkerhedshul. Du behøver ikke at holde hacking for evigt, eller indtil du styrter alle systemerne. Bare følg stien, du er på, indtil du bare ikke kan hacke den længere. Når du er i tvivl, er det bedste at lave et bestemt mål i tankerne og derefter stoppe, når målet er nået.

Hvis du opdager et større hul, skal du straks kontakte de rigtige personer, så de kan begynde at løse problemet med det samme. De rigtige mennesker kan være softwareudviklere, produkt- eller projektledere eller endda CIO'er. Hvis du venter et par dage eller uger, kan nogen udnytte sårbarheden og forårsage skade, der kunne have været forhindret.

Dumme antagelser

Du har hørt om hvad du selv laver, når du går ud fra ting. Alligevel gør du antagelser, når du hakker et system.Her er nogle eksempler på disse antagelser:

Computere, netværk og personer er tilgængelige, når du tester.
Du har alle de rigtige testværktøjer.
De testværktøjer, du bruger, minimerer chancerne for at nedbryde de systemer, du tester.
Du forstår sandsynligheden for, at eksisterende sårbarheder ikke blev fundet, eller at du brugte dine testværktøjer forkert.
Du kender risiciene ved dine test.

Dokumentér alle antagelser, og få ledelsen eller din klient til at logge på dem som en del af din overordnede godkendelsesproces.