Research

Good Morning: I was at dinner over the weekend with a few buddies of mine, and one of my friends asked (again) which AV package is best for him. It seems a few of my friends know I do security stuff and inevitably that means when they do something stupid, I get the call. You can be this guy… Seriously…This guy’s wife contracted one of the various Facebook viruses about a month ago and his machine still wasn’t working correctly. Right, it was slow and sluggish and just didn’t seem like it used to be. I delivered the bad news that he needed to rebuild the machine. But then we got talking about the attack vectors and how the bad guys do their evil bidding, and the entire group was spellbound. Then it occurred to me: security folks could be the most interesting guy (gal) in the room at any given time. Like that dude in the Tecate beer ads. Being a geek – especially with security cred – could be used to pick up chicks and become the life of the party. Of course, the picking up chicks part isn’t too interesting to me, but I know lots of younger folks with skillz that are definitely interested in those mating rituals young people or divorcees partake in. Basically, like every other kind of successful pick-up artist, it’s about telling compelling (and funny) stories. At least that’s what I’ve heard. You have to establish common ground and build upon that. Social media attacks are a good place to start. Everyone (that you’d be interested in anyway) uses some kind of social media, so start by telling stories of how spooky and dangerous it is. How they can be owned and their private data distributed all over China and Eastern Europe. And of course, you ride in on your white horse to save the day with your l33t hacker skillz. Then you go for the kill by telling compelling stories about your day job. Like finding pr0n on the computer of the CEO (and having to discreetly clean it off). Or any of the million other stupid things people in your company do, which is actually funny if you weren’t the one with the pooper scooper expected to clean it up. You don’t break confidences, but we are security people. We can tell anecdotes with the best of them. Like AndyITGuy, who shares a few humorous ones in this post. And those are probably the worst stories I’ve heard from Andy. But he’s a family guy and not going to tell his “good” stories on the blog. Now to be clear (and to make sure I don’t sleep in the dog house for the rest of the week), I’m making this stuff up. I haven’t tried this approach, nor did I have any kind of rap when I was on the prowl like 17 years ago. But maybe this will work for you, Mr. (or Ms.) L33t Young Hacker trying to find a partner or at least a warm place to hang for a night or three. Or you could go back to your spot on the wall and do like pretty much every generation of hacker that’s come before you. P!nk pretty much summed that up (video)… – Mike Photo credit: “Tecate Ad” covered by psfk.com Incite 4 U I’m not one to really toot my own horn, but I’m constantly amazed at the amount and depth of the research we are publishing (and giving away) on the Securosis blog. Right now we have 3-4 different content series emerging (DB Quant, Pragmatic Data Security, Network Security Fundamentals, Low Hanging Fruit, etc.), resulting in 3-4 high quality posts hitting the blog every single day. You don’t get that from your big research shops with dozens of analysts. Part of this is the model and a bigger part is focusing on doing the right thing. We believe the paywall should be on the endangered species list, and we are putting our money where our mouths are. If you do not read the full blog feed you are missing out. Prognosis for PCI in 2010: Stagnation… – Just so I can get my periodic shout-out to Shimmy’s new shop, let me point to a post on his corporate blog (BTW, who the hell decided to name it security.exe?) about some comments relative to what we’ll see in PCI-land for 2010. Basically nothing, which is great news because we all know most of the world isn’t close to being PCI compliant. So let’s give them another year to get it done, no? Oh yeah, I heard the bad guys are taking a year off. No, not really. I’m sure all the 12 requirements are well positioned to deal with threats like APT and even new fangled web application attacks. Uh-huh. I understand the need to let the world catch up, but remember that PCI (and every other regulation) is a backward looking indicator. It does not reflect what kinds of attacks are currently being launched your way, much less what’s coming next. – MR This Ain’t Your Daddy’s Cloud – One of the things that annoys me slightly when people start bringing up cloud security is the tendency to reinforce the same old security ideas and models we’ve been using for decades, as opposed to, you know, innovating. Scott Lupfer offers some clear, basic cloud security advice, but he sticks with classic security terminology, when it’s really the business audience that needs to be educated. Back when I wrote my short post on evaluating cloud risks I very purposely avoided using the CIA mantra so I could better provide context for the non-security audience, as opposed to educating them on our fundamentals. With the cloud transition we have an opportunity to bake in security in ways we missed with the web transition, but we can’t be educating people about CIA or Bell La Padula – RM Cisco milking the MARS cash cow? – Larry

As we continue on our journey through the fundamentals of network security, the idea of network monitoring must be integral to any discussion. Why? Because we don’t know where the next attack is coming, so we need to get better at compressing the window between successful attack and detection, which then drives remediation activities. It’s a concept I coined back at Security Incite in 2006 called React Faster, which Rich subsequently improved upon by advocating Reacting Faster and Better. React Faster (and better) I’ve written extensively on the concept of React Faster, so here’s a quick description I penned back in 2008 as part of an analysis of Security Management Platforms, which hits the nail on the head. New attacks are happening at a fast and furious pace. It is a fool’s errand to spend time trying to anticipate where the issues are. REACT FASTER first acknowledges that all attacks cannot be stopped. Thus, focus remains on understanding typical traffic and application usage trends and monitoring for anomalous behavior, which could indicate an attack. By focusing on detecting attacks earlier and minimizing damage, security professionals both streamline their activities and improve their effectiveness. Rich’s corollary made the point that it’s not enough to just react faster, but you need to have a plan for how to react: Don’t just react – have a response plan with specific steps you don’t jump over until they’re complete. Take the most critical thing first, fix it, move to the next, and so on until you’re done. Evaluate, prioritize, contain, fix, and clean. So monitoring done well compresses the time between compromise and detection, and also accelerates root cause analysis to determine what the response should involve. Network Security Data Sources It’s hard to argue with the concept of reacting faster and collecting data to facilitate that activity. But with an infinite amount of data to collect, where do we start? What do we collect? How much of it? For how long? All of these are reasonable questions that need answers as you construct your network monitoring strategy. The major data sources from your network security infrastructure include: Firewall: Every monitoring strategy needs to correspond to the most prevalent attack vectors, and that means from the outside in. Yes, the insider threat is real, but script kiddies are alive and well and that means we need to start by looking at our Internet-facing devices. First we pull log and activity information from our firewalls and UTM devices on the perimeter. We look for strange patterns, which usually indicate something is wrong. We want to keep this data long enough to ensure we have sufficient data in the event of a well-executed low and slow attack, which means months rather than days. IPS: The next layer in tends to be IPS, looking for patterns of traffic that indicate a known attack. We want the alerts first and foremost. But we also want to collect the raw IPS logs as well. Just because the IPS doesn’t think specific traffic is an attack doesn’t mean it isn’t. It could be a dreaded 0-day, so we want to pull all the data we can off this box as well, since the forensic analysis can pinpoint when attacks first surfaced and also provide guidance as to the extent of the compromise. Vulnerability scans: Are those devices vulnerable to a specific attack? Vulnerability scan data is one of the key inputs to SIEM/correlation products. The best way to reduce false positives is not to fire an alert if the target is not vulnerable. Thus we keep scan data on hand, and use it both for real-time analysis and also forensics. If an attack happens during a window of vulnerability (like while you debate the merits of a certain patch with the ops guys), you need to know that. Network Flow Data: I’ve always been a big fan of network flow analysis and continue to be mystified that market never took off, given the usefulness of understanding how traffic flows within and out of a network. All is not lost, since a number of security management products use flow data in their analyses and a few lower end management products use flow data as well. Each flow record is small, so there is no reason not to keep a lot of it. Again, we use this data to both pinpoint potential badness, and also replay attacks to understand how they spread within the organization. Device Change Logs: If your network devices get compromised, it’s pretty much game over. Traffic can be redirected, logging suppressed, and lots of other badness can result. So keep track of device configuration and more importantly when those changes happen – which helps isolate the root causes of breaches. Yes, if the logs are turned off, you lose visibility, which can itself indicate an issue. Through the wonders of SNMP, you should collect data from all your routers, switches, and other pipes. Content security: Now we can climb the stack a bit to pull information off the content security gateways, since a lot of attacks still show up via phishing emails and malware-laden web links. Again, we aren’t trying to pull this data in necessarily to stop an attack (hopefully the anti-spam box will figure out you aren’t interested in the little blue pill), but rather to gather more information about the attack vectors and how an attack proliferates through your environment. Reacting faster is about learning all we can about what is compromised and responding in the most efficient and effective manner. Keeping things focused and pragmatic, you’d like to gather all this data all the time across all the networks. Of course, Uncle Reality comes to visit and understandably, collection of everything everywhere isn’t an option. So how do you prioritize? The objective is to use the data you already have. Most organizations have all of the devices listed above. So all the data sources exist, and should be prioritized based on importance to the

(Update: Based on a comment, I added some caveats regarding business critical applications.) Since I’m getting my coverage of Network and Endpoint Security, as well as Security Management, off the ground, I’ll be documenting a lot of fundamentals. The research library is bare from the perspective of infrastructure content, so I need to build that up, one post at a time. As we start talking about the fundamentals of network security, we’ll first zero in on the perimeter of your network. The Internet-facing devices accessible by the bad guys, and usually one of the prevalent attack vectors. Yeah, yeah, I know most of the attacks target web applications nowadays. Blah blah blah. Most, but not all, so we have to revisit how our perimeter network is architected and what kind of traffic we allow into that web application in the first place. Defining Default Deny Which brings us to the first topic in the fundamentals series: Default Deny, which implements what is known in the trade as a positive security model. Basically it means unless you specifically allow something, you deny it. It’s the network version of whitelisting. In your perimeter device (most likely a firewall), you define the ports and protocols you allow, and turn everything else off. Why is this a good idea? Lots of attacks target unused and strange ports on your firewalls. If those ports are shut down by default, you dramatically reduce your attack surface. As mentioned in the Low Hanging Fruit: Network Security, many organizations have out-of-control firewall and router rules, so this also provides an opportunity to clean those rules up as well. As simple an idea as this sounds, it’s surprising how many organizations either don’t have default deny as a policy, or don’t enforce it tightly enough because developers and other IT folks need their special ports opened up. Getting to Default Deny One of the more contentious low hanging fruit recommendations, as evidenced by the comments, was the idea to just blow away your overgrown firewall rule set and wait for folks to complain. A number said that wouldn’t work in their environments, and I can understand that. So let’s map out a few ways to get to default deny: One Fell Swoop: In my opinion, we should all be working to get to default deny as quickly as possible. That means taking a management by compliant approach for most of your traffic, blowing away the rule set, and waiting for the help desk phone to start ringing. Prior to blowing up your rule base, make sure to define the handful of applications that will get you fired if they go down. Management by Compliant doesn’t work when the compliant is attached to a 12-gauge pointed at your head. Support for those applications needs to go into the base firewall configuration. Consensus: This method involves working with senior network and application management to define the minimal set of allowed protocols and ports. Then the impetus falls on the developers and ops folks to work within those parameters. You’ll also want a specific process for exceptions, since you know those pesky folks will absolutely positively need at least one port open for their 25-year-old application. If that won’t work, there is always the status quo approach… Case by Case: This is probably how you do things already. Basically you go through each rule in the firewall and try to remember why it’s there and if it’s still necessary. If you do remember who owns the rule, go to them and confirm it’s still relevant. If you don’t, you have a choice. Turn it off and risk breaking something (the right choice) or leave it alone and keep supporting your overgrown rule set. Regardless of how you get to Default Deny, communication is critical. Folks need to know when you plan to shut down a bunch of rules and they need to know the process to get the rules re-established. Testing Default Deny We at Securosis are big fans of testing your defenses. That means just because you think your firewall configuration enforces default deny, you need to be sure. So try to break it. Use vulnerability scanners and automated pen testing tools to find exposures that can be exploited. And make this kind of testing a standard part of your network security practice. Things change, including your firewall rule set. Mistakes are made and defects are introduced. Make sure you are finding them – not the bad guys. Default Deny Downside OK, as simple and clean as default deny is as a concept, you do have to understand this policy can break things, and broken stuff usually results in grumpy users. Sometimes they want to play that multi-player version of Doom with their college buddies and it uses a blocked port. Oh, well, it’s now broken and the user will be grumpy. You also may break some streaming video applications, which could become a productivity boost during March Madness. But a lot of the video guys are getting more savvy and use port 80, so this rule won’t impact them. As mentioned above, it’s important to ensure the handful of business critical applications still run after the firewall ruleset rationalization. So do an inventory of your key applications and what’s required to support those applications. Integrate those rules into your base set and then move on. Of course, mentioning that your trading applications probably shouldn’t need ports 38-934 open for all protocols is reasonable, but ultimately the business users have to balance the cost to re-engineer the application versus the impact to security posture of the status quo. That’s not the security team’s decision to make. Also understand default deny is not a panacea. As just mentioned, lots of application traffic uses port 80 or 443 (SSL), and will largely be invisible to your firewall. Sure, some devices claim “deep packet inspection” and others talk about application awareness, but most don’t. So more sophisticated attacks require additional layers of defense. Understand default deny for what it is: a coarse filter for your perimeter, which

Good Morning: Maybe it’s the hard-wired pessimist in me, but I never thought I’d live a long life. I know that’s kind of weird to think about, but with my family history of health badness (lots of the Big C), I didn’t give myself much of a chance. At the time, I must have forgotten that 3 out of my 4 grandparents lived past 85, and my paternal grandma is over 100 now (yes, still alive). But when considering your own mortality, logic doesn’t come into play. I also think my lifestyle made me think about my life expectancy. 3 years ago I decided I needed an attitude adjustment. I was fat and stressed out. Yes, I was running my own business and happy doing that, but it was pretty stressful (because I made it that way) and it definitely took a toll. Then I decided I was tired of being a fat guy. Literally in a second the decision was made. So I joined a gym and actually went. I started eating better and it kind of worked. I’m not where I want to be yet, but I’m getting there. I’m the kind of guy that needs a goal, so I decided I want to live to 90. I guess 88 would be OK. Or maybe even 92. Much beyond that I think I’ll be intolerably grumpy. I want to be old enough that my kids need to change my adult diapers. Yes, I’m plotting my revenge. Even if it takes 50 years, the tables will be turned. So how am I going to get there? I stopped eating red meat and chicken. I’m eating mostly plants and I’m exercising consistently and intensely. That’s my plan for now, but I’m also monitoring information sources to figure out what else I can be doing. That’s when I stumbled upon an interesting video from a TED conference featuring Dan Buettner (the guy from National Geographic) who talked about 9 ways to live to 100, based upon his study of a number of “Blue Zones” around the world where folks have great longevity. It’s interesting stuff and Dan is an engaging speaker. Check it out. Wish me luck on my journey. It’s a day by day thing, but the idea of depending on my kids to change my diaper in 50 years pretty motivating. And yes, I probably need to talk to my therapist about that. – Mike Photo credit: “and adult diapers” originally uploaded by &y Incite 4 U It seems everyone still has APT on the brain. The big debate seems to be whether it’s an apt description of the attack vector. Personally, I think it’s just ridiculous vibrations from folks trying to fathom what the adversary is capable of. Rich did a great FireStarter on Monday that goes into how we are categorizing APT and deflating this ridiculous “cyber-war” mumbo jumbo. Looking at everything through politically colored glasses – We have a Shrdlu admiration society here at Securosis. If you don’t read her stuff whenever she finds the time to write, you are really missing out. Like this post, which delves into how politics impacts the way we do security. As Rich says, security is about psychology and economics, which means we have to figure out what scares our customers the most. In a lot of cases, it’s auditors and lawyers – not hackers. So we have to act accordingly and “play the game.” I know, you didn’t get into technology to play the game, but too bad. If you want to prosper in any role, you need to understand how to read between the lines, how to build a power base, and how to get things done in your organization. And no, they don’t teach that in CISSP class. – MR I can haz your cloud in compliance – Even the power of cloud computing can’t evade its cousin, the dark cloud of compliance that ever looms over the security industry. As Chris Hoff notes in Cloud: Security Doesn’t Matter, organizations are far more concerned with compliance than security, and it’s even forcing structural changes in the offerings from cloud providers. Cloud providers are being forced to reduce multi-tenancy to create islands of compliance within their clouds. I spent an hour today talking with a (very very big) company about exactly this problem – how can they adopt public cloud technologies while meeting their compliance needs? Oh sure, security was also on the list – but as on many of these calls, compliance is the opener. The reality is you not only need to either select a cloud solution that meets your compliance needs (good luck), or implement compensating controls on your end, like virtual private storage, and you also need to get your regulator/auditor to sign off on it. – RM It’s just a wafer thin cookie, Mr. Creosote – Nice job by Michael Coates both on discovering and illustrating a Cookie Forcing attack. In a nutshell, an attacker can alter cookies already set regardless of whether it’s an encrypted cookie or not. By imitating the user in a man-in-the-middle attack, the attacker finds an unsecured HTML conversation, requests an unencrypted meta refresh, and then sends “set cookie” to the browser, which accepts the evil cookie. To be clear, this attack can’t view existing cookies, but can replace them. I was a little shocked by this as I was of the opinion meta refresh had not been considered safe for some time, and because the browser happily conflated encrypted and unencrypted session information. One of the better posts of the last week and worth a read! – AL IT not as a business, huh? – I read this column on not running IT as a business on infoworld.com and I was astounded. In the mid-90’s running IT as a business was all the rage. And it hasn’t subsided since then. It’s about knowing your customer and treating them like they have a choice in service providers (which they do). In fact, a big part of the Pragmatic CSO is to think about security like a business, with a business plan and everything.

To wrap up my low hanging fruit series (I believe Rich and Adrian will be doing their own takes), let’s talk about security management. Yes, there were lots of components of each in the previous LHF posts (network security & endpoint security) that had “management” components, but now let’s talk about the discipline of management, not necessarily the tools. Think and Be Program Some folks would rather think and be rich, but if you do security for a living, you need to be thinking about a security program. To be clear, establishing a security program is the single hardest thing any security professional has to do. Period. Nothing else comes close in heartburn, futility, angst, or importance. The folks residing in a hamster wheel of pain (a great term coined by Andy Jaquith, I think) tend to spend most of their time in fire-fighting mode. OK, being honest, they spend all their time fire-fighting. That also means a program is not really low hanging fruit (it’s more like skyscraper hanging fruit), but I don’t think you’ll make much headway with any kind of security management without having the structure of a program in place. Thus, this is really about context and the importance of that context as you look to other security management techniques. So why is it so hard to get a program off the ground? Per usual, it gets back to shiny objects and your to-do list. It’s just easier to do something else. Senior management doesn’t have to agree to fixing a firewall rule, re-imaging a machine, or patching a bunch of devices. But they do have to buy into a program. Your peers have to agree to think about security before they do things. Since they don’t like to do that, getting consensus is hard. So most folks just don’t do it – and that’s a big mistake. Without the program in place, your likelihood of success is small. Best of all, you don’t have to implement a full program to greatly increase your chance of success. Yet, all is not lost. You can start slowly with the program and do a few things (kind of low hanging) to get you going: Define success: Without a clear and agreed-upon definition of security success, you may as well give up now. So this really has to be the first step in the process. Communication: How often do you get face time with senior management? It’s probably not enough. Make sure you get an audience as often as you need. In the initial stages probably once a month (if not more often), later on maybe not as much. But if you don’t have something set in stone, scheduled on the calendar, it won’t happen. Accountability: In most organizations, the security team is not well liked. In order to have any chance to implement a security program, you need to change that perception. That’s done one step at a time. Tell them what you are going to do and then do it. Yes, it seems pretty easy. But if it was really easy, everyone would be doing it, right? Just to throw in a shameless plug, I discussed how to implement a security program in The Pragmatic CSO. It goes into a lot of detail on how to structure the program and get acceptance with your business leaders. Incident Response No matter what time it is, it’s time to revisit your incident response plan. Hopefully you haven’t had to use it lately, but don’t get lulled into a false sense of security. Before long you’ll be compromised, and whether you live to fight another day has everything to do with how you respond to the incident. The worst time to learn your IR plan sucks is when you are in the middle of an attack. First make sure senior management understands roles and responsibilities. Who runs point for what? When do the CEO and board need to be notified? When does law enforcement get involved? All of this needs to be documented and agreed upon. Next run simulations and practice. Lots of my practitioner friends practice using live ammo, but if you aren’t under constant attack, then you’ll need to schedule time to practice. Yes, shiny objects and fires to fight make it hard to carve out the time to practice the IR process, but don’t neglect your preparation. Monitor Everything If there is anything the recent APT (advanced persistent threat) hysteria has shown, it’s that we have little chance against a well-funded and patient attacker. The only chance we have is to figure out they are in the house as soon as possible. I call this Reacting Faster, which of course Rich has to improve by reminding us all to React Faster, and Better. The point remains that we don’t know where the attacks are coming from (0-day, by definition, means you don’t know about it, so it’s pretty laughable when an IPS vendor says they can protect against a 0-day attack), so we’d better get better at detecting funky behavior. Anomaly detection is your friend. You need to monitor everything you can, baseline the “normal” course of events, and look for something that is not normal. That gives you something to investigate, as opposed to the literally infinite places where you could be looking for an attack. Logging: Your regulations say you need to log stuff, so you probably have some rudimentary logging capability in place. Or you are looking at one. That’s a good idea because all security management starts with data, and a good portion of your data is in log files. So having an automated mechanism to gather and parse logs is a critical first step. Change detection: Malware tends to leave a trail. Well, most malware anyway. To change behavior usually requires some kind of operating system file change. So seeing those changes will usually give you an indication that something is wrong. Look at key network devices and servers, since those are the interesting targets. Network behavioral analysis: Network flow analysis yields some very interesting perspective on what folks are doing with

Back when I was the resident security management expert over at TechTarget (a position since occupied by Mort), it was amazing how many questions I got about the value of certifications. Mort confirms nothing has changed. Alex Hutton’s great posts on the new ISACA CRISC certification (Part 1 & Part 2) got me thinking that it’s probably time to revisit the topic, especially given how the difficult economy has impacted job search techniques. So the question remains for practitioners: are these certifications worth your time and money? Let’s back up a bit and talk about the fundamental motivators for having any number of certifications. Skills: A belief exists that security certifications reflect the competence of the professional. The sponsoring organizations continue to do their job of convincing folks that someone with a CISSP (or any other cert) is better than someone who doesn’t have one. Jobs: Lots of folks believe that being certified in certain technologies makes them more appealing to potential employers. Money: Certifications also result in higher average salaries and more attractive career paths. According to the folks who sell the certifications, anyway. Ego: Let’s be honest here. We all know a professional student or three. These folks give you their business cards and it’s a surprise they have space for their address, with all the acronyms after their name. Certifications make these folks feel important. So let’s pick apart each of these myths one by one and discuss. Skills Sorry, but this one is a resounding NFW. Most of the best security professionals I know don’t have a certification. Or they’ve let it lapse. They are simply too busy to stop what they are doing to take the test. That’s not to say that anyone with the cert isn’t good, but I don’t see a strong relationship between skills and certs. Another issue is that many of the certification curricula get long in the tooth after a few years. Today’s required skills are quite different than a few years ago because the attack vectors have changed. Unfortunately most of the certifications have not. Finally, to Alex’s point in the links above, lots of new certifications are appearing, especially given the myths described below. Do your homework and make sure the curriculum makes sense based on your skills, interest, and success criteria. Jobs The first justification for going to class and taking the test usually comes down to employment. Folks think that a CISSP, GIAC, or CISM will land them the perfect job. Especially now that there are 100 resumes for every open position, a lot of folks believe the paper will differentiate them. The sad fact is that far too many organizations do set minimum qualifications for an open position, which then get enforced by the HR automatons. But I’d wonder if that kind of company is somewhere you’d like to work. Can it be a perfect job environment if they won’t talk to you if you don’t have a CISSP? So getting the paper will not get you the job, but it may disqualify you from interviewing. Money The certification bodies go way out of their way to do salary surveys to prove their paper is worth 10-15% over not having it. I’m skeptical of surveys on a good day. If you’re in an existing job, in this kind of economy, your organization has no real need or incentive to give you more money for the certification. There has also clearly been wage deflation in the security space. Companies believe they can get similar (if not better) talent for less money, so it’s hard for me to see how a certification is going to drive your value up. Ego There is something to be said for ego. The importance of confidence in a job search cannot be minimized. It’s one of those intangibles that usually swings decisions in your direction. If the paper makes you feel like Superman, go get the paper. Just don’t get into a scrap with an armed dude. You are not bulletproof, I assure you. The Right Answer: Stop Looking for Jobs Most of the great performers don’t look for jobs. They know all the headhunters, they network, they are visible in their communities, and they know about all the jobs coming available – usually before they are available. Jobs come and find them. So how do you do that? Well, show your kung fu on an ongoing basis. Participate in the security community. Go to conferences. Join Twitter and follow the various loudmouths to get involved in the conversation. Start a blog and say something interesting. That’s right, there is something to this social networking thing. A recommendation from one of the well-known security folks will say a lot more about you than a piece of paper you got from spending a week in a fancy hotel. The senior security folks you want to work for don’t care about paper. They care about skills. That’s the kind of place I want to work. But hey, that’s just me. Share:

Getting back to the Low Hanging Fruit series, let’s take a look at the endpoint and see what kinds of stuff we can do to increase security with a minimum of pain and (hopefully) minor expense. To be sure we are consistent from a semantic standpoint, I’m generally considering computing devices used by end users as “endpoints.” They come in desktop and laptop varieties and run some variant of Windows. If we had all Mac endpoints, I’d have a lot less to do, eh? Yes, that was a joke. Run Updated Software and Patch We just learned (the hard way) that running old software is a bad idea. Again. That’s right, the Google hack targeted IE6 on XP. IE6? Really? Yup. A horrifyingly high number of organizations are stuck in a browser/OS time warp. So, if you need to stick with XP, at least make sure you have SP3 running. It seems Windows 7 finally makes the grade, so it’s time to start planning those upgrades. And yes, maybe MSFT got it right this time. Also make sure to use IE7 or IE8 or Firefox (with NoScript). Yes, browsers will have problems. But old browsers have a lot of problems. Also make sure your Adobe software remains up to date. The good news is that Adobe realizes they have an issue, and I expect they’ll make big investments to improve their security posture. The bad news is that they are about 5 years behind Microsoft and will emerge as the #1 target of the bad guys this year. Finally, make sure you tighten patch windows as tightly as possible for the high risk, highly exploitable applications, like browsers and Adobe software. Studies have proven that it’s more important to patch thoroughly, as opposed to quickly. But as seen this past week, it takes one day to turn a proof of concept browser 0-day into a weaponized exploit, so for these high risk apps – all bets are off. As soon as a browser (or Adobe) patch hits, try to get it deployed within days. Not weeks. Not months! Use Anti-Exploitation Technology Microsoft got a bad rap on security and some (OK, most) of it was deserved. But they have added some capabilities to the base OS that make sense. Like DEP (Data Execution Prevention – also check out the FAQ) and ASLR (Address Space Layout Randomization). These technologies make it much harder to gain control of an endpoint through a known vulnerability. So make sure DEP and ASLR are turned on in your standard build. Make sure your endpoint checks confirm these two options remain selected. And most importantly, make sure the apps you deploy actually use DEP and ASLR. IE7 and IE8 do. IE6, not so much. Adobe’s stuff – not so much. And there you have it. To be clear, anti-exploitation technology is not the cure for cancer. It does help to make it harder to exploit the vulnerabilities in the software you use. But only if you turn it on (and the applications support it). Rich has been writing about this for years. Enforce Secure Configurations I have to admit to spending a bit too much time in the Center for Internet Security’s brainwashing course. I actually believe that locking down the configuration of a device will reduce security issues. Those of you in the federal government probably have a bit of SCAP on the brain as well. You don’t have to follow CIS to the letter. But you do have to shut down non-critical services on your endpoints. And you have to check to make sure those configurations aren’t being messed with. So that configuration management thingy you got through Purchasing last year will come in handy. Encrypt Your Laptops How many laptops have to be lost and how many notifications sent out to irate customers because some jackass leaves their laptop on the back seat of their car? Or on the seat of an airplane? Or anywhere else where a laptop with private information will get pinched? Optimally you shouldn’t allow private information on those mobile devices (right, Rich, DLP lives!), but this is the real world and people take stuff with them. Maybe innocently. Maybe not, but all the same – they have stuff on their machines they shouldn’t have. So you need to encrypt the devices. Bokay? VPN to Corporate Let’s stay on this mobile user riff by talking about all the trouble your users can get into. A laptop with a WiFi card is the proverbial loaded gun and quite a few of your users shoot themselves in the foot. They connect on any network. They click on any emails. They navigate to those sites. You can enforce VPN connections when a user is mobile. So all their traffic gets routed through your network. It goes through your gateway and your policies get enforced. Yes, smart users can get around this – but how many of your users are smart that way? All the same, you probably have a VPN client on there anyway. So it’s worth a try. Training Let’s talk about probably the cheapest of all the things you can do to positively impact on your security posture. Yes, you can train your users to not do stupid things. Not to click on those links. Not to visit those sites. And not to leave their laptop bags exposed in cars. Yes, some folks you won’t be able to reach. They’ll still do stupid things and no matter what you say or how many times you teach, you’ll still have to clean up their machines – a lot. Which brings us to the last of the low hanging fruit… When in doubt, reimage… Yes, you need to invest in a tool to make a standard image of your desktop. You will use it a lot. Anytime a user comes in with a problem – reimage. If the user stiffs you on lunch, reimage. If someone beats you with a pair of aces in the hole, right – reimage. Before you go on a reimaging binge,

Our weekly research meeting started with an optimistic plea from yours truly. Will 2010 finally be the year the signature dies? I mean, come on now, we all know endpoint AV using only signatures is an accident waiting to happen. And everywhere else signatures are used (predominantly IPS & anti-spam) those technologies are heavily supplemented with additional behavioral and heuristic techniques to improve detection. But the team thought that idea was too restrictive, and largely irrelevant because regardless of the technology used, the vendors adapt their products to keep up with the attacks. Yes, that was my idea of biting sarcasm. We broadened our thinking significantly, to think about why we haven’t been able to really kill off any security technology, ever. How many of you still use token authenticators? Or line encryptors? It seems once we implement something, we get to live with it for 20 years. Have you ever tried to actually kill a technology? Someone always finds an edge case where you’d be dead if it happens, so you can’t pull the trigger. Who cares that you have a higher likelihood of getting hit by a meteor in the cranium? Not sure about you, but that annoys the crap out of me. With all the time and money we spend maintaining and paying for these tools, we aren’t doing more strategic things for the business. Our world is complex enough. We need to make it a point this year to get rid of some of these long-in-the-tooth technologies. So for this week’s thought generator, let’s put together a security “endangered species list” of things we want to kill. I’ll start: Signature-based AV Engines – Come on, man! We keep these fat and dumb AV engines around because we are worried that the Melissa virus will make a comeback. Now the vendors need a frackin’ cloud to keep track of all the signatures, which don’t work anyway – given that most of the bad guys use AV*Test.org to make sure the major engines are blind to their stuff. As an alternative, we can (and should) be moving towards a whitelist based approach on servers, where you can lock down the applications, since your servers don’t get pissed when they can’t run Tiger Woods golf or watch March Madness online. These tools are ready for prime time now, and it’s time we killed off the old and busted way of doing things. And you shouldn’t need to keep paying your desktop AV vendor to maintain that signature database, especially since most of them already offer white-list technology as a different product. On the endpoints, do we think these AV engines are actually doing any good? Aren’t we better off focusing on patching and ensuring some of the anti-exploitation technologies (like DEP and ASLR) are used within the applications you let users run on their devices? Then we also have to make sure we are watching more closely for compromised endpoints, so bust out that network monitor and ensure you have egress filtering in use. I described these techniques in Low Hanging Fruit: Network Security last week. With the increasing consumerization of IT, assuming you have control of the endpoint is probably naive at best. Imagine what good all the AV researchers could do if they weren’t spending all day auto-generating signatures? OK, that one was a bit easy and predictable. As Rich would say, what’s different about that? Nothing, I just wanted to get rolling. HIPS – As I continue my attack on everything signature, why does HIPS (Host Intrusion Prevention) still exist? I get that folks don’t really do HIPS on the endpoint, but far too many still kill the performance of their servers by comparing activity to known attack code. I’m sure there are some use cases where HIPS is useful, but is it worth the performance penalty and the cost of management and maintenance? Yeah, probably not. Repeat after me: Black lists are for the birds. Black lists are for the birds. So why do we care about HIPS anymore? Should this also be on the list of security technologies to die? What say you? Tell me why I’m wrong. What’s on your list? Put it in the comments, and be sure to mention: The technology Why it needs to go What compensating controls can be used for at least equal protection Remember the best comment of the week can feel good about making a donation to a worthy charity. Let’s all sing now: The Roof, the roof, the roof is on fire… Now discuss! Share:

Good Morning: I love the Internet. In fact, I can’t imagine how I got anything done before it was there at all times to help. Two examples illustrate my point. On Monday, I went to lunch with the family at Fuddrucker’s, since they had off from school. They say a big poster of Elvis with a title “The King” underneath. They had heard of Elvis, but didn’t know much about him. The Boss and I were debating how old Elvis was when he had that unfortunate toilet incident. I whipped out the iPhone, took a quick peek at Wikipedia, and learned the King died when he was 42. Oh crap, that’s not much older than I am right now. Then we went into his history and music and the kids actually learned something. Thanks, Mr. Internet. Next up, I’ve been having some problems with my washing machine. So I check out the appliance boards on the Internet (thanks to the Google) and figure out what the error code means and a few ideas on how to fix it. Turns out it’s very likely a control unit issue. Amazingly enough, there is a guy in the Southeast who fixes the unit for half the price of buying a new part. The guy sends me a little PDF on how to remove the control unit (it was a whopping 3 Torx screws and unplugging a bunch of wires). I put the unit in a box and sent it off. It could not have been easier. Thanks, Mr. Internet. Now what would I have done 10 years ago? I would have called Sears. They would have come over, charged me for the service call ($140), replaced the control unit ($260), and I’d be good to go. $400 lighter in the wallet, of course. They say an educated consumer is the best consumer. Not for the old Maytag Man, I guess. Don’t think he’s sending thanks to Mr. Internet. –Mike Photo credit: “Maytag Man Inflatable” originally uploaded by arbyreed Incite 4 U This week we got contributions from almost everyone, which has always been my evil plan. And as much as I like the help, I do think having a number of opinions weighing in makes things a lot better – for everyone. China wastes a zero day on IE6? – It seems that the zero day vulnerability exploited by China doesn’t only work on Internet Explorer 6, but according to this article in Dark Reading may also work on IE 7 and 8, and might even work around the DEP (Data Execution Protection) feature of XP and Vista. Considering all the old vulnerabilities in IE6 (you know, something you should have dumped years ago), you have to wonder if the attackers just assumed we weren’t dumb enough to still use ancient code open to old exploits. Without listing all the permutations, it looks like IE8 on Vista or Windows 7 (because of that ASLR anti-exploitation thingy) may be secure, but everything else is exploitable and Microsoft is issuing an emergency patch. I realize it’s painful to think you might have to actually update that 10 year old enterprise application so it works with a browser released after 2001, but it’s time to suck it up and browse like it’s 2010. – RM They are better than us – Clever programmers working on a single project, test their code against live servers, monitor effectiveness, and evolve the code to get better every day. Working with operating systems I used to see this dedication. Some of the programming teams I worked on bordered on fanaticism and worked hard to become better programmers. Teams were like coder’s guilds, where more experienced members would review, teach, and occasionally shred other members for shoddy work. They worked late into the night, building new libraries of code, and studied their craft every night on the train ride home. They knew minutiae about protocols and compilers. I swear a couple of them thought in hexadecimal! When I read blogs like “An Insight into the Aurora Communications Protocol” I get the picture that the hackers are more professional than the “good guys” are. Hackers use obfuscation, SSL variations, code injection, command and control networks, and stolen source code to create custom 0-days. These highly motivated people have rapidly evolving skills. What worries me about Aurora isn’t the sophistication of the attack, but the disparity in dedication between attacker and your typical corporate developer. One side lives this stuff and one has a job. This is getting worse before it gets better. – AL Here’s a serving of humble pie. Eat it! – The truth of the matter is that a lot of security folks fail. Almost as often as marketing folks. Combine the two and you get…me. It does make sense to do a little soul searching and this post from Dan Lohrmann on CSOOnline really resonated. Basically his contention is that security folks come across as unusually proud or overconfident. That’s politically correct. I’d say in general we’re a bunch of arrogant asses. Not everyone, but more than a few. The reality is security folks need a bit of an edge, but at the end of the day we still need to be respectful to our customers. Yes, those idiots who get pwned all the time are our customers. So think about that next time you want to throw some snark in their direction. Just share it on Twitter. Like me. – MR Things in public, are, you know, public – On The Network Security Podcast last night we talked a bit about this article by James Urquhart over at CNet on the Fourth Amendment in the cloud. Actually, forget about the fourth amendment (that’s the search and seizure one for you engineering majors), when it comes to the Internet and privacy repeat after me – “if it’s on the Internet, it isn’t private, and never goes away”. The article emphasizes that anything you store on Internet services (I’m not limiting this to cloud) that is accessible by your service provider can’t be considered private under current law. Phone and paper mail are

