The LogLogic Story – Chapter 9

Use

The ‘use’ section of our technology is actually lots of products that all feed off the central warehouse. We have a S.E.M. solution that we refer to as a SOC-in-a-box, which is probably the most accurate correlation engine available. We have compliance technology that takes your assets and people and matches them against directives, and then enforces your processes. We have a forensic workflow solution that is indisputably the most efficient in the business. We have a special data-aware console called Database Security Manager that gives you SOC-type security over your databases. And of course, everything we do is extensible with open APIs.

The point I’m trying to make here is that we give you the ability to do the alerting, searching and reporting that you need, whether it’s for compliance, security or IT operations - all of it enriched from our central warehouse in ways that others can’t match.

Posted by Andy Morris on September 02, 2010 in LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 8

See

Our ‘see’ is simply the biggest, fastest, most scalable and complete IT data warehouse available today. We have one customer that currently gives us 53 BILLION logs per day. Twitter (not a customer), we estimate, produces 127,000 log messages per second. Our biggest box peaks at 250,000. This level of scalability means that if you’re considering building a large datacenter, we’re the only people you should talk to.

But we’re more than just scalable. Our warehouse specializes in structuring unstructured data. We take the data from our Universal Collection Framework and automatically identify it – no more tedious manual configuration the way you do with other vendors. We then feed that IT data into our taxonomy where we add the insight. We take information from asset databases, from active directories (LDAP) and use it, along with our deep knowledge of events, to turn error code 14 on device w3q into “Andy (West Sales) failed to gain external access to main CRM system.”

This insight comes from our unique patent pending taxonomy. But we don’t know everything. You may have a device we’ve never heard off, an application you built yourself, or something that’s so old it’s unique to your environment. Using our Log Labels technology you can, using a simple drag and drop GUI, teach our taxonomy about your uniqueness. And of course, we do this in an enterprise-class fashion. You define data just once, it gets added to a central library of terms, and is automatically pushed to all your appliances. The next version of this will enable you to share your work with the greater community, meaning as an industry, we can finally tackle the long tail of IT data sources.

To be a good corporate citizen, we of course have to play nicely with others. And so we have an open storage system that scales using our own disks, or plays nicely with your corporate SAN’s and NAS’s. It also uses a unique open forwarding technology so we can share our enriched view of the world with any vendor you wish.

And again, we have open APIs, so we’re extensible should we not entirely meet your needs.

Posted by Andy Morris on September 01, 2010 in LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 7

Get

Let’s look at ‘get, see, use’ in a little more detail.

Our “get” is actually technology called the Universal Collection Framework.

This framework provides universal IT data collection capable of collecting, without agents, from just about anywhere. Where we do need agents for those hard to reach places, like HP Integrity NonStop (tandem) machines, or exotic devices, we have them. We also provide specialized technology for capturing database activity without the need for you to turn on costly auditing. All of this technology is vertically scalable to suit data centers of any size. It is also the world’s only WAN-aware store-and-forward technology capable of adapting to time-zones, being scheduled, compensating for unstable pipes, and protecting your data from unauthorized viewers.

The technology that makes all of this work is a brand new protocol we’ve invented called the Universal Lossless Data Protocol – which we intend to open-source next year.

Of course, we also publish open APIs so that you can add to this framework if you wish.

Posted by Andy Morris on August 31, 2010 in LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 6

The Flexibility Wheel

This ‘get, see, use’ is what we refer to as ‘360 Insight.’

Put simply, it means that we don’t care where your data is, or what format it’s in; we can get it and give you 360 degrees of sight into all your IT data.

We don’t care why you’re capturing all that data. Whether it’s compliance, security, or IT-ops, we give you 360 degrees of sight into all your business drivers.

We don’t care who you are. Whether you’re looking for insight because you’re HR, an auditor/assessor, a partner, or that guy in IT - we give you insight.

‘We don’t care’ is harsh. ‘We’re neutral’ lacks the passion behind our focus. What I’m trying to say is that we’re doing all the hard work to understand all of your data, for whatever driver motivates you, while respecting your role within your organization.

We do the work, so that you (or a team of consultants) don’t have to.

Posted by Andy Morris on August 30, 2010 in LogEd | Permalink | Comments (0)

Understanding and Selecting SIEM/Log Management

There’s an analyst firm you may not have heard of called Securosis. Every member of the firm is a rock-star from one of the major players that got fed up constantly having to guard their words and toe a corporate line. These guys speak it like they see it, and it often isn’t pretty. I butted heads with them my first day at LogLogic and lost. I like them for that.

Anyway, they’ve just written a “what the heck is SIEM” paper. Whilst I disagree with their definition of what SIM and SEM are (my definition is here), the paper is well worth your time. It’s long – 40 pages, but there’s something new for everyone in there.

I highly recommend you make the time (even if it is sponsored by a competitor).

Posted by Andy Morris on August 27, 2010 in LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 5

The difference is clear

Our approach is different. Firstly, there’s no spaghetti! Ours is a simple world where all data, regardless of source or type, is centralized, augmented, enriched, parsed and understood, then smartly passed onto the appropriate visualization tools. We aim to create a virtual information pool that enables you to see 360 degrees of your operation; to provide you insight into the workings of your infrastructure.

Over on the left we have what we’re calling ‘Get.’ This is our Universal Collection Framework technology – our unique ability to capture audit trail information from almost any device, in almost any format and then securely and wisely move it to a central store, regardless of LAN or WAN complications.

In the center we have ‘See.’ This is our uniquely, massively scalable IT Data Warehouse, currently represented by our ST range of appliances. If you think of Google for a second you’ll understand why we call this ‘see.’ You know there are a million places on the web to book a flight. But rather than reach into the net and try each site directly, if you ask Google, it will do the search for you. It will display results directly. It will order them in terms of popularity and augment your view of those travel companies, giving you greater insight than you would have gotten if you’d visited all the sites directly yourself. Google enables you to see the raw information in a new way. That’s what we do. We enable you to see your IT data in new and insightful ways.

Over on the right we have the ‘Use’ column. Here we list all the visualization tools you may need. Some we make, others we expect you to source elsewhere. Regardless, they are all able to reach into the warehouse, without all the spaghetti, and be fed enriched, consistent information.

‘Get, See, Use.’ A simple solution to a very complex problem. We provide visibility, control, and improve security without adding all the complexity that others rely upon. There’s also an openness implied in this diagram. We offer an expansible framework, so if our ‘get’ doesn’t meet your exact needs, you can add something else. If our ‘see’ isn’t quite what you need, you can extend it. And if our ‘use’ is not a perfect match, you can use someone else’s.

When you go with our solutions you’ll also find that we pride ourselves in building technology that is simple to use and easy to deploy.

Posted by Andy Morris on August 27, 2010 in LogEd | Permalink | Comments (0)

Products of the week

Hmmm, products of the week? Us? Again? Wow, people love the 5

thank you

Posted by Andy Morris on August 26, 2010 in LogEd , LogLogic News | Permalink | Comments (0)

The LogLogic Story – Chapter 4

Adding Complexity

And that brings us to what I’ll call 1st generation solutions to your problem.

On the left of the slide you’ll see what I call “data assets.” These are your routers, firewalls, switches, servers, operating systems, databases, commercial and homegrown applications and pretty much anything with a plug. It’s a fact of life that almost all of the technology we use creates an audit trail. Some of those trails are called logs, others flow, sometimes they’re just file dumps. The point is, everything we do within the connected world leaves a trail.

Over on the right of the slide are the consumers of those trails. These are the analytics engines - the panes-of-glass from the previous slide. Hopefully, from the tangled spaghetti of colored lines you can see the problem here. We have one customer that has deployed 4 S.E.M. products from several vendors in their SOC. They also have other solutions, such as network monitoring tools. What this means to them is that they have servers with 4 agents on them – all doing the same thing! They get alerts that some S.E.M.’s corroborate, and others totally miss. They have no consistency, they can’t confirm that all the right information is getting to all the right places. And to make matters worse, they’re fearful of upgrading or switching out some of these solutions because the tendrils reach too deeply into the organization and no one knows quite how it’s all wired together.

What started off with the best intentions of adding clarity to a complex network of devices has simply made things worse. An alarm you can’t verify and trust is worse than useless – it becomes the car alarm that goes off in the middle of the night that everybody ignores.

Posted by Andy Morris on August 26, 2010 in LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 3

The Standard Answer

The good news for you is that, as an industry, we’ve recognized your needs and even given them a name – S.I.E.M. or Security Information and Event Management.

S.I.E.M. is made up of two separate technologies - the first and most important is S.I.M., Security Information Management. This is the foundational work of collecting all tracking data - be it Logs, Flow, Assets, Users or Files - consolidating it, and then turning it into useful data. It is the S.I.M. technology that allows for the forensic searching and reporting we just discussed. It is this that you use for good IT management or compliance. We can even use it for simple alerting, such as someone failing to authenticate against a database.

The S.E.M. on the other hand is often referred to as the pane-of-glass or the analytics engine that consumes the collected data and presents it in a way that is meaningful to your needs; whether that’s event management for a SOC, or trending for capacity planning, or SLA management. Some of these visualization tools even provide dashboards that reflect your compliance posture.

The important part of S.I.E.M. is that for it to truly work efficiently and effectively, the pane-of-glass needs to be presented with ALL of the available data and not just a subset.

Posted by Andy Morris on August 24, 2010 in LogEd | Permalink | Comments (0)

Open Standards: Not everyone gets it

By Bill Roth, CMO

In a recent article, our competitor LogRhythm commented on our technology plans which indicated either they don’t understand what we’re doing, or that they think what we’re trying to do will threaten the status quo - and their business.

LogRhythm’s VP of Marketing said the following:

“The idea of a standardized protocol for transporting and storing log data sounds good in theory, but it’s unrealistic given the hundreds of different types of log sources and vendors. A standard like this does more to benefit the vendor than it does the end customer, from both a technological and marketing standpoint," he added. "Standardization would make it easier for the log management or SIEM vendor, but the positive impact on the end customer is hard to see given the widespread collection and transportation capabilities that exist today."

We think the exact opposite.

The Security Information and Event Management SIEM industry needs more standardization not less. As markets mature, they all tend towards open standards. Open standards ensure that customers are free from being locked in to any one vendor, or any one proprietary technology. Additionally, standards provide a way for the consumers to provide input to the technology that they actually use. Standards also make sure there is a level playing field so no one vendor can dominate an industry. The open competition that standards encourage is good. They ensure that the consumers get the technology that they want at a reasonable price.

Consider the work done on CORBA standardization in the early ‘90s, and the standardization that continues to happen with the Java Platform. The Java Platform is an object lesson. Companies like IBM and Oracle were initially opposed to the standardization of Java on the server, in the form of J2EE, because they had large investments in their proprietary application server product lines. But as customers started clamoring for the kind of openness that standardization brings, both IBM and Oracle became licensees of the technology, as did nearly 50 other companies who signed on as licensees of the technology.

As Mark Twain said, “History doesn’t repeat itself, but it does rhyme.” Our path for the ULDP will not be an exact match to the J2EE experience. But we will take an open, community-based approach to developing our standard.

If only the rest of the industry would do the same.

LogRhythm and other competitors obviously benefit from having proprietary technology that essentially locks in their customers to a specific vendor. Take for example ArcSight’s putative “standard” Common Event Format, or CEF. While this looks like an open standard, in reality it is clearly copyrighted and there is no mention of a neutral standards body.

Clearly LogRhythm does not understand what we’re doing here, or does not want to understand. Standards necessarily create a level playing field among the vendors, and force those companies to compete on the features that matter to consumers: ease of use, scalability, and price.

The history of the last 30-years in the computer industry clearly illustrates the benefits of open standards. We believe that the creation of the ULDP will be a positive step forward for the SIEM industry and is something we’re excited to champion. And to share.

Posted by Andy Morris on August 23, 2010 in Innovation , LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 2

The need.

Driving this desire for greater visibility, control and security is usually one of three things (there are of course other drivers, but these are the big three): compliance, security and the need to operate an efficient IT infrastructure.

Regardless of whether you’ve just failed an audit, or you’ve got one looming on the near horizon…or whether your firewall has just been kicked in, or you’re being paranoid because a “like” company has just been breached…or a critical system recently failed and it took you too long to recover - we always get asked for the same 3 things: alerting, searching and reporting.

People always ask us for the big red flashing light that screams something bad just happened. Our PCI data just made it out of the safe network. Warning! Our database just released data through a firewall port that it’s not used before. Warning! A router just went off-line and we’ve lost VPN access. Warning! Something bad has happened. Warning!

Of course, once the siren is silenced you need to get on with the very serious business of Crime Scene Investigation. You need to know: “How did the data get to the unsafe part of the network? Who did it? What else did they do?” You need to know: “Why did the database just send data outside the company? What else uses that port? When was the firewall last reconfigured? By whom?” You need to know: “Why did the router just stop working? Who was the last person to administer it? What was their reasoning?”

Once you’ve gathered your evidence, you need to document your findings – you need reporting. You need to be able to stand up in court and defend your compliance posture, to stand in front of HR or your CEO and defend your security best-practices, to stand in front of your LOB director and defend your operations.

That’s what we do. We give you the big flashing red light, we give you all the forensic searching tools you’ll ever need and we back it all with solid evidentiary reporting.

There are companies out there that specialize in each of these areas. They’ll tell you that once you have an alarm system, you don’t need the CSI stuff. Others will tell you that crime happens so you may as well let it get on with its thing and then have the best CSI team ready to pounce. Others still simply document everything that happens so that lawyers can later pour over the basic facts.

LogLogic believes you need three to be truly protected, to truly have total visibility and control.

Posted by Andy Morris on August 23, 2010 in LogEd | Permalink | Comments (0)

The LogLogic Story – Chapter 1

I’m about to post the full LogLogic story, a short book in 12 chapters. Hopefully it will tell you who we are, what we’re trying to do, and why we’re so very proud of LogLogic 5.

The Problem

The problems we’re trying to address are simple to define but harder to resolve, namely the lack of control, visibility and security in today’s IT shops.

These issues manifest themselves in many ways that we’ll discuss, but they all arise from a basic fact of life – IT is complex. You have lots of apps, databases, servers, routers, firewalls, and just ‘stuff’ to manage. Pretty much anything with a plug these days falls under the realm of the IT department. And of course, it’s all inter-connected. It’s wired together in a way that is difficult to unravel. This complexity means that it’s hard for you to react quickly to security breaches or new compliance demands. It’s hard for you to adapt your system to changes within your organizations, such as mergers or departmental re-structuring. And with complexity come the ever present issues of management – or the lack of it. If I were to try and generically sum up the problems people describe to me, it’s that IT has a lack of visibility and control over the systems that are running the very core of your enterprises. And then of course, there’s security. There’s always the security problem.

Posted by Andy Morris on August 20, 2010 in LogEd | Permalink | Comments (0)

LogLogic 5.0: And it keeps on getting better.

By Dimitri McKay

LogLogic 5 has been years in the making and I’ve been privileged to play with, kick at and test numerous iterations of it since its inception.

The task of building 5 began with a complete back-end overhaul, as we built out the industry’s most scalable IT data platform. This may sound easy, but being able to get massive amounts of data, and clearly see (or translate from machine bleeps to human linguistics) that data, and then use this haystack of facts, is a lot more difficult than you might think. Bringing in upwards of 150,000 MPS, indexing, parsing, enriching, and then using this new insight to search, report and alert in real-time is a massive undertaking. Especially when you scale this across an infinite number of appliances. Map Reduce technology is clever, but speaking to, working with and rendering reports, alerts and searches across a vast array of hardware still takes effort. Remember, we have customers that regularly generate more than 50 billion IT events each day, and they rely on us to interpret that in real time and make it meaningful to them.

That said, I’m going to ignore the back-end and present my top 3 list of front-end features new in 5. I think you will agree they demonstrate a huge leap forward in logging and IT data management technology.

1) The Sex

First up, the GUI - time for more sex appeal. The LogLogic GUI was of particular interest to me, as frankly it hadn’t changed since version 1.0. Sure we’d done some minor updates (added to the sidebar, reorganized some stuff), and to those with experience, it all made sense - there was method to our madness and reviewers regularly gave us 5 stars for “really cutting to the heart of things.” But for those stepping in for the first time, well, we needed to show you a little more TLC. We’ve known this for some time, but for the front-end that we had in mind, we first required that back-end work I talked about. Sure we could have just put lipstick on our stuff, but that’s a tactic we’ll leave to others.

The LogLogic 5 GUI has been completely redesigned with you in mind: consolidation, use cases, intuition - we threw the kitchen sink at it. To achieve our goal we brought in a group of UI designers who’ve built many of the interfaces you and I use every day in common products. These guys are experts. They spent months interviewing customers, identifying top use cases, understanding not only what our product did, but how people use it. And with that, they designed a UI that was not only a user interface, but a workflow engine. And they did so without adding dozens of annoying pop up windows (something else we’ll leave to others). What we now have is indisputably the best forensics workflow solution available. Anywhere.

2) The Insight

Second on my list of awesomeness is the new Log Labels feature. Like the interface story above requiring a better back-end, the story of Log Labels is in two parts.

Several years ago we invented the index search for log data. And it was hugely successful. So much so that at least one other vendor in the log management space went and built an entire business out of it. Ours was fast. It was mean. And just like everybody else’s it was dumb. It didn’t understand the data it was indexing. It just indexed as much as possible for ultra fast search. And as a slick search tool, it certainly got the job done. So now for part two, where for the second time, we re-invent IT data searching.

For awhile now, customers have been asking for a way to create custom parsers, but we stepped back and asked “is it parsers that you really want, or are you trying to add business intelligence to your existing logs?” And as it turns out, that was THE question. Enter Log Labels. Here is a feature that gives our customers the capability they’ve been asking for, without requiring a BSc in Development (something else we’ll leave to the competition). What we’ve created is a way for businesses to interpret their own IT data in a way that makes sense from their unique view point. We know other vendors describe possible solutions to this problem as “very complicated” or even worse, “solvable with professional services” (code for “very expensive with no guaranteed outcome”). So we went the other way. As my father always said, “K.I.S.S” - keep it simple, stupid. And we did just that. We KISSed our Log Labels feature. It’s the next step in evolution from indexing. It adds intelligence to unstructured data. It’s GUI-based. It’s simple to use. It does not require 6 months of professional services. And it’s built into 5 for free. Everyone say Yay!

3) The Time Saver

Lastly, I’m psyched about Policy Based Grouping. I know it seems like just a little thing, but when you actually start to peel it back, it makes perfect sense for our target market (think really really big players). Let me give you a few examples.

PCI Compliance: customers who have to adhere to PCI often segregate their networks and apply the PCI controls only to that specific subnet, which makes perfect sense. But what if you’re logging your entire network, but only want to see specific reports, alerts or searches from a specific subnet? Well, LogLogic can create a dynamic group that will add devices to that specific group as they come online. This automation cuts down administration for our customers tenfold.

Another example? You want to see all firewalls worldwide, but those firewalls are from a handful of different vendors. However, the naming convention all matches a specific standard. You can now create a dynamic group to add all devices with that naming convention worldwide. One shot deal. Job done.

So to all of our customers, you’ll get LogLogic 5 with your current support agreement. No extra charge. No additional cost. No reason to wipe your machine for a clean install. Easy-peasy.

For those who want to see how to consolidate your IT data, get visibility into, and act on events from all of your network devices, operating systems, custom applications, and more...sign up to receive detailed information. We’ll show you how it gets done. The right way.

Posted by Andy Morris on August 18, 2010 in Dimitri , Innovation , LogEd | Permalink | Comments (0)

Why 360 Insight?

By Guy Churchward

With the imminent release of LogLogic 5, our clients can now have true 360 degree Insight of IT data. We’ve always hung our hat on the ability to deliver visibility into the inner workings of an IT environment for security purposes; however, what we’re repeatedly asked is ‘how can you get alerted on something you don’t collect. Obviously this is fraught with complexity, but it plays very well into the formation of a massively scalable IT data warehouse and an essential architectural consideration to deliver peace of mind in the opaque and volatile world of virtualized cloud services.

The baseline deployments for data collection lead to sticking agents on all the sources you think will be relevant, and manually stitching them directly to a GUI - whether a change monitoring product, compliance suite, SEM or forensics tool.

Most companies have a SOC, a few SME’s and a handful of other monitoring application that require their own form of collection. What then transpires is a bloat of agents on the source with lots of end-points to update, and unexpected bills - sometime’s vendors even charge you for customization work! Then there is the ‘WAY TOO MUCH’ network chatter, with a handful of solution providers having their sticky tendrils laced across your network making what should be a simple GUI change feel more like an architectural lobotomy.

Metaphorically, this is like viewing the ocean through a small window - you know what you can see but it’s a subset of what is there, and you have no ability to expand your field of vision as the tool is designed for what it does and ONLY that.

LogLogic 5 accentuates the ability to abstract IT data- or dare I say, create a virtual data information pool - that can be tapped into from any GUI regardless of the use or user requirements. So, regardless of your specific chosen window of information and initial design principle, you now have the ability and flexibility to adjust on the fly and retrofit data sets that might not necessarily have been in your initial scope. For instance, perhaps you’re collecting data for compliance purposes; perhaps you underestimated the breadth of data needed, your initial posture is limited, and your new QSA is a little more demanding than your last. Now it’s just a simple task of encapsulating a larger normalized data set rather than scrambling to protect your company from being written up for non compliance.

Perhaps you run a SOC, and have a some extensive correlation algorithms ticking along but find a ‘like’ company just suffered a breach in a source area you’re not monitoring; so encompass, track back and remediate as you’ve been collected that data all along.

This ability to collect, normalize and store IT data opens up a wealth of use cases that aren’t immediately obvious but substantially enhances both the ROI and TCO of your initial investment. Knowledge is power and you have facilitated a goldmine of information and a key company asset.

By no means have we completed the journey but the technological advancement with LogLogic 5 such as UCF, ULDP, & Log Labels, we’ve set our high watermark even higher. Our moniker is Get-See-Use, if you don’t get it and don’t have the ability to see it, there’s little point in having a flashy dashboard displaying a square foot of ocean floor!

Posted by Andy Morris on August 17, 2010 in Guy , LogEd | Permalink | Comments (0)

360 Insight Made Real: LogLogic 5

My, haven’t we been busy! In case you missed it in this morning’s news, we just reinvented syslog. We also moved into the data enrichment business by combining log data, flow data, asset data and user data in a veritable pool of awesomeness. Of course, all this is delivered on top of the massive scalability we delivered in the Christmas timeframe - making us the biggest, smartest, fastest place to go for IT data management. We’ve also released our generation 1 crowd sourcing tool for data identification, delivered our new ULDP protocol (soon to be open sourced), and built what we believe to be the most optimized and slickest workflow UI for forensics ever seen in a SIEM product.

You can read more about it here.

Or you can read some of the press we’ve garnered in the last 6 hours here.

• Help Net Security
• IT Analysis
• IT Director
• IT BackBones
• IT BackBones Security
• V3
• CBR
• CTO Edge
• Earth Times
• Business Wire
• Cloud Computing Journal
• InfroTech
• bnet
• Maximum IT
• Sun Herald
• SC Magazine
• Dark Reading

And if all of that isn’t enough to impress you, check out this Wall Street Journal article which features quotes and a photo of our esteemed CFO. Life is very good indeed here at LogLogic.

Posted by Andy Morris on August 16, 2010 in LogEd , LogLogic News | Permalink | Comments (0)

More Dark Clouds

By Dimitri McKay

Earlier I pointed out that the silver lining in the Cloud is wrapped inside darker outer shell. Today I’ll go through the pro’s and con’s of Cloud Computing.

First up, the good news.

To start, your local IT people who take care of local application servers, local infrastructure to maintain access to those application servers, and security folks to tie it all down are now free to focus elsewhere. Your critical applications are moved out to the internet along with the cost of maintaining the infrastructure and server hardware/software/operating systems. The Cloud vendor will have their own gear, infrastructure, and employees. So you can immediately reallocate budgets.

In addition, cloud computing is super efficient. If you’re growing an application and have an active growth projection model, adding bandwidth, adding processing, adding storage can be dirt cheap. Cloud vendors offer computing power at cents on the dollar.

Lastly, the cloud is hugely scalable. No longer do you have to wonder if you have the horsepower, the bandwidth or the staff to support your growth efforts. Instead, you can build out capacity as you need it. All at very low cost.

Now, the bad news.

Regulatory Compliance is an issue. At the end of the day, customers are responsible for their data, even if hosted elsewhere. Although service providers have to deal with their own internal and external audits and various certifications, Cloud Providers are not responsible for SOX or PCI audits, they generally don’t maintain audit trails, and they will not open their kimono in order to let each customer bring their auditors in to handle that. So what functions can a Cloud provider offer an organization, if that function is outside the scope of compliance? Very little.

With that comes location of data. If you are an enterprise, and your data is located in another country, you are bound by local law of that data. Not where YOU are. Most Cloud providers are global entities which have data centers round the globe. With some Cloud providers, you can define which countries your data will be hosted within the service level agreement. With others, it’s just pot-luck.

The very definition of Cloud includes the idea of a shared environment. And so how do you keep your data segregated from others? This is a concern that many organizations are wary of in moving to the cloud. What happens to data at rest? Is it stored in the clear? Or is it encrypted? Encryption can be wonderful or a complete disaster.

User Access in the cloud is as much a concern as it is in a local datacenter, except for the fact that you don’t know the processes the Cloud vendor has followed to secure your data. Were background checks done on the people in the remote datacenter? How fast are user accounts shut down when an admin leaves the company? How much access do they have to your data? How secure are the data-centers? Is there any political strife taking place in the hosting country which could be a potential problem for disruption of service?

Although you’ve outsourced your workload, you still have to understand what the cloud provider is offering with regard to disaster recovery. Your data should be distributed across multiple data-centers to ensure that in case of an asteroid hitting the current primary datacenter somewhere on the other side of the world, your business is not affected in ways that could be avoided. How much time will it take your provider to complete a full system restore?

Here’s another concern. What if I want to change Cloud service providers? How will you get your data back? Is it possible to import that data into another cloud? What happens if the Cloud vendor you use gets acquired or shut down?

Lastly, what will you do if something bad does take place? Data theft, illegal or inappropriate activity... what recourse do you have? Because customer data can be spread across multiple countries, who do you call for an investigation? How do you get access to the evidence? What recourse do you have? These are basically impossible to do. There is no global governance police force that would handle these matters. And local and federal police in each country do not have jurisdiction across multiple countries.

You can outsource reliability but you cannot outsource responsibility. Although the cloud offers inexpensive computing power, reduced IT costs across the board, uptime guarantees and SLAs, the fact of the matter is that Cloud is not ready for mainstream until these security, compliance and operational use cases are put to pasture.

Posted by Andy Morris on August 13, 2010 in Cloud Computing , Dimitri , LogEd , SaaS | Permalink | Comments (0)

Dark Clouds.

By Dimitri McKay

Several years ago a new buzzword was formed. “The Cloud”. This was a familiar concept to anyone using “web mail” whether they knew it or not. Email was being offered as a service on the internet. So if you’ve used hotmail, Gmail or Yahoo mail, you’ve used cloud technology. But it goes further than that.

Software as a Service (or SaaS) are cloud based applications not in your local datacenter, but rather, off on servers owned and maintained by some other organization who have a very tightly controlled datacenter, and offers these services on the internet.

The processing, the storage, and the data are all part of a large grids and data centers where distributed computing takes place. We’re talking about hundreds of thousands of server farms which can much more effectively manage the processing power of a service, application or company far better than a single server or node of servers. In fact, economically, cloud computing is far cheaper than traditional computing paradigms.

But there’s trouble in paradise.

In a recent survey 60% of respondents expressed some reservations about moving to cloud computing technology, which, considering all the talk of how fantastic Cloud Computing is, it didn’t appear to be on the roadmap of most companies. In fact, 34% of respondents said that cloud was not even a strategic move for their companies. Why? Because according to 26% of those surveyed, said that they had some form of fear over the risks, security, control and transparency in particular. Many felt that the lack of controls created massive security risks.

The biggest question has been, thus far, how do we offer data security and transparency in the cloud, when frankly, it’s the job of the cloud providers to offer that visibility related to those practices.

Even the early technology adopters surveyed said that they wouldn’t be adopting the cloud just yet. So here are the pro’s and con’s of Cloud Computing.

