LogBlog

« March 2007 | Main | May 2007 »

Hit a Home Run with Log Management and Intelligence at Wrigley Field

Log off and head to the ballpark and log on to Log Management and Intelligence!

When: May 10th 11am Wrigley Field
11am-1pm Seminar; 1:20pm Rooftop Cubs Baseball game
What: Hit a Home Run with Log Management and Intelligence at Wrigley Field
How: RSVP

Do you Log your data? Join LogLogic to discuss your batting average against PCI Compliance. We'll even talk about SOX if you want (even if they do play in that other stadium). Trade info with our product team on how logging can improve the way Enterprise IT runs. Mingle with our customers to learn how they are winning the IT game with log management and intelligence. Then its off to the ballgame.

Come celebrate new LogLogic 4, the World's Most Powerful Platform for Log Data Warehousing & Intelligence. LogLogic's LX platform hits a double in functionality compared to the competition this season and steals home as the most fully featured log management appliance in a league of its own. The LogLogic ST extends its lead this season as the top rated log data archival and search platform. We even play nice with SIEM!

Log Management and Intelligence makes IT able to give business a way to make sense of data from across an enterprise -- all platforms, applications and network devices -- automatically collecting, storing, reporting and alerting to meet compliance regulations and help with risk mitigation. Space is limited, so reserve your spot today. (And don't forget the sunscreen!)

Technorati : , , ,

Posted April 27, 2007 in Log Management & Intelligence | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

The beef over the security of government data

Today Information Week reported that the recent U.S. Department of Agriculture security breach not only puts highlights the risk for identity theft , but could lead to less participation in federal programs.

The online database compromised the security of personal identifying information -- the names and SSN's of about 150,000 people who receive USDA funding from the Farm Services Agency and the USDA Rural Development agency.

USDA is Ohio Congressman Zack Space said:

"This is a pattern of security breaches in government agencies that is becoming all too familiar. But even with this familiarity, it's inexcusable in every instance," Space said in a written statement. "Congress has a responsibility to make sure that the agency is doing everything possible to rectify the situation, make sure that it doesn't happen again, and make sure that victims are notified and compensated."
Just last week it was also disclosed that US citizen data was compromised when a former federal employee of the Social Security Administration illegally disclosed personal information stolen from a government computer as part of an identity theft scheme.

The U.S. House Agriculture Committee will hold a hearing about this situation on Wednesday, May 2. While it is reported to be a smaller incident than initially reported, it is also known that grants data with the personal information had been posted on a government Web site since 1996.


Technorati : , , ,

Posted April 27, 2007 in Risk Management , Security | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Tune Into The LogLogic 4 Podcast

We revealed LogLogic 4 -- the most advanced log management and intelligence platform on the planet -- just a week ago today. Watch for us to highlight all the new features here on the blog, but today you can take the news on the road in our new podcast on the release. LogLogic's own product guru, Michelle Cobb dishes on the LogLogic here as an MP3 file.

Technorati : ,

Posted April 23, 2007 in Log Management & Intelligence | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Logging The Threat From Within

Last week, Information Week reported that a former Social Security Administration employee illegally disclosed personal information stolen from a government computer to aid in an identity theft scheme. This employee was paid to look up identifying information about various people using access levels that were consistent with her employment.

In this case, is it unlikely that alarm bells would have gone off when the information was initially obtained, since the employee wasn't hacking into a system-- she already had approved access to all of the information she needed. However, as the case builds against her, the logs of her system activity could become crucial pieces of evidence.

There are logs for everything the SSA employee did on that system -- legal or illegal. It is important to remember that the benefits of being able to record, report on, and manage your log data do not stop at attack prevention. In a case, like this one, where the breach can not be prevented, information is exposed, and action must be taken retroactively, having easily accessible, immutable log data to act as a continuous fingerprint of system activity is crucial to ensuring that the attacker is held accountable for her actions.


Technorati : , , ,

Posted April 20, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

A New Logging Standard Effort Started: Common Event Expression (CEE)

After long months of undercover work by a small team, CEE effort is ready to be open for broader involvement. Just what is CEE?  Below is an excerpt from a brochure, to be published at MITRE's site soon. I do think that the world is ready for another battle for the establishment of a logging standard, after a long string of miserable failures (see IDMEF, etc).  

"Common Event Expression (CEE™): A standard log language for event interoperability in electronic systems.

CEE standardizes the way computer events are described, logged, and exchanged. By utilizing a common language and syntax, CEE takes the guesswork out of even the most menial of event- or log-related tasks. Tasks including log correlation and aggregation, enterprise-wide log management, auditing, and incident handling which once required expensive, specialized analysts or equipment can now be performed more efficiently and produce better results.

Why CEE?

If multiple systems observe the same occurrence, it should be expected that their description of that event is identical. When combined with relevant event details (time, source, destination), a computer should be able to immediately determine whether two or more logs, data logs, audit logs, alerts, alarms, or audit trails refer to the same event. In order to make this happen, there needs to be a scalable, well-defined way to express events."

We will post more details when they are ready for a public release. For now, watch an ongoing discussion about the upcoming CEE standard on the loganalysis mailing list. The thing to remember is that the standard effort is just starting up and broader industry involvement will be required. Given MITRE track record with standards such as CVE, OVAL and others, this effort has a good chance of becoming real.

Technorati tags: chuvakin, CEE, log management, logging standards

Posted April 20, 2007 in | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Log Management Time

Matt Stansberry asks if it is time for log management over at TechTarget's 'Server Specs: the data center blog.' He points to managing log files as a trend in IT.

Says Stansberry ....

It seems data center managers are more attuned today to overall systems management than they ever have been. At the recent AFCOM Data Center World conference in Las Vegas I attended last month, it seemed to be a more popular track than in past years. Facing audits with piles of papers and Microsoft Excel spreadsheets just isn't cutting it anymore.

That is what our customers are saying as they fire up log management and intelligence.

Technorati : , , , , ,

Posted April 18, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Introducing LogLogic 4 - The most advanced log management platform on the planet

Today is a very exciting day for us. The most advanced log management and intelligence platform on the planet is here.

LogLogic 4 has arrived......You can order it today.

We are excited to launch a product that contains so many new innovations --- with great kudos to our engineering, our QA, our marketing, our entire company (and many of you unnamed customers who helped us in beta testing over the past several months!) to come up with an open, flexible log management and intelligence platform that not only provides insight into IT operations for deep forensics, but also equally performs reporting for rapid compliance regulations -- and does both equally well.

Breaking down log barriers

LogLogic's Log Data Warehouse breaks down silos of log data from across the enterprise. New LogLogic 4 replaces log silos with a secure, distributed, efficient platform, centrally storing log data and streamlining access to and reporting on key information needed to demonstrate compliance, answer legal inquiries or investigate security and/or performance incidents.

On top of that we introduce new aggregated search across multiple LogLogic ST systems to reduce the time and resources needed for forensic analysis.

LogLogic 4 has over 30 new major features, performance improvements and innovations. The the top new features are .....(Drumroll please) ....

New Multi-dimensional Analytics -- a log management first -- mashes "Google-like" search with reporting on indexed data and rapid drill-down capabilities through simple "drag-and-drop" menus. Other solutions only use a single dimensional search. We are the first product to deliver both parsing (multi-dimensional searching, categorization and reporting) as well as indexing (one-dimensional search and reporting) in a single platform. It is kind of like looking at data from the side, the top and every other angle at once.

Our Services Oriented Architecture (SOA) and open API lets users develop their own log analysis applications - or easily integrate log data with existing SIEM deployments, operations consoles and management dashboards, strategically extending LogLogic's platform completely across the Enterprise.

New LogLogic Quad-Processing technology lets users run queries and reports in seconds instead of the hours competitive solutions need to continually reprocess data. This is where speed comes in. The key to log management and intelligence is in the architecture and how you deliver the information, and with LogLogic 4 we do it faster.

With LogLogic's Open Log Services platform, our users can create web portals and custom dashboards to track compliance, risk mitigation and forensic activities and to automate various compliance and business processes. With an open SOAP/XML architecture, we integrate with a wide variety of networking and security devices, as well as legacy applications and systems. This lets us play nice with SIM/SIEM from other vendors.

LogLogic's Agile Reporting sets the bar for what happens after search, allowing IT environments to respond quickly to shifts in the business and changes in reporting. LogLogic lets IT create more than 15,000 highly customized reports from 24 easy-to-use templates, as well as reports for SOX, HIPAA, PCI, GLBA, FISMA as well as COBIT 4.0, ITIL and ISO 17799 frameworks, within seconds and requiring no vendor intervention or costly professional services.

New Universal Log Processing extends reporting, search and alerting capabilities to log data and audit trails from any source - including homegrown and business applications - without requiring any custom development. Introducing this "industry first," LogLogic delivers out-of-the-box analysis on all logs - with no scripting, customization, or waiting for a new device type to be supported, finally putting an end to the 'supported device' race that has plagued the SIEM industry for years.

We hold more data. LogLogic 4 ST systems offer over double the storage capacity now. Two times more than before. Oh, and if you already have a storage system in house that you like? We play nice with it. (Really!) Say you are doing compliance using WORM-based storage for immutability. We support that too - plus we are certified to work with all the top products from the major vendors like NetApp Snaplock, EMC Centera, and Nexsan Assureon.

Do you TiVO? Or Sky in the UK? With new LogLogic 4 we introduce Log Replay. This lets you take log data from a year ago and mix it up with log data from today, and report on all the data in one single report. Isn't that cool? Can you say predictive analysis!

We're green. LogLogic 4 runs faster (over 75k messages per second), but with over a third less power -- which is a really big deal in the datacenter owing to power costs and global warming.

Check out LogLogic 4, the most advanced log management platform on the planet.


Technorati : , , , , , ,

Posted April 16, 2007 in Log Management & Intelligence , LogLogic News | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Computing Monocultures and PCI Compliance

A few years ago, the CTO of my former company (Dan Geer, @stake) was fired over a paper he co-authored on the Microsoft monoculture and its potentially disastrous consequences. The topic of computing monocultures in relation to security has cooled down a bit, but I think it's worthy to revisit the issue in light of today's increasingly regulated and compliance-driven IT environments.

To briefly summarize the debate, Dan's side of the argument (against monocultures) asserts that corporations and governments should diversify their computing environments to better ensure survivability in the event of widespread failures in common operating systems and applications. On the other side, supporters of monocultures tout the positive aspects of running a common computing environment, including economies of scale, enhanced supportability, and vendor leverage with pricing and licensing.

I see the merits of each side and tend to be pragmatic about platform and application selection, advocating solutions that work best for the given problem, with additional decision inputs around security, supportability and vendor relationships being considered based on organization-specific criteria and risk management approach .

When specifically considering Payment Card Industry (PCI) compliance and environments that process payment card data, however, the cost savings and efficiencies traditionally associated with computing monocultures become even more compelling. There are a number of specific requirements in the PCI Data Security Standard that are more costly to comply with as the diversity of the environment increases. Thus, there is a direct correlation between platform and application diversity and the cost and effort associated with achieving and maintaining compliance with the PCI Data Security Standard.

Consider PCI requirement 2.2, which requires secure configuration standards for all system components in the cardholder environment. This means that for every type of router, firewall, network device, operating system, etc. in your PCI-relevant environment (i.e. the environment where cardholder data is transmitted, processed, or stored), you need to develop, document, maintain, and implement system-specific configuration standards.

Back when I was performing PCI audits, I would validate this control by:


• Reviewing the specific configuration standards
• Reviewing the model and mechanism used to implement these standards (e.g. install scripts, gold disks, JumpStart or KickStart configurations, router configuration templates)
• Reviewing the actual configuration on the deployed system to ensure that the standards had been implemented, not just documented

The audit cost for assessing PCI requirement 2.2 goes up with each additional platform supported, and you can also see how the costs associated with creating, managing, and applying these standards increase as the environment becomes more diverse.

This cost to diversity relationship exists in many other PCI requirements - clear examples include:


Requirement 6.1 - Requires that all in-scope components have the most recent security patches installed (within one month of release). More platforms to patch will often mean more patches to test, more change management requests to submit, more tools needed to apply the patches . . .
Requirement 6.2 - Requires a process for monitoring vulnerabilities and security issues related to in-scope components. Also requires that configuration standards be updated as needed based on this new information.
Requirements 11.2 and 11.3 - Require regular vulnerability scanning (quarterly and after significant changes) and penetration testing (annually and after significant changes). Having performed these services for a number of years as a security consultant, I can validate that the price associated with either of these endeavors increases as the number of platforms evaluated rises.

Of course, this doesn't mean I'm advising you to scrap your current credit card processing environment and standardize on a single vendor's solution. Retail and e-commerce card systems and applications are complex beasts and it is difficult or impossible to find a single platform to run all of the systems required (e.g. credit switches, point of sale, fraud monitoring and loss prevention, sales audit, loyalty and affinity marketing, etc.).

Instead, make sure you understand the effect that platform diversity has on the effort and cost that it takes to manage and maintain PCI compliance. Some questions to consider in this arena include:

• Have you done everything possible to limit the scope of PCI compliance (e.g. using network segmentation, limiting systems and applications that process in-scope data, outsourcing card processing functions as necessary)?
• Do you have the expertise to appropriately manage and secure the platforms and applications required?
• Do you have the tools needed to maintain these diverse platforms in a PCI-compliant manner (e.g. patch management systems, log management tools, file integrity monitoring software)?

In the end, maintenance costs (including those that are PCI-specific) should be an input to any important technology decision. Ensuring that these 'cost of complexity' considerations are included as a standard component of risk evaluation and decision making will help provide some basis of assessing the resource needs associated with managing PCI compliance for your chosen technologies.

Posted April 09, 2007 in Compliance | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Survey Says: Log Management

LogLogic has teamed up with the SANS Institute to conduct an independent Research Study on the emerging need for log management and intelligence in the enterprise. Last year's study was pivotal in uncovering the logjam enterprises face estimating that up to 25% of all data generated in teh enterprise is log data.

Andrew Davies of the University of California at San Diego confirms this trend, "Rapid evolution of our entire enterprise IT infrastructure has resulted in exponential growth of data. This is requiring a reassessment and automation of log auditing methods."


In appreciation for your help, your name will be entered into a drawing to receive a Nintendo Wii being given to survey participants. The survey will close after the first 600 participants have completed the questionnaire.

The survey will take only ten minutes of your time and your email address will only be used to notify you if you have won the Wii.

Your valuable input will help us understand how to improve log management and intelligence to support your IT and business needs for everything from forensics to compliance.

SANS will keep individual information confidential and treat data collected from you in accordance with Market Research Association (MRA) Code of Ethics.


Technorati : , , , ,

Posted April 09, 2007 in Innovation , LogLogic News | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Do you log for auditing or forensics? The answer is yes.

At ComputerWorld Michael Farnum makes the case for log management no matter how large - or small - your enterprise may be....

Having all the information in the world does you no good if the user has no idea how to retieve it. And the security admins of the world love to have configurable dashboards that they can give to their boss (and the auditors I spoke of above) so they get fewer questions about what is going on in the network.

Farnum hits on the key comment we hear from our customers as they list their criteria for selecting log management. We frequently hear they need to be able to not only collect logs completely, but being able to report well as equally important requirements for IT. At LogLogic we solve this choice by delivering both -- instead of offering a point product we provide the only log management platform.

Farnum, too, asks the right questons about what log management can be - event correlation, forensics, or audit / compliance widget - concluding that it is all of these and more! Great article worth a long look if you have an auditor looking over your shoulder right now..

Welcome to the LMI market.


Technorati : , , , , ,

Posted April 08, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

« March 2007 | Main | May 2007 »

Anton's Top 11 Reasons to Collect and Preserve Computer Logs

I've been wanting to create those for a long time and finally here they are; some are admittedly tongue-in-cheek, but useful nonetheless. So, enjoy Anton's "Top 11 Reasons to Collect and Preserve Computer Logs", presented in no particular order:

  1. Before anything else, do you deal with credit cards? Patient info? Are you a government organization under FISMA? A financial company? You have to keep'em - stop reading further.
  2. What if there is a law or a regulation that requires you to retain logs - and you don't know about it yet? Does the world "compliance" ring a bell?
  3. An auditor comes and asks for logs. Do you want to respond "Eh, what do you mean?"?
  4. A system starts crashing and keeps doing so. Where is the answer? Oops, it was in the logs - you just didn't retain them ...
  5. Somebody posts a piece of your future quarterly report online. You are "pretty sure" John Smith did it. But did he? How? If not him, who did? Let's see who touched this document, got logs?
  6. A malicious software is rampant on your network. Where it came from? Who spreads it? Just check the logs - but only if you have them saved.
  7. Your boss comes and says 'I emailed you this and you ignored it!!' - 'No, you didn't!!!' Who is right? Only email logs can tell!
  8. Network is slow; somebody is hogging the bandwidth. Let's figure it out! Is your firewall logging? Keep the logs at least until you can investigate.
  9. Somebody added a table to your database. Maybe he did something else too - no change control forms were filed. Got database log management? How else would you know?
  10. Disk space is cheap; tape is cheaper still. Save a log! Got SAN or NAS? Save a few of them!
  11. If you plan to throw away a log record, think - are you 100% sure you won't need it, ever? Exactly! :-) Keep it.

Have more? Feel free to suggest your own reasons to collect and retain logs here!

Coming soon: "Top 11 Reasons to Look at Your Logs"

Technorati tags: , , ,

Posted April 02, 2007 in | Permalink | Comments (0)

Visit loglogic.com

I ♥ Logs

Subscribe to this blog’s feed RSS

January 2010
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
Blogroll
Blogroll
Compliance
Good Reading
LogLogic
LogLogic Partners
Sites We Watch