Fun Read: Harvard Biz Review Data Loss Case

This is an enlightening (if fictional) data breach story at a retailer, involving PCI, data theft, lawyers, breach disclosure and a lot of painful decisions by the exec team. Those who never were in such situations should read in order to at least take a peek at what might happen to your organization in the near future ....

Especially fun things to notice:

- an opinion by their legal that "If we disclose, we’ll probably get sued"
- environment complexity which doesn't allow them to pinpoint the breach

The sad part is that the story is kinda unfinished... Please, please, write it all the way to the end :-)

UPDATE: another set of fun comments on this story is available here. Chris makes an insightful comments about the team going thru "all seven distinct stages of the data breach grieving process" :-)

Fun (Probably Humorous) Piece on Future Warfare

When I saw a link to this at DefenseTech and started reading, I kinda took it seriously. However, as I read about half of it, I realized that it is clearly TheOnion-style spoof piece (after all, it is 2017 and Chelsea Clinton is the president :-)). Check it out and decide yourself ...

Monthly Blog Round-Up - August 2007

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. Yes, attention spans seem to be shrinking even among the security professionals ...

So, my 1st monthly "Security Warrior" blog round-up, top posts and comments by topic.

1. My blog got featured on a few high-profile programming sites and I got a small "/. effect." The topic that got a boost was anti-virus efficiency. Thus, these posts were the most popular: 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,
2. Next, Top 11 Reasons to Collect and Preserve Computer Logs continues to be a "best seller," just as I suspected. Stand by for the third post in the "Top 11" series - "Top Reasons to Secure and Protect Your Logs"
3. WSJ saga (summarized here) and my post Hello, Mr Darwin! also "topped the charts." The bottom line is still "don't rely on users for security" (but still have a good security awareness program!)
4. Of course, last month's Security ROI Pile-Up! post is still hot, hot, hot. More attacks are coming (hint, hint: "positive return on security" - bua-ha-ha-ha-haaaaa)!
5. This month's tip on proxy logs (Anton Security Tip of the Day #12: Proxy Log Fun - Proxy Logs vs Information Leakage) is also on the list.
6. Finally, A Bit More on Log Management vs SIEM (and Semantics) post which highlights some of the differences between SIEM and log management also made it to the top. More on the topic is here.

See you in September :-)

Technorati tags: round-up, monthly

Interesting Vision of Future Direction of Security

Another one of those pieces marked "2blog", but not blogged about before: Rob Newby proposes his vision of future security (rephrased by me): software is crappy and continues to be crappy since this is what the market wants. However, software "comes with" a sandbox, likely written by another vendor and costing extra, that actually enabled security (somehow, possibly thru some kind of application virtualization) - Rob, feel free to correct me here.

Interesting ...

Blogging frenzy mode = off :-)

Still, I Stick to It or 'SIEM vs Log Management'

Even though I did talk about it at length before (e.g. here), this article reminded me to remind you :-) I think Forrester folks are a bit optimistic. Think about it: if you have logs - you need log management. If you are ... if you have ... ehhh, well - when do you need a SIEM?

A long time ago, in my previous life, somebody came to me and said "I want everybody to need SIEM, our SIEM! Make it happen" (well, not exactly these words, but you get the idea). I thought about it long and hard and you know what? - even back then it occurred to me that SIEM is not for everyone. Log management, on the other hand, is for everyone who has logs (well, more than a trivial amount of them ...)

Fun Stuff From Stratfor

An interesting Stratfor piece on Iraq Endgame is republished here at Military.com. Also, some discussion that followed.

Useful for those who don't subscribe to Stratfor (you should!)

UPDATE: why read stuff like this? What's the relevance for security? This pretty much says what I would have written myself :-) - key quote: "Financial Cryptographers [blog] are interested in war because it is one of the few sectors where we face an aggressive attacker (as opposed to a statistical failure model)"

Interesting Forensics and Logging Presentations from DFRWS

Some fun reading material here: DFRWS 2007 preso and papers. A few fun pieces on logs to, specifically

• "Introducing the Microsoft Vista Log File Format. Andreas Schuster. (paper)
• Automated Windows Event Log Forensics. Rich Murphey. (paper)
• Analyzing Multiple Logs for Forensic Evidence. Ali Reza Arasteh, Mourad Debbabi, Assaad Sakha, and Mohamed Saleh. (paper)"

Read on!

OMG, How Naive!

"Designing a PCI-Compliant Log Monitoring System" paper is incredibly naive, since the author thinks "logging in PCI = Requirement 10." Read this instead and learn that logging is actually present (or implied!) in ALL 12 of the PCI DSS Requirements.

On Sony, AGAIN?

While media will now call just about everything "a rootkit" ("why not? it sounds kewl!"), somebody has to ram a long one up Sony's ... you know :-) for utilizing this type of directory hiding. Will this create as much bruhaha (sp?) as their DRM "rootkit"? Maybe not, but now people seem much more paranoid and will watch them more carefully.

On Visualization

Ah, maybe somebody other than Raffy will benefit from it too :-)

Where DO You Draw The Line: Security Responsibility

Warning! Warning! Blogging frenzy ALERT :-)

So, this piece from AndyIT blog and his quote of SANS's Dr Ullrich, touch upon something deceptively obvious: just WHERE do we draw the lines between user vs IT/IS responsibility for security? In fact, the situation is event more complex: it is user vs IT vs infosec team! (and there is also a software vendor responsibility somewhere here....)

Let's go thru some scenarios:

1. User and IT=0%, infosec=100% Result: failure of security due to technology limitations, lack of control over the environment as well as social engineering
2. User=100%, IT, infosec=0% Result: trivial case, obvious failure
3. Then it gets real complex real fast for the cases of shared responsibility ...

Thoughts? Analogies from adjacent fields? Metaphors even? I think this will not be resolved in our lifetime....

UPDATE: AndyIT answers it - "Probably something like Security=85%, IT=10% and Users=5%." See more of his follow-up post here.

Mysterious Post - To Be Explained Later

NEVER FTP as 'root' :-)

0wned - for as long as the eye can see ...

So I am looking at the logs from this deeply 0wned Linux box and not finding any signs of how it was broken info - I am looking for a few days back from the moment it was discovered. As a result, I am puzzled. What's the next step? I am looking a bit more into the past, and then a bit more, and then 2 months more (!) and then - oops! - I run out of logs. Logrotate, thanks bitch! :-) What we have here is a system that has "root" logins from .ro domains for as long as the eye can see. Case closed!

Folks, don't get into such situations - retain the logs for longer! Disk space is cheap, but the creativity that you need when analyzing an intrusion with no evidence is expensive ...

Possibly related posts:

• And The Logs Weren't There: Part I

• And What if the Logs WEREN'T There?

• Top 11 Reasons to Collect and Preserve Computer Logs

• Anton Security Tip of the Day #2: Watch Those Pesky Log Rotation Routines

More Fun With Web Proxy Logs!

After publishing my proxy log tip (here) and preparing for this upcoming webcast on this (here), I figured I'd post a few more mini-tips on web proxy logging and log management.

First, why look at proxy logs? Apart from my overall answer that applies to all logs, proxy-specific reasons are the following:

1. Review users’ activities on the web (not just surfing!)
2. Monitor applications' HTTP activity
3. Detect Web-enabled malware traffic
4. Study proxy performance metrics

Most people just focus on #1 above and kinda forget #2-#4. Also, the focus of #1 is often narrow - what do they surf at work?- and not broad - what do they do on the web? - which is much more useful. While there is no direct mention of proxy logs in recent regulations, monitoring what users do with YOUR data is clearly part of the compliance mandates (and, obviously, a good idea in general!) Indirect references to proxy logging can be seen in the following:

• Proxy monitoring is part of the overall control and governance (thus SOX, HIPAA, GLBA, etc)
• Legal requirements to have audit trails (thus HIPAA, PCI)
• Breach disclosure laws also impact (SB1386 and others, soon US-wide)
• On the flip side, privacy laws might mandate the opposite i.e. NOT having logs.

So, please treat proxy logs with the respect they deserve!

Possibly related posts:

• Anton Security Tip of the Day #12: Proxy Log Fun - Proxy Logs vs Information Leakage

Technorati tags: logging, log management, web proxy, security

On Semantic Web or "Web 3.0" (Yuck!) Threats

I want to be a hype-master for a day :-) So, why else talk about "web 3.0" threats?

In any case, I had this fun chat with a journalist about threats to semantic web (which some people started calling 'web 3.0'). WTF is semantic web? Wikipedia fans go here and here, others go read Sir Tim Berners-Lee. The way I understand it is: it is the web that is both human- and machine-understandable, which creates (or allows one to create) a "mash-up" of anything with anything else (well, almost) as well as allows funky automated ways of querying the web.

So, go read the piece, keeping in mind that journalists have a tendency of hearing what they are writing about, not what is being said :-)

Amazing PCI Book Review

So, this made my day yesterday and I just have to share it. Andrew Hay published this glowing review of the"PCI Compliance" book.

The part most exciting to me obviously was: "Chapter 6 was by far my most favorite chapter and Syngress has offered it as a free download from their website. Many of you know what I do for a living and know how important understanding logging and requirements for logging is for my day-to-day duties. This chapter focuses around PCI Requirement 10 which details how you must handle the log data collected in your PCI environment. As soon as I started reading this chapter I knew that Dr. Anton Chuvakin had written this section of the book, or at least had a heavy insight into its direction. This chapter alone makes the book worth its weight in gold."

BTW, you can get this "gold" chapter [PDF] for free at Syngress site, since it was chosen as a sample chapter (!) by the publisher.

On Nanotechnology

A very fun Stratfor piece on nanotech called "Nanotechnology and the Regulation of New Technologies" says: "A recent patent application was submitted for an organism composed of cells whose genetic makeup has been limited only to the genes necessary to maintain life. These synthetic organisms, combined with nanotechnologies that can provide structure and even potentially movement, create essentially programmable living things."

Security implications anybody? :-)

Size Does Matter :-)

A long time ago, I made a promise to myself to not use this blog to attack competitors (in a broader sense of the word - companies related to log management). And, in general, our marketing folks told me that boosting "other's" web rankings is not a good idea :-)

However, there are always exceptions :-) In this case, I am making an exception because I need to take apart something profoundly stupid. And because it is kinda fun :-)

So, the seemingly smart folks at Dorian said: "It seems that upper management loves to approach enterprise log management as a quest for the one holy grail product that can manage logs from hundreds of different devices and operating systems, in addition to folding the laundry and making coffee.This approach to procuring log management technology is fatally flawed from the outset." [A.C. - their emphasis]

and then even

"The thousands of log generating devices and operating systems in today's marketplace truly and completely prevents any vendor from being a polymath at all of them."

Well, after I stopped laughing at the naivete of the above, I realized that I have never seen a company call itself incompetent with such elegance :-) Have these people heard about taxonomies, normalization, common schemas, cross-device correlation? Or even full-text indexing? You know, the simple stuff :-) How deep under the bush one has to crawl to miss all that?

So, it is not some "evil" "upper management" doing it, it is just common sense talking :-) Indeed, one of the main benefits of log management is in being able to analyze all logs, from all places, all the time (not "some logs, from some platforms, sometimes" :-)) And, analyzing all logs does NOT mean that your solution will be super-complex and cost a million bucks! Yes, sometimes you have to fall back to using a domain-specific log analysis tool, but only if your task is esoteric enough (example: analyzing web logs for specific purchasing behavior) or if you have a small and specific task at hand (example: need to review logs on my desktop). In most other cases, you'd want to cover as much as possible with one tool.

So, to conclude, device-specific log management is so deeply idiotic, I don't want to spend a single second more on that. Stop!

On DLP and Next Big Things

Last post for today - promise! :-)

Is data leak prevention/detection (DLP) the next big thing in security? Fun discussion is here.

Ah, Come On, Use the Spirit, Not the Letter!

Somebody commented on PCI (again!?!) Requirement 10.5.5 which says "Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed."

The comment was: "I am finding this item difficult to truly get my hands around. I am find with using a tool like trip wire to md5sum the log file post log rotation. However, I can't figure out how to handle the logs that are actively being appended too."

Indeed, the req 10.5.5 is phrased funny, because whatever "change detection software" will not STOP the changes, just make them known. However, the req seemingly applies to stored old log files, not the ones currently being appended to. While I saw some folks handle per-record MD5 checksums combined with other-than-append operation detection, PCI doesn't seem to mandate it: just make sure your log management solution keeps checksums on archived log files.

Fun Intrusion Story II

Fun intrusion story - with logs and all.

On PCI Myths

I know some or you are starting to think "Oh, no, Anton is on another blogging spree..." and you know what? I am - screw that "post-a-day" approach :-)

So, fun paper on PCI myths - here are the myths:

" Myth 1: PCI is hard
Myth 2: PCI will make us secure
Myth 3: Encryption is scary
Myth 4: "I don't take enough credit cards…"
Myth 5: Product X will make me compliant"

Read on!

FUD Works! :-)

When reading stuff like this, you can't stop, but think "FUD works!" (my old related piece is also here) If not, wonna lose $256m? :-)

On Database Security and Monitoring

Fun high-level paper on database security. Here is an interesting bit: "Analysts differ a bit in their recommendations, but generally suggest activity monitoring, which could give the most return on investment." While I cringe at this reference to "ROI," the comment itself makes sense. Database encryption lags and will continue to lag, while database activity logging and monitoring - slowly! - starts to rise ...

PCI Complex and Simple....

So, can someone finally explain the "PCI mystery": how can the thing be both "complex" and "basic, common sense" at the same time? This is not the first time I am seeing this, BTW.

PCI and Database Logging

I saw this pathetic excuse of a vendor :-) the other day: they were trying to convince a prospect that their "kinda log management" tool is suitable for PCI DSS compliance (i.e. for Requirement 10 and as well as across others - see more here in my PCI book chapter on logging [PDF]) without having any way to collect and analyze database logs, such as Oracle audit logs/tables or MS SQL trace files. Yuck!

One would think that this post belong in the "Nobody is That Dumb ... Oh, Wait" category, but no, folks, this is for real. Do you think these PCI DSS people put logging requirements in PCI just for fun? I wish :-) No, they put them there so that access to credit card information (PAN as well as other credit card and customer data) is recorded and can be monitored and reported on. And where most of the card numbers and customer info are stored? Yes, in databases!

So, please tell me, how can someone who cannot collect logs from databases have any semblance of credibility in PCI-driven log management? Exactly! :-)

On Awards

Think this (and more here) doesn't happen in enterprise security land? He-he, think again ...

UPDATE: which security publication is known for such reviews?

Fun "Most ..." List from A "Secret" Gartner Blog

"12 Security Features and Rules Most Likely to Mess Up" from a "secret" Gartner blog. Examples

"1. Most likely to be written down
2. Most likely to be left active
3. Most likely to be ignored
4. Most likely to already be in use, without most users' knowledge"

Another Presentation: Logs for Information Assurance and Forensics @ USMA

Here is my old presentation "Logs for Information Assurance and Forensics" that I gave at USMA, West Point last year when I was giving a lecture there.

On BSOFH

BSOFH? ROFL! Very funny indeed.

Esp this: "... Our CFO needed a new office chair after seeing THAT one on his screen" or this: "I can turn my 5-year-old’s artwork into a PowerPoint slide and make the management think it’s the newest ITIL model. Then I can rotate it 90 degrees, flip it 180, and sell it to them the following month all over again."

Fun Paper: "Malicious Web Servers"

A very fun paper by The Honeynet Project!

In this paper "we examine these client-side attacks and evaluate methods to defend against client-side attacks on web browsers. First, we provide an overview of client-side attacks and introduce the honeypot technology that allows security researchers to detect and examine these attacks. We then proceed to examine a number of cases in which malicious web servers on the Internet were identified with our client honeypot technology and evaluate different defense methods. "

New tools are also released.

Nobody Is That Dumb ... Oh, Wait! - V

Another day, another stellar "Nobody Is That Dumb ... Oh, Wait!" case, number V is the series. ... So, will you file for an IPO under such circumstances? :-) Mike adds some hilarious details: "Their income statement showed a loss of about $10 MILLION on revenues just over $2 MILLION."

Ha-ha-haaaaaa. Ha-ha-ha! Haaaa :-)

Is Your PCI Auditor a Scammer?

So, we know from the Gartner folks that sometimes the same company can be used for PCI assessments and then for remediation services or prescribed products. Specifically, they say: "The assessor - which is also a vendor of security services - tells you you need a scanning service for all your nodes and servers, since they’re all somehow connected to the servers holding your cardholder data. Oh, and by the way, they can sell you the scanning service. [...] Well, the card companies may not learned anything from the Enron and accounting/audit firm debacles of the past few years, but we have. That’s why Gartner strongly recommends that you hire an assessor that doesn’t try to sell you security software or services."

OK, this makes sense, even though I believe that one can handle this gracefully and ethically. This is a conflict of interest to carefully resolve and not a scam.

However, I recently came across the opposite situation, which smacks of scam so strongly that you will need to hold your nose for a loooong time :-) Namely, a PCI assessor is saying the following: "Pay my [possibly increased ...] assessment fee and I will make the findings look  like you already have all the technologies needed to comply and you will save tons of money on all this 'unneeded' security gear! If auditors come, my assessment results documentation will look so good, that they will not fine you a dime."

Just how outrageous is that? Just as people grew cynical of compliance spending for security, somebody came up with an idea to spend on compliance and decrease security... Kewl stuff :-)

Anybody knows of any way to report the fucker so that PCI Security Standards Council will revoke his license and ram a big one up his ...?

Technorati tags: security, compliance, PCI

Fun One: "10 claims that scare security pros"

A fun piece "10 claims that scare security pros." Examples are "IT security is information security here", "Our managers have copies of all passwords" and "We sent the firewall rules out to ..."

On Plasma Shields

The bizarre part is that this stuff was all over Russian (then Soviet) tech hobbyist magazines back in the 80s ... All this "controlled plasmoid" stuff isn't new at all, even though some say it never quite worked right, if at all.

UPDATE: the patent does seem to give some credit to works of some Mr Leonov, which seems to be related to reducing air friction using artificially generated plasma cloud around the plane.

On Application Logging for Security

A fun one (Note to self: OMG, how did I miss it when it was published...): "This article examines the dismal state of application-layer logging as observed from the authors’ years of experience in performing source code security analysis on millions of lines of code. "

On "Auditing Security Events 'Best Practices'"

Here is dated, but still insightful doc on "Auditing Security Events 'Best Practices'." It covers event log collection and analysis, as recommended by Microsoft (the list is sadly incomplete - there is certainly much more stuff to look at in the Event Log). Example recommendations:

• Audit success and failure events in the system event category

• Audit success events in the policy change event category on domain controllers

• Audit success events in the account management event category

• Audit success events in the logon event category

Want more? Read the doc.

Build vs Buy for Log Management

My favorite SANS presentation that I gave a few times was "Choosing Your Approach to Log Management: Build, Buy, Outsource" (e.g. see here). This story that I just posted to LogBlog makes this build vs buy distinction painfully clear. Enjoy!

On Conferences

I find it deeply troubling that there are still plenty of conferences that charge speakers for speaking (!). Yes, it is indeed that fucked up! I understand how some prestigious conferences can get away with only giving speakers free conference passes and still attract good talent. Still, the best conferences out there don't stop there: they also cover your travel expenses and sometimes give a small honorarium, which is great. It works wonders to increase the quality of presentations and overall conference experience!

Now, vendor speaking ops are a bit of a different story; a vendor might sponsor a conference and get a speaking slot, clearly marked as such.

However, think what kind of speaker a "pay for play" conference will attract? This automatically means that all people attending a pay-to-speak conference are scammed out of their hard-earned dollars. So, it boggles my mind why would someone ever attend a conference where the only speaker selection criteria is: "Got 3 grand? You ARE an expert here!"

Before signing up for that next security conference, think: is it a pay-to-play scam?

Just A Reminder ...

"The creativity and ambition of cybercriminals all but ensure for years to come there will be a market not only for security technology but for individual security components provided by a multiplicity of vendors."

Another fun quote: ""the security market will therefore remain for the foreseeable future in a steady state which is 'always consolidating but never consolidated.'"

Indeed, this thing I wrote a while ago is still valid.

Possibly related posts:

• Will security ever "get done"?

Free PCI Compliance Book Chapter: On Logging!

Wow! Syngress/Elsevier has released one chapter from our "PCI Compliance" book: and it is my chapter on logs in PCI! Enjoy! [PDF]

Fun PCI Article ...

... which makes a good, if somewhat obvious, point: "Rather than making excuses about how difficult or costly PCI is, companies need to step up to the plate and start taking security seriously. [...] PCI is the best thing that has happened to consumer data protection in the payment industry in many years. "

In other words, stop bitching and start working on things which were useful even before PCI came to bite you in the ass! :-)

Possibly related posts:

• All PCI-related posts
  

If you don’t secure your data, is it unauthorized access?

Interesting: If you don’t secure your data, it’s not unauthorized access?

A quote: "A recent court opinion out of Eastern District of Pennsylvania in Healthcare Advocates Inc. v. Harding Earley Follmer & Frailey, No. 05-3524, is worthy of note. Law.com reports: 'A law firm did not violate copyright and computer anti-hacking laws when it used a Web archive search tool to recover old Web pages of its client’s adversary, says a federal judge.'

Dedicated to Conspiracy Buffs Everywhere ...

The FBI Can’t Link Bin Laden to 9/11? Why Is This Not News? This does seem to confirm it, kind of.

WSJ-inspired Poll Results In

Poll results are in - no surprises for me here (you can till take the poll here).

Will you break a security policy if you know it is neither enforced nor monitored AND that there can be no repercussions whatsoever (and YOU personally don't think it is sensible)?
		Yes, if I REALLY need to do something (53%)
		Yes, sure! No enforcement - no compliance. (17%)
		No (17%)
		No, not if I created the policy (7%)
		Other - leave comments (3%)
		28 total votes

What it means - to me - is that security people are people too :-) This pretty much rhymes with what I said in my first WSJ post here: if users feel that they need (and CAN!) bypass security to do their work, they will ...

UPDATE: the entire WSJ "blood trail" is tagged here. Especially fun bits are here, here and here.

On Crossing the Chasm

Fun post from Andy on "crossing the chasm." Be careful, if your success is only due to early technology adopters, you can run out of them :-) And then, if you cannot sell to "normal people," you are f*cked ...

More On LASSO and Windows Logging

Here is a small blurb that I did for CNET on LASSO (our open-source agentless Windows-to-syslog collector) and Windows log collection. BTW, a new version of LASSO is out.

One thing to keep in mind is that you don't need LogLogic appliances to use LASSO: it can forward events to syslog-ng or other syslog destinations. However, if you do need more than a syslog server, LASSO works perfectly with the appliances as well.

Anton Security Tip of the Day #12: Proxy Log Fun - Proxy Logs vs Information Leakage

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 #12: Proxy Log Fun - Proxy Logs vs Information Leakage

You probably know that web proxies (such as Squid, BlueCoat SG, BlueCoat Netcache and others) produce a lot of fun logs. Indeed, they are fun since they can be used for a whole range of things, from routine monitoring for AUP compliance to malware detection as well as possibly looking for the security scourge of 2007 - web client attacks.

Specifically, in this tip we will learn how proxy logs can be used for detection of file uploads and other outbound information transfers vie the web. First, think what is the legitimate use of file upload functionality for your web users. If web mail is allowed, then sending an attachment will include an upload. What else? The rest will be considered at least suspicious...

In addition to file uploads, some spyware application will also use similar methods to steal data. Looking for methods and content-type in combination with either known suspicious URL  or user-agent (i.e. web client type) can often reveal spyware infections, actively collecting data. Admittedly, a well-written spyware can certainly fake the user-agent field so it is clearly not reliable, but still useful to add to our query above.  Here are some of the criteria we will use to look for uploads in Squid and BlueCoat SG proxy logs:

• HTTP method (logged as "cs-method" by BlueCoat) = POST  (as opposed to the usual GET, used to retrieve web content).
• For information uploads: content type (logged as "RS(content-type)" by BlueCoat) = anything but "html/text" (which is the type used for uploading  web form contents) - especially try content types  "application/octet-stream", "application/msword", "application/powerpoint", "application/vnd.ms-excel", "application/pdf" and a few others to look for common file uploads
• For spyware and application data transfers: user-agent set to anything but the common ones (i.e. not Mozilla, iTunes, LiveUpdate, etc) or even to "unknown." One can also try user-agent containing your favorite messaging app (e.g. "MSN Messenger", etc)

(if you feel adventurous, other interesting content-types to try are "application/x-javascript" and "text/javascript")

Here are the examples of the above, including some "classics" (while spyware specimen are a bit dated, this method of  detecting them via logs is relevant):

1. 1124376766.026 RELEASE -1 FFFFFFFF 4734C557F9315105CA6BE0FA56B94D55 200 1124276674 -1 -1 unknown -1/0 POST http://reports.hotbar.com/reports/hotbar/4.0/HbRpt.dll
2. 1124392388.975 RELEASE -1 FFFFFFFF 810FFBF233584C330353CF0A8C31F5D2 503 -1 -1 -1 unknown -1/813 POST http://log.cc.cometsystems.com/dss/cc.2_0_0.report_u
3. 2007-05-19 03:55:12 160 10.1.1.3 - - - OBSERVED "Spyware/Malware Sources;Spyware Effects;Web Advertisements" - 200 TCP_NC_MISS POST text/html;%20charset=utf-8 http bis.180solutions.com 80 /versionconfig.aspx ?did=5342&ver=1.0 aspx - 10.1.1.2 273 175 - - none - -
4. 2007-05-21 03:10:40 4 10.1.1.3 Joanna- authentication_redirect_to_virtual_host PROXIED "Search Engines/Portals" - 307 TCP_AUTH_REDIRECT POST - http storage.msn.com 80 /storageservice/schematizedstore.asmx - asmx "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MSN Messenger 7.5.0324)" 10.1.1.2 791 2566 - - none - -

Here are some other signs that will make the above log entry extra-suspicious is:

• A dead giveaway: upload happens to a "known bad" URL (e.g containing "gator" and others above) 
• Upload happens to an unresolved IP address (do a "whois" on it!)
• Uploads happens to a port not equal to 80 (i.e. the URL contains a port such as http://10.1.10.10:31337)
• Upload has confidential file name in the log entry (e.g. somebody dumb emailing a sensitive file to himself - as discussed here)

Overall, this log analysis method is good for casting a broad net to catch not just spyware-infected systems, but also unauthorized applications (e.g. method=POST and user-agent=iTunes), instant messaging (e.g. method=POST  and then by user-agent, content or URL), simple forms of data theft and document handling policy violations (emailing files to self via web mail: method=POST and sensitive file name present in the entry; also content type set to popular file types) as well as other abuses of web access. As a result, proxy logs provide an extremely rich AND readily available source of data about threats that users face!

To top it off, one promising direction of future research is using web proxy logs to detect client-side exploits by malicious web servers (more on this in the near future!)

Possibly related posts:

• Anton Security Tip of the Day #6: The Other Web Log
• All my past security and logging tips

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

A "Deep" Thought on WSJ Debacle

Remember this poll I did a while ago? I asked about the willingness to break various security policies. And the results were indeed fun! So, this WSJ debacle made me think about policies and enforcement; thus a new poll:

Will you break a security policy if you know it is neither enforced nor monitored AND that there can be no repercussions whatsoever (and YOU personally don't think it is sensible - EVEN THOUGH you might not be an authority on all risks ...)?

Here is the poll on that! Vote away!!!

Hello, Mr Darwin!

"Hello, Mr Darwin!" - "Hi there."

IT user "gene pool" will probably lose some of its stupidest critters as a result of reading this WSJ article, which is making round in the security community: "Ten Things Your IT Department Won't Tell You."

It starts like fun for some and like utter nightmare for others: "we use our office PCs to keep up with our lives. We do birthday shopping, check out funny clips on YouTube and catch up with friends by email or instant message."

Niiiice. It gets better:

"There's only one problem with what we're doing: Our employers sometimes don't like it." :-) Geee, I guess "some-other-times" they do :-)

OK, great, now what? This:

"To find out whether it's possible to get around the IT departments, we asked Web experts for some advice. [...] How to surf to blocked sites without leaving any traces, for instance, or carry on instant-message chats without having to download software."

And then it all rolls neatly downhill from there; check out such fun items as "6. HOW TO STORE WORK FILES ONLINE" (A "no-brainer" (indeed you are...): "Use an online-storage service") and "8. HOW TO ACCESS YOUR WORK EMAIL REMOTELY WHEN YOUR COMPANY WON'T SPRING FOR A BLACKBERRY" (Wonder how? Eeeeeasy: "Just set up your work email so that all your emails get forwarded to your personal email account." :-)). Even such gems as "7. HOW TO KEEP YOUR PRIVACY WHEN USING WEB EMAIL" (answer: encrypt it!) are there.

But you know what? There is nothing wrong with publishing this; such violations are clearly not rocket science. In fact, there are three possible outcomes:

1. Users do this and are caught, then fined, fired, tortured, shot and otherwise abused. Awesome! :-)
2. Users do this and are NOT caught since you don't really enforce your policy banning such activities. In fact, you - the security pro - don't even know that they are breaking the rules. Sorry, you suck! You need to get another job before your company is sued ...
3. Users do this and are NOT caught since they manage to bypass the deployed security controls. Ah, this is a fun one; that is what makes security a "calling, not just a job" for so many. Go back and deploy, tune, log (yes, logging all such activities is important, especially when HR wakes up and swings the ax...) and have fun. 0days and mafia hackers might be more challenging to fight, but users are surely more numerous :-)
   

Overall, I expect more security bloggers to jump and dropkick this paper. Let the fun begin!

Worm vs Thief: Take Your Pick

At a recent security conference (as many mentioned, presentations are not even half the value of such events!), I had this eye-opening chat with a guy who manages security at a large "natural resource extraction" company (to avoid specifics ...). The conversation moved towards "data security" vs "IT infrastructure security," which I always thought to be a somewhat artificial distinction (they are kinda the same since the sole purpose of IT infrastructure is to process and move data around). However, for this guy the difference was very real; in fact, he said: "I'd rather have all my critical systems fell to a worm than have the details of my mining process stolen and possibly disclosed! We will go out of business the next year." I argued that surely his company has more assets and "crown jewels" than that, but he explained that there are key pieces that, if purposefully stolen, will cause the worst case scenario to manifest ...

This doesn't sound like a super-deep insight, but it is! Days of people shaking in their boots while thinking of the next ILOVERYOU and Slammer are over. Even though anti-malware defenses aren't perfect and worms are not truly dead (although less relevant), it seems that the threat can be considered manageable rather than overwhelming. Notice that "manageable" is not the same as "gone" or "non-existent."

However, data theft is very real, and that is what makes security managers of today shake in their boots (and those who don't - MUST! :-)): having your very key data stolen, sold, possibly disclosed and you - the guardian of such data! - not even knowing how and by whom. We can blab about how hard data classification and sensitive information discovery are, but just do this simple exercise (and consult with your peers, if unsure): theft of which piece of data will make your company go away?! Afterwards, go to the system where such data resides and make pretty darn certain that you log every tiny "fart" :-) that such system and all of its components produce ... You'd be glad you did - your employer's future and thus your job may depend on it!

Possibly related posts:

• Fun Insights from "Missing Mike" :-)

• Data-at-Rest, Data-in-Motion AND Data-in-Use?

Technorati tags: security, data protection, logging, log management