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!
Posted by Anton Chuvakin on April 16, 2008 in Compliance , Innovation , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
It is about time: specifically, timing logs. As I said in my Log Trust and Protecting Logs from Admins posts, the issue of trust is critical in the logging world. After all, logs = accountability; and the latter in unthinkable without trust. If we are to at least pretend that logs objectively record events and user actions, we need to unambiguously establish WHAT happened and WHEN. This post deals with the 'WHEN' issue.
So, can we trust that the time stamp in the log file or the one added by the log management system correctly describes when the recorded event actually happened?
We will start from locating the timestamps in logs. Most of the log formats, such as file-based logs (web servers and proxies, various application, some security gear, etc) and syslog, Windows event logs, database audit tables, etc contain a timestamp. Here are a few examples:
In fact, once I saw somebody use a timestamp to define logs as "timed records of IT activity." So, time is critical for logs being, well, logs :-) At this point it is worthwhile to note that file-based logs will contain a timestamp IN the file, while syslog records arriving over the UDP or TCP port 514 connection are usually timestamped upon arrival BY the syslog daemon (using its own "knowledge" of time) - and then it shows up in the syslog files in /var/log.
Let's assess whether this "in-log timestamp" provides an adequate way of timing the actual events that are being logged. Answering this question is important for investigations and troubleshooting, but becomes nearly a matter of life and death in case of log forensics. Here are some fun cases and issues to consider:
First, what are the chances of a completely false timestamp in logs (BTW, today is Jan 1, 1970!) When might that happen? Typically when a logging system own clock is reset or not set correctly. This timestamp clearly should NOT be trusted. How do you then time this event? This is a separate story that will be discussed some other time...
Second, it’s always 5PM somewhere: in other words, what time zone are your logs in? EST? PDT? GMT? UTC? Or any of more than 24 other possibilities. If you have no idea, you should not trust the timestamp.
Third, are you in drift? Is your system clock? Those pesky drift seconds turn into minutes that then work to undermine the accuracy of timing the records (and thus your certainly and trust in evidence quality)
Fourth, syslog forwarder mysteries are plenty: some of the syslog messages will be delayed in transit and then be timestamped by the final recipient daemon, thus completely losing when the event was originally logged. Admittedly, this delayed syslog messages are rare, but as more people employ buffering syslog daemons (e.g. syslog-ng), it might happen more often.
Fifth, more esoteric, but still real (and really annoying!): some system logs will contain two timestamps. If you don't possess in-depth knowledge of this specific log, confusion has a chance to undermine the trust as well (so, which timestamp should I use?)
Sixth, most people will not think that they will fall to something that stupid: 24 vs 12 hour time. However, when facing an unknown (and poorly designed!) log format, beware that 5:17 might well be 17:17...
Finally, if you know that something got logged at 5:17AM, then when did it happen? Beware of "Log lag!" This issue is actually too tricky to give it justice here... The simplest example is when the process leaves a log record when it exits, not when it starts, which might happen days earlier (thus creating a log lag).
As we dive into more issues with timing logs, we also need to think about sequence timing and absolute timing. Sequence of logged events is a critical fact! Miss the sequence and the whole “house of cards” goes … But! Absolute time is also important! Can we be assured of both being correct all the time? (hint: no)
So, when you look at logs next time and you see a timestamp there - start thinking about all of this :-)
Posted by Anton Chuvakin on April 04, 2008 in Innovation , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
One of the truly major challenges of log management is obtaining trusted logs of administrator activities, sometimes broadened to cover so-called "privileged users" (see my log trust pyramid post for more discussion). Many consider it to be the "lost battle" of logging. However, logging administrator access and actions is more important than ever today; it is one of the few workable ways of dealing with insider attacks.
So, I created this little table where I try to summarize some ways of protecting the C-I-A (confidentiality, integrity, availability) of various logs from administrators and privileged users (some successful and some very hard to pull off). Note that in the case of databases and applications, we need to protect their logs from DBAs and application admins and not from the underlying server platform admins.
UPDATE: table below might be corrupted in some blog readers; see the full table here.
| "C" - prevent admins from reading logs | "I" - prevent admins from changing logs | "A" - prevent admin from disabling logging | |
| Standard Unix | Very hard! Maybe stealth logging (sebek) | Remote logging via syslog to another server, append-only log files (via RBAC) | Very hard! But this is logged and thus can be detected (also: stealth logging) |
| Windows server | Very hard! Maybe stealth logging (sebek for Windows) | Pull the logs ASAP to a central server | Very hard! But this is logged and can be detected (also stealth logging) |
| Databases | DBA activity log stored outside the database (append-only access) | DBA activity log stored outside the database (append-only access) | DBA activity log stored outside the database |
| Firewalls and network gear | Remote logging via syslog to another server - no local logging | Remote logging via | Very hard! But this is logged and can be detected |
| IDS/IPS boxes | Remote logging to another server - no local logging | Remote logging to another server, inaccessible to admin | Very hard! But this is logged and can be detected |
| Misc enterprise applications | App admin log outside the app (not readable to application user) | App admin log outside the app (only appendable by the application user) | Very hard! But this is logged and can be detected |
UPDATE: table above might be corrupted in some blog readers; see the full table here.
Comments?
Posted by Anton Chuvakin on November 26, 2007 in Innovation , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on June 28, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)
Earlier in June, Mark Ford, who lead's Deloitte and Touche's Security and Privacy Services practice, was interviewed by IT Security.
According to Ford, IT security is one of the top issues for CIOs. However, he also noted that a corporate focus on IT security is quicker to take hold in information-centric organizations (banks and other financial service organizations, for example) than in industries like manufacturing or retail that are more geared towards consumers and whose focus is on business operations. With the increase in regulatory focus of such mandates as PCI-DSS and SOX, this has changed over the past few years as corporations in a variety of industries need to have strong IT security in order to be compliant.
What does this mean? Ford commented that historically, companies have put emphasis on the perimeter threat as the key component of IT security. But now, security emphasis is shifting towards a layered defense of the IT infrastructure. The perimeter is still important, but can no longer be considered the main component.
A shift away from the traditional security approaches and towards log management and intelligence, which allows for just the layered sort of approach Ford approves.
Posted by Jill Ratkevic on June 25, 2007 in Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on June 19, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on June 07, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on June 07, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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 Jill Ratkevic on June 04, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on May 29, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
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. . . "
Posted by Jill Ratkevic on May 17, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on May 01, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
"This is a pattern of security breaches in government agencies that is becoming all too familiar. But even with this familiarity, it's inexcusable in every instance," Space said in a written statement. "Congress has a responsibility to make sure that the agency is doing everything possible to rectify the situation, make sure that it doesn't happen again, and make sure that victims are notified and compensated."
Posted by Jill Ratkevic on April 27, 2007 in Risk Management , Security | Permalink | TrackBack (0)
Posted by Jill Ratkevic on April 20, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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..
Posted by Jill Ratkevic on April 08, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on March 29, 2007 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)
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?
Posted by Jill Ratkevic on March 28, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
A new report form CA-based Infonetics Research on the state of worldwide network security appliance and software sales says that there has been an increase of 15% to $4.5 billion between 2005 and 2006, forecasting that the network security market industry will surpass the $5 billion mark for the first time in 2007.
Jeff Wilson, principal analyst at Infonetics Research says that "the most important appliance category to watch over the next year is secure routers."
Key findings in the Network Security Appliances and Software report are:
Secure routers account for 29% of the total integrated security appliance market in 2006 and will continue to increase their share of the market through at least 2010
Worldwide SSL VPN gateway revenue jumped 40% in 2006, following a 61% increase in 2005
Worldwide IDS/IPS (intrusion detection and prevention systems) revenue grew 19% in 2006
Cisco continues to lead the overall network security market, with 38% worldwide revenue share in 2006, posting growth in all network security market segments tracked by Infonetics
Juniper and Check Point are tied for second, each with 9% worldwide revenue in 2006
More info and to preview Infonetics reserach is here.
Posted by Jill Ratkevic on March 20, 2007 in Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Jill Ratkevic on March 08, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
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 Andrew Lark on March 07, 2007 in Compliance , Risk Management , Security | Permalink | TrackBack (0)
LogLogic's Anton Chuvakin's "Five Mistakes of Data Encryption" article just went live at ComputerWorld. This article covers some of the mistakes that often occur when organizations try to use encryption to protect data at rest and data in transit and thus improve their security posture.
The first mistake is not using encryption when it is easy and accepted. I'm talking about those pesky plain text protocols such as telnet and FTP. One can argue that people should have abandoned the above protocols for a host of other reasons, but, as the latest Solaris telnet 0day fiasco indicates, enough people are still using them.
Read the rest of the Anton's top 5 list here.
Posted by Jill Ratkevic on February 26, 2007 in Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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 Jill Ratkevic on February 21, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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 Jill Ratkevic on January 31, 2007 in Compliance , Innovation , Risk Management , Security | Permalink | TrackBack (0)
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 Jill Ratkevic on January 29, 2007 in Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Andrew Lark on January 22, 2007 in Compliance , Log Management & Intelligence , LogMatters , Risk Management | Permalink | TrackBack (0)
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?
Posted by Andrew Lark on December 05, 2006 in Compliance , Log Management & Intelligence , Risk Management | Permalink | TrackBack (0)
Consumer Reports estimates that in the United States, some 62 million adults plan to go shopping nationwide on Black Friday, the day after Thanksgiving that has become synonymous with the start of holiday shopping season. Reuters says that "consumer spending accounts for some two-thirds of U.S. economic activity, and the holiday season typically accounts for about one-fourth of retailers' annual sales." That is alot of retail transactions happening between now and the close of 2006. Just how safe is credit card data in this watershed bliss for retailers?
It might not be safe enough for to meet compliance mandates set forth by credit card companies. PCI DSS is now a reality for many of those retailers whose customers are lining up to get into the stores when they open tomorrow. And, the noose is tightening and how... Just last month Visa reportedly took aim at the nation's largest merchants with fines that start at $10k per month.
Protecting stored data, and being able to prove that you properly secured that data is of vital importance in avoiding big fines. Effectively collecting, alerting, securely storing, searching, and reporting 100% of your log files can help ensure PCI compliance -- continuously. On December 6 we will be hosting a webcast to help give you a playbook to get compliant before those packages are even wrapped under a tree or next to your menorah this holiday season. Register here.Posted by Andrew Lark on November 23, 2006 in Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
Anton is focused on discovering hidden gems in log data among the mountain of log files generated on enterprise systems. Over at his O'Reilly blog, he is offering a few tips on how Sendmail, Exchange, QMail, Postfix, and other MTA logs hide a plethora of insights that are useful for email security and email performance management. To uncover rare and unusual messages easily among the hundreds of other messages out there, Anton offers a quick tutorial on mining the log data for the unusual. His approach to unearth that elusive 10% of messages that are different and potentially ominous? Reviewing and watching for errors and failures in the set of rare messages can make investigations more effective when you review log records from the same timeframe. Another key tip -- look for gaps in logging, especially those gaps that occur immediately following rare messages.
Posted by Andrew Lark on November 14, 2006 in Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
Headlines of the past week are showing that the need for good forensics policies and technology for IT is imminent. From Four Arrested in Chile for Cyber Intrusions to Fourteen Arrested in International ID Fraud Investigation. Even McGruff the crime dog, is making headlines with his campaign to "Take a bite out of Cyber Crime."
Log Management can keep systems running optimally and can enable Enterprises to quickly comply with mandates, but the case for good forensics is often overlooked until it is too late. Security experts understand the importance of a well formulated incident response capability in answering compliance and security mandates.
Learn more about incident response at our upcoming SC Magazine Live Webcast on November 15th at 11amPT, Integrating Log Analysis and Forensics to Deliver Superior Incident Response.
Topics to be covered include:
Defining forensics & LMI best practices - Integrating people, processes, and technology into a seamless forensics and compliance program
Achieve Continuous Compliance and rapid incident response through best-in-class incident response and forensics
Deploy next generation log management and intelligence and host-based investigative technologies as a standard operating procedure for incident response and compliance investigations.
Posted by Andrew Lark on November 09, 2006 in Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
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.
Posted by Andrew Lark on June 27, 2006 in Blinks , Compliance , Log Management & Intelligence , Risk Management , Security | Permalink | TrackBack (0)
“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