Research

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:

Last night I managed to pull a serious Munson. My car battery was dead, so I jumped it from my wife’s car. Then both batteries were dead (her car literally shut down when I tried to start mine). Then my brother in law came over, and managed to jump both cars. We left them running, then turned them off- and both were dead again. One more trip from my brother in law and we were up and running. We drove around for a bit and then stopped to run an errand. We stopped, and restarted, one car at a time so we always had one running vehicle. Both restarted, so we ran them for a minute longer and then ran our errand. Come back, and both are dead. Mall security jumped her car, drove on the highways for 20 minutes, parked it at home. Dead. Dead. Dead. Her car is a hybrid, and we think my battery is dead and something about jumping it blew something in her electrical system. Good times, my friends. Good times. At least I get some amusement this morning out of this article with some of the usual statistical dribble used to scare people into buying products. There’s no need to go into detail- it’s just a survey talking about how few companies perform email encryption, how hard and manual it is, and how employees would use it more if it were easier. This is all, of course, tied into some Nevada law and sponsored by an email encryption vendor. They forget, of course, to mention how few compromises there are of unencrypted email. No reference at all to any real cases where encryption would have prevented the loss of personal data (never mind any fraud associated with said loss). In short, nothing useful to help you make any kind of risk decision. Remember, I’m not against numbers, nor am I against email encryption (I use it occasionally for business communications), but I am against silly numbers with no bearing to anything important. We need more quality metrics and surveys, not this dribble that likely won’t fool a single security professional into buying a product. You might, likely, use email encryption anyway, but this sure won’t affect your decision. Share:

We had a killer episode of the Network Security Podcast this week as Jeremiah Grossman and Robert “Rsnake” Hansen joined us to talk a bit about their new clickjacking exploit. I definitely had some fun on this one, even though Jeremiah and Robert couldn’t dig too deeply into the details. We also managed to sneak in a bit on open source voting, and the top 10 ways to know you’ve been exploited. But mostly, you want to hear is making fun of each other. This was also one of our first episodes we streamed live. Although we record at irregular times, we plan on live streaming as much as we can. Just keep an eye on us on twitter (rmogull or netsecpodcast) for a few hours warning if you want to listen in and harass us over IM. You can download the episode here, and full show notes are at NetSecPodcast.com. Share:

As I write this, the Dow is down nearly 600, Congress struggles to pass a bailout bill, and both the Broncos and Buffs lost over the weekend. Bad times my friends, bad times. Like many of you, although my current financial situation is pretty solid, I can’t help but wonder what the future holds. We’re not merely entering uncharted territory, we’re headed straight for that big black circle marked “There Be Monsters Here”. That doesn’t mean we won’t make it to the other side, but the journey is fraught with danger and challenge. First, a couple of assumptions: Some sort of bailout package will pass. Times will get tough, but we won’t enter a full depression. If we hit a depression all bets are off- since, at that point, much of society essentially collapses. But short of total economic collapse, or a miracle economic recovery, we can somewhat effectively follow the trends and postulate some conclusions. I lost my crystal ball years ago during a wild night with Hoff and Amrit involving some bottles of 40 year old scotch, the real Travelosity gnome, and a Vegas cab driver snorting pure ground Brazilian sugar cane, but if we step back we can probably make a few guesses as to the collective future of the security world. First, our starting assumptions: We’ll continue to see severe credit restrictions- even tighter than now. With limited credit and a weak stock market, the economic effects will spread beyond the financial sector. Retail, auto, and other credit-heavy industries will suffer the most. We will see no decline in security threats, but the threats will morph to adapt to changing market conditions. We don’t need to get fancy; belts will tighten, credit will be harder to obtain, the bad guys will keep adapting, and business will continue, albeit more slowly. These lead directly to some conclusions about the security market: Startup cash will dry up, and IPOs are no longer an exit strategy option. There will be less security product innovation, and what is created will be bought earlier, and cheaper, by established players who can’t afford big acquisitions anymore. We will see continued, massive, consolidation as small companies struggle to survive and larger players can’t create growth. These won’t be big buyouts with happy founders retiring on the beach, but survival consolidations. Think Symantec buying Checkpoint, or Oracle buying Symantec. More middle players will consolidate as well, like the Sophos/Utimaco deal. We’ll have a few big generalists, a smattering of middle-sized guys glomming together, and the occasional small company that bootstrapped with a couple paying clients and isn’t dependent on external financing. Best of breed loses to security suites. Users will demand more suites from their vendors, and “good enough” will be the name of the game. If you have a technologically superior solution no one will care. To be honest, no one really cares today, but they’ll care less in the future. Large price pressure. Users will demand these suites at no (or minimal) additional cost. Vendors will grind over each other in a race to the bottom just to keep customers. It may not look like it on the surface price sheets, but in the nitty gritty street battles on deals you’ll see sales guys tossing in their firstborn essentially for free. A continued obsession with compliance, cost reduction, and obvious threats. If a tool isn’t required by the auditors, doesn’t reduce ongoing operational costs, or stop a threat (like spam/viruses) that knocks people offline, it won’t sell very well. Vendors who don’t solve a clear and present business problem are in trouble. It will be nearly impossible to get budget for anything else. We’ll also see some threat evolution: Tighter credit issuing will reduce new account fraud. If it’s harder for the good guys to get credit, it will also be harder for the bad guys. Existing account fraud will increase. It isn’t like the bad guys will go get some non-existent legitimate jobs. They’ll hammer the financial system, especially phishing/preying on financial fears. As any historian will tell you, fraud tends to increase during times of economic extremes- good and bad. Major attack vectors will be similar to what we see today- clientside and web application. I don’t see anything in an economic downturn that changes the technical nature of the attacks we see today- they’ll continue to get more sophisticated, but that’s happening regardless of any economic issues. And, of course, this will impact security professionals and how we do our jobs: The bad guys will keep us employed, but salaries will be under pressure. “Good enough” applies to us as much as it does to our tools. We’ll see a little professional erosion as underexperienced newbies enter the market to stay employed, and non-security IT folks take added security responsibility. Now will be a good time for a diverse skill set to survive fat trimming. We’ll have to do more with less. That’s so obvious I’m embarrassed to write it. We’ll be under even greater pressure to justify what we do, and what we spend on. Again, really obvious, but as we’ve been talking about long before these economic troubles, the most successful security professionals will be those who can clearly communicate with the business and articulate their value. Get used to accepting more risk. We’ll have to take hits on the small stuff to focus our efforts on the biggest risks. Pragmatic wins. The broader your skill set, the less you cost the company while stopping most of the bad stuff; and the better you can communicate all of this the happier you’ll be. It’s always been about getting the job done, but let’s be honest and admit that it isn’t always about getting the job done. While internal politics and BS will never go away, odds are those who take a practical approach will survive better, and perhaps thrive, during tough economic times. In other words, get used to people trying to nibble at your job, tighter

Over at the Washington Post they note that it looks like a “McCain Wins Debate” ad and quote accidently leaked before the… you know… debate actually happens. While I don’t plan on voting for him, criticizing preparing ads and responses ahead of time would be silly. It’s only prudent since there really isn’t time to create this content after the fact in our obsessive 24 hour news cycle driven society. What can be criticized is this could show a little lack of organization and discipline. Or not. If I were the Democratic equivalent of Karl Rove I might drop a few of these things on my own. Through front companies, of course. Sure, it would eventually be repudiated, but the initial damage will be done. Heck, that’s not even all that creative- aside from the ubiquitous YouTube ads and testimonials, there are all sorts of new attack vectors thanks to the Internet age. We already see plenty of this going on through email campaigns, which seem even more effective than the push polling of Bush II vs. McCain eight years ago. One reason this garbage is so effective? Most people have intense confirmation bias. As Adam posted recently, study after study shows we are inclined to believe that which aligns with our existing beliefs. On top of that, functional MRI studies have shown that political discussions trigger the same parts of the brain as religion- in other words, faith, and sections of our mind that are core to our identity. It is far easier to manipulate someone into believing what they want to believe than introducing contradictory information. The net is fracking perfect for this. Share:

As most of you know, Adrian and I have been pretty slammed lately; bouncing all over the inter-tubes (and airports) on our quest to save freedom and not default on our mortgages. One thing we’ve been wanting to do for a while is summarize everything that’s been going on through the week in a bit more of a structured format, a la Rothman’s Daily Incite. But we’re not nearly as motivated as Mike, but we figure we can handle once a week before we attend the official Securosis Weekly Research Offsite (happy hour). It’s a summary of what we’ve been up to, and our top post selections for the week. Webcasts, Podcasts, and Conferences: I put together the DLP Security School for TechTarget a few weeks back, but it was published while I was in the middle of my travel binge. I really like this education format, and believe it or not there are a few tidbits in there that aren’t in all the other stuff I’ve published on DLP. Adrian just finished the SIM Security School. Did I mention we like this format? Unlike the DLP school he put together a full webcast (as opposed to a video segment) with a ton of content. I spoke on a data masking panel at Oracle World. Here’s a post inspired by the session. This week on the Network Security Podcast Episode 121 our guest was T-Rob discussing Palin’s email hack, and MQ middleware security. Yeah, we thought it was a weird combo too. Outside Writing: The big one for me this week was Macworld- I was heavily involved in the security issue that’s sitting on newsstands this month. Except where it’s sold out, like my neighborhood Barnes and Noble. (I swear I didn’t buy them all). I’m really proud of the issue- it addresses the security needs and questions of average users, and is the kind of thing I can send to my mom. Favorite Securosis Posts: Rich: The Breach Reporting Dilemma. We really need to start looking at breach reporting differently, but I don’t expect it to happen anytime soon. Adrian: Behavioral Modeling. Some of the most significant advances we can make in security are in heuristics, but it’s also an extremely difficult problem. Favorite Outside Posts: Adrian: Jeremiah Grossman on YouTube. (description) Rich: Tim Wilson on Premature Chasm Crossing. I love articles/posts on thinking differently about the security market and, oh, I don’t know, focusing on the end users. Top News: The economy. Is there any other news? Blog Comment of the Week: I don’t agree with all of them, but Dre has some of the deepest comments on the blog. Here’s one on our PCI scanning post: [snip]… Most organizations implement firewall/IPS incorrectly. They assume it’s something you plug in. Most firewalls/IPS don’t protect on the outbound, and most policies allow outbound SYN origination from the DMZ on externally facing interfaces. Most firewalls/IPS don’t provide the real protections one would need without excessive CPU and memory usage. A few null routes (or uRPF) at the border is all that is necessary to prevent traffic to the 80 percent of the Internet we know we can”t trust. …[/snip] We hope you all have a great weekend. Share: