Säkerhet hos TrustSek

Så beter sig våra kontroller

TrustSeks kontroller är icke-intrusiva. En kontroll bedömer en domän utifrån, och det mesta den använder är redan offentligt. När den väl har kontakt med domänens egna servrar gör den det som en webbläsare eller en e-postserver skulle göra, och inget mer.

DNS

MX SPF DMARC DKIM MTA-STS TLS-RPT CAA NS DNSSEC

TLS

:443 · ett handslag

HTTPS

GET / · ett anrop

HTTP

GET / :80 · ett anrop

MTA-STS

policyfil, om den finns

UA

TrustSek/1.0

Ingen portskanning · inga exploits · ingen genomsökning · inga inloggningar

Det här skickar vi till domänen som kontrolleras

• DNS-uppslag. Vi läser domänens öppna DNS-poster: e-post (MX), SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, namnservrar och DNSSEC. För DKIM slår vi upp en lista med vanliga selektornamn. Subdomäner som finns i Certificate Transparency-loggar slås upp i DNS för att se vilka som är aktiva.
• En TLS-anslutning till port 443, för att läsa certifikatet, protokollversionen och det chiffer som servern väljer.
• Två webbanrop till startsidan: ett över HTTPS och ett över HTTP på port 80, för att se om okrypterad HTTP skickas vidare till HTTPS. Vi läser svarets headers och sidans HTML för att se vilka programversioner som visas utåt.
• Er MTA-STS-policy, om er DNS anger att ni publicerar en.

Webbanropen identifierar sig med user agent TrustSek/1.0. Anrop till samma mål sprids ut över tid i stället för att skickas i en klump, och varje anrop har en kort tidsgräns.

Det här gör vi inte

• Vi skannar inte portar. Öppna portar och exponerade tjänster kommer från en leverantör av internetskanningsdata som redan har observerat dem, inte från oss.
• Vi skickar inga exploits, fuzzar inga indata, provar inga lösenord och gör inga aktiva sårbarhetstester. Fynden om sårbarheter är matchningar mellan programversioner som visas utåt och publicerade säkerhetsmeddelanden.
• Vi går inte igenom webbplatsen, följer inga länkar, skickar inga formulär och loggar inte in.
• Vi ansluter inte till lookalike-domäner. Vi kontrollerar i DNS om de är registrerade och frågar sedan threat intelligence-källor om de som är det.

Metoden listar varje källa och vad var och en läser.

Om ni har sett våra anrop

Har anrop från TrustSek/1.0 dykt upp i era loggar, har någon kört en kontroll av er domän, till exempel ni själva, en kund, en leverantör eller en partner. Anropen ovan är allt som skickades. Kontakta oss om ni har frågor.

Så hanterar vi data

• Externa källor. För att kontrollera en domän skickar vi domännamnet, och för vissa källor även dess IP-adresser, till de källor som listas i metoden, till exempel Certificate Transparency-loggar och threat intelligence-tjänster.
• Kontrollerade domäner. Appen sparar de domäner som kontrolleras och resultaten av kontrollerna. Räkna inte med att en kontroll är privat.
• API-nycklar sparas bara som en envägshash. Hela nyckeln visas en gång, när den skapas, och en återkallad nyckel slutar fungera vid nästa anrop.

Rapportera en sårbarhet

Tror ni att ni har hittat en säkerhetsbrist i TrustSek? Berätta det för oss. Vi hör hellre om den från er än från någon annan.

Mejla er rapport till security@trustsek.com. Ni kan skriva på svenska eller engelska. Vi bekräftar varje rapport inom 3 arbetsdagar.

Det här omfattas

• Den här webbplatsen.
• TrustSek-appen på app. under vår domän.
• TrustSeks API på api. under vår domän.

Det här omfattas inte

• Fynd som TrustSek rapporterar om andras domäner. Tror ni att en poäng eller ett fynd är fel? Kontakta oss i stället.
• Tjänster som drivs av tredje parter som vi använder, till exempel vår hostingleverantör eller de datakällor vi frågar. Rapportera sådant till leverantören.
• Rapporter från automatiska skannrar utan belägg för någon faktisk påverkan.
• Saknade headers eller poster enligt bästa praxis utan påvisad säkerhetspåverkan.
• Överbelastningsattacker, spam och social engineering.

Det här vill vi att ni tar med

• Vad ni har hittat och var: URL, endpoint eller komponent.
• Hur man återskapar felet, och vad en angripare skulle kunna uppnå.
• Eventuell proof-of-concept, så begränsad som möjligt.
• Hur vi når er, och om ni vill bli omnämnda.

Det här ber vi er att inte göra

• Kom inte åt, ändra inte och radera inte data som inte tillhör er. Använd testkonton som ni själva har skapat. Kommer ni av misstag åt en annan kunds data: avbryt, spara ingenting och meddela oss.
• Kör inga överbelastningstester, ingen automatisk skanning i stor volym och inget annat som försämrar tjänsten för andra.
• Använd inte social engineering, phishing eller fysiska angrepp mot vår personal eller våra lokaler.
• Publicera eller dela inte problemet förrän vi har åtgärdat det, eller har kommit överens med er om ett datum.

Det här lovar vi i gengäld

Om ni agerar i god tro och följer den här policyn:

• Bekräftar vi er rapport inom 3 arbetsdagar och håller er informerade medan vi arbetar med den.
• Vi vidtar inga rättsliga åtgärder mot er, och ber inte heller någon annan att göra det, för undersökningar som håller sig inom den här policyn.
• Nämner vi er när åtgärden publiceras, om ni vill det.

Vi har inget bug bounty-program och betalar inte för rapporter.

security.txt

Vi publicerar vår säkerhetskontakt i en maskinläsbar fil på /.well-known/security.txt, enligt RFC 9116. Där finns adressen för rapporter, föredragna språk (svenska och engelska), en länk till den här sidan och ett utgångsdatum, som vi förnyar varje år.

Den här webbplatsen

Ett säkerhetsföretags egen webbplats ska klara de kontroller som företaget gör på andra. Den här webbplatsen levereras bara över HTTPS, med HSTS och en strikt policy för tillåtet innehåll (Content Security Policy).