Concepts
Insights uses most of its terms from your SIP installation, and adds a few of its own. This page covers what Insights collects, how that data is scoped, and what each number counts.
How Insights gets your data
Insights runs in FireMon's cloud. It has no route into your network. Your SIP installation opens the connection itself, outbound over HTTPS, and holds it open. You don't need an inbound firewall rule. Prerequisites lists the two hostnames it reaches.
Once a day, a collection job asks every registered installation for:
- The device list and the device groups.
- A value for each metric, on every device and every device group.
- Your assessment and control definitions, and their results.
- Your Policy Planner workflows and tickets, if you have Policy Planner.
Your SIP sends user records without being asked: as a batch when it syncs users, and again when someone opens Insights from the module menu.
Metric values can be up to 24 hours old. A figure on the KPI or All Metrics page is what your SIP reported at the last collection, not what it would report now.
What Insights keeps is measurement and inventory data:
| What | Detail |
|---|---|
| Metric values | One number per metric, per device and per device group, per collection. |
| Device inventory | Each device's ID, name, description, the device groups it belongs to, and its device pack — the vendor, pack ID, name, type, version and build date SIP reports for it. |
| Device groups | Each group's ID and name. |
| Controls and assessments | The definitions, and each control's pass or fail per device group, with the number of rules and devices that failed and the IDs of the failing devices. |
| Users | The name, email address, SIP user ID and authorized device groups your SIP sends across for each user. |
| Your registration | Your client ID, your SIP installation's address for the deep links back, the public key it sent and the matching private key Insights holds for it, the identifiers of the installations allowed to connect, and the SIP and plugin versions seen at the last collection. |
Insights doesn't collect your rule contents. It collects the number of unused rules in a device group, not the rules themselves. Nothing in the collection copies a rule's source, destination, service or action, a network object's addresses, or a NAT translation. Control definitions arrive with their properties and filters removed, which are the parts that hold addresses, ports, protocols, and the device types a control applies to. Assessments arrive with their text sections removed. So where a number has rules behind it, Insights gives you a link into Security Manager instead of a list.
Policy Planner is the exception. If you have it licensed, Insights stores the ticket records your Policy Planner returns, not just the figures worked out from them. Each record holds the ticket ID, its workflow, its status, its created and completed timestamps, its tasks, and the system variables it carries. Every collection replaces them, and a ticket that no longer exists in Policy Planner is removed on the next run.
The AI features answer from your live system. Ask AI and the MCP server send their queries down the same connection to your SIP. Ask about a specific rule and the answer comes from your system at the moment you ask. Both run as your own SIP user, so Security Manager applies that user's permissions just as it would in its own UI. Rules, objects, network paths, raw SIQL, Policy Planner, and listings of your devices and device groups all work this way. Metric values and control results don't. Those come from the stored copy, and can be up to 24 hours old. Insights stores your Ask AI conversations against your account: the questions, the answers, and the results of the queries run to produce them.
Unregistering stops the collection. When an administrator clicks Unregister in Administration > Settings > Insights, Insights marks the registration as unregistered and revokes every API key that installation holds. The next daily run skips your client, so nothing further is collected and your SIP installation can no longer call Insights. Connect Your SIP Instance covers when you would do this, and what to have ready before you register again.
Device groups
A device group is a named set of the devices your SIP manages. You might group them by site, by business unit, or by environment. A device can belong to more than one group.
You define device groups in SIP, under Administration > Device > Device Groups. Insights reads them with everything else it collects, so a group you rename there is renamed here at the next collection. Insights has no screen for adding, editing, or deleting one.
Device group 1 is the all-devices group. Insights opens on it. Your choice of group then follows you from page to page for the rest of the session, and returns to all devices when you reload.
Almost every number in Insights belongs to one device group. Insights collects metrics per group as well as per device, so 8,412 unused rules always means 8,412 unused rules in the group you have selected. Change the selector and the same metric shows a different figure. The device and rule counts beside the selector tell you the scope.
Four parts of Insights ignore that selector:
- Change replaces it with a workflow selector, because Policy Planner numbers are counted per workflow rather than per device group.
- Best Practices has a device group selector of its own, which does not track the shared one.
- The benchmark is built from every customer's device group 1, whatever you have selected on your own side. Benchmarking covers what that means when you narrow your own view.
- Your preferences — the metrics you checked for KPI, the order you put them in, your fiscal year start — apply across every group.
The selector offers the groups your SIP permissions authorize, not every group that exists. Two people at the same company can see different lists and different numbers on the same page. Users and Access covers how that authorization is decided, and what someone with no authorized groups sees.
Policy data
Policy data is what your devices enforce, and what Insights counts. Insights holds the counts, not the contents. Almost every metric name pairs one of the terms below with one of the three questions that follow.
Security rules are the allow and deny decisions on a device. Together they make up the rulebase. NAT rules are the address translations alongside them. Insights counts both. It also counts rules that are disabled, expired, shadowed by a rule above them, redundant, missing a comment, or have logging turned off. Logging is counted twice: once across all rules, and once for accept rules on their own.
Objects are the named definitions that rules are written against, so an address or a port doesn't have to be repeated in every rule that needs it. Network objects are addresses, subnets and ranges. Service objects are protocols and ports. Application objects are the named applications an application-aware device recognizes. Insights also counts profile objects, which are the inspection profiles applied to traffic, and object groups. Network object groups have a page of their own.
Insights asks three questions about that inventory. Most of the cleanup metrics answer one of them.
| The question | The word | What it counts |
|---|---|---|
| Has traffic hit this? | unused | Nothing has matched it. A rule counts as unused when it has matched nothing in the last 90 days; an object counts as unused when SIP holds no last-used date for it at all. |
| Is any rule using this? | unreferenced | The object exists but no rule mentions it. |
| Is there another one exactly like it? | duplicate | Two definitions with identical contents under different names. |
The unused rule count leaves out disabled rules, and rules created inside the 90-day window.
Unused and unreferenced are counted separately because they mean different things. Nothing points at an unreferenced object at all. An unused object may still be referenced by a live rule that never matches anything, so it's as much a question about the rule as about the object.
Controls and assessments
A control is one check Security Manager runs against your devices and their rules. For example: that no rule permits any source to any destination, that logging is on where your policy says it should be, or that remote access uses an approved method. You write controls in SIP, under Administration > Compliance. Most of the ones you'll see come from the library FireMon ships.
Every control carries a severity, a number set by whoever wrote it. Insights sorts those into four bands and counts the failures in each: critical at 8 and above, high at 6 to 7, medium at 3 to 5, and low at 2 and below. Severity is also the weight behind the category scores. A critical control failing on one device moves a score further than a low one failing on four.
An assessment is a named set of controls, assigned to device groups and run together. Your SIP may have several. Best Practices is built almost entirely from the one named Best Practices, the FireMon Best Practices Assessment. That is why most of that page shows the same checks for every customer, and can be compared across them. Its Vendor Hardening card is the exception, and draws on a set of CIS benchmark assessments instead. Insights collects assessments you write yourself too, but that page doesn't use them.
A control ends up in one of three states for a device group.
| State | What it means |
|---|---|
| Pass | The control ran and nothing failed it. |
| Fail | The control ran and at least one device or rule failed it. Insights records how many of each, and which devices. |
| No data | The control produced no result for this device group over the period you are looking at. |
No data is common, and it isn't a failure. Each control is scoped to the device types, vendors and devices it applies to. A check about a VPN configuration returns nothing for a device with no VPN. An assessment doesn't have to be assigned to every device in a group either. Controls with no data are left out of the score. They don't count as passing or failing.
Results reach Insights on the daily collection, not live. Insights reads each control in your SIP, takes its per-device results, and totals them per assessment and per device group. It stores one row per control, per device group, per collection: pass or fail, how many rules failed, how many devices failed, and which devices those were. The per-rule detail behind those counts stays in Security Manager.
Scores
Insights uses the word score for four different numbers. Two come from Security Manager, and two are its own.
Security Concern Index (SCI) is Security Manager's measure of how much failed control severity a device is carrying. It is calculated per device. Insights collects it and reports the device group's average as Average Security Concern Index. Lower is better.
Device complexity is Security Manager's measure of how complicated a device's configuration and rules are: how many rules there are, how much they overlap, and how the whole thing is structured. It is also per device, also averaged across the group by Insights, and lower is better here too.
Insights doesn't recalculate either one. It collects the number Security Manager produced and keeps the history.
Category scores are Insights' own, and they're what the Best Practices page shows. Each category takes the controls tagged to it, and weights each one by how many devices it covers and by its severity. The score is the failing share of that weight, on a 0 to 10 scale. Zero means no device is failing any control in the category. Ten means every device fails every one. Controls with no data are left out.
Overall Posture is the average of the category scores that have data, on the same 0 to 10 scale. It is charted by fiscal quarter: the quarter to date plus the three before it, against a fiscal year start month you choose.
Zero is the good end of both Insights scores. They measure failure, not achievement. A category score that rises means more is failing, and a falling one means less. Benchmarking covers how to read a score against the customer average.
SCI and a category score can move differently on the same data. SCI is worked out per device and then averaged, and treats each control as pass or fail on each device. A category score is one weighted figure for the whole group, where a control covering 400 devices counts for far more than one covering 4.
Revisions
A revision is a copy of one device's configuration at a point in time. Security Manager retrieves the configuration on a schedule, or when it detects a change, normalizes it, and stores the result as a new revision. Your policy history is that stack of revisions, and every "what changed" number in Insights comes from the differences between them.
When a device stops producing revisions, its numbers stay at the last successful retrieval while the real configuration moves on, and every metric that device feeds goes out of date. Five metrics count the devices in that state:
| Metric | What it is telling you |
|---|---|
| Devices where the latest revision failed | The most recent retrieval failed, so this device's data is already behind. |
| Devices with more than one bad revision in the last 72 hours | Repeated failure. Usually credentials, reachability or a missing device pack. |
| Devices with no revision in the last 48 hours | Nothing new has arrived. Normal on a static device, worth checking on a busy one. |
| Devices with no revisions | Never successfully retrieved since it was added to management. |
| Devices with only one revision | Retrieved once at onboarding and never again. |
All five are also given as a share of your total device count, so adding devices doesn't show up as a worsening number.
Insights also counts the rule changes themselves over the period you select: rules added, rules removed and rules modified. Net is additions minus removals. 400 additions with 380 removals is very different from 400 additions with 20 removals, and the addition count on its own doesn't tell you which you have. Revision Analytics breaks this down by device, and compares your net growth with other customers.
Policy Planner
Policy Planner is a separately licensed SIP add-on. If your organization hasn't licensed it, Insights has nothing to collect here and the Change page is empty.
Where it is licensed, Policy Planner turns an access request into a rule change. A ticket is one request, from "please open this port between these two systems" through to the change being made. A workflow is the process a ticket follows, and an organization can run several: a fast path for low-risk changes, a longer one for anything touching the perimeter. A stage is one step of a workflow. Insights measures four of them: redesign, review, implement and verify. Redesign is the design step, and the screens and metric names label it Redesign.
Policy Planner numbers are counted per workflow, not per device group. The Change page swaps the device group selector for a workflow selector to match. Insights also keeps a combined figure across all workflows.
What Insights trends:
| Number | What it measures |
|---|---|
| Tickets | How many tickets exist, and how many were created on each day. |
| Open tickets | Tickets not yet completed, also expressed as a share of all tickets. |
| Average duration to complete | Hours from a ticket being created to being completed. |
| Average stage duration | Hours spent in redesign, review, implement and verify, each measured on its own. |
| Changes made | Security rules, network objects and service objects changed through Policy Planner. |
When the average duration climbs, the stage breakdown tells you which step is taking the time.
Metrics
A metric is a daily snapshot of one count. Insights asks your SIP how many of something there are, stores the number against the date, and asks again tomorrow. It doesn't store the data behind the number. So a metric can tell you unused rules rose by 600 this quarter, but only Security Manager can tell you which rules they are.
Everything else on the metric pages is built from that series. The current value is the most recent snapshot. Change over a period compares the newest snapshot with the oldest one inside it. Widening the range doesn't add anything up. It moves the point you're compared against.
Ideal direction. Some metrics are better low: unused rules, shadowed rules, control failures, duplicate and unreferenced objects, complexity and SCI. Others have no ideal at all. Total Devices, Total Security Rules and Total Network Objects describe what you have rather than judging it. No metric in Insights is better high, so a rising number is either bad or neutral. Insights colors a change green or red where the metric has an ideal direction, and leaves it uncolored where it doesn't.
Counts and proportions. Where a metric has a natural total, Insights measures change against that total instead of the raw number. A customer goes from 100 unused rules to 200, which looks like a bad quarter. But their total rules went from 500 to 10,000 over the same period, so unused rules fell from a fifth of all rules to a fiftieth. The raw count doubled. As a share of all rules, it fell by a factor of ten.
So unused rules are tracked against total rules, control failures against total rules, unreferenced network objects against total network objects, and so on. Metrics with nothing to divide by are tracked on the raw number: the totals, the scores, and counts like Number of Revisions. Benchmarking applies the same rule to the comparison against other customers.
The period. There are five trend ranges: 1w, 1mo, 6mo, 1yr and Max. A range unlocks once your registration reaches a set age. Finding Your Way Around covers where the control is, and which pages use it.