Mirror of https://github.com/roostorg/osprey
github.com/roostorg/osprey
1# User Research Overview
2
3Osprey 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
7Most 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
42T&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)