Cisco Blogs

Cisco Blog > Security

Network Access Control Sure Isn’t What It Used to Be…

Chances are you might be reading this blogpost on a device other than a laptop or desktop computer.  I’d also wager that the device you’re using to read this post handles double-duty – that is, you use it for both work (e.g., checking email, reviewing confidential documents) and play (e.g., Vine, Flappy Bird, social media).

You’re not alone.  Everywhere you turn, you’ll see someone using a smartphone or tablet to be productive – both on corporate and non-corporate networks, for example, a coffee shop’s guest network.  For enterprise IT, this means that the scope of managing an “enterprise network” has really expanded beyond controlling user access to a company intranet to controlling user access to company data across the “extended network” – wherever and however employees choose to do that.

The increased risk due to a larger “attack surface”, fundamentally changes how you approach access control and security.  Traditional Network Access Control (NAC) was technology that, while complex and complicated to deploy, worked well enough when enterprise IT controlled the intranet and the procurement of allowed devices.

However, as the Enterprise Mobility, a.k.a. Bring Your Own Device (BYOD), phenomenon accelerated to become the new corporate norm, traditional NAC wasn’t as effective anymore, due to technology that was overly complex to scale with an overarching need for multiple 802.1X supplicants that generally targeted on more “traditional” endpoints like Windows PCs. As a result, enterprises turned to mobile device management (MDM) platforms as a new way to secure just those mobile devices.  These MDM solutions were definitely easier and less expensive to deploy and manage than NAC and offered a tangible security ROI.

Even today, many organizations continue to use MDM (and its successor, enterprise mobility management or “EMM”) as a bit of a security silo to secure and manage these devices.  However, as is implied, this strategy has a couple of caveats:

  1.  MDM/EMM can enforce device policies (e.g., PIN lock, encryption, whitelisted applications) but offers zero enforcement capabilities for actual network access policies – e.g., restricting corporate network access to financial databases or sales document repositories. The device may be secured, but network access is potentially wide open.
  2. Obtaining 100% full compliance with installing/configuring the MDM/EMM agent on endpoints is nigh impossible, since the MDM/EMM solution works in isolation from other security solutions. Thus, compliance relies heavily on end-user cooperation and participation, which makes it highly likely that non-compliant devices could gain access to the network. From there, who knows what might happen, if the device is compromised.

The net-net here is that enterprises that leveraged solely MDM/EMM to protect their devices and networks are potentially achieving only part of their security objectives.

Fortunately, network access control platforms have seen a renaissance in the past few years and have evolved substantially.  In my last post, I highlighted a recent white paper that discussed how NAC is evolving away from simply basic access or admission control and transforming into a more sophisticated set of controls for endpoint visibility, access, and security – technology dubbed “EVAS” by some. Unlike its overly complex and complicated ancestor, the newest generation of NAC solutions (or EVAS) utilize advanced contextual data gleaned from a number of different sources – including EMM/MDM – in order to enforce granular, dynamic network access policies. In essence, these solutions leverage the network as a sensor in order to make proactive access control decisions e.g., applying different access policy depending on the device being used or the compliance state of the device; or enforcing access to prevent unauthorized lateral movement across a network) throughout the extended network – regardless of how authorized users or devices connect.

This evolution has transformed NAC from a limited security hindrance into a powerful business enabler for enterprises, with more advanced solutions going beyond simple access policy and integrating with other network and security solutions to share data and improve the efficacy of all solutions. For example, here at Cisco, when I attempt to access the network with my iPad, the Cisco Identity Services Engine (“ISE”) (our NAC/EVAS solution) sees my device’s attempt to connect.  It checks the profile and posture of the tablet to ensure that it is compliant with our mobile device wireless access policy (i.e., with MDM/EMM software installed).  If not, Cisco ISE, which is integrated with an EMM/MDM software solution, redirects me to install that software first in order to become compliant before I gain whatever access my particular level of authorization allows on the network.  With this integration between the two solutions, my tablet is now secured with the MDM/EMM software, and my level of access to network resources is seamlessly controlled, down to the letter, courtesy of the NAC/EVAS solution. Caveats solved.

Ultimately, this is just the beginning. Enterprises have realized that the “new NAC” can serve as a viable centerpiece for not only securing access but also for integrating with existing and previously silo’ed security and productivity solutions – like EMM/MDM – that may already be deployed in the enterprise network.

At the end of the day, NAC sure isn’t what it used to be…but that’s, actually, a very good thing.

For an additional perspective on NAC, market trends, and solutions, I invite you to look at the newly-released 2014 Gartner Magic Quadrant for Network Access Control (NAC).

