YOU Don't Sell Security Like, Do You?

Funny indeed!

On "TJX Was Not PCI Compliant. Who Pays?"

Darn good question indeed: TJX Was Not PCI Compliant. Who Pays?

Let's watch this one ...

Re-tagged?

So, can somebody "more web-2.0 than me" explain what I am supposed to do if somebody double or triple tags me? I will soon run out of secrets to tell if I am to tell 5 on every tagging occurrence? :-)

NBS Log Analysis Tricks Live On!

A long, long, long time ago (eh, like, in 1997 :-)) Marcus Ranum said in his post "artificial ignorance: how-to guide": "... you build a file of common strings that aren't interesting,  and, as new uninteresting things happen, you add them  to the file." And then you watch for other log records, which are then presumably interesting.  This introduced the concept of "negative" filtering i.e. looking NOT for what you know to be "good."

This technique is indeed extremely effective for finding "interesting" (i.e. unusual + actionable; see more, for example, here [PDF]) events in logs.  I even wrote a few prototype tools myself - including filters such as "new log record type for this port", "new for this network segment", "new for this sensor", "new for this IP range", etc or even two-dimensional ones such as "new for this port and destination IP address" which worked really well. All approaches had adjustable timeout after which the tool would consider an event to be new (e.g. "new for this week", "new for this month", etc). However, few vendors chose to incorporate such analysis approach in their products (bizarre, isn't it?).

And now, 10 years later (!) somebody finally did. In his post on 'Finding Events that have "Never Been Seen" Before' Ron Gula (with Marcus Ranum standing over his shoulder, no doubt :-) ) talks about implementing this in his product. What took you so long? :-)

They say "Regardless if your event logs are from UNIX systems, router access control violations, wireless access DHCP logs, intrusion detection systems or so on, after a certain period of time, the same events tend to repeat themselves. This is because most of our networks run controlled and automated processes. With this in mind, finding out when something "new" occurs could indicate a security or administration problem. " Right on! There is more fun stuff in the follow-up post 'More on "Never Before Seen" Log Events'.

Technorati tags: log management, logs, chuvakin, security, log analysis

Book Review: ”Understanding Voice over IP Security"

Book Review: ”Understanding Voice over IP Security" by Dave Piscitello and Alan Johnston

Now, VOIP security has been talked about for a few years; it started even before organizations started to deploy VOIP in greater numbers. Many folks like to say that “VOIP security is a disaster,” but usually they don’t explain how or why.

Dave Piscitello does. In his excellent book “”Understanding Voice over IP Security” he provides excellent coverage of both VOIP technology basics as well as internet security fundamentals (which are admittedly more useful to the security beginners) Then he fuses the above information into a comprehensive coverage of VOIP security issues, from protocols to call fraud.

VOIP and NAT? Security analysis of SIP protocol? VOIP and honeypots? PSTN gateway security? Public VOIP vs private VOIP? Is VOIP spam inevitable? Yes, all those and much much more are covered in the book.

On the negative side, I had to skip through some of the security basics (yes, even a castle metaphor is there …), but I am conscious of the fact that such content is indeed useful to people with networking background. At the same time, some of the esoterica of phone networks was completely new to me and thus exciting to read.

I enjoyed the book; I liked that it is written to be useful to both security folks – who need to learn about VOIP - and network folks – who often need to acquire better security education.

Authentication: I Just Love This ...

Quoting from here:

"There are three types of authentication:

1. Something you've lost,
2. Something you've forgotten, and
3. Something you used to be."

Security Cartoons

Run, not walk, while having your RSS reader with you, to this site. Then prepare to ROFLMAO.

"Risk House" Model

Just an interesting, information-dense picture of enterprise risk.

One Fun Prediction: Virtualization

A bold prediction indeed: "Yep, in 2007 virtualization and app-security will be the NAC of 2006 so get ready."

Interesting ...

ROI on Not Getting Your Ass Whooped

So, what is the ROI on not jumping off a building? Do you, like, compute it before performing a "not jumping off a building act." Obviously, that is stupid.

Fine, let's try this one next - what is the ROI of not going to jail (and sharing a cell with whatever Bubba)? Well, most if not all people know that they must not go to jail, without doing an ROI computation, not even an ad-hoc one :-)

Then, why oh why, you are doing an ROI on compliance? If you have a well-defined regulation with a clear track record of pursuing its offenders, you don't just comply because whatever semi-intelligent "ROI computation" tells you to. You comply because you have to! You don't use a formula, you do it because you have no choice.

You can argue with the law and try to influence whatever lawmakers to make a new or a better one, but you follow it while it stands ...

Logs Are Everywhere!

Given that I am closely involved in a log management business, I sometimes have those moments that I see logs everywhere. But guess what? Logs are everywhere! From a server under your desk to satellites to ship systems to personal electronics to telecom equipment to building control systems - logs are indeed omnipresent.  

And, at present, such logs are never looked at. How often do you - or, even worse, a typical computer user -  look at your Windows (Linux?) workstation logs?  I am guessing: when something goes wrong. It is pretty much the same for most of the above logs. And that is how it always was - from the olde times of "The Cuckoo Egg" (and probably even from  the times of the ENIAC) to today.

But - and here is the point! - it is changing now. My natural flow of log management shows us that people start looking at common firewalls and servers before they look at operational logs from, say, an elevator in their building, such log sources are out there. However, the time when people will start looking at most of the above logs - and not only after a problem rears its ugly head - is coming ...

Yes, I am being somewhat philosophical here at 21,456 ft, flying back from  DoD Cybercrime 2007...

Technorati tags: log management, logs, chuvakin

On Fruit, Low Hanging and Those Hanging Elsewhere

Here is an insightful post from Jeremiah Grossman blog. As he says, often people recommended fixing the simple glaring vulnerabilities - low-hanging fruit - after a vulnerability assessment.

And then he makes this bold claim: 'eliminating the low-hanging fruit doesn't really do much for website security.' He then explains that this is because the role of 0days is much higher in web hacking compared to platform hacking and removing simple problems just means that complicated ones are sure to be exploited ...

It does seem to make sense! So, in this case "better than nothing" strategy gives you just about the same stuff "nothing" strategy aka "close your eyes and go."

Those doing risk assessments should definitely pay attention to this!

On Failures ...

It is always sad when a good security company fails, but sometimes it seems somewhat justified: I was deeply underwhelmed by their positioning whenever I saw them at conferences in the past few years.

Also, as pointed out in the paper, "no one vendor is solving it [insider problem]in an end-to-end fashion" has something to do with it ... And no one vendor will.

And, here is my del.icio.us feed for security failures; feel free to check it out once in a while.

On Math

Kinda one of'em "no comment" thingies...

Log Management Cloud

Here is a log management tag cloud, build by clusty. Notice something interesting?

Logs and Compliance: Married for Life

Despite this cheesy title, I am talking about something serious here. Many security solutions are being sold as "compliance solutions" nowadays (and there is nothing wrong with that). However, sometimes I can't help but chuckle (or, less often, roll on the floor laughing :-)) when I see a vendor make an especially tenuous connection between their offering and whatever compliance mandate or regulation (e.g. "our firewall is really a ... khmmm ... yes!  a compliance solution, because it ... eeeeh ... helps you, you know, be compliant and stuff" :-))

However, there is one technology that has "compliance" written all over it:  log management. Why am I saying this? Is it because LogLogic pays me?  No, this post is actually inspired by this paper here. Two quotes illustrate  my point:

1.  "By reviewing the logs, data center managers can record specific kinds of activities to show auditors that controls are in place." Yes, one can try to look at the configurations to see the controls, but only logs show how those controls manifest in real life.

2. "The other function of log data in compliance is to report on exceptions -- explicit log events that represent issues requiring investigation [...]" Indeed, logs provide an objective (subject to known caveats ...) trail of activity and should be used pretty much in all investigations.

The paper further mentions the role of logs in SAS 70 audits; while some people make jokes about it as a means to "prove security", it seems to be the choice of some companies that seem to streamline their audit processes.

Technorati tags: security, compliance, log management

More on Why Passwords Will Stay

He asks: "Fine, but what happens when we have dozens of key fobs to manage?" He also proposes a solution here. But guess what? It ain't. And biometric creds cannot be changed, which is pretty bad. Who do we have left standing? Passwords ...

Still, this "password series" is meant to incite, but nobody bit so far. What's the story?

Got a "Second Life" Office?

Some security companies do.

Now and Zen :-)

So, can someone pray tell me, how is this SONAR thing different from "Use Heuristics" in their standard anti-virus? The claims look pretty much the same, if you look carefully ...

The only explanation that seems reasonable is that the "old way" was kinda ... fake ;-)

Security vs Networking

" Simply put, the networking group should maintain and configure network devices, and the security group should maintain and configure security devices."

Ah, I also sometimes lament that this world should be a simpler place :-) So, pray tell me, what is a firewall: a network or a security device?

Got this one? How about a switch firewall blade in a switch?

Oh, got the above OK? Here is a tougher one: a firewall code in a router?

Got my point!?

On "Eight daily steps to a more secure network"

So, yeah, in light of this, why am I posting this. :-) Because folks who currently don't do anything, will certainly benefit from reading this list of daily security tasks.

And, of course, logs are there en masse :-)

"Look at your antivirus logs: Did a virus hit your e-mail system last night? Are the antivirus signatures up to date?" [I'd add: check AV logs for failed updates and scans as well as other AV failures and even AV software uninstallations and terminations]

"Read the security logs on your domain servers: Did the system lock out any accounts last night? Pay special attention to any accounts with administrator access. Verify that lockouts were human error—and not part of a breach attempt." [I'd add - look for configuration changes, service restarts, various failures as well as resource issues - all might be indicative of attacks, failed or successful.]

"Check more logs: Take an in-depth look at IDS and firewall logs. Who on the Internet is knocking on your door? What are they looking for? Who on the inside of your network is doing something they shouldn't be?. If you find unauthorized and/or illegal activity, report it immediately, and take action to stop it." [I'd add look for NEW events from your IDSs which were never seen before]

Of course, if you happen to own a log management system, doing the above tasks would be a breeze :-)

Practicing "Best Practices" vs Doing Good Work?

So, is this true? - "One of the major trends I have seen with some dismay is the notion that security professionals have become increasingly concerned with being able to demonstrate that they went through the steps of securing their systems from attack and less concerned with actually protecting the systems from attack."

I kinda see the same trend, but I am not sure it is entirely a bad thing. Folks who are switching to "going thru the steps" are switching from "NOT going thru the steps" and not from "actually protecting the systems." Checklist approach is good for those who didn't have any approach at all :-)

Further, he says that "Best Practices alone are the equivalent of a night watchman." Hmmm, I always thought that "best practices" is what the BEST organizations follow, not what the [dumb] majority follows. Thus, I am not sure I agree with the above "anti-best practices" stance. At the same time, I totally agree that "real security is a creative act", at least nowadays.

So, what's the overall point? Look at available "best practices", choose the right ones, follow them, but still be creative. No checklist will ever guarantee you that you will not suffer a loss ...

On "Repairing Corrupted Windows Event Log Files"

Just a useful article on "Repairing Corrupted Windows Event Log Files."

On SIEM, etc

I meant to highlight it before, but I am only doing it now - great insight (mmm, "incite"), Mike.

"The security management business (really I mean SIEM here) is made up of the lucky (e-Security and Network Intelligence - who got acquired this year), the survivor (ArcSight – who is moving into other businesses like log management and network configuration fast), and the walking dead (everyone else). And the shake-out will be severe in 2007. [yeah!]"

On Vendor vs Hacker: A Useful Reminder on How World Works

This post serves as a useful reminder for folks who are stuck writing documents for compliance instead of dealing with security issues :-) (as well as others too)

"Consider this scenario: Hacker finds a vulnerability with a product from a vendor.

Vendor has access to all the source codes. Vendor has the knowledge about the functional design, architecture, bugs, future roadmap Et. Al. Moreover, a vendor has the money and other valuable resources.

Hacker does not have access to the source code in most cases. Hacker does not have all the details about the functional design, architecture, bugs, future roadmap Et. Al. Pragmatically speaking, a hacker is trying to break into a blackbox with limited resources."

The conclusion made by the author of the above is kinda questionable though:

"If a hacker finds a vulnerability in a product. I am more inclined to point finger at the vendor's sloppiness than heaping encomiums about the hacker's intelligence."

I would say "not always." Vendor is in the business of making money and leaving vulnerabilities (by means of not spending a fortune on security software testing) in the product might make some business sense. Thus, it is not always sloppiness. And, some vendor do make an extra effort, and thus those folks who discover vulns in their stuff are pretty darn intelligent...

Thought-Controlled Machinery Is Here

Just quoting another blog on this - nothing much to add, really :-)

"The University of Washington Neural Systems Lab have created a humanoid robot you can control with your thoughts.

I'll say that again - a humanoid robot you can control with your thoughts

The future is here. Thank you and goodnight.

The control system is a type of EEG-based non-invasive brain-computer interface and the page has video of the robot in action, as well as a video that describes the neuroscience of how the interface works."

Cool Future Predictions

"The World Future Society (a premier competitive intelligence resource) has just published a set of forecasts for the next 25 years from its members and from its journal The Futurist." Top 10 and some fun comments are also available here

Here is an example:

"Forecast #2: The era of the Cyborg is at hand. Researchers in Israel have fashioned a "bio-computer" using the DNA of living cells instead of silicon chips. This development may soon allow a computer to connect directly with a human brain."

Natural Flow of Log Management

I just came back from visiting some of our customers and then did a bit of thinking of what logs people tend to deal with first (and why). It would sound obvious for some, but possibly insightful to others. While we often say that you need to look at all the logs, often real-life limitations interfere

So, even a few years ago, any firewall or network admin worth his salt would look  at least at a simple summary of connections that his baby PIX or Checkpoint is logging. Indeed, firewall log analysis represented a lot of early business for log management vendors. Many firewalls log in standard syslog format and such logs are easy to collect and review.

Reviewing network IDS logs (for those companies that chose to deploy this technology), while unduly exciting in case of an incident, is often a very frustrating task since NIDSs would sometimes, you know, "lie" to you by recording "false positives." Still, NIDS log analysis, at least the post-mortem kind, often comes second after firewalls since the value of such info for security is undeniable and logs can, in most cases, be easily centralized for analysis.

Even though system administrators always knew to look at logs in case of problems, massive server operating system (both Windows and Unix/Linux flavors) log analysis didn't materialize until more recently. Collecting logs from all critical (and many non-critical) Windows servers, for example, was hindered by the lack of agentless log collection tools, such as LASSO. On the other hand, Unix server log analysis was severely undercut by a total lack of unified format for log content in syslog records.

Web server logs were long analyzed by the marketing departments to check on their online campaign successes (and most web server admins would not ignore those logs as well). However, since web servers don't have native log forwarding capabilities (most log to files stored on the server itself) consistent centralized web log analysis for both security and other IT purposes is still ramping up. There is plenty of interesting info to dig for.

Similarly, email tracking thru email server logs languishes in a somewhat similar manner: people only turn to email logs when something goes wrong (email failures) or horribly wrong (external party subpoenas your logs). Lack of native centralization and, to some extent, complicated log formats slowed down the email log analysis initiatives.

Judging by the traffic on loganalysis mailing list, database logging wasn't on the radar of most IT folks until probably last year. It is emerging now! In fact, IT folks were perfectly happy with the fact that even though RDBMS had extensive logging and data access auditing capabilities, most of them were happily never turned on. It will be all the rage in a very near future. Oracle, MS SQL, DB2, MySQL all provide excellent logging, if you know how to enable it (and know what to do with the resulting onslaught of data)

What's next? Web applications and large enterprise application frameworks largely lived in the world of their own, but now people finally starting to realize that their log data provides unique insight into insider attacks, insider data theft and other trusted access abuse. I expect to see much more of such logs flowing into log management solutions. Additionally, desktop log analysis should not be too far behind.

In a more remote future, various esoteric log sources will be added into the mix. Custom applications, physical sensors and many other uncommon devices and software want to "be heard" as well! :-)

So, from firewall logs to NIDS to servers to databases, web servers and then applications seems very common across a large number of organizations.

Just an interesting observation!

Technorati tags: log management, logs, loglogic, chuvakin, security management

And The Logs Weren't There: Part I

Seeing this story (where logs weren't available when sorely needed) inspired me to finish my own version of that...

First, let me quote the conclusions from the above post.

• "If you got important data to protect, log everything you reasonably can. All the “security” in this scenario failed and failed to help reconstruct events.
• Do you have one of those semi hands-off security appliances that you presume is working fine because you can connect to the web admin portal? Make it forward logs to somewhere.
• Do you have workstations which touch sensitive data anytime? Yes. Then boost the priority to configure central logging, stop procrastinating, then take comfort you’ll be in better shape than the poor souls at this company fighting to salvage their pride, and maybe their jobs."

Darn right! There is no better way to say it. But - guess what - despite us saying this (and pointing possible mistakes), a lot of people still choose to ignore logs. What can we use to help them, even despite themselves? We will invite our friend, Mr Fud F. Scarecrow :-) to assist us with this affair. Yes, many proclaim that people need to be naturally drawn towards doing "the right thing" and scaring people into action is not that efficient (especially, if you do this one too many times...). However, this is the world we live in and in it, FUD works. FUD sells insurance as well as safety features in cars and other products, moves compliance solutions, makes people read and update their boring DR and BC plans, and causes a lot of good overall :-)

And, indeed, one can get desensitized if you hear that "sky is falling" too often, but here is the thing: I am willing to take the risk of such "desensitization" given that sky is indeed "not quite static" :-)

So, let's look at one such scenario in this post (which is, as they say, "inspired by a true story"). Imagine you have a Windows Active Directory (AD) server (or a domain controller) that holds all of the accounts for a good part of your organization. One notable morning you get calls from dozens of frantic users (yes, including your boss's boss :-() who are unable to login to their Windows systems. Their computers reject their apparently correct logon credentials. You check the account settings on your AD box and your face turn pale: there aren't any accounts. The term would be "mysteriously vanished" :-) Where do you go next? Windows event logs on the AD server, of course. Good thinking! However, AD servers and DCs are famous for being very chatty, often producing hundreds of event log records per second on busy networks. Thus, when you look at the logs you notice that the entries older than 8 hours got rotated into oblivion. And there is nothing that points at the account disappearance within the remaining log data. Argggh!

Now, what do you do next? Do you feel at least a little fear about your job, maybe also feeling slightly uncertain of what exactly happened with your server or even doubtful that you can prevent it, if it were to happen again. Maybe your IT team has an SLA to worry about? Which has your boss's bonus dependent on it? What if it happens again tomorrow (after you painstakingly restored all the accounts based on old records, incremental backups and the info from the users)? And why can't it? - you have no idea why it happened this time... Are you 0wned now - or was it a junior admin error? Or a new Windows bug? You truly have no way of knowing, which, as we all know, doesn't help you to feel brave, certain and doubtless... :-)

Now, if only you bought that log management solution and started collecting and analyzing logs before, and not after the incident (as it really happened in the above case) Imagine that!

Technorati tags: security, chuvakin, logs, log management

My Security Predictions for 2007 ... Go!

Finally ... the wait is over. In a few short seconds, my security predictions will be unleashed onto the world. Prepare to be ... underwhelmed (he-he, just kidding!)

Unlike last year, I won't muddy the waters with scores and ratings, but will just say it: predicting is easy if you go for the obvious trends that everybody sees ("hackers will hack, phishers will phish, spammers will spam, bot herders will bot herd, other criminals will, eh, do crimes!" and - yes! - both bad and good stuff will happen in ample quantities). Last year I erred on the side of caution and got every single prediction right. Promise I will be more aggressive - and thus more fun - this time :-)

I. Platforms: Vista will have no impact on the overall risk level of most organizations out there. Yes, some holes will certainly be plugged (and I even agree that "Vista is the most secure version ever", just like every single one of its predecessors was - in its time), but others - possibly of types we don't even know about - will crop up. Sorry, but secure platform =/= secure Internet (kinda like you wearing a Kevlar vest doesn't lower crime in the neighborhood).

II. New technologies: no credible technology that can alone "solve" the problem of insider threat will emerge (many will try); the insider threat problem is just too broad, diverse and rich to be solved by a single technology or even a single vendor (corollary: if somebody is trying to sell you such a technology that claims to do exactly that on its own, then - well, you know what to do ...)

III. Security market: we will see more than a few firesales and possibly total and miserable security vendor failures (wonna bet which legacy SIEM vendor will die first? :-)) There are way too many companies who sell some random and often irrelevant "protection" which sometimes doesn't even work ... at their own demo ... when their CTO demos it ... the third time ...

IV. Risk management: a confusion about what is "risk management" will not subside this year. Business risk? Information risk? Risk as threat x vulnerability x asset? Risk as probability of loss? Arrrghh! - It goes on and on and on. No standard accepted definition of risk management in the field of infosec will emerge.

V. NAC: of course, no list of 2007 prediction is valid without mentioning knack :-) And you know what? NAC will shrink, NOT grow in importance this year! This is where the rubber meets the road and fish start to swim upstream :-) - this prediction started from me reading Richard's piece "NAC is Fighting the Last War" which struck me like a Strength 15 Lighting Bolt. Indeed, narrowly defined NAC largely targets worm infections (and will thus lose relevance) while broadly defined NAC starts to sound like having a well-run network (which is as relevant today as it was in 1992 and probably 2012 as well). The Planet NAC is about to experience a premature eclipse :-)

VI. 0-days: 2006 was the year when this previously obscure term fell victim to malignant marketEErs. 2007 will see more of the same, no doubt. But what about the real 0-day-wielding attackers, poking jokes at the above "oh-day defenders"? Security research into new types of vulnerabilities will certainly continue and more types of previously "safe" (rather, "erroneously thought of as safe") types of content will be used to attack applications. MPG with 0day? AVI with 0day? And, our old friends doc, xls, ppt and now PDF. On the other hand, a major 0-day worm still won't happen.

VII. IP and ID theft, data loss: at the risk of sounding hilariously obvious, I would state that such incidents of ID theft (phishing, etc), broader intellectual property (IP) theft and loss will continue largely unabated. Will we, the security community, try to stop it? Of course, but nowhere near hard enough ...

VIII. Compliance: but of course! Did you think I'd miss this bad boy? Mandatory regulatory initiatives that pack a bite or a punch, such as PCI, will continue to spread and thus grow in importance, while jokes like HIPAA will continue to languish, helping my # VII prediction come true with a bang ... At the same time, I am undecided on the voluntary frameworks that you can choose to comply with (ISO17799/270001, COBIT, ITIL, etc) - will they take off like a rocketship or remain steadily interesting to some? Only time will tell.

IX. Security awareness: well, security awareness will ... ah, come on, just laugh: bua-ha-ha-ha-haaa :-)

X. Finally, I would like to reiterate a few of the last year's predictions that will still ring true this year. Client-side and application-level (especially, web application) vulnerabilities will still be outrunning the server-side and platform-level ones. Major wireless attacks and malware will still not destroy the world.

So, there you have it! Enjoy, comment, slam, compliment, etc! And remember - just as one cannot predict the threats of tomorrow today, one still won’t be able to do in 200X. And in 20XY :-) And - but I am going out on a limb here - in 2XYZ! :-)

All predictions for 2007 that I've seen are tagged here.

Technorati tags: chuvakin, security, predictions, 2007

Anton Security Tip of the Day #7: Don't Log or "They" Will Get Us!

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 #7: Don't Log or "They" Will Get Us!

This tip steps away from regexes, log parsing, data mining and those pesky oh-days :-) and touches upon an interesting log management process debacle.

So, imagine you are a hard-working system admin, just as overwhelmed with various system management issues as "the next guy." One day your boss's boss rushes in and asks you: do we log our employee and partner access to application, tools and data stored on our systems? Thinking that he has finally seen the light and understood the value of logging, you cheerfully say "Of Course!" However, his response causes you to drop that wireless hub you are holding: "We need to stop it immediately or THEY will get us!"

They? Who are "they": the aliens, the ATL agency (stands for "Appropriate Three Letter" agency :-)) or the evilicious Illuminati? No, the boss explains, in this case "they" are simply lawyers who, in case of a litigation against our company, might subpoena the log records (together with email, IM, old documents an other stored and transmitted electronic communication), revealing the horrible truth (whatever it might be - everybody is hiding something).

Upon waking up one night with the above hear, the boss remembered that he "heard somewhere" that if you don't log anything in your normal course of business, than nobody can get the records: they simply won't exist. And so he suggested you turn all logging off. Uh-oh.

This tips is about how you might respond!

Well, first, we need our logs! We use them just about every day for all sorts of operational tasks and losing all that will make troubleshooting and system administration impossible. If you would happen to lose whatever system to malfunction or attack, you will have almost no way to learn what went wrong and thus prevent it in the future.

Second, auditors expect to see logs. And thus, claiming that "we don't do it here" won't fly with them since they would not be able to do their jobs. And - do you really want a pissed auditor within a 5 miles radius? One that doesn't report to IT (i.e. to that boss's boss...)?

Third, if you handle credit card transactions and thus subject to PCI requirements, you have to log, period. Nothing to argue with - unless you plan to run a cash-based business for the rest of your life.

Fourth, if you happen to work towards some of the IT "best practices" and strive for operational excellency, lacking logs will totally torpedo these efforts. Most such documents call for logging and monitoring.

Fifth, indeed, the new e-discovery rules (rule 37(f) "Safe Harbor") do indeed state that 'If you can prove that missing data has been deleted during “routine” data expunging [or never existed in the first place], you are probably safe from legal sanctions.' However, most people agree that it is not an unlimited "get out of jail free card" since there are commonly accepted views of what is routine (e.g. doing some logging) vs what is exceptional - or even exceptionally dumb (e.g. not doing any logging)

So, today's tip is: logging is too useful to be destroyed on a whim. If you get in a similar situation (although, likely not that extreme!) use this material to fight for your logs!

Again, 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, logs, log management, chuvakin

Further Musings on Web Filters

So, this post of mine did generate some fun responses. While going thru them I remembered an old idea that I saw a long time ago on one of the security mailing lists, possibly firewall-wizards. Somebody suggested collecting all the web surfing statistics data for all the company users and posting it publicly (well, internally) for all to see instead of blocking.

Want to surf playboy.com in clear violation of the network AUP? Suuuure, help yourself, but be relatively confident that your boss will know about it. Surfing to a "hacking" site? Well, if security is your job, you should be.

This approach resolves the "false positives" challenge, inherent with "blacklist" filters and takes a now-fashionable community approach to security. At the same time, embarrassing people into action seems more efficient than threatening or failing while trying to block their access. What is even better, this approach does seem to "fail gracefully" unlike the "block and filter" approach since he latter, when penetrated, provides no benefit.

So, post the statistics per user, URLs, volumes, etc. Glance over the results and let others do the same. I am pretty sure that "inappropriate web access" will subside dramatically. Since we know we 'have no privacy' , why not use it to our advantage?

Musings On Passwords

Many people predict the death of password any-day-now, since 1985. Let me try to throw something discussion-worthy out there. I'd make the claim that passwords a) are just fine if done right and b) will never die.

So, here are two recent pieces related to death of passwords:

This "Password Irony" piece refers to Bruce Schneier's paper which analyzes MySpace password cracking. In "Password Irony" Pete adds: "I am at a loss to explain how he can come to this conclusion when every single one of the 34,000 passwords he analyzed were stolen through a phishing attack." OK.

This "Myth of secure password is ended" does reminds us that rainbow tables allow us to crack passwords much easier: "then arrived the Rainbow Table method and everything changed." OK, OK

So passwords are bad. Or are they?

However, think about your typical 4 digit ATM PIN: are you freaking out because of it? I don't! Why:

* no password data to run rainbow tables methods
* no brute forcing (lockout after 3)
* only complicated and conspicuous physical "sniffing" (and shoulder surfing) can be used to steal the PIN
* password needs to be entered only at a specific location and not remote (and there is usually a camera that watches you while you do this)

The above sure seems sufficient since "ATM password attacks" are not that common. So, passwords seems to be done right in this case.

Now, think about all the good things about passwords:
* no physical device to possess (and lose, and buy, and carry, etc)
* easy to change (unlike most if not all biometric methods - this scare me for good since once lost biometrics cannot be changed ...)
* [sometimes] easy to remember while secure (in case of long pass phrases)

Thus the conclusion is obvious: long live the passwords!

Another Fun Old Preso: "Threat and Vulnerability Intelligence"

Here is one more of my old presentations from 2003: "Threat and Vulnerability Intelligence." I admit that it does sound naive at times, but I think it is still [somewhat] relevant and useful.

On Getting to Blocked Web Sites

So, why would someone who runs a security blog link to a list of advice on bypassing web filters (see ”Top 10 methods to access banned websites”)?

Good question! Here is the answer: a large part of web content filtering seems like a bit of a counter-productive scam to me. With each content filter used, I have seen very large numbers of very annoying "false positives" (i.e. useful and harmless sites being blocked) that lead me to think of ways of bypassing them. The best analogy would be if you anti-virus solution will flag and destroy random non-malicious files every day. Would you use it? No way!

Is that a good thing? No. Is that a policy violation? Maybe. But - guess what? - once I needed to go to SecurityFocus to do my job and some dumb content filtering vendor blocked it in their default configuration as a site on "hacking" (wOw, that is deep!) This did happen a few years ago, before Symantec bought the site, but, to be honest, I never checked back whether they still block it.

On Open Source in SIEM and Log Management

Now, check out the prediction #4 and the comments on it here. Folks discuss the challenges that a possible open source SIEM solution would face, if it ever to materialize (OSSIM and OSSEC excluded for various reasons)

More on Amazing Lack of Teeth in HIPAA

Lots of folks joked about how toothless HIPAA is. Now, it turns out that the complaints don't even get investigated, much less see through all the way to resolution ...

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

No wonder so many IT and security folks in medical orgs openly state that their plan is to ignore HIPAA completely until they are (more like "if they ever...") sued.

Richard, Get'Em! :-)

Honestly, I have never-ever-ever seen people more confused than this about what are threats and what are vulnerabilities.

Just an idea: Richard Bejtlich should start a doghouse on his blog, kinda like what Bruce Schneier has for crappy crypto on people who mix up the definitions of threats, assets and vulnerabilities. Examples:

" Here are some relatively common security threats to help you get started in creating your company's threat list:
Computer and network passwords.
[...]
Data backups
[...]
Long-distance calling"

etc.

The article is also full of hilarious blurbs such as this "Most threats repeat themselves, so by cataloging your company's past experiences and including the relevant threats on your threat list you'll get a more complete picture of your company's vulnerabilities."

Stuff like this makes people not take the security profession seriously...

Most People Don't Trust Their Security Software ...

"A poll of Internet users shows that a majority are "not confident" that their security software is protecting them."

But, seriously, should they? Security SOFTWARE never saved anybody on its own; security people executing security processes which involve running security software is what protects the organizations ...

Security Absurdity Lives On

So, this landmark paper "Security Absurdity: The Complete, Unquestionable, And Total Failure of Information Security" that I commented on before lives on. Here is a looooong bunch of comments aggregated by the author.

Most everybody is screaming for "What is you S-O-L-U-T-I-O-N!?" and the author promised Part II containing exactly that. Oh, yes, the world is waiting! :-)

And, I hope you guys don't lower your opinion of me since I am blogging this at 11PM Saturday night :-(

On Visualizing Log Data

Here is a fun discussion on why market is not ready for security data visualization (or the other way round) from a new portal SecViz.org.

Indeed, not understanding the underlying data as well as high skill level requirements are all there ...

2007 Prediction Criticism

I've been meaning to assault - yes, just for fun - somebody else's 2007 security predictions before releasing my own. And I've been looking for a suitable target for days and - oops! - Richard "Death of the IDS" Stiennon releases his.

Now, I mentioned in the past (just Google) that some people just shouldn't be in the prediction business :-) So, what do we have to tear apart here:

"4. Attacks against DNS are the threat of the year"

He-he, no way. This ain't 1995 anymore. Yes, DNS servers will be hit, but it will certainly not be "a threat of the year."

"6. More attacks against wireless networks"

Nope, dramatic increase is not going to happen. There are still enough Windows boxes left to hit before moving on. Then again, a law of small numbers might help and the current low attack count +1 would qualify as "more attacks"...

But - as a disclosure - there is one prediction that is superbly inciting. In fact, I was going to put it in my own prediction set as well (just wait...) Here it is:

"10. Spread of Windows Vista will have zero impact on the overall threatscape"

Right on! It won't have an impact.

Zone-H Defacement Story: Log Analysis at Work

Here is a fun account of a [relatively] advanced attack against a high-profile site (a high-profile defacement mirror site, to be exact!)

Not surprisingly, web server logs play an important role in the investigation, in a situation which I highlighted in this tip. Specifically see these two records shown in the paper:

- - [21/Dec/2006:23:23:15 +0200] "GET

/index2.php?act=img&img=ext_cache_94afbfb2f291e0bf253fcf222e9d238e_87b12a3d14f4b97bc1b3cb0ea59fc67a

HTTP/1.0" 404 454

"http://www.zone-h.org/index2.php?option=com_jce&no_html=1&task=plugin&plugin=..<>/<...

&file=defi1_eng.php.wmv&act=ls&d=/var/www/cache/&sort=0a"

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)"

- - [21/Dec/2006:23:23:59 +0200] "GET

/index2.php?option=com_jce&no_html=1&task=plugin&plugin=..<>/<...

&act=ls&d=/var/www/cache/cacha/&sort=0a

HTTP/1.0" 200 3411 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)"

212.138.64.176 - - [21/Dec/2006:23:25:03 +0200] "GET /cache/cacha/020.php

HTTP/1.0" 200 4512 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)"

(note the web server response codes in bold)

This is another fun log line from the incident account that has some lessons-learned value as well - it has a 200 code on a script that you (the web server admin) didn't deploy (see bold)...

- - [22/Dec/2006:01:05:15 +0200] "POST

/cache/cacha/020.php?act=f&f=configuration.php&ft=edit&d=%2Fvar%2Fwww%2F

HTTP/1.0" 200 4781

"http://www.zone-h.org/cache/cacha/020.php?act=f&f=configuration.php&ft=edit&d=%2Fvar%2Fwww%2F"

"Mozilla/5.0 (Windows; U; Windows NT 5.1; ar; rv:1.8.0.9) Gecko/20061206

Firefox/1.5.0.9"

So, what do we learn from this incident log analysis:

1. Look for weird commands (those containing ".

More on The Same

Bruce Schneier makes more fun of airline security here.

So, Is There ANYBODY in Our Profession Who ...

... doesn't agree with that:

"I've had countless conversations with security folks, the majority of whom believe that the TSA security measures are useless. And now yet another respected news outlet is saying it too. And you know what? He's totally right. The security measures are a show... And underneath the show? Continued incompetence. "

Just thinking aloud. Read the entire travel horror story and security lessons here.

Blog Tagging Onslaught

So, I've been blog-tagged by Richard Bejtlich. I admit that I have to research what it meant :-) So, I am telling five things that my readers might not know about me and giving a list ("tagging") of five other bloggers to spread the meme further.

So, my five things:

1. For whatever strange reason, some of the other tagged security bloggers chose their past military experience as one of the items: so I am stealing this one. No, I didn't drive a tank (neither American nor Russian :-)), but I did some fun stuff during my "ROTC" training since I was doing it in PsyOps. 'Nuff said.
   
2. My security career pretty much started from reading a book called "Maximum Security" by Anonymous. And, no, I still don't know who wrote the book (feel free to enlighten me)
3. I hate the work "geek" and I don't associate with Dilbert, ever.
   
4. To back the #3 up :-) I have one of the most non-geek hobbies ever: latin dancing (see e.g. this).
   
5. And finally - a shocking revelation: in the past (and I do stress that point!), I was very interested in the teachings of some Ross Jeffries ...
   

My five "victims":

1. Raffy Marty
2. Pete Lindstrom (yes, even in light of this)
3. Ron Gula
4. Amrit Williams
5. Thomas Ptacek