Research

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

I’ve been hearing a lot about Virtual Desktops lately (VDIs), and am struggling to figure out how interested you all really are in using them. For those of you who don’t track these things, a VDI is an application of virtualization where you run a bunch of desktop images on a central server, and employees or external users connect via secure clients from whatever system they have handy. From a security standpoint this can be pretty sweet. Depending on how you configure them, VDIs can be on-demand, non-persistent, and totally locked down. We can use all sorts of whitelisting and monitoring technologies to protect them – even the persistent ones. There are also implementations for deploying individual apps instead of entire desktops. And we can support access from anywhere, on any device. I use a version of this myself sometimes, when I spin up a virtual Windows instance on AWS to perform some research or testing I don’t want touching my local machine. Virtual desktops can be a good way to allow untrusted systems access to hardened resources, although you still need to worry about compromise of the endpoint leading to lost credentials and screen scraping/keyboard sniffing. But there are technologies (admittedly not perfect ones) to further reduce those risks. Some of the vendors I talk with on the security side expect to see broad adoption, but I’m not convinced. I can’t blame them – I do talk to plenty of security departments which are drooling over these things, and plenty of end user organizations which claim they’ll be all over them like a frat boy on a fire hydrant. My gut feeling, though, is that virtual desktop use will grow, but be constrained to particular scenarios where these things make sense. I know what you’re thinking, “no sh* Sherlock”, but we tend to cater to a … more discerning reader. I have spoken with both user and vendor organizations which expect widespread and pervasive deployment. So I need your opinions. Here are the scenarios I see: To support remote access. Probably ephemeral desktops. Different options for general users and IT admin. For guest/contractor/physician access to a limited subset of apps. This includes things like docs connecting to check lab results. Call centers and other untrusted internal users. As needed to support legacy apps on tablets. For users you want to let use unsupported hardware, but probably only for a subset of your apps. That covers a fair number of desktops, but only a fraction of what some other analyst types are calling for. What do you think? Are your companies really putting muscle behind virtual desktops on a large scale? I think I know the answer, but want a sanity check for my ego here. Thanks… Share:

There is a caste system in technology. It’s an engineering caste system, or at least that’s what I call it. A feeling of superiority developers have over their QA, IT, product management, and release management brethren. Software developers at every firm I have ever worked for – large and small – share a condescending view of their co-workers when it comes to technology. They are at the top of the totem pole, and act as if their efforts are the most important. It starts in college, where software programs are more competitive to get in and require far more rigorous curricula. It is fostered by the mindset of programmers, who approach their profession more like religion. It’s not a 9-5 day job, and most 20-something developers I have worked with put in longer hours and put in more time into self education than any other profession I have ever seen. They create something from nothing every day; and with software, anything is possible. The mindset is reinforced by pay scales and recognition when products are delivered. Their technical accumen runs far deeper than the other groups and they don’t respect those without it. This relationship between different professions is reinforced when problems arise, as developers are the ones explaining how things work and advising those around them. It’s the engineering team that writes the trickier test cases, and the engineers who comes up with the best product ideas. Heck, of the last four organization I have run, to solve serious IT issues I had to assign members of the engineering team to debug and fix. They are technology rocks stars and prima donnas. Right or wrong, good or bad, this attitude is commonplace. Why do I bring this up? Reviewing the marketing and sales collateral from several security vendors who are applying their IT marketing angles to software developers, I see a lot of approaches that will not work. When it comes to understanding buying centers, those who have traditionally sold into IT don’t get the developer mindset. They approach sales and marketing as if the two were interchangeable, but they are not. The things developers consider important are not the same things the rest of IT considers important. It is unlikely your “IT Champion” can cross-pollinate your ideas to the development team – both because your champion is likely seen as an outsider by the developers and due to internal tension between different groups. Development sets development requirements. White box test tools? Web application assessments? WAF? Even pen testing? These all need different buyers, with a different mind set and requirements than the buyers of other IT kit – especially compared to network operations gear. The product and the value proposition needs to work in the development context. Most sales and marketing teams want to target the top – the CIO – and work their way down from there. That works for most of IT, but not with developers who have their own set of requirements over and above business requirements, and often neither fear nor respect upper management. They are far less tolerant of marketing-speak and BS and much more focused on getting things done easily, so you had better show value quickly or you’re wasting time. UI, workflow, integration, and API options need to be more flexible. When it comes to application security, it’s a developer’s world, so adjust or be ignored. Share:

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