March 11, 2008
We are frantically preparing for the SOURCE Boston conference which starts tomorrow morning.
You can keep track of the happenings via Twitter. It’s pretty interesting how this Twitter thing is taking off. I will try to update my feed (@zrlram) regularly over the next days so you can keep track of what’s going on.
There are a lot of other Security Twits here who hopefully keep their feeds up to date. I am sure @mediaphyter (Jennifer Leggio) is keeping her feed current with the latest gossip. Careful though, she is not always saying the truth 😉
March 9, 2007
I just returned from a hearty breakfast on the 22nd floor of my hotel, overlooking Frankfurt. Great hotel, great views! I was flipping through the pages of the ISSA journal. I haven’t really posted any article reviews in a long time. I got too frustrated, I guess. There is this article, I just can’t resist but making two quick comments. The article was posted in the January 2007 issue and is about managing passwords. The first thing that hit me is that this author actually gives us two email addresses in the “About the Author” box. Why would I need two addresses? Isn’t one enough? Anyways. Sorry. What I was really confused about is that the author talks, in the very first paragraph, about:
“I cannot wait for the day when my PC offers two-factor authentication. -snip- I can’t begin to quantify the convenience that will come from having to convince just my PC that I am who I say I am, and then letting it handle the task of convincing the myriad financial institutions, -snip- that I am who I say I am.”
Wow. Maybe the author should read up on two-factor authentication and the topic of single sign on. They are not the same. And believe me, two-factor authentication is not going to ease your life! It’s one more form of authentication. How can that be easier than two? But again. Single Sign On is not two-factor authentication. It’s a fairly big step between two-factor authentication and single sign on! And I am not sure whether I really want that. Topic attack surface!
March 4, 2007
I am reading a lot of papers again and I keep finding research which just doesn’t get it. Or at least they are not capable of cleanly communicating the research. If you are doing research on visualization, do that. Don’t get into topics you don’t know anything about. Don’t get into common event formats for example! Make assumptions. Let experts in that field make a call. Let them figure some things out. You can say what you did to overcome your challenge, but don’t – please don’t – mention those things as a contribution of your work. It actually does two things to your research: First it distracts people from what you really did, and second, it misleads others that are not experts in that field to believe that you have a viable solution. So, visualization is visualization and not log normalization!
January 7, 2007
I read a lot of research papers and security articles. I am getting so tired seeing all these tools, research papers, and new algorithms that propose new approaches in computer security and then as a proof, they are solving one of the “old” problems: Detecting worms, portscans and finding peer-to peer traffic. Guys, it’s been done. We don’t need any more tools to do it. It’s easy and nothing to show off with!
Show me that other use-cases can be solved with your new approch. That will not only tell me that you actually thought about the problem space, but it will help the security community at large to tackle new problems (maybe some that they were not even aware of)!
January 5, 2007
Are you one of those people who read the ISSA articles by first checking out the title and then the little bio about the author, posted at the end of the article? I am! What is funny to me is that the acronyms after the name are getting more and more. Is there a list of accepted certification acronyms? What do you put there? Does everyone really know what they mean? And is more better?
The best one I have seen is RSA. What’s that? Is this guy certified in public key crypto? Can he do it in his head? Is he certified in RSA secure IDs? What is it? No idea. Is it really cool to put a CCNA and MCSE certification after your name? I would almost be ashamed 😉 I keep wondering whether more certifications is really better. To be honest, when I get resumes, I am a bit alarmed if someone has too many certifications. Doesn’t that mean that the person spends more time on certifications than doing real work? I’d rather have someone who knows his stuff hands-on than through certifications. But that’s just me.
October 2, 2006
I just came accross this review on DefCon presentations. Is published on unixreview.com. I don’t know the author, but I certainly like what she had to say about my presentation:
I’ll begin with Afterglow, by Raffael Marty, which is a visual log analysis tool. Martyýs tool runs either via Perl or Java and does some cool stuff by making text log files into understandable graphs. This type of tool can help you truly understand the big picture of what your logs are telling you without making you go cross-eyed trying to read them all. This was the second year Marty has discussed this tool, and I was very impressed by his dedication to this work.
There is actually another person out there who wrote a summary of DefCon 13 (so last year) and put some graphs online. I am impressed 😉
August 31, 2006
The article starts out fairly okay and then starts talking about how IPSs (intrusion prevention systems) can help with PCI compliance:
- The first point the author makes it that you should protect your infrastructure with “… Stateful Firewall Technology”. Stateful! That’s important! What about just one word about layer 7 firewalls? Content filtering? The author somehow misses that aspect completely.
- “Stopping malicious content [by protocol verfication]”. So how can an attack be stopped by doing “protocol verification”? If I do an application-level attack against an SAP system, that will totally comply with all the protocol specifications that you can find in all the RFCs out there!
- By the way, an IPS should also do: “… real-time threat assessment of millions of IP addresses”. I wonder how they do that. Givef the context an IPS really has. I prefer my SIM do that. I don’t really think an IPS is capable of that. Maybe the author would care to elaborate on that a bit more. That would be really interesting.
- The last thing that strikes me: “IPS solutions … are the heart of maintaining the highest level of protection for PCI-dependent organizations…” What about using effective access control or vulnerability management? Why is the lower level of PCI compliance based completely on vulnerability management if IPS technology really helps you to be PCI compliant? Strange.
It seems to me that all these articles in the ISSA journal are written for just one purpose: VENDOR PITCHES! But maybe that’s just me. Fully-Verified is our favourite KYC company since it generally takes care of most of our problems before we even know they’re problems, but I guesss “all in one” companies aren’t always as specialized as some of these.
Finally I am travelling again. This also means that I have some time to read through the stack of security magazines that are piling up on my desk. It was getting a bit scary to think about reading through all these magazines. But somehow I was looking forward to the ISSA magazine. I kind of new that there would be something to critizise… And here we go:
There is an article in the June 2006 issue about “Denial of Service Attacks: Should it Mean Denial of Service?” I guess it is due to the fact that I am not a native English speaker, but this title does not really make sense to me.
Anyways. Let’s see what we can learn about DoS attacks. The first thing that stroke me is that the author mentions that
“… how firewalls help prevent denial of service under DoS/DDoS attacks”. I guess it depends on how someone defines DoS (which the author does later in the article), but in general a resource consumption DoS (don’t ditch me for not using correct DoS categories, I quite frankly have not seen a good taxonomy that I could reference) cannot be stopped by a firewall. Never! Unless you deploy it on an ISP level, but that’s a whole different story. And even if you talk about other DoS attacks which attack specific services and kill them (by for example exploiting some vulnerability), how do you make sure that you block the attack and not legitimate customers? I guess I am moving way too fast, the author promises to give us an answer in the article. Unfortunately he really fails to do so. He mentions packet filters at some point, but does not at all tell us how he would really mitigate a DoS attack. Bummer.
Did I just say that I had no real taxonomy for DoS attacks ready? Well, the author fills that gap right away. But be warned. I don’t like the taxonomy at all. Actually, this gets me going off topic. But have you every read up on taxonomies and how they are defined? Do it. It’s really interesting. Please, don’t call your attempt to come up with some kind of a categorization a taxonomy. It’s plain wrong! A taxonomy is a beautiful mathematical construct that has certain well-defined properties! Honor that fact! Please! What we have here is definitely no taxonomy, but let’s leave it at that.
The first category the author mentions is by traffic type. “Legitimate traffic flood” – okay. I like that. But! The examples given don’t fall into this category at all: UDP floods – okay. Maybe. What’s the last time you have seen an application using UDP? I thought we were in the age of Web2.0? Then ICMP floods. Hmm… Since when are your applications running over ICMP? Interesting. Maybe Kaminski is tunneling something again *gins*. Certainly no legitimate traffic! Then SYN floods. Okay. If we stretch legitimate traffic, that might be okay. Why don’t you just mention someone with a huge pipe making legitimate Web requests on your Web application? That would do it!
The next Traffic Type the author mentions is “Malicious traffic flood”. Why is this defined as “These packets carry malicious content and may be self-propagating.” Interesting. The packets are self-propagating? Like source-routed? Just kidding.
Next category: I love the title: “Attack Intent”. How do you possibly know what the intent of an attack is? Maybe I am just playing around and hit you by accident. How does that traffic look different from a targeted attack? So you know what my intent was? I doubt it! Anyways; here comes the same entry again that we just had: “Bandwidth depletion” how is that different from traffic floods? And why would smurf-attacks, fraggles, UDP floods (note that we already had this example in another category) and ping floods. Somehow I don’t really need any of these “sophisticated” attacks to consume all your bandwidth.
Here goes another nice one: Category: “Exploitation Type”: Network-based. Hmm… “These attacks exploit the limitations of the network under attack and can be controlled by the use of firewalls…” Really? How come you can still accept legitimate traffic if your uplink is saturated? And then: “NAT techniques can be used to isolate and secure corporate internal networks”. How does that have anything to do with DoS attacks? Wow…
Makes me curious how the author is going to talk about the “DoS Attacks in Detail”. It’s going to be fun, I bet!
The first pretty interesting statemenet about the details is who launches DoS attacks: “… irresponsible, unethical people with destructive intentions.” Really? Have you heard of commercial interests? Irresponsible? Why? Unethical? Maybe. But let’s move on. “The goal of the attackers is to exploit vulnerabilities in victim systems …” What? Why would that be the goal? The goal would be to rob someone of the ability to conduct business. Or to use his resources.
We are slowly getting down in the protocol stack to talk about the really important details. The networking details of the attack. That’s going to be fun! First clue that the author really knows his networking: “The attacker typically employs TCP, UDP or ICMP protocols to launch the attack”. On the transport layer, what other protocols have you used lately? I don’t know many more…
“ICMP Unreachable Flood”: Maybe the author should read up on this again. Why would I flood someone with ICMP unreachable messages (by the way, did you know there were two types of unreachables? Host and Port?) And why would I spoof the source IP? Did you mean I send spoofed UDP packets to closed ports and the spoofed source address is the one of the victim? Try that!
Hang in there, the best is still to come!
“This instructs the routers to send the messages to all IP addresses”. Do you know how broadcast works? Yes? How many packets are sent if I want to send something to all 254 hosts of a C class? One! All machines are instructed to read the packtes! There are NOT 254 (and certainly not 255) packets!
But here comes the gem: Under Fraggle Attacks: “It is different from smurf attacks in that the packets are UDP ECHO packets instead of ICMP ECHO packets.” Do you find the mistake? UDP ECHO? Wow. Where did you acquire your TCP/IP skills? Especially the fact that the author mentions the chargen attack as a specific item. That’s the same my friend. It’s UDP packets, but they are going to the chargen/echo service…
“PUSH+ACK attacks”. What? This is getting better and better. Maybe I should read Stevenson’s books again. Gosh. Has anyone tried what the author suggests about hijacking sessions and stuff? I don’t think he has heard of TCP sequence numbers and issues like that. Uiuiui… The same problem with “TCP reset floods”!
And talking about “Ping of Death and ECHO/Chargen” attacks in 2006 is kind of interesting. Okay. I heard that Vista was vulnerable to the PoD attack; But a Chargen attack? Dude, in what century do you live?
Here comes the attack for 2006: “Packet Header Scrambling”. The author suggests to set all the QoS bits. Hmm… Interesting. Have you tried this?
I really advise the authors to do some more research before they write about a certian topic and even more so the magazines should not accept every article they get. Has anyone proof-read this before it was published?
I thought that was it, but the article continues with suggestions on countermeasures…
Maybe there are some interesting methods mentioned here. I love this countermeasure: “MIB Statistics”. How the heck is this a countermeasure? Oh sorry, it’s under the topic of ‘prevention of seconday victims’. Right!
Mitigation of DoS attacks via Load Balancing? Throttling? Dropping requests? Auch… Again, maybe on the ISP level.
“Other Measures”: Honeypots! Interesting. So HoneyPots as a countermeasure to DoS attacks. Why not. But how? Well, by doing traffic analysis (isn’t that too late already?) or by packet tracing (at least you know what IP attacked you) or by replaying traffic (to generate some more load on my systems?)
And if you should not know what an IDS is: “Intrusion Detection/Prevention systems are configured to baseline regular traffic and detect anomalies based off the normal traffic flow”. I really wish they did! Wouldn’t that be nice! And which IDS does that?
July 23, 2006
It’s done. I was working on writing a chapter for the new Snort book. I got the chapter on data analysis assigned. These things take time. It was fun writing it though. It forced me to look into some tools that are quite interesting. OpenSIMs and OSSIM are two of them. They are not quite as mature as I was hoping they would be. Well, somehow I guess I knew they wouldn’t be. They are great starting points for a SIM though. Maybe they should just combine the two projects.
Another project that I found was interesting is SEC. The Simple Event Correlator. I have looked at this tool before, but this time I have to say, I am quite impressed. The correlation capabilities are quite interesting. There is one huge problem, which is that you have to define the matching log entry for every rule. This just doesn’t scale. You need to have a normalization module first and then you apply the correlation on the normalized data. And by normalized I mean parsed and categorized! And that’s one of the other huge problems: Categorization is not standardized and it takes a huge amount of work to do it yourself. Believe me, I know what it means to categorize. We have a database of aobut 150.000 events that we categorized…
Anyways. The chapter is written and hopefully I can spend some more time again on the other writing projects I have lined up. But first it’s going to be travel and conference month! BlackHat is close!
May 23, 2006
I haven’t done any of these reviews in a while. I guess I haven’t been travelling much lately. Anyways. I came accross this article on Insider Threat by Ronald Mendell. I am not sure the author really understands the insider threat problem. Let me give you my perspective:
The author suggests that the primary line of defense against insider threat is using countermeasures based on specific responses to particular threats. That’s a mouth-full, isn’t it? He continues by saying that you should follow a recognized standard like ISO 17799 or a checklist to identify needed safeguards. Well, first of all, you can follow a lot of checklists and implement a security program based on ISO 17799 and still have tons of insider problems. Insiders do not use common attack vectors that can be revealed with following standard approached. That’s the core problem! [Note that I am not saying that you shouldn’t use a checklist, but it does not help much against your insider problem!]
Well, I would be a bad commentator if I was not offering another approach. If the author spent some time reading research in this area, he would have found a study by Mitre which suggests that most of the insiders can be detected while they do reconnaissance! Think about it. Someone who wants to abuse his privileges is not going to sound all the bells and whistles of your security controls, but he might go off and do some reconnaissance or start behaving abnormal! I am not going into details on how you could actually monitor these things, but you can imagine how (just look at the company I work for 😉
I also don’t see the point the author tries to make with his very lengthy bat-script example. He describes how someone builds a bat script on windows to collect certain information via different commands, such as the net command. He claims that the problem is that people can build bat scripts on their boxes. That’s completely wrong. The problem is that this user had privileges to execute the net command.
The article continues with giving a checklist of things to do to detect insiders. Actually it’s more a checklist that would prevent insiders from being successful. I couldn’t disagree more with the checklist. The things mentioned are good security practices, but do not help at all in preventing insider abuse. For example, the author urges people to block null sessions by filtering port 139/tcp and 445/udp traffic. First of all, it is exactly the other way around: 139/udp and 445/tcp. Second, where do you filter that? Between zones? That’s not going to help. If I am on the same LAN, I can still access other machines. If you turn it off on the end-systems, you won’t be able to share files among machines anymore. The only thing you really want to do is disabling anonymous connections and disable all default accounts, etc. And why would having a UNIX shell (which by the way is not how I would call a cygwin session) on a Windows machine is bad and needs to be turned off?! That’s hardly the problem. Does the author actually know what a UNIX shell is and what that means on a Windows box? Just because I might be able to write more powerful shell scripts (Is this even true? I bet bat scripts are pretty powerful too!), but that does not give me more control over what I am after…
Then again, the author mentions that users learn the vulnerabilities of the network or system and exploit them. Well, that might be a problem, but barely one that pertains to the insider threat problem! insiders don’t need vulnerabilities. Or do you think the CFO is going to exploit a vulnerability to get to confidential financial records? No dude, he already has legitimate access to them. The problem is if the CFO starts printing these things and takes them places! That’s what you are after! You gotta start to think differently!
Think profiling, think abnormal behavior, think watch-lists, think roles. That’s all I have to say!
