Research

On the surface endpoint encryption is pretty straightforward these days (WAY better than when I first covered it 8 years ago), but when you start matching all the options to your requirements it can be a tad confusing. I like to break things out into some simple categories/use cases when I’m helping people figure out the best approach. While this could end up as one of those huge blog posts that ends up as a whitepaper, for today I’ll stick with the basics. Here are the major endpoint encryption options and the most common use cases for them: Full Drive Encryption (FDE): To protect data when you lose a laptop/desktop (but usually laptop). Your system boots up to a mini-operating system where you authenticate, then the rest of the drive is decrypted/encrypted on the fly as you use it. There are a ton of options, including McAfee, CheckPoint, WinMagic, Utimaco, GuardianEdge, PGP, BitArmor, BitLocker, TrueCrypt, and SafeNet. Partial Drive Encryption: To protect data when you lose a laptop/desktop. Similar to whole drive, with some differences for dealing with system updates and such. There’s only one vendor doing this today (Credent), and the effect is equivalent to FDE except in limited circumstances. Volume/Home Directory Encryption: For protecting all of a user’s or group’s data on a shared system. Either the users home directory or a specific volume is encrypted. Offers some of the protection of FDE, but there is a greater chance data may end up in shared spaces and be potentially recovered. FileVault and TrueCrypt are examples. Media Encryption: For encrypting an entire CD, memory stick, etc. Most of the FDE vendors support this. File/Folder Encryption: To protect data on a shared system- including protecting sensitive data from administrators. FDE and file folder encryption are not mutually exclusive- FDE protects against physical loss, while file/folder protects against other individuals with access to a system. Imagine the CEO with an encrypted laptop that still wants to protect the financials from a system administrator. Also useful for encrypting a folder on a shared drive. Again, a ton of options, including PGP (and the free GPG), WinMagic, Utimaco, PKWare, SafeNet, McAfee, WinZip, and many of the other FDE vendors (I just listed the ones I know for sure). Distributed Encryption: This is a special form of file/folder encryption where keys are centrally managed with the encryption engine distributed. It’s used to encrypt files/folders for groups or individuals that move around different systems. There are a bunch of different technical approaches, but basically as long as the product is on the system you are using, and has access to the central server, you don’t need to manually manage keys. Ideally, to encrypt you can right-click the file and select the group/key you’d like to use (or this is handled transparently). Options include Vormetric, BitArmor, PGP, Utimaco, and WinMagic (I think some others are adding it). Email Encryption: To encrypt email messages and attachments. A ton of vendors that are fodder for another post. Hardware Encrypted Drives: Keys are managed by software, and the drive is encrypted using special hardware built-in. The equivalent of FDE with slightly better performance (unless you are using it in a high-activity environment) and better security. Downside is cost, and I only recommend it for high security situations until prices (including the software) drop to what you’d pay for software. Seagate is first out of the gate, with laptop, portable, and full size options. Here’s how I break out my advice: If you have a laptop, use FDE. If you want to protect files locally from admins or other users, add file/folder. Ideally you want to use the same vendor for both, although there are free/open source options depending on your platform (for those of you on a budget). If you exchange stuff using portable media, encrypt it, preferably using the same tool as the two above. If you are in an enterprise and exchange a lot of sensitive data, especially on things like group projects, use distributed encryption over regular file/folder. It will save a ton of headaches. There aren’t free options, so this is really an enterprise-only thing. Email encryption is a separate beast- odds are you won’t link it to your other encryption efforts (yet) but this will likely change in the next couple years. Enterprise options are linked up on the email server vs. handling it all on the client, thus why you may manage it separately. I generally recommend keeping it simple- FDE is pretty much mandatory, but many of you don’t quite need file/folder yet. Email is really nice to have, but for a single user you are often better off with a free option since the commercial advantages mostly come into play on the server. Personally I used to use FileVault on my Mac for home directory encryption, and GPG for email. I then temporarily switched to a beta of PGP for whole drive encryption (and everything else; but as a single user the mail.app plugin worked better than the service option). My license expired and my drive decrypted, so I’m starting to look at other options (PGP worked very well, but I prefer a perpetual license; odds are I will end up back on it since there aren’t many Mac options for FDE- just them, CheckPoint, and WinMagic if you have a Seagate encrypting drive). FileVault worked well for a while, but I did encounter some problems during a system migration and we still get problem reports on our earlier blog entry about it. Oh- and don’t forget about the Three Laws. And if there were products I missed, please drop them in the comments. Share:

