Maak testnormen voor uw ethische hacks - dummies

Eén miscommunicatie of misstap in uw testnormen kan de systemen tijdens het testen doen crashen tijdens je ethische hacktests. Niemand wil dat dat gebeurt. Om ongelukken te voorkomen, ontwikkelt en documenteert u testnormen. Deze standaarden moeten

bevatten Wanneer de tests worden uitgevoerd, samen met de algemene tijdlijn
Welke tests worden uitgevoerd
Hoeveel kennis van de systemen die u van te voren verkrijgt
Hoe de tests worden uitgevoerd en van welke bron IP-adressen
Wat u doet wanneer een grote kwetsbaarheid wordt ontdekt

Tijd voor uw tests

Dit geldt vooral voor ethische hacktests. Zorg ervoor dat de tests die u uitvoert de verstoring van bedrijfsprocessen, informatiesystemen en mensen tot een minimum beperkt. U wilt schadelijke situaties vermijden, zoals het verkeerd communiceren van de timing van tests en het veroorzaken van een DoS-aanval tegen een e-commercesite met veel verkeer midden op de dag of het uitvoeren van wachtwoordkraaktoetsen midden in de nacht.

Zelfs mensen in verschillende tijdzones kunnen problemen veroorzaken. Iedereen in het project moet het eens zijn over een gedetailleerde tijdlijn voordat je begint. Als de teamleden akkoord gaan, komt iedereen op dezelfde pagina en worden de juiste verwachtingen geformuleerd.

Uw testtijdlijn moet specifieke kortetermijndatums en -tijden van elke test, de begin- en einddatum en eventuele tussentijdse mijlpalen bevatten. U kunt uw tijdlijn ontwikkelen en invoeren in een eenvoudig spreadsheet- of Gantt-diagram, of u kunt de tijdlijn opnemen als onderdeel van uw oorspronkelijke klantvoorstel en contract. Uw tijdlijn kan ook werkafbraak zijn in een groter projectplan.

Voer specifieke tests uit

Mogelijk bent u belast met het uitvoeren van een algemene penetratietest, of wilt u mogelijk specifieke tests uitvoeren, zoals kraken van wachtwoorden of proberen te winnen toegang tot een webapplicatie. Of misschien voert u een social engineering-test uit of beoordeelt u Windows op het netwerk.

Hoe u ook test, u wilt misschien niet de details van de test bekendmaken. Zelfs als uw manager of klant geen gedetailleerde verslagen van uw tests nodig heeft, documenteer u wat u op een hoog niveau doet. Het documenteren van uw testen kan helpen mogelijke miscommunicatie te elimineren.

U kent mogelijk de algemene tests die u uitvoert, maar als u geautomatiseerde hulpprogramma's gebruikt, is het wellicht onmogelijk om elke test die u uitvoert volledig te begrijpen. Dit is met name het geval wanneer de software die u gebruikt real-time updates voor de kwetsbaarheid en patches van de leverancier ontvangt telkens wanneer u deze uitvoert.Het potentieel voor frequente updates onderstreept het belang van het lezen van de documentatie en bestanden die bij de tools die u gebruikt.

Blinde versus kennisbeoordelingen

Kennis hebben van de systemen die u test, is misschien een goed idee, maar het is niet verplicht. Maar een basiskennis van de systemen die u hackt, kan u en anderen beschermen. Het verkrijgen van deze kennis moet niet moeilijk zijn als je je eigen interne systemen hackt.

Als u de systemen van een klant hackt, moet u misschien wat dieper graven in de werking van de systemen, zodat u er bekend mee bent. Dit betekent niet dat blinde beoordelingen niet waardevol zijn, maar het soort beoordeling dat u uitvoert, hangt af van uw specifieke behoeften.

De beste aanpak is om onbeperkte -aanvallen te plannen, waarbij elke test mogelijk is, mogelijk zelfs inclusief DoS-tests.

Overweeg of de tests moeten worden uitgevoerd zodat ze niet worden gedetecteerd door netwerkbeheerders en providers van beheerde beveiligingsservices. Hoewel dit niet vereist is, moet deze praktijk worden overwogen, met name voor social engineering en fysieke beveiligingstests.

Locatie

De tests die u uitvoert, dicteren waar u ze moet uitvoeren. Uw doel is om uw systemen te testen op locaties die toegankelijk zijn door kwaadwillende hackers of werknemers. Je kunt niet voorspellen of je wordt aangevallen door iemand binnen of buiten je netwerk, dus bedek al je bases. Combineer externe tests en interne tests.

U kunt vanuit uw kantoor enkele tests uitvoeren, zoals het kraken van wachtwoorden en beoordelingen van netwerkinfrastructuur. Voor externe hacks waarvoor netwerkconnectiviteit is vereist, moet u mogelijk off-site gaan of een externe proxyserver gebruiken. Sommige kwetsbaarheidscanners van beveiligingsleveranciers worden vanuit de cloud uitgevoerd, dus dat zou ook werken.

Beter nog, als u een beschikbaar openbaar IP-adres aan uw computer kunt toewijzen, sluit u eenvoudig aan op het netwerk aan de buitenkant van de firewall voor een hacker-in-oog-oogpunt van uw systemen. Interne tests zijn eenvoudig omdat u alleen fysieke toegang tot het gebouw en het netwerk nodig hebt. Mogelijk kunt u een DSL-lijn of kabelmodem gebruiken die al aanwezig is voor bezoekers en vergelijkbare gebruikers.

Reageren op kwetsbaarheden die u vindt

Bepaal vooraf of u zult stoppen of doorgaan als u een kritisch beveiligingslek vindt. Je hoeft niet voor altijd te blijven hacken of totdat je alle systemen hebt gecrasht. Volg gewoon het pad waarop je bent totdat je het gewoon niet meer kunt hacken. Bij twijfel is het het beste om een specifiek doel voor ogen te houden en vervolgens te stoppen wanneer dat doel is bereikt.

Als u een groot gat ontdekt, neemt u zo snel mogelijk contact op met de juiste mensen zodat ze meteen het probleem kunnen oplossen. De juiste mensen kunnen softwareontwikkelaars, product- of projectmanagers of zelfs CIO's zijn. Als je een paar dagen of weken wacht, kan iemand misbruik maken van de kwetsbaarheid en schade veroorzaken die voorkomen had kunnen worden.

Domme veronderstellingen

Je hebt gehoord over wat je van jezelf maakt als je dingen aanneemt. Toch maak je aannames wanneer je een systeem hackt.Hier zijn enkele voorbeelden van die veronderstellingen:

Computers, netwerken en mensen zijn beschikbaar tijdens het testen.
Je hebt alle juiste testtools.
De testtools die u gebruikt, minimaliseren de kans dat uw systemen worden gecrasht.
U begrijpt de waarschijnlijkheid dat bestaande kwetsbaarheden niet zijn gevonden of dat u uw testtools verkeerd hebt gebruikt.
U kent de risico's van uw tests.

Documenteer alle aannames en zorg ervoor dat het management of uw klant ze ondertekent als onderdeel van uw algemene goedkeuringsproces.