5 Keys for Moving Enterprise Security to the Cloud

The worst economy in 70 years hasn’t deflated the cloud: In 2009, cloud services were already a $16 billion market, says research firm IDC. By 2014, global cloud revenues will hit $55.5 billion, growing five times faster than other IT products.

It’s not hard to see why enterprises large and small are flocking to the cloud. The cloud reduces IT capex and opex by shifting those costs to the enterprise’s cloud provider. That’s an obvious benefit even in flush times, but it’s even more attractive when the recession has CIOs and IT managers looking to run as lean as possible.

Cloud computing also helps enterprises stay nimble -- by enabling them to take advantage of new technologies faster than if they had to buy and deploy the equipment themselves, for example. That flexibility can produce competitive advantages, including rolling out services quickly to respond to changing market conditions.

Another big draw is the ability to scale IT systems up and down to meet changing needs, such as peaks during the holiday shopping season. That lets enterprises be more responsive to a flood of new customers, but without purchasing IT infrastructure that would be underutilized between peak periods.

5 Tips for Fighting Breaches

As any CIO or IT manager is quick to add, the cloud’s benefits can’t come at the expense of security. Even minor breaches can have big implications, ranging from a PR nightmare and class action lawsuits when confidential customer information is compromised, to jail time if it turns out that lax security policies violated laws. Worst-case scenario: a breach so big that Congress enacts a law nicknamed after the company.

Some enterprises have an internal cloud, others work with a cloud provider and still others have a combination of the two. These tips apply to all three models:

1. Start clean.
Some enterprises require their cloud provider to put their data only on brand-new servers. They believe it’s impossible to remove every trace of former tenants and that this electronic detritus creates back doors for hackers.

2. Secure access to the cloud.
Implement strong authentication mechanisms to secure every Web path that provides access to the cloud. Ditch simple, password-based logins in favor of multifactor authentication. In fact, some industries mandate this. One example is financial services, where since 2006 the FFIEC has required banks to use multifactor authentication to protect logins into their sites. Also, take a look outside your industry to see if there are any regulations and best practices that you could adopt or adapt to beef up cloud security.

3. Safeguard the data in the cloud.
This is another place where it’s key to keep up with industry-specific laws and best practices, including ones that can be borrowed from other sectors. For example, the Payment Card Industry (PCI) standard specifies physical and logical controls for data both when it’s at rest and in motion, while HIPAA provides similar requirements for medical data.

4. Verify and audit.
Third-party auditors can verify that your cloud or your cloud provider meet security and privacy laws, as well as any industry-specific best practices. Besides PCI and HIPAA, audits may look at compliance with SAS 70 which covers application security, physical security and security processes. Another is ISO 27002, which lists hundreds of options for security management.

5. End clean.
PCI is also an example of how some industries require that data be destroyed, including the hard drives. That includes when switching cloud providers: The contract should spell out exactly how data must be destroyed.

Need more tips? Check out Cloud Computing: Benefits, Risks and Recommendations for Information Security, a European Network and Information Security Agency report that covers 35 common risks and strategies for mitigating them. These tips are applicable in every part of the world. You can read more about consumer focused cloud security here.

Sourcefire Expert Explains Next-generation Firewalls

As security threats evolve, so must firewalls -- but not at the expense of network performance. That’s one factor that enterprises need to consider when developing a strategy for next-generation firewalls.

Nearly half of the medium and large enterprises in a recent Ponemon Institute survey sponsored by security vendor Sourcefire have deployed a next-gen firewall. The survey also found performance degradation to be a major concern. Jason Lamar, Sourcefire’s senior director of product management, recently spoke with Intelligence in Software about how next-gen firewalls work and the architectural options.

Q: What exactly is a next-gen firewall?

Jason Lamar: It’s a combination of threat prevention, access control and application control. The next-generation part is about going beyond the traditional language of writing firewall policies, where you use users and applications as the way to communicate what the policy means and how it would be implemented. That’s the common definition out there in the marketplace.

