metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Vetticaden (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (METRON-195) Next Generation Metron UI
Date Wed, 01 Jun 2016 17:36:59 GMT

     [ https://issues.apache.org/jira/browse/METRON-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

George Vetticaden updated METRON-195:
-------------------------------------
    Description: 
!Metron Next Gen UI.png|width=800, height=400!

Over the last few weeks, we have had the chance to interview over 20 different SOC/Security
personnel from various organizations. These folks represented the following personas:
* Tier 1, 2 and 3 SOC Analyst
* SOC Manager
* Security Platform Architects
* SIEM Engineers
* Data Scientists

The interviews ranged from 10 minute to 2 hour conversations and some of the interview questions
can be found on the following wiki page: https://cwiki.apache.org/confluence/display/METRON/SOC+Interview+Discussion+Guide


In addition to these questions, we had the opportunity to watch them use their current security
tooling and also watch them use the current Metron based Kibana UI (for folks that had Metron
deployed)

The user interviews are documented here:
https://cwiki.apache.org/confluence/display/METRON/User+Interviews
This provides us a valuable trove of requirements and insights about the challenges faced
by SOC personnel.

While the current Metron UI based on Kibana 3/4 has some advantages including the ability
to connect to different elastic indexes, dashboard and panel support, and rich support for
different panel types,  it was clear  the current Metron UI lacks some key capabilities that
most SOC personnel would require. Some key limitations identified based on these interviews
included:
* Clunky unintuitive user interface. Someone has to to teach how to use Metron UI couple of
times for a user to understand even how to start with it.
* All things around searching was very difficult to understand. This included things like
** Difference between search and filtering
** How to create a pinned/named query
** How to associate pinned queries to panels
** Search DSL was difficult to use
* No Authentication or RBAC support
* Alert Triaging not supported

In addition to these challenges, the following were key requirements that the SOC personnel
deemed critical for Metron to have:
* Support for Alert Triaging. The ability for the user to group/search alerts and their related
telemetries and create a case/ticket from it.
* Case Workflow Management
* Alert Queues that SOC analysts can pick up alerts to work on
* Authentication & Authorization/RBAC Support
* Make Search easier for a novice easier
* Faceting Support
* More robust pivoting functionality. 
* Help the advanced user write more complicated queries/searches
* More advanced visualization support including link analysis / Knowledge Graphs
* Curated/Filtered views of Alerts for SOC 1 Analysts
* KPIs  that provides accountability (e/g: average time spent on case, top 10 critical alerts,
SLA violations..)
* Better/ more intelligent grouping of alerts into a "Meta-Alert"
* Drill down of Meta-Alert into the set of alerts the meta consists of. Drilling down on a
raw alert to the the telemetry data sources
* Management UI Tooling around provisioning, monitoring and managing Metron.

Based on this data, some key design principles started to emerge that the Metron UI should
adhere to:
# A Single Pane of Glass - One interface to monitor and act Telemetry feeds, Behavior anomalies,
Alerts and Meta-Alerts, Metron system health, Investigate, slice and dice, hunt and seek,
search & filter, Collaborate and share info and Identify and collect data
# Find Needles in the Haystack - Find that tiny detail that helps you create a better defense.
Meta-Alerts are doorways to the data details  Meta-Alerts can contain hundreds of smaller
related alerts. Search and Facet to dive deeper
# Same Data, Many Angles -  One data set can be visualized in many ways. Not only do we need
to show many views of a data set out of the box. We must also allow for customization.
# It’s All Collaborative - I can share anything I see. I can preserve it for later. I can
save it for myself or send to someone else. Once a collaboration begins, we can annotate and
categorize data for future use and investigation. Oversight. All activity is audited. So what
I do and the amount of time I spend doing it can be backtracked and replayed somehow.
# It Evolves - Off the shelve, the system will be powerful. However, it can grow and evolve
with threat intelligence feeds, Behavior Modeling, App store style add-ons, and Learning Models.
Learning Models use machine learning to predict anomalous behavior. It takes a pattern and
alerts when similar patterns emerge. Behavior Modeling observers the average entity behavior
and creates an expected range of behavior.  The system learns from what happens as well as
what you feed it.
# A Tailored Fit - The system is personalized and customizable. Based on role, a user may
get a specific interface. Based on experience, a user can modify interfaces to suit there
personal preferences.
# I’m Never Lost - No matter how deep a user dives into the data, they always know where
they are. I can move back through my diving to a previous result. The complexity of these
systems can be immense. We need to design for interruption and the resuming of their place
by providing some way-finding tools to guide users.
# It Teaches You - The system teaches novice users to become advanced users. As you use the
system if gives you all the hints you need to become an expert. Complex things are made easy
enough for anyone to be able to do.
# Think for Them - The system anticipates user needs and does the thinking for them. We put
the burden of complexity on the software so that we simplify the user experience. Make the
experience as human as possible, guide and help users achieve outcomes. Shorten the number
clicks by decreasing complexity.

Hence, based on these challenges and requirements discovered from these interviews, this is
a proposal to build a set of next generation user interfaces for Apache Metron that caters
to the different SOC personas that will use Metron. Fore more details on SOC personnas see
here: https://cwiki.apache.org/confluence/display/METRON/Metron+User+Personas+And+Benefits


As the below above illustrates, the proposal is to move away from Kibana and introduce a number
of different views/UIs that caters to different types of SOC users across three Phases:
* Phase 1 - This phase focuses on SOC analysts and  Managers. They includes  the following
different Views/UIs:
** Metron Investigator UI - Ability for SOC analyst to do alert triaging, threat  hunting
and searching. It should also provide the ability to export a view based on the filters and
seed a new Metron Case with that context.  
** Case Management Workflow - The ability to manage Metron cases. This entails supporting
different workflow statuses (new, pending, in-progress, escalate, etc..) It also should provide
Metron case queue management functionality. 
KPI and Situational Awareness Dashboards - Set of Dashboards that provides situational awareness
of the environment as well key performance indicators for managers. 
* Phase 2 - The primary focus is on the Platform Engineers / Dev Ops that will manage the
Metron application. This involves interfaces to manage topologies, enrichments, threat intel
data sources, configuration, ec..
* Phase 3 - This phase is all about the data scientist and providing an integrated analytical
environment that uses powerful tools such as Zeppelin, Jupiter, Python etc..
     

This initial high level proposal will need to be fleshed out as the community provides their
feedback.  


  was:
!Metron Next Gen UI.png|vspace=4!

Over the last few weeks, we have had the chance to interview over 20 different SOC/Security
personnel from various organizations. These folks represented the following personas:
* Tier 1, 2 and 3 SOC Analyst
* SOC Manager
* Security Platform Architects
* SIEM Engineers
* Data Scientists

The interviews ranged from 10 minute to 2 hour conversations and some of the interview questions
can be found on the following wiki page: https://cwiki.apache.org/confluence/display/METRON/SOC+Interview+Discussion+Guide


In addition to these questions, we had the opportunity to watch them use their current security
tooling and also watch them use the current Metron based Kibana UI (for folks that had Metron
deployed)

The user interviews are documented here:
https://cwiki.apache.org/confluence/display/METRON/User+Interviews
This provides us a valuable trove of requirements and insights about the challenges faced
by SOC personnel.

While the current Metron UI based on Kibana 3/4 has some advantages including the ability
to connect to different elastic indexes, dashboard and panel support, and rich support for
different panel types,  it was clear  the current Metron UI lacks some key capabilities that
most SOC personnel would require. Some key limitations identified based on these interviews
included:
* Clunky unintuitive user interface. Someone has to to teach how to use Metron UI couple of
times for a user to understand even how to start with it.
* All things around searching was very difficult to understand. This included things like
** Difference between search and filtering
** How to create a pinned/named query
** How to associate pinned queries to panels
** Search DSL was difficult to use
* No Authentication or RBAC support
* Alert Triaging not supported

In addition to these challenges, the following were key requirements that the SOC personnel
deemed critical for Metron to have:
* Support for Alert Triaging. The ability for the user to group/search alerts and their related
telemetries and create a case/ticket from it.
* Case Workflow Management
* Alert Queues that SOC analysts can pick up alerts to work on
* Authentication & Authorization/RBAC Support
* Make Search easier for a novice easier
* Faceting Support
* More robust pivoting functionality. 
* Help the advanced user write more complicated queries/searches
* More advanced visualization support including link analysis / Knowledge Graphs
* Curated/Filtered views of Alerts for SOC 1 Analysts
* KPIs  that provides accountability (e/g: average time spent on case, top 10 critical alerts,
SLA violations..)
* Better/ more intelligent grouping of alerts into a "Meta-Alert"
* Drill down of Meta-Alert into the set of alerts the meta consists of. Drilling down on a
raw alert to the the telemetry data sources
* Management UI Tooling around provisioning, monitoring and managing Metron.

Based on this data, some key design principles started to emerge that the Metron UI should
adhere to:
# A Single Pane of Glass - One interface to monitor and act Telemetry feeds, Behavior anomalies,
Alerts and Meta-Alerts, Metron system health, Investigate, slice and dice, hunt and seek,
search & filter, Collaborate and share info and Identify and collect data
# Find Needles in the Haystack - Find that tiny detail that helps you create a better defense.
Meta-Alerts are doorways to the data details  Meta-Alerts can contain hundreds of smaller
related alerts. Search and Facet to dive deeper
# Same Data, Many Angles -  One data set can be visualized in many ways. Not only do we need
to show many views of a data set out of the box. We must also allow for customization.
# It’s All Collaborative - I can share anything I see. I can preserve it for later. I can
save it for myself or send to someone else. Once a collaboration begins, we can annotate and
categorize data for future use and investigation. Oversight. All activity is audited. So what
I do and the amount of time I spend doing it can be backtracked and replayed somehow.
# It Evolves - Off the shelve, the system will be powerful. However, it can grow and evolve
with threat intelligence feeds, Behavior Modeling, App store style add-ons, and Learning Models.
Learning Models use machine learning to predict anomalous behavior. It takes a pattern and
alerts when similar patterns emerge. Behavior Modeling observers the average entity behavior
and creates an expected range of behavior.  The system learns from what happens as well as
what you feed it.
# A Tailored Fit - The system is personalized and customizable. Based on role, a user may
get a specific interface. Based on experience, a user can modify interfaces to suit there
personal preferences.
# I’m Never Lost - No matter how deep a user dives into the data, they always know where
they are. I can move back through my diving to a previous result. The complexity of these
systems can be immense. We need to design for interruption and the resuming of their place
by providing some way-finding tools to guide users.
# It Teaches You - The system teaches novice users to become advanced users. As you use the
system if gives you all the hints you need to become an expert. Complex things are made easy
enough for anyone to be able to do.
# Think for Them - The system anticipates user needs and does the thinking for them. We put
the burden of complexity on the software so that we simplify the user experience. Make the
experience as human as possible, guide and help users achieve outcomes. Shorten the number
clicks by decreasing complexity.

Hence, based on these challenges and requirements discovered from these interviews, this is
a proposal to build a set of next generation user interfaces for Apache Metron that caters
to the different SOC personas that will use Metron. Fore more details on SOC personnas see
here: https://cwiki.apache.org/confluence/display/METRON/Metron+User+Personas+And+Benefits


As the below diagram illustrates, the proposal is to move away from Kibana and introduce a
number of different views/UIs that caters to different types of SOC users across three Phases:
* Phase 1 - This phase focuses on SOC analysts and  Managers. They includes  the following
different Views/UIs:
** Metron Investigator UI - Ability for SOC analyst to do alert triaging, threat  hunting
and searching. It should also provide the ability to export a view based on the filters and
seed a new Metron Case with that context.  
** Case Management Workflow - The ability to manage Metron cases. This entails supporting
different workflow statuses (new, pending, in-progress, escalate, etc..) It also should provide
Metron case queue management functionality. 
KPI and Situational Awareness Dashboards - Set of Dashboards that provides situational awareness
of the environment as well key performance indicators for managers. 
* Phase 2 - The primary focus is on the Platform Engineers / Dev Ops that will manage the
Metron application. This involves interfaces to manage topologies, enrichments, threat intel
data sources, configuration, ec..
* Phase 3 - This phase is all about the data scientist and providing an integrated analytical
environment that uses powerful tools such as Zeppelin, Jupiter, Python etc..
     

 

This initial high level proposal will need to be fleshed out as the community provides their
feedback.  



> Next Generation Metron UI
> -------------------------
>
>                 Key: METRON-195
>                 URL: https://issues.apache.org/jira/browse/METRON-195
>             Project: Metron
>          Issue Type: Wish
>            Reporter: George Vetticaden
>         Attachments: Metron Next Gen UI.png
>
>
> !Metron Next Gen UI.png|width=800, height=400!
> Over the last few weeks, we have had the chance to interview over 20 different SOC/Security
personnel from various organizations. These folks represented the following personas:
> * Tier 1, 2 and 3 SOC Analyst
> * SOC Manager
> * Security Platform Architects
> * SIEM Engineers
> * Data Scientists
> The interviews ranged from 10 minute to 2 hour conversations and some of the interview
questions can be found on the following wiki page: https://cwiki.apache.org/confluence/display/METRON/SOC+Interview+Discussion+Guide
> In addition to these questions, we had the opportunity to watch them use their current
security tooling and also watch them use the current Metron based Kibana UI (for folks that
had Metron deployed)
> The user interviews are documented here:
> https://cwiki.apache.org/confluence/display/METRON/User+Interviews
> This provides us a valuable trove of requirements and insights about the challenges faced
by SOC personnel.
> While the current Metron UI based on Kibana 3/4 has some advantages including the ability
to connect to different elastic indexes, dashboard and panel support, and rich support for
different panel types,  it was clear  the current Metron UI lacks some key capabilities that
most SOC personnel would require. Some key limitations identified based on these interviews
included:
> * Clunky unintuitive user interface. Someone has to to teach how to use Metron UI couple
of times for a user to understand even how to start with it.
> * All things around searching was very difficult to understand. This included things
like
> ** Difference between search and filtering
> ** How to create a pinned/named query
> ** How to associate pinned queries to panels
> ** Search DSL was difficult to use
> * No Authentication or RBAC support
> * Alert Triaging not supported
> In addition to these challenges, the following were key requirements that the SOC personnel
deemed critical for Metron to have:
> * Support for Alert Triaging. The ability for the user to group/search alerts and their
related telemetries and create a case/ticket from it.
> * Case Workflow Management
> * Alert Queues that SOC analysts can pick up alerts to work on
> * Authentication & Authorization/RBAC Support
> * Make Search easier for a novice easier
> * Faceting Support
> * More robust pivoting functionality. 
> * Help the advanced user write more complicated queries/searches
> * More advanced visualization support including link analysis / Knowledge Graphs
> * Curated/Filtered views of Alerts for SOC 1 Analysts
> * KPIs  that provides accountability (e/g: average time spent on case, top 10 critical
alerts, SLA violations..)
> * Better/ more intelligent grouping of alerts into a "Meta-Alert"
> * Drill down of Meta-Alert into the set of alerts the meta consists of. Drilling down
on a raw alert to the the telemetry data sources
> * Management UI Tooling around provisioning, monitoring and managing Metron.
> Based on this data, some key design principles started to emerge that the Metron UI should
adhere to:
> # A Single Pane of Glass - One interface to monitor and act Telemetry feeds, Behavior
anomalies, Alerts and Meta-Alerts, Metron system health, Investigate, slice and dice, hunt
and seek, search & filter, Collaborate and share info and Identify and collect data
> # Find Needles in the Haystack - Find that tiny detail that helps you create a better
defense. Meta-Alerts are doorways to the data details  Meta-Alerts can contain hundreds of
smaller related alerts. Search and Facet to dive deeper
> # Same Data, Many Angles -  One data set can be visualized in many ways. Not only do
we need to show many views of a data set out of the box. We must also allow for customization.
> # It’s All Collaborative - I can share anything I see. I can preserve it for later.
I can save it for myself or send to someone else. Once a collaboration begins, we can annotate
and categorize data for future use and investigation. Oversight. All activity is audited.
So what I do and the amount of time I spend doing it can be backtracked and replayed somehow.
> # It Evolves - Off the shelve, the system will be powerful. However, it can grow and
evolve with threat intelligence feeds, Behavior Modeling, App store style add-ons, and Learning
Models. Learning Models use machine learning to predict anomalous behavior. It takes a pattern
and alerts when similar patterns emerge. Behavior Modeling observers the average entity behavior
and creates an expected range of behavior.  The system learns from what happens as well as
what you feed it.
> # A Tailored Fit - The system is personalized and customizable. Based on role, a user
may get a specific interface. Based on experience, a user can modify interfaces to suit there
personal preferences.
> # I’m Never Lost - No matter how deep a user dives into the data, they always know
where they are. I can move back through my diving to a previous result. The complexity of
these systems can be immense. We need to design for interruption and the resuming of their
place by providing some way-finding tools to guide users.
> # It Teaches You - The system teaches novice users to become advanced users. As you use
the system if gives you all the hints you need to become an expert. Complex things are made
easy enough for anyone to be able to do.
> # Think for Them - The system anticipates user needs and does the thinking for them.
We put the burden of complexity on the software so that we simplify the user experience. Make
the experience as human as possible, guide and help users achieve outcomes. Shorten the number
clicks by decreasing complexity.
> Hence, based on these challenges and requirements discovered from these interviews, this
is a proposal to build a set of next generation user interfaces for Apache Metron that caters
to the different SOC personas that will use Metron. Fore more details on SOC personnas see
here: https://cwiki.apache.org/confluence/display/METRON/Metron+User+Personas+And+Benefits
> As the below above illustrates, the proposal is to move away from Kibana and introduce
a number of different views/UIs that caters to different types of SOC users across three Phases:
> * Phase 1 - This phase focuses on SOC analysts and  Managers. They includes  the following
different Views/UIs:
> ** Metron Investigator UI - Ability for SOC analyst to do alert triaging, threat  hunting
and searching. It should also provide the ability to export a view based on the filters and
seed a new Metron Case with that context.  
> ** Case Management Workflow - The ability to manage Metron cases. This entails supporting
different workflow statuses (new, pending, in-progress, escalate, etc..) It also should provide
Metron case queue management functionality. 
> KPI and Situational Awareness Dashboards - Set of Dashboards that provides situational
awareness of the environment as well key performance indicators for managers. 
> * Phase 2 - The primary focus is on the Platform Engineers / Dev Ops that will manage
the Metron application. This involves interfaces to manage topologies, enrichments, threat
intel data sources, configuration, ec..
> * Phase 3 - This phase is all about the data scientist and providing an integrated analytical
environment that uses powerful tools such as Zeppelin, Jupiter, Python etc..
>      
> This initial high level proposal will need to be fleshed out as the community provides
their feedback.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message