Security Strategy
Design Thinking – How to Make Complex Data, Simply Useful
Introduction
As Ordr has gained momentum over the years, the breadth and depth of our data lake have exponentially grown, with more customers adopting Ordr and extending our solution to protect more parts of their environments. More customers and more departments of each customer’s environment mean more devices, which means more data being ingested to our platform. The growth of our data lake can also be attributed to more external inputs as we increasingly take in new sources of device context data to provide deeper insights and help our customers understand risk.
The rate of data growth we have seen creates unique challenges on the visualization side. Recently we paused to think about how our solution could better organize and present vast amounts of rich analytical data in a way that is both accessible and valuable for our users. It is truly an art indeed on how to balance the desire for simplicity with the appetite for the rich context that goes with it.
As our user base expands to new roles and personas, the product must adapt to different outcomes relevant to each user. Each user’s level of expertise and area of interest may vary, and workflows must cater to these users seamlessly. A product must meet the needs of different roles without the need to fork and build a dedicated version to satisfy the diverse needs of each user. A daunting task is less often discussed but is nevertheless critical to maximizing value for users.
With full awareness of our challenge, we set off to radically improve how we present our ever-increasing data in the most impactful, simple way to our expanding universe of users.
The Approach
As part of our product design process, we decided on an iterative approach called “design thinking,” a process defined as:
A bottom-up, non-linear, team-based iterative process that seeks to understand and empathize with users deeply, challenge existing assumptions, redefine problems, and brainstorm innovative solutions to prototype and test with customers.
Design thinking gave us a framework of 5 stages that include:
Empathize > Define > Ideate > Prototype > Test
With the design thinking framework, we set up a series of workshops and enrolled a range of users from our customers and prospects representing a variety of user roles to provide us both depth and breadth of insights and feedback we needed to collect requirements.
We started the process by asking our users the simple question:
How can we design a better user experience to make the data we provide in Ordr simple to understand and valuable for you and your role?
Some of the key requirements we heard from our design partners included:
- Organize information to fit my role and help me filter out the noise so I can focus on the information I need.
- Surface insights most relevant to my role and make them clear. Insights are the road signs that help me make decisions as I look at data.
- Allow me to “shape” and organize data to fit my needs in a fast and fluid way.
- Help me maintain the context of my data so I don’t “lose my place” as I move around the application.
- Let me see different views so I can analyze data from different perspectives and uncover insights that might otherwise be missed.
- Prioritize content over color to me understand the structure of my data without unnecessary visual distractions.
The New Model Emerges
A key takeaway from the workshops was understanding that one user’s noise is often another user’s signal. It was clear that the new model needed to present data in a simple, customizable way without sacrificing the impact or richness of the data.
A query language approach is a good option, but it could not address the signal-to-noise problem without impacting other user requirements we had gathered during the workshops. For a query language approach to be successful, a user needs to know what they’re looking for and needs to become proficient in the new syntax and semantics of the language. This impacts adoption and time to value – two things we were not willing to sacrifice.
Our analytics engine is rooted in the foundational principle of surfacing a constant stream of prioritized insights in real-time vs. waiting for a user to “ask” for data using a query. In our view, the solution would come from a comprehensive understanding of the intersection between increasing data richness and a variety of UI/UX information retrieval approaches working together to achieve the desired result.
Pillars of the Model
From our learnings in the workshops, we defined the following seven pillars that guided the design of the UI/UX presentation model.
PILLAR 1: Create a clear consolidated experience for each role
Our users have distinct roles, backgrounds, traits, abilities, and dispositions. We expect this diversity will continue to expand and increase in complexity.
Scoping data coming into the UI based on a user role allows us to reduce the less relevant data (noise) and deliver a clean baseline of data (signal) for each user. With this in mind, we established a persona-based user experience, which requires filtering data from the data lake for a specific role and persona.
Persona-based filtering is easier said than done. The whole platform needs to run dynamic queries in the backend to customize itself on the fly. For example:
- An inventory and asset management workflow requires data on devices and relevant vulnerabilities.
- A security incident response workflow requires data on the latest alarms across all assets.
- A forensics workflow requires data on traffic flows and patterns.
For example, we designed a user role for Healthcare Technology Management (HTM) that switches the entire UI dashboard and shows only data relevant to their role and daily workflow needs.
The UI adapts to these wildly diverse use cases and data requirements while catering to each user’s role.
PILLAR 2: Provide each user with contextual insights
Insights offer users top-level guidance like a road sign to separate the signal from the noise. Our model uses computationally intensive methods to surface insights in real-time, tailored explicitly for each role.
Each user requires a different dashboard and depth of context for the workflow they are interested in to be presented as top-level data.
PILLAR 3: Allow each user to shape data relevant to their role
Data Shaping controls the scope of data allowing each user to either explore data or “set and forget” a view for specific workflows. Data Shaping reduces clutter by reducing the number of devices displayed, making it easier to slice and dice the data more cleanly.
For example, in our system, setting the data shaper to a specific location only shows the devices in that location and associated data. Whether the user is in a sub-section of the product or moving across the hundreds of panels, they see only data relevant to that location.
Another example is a radiology technician using the shaper to focus on radiology-related devices. The entire product today customizes itself to radiology devices across all panels and screens. That radiology technician can now work on security, traffic analytics, vulnerability management, risk management, or policy provisioning without being shown the “noise” created by other non-radiology devices.
PILLAR 4: Enable context-aware search across the entire UI
When the data set accumulates over time into several terabytes, launching a generic search that takes more processing time to respond back after several seconds does not usually present a good user experience. But tailoring the search function to each panel where the user is currently focused on reduces the data set to search and narrowing search parameters resulting in faster query time as well as better user experience.
As an example, in each table and each panel, search parameters differ as follows:
- Device detail table provides a search function on thousands of device attributes.
- The security alarm panel provides a search capability using alarm categories as parameters.
- The traffic analytics panel provides a search capability related to traffic/flow parameters.
- The application panel provides a search based on destination URL or application protocol details like port numbers.
- Search enabled in every column of a table with parameters within that column for further quick deep dive of data.
Implementing context-aware search in each panel when there are hundreds of panels is a huge undertaking. But now that it is designed in, it is well worth the effort to minimize complexity for the user.
PILLAR 5: Allow users to easily share findings and views
Once a user has reduced a view to a list of devices that need further action, that view, including the entire context, can be easily shared with others as a URL. Another user clicking that URL comes back to the same screen with a list of devices without having to search and filter for attributes. This is a perfect example of how context gets naturally amplified with the power of sharing. Our system today allows users to save the context at various places in the navigation workflow and share it with their colleagues.
PILLAR 6: Allow users to enforce policies quickly without losing context
The action framework allows users to take quick action on any device, alarm, or vulnerability without losing context in the UI. For example, today with this release, a user can identify a list of vulnerable devices and move that complete list to a quarantine VLAN with a single click. Another example is too easily clear a series of alarms associated with devices that have the same make and model with one click. Invoking an action that requires multiple steps in action sequence right within the context without losing focus is critical to get workflows accomplished quickly.
PILLAR 7: Allow users to define their own region/location for easy aggregation
Ordr gathers location information from various sources including switches, access points, and network management systems. Device location is extremely granular in Ordr and is helpful to track a device as it moves through an organization or locates a device that has gone missing. It is critical to know exactly where a device that is affected by malware/ransomware is connected in the network (switch/port or AP/SSID or VPN (Virtual Private Network) or external).
But for manageability purposes, users want to use location to view all devices in a specific region, site, or location within that site. A location means something different from user to user, so customization is critical. The need to present data based on business function was a key driver for this, and it avoids all the clutter. For example, a user responsible for the Phoenix division can use location to focus on the devices in the Phoenix location only and not have to see devices in other locations. Our ability to aggregate micro-locations into administrative regions is very well received by our customers, given the distributed nature of the various hospital chains as well as the continuous changes in organizational hierarchy due to mergers and acquisitions.
Combining the Pillars
Ordr provides users with details on over a thousand attributes for each device. Attributes include details such as device OS, software stack, vulnerabilities, where the device connects from, connection methods, what the device communicates with internally and externally, risks based on behavior, context information from various tools, and users who have logged into the device.
Ordr is indeed a complex and dynamic system with vast amounts of data and potentially limitless insights. Using all seven pillars in combination, we believe our approach dramatically improves the signal for each user and does so in the context of their specific workflows to ensure they can use our platform and insights efficiently. This platform approach also supports our quest to make the complex problem of securing every connected device simple.
We recently launched Ordr 8 Clinical Defender with persona-based workflows designed for healthcare HTM users. With this new release, we applied the pillar framework above and created a foundation for a scalable platform that will produce many persona-based workflows operating on a single customizable and robust backend data set.
We received some excellent feedback as we shared our latest release and here are some of the things we heard:
“It is refreshing to work with a vendor that listens and empathizes with issues and pain points from customers. It’s exciting to see the rubber meet the road regarding suggestions and requests.”
“Loved what I saw in the review of new GUI.”
“Data shaper simplifies my current operation dramatically.”
“I like simplified search and its’ consistency throughout the product.”
“Location-based shaper is huge both for remote clinic management and for M&A (Mergers & Acquisitions) situations.”
Moving forward, we will keep working with our customers and prospects as design partners in this “design thinking” framework to continually evolve our platform. In the end, it is all the constant customer feedback that makes Ordr an excellent product.
We will be back soon with more updates on how the Ordr platform continues to evolve.
Interested in Learning More?
Subscribe today to stay informed and get regular updates from Ordr Cloud
