LogBlog

LogLogic Buys Exaprotect: 3 Reasons Why Customers Win.

By Dominique Levin
VP Marketing & Strategy

Last week LogLogic announced its intend to acquire Exaprotect. In February we had already announced a partnership with Exaprotect to deliver the LogLogic Security Event Manager. In February we also announced LogLogic Compliance Manager, which has since shipped to the general public, and LogLogic Database Security Manager, generally available later this quarter. Now we have added the Exaprotect Change Manager product line. In a mere couple of months LogLogic went from a singularly focused company with leading log management platforms to having five product lines working together to form the most complete security management suite.

So how does this all benefit customers?  The combined product portfolio answers 3 simple questions for customers:

What is happening?

What is important?

What to do about it?

1. What is happening? Log Management and Database Activity Monitoring.

It all starts and ends with log data. You cannot secure or manage what you cannot see. Therefore, first focus on building a central repository of user and system activity. You do this through aggregating, summarizing and archiving log data. Log data can tell you who are accessing your network, systems and even who are seeing, changing or moving individual information objects. Per a recent SANS survey, 99 percent of customers are collecting (or planning to collect in the next year) some log data but for many it is work in progress. Virtually all collect network data (“who is accessing my network?”) and most collect system-level data (“who is accessing my systems?”). For most companies even collecting a complete activity record remains a work in progress. Leading-edge organizations are now turning their attention to understanding activities around business applications, transactions and monitoring access to specific sensitive information objects. This is particularly true for structured information in databases. Databases are a one-stop shop for valuable data. Organized criminals are targeting sensitive data in databases to sell for $300 per record. Since the data is structured, you know where it resides and you can monitor access to these specific records. LogLogic expanded into database activity monitoring with a specialized database sensor. The sensor sees more than you would through native logs, including activities that are triggered by stored procedures, obfuscated queries and such. This is great as a stand alone product, but at the end of the day, database activity should be analyzed in context with all other activity data – hence the convergence of log management and database activity monitoring.

clip_image003

2. What is important? Compliance management and security event management.

Just having the data on a pile is of course not enough. Once you have a central record of activity, you need look at this information. Few organizations are proactive about this. LogLogic compliance management and security event management applications can help. LogLogic Compliance Manager is about deciding who should be looking at what log data when and then enforcing such log review process through software. Compliance is a collaborative process and Compliance Manager facilitates collaboration on pro-active security. It productizes best practices, presents reviewers with an easy in-box of log review tasks and the ability to annotate and score activities. Ultimately the log review scores roll up into a dashboard that presents executives with the overall timeliness of review and a compliance score. It is still human beings who do the bulk of the actual analysis. LogLogic Security Event Manager goes one step further and uses cross-device correlation and contextual analysis with vulnerability and asset data to prioritize suspicious activities automatically. For example, access to a HR database followed by a large e-mail sent, could be suspicious and needs to be investigated immediately.

clip_image004

3. What to do about it? Change management and database security.

Contextual analysis of log data is cool and it can go a long way turning raw log data into actionable information and even into recommendations. However, security Nirvana would be self healing. Increasingly software could make automated recommendations and predictions about unusual and suspicious activities and could prevent bad things from happening in the first place. LogLogic Change Manager and the LogLogic Database Security agent both have the ability to enforce security policies. Most customers aren’t quite ready to automatically re-configure a firewall policy based on a security alert, but at some point in the future as predictions become more accurate, automatic remediation will become a reality. One area where automated prevention is a reality is in database security. About 20% of database security customers also turn on active blocking. It makes sense that blocking would be more prevalent with systems that can do fine-grain monitoring. It is tricky to kick somebody off the network wholesale based on a security alert. There are still too many false positives. If you get it wrong you seriously hurt productivity. That is not a good thing ever, but especially not in an economic downturn. Most organizations prioritize productivity over security. It is much more acceptable however, to block access to a specific piece of information based on suspicious activity.

In summary, with the addition of Exaprotect, LogLogic can better protection information at a lower cost. This is good news at a time that few customers can afford to maintain the staff and budgets to integrate many disparate point products.  Unified security management also leads to better information protection. Pro-active security monitoring (LogLogic Security Event Manager and LogLogic Compliance Manager), combined with fine grain monitoring (LogLogic Database Security Manager) leads to more accurate prevention (LogLogic Change Manager and LogLogic Database Security Manager) and better information protection.

Posted by Dominique Levin on April 27, 2009 in Compliance , Log Management & Intelligence , LogLogic News , Security | Permalink | Comments (0)

Top 3 mistakes of PCI requirement 10 (part 2)

By Dimitri McKay

In my previous post, I talked about the number three PCI requirement mistake, which is thinking that PCI is about check boxes, not about security and accountability. You can read more about that here:

This is the second part. The “Post Audit Follow Through”.

Once the audit is over, there’s still work to do. Logging all new devices, reading daily reports and following up on report results is just as important as the initial audit. You must monitor those reports every day! You must be aware of those deviations from norm, those thresholds being crossed, those anomalies being detected. It’s time to dig deeper!

Let me give you an example. I had a customer who over the course of 6 months had every server on his network fail two logons in a row every day. Prior to setting up his log management tools, he had NO visibility of it. None. What had been causing this event was a dictionary attack, and the crafty hacker knew that 3 logon failures = account lockout. By attempting twice per day for each machine, he was able to stay under the radar, not lock out any accounts, and continue the silent attack.

By reviewing the alerts, by reviewing the reports, by doing due diligence you’ll have visibility into these sorts of events.

The job of a security engineer is a continuous path. There is no finish line. The audit isn’t going to be the end, but rather the starting point. The audit is going to help you identify what is up to par and what needs work. From there, you now have another path to travel.

Stay tuned for the final piece, the Top 3 Mistakes of PCI Requirement 10.


Posted by on January 15, 2009 in Compliance | Permalink | Comments (0)

Top three PCI compliance mistakes of Requirement 10

By Dimitri McKay

As an SE for LogLogic, I talk PCI (the payment card industry’s PCI-DSS) several days a week. I talk about requirement 10, I talk about retention requirements, I talk about evidencing log management. Out of all the common industry mandates and government compliance requirements, PCI exists as the one with the sharpest teeth. PCI can affect the purse by issuing fines, or raising the card swipe rate percentage.

With that, I’d like to talk quickly about the three most common PCI compliance mistakes of Requirement 10. This will hopefully aid in alleviating your headache from auditors, the headache of upper management and the headache of the Payment Card Industry.

Number 3: PCI Compliance isn’t about check boxes, it’s about security and accountability:

PCI Compliance isn’t about pleasing auditors and going through the list to mark yourself compliant. Sure, that's part of it, but the reason PCI exists is to secure your business from threat, secure your business from breach, secure your business from outside intruders. I’ve seen pre-sale customers run through a proof of concept of a log-management tool just to get through an audit. They then return the tool, immediately dropping Requirement 10, and dropping out of compliance. I found this to be absolutely insane. Here’s why.

We had a customer who was a high profile target. They had all the toys: the SIEM, segregated networks, tons of security, IDS/IPS, etc. Well, they were breached. Somehow, some way the attacker got in, got to their DB, and pulled a ton of account records: name, address, social, credit cards, etc. Now, in a situation like this, the customer had NO idea what was affected. Were his routers/switches/firewalls compromised? Their policies? Were their IOS’s re-written with a backdoor? The security officer had no idea. How about the servers on that network? Rooted? Compromised? Who knows? The scope of the breach was completely unknown. To identify a scope, most businesses would need to bring in a forensics team, go through a mountain of log-data, and identify the scope. However, as a LogLogic customer, they were able to go back and scope the breach based on the attacker's IP address(es) immediately. In a couple hours they knew where, when and how the attacker gained access. They knew what machines were affected, they knew what database was breached, they knew what user data was stolen. Log data to the rescue.

This is what PCI is about. It’s about security, it’s about doing to the best of your ability what you can to secure your network and, if you are breached, it’s about having the evidence to track down the hacker and, if able, prosecute them. Not just about check boxes, or passing audits.

Posted by on January 11, 2009 in Compliance | Permalink | Comments (0)

Tough Security Questions for SaaS Providers - Part 2

[ Originally posted at OnSaaS ]

This is part 2 of the tough security questions for SaaS providers. In part 1 of the series, we asked the following questions:

1. Data Locality - Where's my data?
2. Data Segregation - How is my data segregated with other customers, potentially my competitors?
3. Data Access - Who can access my data in your company?
4. Access Audit - Who has accessed my data and where's my access logs?

We are continuing this discussion with the following questions in part 2.

5. How are the users authenticated and authorized?
6. Web Application Security - How secure is the SaaS provider's web application?
7. Data Breaches - How do you protect my data from insider breaches?
8. PCI DSS - Are you compliant with PCI DSS?

5. How are the users authenticated and authorized?

Companies have spent hundreds of man years and millions of dollars trying to setup single-sign-on systems inside the corporate firewalls. Most companies, if not all, are storing their employee information in some type of LDAP servers. In the case of SMB companies, a segment that has the highest SaaS adoption rate, Active Directory seems to be the most popular tool for managing users. In many cases, companies have designed their IT infrastructure so that all authentication, including VPN, web proxy, file server, and others will go through this single infrastructure. The process of employee onboarding and termination is much easier this way.

Just as companies start to have some success, the advent of the SaaS model changes the scenario again. With SaaS, the software is hosted outside of the corporate firewall. Many times user credentials are stored in the SaaS providers' databases and not part of the corporate IT infrastructure. This means SaaS customers must remember to remove/disable accounts as employees leave the company and create/enable accounts as come onboard. In essence, having multiple SaaS products will increase IT management overhead.

SaaS customers will start asking questions on identity and access integration and providers would be wise to design such features in early on. For example, SaaS providers can provide delegate the authentication process to the customer's internal LDAP/AD server so that companies can retain control over the management of users.

6. Web Application Security - How secure is the SaaS provider's web application?

One of the "must-have" requirements for a SaaS application is that it has to be used and managed over the web (in a browser.) This creates an interesting scenario. In the on-premise scenario, when a vulnerability is found, at least you have your firewall protecting the application so you may get a bit more time to patch it (assuming the application vendor provides the patch in a timely fashion.) However, in the SaaS world, there is no such luxury. Any vulnerability identified can potentially have detrimental impact on all of the customers. Even leading security companies aren't immune to security holes in their web applications.

Web application security is quite a hot topic these days and it's discussed by many security researchers such as rmogull and RSnake. Here's an interesting article on "What web application security really is".

Verizon Business recently released their Verizon Business 2008 Data Breach Investigations Report. Of all the breaches, 59% of the breaches involve hacking, with the following breakdown:

  • Application/Service layer -39%
  • OS/Platform layer - 23%
  • Exploit known vulnerability -18%
  • Exploit unknown vulnerability - 5%
  • Use of back door -15%

Attacks targeting applications, software, and services were by far the most common technique, representing 39 percent of all hacking activity leading to data compromise. This follows a trend in recent years of attacks moving up the stack. Far from passé, operating system, platform, and server-level attacks accounted for a sizable portion of breaches. Eighteen percent of hacks exploited a specific known vulnerability while 5 percent exploited unknown vulnerabilities for which a patch was not available at the time of the attack. Evidence of re-entry via backdoors, which enable prolonged access to and control of compromised systems, was found in 15 percent of hacking-related breaches. The attractiveness of this to criminals desiring large quantities of information is obvious.

Currently there's really no mandate or requirement for SaaS providers to provide detailed security analysis of the SaaS application. However, it would be wise for the SaaS providers to start considering something similar to what PCI DSS has required of the merchants:

  • 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
    • 6.5.1 Unvalidated input
    • 6.5.2 Broken access control (for example, malicious use of user IDs)
    • 6.5.3 Broken authentication and session management (use of account credentials and session cookies)
    • 6.5.4 Cross-site scripting (XSS) attacks
    • 6.5.5 Buffer overflows
    • 6.5.6 Injection flaws (for example, structured query language (SQL) injection)
    • 6.5.7 Improper error handling
    • 6.5.8 Insecure storage
    • 6.5.9 Denial of service
    • 6.5.10 Insecure configuration management
  • 6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
    • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
    • Installing an application layer firewall in front of web-facing applications.

Additional sources of information provided as a starting point for more information on web application security would include


Trey Ford of Security Spin Control has a fairly good explanation of the recently released PCI information supplement on requirement 6.6.

SC Magazine also has an article on Deconstructing PCI 6.6 for the management folks.

7. Data Breaches - How do you protect my data from insider breaches?

In the Verizon Business breach report blog, Verizon Business stated that

While criminals more often came from external sources, and insider attacks result in the greatest losses, criminals at, or via partner connections actually represent the greatest risk. This is due to our risk equation: Threat X Impact = Risk
  • External criminals pose the greatest threat (73%), but achieve the least impact (30,000 compromised records), resulting in a Psuedo Risk Score of 21,900
  • Insiders pose the least threat (18%), and achieve the greatest impact (375,000 compromised records), resulting in a Pseudo Risk Score of 67,500
  • Partners are middle in both (73 39% and 187,500), resulting in a Pseudo Risk Score of 73,125

Many SaaS advocates claim that SaaS providers can do a better job at protecting the customers' data. Unfortunately, just because the data is now in the cloud, it does not reduce the risk of insider breaches. Insiders still have access to the data, they are just accessing it a different way. Just because the data is in the cloud, the responsibility of segregation of duties and access authorization still fall on the customers, not the SaaS or cloud computing providers. So yes, it may reduce the chance of insiders getting direct access to, say, a database, it does not in any way reduce the risk of insider breaches. In fact, it may even increase the possibility as you now have to take into consideration of the cloud or SaaS providers’ employees. They have access to a lot more information and a single incident could expose information from many customers.

SaaS providers should be prepared to answer questions on what tools and processes are utilized to ensure segregation of duties and protect from insider breaches. Remember, in the case of the mult-billion dollar insider incident at Société Générale, IT management had implemented all of the controls recommended by auditors, but nobody was monitoring them. So it's extremely critical to be able to show the processes around these security controls.

8. PCI DSS - Are you compliant with PCI DSS?

PCI DSS has a specific section for hosting providers (including SaaS providers):

Requirement A.1: Hosting providers protect cardholder data environment

As referenced in Requirement 12.8, all service providers with access to cardholder data (including hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that hosting providers must protect each entity’s hosted environment and data. Therefore, hosting providers must give special consideration to the following:

A.1 Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, as in A.1.1 through A.1.4:


  • A.1.1 Ensure that each entity only has access to own cardholder data environment
  • A.1.2 Restrict each entity’s access and privileges to own cardholder data environment only
  • A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10
  • A.1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.

A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not necessarily guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

Simply put, SaaS providers must be compliant with PCI DSS in order to host merchants that must comply with PCI DSS.

We will continue with our tough security questions in part 3 of this series.

Posted by on July 07, 2008 in Cloud Computing , Compliance , SaaS , Security | Permalink | Comments (0)

Tough security questions for SaaS providers - Part 1

[ Originally posted at OnSaaS ]

We will be writing a series of blog posts on the tough questions that SaaS providers can expect to get from customers or they should ask themselves. The questions will span many different areas including security, compliance, sales, marketing and operations. This is Part 1 of the security questions.

As we mentioned previously here, one of the biggest obstacle to enterprise SaaS adoption is the issue of trust. Customers are asking SaaS providers "Can I Trust You?!" The security analysts and warriors are asking similar questions.

Some SaaS advocates have argued that concerns for SaaS security are just red herring. It is true that, to date, there hasn't been any major breaches amongst SaaS providers. However, we have already seen some activities such as the breach at Salesforce.com. In addition, we have seen many anecdote evidence that multi-tenant architectures in the B2C (e.g., Flickr, YouTube) world are prone to data leakage.

One may argue that these are consumer sites and are not relevant for the SaaS providers. However, the same technologies and architectures are being used in both the consumer and enterprise world. In fact, as the trend of IT consumerization continues, we will see more and more of the consumer technologies being used in enterprise applications. Think about it this way, what if this Salesforce.com and your customer list popped up in your competitor's screen?

SaaS providers should be prepared to answer security questions from customers and enterprises. Here are a list of questions that SaaS providers will likely get asked during customer trials/evaulations.

1. Data Locality - Where's my data?

Due to compliance and data privacy laws in various countries, locality of data is of utmost importance in many enterprise architecture. For example, in many EU and South America countries, certain types of data cannot leave the country because of potentially sensitive information. In addition to the issue of local laws, there's also the question of whose jurisdiction the data falls under when an investigation occurs. In most cases, the government where the data is housed will likely win. A good example of this type of concern is when the French cabinet banned the use of Blackberry devices.

Many enterprises have architected around these issues for the on-premise software they install. However, with cloud computing and SaaS, this issue is even more exasperated. In a cloud computing environment, sometimes you don't know where your data is stored or where your application is being run; and some proponents of cloud computing are also saying that you shouldn't have to worry about where the computing resources are as long as your application is running and behaving as it should. However, other leaders in the cloud computing space are taking note of the data privacy and locality issues. For example, Amazon recently announced the availability of an European S3 cloud, and Salesforce.com is also planning Singapore data center.  

Given the regulatory compliance and data privacy concerns, SaaS providers should be ready to answer tough questions about where their computing resources are and will customer data be ever transferred outside to another jurisdiction with different laws.

2. ata Segregation - How is my data segregated with other customers, potentially my competitors?

Everyone's talking about the benefits of multi-tenancy in the SaaS world, but many seem to ignore one of the biggest security concerns, mixing customer data together, that came along with multi-tenancy.   

One of the reasons that hampered SaaS adoption initially was trust. End users must trust that the SaaS providers have the best security in place to protect their data and never expose their data to anyone outside of the authorized domain. Therefore, the ability to segregate data by end customer is a critical requirement for the SaaS providers. There are many architectural methods in segregating the end customer data. At the end, the requirements come down to that users must never see the data that they are not authorized to see, and that end customer's data should never be exposed to other end customers. 

Saas Providers would be wise to consider data segregation early on in the architectural design. For most ISVs turning into SaaS providers, this is an unfamiliar territory and should seek guidance if possible. SaaS providers should also understand the customer concerns and address them early on.

3. Data Access - Who can access my data in your company?

Enterprises have spent hundreds of thousands of dollars on identity and access management systems, log management systems and other software to ensure that employees access only information they are allowed. Within the confines of their firewalls, IT organizations may feel that they have the situation somewhat under control. The advent of SaaS have changed that. With the company data outside of the firewall and in a "cloud," IT organizations no longer can control who and when their data-in-the-cloud will be accessed. Without visibility into the cloud, IT organizations are accepting a much bigger risk compare to when everything's inside the firewall. Even though many SaaS providers have offered various capabilities such as authentication integration with customers' own LDAP servers, this perception of lost control is a difficult hurdle to get over.

SaaS providers offering cloud services, whether it's infrastructure, platform or application, should accept the responsibility of protecting customer data as a single breach could affect all of the customers. SaaS providers must be prepared to help customers understand their security policies on user access, activity monitoring as well as segregation of duties.

4. Access Audit - Who has accessed my data and where's my access logs?

The last few years we have seen a rise of log management and SIEM solutions aimed at compliance-aware organizations. These products is responsible for collecting, analyzing, correlating, archiving and reporting on all activities happening inside an IT infrastructure. Part of the reason these products became such a success is because of the need to track and monitor user activities in the world of regulatory compliance. In addition to compliance, IT organizations use logs to help them identify security issues, perform troubleshooting and forensics analysis, and analyze traffic and user patterns.

With software in the cloud, network, system and application logs are no longer easily accessible by IT organizations. They either have to negotiate access to these logs during contract time, or they have find new ways of monitoring user activities. Given that the IT organizations don't "own" the software, it makes it even more difficult to "hack" around the system. Without access logs, IT organizations may not be able to answer simple questions from auditors, such as "who have accessed the financial information in the past quarter?"

Knowing how critical access logs are to compliance, operations and security matters for IT organizations, SaaS providers should consider providing access logs as a part of their normal service or have it as an option for customers. As an example, Amazon's S3 service offers options to enable and download access logs.

We will continue with our tough security questions in part 2 of this series.

Posted by on July 07, 2008 in Cloud Computing , Compliance , SaaS , Security | Permalink | Comments (0)

Anton Logging Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

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. One of the bloggers called it "pay it forward" to the community.

So, Anton Logging Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

This tip digs into a seemingly simple, but really VERY esoteric subject: monitoring file access and modification via a Windows event log. Now, some people - who never studied this subject - tend to have a very simplistic view of this: just enable Object Access auditing, then right-click on a file or directory, click Security->Advanced->Auditing and then pick what types of events will be logged and by what accessing entities (i.e. users or computers). OK, so this will produce some logs, that is for sure. But are they useful?

First, why are we doing this? We typically need to know the following when we audit file access in Windows (or any other OS for that matter) for security (monitoring and investigation) or compliance:

Can we get this from the above logs? No.

What? No!?! Really?

Yes, really. We can get some of the above, some of the time, not all of the above, all of the time. Here is an example, we are looking at event ID 560 (picture) and then at an extract from its description field.

Event:

event_log560_1_thumb

Description (selected field):

Object Server: Security

Object Type: File

Object Name: C:\0\TestBed\simple_text_file.txt

Image File Name: C:\WINDOWS\system32\notepad.exe

Primary User Name: Anton

Primary Domain: XXXXXX

Accesses: READ_CONTROL

SYNCHRONIZE

ReadData (or ListDirectory)

WriteData (or AddFile)

AppendData (or AddSubdirectory or CreatePipeInstance)

ReadEA

WriteEA

ReadAttributes

WriteAttributes

 

WTH is that? Well, we know that the user  'Anton' has successfully read? wrote? changed attributes? did something? with a file named "C:\0\TestBed\simple_text_file.txt" using a program named "C:\WINDOWS\system32\notepad.exe." That's the best we can get, in this case! We may try to look at event IDs 562 and 567, but this missing information (i.e. the exact action performed) will not be added.

BTW, there will be  a few more dozen (sometime hundreds!) of the 560s, 562s and 567s  produced - all from just opening the text file in a notepad. The above event is notable for having BOTH "notepad" and "simple_text_file.txt" in the same event; others will have either of the two.

Anything else gets in the way? Yes, lots! MS Office will write to all files, even just opened for reading (with no user modifications to the content whatsoever), which will screw up your log monitoring efforts. If the file is on a share, more information will be missing (e.g. username might be).

So, how to use Windows event logs for file access tracking?

  1. Enable logging (as described above)
  2. Pick events 560 (most useful) and 562, 567 (useful too)
  3. Look for fun filenames that might be touched by the users (have a list of files and users handy)
  4. Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
  5. Ponder the 'Accesses' section of each event until your brain turns blue :-) or until you decide whether such access is authorized or not...

Overall, this is still very useful for file access monitoring, but the process is somewhat painful.

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

Technorati tags: , , ,

Posted by on May 08, 2008 in Compliance , Innovation , Log Management & Intelligence , Security | 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:

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:

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:

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!

Technorati tags: ,

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

From Log Apathy to Log Enlightenment

So, I was talking to this small log management vendor the other day and he confided to me that his product faces fierce competition in his target market (which is, important to note, small to medium companies with 10-100 systems): and this competition is apathy.

More specifically, his prospects either just blow him off by saying "pah, who needs logging!" or they profess their undying love of all things logging - and then still don't buy his product (which is priced, shall we say, "to go")

Admittedly - and somewhat tongue-in-cheek, these are the same companies that form the core of today's botnets (due to various reasons including their scarce resources) and enable RBN to deliver high-quality malicious services to criminal enterprises worldwide. Still, if you happen to have thoughts along the line of "who needs logs?" or "ah, logging? it will come later!", you really deserve a nice fat check from RBN and other malicious "hacking" syndicates since it is extremely likely that your overall attitude towards security is just as misguided...

But how to progress from such ... what was before the Stone Age? ... Sharpened Stick Age? to modernity? Most companies go through the following stages in regards  to their logging:

  1. Deep log ignorance: "Logs? What are those?"
  2. Shallow log ignorance: "Later...later...later... #37 on the TODO list."
  3. Log collection: "We gather and store dead log data...cold."
  4. Log searching: "We will dig into the pile when we have to ... hopefully never!"
  5. Log analysis and reporting: "We know our logs - and what they mean"

(also see my post "Natural Flow of Log Management" for some specifics)

Of course, compliance (PCI DSS and others) helped move people from 1. and 2. to 3., but, sadly,  people often get stuck at 3. (just collection) or 4. (collection  + maybe search) and never progress to Logging Enlightenment of 5.

Yes, PCI DSS and other regulations mandate not just log collection, not just dead cold log storage, but also log review (daily, in case of PCI DSS Requirement 10), but "review" happens to be the item that gets overlooked  all too often.

Why is that?

I think the reason is that log analysis is still too hard and still not automated enough for an average organization. Yes, I did see some corporations that built their own log analysis systems that - surprise! - exceeded the best available from the vendors [at the time]. However, a typical company IT department would not have Ph.D. poring through hardcore text mining research papers in order to improve their home-grown log analysis AI. They expect the vendors to  eat the logs, chew on them for a bit - and then spit out the answers.

Are we there yet? No, but we will be!!!

Technorati tags: , ,

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

RSA 2008 Summary

So, RSA 2008 has come and gone.  Now that everybody has recovered from the information overflow, it is time for summaries and reflections. Before we begin, go read my RSA Impressions (Part 1,2,3,4). Next, read what others said about RSA 2008 (via my del.icio.us feed). Then reflect on past RSA shows (2006, 2007).

Ready now?

First, what was the theme? Unlike in the past, I personally couldn't pick any. The candidates were GRC (and compliance + risk management) , DLP (and other data-leak/-theft technologies), IAM (and identity enablement), but none quite measured up to being a show "theme."

What I saw too much off? Even though their numbers have shrunk, I still saw too many NAC vendors there (Lockdown, here we come!). One of my friends joked that there were more "GRC vendors" than NAC vendors, but both were in low enough numbers to make it a trend. As far as loud noises back from RSA 2007, "identity-driven this or that for security" was still very visible. What is also bizarre is that people still start log management companies. I saw a couple of new ones - amazing, isn't it? Yes, it is a hot space, but come on! Accept that LogLogic is the leader and be done with it :-)

Overblown messages? "Information-centricity." It was cool and hot :-) and new when Hoff said it.  But when it trickled down to keynotes of some "trailing edge" vendor executive, it became boring and stale. And, while we talk about "information centricity" people must still worry about "A" (availability) first (see this discussion).

What I didn't see enough of? VOIP security. Somehow this previously hot trend is quieted down. Also, I saw a lot of web application security vendors, but I think that is still not enough as this is an area with a raging fire, not just "some hotness." Also, I expected to see more vendors messaging around (and, actually helping with!) fraud. Dan Geer's Verdasys kinda mentioned that, but pretty much in passing. Is fraud handled outside of security (and thus out of RSA)? I am not sure.

What I didn't see at all? I didn't see much "market consolidation" - no huge deals, no vendors of note "taken out", etc. Still a huge number of security companies around ... some with products that seem deeply out of touch with today's threat landscape.  One of the speakers said that nowadays "no single security pure-play expected to change the world", but it sure seems like many will try!   Along the same line, Mike R said that such shows are 18-24 months ahead of what "normal" people deploy. This might explain the VOIP and other missing items.

As I said before, "consumerization" of IT - i.e. IT infrastructure, servers, laptops, storage, services, computing resources, applications, etc provisioned outside of IT departments was an elephant in the room. It is not simply "unmanaged IT" or "consumer-grade IT for business", it is the whole "not-IT-department IT" phenomenon. Yes, via mashups it even includes "non-IT application development" (read this fun 451Group report on that). Security implications of this are nothing short of ginormous.

In light of this, I liked how one presenter said this: "we lost the desktop" - meaning "1/3 is managed by users [not IT], 1/3 is unmanaged and 1/3 is compromised/ "managed" by hackers."  Sad but true... Dave Aitel used to joke how in the future banks will have to "re-compromise" your PC so that some temporary security can be established for you to transact business with them. Are such horrifying times upon us already? Maybe desktop virtualization will help with this ...

Overall, RSA 2008 show was an enjoyable, enlightening and thought-provoking experience, as usual. I've heard it was the same even for people who didn't attend a single presentation - indeed, RSA is about people, not slides...

See you next year at RSA 2009!

Technorati tags: , , ,

Posted by on April 16, 2008 in Compliance , Innovation , Log Management & Intelligence , Risk Management , Security | 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!

 

Technorati tags: , , ,

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

NERC CIP Rules Out - Logs In!

NERC security rules [PDF], that were updated and became mandatory last week, might well become "a new PCI DSS" and trigger "a golden age" of security in the energy industry: the rules are mandatory, they are specific (more specific than a lot of other regulatory security guidance) and there is an enforcement body (NERC) that can make life miserable for those not complying. 

Here are some log-related examples from the guidance:

"R5.1.2. The Responsible Entity shall establish methods, processes, and procedures that generate logs of sufficient detail to create historical audit trails of individual user account access activity for a minimum of ninety days. "

"R6.4. The Responsible Entity shall retain all logs specified in Requirement R6 for ninety calendar days."


"R6.5. The Responsible Entity shall review logs of system events related to cyber security
and maintain records documenting review of logs. "

So, again: have logs, retain them ("Top 11 Reasons to Collect and Preserve Computer Logs") and review them ("Top 11 Reasons to Look at Your Logs"). Or, better, have a log management tool do it for you!

 

Technorati tags: , ,

Posted by on January 24, 2008 in Compliance , Log Management & Intelligence , 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:

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):

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!):

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.
Technorati tags: , , ,

 


Posted by on November 30, 2007 in Compliance , Log Management & Intelligence , LogEd , Security | 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].

Technorati tags: , ,

 


Posted by on October 05, 2007 in Compliance , Log Management & Intelligence , LogEd , LogMatters | Permalink | Comments (0)

Breaches Rise - PCI DSS Enforcement Lags

The Computing Technology Industry Association (CompTIA) recently commissioned a survey of IT organizations regarding the severity of security breaches within their IT environments. Given all the publicity surrounding compromised systems over the past year, the results are hardly surprising - the severity level is on the rise. Timothy Prickett Morgan of IT Jungle provides a good survey synopsis here ( http://www.itjungle.com/tlb/tlb092507-story08.html).

Here's a stat that should grab your attention -- Across all companies, the average cost of dealing with a security breach was $369,388, with a number of large companies with breaches that cost more than $10 million each thus skewing the average. That's a hefty price stemming from various kinds of malware and human mistakes.

Now that the Payment Card Industry Data Security Standard (PCI DSS) deadline has passed (see story here - http://www.scmagazineus.com/Visa-PCI-deadline-looms-for-tier-one-merchants/article/35880/) and a significant amount of large companies still haven't completed PCI compliance work, you can expect a fair amount of finger pointing in the near future as organizations fail external audits.

LogLogic's Anton Chuvakin posed some great questions sure to fan the coming PCI DSS blame game flame ...

1) Who is ultimately responsible for data loss: merchants, banks, customers  or ...?

2) Is Visa/MC PCI DSS too onerous, not enough or just "common sense" security?

No simple answers are expected, unfortunately. Penny (or perhaps $10 milion dollars in PCI fines?) for your thoughts?

Technorati tags: , ,

Posted by on October 03, 2007 in Compliance | 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)

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:

Technorati tags: ,

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

Log management in the age of compliance

ComputerWorld features a story by Anton on Log management in the age of compliance. Here are a few highlights:

There are a variety of other regulations that call for log management capabilities, although less explicitly than the aforementioned three. California Bill 1386 and its upcoming federal equivalent, for example, require a state agency, person or business that owns or licenses computerized data that includes personal information to disclose any breach of the security of the data to any California resident whose unencrypted personal information was acquired by an unauthorized person.

Logs, which by nature allow for tracking IT infrastructure activity, are the best way to assess if, how, when and where a data breach has occurred. Management of these logs is therefore the best way to assess what data has been accessed or stolen and, thus, who needs to be notified.

The major effect the age of compliance has had on log management is to turn it into a requirement rather than just a recommendation, and this change is certainly to the advantage of any organization subject to these regulations. It is easy to see why log collection and management is important, and the explicit inclusion of log management activities in major regulations like FISMA, HIPAA and PCI-DSS highlights how key it truly is to enterprise security as well as broader risk management needs.

Posted by on July 18, 2007 in Compliance | Permalink | Comments (0)

Our Very First Customer

Recently our first customer -- a financial company -- participated in a case study on Log Management as part of the SANS Institute's What Works series. The customer (sorry, we can't share their name) deployed our very first evaluation unit and was our initial beta site. It was facinating to hear Victor Hsiang reminisce about the early days of LogLogic from the customer's perspective -- and how we've evolved as a company, technology -- and now industry since then.

He talked about those first products. What we do well. What we could do better. He says we are mature (shh, don't tell anyone) and responsive. But most of all he says that we have evolved into a product that "helped us move forward in standardizing on one log management solution for "this large financial firm" globally." (Yes, we are blushing.)

Victor also talks about how he uses log management for Compliance (SOX) use case and discusses how the product is being used in live troubleshooting with the company's own customers. Staff's time is being spent on custom reporting, but he also explains that once they had a template and process, is simple. Our software team is particularly pleased he said the interface was "intuitive" and did not require training. (They liked it so much the GUI team is even are trying to use it as an excuse to get an extra day off next week :-)

Our favorite quote?

"It was literally bring the box in, or the appliance, install it in the rack, provide power, IP address it, give it a DNS and a gateway. Then exit the data center and go back to your desk and start to configure your devices to send logs to it. "

Oh and yes Victor, we'll look into that feature request. Check out the case study and 40 minute replay at SANS.

Technorati : , ,

Posted by on June 28, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | Comments (0)

Webcast: Protecting Information Assets

Most enterprises are worried about protecting critical confidential information and customer data. How are you doing it? What are industry best practices for securing infomation assets?

Join us during a daylong event on securing your data at SCMagazine -- along with our partners NetApp and Websense -- on a webcast on June 20, 2007 from 10:30 am PST / 1:30 pm EST. The event will cover such log management topics as:

Aggregating and storing a "fingerprint" of all systems and user activity.
Learn best practices and mandates for log data retention.
Monitoring access to information stored in your enterprise.
Understand how to alert and report on the flow of information across multiple systems and platforms.
How does log data work together with information leakage solutions to prevent privacy violations?
How can you protect chain of custody and ensure that the information will stand up as evidence in the court of law?
How quickly should you be able to produce and share reports?
What are common reports and alerts being used for information asset and compliance enforcement?

Log data is the digital equivalent of a surveillance camera. It functions a deterrent and also provides legal evidence to prosecute those who leak or steal information. In this special Webcast, subject-matter experts from LogLogic, WebSense and NetApp will discuss how organizations can ensure IT Governance, Compliance and mitigate risk with multiple mandates using next generation Log Management and Intelligence, Data Leakage Prevention and high performance and high-security records retention.

Register here.

Technorati : , ,

Posted by on June 19, 2007 in Compliance , Risk Management , Security | Permalink | Comments (0)

National Data Security Laws Evolving

Only about two-thirds of existing state data breach notification laws apply to state agencies according to Bruce Brody, vice president of information assurance at CACI in an article at Federal Computing Week.

FCW asks the question -- Would a federal breach notification law bring greater security and sanity to those who find their personal data has been lost or stolen?

The impact of emerging state laws targeting data security and how government agencies factor into being governed by those laws is quite an interesting read. And joining these local initiatives are a host of proposed national bills. The implications of these laws as well as the impact they could have on non-government organizations is going to be a hot debate. Even we got into the discussion, as our resident expert Anton Chuvakin (also LogLogic's Director of Product Management ) weighs in on the topic in the FCW piece.

Chuvakin notes that while existing state laws are already working to protect consumers, he cautions on the realities a national law could bring with it:

"Because many existing state laws are effectively working to protect consumers affected by data breaches, federal legislators must be careful not to pass a national law that is less rigorous than the laws many states have passed, said Anton Chuvakin, director of product management at LogLogic, a risk mitigation company. Were that to happen, he added, "some citizens could lose the protections they enjoy now."

As we noted earlier this year, ignoring data security mandates could cost plenty. Thanks to very high profile breaches like TJMaxx are not only making headlines, but some consumers are nervous about their data and privacy. And US Congress to the European Commission (EC), along with state initiatives in Minnesota, Texas, and California are popping up to deal with the issue.

Technorati : , , , ,

Posted by on June 12, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

2007 Log Management Survey Detailed

Yesterday, we held a webcast with The SANS Institute to announce the complete findings of the 2007 Log Management Survey. The survey, sponsored by LogLogic for the third year in a row, polled more than 650 IT professionals in government, financial services, banking, manufacturing, healthcare, telecommunications, and education sectors from the North American Global 2000 (G2000) - Forbes's comprehensive list of the world's biggest companies.

The verdict? The G2000 continues to adopt log management and intelligence to end the 'logjam.' Turns out that despite its importance, security is not the prime motivation for log management. More than half of those surveyed reported operations management and monitoring the health of the network as the prime motivation for using log data. And, 43% indicated compliance with SOX, PCI and other mandates as the top priority. Download the Executive summary here or check out the Webcast findings here.


Technorati : , , , ,

Posted by on June 07, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | Comments (0)

California Considers Making PCI DSS Law

This week California is considering a bill that would require organizations that accept credit and debit cards to follow the Payment Card Industry (PCI) Data Security Standard. Noncompliance could mean banks would have to cover the costs associated with notifying customers that their credit card numbers may have been stolen and the cost of replacing credit cards, at a cost that could run upwards of $1 million per breach, according to estimates in a California State Senate report in May that provided details on the bill. The California law would apply to anyone who wanted to do business with a California resident, according to this article at Government Executive blog.

The public backlash after the January disclosure of a major security breach by Massachusetts based retailer TJX has acted as a stimulus for attention and consumer protection mandates. Just last week Minnesota enacted the Plastic Card Security Act, based on the PCI Standard. And other states like Massachusetts and Texas are also considering laws. The Lone Star state's House voted unianimously to approve the PCI-related bill, but the state Senate closed its session before it could vote on the issue.

Log management can help out with complying with the PCI DSS regulations quickly, plugging into your existing IT infrastructure. For some tips, check out 7 Habits of Highly Effective PCI Compliance- a Forrester Webcast with analyst Khalid Kark, sponsored by LogLogic. A PCI book is on the way from LogLogic's Anton Chuvakin later this year.

Technorati : , ,

Posted by on June 07, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

ITIL Gets An Update

ITIL is getting an update after 7 long years. The UK's Office of Government Commerce (OGC) is updating their comprehensive documentation of best practices for IT Service Management. As part of the launch of the new ITIL V3, the organization is hosting a series of roadshows throughout the world beginning today in London -- with stops in San Jose, CA and Chicago, IL here in the US in June.

New ITIL V3 is to consist of 5 central books and an official introduction book, according to the OGC. These incorporate the best of ITIL V1, V2 and tested current best practice for ITSM. The 5 central books are made up of Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement.

CIO.com is featuring a good overview of ITIL with some pros and cons of using the framework. The short version is that ITIL is the industry's most widely accepted approach to IT service management, provides a cohesive set of best practices, drawn from the public and private sectors globally and is supported by field-tested implementation methodologies and assessment tools, certification and accredited training organizations.

LogLogic offers an ITIL Pocket Guide a pragmatic approach to ITIL implementations. There are 50 reports and 45 alerts in the LogLogic ITIL package to get you started with ITIL and Log Management and Intelligence. To obtain a copy of the guide, go here.

Technorati : , ,

Posted by on June 05, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

Why Banks Are Moving to Log Management

Banking Information Security magazine is covering the emerging trend in log management as it makes it way through the banking sector. They profile LogLogic cusomer, Citizens & Northern Bank, a $1.2B bank out of Pennsylvania, that has made log management a requirement for meeting compliance mandates with Gramm-Leach-Bliley and Sarbanes-Oxley. Using log management, the bank's auditors now have a way to easily track and monitor log data and get compliant fast.

Citizen's Bank learned early on what other G2000 companies are now realizing -- log management is inceasingly becoming the weapon of choice in the quest for compliance. Banking, an industry known for security and scrutiny of IT products is joining a growing trend of deploying log management for security, forensics, loss prevention and compliance. Why? As the article explains, the Industry's Federal Financial Institutions Examination Council (FFIEC) says that "without real log management, organizations are out of compliance and at risk" and calls on companies to monitor their log data. From the article,

"As administrators responsible for various network devices and operating systems, we need to know what typical behavior is," says Pete Boergermann, head of MIS at Citizens & Northern. "When we look at events, we are more apt to know what we are looking at and respond."

Read more about Citizen and Northern Bank's log management deployment in this SANS What Works case study from last year. Log Management and Intelligence is on the IT and business agenda. Industry trends are available in the just-released market survey on log management adoption. The LogLogic-sponsored research study with the SANS Institute is available for preview here or join us with SANS for a presentation of the trend at a joint webcast.

The complete article is at Banking Information Security, please note that registration may be required.

Posted by on June 04, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

G2000 Logjam Continues To Spur Log Management Says SANS Survey

We teamed up with the SANS Institute again this year to survey the G2000 on the trends driving log management and intelligence. You can dowload a copy of the preliminary findings of the 2007 Log Management Survey or sign up to attend a webcast presentation of the results with SANS on June 6th.

Based on last year's findings SANS Institute CEO Stephen Northcutt said:

"In our analysis, we found that G2000 IT leaders are today not only validating the use case for log intelligence, but are signaling the increased need for the market to evolve even further with log services that cost-effectively allow them to exchange information with other solutions."

The 2007 survey saw that trend continue to evolve. Polling more than 650 IT professionals in government, financial services, banking, manufacturing, healthcare, telecommunications, and education sectors from the North American Global 2000 (G2000) - Forbes's comprehensive list of the world's biggest companies, key findings:

· Log data monitoring continues to grow exponentially. Of those surveyed over 61% report using log data to assess IT incidents and minimize downtime (an increase of 24% over 2006 survey results).

· Log data retention is up significantly, but most of the G200 and G2000 are still failing to meet compliance regulations. Despite regulatory recommendations or requirements that logs be maintained for three to five years, 11% say they keep log files between 30 and 90 days, 10% retain data for six months and 5% less than 30 days. Remarkably, a full 14% say are not sure how long they keep log data, relying on the system default as defined by their operating system.

· Security while important is not the prime motivation for log management. More than half of those surveyed reported operations management and monitoring the health of the network as the prime motivation for using log data. 43% indicated compliance with SOX, PCI and other mandates as the top priority.

· The quantity of stored log data is rising. 57% percent of survey respondents store logs from as many as 500 sources.

To receive a preview copy of the 2007 Log Management Survey, sign up here. To attend the webcast, sign up at the SANS Institute.

Technorati : , , , , , , ,

Posted by on May 31, 2007 in Compliance , Log Management & Intelligence , Security | Permalink | Comments (0)

The Cost of Reputation In Light of a Security Breach

What is the cost to reputation from a security breach? Well it depends . . .

Over the past few months we've talked alot about TJX and their now-infamous security breach. In fact, a few days ago, InformationWeek reported that TJX Companies, Inc. (the parent company of T.J. Maxx and Marshalls, among retailers) continues to be hit hard by their breach -- which is now being known as the largest customer data breach in history.

In fact, the company announced in its first quarterly earnings statement that it took a $12 million hit (or 3 cents per share), owing the loss to the over 45 million credit and debit card numbers that were stolen from its IT systems over an 18-month period. During their earnings call, TJX went elaborated that they incurred an after-tax charge of $12 million for technical and legal fees related to the investigation and containment of the breach. Part of the costs, too, are for measures that they are taking in reponse to the breach to improve computer security and systems. This is $12M in addition to the $5M for similar efforts that the company reported at the end of the fourth-quarter. This means only one quarter into the new fiscal year, the company has already lost $17 million.

Between the above and a pending class-action lawsuit being filed by the Massachusetts Bankers Association, it stands to reason that the price of reputation is pretty high in response to a security breach. The ROI on proactively preventing breaches is far more tolerable -- and less costly -- for most companies.

Ignoring PCI Compliance could be bad for your business, and risky to boot.


Technorati : , ,

Posted by on May 29, 2007 in Compliance , Risk Management , Security | Permalink | Comments (0)

LogLogic 4 Earns Approved for SCLabs Rating from SCMagazine's Las

We have received the distinction of Approved for SCLabs Rating from SCMagazine for LogLogic 4.Second year in a row. How cool is that? The verdict?

The LogLogic LX release 4.0 is a top-flight product and we continue to award it our Approved for SC Labs rating, the highest rating that we award. Over the coming year it will continue to be our log analysis workhorse

Some highlights from the review. Peter Stephenson writes,


"I have used the LX/ST combination for research that involves large log sets and, while I like the product a lot, I have to admit that there have been a few limitations. One of those limitations is the types of logs that it can handle. The other is the way it has handled raw log content. Both of these limitations have been rendered obsolete in release 4.0. "

"Implementation is quick and easy. Although users will not need to reinstall the entire system (the new release comes as an upgrade), we opted to do a fresh install. We installed on our legacy (release 3.X) appliance and the entire installation took under a half hour. The results were flawless."

Read the whole thing here.



Technorati : , , ,

Posted by on May 21, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

Managing Incidents in Age of Compliance

In this ComputerWorld guest column, LogLogic's Anton Chuvakin outlines the basics of incident response and relates them to three major compliance regulations -- FISMA, HIPAA, and PCI DSS -- that directly affect the specifics of setting up incident response capabilities.

" . . . being prepared for incidents via an incident response plan is likely to be one of the most cost-effective security measures an organization takes. Timely and effective incident response is directly responsible for decreasing the incident-induced losses. It can also help to prevent expensive and hard-to-repair reputation damage, which often occurs following a publicly disclosed security incident."

Compliance, too, is one area that Chuvakin points out has repeatable IR capabilities due to some predictability:

" . . . recent government regulations and standards put forth by industry groups have explicitly highlighted the importance of having a repeatable incident response plan to guarantee security of key data; they even mandate specific details on how incident response should be performed. Thus, some aspects of IR planning and procedures have, as a direct result of these regulations, moved from the "should" category to the "must" category. . . "





Technorati : , , , , ,

Posted by on May 17, 2007 in Compliance , Risk Management , Security | Permalink | Comments (0)

Innovation Stems SOX Costs

Today, Financial Executives International (FEI) announced the results of their sixth Sarbanes-Oxley compliance survey, which found that Section 404 compliance costs were down this year than in each of the first two years. Section 404 requires corporate annual reports to contain both a statement of management's responsibility for establishing and maintaining an adequate internal control structure and procedures for financial reporting and management's assessment, from the end of company's more recent fiscal year, of the effectiveness of the company's internal control structure and procedures for financial reporting. Section 404 also requires the company's auditor to attest to and report on management's assessment of the effectiveness of the company's internal controls and procedures for financial reporting.

They FEI surveyed 200 companies about their compliance experiences with Section 404 and based on the results, they concluded that the total average cost for Section 404 compliance was $2.9 million during fiscal year 2006, a 23 percent decrease from 2005 totals. The data also shows reductions in internal and external costs of compliance, with internal staff time decreasing by 10 percent. Additionally, total compliance costs have dropped about 35 percent since year one, attributed to companies' increased efficiencies in Section 404 compliance.

What is the root cause of this new found efficiency? FEI President and CEO Michael P. Cangemi attributes it, in part, to technological advancements in the field of compliance.

We've seen this trend of mature of approaches to SOX in spades. Log management solutions go well beyond SEM or SIM - they reach deep into supporting critical operational processes; automating and monitoring controls.

As compliance continues to be a priority in the boardroom, it will continue to drive software innovation through the coming years and software innovation will continue to make compliance efforts more efficient. And Log Mangagement is increasingly playing a key role in that transformation -- and costs savings in enterprises.

Technorati : , ,

Posted by on May 16, 2007 in Compliance | Permalink | Comments (0)

Keep Those Logs. But Keep Them Right...

One of the important lessons from the AOL log saga was secure your logs (and think twice before letting them out of the building).

Another thing it highlighted was the value of logs outside of the security context - that doesn't mean they aren't really important to security and Information Asset Protection. In fact, Google has been quick to highlight the security value of logs:

"Immediate deletion of IP addresses from our logs would make our systems more vulnerable to security attacks, putting the personal data of our users at greater risk. Historical logs information can also be a useful tool to help us detect and prevent phishing, scripting attacks, and spam, including query click spam and ads click spam," says Fleischer.

Nate Anderson has a great piece on why Google retains log data. Retention laws around the planet differ by country and regulation. Nate makes a good point:

Two months ago, Google announced a plan to anonymize its logs, but only after retaining the data for 18 to 24 months. After that time, user searches will still be stored, but it should be impossible to link search queries up with individual users. Of course, this is what AOL researchers thought when they released their own search logs, but queries often turn out to be highly specific things... the sort of things that can eventually be used to identify individuals.

Fisher also points out that one of the emerging European laws is, well, emerging - complicating things:

"Since these laws do not yet exist, and are only now being proposed and debated," Fleischer says, "it is too early to know the final retention time periods, the jurisdictional impact, and the scope of applicability. It's therefore too early to state whether such laws would apply to particular Google services, and if so, which ones." Even though the laws are not yet in force in Europe and won't apply retroactively, Google still uses the law as an argument to retain data now, and to do so for the longest possible period the law provides for.

One of the challenges is that privacy, telecommunication and labor law differs greatly from one country to another around the world. For instance, in France, log Data can be retained for up to 6 months in the maximum (the penalty is up to 5 years of imprisonment term and a 300,000 euros fine) while in Germany it is recommended that log data should be deleted as soon as it is no longer needed for fulfilling the purpose for which it was are stored - this should typically not exceed 2-3 months.

Compliance mandates also vary in either direct or implied retention requirements:

 

This is where automating storage, chain of custody and securing of log data can ease much of the pain. Through a log data warehouse regional and regulatory requirements can easily be reconciled and managed. So whether the Government may or not require it today, or, regulations related to your business probably do require it - collecting and storing log data makes good commercial sense and shouldn't be either a pain or a risk.

Posted by on May 16, 2007 in Compliance | Permalink | Comments (0)

PCI Takes A Twist

Computerworld reports that the State of Texas is mulling a bill that would make PCI requirements law - and that retailers that accept credit cards would be financially liable for data breach costs.

The state's House of Representatives last week voted 139-0 in favor of a bill that would formally codify PCI requirements into a state law that merchants would be obliged to comply with if passed. Under HB 3222 a breached entity will have to reimburse banks and credit unions the cost associated with blocking and reissuing cards if the merchant was not PCI compliant at the time of the compromise. It also provides a safe harbor against such liability for companies who are PCI compliant and get breached. The proposal needs to win approval in the state Senate before it becomes law.

Texas is not the only state eyeing such a bill. In Massachusetts, legislation proposed earlier this year by state Rep. Michael Costello would hold retailers financially liable to banks for the costs of a credit card security breach.

Gartner's Avivah Litan comes out swinging though suggesting that banks are shifting too much liability to the merchants. "In every single instance, the retailer already has to pay for the direct costs of the fraud. And now banks are trying to shift the customer service costs to the retailer as well," she said. "Retailers are being pinned against the wall, frankly," Litan said. "If laws like this take affect, it could have serious consequences on a retailer's balance sheets."

While that might be the case the reality is that the retailer (after the consumer) has the most loose - especially reputationally. What shouldn't be confused is the cost of doing business versus the cost of implementing industry mandates. Effective protection of customer data should be viewed as a cost of doing business. PCI is forcing an entire industry to step-up to that responsibility.

I speak to plenty of retailers. Many are already there. Some of them have very small and resourceful IT departments who have automated many of the processes, reports, sampling and alerts that surround PCI. What always amazes me is the number of retailers, some large, that still lack by even basic standards, strong security processes. Who should bear their costs - the banks, or ultimately the consumer? We're here to help.

Posted by on May 16, 2007 in Compliance | Permalink | Comments (0)

SANS Log Management Summit WrapUp & Conference Materials

The SANS Institute has posted the presentations from the 2007 Log Management Summit held in San Jose, CA last month. The complete set of presentations is available as a downlead (zip file) here.

A number of bloggers attended the event and they have had some nice writeups of the event. Blog Infosec Potpourri has a nice discussion of some sessions.

Finally LogLogic's Anton Chuvakin has a few observations on the state of the Log Management Industry ...

I noticed that logging for operational uses was much better represented and more frequently mentioned compared to last year; logging for security and compliance were certainly there in full

force, but logging for operational uses, which is the oldest, classic use for logs, seems to be making a comeback and people really buy (or build - and then suffer :-)) log management tools to deal with the challenge.

On the market side, Summit pretty much proved that there is a log management market now with its own players, requirements, use cases, etc. At the same time, buyers are much more aware of what they are actually signing up for when they call a log management vendor. Still, I saw a share of people who made really bizarre decisions in regards to their logging

...

Technorati : , , , ,

Posted by on May 06, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

Visa's New PCI List You Don't Want To Be On

Two weeks ago Visa sent out a letter that listed a half dozen vendors whose POS products have been shown to contain stored card data in known data breaches. Digital Transactions News reports that Visa is recommending that merchants stop using these products. In fact Eduardo Perez, vice president for payment system risk and compliance at Visa, told the the news site that the while the list is not publicly available today Visa is considering "posting it on a private page on its Web site that is available to members."

While he says vendors on the list were contacted before the letter went out from Visa, Perez went on to say that not only was:

"a patch or an upgrade that would not store prohibited card data" made available to merchants, but that the update on how to make the names solutions compliant was available in the warning letters. He said, "Obviously, they weren't happy, but in most cases they wanted [the information] out there because it gave them more ammunition as to why merchants should upgrade"

PCI Compliance is not only at the top of merchants agendas this year, but progress towards compliance is mounting as the June 2007 deadline looms. Visa reports that most large merchants have been able to prove they are not storing credit card-verification data, PIN numbers, and other encoded information typically found in magnetic stripes, which is one of the key requirements of PCI.

And in more evidence of PCI Compliance, Visa now says that 35% of Level 1 merchants, as defined by Visa as those processing 6 M or more transactions annually, are now PCI compliant. This is up from 18% a year ago. A full 51% have completed Visa's 'report on compliance' which is recognized as a step toward satisfying PCI requirements that involves a review of systems for security flaws and demonstrate a plan to fix them, often referred to by Visa as remediation.

In less than two months, the PCI DSS standard will be enforced for merchants, making fines a reality for many merchants who accept credit cards. The mandate is the requirement for monitoring and storing credit card data mapped to four levels of security based on a merchant's volume of credit card transactions.

Major breaches at global companies like TJMaxx have not only illustrated the needfor protections, but have also spurred on legislative efforts to deal with securing customer data in the US.

So how are you tracking to meet the PCI deadlines in 2007? Log management and intelligence provides some key strategies now.

Technorati : , , ,

Posted by on May 01, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

Logging The Threat From Within

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

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

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


Technorati : , , ,

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

Log Management Time

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

Says Stansberry ....

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

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

Technorati : , , , , ,

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

Computing Monocultures and PCI Compliance

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

Welcome to the LMI market.


Technorati : , , , , ,

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

LogLogic Platform Gets Certified for NetApp's Snaplock

Today we announced that we are the LogLogic Log Management Platform is now certified for NetApp's Snaplock storage and compliance solutions. Snaplock to help customers simplify the management of immutable lhich is designed to create WORM (Write Once Read Many) data archives.

Log data is often stored in departmental silos without attention to data integrity or security, but compliance mandates and operating pressures -- such as frequent audits and increasing demands for user activity monitoring - are making Enterprises approach log data horizontally across the organization. To do this, collecting all log data all of the time is critical as is storing the log files in a completely secure and unchangeable form. For forensics, legal reasons and satisfying compliance mandates like PCI, immutability of log data is becoming necessary in today's enterprise.

Gerard M. Stegmaier of Silicon Valley law firm Wilson, Sonsini, Goodrich and Rosati talked about the implications for Logs and the Law in a podcast along with LogLogic's Andy Lark. Check it out here.





Technorati : , , , ,

Posted by on March 29, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | Comments (0)

On Photocopiers and Identity Fraud

Over at Baseline, Debbie Gage writes ...

At least 15 million Americans are now victims of identity fraud, up more than 50% since 2003 when the Federal Trade Commission released its numbers, Gartner says. Americans are also losing more money to identity fraud--$3,257 on average in 2006, compared to $1,849 in 2005--and they're recovering less, an average of 26% less.

That is alot of companies that should be listening to Avivah right now. PCI is here and getting compliant is a necessity. (And Avivah specializes in that area of course!)

But how about those devices -- you know those photocopiers are watching your data too...

"Everyone forgets that there's data in there," said Avivah Litan, an analyst at Gartner. "Copiers and other intelligent devices like multifunction printers are very exposed in the enterprise. They're open to attack via modems, and people forget about changing the default passwords."

All of your devices are harboring data. How do you deal with that? Is it secure?



Technorati : , , ,

Posted by on March 28, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

Drowning in Data? Grab a Log

IDC researcher John Gantz began a study on data, estimating that 161 exabytes of digital data - or about 161 billion GB - were generated in 2006 alone. Think about that. According to the USA Today that is

168 million terabytes, or roughly the equivalent of:
36 billion digital movies
43 trillion digital songs
1 million digital copies of every book in the Library of Congress

How much of the data generated inside businesses must be stored? Facing government regulations over the globe, such as the Sarbanes-Oxley Act in the US and the EU Data Retention Directive, more and more organizations are being required to save more information than ever. The impact of the regulations globally is staggering. Just this week analysts predicted the impact of the EU law on Asia could see communications providers and operators in the region to comply.

Searching on all the data is even trickier. Log Mangement and Intelligence effectively deals with the problem of continuously complying to multiple mandates simultaneously and being able to locate the data you need for compliance, forensics and to reap operational efficiencies.

Technorati : ,

Posted by on March 08, 2007 in Compliance , Risk Management , Security | Permalink | Comments (0)

Visa Takes Data Security to DC

Today, at the second Maintaining Trust in Payments Summit, organized by Visa and Harvard Business School Publishing, industry leaders from business, government, and technology gathered in D.C. to discuss the security for the electronic payments industry, including the ever-present problems of consumer data theft and identity fraud, which, according to a recent Gartner survey, has increased by 50% in three years.

Topics covered the role of technology in payment security, the amount of time companies should be allowed to wait before disclosing data breaches to consumers (no doubt sparked by TJ Maxx's admission that their recently publicized security breach may have occurred as far back as 2003) and the role of the government in protecting both consumers and the payment card industry.

Kudos to Visa for organizing this summit-- hopefully log management will play an important role in the discussions as PCI compliance requires that organizations maintain detailed, real-time reports on their log data to ensure network and data security.

Technorati : , , ,

Posted by on March 07, 2007 in Compliance , Log Management & Intelligence , Security | Permalink | Comments (0)

Leading Causes Of Data Loss

Looking at this report, an effective LMI platform is a key antidote to data loss. Sure, it won't prevent someone loosing a laptop, but it will deliver alerting and reporting on many of the other areas identified in this report.

What is interesting is the extent to which human error is the overwhelming cause of sensitive data loss, responsible for 75 percent of all occurrences. User error is directly responsible for one in every two cases (50 percent) while violations of policy - intended, accidental and inadvertent - is responsible for one in every four cases (25 percent). Your LMI patform should deliver reporting and alerts on major IT controls and standard policies.

Posted by on March 07, 2007 in Compliance , Risk Management , Security | Permalink | Comments (0)

Who's minding your security events?

Warning signs buried in audit logs and system security events  are often ignored or simply unnoticed by IT pros until it's too late, writes Bill Elmore at TechRepublic. Pointing out that these "alerts" could prevent or thwart attempted data breaches if actively monitored and acted upon, he chronicles the high profile breeches at UCLA and Ohio University as examples of how things can go wrong -- quick.

Compliance and mandates like HIPAA or SOX can help ensure that data is checked. Data security is at the top of the IT agenda this year. In fact, the The US Goverment Accountability Office (GAO) out data security on the 2007 "High Risk" List  for government systems.

Elmore says:

Another reason for security mishaps is the fact that IT is still just a necessary vehicle for the rest of corporate America. IT serves as the conduit for business profitability but is still viewed as a hit on the bottom line – an expensive hit at that. Additionally, as IT budgets become leaner, more work is expected of an already taxed staff. Walk around your IT department and ask each pro how much time they spend chasing down data security events and reviewing audit logs. Unless they happen to be security analysts, you'll probably get an emphatic response that they have too many other duties and projects to tend to than to spend their time poring over security event logs.

How does your organization view IT's role and how well does your company monitor who is accessing your data?

Posted by on February 28, 2007 in Compliance , Log Management & Intelligence , Security | Permalink | Comments (0)

SANS Log Mangement Summit 2007 Moves to San Jose

The SANS Institute has announced the 2007 Log Mangement Summit. Besides moving to San Jose this year, the event has expanded and includes even more vendors and customers, offering an in-the-trenches look at how log management is changing the face of IT.

Ignoring data security mandates could cost your company a bundle this year. As high profile breaches are making headlines and consumers nervous about their data and privacy, enforcing security is taking a center stage. From the halls of US Congress to the European Commission (EC), new laws are being proposed whereby firms across the globe would have to inform regulators and customers of all security violations. Log Management and Intelligence can help meet these regulations.

In fact, log management, as we have come to see from our customers, is addressing stringent regulatory requirements to keeping IT operations running optimally. In fact, the Global 2000 are investing in log management and intelligence, according to a report from the SANS Institute that we commissioned. “The Log Industry: An Untapped Market” is the first study to identify the business and technology issues faced by IT executives and examines how log data is being used to address their critical needs.

Want to learn more? From SANS Research Director Alan Paller's announcment on the Summit:

The Log Management Summit is a user-to-user, non-commercial conference on what works in log management. It is the only place where you can learn about the strengths and weaknesses of competing technologies, where users will share the lessons they learned about what to log and what to keep and what to report.

Nearly every major regulation affecting cyber security now demands or implies the need for continuous logging and effective log management -- HIPAA, SOX, ISO 27001, COBIT. Even the Processing Card Industry (PCI) standard appears to demand it. And regulations governing information security technology are evolving as fast as the technology itself. Beginning in 2007, for example, a significant motivator for compliance with HIPAA is that "whistleblowers" for violators of the new guidelines may be awarded 15% of any associated fines.

Organizations that have implemented log management systems have found that they provide far more value than simply meeting compliance requirements. Their greatest value lies in the improvements they create in your defensive posture, but great benefits also accrue to the operations managers who have, for the first time, visibility into the details of what has happened on every system in their network.

The event will be held April 23-25 in San Jose, CA. This is SANS' second Log Management Summit. If you are planning to implement log management or have a compliance need, it is a must-attend!

Posted by on February 21, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

Research: Don't let sleeping logs lie

Who is looking at your logs? Better yet, what systems and policies do you have in place to monitor log files?

Datacenters are increasingly turning to log management to ease compliance burdens, and gain instant insight into the network. Nemertes Research says that "almost 80% of large and small enterprises have a data center-specific security policy defined, and of those with policies, more than 80% regularly test compliance with them."

The bad news?

Although everybody engages in some level of system logging (whether solely for security reasons, or in support of regulatory-compliance efforts as well), fewer than 30% of companies log all systems, and fewer still collect the logs at a central location for review and analysis. In fact, most logs are left in place and never reviewed except in the heat of a crisis, or worse, in the aftermath.

At NetworkWorld, Nemertes offers some suggestions on log management and the security considerations for customers, with recommendations of what to look to vendors to deliver in a strategy.

Not knowing what is going on in your enterprise is not a good defense, and point products only serve to add to creating even more silos of information across the enterprise. Taking the Log platform approach, with SOA and other architectural considerations are how we at LogLogic approaches log management and intelligence, and one that our customers are trumpeting!

 

Posted by on February 20, 2007 in Compliance , Log Management & Intelligence , LogMatters , Security | Permalink | Comments (0)

Global enterprises, governments turning to SOA

Research from Zapthink takes a look at the 'State of Worldwide Service-Oriented Architecture Adoption.' Analyst Ronald Schmelzer comments on the increasing global reach of SOA:

" . . . the net result is that no multi-national company can afford to avoid or overlook the issues associated with global distributed computing. Issues related to international regulatory compliance, internationalization and localization, support for multi-ethnic cultures, languages, and business practices must be the method de facto to be supported in any SOA initiative rather than an after-thought once the application is delivered in a particular language or cultural bias."

Schmelzer says that SOA adoption is not just happening in North America and Europe, noting: 

"...substantial uptick in SOA adoption in Australia, India, Korea, China, Singapore, parts of Latin and South America, and the Middle East. Many of these global initiatives have a particular industry bent, such as a strong telecommunications presence in Korea, banking and insurance in Australia, government in Singapore, manufacturing and services in China and India, and retail in the Latin and South American regions."

Just last week a report in Defense News noted that the DoD is moving its web portals to a service-oriented architecture. It makes sense for the DoD to make sure that the right relationships between data can be connected, automating compliance and making data accessible in the most effective and cost efficient manner.

We're finding that the public sector is looking at SOA more and more as well at LogLogic. Log Management and Intelligence delivered as an SOA turns proprietary closed systems throughout the organization into ‘Open Log Services’ that can be re-used and repurposed, helping with all kinds of compliance from FISMA to PCI.

More findings on SOA at Zapthink.

Posted by on February 10, 2007 in Compliance , Innovation , Log Management & Intelligence | Permalink | Comments (0)

Keep Your Eye On PCI Compliance

Take away the fines, the security breaches, and the looming deadline, and at the end of the day if a business wants to be competitive they will figure out how get compliant. Why? To not take customer credit cards from Visa, MasterCard, and American Express makes it hard to sell anything in a global economy.

Protecting data information and being able to prove you are mitigating the risk of the data being breached is central to satisfying PCI DSS. But what you should be asking is how can you cost effectively reach compliance and stay that way. The real answer? LMI.

Find more resources and tools at PCIAwarness.com, including an upcoming PCI Compliance webcast, on February 21st at 11am PT, in which Sr. Analyst from Forrester Kahlid Kark will speak to what the looming deadlines are and what you can do to achieve PCI Compliance.


Technorati :

Posted by on February 08, 2007 in Compliance | Permalink | Comments (0)

The Age of CSO Pragmatism

Security Incite's Mike Rothman has released The Pragmatic CSO: 12 Steps to Being a Security Master. Written for Chief Security Officers in the corporate world today, the book looks at the business reasons and impact of securing a network.

Mike gives you a sneak peek of the book here. But we found lots of reviews out there touting the book - including Richard Bejtlich's shout out over at his TaoSecurity blog. Richard writes:

The most important feature of "P-CSO" (as it's called) is that it is a business book. P-CSO teaches readers (assumed to be techies, for the most part) how to think like a businessperson who reports and interacts with other businesspeople. I took business classes in college and graduate school, and I run my own business. Most of the time, however, I'm doing technical work. I usually stay so busy that I don't consciously consider the sorts of business issues Mike describes.

We learned that Rothman plans to launch the Pragmatic CSO community in February. We hope to learn more from Mike this Monday night!

Posted by on January 31, 2007 in Compliance , Innovation , Risk Management , Security | Permalink | Comments (0)

What are the "Five Mistakes of Security Log Analysis"

Anton Chuvakin gave a talk at the DoD Cybercrime Conference 2007 in St. Louis, Missouri last week. 

In his presentation, the "Five Mistakes of Security Log Analysis," Anton talks about operational security challenges that organizations face while deploying log and alert collection and analysis infrastructure. Chuvaking highlights the top five most common mistakes organizations make in this process: not storing logs long enough to comply with gov't regulations, not preserving the forensic quality of logs, and only looking for known 'bad records.'
 
To get the complete presentation, detailing how to avoid these, and other, mistakes email us.
 
Take a peek at the presentation here.

Posted by on January 29, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

NIST Expert Says Legacy Systems Must Be FISMA Compliant Within 1 Year

Legacy systems are expected to be in compliance with NIST within 1 year of the publication date, according to Dr. Ron Ross of NIST in his presentation today about FISMA Compliance. And that is not all! Systems under development are expected to to be in compliance immediately upon deployment.

We sponsored a Government Computer News webcast on FISMA Compliance this morning with Dr. Ross to record attendance! (Over 900 people signed up!)

Ross went through FISMA guidelines, cleared up misconceptions on FISMA Compliance, and made recommendations for sound strategies to to get compliant with FISMA in short order.

Three key takeaways:

"Successful FISMA Implementation demands that organizations adopt an "enterprise-wide" Security Strategy"

"Common controls must be continuously monitored with results shared with all information system owners"

"Continuous Monitoring; Facilitates annual FISMA reporting requirements"

Log Management and Intelligence delivers FISMA Compliance in minutes. Our just announced FISMA Compliance and Control Suite helps government agencies verify that information security policies are being followed, substantially reduce audit time and expense, and achieve FISMA compliance. Out-of-the-box reports and alerts directly map to NIST standards, including NIST 800-53 (security controls) and NIST 800-92 (log management), providing an efficient, easy-to-implement solution. Our approach is cost-effective, using all available log data to automate the process of auditing and enforcing policies - and supports 100% of all log-related IT controls as outlined by FISMA. And -- its the first FISMA compliance solution based on log management and intelligence.

Technorati : , , , ,

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

Compliance Driving Log Management Into the DataCenter

Datacenters are increasingly turning to log management to ease compliance burdens according to Matt Stansberry at SearchDataCenter. Stansberry points to SAS 70 auditing as an example of internal controls define standards for auditors in assessing controls at a service organization and says that logs come into play as data center managers can prove controls such as proving that the business "has disabled user logins when people are terminated."


Analyst Dana Gardner weighs in:

For instance, a company can show how it is enforcing its policies. If a company doesn't want its workers sending emails to employees in a competing company, it can use log data on routers, hubs and email systems to block or record that activity.

"It can also be used for internal issues," Gardner said. "If you're a financial institution, your traders shouldn't be talking to your investment bankers. You can prove to the SEC that your traders aren't having communications with the investment bankers, at least not on your systems."

Illinois auditing consultant Russ Gates adds:

"I sat in on a Web-cast LogLogic did the other day and a lot of their points are valid," Gates said. "If somebody thinks logs are important and relevant you've got to have software to deal with it. In any big system you'd have hundreds of thousands of events being logged. Parsing out the ones that matter -- a database failure or security violation, getting those in front of somebody -- the key thing is tying those into a response you can do something with."


As Anton noted earlier this week, traffic is up on the loganalysis mailing list, and other trends are showing that log management is emerging right now! As simple Google search of "log management" drives this home with over 239 million hits -- and growing daily.

Technorati : , , , , , , ,
Del.icio.us : , , , , , , ,

Posted by on January 23, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

The Demystification of Event Logs

Will Kelly writes at processor.com that "Demystifying event logs requires proactivity with an eye toward retention, review, and automated tools to ensure that your log events are presented in a usable and actionable manner to your data center team."

LMI fulfills this charter. Kelly quotes our own Anton Chuvakin:

He also advises a proactive approach to handling log management vs. opening them when a network outage or security issue occurs. "Not looking at the logs until something happens is a big mistake," according to Chuvakin, because regular viewing of your logs enables you to see early signs of problems, such as security incidents like probes, not just trends.

Read the entire article here.

Technorati : , , , , ,

Posted by on January 22, 2007 in Compliance , Log Management & Intelligence , LogMatters , Risk Management | Permalink | Comments (0)

Webcast: Log Management takes on FISMA Compliance

There is a newly added LogLogic Sponsored-Webcast with Government Computer News on FISMA Compliance this Wednesday, January 24, 2007 11 a.m. Eastern | 8 a.m. Pacific.

The online event features Dr. Ron Ross, a senior computer scientist for the National Institute of Standards and Technology (NIST) and author of several federal security publications and guidances. Host of the event is GCN assistant managing editor Jason Miller for a one-hour discussion on how agencies can use the Federal Information Security Management Act (FISMA) to improve their IT security and get compliant with FISMA.

To attend, sign up here.

Del.icio.us : , , , , , , ,

Posted by on January 22, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

HIPAA: Report Shows Most Complaints Not Investigated - IT Compliance

The motivation to get HIPAA compliant shouldn't be to avoid getting sued - it should be to protect your informaiton assets. Saying that, we do wonder how many will be motivated to comply with a mandate that isn't being enforced - according to Government Health IT "Most privacy complaints are not investigated":

"The Department of Health and Human Services investigated less than 25 percent of 22,964 privacy complaints submitted to HHS’ Office for Civil Rights (OCR) from April 2003 through September 2006"

"Melamedia found that of the 5,400 complaints investigated – all of which were filed against health care organizations covered by the Health Insurance Portability and Accountability Act (HIPAA) – OCR officials took informal action in 3,700 cases. Officials absolved the accused health care organizations in 1,700 others."

Will the new False Claims Act Guidelines coming into play with HIPAA enforcement, will enforcement activities will increase? Perhaps. As Rebecca points out:

A significant motivator for compliance is that beginning in 2007, "whistleblowers" for violators of the new guidelines will be awarded 15% - 25% of any associated fines, depending upon the situation. This could definitely motivate employees, former employees, and patients/customers to report what they believe are HIPAA violations when they may not have to date.

This could bring the Department of Justice (DOJ) into the HIPAA compliance and enforcement mix.

The real question is, "will compliance activities increase? Read more here and here...

Posted by on January 08, 2007 in Compliance | Permalink | Comments (0)

The Future Of SIEM

THe SIEM market will begin to diverge in 2007 according to Amrit Williams - ex-Gartner analyst. His final sentence reflects what we have been seeing for the past two years:

Log management will break out as it own class of products and will see the biggest growth as folks realize that at the end of the day all they really wanted was a syslog server on steroids.

Kind of. What customers come to realize quickly is the intrinsic value log data has and the broad range of answers it can give them across IT functions. From IT Opertations through Compliance and, of course, Security. They want much more than just a "syslog server on steroids".

In looking at the business cases and RFPs what most customers are looking to address is the entire log life-cycle (collect, alert, store, report, share) against specific applications - be they compliance or controls validation - to name just two.

Either way, Amrit is right in identifying that the market is diverging.

Posted by on January 02, 2007 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

User Activity Monitoring. It All Starts With A Log

User activity monitoring starts with effective logging. Logs provide the fingerprint of a users activity across the network. InformationWeek illustrates this well.

Managers must not only monitor system access, but also let employees know their system changes can be tracked. Employers should be wary of people unwilling to share their knowledge about systems or uncomfortable with the fact that their activities accessing systems or data can be tracked.

Mike picks-up on this over at Security Insights (subscribe to his daily email - worth the read):

But that's far from the only place insiders can cause damage. It ain't easy, but there are a couple of tips to help deter the behavior and then detect it. First is logging. You should be logging all administrative changes. Duh! But here's the nuance. Store the logs somewhere else and do not provide access to the administrators. Thus, they can't tamper with the logs to cover their tracks. They'll need to think twice before setting backdoors and the like.

Both Mike and InformationWeek get at one of the key tenets of an effective LMI solution - chain of custody. Even administrators shouldn't have access to your set of immutable log data. And you also want controls over some reports and alerts. All this can be managed very easily with the right solution.

You LMI policies should also incorporate two other elements. Who is "watching the watchers" (often IT Audit takes on this role in larger enterprises) and, who is auditing the policy - do you, for instance, have automated reports and alerts as to the status of logging?

Posted by on December 14, 2006 in Compliance | Permalink | Comments (0)

Telco Rings Up Log Management and Intelligence Platform

Recently a large telecommunications carrier came to us because their extenal auditors required log management as part of their Sabanes-Oxley compliance strategy. The auditors, of course, created an urgency to get the telco to meet a business goal and report data that is readily accessible through log files. Compliance was central in creating the demand for LMI, but it didn't take long for other departments to support the project and extend log management across the enterprise -- something a product just can't do.

As we began rolling out LMI, the problem management department stepped forward. They had been looking to improve on log-based root-cause analysis for years. Historically, wehen they encountered a performance problem in the corporate network that could not be explained by the initial systems management alert alone, they were performing a manual search to find relevant log data -- and taking days to find an answer. Automating the process with log management and intelligence sped up this process with a simple log search and through agile, ad-hoc reporting with a single mouse-click.

Next, the help-desk group stepped up. They were seeking to integrate log data directly into their trouble-ticketing system. Now, a second-phase implementation was born. Now, when an operator opens up a trouble-ticket it includes a link that can retrieve the most recent log messages generated by the failing system and cross-correlate that with other log messages for the same IP address or user. This integration was easily achieved using open log services based on web-services standards.

This customer is just one of many LogLogic customers that point to a single need for log management, but quickly realize that a LMI platform addresses multiple needs across their enterprise. A point product can't begin to deliver the same level of support, or recoup the same ROI. Time and time again we see our customers validating LMI's role in supporting a multiple stakeholders simultaneously. Only an open, services-oriented architecture is able to achieve the ease-of-integration and multiple views into log data without incurring exorbitant professional services costs.

What is your organization dialing up in the new year to solve complex IT?



Technorati : , ,

Posted by on December 05, 2006 in Compliance , Log Management & Intelligence , Risk Management | Permalink | Comments (0)

A Longview on SOX

SC Mag just published a feature looking back on Sarbanes-Oxley, two years later. The article chronicles the initial fear SOX brought to the boardroom three years ago as it differed from other regulations by adding real "teeth" -- and jail time for executives who were noncompliant.

With the initial shock now gone from SOX compliance, companies today are focusing more on the process and strategies for continuous compliance, rather than the fear of jail time.

SCMag's Frank Washkuch writes: "Now those fears are mostly in the rearview mirror for corporate executives, as two years of experience with the regulations - plus a lack of SOX-related prosecutions - have put minds at ease with the federal mandate. Many forward-looking companies are also realizing that they can use SOX to their advantage to create best practices... Because of the complexities of making sure major national and international corporations are compliant with numerous state, federal and, in some cases, foreign standards, many companies are now using automated processes."

Washkuch taps LogLogic's own Andy Lark for his take on SOX two years later. Lark is quoted, "We're seeing an enormous interest in anything that automates SOX, as well as anything that regulates other regulations," he says. "What we say to people is that rather than building a SOX dashboard, you're going to be much better off building a COBIT 4 board that can be used for SOX. We definitely see a lot of elevated interest in anything that automates manual processes."

Technorati : , , , , , ,
Del.icio.us : , , , , , ,

Posted by on November 21, 2006 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

How to Select a Log Management Approach

At the SANS Network Show in Las Vegas last Wednesday LogLogic's Anton Chuvakin presented a "standing room only" lunch session on "Selecting a Log Management Approach." We were asked to post the slides in which Anton takes a look at the key choices in log management and intelligence, along with best practices, drawing on LogLogic's customer experiences.

Anton tackles the key questions over whether to build with open source tools or buy a solution -- by giving you the questions you should ask your vendor and what to do about ROI and compliance. Choices, risks, and advantages of all options, as well as a look at strategies you can use today to harness your logjam are explored.

The slides are available as a pdf download.





Technorati : , , ,
Del.icio.us : , , ,

Posted by on October 10, 2006 in Compliance , Innovation , Log Management & Intelligence | Permalink | Comments (0)

PCI in the UK

Looks like European merchants are recognizing PCI DSS. A report out from UK-based The Logic Group now reports 85% of respondents are aware of the PCI DSS standard, which is a significant improvement from the group's last survey which reported just 45% knew about PCI. With compliance due in June 2007, 60% of companies surveyed are currently at the PCI assessment phase says the group.

Just last month the PCI standard got American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International announced the formation of an independent council designed to manage the ongoing evolution of PCI DSS.

Technorati : ,

Posted by on October 05, 2006 in Compliance | Permalink | Comments (0)

Congress Takes Aim At Log Data

Retaining log data is one area that is getting significant attention as of late as cybercrime continues to be a key focal point for law enforcement authorities. Colorado Congresswoman Diana DeGette believes that no clear guidelines are in place to either protect privacy or secure onine users, and late last week said she will be introducing legislation to force Internet providers to retain customer data for at least one year.

Plenty of recommendations are out there - for instance, Basel requires data retention from 3-7 years, PCI recommends a minimum of one year of data retention. And equally important is how the data is stored and managed. For example, is the data secure in transport and at rest? Is it an immutable set of data or processed data and how do you handle disposal?

What would legislation look like? DeGette suggests that:

One form could require Internet providers and perhaps social networking sites and search engines to record for a year or two which IP address is used by which user. The other form would be far broader, requiring companies to record data such as the identities of e-mail correspondents, logs of who sent and received instant messages (but not the content of those communications), and the addresses of Web pages visited.

DeGette said Thursday that her proposal would not require retention of the communications themselves, but would identify data so that law enforcement officials--if they had probable cause to believe a crime has been committed--could go in and get a subpoena and subpoena these IP addresses.

Regardless of how legislation aims to deal with the issue of cybercrime, one trend that we are seeing at LogLogic is individual sites proactively alerting patrons of their policies regarding log data. PopSugar, a red-hot celebrity gossip site based in San Francisco, has a posted privacy policy that calls out log files in great detail. PopSugar alerts patrons of their site that they use log data "to analyze trends, administer the site, track user's movement in the aggregate, and gather broad demographic information for aggregate use. These log files are not linked to personally identifiable information. We may use a tracking utility that uses log files to analyze user movement."

Whether it is for legal reasons, to track down the bad guy, or just to gather marketing data on viewers, log data a systematic and managed approach to collecting log data is critical.


Technorati : , , ,

Posted by on September 25, 2006 in Compliance , LogMatters | Permalink | Comments (0)

The Global State of Information Security 2006

 The latest survey results are out and the prognosis isn't good. Overall, the state is generally regarded to be poor.

Complacency, it seems, abounds. A large proportion of security execs admitted they're not in compliance with regulations that specifically dictate security measures their organization must undertake or risk stiff sanctions, up to and including prison time for executives. Some of these regulations—such as California's security breach law, the Health Insurance Portability and Accountability Act (HIPAA), and non-U.S. laws such as the European Union Data Privacy Directive—have been around for years. Is this an example of adolescent rebellion, or are security executives finding it hard to obtain the necessary resources to comply?

The answer, says Mark Lobel, a PwC advisory partner specializing in security, is neither, actually. The information security discipline still suffers from the fundamental problem of making a business value case for security. Security is still viewed and calculated as a cost, not as something that could add strategic value and therefore translate into revenue or even savings

We've just invested a substantial amount of time and energy into an ROI model that gets at the issue of making the business case. Look for that over the next week on our site. Today we're announcing our broad support for ITIL. While niche LMI vendors look to basic search, we're investing in aligning LMI with business objectives through best practices like ITIL. The reason is clear:

A larger percentage of companies are aligning security objectives with business objectives (20 percent of respondents said they align all security spending with their business objectives, up from 15 percent in 2004) and are prioritizing data sets based on the sensitivity of the information contained in each application. They're then protecting those sets with the appropriate amount of security (25 percent in 2006, up from 21 per­cent in 2004).

Link to The Global State of Information Security 2006 - Editorial - CIO

Posted by on September 19, 2006 in Compliance , Security | Permalink | Comments (0)

PCI Standard Gets Teeth

Often standards emerge out of necessity. Take the case of Payment Card Industry (PCI) Data Security Standard, something we are very focused on here at LogLogic. The standard for compliance was borne out of necessity and the scope of the requirements were adopted from Visa and MasterCard's own policies of how they felt it should be set up -- and is focused on those requirements that are key to their operations.

Last week American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International announced the formation of an independent council designed to manage the ongoing evolution of PCI DSS. The newly minted PCI Security Standards & Council's stated goal is to improve payment account security. This is great news for consumers and vendors in advance of a significant shopping season.

As part of their first order of business, the group is proposing some key changes to the standard, notably releasing a new set of technical criteria that will address evolving security threats. And front and center is some policies on logging data, monitoring and retaining data. The new directive Payment Card Industry Data Security Standard (DSS) v 1.1 is available here (pdf) and notably calls for merchant data to be retained for one year to meet compliance.The new set of guidelines will be the only recognized standard, says the Council, beginning January 2007.

Technorati : , ,

Posted by on September 11, 2006 in Compliance , Security | Permalink | Comments (0)

Three SOX Learnings

New to the LogLogic team, I made my way to the ISACA(Information Systems Audit and Control Association) Silicon Valley Chapter's monthly meeting on August 11, 2006 to learn about Sarbanes-Oxley (SOX) efforts from the C-level exec's perspective. The panel line-up was excellent: Bill Vaas, President/COO of Sun Microsystems Federal Inc; Maria Shaw, Director of the Risk Control Group at McKesson; and Jeff Brzycki, Senior Director of IT Shared Services at Symantec Corporation.

The event proved to be a lively discussion between ISACA attendees and the panel, moderated by Ray Cheung, Director of Risk Advisory Services at KPMG. Here are three key SOX lessons that I took away from the discussion:

  1. Reap the benefits of SOX. A common theme throughout the discussion was that of the upside and downside of SOX compliance requirements. On the upside, SOX has forced companies to take IT and financial processes and controls more seriously. Things like single sign-on, access management, segregation of duties and identity management have become more pervasive because of SOX, and companies are finding that they are ultimately better off for it. According to Jeff Brzycki, for those that have taken the proactive approach, companies have found that a SOX byproduct is "continuous improvement which otherwise may have been ignored." On the downside, some aspects of SOX requirements have forced companies to duplicate efforts or created manual controls which add up to unnecessary spending. As Bill Vass summed it up: "SOX can bring CIO's peace of mind, but unfortunately it sometimes brings unnecessary overhead as well." Bottom line: Companies who are now in their 2nd or 3rd year of SOX compliance have learned to be more proactive and build risk management and compliance automation plans into the IT development process up front. Automating compliance efforts through technologies such as log management and intelligence (LMI) can help to reduce duplication and unnecessary spending.
  2. Designate SOX leaders. According to the panelists, when executives are grilled about financial and IT controls, it has been all too common to hear those executives say to their direct reports, "We're OK, right?" -- and so on, down the chain of command. To counter this dangerous "pass the buck" mentality, different companies are taking different approaches, but all are finding it necessary to put empowered managers in place to oversee their SOX and other compliance programs. Vass' recommendation was to set up an executive oversight committee and have a senior-level person manage the program on a day-to-day basis. Shaw suggested naming a C-level compliance exec to oversee not only SOX, but all compliance programs throughout the company. Whatever the approach, the important thing is to make sure there is accountability. According to Brzycki, the reality of SOX is that "personal accountability is a key reason to get C-level execs involved up front."
  3. Move beyond compliance to total quality management (TQM). According to Jeff Brzycki, "SOX brought awareness of IT general controls to a larger group of people. These controls should be there, for companies to be effective and to maintain integrity in their IT operations. SOX simply reinvigorated the grasp of the importance of this. So, yes, SOX can evolve into a Business Quality exercise, but today compliance is still the number one objective." It was agreed across the panel that today there is still too much "voodoo" around compliance and that companies need to get more serious about using technological tools to take compliance to the next level. According to Maria Shaw, "While we're not there yet in terms of moving beyond compliance to TQM, it is imperative that we put in place repeatable processes to be able to measure success at a higher level. Today's manual processes and disparate systems are forcing companies into the weeds, making it difficult to step back and see the big picture." While her company now tackles each compliance requirement as a separate project (HIPAA, SOX, etc.) she envisions them moving to the point of putting everything through the same process.

According to Brzycki, "SOX is more than an internal issue, it's a brand issue." We at LogLogic couldn't agree more. Staying proactive on the compliance front is simply good for business. And using LogLogic's advanced appliances for log management can allow a company to meet these goals - without breaking the bank. - Heidi

Technorati : , , ,

Posted by on August 14, 2006 in Compliance | Permalink | Comments (0)

Finanical Institutions Face Surge In External Attacks

Deloitte's latest Global Security Survey says that the world's largest financial institutions have faced a surge in the number of security attacks over the past year, particularly from external sources.

You can download a copy or, here are some of the highlights - all of which point to the need for next generation log management and intelligence solutions.

  • More than three-quarters (78 percent, up from 26 percent in 2005) of respondents confirmed a security breach from outside the organization and almost half (49 percent, up from 35 percent in 2005) experienced at least one internal breach.
  • The top three most common attacks over the past 12 months included ones intended to extort some form of monetary gain. Phishing and pharming were employed for more than half (51 percent) of external attacks, followed by spyware/malware (48 percent).
  • Insider fraud (28 percent) and customer data leaks (18 percent) were cited by respondents among the top three most common internal breaches. Ninety-five percent of participants indicated their information security budget grew over the past year.
  • Almost three-quarters (72 percent) of financial institutions who experienced a security breach indicated the estimated amount of damage for the organization, including direct and indirect costs, was in the range of US $1 million.
  • 83 Percent Fear the Enemy Within: Despite the publicity received by external security threats, attacks from within are a great risk. In fact, among the TMT companies whose security was breached in the last 12 months, half were attacked from inside the company. Less than half (47 percent) of respondents said they were very confident that their infrastructure is property protected against internal attacks, as opposed to almost two-thirds (63 percent) for external attacks. The vast majority of TMT companies (83 percent) said they are concerned about employee misconduct involving information systems.

Posted by on June 27, 2006 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

The Log Management End Game

Mike Rothman has an interesting post on the SIM endgame. He flags one on the primary differences between SIM and LMI:

But auditors and compliance type folks are all about reports. They are not about remediation. They need artifacts of what has happened and in many cases they have to forensically look at the data to piece together the circumstances around an issue. Log management solutions cater to these folks. They gather a crapload of log data while maintaining forensic integrity. They are even starting to add value by putting a reporting engine on top of it to provide the auditors with - you guessed it - a set of artifacts to show what has happened and how it proves compliance.

Technorati : , ,

Posted by on June 09, 2006 in Compliance , Log Management & Intelligence | Permalink | Comments (0)

A Short Primer On PCI Compliance

If you're a credit card merchant, service provider or retailer who processes, stores and transmits cardholder data, you have a fiduciary responsibility to protect that data. But with data volumes increasing exponentially and tolerance among regulators and consumers falling to new lows, meeting that responsibility is indeed challenging.


The Payment Card Industry (PCI) Data Security Standard, resulting from collaboration between Visa and MasterCard, provides a solid framework for safeguarding credit card data with 12 specific requirements, many of which can only be met with log management and intelligence. Included are specific mandates related to log data.

The PCI standard applies to store merchants, banks, service providers and card processors. And that's not all. PCI extends to all system components connected to cardholder data environments, including network components (firewalls, switches, routers, security appliances, etc.); servers (web, proxy, database, email, authentication, etc.) and applications, both internal and external. In other words, PCI compliance is a lot of work.

The process of complying with PCI compliance can be viewed in three stages:

1) Collection and storage-You must be collecting and securely storing all log data so that it is available for analysis, yet tamper-proof and secure.

2) Reporting-You must be able to prove compliance on the spot if audited, and present evidence that controls are in place for protecting data.

3) Monitoring and alerting-You must have systems in place, such as auto-alerting, to help constantly monitor access and usage so that administrators are warned of problems immediately and can rapidly address them. These systems should also extend to the log data itself - can you prove that log data is being collected and stored?

Underpinning this is the need for a clear set of IT controls. These provide the framework for evidencing and attesting to compliance. Controls like COBIT and ITIL provide a systematic way of not just answering PCI, but also other compliance mandates such as SOX.


An LMI solution like LogLogic helps companies reduce the labor and costs associated with PCI compliance by automating these three steps. The solution provides collection and secure storage of 100% of log data collected from all devices, servers and applications, along with compliance-specific reporting templates that organize data quickly and accurately to satisfy auditors. Finally, the solution allows administrators to set custom alerts and continuously monitor network activity.

Complying with PCI, merchants and service providers not only meet their obligations to the payment system but create a culture of security and operations effectiveness that benefits everyone. PCI compliance limits risk and builds confidence in the payment industry, and safeguards data from all types of payment network fraud. Which goes to show that what is good for the bottom-line can also be good for the top-line.

Technorati : , ,

Posted by on June 06, 2006 in Compliance , Innovation | Permalink | Comments (0)

IT Auditors Turn To Cobit For Sarb-OX Guidance

ComputerWorld says "increasingly, to keep themselves and their companies out of trouble, IT auditors are going by the book - the Cobit book on IT governance". Interestingly, they also point to the increasing integration of Cobit and ITIL. One of the many benefits of Cobit is that it fosters a strong dialog and partnership between IT, business users and corporate auditors.

These are some of the many reasons that we standardized on Cobit for SOX compliance reporting and alerting.

Technorati : , , , ,

Posted by on June 05, 2006 in Compliance | Permalink | Comments (0)

A Marriage of IT Governance and IT Services Management

“Operational Efficiency” is one of four priorities identified in recent interviews with 82 IT executives by Andreas Antonopoulos from Nemertes Research. Companies are focusing on data-center management and operations, attempting to cut costs, improve efficiency, and better align IT spending with business needs and service demands. A whopping 75% of respondents see a shift in IT culture to "IT as a service" and over 50% of respondents have adopted governance and delivery standards such as ITIL and COBIT.

It is encouraging to see the ITIL and COBIT frameworks finally being mentioned in the same breath. ITIL is a favorite with IT Operations, whereas COBIT is the darling of auditors and security personnel. COBIT has a strong association with “SOX Compliance” but COBIT can also be used to improve the quality of IT and to cut costs by reducing downtime. By the way, “availability” was one of the other priorities identified.

Similarly, successful Log Management and Intelligence implementations reach beyond security monitoring and include COBIT and ITIL controls around identity and access management, change management, business continuity and IT infrastructure (service level agreement) monitoring.

The hidden message in all of this is when selecting a Log Management and Intelligence system make sure to involve your operations folks to evaluate your vendor on operations features such as fast, ad-hoc reporting and search.

- Dominique

Posted by on May 24, 2006 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | Comments (0)

Looking Back At Interop

We're catching our breath after a crazy week at Interop and the launch of LogLogic's PCI Compliance Suite, Project Lasso and Log-ED training programs. If you're interested in reading more, here are a few of the highlights:

  • Infoworld on LogLogic getting into Open Source
  • NetworkWorld on Vendors easing compliance
  • Cnet on LogLogic adding an open source foundation
  • The Register on users not having to mess around with Windows agents

There was plenty more written, all pointing to the intersection of logs and compliance - and logs and open source. Expect more from us in both areas in the coming months.

Posted by on May 08, 2006 in Compliance , LogLogic News | Permalink | Comments (0)

Logs & The Law

In the end, a firm's IT systems are only as secure as its employees' intentions and actions. Witness that close to 70 percent of network security incidents at Fortune 500 companies are caused by employee actions -- 30 percent malicious and another 39 percent inadvertent -- according to a 2004 survey by the Ponemon Institute, an Arizona think tank.

This and more appears in a great story in Legal Technology that flags the importance of logs:

The first step toward better data security could be as simple as enabling that feature, clearing storage space on servers for the logs, and having an IT or human resources employee review them on a regular basis. Logs can get very big very quickly in a large firm, but automated security tools, such as those built into Microsoft server software, can be set to flag only unauthorized access. For authorized access, however, having a person look the logs over is the only way to catch suspicious activities, Zawa says.

Even if a firm doesn't have the resources to have someone routinely review logs, they provide an essential record if someone is suspected of network tampering. Brian Conlon, CIO at Washington, D.C.-based Howrey, says logs are also useful when data is lost accidentally, because a records administrator can review a log to find out who was the last person to use a missing file.

This is precisely the problem LogLogic solves: 100% collection of log data from 100% of devices - at industry leading speeds of 50,000+ messages per second - with legally valid storage - and alerting and reporting at 'Google-like' speeds.

Posted by on December 04, 2005 in Compliance | Permalink | Comments (0)

Steps for preserving the integrity of log data

NOVEMBER 03, 2005 (COMPUTERWORLD) - In the past few years, companies have spent billions of dollars to update their IT infrastructures to meet requirements from various government regulations such as Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act.

One of the more noticeable and most important recommendations of these regulations is record-keeping. For example, Sarbanes-Oxley recommends that all companies "maintain financial records for seven years." In order to ensure the accuracy of corporate financial and business information, this recommendation also pertains to records that are used to "audit unauthorized access, misuse and fraud." Other regulations such as HIPAA also recommend keeping records for up to six years.

Altered log data prohibits court admissibility

The integrity of information is crucial when submitting evidence to the court. Just like crime-scene evidence, which prosecutors must prove hasn't been tampered with, electronic data submitted to the court must adhere to the same stringent requirements. As such, log data generated by the IT infrastructure also has to be archived in its original and unaltered format.

Reports generated from the logs are usually insufficient to convince the other side (defense or prosecution) that they haven't been tampered with. Lawyers from either side may question the accuracy of the reports and will want to perform their own analyses. For example, if you claim that someone has sent out data from the Sarbanes-Oxley-related financial servers, how do you substantiate that claim? Tampered data can't be used as evidence to prove your claim. In these scenarios, unaltered logs have to be provided.

In addition to the unaltered logs, evidence may be needed to prove that the logs weren't tampered with. Some companies have chosen to digitally sign the log files collected and then keep the digital signatures at a location separate from the logs. Others have chosen to store logs on WORM (write once, read many) drives such as CD-ROM/DVD-ROM or storage devices such as EMC Corp.'s Centera. Both processes ensure that tampering of logs can be detected or prevented.

But why would the court or the auditors trust the archived unaltered logs? Auditors are always looking to see whether the log data can be tampered with or modified at any point during the collection process. Was the transport encrypted over the WAN to ensure confidentiality? Were the logs signed during transmission to ensure integrity? What programs or processes handled these logs during the collection process? Are these programs or processes clearly documented to ensure that no fake data was injected into the stream? Were any users involved during this collection process?

This is where clear and detailed documentation on the collection process is required. The process of how logs are handled from the point where logs are generated to where logs are archived -- and everything in between -- must be clearly documented to prove that the log collection process is reliable and secure and that no data was tampered with. The documentation process should include details such as the encryption or digital signature algorithms used during transmission, the likelihood of data loss during the collection process, any manual process that required human intervention and users who touched any of the logs,

Long retention periods allow timely investigation

Even though there's no explicit regulatory requirement that companies must keep all log data for the full recommended time period, many experts agree that for Sarbanes-Oxley or HIPAA compliance, unaltered logs should be kept online for at least 12 months. However, your auditors or your corporate policy may require a longer retention period. If you don't already have a corporate information retention policy, create one now.

Having an online archive of log data allows timely investigations and also provides long-term reporting for the auditors. Many security investigations, especially those involving security policy or acceptable-use violations, may require mining of logs as far back as 12 months to ensure that no details are missing. Without the log data online, the investigations will take much longer, since the IT administrators would have to restore logs from off-line backup, such as tapes.

Regarding financial auditing, the auditors may also want to go back several quarters to look at the financial results. In order to prove the integrity of the financial data, related log data might be required to prove that there was no unauthorized or inappropriate access during those periods.

The importance of keeping unaltered logs for evidence, whether for the court, the auditors or human resources, can't be underestimated. It should be one of the most critical requirements when building your compliance infrastructure.

Jian Zhen, CISM, CISSP, is the director of product management at LogLogic.

Posted by on November 05, 2005 in Compliance | Permalink | Comments (0)

Get Compliant. Improve Your Business.

IDC reports that respondents to their survey "The Compliance Chasm", indicated that they were not only anticipating improvements in financial management activities but overall business performance management as well. 88% of respondents said that Sarbanes-Oxley would have a positive impact on business performance. As a result, IDC reports, a number of organizations have now moved from viewing compliance as a burden to using compliance requirements as an opportunity to improve business processes and manage risk.

"Sarbanes-Oxley requires constant vigilance over financial reporting processes that can extend throughout the enterprise," said study author Kathleen Wilhide, director, financial compliance applications and BPM software at IDC. "As a result, it is no surprise to see that technology, including compliance software, is playing a vital role in the compliance effort. The implications of compliance software reach beyond meeting Sarbanes-Oxley mandates; the software also has the capability to contribute to increased efficiency and profitability across the organization."

Log management and intelligence is a foundational activity for achieving SOX compliance. We've got more info on our site if you are interested.

You can read more here.

Posted by on October 20, 2005 in Compliance , LogLogic News | Permalink | Comments (0)

Visit loglogic.com

I ♥ Logs

Subscribe to this blog’s feed RSS

January 2010
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Categories
Archives
Blogroll
Blogroll
Compliance
Good Reading
LogLogic
LogLogic Partners
Sites We Watch