Rework Dashboard page

[vpetersson]

Sending the user to a list of devices isn't the best user experience. Instead, let's rework the interface a bit.

Node List

Let's start by moving the current dashboard (i.e. the device list) to a separate tab called 'Nodes'

Dashboard

The Dashboard is what the user will be presented with when signing in. It should have visualizations and an "Add Node" button as a call to action.

I want to visualize the following:

• Failed/Successful logins
• Average Trust Score
• CVEs detected (by severity)
• Blocked connections (i.e. rogue connections blocked by the agent)

All should be fleet wide and over the last 30 days.

I'm thinking we could use something like a stacked bar chart from ChartJS

Crude WIP Mockup:

[a-martynovich]

@vpetersson Please explain how exactly this data should be presented: what are the X and Y axes and what do we consider different datasets (looking at stacked bar chard you provided).

[vpetersson]

These would be four different charts. To be more specific, the following would be stacked charts:

• Failed/Successful logins
• CVEs detected (by severity)

(Y is simply the count of each item, and X is time)

For the following we would simply have a simple bar chart (assuming the stacked one doesn't fallback to that):

• Average Trust Score
• Blocked connections (i.e. rogue connections blocked by the agent)

[a-martynovich]

@vpetersson So we view nodes as different datasets, right? And which time measures should X axis show? Like days, months, ...? Also we should now keep history of these data points in order to display them in this fashion.

[vpetersson]

So we view nodes as different datasets, right?

We would look at this comprehensively across the fleet. E.g. failed logins across the entire fleet.

And which time measures should X axis show? Like days, months,

I'm thinking 30 days.

Also we should now keep history of these data points in order to display them in this fashion.

Yes, I'm aware we don't have all the historical data for this right now.

[a-martynovich]

Yes, I'm aware we don't have all the historical data for this right now.

New questions arise now. Where do we store the historical data: our database or somewhere else (DataStore?). How often do we sample the data: once in 30d or more often (shall we need better resolution in the future?).

Also, regarding another graph:

Blocked connections (i.e. rogue connections blocked by the agent)

1. What does this mean? Incoming or outgoing connections?
2. Are those connections which were actually blocked on the device (in which case how do we gather this data: by reading the journal or adding I-tables counter?) or is it just the number of ports/connections blocked by the user in the UI?
3. Why did you put it in a "simple bar charts" category, not in "stacked bar charts"?
   1. Is it supposed to be a fleet-wide value?
   2. if so, how is it calculated? A sum (in which case we can't deduce the connections unless we send them all to the server, and that's another issue), or an average?

[vpetersson]

New questions arise now. Where do we store the historical data: our database or somewhere else (DataStore?). How often do we sample the data: once in 30d or more often (shall we need better resolution in the future?).

I'm easy on the place to store this. It's probably "cheaper" to store this in DataStore than in SQL.

In terms of frequency, i want a sample rate of once per day. Let's just take a snapshot per day, and then and store that. We can deal with retention period later.

What does this mean? Incoming or outgoing connections?

Good question. My initial thought was outgoing connections (the ones we check against the rouge IP blocks). However, now that you mention it, we should probably do both.

Are those connections which were actually blocked on the device (in which case how do we gather this data: by reading the journal or adding I-tables counter?) or is it just the number of ports/connections blocked by the user in the UI?

My initial line of thinking was that we'd use the ones we read back from the journal. What I want to illustrate is that "we're actually doing something" with regards to blocking connections to show that we are providing value.

Why did you put it in a "simple bar charts" category, not in "stacked bar charts"?

Well, for some of these metrics, we only have one data point to render. Hence there is no need for stacking.

Is it supposed to be a fleet-wide value?

Yes.

if so, how is it calculated? A sum (in which case we can't deduce the connections unless we send them all to the server, and that's another issue), or an average?

It's the sum. So yes, we need to send them to the server, which would include some rework on the agent side i presume.

[a-martynovich]

If it's a fleet-wide value and it's a sum, do we need to dedup the list of blocked connections? Suppose the whole fleet of N nodes tries to connect to some external IP and this gets blocked on every node. Does this count as a) 1 blocked connection (in which case we need to dedup the list on the server) or b) N blocked connections?

In case of a) if we need to dedup the list on the server we need to send the list of blocked connections from every device. In order to gather this list we can read the journal but it's unreliable because some records may easily be lost (rate control) or rotated.

In case of b) if we don't need to dedup the list we can use iptables counter to track how many connections were blocked. This is reliable but we don't track which connections were actually blocked, only their count.

[vpetersson]

No, we shouldn't dedup the list. Hence a single endpoint attempt on all nodes should count as N connections.

That said, if we use the iptables counter, when does that reset (on reboot)? If so, it's not super useful. We want to understand the number of blocked connections in in 24 hour windows.

[a-martynovich]

That said, if we use the iptables counter, when does that reset (on reboot)? If so, it's not super useful. We want to understand the number of blocked connections in in 24 hour windows.

I think we can work around that. If not, reading journal is our fallback option.

[AlEsmail]

What will the dashboard look like before a node has been added? How will you not only guide but also encourage the user to 'get started'?

• Can you keep dummy data in here similar to how airtable uses dummy data to illustrate how their spreadsheets can be used?
• Or warnings on common CVEs or risky connections?
• Other methods to engage a user that has just arrived?

This dashboard task does a good job for users that have already started but our current situation is that we need a strong onboarding process for new users as well.

[a-martynovich]

"Crude WIP Mockup" contains data which is not described in this task.

[vpetersson]

"Crude WIP Mockup" contains data which is not described in this task.

Yes, this task is work in progress.

[vpetersson]

@AlEsmail

Can you keep dummy data in here similar to how airtable uses dummy data to illustrate how their spreadsheets can be used?

I'm not sure about the idea of using dummy data. In Airtable, it isn't really dummy data. They literally create a spreadsheet for you based on a template. The only way I can think of duplicating something similar, would be to have a 'dummy node' as part of the account creation that would inherit some data. This would however make it fairly complicated to resolve the historical records once the user adds his/her first node.

Or warnings on common CVEs or risky connections?

I'm not following this one.

Other methods to engage a user that has just arrived?

I'm thinking we would push recommended actions (such as integrate with Github and add your first node) to the Next Actions list.

Here's an updated mockup:

[AlEsmail]

I'm not sure about the idea of using dummy data. In Airtable, it isn't really dummy data. They literally create a spreadsheet for you based on a template. The only way I can think of duplicating something similar, would be to have a 'dummy node' as part of the account creation that would inherit some data. This would however make it fairly complicated to resolve the historical records once the user adds his/her first node.

How about just a picture of a graph so that they have some idea of why they should engage with this interface?

Or warnings on common CVEs or risky connections?

I'm not following this one.

Other methods to engage a user that has just arrived?

I'm thinking we would push recommended actions (such as integrate with Github and add your first node) to the Next Actions list.

This doesn't answer the question of why a user should bother to integrate Github or add a node. Imagine staring at an empty dashboard and being told 'do this next'. You're assuming people know what they're getting and just need to be educated on how to get there. Assume they haven't read the docs, the blogs or the tutorials. Why should they engage?

I'm also not convinced on all the data you've chosen or on the order.

Why are failed logins the most important thing that they make the dashboard instead of insecure services or CVE short list? (let alone top left corner) Why is this over time? There is no time based evolution of failed logins - either someone is brute force attacking or not. Or someone forgot their password. If you ask me this is wasted space.

I'd propose the following:
-Top left: Trust score number - 7 day average (small number below indicating % change over last 7 day period)

-Top right: Daily trust score line chart (time frame: last 7 days)
Or bar graph: last 28 days but with 4 data points indicating 7 day averages (I prefer this)

-Bottom left: Next Five reco actions (as you have bottom right)

-Bottom right: Recommended actions completed (same time frame as daily trust score chart from top right) - that way performance should reflect effort in actions completed

[vpetersson]

How about just a picture of a graph so that they have some idea of why they should engage with this interface?

This is presumably doable without too much effort.

This doesn't answer the question of why a user should bother to integrate Github or add a node. Imagine staring at an empty dashboard and being told 'do this next'. You're assuming people know what they're getting and just need to be educated on how to get there. Assume they haven't read the docs, the blogs or the tutorials. Why should they engage?

I don't think a user would sign up for an account without some goal. They wouldn't sign up for an account if they just browsing the internet. Bringing this back to Airtable. You wouldn't sign up for an Airtable account without having a purpose (e.g. you want to try a new spredsheet tool or try a new CRM). The same holds true here. You wouldn't sign up for WoTT if you have no interest in server/device/node security.

Why are failed logins the most important thing that they make the dashboard instead of insecure services or CVE short list?

The order of things isn't set. We can move them around. It's a crude mockup.

Why is this over time? There is no time based evolution of failed logins - either someone is brute force attacking or not. Or someone forgot their password. If you ask me this is wasted space.

I disagree. Time is super relevant here. You want to see the development over time. This is how you identify patterns. Such as a brute force attack five days ago. I would definitely want to see this data rendered over time.

Another reason for including failed/successful login is that I anticipate it to be a very dynamic data point. If we're not using this, everything is more or less tied to recommended actions, which are somewhat static (with the exception of detected CVEs).

Top left: Trust score number - 7 day average (small number below indicating % change over last 7 day period)

I'm not opposing this.

Top right: Daily trust score line chart (time frame: last 7 days) Or bar graph: last 28 days but with 4 data points indicating 7 day averages (I prefer this)
-Bottom left: Next Five reco actions (as you have bottom right)
-Bottom right: Recommended actions completed (same time frame as daily trust score chart from top right) - that way performance should reflect effort in actions completed

Here's a mockup: