Business Intelligence Role in NSM

Since I have been on a roll with the whole BI topic lately, I’ve decided to continue this trend, at least for a little while longer, and apply it to NSM. I have covered this before.

As it stands now, Sguils primary focus is providing facilities for the network security analyst, and it succeeds in that role admirably. In fact, I would go as far as to say it is the best tool for any serious network security monitoring operation. I consider Sguil to be the only tool that really facilitates the analyst’s portion of the NSM methodology as outlined by Richard Bejtlich, with capabilities such as session data, packet data, and full transcripts. But from a business perspective, the Sguil setup has great BI potential for NSM operations. In fact, I would say that the BI potential that NSM provides is one of its strongest, yet most overlooked, elements.

Consider this, the tools that Sguil is built on top of already provide the ability to collect data, and it already logs this data into a somewhat meaningful schema for further data analysis. Data is already stored in such a way that is can be categorized, grouped, and counted, thus providing the basis for real BI opportunities. In my opinion, this is one of the strongest points that separate NSM from other security practices. By being able to work with data, reports can be generated to help managers and stakeholders make informed decisions in regards to information security policies. If you are running a full Sguil setup, and data is collected that indicates a particular Internet facing host is frequently the target of attacks, then managers can make a decision regarding the necessity of this machines role to the companies infrastructure. The numbers will show that the machine is poses a potential problem, and management can address this and direct the IT staff. If the machine has outlived its usefulness, then it merely provides an avenue of attack, and management can decide to take this system offline. I myself have seen this in action with some of the clients that BATC had during my days working as a security analyst.

BI/MIS built on top of NSM data will allow managers to make informed decisions about network security, regardless of their understanding of security principles (although knowledge in this area are definitely beneficial). It doesn’t take an expert to understand the severity of a compromise, and with numbers to support it, the proof is in the pudding (sorry, I’ve been hearing that a lot lately, I’ve been looking for an excuse to use it). So while Sguils capabilities provide for an excellent platform to serve as a transactional system, I believe BIRT is the platform to serve as MIS in this setup, as I have stated previously in other articles.

It has been previously stated that IT staff should be given more authority to enforce security policies. I cannot stress how much I disagree with this belief. The extent of authority I would give IT staff is to remove machines that violate security policy from a network. Anything else is the responsibility of management and HR. IT staffs that I have encountered in the past are usually too busy to play network police, and they do not have proper “people skills” or “emotional intelligence”. Granting them that authority opens up companies to potential lawsuits, there is a reason why management has to undergo training for these sorts of tasks. The best way for IT to address these kinds of issues is to help facilitate better BI based off of NSM data.