« September 2007 | Main | November 2007 »
Just What is Enterprise Class? Part V
Here is the final enlightening post from Dimitri McKay, our super-brilliant network and systems engineer from the East Coast, where he continues to discuss the meaning of the phrase "enterprise-class," which is certainly MUCH more than a marketing buzzword! Part I is here, Part II is here, Part III is here. Part IV is here.
Dimitri McKay says: "This is the final piece in the five part series entitled “Enterprise Class”. The term “Enterprise Class” for most of us has appeared on Bullshit-Bingo cards for years, but when we actually explore WHAT “Enterprise Class” is and how it pertains to a certain product, you can learn quite a bit about that product, and how it stands up to both the competition and how it stacks up against what it is and what it should be.
As of this writing, LogLogic has set free it’s next code-base, LogLogic4 Release 2. With added features and fixes, LogLogic fits the Enterprise all the more with each release.
13. Usability: Because of the large number of customers using LogLogic, the mission critical nature of the business problems being addressed, and the system complexity that is introduced due to the previous topics, usability is a critical factor for LogLogic. Our goal is to strike an appropriate balance between ease of use and complex functionality. Let’s face it. Using LogLogic to handle forensics, or compliance, or general reporting and alerting is an easy solution to a very complex problem. We are taking the chaos of a massive amount of log-traffic and we are taming it via the use of log forensics tools, summary reports, and real-time alerts.
When I was on the support team one of the biggest questions customers would call and ask after purchasing the LogLogic appliance was “Now what? What should I be looking for?” - and the answer LogLogic came up with was the compliance suites. The compliance suites are a phenomenal way of helping the customer hit the ground running. It’s simple. “Install this suite of search filters, alerts and custom reports. Then tailor it to your network. Now you’ve solved your compliance problems and/or government mandates.”
14. Compatibility/Maintainability: To minimize downtime as part of providing high availability, LogLogic must provide compatibility from one release to the next. Backward compatibility means that the when a new version of LogLogic is installed, it continues to work with the previously installed customizations and other systems witch which it interacts such as source devices and remote authentication services.
Forward compatibility means that when systems around the LogLogic are upgraded, the LogLogic must continue to function as it did before, even though the new software may support new log formats. When fixes are provided for LogLogic, downtime for installing the fix must be minimized by providing support for incremented updates such as patches and hot-fixes. LogLogic must also offer several solutions to handle updates such as automatic update via the web, or manual file updates due to the appliances being offline.
Thank you for reading my five piece foray into the Enterprise. Please feel free to email me your thoughts, comments, or post them below. Stay tuned to LogLogic as we journey where no other LMI vendor has gone before."
Posted October 31, 2007 in Innovation , Log Management & Intelligence , LogMatters | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
The Results are In
A few weeks ago we blogged about being named a Deloitte technology Fast 50 Rising Star. Last night, Deloitte announced the official rankings.
LogLogic came in at #9 with a 3 year revenue growth percentage of 1383% (the average revenue growth percentage of this year's Fast 50 Rising Star winners is 1885%). Check out the full rankings here.
We've been going strong this year and have no intention of slowing down anytime soon.
Posted October 31, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
TJX Update: The Drama Continues
It all began in July 2005, the first of many repeated security breaches occurring over 17 months that have reportedly affected more than 94 million separate accounts, according to a story from last Friday in Bank Info Security.
On October 23rd, new documents were filed in the Federal Court in Boston detailing that as many as 96 million customers may have been affected – 65 million VISA victims and 29 million MasterCard victims.
Bank plaintiffs are furious. Daniel J. Forte, president and CEO of the Massachusetts Bankers Association (MBA) noted (http://www.bankinfosecurity.com/articles.php?art_id=234&pg=1) earlier this year: “If we’re successful against TJX, the nation’s major retailers will finally wake up to the fact that not protecting consumer data is an unfair trade practice and that investment in data management systems to protect consumers and shield consumers against fraud and identity theft is required.”
According to The Boston Globe, "TJX already has reached a tentative settlement with attorneys representing consumers who were harmed by the breach, who would receive cash or merchandise vouchers, credit monitoring, and other benefits if the deal is finalized."
Industry analysts are now estimating the costs to TJX ranging from $500 million to $1 billion. How much does a log management solution cost?
Posted October 31, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Poll: Why Do You Collect Logs?
The previous poll (vote here, live results here, analysis here) proved to be a success so the next one is here.
This time the question is: "Assuming that you centrally COLLECT system, network or security logs from their originating sources, what is THE MAIN reason for doing it?"
UPDATE 11/11/2007: results and analysis are posted herePosted October 31, 2007 in Log Management & Intelligence , LogMatters | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Log Collection Poll Results
My poll on log collection have been a great success and now the results are in. Here is the link to the running totals as of now (the graphic snapshot from yesterday can be seen here). Let's review and discuss the findings after running it for slightly over a week.
- First, which of my expectations were NOT met? Well, I did expect that firewalls will be #1, not Linux/Unix servers. Admittedly, the difference is not so big, but I am impressed: Unix syslog still rocks the logging world :-)
- Second, the top source of collected logs is also the hardest to analyze due to its lack of structure. Nowadays I treat syslog from Unix/Linux as "broken English" and not as "data." It is a dog to parse (that is why we are trying to find something novel)
- Third, I was amazed that database logs were THAT high on the list. Wow! All the evangelizing seems to have worked out :-)
- Fourth, Windows server log collection is still in the dumps - but we need it! Go grab LASSO and dump those event logs into syslog without pesky agents. Easy!
- Firth, other Unix logs - what are those? We might never know what the respondents meant: still, I think that these are binary audit logs and other fine-grained audit logging. Indeed, many people starting to look at BSM audits and other "ugly ducklings" of logging.
- Sixth, web server logs are gold - everybody knows it. The poll confirms this as well: they are #2. Some fun analysis tips from me are coming soon.
Next poll coming soon! Thanks a lot for responding!
Possibly related posts:
-
Top 11 Reasons to Look at Your Logs
-
Top 11 Reasons to Collect and Preserve Computer Logs
- Database log management
Posted October 26, 2007 in Innovation , Log Management & Intelligence , LogMatters | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
When "Traitor" lurks in "Administrator"
Last week, Tim Wilson, site editor of Dark Reading (www.darkreading.com) , wrote an article (http://www.darkreading.com/document.asp?doc_id=136399&WT.svl=news2_3) about rogue sys-admins. Wilson not only offers examples of angry system administrators purposefully tampering with vital, private corporate information, but also warns, "there have been numerous studies that illustrate, in some detail, that even non-disgruntled IT administrators frequently abuse their access privileges to access unauthorized files, emails, and even personnel records."
Wilson makes a good point here, one that we can't stress enough to customers: monitor your log data for unusual activity and keep an eye on what information your users are accessing, when they are accessing it, and from where they are accessing it. Though every enterprise security infrastructure MUST protect against the external "bad guys," don't forget to guard against those ostensibly trustworthy inside the company that have easy access to sensitive information.
Posted October 24, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
LogLogic Named 2008 Info Security Product's Guide Global Product Excellence Awards Finalist
Thank you for your votes - LogLogic has been named a 2008 Info Security Product's Guide Global Product Excellence Awards Finalist in 4 categories: Excellence in Compliance Solution, Excellence in Event Management Solution, Excellence in Forensics Solution, and Excellence in Security Solution for Enterprise.
LogLogic was voted a finalist by more than 11,000 voters worldwide consisting of end-users, channel partners and readers of Info Security Products Guide. The winners in each category will be announced in January at the Technosium 2008 conference in Santa Clara.
We aim to bring attention to the importance of log management for enterprise security and compliance, so we couldn't be happier to receive this recognition from Info Security Product's Guide -- and we couldn't have done it without your votes. We appreciate you taking the time.
Posted October 18, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
SC Magazine Awards Reader Trust Award Voting Now Open!
LogLogic has been nominated as "Best Computer Forensics Solution" in the Reader Trust Award category of the SC Magazine Awards 2008 and we want your vote! Go to http://www.scawards.com before November 2nd and vote for your favorite log management and intelligence company and solution (Hint: that would be Loglogic and LogLogic 4 respectively).
LogLogic customers, channel partners, distributors, and VARs are all eligible to participate in the voting process. The SC Magazine Reader Trust Awards go to products that have won the most votes from people who know them well and use them every day, so YOU are our best resource for receiving this prestigious accolade. The finalists for the SC Magazine Awards will be announced in December. Please help us get to the Finalist Circle!
Posted October 18, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Poll: Which Logs Do You Collect?
I figured I'd do a poll a week since people really like it. So, my first poll-a-week: Which Logs Do You Collect?
Vote away! I will post and comment on results here after a few weeks.
Posted October 17, 2007 in Log Management & Intelligence , LogEd | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Simple Log-based User Profiling for Activity Monitoring
Recently I've been looking into detecting stolen/shared access account credentials. Now, how can you detect that? No NIDS will trigger, NIPS will let is pass, no unusual types of log records might ever by produced (especially if only limited logging is enabled). And what raises the stakes is that this type of activity is not only about "hacked" accounts, but also about insider abuse of accounts.
However, there will likely be changes in how normal log records are produced.
Let's summarize some known methods for using a simple user "profile" to detect account theft aka account sharing aka user impersonation aka access with stolen/shared credentials. It implies that we've been collecting the logs before the incident and have a solid trail of normal users and legitimate account owners.
- Unusual login source IP (e.g. normal user always comes from 10.0.X.Y or 10.1.X.Y, but now we see a login from 172.16.0.Z) - will work in some cases, but not for the free-for-all servers such as at a University
- Unusual login time (e.g. normal user always comes from 9AM to 5PM, now we see 3AM) - will work in most cases, but will fail if the attacker happens to be in the same time zone
- Unusual login session length (e.g. normal user always stays logged in for 5-20 minutes, now we see a 10 hour-long session) - works only if logout is logged; might not catch a lot of realistic but malicious connections
- Unusual login frequency (e.g. legitimate user logs in once a day in the morning, now we see dozens of connections) - will work for some cases, but others will be missed
- Unusual login failure/success ratio before a successful login (e.g. normal user always types the password right the first time, now we see failures than successes) - not too reliable, obviously
- Unusual list of user actions performed (normal user only reads these files, but now we see writes to a very different set of files) - will work most frequently, but needs more granular logging of file access, object changes, etc (audit logging) [more on this in the near future!]
So, if you have logs of user activities, at the very least, logins and logouts ( but having records of more user activities is always better!), for the last few weeks or months, one can compute the above profiles using historical data and then compare them with current numbers (very similar to some of the methods from my classic log mining presentation).
The final missing bit is for how long to collect your normal user behaviors: I discovered that 1 week to 1 month works pretty well. Less time yields unstable results and more time necessitates much more data crunching without much gain.
Posted October 12, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Just What is Enterprise Class? Part IV
Here is the next enlightening post from Dimitri McKay, our super-brilliant network and systems engineer from the East Coast, where he continues to discuss the meaning of the phrase "enterprise-class," which is certainly MUCH more than a marketing buzzword! Part I is here, Part II is here, Part III is here.
"10. Serviceability/Manageability: The scale of deployment of a LogLogic solution, whether it be managed remotely or locally, requires features which allow the solution to be managed effectively. FCAPS is an acronym which is often used to remember the following guidelines of security log appliance management:
Fault, Configuration, Accounting, Performance, and Security
The users of LogLogic must be able to monitor what is happening on the system itself, as well as the network around it and applications on it, and to have the ability to diagnose faults when they occur.
Fault diagnosis requires the ability to collect sufficient information about the fault when it occurs, preferably without having to reproduce the fault. We log our own appliance, and anything else on the network, and then alerts can be handled via SNMP traps sent to an SNMP trap receiver such as HP Open View or IBM Tivoli. The other option is an alert sent to a remote pager or mobile device, or even an email to the NOC/SOC personnel.
11. Customizability/Flexibility/Integrability: LogLogic is used to solve complex business problems on a large scale. For some it’s used for various compliance needs, such as PCI or SOX. To others, it’s an alerting or filtering tool, while forwarding a few of the log records on to a SEIM (typically, as much as it can handle, which is usually not as much as needed ...) or a specific other security tool. To others, LogLogic is used for general reporting, incident investigations or forensics. Regardless of how it’s used, LogLogic a different tool to different people.
LogLogic appliances are rarely rolled out as a single unit in an environment. Generally they are rolled out by location, by message per second (MPS) requirements... or by long term storage requirements, but any way you shake it, LogLogic architecture is designed to meet the needs of the Enterprise (and this is not to say that SMBs won't benefit from log management!).
Usually you’ll see several LX reporting/alerting appliances feeding back to a single long term storage ST appliance, but that’s not written in stone. Sometimes customers send all of their log data direct to the ST storage appliance (which handles a massive 75,000 messages per second) in order to take advantage of a single IP address destination. This, in my own humble opinion, is a good data center solution.
My point is, the architecture of the LogLogic appliances is a variable (but still easy!) which gives you total control. There is no firm “config” that is required for boxes to be placed in. Instead, the architecture is flexible, and allows for multiple configurations depending on the environment they reside in. This is the ability to remain agile.
Living in an enterprise world, we must adopt to new technologies as they become standards. Often some of the features on the LogLogic appliances overlap with other technologies already in use. Because of that, we have engaged the ability to utilize those technologies in those situations. One example is that LogLogic has but doesn’t always provide its own identity management functions. Typically there is another authentication management that the enterprise is already using, such as TACACS+ or RADIUS. The enterprise may have adopted particular standards to manage user databases and access control. For this LogLogic needs to be flexible in it’s architecture, allow customizability within the enterprise, and integrate well within the framework of the already existing environment.
12. Support: With any mission critical software deployment, the enterprise must have a reliable way of getting support for diagnosing problems and getting fixes and advanced replacements. This includes 24x7 availability for support personnel and an organization with the experience and expertise to understand how the appliances are used in enterprises. Our support is not only top-notch, but is also praised by our customers!
Thank you for tuning in to part lV of “Enterprise Class” where I’ve laid down WHAT enterprise-class really is, and how LogLogic has tackled it. I’d also like to thank our competitors who have been visiting my blog. You can imitate, but you’ll never duplicate us, boys!
Next piece will conclude the series ... stand by!"
Posted October 11, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
LogLogic 4 Release 2 Has Arrived!
Today, we are proud to announce LogLogic 4 Release 2, the newest version of our award-winning log management and intelligence platform.
This release includes more than 25 new features to help companies make the most of their log data for quicker, easier, and more effective security and compliance initiatives.
Among these features are extended log data warehouse capabilities, which now include fine-grain auditing capabilities that document all users activities including data accessing, changing or deleting information at rest. The LogLogic log data warehouse delivers a comprehensive approach to user activity monitoring through the use of log data that complements identity management operations. Where identity management is focused primarily on authentication and authorization, log data capture completes the puzzle of all users' activities after they have been authenticated by the system. By monitoring information level activities, companies can better protect information assets and complement IT Governance, Risk and Compliance initiatives.
It has been a busy time for us Loggies launching several new channel programs over the past few weeks, but we never tire in our devotion to bringing top-quality log management solutions to the market.
Posted October 08, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
PoS Logs out of PCI Scope? Surely You Are Joking...
... well, turns out they were dead serious. As I expressed my puzzlement to our resident PCI auditor, he explained that PoS logs and overall security of PoS devices are often "in-scope for PCI, but out of scope for a typical PCI audit." How bizarre is that? But let's start from the beginning.
First, what on Earth is a PoS? PoS, or Point-of-Sale terminal, is a machine that stores (or whoever else who takes credit cards) use to process credit card transactions: scan cards, communicate with verification server, print receipts, etc. It might be standalone or combined with a cash register. It might very very simple - just card reader + transaction unit in a single hardware unit - or as complex as a Windows PC with a cash drawer and no software updates (a scary thing indeed!)
So, in the latter case, there are certainly logs involved. In fact, there are also PoS-specific application logs, such as this example below, coming from an IBM SurePoS device:
--------------------------------------------------------------------------------------------------------------------------------
01/11 09:11 CC 5 W518 PROGRAM ADDDDDXUXDL HAS ENDED
B3/S111/E007 REASON=2 TYPE=3 RC=00000000
SOURCE: OCF
REASON: Application ended PROGRAM TYPE: Background
RC: No error
--------------------------------------------------------------------------------
PoS devices might be configured to store credit card numbers locally (for backup) and also to offload them to a "branch server" (a store server or both a store server and a regional server). Are there logs of who accessed them on the local PoS system? Unlikely. Are they looked at? Probably not. Maybe the logging is done better on the branch or store central server, but even this is not a certainty.
Overall, I am willing to bet a bottle of decent champagne that very few people, if anybody, in the whole world are regularly looking at PoS logs. At some happy point in the future, I predict they will start since the Beast of PCI will make them :-) When this happens, we will talk about PoS log analysis.
As of today, you would do comparatively well if you will collect and save them and thus will have a chance to review them for incident response for your next data theft case (or show them to an unusually nosey PCI auditor...)
More fun PoS security reading is here [PDF].
Posted October 05, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Just What is Enterprise Class? Part III
Here is the next enlightening post from Dimitri McKay, our brilliant network and systems engineer from the East Coast, where he continues to discuss the meaning of the phrase "enterprise-class," which is certainly MUCH more than a marketing buzzword! Part I is here, go read it first. Part II is here, go read it next.
"This is the third piece in the five part series titled “Enterprise Class”. Here we’ve gone through what IS enterprise class and how that corresponds to the LogLogic solution. Feel free to post your comments.
7.Performance: Performance is a broad topic. We’re not just talking local log collection performance, but also the ability to perform efficiently while in a distributed environment is critical to enterprise class hardware and software.
While the ability to add more LogLogic appliances allows more devices to be logged and application data to be collected, if the software does not perform with a high level of efficiency, the cost to deploy a system for the required number of devices will be prohibitive.
LogLogic’s top end reporting appliances handle 4000 messages per second sustained. That is a HUGE amount of traffic. if you’ve ever had to sift through it, you’d agree. Think about it. That’s 240,000 messages per minute. 14.4 million messages per hour. That’s 345.6 million messages per day. Grep that with your syslog server. Parse that with your SIEM. It’s not going to happen (not without an ENORMOUS price tag). And our log collection appliance do even more, way more: 75,000 messages per second sustained. Wow!
Performance on a LogLogic appliance is measured based on several factors: CPU usage, messages per second, and disk usage which are important not only for the main functions of the system such as receiving and parsing logs, but also for the ability to run reports and searches on those messages.
8.Security: Because LogLogic is used for mission critical functions, security is essential. LogLogic must ensure that users who are authenticated to the appliances only have access to the functions they need and access to the log sources that are determined by their job role. LogLogic must also offer the ability to encrypt data as it moves between appliances (which we do via LogLogic TCP) and to also offer the ability to use WORM or data at rest encryption (which is handled by the EMC Centera or NetApp for WORM and Decru for data" at-rest" encryption).
LogLogic also covers security with the ability to verify that the system is secure through audit trails, general protection of the appliance through a secure linux kernel locked down in the default install, perform self logging, and then hashing the raw logs which are kept in an immutable format. At LogLogic we take security serious, and the box is put through a variety of vulnerability assessments on a regular basis.
9.Documentation: Because LogLogic handles device support through a specialized group of folks we call “LogLabs” we are able to add devices at an expeditious rate. With each of those new devices comes the required measures to configure each of those devices for logging, and with that knowledge transfer that to documentation. Over time our Documentation Group has continued to grow. Knowledge management is essential to managing the enterprise class solution while alleviating the strain on any of the support or field engineering staff.
Check back soon, to see more about how LogLogic does Enterprise right. In the next episode I will run off on a tangent about usability and flexibility/interoperability/customizability and support! We are boldly going where no other LMI vendor has gone before!"
Posted October 04, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
LogLogic Announces MSP Partner Program
We officially announced our Managed Services Provider (MSP) Partner Program today (link to http://www.loglogic.com/news/news-releases/2007/10/loglogic-announces-msp-partner-program/). Again, compliance is the main driver in the program's early success, which already counts VeriSign, BT Counterpane, CynergisTek, and NetBoundary as partners.
Here's why the MSP market is ripe for log services. With the increasing need to meet corporate mandates and best-practices frameworks, which both require collection, archival, and analysis of logs, organizations are increasingly turning to managed services to alleviate the complexity of log management. At the same time, compliance and operational demands are requiring MSPs to offer managed services beyond security devices to servers, network devices, and applications -- and log services from LogLogic enable the MSP's customers to make better operational and financial decisions by using log data to provide a holistic view of system and user activity, policies and business impacts.
For more information on the LogLogic MSP Partner Program, visit http://www.loglogic.com/partners/mssp-partners/.
Posted October 03, 2007 in | Permalink | TrackBack (0)
« September 2007 | Main | November 2007 »
Breaches Rise - PCI DSS Enforcement Lags
The Computing Technology Industry Association (CompTIA) recently commissioned a survey of IT organizations regarding the severity of security breaches within their IT environments. Given all the publicity surrounding compromised systems over the past year, the results are hardly surprising - the severity level is on the rise. Timothy Prickett Morgan of IT Jungle provides a good survey synopsis here ( http://www.itjungle.com/tlb/tlb092507-story08.html).
Here's a stat that should grab your attention -- Across all companies, the average cost of dealing with a security breach was $369,388, with a number of large companies with breaches that cost more than $10 million each thus skewing the average. That's a hefty price stemming from various kinds of malware and human mistakes.
Now that the Payment Card Industry Data Security Standard (PCI DSS) deadline has passed (see story here - http://www.scmagazineus.com/Visa-PCI-deadline-looms-for-tier-one-merchants/article/35880/) and a significant amount of large companies still haven't completed PCI compliance work, you can expect a fair amount of finger pointing in the near future as organizations fail external audits.
LogLogic's Anton Chuvakin posed some great questions sure to fan the coming PCI DSS blame game flame ...
1) Who is ultimately responsible for data loss: merchants, banks, customers or ...?
2) Is Visa/MC PCI DSS too onerous, not enough or just "common sense" security?
No simple answers are expected, unfortunately. Penny (or perhaps $10 milion dollars in PCI fines?) for your thoughts?
Posted October 03, 2007 in Compliance | Permalink | TrackBack (0)
November 2007
| 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 |
Categories
Archives
- 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