Research

Driven by the continued noise about the RSA and Comodo breaches, we have spent a lot of time stating the obvious this week. But then I remember that what is obvious to us may not be to everyone else. And even if it is obvious to you, sometimes you need a reminder because you are probably too busy fighting fires and answering questions from senior management (like “Don’t I take dumps in a Comodo?”) to remember the obvious stuff. So, once again, it is time to don the Captain Obvious suit and talk about layered security models. Rich reminded everyone about Crisis Communications yesterday and earlier this week; Adrian ranted about people fail trumping process fail regarding development every day of the week. Now it’s my turn. If you only have one line of defense, such as strong authentication (either two-factor or even a digital certificate) – you are doing it wrong. Yes, we still need layers in our security models. You cannot assume that any specific control will be effective, so you need a variety of controls to ensure critical information is adequately protected. That’s the underlying concept of the vaults idea balloon I have been working on. Depending on the sensitivity of the information, you layer additional controls until it’s sufficiently difficult to compromise that information. Note that I said sufficiently hard – Captain Obvious reminds us that everything can be broken. When you are building your threat models, you don’t assume your user is trusted, even after they authenticate, right? Remember, a device can be compromised after authenticating just as easily as before. Or someone could be holding a gun to your user’s head, which makes most folks pretty well willing to provide access to anything the attacker wants. That’s another reason the RSA and Comodo breaches should be business as usual. Factor in that you now have a bit less trust in the authentication layer. How does that change what you do? This is why we also advocate monitoring everything, looking for not normal, and being able to react faster and better to any situation. Yes, your controls will fail. Even when you layer them. So constantly checking for out-of-the-ordinary behavior may give you early warning that something has been pwned. In a post earlier this week, Rob Graham linked to a South Park clip where Captain Hindsight points out that BP’s critical error was not having a backup valve for the backup valve for the regular valve. Of course. And you know that in your shop Captain Hindsight will make an appearance when you get compromised. That’s part of the job, but you can make sure you are doing all you can to reduce the likelihood that one control failure will provide open access. That means don’t outside without your layers on. Photo Credit: “Captain Obvious” originally uploaded by Gareth Jones Share:

It seems blog popularity is a double edged sword. Yes, thousands of folks read our stuff every day. But that also means we are a target for many SEO Experts, who want to buy links from us. No, we don’t sell advertising on the site. But that doesn’t stop them from pummeling us with a bunch of requests each week. Most of the time we are pretty cordial, but not always. Which brings us to today’s story. It seems Rich was a little uppity yesterday and decided to respond to the link request with a serious dose of snark. Rich: Our fee is $10M US. Cash. Non-sequential bills which must be hand delivered on a unicorn. And not one of those glued-on horn jobs. Must be the real thing with a documented pedigree. I guess Rich thought that it was yet another bot sending a blind request and that his list of demands would disappear into the Intertubes, but alas, it wasn’t a bot at all. This SEO fellow and Rich then proceeded to debate the finer issues of unicorn delivery. Interestingly enough, the $10MM fee didn’t seem to be an issue. SEO Guy: Thanks for getting back. I may have some issues fulfilling your request. The $10M will not be a problem, however I don’t know if you’ve noticed, but unicorns are a heavily-endangered species. Even to rent one would require resources that exceed my nearly limitless budget. Do you know how much a unicorn pilot charges by the hour? Rich: African or European unicorn? SEO Guy: How far do you live from Ireland? Rich: About 7000 miles, but my wife has unknown ancestors still living there and I have red hair. Not sure if that will get a discount. SEO Guy: Would it be okay if the unicorn itself delivered the (what I am assuming is a golden satchel of) money instead? I know you want it hand-delivered (mind out of the gutter) and that unicorns lack hands. Rich: Excellent point and I see that will save on the piloting fees. Yes, but only if we can time delivery for my daughter’s birthday and you also include a frosted cupcake with a candle on it for her. I think she’d like that. You can deduct the cost of the cupcake from the $10M, if that helps…but not the cost of the candle. So yes, as busy as we are with launching our super sekret project, polishing the CCSK training course, and all our client work, we still have time to give a hard time to a poor sap trying to buy a few links for his SEO clients. So every time I’m grumpy because QuickBooks Online is down, the EVDO service in my favorite coffee shop is crap, and I have to restructure a white paper – I can just appreciate the fact that I’m not the SEO guy. Yes, I do have to deal with asshats every day. But they are asshats of my own choosing. This guy doesn’t get to choose who he solicits and I’m sure a debate about unicorns was the highlight of his day of drudgery. Yes, I’m a lucky guy, and sometimes I need an SEO unicorn to remind me. -Mike Photo credits: “Unicorns!” originally uploaded by heathervescent Incite 4 U Testing my own confirmation bias: There are many very big-brained folks in security. Errata’s Rob Graham is one of them. Entering a debate with Rob is kind of like fighting a lion. You know you don’t have much of a chance; you can only hope Rob gets bored with you before he mauls your arguments with well-reasoned responses. So when Rob weighed in on Risk Management and Fukushima, I was excited because Rob put into words many of the points I’ve been trying (unsuccessfully) to make for years about risk management. But to be clear, I want to believe Rob’s arguments, because I am no fan of risk metrics (at least the way we practice them today). His ideas on who is an expert (and how that changes), and what that expert needs to do (have the most comprehensive knowledge of all the uncertainties) really resonated with me. Maybe you can model it out, maybe you can’t. But ultimately we are playing the odds and that’s a hard thing to do, which is why we focus so heavily on response. Now Alex Hutton doesn’t back down and has a well reasoned response as well. Though it seems (for a change) that both Rob and Alex are talking past each other. Yes, my appreciation of Rob’s arguments could be my own biases (and limited brainpower) talking, which wouldn’t be the first time. – MR Careful with that poison: Some days the security industry is like cross-breeding NASCAR with one of those crappy fashion/cooking/whatever reality shows. Everyone’s waiting for the crash, and when it happens they are more than happy to tell you how they would have done it better. As analysts we get used to the poison pill marketing briefs. You know, the phishing email or press release designed to knock the competition down. And there is no shortage of them filling my inbox after the RSA breach. At least NASCAR has the yellow caution flag to slow things down until they can get the mangled cars off the track. But I have yet to see one brief that shows any understanding of what happened or customer risk/needs. So I either delete them without reading or send back a scathing response. I have yet to see one of these work with a customer/prospect, so it all comes off as little more than jealous sniping. And besides, I know RSA isn’t the first security company to be breached, just one of the first to disclose, and I doubt any of the folks sending out this poison could survive the same sort of attack. If they aren’t already pwned, that is. (No link for this one since you all are probably getting the same emails). – RM No poop in the sandbox: Good article in Macworld describing the

Ben Franklin was a pretty smart dude. My favorite quote of his is: “In this world nothing is certain but death and taxes.” For a couple hundred years, that was pretty good. But at this point, I’ll add mergers and acquisitions as the third certainty in this world. Maybe also that your NCAA bracket will get busted by some college you’ve never heard of (WTF VCU?). We saw this over the weekend. AT&T figures it’s easier and cheaper to drop $39 billion buying T-mobile than build their own network (great analysis by GigaOm) or gain market share one customer at a time. And in security, there are always plenty of deals happening or about to happen. Remember, security isn’t a standalone market over time, so pretty much all security companies will be folded into something or other. Take, for instance, WebSense trying to sell for $1 billion. And no, I’m not going to comment on whether WBSN is worth a billion. That’s another story for another day. Or the fact that given Intel’s balance sheet, McAfee will likely start taking down bigger targets. All we can count on is that there will be more M&A. But let’s take a look at why deals tend to be the path of least resistance for most companies. Outsourced R&D: Anyone who’s ever worked in a large company knows how hard it is to innovate internally. There is a lot of inertia and politics to overcome to get anything done. In many cases it’s easier to just buying some interesting technology, since the buyer has a snowball’s chance in hell of building it in-house. Distribution leverage: There are clear economies of scale in most businesses. So the more stuff in a rep’s bag and the bigger their market share, the more likely they’ll be able to sell something to someone. That’s what’s driving Big IT to continue buying everything. This also drive deals like AT&T/T-Mobile, because they are buying not just the network, but also the customers. Two drunks holding each other up: Yep, we also see deals involving two struggling companies, basically throwing a hail mary pass in hopes of surviving. That doesn’t usually work out too well. And those are just off the top of my head. I’m sure there are another 5-10 reasonable justifications, but from an end-user standpoint let’s cover some of the planning you have to make for the inevitable M&As. We will break the world up into BD (before deal) and AD (after deal). Before Deal: Assess vendor viability: First assess all your security vendors. Rank them on a scale from low viability (likely to be acquired or go out of business) to rock solid. Assess product criticality: Next look at all your security products and rate them on a scale from non-critical to “life is over if it goes down.” Group into quadrants: Using vendor viability and product criticality, you can group all your products into a few buckets. I recommend 4 because it’s easy. This chart should give you a good feel for what I’m talking about. Define contingency plans: For products in the “Get Plan B now” bucket, make sure you have clear contingency plans. For the other quadrants, think about what you’d do if there was M&A activity for those offerings, but they are less urgent than having a plan for the critical & fragile items. After Deal: Call your rep: Odds are your rep will be a pretty busy guy/gal in the days after a deal is announced. And there is a high likelihood they won’t know any more than you. But get in line and hear the corporate line about how nothing will change. Yada yada yada. Then, depending how much leverage you have, ask for a meeting with the buyer’s account team. And then extract either some pricing or product concessions. The first renewal right after a deal closes is the best time to act. They want to keep you (or the deal looks like crap), so squeeze and squeeze hard. Call the competition: Yes, the competition will be very interested in getting back in, hoping they can use the deal’s uncertainty as a wedge. Whether you are open to swapping out the vendor or not, bring the other guys in to provide additional leverage. Revisit contingency plans: You might have to pull the trigger even if you don’t want to, so it’s time to take the theoretical plan you defined before the deal, and adjust it for reality now that the deal has occurred. Evaluate what it would take to switch, assess the potential disruption, and get a very clear feel for how tough it would be to move. Don’t to share that information with vendors, but you need it. None of this stuff is novel, but it’s usually a good reminder of the things you should do, but may not get around to. Given the number of deals we have seen already this year, and the inevitably accelerating deal flow, it’s better to be safe than sorry. Share:

It’s hard to believe, but we have wrapped up the initial research on this series dealing with how network security evolves, given the need to provide access to critical information at any time, from anywhere, on any device. We call it any computing. We’ve dealt with the risks and how enforcement and policies will change. And talked quite a bit about integrating these enforcement points into the existing network and security infrastructure. Finally, we wrapped the series yesterday with Quick Wins, about the process of selecting and implementing these technologies. So here is the index of posts. Enjoy. The Risks Containing Access Enforcement Policy Granularity Integration Quick Wins If you missed any of these posts, check out our Complete Feed on the web or via RSS. Then you’ll be sure to get everything we publish. The next step is to assemble these posts, massage a bit, have someone who knows how to write edit the whole thing, and then publish as a white paper. That should happen over the next two weeks. Stay tuned – we’ll post the paper’s availability right here. Share:

We have worked quickly through the main concepts of using network security tactics to provide access to the myriad of endpoint and mobile devices, so now let’s shift to a process to ensure success for your project. This is all about success, so we find the best path is to focus your project on establishing an initial quick win, and then gradually build momentum for the technology with expanded deployment. Step 1: Define Success We know this seems obvious, but it’s amazing how many organizations just start projects without focusing on the problem to solve and how to gauge success. So we start every process by making sure everyone is on the same page regarding what needs to be protected, and from what specific threats. You can do a formal threat model or an informal list of use cases. But you need to know, and everyone else must agree, what success means for this project. Step 2: Establish Deployment Plan What’s next? Protect the most critical information, of course. In this step get everyone on the same page regarding where enforcement points will be installed and how you’ll phase in the deployment. Understand up front that you will be wrong – what makes the most sense may change as you go through the project. This isn’t about carving anything in stone – it’s thinking ahead of time about the best way to solve your problem – before some vendor puts you on a runaway train. Note that all this work happens before you start engaging with vendors. We advocate a strong plan before starting product evaluation. Again, things may change, but if you don’t know what you are trying to get done ahead of time, the odds are you will never get there. Step 3: Technology Evaluation Now you get to suffer though any number of dog and pony shows to establish your short list of vendors. We suggest keeping the meetings focused and making sure you do some homework before sitting with a vendor. Then you’ll at least know when they are blatantly pulling your leg. Step 4: PoC When dealing with complicated technology, we always recommend a proof of concept (PoC) before buying anything. Given the number of integration points for Network Access Control, you’d be crazy not to ensure each vendor could work with your existing stuff. We also believe the PoC needs to be customer driven; which means you define the use cases, integration points, and management tasks to be tested – not the vendor. Surprisingly enough, vendors have a unfortunate tendency to direct you toward the strengths of their products. You need to stay laser focused on solving your problem. Be particularly wary of user experience and day-to-day operations, because once you buy something you’ll be living with it every day for quite a while. Also ensure you have the operational groups on board during the PoC – particularly the network and endpoint folks. Implementing NAC (or something like it) impacts both these areas – often quite significantly. And the last thing you need is another group sabotaging your efforts because you didn’t line up support early in the process. Step 5: Initial Deployment/Quick Win At this point, after you have selected and bought technology (yes, we skipped a bunch of steps, including actually buying the gear), you need to roll it out. For NAC, we recommend most organizations focus on visibility initially. This provides dashboards and reports about what devices are connecting, where they are going, and what they are doing. Gradually enforcement policies for some classes of users/devices can be introduced – once you figure out where the biggest exposures are, based on real usage rather than the theoretical threat model. We favor visibility first because this is about getting a quick win. Breaking users’ ability to get onto the network and do work qualifies as a big loss. To take it a level deeper, given the sensitivity around mobile devices, a logical place to start is monitoring the mobile devices on your network. In our experience this is pretty enlightening, and will clearly drive the first set of access control policies. Alternatively you could scrutinize guest access or folks coming in on the VPN from unprotected networks. We aren’t religious about where you start, but make sure you focus on a place where you know bad stuff is happening. This way you get proof of the bad stuff and then take quick action to block it, which becomes a quick win. Then you can focus on the next area of bad stuff and build momentum for the technology and project. Wrapping up Given that most of these project have some kind of compliance driver, you also need to focus on documentation during the project. Document how you achieve some aspect of whatever compliance mandate you worry doubt. Document how you compare to the success criteria you established early on in the project. Make sure to document the support you lined up from other operational groups throughout the project. That will help when they inevitably push back on deploying the technology for some reason or other. We have spent considerable time thinking about the impact of any computing (providing access from anywhere, at any time, on any device) on how we need to protect our networks. These emerging requirements – especially in light of the avalanche of consumer-oriented mobile devices – are driving us to providing Network Access Control capabilities on our networks. Whether implementing a specific NAC device or using your existing switching and security infrastructure, you need the ability to guard against unauthorized access to your most critical information. This involves a number of choices about integrating with the existing network and security infrastructure, as well as endpoint/mobile device management, depending on the level of remediation required on out-of-policy devices. There are many potential issues regarding this integration and remediation which must be identified and addressed during the procurement process, so focus on a modest initial roll-out which both provides answers for followup and builds momentum though quick wins. It sounds easy, and on paper it is. You’ll find real

It’s easy to be cynical. If you want to look at the negative, things are bad. The economy isn’t great and in many parts of the world it is getting worse. Politics are divisive. The Earth is pushing back at 7.9 on the Richter scale, resulting in a generation of Japanese who may be glowing sooner rather than later. Why do we bother? Security is a microcosm of that. It’s easy to descend into rage about pretty much everything. Budgets, users, senior management, auditors, regulations. I mean everything just sucks, right? I was at BSides Austin last week, and that was the undercurrent from folks at the con. I did my Happyness presentation and it went over pretty well. At least we could laugh at the folly of our situation. When I feel bad, I try to make fun of the situation. Right after I tear something into little pieces, that is. So that presentation is all about accepting our lot in life and learning to enjoy it. They say it’s always darkest before the dawn. Despite my pessimistic view on the world, I’m trying to change – to be optimistic. We are seeing technology advance at an unprecedented pace. The world is a much smaller place with many of these new collaboration capabilities. I mean, a guy can make a living by blogging and tweeting from a coffee shop anywhere in the world. Really. I wonder what technology will look like when my kids enter the workforce in 12-15 years. But in the end it’s about the people. It’s easy to be cynical on the other end of a Twitter client, or as a troll on a blog post. It’s easy to snipe from behind a TOR node. But when you actually spend time with people, you can get optimistic. I mean, look at the outpouring of help and gifts to Japan, and Haiti & Chile before that. And then there are the little things. This week I’m on the road and needed a quick dinner. So I stop into a Chipotle, because I’m a burrito junkie. I notice the woman ahead of me talking about not having any money with her and if they don’t take her coupon, she has to leave. I figure worst case, I’ll cover her burrito since that’s the right thing to do. But the guy at the register is way ahead of me and lets it go. Turns out they did take her coupon and that entitled her to not just her meal, but 2 others. So she turns to me and the lady behind me and says she’s got it. Yeah, man, a free burrito. And that made me remember that one person can do an act of kindness at any time. Maybe it’s funding a Kiva loan. Maybe it’s volunteering at a local food bank or other worthy local organization. Maybe it’s tutoring/mentoring someone without the opportunities you had. The real message of the Happyness pitch is that you have a choice. You can deal with everything either negatively or positively. Yes, it’s a struggle, because negativity is easier – at least for me, and probably for you too. But remember that every time you feel rage, you can turn that around. Do something nice instead of something mean. Novel idea, eh? Now I’ve got to practice what I preach. Talk is cheap and I’ve been talking a lot. Maybe I’ll head over to Chipotle and pay it forward. Maybe you should too. -Mike Photo credits: “happy burrito” originally uploaded by akeg Incite 4 U HP’s Strategy: cloudy and not so seamless: Apparently I drew the short straw and ended up attending HP’s annual analyst shindig. Being locked up in a room with 300 analysts is interesting, but let’s just say it’s good I don’t carry a weapon in CA. HP’s strategy is, amazingly enough, all about the cloud. Their tagline is “seamless, secure, and context-aware.” Hmmm. Security is perceived as important for cloud stuff, so I get that. I’ll even say that on paper HP’s security story is pretty good. But then I hit myself with the clue bat. This is a company that had very few security assets and capabilities – until a year ago they rapidly acquired TippingPoint, Fortify, and ArcSight. Now they claim to be a Top 5 security provider, which seems to involve creative accounting. I guess they sell a lot of secure PCs. As I’ve mentioned before, customers can’t implement a marketecture. They have years of integration work to do, and they need to have a larger presence on the endpoint and with network security products. An IPS is not a network security strategy. So HP will continue to buy stuff. They have to, but the issue is with making their products seamless. Right now it’s anything but. – MR Amazon drops the vBomb: As a loyal Amazon Web Services subscriber I received another morning email update. In my massively sleep-deprived state I figured it was merely another cool service like Elastic Beanstalk, but once the coffee kicked in my eyes popped wide open. AWS added a massive networking update that basically wipes out the divisions between VPC and public instances (if you want) and supports complex architectures such as a hybrid internal data center-to-VPC-to-Internet facing stack. Hoff, as usual, has a good take, and I’ll probably need to write it up for Securosis. After I rewrite significant chunks of the CCSK class. This update isn’t everything a large enterprise needs, but it’s a giant leap forward. Heck, we finally get outbound filtering! – RM Incentives: Tax incentives to promote cyber security? Apparently that’s the idea. But my question is why would voluntary participation be any better for security programs than mandatory compliance? I have two problems with opt-in programs. First, the level of effort is always less than or equal to the incentive, and half-assedfunded security programs don’t cut it. Second, the effort devolves into pure marketing to give the appearance of being secure. Think PCI compliance, but without the audit. Now couple that with complex stacks of software, and try

Supporting any computing – which we have defined as access to your critical information from anywhere, at any time, on any device – requires organizations to restrict access to specific communities of users/devices, based on organizational policies. In order to do this, you need to integrate with your existing installed base of security and networking technologies, ensuring management leverage and reducing complexity. No easy task, for sure. So let’s discuss how you can implement network access control to play nicely in the larger sandbox. Authentication When an endpoint/mobile device joins the network, you can start with either a specific authentication or network-based detection of the device, via passive monitoring of the network traffic or the MAC address of the connecting device. The choice of how strong an authentication comes down to whether building policies based on device and/or location will be granular enough. If you want to take into account who is driving the device into the policies, then you’ll need to know the identity of the user. Although there are techniques to identify users passively, we prefer stronger methods to determine identity; these require integration with an authoritative source for identity information. The integrated directory might be Active Directory, LDAP, or RADIUS. Authentication is either via a persistent agent, a connection portal (provided as part of the NAC solution), or a protocol such as 802.1X. Keep in mind that identity is a dynamic beast, and users & groups are constantly changing. So it’s not sufficient to provide a one-time dump of the directory. You’ll want to check for user/group moves, adds, and changes, on an ongoing basis. At authentication time you need to figure out what’s going on with the device, which involves inspecting it to understand its security posture. Endpoint/Mobile Device Integration The first decision is how deeply to scrutinize endpoints/mobiles when they connect. Obviously there is a time factor to scanning and checking security posture, which can cause user grumpiness. Though most organizations want to make sure devices are properly configured upon access, many aren’t ready to react to the answers they may get. Do you block access when a device violates policy? Even when the user has a legitimate and business critical need to be on the network? As we discussed briefly in the post on policies, you may want to define policies based on the security controls in place on the endpoints/mobiles. Compromising your security by providing access to compromised devices makes no sense, so what remediation should happen? Do you patch the device? That requires the ability to integrate with the patch management product. Do you reconfigure the device? Or update the endpoint protection platform? It depends on the nature of the policy violation and which information that user can access, but you want options for how to remediate. And each option requires support from your NAC vendor. You could just ignore the details and block users with devices which don’t comply with policy, but this tends to end with your rainmaker calling the CEO because she can’t get into the ordering system to book that critical deal. Which presumably won’t work out very well for you. Another consideration is that devices may be compromised after connecting. Detecting a compromised device involves both re-authenticating devices periodically (to ensure a man in the middle hasn’t happened), as well as assessing the security posture of the endpoint/mobile device every so often. Another tactic is to detect compromised devices by their behavior – which requires continuously checking devices for anomalous behavior. Most NAC devices are already monitoring the network anyway to detect new devices, so this anomaly detection capability is frequently available. Now that you know the posture of the endpoint/mobile, you can determine the appropriate level of access it, enforcing that policy at the network layer via integration with other infrastructure. Network Integration There are plenty of ways to enforce network access policies using your switches and firewalls. Let’s take a look at the major techniques: Inline device: Obviously an option for enforcing access policies is to be in the middle of the connection and able to block unauthorized devices as needed. Networking infrastructure players who offer NAC can provide multipurpose boxes that act as inline enforcement points. There isn’t much more to say about it, but this approach has a dramatic impact on network design. CLI: The good old command line is still one of the more popular methods of enforcing access control. This involves the NAC equipment establishing a secure, authenticated session (typically using SSH or SSL) with a switch or firewall and making an appropriate change. That might mean moving a user onto a guest VLAN or blocking their IP from access a protected network. Obviously this requires specific integration between vendors, but given that a handful of vendors control the switch and firewall markets, this isn’t too daunting. That being said, there may be delays in compatibility when network/security gear is upgraded, so make sure to check for NAC support before any upgrades. 802.1X: The standard 802.1X protocol is typically used for authentication on connect (as described above), for which it is well suited. But the protocol also includes an option to send enforcement policies to endpoints, which gets far more involved. Even though 802.1X is a mature standard, interoperability can still be problematic in heterogeneous network/security environments. Individual vendors have generally sorted interoperability between their own NAC and general networking products, but it’s never trivial to make .1X work at enterprise scale. SNMP: Another option for integration with switches is using SNMP to send commands to the networking gear. The advantages of SNMP clearly center around ubiquity of support, but security is a serious concern (especially with early versions of the protocol), so ensure you pay attention to device authentication and session security. * All of the above As usual, there is plenty of religion about which integration technique is best, which continues to amuse us. Our stance hasn’t changed: diversity in integration techniques is better than no diversity. We also prefer multiple enforcement tactics – multiple, layered controls provide additional hurdles for attackers. That means you want

As we discussed in the last post, there are number of ways to enforce access policies for any computing. Given the flexibility and dynamic nature of business, access policies should provide sufficient flexibility to meet business needs. To illustrate, let’s look at how an enforcement mechanism like network access control (NAC) can provide this kind of granularity. What you want is map out access models and design a set of policies to provide users with the right access at the right time from the right device. Let’s focus on mobile devices, the poster children for any computing, and typically the hardest to secure. First we will define three general categories of mobile devices trying to connect to your network: Corporate devices: You have issued these devices to your employees and they are expected to get full access to pretty much whatever they need. You’ll want to verify both the user (strong authentication) and the device itself. It is also important to monitor what the device is doing to ensure authorized use after the pre-connect authentication. Personal devices: Sure, it’s easy to just implement a blanket policy of no personal devices. There are big companies doing that right now, regardless of user grumpiness over not being able to use their fancy new iPads at work. But if draconian isn’t an option in your shop, you could move authenticated, unauthorized devices onto a logical network configured only for outbound Internet access. Or provide access to non-critical resources such as employee wikis and the like but block access to corporate email servers, assuming you don’t want company email on these devices. Everything else: Lots of guests show up at your facilities and try to connect to your networks – both wired and wireless. If they successfully gain access via WPA2 or a physical port, they need to be bounced from the network. This represents the “access” part of network access control. Depending on your pain threshold, there are many other device types and usage models that can be profiled to create specific enforcement policies. Granularity is only limited by your ability to map use cases and design access policies. Let’s not forget that you can also implement policies based on roles. For instance, your marketing group might have network access with iPads, since every good marketer needs one. But if engineers do not have a business justification for iPad use that group could be blocked. Policies aren’t defined merely by what (device) the user has, but also on who they are. Posture-based Policies What about policies based on defenses implemented on the endpoint or mobile device – such as AV, full disk encryption, and remote wipe? Clearly you need to control those devices as well. Being able to restrict users without certain patches on their device is legitimate. Or you might want want to keep end users off of your protected network segment if they don’t have full disk encryption active, to avoid breach disclosure if they lose the device. It’s not just about knowing what the device is, and who is using it, but also what’s on it. As you can see, this is problem includes at least 3 dimensions, which is why getting policies right is a prerequisite for controlling access. We’ll talk more about getting the policies right incrementally when we wrap up the series. Which, once again, brings up our main point. Make sure you can enforce security policies that reflect your desired security posture given the context of your business processes. Don’t force your security policy to map to your enforcement mechanisms. Share:

As most of you know, I’m a huge NFL fan. In fact I made my kids watch the combine on NFL Network two weeks ago when the Boss was away. The frickin’ combine. I was on the edge of my seat watching some guy run a 4.34 40-yard dash. And heard the groans of the crowd when a top rated offensive tackle did only 21 bench presses of 225 pounds. That’s it? And some defensive lineman did 50 reps on the bench. 50 reps. If this DT thing doesn’t work out, I’m sure he’s got a future benching Pintos in the circus. Unless you have been hiding under a rock, you also know the NFL players’ union and owners are locked in a stand-off to negotiate a new collective bargaining agreement. It’s hard to sympathize with either side – either the billionaires or the multi-millionaires. Though when you read this truly outstanding piece by Bill Simmons of ESPN, you get a different perspective, and it’s even hard to feel anything but disdain for the owners. Though I’m not going to shed any tears for the players either. But if you really want, you can feel sad for the biggest bust in NFL draft history, because he made $38 million and still had his house end up in foreclosure. I’m not sure about you, but Wall Street is still one of my all-time favorite movies. Though it’s debatable whether Bud Fox is #winning nowadays. When Gekko does his soliloquy at the annual meeting, anchored by the catchphrase “Greed is good,” I still get chills down my spine. Although I’m not sure I believe it any more. You see, I grew up in a pretty modest home. We weren’t poor, but we weren’t rich either. I had stuff, but not the best stuff. I did things, but my friends did more. So I’ve always chased the money, most likely out of some misguided childhood belief that I missed out on something. That pursuit has brought me nothing but angst. I’ve made poor career decisions. I’ve worked with assholes. And I didn’t get rich. Sure, I’m comfortable and I’m fortunate to be able to provide a nice lifestyle for my family, but I can’t buy a plane. At one point in my life, I’d have viewed myself as a failure because of that. So no more chasing the money. If I find it, all the better, but my career decisions are based on what I like to do, not how much I can make. As I’ve gotten older, I have also realized that what’s right for me may not be right for you. So if you still want to own a plane, more power to you. We need folks with that drive to build great companies and create lots of value and spur the economy. Just don’t ask me to play along. I’m not interested in running a competitor out of business. Nor am I interested in extracting every nickel and dime from our clients or screwing someone over to buy another yacht. And that’s also why I’m not the owner of an NFL team. So I guess my answer is “Greed is not interesting anymore.” -Mike Photo credits: “Greed” originally uploaded by Mike Smail Incite 4 U We suck at hiring: Many of you work at reasonably sized companies. You know, the kind of company with an HR department to tell you not to surf pr0n on your corporate laptop. Those helpful HR folks also lead the hiring process for your security folks, right? This post by Chief Monkey should hit you in the banana (or taco – we don’t want to discriminate). I usually like a rent to own approach. Offer promising folks a short term contract, and if they have the goods bring them aboard. Yes, I know that in a competitive job market (like security), some candidates may not like it. But your organization is probably more screwed up than anything they have seen before, so this provides some risk mitigation for the candidate as well. They could opt out before it gets much more difficult. – MR Just say no (Rich’s take): Believe it or not, sometimes saying no is the right thing to do. I realize we’re all new-age self-actualized security pros these days, but sometimes you need to hit the brakes before ramming into the back of that car parked in the center lane while some doofus tries to finish a text message. Wells Fargo is clamping down on any use of employee-owned devices, and simultaneously experimenting with corporate iPads to supplement corporate smartphones. In a business like financial services, it only makes sense to operate a more restrictive environment and require employees to use personal devices and personal networks for personal stuff. Not that I’m saying the rest of you need to be so restrictive – you are not one of the biggest financials in the world and you probably won’t be able to get away with being so draconian. Heck, thanks to iPhones/Android/Winmo7 your users can still access Facebook all they want while at work… without hitting your network. – RM Just say no (Adrian’s take): Well’s Fargo’s IT department is saying no to personal devices being connected to the corporate network. Part of me says “Good for them!” I don’t use the same machine to surf the web as I do for online banking, so SoD (Separation of Devices) seems like a good idea. Part of me thinks Wells Fargo makes so many bad decisions in general, what if this is wrong too? I started to wonder if we could see a time when the local area network is only partially secured, and the banks let employees use their own devices on the less secure area. What if critical applications and processes are heavily secured in the cloud, as they move away from the users who create a lot of the security problems? Would that be a better model for separating general usage from critical processes and machines? Food for thought. – AL Looking for work, Tier 1 spammer… So Soloway is out of the big house. I wonder if

As we continue with “Network Security in the Age of Any Computing”, we have already hit the risks and the need for segmentation to restrict access to sensitive data. Now we focus on technologies that can help restrict access – which tend to be NAC, firewalls, and other network layer controls (such as VLANs and physical segmentation). Each technology has pros and cons. There are no ‘right’ answers – just a set of compromises that must be made b weighing the various available technology options. NAC Everyone likes to beat on Network Access Control (NAC), including us. The technology has been around for years, and most of those years have been marketed as The Year of NAC. Unfortunately the technology was oversold years ago, and could not deliver on its promise of securing everything. Imagine that – marketing getting ahead of both technology and user requirements. But folks in the NAC space have been (more quietly) moving their products along, and more importantly building NAC capabilities into a broader network security use case. But before we jump in, let’s take a look at what NAC really does. Basically it scrutinizes the devices on your network to make sure they are configured correctly, and accessing what they are supposed to. That’s the access control part of the name. The most prevalent use case has always been for guest/contractor access, where it’s particularly important to ensure any devices connecting to the network are authorized and configured correctly. Of course, under any computing, every device should now be considered a guest as much as feasible. Given the requirement to ensure the right devices access only the right resources, integrating mobile devices security with Network Access Control offers a means to implement control structures so one can trust but verify these devices. Which is what it’s all about, right? So what’s the issue? Why isn’t NAC proliferating through everything and everywhere, including all these mobile devices? Like most interesting technologies, there is still too much complexity for mass market deployment. You’ll need to link up NAC with your identity infrastructure – which is getting easier through standard technologies like Active Directory, LDAP, and RADIUS, but is still not easy. From a deployment standpoint, the management devices need to see most of the traffic flowing through your network, which requires scalability and sensitivity to latency during design. Finally, you need to integrate with existing network and security infrastructure – at least if you want to actually block any bad stuff – which will be the subject of a later post in this series. As folks who follow markets for a living we know that once the hype around any market starts dying down, the technology starts becoming more prevalent – especially at the large enterprise level. NAC is no different. You don’t hear a lot about it, but it’s happening, largely driven by the proliferation of these mobile devices and the need to more effectively segment the network. Firewalls As described in the PCI Guidance we excerpted, our PCI friends believe firewalls are key to network segmentation and protecting sensitive information. They are right that front-ending sensitive data stores with a firewall is a best practice to control access to sensitive segments. Unfortunately, traditional firewalls tend to only understand IP addresses, ports, and protocols. With a number of newer web-based applications – increasingly encapsulated on port 80 – that can be problematic. This is driving the evolution of the firewall to become much more application aware. We have covered that evolution extensively, so we won’t rehash it all here. But in the use case of network segmentation for dealing with mobile devices, scalability of application layer inspection remains a major concern. These devices need the ability to inspect and enforce application layer policies at multi-gigabit internal network speeds. That’s a tall order for today’s firewall devices, but as with everything else in technology, the devices continue to get faster and more mature. All hail Moore’s Law! So these evolved firewalls are also instrumental for implementing a network segmentation architecture to support any computing. Network Layer Controls But the path of least resistance tends to be based around leveraging devices already in place. That means using the built-in capabilities of network switches and routers to enforce required segmentation and access control capabilities. First let’s hit on the brute force approach, which is physical segmentation. As we described in the last post, we believe that Internet access for mobile devices and guests should be on a totally disparate network. You don’t want to give a savvy attacker any chance to jump from you guest network to your internal net. This level of physical segmentation is great when the usage model supports it, but for most computing functions it doesn’t. So many folks leverage technologies such as VLAN (virtual LANs) to build logical networks on top of a single physical infrastructure. At the theoretical level, this works fine and will likely be good enough to pass your PCI assessment. That said, the objective isn’t to get the rubber stamp, but to protect the information. So we need to take a critical look at where VLANs can be broken and see whether that risk is acceptable. There are many ways to defeat VLAN-based segmentation, including VLAN hopping. To be fair, most modern switches can detect and block most of these attacks if configured correctly. That’s always the case – devices are only as strong as their configuration, and it’s rarely safe to assume a solid and secure configuration. Nor is leaving the security of your critical data to a single control. Layers of security are good. More layers are better. But given that everyone has switches and they all support VLANs and physical segmentation, this will continue to be a common means for restricting access to sensitive data, which is a good thing. VLANs + firewalls + NAC provide a comprehensive system to ensure only the right devices are accessing critical data. That doesn’t mean you need to do everything, but depending on the real sensitivity of the data, it shouldn’t hurt. Device Health As described in