Skip to main content

Vad den här integrationen bidrar med

Adaptive Security kan bidra med data om arbetsstyrka, utbildning och flerkanaliga simuleringsresultat. Granskade exempel är bland annat:
  • phishing.simulation.clicked — klickade på ett simulerat e-postmeddelande utan att rapportera det
  • phishing.simulation.credential.submitted — angav inloggningsuppgifter på en simulerad inloggningssida
  • phishing.simulation.attachment.opened — öppnade en bilaga i ett simulerat e-postmeddelande
  • phishing.simulation.reported — rapporterade ett simulerat e-postmeddelande
  • smishing.simulation.replied — svarade på ett simulerat sms
  • vishing.simulation.succeeded — följde instruktionerna från en simulerad uppringare
  • training.assigned — tilldelades säkerhetsutbildning
  • training.completed — slutförde säkerhetsutbildning
  • training.past.due — missade en tidsfrist för utbildning
Dessa exempel visar vilka typer av normaliserad aktivitet som Living Security kan använda. Se hur integrationsdata blir signaler.
Adaptive simulerar via tre kanaler, och Living Security poängsätter varje kanal separat. E-postresultat poängsätts som nätfiske, sms-resultat som smishing och telefonsamtalsresultat som vishing. En person som klickar på ett simulerat e-postmeddelande och en person som svarar på ett simulerat sms mäts inte som samma beteende, eftersom bedömningen som gjordes i respektive fall skiljer sig åt.

Vad Living Security behöver

Roll som krävs: En administratör i ert Adaptive Security-konto med åtkomst till Settings → API. Adaptive styr API-åtkomst med rollbaserade behörigheter, så token måste tillhöra en roll som kan läsa användare, nätfiske och utbildning. Åtkomst: Skrivskyddad. Living Security läser enbart från Adaptive Security och skapar, ändrar eller raderar aldrig något i ert konto.

Vad Living Security hämtar

Telefonnummer lagras inte. Adaptive returnerar arbets- och mobilnummer i användarposten. Living Security tar bort båda innan något lagras, eftersom ingen funktion i Living Security använder dem.
Adaptives egen riskpoäng registreras men används aldrig i poängsättningen. Adaptive beräknar en current_risk_score per person. Living Security sparar den så att ni kan jämföra de båda systemen sida vid sida, men Index för mänsklig risk beräknas alltid utifrån observerat beteende med Living Securitys egen publicerade modell — aldrig utifrån en annan leverantörs sammansatta poäng.

Förutsättningar

  • Ett Adaptive Security-konto med API aktiverat.
  • Administratörsåtkomst till admin.adaptivesecurity.com.
  • Användarnas e-postadresser i Adaptive som matchar de adresser som era andra anslutna system använder. Living Security använder e-postadressen för att matcha en Adaptive-användare med en person.

Del A — I Adaptive Security

Er Adaptive Security-administratör utför dessa steg.
1

Öppna API-inställningarna

  1. Logga in på admin.adaptivesecurity.com som administratör.
  2. Gå till Settings → API.
2

Generera API-token

  1. Generera en ny API-token.
  2. Ge den ett namn som ni känner igen senare — till exempel Living Security.
  3. Kontrollera att tokenens roll kan läsa användare, nätfiskekampanjer och utbildningskampanjer.
  4. Kopiera token.
Kopiera token innan ni lämnar sidan. Om ert Adaptive-konto anger ett utgångsdatum för token, notera datumet — Living Security kan inte hämta data efter att den har gått ut, och anslutningen måste då uppdateras med en ny token.

Del B — I Living Security Platform

Programansvarig utför detta steg, eller systemadministratören om delegerad konfiguration används.
Nu är ni anslutna till Adaptive Security.

Hur ofta data hämtas

Adaptives rapporterings-API erbjuder inget filter för vad som har ändrats sedan senaste hämtningen. Därför läser Living Security varje simulerings- och utbildningskampanj så länge den fortfarande genererar resultat och slutar läsa den när den har varit stängd i två veckor. Sena klick och sena rapporter fångas därmed fortfarande upp, och avslutade kampanjer läses inte om i det oändliga.
En första anslutning till ett stort Adaptive-konto kan kräva flera schemalagda körningar innan allt har lästs in. Varje körning läser så mycket den hinner och nästa fortsätter där den förra slutade, så antalen ökar under det första dygnet eller de första två dygnen i stället för att visas på en gång.

Felsökning

API-token är felaktig, har gått ut eller har återkallats. Adaptive returnerar ett tomt svar vid det här felet, så det finns ingen ytterligare information att läsa. Generera en ny token i Settings → API och anslut på nytt med den. En delvis kopierad token ger samma fel och är den vanligaste orsaken.
Token autentiserades, men dess roll kan inte läsa den begärda datan. Det hjälper inte att klistra in samma token igen. Kontrollera i Adaptive att tokenens roll har läsbehörighet för användare, nätfiske och utbildning, eller utfärda en token från en roll som har det.
Adaptive begränsade anslutningens anropsfrekvens. Living Security avbryter den körningen och återupptar från samma punkt vid nästa schemalagda körning, så ingen data går förlorad — antalen tar bara längre tid att öka. Om problemet kvarstår i flera dagar, kontakta Adaptive Securitys support och fråga om vilken anropsgräns som gäller för ert konto.
Kontrollera att de kampanjer ni förväntar er faktiskt har körts. Adaptive rapporterar registreringar endast för simuleringar som har skickats, så en kampanj med status Utkast eller Schemalagd bidrar inte med något förrän den har skickats ut. Living Security läser medvetet inte dessa, så att anropsbudgeten används för kampanjer som har verkliga resultat.
Living Security avgör kanalen för varje resultat utifrån det scenario som är kopplat till det. Om ett scenario har raderats i Adaptive efter att dess simulering kördes registreras resultaten mot e-postkanalen, eftersom kanalen inte längre kan läsas. Du undviker detta genom att behålla avvecklade scenarier i Adaptive i stället för att radera dem.