Mirror of https://github.com/roostorg/osprey
github.com/roostorg/osprey
User Personas (#43)
Adding anonymized and aggregated user personas from the research done for Osprey
authored by
Andrew Chang
and committed by
GitHub
a08942ce
d999ccb3
+70
docs/images/user_persona_engineer.png
docs/images/user_persona_engineer.png
This is a binary file and will not be displayed.
docs/images/user_persona_operations.png
docs/images/user_persona_operations.png
This is a binary file and will not be displayed.
+70
docs/user_personas.md
+70
docs/user_personas.md
···
1
+
# User Research Overview
2
+
3
+
Osprey is designed for users who need to investigate and take automated action on events in real-time. By interviewing prospective Osprey users, ROOST has drafted the following user personas for developers to better understand who might be interested in using this tool. We hope this research helps the open source community prioritize features to build moving forward!
4
+
5
+
## T&S Engineers
6
+
7
+
Most engineers who are interested in potentially using Osprey are like Alice – they do not currently have a viable rules engine due to cost, lack of flexibility, or limited available options. However, they need a tool for real-time event processing to handle adverse events at scale. They also want to optimize how Osprey works with the rest of their tech stack.
8
+
9
+
10
+
11
+
*Jobs to be done include:*
12
+
13
+
- When I manage rules, I want a flexible and intuitive developer experience (including intuitive logic and easy to learn programming syntax) so that I can make changes quickly and without being reliant on third party tools
14
+
15
+
- When I assess new tools, I clear info on ease of deployment and integration with common tools (e.g., Splunk), so that I know if the tool will work within our stack
16
+
17
+
- When I deploy changes, I want to ensure they will be as effective as possible, to avoid future duplication of work
18
+
19
+
*Pain points prior to Osprey include:*
20
+
21
+
- Bad dev experience in existing rules engines, given lack of flexibility and poor UI
22
+
23
+
- Cost / risk of new integrations
24
+
25
+
- Limited flexibility in adapting rules (e.g., online to offline toggle) or initiating non T&S workflows
26
+
27
+
- Immediate enforcement of preset rules enables bad actors to iterate approaches until successful
28
+
29
+
*Desired capabilities from Osprey include:*
30
+
31
+
- Core documentation, functionality, and QOL features for easy deployment and interoperability
32
+
33
+
- Event schema management system flexibility so code is SSOT and can be easily adjusted
34
+
35
+
- Offer UI- and code- driven approaches to making changes
36
+
37
+
- Native randomized action timing for enforcement
38
+
39
+
40
+
## T&S Operations Teams
41
+
42
+
T&S analysts like Bob are primarily concerned with their ability to (1) intuitively analyze data trends of adverse behavior and (2) quickly iterate on rules to take enforcement actions against such behavior.
43
+
44
+
45
+
46
+
*Jobs to be done include:*
47
+
48
+
- I want to quickly search for, review, and explore potential trends of bad behavior so I can proactively identify threat patterns and build rules accordingly
49
+
50
+
- I want to easily build, iterate, and deploy rules, so I can respond to threats without overreliance on Engineering and without losing nuances of my analysis
51
+
52
+
- When navigating Osprey, I want to easily understand the current platform landscape, including which rules have been applied and which accounts are connected, so I can better understand what types of actions to take
53
+
54
+
*Pain points prior to Osprey include:*
55
+
56
+
- Limited open-ended exploration, reducing insight quality / efficiency
57
+
58
+
- Difficult / slow to make changes (e.g., edit rules) w/o Eng. support
59
+
60
+
- Messy interface for reviewing events (e.g., limited filtering, static elements, visibility into rule firing)
61
+
62
+
- Poor integration with review tools (e.g., build filtered review queues)
63
+
64
+
*Desired capabilities from Osprey include:*
65
+
66
+
- Facilitate creative investigations by enabling users to easily query on multiple element types (e.g., event, account age, user history)
67
+
68
+
- Empower non-technical users to make quick changes (e.g., add or edit rules, events, etc.)
69
+
70
+
- Build intuitive, centralized UI to enable clear labeling and data manipulation (e.g., view all rules)