First up, the benefits. Cost. To start, your local IT people who take care of local application servers, local infrastructure to maintain access to those application servers, and security folks to tie it all down can now focus elsewhere. Your critical applications are moved out to the internet along with the cost of maintaining the infrastructure and server hardware/software/operating systems. The Cloud vendor will have their own gear, infrastructure, and employees. So you can immediately readjust budgets and priorities.

In addition, cloud computing is super cheap. If you’re growing an application and have an active growth projection model, adding bandwidth, adding processing, adding storage can be dirt cheap. Cloud vendors offer computing power at cents on the dollar.

Lastly, the cloud is hugely scalable. No longer do you have to wonder if you have the horsepower, the bandwidth or the staff to support your growth efforts. Instead, you can build out capacity as you need it. At very low cost.

Next we’ll go in to the pro’s and con’s in more detail.

Posted by Andy Morris on August 11, 2010 in Cloud Computing , Dimitri , LogEd , Risk Management , SaaS , Security | Permalink | Comments (0)

Next Generation Log Management – The Platform Principle

By Steve Armendariz - LogLogic

A View from the Field: Steve is a Territory Manager based in Texas.

We are living in exciting times and for many obvious reasons. One reason, that I find extremely interesting, is that we have moved beyond the need to validate the importance of centralized log management. Rarely now, do we encounter an organization that is resistant to the idea. Those few companies that are normally argue the operational burden or the potential legal liability but these outdated notions are based primarily on a lack of understanding, internal culture or resource constraints.

What we are seeing as an emerging trend is that best in class companies have a much different orientation. These industry leaders no longer view their central log repositories as a corporate liability but as a strategic information asset. They are taking the stance that they are in effect building a corporate log data warehouse. This log data warehouse will be used for driving IT operational efficiencies into the business across a number of fronts.

Keep in mind that this is much more than mind-set and posturing. It truly is leveraging the log data warehouse for innovative use in areas such as security event correlation, compliance process integration, database security monitoring and the development of custom applications. These abilities are based primarily upon your centralized log data warehouse functioning as an Open Log Management Platform. In effect, being able to not only collect, store and search… but more importantly being able to “share” this information. Before diving to deep into this sharing ability, let’s take a look at some very important key solution attributes.

There are a number of key attributes that a corporate log data warehouse must posses for these efficiencies and economies to be realized. Given the importance of the information that is being stored, your log management platform must have stringent but not rigid set of data controls. These should include flexible retention policies based on log source type. There also needs to be a clear separation of duties and strong chain of custody controls. Additionally, if the platform is not self auditing you create the potential for compliance violations. One area that I feel passionately about is that the platform must not only provide “data dump” reporting but must also support stimulating visual analysis. This can be incredibly useful in helping put the results in context and in identifying patterns that normally would not jump out at you.

From an open platform perspective one of the critical elements is providing multiple methods for accessing the data. This means in near-real time as it streams into the platform, access to the parsed information that has neatly been inserted into tables and most importantly rich access to the raw log data. Another critical piece of functionality is log forwarding. This means being able to forward raw logs in there entirety or being able to forward only “pieces” of the message based on upstream requirements. Most importantly though, the platform must provide an open web API that enables other applications to be built in abstraction, that is, without knowing anything about the underlying hardware, user interface or other product specifics (other than the standard information needed for programmatic access). This final ability is the true game changer for our industry.

Yes, this is an exciting time for us in the Log Management business as we move beyond the less sophisticated days of collect, store and search and into the next generation of user developed log powered applications. And that my friends, is a topic for our next conversation.

Posted by Andy Morris on July 27, 2010 in LogEd | Permalink | Comments (0)

The first Security Information and Event Management (SIEM) related App for the iPhone!

I’m staggered. As you know we’ve spent the last 12 months (or longer for some people) with our heads down working on the “next big thing”. Everyone here is running on max-power as we gear up for the grand unveiling. Nobody has spare time to do those things we all enjoy: running, drinking, meeting friends, hugging family, patting the head's of cute dogs…

And yet somehow, one of our brethren has found the time to build the first SIEM-related iPhone app…Christophe Briguet, you are legend!

This is his app. It’s got nothing to do with LogLogic, other than we’re proud to promote it to you. You can get the app at http://bit.ly/d6Qank

We have a limited number of free promotional codes to give away if you don’t feel Christophe deserves a dollar of your money. Email me to receive a code.

Here’s what Christophe has to say about his app:

“Knowing the volume of logs generated by your environment is critical for people that have to choose or design a Security Information and Event Management solution. IT staff have to deal with various metrics to measure the amount of log data produced and Log Caliper can help them quickly convert between various SIEM and Log Management units. Conversion of messages per second/hour/day and Mega/Giga/Tera Bytes are done much faster and easier with Log Caliper. “

Posted by Andy Morris on July 15, 2010 in LogEd , Videos | Permalink | Comments (0)

Do I get a T-Shirt with that?

Posted by Andy Morris on July 09, 2010 in LogEd , Videos | Permalink | Comments (0)

An event by any other name

By Christophe Briguet

There are two well known acronyms in the SIEM world that are often use without too much distinction: MPS (Message Per Second) and EPS (Event Per Second). These two metrics have almost the same meaning and are both used unthinkingly to describe the amount of data generated by a source, or manageable by a SIEM solution.

I’d like to clarify the terminology as we use it:

• MPS is the rate of incoming data received or managed by a Log Collection solution. Usually a Message is any line of log, that either have either security significance or not.
• EPS is the rate of incoming data received or managed by an Event Correlation solution.

Knowing these two metrics is a critical requirement for the success of a SIEM deployment. We recommend keeping the EPS rate lower than the MPS rate by filtering and only forwarding messages to the Event Correlation layer that will be needed for real-time for alerting and critical event notification.

In LogLogic’s SEM, an Event is a standardized data object (based on both IDMEF and the LogLogic ontology) representation of a log entry that has been normalized by at the collection layer. The Events collected by the SEM Appliance are also called ‘Elementary Events’. When these events are aggregated by the aggregation engine they are called ‘Aggregated Events’.

Posted by Andy Morris on June 22, 2010 in LogEd | Permalink | Comments (0)

What the heck is Oryza Sativa and what's it got to do with Log Management?

By Guy Churchward

On a recent whirlwind customer tour we’ve been discovering yet more interesting use cases for log management. It struck me that while embracing what might be seen as a pretty boring IT staple, the results deliver a goldmine of diverse information and visibility uses.

Here's 3 interesting yet not quite mainstream examples;

• A petrochemical company is deploying infrastructure downstream both at their locations and their affiliated partners. Their engineers needed to track the relative success of their deployments, so they use our product to QA the deployments, delivering real-time alerts on failures or data loss.
• A company is having difficulty with competitors scrapping content off their websites and using it to rapidly compete with or potentially switch clients for ecommerce selling. They’re using log and security management to alert and mitigate data loss.
• A hardware manufacturer has a patented technology but wants to grant access to the design programs to their OEMs. They use log management to oversee the management, provisioning, access, progress and security of the program.

Being the leading provider of an open log management platform we see unusual and diverse cases like these every week. Thinking about them lead me down a slightly twisted path, that to articulate such interesting cases, we should produce a cookbook of fabulous gastronomic creations.

So, the easy leap to the next topic was that if logs were a food ingredient, which one would they be? Assuming staple, boring, bland-unless-augmented, and I get to rice!

Hmm, so does that make us Uncle Ben? Simple execution, leading brand, removed the cost and complexity? (By the way, Uncle Ben’s rice was first marketed in 1943 and was the top-selling rice in the United States from 1950s)

Continuing my twisted journey, I discovered that there’s at least 36 countries that declare a nation dish based on rice. (There are only 193 seats at the United Nation!)

In the spirit of amusing education, below are some interesting facts on rice.

• Rice production has the potential to improve nutrition, boost food security, foster rural development and support sustainable land care.
• Raw rice may be ground into flour for many uses, including making many kinds of beverages such as amazake, horchata, rice milk, and sake.
• Rice is often directly associated with prosperity and fertility, hence there is the custom of throwing rice at newlyweds.
• The earliest remains of cultivated rice in India have been found in the north and west and date from around 2000 BC.
• The U.S. provides about 12% of world rice trade.
• The largest collection of rice cultivars is at the International Rice Research Institute (IRRI) in the Philippines, with over 100,000 rice accessions held in the International Rice Genebank.

So partially this is an informational blog about how boring staples can shape the world, but in the main it's a request to you. Please let me know how you use logs in cool and interesting ways- I’ve a cook book to create.

Oh, and to answer the title…

“Rice is the seed of the monocot plant Oryza Sativa. As a cereal grain, it is the most important staple food for a large part of the world's human population, especially in East, South, Southeast Asia, the Middle East, Latin America, and the West Indies.”

Posted by Andy Morris on June 18, 2010 in Guy , LogEd | Permalink | Comments (0)

UK Electoral Commission: “We do not have automated systems to monitor the activities of users whilst accessing the electoral registers”

Guy Churchward, CEO at LogLogic

Back in March 2010 we submitted six key questions under the Freedom of Information Act to the UK Electoral Commission. We wanted to find out how they are protecting eligible voter information and monitoring access to the Registers. We have now finally (weeks after the 20 working days deadline) received a reply.

Initially we asked whether they had a product in place which allowed them to monitor and log access and changes to information on the electoral roll register/database. They replied stating that they don’t. Apparently local authorities manage their own electoral registers meaning that there is no central point of control at all. They are sent secure updates on a monthly basis by each individual local authority – how this is done (over email, USB etc.) wasn’t stated. The Commission did not divulge details on whether each local authority had a product in place to monitor and log access either. 

We also asked how many people had access to the Registers and whether this was reviewed on a regular basis. The response here was interesting. Within the Commission, a total of 25 staff have access to the electoral registers in the Party and Election Finance team.  These documents are stored in restricted folders and can only be accessed by the relevant staff for purposes of checking permissibility of donations to political parties. In addition a number of technical staff (currently 8) in the IT team also have access to the information. The electoral register information is apparently only accessed on a need to know basis and these access permissions are controlled the ICT team with permission given in line with an agreed policy and procedure after obtaining appropriate authority.  All information assets, including the electoral rolls, are reviewed annually (and ad hoc throughout the year if there is an indication that this may be necessary or as part of an audit) to ensure that they are handled and used appropriately. In addition, each time there is a change in staff, permissions to access the electoral registers are reviewed.  

Whilst this sounds reassuring it is important to note that procedures and policies are great – but only if they are followed to the letter. And who is checking that? We would have (hopefully) assumed that privileged users were also being electronically monitored regarding their activities on the registers as a backup, but the answer to that question was no. They do not currently have automated systems in place to monitor the activities of users whilst accessing the electoral registers. 

My "Spider Sense" went off. Yes, the Commission’s security measures conform to ‘data handling in government’ guidelines, but they aren’t tracking users electronically and subsequently don’t have any way of generating real time security alerts.

The need to monitor the digital footprint of employees in order to preserve the confidentiality and integrity of data and monitor privileged user activity is extremely important – especially with regards to public sector information. It’s very disappointing. I’m hoping that each local authority is a little sharper and are electronically managing and monitoring access to their databases – it’s certainly something we should be asking our councils about.

It is critical organisations like the Electoral Commission implement a central workable and secure solution. They must act upon it, monitor and maintain processes and stay up-to-date with access controls. Well-managed log data can provide them with a vital window on irregular activities. Why wouldn’t they implement it?

Posted by Andy Morris on May 25, 2010 in Guy , LogEd | Permalink | Comments (0)

Yes, We Lowered Our Prices on our Security Event Manager Appliances Part 3

Life – it’s all in the timing.

So what of the timing of this slashing? Well, that actually brings together 2 things that are happening simultaneously, one is SIEM, the other is ELF.

As part of the “we want alerting” conversations we’ve been having, we’ve noticed that there are just way too many definitions of the logging and alerting in the market place. Go and pull papers from Forester, Bloor, Butler, IDC, Securosis, and Gartner and you’ll find a slew of different definitions. Do a quick Google of SC Magazine, ZDNet, The Register, and the IT Pro and you’ll find even more. It seems nobody can actually agree on what is SIM and what is SEM. And then there’s a whole group of people bullying and force-fitting their vision of SIEM onto unwilling vendors. So let’s be really clear, using the “icing on the cake” allegory, we discounted the 10% icing, the SEM (correlated event management), but we did not discount the 80% cake (SIM – log management).

The SIEM market (SIM+SEM) is currently setting their prices based entirely on the icing and pulling the cake in for free. There are several reasons for this. The most obvious is that the icing is the attractive sexy attention getter – the one thing that the customer think they want. The cake on the other hand is doing all the heavy lifting, and truth be told, it’s satisfying your real needs.

What of the vendors charging a premium for the icing I hear you ask? Utter baloney. No they’re not; these vendors just claim they are to fool the customers into thinking they’re getting a good deal. We regularly hear of customer receiving 80% or 90% discounts off RRP. In fact, at a recent industry get-together, one vendor told me that they have a POLICY of automatically discounting 80% if a competitor is bidding, and that it “almost always” rises to 100%. To misquote:

“Price doesn’t matter to us because we know we’ll get the customer with upgrades, consultancy, installation services and maintenance.”

As it turns out, all those air-miles logged by our “executives in the trenches” were miles well spent, as they helped us to uncover a dirty secret – SEM represents more shelfware than any other software in IT security. And that sad fact sums up the state of our competitors’ SEM offerings: bloated software that doesn’t do what the customer needs, is almost impossible to install and costs way more than you imagined.

We want to change the game by offering real solutions, to real problems, at an appropriate price. And that brings us to ELF, which we’ll talk about next time. Stay tuned…

Posted by Andy Morris on May 21, 2010 in LogEd | Permalink | Comments (0)

Yes, We Lowered Our Prices on our Security Event Manager Appliances Part 2

The 80/10,10 rule

To paraphrase my previous post

Our customers want a flashing box when “bad things” happen, they also want to know what else happened to cause the alert (investigative forensics). This leads to demands for regular reporting, trending analysis, and closed-loops to improve the alerting. Then they add to that HA, pipe-management, roles based access, and infrastructure integration.

From the above list, LogLogic can satisfy 80% of those demands with our SIM product; our Log Management platform. Many people forget, but loggers generate alerts too. On top of our SIM, we add a SEM. Our SEM is an awesome piece of unique patented technology that utilizes an event taxonomy to generate correlated alerts – virtually out of the box. I like to think of this as a nice 10% icing on our solution.

