Friday, August 31, 2007
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" :-)
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.
- 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,
- 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"
- 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!)
- 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)!
- 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.
- 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 :-)
Thursday, August 30, 2007
Blogging frenzy mode = off :-)
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 ...)
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)"
- "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)"
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:
- 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
- User=100%, IT, infosec=0% Result: trivial case, obvious failure
- Then it gets real complex real fast for the cases of shared responsibility ...
UPDATE: AndyIT answers it - "Probably something like Security=85%, IT=10% and Users=5%." See more of his follow-up post here.
Wednesday, August 29, 2007
Monday, August 27, 2007
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:
First, why look at proxy logs? Apart from my overall answer that applies to all logs, proxy-specific reasons are the following:
- Review users’ activities on the web (not just surfing!)
- Monitor applications' HTTP activity
- Detect Web-enabled malware traffic
- 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:
Friday, August 24, 2007
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 :-)
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.
Security implications anybody? :-)
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!
Thursday, August 23, 2007
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.
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"
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! :-)
Wednesday, August 22, 2007
Tuesday, August 21, 2007
"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"
Monday, August 20, 2007
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."
Thursday, August 16, 2007
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.
Wednesday, August 15, 2007
Ha-ha-haaaaaa. Ha-ha-ha! Haaaa :-)
Tuesday, August 14, 2007
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 ...?
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.
Monday, August 13, 2007
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
Friday, August 10, 2007
Thursday, August 09, 2007
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?
Wednesday, August 08, 2007
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:
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:
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.'
|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.
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.
Monday, August 06, 2007
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)
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):
- 1124376766.026 RELEASE -1 FFFFFFFF 4734C557F9315105CA6BE0FA56B94D55 200 1124276674 -1 -1 unknown -1/0 POST http://reports.hotbar.com/reports/hotbar/4.0/HbRpt.dll
- 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
- 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 - -
- 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:
Friday, August 03, 2007
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!!!
Wednesday, August 01, 2007
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:
- Users do this and are caught, then fined, fired, tortured, shot and otherwise abused. Awesome! :-)
- 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 ...
- 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 :-)
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: