Research

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

A new approach to an old problem One of the more pernicious problems in information security is allowing someone to perform something they are authorized to do, but catching when they do it in a potentially harmful way. For example, in most business environments it’s important to allow users broad access to sensitive information, but this exposes us to all sorts of data loss/leakage scenarios. We want to know when a sales executive crosses the line from accessing customer information as part of their job, to siphoning it for a competitor. In recent years we have adopted tools like Data Loss Prevention to help detect data leaks of defined information, and Database Activity Monitoring to expose deep database activity and potentially detect unusual activity. But despite these developments, one major blind spot remains: monitoring and protecting enterprise file repositories. Existing system and file logs rarely offer the level of detail needed to truly track activity, generally don’t correlate across multiple repository types, don’t tie users to roles/groups, and don’t support policy-based alerts. Even existing log management and Security Information and Event Management tools can’t provide this level of information. Four years ago when I initially developed the Data Security Lifecycle, I suggested to a technology called File Activity Monitoring. At the time I saw it as similar to Database Activity Monitoring, in that it would give us the same insight into file usage as DAM provides for database access. Although the technology didn’t yet exist it seemed like a very logical extension of DLP and DAM. Over the past two years the first FAM products have entered the market, and although market demand is nascent, numerous calls with a variety of organizations show that interest and awareness are growing. FAM addresses a problem many organizations are now starting to tackle, and the time is right to dig into the technology and learn what it provides, how it works, and what features to look for. Imagine having a tool to detect when an administrator suddenly copies the entire directory containing the latest engineering plans, or when a user with rights to a file outside their business unit accesses it for the first time in 3 years. Or imagine being able to hand an auditor a list of all access, by user, to patient record files. Those are merely a few of the potential uses for FAM. Defining FAM We define FAM as: Products that monitor and record all activity within designated file repositories at the user level, and generate alerts on policy violations. This leads to the key defining characteristics: Products are able to monitor a variety of file repositories, which include at minimum standard network file shares (SMB/CIFS). They may additionally support document management systems and other network file systems. Products are able to collect all activity, including file opens, transfers, saves, deletions, and additions. Activity can be recorded and centralized across multiple repositories with a single FAM installation (although multiple products may be required, depending on network topology). Recorded activity is correlated to users through directory integration, and the product should understand file entitlements and user/group/role relationships. Alerts can be generated based on policy violations, such as an unusual volume of activity by user or file/directory. Reports can be generated on activity for compliance and other needs. You might think much of this should be possible with DLP, but unlike DLP, File Activity Monitoring doesn’t require content analysis (although FAM may be part of, or integrated with, a DLP solution). FAM expands the data security arsenal by allowing us to understand how users interact with files, and identify issues even when we don’t know their contents. DLP, DAM, and FAM are all highly complementary. Through the rest of this series we will dig more into the use cases, technology, and selection criteria. Note – the rest of the posts in the series will appear in our Complete Feed. Share: