Preventing the Next Digital Black Swan: The Auditor, The CISO and The C-Suite

Their brand names are notorious in cybersecurity circles: EquifaxUber, Maersk and Saudi Aramco. Each of these businesses suffered a big breach – cyber incidents that, together, affected many millions of customers. But it wasn’t only consumer data that was compromised; these companies took huge reputational hits as well. Today, all organizations live in fear of experiencing a similar “digital black swan” event and being made an example of by the media.

Understanding Digital Black Swans
Digital black swans presuppose two key characteristics. First, their impacts are catastrophic. For example, during the 2017 Equifax breach, hackers stole personal data from over 145 million Americans – nearly 44% of the US population. Equifax’s CEOCIO, and CSO were all forced to resign. And the company is facing dozens of government investigations and hundreds of class-action lawsuits.

Digital black swans are not always limited to individual companies and their customers; sometimes, there can also be national or global impacts. During the 2012 Saudi Aramco cyberattack, three-quarters of the company’s hard drives were destroyed. Saudi Aramco sent representatives directly to computer factory floors in Southeast Asia to purchase 50,000 new hard drives – every single hard drive on the factory line. This constrained the global supply of hard drives, causing computer prices to spike.

The second characteristic of a digital black swan is that they are unpredictable. The cyber event appears to come out of nowhere, catching companies by surprise. Consequently, organizations often don’t hold themselves accountable because they are under the false belief that there is nothing that they could have done to prevent an attack of this nature.

Controlling Your Swans
On the surface, digital black swans may seem unforeseeable, but if you dig a little deeper, you’ll generally discover that many of these incidents could have been prevented. For instance, in the Equifax breach, hackers exploited a vulnerability that was publicly disclosed two months prior to the attack. If Equifax had installed the patch in a timely manner, this breach would likely have been prevented.

The key to preventing digital black swans is carefully putting critical controls in place. There are a number of controls that companies can use to reduce the odds of experiencing a major cyberattack. For example, Equifax suffered from faulty vulnerability management. The credit reporting company had ample time to install a routine security update that would have prevented the cyber incident.

Poor security practices at Equifax were systemic. Shortly after the breach, it was revealed that one of the company’s online employee portals could be accessed using the default credentials of  “admin” as both the username and password. This simple negligence put millions of Americans’ data at great risk.

Likewise, the major cyber incidents at Saudi Aramco, Uber, Maersk and even the Ukrainian power grid could have prevented their attacks – or at least drastically reduced the impacts of those attacks – with proper security controls in place.

Flying (In)Formation
Contrary to popular belief, cyber risk is not a nebulous concept. Cyber risk can be measured, and because it can be measured, it can be managed. Cyber incidents can be anticipated by using risk scenarios that quantify potential loss magnitude (such as business impacts). When organizations evaluate the variety of threats and potential success rates against the various assets they own, they can quantify the possible losses in these observed or contrived scenarios. As such, senior business leaders can prioritize the appropriate controls and countermeasures to ensure that their most valuable assets – their crown jewels – are properly protected.

Cybersecurity matters affect many areas of an organization, and thus involve people in an array of positions: auditors, CISOs, senior officers, etc. Though each of these roles have different responsibilities, they share a common mission: keeping the company safe from cyber threats. Cybersecurity is a true team sport. And like all team sports, one of the keys to success is effective communication. IT auditors need to look across the organization to ensure it is in compliance with any regulations as well as to identify potential areas of weakness and to convey new requirements and recommendations to the CISO or other information security managers. CISOs need to work within their budgets to protect their enterprise from cybersecurity risks, while balancing the need to keep the organization fluid and functioning. There are several resources available that can help senior executives and other business leaders manage and oversee cyber risk, such as CyberVista’s Resolve Program. Furthermore, CISOs need to communicate this risk to executives and the board by explaining cybersecurity issues in business terms; they need to translate bits and bytes into dollars and cents. And conversely, business executives need to overcome their technophobia, become more informed on cyber risk issues, and prioritize and manage that risk as an enterprise risk.

Editor’s Note: Jeff Welgan will present on this topic at the 2018 Governance, Risk and Control Conference, to take place on 13-15 August in Nashville, Tennessee, USA.

Jeff Welgan, Head of Executive Training Programs, CyberVista

[ISACA Now Blog]

Software-Defined Perimeter Architecture Guide Preview

The Software-Defined Perimeter (SDP) Working Group was founded five years ago, with a mission to promote and evangelize a new, more secure architecture for managing user access to applications. Since the initial publication of the SDP Specification, we’ve witnessed growing adoption and awareness throughout the industry. As practitioners, vendors, evangelists, and guides, we (as the SDP working group) have learned a great deal about SDP in practice, and wanted to capture and share that knowledge.

This was the driver for us to create the forthcoming Software-Defined Perimeter Architecture Guide. We’ve decided to publish a preview blog series here to obtain feedback on this work-in-progress artifact, and to spark conversation about SDP architectures and deployments. Ultimately, we intend the final published Architecture Guide—scheduled for publication in Q4 2018—to encourage broader (and more successful) adoption of SDP architectures.

Please join the conversation in the SDP working group here—we’re open to feedback, questions, or even just good restaurant recommendations. Thanks for reading this, and we look forward to engaging with you.

In this first blog posting, we’re going to walk through the SDP Architecture Guide outline and provide color commentary. Keep in mind that this document is still a work-in-progress, so the content and structure may well change prior to publication. Let’s dive in:

  • Introduction
    • Why We Wrote This Document
    • Target Audience
    • Goals
    • SDP Scenarios

In the introduction, we provide the motivation for the document, articulate who our target audience is, and explain our goals. Then, we enumerate SDP scenarios (AKA use cases), briefly explaining each one, and exploring the benefits that SDP provides in that scenario.

  • SDP, Zero Trust, and Google’s BeyondCorp

In addition to SDP, there is a lot of noise and activity in today’s marketplace around the Zero-Trust philosophy, and to some degree about Google’s internal BeyondCorp security initiative. In this section, we attempt to make sense of this and explain the similarities and differences between them.

  • SDP Overview
    • Core SDP Concepts
    • SDP Architecture
    • SDP Deployment Models
      • Client-to-Gateway Model
      • Client-to-Server
      • Server-to-Server Model
      • Client-to-Server-to-Client
      • Client-to-Gateway-to-Client
      • An Alternative Architecture: The Cloud-Routed Model

This section presents the foundational elements of SDP, including its core underlying concepts. We also dive into the SDP architecture and discuss each of the SDP deployment models.

    • Single-Packet Authorization
      • SPA Benefits

Single-Packet Authorization (SPA) is one of most important parts of SDP. By compensating for the fundamentally open (and insecure) nature of TCP/IP, SPA enables secure and reliable deployment of SDP Controllers and Gateways onto insecure and public networks. In this section, we analyze the SPA protocol, suggest some improvements, and expand upon its benefits to SDP.

    • SDP Policy Model
      • SDP Policy Overview
      • Policy Components

SDP, as a specification, is silent on a policy model. In this section, we introduce the elements that an SDP policy model should have and the corresponding capabilities that an SDP platform should be able to express. We conclude this section with a few example policies.

  • SDP in the Enterprise
    • Architecture Considerations
    • Security and IT Technologies
      • SIEM
      • Firewalls
      • Intrusion Detection/Prevention Systems
      • Virtual Private Networks
      • Next-Generation Firewalls
      • Identity and Access Management
      • VPNs
      • NAC
      • SDN
      • IDS / IPS
      • EMM / MDM
      • Web Application Firewalls
      • Cloud Access Security Brokers

This section introduces a simplified (but prototypical) enterprise model, exploring how each of the Security and IT technologies shown above are impacted by the deployment of SDP.

  • SDP Business Benefits

We conclude with the business benefits that SDP can deliver. This section, which will be constructed in a tabular format, will provide an overview of these benefits. We look forward to providing more detailed, quantified benefits and case studies in a future document.

Thanks for reading through the outline. In our next blog post in this series we’ll talk through the SDP Core Concepts table.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.

[Cloud Security Alliance Blog]

The Multiple Options for Multi-Factor Authentication

How do you prove you are you? In the physical world, we have birth certificates and driver’s licenses to prove we are who we say we are. Yet this question becomes more difficult when you are trying prove yourself to a computer system. Thankfully, Multi-Factor Authentication (MFA) can help in a variety of ways.

MFA is a method of authorizing a user’s claimed identity and granting that user access to a system. MFA is achieved after a user has provided two or more factors to an authenticating mechanism, such as something the user knows, has, or is. MFA factors can be derived from any of the three.

A common example of a factor would be your username and password. Both are a form of something you know. Stemming from MFA is Two-Factor Authentication (2FA). This is an MFA protocol that requires a user to present a unique factor from two separate mechanisms, as often comes into play with an ATM card. You are only able to use your ATM card if 1) you have the card, and 2) you know the PIN associated with the card.

Finally, we have Two-Step Authentication (2SA). Two types of 2SA are a disconnected token (such as hard tokens and Keyfobs), and a soft token, which is an application that will generate a unique number combination. While both serve the same function, each has its own advantages and disadvantages. For instance, hard tokens cannot be duplicated. However hard tokens are costly to acquire and have to be physically handed to each and every user, creating an administrative burden. Soft tokens, on the other hand, can be widely disseminated, ensuring the likelihood that it is an authorized user requesting access to the system. Yet soft tokens are more susceptible to outside attacks than a hard token.

Whether you use a soft or hard token, you are still limiting the application to either a physical device that a user must always retain and not lose, or an app on a person’s phone. Both tokens can be lost, eaten by the family dog, broken, or otherwise rendered useless. What then? You can use something you have, something you know, and more importantly, something you are. Biometrics, the use of physical characteristics, such as an eye scan, fingerprint readers, and facial recognition, can potentially eliminate passwords, thus removing the password recovery requirement, a key vulnerability of MFA/2FA/2SA. Biometrics are instant, require no keys, and are unique to each individual.

While biometrics seem promising, there are some potential challenges. If a user relies on facial recognition software and gets a tattoo or a facial injury, will that prevent him or her from using the feature? Some users may have damaged fingerprints, rendering that option useless. Further, the use of biometrics implies that every user has a smartphone or tool capable of reading and comparing the data to a table for reference and approval.

Be it hard or soft token, or biometrics, each MFA option has its benefits and its costs. Which one you or your company choose will be based on the size of your company, the scope of users requiring a token, and what level of risk your company is willing to accept.

Cory Missimore, Assistant Manager, Information Security Compliance, Bloomberg BNA

[ISACA Now Blog]

English
Exit mobile version