Posts tagged: 'log management'

The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.

http://blog.logrhythm.com/tags/log-management/feed
 
 

IT Archaeology “Easy Access to Your Archived Logs for Historical Forensics”

I once lost a huge amount of data – the regular stuff such as photos and other useful files. A review of the logs with my SIEM product showed several disk failure messages. Had I only been able to make sense of the logs and known what they meant I could have saved all my data. Of course, while losing some files is inconvenient, what happens when the data that is lost is of a more critical nature, such as the log files that you may need to analyse in the future for forensic purposes or compliance? Now that I have a few more years of SIEM experience and have seen the alternatives, no one else, as far as I have seen, has executed on the concept of using log data for analysis and/or reporting like LogRhythm.

I work with Support and Professional Services at LogRhythm. A typical day at LogRhythm is one where I am reviewing tickets and a call comes in from a customer that goes something like this: “I am investigating an incident that took place 6 months ago. Is there a way I can achieve this with LogRhythm? I have so far tried restoring data from old backups and used SQL queries, command line tools and varying degrees of imagination to try finding some of the data relating to a specific user and systems. I have also logged into my Domain Controllers but they only keep up to a week of data at most.”

Fortunately I’m able to respond with: “Of course you can. Providing that you still have the Log Data available for that time period, you can use the SecondLook feature to recover any log data you want.”

It’s interesting to me that one of LogRhythm’s most useful forensics tool is one of the more ‘unknown’ features to quite a few of our customers. In LogRhythm speak this capability is known as the SecondLook archive restoration wizard, and it makes a huge difference for someone tasked with performing a forensics investigation – like the one I just mentioned.

LogRhythm’s SecondLook wizard allows you to retrieve log data from any archive files, such as those stored directly on your LogRhythm Server, or off the box on a SAN or NAS. It allows you to bring this back to a separate database and make the data available for investigations and reporting. Since the archived data is digitally signed with a cryptographic hash, it can also report if any modification or deletion of data has taken place, maintaining the digital chain-of custody that most of our customers require.

To use SecondLook all you need to configure is a new database instance called the Recovered Archive Database (RADB), which is used for analysis and forensics on data that is no longer kept online.

LogRhythm SecondLook Log Management, SIEM 2.0 Interface

Then you use the SecondLook wizard to bring back any archived data that matches your search criteria into the RADB. Once it’s there, you can easily run an investigation against this database.

LogRhythm SecondLook Log Management, SIEM 2.0 Interface

Don’t get me wrong, backups are very important, especially considering my data loss scenario, where a lot more than log data was lost. However, when it comes to making long term log data available for investigation and reporting on what happened several months ago, you can’t beat SecondLook.

 

Tags: , , ,

0 Comments | General

 
 

“Keeping it in context”

Earlier this week, HP announced its plans to acquire ArcSight for $1.5 billion. This news signaled HP’s recognition that central log and event management is an essential technology platform for HP to pursue their vision on multiple fronts. Bill Veghte, HP’s executive vice president for software and solutions, said on a call with Wall Street analysts that the announcement confirms “HP’s intent to be a leader in enterprise security”.

Some SIEM vendors have used this news as a chance to spread FUD (fear, uncertainty and doubt) to organizations that might be considering an ArcSight purchase by suggesting that product development schedules at ArcSight/HP will be delayed, service response times will be hit, etc. Do they really think most IT purchasers just fell off the turnip truck? Certainly things will change for ArcSight. But mergers and acquisitions happen all the time and most IT purchasers are more than capable of assessing how vendors match up against their decision criteria, including those vendors that are in the process of being, or have recently been, acquired. These IT purchasers don’t benefit from vendor fear-mongering. Rather than contributing more FUD, I think a closer evaluation of Mr. Veghte’s comments serves a more useful purpose.

Mr. Veghte stated that the visibility ArcSight’s products bring into an organization is a cornerstone for HP to becoming a leader in enterprise security and that “if you can’t see it, you can’t secure it.”
While his statement certainly sounds good, if you’re only seeing “it” without seeing “it” in context, you’ll remain blind to potentially serious threats and significant points of exposure. By “context” I’m referring to all the other information relevant to that activity (the forensic details that help to tell the full story and/or paint the complete picture).

Let’s take an activity that on the surface is deemed benign at the time of occurrence, such as a successful authentication to a VPN server. Successful VPN connections happen all day long and represent normal business activity. As such, this activity never gets classified as an “event”. It’s simply seen as one of a million benign logs. But what if the user was connecting via VPN from Poltava, Ukraine at 2am local time? Wait a minute. You don’t have any operations in Ukraine and the apparent “trusted” user copied data from your payment application server to their laptop. Furthermore, that particular user logged off from his office in San Diego just six hours earlier. It becomes clear that just seeing your VPN server and perhaps even watching for unauthorized access isn’t enough.

Capturing valuable contextual data such as direction, bytes in/out, geolocation information, impacted hosts and applications, universal time, etc., and storing it in a single, highly accessible and searchable data structure is critical to truly securing your enterprise. LogRhythm provides over 40 metadata fields to capture such context with powerful tools to tap that information for unprecedented insight and awareness.

We’ll be steering clear of turnip trucks and continuing to build truly best-in-class Log Management and SIEM 2.0 solutions (and keeping things in context).

 

Tags: , , ,

1 Comment | General

 
 

PCI 2.0 Preparedness

The PCI Security Standards Council is due to release the 2.0 version of the PCI Digital Security Standard (DSS) and Payment Application-Data Standard (PA-DSS) the end of October, 2010. For LogRhythm, this is a very important event as many of our customers must comply with PCI regulations. LogRhythm’s current log and event management and File Integrity Monitoring capabilities for PCI will meet the same requirements in PCI 2.0 and we are updating our compliance reporting package to reflect upcoming modifications and a new numbering schema. With that understanding, let’s investigate the highlights of PCI 2.0 posted at https://www.pcisecuritystandards.org/pdfs/summary_of_changes_highlights.pdf.

PCI-DSS imageA very reassuring statement from this guidance is on the second page, “Stakeholders will notice that the changes to PCI DSS 2.0 and PA-DSS 2.0 are relatively straightforward and do not introduce significant changes.” Hold that sigh of relief for the moment; the areas where changes occur do have an impact on log management.

Payment applications must now support centralized logging. For log management, the area of greatest impact will be that PCI PA-DSS requirement 4.4, which now requires payment card applications to “support centralized logging, in alignment with PCI DSS requirement 10.5.3″. PCI DSS requirement 10.5.3 specifies that logs must be copied to a tamper resistant central repository or media.

This might raise several red flags, such as “Are we capable of collecting logs from our payment card applications?” or “Will our organization be able to monitor these collected logs in compliance with PCI DSS 10.6?” PCI-DSS requirement 10.6 mandates that you “Review logs for all system components at least daily.” With so many payment card applications coming from a wide diversity of vendors, it would be expected that custom rules and processing would be needed to support them.

If you have LogRhythm already you can relax, because compliance with central logging of payment card applications is supported today. LogRhythm can pull application logs using a number of techniques, including Microsoft Event Logs, ASCII files, ODBC connected databases, Syslog and SNMP. In most cases, the applications that already comply with PCI PA-DSS 1.2 requirement 4 will not need to be reprogrammed to meet PCI PA-DSS 2.0 and in any case, the flexibility of LogRhythm means that you will be able to collect logs in whatever format the application uses.

Once log collection is complete, processing of the logs is highly recommended in order to prove proper monitoring to the QSA. Both interviews and visual confirmation are required for satisfying PCI DSS 10.6, so simply pointing to unprocessed logs might raise concerns. Using LogRhythm’s custom rule builder, support for the custom or small install base applications can be built by your organization’s LogRhythm administrators and analysts.

While we can already collect the raw logs, if your organization would like to tap LogRhythm’s Knowledge Engineering team for development of custom normalization rules for your credit card application, a fix-fee service exists for expedited rule development, let us know.

Tags: , , ,

1 Comment | Compliance

 
 

Compliance buys the steak, but where is the sizzle?

Another meeting or WebEx demo is scheduled – things are busy for me six months in as Sales Engineer for LogRhythm in the UK.  I dial into the conference call and off we go.  The first question that normally gets asked by one of my enthusiastic sales colleagues is “what’s the driver for the project…?”  To date the answer is usually “compliance“.

I’ve worked with enterprise networks for over 10 years now and was responsible for designing, deploying and managing a large network for a leading Managed Security Services provider. When I designed the network, I paid no attention to log and event management. I knew that each of the products and technologies created logs and had their own management interface to allow me to view that information if needed. From what I’ve seen, this isn’t an uncommon approach. It then happened……

… Friday night @ 17:00hrs, my phone rings and it’s one of the sales managers on the phone: “Hi, can you create a report showing when John Doe has logged into the network over the past two weeks?”  Ok, this isn’t too much of a task for me I think, I can simply log into the domain controller and take a look at the security logs, export the information to excel, manually edit it and create a report. Then the same sales manager asks “I also want to know what websites John Doe has visited whilst logged into the corporate network.  Oh, and can you tell me if they have also logged in remotely over the VPN?  If I can have the reports on my desk Monday morning, that would be good.” All of a sudden the fairly simple task becomes more complicated and will require the use of various different GUIs, tools and lots of my weekend!

…Back to the demo: As I walk through the console showing the customer how easy it is to run an investigation against any or all of the log sources, showing how to use the common events and classifications to apply filters (Origin Login = John Doe, Classification = Authentication Success) to the log data that LogRhythm has enriched and normalized, I then show how easy it is to use the displayed data

example of a log

and create a graphical report.

I continue to demonstrate the power of tail in a troubleshooting or activity monitoring scenario and apply a filter showing URL and Origin Login = John Doe and we sit there in real-time watching the user’s activity.  It’s about this point that the pin drops.

 

Yes the driver might be Compliance, but it’s the additional operational features and visibility that LogRhythm provides that gets the technical operations team excited and actually sells the product more often that compliance on its own.

I wish I had paid more attention to my SIEM requirements when I designed the MSSP network all those years back. If I had I would have made it home much earlier that Friday night!

 

Tags: , , ,

0 Comments | Compliance

 
 

Compliance – Time to Change the Future

groundhog day imageHe’s having the worst day of his life… over and over again.’

Ring any bells? It’s the strap line from the film Groundhog Day which sees Bill Murray’s character, Phil Connors, caught in a time warp – repeatedly waking up to find that things are exactly the same as the day before.

The film charts Connors’ frustration at being faced with the same situations every single day and seemingly unable to start the next day afresh.

Whether it’s travelling the same daily commute, or having repeated discussions about the latest information security regulation directive, I’m sure we’ve all related to that character at some point. Particularly if you are a miserable old curmudgeon like me (in fact I think you will find that Bill Murray based his screen persona on yours truly….)

With a seemingly endless list of new or amended regulations being introduced, it’s no wonder that IT security professionals can often feel like they’re stuck in their own Groundhog Day.  No sooner does an organisation achieve compliance for one regulation, than another comes along, often bringing with it a sense of déjà vu for all involved.

Take the Payment Card Industry Data Security Standard for example. The first standard was introduced in December 2004, with the most recent revision in 2008, and an updated version due this October.  As such, the regulation seems to have been around for an eternity and it’s no wonder that mentioning the subject will trigger a glazed response from many in the industry.

This rings even more true in the public sector where there seems to be a never ending stream of new initiatives and guidelines relating to information management and technology infrastructures. In the UK alone, organisations are faced with, for example, GSI/GCSX, CoCo compliance and latterly Memo 22 replacement, Good Practice Guide 13 (GPG 13.)

Information security is an ever changing beast. As technology evolves, so do the risks posed which is why it’s imperative that organisations -public and private – don’t become complacent when it comes to compliance.

As Bill Murray found in Groundhog Day, the only way to escape the monotony of his time warp was to re-assess his attitude to life. Of course I’m not suggesting for one minute that we turn our lives upside down, but there’s a lot to be said for taking a proactive approach when it comes to guarding against risk.

In every information security related regulation, there’s a requirement in some shape or form to protect the information being held by the organisation – from credit card details to children at risk records.  Despite this, all too often security incidents are discovered after the event, once the damage has been done.

Protective Monitoring tools such as LogRhythm’s bring a new proactive dimension to information security-fulfilling multiple compliance requirements in the process.  By centralising and automating how log data is managed, organisations can gain a clear insight into network and user behaviour.  Any irregular activity is automatically flagged in real-time while reporting for compliance purposes is simpler and less time consuming.

As with most Hollywood films, Bill Murray’s ultimate goal was to get the girl. While I can’t guarantee that LogRhythm will bring similar results, it will help ease the Groundhog Day frustrations for those facing the continued compliance struggle.

Unless you’re happy living in Punxsutawney of course….

Tags: , , , ,

0 Comments | Compliance