The very basic notion of security products and technologies is to protect your organization. However, most of them require some kind of ongoing monitoring. Each product introduces a model for monitoring built on the threats it deals with as well as the protection it provides - whether it is malware, network signature hits, abnormal behavior performed by users - the result is the same. The administrator faces lists of security events presented in different flavors (alerts, reports, logs) using different terminologies (and, BTW, these are in different consoles if you really want to master them). On the other hand, some systems, like Microsoft Forefront Stirling, encapsulate all this data into a single a risk level per each asset in the organization (users, computers and data).
So what’s the best way? Observing the operation of your protection systems OR watching the security risk impact on your user accounts and computers? We vote for the latter here in the Security Assessment Sharing group in Microsoft. Our perspective is that the protection systems should be utilized and viewed from the projected risk perspective. We have been fortunate to bring the risk perspective from the various enterprise security technologies of Microsoft (from TMG, Forefront Server for Exchange and SharePoint, Forefront Client Security and recently with some 3rd party vendors) – all of this work though is not to monitor the security systems but to bring the most concise and comprehensive angle - what our marketing folks now push as Microsoft business ready offering.
So how does this fit in Microsoft codename Stirling? Pretty much like on the below screenshot (it's a screen-capture from our very own dogfood that we "eat" here regularly). No one can really run around, check various consoles and manually correlate log files.. Stirling allows easy viewing and drilling down into IT assets according to their risk level. In the screenshot below, Stirling calculates the risk associated with each computer. On some of the computers the risk is medium, and on some of them the risk is low. Stirling enables the administrator to identify security incidents on computers with a higher risk, and start by handling those.
How's the risk calculated?
1. Stirling's Security Assessment Sharing framework (SAS) allows all security solutions to talk in one common language: the security assessment sharing. Each assessment is described by its type (e.g. compromised computer), severity (e.g. high for an active malware that cannot be cleaned) and confidence (e.g. high for a 100% certain security issue observed) – all targeted to describe a specific computer or user-account.
2. We apply the asset value of the subject of the assessment; this is a 3-level value that describes the asset’s worth to the organization (e.g. Normal for a plain desktop vs. Critical for a mission critical line-of-business server). Once we have these data points (active assessments + asset value) we can classify the security risk on an individual computer or user account.
In the screenshot example above we see 3 security assessments on a computer: one describes an active malware issue and two others describe vulnerabilities from missing security updates. These assessments contribute to the risk on that asset and cause it to be in a Medium risk level.
Why is security risk monitoring better from viewing lists of active malware infections log in the enterprise? Simply because it aggregates the various security incidents (input points from different protection technologies, but this is a subject for a different post) into a comprehensive risk-based view that presents a prioritized assets in risk (instead of chasing around the active security events in the enterprise).
When we designed Stirling we saw the interest from customers to also get a concise understanding on the security risk for some specific Stirling groups and for the entire enterprise. And so we designed to this scenario with the risk gauge and risk pie-charts in the main Stirling Security Dashboard (another screenshot from our dogfood is here):
What you can see here is that you have a quick at-a-glance view on whether you have a burning-risk enterprise situation (or a relatively peaceful day). Each of the dashboard elements allows one-click drilldown navigation to see the exact set of computers and user-accounts that pose risk on the enterprise.
How's the enterprise risk presented in the gauge is calculated?
Our algorithm is calculating the amount and percentage of IT assets at risk in the enterprise, and then, according to some thresholds, presents the overall enterprise risk. A risk rule example could be the high enterprise when in case 20% of the enterprise computers are found at high risk.
Like a consumer confidence economic indicator, the approach here is to report on the current overall situation (Stirling reports allow comparing to previous risk levels). And the main benefit is again the broadest possible perspective on IT assets that need to be protected.
I'm not suggesting by any means that monitoring the actual security devices is not needed. It's absolutely a must to check on the health of these systems and sometimes needed in order to analyze the security risk posed on protection targets that is spotted using the security device itself. However, if you care about being the most effective when it comes to security monitoring I suggest you consider my cup of tea – asset-based security monitoring. Feedback on that anyone?
