Spørgsmål vi faktisk får.

En scanner læser et versionsnummer og fortæller, hvad der kunne være galt. Den afleverer en liste af hypoteser og lader jer om triagen — og det er dér, omkring 40 % af de fleste teams’ sikkerhedstid går, før nogen har rettet noget som helst.

Vi laver triagen. En agent prøver hver kandidat af, sikkert, og et menneske sætter sit navn på vurderingen. Omkring 91 % af de rå fund når aldrig frem til jer, fordi de ikke var virkelige. Det, der når frem, kommer med kaldet, svaret og et skærmbillede, så diskussionen med udviklerne tager ti sekunder i stedet for et sprint.

Den anden halvdel af forskellen er omfang. En scanner tjekker den liste, I gav den. Vi går ud og finder listen — certifikattransparens, DNS, sky-adresseblokke, kodeværter, den lagerbucket nogen glemte i 2021 — og tjekker igen hver sjette time. En CVSS 9.8, ingen kan nå, er et rygte. Et åbent adminpanel på et subdomæne, I havde glemt, er en tirsdag.

Nej, og vi vil helst ikke have, at I køber det som en.

En penetrationstest er afgrænset, tidsbegrænset og udført af navngivne mennesker, typisk en gang om året, og den ender i en underskrevet rapport. Vi kører løbende, på tværs af alt hvad I eksponerer, og fortæller hvad der er sandt i denne uge. Forskellige opgaver. Sælger nogen jer det ene som det andet, så spørg hvilken uge deres rapport dækker.

I kan stadig få en gennem os. En penetrationstest kan lægges til enhver abonnement og køres efter en plan. Fordi vi allerede har kortlagt jeres flade, bygger omfanget i udbudsmaterialet på hvad I faktisk har, ikke på hvad nogen kan huske. Vi skriver materialet, sender det ud til flere leverandører på én gang og hjælper jer med at sammenligne svarene på lige vilkår. Deres fund lander derefter samme sted som vores — verificeret, sporet og gentestet ved deploy — i stedet for i en PDF i en mappe, ingen åbner, før revisoren spørger.

Vi udfører ikke testen selv, så vi har ingen grund til at ønske, at den finder meget eller lidt.

Nej. MDR- og SOC-ydelser overvåger jeres enheder og jeres logfiler for nogen, der allerede er inde. Vi overvåger det, I eksponerer udadtil, og beviser hvad nogen kunne nå, før de når det. De to overlapper knap: jeres MDR-aftale udelukker næsten med sikkerhed jeres eget produkt, som er den største angrebsflade I ejer, og den eneste I fuldt ud styrer.

Vi arbejder i kontortid, med vilje. Har I brug for nogen vågen klokken tre om natten, har I også brug for en MDR — og vi ligger opstrøms for den og efterlader færre veje ind for dem at holde øje med.

Det betyder en snæver opgave og en hård regel: bevis det uden at ødelægge noget. En agent tager ét kandidatfund, forsøger at bekræfte det med læseadgangsmetoder og registrerer kaldet, svaret og et skærmbillede. Destruktive klasser er slået fra som standard og bliver det, indtil I skriver under på noget bestemt.

Intet når jer på en agents ord alene. Et menneske læser beviserne og skriver under på vurderingen — hvilket også er grunden til, at der er et navn at give revisoren, når han eller hun spørger, hvem der gennemgik det.

Ikke for at komme i gang. Den gratis gennemgang af angrebsfladen kræver intet fra jer — kan vi nå det fra internettet, så kan vi, og det er netop pointen med øvelsen.

Når I er på en plan, kræver ændringsgennemgangen læseadgang til jeres repositories og CI. Ingen agenter, ingen ændringer i jeres pipeline, cirka én arbejdsdag af jeres teams tid.

I hører om det lørdag. Agenterne kører hele ugen; mennesker verificerer i kontortiden. Når en agent bekræfter noget kritisk uden for kontortid, går alarmen og beviserne til jer med det samme, markeret som agentbekræftet og endnu ikke gennemgået, så I kan handle uden at vente på os. Den skriftlige vurdering og rådet om udbedring følger den næste arbejdsdag.

Vi er ikke en 24/7-ydelse og påstår ikke at være det. Vær skeptisk over for enhver på vores størrelse, der gør.

I er velkomne til at prøve. Vi siger nej, skriftligt.

Bemyndigelsen er en del af onboardingen, ikke en efterfølgende formalitet. I underskriver en standardaftale, der opregner hvad der er i scope — domæner, repositories, miljøer — og bekræfter at I har ret til at lade det teste. Intet uden for det scope røres, og at udvide det er en underskrevet ændring, ikke en supportsag. Til den gratis gennemgang verificerer vi desuden ejerskab med en DNS-post, før noget kører.

Leverandørsystemer testes under jeres kontraktlige rettigheder over for den leverandør, med leverandøren orienteret. Aldrig i stilhed.

Det er hovedsagelig derfor, folk køber det. ISO 27001-revisorer stikprøver nu enkelte ændringer (A.8.29, A.8.32) i stedet for at acceptere et politikdokument, og dokumentationen findes enten den dag, de spørger, eller den gør ikke. DORA og NIS2 skubber det samme spørgsmål ned fra jeres regulerede kunder i form af leverandørspørgeskemaer, I skal besvare.

Det, vi producerer, er dateret dokumentation per ændring og per release — hvad der ændrede sig, hvad der blev gennemgået, af hvem, hvad der kørte, hvad der blev gentestet. Det er, hvad de spørgsmål reelt beder om. Vi reviderer selv finansielle institutioner under DORA og NIS2, så dokumentationsmodellen er bygget fra den spørgende side af bordet.

Ja. Det er det, de er til. Ud af det samme materiale kommer to rapporter: en ledelsesrapport — eksponering, tendens, hvad der er over sin SLA, og hvis navn der står på det — og en teknisk rapport med fundene, trinnene til at genskabe dem og gentestresultaterne. Begge kan ses i deres helhed på platformssiden.

På de højere planer underskriver vi også en årlig erklæring, til den kunde der spørger hårdere end et spørgeskema.

Én ting I leverer, plus den flade der betjener den: dens repositories, dens domæner og subdomæner, dens miljøer. En SaaS-applikation med et marketingsite og et testmiljø er ét produkt. To applikationer, der tilfældigvis deler login, er to.

Planerne måles i produkter, fordi det er den enhed, jeres eksponering faktisk vokser i — aldrig per udvikler, per enhed eller per fund vi rejser.