Sourcefire has a little different perspective. Our belief is that you really need to have a next-generation intrusion-prevention system (IPS) as a component of a next-generation firewall. That requires contextual awareness, which is the systematic understanding of the network that you’re trying to protect, as well as all of the relevant information about the endpoints, files, users, applications and operating systems. You need to know all of that stuff about your environment in order for your system to work effectively as a next-generation security solution. We believe that you need to have contextual awareness and an enterprise-quality IPS to really be next-generation.

Q: What’s an example of the kinds of threats that a next-gen firewall would catch?

J.L.: Traditional firewalls that look only at ports and IP addresses won’t pick out anything that’s especially evasive. So a traditional firewall won’t find command-and-control channels that have been set up by an owned host inside your network, for example. And a traditional firewall that just added on good-enough IPS -- more of a Unified Threat Management approach -- won’t have the extensive evasion prevention and traffic normalization good enough to detect rapidly changing threats.

Q: So a next-gen firewall would be doing things such as filtering by signatures and reputations, right?

J.L.: Yes. The reputational component is there as an additional context, so to speak. It’s about detecting things at a high accuracy. If you look at the kinds of testing you do for a next-generation IPS, like we do at NSS Labs, and you compare that to what the traditional firewalls have in terms of threat prevention, there’s a big gap.

Q: Encryption can provide a shield for malware. Isn’t that why a next-gen firewall decrypts traffic?

J.L.: Definitely. It is a component of a next-generation firewall architecture. Most next-generations don’t do this well, though. Their performance doesn’t scale. Some vendors will tell you that you need embedded SSL decryption, but when you turn that on, the whole performance of the system tanks.

You really need an architectural approach to decryption. Why impact your IPS and application-control performance when you could have a standalone, scaling appliance to do that decryption?

By the way, most enterprises have some other reason to want to decrypt SSL than just to do the next-generation firewall components. A lot of times, there’s a content gateway there that they want to interface with or some other thing that they want to have looking at the traffic. If you go with the next-generation firewall with embedded SSL, you miss an architectural trick in offloading SSL so you can use it for multiple security inspection points.”

Q: Any other architectural tips one should consider when developing a next-gen firewall strategy? Any pitfalls to avoid?

J.L.: A lot of enterprises are struggling with whether to displace their whole firewall infrastructure for a new, next-generation firewall versus supplement and augment with next-generation firewall as an additional control behind their traditional firewall. Not every enterprise is ready to make that move or has the financial resources to make that move quickly.

Q: That ties in with the survey, where 56 percent of respondents prefer augmentation rather than replacement.

J.L.: For many organizations, it’s just too much to switch all that around when the real benefit you’re trying to get is better security and that’s really delivered through the threat-prevention and application-control components. Why change the thing that’s working and that’s operationally and organizationally the most difficult to move when you really want to get application control and better threat prevention?

A lot of customers think they’re going to buy a next-generation and switch all of their policies over to the thing with a couple of mouse clicks. That’s usually not the case, and typically it’s not advisable. Take the opportunity to rationalize the policies you should have now versus carrying forward a policy that doesn’t match what you’re trying to do.

Photo: @iStockphoto.com/alexsl

McAfee’s Edward Metcalf Shares Hybrid Rootkit-thwarting Strategy

It’s been 21 years since the first rootkit was written, but it wasn’t until 2005 that rootkits reared their ugly heads in the mainstream. Today, there are more than 2 million unique rootkits, and another 50 are created each hour, according to McAfee Labs.

Hackers like rootkits because they work silently, which makes them ideal for harvesting credit card numbers and other valuable information, as well as industrial espionage and electronic terrorism. Thwarting rootkits isn’t easy because they load before the operating system (OS) does, and antivirus platforms don’t kick into action until after the OS starts running. In response, security researchers have created a hybrid hardware-software approach that loads first and then looks into memory’s deepest corners to ferret out rootkits.

McAfee’s recent DeepSAFE technology is an example of this hybrid, which supplements conventional antivirus software rather than replacing it. Edward Metcalf, McAfee’s group product marketing manager, recently spoke with Intelligence in Software about how hardware-assisted security works, what the benefits are and what enterprises need to know about this emerging class of security products.

Q: Why have rootkits become so common over the past few years? And how is their rise changing security strategies?

Edward Metcalf: For the most part, it’s always been a software-based approach that the cybersecurity industry has taken to combat malware. But the motivation of cybercriminals has changed over the past few years. Early on, it used to be about fame: getting their name on the news or in the hacker community. About six years ago, we started seeing a shift in their motivation from fame to financial gain. That’s changed the landscape dramatically, as evidenced by the growth in malware and techniques.

McAfee and Intel realized that there are things within the hardware that allow our software to work, such as looking at different parts of the system that block certain types of threats: looking at the memory and blocking kernel-mode rootkits, for example. So the last couple of years, McAfee and Intel have been working on technology to allow McAfee and other vendors to better leverage and utilize the hardware functionality.

The first evolution of that integration between hardware and software is the DeepSAFE platform. DeepSAFE uses hardware functionality built into the Intel Core i3, i5 and i7 platforms.

Q: So DeepSAFE basically shines a light into previously dark corners of PCs and other devices to look for suspicious behavior that OS-based technologies wouldn’t see, right?

E.M.: Until now, for the most part, all security software has operated within the OS. Cybercriminals know that, and they know how to get past it and they’re developing ways to propagate malware. Stealth techniques like kernel-mode and user-mode rootkits are sometimes really difficult to detect with OS-based security.

The current implementation of DeepSAFE utilizes the virtualization technology built into the Core i-series platform. We’re using that hardware functionality to get beyond the OS to inspect memory at a deep level that we’ve never been able to before because we’ve never had that access. It does require PCs to be running that latest platform of the Core i-series platform.

Q: If an enterprise has PCs running those Core i processors, can they upgrade to DeepSAFE?

E.M.: Yes. I wouldn’t position it as an upgrade. It’s added functionality that provides a deep level of protection.

DeepSAFE and Deep Defender do not replace the current antivirus on a machine. They augment it. It gives us a new perspective on some of the new threats that we’ve always had a hard time detecting because they’ve always loaded well before the OS loaded, which prevented us from seeing them because we’re an OS-based application. Cybercriminals knew that that was a flaw.

Q: Is it possible to apply this hybrid architecture to embedded devices that run real-time OS’s (RTOS’s)?

E.M.: Absolutely. Currently, we don’t have the ability to do that, but we’ve already talked about working with RTOS like Wind River. Taking the DeepSAFE strategy to the embedded device certainly could happen in the future.

People are asking about whether we can put DeepSAFE on tablets and smartphones. The answer is potentially yes if we have the hardware functionality or technology to hook into the hardware that we need in order to get that new vantage point.

Q: Hackers have a long history of innovation. Will they eventually figure out how to get around hybrid security?

E.M.: We constantly have to play a cat-and-mouse game: We develop a new technology, and they find ways to get around it.

In DeepSAFE, we’ve developed a number of mechanisms built into how we load and when we load to prevent any circumvention. Because we’re the first to load on a system, and because we use techniques to ensure that we’re the first one, it makes it harder for cybercriminals to develop ways to get around it.

Security Issues for Multicore Processors

If hackers love one thing, it’s a big pool of potential targets, which is why Android and Windows platforms are attacked far more often than BlackBerry and Mac OS X. So, it’s no surprise that as the installed base of multicore processors has grown, they’ve become a potential target.

That vulnerability is slowly expanding to mobile devices. Within three years, nearly 75 percent of smartphones and tablets will have a multicore processor, predicts In-Stat a research firm. That’s another reason why CIOs, IT managers and enterprise developers need to develop strategies for mitigating multicore-enabled attacks.

Cambridge University researcher Robert Watson has been studying multicore security attacks such as system call wrappers for several years. He recently spoke with Intelligence in Software about multicore vulnerabilities and what the IT industry is doing to close the processor back door.

Q: As the installed base of multicore processors grows in PC and mobile devices, are they becoming a more attractive target for hackers?

Robert Watson: One of the most important transitions in computer security over the last two decades has been the professionalization, on a large scale, of hacking. Online fraud and mass-market hacking see the same pressures that more stock-and-trade online businesses do: How to reach the largest audience, reduce costs and to reuse, and wherever possible, automate solutions. This means going for the low-hanging fruit and targeting the commodity platforms. Windows and Android are a case in point, but we certainly shouldn't assume that Apple's iOS and RIM's Blackberry aren't targets. They are major market players, as well.

Multicore attacks come into play in local privilege escalation. They may not be how an attacker gets their first byte of code on the phone -- that might be conventional buffer overflows in network protocols and file formats, or perhaps simply asking the user to buy malware in an online application store.

Multicore attacks instead kick in when users try to escape from sandboxing on devices, typically targeted at operating system kernel concurrency vulnerabilities. In many ways, it's quite exciting that vendors like Apple, Nokia and Google have adopted a "sandboxed by default" model on the phone. They took advantage of a change in platform to require application developers to change models. This has made the mobile device market a dramatically better place than the cesspool of desktop computing devices. However, from the attacker perspective, it's an obstacle to be overcome, and multicore attacks are a very good way to do that.

Q: What are the primary vulnerabilities in multicore designs? What are the major types of attacks?

R.W.: When teaching undergraduates about local and distributed systems programming, the term "concurrency" comes up a lot. Concurrency refers to the appearance, and in some cases the reality, of multiple things going on at once. The application developer has to deal with the possibility that two messages arrive concurrently, that a file is changed by two programs concurrently, etc.

Reasoning about possible interleavings of events turns out to be remarkably difficult to do. It's one of the things that makes CPU and OS design so difficult. When programmers reason about concurrency wrong, then applications can behave unpredictably. They can crash, data can be corrupted and in the security context, this can lead to incorrect implementation of sandboxing.

In our system call wrapper work, we showed that by exploiting concurrency bugs, attackers could bypass a variety of security techniques, from sandboxing to intrusion detection. Others have since shown that these attacks work against almost all mass-market antivirus packages, allowing viruses to go undetected. Similar techniques have been used to exploit OS bugs in systems such as Linux, in which incorrect reasoning about concurrency allows an application running with user privileges to gain system privileges.

It is precisely these sorts of attacks that we are worried about: the ability to escape from sandboxing and attack the broader mobile platform, stealing or modifying data, gaining unauthorized access to networks, etc.

Q: What can enterprise developers, CIOs and IT managers do to mitigate those threats? And is there anything that vendors such as chipset manufacturers could or should do to help make multicore processors more secure?

R.W.: Concurrency is inherent in the design of complex systems software, and multicore has brought this to the forefront in the design of end-user devices. It isn't just a security problem, though. Incorrect reasoning about concurrency leads to failures of a variety of systems. Our research and development communities need to continue to focus on how to make concurrency more accessible.

Enterprise developers need to be specifically trained in reasoning about concurrency, a topic omitted from the educations of many senior developers because they were trained before the widespread adoption of concurrent programming styles, and often taught badly even for more junior developers. Perhaps the most important thing to do here is to avoid concurrency wherever possible. It is tempting to adopt concurrent programming styles because that is the way things are going. Developers should resist!

There are places where concurrency can't be avoided, especially in the design of high-performance OS kernels, and there, concurrency and security must be considered hand-in-hand. In fact, concerns about concurrency and security, such as those raised in our system call wrapper work, have directly influenced the design of OS sandboxing used in most commercially available OSs.

For CIOs and IT managers,  concurrency attacks, like hackers, are just another weapon in the arsenal that they need to be aware of. Concurrency isn't going away. We use multicore machines everywhere, and the whole point of networking is to facilitate concurrency.

What they can do is put pressures on their vendors to consider the implications of concurrency maturely and on their local developers to do the same. Where companies produce software-based products, commercial scanning tools such as Coverity's Prevent are increasingly aware of concurrency, and these should be deployed as appropriate. For software developers, we shouldn't forget training:

First, to avoid risky software constructs, and second, to know how to use them correctly when they must be used.

We should take some comfort in knowing that hardware and software researchers are deeply concerned with the problems of concurrency, and that this is an active area of research. But there are no quick fixes since the limitations here are as much to do with our ability to comprehend concurrency as with the nature of the technologies themselves.

Read more about development and cybersecurity here.

Managing the Deluge of Personal Hand-held Devices Into the Enterprise

Until recently, many enterprise IT organizations prohibited the use of personal hand-held devices in the enterprise environment. With the consumerization of IT, it faced the daunting challenge of enabling employees’ desire to access corporate information using an array of personal hand-held devices. Ten years ago, employees came to work to use great technology. Now, with the battery of consumer devices available, they often have better PCs and printers at home than they do at work. Because user expectations and needs have also changed, enterprise must adapt.

In the enterprise, a highly mobile workforce wants to take advantage of the most up-to-date systems, services and capabilities to do their jobs, typically using hand-held devices as companion devices to extend the usefulness of their corporate-owned mobile business PCs. This allows them to access information easily from home or on the road. For example, many users want to synchronize their corporate calendars with a third-party Web-based calendar utility so they can use their personal devices to access their work calendars from anywhere. They are motivated to get their jobs done in a manner that is easy, efficient and most productive.

Employees often don’t consider the information security issues raised by such a practice; however, information security is critically important for IT. Analysis of any policy prohibiting all personal devices shows that enforcing the policy would consume extraordinary resources in software and support and would negatively impacted users’ productivity.

Such an approach would require IT to verify every application before allowing a user to install it, which alone would take away much flexibility from the corporate user base. It would also need to significantly modify corporate culture and user expectations, deploy new lab networks and install large amounts of new hardware and networking equipment. That kind of control is just not possible or productive.

Solutions Must Balance User Demand and Information Security
With each new generation of technology, IT must develop ways to help keep information secure. The challenge is to develop a policy that maximizes both user demand and information security to the greatest extent possible. With safeguards in place to protect information and intellectual property, employees are allowed to select the tools that suit their personal work styles and facilitate their job duties, improving employee productivity and job satisfaction. Since the use of personal devices is accelerating, policy needs to change to accommodate it. The best option embraces the consumerization of IT, recognizing that the trend offers significant potential benefits to both users and to IT:

  • Increased productivity. Users can choose devices that fit their work styles and personal preferences, resulting in increased productivity and flexibility.
  • Greater manageability. By offering a program that users can adopt, IT is aware of what they are doing and can offer services that influence their behavior. This provides a clear understanding of our risk level so IT can actively manage it.
  • Enhanced business continuity. If a user’s mobile business PC is nonfunctional, a personal hand-held device provides at least a partial backup, enabling the user to continue to work productively.
  • Loss prevention. Internal data indicates that users tend to take better care of their own belongings and tend to lose personal devices less frequently than corporate-owned devices, which actually enhances information security.
  • Greater security. Rather than ignore the consumerization of IT, IT can increase information security by taking control of the trend and guiding it.

By taking control of the trend and the technology in its environment, IT is able to circumvent many of the security issues that might have occurred if it simply ignores the issue or prohibits employees from using their own devices to accomplish some of their job duties.

Addressing the Unique Security Challenges of This Workplace Trend
Recognizing the potential benefits of the consumerization of IT to both employees and to IT, the best step is to identify the unique security challenges of this workplace trend, investigate user behavior and define the requirements of an IT consumerization policy. That policy must support users’ needs for mobility and flexibility by allowing personally owned hand-held devices in the enterprise and allowing other personally owned devices in the future.

It is relatively easy to verify and enforce which applications are running on corporate-owned hand-held devices. With personal devices, this process is not so straightforward because employees have the right to install any applications they choose. However, we have identified certain minimum-security specifications for hand-held devices that provide a level of information security that allows IT to test, control, update, disconnect, remote wipe and enforce policy:

  • Two-factor authentication required to push email
  • Secure storage using encryption
  • Security policy setting and restrictions
  • Secure information transmittal to and from the enterprise
  • Remote wipe capability
  • Some firewall and intrusion detection
  • System (IDS) capabilities on the server side of the connection
  • Patch management and enforcement software for security rules
  • The ability to check for viruses from the server side of the connection, although the device itself may not have antivirus software

In the case of antivirus software, we analyzed virus attacks on mobile devices and found that very few targeted corporate information; most either sent text messages or attacked the user’s phone book. Although we expect malware incidents to increase over time, the current threat level to actual corporate information is low.

Mobile Business: PCs or Thin Clients?
We have not found that the thin client computing model, which centrally stores information and allows access to that information only from specific devices, is a foolproof way to protect corporate information.

Although thin clients are appropriate for certain limited applications, in general we feel they limit user mobility, productivity and creativity. Also, many of the perceived security enhancements associated with thin clients need to be viewed with caution. In fact, many of the information security risks merely moved; they didn’t disappear. For example, thin clients usually don’t include the same level of information security protection as mobile business PCs, yet they can still connect to the Internet and export information, putting that information at risk. Therefore, the loss of productivity that comes with using thin clients is for little or no gain.

Security Considerations
One of the biggest technical challenges to implementing our policy involved firewall authentication. With IT-managed systems, authentication uses two factors: something you know (a password) and something you have (a registered mobile business PC). But when the device is unknown, you are left with only one authentication criterion.

Therefore, one of the interesting challenges of allowing personal devices in the enterprise is using information on the device to authenticate to the network, without that information belonging to the user. If the employee owns the piece of information used to authenticate to the network, IT would have no grounds for disciplinary action if the user were to choose to move his or her data to a different device to get access to the network. For example, the International Mobile Equipment Identity (MEI) number on a mobile device belongs to the user if the user owns the hardware, so that IT cannot use that to authenticate the device.

To address this issue, IT can send a text message to a predefined phone number, and that text message becomes the user’s password. In this scenario, the phone number is the must-have authentication factor, and the text message is the must-know authentication factor.

Device management also poses challenges, because one solution doesn’t fit all devices and applications. You should design your device management policy with the expectation that a device will be lost or stolen. Therefore, you can expect it to be able to protect itself in a hostile attack. This means that the device is encrypted, can self-wipe with a number of wrong password attempts, and we can remotely wipe the device. Your personal device policy should require users to have controls in place prior to any loss.

Also, some services need greater levels of security than others. For example, the system for booking a conference room doesn’t need the high level of security required by the sales database. Therefore, the room booking system can reside on a device over which we have less management control. You can develop a tiered management system.

The consumerization of IT is a significant workplace trend IT has been actively anticipating for years. You need to establish a comprehensive information security policy, train users and service desk personnel and develop technical solutions that meet your information security requirements. These accomplishments will enable IT to take advantage of the benefits of IT consumerization, without putting our corporate data at risk.

To successfully accommodate employees’ desire to use personal devices in the enterprise, it is important to proactively anticipate the trend -- not ignore it or lose control of the environment by simply doing nothing. Success also hinges on an even-handed approach to developing policy, where each instance of personal device usage is treated consistently; it would be difficult to take action if one employee did something if that thing was common practice.

Highly mobile users can use either their own device or a corporate-owned hand-held device as a companion to their mobile business PC. Because employees with similar responsibilities have different preferences, allowing them to use the hand-held devices that best suit their work styles increases productivity and job satisfaction.

For more information on Intel IT best practices, visit Intel.com/IT

Photo Credit:@iStockphoto.com/mipan