Yesterday, Adrian posted his take on a conversation we had last week. We were headed over to happy hour, talking about the usual dribble us analyst types get all hot and bothered about, when he dropped the bombshell that one of our favorite groups of products could be in serious trouble. For the record, we hadn’t started happy hour yet. Although everyone on the vendor side is challenged with such a screwed up economy, I believe the forces affecting the database security market place it in particular jeopardy. This bothers me, because I consider these to be some of the highest value tools in our information-centric security arsenal. Since I’m about to head off to San Diego for a Jimmy Buffett concert, I’ll try and keep this concise. Database security is more a collection of markets and tools than a single market. We have encryption, Database Activity Monitoring, vulnerability assessment, data masking, and a few other pieces. Each of these bits has different buying cycles, and in some cases, different buying centers. Users aren’t happy with the complexity, yet when they go shopping the tend to want to put their own car together (due to internal issues) than buy the full product. Buying cycles are long and complex due to the mix of database and security. Average cycles are 9-12 months for many products, unless there’s a short term compliance mandate. Long cycles are hard to manage in a tight economy. It isn’t a threat driven market. Sure, the threats are bad, but as I’ve talked about before they don’t keep people from checking their email or playing solitaire, thus they are perceived as less. The tools are too technical. I’m sorry to my friends on the vendor side, but most of the tools are very technical and take a lot of training. These aren’t drop in boxes, and that’s another reason buying cycles are long. I’ve been talking with some people who have gone through vendor product training in the last 6 months, and they all said the tools required DBA skills, but not many on the security side have them. They are compliance driven, but not compliance mandated. These tools can seriously help with a plethora of compliance initiatives, but there is rarely a checkbox requiring them. Going back to my economics post, if you don’t hit that checkbox or clearly save money, getting a sale will be rough. Big vendors want to own the market, and think they have the pieces. Oracle and IBM have clearly stepped into the space, even when products aren’t as directly competitive (or capable) as the smaller vendors. Better or not, as we continue to drive towards “good enough” many clients will stop with their big vendor first (especially since the DBAs are so familiar with the product line). There are more short-term acquisition targets than acquirers. The Symantecs and McAfees of the world aren’t looking too strongly at the database security market, mostly leaving the database vendors themselves. Only IBM seems to be pursuing any sort of acquisition strategy. Oracle is building their own, and we haven’t heard much in this area out of Microsoft. Sybase is partnered with a company that seems to be exiting the market, and none of the other database companies are worth talking about. The database tools vendors have hovered around this area, but outside of data masking (which they do themselves) don’t seem overly interested. It’s all down to the numbers and investor patience. Few of the startups are in the black yet, and some have fairly large amounts of investment behind them. If run rates are too high, and sales cycles too low, I won’t be surprised to see some companies dumped below their value. IPLocks, for example, didn’t sell for nearly it’s value (based on the numbers alone, I’m not even talking product). There are a few ways to navigate through this, and the companies that haven’t aggressively adjusted their strategies in the past few weeks are headed for trouble. I’m not kidding, I really hated writing this post. This isn’t a “X is Dead” stir the pot kind of thing, but a concern that one of the most important linchpins of information centric security is in probable trouble. To use Adrian’s words: But the evolutionary cycle coincides with a very nasty economic downturn, which will be long enough that venture investment will probably not be available to bail out those who cannot maintain profitability. Those that earn most of their revenue from other products or services may be immune, but the DB Security vendors who are not yet profitable are candidates for acquisition under semi-controlled circumstances, fire-sale or bankruptcy, depending upon how and when they act. Share:

There was some great hype in the wireless security world this weekend thanks to an article that made it on to Slashdot, and some FUD pumping so-called security consultants. Elcomsoft issued a press release that they can now crack WPA keys WAY faster using the GPUs (Graphics Processing Units) on the latest video cards. It’s kind of cool, and for wireless pen testing the tool sounds useful, but some of the quotes in the article from the security firm GSS (who I never heard of) are the typical garbage: “This breakthrough in brute force decryption of Wi-Fi signals by Elcomsoft confirms our observations that firms can no longer rely on standards-based security to protect their data,” said GSS managing director David Hobson. “As a result, we now advise clients using Wi-Fi in their offices to move on up to a VPN encryption system as well.” … Hobson added that the development could spur a step back from wireless to wired network connection in sensitive installation, such as financial services organisations, particularly concerned about data privacy. Idiots. These guys are forgetting two things- first, this method doesn’t work AT ALL against an enterprise installation (RADIUS) of WPA. George Ou has more on this. Second, as the original article added as an update, this attack only speeds up brute forcing. Use a long, strong passphrase for your WPA key and you’re fine. Rob Graham also has more on this. WPA-PSK still sucks to manage, and keys go stale, but use a good one and you’re fine. GCC should go back to playing Team Fortress or something with those video cards, because they were either misquoted, or clueless. Share:

What a wild, wacky, crazy week. I have a funny suspicion a lot of stock brokers and investors are scraping together their spare change for some major liquid escapes this weekend. As a small business we haven’t felt the impact yet, but we are keeping a close eye on things and preparing to adjust our strategy as needed. Security deals are definitely slowing- we sense an impending rush of acquisitions, and a general feeling of nervousness. The need for security never goes away, but if you aren’t making plans to protect yourself through this crisis, you might go away. Someone responded to a Twitter post of mine that this will be over before the next president takes office; I can’t possibly imagine that happening. Meanwhile, we watched the usual spectacle of the Presidential debate. Since I already know who I’m voting for, I’m not sure why I watch them at all. Like NASCAR, I suppose I don’t want to miss out when someone smashes into the wall and bursts into flames. On the security front, this week we saw more clickjacking details emerge, Apple release a security update, the World Bank get totally pwned, and Symantec make a major acquisition at a good multiple. But don’t get too excited; we also know a lot of investors pushing early exits at low multiples to save what they can. I don’t mean to focus so much on the finance side of the security world, but I think we’re going to see it bleed into our daily operations as the vendor landscape shifts around. Over here at Securosis central I continued to geek out and work on our infrastructure. We may be small, but we’re trying to set up some cool collaboration tools to support us as we grow. For you other small business types, the wiki/blog/calendar/mail group integration of OS X Server works surprisingly well, although I don’t think it would be my first choice for an external web server. I just wish it would index documents attached to the wiki. I also ordered a Drobo for our backups and I’ll let you all know how it works. Oh- and on my run yesterday I saw two coyotes in the park near our house watching me. Very cool. Webcasts, Podcasts, and Conferences: Martin and I have started broadcasting the Network Security Podcast live as we record it. In episode 123 (my luggage combination!) we talk about electronic voting, China spying, and clickjacking. If you didn’t catch it in the October print edition of Macworld, here’s the online version of the firewall article I coauthored with Chris Pepper. I wrote an article on mobile phone networks for TidBITS that made the front page of Slashdot. I think it’s about the 6th time I’ve hit the front page this year, which is pretty wacky. The TidBITS server had a massive failure unrelated to the Slashdot load right after the article was linked (oops). I was quoted over at Dark Reading on the license changes to Metasploit 3.2. I know I wrote that quote, but reading it now it comes off strangely ambiguous. For the record, I think it’s a great change that will really drive some interesting things in the pen testing software world. Adrian and I were invited by Jeremiah Grossman to a lunch event here in Phoenix with his company (WhiteHat Security) and F5. It was nice to finally get a demo of the F5/WhiteHat integration (WhiteHat generates dynamic WAF rules on the F5 box to block validated vulnerabilities; it’s pretty cool). Jeremiah also showed us his clickjacking code/demo. I almost wondered if I downplayed it too much after seeing it at work. On the bad side, some slimeballs from a local ISP decided to show up, enjoy a free lunch, and proceed to hit up every single one of us there as their personal sales prospects. I pretended I was out of business cards, but they snagged one of Adrian’s so he’ll get the call. Talk about low. Favorite Securosis Posts: Rich: Clickjacking Details, Analysis, and Advice. I tried to put some context around it, and talk about the overall impact. Direct from Rsnake is some advice on limiting the exploit. Adrian: Symantec Buys MessageLabs. Symantec pays a hefty price, but they land a leader in SaaS email security and fill out their messaging security portfolio. Favorite Outside Posts: Adrian: I had trouble naming any single post my favorite for the week. There was a most shocking, a scariest, a most depressing and a most sadly illuminating. I am going with the illuminating look into the minds of Sequoia Capital and their reactions to the current financial crisis. This should look a lot like the tech crash of 2001, and frankly, I hope this information was conveyed to their portfolio companies 9-12 months ago as the window to react has passed. Rich: Gunnar Peterson’s Innovators, Imitators, and Idiots. Just a great post that I need to blog about more fully later. Top News: The World Bank is seriously compromised. We need a new word for pwn. Apple releases a big OS X security update. Asus ships EEE PCs infected with a virus. Good job guys. ATM skimmers now include a wireless modem for SMS messages. The bad guys increase their embedded devices skills. Blog Comment of the Week: Christophe’s comment on My “Policies, Plans, and Procedures” post: Alas, I work in a former communist country where people were used to signing awful things, and hide whatever they did from upper eyes. I sure have an agreement, signed by all users, stating their responsibility, but that means almost nothing to them. Time for happy hour with some of out local financial analyst friends. Smart guys who are doing well through this mess, so we plan on getting them loaded and sucking up the advice. Share:

