Perimeter
4/5/2011
11:49 AM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%

IT GRC, ESIM Vendors Dig In For War

With no sign of the two technologies combining into one, where does that leave the buyer?

Although IT GRC and the easily identifiable vendors that compete in the sector might sound fairly cut-and-dry, there is an adjacent technology sector muddying the water and causing confusion among buyers: enterprise security information management (ESIM).

The ESIM sector is composed primarily of security information and event management (SIEM) and log management vendors. One could easily draw static lines dividing disparate security technologies, but the lines (if they ever truly existed) between ESIM and IT GRC products are starting to blur.

Since EMC's January 2010 acquisition of Archer Technologies, ESIM vendors are including more risk-centric capabilities within their core products. In fact, many ESIM vendors began searching for an IT GRC product acquisition to achieve the competitive parity presented by a joint RSA (enVision) and EMC (Archer) product pairing. From a 10,000-foot view, one could easily draw parallels between both product sectors.

Generally speaking, both can consume log and vulnerability data in addition to providing users with alerting, dashboard, and ticket workflow capabilities. The biggest difference, however, is the audience for which each product is designed. ESIM products have always had a heavily weighted operations and security side, whereas IT GRC products are traditionally presented to CISO-, CSO- and CFO-level executives, in addition to the somewhat newly minted chief risk officer (CRO) and chief compliance officer (CCO) designates.

To appeal to all levels of the organization, nearly all of these vendors present their products with an alluring and whimsical term to hook buyers: a single pane of glass. Promising the coveted single pane of glass for all levels of the organization to leverage, vendors are hoping to bring their products to bear in support of the entire business stack -- from the entrenched security practitioner at the bottom to the executive branch of the organization.

Unfortunately, it is extremely difficult to present data in a way that is everything to everyone, since ESIM and IT GRC products were designed with different business use cases in mind. So ESIM is a more security-centric and operationally positioned technology, while IT GRC is a more business-centric and process-positioned technology.

So which one should you pick? One issue that plagues the adoption of IT GRC systems is the cost of purchasing both an IT GRC and ESIM product. Organizations faced with having to choose between an IT GRC or ESIM product typically do not have the budget to purchase both. Since the purchase of an ESIM is predominantly driven by a compliance mandate, the water becomes even more muddied when the buyer learns that the ESIM could cover everything but the "G" portion of IT GRC -- a somewhat lofty claim when the capabilities of both product sectors are examined under the end-user microscope.

So who's the buyer for IT GRC? The side of the organization that purchases IT GRC products remains those responsible for the measurement and reporting of risk and compliance within the organization. These people are also the holders of the budget for projects of this nature and might see the security aspect of an ESIM as simply "nice to have," as opposed to a primary purchasing driver. Should the security team have little sway over those further up the management stack, increasingly more organizations could find themselves adopting IT GRC products over ESIM products.

While I don't see the ESIM and IT GRC sectors converging to create a new combined sector, it is likely safe to postulate that there will at least be some overlap in the immediate future as the adjacent sectors figure each other out.

A more likely result will be closer integration and data sharing between the products in each sector. Why send IDS logs to both an ESIM and an IT GRC product when one could simply forward the data to the other? Instead of poking holes in a perimeter firewall to allow data sources to feed a cloud-based IT GRC product, why not allow the on-premises ESIM product to aggregate and forward, or vice versa? Of course, in order to facilitate this transparent cooperation, a promiscuous integration stance will need to be embraced by the vendors in their respective sectors to further the cross-pollination between products.

Andrew Hay is a senior security analyst with The 451 Group's Enterprise Security Practice

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0972
Published: 2014-08-01
The kgsl graphics driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, does not properly prevent write access to IOMMU context registers, which allows local users to select a custom page table, and consequently write ...

CVE-2014-2627
Published: 2014-08-01
Unspecified vulnerability in HP NonStop NetBatch G06.14 through G06.32.01, H06 through H06.28, and J06 through J06.17.01 allows remote authenticated users to gain privileges for NetBatch job execution via unknown vectors.

CVE-2014-3009
Published: 2014-08-01
The GDS component in IBM InfoSphere Master Data Management - Collaborative Edition 10.0 through 11.0 and InfoSphere Master Data Management Server for Product Information Management 9.0 and 9.1 does not properly handle FRAME elements, which makes it easier for remote authenticated users to conduct ph...

CVE-2014-3302
Published: 2014-08-01
user.php in Cisco WebEx Meetings Server 1.5(.1.131) and earlier does not properly implement the token timer for authenticated encryption, which allows remote attackers to obtain sensitive information via a crafted URL, aka Bug ID CSCuj81708.

CVE-2014-3534
Published: 2014-08-01
arch/s390/kernel/ptrace.c in the Linux kernel before 3.15.8 on the s390 platform does not properly restrict address-space control operations in PTRACE_POKEUSR_AREA requests, which allows local users to obtain read and write access to kernel memory locations, and consequently gain privileges, via a c...

Best of the Web
Dark Reading Radio