Problem Validation: UEBA for Activities in GitLab
What's this issue all about? (Background and context)
Self-managed GitLab customers lack actionable insights and controls to identify and prevent potentially unwanted user actions within their instance. More specifically, because of the critical nature of the work product GitLab contains (source code, infrastructure configs), customers want to be alerted to any potentially damaging behavior, be that from an insider threat or via a compromised employee account.
What are the overarching goals for the research?
- Identify primary and secondary areas of interest for monitoring (e.g. repo activity, runner activity)
- Determine desired areas for monitoring and managing behavior events (e.g. inside GitLab or external tool—and if external, which ones).
What hypotheses and/or assumptions do you have?
- Interest in or plans to use UEBA will be higher than actual adoption.
- Most interest will be around repo misuse (mass cloning) and resource (runner) utilization.
- The larger the organization, the more likely to have existing UEBA capabilities.
What research questions are you trying to answer?
- What are the top two or three activities users are most interested in monitoring?
- Where will users want to monitor and manage UEBA events?
- Does our existing Security Operations Engineer persona (Alex) cover our UEBA use cases? (If not, potentially update based on findings.)
- How complex is users’ current setup and configuration, and how automated / flexible / manual is the management?
- How do users deal with an anomalous event?
What persona, persona segment, or customer type experiences the problem most acutely?
- Security engineer who triages and responds to security alerts and events.
- Preferably a GitLab customer.
- Must be interested in (or already have tools in place for) UEBA.
What business decisions will be made based on this information?
Based on determined interest, UEBA for activities in GitLab will either proceed to Solution Validation to make it Minimal or the need for the category will be re-evaluated.
What, if any, relevant prior research already exists?
None
What timescales do you have in mind for the research?
Ideally research can be completed by end of %12.10.
Who will be leading the research?
@tlavi and @matt_wilson
Relevant links (opportunity canvas, discussion guide, notes, etc.)
TODO Checklist
-
PM: complete the research brief. -
UXR: review research brief and provide feedback. -
PM: draft a discussion guide. -
UXR: review discussion guide and provide feedback. -
UXR: draft a screener (this is done simultaneously with the PM drafting a discussion guide). -
PM: review the screener. -
UXR: open a recruiting request, and assist with scheduling participants. -
PM: moderate interviews. -
UXR: update the recruiting request, to ask the Research Coordinator to reimburse participants. -
PM + UXR: synthesize the data collaboratively. -
UXR: document the findings in the UXR_Insights project. -
UXR: link the epic containing all research insights to this issue, and, if applicable, unmarks this issue as confidential before closing it. -
PM (optional): hold a debrief session with PD and other interested stakeholders.
Edited by Tali Lavi