During my first two weeks at Securosis, I’ve gotten soundly thrashed for being too “touchy-feely.” You know, talking about how you need to get your mindset right and set the right priorities for success in 2010. So I figure I’ll get down in the weeds a bit and highlight a couple of tactics that anyone can use to ensure their existing equipment is optimized. I’ve got a couple main patches in my coverage area, including network and endpoint security, as well as security management. So over the next few days I’ll highlight some quick things in each area. Let’s start with the network, since it’s really the foundation of everything, but don’t tell Rich and Adrian I said that – they spend more time in the upper layers of the stack. Also a little disclaimer in that some of these tactics may be politically unsavory, especially if you work in a large enterprise, so use some common sense before walking around with the meat cleaver. Prune your firewall Your firewall likely resembles my hair after about 6 weeks between haircuts: a bit unruly and you are likely to find things from 3-4 years ago. Right, the first thing you can do is go through your firewall rules and make sure they are: Authorized: You’ll probably find some really bizarre things if you look. Like the guy that needed some custom port in use for the poorly architected application. Or the port opened so the CFO can chat with his contacts in Thailand. Anyhow, make sure that every exception is legit and accounted for. Still needed: A bunch of your exceptions may be for applications or people no longer with the company. Amazingly enough, no one went back and cleaned them up. Do that. One of the best ways to figure out what rules are still important is to just turn them off. Yes, all of them. If someone doesn’t call in the next week, you can safely assume that rule wasn’t that important. It’s kind of like declaring firewall rule bankruptcy, but this one won’t stay on your record for 7 years. Once you’ve pruned the rules, make sure to test what’s left. It would be really bad to change the firewall and leave a hole big enough to drive a truck through. So whip out your trust vulnerability scanner, or better yet an automated pen testing tool, and try to bust it up. Consolidate (where possible) The more devices, the more opportunities you have to screw something up. So take a critical look at that topology picture and see if there are better ways to arrange things. It’s not like your perimeter gear is running full bore, so maybe you can look at other DMZ architectures to simplify things a bit, get rid of some of those boxes (or move them somewhere else), and make things less prone to error. And you may even save some money on maintenance, which you can spend on important things – like a cappuccino machine. Segregate (where possible) No, I’m not advising that we go back to a really distasteful time in our world, but talking about our understanding that some traffic just shouldn’t be mixed with others. If you worry about PCI, you already do some level of segregation because your credit card data must reside on a different network segment. But expand your view beyond just PCI, and get a feel for whether there are other groups that should be separate from the general purpose network. Maybe it’s your advanced research folks or the HR department or maybe your CXO (who has that nasty habit of watching movies at work). This may not be something you can get done right away because the network folks need to buy into it. But the technology is there, or it’s time to upgrade those switches from 1998. Hack yourself As mentioned above, when you change anything (especially on perimeter facing devices), it’s always a good idea to try to break the device to make sure you didn’t trigger the law of unintended consequences and open the red carpet to Eastern Europe. This idea of hacking yourself (which I use the fancy term “security assurance” for) is a critical part of your defenses. Yes, it’s time to go get an automated pen testing tool. Your vulnerability scanners are well and good. They tell you what is vulnerable. They don’t tell you want can be exploited. So tool around with Metasploit, play with Core or CANVAS, or do some brute force work. Whatever it is, just do it. The bad guys test your defenses every day – you need to know what they’re finding. Revisit change control Yeah, I know it’s not sexy. But you spend a large portion of your day making changes, patching things, and fulfilling work orders. You probably have other folks (just like you) who do the same thing. Day in and day out. If you aren’t careful, things can get a bit unwieldy with this guy opening up that port, and that guy turning off an IPS rule. If you’ve got more than one hand in your devices on any given day, you need a formal process. Think back to the last incident you had involving a network security device. Odds are high the last issue was triggered by a configuration problem caused by some kind of patch or upgrade process. If it can happen to the FAA, it can happen to you. But that’s pretty silly when you can make sure your admins know exactly what the process is to change something. So revisit the document that specifies who makes what changes when. Make sure everyone is on the same page. Make sure you have a plan to rollback when an upgrade goes awry. Yes, test the new board before you plug it into the production network. Yes, having the changes documented, the help desk aware, and the SWAT team on notice are also key to making sure you keep your job after you reset the system. Filter outbound traffic