Nokia
Workbench
Enterprise UX
Cyber Securit & Automation
Shipped : V1.0, Q2 2022
The Team
Product Owner
Lead Designer
Development team of 4
Visual Designer
My Involvement
Stakeholder interviews, Identifying User Workflow, defining Information Architecture, developing Interaction Models, Concept Sketches & Prototyping, Design Documentation & Handoff.
Timelines
Phase 1
6 Months
Phase 2
Started Q3 2022
The Back Story
Cybersecurity Dome is Nokia’s award-winning security orchestration platform that offers a set of pre-built 5G use cases for network security assurance solutions built on top of Microsoft Azure’s Sentinel. Nokia’s Security Business group wanted to develop a portal for L3 Security Analysts and Chief Information Security (CISO) personnel to
Quickly recognize Network Security Stance
Identify threat source(es).
Respond with an appropriate, pre-built remediation workflow.
Keep on top of overall SLA performance
The product team wanted to work with the UX team to:
“ Explore workflows for L3 Analysts and CISOs such that they do not need to go back to Microsoft’s Sentinel UI as much as possible. “
Engagement Timelines
This was a long-term project that started in the Q3 of 2021 and managed to deliver an Internal MVP during the end of Q2, of 2022.
We continued the project post-Internal MVP, to improve the product based on some feedback from Proxy Users and SMEs within Nokia.
Phase 1
The Minimum Viable Product
We started with a few rounds of discovery sessions over the first month, involving stakeholder interviews, and SME interviews we outlined the core responsibilities of L1, L2, L3 Analysts, and CISO.
While most of these tasks can be performed on Microsoft’s Sentinel, strategic and managerial tasks like identification of Critical Incidents, Keeping up with SLA trends, take more effort to perform on Sentinel. These provided a problem statement for us to solve.
Key ambition of the product team was to develop a product that delivers “ Value beyond incident management ”
Initial Concepts
AtScale is a Technology-Lead Product company that operates in a niche market, in a fast-paced startup culture. New Feature requirements are primarily technology innovations or delivery of a improved usability of an existing feature. These are primarily envisioned by AtScale’s Chief technology Officer and Product Managers and with over a decade of subject matter expertise in the field of Big Data and Business Intelligence. Much of the Engineering team also comprises of engineers and developers who have considerable or some experience in the field of Data, Analytics, and BI tools.The CTO and Product Managers also are the primary ‘Source of Truth’ for all our domain specific Insights and Observed User Behaviour from years of experience in teh field and from their conversations with customer teams.
As a design team at AtScale, our goal is to leverage the SME’s Insights into the Product Challenges, Insights on User behaviour to translate feature requirements into delightful and task efficient user flows.
We hosted brainstorming sessions through the next two weeks with the Product team based on the goals and identified a few possible ways of achieving them.
The initial concepts revolved around delivering visibility of threats and impact on 5G Slices and Customer networks. While it was agreed that it addressed the goal of delivering value beyond incident management, the Engineering team was not ready to deliver the goal just yet. We now had to pivot and find a different approach.
Over the next few weeks, we went back to the drawing board with the Product owners to identify
“How might we deliver value beyond incident management?”
We had to understand what is more valuable to an L3 analyst and CISO manager. We took feedback on our initial concepts from Subject matter Experts who have been on the field in Cybersecurity roles as Cybersecurity analysts and managers in the past.
SME Feedback
C
L3 analyst's priority is to make sure critical network infrastructure is healthy over just trying to resolve incidents in the list.
B
L3 analyst has a higher understanding of the Network Topology, Criticality of Network Functions & Elements.
A
Incidents come to an L3 when L1 & L2 analysts could not solve the incident based on their standard repository of responses or initial research.
With the above findings, we explored a few ideas
1.
Visibility into the Network health via topology allows the L3 Analyst to dive into it based on his expert understanding of which part of the network is of higher priority.
2.
Coming up with a scoring system, that quickly determines the criticality of individual network entities and the network as a whole on a high level. This would allow the Analyst to identify areas of interest for further investigation.
3.
The system would still provide access to individual incidents but this will be a secondary focus in the context of network entities.
With the above findings, we explored a few ideas
We started exploring workflows and designs based on the above while we faced our first challenge. There were no existing models that allowed a clear representation of the entire 5G Telco Network. The network was made of three major layers. RAN, Transport, and Core. These layers were different in terms of how they behave, and also how they are logically arranged. An attempt to visualize them all in a single view will render it unusable.
To simplify this, we decided to separate the visualization of the three layers and allow the user to focus on each of them separately.
Round 1 MVP
Phase 2
Exploring relationship User Entities and Network Entities in a threat scenario
Post the Internal MVP in phase 1, we were able to go back to our proxy users to validate our findings and our hypothesis of narrowing down the L3 Analyst’s focus by separating the three Network Layers and Visualizing the threat via ‘Threat Score’ on the Network Topology Diagram.
While the SMEs agreed that this might help, they were missing visibility into the actors responsible for the threat. That is the users accessing the network or in other words ‘User Entities’
This needed us to explore ways to represent a user of the network or ‘User Entity’ within the Network Topology Diagram.
Some Initial Challenges
Just as it was difficult to represent all three layers of a 5G network in one view. Visualizing users accessing network elements in the same view would make it cluttered as one user could be accessing multiple network elements and multiple users would be accessing one network element at a time at any given point. This would add a barrage of connections across network elements and user entities.
After some brainstorming, we realized, if we could introduce network ‘Perspectives’ we might be able to visualize the network Entities and User Entities separately while allowing some visual association of each entity to the other perspective.
Closing Thoughts
At Nokia, we work with a lot of product teams who are trying to translate a promising technology into a useful product or service for telco operators across the world. Since these technologies affect large and often times critical networks across the globe, they take a while to mature before they are delivered to real customers.
While product and design teams get to work with the end users to define the product usability, this usually becomes viable after proving the idea has a viable value within the organization and then crossing a lot of bureaucratic red tape.
The design team was able to identify Subject Matter Experts within Nokia who were in similar roles and responsibilities as our end users would and were able to validate a lot of the product team’s assumptions and our design proposals. This allows us to offset some risks of designing completely in the dark.
The product is pending further testing and validating the product team’s assumptions from real users and customers.
We were able to take the product to the big stage in front of some real customers at the Mobile World Congress in 2023 allowing us a chance to get our first real-world feedback.
In the coming months, the plan is to conduct interviews with two prospective customers in North America and refine the assumptions and workflows as necessary.
iamahmedbaig
@gmail.com