1. Accelerate Migration to the Private Cloud

Motivated by lower costs and vastly improved flexibility, most large companies are putting in place standardized, shared, virtualized, and highly automated environments to host their business applications. These are—with all their various permutations—known in practice as the “private cloud.”¹ As early as 2011, nearly 85 percent of large companies we interviewed said that cloud computing was one of their top innovation priorities, and 70 percent said that they were either planning or had launched a private cloud program.² Those that are further along have often found that they could migrate 60 percent of their workload³ to these much more capable and cheaper private cloud environments (Figure 5.2).

However, despite the uptake, there remains a debate over the benefits of hosting applications in a private cloud environment. Some cybersecurity professionals argue that the drivers of the improvements in efficiency and flexibility can also make it easier for attackers to exploit the corporate network. Virtualization—the co-locating of multiple images of operating systems on a single physical server—allows malware to spread from workload to workload. Standardization simplifies a data center environment, which makes life easier for IT teams but also creates a security monoculture that is easier for attackers to understand. Similarly, while automation helps system administrators enormously in managing the data center environment, it can be tremendously destructive if an attacker gains access to a system administrator’s login credentials.

Some of the most sophisticated IT organizations have exactly the reverse point of view. They have concluded that traditional data center environments are entirely unsustainable and that well-designed private cloud programs provide the opportunity to improve cost, flexibility, and security simultaneously.

2. Use the Public Cloud Selectively and Intentionally

A few years ago, account executives from a major public cloud provider called on the head of infrastructure at one of the world’s largest banks. They made a compelling presentation about how much they had invested in their cloud platform and the richness of its capabilities. As the pitch concluded, the head of infrastructure complimented the account team but had just one question: “I have data that can’t leave the United States. I have data that can’t enter the United States. I have data that can’t leave the European Union. I have data that can’t leave Taiwan. If I used your service, how would I know all those things would be true?”

One of the account team replied, “That doesn’t make any sense. Why would you want to run your business that way?”

To which the head of infrastructure said, “You seem like nice boys. Why don’t you come back in a few years when you have this figured out.”

It is for just these reasons that large enterprises have been reluctant to turn to public cloud services (especially infrastructure). They remain unconvinced that providers have figured out how to provide enterprise-grade compliance, resiliency, and security. Our survey results back this up. On average, companies are delaying the use of cloud computing by almost 18 months because of security concerns. In many interviews, we heard chief information officers (CIOs) and CISOs express concerns that malware could move laterally from another company’s public cloud-hosted virtual servers to their own because they would both be running on the same underlying infrastructure.

Nevertheless, if companies put in place the mechanisms to channel the right workloads to the appropriate cloud services, then it is perfectly possible to make exciting capabilities available while continuing to protect important information assets.

Therefore, IT organizations cannot take an absolutist position against public cloud services. Given the resources that providers are investing in new capabilities and the attractive costs—especially during the price war that is being waged as we write—there will continue to be strong demand for these services. As a result, IT organizations that try to prevent their use may find themselves in a challenging position. From one direction, business partners will see them as being obstructive—grist to the mill for those who constantly perceive cybersecurity as blocking value creation. From the other direction, end users and even application developers will simply work around or ignore corporate policies given how easy public cloud services are to procure. If your users have credit cards, they have access to the public cloud, but without guidance they may select services with weaker security capabilities and use these services without the additional security controls that enterprises can apply.

An approach that protects an institution’s important information assets while supporting innovation by providing access to public cloud services must take into account four factors:

1. The sensitivity of information assets. There are huge variations in the sensitivity of corporate data, as we discussed earlier in the book. Some workloads process incredibly sensitive customer information or intellectual property (IP). Others process important information, but disclosure would not have grave business consequences.¹³ Ensuring that only those less sensitive workloads are directed to the public cloud would ease the concerns of cybersecurity managers.
2. The security capabilities of specific public cloud offerings. There are also huge variations in the security models for public cloud offerings. At one end of the spectrum there are security practices that might be politely described as “consumer grade,” while at the other end we see providers employing robust perimeter protection, encrypting data at rest, and placing strict controls on how and when operators can access their customers’ data. Choosing the right vendor is therefore paramount.
3. The security of comparable internal capabilities. When the business asks cybersecurity teams about the security of public cloud offerings, the response has to be “compared to what?” There are many situations where a public cloud offering might be riskier than a service from the company’s strategic data center but far more secure than a comparable service hosted by an internal regional IT organization that has been starved of investment for years.
4. The possible enhancements of public cloud offerings. Many start-ups are racing to develop the technology that will allow enterprises to use public cloud offerings securely by encrypting data transmitted to cloud providers or entire cloud sessions and allowing enterprises to retain the keys required for decryption.

A transportation company seeking to develop a cloud strategy identified all the workloads required to run its business and assessed each one in terms of critical requirements, including the sensitivity of data processed. It was then able to map each workload to a hosting model: traditional hosting, private cloud, Software as a Service (SaaS), or public cloud infrastructure (Figure 5.3). For workloads that could be hosted on SaaS or public cloud infrastructure, the company identified specific vendors that could at least match its own internal capabilities in terms of security and then examined ways to put additional software around these public offerings to enhance security further.

3. Build Security into Applications

Application security mattered less when employees accessed corporate applications from desks inside the company’s buildings. Today, companies cannot control such a clear bricks-and-mortar perimeter, and highly functional applications are available to both customers and employees who expect to access such applications anytime, anywhere. The result is that hackers can use application-level attacks, gaining entry through the web browsers that provide a gateway into the application. For example, hackers were able to lift customer data from one bank because developers exposed sensitive information via the browser bar in the company’s online banking applications.

To the layman—or the board member with no IT background—this sounds like a rudimentary error from the developer. The reality is that application developers do not understand how to write or test for secure code; most computer science courses do not require much information security training and what does exist tends to be a checkbox set of practices, rather than an immersive course that teaches the problem solving required for secure application development. Many development teams, for example, do not follow best practice and include libraries to scan for known code vulnerabilities or run them as part of their nightly build. Instead, security functionality tends to slip down the agenda as understaffed teams rush to deliver business functionality. Even intelligence agencies have asked for rigorous password capabilities to be deprioritized so that time could be spent improving an application’s user interface.

On top of all this, many companies have weak identity and access management (I&AM) capabilities for validating which users can access which application. Applications may use home-brewed or out-of-date I&AM and a wide variety of different capabilities. This makes it even harder to enforce common password policies and requires users to remember a variety of passwords. One industrial company found that senior executives had to use as many as 20 different passwords; no surprise that some of them wrote them down in a notebook or saved them in files stored on their desktop.

The final problem for IT is that legacy applications can predate the development of secure coding practices. An insurance company reviewed its cybersecurity setup and found that it was doing a pretty good job of securing new applications, but the backlog of applications that could not be made secure cost-effectively ran into the thousands.

Although enhancing application-level security can be an even more challenging organizational change than addressing other technology issues such as networks or end-user devices, some companies have found effective practices that can help them improve their position:

• Incorporate instruction on secure coding practice and security problem solving into development training from day one; one financial institution devotes nearly 25 percent of developer training hours to security topics.
• Build a rich set of security tools and application program interfaces (APIs) (for code scanning, security monitoring, and I&AM) into the development environment. This helps minimize the extra time developers need to secure applications.
• Constantly challenge the application portfolio using penetration testing. One bank has a team of 50 security specialists who do nothing but try to break into its applications.
• Use the creation of agile teams as a forcing device for change, and make sure that security requirements are incorporated into agile methodologies.
• Perhaps most importantly, get serious about lean application development. Applying lean operations techniques to application development and maintenance can improve productivity by 20 to 35 percent, but it also reduces security vulnerabilities in application code by bringing all the stakeholders on board early, stabilizing requirements, and putting quality first throughout the development and maintenance processes.¹⁴

4. Move to Near Pervasive End-User Virtualization

For all the creativity and resourcefulness of cyber-attackers, one common situation remains the starting point for many attacks. The attacker sends an employee a phishing e-mail and the employee clicks the link, which takes him to a website that installs malware on his device. The attacker is in.

Cybersecurity teams used to rely on antivirus software to protect desktops and laptops from malware, but two developments have reduced the effectiveness of that model. Advances in malware technology have meant more and more of it can slip past antivirus software, and as employees expect to work anywhere, companies have to manage new types of client devices with new types of security vulnerabilities, specifically mobiles and tablets. As a result, sophisticated institutions are finding they have to move to virtual end-user environments, where both traditional and mobile end-user devices simply display information and collect user input but store very little.

For some time, leading CISOs have said they continue to use antivirus software mostly for cosmetic purposes. Antivirus packages used to compare a piece of the software’s executable file against a database of known malware to determine whether the software was safe. Now that cyber-attackers have developed malware that changes form over time, it is no longer effective to compare it against a blacklist. As a result, many CISOs say they continue to pay for antivirus tools mostly to appease regulators or just in case they happen to foil a simplistic attack that would not have been prevented otherwise. The debate over antivirus effectiveness came to an end when executives at Symantec, a leading developer of antivirus tools, announced the death of the antivirus model in the Wall Street Journal.¹⁵

Just as antivirus tools became less effective for desktops and laptops, the rise of enterprise mobility presented a whole new challenge. Back in 2009, nobody knew what a tablet was. Today, they are pervasive in executive suites and among mobile professionals. By 2017, enterprises will account for nearly 20 percent of the global tablet market of nearly 400 million units.¹⁶

Again and again, CISOs have expressed their nervousness about the immaturity and fragility of the software that connects smartphones and tablets to their corporate networks. Integrating mobile device management, virtual private networks (VPNs), and other software from multiple vendors creates seams and crevices that attackers can exploit. In addition, the complex manual processes required to use mobile devices in an enterprise environment increases the likelihood that security policies will not be implemented correctly on any given device, creating additional footholds for attackers. Bring-your-own-device schemes (in which employees use their own tablets and smartphones for work purposes) and the bewildering proliferation of devices and client OS versions (especially within the Android ecosystem) make secure operations even more difficult.

These challenges exacerbate tensions between embracing mobility and enabling innovation on the one hand and securing the devices and the network on the other. One insurance company CISO had to field calls from board members on successive days, first asking him to promise that a breach couldn’t happen and then protesting that he hadn’t approved the use of tablets for board documents.

5. Use Software-Defined Networking to Compartmentalize the Network

In a world where nobody can eliminate breaches, it becomes especially important to contain the attacker’s ability to move from one infected node of a technology network to the next. This “lateral movement,” as it has become known, is getting harder to prevent as the corporate network environment has evolved, leaving IT organizations with a tough choice between preventing attackers from expanding their reach and introducing too much operational complexity.

Historically, as companies consolidated their IT organizations, they stitched enterprise networks together from departmental networks and networks picked up in various acquisitions. Different networks used different architectures, different technology standards, and, in some cases, different protocols—and they were walled off from one another by gateways and firewalls. This created complexity and inefficiency and hurt network performance. Network managers had to make manual configuration changes to install new applications and perform detailed analyses to identify the root causes of slow traffic between sites managed by different business units.

Over the past 10 years, most large enterprises have simplified their networks. One global financial institution went from 25 networks to just 2, saving more than $50 million a year. A pharmaceutical company created a global flat network because it wanted to allow seamless videoconferencing between any two offices globally, from Peru to Madagascar (without in fact assessing how many executives in Peru needed to videoconference with their counterparts in Madagascar). Simplification had a downside, though: it created more entry points into its networks.

As companies integrated their supply chains with vendors and exposed more of their technology capabilities to customers, they created more direct network connections between themselves and their business partners. This allowed investment banks to give prime brokerage customers the performance they required and allowed pharmaceutical companies to collaborate closely with research partners. However, it also created more opportunities for attackers to jump from one company’s network to another’s and created more network entry points that network or security operations teams had to monitor. Once an attacker gains entry to the environment, he or she can see all the other systems, which makes them easier to analyze and compromise. The high-profile breach of Target occurred partly because one of its vendors, which needed access only to the billing system, also had access—unwittingly—to the point-of-sale system. Once an attacker had breached the vendor’s security systems, it suddenly had access to data inside Target that never should have been visible.

A particularly important potential vulnerability is having the security controls themselves sit on the same network they protect. This is one of the easiest things to segment, and it is essential to do so; otherwise, the first thing a sophisticated hacker will do once inside the network is disable the organization’s ability to track where he or she is.

6. Use Dedicated Document Management and Workflow Tools Instead of E-mail

Some CISOs say that they are quietly confident about how their company protects the structured data it stores in databases, but have sleepless nights about the extremely sensitive information that executives pass back and forth to each other via e-mail attachments. Documents make up a growing share of their company’s data, and many of the controls they use to protect structured data just do not apply. A few companies have started to get control of this type of data by creating and mandating the use of sophisticated capabilities for managing sensitive documents. More need to catch up with them.

Stories about the theft of millions of customer records often reach the front pages of the broadsheet press. These are embarrassing for the companies concerned; however, some of a company’s most sensitive and valuable corporate strategic information sits around in documents or just in plain text. Senior executives communicate with each other about acquisition targets, markets to enter, business strategies, layoffs, negotiations, divestitures, and so on, using presentations they create on their desktops and share via e-mail. Managers and analysts collaborate on business plans, valuation models, financial forecasts, and pricing strategies using spreadsheets they, again, create on their desktops and share via e-mail. Often, once all these incredibly sensitive documents have been created, they languish either in e-mail inboxes or in file shares.

Documents like this can be extremely complicated to secure because companies have little control and no visibility into who opens, alters, and transmits them. In many cases, entire departments have access to shared folders that hold sensitive documents. Any executive or manager can access an important strategy document and, perhaps without thinking about how sensitive it is, forward it to dozens of people. The more places a document exists in a company’s environment, the more likely an attacker will be able to find it. The insider threat is even more pronounced—the more people have access to a document, the greater the chance that one of them uses it inappropriately.

The companies that are making progress in addressing this issue have fundamentally changed the way their staff work with documents. Law firms may have a reputation for being technology laggards, but in this area they have made the most progress. Spurred by the demands of their clients, most of the largest law firms now use document management tools extensively. If a lawyer works on a client matter, she has no choice but to create all the relevant documents within the document management platform. That means that only a small number of her fellow lawyers can access any set of documents, reducing the impact if attackers compromise any one lawyer’s credentials. Perhaps more importantly, this rigor in document management provides the firm with visibility into who is accessing, transmitting, and altering client materials, which makes it much harder for insiders to exploit client information undetected. Document management systems can also insert tags about the sensitive information any given document contains into its metadata. This makes it exponentially easier for data loss protection (DLP) tools to stop users from e-mailing or printing a document that they should not.

Other companies go even further in protecting their most sensitive information. An oil and gas company moved discussions about negotiation strategies for extraction rights out of clear text in e-mail and into documents secured with digital rights management (DRM), reducing the risk that an unauthorized party could see the maximum amount it bid for a property. A manufacturing company is implementing DRM for the materials containing technical specifications it sends to its suppliers. This makes it much harder to forward this information inappropriately because DRM prevents users from opening, printing, or copying a file unless they have authorization from the document’s creator.

As with the other security improvements discussed in this chapter, protecting unstructured data requires dramatic changes far beyond the cybersecurity function. That said, it does not have to mean a worse user experience. In a world where everyone complains about e-mail overload, how much frustration results from version upon version of a single document clogging up inboxes? How much time do executives, managers, and other professions spend trying to find the latest version of a document or extracting comments from complicated e-mail threads? The browsing, tagging, and search features of a well-designed document management capability make it much easier to find the right document, and collaboration tools make it much easier to aggregate and act on feedback. It is a change of mind-set, but one that can prove popular once adopted.