« May 2008 | Main | July 2008 »
Identity titans are battling over log management
Despite economic slowdown, the identity and access management (IAM) market seems on fire. Forrester predicts in a recent report (March 2008) that the market for identity and access management (IAM) solutions will grow more than 20 percent annually, from about $2.6 billion worldwide in 2006 to more than $12.3 billion by 2014.
Similarly, in a security spending survey published by Goldman Sachs in April 2008, Identity Management ranked second in CSO spending priorities (second only behind endpoint management and encryption). 64% of respondents are expecting to increase spending in the area over the next 12 months.
The largest area of growth, Forrester predicts, will be in user account provisioning technologies, which will become a $7.9 billion market by 2014, or 64 percent of the entire IAM market.
The titans in user provisioning, vying for the Gartner Magic Quadrant leadership position, are Sun Microsystems, Oracle, IBM and Novell. Each of these vendors appears to be stock-piling weapons for the fight. Oracle and Sun each closed role mining acquisitions in recent months: Oracle bought Bridgestream and Bharosa, while Sun Microsystems bought Vaau and IBM focused on Single Sign On by scooping up Encentuate.
Beyond role mining and single sign on, (privileged) user activity monitoring and log management appear to be the next battle ground. When provisioning new users and granting new privileges, it is valuable to know how and when users are accessing company resources and applications. In many cases, regulatory frameworks are demanding that organizations know how privileges are used.
IBM took the first step by acquiring Consul Risk Management, which has some rudimentary log management and privileged user activity monitoring capabilities. ArcSight, a recent entrant into the log management market, is claiming some tie-in with the Oracle identity ecosystem in a recent press release. Novell and Sun Microsystems both collaborate with LogLogic.
To learn more, stay tuned for an upcoming LogLogic Webinar on the topic on July 31, 2008.
Posted June 25, 2008 in | Permalink | TrackBack (0)
« May 2008 | Main | July 2008 »
Logging Poll #8 Analysis: Essential Log Context
In my poll #8, I asked a question: what information is most important when analyzing a particular log record. Live results are here and final count is also below:
What can we conclude?
First, good documentation never hurts - indeed, the most popular information to look for when facing a new log record is documentation on what it means. While some software vendors are great in this regard, many other don't bother documenting their logs or document them only when customers complain.
Second, I was not sure that the second popular choice would be "Other logs from about the same time (this and other systems)." This strongly points at huge value of cross-device log analysis (see this recent log entry on that), where all the logs are consolidated and analyzed together (it goes without saying that time is synchronized OR at least corrected across those logs). Indeed, if you are confused about a log and documentation is not available, reviewing "what else was/is going on?" is smart. Trusting log time stamps across many systems is also key for that.
Third, having IP addresses in logs is great, but human-readable names are better: IPs in logs needs to be mapped to DNS or Netbios names. Indeed, given that often such names reveal where the system is, who might own it, what its function is, etc this information is not just a mapping, but true log information enrichment.
Fourth, so, what's next? The above 3 top responses are indeed universally useful, but the next choice digs deeper: flows, packets, connections and other network information does complement logs and is often studied in combination with logs (e.g. see a strange log entry then go see who connected to the system at that time or where the system itself connected to).
Fifth, next comes a group of pretty much everything else: other logs from the same system, logs about the same system as well as loosely defined 'similar' log entries. These come handy, but are not top choices. In fact, from this I conclude that people think that A LOT of additional context information is needed to make sense of a confusing log entry.
Sixth, what was surprising? I thought that identity lookups (e.g. IP to real name or other user identity information) would score higher. I also suspect that people were confused by "logs ABOUT the same systems" (what I meant is, for example, use firewall logs that mention the system which log we are now analyzing) and this should score higher.
Seventh, anything fun in the "Other" category? Yes, there were a few insightful ones: first, results of a Google search (such as for the info from the log entry in question)! Very true indeed. Also named were logs from the same daemon/program (how can I miss it?), logs from previous incidents and information on the logging system owner. All very useful indeed. Thanks for good ideas!
Next poll coming up soon!
Past logging polls and their analysis:
Posted June 09, 2008 in Innovation , Log Management & Intelligence | Permalink | TrackBack (0)
« May 2008 | Main | July 2008 »
A PCI-Data Security Standard for Cloud Computing?
What happens when sensitive data is processed and archived outside the enterprise, in the cloud, by non-employees, perhaps off-shore? Does it mean that the risk of compromising or securing this data goes up? Perhaps not, but the stakes are certainly higher. Imagine Salesforce.com hitting the front page of the Wall Street Journal because its employees have compromised or leaked customer data? That would hurt their business (understatement) even more than it would their clients. Perhaps the cloud computing industry should come up with a data protection standard like Visa and Mastercard did for the credit card industry? Some best practices every on demand vendor should consider when it comes to protecting customer data:
Privileged User Access
Companies should hold their outsourcer to the same high standards for internal control as they apply in-house. It starts with accountability – if you monitor the actions of privileged users they are less likely to transgress. And if they do, the outsourcer can take immediate action. It is no wonder that the credit card companies have made access to credit card holder data a cornerstone of their standard. Perhaps outsourcers should do the same when it comes to access to customer data?
Investigative Support
What happens when an employee leaves the company and you expect he may have downloaded some customer data onto his private laptop before you de-provisioned him from the on demand sales management system? Can you call your provider and ask for the audit trail that proves or disproves his (or her) transgression? It certainly is a fair question to ask of your outsourced provider and the answer may surprise you. Shared services can be difficult to investigate, because in some cases logging and data may be stored on shared servers.
Availability
Reliability and 24/7 uptime are cornerstones of outsourced services. Customers should demand service-level agreement guarantees and on demand providers should put in place scalable and repeatable models to ensure they meet these service-level agreements. The requirements for pro-active monitoring of performance bottlenecks and speedy recovery if availability is at stake are mission critical. Putting log data in the hands of front-line service desk employees can dramatically speed up this process.
Compliance
At the end of the day, customers should demand to know what risk mitigation their cloud providers is putting in place to protect data, support investigations and maintain service level agreements. It is no more than reasonable for customers to demand monthly reports that demonstrate control and accountability on the part of the service provider. Wouldn’t it be cool to see a report on who accessed your most critical data each month and to know that a service provider employee has reviewed this report on a daily basis? For cloud service providers executive reporting on security and availability risk mitigation could be an important differentiation.
Posted June 05, 2008 in | Permalink | TrackBack (0)
« May 2008 | Main | July 2008 »
Cross-Device-Type Log Management vs Device-Specific Log Management
Now, I have to first admit that, in general, dealing with logs on a device-specific basis is a utterly inefficient. What I mean here is when you gather Windows logs in one place, Linux logs in another place, database logs in yet another place; all in different formats, all in different systems not connected to each others, all managed by different people who don't talk to each other (and sometimes hate each other). Basically, this situation is "logs at their worst": all different, all disjointed and, as a result, all next to useless.
However, there are rare situations where you can choose device-specific log management approach without wasting time and money. For example, you might be motivated by the fact that tools that can handle one specific type of log data (e.g. Windows-only, web server-only or Cisco PIX-only) are usually many times less expensive than cross-device log management tools. The table below clarifies it:
| Use Case vs Approach | No log consolidation - logs remain on systems they are produced | Device-specific log consolidation and analysis | Cross-device log consolidation and analysis from all log sources |
| Alerting based on log strings (keywords) that indicate security or operational problems | Impossible or tremendously hard to manage across many systems | Acceptable - alerts on each log type are handled by different teams | Superior - all logs are available for analysis when the alert is triggered |
| Reviewing logs for troubleshooting server problems | Acceptable - server logs are sufficient for | Better - one can also look at logs from other similar servers | Better - but same as device-specific log analysis since only one type of logs needs to be reviewed |
| Log review for compliance with PCI DSS | Not acceptable - log management is mandated by Req 10 | Impossible or very inefficient - as many types of log data needs to be collected and reviewed | Optimal - all PCI relevant logs can be collected and reviewed in one system |
| Looking for records of a specific user activity | Impossible or tremendously hard since hundreds of systems might need to be searched | Inefficient - several different systems needs to be accessed to review all records of user's activities (and then data needs to be manually correlated) | Optimal - one query gives all traces of the user activity |
| Log review for incident response or forensics investigation | Impossible or tremendously hard since hundreds of systems might need to be searched for evidence | Inefficient - several different systems needs to be searches for evidence and then data manually correlated | Optimal - all log evidence can be found, reviewed and analyzed on one system, neither hundreds, nor several |
Also, while looking at logging tools, one needs to make a distinction between tools that can collect all sorts of logs but only allow you to analyze one log type at a time (e.g. sawmill) vs tools that can collect all sorts of logs AND allow you to analyze all of them together (e.g. LogLogic). The former tools still fall under "device-specific log management" despite their ability to gather hundreds of different log types.
The bottom line: in most cases, cross-device, uniform log management provides huge value, especially if your motivation for log management is compliance or incident response.
Posted June 02, 2008 in Innovation , Log Management & Intelligence , LogMatters | Permalink | TrackBack (0)
July 2008
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
Categories
Archives
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005