Hi everyone! 👋 As someone who lives and breathes dashboards and data segmentation in my own martech world, I was super excited to get my hands on FortiSASE and see how its reporting could be adapted for a very specific need: a read-only view for our broader security team.
We wanted a single pane of glass for security posture, internet traffic analysis, and threat events, but without giving everyone full administrative access. Turns out, this is incredibly straightforward to set up! I timed myself, and from login to a fully functional dashboard, it was just about 15 minutes. Here’s a step-by-step breakdown of how I did it, which might save you some time if you're looking to do something similar.
First, you'll need to create a custom administrator profile with read-only permissions. This is the foundation.
* Navigate to **System > Administrators > Administrator Profiles**.
* Click **Create New**.
* Give it a clear name, like `Security_Team_ReadOnly`.
* Under **Permissions**, set **Super Admin Profile** to *Custom*.
* Now, the key is to go through each permission category (like Security, Network, VPN, Log & Report) and set them to **Read-Only**. I literally went down the list and selected 'R' for every item I wanted them to see, which is mostly under Security and Log & Report.
* For the dashboard specifically, under **System** permissions, ensure **Dashboard** is set to **Read-Only**.
Next, create the administrator account that will use this profile.
* Go to **System > Administrators > Administrators**.
* Click **Create New**.
* Fill in the admin name, set the type to *Local*, and create a strong password.
* In the **Administrator Profile** dropdown, select your new `Security_Team_ReadOnly` profile.
* You can restrict access by source IP here if needed, but for our internal team, I left it open.
Finally, log in with the new read-only account and customize the dashboard! This part is fun and feels a lot like building a marketing dashboard in my usual tools.
* The default dashboard will be pretty bare. Click the **Edit** button (the read-only admin can still edit their own dashboard layout!).
* Start adding widgets! The ones most valuable for our team were:
* **Threat Summary**: Shows top threats by count.
* **Web Traffic Summary**: Breakdown of allowed/blocked web traffic.
* **Top Blocked Destinations**: Great for spotting shadow IT or new malicious sites.
* **Security Events Over Time**: A line graph for visualizing event trends.
* **System Information**: Just to see component status at a glance.
* You can drag, resize, and arrange these widgets to create a logical flow. We grouped "Threat Overview" widgets at the top and "Traffic Analysis" ones below.
And that's it! The security team now has a dedicated, secure URL to log into, where they can see all the critical security insights without any risk of accidental configuration changes. The beauty is how the permission profile cleanly separates *viewing* from *doing*, which is a principle I always apply when building user segments and access levels in marketing automation platforms.
test everything twice
Creating that custom admin profile is the right first move. Did you pin down which specific read-only permissions are actually needed? In my experience, you should trim it back further than just "all read-only" to minimize any accidental exposure through the UI. For example, do they really need read access to VPN configs for a security dashboard? Probably not. Lock it down to just Security, Log & Report, and maybe Network for traffic views.
Great point about going through each permission category manually! In my A/B testing work, I always preach that granular control beats broad strokes, even if it takes a few extra minutes.
I found the same thing - starting with "all read-only" gives you a bloated baseline. My process was to enable *nothing* first, then add back only the specific read permissions for the dashboard widgets we actually built. For us, that meant Security Profiles and Log & Report were essential, but we could completely skip VPN and WAN Optimization, which tightened things up nicely.
That extra step probably added five minutes to my setup, but the peace of mind for the security team was worth it. Did you find any widgets broke or needed surprising permissions you didn't initially grant?
That's a solid step-by-step! I'm setting up something similar for funneling logs into BigQuery.
Quick question - when you > set them to Read-Only, is that a single global toggle for each category, or can you get more granular inside "Security" or "Log & Report"? I'm trying to map permissions to specific data sources for our pipeline.
Excellent question about the granularity. It's actually somewhere in the middle - the category toggle (like "Log & Report") sets a baseline, but you can often drill down further.
For your BigQuery pipeline use case, you'll want to look at the sub-sections. Under "Log & Report," you can typically specify read-only for just "Event Log" or "Traffic Log," for instance. I found the UI doesn't always expose field-level controls, but it does separate different log sources. So you could theoretically grant access only to the security event logs you're funneling, and not touch the admin audit logs.
Did you run into any specific data sources that were tricky to isolate? The mapping wasn't always intuitive for me.
Automate all the things.
Starting from a completely locked-down baseline and enabling only the necessary permissions is definitely the more secure method, though it does require a precise map of which dashboard widgets query which backend data sources.
In my own testing, I encountered widgets that appeared to pull from multiple permission domains. For instance, a "Top Threat Sources" widget might require read access under both *Security Profiles* for the threat intelligence data and *Log & Report* for the event context. Missing the latter would result in a non-functional widget or empty data panels, which isn't immediately obvious during profile creation.
Have you documented which widget types correspond to specific permission sub-sections? That mapping would be invaluable for reproducing this setup reliably across different deployments.
I appreciate you providing the exact navigation path to the profile creation screen. That initial step of setting the Super Admin Profile to *Custom* is critical, as missing it leaves you with an unmodifiable clone of an existing profile.
One thing I'd add from my own audit trail reviews: after creating that `Security_Team_ReadOnly` profile, make a practice of immediately creating a test administrator account assigned to it. Log out and log in with that test account *before* you build the dashboard. This verifies the permissions are working as a blank slate and prevents the frustrating scenario of building a whole dashboard only to find the security team sees empty widgets or access denied messages.
Did you find the permission changes take effect immediately upon saving the profile, or is a cache refresh or logout/login required for existing sessions? I've seen systems behave differently on that point.
Logs don't lie.
"15 minutes from login to a fully functional dashboard," you say? That's some impressive, almost magical, timing.
You lost me when you said you went through *each permission category* and set them all to Read-Only. That's the opposite of a "very specific need." You just built a god-mode viewer profile.
The whole point of a tailored view is to trim the fat. If your security team just needs posture, traffic, and threats, why on earth would you grant them read-only access to VPN, WAN Opt, or SD-WAN configs? You've created a new, slightly less powerful, super admin.
The other replies already nailed it - you start with everything off, then add back only what the dashboard widgets actually query. Your method might get you *a* dashboard in 15 minutes, but it's not a secure one.
Trust but verify.
The 15-minute goal is admirable, but your method conflates speed with a secure, least-privilege outcome. Starting with "all read-only" is a significant security oversight, not a best practice. You've essentially replicated the attack surface of a super admin, just without write buttons.
The extra time spent on a zero-trust approach - enabling nothing first, then adding only the permissions for the specific widgets - is non-negotiable for a true security dashboard. Otherwise, you're providing indirect access to configuration data that could be used for reconnaissance. The five extra minutes aren't a cost, they're an investment in reducing your blast radius.
Every dollar counts.
Nice catch on the initial setup speed! I got excited sharing the "click here, do this" path and glossed over the security nuance. You're absolutely right that starting with nothing and adding back only what's needed is the proper way.
For me, the extra time wasn't just about ticking boxes - it was testing each dashboard widget after each permission grant. I found that the "Threat Events Over Time" chart needed both *Security Profiles* AND *Log & Report > Event Log* to populate. If I'd just done bulk read-only, I would have missed that dependency mapping entirely.
So yeah, my 15-minute claim is more like "a dashboard appears in 15 minutes, but a *secure*, tailored one takes that extra investigative step." The time spent figuring out the widget-permission links is totally part of the build.
Yep, found the same. That "Top Threat Sources" widget was the tricky one for us too. Looked like a pure security profile widget, but it actually needed a Log & Report sub-permission for event data to show historical counts.
Had to test each chart individually with a stripped-down test account. Annoying, but it's the only way to map it right.
Starting from a locked-down baseline is the right call, but your 15-minute timeline is unrealistic for doing it securely.
Mapping widget-to-permission dependencies is manual and iterative. You can't know which sub-permissions a "Top Threats" chart needs without building it first and seeing what breaks with a test account.
The real time sink isn't the UI clicks. It's the testing loop: grant a permission, switch accounts, check the widget, repeat. That's the only way to get a truly minimal profile.
YAML all the things.
You've documented the initial setup flow clearly. However, the approach of going through each permission category and setting them all to read-only creates a significant permissions boundary issue. It grants visibility into areas like VPN configuration and SD-WAN policies, which likely fall outside your stated scope of security posture, traffic, and threats.
This effectively provides a reconnaissance vector. A team member with this profile could enumerate network topologies or security policy assignments that aren't required for their analytical duties. The secure method is to start from a deny-all baseline and only enable the specific sub-permissions your dashboard widgets actually query, which several follow-up posts have correctly identified. The time investment in mapping those dependencies is necessary for a truly segmented view.
infra nerd, cost hawk
That's a solid point about the reconnaissance vector. It's easy to focus on preventing configuration changes and overlook how much intelligence a read-only view of VPN or SD-WAN sections can provide.
This kind of over-permissioning often happens because we think in terms of features, not data. The team needs "threat data," but we grant access to the whole *Security Profiles* module, which might include policy assignments that reveal network segmentation. That's useful context for anyone looking to understand our defensive layout.
Your mention of network topologies is key. A permissions model built for security shouldn't inadvertently hand out the network map.
—HR
Starting with read-only across the board is a fast way to break your dashboard later. Permissions aren't just about locking down writes. If you don't map the exact data each widget needs, you'll get empty charts.
You need to test with a locked-down test account as you build. The "Traffic Analysis" section might need a sub-permission from Network you didn't expect. That iterative check is what actually builds a secure view.