Fokussierung auf die richtige Persona

November 10, 2022

Von Jim Beno - Direktor für Benutzererfahrung, Skyhigh Security

Als Sicherheitsunternehmen arbeiten die Benutzer unseres Produkts in der Regel in der Organisation für Informationssicherheit (InfoSec). Aber wir stellen immer mehr fest, dass unsere Security Service Edge (SSE) Funktionen auf Benutzer außerhalb des Sicherheitsteams abzielen: meist in der Informationstechnologie (IT), aber auch im Bereich Engineering / Operations. Dies sind die Personen, die Anwendungen in der Cloud entwickeln und bereitstellen, den Zugriff darauf kontrollieren und die Leistung des Netzwerks sicherstellen.

Es gibt mindestens vier wichtige SSE-Workflows oder Funktionen, die auf Rollen außerhalb der Sicherheitsorganisation abzielen:

• Zugriff auf Anwendungen gewähren - Da Unternehmen immer mehr ihrer Infrastruktur in die öffentliche Cloud verlagern, müssen sie den Zugriff auf die dort gehosteten Anwendungen kontrollieren. Unsere Lösung Zero Trust Network Access (ZTNA) bietet diese Möglichkeit. Die Verwaltung dieser Zugriffsrichtlinien und die Beantwortung von Zugriffsanfragen von Mitarbeitern ist nicht die Aufgabe des Security Operations Center (SOC). Diese Aufgabe obliegt der IT-Abteilung und dem IT-Helpdesk.
• Verwaltung von Firewall-Richtlinien - Bei all dieser Infrastruktur in der öffentlichen Cloud müssen Unternehmen aus Sicherheitsgründen den Zugriff nicht nur kontrollieren, indem sie festlegen, "wer" diese Anwendungen nutzen kann, sondern auch das "wie" - die Details zu den Protokollen, Ports, Geräten, Standorten usw.
• Digital Experience Monitoring - Mit Bürostandorten auf der ganzen Welt und vielen Mitarbeitern, die von zu Hause aus arbeiten, ist es unvermeidlich, dass einige Mitarbeiter Probleme beim Zugriff auf eine Anwendung oder einen Dienst haben. Die Identifizierung des Umfangs und der Ursache dieser Probleme kann ein Alptraum sein. Wenn der IT-Helpdesk anruft, wird das Sicherheitsteam nicht zum Hörer greifen.
• Behebung von Fehlkonfigurationen und Schwachstellen - Innerhalb der IT und der Technik erstellen verschiedene Teams möglicherweise Anwendungen auf Amazon Web Services (AWS), Google Cloud Platform (GCP) oder Microsoft Azure. Unsere Aufgabe ist es, Unternehmen dabei zu helfen, diese Anwendungen zu sichern, ganz gleich, ob es sich um den IT-Architekten handelt, der für die Cloud-Infrastruktur verantwortlich ist, um die Account-Inhaber, die die Anwendungen entwickeln und konfigurieren, oder um die DevOps/DevSecOps-Mitarbeiter, die sie bereitstellen. Wenn wir eine Schwachstelle oder eine Fehlkonfiguration entdecken, hat das Sicherheitsteam nicht "den Schlüssel zum Schloss", um sie zu beheben - wir müssen das Problem dem IT- oder Technikverantwortlichen vorlegen, der die Änderung vornehmen kann.

Personas erstellen

Bei Skyhigh Security haben wir spezielle Nutzerforscher, deren Aufgabe es ist, Kunden zu verstehen und Erkenntnisse zu gewinnen, die in die Produktanforderungen und das Design einfließen. Bei jeder neuen Produktfunktion müssen wir sicherstellen, dass wir die richtigen Benutzer ansprechen und alles über sie erfahren, was wir können: Was motiviert sie? Welche Aufgaben führen sie aus? Welche Anwendungen oder Systeme verwenden sie? Wie arbeiten sie mit anderen zusammen? Was sind ihre größten Probleme?

Wir beginnen damit, diese Fragen an interne Teammitglieder im Produktmanagement und im Vertrieb zu stellen. Oft halten wir eine Arbeitssitzung ab und halten unser kollektives Wissen auf einem virtuellen Whiteboard fest. Sobald wir wissen, welche Rollen wir ansprechen wollen, befragen wir Kunden und beobachten, wie sie arbeiten. Nach einigen dieser Sitzungen werden sich einige gemeinsame Themen herauskristallisieren. Wir fassen dann alle Erkenntnisse zusammen, indem wir eine fiktive Figur - eine "Persona" - erstellen, die zum Mittelpunkt für das Schreiben von Anwendungsfällen und das Design wird.

Fred und Kawika stellen sich vor

In letzter Zeit haben unsere Forscher zwei neue Personas untersucht, die für die Überwachung von digitalen Erfahrungen und Firewall-Richtlinien zuständig sind: "Fred", der im IT-Helpdesk arbeitet, und "Kawika", der Netzwerkadministrator. Hier sind einige der Erkenntnisse, die wir von diesem dynamischen Duo gewonnen haben:

• Kawika ist für die Leistung des Netzwerks verantwortlich. Wenn alles gut läuft, ist das Leben schön. Aber wenn etwas schief geht, muss er alles stehen und liegen lassen und sofort handeln. Um dies zu vermeiden, möchte er kritische Anwendungen im Netzwerk proaktiv überwachen - er kann nicht warten, bis ein Haufen Trouble Tickets eingeht.
• Ähnlich wie beim SOC gibt es auch bei der IT verschiedene Ebenen für die Bearbeitung von Support-Problemen. Wenn ein Mitarbeiter ein Problem beim Zugriff auf eine Anwendung hat, öffnet er ein Ticket, das vom IT-Helpdesk bearbeitet wird. Das bedeutet, dass Fred der Erste ist, der das Problem untersucht. Er hat ein Handbuch, das ihn bei der Fehlersuche anleitet. Wenn es nach einem Netzwerkproblem aussieht, wird er das Problem an das Netzwerkteam weiterleiten. Jetzt ist Kawika an der Reihe.
• Die Diagnose eines Netzwerkproblems ist nicht einfach. Die Netzwerkarchitektur ist komplex. Wenn Sie auf einen Cloud-Service zugreifen, wird der Datenverkehr vom Gerät des Mitarbeiters über viele verschiedene Netzwerke geleitet. Es gibt viele Variablen, die die Leistung beeinflussen können, und die Bedingungen können sich im Laufe der Zeit ändern. Um diese Probleme zu untersuchen, muss Kawika viele Tools und Konsolen verwenden, um die benötigten Informationen zu erhalten.

Vermeiden von Mehrdeutigkeit

All diese Erkenntnisse werden auf einseitigen Datenblättern zusammengefasst, die wir für Fred, Kawika und ihre Kollegen erstellt haben. Wir halten auch Schulungen ab, um die Personas in den funktionsübergreifenden Teams vorzustellen. Wenn wir hören, dass Produktmanager und Ingenieure eine Persona namentlich erwähnen, wissen wir, dass wir unsere Arbeit gut gemacht haben!

Jeder UX-Designablauf in Figma beginnt mit einer Zeichenfläche, auf der die Zielperson und der Anwendungsfall dargestellt sind. Auf diese Weise sind alle Beteiligten auf derselben Seite und wir vermeiden zweideutige Verweise auf "den Administrator" oder "den Sicherheitsarchitekten". Wenn wir den Entwurf überprüfen und jemand die Zielperson in Frage stellt, ist das großartig! Wir begrüßen diese Diskussion. Und genau so sind Fred und Kawika entstanden.

Es gibt nichts Schlimmeres, als eine neue Funktion zu entwerfen und zu entwickeln, um dann nach der Veröffentlichung festzustellen, dass Ihre Annahmen über den Zielbenutzer falsch waren. Das könnte erhebliche Auswirkungen auf den Arbeitsablauf haben und eine komplette Überarbeitung erfordern. Es ist viel besser, im Vorfeld in eine kleine Nutzerforschung zu investieren, um Ihre Annahmen zu überprüfen und sicherzustellen, dass Sie auf dem richtigen Weg sind.