Anton Chuvakin Blog - "Security Warrior"

Links for 2008-05-16 [del.icio.us]

2008-05-17T00:00:00-05:00

Layer 8 - R, C, G

In Passing on DLP

2008-05-16T19:08:00.001-07:00

Now, I am not some world-famous DLP analyst, but it doesn't mean that I cannot have an opinion on this "searing-warm" :-) security concept: "data leak 'prevention'" or DLP (notice the double quotes around prevention...)

I admit that in the past I poked jokes at DLP for being "ADLP", with "A" standing for "accidental." Indeed, most of the technology approaches I've seen were "good enough" for preventing accidental leaks (e.g. Excel sheet with SSNs being emailed to an external party by mistake) and for preventing truly idiotic "insider" attacks of the same nature. Whether they sniffed or used desktop agents, the tools were good enough to do the above, but not much more (or, they allowed you to do more, but via a truly ginormous effort by your security team). And then a retarded kindergarten kid can bypass them in his sleep without working up a sweat ...

In other words, DLP was for keeping honest (but sloppy) people honest and keeping idiots idiotic (but a bit safer). Which is, don't get me wrong, pretty darn useful: after all, overall, employee mistakes still cause more damage than hackers (!)

However, whenever I heard about DLP, I always felt some deeper longing for more - maybe for a technology that CAN actually stop some, clearly defined classes of malicious data theft, perpetrated by non-idiots.

What such technology might be? Well, IMHO, it should have three things:

Easy on the end user (=information owner) - thus no manual information tagging needed (don't you know, its dead!)
Easy on the tool operator (=security team) - thus no super-granular policy-writing needed (and please - spare me the regexes!)
Effective enough to stop malicious insider of reasonable skill over specific information channels- thus, some new technology for accurate detection of possibly modified documents across channels (e.g. common network)

Tough to match? Yup, it sure it. But that's not all: I'd like it to defend against theft of structured, unstructured and structured->unstructured (e.g. database contents pasted to email!) information over just about any network channel (not device theft and not USB/portal device download - these are a different story). What's more, I think that to enable #3 above the DLP "box" needs to actually understand what the document is about and to do it in a human-like fashion (Yes, including rephrased (!) content. Yes, I am picky :-)).

The above clearly does NOT mean that the technology is not bypassable - there is always an encrypted zip file and gpg, custom encrypted network protocols, or even a screenshot emailed, etc (not even going to device theft, USB xfers or camera phone + screenshot + MMS). It just means that it takes DLP a few big notches up from "anti-retard defense" to blocking a malicious and dedicated non-IT employee from stealing the crown jewels.

And, if one is trying to be honest about DLP, he need to define what is out of scope (after all, only narrowly defined problems are actually solvable in this space, not "our MagicBox 6.1 will block ALL data theft," which is absurd - if you believe that, you need your head examined).

I was pretty shocked to learn that something like this actually exists today: the next wave of DLP start-ups is about to emerge. For example, NexTierNetworks can detect information traces even in modified and heavily edited documents (I would like to try rephrasing as well; I suspect it will work!). When I saw a demo I was pretty impressed that you can get a financial document, change a few things here and there, paste it to email - and the system will still stop it by saying "uh-uh, this is sensitive info, no can do" :-) Mind you, this is not what current DLP vendors call "fingerprinting," since it actually uses what the document is about i.e. works on a - hate the word! - semantic or meaning level. So, DLP + a bit of NLP (the other NLP) = magic :-)

As a disclosure, I have to say that I just joined their Advisory Board, but, as you can guess, I joined because I am impressed (not "impressed because I joined!" :-))

Technorati tags: security, DLP, new technology

Why Is ISO2700x Hot in UK, but Not in US?

2008-05-16T11:36:00.001-07:00

First, something hilarious: I was teaching this brief course on logs overseas and touched upon a subject of ISO17799. So, having recently read how many companies in the US were ISO17799 certified, I asked my audience whether they could guess what the number was. One guy volunteered an answer, after some hesitation: "Less then 50%?"

That's "percent", folks :-)

I said to him: "You are right!" and laughed - "It is indeed less then 50!" 50 as in "count" (I read somewhere at the time that 49 companies were certified US-wide)

So, ISO17799 is hot in some countries: UK, Japan, Russia (where it is a basis for a set national standards), many others. But not in the US.

I have long been puzzled about this. What's the story?

The most likely explanation is that every security manager worth his salt read ISO17799 documents and then used the ideas and material in his own policies, procedures, etc. On the other hand, he sees no motivation whatsoever to invest in certification - since nobody is making him do it (no equivalent of a PCI auditor is standing nearby with a big axe...)

Another explanation that due to longer history of security management in the US (compared to other countries), home-grown approaches took root and no external standard will dislodge them?

Yet another hypothesis goes like this: in the US, it is more important to do a good job [managing security] than to be "standards-compliant." Is the opposite true in Europe and Asia? I dunno...

Or maybe ISO stuff is seen as "that Euro thing?" Exotic like a Hungarian chick, but just as relevant :-)

Any ideas? UK scene, any ideas? Do you care for ISO17799 at all? As a useful document to read or a something to be certified in?

Another Old Presentation: What Every Organization Must Log and Monitor

2008-05-15T15:11:00.000-07:00

Finally, I decide to "liberate" this presentation as well: "What Every Organization Must Log and Monitor" circa 2004.

This is still very useful and relevant; also, many people will appreciate my attempt to do the impossible i.e. give a simple answer to a very complex question (BTW, it rarely works :-))

So:

| View | Upload your own

Links for 2008-05-15 [del.icio.us]

2008-05-16T00:00:00-05:00

Thinking Beyond the Ivory Towers
people who write papers in LaTeX two-column format end up saying the sky has a high negative trajectory,
Addressing the Insider Threat - Realtime IT Compliance
Shimel Wants To Sell You A Dead Parrot. On An Iceberg. Slathered In GRC | securosis.com
StillSecure, After All These Years: Rich Mogull does his best Stiennon imitation, says GRC is dead

Fun Security Reading - 3

2008-05-15T14:11:00.001-07:00

Instead of my usual "blogging frenzy" machine gun blast of short posts with links and commentary, I will now combine them into my new blog series "Fun Reading on Security" or "FRoS." Here is an issue #3, dated May 15, 2008.

First, watch Dave Aitel beats the dead horse of academic security "research." Quote: "people who write papers in LaTeX two-column format end up saying the sky has a high negative trajectory." (other examples)
I work for a vendor, but I am not "vendor scum." What is the difference? If you write a paper about a fake trend or about a non-existent phenomenon (that your marketing department created) with the sole intention of selling your product while masquerading your piece as "objective content", you will probably be called "vendor scum." Example: do you know why insiders are dangerous? Because of telnet and modems (no shit!) :-)
Rich Mogul drop-kicks GRC. Then kicks it in the balls. Then steps on it. Fun read, for sure.
Did somebody just utter "ROI"? Yeah - and that means katana blades sharpened, flamethrowers charged, pet trolls enraged :-) Yes, the beast is back - with a vengeance. Bruce Schneier hits it with +5 Flaming Blade, it doesn't die, it bites back ... again. If you love/hate ROI, read these. And Mike R comment here. Can we just replace the "R"-word with "economic measure of security" or "security efficiency?"
Does anybody with at most half a brain believes that "almost one out of every three individuals who were informed of a data security compromise involving their personal data have ceased doing business with the company that experienced the incident" (source here and more commentary here)? Well, same people who believe FBI/CSI surveys, I guess :-) UFO? Spoon bending? Santa Claus anyone?
NEWSFLASH!!!! Employees needs to be monitored!!! Wow!!! Reeeeally? Well, it is news to some people. Mike R makes good fun of them here.
Harebrained paper about PCI and using cards (credit and debit), which serves as a perfect illustration of how some people perceive risk. Repeat after me: you are not liable for mis-use of your credit card, your bank is. Debit card? Very different story!
So, risk, yes. A really good piece about risk is here. Then again, it is RiskAnalys.is? :-) More on risks of compliance stuff (also good) is here.
Richard clearly, succinctly, brilliantly explains the "security chasm" here by commenting on Greg's article (featured in my previous FRoS): "The first camp spends more time talking about "enabling business" and "elevating the infosec conversation" while the second camp deals with the mess caused by the first world's ignorance of security problems."
Security reading? Nah, fun security listening (that is, unless you are sick of hearing about RSA 2008 again), where we discuss - yes, you guessed right! - past RSA 2008 show.

Enjoy!

Links for 2008-05-14 [del.icio.us]

2008-05-15T00:00:00-05:00

Another Old Presentation: Security Metrics

2008-05-14T16:23:00.000-07:00

Another oldie, but ... well, maybe not goldie: my 2005 presentation on security metrics.

Links for 2008-05-13 [del.icio.us]

2008-05-14T00:00:00-05:00

More On Non-lethal Weapons: Electrified Shieds

2008-05-13T15:12:00.000-07:00

Two quotes are enough, really:

"The kit "features a peel and stick perforated [f]ilm, power supply and necessary conversion equipment. This laminate becomes electrified providing a powerful deterrent to protect officers and keep suspects or rioters at bay." What could possibly go wrong?"

Love that last sentense...

and

"It's all part of the Office of Law Enforcement Technology Commercialization's Mock Prison Riot"

Wow, a prison riot, what a fun event! ;-)

Read here.

Links for 2008-05-12 [del.icio.us]

2008-05-13T00:00:00-05:00

Senate Votes to Prevent Genetic Discrimination in the Workplace | Privacy Digest
Spire Security Viewpoint: The Best Virtualization Joke Ever...
The Forrester Blog For Security & Risk Professionals
Visionary folks see this promised land of information security and risk management being in the green valley of business-driven risk management, where data, identity, policy, and compliance are crucial cities (elements).
Reflections on the 2008 RSA Conference (The Falcon's View)
Communicating about risk - part 1 | RiskAnalys.is
Schneier on Security: Third Annual Movie-Plot Threat Contest Semi-Finalists

Log Management: Insight From Ancient Times (The 80s, That Is :-))

2008-05-12T17:35:00.000-07:00

My boss has posted two of the very fun blurbs on log management to our blog; do check them out, especially if you are the fan of the 80s :-)

Fun blurbs from the above:

"In surveys, 70%+ of organizations confess their primary budget for log management still comes from compliance. However, this same group admits for years now that 70% of their use of log data is driven by operational needs such as fault detection and problem isolation."

"The requirement to collect 100% of all log messages of all log sources is even more important in operations than it is in security." (why?)

"Rather than replacing these systems with yet another console, most companies are going to look for the ability to integrate a new information source, log data in this case, into the existing fault management console. Web services likely will be the mechanism of choice."

Another Old Presentation: Security Management Trends

2008-05-12T17:30:00.000-07:00

Now, I have NO idea whatsoever why somebody will be interested in my "Security Management Trends 2004" (!) presentation, but here it is, released from cold storage :-)

A Few Upcoming Presentations

2008-05-12T17:21:00.000-07:00

Just wanted to highlight a few of my upcoming presentations, live and web-based:

"Anton live:"

Webinars and webcasts:

NIST 800-92 for FISMA (And Beyond) + some LogLogic product presentation on May 20
'Worst Practices' of Log Management webcast on May 22 (this one is FUN!)
SANS Log Management Survey Review (this WILL be fun, I am warning you! :-)) on June 5th, 2008.

Enjoy!

UPDATED: 5/13/2008

Links for 2008-05-09 [del.icio.us]

2008-05-10T00:00:00-05:00

Now, Somebody Please Tell Me This is A Spoof ...

2008-05-09T17:21:00.000-07:00

... NOW!!!

"Hackers recently bombarded the Epilepsy Foundation's Web site with hundreds of pictures and links to pages with rapidly flashing images.

The breach triggered severe migraines and near-seizure reactions in some site visitors who viewed the images. People with photosensitive epilepsy can get seizures when they're exposed to flickering images, a response also caused by some video games and cartoons."

Fun Reading on Security - 2

2008-05-09T12:20:00.001-07:00

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #2, dated May 8, 2008.

So my next iteration of fun reading on security, logging and other topics.

0x000000 blog has a neat post on security, word definition and all. It reminds us that "security is forever" since it is about people, not broken technologies. A quote: "And so we will never able to secure other people, they have to secure them self. And we know that they can't." Same blog also have a fun (but a little bizarre with a little 80s feel) interview with Richard Stallman.
Along the same line, discussion about security industry longevity is here at Gunnar Peterson's blog: specifically, he debates Mike R's semi-humorous prediction that in 2012 there will be 0 "security professionals." Indeed, secure networks + secure OS + secure apps < security.
Also a very fun read comes from DarkReading: "7 dirty secrets of the security industry." Example quotes: "The goal of the security vendor is not to secure, it's to make money" , "Security vendors want businesses to buy what they sell, so they push specific products to block specific threats "; it also discusses another facet of compliance vs security.
Fun - and as usual heated - debates about the "AV is dead" and "anti-anti-virus revolt" happen here. Is blacklisting AV dead now? More dead than before? :-) Or just "limited", but still very useful? BTW, Matasano opines on the subject here as well, calling it not a revolution, but a protest.
The next Carnival of the Security Catalyst Community - April 22, 2008; as always fun. Next carnival Apr 29 is here and the last (so far) one is here.
Really good look at logging for developers is here. "all too often logging gets treated as optional and not necessary. In this column we will cover the essentials of logging []for developers!] from a security perspective"
Latest stolen account prices are posted here by AVERT Labs guys. Account with $16,000 goes for about 700 euros (!) Also, Finjan reminds us that top corporations are all owned.
ISP data retention rears its (ugly?) head again. Good business for LogLogic or privacy nightmare?
A fun read from Tizor Blog: "How did the TJX data breach happen? Part 1: Anatomy" A must read, with diagrams, etc. "After breaching the TJX wireless system, the attacker was able to gain administrative privileges to the RTS servers located at the TJX corporate headquarters in Framingham, MA."
A very good read from Greg Shipley: "Risk Management: Do It Now, Do It Right." A lot of interesting bits about CSOs, security technologies evolution, etc. "The journey continues. We invested hundreds of millions of dollars in intrusion-detection systems without a solid understanding of their relative effectiveness and total cost of ownership. The IDS craze led to reinvestments in intrusion-prevention systems that even today are only partially enabled, and PKI is still a bad word in many IT circles. There's no shortage of disappointments on other product fronts."
"Data Classification Is Dead?" Rich Mogul explains why data classification by the owners is never going to fly... "Enterprise content is just too volatile for static tags to really represent its value. Even those of you in defense/intelligence don’t *really* do granular data classification. " This is a good reminder to shoe that just spout the propaganda "first, need to classify data." Can you hope to do "DLP" without it? Also, read this one from Rich as well: not only you can't classify, you often don't know who owns what.
Hot, hot, hot! "Snake Bytes " on DarkReading. "We are all in the business of stopping just enough crime to keep us in business." Wow! Definitely a must read.
Marcus Ranum on logging in Start Trek (read the whole thread): "What do you expect from a starship that runs on Windows-24k? Microsoft added support for syslog in 2348 - citing customer demand - but still
has no Enterprise-class log architecture." :-)
Piece on PCI and log management where a vendor makes an idiotic faux pas by saying that "less than 1% logs are of interest." In reality, all (OK, most) logs are of interest under the right circumstances. And we almost never know which ones we'd need.
A fun blurb from a lawyer on PCI. Good conclusion too: "Regardless, now is the time for merchants to begin engaging their legal teams to address PCI compliance, and opening the lines of communication between the lawyers and security pros." He also fights the checkbox mentality by saying that "merchants should not view their internal security personnel or QSAs as “rubber stamps” of PCI compliance." I am happy to see this lawyer basically say that if you ignore PCI, your ass is 0wned :-)

On that happy note - see you next time! :-)

Technorati tags: security, reading, trends, market

Links for 2008-05-08 [del.icio.us]

2008-05-09T00:00:00-05:00

Anton Chuvakin Blog - "Security Warrior": Anton Security Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

OMG, This is Sooo "Kid in A Candy Store" :-)

2008-05-08T14:21:00.000-07:00

"First USENIX Workshop on the Analysis of System Logs (WASL '08)
December 7, 2008
San Diego, CA, USA"

CFP here.

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

2008-05-08T13:37:00.001-07:00

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 Security Tip of the Day #15: Fear and Loathing in Event 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:

Time/date
Computer where it happened
User who touched the file
Application he used to access the file
File name + location (directory, share, etc)
Type of access (read, write, create, delete, etc)
Status (i.e. success or failure)

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:

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?

Enable logging (as described above)
Pick events 560 (most useful) and 562, 567 (useful too)
Look for fun filenames that might be touched by the users (have a list of files and users handy)
Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
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 paaaaaainful.

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: security, tips, logging, log management

Another Old Presentation: Log Baselining

2008-05-08T12:07:00.000-07:00

As I did in the past, I am releasing another one of my old presentations. This one is about baselining logs and was given at SANS a few years ago as SANS @ Night. It mostly a subset of my "Log Mining" preso, but with some things added and clarified. Keep in mind, this is circa 2006 or so :-)

I dug out a few more fun ones, that go as far back as 2002. I will release them here in a few days.

Need Proof That I am Popular in UK! :-)

2008-05-08T12:04:00.000-07:00

Just a little bit of stats-boosting and ego-stroking :-)

Nominate me in
IT Security

Why [Some] Smart People Hate Logs?

2008-05-08T11:20:00.001-07:00

WARNING! "Ph." in "Ph.D." at work (play?) here :-) This is one of them darn philosophical posts...

Now, some people hate logging, because logs are too hard to deal with (enable, collect, store and especially understand and interpret). However, there is a whole other group of fairly intelligent people who "hate logs:" the organizers of some well-known technical security conferences. The experience of many of my colleagues (and competitors!) and myself proves that a log-related talk will NOT be accepted to ANY technical security conference nowadays. Now, some were generous enough to explain why. Others were not (screw them and no link :-)).

But let me rant about this one a bit. First, it is always a possibility that they dislike me not logs:-) - this is easily disproved, however, since some of my colleagues had the same exact experience. Do they dislike vendors talking about logs? Nah, this isn't it either - most of my conference presentations had nothing to do with LogLogic, even though they are about logs. Some of my friends (and this blog readers) tried to suggest that an audience of such events "knows everything there is to know about logs." This is not true since - gasp!- nobody knows everything there is to know about logs: they hide way too many mysteries (with useful answers!) to discount them like that. Another one I've heard is that "real hackers don't get logged -> logs are useless", which is also silly: this is true only if you take a very narrow view of logs (e.g. NIDS alerts),; clearly, everybody is logged by the firewalls, servers, apps, etc. The challenge is not a lack of data, but too much data and not enough time and tools.

But we are about to "hit paydirt" with this question...

Tool? Did I just mention tools? This opens the last and final, deeply evil reason for such "log-hate": one of the conference organizers mentioned that, in his opinion, there is nothing new in the field of log analysis since regex-match-based alerting (and regex-based parsing into database tables).

And you know what?

Drum roll....

He was actually somewhat right.

Indexing did come in the world of logging, but, personally, I don't find it to be a huge feat of human ingenuity (even though it is definitely useful). I also think we are not doing enough with index data (and I definitely intend to change that...)

In addition, there was A LOT of academic research on the subject, from the SRI EMERALD in the 80s (and even earlier) to today, but many of the papers I've seen sit on the "hilarious side of useless"...

So, I need a campaign "Making Logs Sexy Again!" (and some impressive research results to boot) - will it work? Let's try and find out!

Reverse Compliance or "Logs as Proof of Incompetence?"

2008-05-06T17:27:00.001-07:00

This post is inspired by the BeastOrBudda musings on compliance here.

Now, I wrote a bunch of things about logs for PCI DSS compliance (including my book chapter) and overall logging for compliance. How about "reverse compliance" against logs?

Whaaaat? WTF is "reverse compliance?"

"Reverse compliance" is a motivation to purposefully avoid technologies that have a chance of telling you that you are NOT in compliance. Sadly, logging is featured very high on the list of such technologies that a) tell you about all the problems with your compliance posture (e.g. direct violations of regulatory requirements, lack of controls, inefficient controls, policies not followed, etc) as well as b) are mandated by various regulations (e.g. PCI DSS) and c) actively used by auditors for finding compliance issues.

When this type of thinking in progress, people start going even further towards:

If I have no logging, people will not know that I was "0wned" for years and thus have to notify the customers (reverse breach disclosure compliance)
If I have not logs, nobody can blame that I knew (or - had a way to know) about the successful attack and data theft?
If breach investigation will lead to a dead end due to not having logs, maybe I won't be fined as severely?
If I don't have logs to show the auditors, they won't blame me for mismanaging security in my environment (or - they will only blame me for not having logs and not for all the other serious issues I have...)
If I have no logging, I cannot be found to be in violation of many PCI DSS requirements since evidence of violation will be in the logs (but, will, obviously be in violation of Requirement 10)

The key question is how widespread "reverse compliance" is? I am sure that many of my enlightened readers would think that no organization is that f*cked up :-) Well...

... some sadly are. Is "worst in class" label appropriate here? Maybe not, since these companies are thinking that they are "being smart about their business" and saving money by avoiding those "useless" (also known as "common sense" ;-)) compliance requirements.

So, will you log if logs will prove your incompetence?

That is, my friend, the whole question here...

On the other hand, I hope that this "approach" is not too common in the age of breach notification laws: logs or no logs, they will have to tell the public and - often! - without logs they will have to announce that ALL is lost. The burden in on them to prove what was NOT stolen IF the server where the data is stored was found to be owned.

For example, a compromised server + critical data stored = every record is assumed 'lost' in the absense of logs.

This is, in fact, one of the stronger motivation for log management today as it shows you clear, obvious savings: notify 200,000 people vs notify 40,000,000 people of the breach at, say, $5 apiece....

Technorati tags: compliance, security

So Cool: Richard on NAC

2008-05-06T11:29:00.000-07:00

This is fun: Richard "IDS is dead" Stiennon says "NAC is dead."

I will now start calling him Richard "Both IDS and NAC are dead" Stiennon. Also, he is hereby proclaimed a Mortician of Security Industry :-)

Sorry, it is all in good fun!

More on that tomorrow in my "Security Reading II" piece, BTW.

Nobody Is That Dumb ... Oh, Wait X

2008-05-05T14:26:00.001-07:00

The fans of "Anton-style humor" will (darn it, MUST!) appreciate the X-th (i.e. super-anniversary) installment in my strictly aperiodic "Nobody Is That Dumb ... Oh, Wait" series, a cheap [but - hopefully! - more humorous] imitation of the infamous "doghouse."

Today's entry is about throwing free money and free work [of somebody else, mind you] down the proverbial crapper.

So, the other day I was at one security conference which had a bit of a vendor expo. Since I work for a log management vendor, I am always on the lookout for new log-producing technologies. Typically, I just ask the vendor to send some log samples so that we can either create an official support package for this new log source or, at least, see how such logs will fare with our log indexer (that enables LogLogic index searches and Index Reports).

Obviously, every vendor I ever approached loved it: after all, they might get something for nothing. If they are small, integrating with LogLogic might help their business. If they are big, they are typically happy that their "partner ecosystem" is growing. All it takes for them is sending a small sample of their logs - and we will do the rest.

While cruising that show I noticed a booth of a relatively well-known (but still pretty small) security appliance vendor. So I chatted with them a bit and in the end asked the engineer to connect me with their core folks so that we [LogLogic] can get a sample of logs and then develop support for it. We don't really have to do it for them, but, then again, it might come handy, who knows.

Imagine my surprise (nah, shock!) when an email came that they "don't really want that." I thought long and hard about the possible benefits of NOT having your logs in a log management system, but only one stood above the rest - and that is STUPIDITY! Thus, this entry :-)

Technorati tags: stupidity, logs, logging

Poll #8 Log Analysis Context

2008-05-05T13:44:00.000-07:00

So, my next poll is up - and it is fun: Which of the types of information below are most useful when trying to make sense of a log entry?

Vote here!

Past polls:

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

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

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

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

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

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

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

Log Haiku #6 (Final)

2008-05-05T13:15:00.001-07:00

How do you eat an elephant?

Piece by piece you do!

But what it objects to it? Logs do.

Sorry, no more logging haiku were created - hopefully the logging book project will come back to life soon...

Monthly Blog Round-Up - April 2008

2008-05-01T22:17:00.001-07:00

I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

In a bizarre twist of fate, the #1 post this month is this little blurb on what will motivate the improvement of security in the future. So, is it lawsuits after all?
Emerging from its well-deserved oblivion is the topic of anti-virus efficiency. Here are the posts: Answer to My Antivirus Mystery Question and a "Fun" Story, More on Anti-virus and Anti-malware, Let's Play a Fun Game Here ... A Scary Game, The Original Anti-Virus Test Paper is Here!, Protected but Owned: My Little Investigation, A Bit More on AV and Closure (Kind of) to the Anti-Virus Efficiency/Effectiveness Saga.
Again this month, my logging polls are super-hot: specifically, a controversial Windows Log Collection Poll (which is a poll #7) sits among the Top5 posts (closely behind is poll #6 about logs that people actually look at).
People, please stop googling for "open source SIEM." :-) Really! You are not going to find it, 'cause it doesn't exist (yes, OSSIM exists, but I still doubt that it will gain massive adoption any time soon). In any case, this tiny blurb from 2 (!) years ago where I explain why an open source SIEM will NOT emerge soon is in Top5 posts (weird indeed!). I have to tell you that the volume of google queries for "open source SIEM" that land on my blog has increased by a factor of 8 (!!!) over the course of last year.
Finally, a Top5 item which did not surprise me this month: my RSA impressions are Top5 as well (this post and the whole RSA2008 coverage)

See you in May!

Possibly related posts / past monthly popular blog round-ups:

Technorati tags: monthly

Log Haiku #5

2008-05-01T22:05:00.001-07:00

To act or not to act, huh?

That is the question.

You, not logs, must answer it!