Tags: , ,

Issues and Dilemmas in Information Security Practices

Editor’s note: In A Circular Problem in Current Information Security Principles, we highlighted one of the challenges in our knowledge domain that contributes to the ineffectiveness of today’s information security practices. In this third installment, we review the issues and dilemmas that are common in our practice environment.

One of the challenges information security management teams face is justifying their value proposition to the business to ensure that security requirements receive adequate resource allocations. The paradox here is that if security management within an organization is effective, the results typically show no observable outcome (i.e., no security incident). Interestingly, even if a security incident is not present, it does not necessarily mean that good security management practices are in place. They might be missing because of a security detection mechanism flaw, or simply because the attacker has no interest in carrying out an attack during that time period.

On the other hand, when a security breach occurs, the security manager is often questioned for failure to anticipate and prevent the incident. Security managers therefore often fall back on past or external incidents as a form of justification. Business managers frown on these explanations because they normally do not believe they are no better than their peers or competitors in the industry. Read More »

Tags: , , ,

Continuous Protection on the Endpoint: Show Me

Advanced malware is dynamic, elusive, and evasive. Once it slithers into the organization’s extended network, it can very quickly proliferate, cause problems, and remain undetected by traditional point-in-time security tools. These tools poll or scan endpoints for malware or indicators of compromise at a moment in time, and then do not evaluate again until the next big scan is triggered.

To prevent a malware intrusion from becoming a full-fledged and costly breach, it is important to catch that malware as quickly as possible. To do that, you need to go beyond point-in-time tools, and instead continuously watch and analyze all file and program activity throughout your extended network, so that at the first glimpse of malicious behavior you can contain and remediate immediately.

Read More »

Tags: , , , , , ,

Wiper Malware – A Detection Deep Dive

This post was authored by Christopher Marczewski with contributions from Craig WIlliams

*This blog post has been updated to include Command and Control IP addresses used by the malware.

A new piece of wiper malware has received quite a bit of media attention. Despite all the recent press, Cisco’s Talos team has historic examples of this type of malware going back to the 1990s. Data is the new target, this should not surprise anyone. Recent examples of malware effectively “destroying” data – putting it out of victims’ reach – also include Cryptowall, and Cryptolocker, common ransomware variants delivered by exploit kits and other means.

Wiping systems is also an effective way to cover up malicious activity and make incident response more difficult, such as in the case of the DarkSeoul malware in 2013.

Any company that introduced proper back-up plans in response to recent ransomware like Cryptolocker or Cryptowall should already be protected to a degree against these threats. Mitigation strategies like defense in depth will also help minimize the chance of this malware reaching end systems.

The Deep Dive

Initially we started investigating a sample reported to be associated with the incident to improve detection efficacy. Based off our analysis of e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a we were able to link 0753f8a7ae38fdb830484d0d737f975884499b9335e70b7d22b7d4ab149c01b5 as a nearly identical sample. By the time we reached the network-related functions during our analysis, the relevant IP addresses belonging to the C2 servers were no longer responding back as expected. In order to capture the necessary traffic we had to modify both of the aforementioned disk wiper components. One modification replaced one of the hard-coded C2 server IP addresses with a local address belonging to a decoy VM while changing references to the other hard-coded addresses to point to this local address instead. The other modification simply changed the parameter being passed to an instance of the Sleep() function so debugging efforts wouldn’t be put on hold for 45 minutes (the original sample used a 10 minutes sleep).

When we initially examined a rule that was being distributed in the public we were looking for areas where we could improve coverage to better protect our customers. The new Wiper variant is poorly written code and luckily includes very little obfuscation.The author(s) made the mistake of allocating a buffer for the send() function that surpasses the data they wished to include in the payload: a null-terminated opening parentheses byte, the infected host’s local IP address, and the first 15 bytes of the host name. This incorrect buffer allocation results in the desired data, in addition to some miscellaneous data already present on the stack (including the 0xFFFFFFFF bytes we alerted on in the first revision of our rule).

Simply running the disk wiper component on different versions of Windows proves the miscellaneous data from the stack that we onced alerted on only applies to beacons being sent from Win XP hosts:

Read More »

Tags: , , ,

A Circular Problem in Current Information Security Principles

Editor’s Note: In this second installment of the blog series on more responsive security, we take a closer look at the circular problems associated with four common security principles in managing “weak link” risks in Information Technology organizations.

Before discussing what constitutes this responsive approach to security, let us first look at a few of the fundamental principles of information security to understand the unique challenges organizations face today in managing security risks.

Read More »

Tags: , , , ,