TaoSecurity Blog

This one's in my wheelhouse, but details are sketchy. So far the best simple article is New attacks reveal fundamental problems with TCP by Dennis Fisher. Nick Weaver's Slashdot comment provides the best technical explanation of one of the attack vectors, I think: The observation: You can use a SYN-cookie like trick on the client side as well for an attacker: You send SYNs where the initial seq # = H(sip, dip, sport, dport). Now when you get a SYN/ACK back, you can send the ACK to complete the handshake. You can use the ACK field back from the server to know where you are in what data to send (just subtract the value from the initial sequence # to know what the next piece of data to send is), and you can know where you are in the received data (if necessary) by storing just the server's initial sequence #. As a result, you can now interact with the server without having to maintain ANY TCP session state, or just a single word (the server's initial seq #), allowing t...

Previously I posted Wanted: Incident Handler with Reverse Engineering/Malware Analysis Skills . That article noted our GE Careers job posting (843369). We received several great candidates with reverse engineering and malware skills, but none in Cincinnati. Therefore, I am shuffling the positions a bit. The RE/malware person does not need to reside in Cincinnati, but now I need a different incident handler definitely located in Cincinnati. The incident handler in Cincinnati should meet the following requirements. Strong incident handling skills. I want this person to be able to speak authoritatively and confidently when dealing with internal business partners. (This is not a job supporting external customers.) Strong mentoring skills. This candidate will interact daily with our Command Center personnel. The Command Center will be the 24x7 component of our Incident Response Center. This incident handler will need to be a mentor and coach for the Command Center analysts, although...

My 19th Snort Report titled Using SnortSP and Snort 2.8.2 has been posted. From the article: Solution provider takeaway: Solution providers will learn how to set up two Snort 3.0 beta components -- the Snort Security Platform (SnortSP) and the Snort 2.8.2 detection engine on the SnortSP. In the last Snort Report , I discussed the architectural basics of Snort 3.0. The new Snort system consists of the Snort Security Platform (SnortSP) plus an assortment of engines. SnortSP is a foundation that provides traffic-inspection functions, like packet acquisition, traffic decoding, flow management and fragment reassembly. Each engine runs as a module on SnortSP. The first available module is a port of Snort 2.8.2 specifically for running on top of SnortSP. I can never tell when SearchSecurity will post these articles... this one is dated 5 Sep but I just noticed it online.

Recently a group of managers at work asked me to explain why I blog. This is a very good question, because the answer might not be intuitively obvious. Perhaps by sharing my rationale here, I might encourage others to blog as well. Blogging organizes thoughts. Recently I nodded in agreement when I heard a prolific author explain why he writes. He said the primary purpose for writing his latest book was to organize his thoughts on a certain topic. Writing an entire book is too much for most of us, but consolidating your ideas into a coherent statement is usually sufficient. Blogging captures and shares thoughts. Once your thoughts are recorded in electronic form, you can refer to them and point others to them. If I am asked for an opinion, I can often point to a previous blog post. If the question is interesting enough, I might write a new post. That satisfies this reason and the previous one. Blogging facilitates public self-expression. This is a positive aspect of the modern...

Another reader asked me this question, so I thought I might share it with you: I'm really struggling with... how to communicate risk and adequate controls to the business managers at my employer... To put it bluntly, this is the first time the company has really looked at it [security] at all and they don't really want to deal with it. They have to because of the business we are in though... So while I've got a blazing good example of what doesn't work, I still don't know what does. What are some good resources that you have found in communicating security (or other) risks to business? Are there books, blogs or authors that you would recommend? I've written about this problem in the past, in posts like Disaster Stories Help Envisage Risks and Analog Security is Threat-Centric . I'll be speaking about this problem in my SANS Forensics Summit keynote next month, with the theme of "speaking truth to power." Throughout my career, I've found f...

A long-time blog reader pointed me towards this Computerworld article Making enemies, but needing allies . I must absolutely emphasize that this story is not me, nor does it reflect issues I have. However, my blog reader asked me specifically to ask if any of you share this problem, and if yes, how do you handle it? Our fledgling security organization is starting to run into some significant relationship challenges. As we're beginning to build our information security program from scratch, we're causing some friction. In my company, information security is part of the IT department, but like several other IT disciplines, it reports directly to the CIO. As a result, the infosec and IT support teams are peers, a relationship as uneasy as that of siblings. Over the past couple of weeks, tensions between our teams have been rising sharply ... As we try to bring security to an acceptable level, we are introducing new policies and standards that are being met with hostility by the...

Last week I attended VizSec 2008 and RAID 2008 . I'd like to share a few thoughts about each event. I applaud the conference organizers for scheduling these conferences in the same city, back-to-back. That decision undoubtedly improved attendance and helped justify my trip. Thank you to John Goodall for inviting me to join the VizSec program committee. I enjoyed the VizSec keynote by Treemap inventor Ben Shneiderman. I liked attending a non-security talk that had security implications. Sometimes I focus so strictly on security issues that I miss the wider computing field and opportunities to see what non-security peers are developing. I must admit that I did not pay as much attention to the series of speakers that followed Prof Shneiderman as I would have liked. Taking advantage of the site's wireless network, I was connected to work the entire day doing incident handling. I did manage to speak with Raffy Marty during lunch, which was (as always) enlightening. One t...