So what of the missing 10%? Call that R&D. If you look at the Gartner Magic Quadrant you’ll see there are lots of vendors selling SEM products, and paying lip service to SIM. One of the things all SEM vendors have in common is that we’re all investing heavily in R&D – there’s got to be a reason for that. And the honest truth is that as a market place we’re not servicing 100% of the customers’ needs. Nobody offers solutions that scale to the extent that the largest demand (or even the ‘typical’ in many cases). Nobody offers installs that take minutes rather than days (months in the case of some vendors). Nobody offers full integration with every single back-end and front-end system you can imagine.

But the baseline, the 80%+10%, we do that better than anyone else. That’s just us being straight with you – we’ve got nothing to hide. Because here at LogLogic, we’re not afraid to let you take a peek behind the curtain at the Wizard.

Posted by Andy Morris on May 20, 2010 in LogEd | Permalink | Comments (0)

Yes, We Lowered Our Prices on our Security Event Manager Appliances

Many of you will have noticed that Monday we announced a price cut for our SEM products. We did this for one reason only, to establish a market value for the core features of security event management. There are many blogs talking about what we did, but one of the most thoughtful ones to catch our attention was by Rocky over at VisibleRisk.

Let me explain the rational, but first, before you get all glass-half-empty on me, I’ll point you to our last 3 earnings statements (3^rd quarter, 4^th quarter, 1^st quarter). For those of you with an investment in our future, relax, we’re doing great.

We just want alerting

So back to the price slashing. As you know, we have a new leadership team here at Logging Towers™ under the watchful eyes of Guy Churchward and a re-energized board. One of the first tasks this new team undertook was a market assessment and an install base assessment. Together they’ve racked up thousands of air miles listening to customers, partners, prospects and the competition.

What they found was that the overwhelming majority of our customers and prospects express their needs as this – they want core functionality, like alerting.

A bit like when you try and buy a new car, you ask for something sexy and fast but in reality you actually want something sexy and fast, that gets the kids to school, gives good MPG, has long service intervals, has a bike rack for the weekends, maybe a roof rack for the HomeDepot run. Oh and you need a Sat Nav. Does it come in Red?

SEM is just the same. Our customers want a flashing box, a pager alert, an email, or a trouble ticket opened when “bad things” happen. That’s the sexy and fast. But they also then want to ask what I’ve previously called The Million Dollar Question, what else happened to cause the alert (investigative forensics). This then leads to demands for regular reporting, trending analysis, and closed-loops to improve the alerting. Then they start thinking about the drive to school; should there be an alternative route, what if we need to car pool, etc, and so HA, pipe-management, roles based access, and infrastructure integration get discussed.

The conversation is always long and convoluted, but still, the customer only wants the basics. And they should be charged accordingly. That’s what we’ve done.

Posted by Andy Morris on May 18, 2010 in LogEd , LogLogic News | Permalink | Comments (0)

Time when you’re dead

"In the afterlife you relive all your experiences, but this time with the events reshuffled into a new order: all the moments that share a quality are grouped together.

You spend two months driving the street in front of your house, seven months having sex. You sleep for thirty years without opening your eyes. For five months straight you flip through magazines while sitting on a toilet.

You take all your pain at once, all twenty-seven intense hours of it. Bones break, cars crash, skin is cut, babies born. Once you make it through, it's agony-free for the rest of your afterlife.

But that doesn't mean it's always pleasant. You spend six days clipping your nails. Fifteen months looking for lost items. Eighteen months waiting in line. Two years of boredom: staring out a bus window, sitting in an airport terminal. One year reading books. Your eyes hurt, and you itch, because you can't take a shower until it's your time to take your marathon two-hundred-day shower. Two weeks wondering what happens when you die. One minute realizing your body is falling. Seventy-seven hours of confusion. One hour realizing you've forgotten someone's name. Three weeks realizing you are wrong. Two days lying. Six weeks waiting for a green light. Seven hours vomiting. Fourteen minutes experiencing pure joy. Three months doing laundry. Fifteen hours writing your signature. Two days tying shoelaces. Sixty-seven days of heartbreak. Five weeks driving lost. Three days calculating restaurant tips. Fifty-one days deciding what to wear. Nine days pretending you know what is being talked about. Two weeks counting money. Eighteen days staring into the refrigerator. Thirty-four days longing. Six months watching commercials. Four weeks sitting in thought, wondering if there is something better you could be doing with your time."*

How much time will you spend pouring over near-indecipherable logs? We can help you minimize that that.

*Excerpted from 'Sum - Forty tales from the afterlives' by the very talented David Eagleman. I urge you to buy the book.

Posted by Andy Morris on May 12, 2010 in LogEd | Permalink | Comments (0)

Size really DOES matter…

By Dimitri McKay
LogLogic Security Architect

On a daily basis, the LogLogic Technical Sales team sizes opportunities and architects solutions for our target audience. LogLogic, being an appliance, sizes these opportunities on a minimum of two variables:

1) Throughput – or what is the message per second (MPS) rate?
2) Retention requirement – or how long do you want to store your logs?

Now, ‘throughput’ is certainly a vague or at the very least an elusive requirement, because off the top of your head can you really estimate your MPS? We start here…by filling in all the blanks for syslog streams, file pulls, alerts, data retention, number of devices, etc. to come up with a number. Then we apply the appliances toward that number in order to offer you a solution for that rock in your shoe. Are we building an operational solution, a forensics solution, and/or a compliance solution?

What I wanted to do in this blog post was put MPS rates into scope for you, and also help you understand why LogLogic is the biggest ‘baddest’ log monster on the block.

Case in point:
Twitter...the short-blog-messaging service has steadily grown to over 50 million tweets per day. You know it. Your Grandmother uses it to tell you that she’s on her way to Bingo. Well, to help give you context, all of Twitter generates roughly 7 terabytes of raw log messages per day.

Let’s do the math:

7TB divided by average message size in bytes
= (7696581394432 / 700) = 10995116278

Divided by number of seconds in a day
(10995116278 / 86400) = 127258.3

This equates to an average of 127,258 messages per second. Every second. Every minute. Every Hour. Every day.

Wow! That seems like a ton of data…

Until you line it up with our appliance. Just the one. A single LogLogic appliance. One LogLogic ST appliance can handle up to 150,000 MPS.

That’s right, one box. We can easily cram all 127k MPS of Twitter’s logs into a single appliance, and have room to spare.

Let’s say that again.

LogLogic could collect all of Twitter’s logs IN ONE BOX.

That’s what makes us enterprise class. That’s “big data”. That’s LogLogic.

Posted by Lex Van den Berghe on May 06, 2010 in Dimitri , LogEd | Permalink | Comments (0)

Is the UK Electoral Commission Equipped to Protect YOUR Data?

By Guy Churchward, LogLogic CEO

With the May general election looming, the buzz in the UK over who to vote for is electric. For the first time we’ve seen the “big three” participating in live election debates trying to get their messages out to the public. Much thought has been given to each leader’s communications technique and delivery style - and whilst it’s great to watch, LogLogic’s interest firmly lies in just how the electoral commission is protecting eligible voter information on the Register. The electoral register is a database which holds key details about every single voter in the UK. To check that its data was being protected and monitored correctly we submitted several questions to the Electoral Commission under the Freedom of Information Act (FOIA) on the 19^th March 2010 which gave them 20 working days to respond with answers.

We posed questions such as:

• Whether they have a product in place that allows them to monitor and log access and changes to information on the electoral roll register/database:
• How many people have access to the register/database and is this reviewed on a regular basis (and if so how often)?
• Are privileged users being electronically monitored regarding their activities on the register/database?
• Do the security measures in place conform to ‘data handling in government’ guidelines?
• Are they able to generate real time security alerts to highlight any suspicious user activity on the register/database?  
• How quickly do you apply security patches to the register/database after release from the vendor?

It is no surprise then that we’ve not received a response within the 20 days specified by law. We’ve chased them for answers and had responses back apologizing for the delay – but all we’ve received so far are excuses. These are basic data security and log management questions – and they should be able to confirm whether these are in place – or not – within a matter of a few minutes. 

Whilst we continue to wait for a reply, we hope that your data is safe and being managed carefully.

Posted by Bill Roth on May 04, 2010 in Guy , LogEd | Permalink | Comments (0)

The million dollar question

The question is a deceptively simple one: what else did they do?

I’ve been reading a lot about PCI DSS recently, a trip to the arcane that should have been boring but was actually quite stimulating. The whole thing was kicked off by John Kindervaag of Forrester telling us that he thought PCI was the world’s biggest vertical market.

Now don’t get me wrong, this is not new to us. We’ve had a PCI compliance enabling tool for quite some time, and in fact, its one of our leading sellers, but to describe PCI as a vertical, well, that was new. As you know you can achieve PCI compliance any number of ways, and there are several security frameworks, such as COBIT, COSO, and the various ISO security standards, that provide a set of best practice information security that you can use. These same frameworks of course, can be used for other things too. I’m thinking specifically of COBIT and how many people use it for SOX compliance.

So here I am noodling on the greatness of PCI and I realize, if a vendor has bumped in to a Bad Person™, and they’re now in violation of PCI, what else did the Bad Person™ do? If my PCI is built on a COBIT framework, am I now in violation of SOX too? How can I find out?

I’ve just spent the week in Florida (it rained) for the InfoSec Orlando show, where we had a booth amongst a sea of competitors. They all had one thing in common, they all were pushing event management as the answer to the question. I don’t think it mattered what the question was, but the answer was clearly that people needed events.

Whilst all this was going on, the Supreme Logger here at Logging Towers was off on a vacation, sailing somewhere nice and smelling faintly of SPF30. During what I assume was a gap between margarita’s he sent a short message to a few of us saying “logging is like twittering for devices”.

And then Google launched a Twitter time-machine like search tool, claiming that whilst Twitter lived in the now, surely being able to ask what related things happened in the past was of value. And then it all tied together. The million dollar question had apparently been bugging Google too.

You see, building solutions with a single goal, such as being PCI compliant is a fool’s errand. Living in the moment with no sense of past is just blinkered. Back at InfoSec I had a wander around and I talked to a few competitors (we do that you know, talk amongst ourselves), and you know what I found out? The million dollar question knocks ‘em dead. They live in the now. They have no sense of place. No sense of history. When they trigger a PCI alert, the obvious next question is “what else did they do?” Where else in my system did Bad Person™(BP) wander? How long has said BP being stealing from us?

If you only live in the now, you can’t answer that question. What you need is something that listens to all the twittering of your devices and stores all that chatter and gossip in a time machine for later log-ologists to dig over and gain a sense of place in the world. To be able to answer the million dollar question you need a fabric that touches all corners of your enterprise and is poised ready, to answer whatever question you need to ask.

Alerting is cool. We do alerting. Knowing is better, and we know everything that twittering devices ever mumbled.

Posted by Andy Morris on April 25, 2010 in Compliance , Log Management & Intelligence , LogEd , Risk Management | Permalink | Comments (0)

Do your "Traffic Allowed" logs sing?

By Christophe Briguet, Log Maestro

In his blog post series "The Best Defense is a Good Logfense" Gorka Sadowski described how to fortify a ‘defense in depth’ strategy with logs. The release of our Log Source Package #16 (LSP) gives me the perfect opportunity to start a new blog series offering some concrete examples of Gorka's claims.

The newest LSP adds support for numerous new log sources including Fortinet, Microsoft SharePoint, McAfee ePolicy Orchestrator (with VirusScan), IBM DB2, Oracle DB server and Microsoft SQL Server. As you may know, these logs are notoriously hard to understand so we’ll start this series with something a little more comprehensible, the “Traffic Allowed” (TAL) log.

The TAL is the most common, the largest and the most overlooked of all the firewall logs. It records all activity that happens on your network legitimate or not. This log is also known as "build ... connection", "packet accepted" or "access-list ... permitted".

Firewall devices such as the newly supported Fortinet ones, produce logs for all accepted network connections that can tell you many things about your in- and out-bound activities. We’re going to use the TAL to perform the below six basic operations:

1. Confirm malicious activity
2. Detect policy violations, misuse, or the bypassing of internal controls
3. Detect DOS or an unusual number of connections
4. Detect suspicious traffic destinations
5. Create activity trend reports for the Operations team
6. Optimize rules to improve performance

Confirm malicious activity

Either after the fact during forensic analysis of your network, or during the real-time correlation of events, the TAL can be used to confirm specific connections. When correlated with an IDS it allows you to track activity of a specific IP address. Using a closed loop process you can re-create events and determine if an original alert was genuine or a false positive.

Detect policy violations, misuse, or the bypassing of internal controls

The TAL can be used to check for any unwanted protocols or services that the firewall should have blocked but didn't (e.g. IM services, P2P, etc.).

To complement the firewall filtering policy, traffic allowed logs can be used to detect misuse of production servers. For example, they can show allowed traffic from a critical Windows controller server that is not using a valid Windows-related protocol (e.g. AD, DNS, Kerberos, LDAP, etc.). You can use the same approach to detect outbound traffic on email servers that not related to SMTP, POP3 or IMAP. Or, knowing that SNMP can only come from a restricted range of machines, you can use the TAL to find rogue mail servers. I could go on about proxy servers, app servers etc. but you get the idea.

Most organizations have clearly defined Acceptable Use Policies (AUP) that outline how an individual can interact with the Internet, e.g. with these policies being automatically enforced by Content Gateways. It is possible to detect the bypassing of these gateways and the associated AUP violation, by searching for HTTP and HTTPs traffic not emanating from gateway. In particular, the HTTP POST request is often used by malicious software to connect to various PHP files on a control server.

Detect DOS or an unusual number of connections

Denial Of Service attacks or a worm out-break can be detected by analyzing the TAL. For example, an increasing and unexpected number of ‘accepted connections’ may be the consequence of malicious activity or security incident. In this case, with the traffic not being blocked by the firewall, the attack or propagation should be considered a priority.

Detect suspicious traffic destinations

The TAL can used to detect traffic with a suspicious location. For example, it is often illegal for some organization to communicate with countries that are under US policies and embargoes (e.g. Afghanistan, China, Congo, Cuba, Cyprus, Eritrea, Haiti, Iran, Iraq, North Korea, Lebanon, Liberia, Libyan Arab Jamahiriya, Sierra Leone, Somalia, Sri Lanka, Sudan, Syrian Arab Republic, Venezuela, Vietnam, Yemen, Zimbabwe). In some context, any traffic with one of these countries may be considered illegal.

Create activity trend reports for the Operations team

You can also use the TAL to create bandwidth trend reports, helping you better understand your actual network activity. (Who is talking with whom? With which protocol? How many bytes sent and received, etc.) Reports are usually of a ‘Top n’ list format but can be visually mapped to countries using a Geo IP database to help quickly spot unexpected traffic.

Optimize rules to improve performance

The optimization of firewall policies is critically important to provide high performance packet filtering particularly for high speed network security. ‘Traffic Allowed’ logs contain the ID of the filtering rules that match the traffic, which in turn can be used to rank rules and optimize performance.

Making a singing ‘Traffic Allowed’ log.

All the use cases described here will enhance your security operation and can be automated with a SIEM solution that provides correlation with an assets. But to be able to implement these smart correlation scenarios, you will need to build a strong and reliable log collection infrastructure that will provide the require scalability and storing capabilities to manage the voluminous (Tera-bytes, Petra-bytes?) Traffic Allowed logs. This log management layer will help to filter, correlate and selectively forward logs to the correlation engine according to use cases you want to implement. The best advice to make your logs sing is to start with Log Management and then grow up to SIEM.

Posted by Andy Morris on April 16, 2010 in Log Management & Intelligence , LogEd , Security | Permalink | Comments (0)

You could be guilty of Insider Trading and not even know it.

By Barbara Rogan
LogLogic General Counsel

Insider trading. When you hear that, you think of Michael Douglas in Wall Street or of Ivan Boesky. You might even think of the folks over at Galleon who were charged with insider trading just this last fall.

Typically, you think of people who are guilty of insider trading as people on Wall Street or in the financial world that have top level contacts. But, if you work for a web analytics company, you too could be an insider.

Take, for example, the IT professional who works for a web traffic analytics company Let’s call him Sid - as in in”SID”er. (Get it?) After working for the company for awhile, Sid begins to notice certain patterns of web traffic that occur before a company is bought. All at once, Sid sees a lot of traffic coming to ABC Co’s site and much of the increased traffic comes from XYZ Inc. A couple of weeks later, Sid then sees the traffic drop off dramatically. A little while later, Sid hears that XYZ Inc. just bought ABC Co. The next time Sid sees this pattern, he buys the affected company’s stock thinking they might be a target of an acquisition. Low and behold, when the targeted company is bought, Sid makes a tidy sum off of the increased price of the stock.

Sounds like a winning recipe wealth creation? Think again. That is insider trading. But how? Sid doesn’t work for either of the involved company and he didn’t get any “tips” from knowledgeable insiders. Sid was just cleaver enough to figure out something on his own and make a few bucks – no harm right?! Wrong.

Per the SEC’s Rule 10b5-1 (promulgated under the Securities Exchange Act of 1934 for those of you detail-oriented types), any purchase of a stock “made on the basis of material nonpublic information about that security or issuer, in breach of a duty of trust or confidence that is owned directly, indirectly, or derivatively, to the issue of that security” is prohibited insider trading.

In this case, Sid, as an employee of the web traffic analytics company, owed a duty to the targeted company via service provider relationship. The information he traded on, the web traffic increase and then drop-off, was not public information. If Sid trades on that information, even if he loses money, he is still guilty of insider trading.

So, how on Earth does this relate to logs? Well, the use of log management for compliance is not just limited to PCI or HIPAA. If Sid’s company had a robust log management system in place, it could be used to track Sid’s access to the company’s systems. If Sid’s company had seen Sid accessing data that he didn’t need to do his job, then Sid’s company would have the opportunity to address Sid’s behavior before it became a problem. So use of robust log management solutions, like LogLogic’s, can help prevent the Sid’s of the world from becoming the next Gordon Gecko.

Posted by Andy Morris on April 13, 2010 in Compliance , Legal Nerd , LogEd | Permalink | Comments (0)

Attacking the world and his dog.

Sometimes we do stuff for fun. Other times we do stuff just to get a rise. And sometime we do things because they’re right.

So this week we launched a new ad campaign pointing out some of the provably wrong claims of our competitors. The ads when served in the right order made us all smile.

Check this out…

Wonder how they’ll respond?

Bring it on boys; we’re younger, faster and people actually like us.

Then for no reason at all I decided to pick on the DLP industry not once but twice.

Firstly on page 41 of the current edition of InfoSecurity magazine…

And then in a SANs log management webcast RSA decided to tell everyone they were a GRC company and if anyone needed big disks they had a few, so I did it again. Only this time the nice folks at netForensics helped out. (Thanks Tracy, you’re a nice dude.)

Been a log-tastic week for us. I’m guessing next week we’ll have some fires to put out.

Happy Friday people.

Posted by Andy Morris on April 09, 2010 in LogEd | Permalink | Comments (0)

Be careful what you wish for

‘I wish they’d take more initiative.’

‘Why do we have to hand-hold them so much?’

‘Surely for the amount we’re paying we should get some original thought?’

People don’t say that anymore. It’s amazing how well the outsourcing teams have grown up. We pay 15 people in [insert country of choice] to do a job and they just do it. The quality is perfect. The deliverable is on time. We sent them machines, databases, and ideas, and they simply delivered.

Shame it took 15 people. With the best of home grown talent we could probably have done it with 10 but heck, they’re cheaper.

Pause. Stop. Think.

If we’ve spent the last 15 years training people on our code, helped them build universities that are the envy of the world, shouldn’t it have taken them 10 people to complete the task too?

Pause. Stop. Think.

There are more valedictorians graduating university in India than there are kids entering high school in America.

Pause. Stop. Think.

Maybe they did it with 5. What were you paying the other 10 to do? On your machines. With your data.

Maybe now’s a good time to turn on logging?

Posted by Andy Morris on April 08, 2010 in LogEd | Permalink | Comments (0)

Divorce: more than the loss of your CDs

‘I wish they’d take more initiative.’

‘Why do we have to hand-hold them so much?’

‘Surely for the amount we’re paying we should get some original thought?’

We’ve all had these conversations. It was the 90’s. We had tons of cash. Porting code to new platforms was beneath us. Maintaining legacy applications is not why we studied so hard at University. Why should we pay a top engineer $100 an hour when some kid would do it for $5 in a country miles from these shores?

But, damn, I’m not sure it’s worth the pain, they never show any initiative!

Its 15 years later. The worker bees that were so ill-trained and underpaid have grown up. They’re better educated than us. There are more valedictorians graduating university in India than there are kids entering high school in America. And they all want and deserve our standard of living.

And you gave them all your source code.

All your corporate secrets.

You sent them servers, disks, blueprints, databases, ideas… everything.

Our economy is tanking. Desperate coders will work for food. ‘Hey, porting is interesting work!’ ‘At least maintenance work never dries up!’ ‘We should buy native; give our own people a job’.

We’ve all seen divorce, breakups, & separation. It’s never easy. It’s rarely smooth. There’s always animosity. Somebody always feels slighted.

Someone always keeps a CD they shouldn’t.

If only you’d have kept a log of who had what.

Posted by Andy Morris on April 07, 2010 in LogEd | Permalink | Comments (0)

Economic stimuli to accelerate the evolution of worker bees to barbarians?

By Guy Churchward

The title may be a mouthful, but the premise is pretty straightforward: the US economy is not exactly in the best shape it could be. California – now facing a $21B budget deficit - isn’t all ‘fun in the sun.’ My local grocery market is now advertizing their fresh produce from ‘local’ or ‘foreign’ producers. Apparently this is the FDA’s doing but I posit this is more an attempt to condition us to buy local and keep the dollars closer to home. All of these facts shed light on a larger, more global trend.

Being immersed in Silicon Valley since ’96, I’ve experienced the marked drive towards outsourcing IT services and engineering. This trend is usually dressed as efficiency, but a thin veil hides two ugly truth points. The first is obvious – it’s really about cost savings. The second point is more elusive. In a buoyant economy, where local talent have plenty of work options available to them, why not just ship out the grunt work that nobody wants to do.

This is an uncomfortable topic of conversation, but I’ll bet you know exactly what I am getting at. Fast forward to the economic realities of today and you’ll see that this initiative has stimulated growth in a number of countries/regions such as India (Bangalore), Israel, Argentina, Russia and of course China. Don’t get me wrong, the countries I mention aren’t entirely propped up by IT outsourcing, but it’s certainly a vibrant source of funds and has a substantial economic impact.

It’s simple cause and effect: you have universities abroad conditioning and pumping out worker bees to handle the influx of dollars and contract jobs coming from North America and Western Europe. But how fine is the line between turning a cog and actually creating your own engine?

What happens if jobs “back home” are in short supply and high demand? What if the economy is such that ‘buying/hiring local’ becomes a mantra? Add to this the natural theory of evolution, and I wonder how content a worker bee would be, continuing to innovate for his foreign clients?

How many innovative start-ups have spring-boarded out of Bangalore, applying the pragmatic grounding and exposure to westernized innovations?

These are truly exciting times. It’s dog eat dog, but how much visibility do you ‘really’ have on the evolution process? Are the worker bees actually bees, or are they barbarians with wings?

From a practical security and compliance standpoint, it’s been categorically proven that the number of barbarians banging at your doors and windows has increased, however the damage has remained small, when compared to internal breaches that often have such catastrophic impacts.

So imagine if an innocuous and well intended tax incentive came about in your country that encouraged global insourcing and stimulated an increase in domestic jobs. Even if you had no intention of taking advantage of this tax incentive, could this still push your friendly outsourced worker bee overseas to pick up a sword (and your assets) and run for the nearest open door?

All I can say is that evolution will progress, the bees will become bosses, and the need to have a solid defensive and protective IT strategy will continue to grow in urgency. We are seeing a rapid increase in use cases where log management is being used to monitor the security of contractors. Along with the increasing relevancy of adding umbrella insurance policies, I’d double-check that your subscriptions are up to date and you’ve the right tools in place regardless of your intended outcome. Your strategy should not be just about how you want to react, but how you need to react to gravitational impacts that global trends like these invariably present.

Posted by Andy Morris on March 25, 2010 in Guy , LogEd , Risk Management | Permalink | Comments (0)

The Joys of Logging

As a Brit working for an American company based in the heart of Silicon Valley, I occasionally get accused of forgetting the wet, cold island I hail from. Our UK marketing team just reminded me how overlooked and hardworking the peoples of Europe are. Here’s some of the joy our European team have spread about their love of logging recently.

Europe Rocks!

• SC Magazine: Biometrics story
• DigitalIDNews: Biometrics story
• SC Magazine: 5 star product review
• SC Magazine: Product launch
• Infosecurity magazine: Product launch
• IT Pro: Shell data breach
• The Register: Shell data breach
• IT Backbones Computing: Product launch
• IT Backbones Security: Product launch
• IT Backbones Networking: Product launch
• Searchsecurity: Wick Hill comment
• IT Analysis: Quad
• Security Vibes: Impressive
• IT Backbones Software: Q1 momentum
• IT Backbones Networking: Q1 Momentum
• Searchsecurity: Log management tips
• IT Pro: DSM review
• Datacentre Edge: Cloud
• SC Magazine: Wyndham Hotel
• Fresh Business Thinking: Cybersecurity
• Geek Shui Living: Biometrics
• Security Park: Cybercrime

Posted by Andy Morris on March 18, 2010 in LogEd | Permalink | Comments (0)

A Five-Star Week

We’ve been at RSA San Francisco all week talking to customers, prospects, competitors and the great unwashed. Now as we gracefully slide into the weekend to recover, as I look around the office, all I see are smiling but tired faces.

During the long dark winter months it’s often easy to lose your gleam, to start to question your place in the world. This season has been no exception. I’ve heard sales people grumble about missing features, or an occasional bug, the lack of marketing support, or just the plain fact that a prospect got a 90% discount from a competitor eager to win a deal.

And then suddenly RSA bursts onto the scene like sunlight through a storm cloud – and all is made better. This year we saw competitors literally giving cash away to win attention. We heard from customers who virtually, and in one case, physically hugged us. We spoke to IT guys that are running the competitors’ products, but now want to switch to us, having learnt the hard lesson that sometimes things are free for a reason.

We laughed at/with our CEO and CMO as they made fools of themselves in our new quirky videos. We enjoyed fine food, beer and conversation with our customers and sat humbled and amazed at their stories of how we’ve helped them out of legal, moral, and just plain sticky situations. Another nice feather for our cap: the cool new Borderless Security ecosystem from Cisco now includes us as the log management go-to people of choice.

And finally, when we thought there could be no more joy in the week, we were awarded 5 out of 5 stars for our database management product, and chosen as one of the products of the week over at NetworkWorld.

Happy Friday people. We’re going home to sleep the sleep of the victorious.

Sign up for our LogLogic Newsletter and join in the continuing fun.

Posted by Andy Morris on March 05, 2010 in LogEd | Permalink | Comments (0)

Logging Poll #8 Context for Log Analysis

So, my next poll is up - and it is fun (but more technical): what information is most useful when trying to make sense of a log entry?
Vote here! Analysis will be posted here in a few weeks.

Past polls:

Poll #7 "What tools do you use for Windows Event Log collection?" (analysis)

Poll #6 "Which logs do you LOOK at?" (analysis)

Poll #5 "What are your top challenges with logs?" (analysis)

Poll #4 "Who looks at logs in your organization?" (analysis)

Poll #3 "What do you do with logs?" (analysis)

Poll #2 "Why collect logs?" (analysis)

Poll #1 "Which logs do you collect?" (analysis)

 

Technorati tags: logging, log analysis, polls

Posted by on May 05, 2008 in Innovation , Log Management & Intelligence , LogEd | Permalink | Comments (0)

Critical Log Management Questions - Answered!

Here are some interesting log management questions I got asked some time ago; reposting here for our blog readers.

Q1: For those companies that have successfully implemented enterprise-wide logging, what were the big nasty surprises that they encountered?

A1: Here are a few:

• political boundaries within the organization: "these are our logs, and you are not getting them"
• privacy laws: some logs cannot be collected in some countries; some cannot cross the border, some cannot be seen by some people, etc. This is true mostly in EU, less in US.
• legal blocks: work with legal before deploying any org-wide log management; legal might try to prevent certain data from ever being created (for fear of being legally discovered later)
• log volume: underestimating log volume is common and pretty nasty
• related to the last one: vendors being "optimistic" about their tool scalability
• time synchronization (of course!), specifically, lack thereof.

Q2: For those companies that have successfully implemented enterprise-wide logging, what was their implementation approach?

A2: Typically, 2-3 vendor PoC or pilot first. Then with the chosen vendor: phased approach based on location + type of log source (e.g. firewalls, then routers, then OS, then proxies, etc) + network topology (e.g. DMZ, then internal) + log source criticality (e.g. critical servers first; the rest next). This might be handy to look at.

Q3: What kind of storage requirements have been experienced by those organizations who have successfully implemented enterprise-wide logging?

A3: Massive? :-)

Here is a simple example: PCI DSS is a bit more aggressive than NERC since it mandates 1 year of log retention vs NERC 90 days, so: 1 year worth of logs is = 365 days x 24 hours x 3600 seconds x 1 (one!!!) busy firewall with 100 log messages each second x 200 bytes per message average (e.g. valid for PIX and ASA devices) = 588 gigabytes / year of raw log data uncompressed (assuming 10x compression you'd get about 60GB of compressed log data per year)

Store it in RDBMS? Multiple it by 2-3. Have an index? Add about 30%.

The bottom line is: terabyte is the unit to measure logs.

Q4: At the organizations that have successfully implemented enterprise-wide logging, how logging impacted network and system performance?

A4: Too broad a question, so here are a few pointers:

• logging affects performance much more on some types of systems compared to other types: most painful examples are databases where some people (can't find a link...sorry) report performance loss of up to 40% if logging all SELECT statements and other data retrieval commands (you need to log selectively on these); in other cases (e.g. web servers) there is no performance loss and logging is "always on"
• log collection: agents impact system performance (long post on this subject): a little when they run (everybody knows this) and A LOT when they crash (few people think about it - agent software memory leaks are not uncommon); unlike agents, remote agentless log collection barely affects system performance (unless you have one of the few esoteric cases)
• log transfer and network performance: look for compressed (logs compress really well), TCP-based transfers; syslogging over UDP uncompressed has a chance of doing a pipe saturation DoS on your network. Yes, people say "use a dedicated LAN," but this is definitely wishful thinking for many. Also, raw UDP syslog in large quantities over WAN = insanity :-)

Q5: What were some successful strategies for obtaining buy-in from system owners and operators in regards to turning logging on?

A5: OK, also too broad a question, but here are some pointers:

• provide them a useful service based on their logs (e.g. performance measurement, availability monitoring, compromise detection :-), or other security metrics, etc)
• help them with their compliance mandates (e.g. create reports that they can show to the auditors that "bug" them)
• give them tools to better solve their problems (e.g. allow access to a log management tool so that can investigate issues better, search the logs, check on their users, etc)

Q6: How the organizations that have successfully implemented enterprise-wide logging dealt with unusual devices (=log sources) that have no log management vendor support?

A6: They were in massive pain - if they choose a log management vendor wrong. You need to look for vendors that have "universal log source support" with NO requirement for a custom rules or custom collector/connector/agent development. LogLogic have generic text log collectors that can grab and analyze unknown logs. Typically this is done via some form of text indexing that works across all logs, including those from unknown, vertical, esoteric or custom-developed log sources

Hope it was useful!

Posted by on April 24, 2008 in Compliance , Innovation , Log Management & Intelligence , LogEd | Permalink | Comments (0)

Quick and Fun Poll on Behavior Change

While I am analyzing my previous poll, here is a quick and fun one: do we change our behavior when monitored? Vote away!

 

Posted by on March 27, 2008 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

Logging Poll #4 "Who Looks at Logs?" Analysis

Time to analyze my final 2007 poll on logs. In it, I asked who actually looks at logs at the organization. Here is what came up: results are here and also included below.

 

What can we conclude from this?

First, an obvious conclusion is in order! No matter how many times one can utter the word "compliance," logs are still most useful for mundane (one would hope!) system administration. Yes, indeed, sysadmins are the primary consumers of logs - yesterday, today, and - likely! - tomorrow as well.

Second, I am saddened by the fact that application developers have not warmed up to logs, at least not en masse (and not according to this limited poll...). I am guessing when they start thinking of logging when creating their applications, they will be more aware of the fact that you can troubleshoot the applications using logs ...

Third, incident response team showing that low is some kind of fluke, I am sure. Everybody knows that logs are indispensable during incident response. Yes, even if only a little logging was enabled or even logging defaults left in place, logs often reveal answers unobtainable via any other mechanisms.

Next poll coming soon!

Posted by on January 08, 2008 in Innovation , Log Management & Intelligence , LogEd , LogLogic News | Permalink | Comments (0)

Logging Glossary: Operational Log Message

As I mentioned here,  I started publishing the LogLogic Logging Glossary. So, here is the twelfth term (first second third fourth fifth sixth seventh eighth ninth tenth eleventh):

Operational Log Message

A log message about the state of a product, the product's operation or support of its application, or the interaction of the product with its environment.

Operational messages are one of the three basic message types. They can be summarized as:

• Administrative – Changes to the product
• Operational – The product itself and the job it is doing.
• Application – The product doing its job.

Example of operational messages are: backup succeeded, update applied, memory is running low, system load high, etc.

Future Glossary entries will cover Administrative Log Messages and Operational Log Messages

Posted by on December 20, 2007 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

Logging Poll #3 "What Do You Do With Logs?" Analysis

So, the results of my 3rd poll are ready: live results are here, picture is also in this post.

First, this poll way more popular than my previous "why" poll. It seems like people do dislike to wonder "why."

Second, what are  the two choices, that are by far the most popular? They are:

• Store raw logs on a server (23%)
• Search raw logs (grep) when needed (24%)

Yes, this is the "state of the art" of logging:   collection of raw logs and "as needed" grep aka "slow and painful" search. In fact, the above answers might not even be given by the same people: some might be grepping logs on the individual servers, while others collect them on syslog servers and never touch them. That is why being in log management business is such a great thing: you have nearly the whole world to evangelize about the value of logs and log management tools.

Third, what's the next most popular idea of analyzing logs? It is "Run my own log analysis tool" at 10% of the respondents. Indeed, this movement still lives and thrives: people choose the Build->Suffer approach to log management often enough ...

Fourth, next come my somewhat self-inflicted surprise: apart from commercial log management (at 4%) and rolling one's own (discussed above at 10%), I added the option of "Use other log analysis tools"   which captured 7% of the vote. But what does that mean? I have no idea!

Fifth, I am NOT surprised by the lack of popularity of the rule-based correlation tools, such as SIEM (at 2%). When I made my decision to join LogLogic, I had to ponder this one really, really hard. My conclusion at the time (which is also valid now, even more than back in 2006) was that "SIEM is for some, log management is for everybody." This poll confirms this further.

Finally, all my logging polls and analysis are here. Next one is coming up!

Posted by on December 08, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

Anton Logging Tip of the Day #13: Into the Darkness ... or The Ominous World of Unix Binary Audit Logs

Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative.

So, Anton Security Tip of the Day #13: Into the Darkness ... or The Ominous World of Unix Binary Audit Logs

In this tip, we will take a peek at one of the most esoteric areas of logging: Unix binary audit logs. Solaris BSM and Trusted Solaris auditing is the least unknown :-) example of it, even though other Unix vendors have similar auditing capabilities - see this for HP-UX Audit and this for IBM AIX audit. Linux kernel audit is also pretty much the same thing. If you look for information on 'Solaris BSM audit logs' , you'd find plenty of tips on how to enable such logging, a little on how to manage/rotate the log files, a bit on how to survive the resulting data deluge and ALMOST NOTHING on what to do with the log data, which is kinda sad :-) After looking at BSM logs for a while, I developed an opinion that nobody has ever looked at them on a regular basis :-)

So, let's assume you enabled Solaris BSM kernel audit for user "root" and few other "interesting" users (there is no per-object logging in Solaris; other Unix variants do have it) via the following commonly recommended per-user configuration in /etc/security/audit_user:

root:lo,ad,fw:no

anton:all,-all:no

jsmith:all,-all:no

This configuration file pretty much leads to logging of everything that the above listed users do. Now, you have audit files growing like mushrooms in your /var/audit. What good does it give us?  First, we need to convert the binary audit files into text - something along the lines of

# auditreduce -A  /var/audit/20071127193515.not_terminated.SunUltra10 | praudit -l > /tmp/sol_box_11272007

will do. Now what? In this tip we will pick one thing to use these logs for: how use them to see who is trying to copy sensitive files off the system.

First, who is connecting out - lets's search the logs for 'connect' calls (if you are using LogLogic for it, use Index Search for this task; if not, grep will have to do, but be prepared to wait, possibly a looooooooooooong time :-)). A few recommended searches:

• "connect AND 172.16.10.*"   or "connect AND NOT 172.16.10.*"   (to look for connection to specific IPs or only to outside networks) or simply 'connect AND username' to look for connections by a specific user (if you log many users)

Here is an example found (with connect, IP and user in bold):

header,103,2,connect(2),,Tue Nov 27 11:36:46 PST 2007, + 193 msec,argument,1,0x4,so,socket,0x0002,0x0002,0x80d6,SunUltra10,0x0016,10.1.1.41,subject,root,anton,other,anton,other,29902,29720,0 1611 172.16.0.173,return,success,0

At this point we already know the user name of the user who run that connecting process since it will be in the results (you can also the user to search as I showed above).

Next, what are those connections - let's try to uncover which programs actually connected (BSM logs don't make that easy!). Let's search for process starts in the same time frame (within a few seconds):

• "execve AND NOT ls AND NOT <whatever other commands you don't care to see>" will give you a list of started programs.

Example found:

header,124,2,execve(2),,Tue Nov 27 11:36:46 PST 2007, + 115 msec,path,/usr/bin/scp,attribute,100555,root,bin,136,1573,0,subject,root,anton,other,anton,other,29901,29720,0 1611 172.16.0.173,return,success,0

OK, so somebody is trying to connect via SSH/SCP. Notice that both records - connect and execve -  have the same timestamp, up to a second. Sadly, time and parent process ID ( which is in our case 29720) is all that correlates them together.

Finally, what file was affected (i.e. copied off the system via scp in this case) - more digging is in order; we again use the process ID and time. The easiest is to search for a file name or browse all records around the same time frame (might be A LOT!):

• "*secret.zip* AND anton" will work; we can add the above process ID and look for "anton AND 29720" (but expect a lot of data since this is a shell process ID)

For example:

header,135,2,open(2) - read,,Tue Nov 27 11:36:47 PST 2007, + 900 msec,path,/tmp/not-so-secret.zip.gz,attribute,100600,anton,other,0,32743959,18446744073709551615,subject,root,anton,other,anton,other,29901,29720,0 1611 172.16.0.173,return,success,4

What do we know now? This user connected to this system and MAYBE copied this file via, MAYBE via scp. How cool is that? (A: not cool at all, since we are not sure, but that is all we can do with such logs)

To conclude, if you can avoid dealing with Solaris BSM logs, please do so :-) On a more serious note, you now know why these logs were called "the ugliest logs ever."  Even more seriously (but still pretty humorously), these logs are a classic example of trees that make every effort to obscure the forest, because these logs record system calls and not processes or user actions (and connect, execve and read are all logged separately). There are also many, many more idiosyncrasies where these come from :-)

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Tips of the Day.

 

Posted by on November 30, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | Permalink | Comments (0)

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 by on October 17, 2007 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

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.

1. 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
2. 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
3. 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
4. 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
5. 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
6. 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 by on October 12, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

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 by on October 11, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

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 by on October 05, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

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 by on October 04, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

Log Trustworthiness Hierarchy

This post is inspired by the old TaoSecurity post Enterprise Trust Pyramid where he explains that he trusts some security, system and network evidence data more than other. For example, dedicated NSM sensor records are trusted more than vanilla server logs. With this post, I am looking to establish a log trustworthiness hierarchy so that people start thinking about trusting log data as a kind of a spectrum, from "probably trash" to "guaranteed to be an accurate record of activities."

So, do you trust your logs to accurately depict what happened on the system or network? Which logs do you trust the most? How do we increase this trust?

My first draft of such trust hierarchy follows below (from low trust to high trust):

1. Compromised system logs (mostly trash, but might contain bits that attacker missed/ignored)
2. Desktop / laptop OS and application logs (possibly changed by users, legitimate systems owners, etc)
3. All logs from others systems where 'root'/Administrator access is not controlled (e.g. test servers, etc)
4. Unix application logs  (file-based)
5. Local Windows application logs
6. Local Unix OS syslogs
7. Unix kernel audit logs, process accounting records
8. Local Windows server OS (a little harder to change)
9. Database logs (more trusted since DBA cannot touch them, while 'root' can)
10. Other security appliance logs (located on security appliances)
11. Various systems logs centralized to a syslog server
12. Network device and firewall logs (centralized to syslog server)
13. Logs centralized to a log management system via a real-time feed (obviously, transport encryption adds even more trust)

Admittedly, the differences between some of them are minor or even non-existent ...

To conclude, some logs DO in fact provide reliable evidence in case of an incident; you just need to know which ones to trust and which ones to only consider to be "hints" (or possibly even a misdirection). But of course, you need to first have logs and then look at them.

Posted by on September 27, 2007 in Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

Just What is Enterprise Class? Part II

Here is the next enlightening post from Dimitri McKay, our 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.

"4.Scalability: To support a large number of devices in growing enterprises, SIEM and log management products differ a great deal in how they scale. Some of the SIEM products require you to add as many as three new appliances, (which all carry a hefty price tag) just for a slight increase in throughput. Others require you to forklift out your existing hardware to bring in new, bigger (and more expensive) equipment. In my own humble opinion these options are completely ridiculous.

The LogLogic scalability approach is uniquely simple. “Add log-traffic to your LogLogic appliances until you reach capacity on that box. Then add another box. Rinse and repeat. Each box does it’s own collection, does its own parsing, reporting and searching, and does its own storage. No special other boxes required. All encompassing solution.

Of course, with “Scalability” comes other requirements of how to add capacity not only vertically, but what of horizontal scalability? Such features would include the ability to report across all LogLogic appliances, manage users and their access rights across a global environment, and use some form of remote authentication such as TACACS+ or RADIUS. This distribution should be an asset, and not a limitation of the overall system scalability. All of these are addressed and in the current LogLogic 4.x.

5.High Availability: Due to the number of corporations and government agencies depending on LogLogic for regulatory compliance, system security and forensics, as well as heartbeat monitoring and troubleshooting, it’s safe to say that LogLogic is “Mission Critical”.

Because LogLogic is a “Mission Critical” system, it must support the internal and external capacity for zero downtime via high availability. This is accomplished via bonded NIC’s, hot-swap drives in various RAID arrays and Mirrored sets, hot swap redundant power supplies and most importantly... the ability to link the boxes together in an active pair. Should there be a failure in a LogLogic pair, both appliances are exact clones of each other, and the passive appliance jumps right into gear as the primary. In milliseconds. It’s genius.

In a perfect world, there would be zero downtime on “Mission Critical” systems. Here at LogLogic, we try to minimize that to as little as possible through the use of various forms of HA, and it shows. Have you seen our new hardware?

6.Reliability: Although high availability plays a part here, I prefer to think of reliability as the quality of the code-base, the product design itself, and the forward motion of feature sets and additional device support in a timely fashion.

LogLogic is built on a stripped down lean, mean hardened Linux platform. From there we didn’t go the route of a proprietary datastore which can start as a good idea and then turn into a huge hulking mess with nothing but frustrations stemming from using, maintaining and increasing the capabilities of, but rather we went with a solid database solution for storing meta-data. Industry standard. Well known. Easy to use. Robust.

Then we built in some brilliant parsers and a very straight forward GUI. Sprinkle that with some great features and a little bit of magic and you have a LogLogic appliance. Our upgrade plans and implementation are fast and furious. We release new device support monthly. Monthly additions. Monthly updates.

At the end of the day, however, extenuating circumstances happen. Should there be a hardware or software problem, LogLogic support is there to help. With 24/7 support and advanced replacement available to our platinum level enterprise class customers, all the bases are covered.

Build the appliance on a solid kernel, with a well known and well tuned database. Add HA, some of the finest engineering talent in the world, and a great support team, and LogLogic does enterprise right.

Stay tuned for the 3rd installment of “Enterprise Class”. LogLogic is going where no LMI vendor has gone before."

Posted by on September 27, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

More Web Proxy Log Tips

After publishing my proxy log tip (here), I figured I'd post a few more mini-tips on web proxy logging as well as a link to my full presentation (webcast with voice, slides only) on web proxy log management.

First, why look at proxy logs? Apart from my overall answer that applies to all logs, proxy-specific reasons are the following:

1. Review users’ activities on the web (not just surfing!)
2. Monitor applications' HTTP activity
3. Detect Web-enabled malware traffic
4. Study proxy performance metrics

Most people just focus on #1 above and kind of forget #2-#4. Also, the focus of #1 is often narrow - what do they surf at work?- and not broad - what do they do on the web? - which is much more useful. While there is no direct mention of proxy logs in recent regulations, monitoring what users do with YOUR data is clearly part of the compliance mandates (and, obviously, a good idea in general!) Indirect references to proxy logging can be seen in the following:

• Proxy monitoring is part of the overall control and governance (thus SOX, HIPAA, GLBA, etc)
• Legal requirements to have audit trails (thus HIPAA, PCI)
• Breach disclosure laws also impact (SB1386 and others, soon US-wide)
• On the flip side, privacy laws might mandate the opposite i.e. NOT having logs.

So, please treat proxy logs with the respect they deserve!  Here is my full presentation (webcast with voice, slides only), on analyzing and managing web proxy logs.

Related posts:

• Anton Logging Tip of the Day #12: Proxy Log Fun - Proxy Logs vs Information Leakage

Posted by on September 24, 2007 in Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

Just What is Enterprise Class? Part I

Here is another enlightening post from Dimitri McKay, our network and systems engineer from the East Coast, where he discusses the meaning of the phrase "enterprise-class" (which is sometimes known to be abused in marketing literature...)

"The Enterprise is generally a huge task, and this post itself is quite large. Due to the mass of both this post and the average Enterprise roll-out, I will break this down into 5 parts. Here is part 1 in the 5 part series.

I hear the term “Enterprise Class” as a buzz word to define hardware and software. Sometimes it’s used to describe a feature set, and to some it’s a scalability reference. Here’s what “Enterprise Class” means to me, and how it pertains to LogLogic solutions as a whole.

1. Multi-user: LogLogic handles the Multi-user process in a two prong attack. First, we offer the basic granular local account system which gives users the rights needed to do the job on only the devices they require. Now, on the enterprise side, we have added the ability to connect to TACACS+, RADIUS and soon LDAP/AD servers in order to alleviate the task of managing users on the LogLogic Appliances. Multi-user is a must for anything that is to be considered “Enterprise Class”. I’m hoping to see some additional authentication methods in the future, however, as for now the TACACS+ and RADIUS option certainly covers the majority of our enterprise customers.

2. Accessibility: In 1998, Congress amended the Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities. Inaccessible technology interferes with an individual's ability to obtain and use information quickly and easily.  Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. Most of the specifications for software pertain to usability for people with vision impairments. For example, one provision requires alternative keyboard navigation, which is essential for people with vision impairments who cannot rely on pointing devices, such as a mouse. Other provisions address animated displays, color and contrast settings, flash rate, and electronic forms, among others (see more at Section508.gov).   Now, at LogLogic, we try to make our GUI as straight forward and easy as possible. We adhere our GUI to the standards and framework put forth by the web browser itself, which thereby adheres itself to the accessibility options within both that browser and also the Operating System.

3. Localization: As with any business solution, our world isn’t set in one language or specific dialect. As a whole, LogLogic offers language options not only in English but also in languages relevant to foreign countries that are bound by the same requirements that LogLogic can address such as JCobit and J-Sox, which are the Japanese versions of COBIT and Sarbanes-Oxley (SOX) compliance. As we move forward LogLogic continues to add alternative language support such as Korean and Chinese.

Stay tuned for the next episode of “Enterprise Class” where I will run off on a tangent about HA, reliability and scalability."

Posted by on September 24, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

More Project LASSO Updates

Dimitri McKay, our network and systems engineer from the East Coast contributes this fun story: "When I first started at Loglogic, the only option for retrieving Windows logs was via an open source product called Snare. Snare was a simple concept. It would basically tail a Windows event viewer and whenever a new event was written, Snare would convert that to syslog, and send it over the wire (UDP or TCP) to its destination. Basic concept, basic execution. 

    Now, all of this was well and good, however, I couldn’t help but feel like an agent was not the greatest of solutions. As a former Windows Engineer, I was sort of put off with the idea of agents as a whole. It seemed like everyone was offering agents, and those agents were never happy on my systems in some form or another. So began Project Lasso. 

    Over some Thai food, Matt Foley, Andrew Morris and myself had a conversation about an agent-less Windows solution, and later that day I found myself writing a PRD for the “Windows Remote Event Collector” which was code named Project Lasso. 

    The name stuck, and with our 4.0 release I’m really happy with the ongoing development of the product. The concept is simple... Lasso is installed either as an agent to monitor itself, or on a “Project Lasso Server” where it uses WMI connections to connect to the other hosts it will be pulling logs from. There it pulls the string dll’s to a local repository, and then pulls the windows events themselves. Both the string dll’s and the events are then sent to the receiving syslog or Loglogic appliance where they are parsed and indexed. [Anton: they can also be sent to any other syslog receiver, such as a syslog-ng server]

    In 4.0 we added a few features I’m very excited about. 

The ability to use custom shares. In version 3.x we needed a Domain Admin account to pull the full Windows events. The Domain Admin account was the only account which had access to:

• The Event Viewer (for the header and events themselves)
• The Registry (to point to the string dll’s.) 
• The file system (via c$ to get the string dll’s.)

In Project Lasso 3 if you set some Active Directory policies, you could eliminate the need for a Domain Admin for the registry and event viewer, but not the C$ admin share. The only other account that had access to that was the Backup Administrator. Now, in Project Lasso 4 we don’t have that issue any longer because we can configure just a standard Lasso User account to have access to the registry, the event viewer, and a local drive via a custom share.

The ability to change the Hostlist.ini on the fly: In Project Lasso version 3.x when you added hosts to be monitored, you had to restart the Lasso service. Well, this process became somewhat onerous in that every time an Administrator needed to add new servers/clients to be monitored by Project Lasso he had to re-start the service which would take quite a bit of time to check those string .dll’s for changes or additions and then start pushing logs to the destination server. This could sometimes take more than a few minutes depending on the number of hosts. So much for real-time alerting or reporting. None of this is a problem anymore as the Project Lasso service will now grab the new hosts on the next pass.

Shared DLL Repository: Prior to Project Lasso version 4, when a dll Repository was created on the Lasso Server, it downloaded all .dll’s for all monitored hosts. This means there was a ton of the same .dll’s in the repository as each machine would most likely have the same .dll’s. These folders were about 120MB large in Lasso 3 times the number of hosts you were monitoring. That can be a big storage problem in a short amount of time. In Lasso 4, the dll’s are shared among hosts so it has a much smaller disk space requirement.

In closing, if you’re interested in routing Windows Events to a syslog or Loglogic appliance, you can do so via Project Lasso either in agent mode or in agent-less / remote collector mode.

Feel free to check out the always free Lasso 4 on Logforge"

Indeed, Project Lasso  is in wide use among LogLogic customers as well as in the broader world. Deal with Windows logs? Grab Project Lasso!

Posted by on September 17, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

Read "PCI Compliance" book chapter on logging!

As you know, the "PCI Compliance" book is out. Syngress/Elsevier publisher released one chapter from the book for free: and it is my chapter on log management and logging in PCI! Enjoy it here! [PDF] The book (and, in fact my logging chapter!) already got some glowing reviews.

While people still argue whether PCI is simple or overly complex, PCI DSS is certainly motivating a lot of people to take a long hard look at their IT security ... For example, more people are starting to look at database logs as a result of PCI. While some vendors are still lagging behind, you can get your database logs into LogLogic today!

Posted by on August 24, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

Logging Glossary: Log Preprocessing

As I mentioned here,  I started publishing the LogLogic Logging Glossary. So, here is the eleventh term (first second third fourth fifth sixth seventh eighth ninth tenth):

Log Preprocessing

1. The process of modifying or transforming a message as preparation for later stage processing.

Preprocessing can include multi-line message handling, encoding conversion, and special character substitution.

2. The prerequisite analysis of headers or other information in a log that define the formats or values present in the log messages.

The preprocessing assures correct parsing and identification of values. 

Posted by on August 20, 2007 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

Anton Logging Tip of the Day #12: Proxy Log Fun - Proxy Log Analysis for Possible Information Leakage Detection

Following the new tradition of posting a tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Logging Tip of the Day #12: Proxy Log Fun - Proxy Log Analysis for Possible Information Leakage Detection

You probably know that web proxies (such as Squid, BlueCoat SG and others) produce a lot of detailed logs, that record all web traffic flowing through the proxy as well as pass/block decisions made by the proxy's content filters and possibly embedded anti-malware tools. Proxy logs can be used for a whole range of things, from routine monitoring for Acceptable Use Policy (AUP) compliance to malware detection as well as possibly looking for security scourge of 2007 - web browser attacks by malicious or compromised web servers.

Specifically, in this tip we will learn how proxy logs can be used for detection of file uploads and other outbound information transfers vie the web. First, think what is the legitimate use of file upload functionality in your environment. For example, if using web-based mail services is allowed, then sending an attachment will include an upload. What else? The rest will be considered at least suspicious...

In addition to file uploads, some malicious or commonly unauthorized applications will use similar methods to steal or transfer data, that will be reflected in proxy logs. Looking for HTTP methods (such as POST) and content-type in combination with either known suspicious URL  or user-agent (i.e. web client type) can often reveal spyware infections, actively collecting data. Admittedly, a well-written spyware can certainly fake the user-agent field so it is clearly not reliable, but still useful to add to our query above. 

So, here are some of the criteria we will use to look for information uploads in Squid and BlueCoat SG proxy logs:

• HTTP method (logged as "cs-method" by BlueCoat) = POST  (as opposed to the usual GET, used to retrieve web content).
• For information uploads: content type (logged as "RS(content-type)" by BlueCoat) = pretty much anything but "html/text" (which is the type used for uploading  web form contents) - especially try content types  "application/octet-stream", "application/msword", "application/powerpoint", "application/vnd.ms-excel", "application/pdf" and a few others to look for common file uploads.
• For spyware and application data transfers: user-agent set to anything but the common ones (i.e. not Mozilla, iTunes, LiveUpdate, etc) or even to "unknown." One can also try user-agent containing your favorite messaging app (e.g. "MSN Messenger", etc)  and see which such applications are in use.

(if you feel adventurous, other interesting content-types to try are "application/x-javascript" and "text/javascript")

Here are the examples found in proxy logs using the above query, including some "classics" (while spyware specimen are a bit dated, this method of  detecting them via logs is still relevant and useful):

1. 1124376766.026 RELEASE -1 FFFFFFFF 4734C557F9315105CA6BE0FA56B94D55 200 1124276674 -1 -1 unknown -1/0 POST http://reports.hotbar.com/reports/hotbar/4.0/HbRpt.dll
2. 1124392388.975 RELEASE -1 FFFFFFFF 810FFBF233584C330353CF0A8C31F5D2 503 -1 -1 -1 unknown -1/813 POST http://log.cc.cometsystems.com/dss/cc.2_0_0.report_u
3. 2007-05-19 03:55:12 160 10.1.1.3 - - - OBSERVED "Spyware/Malware Sources;Spyware Effects;Web Advertisements" - 200 TCP_NC_MISS POST text/html;%20charset=utf-8 http bis.180solutions.com 80 /versionconfig.aspx ?did=5342&ver=1.0 aspx - 10.1.1.2 273 175 - - none - -
4. 2007-05-21 03:10:40 4 10.1.1.3 Joanna- authentication_redirect_to_virtual_host PROXIED "Search Engines/Portals" - 307 TCP_AUTH_REDIRECT POST - http storage.msn.com 80 /storageservice/schematizedstore.asmx - asmx "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MSN Messenger 7.5.0324)" 10.1.1.2 791 2566 - - none - -
5. 2007-05-22 21:35:09 215 10.1.2.237 200 TCP_NC_MISS 217 8122 POST http kenobi.example.com /exchange/john.smith/Drafts1/RE:%2520CustomerList.xls-2.EML - - DIRECT kenobi.example.com - "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" PROXIED none - 10.1.170.42 SG-HTTP-Service - none –

The first three are traces of spyware (one was even identified by a BlueCoat content filter as "Spyware/Malware", the fourth is MSN Messenger-based activity while the fifth is emailing the Excel file via web mail.

Here are some other signs that will make the above log entry extra-suspicious is:

• A dead giveaway: upload happens to a "known bad" URL (e.g containing "gator" and others above) 
• Upload happens to an unresolved IP address (do a "whois" on it!)
• Uploads happens to a port not equal to 80 (i.e. the URL contains a port such as http://10.1.10.10:31337)
• Upload has confidential file name in the log entry (e.g. somebody dumb emailing a sensitive file to himself - as discussed here)

Overall, this log analysis method is good for casting a broad net to catch not just spyware-infected systems, but also unauthorized applications (e.g. method=POST and user-agent=iTunes), instant messaging (e.g. method=POST  and then by user-agent, content or URL), simple forms of data theft and document handling policy violations (emailing files to self via web mail: method=POST and sensitive file name present in the entry; also content-type set to popular Office file types) as well as other abuses of web access. As a result, proxy logs provide an extremely rich AND readily available source of data about threats that users face!

To top it off, one promising direction of future research is using web proxy logs to detect client-side exploits by malicious web servers (more on this in the near future!)

Possibly related posts:

• Anton Security Tip of the Day #6: The Other Web Log
• All my past security and logging tips

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Tips of the Day.

Posted by on August 07, 2007 in Innovation , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | Comments (0)

Musings on 100% Log Collection

One of the most exciting, complicated and, at the same time, very common questions from the field of log management is the "what logs to collect?" question. This comes up during compliance-driven log management projects (in the form of "what to collect for PCI DSS compliance?") as well as operationally-driven (in the form of "what logs from this application do I need to detect faults and errors?") or security-driven log management projects (in the form of "which logs will help me during the incident response?")

What are the answers that one sometimes hear? Otherwise awesome log management guidance NIST 800-92 "Guide to Computer Security Log Management" confuses the reader with this fascinating blurb: "generally, organizations should only require logging and analyzing the data that is of greatest importance." And how do people to know which logs are of importance? (I did have a bit of a debate with NIST folks on that...)

Other answers are situation-specific and thus limited in their usefulness ("need IDS alerts + server logs to detect intrusions via correlation", "need all logs that show access to PHI").  I spoke about the pitfalls of "prioritizing before collection" in my presentation "Six Mistakes of Log Management" and its companion paper.  In some cases, such as the incident response scenario, you might be naturally leaning towards grabbing as much as possible, since you never know which bit will help you answer that dreaded "WHAT happened?!" question ...

On the other hand, there is a simple answer that doesn't suffer from the above issues: collect everything. However, many folks go into a state of shock upon hearing it :-) "Everything!?! HOW can you collect 'everything''? What about storage, bandwidth, hardware, etc?"

But you know what? It really isn't as bad as you think! Just think that:

1. Logs compress really well (1:10 to 1:15 compression ratios are not unheard of), so bandwidth and storage are less of an issue that initially estimated
2. Disk storage is cheap (and tape is cheaper still); holding a billion of log records might well cost  under $200 (!) in disk drive cost
3. Figuring out what you need, might need, can be "told to need", will need, etc is genuinely hard. You will never get it right!
4. Many logs don't need to get collected the next second after generation, thus allowing you to save some bandwidth by moving them when network is less busy.
5. Technologies exist to make sense of "everything", not just "hand-picked" and parsed logs. More on the "making sense" part later

Convinced yet? So, if you are pondering "what logs to collect?", try to switch your mindset into thinking "what will it take for me to collect everything?" You probably won't regret this decision!  At the same time, one can try to reverse this question and ask "why collect everything?" - in this case, the answer will be "because any other collection strategy is worse."

Related posts:

• Top 11 Reasons to Collect and Preserve Computer Logs

• Six Mistakes of Log Management

Posted by on July 19, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | Permalink | Comments (0)

Logging Glossary: Log Header

As I mentioned here,  I started publishing the LogLogic Logging Glossary. So, here is the tenth term (first second third fourth fifth sixth seventh eighth ninth):

Log Header

A set of information at the beginning of a log file or the start of a log message.

The information usually consists of context information, or meta data.

It may have a fixed or variable format. Fixed formats and some variable formats are usually well defined in vendor documentation. Some variable formats, such as with Syslog are subject to vendor discretion.

Posted by on July 17, 2007 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

Anton's Security Tip of the Day #6: The Other Web Log

We all know that Apache web server has its access_log log files while IIS has its w3c logs. When people think about web log analysis, they think about the above and only about the above logs, often calling them "the web server logs."  However, the other web log - error_log  (in case of Apache) - contains a lot of fun and useful info as well.

Today's tip is to encourage the review and analysis of this treasure trough - pardon the idiom - of insight.

So, what goes into the error_log? Well, errors, duh! Why errors matter? 'Cause errors often present the only indication that a) you are being 0wned or, worse, that b) you've been 0wned by the attackers.

Additionally, apart from the obvious security usage mentioned above, errors matter since they - or rather, some of them - require actions by the user and thus knowing about them is of huge importance. What is even more striking is that many error messages present an interesting tradeoff - do only a little now to correct the reasons (or, "the root cause" as network management people would say) for the error, or do a whole lot later when the system crashes, gets hacked or "misbehaves" in some other truly spectacular way. Now, a grizzled BOFH would surely say "heh, but who would want to do that! surely, dealing with a dramatic world-ending catastrophe later is more fun that making a minor config fix now."

Now, back to the Apache errors; we are going to show a few examples from a live phishing site, run by the attackers on a compromised server.  We will start from the obvious - server restart, which actually happened as a result of an attack, in our case.

[Sun Mar 12 04:02:05 2006] [notice] SIGHUP received. Attempting to restart

Did YOU restart the server? No? Two choices then - someone else did (likely without permission!) or the server got restarted automatically for whatever strange reason. You certainly need to be at least somewhat concerned in both cases - thus: look for the above messages.

Here are a few more fun examples - the relevance of those for your business is left as an exercise for the readers, but all of the messages below:

[Mon Mar 13 14:54:11 2006] [error] [client 10.10.10.10] Premature end of script headers: index.htm

Does "index.htm" sound like a script to you? It sure should not; and this error message indicates that somebody is trying to run it as a script - a clear indication of malicious behavior. The next message is also similar in this regard:

[Mon Mar 13 14:54:26 2006] [error] [client 10.10.10.10] attempt to invoke directory as script: /var/www/cgi-bin/tcpsupport/

and so is this one:

[Mon Mar 13 14:54:23 2006] [error] [client 10.10.10.10] (8)Exec format error: exec of '/var/www/cgi-bin/tcpsupport/main.htm' failed

Other interesting things spotted on the same server -this one looks like an overflow attack attempt (and, no, the NIDS did not make a squeak about it)

[Thu Mar 19 07:16:11 2006] [error] [client 10.10.10.10] request failed: URI too long (longer than 8190)

So, to conclude, the tips is: when doing web server log analysis, make sure you look at the error logs as well as the access logs.

- Anton

Posted by on December 15, 2006 in LogEd , LogMatters , Security | Permalink | Comments (0)

How Log Intelligence is Transforming IT

Compliance, information protection, audits, user monitoring and risk mitigation are driving a new set of practices and policies in IT -- all around managing log data. In fact, recent research points to the Global 2000's continued investment in Log Management and Intelligence (LMI), projecting double-digit growth in 2006 to $380M.

And log data continues to grow at an unprecedented rate -- which just further compounds the issue of how to manage it!

We are hosting a webcast with the SANS Institute on August 9 to discuss the trends and solutions. LogLogic's Andy Lark will be joined by SANS Institute CEO Stephen Northcutt. Register here.

Posted by on August 03, 2006 in Log Management & Intelligence , LogEd | Permalink | Comments (0)

At the SANS Log Management Summit

Anton, Jill and myself are here in DC at the inaugural SANS Log Management Summit. Alan Paller opened the morning session to a packed room - over 200 people are attending - stating that Log Management is the sweet spot that bridges compliance and security.

Ben Wright took the stage after him speaking on Logs & The Law. A couple of the highlights from my rough notes:

1. Have a written policy... it is better to speak in general terms rather than hard language. And, a written policy, not followed = a negligence case.
2. Keep logs of log management - records about what was reviewed. Ben saw lots of value in this saying that "logs of log management are more valuable than logs themselves".
3. Bias to keeping more logs - general trend in law which rewards organizations that keep more information than they did in the past. More expectations for records/archives.
4. Only full audit committee should have power to know all logs... Maintaining custody of your log data is something we constantly emphasize and is a key feature of LogLogic.

Watch for our SANS Webinar on Logs & The Law - with Ben - later this month.

A great customer panel followed featuring a very large financial institution - and LogLogic customer, NetApp and others. NetApp are collecting some 40 million log messages a day - and emphasized that you can't use people exclusively to do log data mining when processing these kinds of volumes. You need a great tool. They made some other great points that we often look at when architecting solutions. You can't just collect logs from one set of devices and they shouldn't be dispersed. Get them centralized for rapid review and forensics. There was a definite preference on the panel for agentless log management systems.

- Andy

Posted by on July 12, 2006 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

The Case for Universal Log Processing

Andreas Antonopoulos revealed some more wisdom from his interviews with 82 IT managers:

“The average enterprise has more than 1,200 applications, but even that number is increasing every year”.

I have always known that enterprises have many applications because a typical log management and intelligence RFP has requests for about 200 discrete log sources. The bigger point is that 70% of enterprise software applications are homegrown or highly customized. This means there are a lot of “one-off requests”.

Therefore, it doesn’t matter anymore how long your list is of “supported applications”. What really matters is how quickly you can support “unknown log types”. Nothing is better than instant gratification and so at LogLogic have opted for out-of-the-box support for unknown log types. We use natural language processing and machine learning algorithms to provide baseline support for any application that writes ASCII.

- Dominique

Posted by on May 31, 2006 in Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

LogLogic and the SANS Institute Sponsor Industry’s First Log Management Summit

As the proven industry leader in transforming log data into critical intelligence for compliance, operations and security, we're thrilled to announce that with the SANS Institute we have created the only major conference on what works in log management, to be held in Washington, D.C. on July 12-14.

This promises to be a great event with more than 20 speakers - mostly users - speaking to best practices and leading-edge approaches. Moreover, it will go beyond security and network intelligence to look at more complete approaches to LMI spanning operations, IT controls, compliance and SLAs. Here's what Anton has to say:

It's time for log management to move beyond network intelligence and security event management, said Anton Chuvakin, director of product management, LogLogic, and member of the SANS Organizing Committee. Log management and intelligence has established itself as a critical discipline in medium to large enterprises. Activities such as compliance, information protection, audit, availability and user monitoring and risk mitigation are driving a new set of practices and policies. Our commitment to and participation in this event is further evidence of our support for the global log management and intelligence market. We look forward to sharing this event with our customers and partners.

If you are a LogLogic customer or partner and interested in attending, be sure to use the promo code to get a discount: LOGLOGIC10.

Posted by on May 30, 2006 in Log Management & Intelligence , LogEd , LogLogic News | Permalink | Comments (0)

Attend Log-ED ~ Go Home Earlier

Last week we announced the arrival of Log-ED, a new series of training programs that will take your log management and intelligence expertise to new levels.

Our first offering, Log Management and Intelligence Analyst, teaches best practices for collecting and storing log data; implementing log standards; and, provides an overview on how companies can validate IT controls and mitigate risk using logs.

It's time to mark your calendars! Public courses are available:

• San Jose: May 23-24
• Atlanta: May 31-June 1
• Chicago: June 6-7

Enroll today!

Learn how to:

• Understand log management and intelligence best practices
• Exercise log management best practices from current processes
• Perform administrative tasks using the user interfaces Implement
• Open Log Services & of delivery log data from devices to LogLogic appliances — and from these appliances to other systems
• Systematize file transfers from devices to LogLogic appliances
• Distinguish user privileges
• Apply user rights to fit a specific role
• Design and implement a centralized management solution
• Carry out Agile Reporting
• Implement and easily customize alerts and reports to notify an analyst of important events
• Understand why automated and continuous compliance is mission critical
• Discuss today’s regulatory environments and mandates — including SOX, COSO, and COBIT 4.0
• Explore the features of LogLogic Compliance Suite
• Validate and monitor IT controls using LogLogic appliances
• Perform network forensics on a simulated compromised network

If you aren't using LogLogic, that's fine. You'll still learn lots. If you are, this is the perfect opportunity to use your log management and intelligence platform to its fullest potential. Let us show you what it can do for you to make you better at your job, while lessening your workload. With these new skills, it's likely you'll be going home much earlier!

Posted by on May 12, 2006 in LogEd | Permalink | Comments (0)

Visit loglogic.com

Subscribe to this blog’s feed

• September 2010
• August 2010
• July 2010
• June 2010
• May 2010
• April 2010
• March 2010
• February 2010
• January 2010
• December 2009
• November 2009
• October 2009
• September 2009
• August 2009
• July 2009
• June 2009
• May 2009
• April 2009
• March 2009
• February 2009
• January 2009
• December 2008
• November 2008
• September 2008
• August 2008
• 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

Blogroll

• Whatever Compliance
• CynergisTek
• Bruce Schneier
• InfoSecDaily

Compliance

• Compliance Pipeline
• SOX Compliance Journal
• Sarbanes-Oxley 101

Good Reading

• Internet and Web Security Review
• Log Management ROI
• Log Management Best Practices
• SANS Institute Log Management White Paper

LogLogic

• O’Reilly
• Anton Chuvakin
• LogLogic.Com
• Jian Zhen

LogLogic Partners

• Juniper Networks
• ONStor
• Counterpane
• Bluecoat

Sites We Watch

• Verizon Business Security Blog
• SANS
• IT Manager's Journal
• CIO Insight
• Security Focus
• TechWeb
• Slashdot
• InformationWeek
• The Reg
• C/Net
• OSF DataLossDB | Data Loss News, Statistics, and Research