For instance, NAC has been finding increased traction within the traditional enterprise as businesses expand their use of SaaS solutions and cloud services. Just think about how many sales organizations have implemented online cloud-based CRM offerings such as Salesforce.com or NetSuite. More and more companies are moving away from purely in-house solutions, and looking at MSPs and saying, “I want you to manage my X” or “I want to leverage your infrastructure to do Y.”   As a result, companies are employing a combination of on-premise equipment and cloud services. And, oftentimes, that erodes their security focus. Instead of discussing NAC strategies and how they can help protect corporate assets, companies talk about how they can secure the cloud services, SaaS, and other services beyond their perimeters that they don’t necessarily control.

NAC is also finding its place as growing IT environments become increasingly difficult to manage and maintain. A homogenous Windows environment may still have four different flavors of Windows running, two different versions of Windows server… you get the point.  That is a challenge in and of itself, but add the need to support Smartphones (Androids, iPhones Blackberries, etc), iPads, hand scanners, you name it, and you’ve got a growing, disparate environment that is further dissolving the hard perimeter of yesteryear. Don’t forget about trends such as telecommuting! The results? A management conundrum as the perimeter continues to deteriorate.  The big question is: how do we secure all those devices?

Higher education has been successfully dealing with these very challenges for quite some time. Students want to use divergent technologies, such as laptops for doing schoolwork, Smartphones, gaming consoles, and DVRs, all of which connect to the network and want Internet access. This alone creates a heterogeneous environment that is challenging to manage. Higher education institutions have responded in a number of ways including strategically using NAC to adapt effectively to the hyper-changing environments.

Rather than trying to control and manage every end point, NAC audits the end point and enforces access based on the results. Auditing end points enables organizations to provide healthy networking environments. This concept can be equated to secondary school requirements that parents deal with every year – every child must have an annual doctor’s check-up and be up-to-date on certain immunizations so that he or she can attend school. Within information security, organizations can see whether or not a user has up-to-date antivirus software, a firewall running, etc., segregate them into the environment based on the results, and allocate specific resources to the user to make them healthy. For example, if a user doesn’t have the latest antivirus software, the organization can restrict access to all network resources except those necessary to update their antivirus software. The user is granted access to the rest of the network only after the antivirus software is downloaded.

Commercial organizations are now revisiting NAC and looking at the solutions and strategies that Higher Education as employed. Do you think it’s possible for them to achieve this level of control?

Jason Prost
Solutions Engineer – Accuvant

Sorry to be the bearer of bad news, but DiD can actually make the job of an attacker far easier than it otherwise would be, depending on how it is implemented. Here’s why: as the complexity of the data that is processed increases, it becomes easier for an attacker to introduce an exploitable vulnerability. Therefore, when an attacker is culling the potential target list, they will focus on the applications that process the most complex data. Anti-virus applications are a pretty good fit.

There are companies that implement as many anti-virus products in as many places as their budgets will allow because they think this strategy will keep them safe. They’ve got anti-virus software on workstations, email gateways, proxy servers, network attached storage, mobile devices, messaging, gateways, FTP and HTTP traffic analyzers, and soon enough, they’ll have it on any other technology that stores or transmits files. This strategy gives the attacker a path into each of these systems and allows them to bypass each segmentation layer that may exist within the network. This strategy also makes end users feel invincible, and often leads them to participate in more risky online behavior. When a false sense of security is established, a user may use the same machine to perform risky online behaviors that they use to perform financial transactions, putting sensitive personal or corporate data at risk.

So, what security measures will work without providing additional opportunities to attackers?

Patching the underlying error within the code is the easiest way to keep a vulnerability from being exploited. This process increases security without increasing the amount of code an attacker can interact with. While it is the most straightforward solution, many organizations fail to quickly patch vulnerabilities because of time constraints, management issues or because the patch causes a mission critical application to fail.

Virtualization can provide a computing platform where dangerous operations can be performed and relatively little effort expended to revert the virtual machine to the exact state it was before dangerous actions were performed. The biggest danger with virtualization is that attackers can leverage vulnerabilities to move between the virtual machine and the host machine. As long as the virtual machine software is kept up-to-date with the latest patches, then an attacker would have to use a zero day exploit.

Another effective strategy is to remove infrequently used features from software packages. In general this approach is not commonly employed because software developers feel the need to maintain backwards compatibility, a tendency that is driven by end users who want to be able to access and manipulate historical documents. Here’s a workaround: include a separate program that updates documents produced by outdated versions of a program to the newest version. This enables the backwards compatibility that some end-users desire while keeping the main program lean with regard to rarely used features.

The bottom line is that DiD increases the attack surface available to an attacker and can lead to assumptions that further increase risk to an organization. When implementing a security strategy, it is always preferable to limit the amount of code that processes potentially malicious data.

Ryan Smith
Chief Research Scientist – Accuvant LABS

1. There is truly a need for the application.  There must be an honest business need for the application. If not, organizations should seriously question the decision to use it. This must be carefully considered as every application chosen to support an enterprise-level need increases the overhead of an organization’s IT staff in terms of security and management responsibilities.  Many things are “nice to have,” but, at the end of the day, they simply decrease an organization’s security posture and tax already stressed resources.
    
2. The application can be thoroughly supported by the vendor or with available third-party resources.  Before using an application, the organization should determine how well they can support that application. It’s not wise to tie the success of an enterprise to an application that is overly difficult to manage or maintain. If the application does not have active vulnerability discovery and remediation support, requires management and support overhead that the organization cannot supply, relies on program or system support that negatively impacts the organizations business continuity management program, or contains areas of management and/or security vulnerabilities that cannot be sufficiently addressed using available native or third-party solutions, then the use of the application is likely not a good choice. Too often, we become fascinated with the shiny new car and forget to consider if we have the ability and money required to keep the car running.

Examples of applications that companies should be concerned about include social media and older legacy applications.  These show both ends of the software spectrum – the new and the old.  Both, however, have concerns that must be addressed before they are allowed into the enterprise.

Social media is a rapidly expanding area, and, in many cases, these applications can definitely have legitimate business uses.  However, organizations should consider the dangerous concerns that social networking applications present concerning unauthorized data loss, loss of worker productivity, bandwidth and system resource consumption, and possible infection vectors for compromised code and malware.

Older, well-known applications are often used in favor of newer versions of the same systems.  Companies must consider that the cost savings made in not upgrading to newer versions may be offset by inherent security risks. Widely published and well-known security vulnerabilities contained in these programs can be easily compromised using tools openly proliferated across the Internet.  Also, the software may be at the end of its support lifecycle or tied to older hardware that is no longer easily available for replacement.  Older protocols and operating systems may have a legitimate business use, but, given the wide variety of more secure, supported, and commercially viable options available, the continued use of these products are likely more of a risk than benefit.

What litmus test does your organization use to determine whether or not to deploy a specific application in your environment?

Chris Gray
Senior Risk and Compliance Management Consultant

The most serious concerns are related to connectivity via email, Web, SMS and enterprise applications. This, combined with the ever-increasing local storage capabilities and 3G/4G speeds on smartphones, increases the potential for exposure of sensitive, confidential and legally protected data. On top of that, most users are not incented to comply with security policies before they are allowed to connect to email. Finally, lost or stolen devices that have sensitive data can be compromised, and most phones do not have any encryption capabilities on them or on their memory cards.

Despite these concerns, companies continue to add more and more mobile phones as time goes on. There has also been a noticeable shift in corporate phone policies in recent years. Previously, most companies provided their users with specific phones, usually based on one operating system. Now, many companies are allowing users to go and buy whichever type of phone they prefer. This change proves that businesses don’t feel that they can slow down and wait for smartphone security technology to keep up. Executives and IT gadget hounds are swapping up to the latest and greatest phone platforms faster than their security administrators are able to add corporate network support and safeguards.

While productivity outweighs the risks for many of the organizations that we work with, we are starting to see more and more smartphone companies keep pace with the new code being released on the mobile OS platforms. That’s good news from a security perspective but it is a cat and mouse game and there is always a lag from when a new OS release comes out and when the proper security mechanisms catch up. There are also plenty of actions that IT can take to securely integrate these devices. An important first step is to develop mobile security and acceptable use policies. Next, we recommend the IT team perform user awareness training with employees – a step that is often overlooked. Another best practice is to implement a safeguard technology for the smartphones that will protect the organization from risk related to exposure of legally protected data, loss of critical intellectual property and non-compliance with business critical regulations. Fortunately, there are enterprise solutions that provide numerous security enhancements to the disparate list of phones in use by most organizations.

Accuvant works with many smartphone security vendors that provide a single console to manage smartphone protection across these disparate platforms, such as iPhone, Palm OS, Symbian, Android and Windows Mobile. It is best to deploy a solution that can manage and support smartphone security and connections with a complete over-the-air (OTA) environment (with no connection to PCs or local networks required) for enrollment, provisioning, reporting, policy control, self-service user portals, on-device encryption of all enterprise data, and kill pill capabilities that remove only the enterprise data on the device along with help desk and recovery from lost passwords.

Are you losing any sleep over your organization’s smartphone security practices?

Matt Bossom 
Accuvant Program Manager – Technology Solutions

Originally, rootkits started off as replacements for system programs that might show traces of an attacker.  These replacements had additional code added into them to prevent the legitimate system owners from seeing the traces an attacker had left behind.

Companies developed software to detect the rootkits’ presence so that they could combat them. These pieces of software took simple cryptographic fingerprints of legitimate binaries and periodically compared them against the installed software.  If a single bit of the file was changed, the fingerprint was dramatically changed. As a result, these tools were extremely effective in detecting rootkits.

Unfortunately, as rootkit countermeasures matured, attackers also evolved their tools. All of the programs that could potentially show traces of attacker activity relied on a central piece of software: the kernel.  So, attackers found ways to modify the kernel to hide their traces. They were able to combat the signature-based anti-rootkit technology, which marked the start of a trend that continues to this day – the high-tech game of cat and mouse. As software has continued to evolve to meet the needs of rootkit detection by staying up-to-date with the latest trends, rootkits have continued to evolve by delving deeper into the system.  The trend went from modifications of system programs, to modifications of the kernel, all the way to modifications of the system BIOS and leveraging processor virtualization features.

Computer hardware manufacturers have been pushing Trusted Computing out incrementally over the past few years. And, Trusted Computing could turn out to be an end to the game of cat and mouse. However, if history has anything to say then it will just be another turn in the game.

Ryan Smith
Principle Researcher – Accuvant LABS

But, here we are, nearly a year and a half later, and a recent healthcare survey conducted by the Healthcare Information and Management Systems Society (HIMSS) found that many hospitals, behavioral health sciences organizations and doctors offices, and their business associates are still unprepared to meet the new HITECH provisions. Why? Because the impact of HIPAA HITECH is far reaching, and can be overwhelming to businesses that fall within its scope.

Understanding the provisions and implications is the first step in achieving compliance. It is also a necessity if you’re going to build policies and practices that adhere to HIPAA/HITECH, and potentially secure some of those stimulus incentives. Here are what I deem to be some of the most important requirements:

• All of the elements of the HIPAA Security Rule. While the Final Rule has been in place since 2003, many organizations took a “wait and see” approach to fully implementing these standards for protecting electronic protected health information (e-PHI). HITECH should be seen as an opportunity to revisit the overall alignment with HIPAA security and improve current security practices.
• Under HIPAA/HITECH, business associates of covered entities such as health plans and providers are subject to HIPAA privacy and security rules. As a result, those associates are now required to implement appropriate safeguards. In addition, covered entities must now re-evaluate the way they manage contractual relationships with these entities to make sure that all patients are protected.
• The ARRA requires the U.S Department of Health and Human Services (HHS) to audit covered entities and their business associates regarding HIPAA privacy and security compliance, and to formally investigate a covered entity or a business associate upon receipt of a complaint. Under the ARRA, penalties can range, depending on type of violation, from $100 to $50,000 per violation, with a cap of $25,000 to $1.5 million per year for violations of an identical requirement during the same calendar year.
• The HIPAA security standard did not previously include explicit breach notification requirements. Now, individuals affected by a breach of the privacy and security of their e-PHI must be notified within 30 days after HHS issues guidance. Breach notification applies to covered entities, but also extends to their business associates.

The bottom line is that regulation complexity continues to increase, combined with stiffer penalties and disclosure requirements for breaches. It is imperative that healthcare participants understand the implications for their organizations and respond appropriately.

Evan Tegethoff
Solutions Architect – Risk and Compliance Management

There’s one major problem with this “throw money at the compliance requirements” approach. It does not necessarily make companies more secure. GLBA, for instance, requires that organizations protect their financial data, but it does not address most forms of privacy-related information or intellectual capital. PCI is driving companies to spend entire annual IT budgets on point solutions to address specific elements of the Data Security Standard. Unfortunately, with all of these requirements and costs, many of the organization’s other security program elements are pushed aside, leaving much of the company’s sensitive data (not related to cardholder information) with a much less secure posture. HIPAA protects medical privacy information around patient care.  It does not, however, require many other important elements of a well functioning security program such as effective vulnerability management and risk-based decision making. Sarbanes-Oxley Section 404 assesses the effectiveness of internal controls around financial information, but beyond this scope, the security environment is largely ignored.

With all of these competing demands, companies are spending incredible amounts of money to achieve compliance, focusing on the checklist of required controls to avoid fines and reputational stigmas. Unfortunately, in addressing the specific goals of a specific regulatory requirement, the organization misses out on implementing a complete and well functioning security program.  Rather than drive security strategy and architecture, compliance should instead be viewed as a result of an overall approach that ensures a proper data lifecycle – proper data classification, proper data collection, protection, storage and disposal. This distinction is critical since, in my experience, companies that do not adopt the viewpoint of proactively addressing proper data lifecycle rather than simply treating specific issues usually end up in a perpetually cycle of reactive fire-fighting.

Here’s a real world example to illustrate my point. One organization, a retail company with thousands of remote store locations, was aggressively addressing PCI requirements and spent a significant amount of money on point solutions to achieve compliance. Late in the effort of checking off all the PCI DSS compliance boxes, the organization, wisely, took a moment to begin an inventory of all valuable data that resided in their systems. One issue that arose was the presence of unencrypted data elements that could, together, be used to establish user identity – a definite risk for privacy violations by most state data protection and breach notification legislations.  This information, however, was not a PCI issue, and it was shelved for remediation at a later date.

Unfortunately, before the changes could be implemented to address the issue, a physical breach occurred and the information was lost.  An immediate assessment took place, involving external expertise to identify legal and regulatory requirements to address breach notification costs, required notification communications, and steps to address customer concerns such as credit reporting agency support to provide ongoing monitoring of credit-related issues to affected customers.  Total cost?  More than a quarter-million dollars to perform extensive privacy reviews, and nearly the same amount in external counsel fees and lost internal manpower hours. PCI fines are sometimes extensive, but agreements can often be reached with the acquiring bank(s).  Shelving that real risk in favor of concentrating on compliance had a much more immediate, and likely expensive, price tag.

So, what is the lesson learned here?  This situation should have been addressed by first pausing a moment to understand the totality of the problems before spending a cent on point-in-time, point-of-presence fixes. The second step should then have been to understand what solutions, from a conceptual point of view, needed to be implemented to mitigate the risks rather than just focusing on a checklist approach.  Then, with risks identified and minimized through data lifecycle management, the scope of “real” work could have been reduced, and technology and process implementation could have been relied upon to truly secure the enterprise.

I guarantee that following a risk-based approach rather than a compliance-focused approach would have resulted in far less expense, greatly reduced the amount of time lost reacting to an emergency situation, delivered effective protection of carefully researched and identified sensitive data, and provided compliance with specific PCI requirements as well as other applicable regulation and standards.

Chris Gray
Senior Risk and Compliance Management Consultant

In the old days, when Web 1.0 was all the rage, a website developer or administrator published all the content for end users to read. Things were relatively safe as long as certain protection mechanisms were in place. But, life has become more complicated in recent years with the launch and subsequent popularity of Web 2.0. This new age of collaboration introduced a fun and innovative way for end users to communicate via social media sites such as FaceBook, Twitter, MySpace and many many others.  However, because social media sites pull content from multiple sites and servers, Web 2.0 has made it significantly more complicated for you to truly secure your users’ browsers.

Trust is really at the root of the problem.  Social networking sites give users an inherent sense of trust that they shouldn’t have. And, unfortunately that trust opens the door wide open for a variety of new attack vectors. If you don’t have the right policies and solutions in place, there’s a pretty good chance that sooner or later the bad guys are going to use social media to access your corporate data.

How will they do it? There are a few different strategies we’re seeing. 

1. In some instances, criminals are creating malicious websites (or infecting legit sites due to their own vulnerabilities) that have malware installed and are redirecting users in various ways to those sites. Once a user goes to the malicious site, their system becomes infected with this malware.  At this point, the attacker is purely limited by their imagination on what could happen next.  Most commonly, the malware starts harvesting information from your user’s system, such as their passwords or corporate information.  The malware then attempts to either stream this information back to a predetermined host controlled by the attacker, or utilizes a batch process to email or funnel this information out to the attacker.
2. As of late, spear phishing is the attack strategy of choice. With this method, criminals gather information about your employees from social networking sites. 

This brings up another common oversight or gap in many organizations current information security policies.  As an example, should your employees be allowed to disclose that they work for you?  How about the division of the company they work in?  How about what project or program they are working on?   All of this type of information can be used in a spear phishing attack. 

Once the attacker has gathered enough information about their intended target, they start sending personal emails to your end users to gain their trust, and then direct them to websites or applications to install, which facilitates the malware infection. Cross-domain attacks are also common. This strategy influences users to click on links they normally wouldn’t have because of their newly assumed trust level with the attacker’s bogus company or request.  Once infected, again, it’s up to the attacker’s imagination at this point on what they wish to do with their new victim.  

There are a number of things you can do to protect your company and mitigate the threats:

• Implement an IT security program with sound policies – Adopt or update your existing Acceptable Internet Usage policy to inform your employees on what types of information they are allowed to post online about your company to reduce the possibility of spear phishing.
• Implement the right technologies – At this point, you should already have anti-malware/anti-virus software installed on every corporate computer to attempt to cover your end users. In addition to this, you should consider investing in data leak prevention solutions, to help enforce your corporate policies on what is acceptable content to post online or even be allowed to leave your network.
• Continually educate your employees – a lot of cybercrime relies on an end user’s lack of knowledge. Continually update and performed user awareness training sessions or “brown bag” events to teach your users the common threats they will face, as well as update them on the latest attacks being carried out.

 Jim Broome
Director – Accuvant LABS

Interestingly, many medium to large sized enterprise networks today still have distinct service provider characteristics. The network groups often contain extremely strict SLA requirements, have the need to utilize network virtualization to lower real estate footprint in costly data-center space, and depend on departmental charge-backs when services divisions need to re-coupe cost associated with supporting the businesses network requirements. In some cases, enterprise professionals find that their company’s network has been architected into a corner; when new business requirements come down the pike, the entire network needs to be re-assessed and in many cases, re-designed.

Because many IT professionals still relate MPLS to a service provider technology, they don’t realize the value it can deliver to their enterprise. MPLS is an open standard supported by the majority of vendors that manufacture switches and routers, and can help even the largest networks in world to scale their infrastructure, services and mission critical business applications. Not only does it provide a topology that’s built to scale, it gives managers the ability to quickly respond to new requirements while still achieving an extremely capable and highly resilient network.  Importantly, even if a network re-architecture is required, this is a small investment compared to the alternative, which requires capital expenditure. 

When planning for tomorrow, networks must be increasingly agile in order to keep pace with the ever-changing business requirements that dictate network architecture. Network segmentation and enhanced security and performance on an application or user basis are just a few examples that can be handled with ease in an MPLS environment.  Another great feature is that enterprise network operators have the choice of building, buying or both when it comes to deploying MPLS. Increasingly, deployments are a “hybrid” solution, with some of the WAN outsourced to a service provider and the rest built using the company’s internal DWDM/dark fiber infrastructure.

Other appropriate uses for MPLS include WAN consolidation projects that require disparate WAN connections to be combined into a single network, virtualized network core projects that result in true, independent separation of layer 2 and 3 network services, and transport network conversions of costly SONET/DWDM infrastructure to MPLS.

In conclusion, the benefits of MPLS should not be ignored. It can make an organization’s existing network more agile and keep cap and op ex budget intact.  MPLS is an extremely scalable and flexible technology that is underutilized because many network operators fear it will add complexity. The truth is management will be simplified when organizations achieve a consolidated IP Based network with traffic engineering capabilities and dynamic network service provisioning.

Thomas Perniciaro
Solutions Architect – Accuvant

Do you really understand the true risk to your sensitive data and critical systems? If not, it’s time for you to do a little soul searching and find the answers to some really important questions, such as “What really matters to my organization from a security perspective?” And, “Where are we failing to secure our critical assets?”  Given the inability of most organizations to apply adequate time and/or budget to simultaneously tackle every potential security issue, you really need to answer these questions so that you can identify and address your truly critical concerns first.  I’ve seen too many organizations run around in circles trying to secure the next items on their radar – an approach that more often than not turns out poorly.

Here’s what I recommend: use risk to determine the priority of your security initiatives. Take a systematic and effective approach to your security program by first understanding the business drivers in each of the business units. Don’t know where to start? Ask yourself, “How does this unit make money?” Although a bit simplistic, this is a great place to start. From here you should be able to identify mission-critical assets – those are the assets required by the critical systems you just identified.

Once you have identified critical systems and assets, you now know what to protect, but from whom? And what? Categorize and determine the capabilities of the most likely threats you have to these critical systems and assets. Then, determine the vulnerabilities you have in your existing security controls and identify the effort required to exploit these vulnerabilities. Then, start tackling the risks that could most significantly impact your enterprise. Sound like a lot? In all truthfulness, a risk-based approach – especially if legal and regulatory requirements are a concern- is the most efficient way to gain accurate visibility into your current state of compliance and identify what steps are required to mitigate gaps. And, if you need help, check out our new Information Security Risk Assessment service.

Once you’re headed down this path, it is natural to wonder if you have too much or too little security and if you’ll know either way. And that’s great – at least you are considering both ends and that means balance. It is important to understand that critical systems and sensitive data are not the only assets of your company – so is money and time. There is such a thing as too much security. The spending of resources on security improvements should be limited by the value their implementation brings to the protection of other assets (capped by asset value).

You should put enough effort into security to reduce the real, validated risk to an acceptable amount. When security efforts are a hindrance to your business processes beyond the value of what is being protected, your company has too much security in place.

I’ve just thrown a lot at you so let me give you a good rule of thumb. When you start worrying more about how much you are spending on security than you are about your assets being compromised, then you are spending too much. If you are still worried about the protection of your assets over security spending, you have put in too little.  Re-evaluate, re-address and re-implement.

Have you been taking the right approach? Can you demonstrate that to management?

Doug Landoll
Practice Director – Risk and Compliance Management