Interesting Log Management Interview

An interesting interview related to log management is posted here at Cutaway Security. It brings a few well-known, but not less sad :-), points about IT's view of logging. For example,

"Centralized logging is one of the keys to a good security posture.
Percentage-wise, how many companies do you see doing this?

Unfortunately, the customers I have been dealing with are very late
coming to this game. And I am not talking about SIEM either. Just
centralized logging. Many of them have some kind of syslog server with
a few logs getting thrown to it, but very few have any kind of real
centralized logging solution where they can go do forensics and get a
good idea of what was happening in their network as a whole at any given
time."

He also brings up a good point about sensitive info in logs, which I also mentioned here ("logs as PHI under HIPAA"). And, of course, I was overjoyed to see him mention that "log management is crucial to forensic investigations."

Read the whole thing here. More comments on logging, inspired by the above interview are posted here.

A Bit More on AV

So, seeing more coverage of AV [in-?]efficiency today (e.g. here as well as all the old stuff here and summarized here) leads me to finally come out of the closet (OMG, I've been in the closet all this time... :-)).

After another one of my friends (who works in security and is obviously pretty darn smart about online risks), "protected" by a major-brand AV, had to rebuild his system, I decided "enough is enough." So, as of a few weeks ago, Symantec AV is gone from my systems, for good.

Time to stop and reflect on this a bit. I've been running AV for a good numbers of years, but not as many as others. Back in good ole days of Win95/98, I was not running anti-virus, mostly relying on my risk avoidance. Then my work PC came with an anti-virus tool and it kinda stayed on. Over all these years, I had exactly 0 (zero) infections on my own machines (apart from viruses that I brought in myself to experiment, of course :-)). However, saying farewell to the most popular security technology is a touching moment, to be sure.

At this point, I am pretty sure about 97.3% :-) of you are getting more and more curious: what is Anton smoking? How can he venture out in the world without any security software on this systems?

Well, I never said that I didn't replace it with anything. I did! I am happy to tell that I replaced the AV with a HIPS-like tool from Savant Protection, which mostly relies on a fancy version of whitelisting to protect the system (details here). As a disclosure, I need to mention that I am on their Advisory Board, but my decision to protect my own systems with it had little to do with it.

First, I installed it just to play with it, but then I realized that I want to run it "in production" due to its many advantages (no updates, no noticeable CPU impact, no silly scans to run, etc) Admittedly, sometimes you will need to respond to a pop-up (in the mode that I run it in!), but it is not a big deal. Feel free to check it out!

So, this post also works as a response to those of you who were saying "stop bitching about AV, you probably run it yourself: it sucks, but it is a must"...

On LogLogic

A few people asked me how's LogLogic doing - this blog post from my boss pretty much says it all.

And - we are still hiring (even though we recently hired a whole bunch of really good people - as in "REALLY good" :-)). BTW, if you just like the company (and you should!), but not any particular position - please apply anyway!

On Breach Economics

Here is a fun excerpt from an even more fun discussion on securitymetrics list related to "pricing" security breaches, especially TJX. One line summary: we know nothing :-)

Another Presentation: FINAL Full Log Mining Slides

Today I am happy to release what I consider to be my most interesting old presentation - a full slide deck on log mining. It covers a few years of my research into using simple data mining techniques to analyze logs stored in a relational database. It even comes with examples of real intrusions caught by my algorithms as well as tips on reproducing my results in your environment.

Here is the abstract: "The presentation will describe methods for discovering interesting and actionable patterns in log files for security management without specifically knowing what you are looking for. This approach is different from "classic" log analysis and it allows gaining an insight into insider attacks and other advanced intrusions, which are extremely hard to discover with other methods. Specifically, I will demonstrate how data mining can be used as a source of ideas for designing future log analysis techniques, that will help uncover the coming threats. The important part of the presentation will be the demonstration how the above methods worked in a real-life environment."

As you know, I have long been a fan of using (eh, make that "trying to use" :-)) data mining techniques for log analysis, since I see the questions such as "what do I search for?", "what report to run?", "what alerts to define?" (see some discussion here) as inherently too hard. Log mining hold a promise to automate answering these question and thus move log analysis beyond choosing and then running reports, alerts and correlation rules.

Enjoy the slides!

Log Trustworthiness Hierarchy

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

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

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

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

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

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

Technorati tags: logging, log management, trust

"Security profile" of me at Roer.com

Here. It does reveal a few cheesy details about me.

Nobody Is That Dumb ... Oh, Wait VII

Awesome, we have a winner for our aperiodic :-) "Nobody Is That Dumb ... Oh, Wait" "contest."

So, why give this prestigious award to these assclowns? Here is why: "The Ameritrade spokeswoman says the company believes no Social Security numbers have been taken because the only known illicit activity traceable to the breaches is spam, not identity theft."

Oh, that makes perfect sense! Do the words "... that we know of" ring a bell? No? Then your f*cking bell is broken! :-)

Rich Mogul has some fun comments here. Also, check out his poll on how people think it was breached.

There is one caveat, however: if logs from those databases were collected, preserved and now can be analyzed, I'd actually take the above statement seriously and will have to eat up my "Nobody Is That Dumb ... Oh, Wait VII" entry... Something is telling me this aint' happening though :-)

War on "Checkbox Security"

So, I've been meaning to write a longer post on this, but time crunch barged in, so I will just drop a formula here.

First, checkbox compliance is OK: compliance is inherently "checkboxy" - as in 'here is a list - now bring your environment in agreement with it'

Second, in some sad places, compliance = security (despite all the discussions to the contrary)

Third, a result is checkbox security which is an ugly, sad, wasteful, multi-headed critter which shows up in many places at once (e.g. 'see here, it said 'IDS' - Ooook, ours is unpacked, racked and connected - CHECK!' or even 'SOX? We did SOX by doing all this documentation here. So now we are safe, right?' or 'Pay for my PCI audit and I will make you [look] secure')

You know what? I'd take a FUD-driven security (also here) over this bugger any time of the day ...

UPDATE: a few insightful comments on this blog were inspired by my piece ("Compliance gives you a 'C' - now, how do you get to an 'A'?"). Check them out!

Technorati tags: security, compliance, musings

Another Incident, Another "Where WERE the logs?" Story...

Not much to say, just a quote will suffice (full here) : "A friend called me today to ask for some help. Turns out a contractor he let go came back in through a backup service account and wreaked havoc on the network. And to add to the headache, the contractor deleted the event logs. There is a SIEM (security incident and event management) solution installed, but my friend is not sure if he had enough logs getting pushed to it to give him enough evidence. And even if he does have the right logs pushed, he may not be able to use the logs he has since the SIEM product he has in place is very poor in the forensics category (it trashes...errr, normalizes logs to a high degree - no raw logs available). "

Another incident, another "OMG, where ARE my logs!!?" story, but with a new twist "screwed by SIEM" :-)

Related posts:

• And The Logs Weren't There ...

• Are YOU Ignoring Logs?

More on Logging Allowed Connections on the Firewall

Another interesting, old post/thread, related to a subject I was talking about recently: a nice long list of reasons of logging allowed traffic on the firewall.

And, of course, if you do do that (you should!), you'd have more log stuff than you care to admit :-) So, get log management.

A, then C, then I!?

Something compelled me :-) to highlight this blurb from Richard's old blog post; a deep insight that I missed before: "One final note on adversaries:

• First they DoS'd us (violating availability).
• Now they're stealing from us (violating confidentiality).
• When will they start modifying our data in ways that benefit them in financial and other ways (violating integrity)?

We will not be able to stop all of it and we will need our applications and data to help tell us what is happening."

... which also reminds me of semantic attacks.

One Last Time: "Choosing Your Log Management Approach" presentation

So, this coming Friday I will be giving my award-winning :-) presentation "Choosing Your Log Management Approach: Buy vs Build vs Outsource" one last time at SANS NS 2007 in Las Vegas, NV (details here and below).

The preso will then be retired and will find new life as a zomby ... eh... as a LogLogic webcast :-). It will be replaced by an even more exciting (by approximately the factor of 7.3x ;-)) log management presentation with a still-secret name...

So, see you in Vegas! BE THERE!

LogLogic Lunch and Learn Presentation
- "Choosing Your Log Management Approach"
- Speaker: Dr. Anton Chuvakin, GCIA, GCIH, GCFA
- Friday, September 28th, 2007 * 12:30pm - 1:15pm

UPDATE: the webcast version of this will be first aired on Jan 29, 2008. Sign up here!

UPDATE2: slides are posted.

Mind Blast from the Past: Psi-Weapons Again...

Near-future energy weapons? Airborn lasers? Microwave pain beams? Sonic weapons? Directed plasma fields?

Bua-ha-ha-haaaa, mere kindergarten toys! :-) Direct control of the mind beats them all to squeaking pulp (if it works...) This story about a new DHS contract bring back the old specter of Russian psi-weaponry from the forgotten early-90s lore (e.g. see here). Now their research center even has an English website (here), check it out.

Far Future of Security ... Today

Really, no way to say it better than this bit of Marcus Ranum quoted by Richard: "Will the future be more secure? It'll be just as insecure as it possibly can, while still continuing to function. Just like it is today." Amen to that! :-)

He then seals it with this inspiring line: "Marcus clearly shows that there is no secure -- i.e., there is no end game. None of us can retire "when our work is done." We will retire when we can hand off the problem to another generation."

Reminds me of my historical post "Will security ever "get done"?" ...

Absurd Patent on Log Management

Reading this makes it pretty clear why sooooo many want to overhaul the US patent system. It is a patent titled "System and method for analysis and management of logs and events," which is choke-full of trivia and prior art. Here is the excerpt (full here):

"SUMMARY OF THE INVENTION

[0023] According to one aspect of the present invention there is provided a log record analyzing system for monitoring a log record from at least one computerized system. The log record analyzing system comprising:

• a pattern repository adapted to store more than one pattern object record of different grammar types and
• a parsing engine associated with the pattern repository.

The parsing engine comprises:

• a raw log data input for receiving raw log data,
• a matching unit associated with the input for matching between the raw log data input and
• one of the pattern object records, and
• an output for outputting a parsed structured version of the raw log data using a structure extracted from the matched record. "

Wow, this is truly new ... circa 1978 :-)

On Enterprise Class

Fun post on what constitutes an "enterprise-class" log management solution, part I of an upcoming five part series.

Interview On Logs for Compliance

"In a recent IT Business Edge interview, Chuvakin reminded us that having logs somewhere in cold storage isn’t enough when it comes to compliance requirements."

I sure did - here is the full interview titled "Log Management: Having 'Tape Closet' Doesn't Come Close".

Fun Privacy Discussion

I took part in this privacy-related panel podcast (audio here, description here) titled "Do we have privacy anymore?."

It was actually very fun since I tried to play the devil's advocate and steer the discussion towards "Do we WANT privacy anymore?" And you know what? While doing it, it dawned on me that there are "two privacies" or a "privacy chasm" of sorts.

On one hand, we have the "Facebook pix don't matter crowd" (sample)
On the other, we have medical record sharing among "partners"
etc, etc.

I think loss of privacy is not a big deal. Really! If you don't like your privacy, just toss it :-) like many did. However, the loss of CHOICE of what gets shared/publicized IS a big deal.

To summarize, I bet all people, who think that pics of them naked on Facebook are perfectly OK, will NOT want to be denied employment since their doctor shared their health issues with their insurance which then shared the info with their would-be boss ...

On TDA Data Loss

Now, if this isn't screwed up, I dunno what is: "E-mails obtained by Network World show that Ameritrade received explicit and repeated warnings from an IT security expert starting Jan. 9, 2006 that its customer data had apparently been compromised, placing the start of the breach much earlier than previously reported and likely pushing it into 2005."

Good bye, TJX breach. We hardly knew you - you are now officially #2 (painful, ain't it? :-)) on the infamy scale. Welcome, TDA! Congrats!

Solaris BSM Logging for PCI

Fun (damn this word! :-) somebody hand me the heavy-duty thesaurus ...) piece on Solaris audit settings for PCI DSS version 1.1 is here.

These settings will create quite a flow of log data! How do you analyze it? Well, this is THE least covered angle of Solaris BSM and other detailed audit logging mechanisms and - surprise! :-) - is also a subject of my upcoming paper (and the next logging/security tip)! Stand by ...

Of course, feel free to also check out my PCI book chapter on logging.

On Marketing Desperation

OMG, ROFL! :-) - Ahhh. Marketing Desperation. | securosis.com: "You can always smell desperation. It has a certain… quality that gently waifs into the nasal cavity, tickling those very nerves that are too oft neglected in our sanitary society. You know, the same ones that pick up the odor of sewer crap. What’s odd is that this smell is extruded not only by the truly desperate, but by those whose self esteem is so battered that they crave every bit of validation they can beg off the nearest passerby.

Today, thanks to Alan Shimel, we see probably the most amusing act of desperation I’ve ever witnessed. One of his competitors bought the Google AdWords for Alan’s name."

UPDATE: now, I am offended here! Why aren't people doing it on my name? :-)

Dedicated to iPhone Users Everywhere ...

A humorous quote from Laura Ries, related to iPhone price drop: "If the iPhone were truly living up to anything near its hype, then Jobs is the dumbest person alive. Lesson number one in business school: You don’t drop the price on winners."

Is it time to say that she was right and everybody else wrong? Or not yet?

Simply Cannot Resist...

Eddie is my friend and all, but I simply cannot resist, but ROFL at that: "... says Eddie Schwartz, CSO and vice president of marketing for NetWitness."

It is official folks! Security = marketing :-)

How Low Have I Fallen?

... I joined Facebook. Sad, indeed :-)

I Wish, I Wish or "What's exciting about LogLogic?"

I wish (not really :-)) that this were true: "'The problem that LogLogic has is that it has no competitor so its market is ill-defined. There are point solutions that are appropriate departmental or divisional solutions but there is nothing really like LogLogic on an enterprise scale."

It does sound nice though (esp. this "Regardless of how you label it, LogLogic is clearly its own market leader.")

Fun read about us.

Writing Your Own? He-he-he...

Great rant from Tina on why so many people write their own log analysis scripts ... and then suffer, suffer, suffer! :-)

Logging Tips, Kinda

Hate such logging tips: "Log relevant information in a format that is useable." When I see this, my first reaction is to say "f*ck you too!" :-)

To give it credit, the piece does have some solid logging advice, e.g. "Exclusive filtering [A.C. - aka 'artificial ignorance'] is a god-send to troubleshooting because it’s easier to filter out noise and whittle the logs down to the relevant entries rather than guess at what you want to see." or "Log clients centrally"

Read more.

Fun Anti-sec Rant

Moderately enlightening, mildly anti-sec rant called "Why Security Is Useless" is here.

Quick Tip: Password in Logs

I think I mentioned it before, but it helps to repeat: sometimes, your users' passwords will show up in logs, alongside the usernames.

If you are under HIPAA and username/password combos are considered PHI, then logs also become PHI ... think about it.

On Using SIEMs with Log Management

A fun piece which kinda highlights why some people deploy both SIEM (for correlation) and log management (for 100% log collection and analysis).

Interesting quotes: "Can I, algorithmically ahead of time, guarantee that the system will “think” about every event I want it to? With almost every single correlation methodology Ive seen - especially including [SIEM's] default methodology - the answer is a resounding “NO”." and also "This methodology failure means that you cannot go back and do formal analysis on an incident that has passed through [SIEM] without the original raw events and significant manual labor except by sheer luck"

Thus, you have a SIEM for selective real-time security analytics via correlation and risk scoring AND a log management to have a full archive of all logs for incident response and in-depth analysis.

UPDATE: Jack posted a detailed clarification here (and in comments below); still, I'd say that if we live in the world of SELECT statements and limit ourselves to database / structured data analysis, we are by definition missing things that are:

• filtered away on the agent/collector/connector
• not parsed into the database by vendor's choice
• not parsed by mistake / agent bug
• not retailed for long enough on the database ...
  

Massive Log-like Data Analysis Research from Google

Quoting from the abstract (here, full PDF here): " Very large data sets often have a flat but regular structure and span multiple disks and machines. Examples include telephone call records, network logs, and web document repositories. These large data sets are not amenable to study using traditional database techniques, if only because they can be too large to fit in a single relational database. On the other hand, many of the analyses done on them can be expressed using simple, easily distributed computations: filtering, aggregation, extraction of statistics, and so on. We present a system for automating such analyses."

HIPAA, Insiders and Logging (Of Course!)

Fun lessons from a recent HIPAA-related insider attack, PHI deletion and other fun stuff as well as subsequent prosecution reported on this blog.

A log-related quote (which illustrates how logs are indispensable vs insider attacks): "3. Log the access of personnel with authorized access to sensitive data and systems. [A.C. - a true no-brainer, right? Go to a typical organization and see lots of people who don't log - does it mean they all lack brains? :-)] [...] No one individual should be controlling the entire network and data resources. If this is the situation, there should be another position, outside the individual's area, logging and monitoring the individual's activities."

Fun Preso on Proxy Logs

I did a few insightful webcasts for LogLogic lately, here is one of them (webcast with voice, slides only), on analyzing and managing web proxy logs. It goes well with my logging tip #12, also on proxy logs.

A Few Notes on the MediaDefender Job

Run for hills, run for the hills! :-) A blogging frenzy commences...

First, as everybody rejoices about the fate of MediaDefender, "the new SCO of hatred," one need to compare and contrast this story with the "old" WJS saga (e.g. see it all here).

Specifically, see this bit from WSJ-gate: "The Trick: You, too, can stay up to date on work email, using any number of consumer-oriented hand-held devices. Just set up your work email so that all your emails get forwarded to your personal email account."

and this MediaDefender-gate bit: "The emails contains information about the various tactics and technical solutions for tracking p2p users, and disrupt p2p services,” and “A special thanks to Jay Maris, for circumventing there entire email-security by forwarding all your emails to your gmail account”"

So, can the douchebags sue the WSJ and increase the level of hilarity for everyone?

Mike Is Expanding ....

... from enterprise (Pragmatic CSO) to consumers (Mike's Security Guide)

Not sure about you, but when I saw this first, I felt the need to check my calendar: oh my, April 1st sure did crawl on me :-)

It seems real enough though! Still, some bits heavily smell of spring :-), like this one: "Since a hallmark of Security Mike's approach is that consumers don't need to pay for security software anymore, you'll want to get rid of those heavy "suites" that slow down your machine and lighten your wallet."

What a "new direction", if I ever saw one! BTW, here is quick and fun trivia question that checks your deep knowledge of obscure references: after what kind of training one loses an ability to say the words new direction without smiling?

New Paper: "Intrusion detection in the age of compliance"

Here is another paper in the "... in the age of compliance series" called "Intrusion detection in the age of compliance." The previous ones are:

• "Log management in the age of compliance"

• "Incident management in the age of compliance"

A Sensible Piece on Logging in PCI DSS

PCI DSS Compliance Demystified blog presents a sensible piece on Req 10 ("Track and monitor all access to network resources and cardholder data") here.

A few useful quotes from it: "This requirement is mean to show: Who did What and When, in order to (1) alert on suspicious activity and (2) facilitate a forensic investigation."

Indeed, log enough to know when things go bad and to investigate after you learned that they went bad.

They also highlight the need for database logging in PCI.

In any case, go read it.

Once More on Failure of Academic Research in Security

Many people, myself included, have bemoaned the complete failure of academic research in information security. The main reason for this is a complete disconnect of academic security research from real-world threats and vulnerabilities (e.g. I still see people publishing papers inventing signature-based network IDS systems, reinventing MAC/RBAC, neural nets to catch hackers, etc - and if I hear about the Lincoln labs 1998 intrusion detection data set again, I will screeeeeeeeeeeam! :-))

This fun post brings a few more examples. It gets to "Security against real threats is the point where scientific integrity, method and rigour unravels" and continues to "The academics have presented stuff that is sometimes interesting but rarely valuable. They've pretty much ignored all the work that was done before hand, and they've consequently missed the big picture" and even "The academic world of security is simply too far away from their subject. " (which all ring sadly true)

What is much more exciting is that there is finally an explanation for this "induced stupidity" phenomenon, that puzzled so many in the security field: "Academic work is only serious if it quotes other academic work. The papers above are reputable because they quote, only and fulsomely, other reputable work. And the work is only rewarded to the extent that it is quoted ... again by academic work. The academics are caught in a trap: work outside academia and be rejected or perhaps worse, ignored. Or, work with academic references, and work with an irrelevant rewarding base."

You know what? I think the above does explain it!

CA Next Generation Breach Law

As reported, California is close to passing is next-generation breach law, "Consumer Data Protection Act", that "would require retailers to reimburse banks and credit unions for the costs of data breaches."

Wow! This does sound like the next step in the onslaught of compliance mandates. And, retailers will finally stop bitching and start working on those PCI projects :-)

Cook Your Own Log Standard in 30 Minutes or Less

Remember the classic about underpants gnomes business plan, specifically:

1. "Collect Underpants
2. ???
3. Profit!"

Here is similar guide, inspired by a recent vendor monkey activity:

1. Register a domain, which includes "open" and "log" and something else (openlogunderpants.org - it MUST be a .org! - will do just peachy).
2. Put some content up that explains that you will concur the world and also solve the hard problem of log standardization in the process; do NOT - I repeat, NOT! - forget to utter the dreaded "C-word" of immense power - compliance.
   
3. Create a PDF document describing one of the existing log formats, such as as syslog or W3C (but do change a few minor things around, just for fun!). The key here is low embarrassment value. If you are smart, you'd also say "taxonomy" at least once.
   
4. Code a convenient "show me yours and I will show you mine" page to collect the info of those who want to download the above PDF (you can't be too open, you know!)
5. Issue a press release that claims that you have achieved god-like status and everybody in the whole worldzoo supports you and is just as excited.
   
6. ???
7. Profit?!

OK now. MITRE CEE log standard effort might be slow (make that reeeeeeally slow...), but it is here and there is active work being done on this real standard. Why embarrass yourself with a fake standard at this point is totally beyond me ...

UPDATE: one of my readers suggested that I need a picture of underpants to go with it, but - you know what? - it would be ... below me :-)

UPDATE2: if you care to see more factual analysis of this "standard," go here where a new rift of an asshole is being ripped right through its center :-)

UPDATE3: another great analysis of this so-called "standard" is here. I wish I can also quote what some smart people on the CEE mailing list said about it :-)

Pre-post on Logging and Privacy

As I am working on a long and fun blog post related to logging and privacy, here is one fun bit: semi-silly predictions of privacy (lack thereof) in the year 2020.

And, of course, a fun logging bit: "All e-mail and logs of network and search activity will be stored permanently. " (I am assuming one needs also to add: all activity on computers and networks is logged, as I said here)

On "IT Audit Checklist: Logging, Monitoring, and Reporting"

ITCi has released this "audit checklist" related to logging. It is a little light on the details, but is worth reading - or giving to your boss to read! - anyway.

"This checklist supports an internal audit of the organization's logging, monitoring, and reporting policies and procedures as a function of compliance, risk management, and governance. Offering concrete recommendations, this checklist aims to help management ensure the overall confidentiality, integrity and availability of IT systems and infrastructure.

Download Now"

Guide to Hating Competitors

So, inspired by Andrew Hay post (here), I figured I'd expand a bit and create "A Brief Guide to Hating Competitors," a marvelous piece of vendor propaganda :-)

Indeed, many of my fellow vendors are fun and smart people, some are also friendly :-). Sharing technology and sometimes even market insight with them - while having your competitive market positions and IP concerns in mind - is perfectly fine, in my estimation.

However, there are certain vendor behaviors that, in my world, can trigger a prolonged hatred. These are (ALL were observed in real world - some not by myself...)

1. Super-unethical selling: fake references (I saw a vendor give a phone number of their own sales engineer as "here is a number for our reference government customer"...), direct and known lies, etc
   
2. Hacking the competitor's website and other online resources (e.g. support site) or accessing them using stolen credentials
3. Stealing evaluation gear/software from a side by side eval project at a prospect site
   
4. Other examples of direct IP theft (once I saw this done using a VC firm as a cover)
5. A few other things that SCIP folks would frown at.
   

Any additions? Thoughts?

UPDATE: fun follow-up post from Mike (and a bit more here) with more nefarious activities by vendors ... Yuck!

Inspired by Tor - Think!

So, inspired by the recent Tor story (this and many others), here is something to think about:

1. You buy a PC and connect to Internet (pay for your own connection)
   
2. Download and install Tor
3. Monitor it (full packet cap) in violation of its license, but in compliance with your policy
   
4. See what looks like a secret email from somebody
   
5. Grab the email and send it to a journalist
6. Ooops! :-)
   

So, the question is: is this legal? can you be sued regardless? would you do it?

P.S. similar discussion kinda occurred on the Honeynet Project internal list about a year ago and the results were ... well, inconclusive at best.

On Viagra

Thru this blog post, I learned that "spammers have been using [compromised] systems within Pfizer's network to send out Viagra spam." The source seems to be this post here.

Both funny and stupid!

Hole Cow! Auto-phisher Training Video

Wow and double wow :-), now the true bottom of the barrel of the attacker "community" can achieve instant phishing success using the AutoPhisher tool, which comes complete with the training video.

Mammoth Logging Tutorial Coming....

Just wanted to let you know that my mammoth (=7 hour!) logging tutorial is coming soon ... I will be unleashing it upon the world the first time at MISTI IT Security World 2007 on September 20th. Prepare to be awed!!! :-)

Here is [only some of] what it will cover:

"Log Management from A to Z

Thursday, September 20, 9:00AM - 5:00PM

This workshop will cover all aspects of system, network and security logs - from making sure that logs exist, to advanced analysis techniques, to log forensics and regulatory issues related to logging. It will start from the basics of logs, cover various log types, simple log review, describe a phased approach to implementing a company-wide log analysis and then go into specific tasks that users need to be doing on a daily, weekly, monthly basis, as well as in the case of a security incident. It will also touch upon various uses of logs for forensics, compliance and operational monitoring.

This workshop will cover:

• What the logs are and where they come from: operating systems, network gear, security devices, databases, applications, etc.
• Configuring systems for logging: a brief run-through of common systems and applications
• What's in the logs: what you would see if you read all the logs (even though you won't!)
• Log centralization for analysis
• Phased log centralization strategy
• Log storage: just what is log retention?
• Everything about log analysis: from manual review to data mining and advanced algorithms
• Real-time vs. historical analysis: better late than later?
• Log monitoring: strategy and practice
• Logs for incident response, forensics and the court
• Mistakes of log management: are you committing them now?
• Upcoming log standards and log taxonomy
• Future of log management"
  

What Happens If One Marries ...

... a screwed-up security to a screwed-up privacy?

Answer: NASA. The idea is disarmingly simple: require very detailed background checks for all employees, collect mammoth amounts of data and then lose it (the last part hasn't happened yet - but I am pretty sure it is in the works :-))

But people figured that will fight it! Can they win?

Nobody Is That Dumb ... Oh, Wait VI

Now, making jokes about Gartner (the latest I've heard is related to a "G-spot" and is thus unprintable :-)) is one thing and it is fair game, but stealing from Gartner is definitely "not kosher."

It is also royally dumb to steal Gartner's content and put it on a personal blog as "your insight" as this assclown here did. This so-called blog post with "insights about SIEM" is copied verbatim from Gartner's 2007 Magic Quadrant on SIEM with no attribution anywhere within a five mile radius. Let's see:

Big G says, e.g. in their 'Use Case #4': "Full-featured SIEM products designed to deliver a broad set of capabilities, including security operations center console functions for large, complex
environments"

Assclown says in his item #4: "Full-featured SIEM products designed to deliver a broad set of capabilities, including security operations center console functions for large, complex environments."

Surprise - all other items match as well! :-)

Gartner folks, prepare your attack dogs! :-)

So, Is DMCA Pure Evil or What?

So, bad law or bad people [abusing it]?

"The Science Fiction and Fantasy Writers of America has used the Digital Millennium Copyright Act to fraudulently remove numerous non-infringing works from Scribd"

The next line is kinda fun: "Ironically, by sending a DMCA notice to Scribd, SFWA has perjured itself by swearing that every work on that list infringed a copyright that it represented."

Yuck!

On Obscure References

Tom Liston reveals himself as a fellow Wilson fan in his blog post "Immanentize the Eschaton." The post is yet another kick in the general direction of signature-based anti-malware. However, I actually happen to think that what he observed was behavior-based detection working as it should ...

"PCI Compliance" Book Slashdotted....

"PCI Compliance" book slashdotted... A lot of really stupid comments on the thread that follows the review; many folks somehow thought this is a book about the hardware PCI cards ;-) Ooops!

On Assurance vs Indication

Yes, this will tell the whole world how behind am I am blogging, but so be it :-) So, I wanted to respond to Rob's comments related to e-discovery here. So, Rob says: "In a nutshell, it [A.C. - e-discovery] is the process of collecting, searching, preserving and analysing digital information. [...] And there are some real security issues here: 1) If I have collected information from a system, how do I know that information hasn't already changed en route to collection? " [2-5 skipped, see the original post]

He then concludes with "So who's interested in this? Well, apparently not the real security guys" which is obviously absurd.

In reality, e-discovery is moderately hot and doing it better and more secure is of interest to vendors (more) and customers (less). However, there are perfectly good solution to the "issues" Rob brings, which kinda makes them not issues, really :-) Specifically:

1. "If I have collected information from a system, how do I know that information hasn't already changed en route to collection?" Anton: encrypt it in transit; SSL, SSH work.
   
2. "How do I know it hasn't been seen and manipulated, or copied?" Anton: encrypt + hash it in storage; SSL, SSL work too.
3. "Between collection and searching, how do I know the index hasn't changed, and therefore the information I am now looking at is redundant?" Anton: log all access to system, check the access logs before searching. if you have doubts, reindex. Index is dynamic so you cannot checksum it.
4. "How can I preserve information without it becoming prohibitively expensive?" Anton: burn a DVD! Or use one of those funky EMC or NetApp WORM storage boxes.
5. "When I want to analyse this information, how do I know I'm analysing the right things?" Anton: this one is up to you :-)
   

At the same time, e-discovery is a little like forensics, you absolutely don't need it until the moment you can't live without it. Maybe this pushes the interest to dedicated e-discovery technologies down a bit?

NEW Six Mistakes of Log Management Paper

So, I wrote this sexy paper back in 2004 called "Five mistakes of log analysis" and you know what? - It ain't 2004 anymore! :-) I was sitting on an updated version for a while, but here it is, finally. Enjoy "Six Mistakes of Log Management"! Thanks to InfosecWriters.com folks for publishing it.

IPv6 Fun

Check out this funky thread on IPv6 at firewall-wizards here! What blew my mind was this line: "You know, like what a few of us suggested back in 1992 - namely doubling the address size, left-filling with zeroes, and bumping the version number." BTW, guess who said this (answer: him)

Wow, so is IPv6 a new OSI (this analogy is also made here)? Holy Chao, I was somehow a lot more optimistic about IPv6's future ...

Another interesting thought mentioned was that IPv6 is so complex so that any and all possible security benefits will be totally razed by its enormous complexity. E.g. (another quote): "The recent rumblings about problems in V6 indicate that finding flaws in V6 will be a lot like hunting Passenger Pigeons was in the 1700's: point your shotgun at the sky and pull the trigger and several will fall at your feet. " as well as this (from here): "IPV6 has got a lot of complexity and was designed by a committee."

On Faking It

This fun post from AndyIT blog jumps from "staying fresh" to logs and reaches this curious observation: "How many times have you or someone you know spent a day or two prior to an audit "falsifying" log reports. Going through and checking off that they were checked when they haven't been looked at in days, weeks or months."

And my thought of this is: is this the result of people dumbly substituting "compliance" for "security"? Or something else? After all, reviewing logs is required not because "auditors are evil", but because it is genuinely useful, so why fake it (I am guessing due to radical time crunch or due to mammoth scale and boring nature of this task - when lacking the right tools)?