I don’t remember the exact quote from King of the Hill (an animated series here in the US), but it went something like this. Bobby: But how come you don’t want Luanne to go out with guys but you want me to date girls? Dad: It’s called the double standard, Bobby. Don’t knock it – we got the long end of the stick on that one. Alan Shimel clearly got the short end of the stick when his account was hacked. Heck, he got the short end of the nub, and so would pretty much all of us. Odds are high you’ve heard that the college kid that hacked Palin’s account is being indicted and could face jail time. Twitter was all aflutter yesterday with concerns that the potential punishment exceeds the crime. Personally, I believe if you break the law, you face the consequences. I also harbor no illusions that our justice system is blind. It’s clear if you mess with a popular politician, they will frack you as hard as possible, in every way possible Then bury you. Then pee on your grave. Then pee on your dog before they bury it next to you. Your family and friends? You really don’t want to think about that. And when you mess with a maverick Republican? Well, let’s better hope they can’t track down anyone that ever bothered to smile in your general direction. Had the perpetrator broke into a government account I would expect a different set of consequences. But a personal account should be treated the same as Joe Six Pack’s. Heck, Alan’s break in involved documented financial fraud, unlike Palin. Not that I think we should destroy the lives of every college kid that virtually shoplifts a virtual candy bar (punishment should suit the crime), but over-tolerance only breeds contempt. Just call me a dreamer, but as a realist I know I’m just wasting my words on this particular topic. Still, I’ve heard from businesses that unless credit cards or other hard financial losses are clearly involved it is essentially impossible to get law enforcement to take action; they just don’t have the resources. As such we need to focus on our own monitoring and incident response. If you can’t prove someone really stole your cash, you won’t get the attention of law enforcement. If you can’t give them a description, don’t expect the case to go very far. It’s really no different in the physical world. A few years ago, when I moved to Phoenix, we screwed up and left the garage door open at night. One of those silly mistakes when you think the other person took care of it. Neighborhoods are routinely cruised out here, and when I woke up and noticed it was too late. There went my road bicycle, most of my climbing gear, and, worst of all, a small pack containing my original Star Wars figures I’d saved since I was a kid and some other very personal mementos. We filled out a police report but never expected any action (no, they won’t take fingerprints if someone steals your bike), and after our deductible it wasn’t even worth filing an insurance claim. I made the rounds of the local pawn shops, but no joy. Society accepts a certain level of losses, since we don’t have the resources to continue otherwise. That doesn’t, of course, apply when something gets the press attention of the Palin hack. Sometimes it’s about the losses, and other times it’s about looking good in the press. Share:

I was catching up with Rob Newby’s blog and this post on dealing with security policies vs. standards/processes caught my eye. Although policies form the foundation for our security programs (at least they should), I find that more often than not they are completely misused by many of my clients. While I’ve noticed definite improvement over the past few years, I still often walk into organizations and see big 3 inch binders full of their security policies. Rob does a great job of breaking these out, but I’d like to take it a step further. I’m going to dig into some nitty-gritty details, but feel free to skip to the end where I tell you why none of this parsing of language matters much. Here’s how I like to divide up the world of security gove ance documentation:200810071218.jpg Policies are high-level strategic governance with executive sponsorship. Policies should be short and to the point, since those who sign off on them don’t need to know the technical details. An example might be, “we shall monitor all database activity based on the sensitivity of the data and legal or contractual requirements”. Keep in mind, that since policies should be signed off by senior management you want to keep them generic enough that you don’t have to go back to the CEO/CIO/CFO/COO every time you want to change a firewall configuration or AV product. The next layer down are the high-level tactical documentations- plans and standards. The security plan is how you intend on achieving the policy, but it’s still not at the level of specific steps. Keeping with our policy above, the plan would specify the contractual requirements, basic data classification, which activity will be monitored, and so on. While plans define how security will do things, standards define how everyone else has to do things. Below that are your specific implementation documentations- processes, guidelines, and procedures. Here’s where you get into the bitty-gritty of actual implementation and step by step guides. A process is a repeatable series of steps to achieve an objective, while procedures are the specific things you do at each of those steps. Keeping with out example above, the process would define how monitoring occurs (e.g. third party DAM tool), and the procedure is which bits to flip within the tool. Yeah, I think that’s a whole lot of paper and a huge time sink myself. Here’s a slightly more pragmatic, and somewhat repetitive, way of looking at things: Policies are still high level strategic governance with executive sponsorship; that never changes. Short and sweet since it makes it easier to get them approved, and you want o have to change them as little as possible. I don’t really care what you call below that, but you should have a security plan for implementing your policies. Plans are managed at the CISO or security director level (whoever is in charge) and change more frequently. You don’t want to have to go to the CEO to change your plans. At this layer you also have your standards- which, if you think about it, is the next layer of gove ance. CEOs sign off on policies, and CISOs sign off on standards. Below that is where you detail how the heck you’ll accomplish all this gove ance. You document processes, list our procedures, and issue guidelines and configuration standards. This stuff will change all the time, and shouldn’t necessarily need the CISO to sign off on it unless it breaks with the layer above. The simpler the better, but if you don’t write this stuff down in an organized way you’ll eventually pay the price. By breaking it down into these three main layers, you can more easily change both the minutiae and the big picture as you adapt to changing conditions. Share:

Looks like the cat is out of the bag. Someone managed to figure out the details of clickjacking and released a proof of concept against Flash. With the information out in public, Jeremiah and Robert are free to discuss it. I highly recommend you read Robert’s post, and I won’t try and replicate the content. Rather, I’d like to add a little analysis. As I’ll spell out later, this is a serious browser flaw (phishers will have a field day), but in the big picture of risk it’s only moderate. Clickjacking allows someone to place an invisible link/button below your mouse as you browse a regular page. You think you’re clicking on a regular link, but really you are clicking someplace the attacker controls that’s hidden from you. Why is this important? Because it allows the attacker to force you to interact with something without your knowledge on a page other than the one you’ve been looking at. For example, they can hide a Flash application that follows your mouse around, and when you go to click a link it starts recording audio off your microphone. We have protections in browsers to prevent someone from automatically initiating certain actions. Also, many websites rely on you manually pressing buttons for actions like transferring large sums of money out of your bank account. There are two sides to look at this exploitation- user and website owner. As a user, if you visit a malicious site (either a bad guy site, or a regular site that’s been hit with cross site scripting), the attacker can force you to take a very large range of actions. Anytime you click something, the attacker can redirect that click to the destination of their choice in the context of you as a user. That’s the important part here- it’s like cross site request forgery (really, an enhancement of it) that not only gets you to click, but to execute actions as yourself. That’s why they can get you to approve Flash applications you might not normally allow, or to perform actions on other sites in the background. As with CSRF, if you are logged in someplace the attacker can now do whatever the heck they want as long as they know the XY coordinates of what they want you to click. As a website owner, clickjacking destroys yet more browser trust. When designing web applications (which used to be my job) we often rely on site elements that require manual mouse clicks to submit forms and such. As Robert (Rsnake) explains in his post, with clickjacking an attacker can circumvent nonces (a random code added to every form so the website knows you clicked submit from that page, and didn’t just try to submit the form without visiting the page, a common attack technique). Clickjacking can be used to do a lot of different things- launching Flash or CSRF are only the tip of the iceberg. It relies heavily on iFrames, which are so pervasive we can’t just rip them out. Sure, I turn them off in my browser, but the economics prevent us from doing that on a wide scale (especially since all the advertisers- e.g. Google/Yahoo/MS, will likely fight it). Clickjacking is very difficult to eliminate, although we can reduce its risk under certain circumstances. Because it doesn’t even rely on JavaScript and works with CSS/DHTML, it will take a lot of time, effort, and thought to eliminate. The fixes generally break other things. After spending some time talking with Robert about it, I’d rate clickjacking as a serious web browser issue (it isn’t quite a traditional vulnerability), but only a moderate risk overall. It will be especially useful for phishers who draw unsuspecting users to their sites, or when they XSS a trusted site (which seems to be happening WAY too often). Here’s how to reduce your risk as a user: Use Firefox/NoScript and check the setting to restrict iFrames. Don’t stay logged in to sensitive sites if you are browsing around (e.g., your bank, Amazon, etc.). Use something like 1Password or RoboForm to make your life easier when you have to enter passwords. Use different browsers for different things, as I wrote about here. At a minimum, dedicate one browser just for your bank. As a website operator, you can also reduce risks: Use iFrame busting code as much as possible (yes, that’s a tall order). For major transactions, require user interaction other than a click. For example, my bank always requires a PIN no matter what. An attacker may control my click, but can’t force that PIN entry. Mangle/generate URLs. If the URL varies per transaction, the attacker won’t necessarily be able to force a click on that page. Robert lays it out: From an attacker”s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren”t met, the attack falls down. Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn’t always work). I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials. Robert and Jeremiah have been very clear that this is bad, but not world-ending. They never meant for it to get so hyped, but Adobe’s last-minute request to not release caught them off guard. I spent some time talking with Robert about this in private and kept feeling like I was falling down the rabbit hole- every time I tried to think of an easy fix, there was another problem or potential consequence, in large part because we rely on the same mechanisms as clickjacking for normal website usability. Share:

There’s been a bunch of new information coming out the past few days about the potential big TCP denial of service flaw. The three most informative posts I’ve read are: Fyodor’s discussion of either the same, or a similar issue. Richard Bejtlich’s overview. Rob Graham’s take on the potential attack. Here’s what I think you need to know: It is almost certainly real. Using this technique, and attacker with very few resources can lock up the TCP stack of the target system, potentially draining other resources, and maybe even forcing a reboot (which could trash the host OS). Anything that accepts TCP connections is vulnerable. I believe that means passive sniffing/routing is safe. The attack is obvious and traceable. Since we are using TCP and creating open connections (not UDP) it means spoofing/anonymous attacks don’t seem possible. Thus, I’d be more worried about a botnet that floods your upstream provider than this targeted attack. This is the kind of thing we should be able to filter, once our defenses are updated. In other words- a bad attack, but a moderate risk. That said, there are aspects of this that still concern me and we need to keep in mind: We don’t know if our assumptions are correct. This could be a different, and much more serious, technique. Such as something spoofable. Unlikely, but possible. Nothing says a botnet can’t use this- and thus make filtering and tracing a real pain. Imagine a botnet rotating this attack technique around to different nodes. It could support more efficient botnet attacks, that could then drop to regular flood mode if it doesn’t think the more efficient direct mode is working. We don’t know it doesn’t do something to the router infrastructure or passive monitoring. Again, unlikely based on the information released, but I’d hate to dismiss this as concerning until we know more. Until there’s some sort of fix, the Defcon network and coffee shops near universities are really going to suck. Until this is fixed, small businesses and individuals are the most likely to suffer. An enterprise might be able to detect and drop an attack like this, but individual users and small business don’t have the resources. Get ready for vendor pouncing. Share:

Yesterday, following up after recording the podcast on clickjacking, I was talking with Robert Hansen about the TCP flaw some contacts of his found over in Sweden. He wrote it up in his column on Dark Reading, and Dennis Fisher over at TechTarget also has some information up. Basically, it’s massive unpatched denial of service attack that can take down nearly anything that uses TCP, in some cases forcing remote systems to reboot or potentially causing local damage. Codified in a tool called “Sockstress”, Robert E. Lee and Jack C. Louis seem to be having trouble getting the infrastructure vendors to pay attention. I can’t but help think it’s because they are with a smaller company in Sweden; had this fallen into the hands of one of the major US vendors/labs methinks the alarm bells would be ringing a tad louder. From what Robert told me, supported by the articles, this tool allows an attacker to basically take down anything they want from nearly anywhere (like a home connection). Robert and Jack are trying to report and disclose responsibly, and I sure as heck hope the vendors are listening. Now might be the time for you big end users to start asking them questions about this. It’s hard to block an attack when it takes down your firewall, IPS, and the routers connecting everything. One interesting tidbit- since this is in TCP, it also affects IPv6. Share:

Greg Young over at Gartner has a humorous post on possibly the best way to make money in network security- the “Security Silly Jar”. Just drop in a quarter anytime someone says something stupid from the list. My favorite is number 9: 9. software can”t be secure. Could you please at least try. If you don’t know Greg, he’s the lead for network security over at Gartner and someone definitely worth reading… Share: