Blog

Thanks for returning for the second blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide (Read Part 1). In this article, we focus on the “SDP Scenarios” section of the document, which briefly introduces the primary scenarios for SDP, explains why organizations should consider adopting SDP, and lists the benefits that SDP delivers for that scenario.

This section is—by design—concise. We’re passionate about SDP and network security, and could write an entire novel on this topic (in which our hero, network security architect Reavis Macdonald, uses SDP to prevail against a malicious adversary and save his organization from a record-breaking GDPR fine!). Sadly, our editor assures us that such a story wouldn’t be a bestseller, and that our Architecture Guide should likewise err of the side of brevity.

In this blog posting, we’ve chosen to elaborate on several of the scenarios and to provide some color commentary. Let’s get started!

SDP Scenarios at a Glance

Scenario 1: Identity-Driven Network Access Control

This scenario is the heart of the value that an SDP architecture provides. It enables organizations to fundamentally change the way they’re viewing security—shifting away from IP addresses and subnets, and toward identities and business systems. This is more than a technical shift—at least, it should be more than that. We’ll discuss this more in the SDP Policy section in the main document, but SDP allows for policies to be described in terms that are meaningful to the business, yet are enforced by the network.

Scenario 2: Network Microsegmentation

The concept of network microsegmentation—often part of a Zero Trust initiative—is driven by the imperative to enforce the principle of least privilege at the application and network level. But microsegmentation is only a means to an end. It requires a policy model, and a mechanism for automated enforcement of these microsegments in order to deliver efficient and effective value to the enterprise.

Shifting gears slightly, we now introduce several use cases that organizations commonly use to get started with Software-Defined Perimeter projects.

Scenario 3: Secure Remote Access (VPN Alternative)

Virtual private networks (VPN), while widely deployed, nevertheless suffer from a variety of shortcomings that frequently drive organizations to consider the Software-Defined Perimeter as an alternative. In addition to being disruptive to the user experience, VPNs typically provide too-broad network access, exposing far more services and protocols than necessary. VPNs are also difficult or awkward to use when people need to concurrently access many distributed resources —either across data centers or cloud environments. And finally, VPNs are a point solution. Because they are only used for remote access, their access policies are by definition unable to apply to on-premises users. SDP solves all these problems with VPNs, providing a single consistent and user-friendly platform that secures access for both remote and on-premises users with fine-grained control of access rights.

Scenario 4: Third-party User Access

Third-party access is another very common use case for SDP. While remote third-parties may fall under the VPN scenario, many organizations have considerable numbers of third-party users working on-premises. These users often need very specific (and limited) network access, while nevertheless using the same network as employees with broader access. A Software-Defined Perimeter provides a simple solution for this, which ensures that these third-party users have a consistently secured and managed set of network privileges, regardless of whether they are remote or on-premises.

Scenario 5: Enabling Secure Transition to IaaS Cloud Environments

Finally, we’re seeing many organizations leverage SDP to more easily and securely adopt IaaS cloud environments. Rather than relying on direct site-to-cloud connections (which provide too-broad network access), or traditional VPNs (which are awkward to use in multi-account or multi-site environments). SDP allows for precise access control to cloud environments, managed on a per-user basis.

Conclusion

We hope that this preview blog post gave you a good sense for some of the SDP scenarios, as well as a bit of expository context on our thinking around them. In our next blog posting, we’ll be reviewing the core concepts of the Software-Defined Perimeter , explaining their benefits, and listing some of the associated threats that they mitigate.

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.

Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.

[Cloud Security Alliance Blog]

Cloud security is on everyone’s minds these days. You can’t go a day without reading about an organization either planning its move to the cloud or actively deploying a cloud-based architecture. A great example is the latest news about the US Department of Defense and its ongoing move to the cloud.

The US government is leading the charge by encouraging the private sector to provide secure cloud service offerings that enable federal agencies to adopt the cloud-first policy (established by the Office of Management and Budget in 2016) using FedRAMP. FedRAMP is a US government-wide approach for security assessment, authorization and continuous monitoring for cloud products and services. It sets a high bar for compliance with standards that ensure effective risk management of cloud systems used by the federal government.

There is even some chatter now about efforts to establish FedRAMP as a law, in an effort to encourage agencies to adopt the cloud at a more rapid pace. The delay in adoption is by no small measure related to the complexity, the intensive resource requirements of the current FedRAMP processes and finding providers that are FedRAMP-certified.

One of the main considerations to the adoption of FedRAMP on a wider scale is the difficulty for the industry, Third Party Assessment Organization (3PAO) and Cloud Service Providers (CSP) to determine what the profitability model is for engaging in the FedRAMP program.

Establishing such metrics can offer key drivers for industry adoption, perhaps by allowing CSPs to determine how offering FedRAMP-accredited IaaS/SaaS/PaaS can be truly beneficial and profitable for the company’s bottom line, at the same time allowing the agencies to determine the cost effectiveness of a move to the cloud.

While achieving FedRAMP accreditation has many challenges (as TalaTek learned over the past 18 months during deployment of its own cloud-based solution), there are clear benefits for the federal agencies and the industry to work with a FedRAMP-authorized service providers. At a high level, these include an established trust in the effectiveness of implemented controls and improvement of data protection measures.

Despite the many challenges for adoption, I am a big believer in the benefits outweighing the challenges of the FedRAMP program, especially in the long run, after the kinks are ironed out and the program maturity improves through increased adoption of both government and private industry.

The FedRAMP program provides significant value by increasing protection of data in a consistent and efficient manner – a key need among government organizations and especially among information sharing agencies – by providing these key benefits:

• Enables a more successful move to the cloud for federal agencies;
• Ensures a minimum security baseline for all cloud services;
• Provides managed security continuity for a cloud offering versus a onetime compliance activity;
• Standardizes requirements for all cloud service providers; and
• Creates a 3PAO cadre that is capable, certified and can ensure quality assurance for cloud implementations.

By providing a unified, government-wide framework for managing risk, FedRAMP overcomes the downside of duplication of effort and inefficiency associated with existing federal assessment and authorization processes.

When considering a move to the cloud and the level of security that is necessary, we should all take risk management seriously and invest in skill development and knowledge, as well as in adapting the processes for the 21st century and getting ready for the reality of the dominance of the cloud in our near future. FedRAMP provides the roadmap for any organization to achieve these goals.

Baan Alsinawi, TalaTek founder and president

[ISACA Now Blog]

Threat hunting is all about being proactive and looking for signs of compromise that other systems may have missed. As defenders, we want to cut down the time it takes to detect attackers. To accomplish this, we assume the bad guys have penetrated our defenses, and then proceed to look for traces that their activities have left behind.

Putting aside the technical details, it is extremely important to consider the person, or perhaps the team, who is doing the hunting. I describe a good threat hunter as a person with a wide skill set who has “been there and done that” in multiples areas of IT and security. There are four main dimensions that help shape a good hunter:

Curiosity
A threat hunter needs to be patient, highly motivated, and driven by a desire to know more. The person needs to start asking questions such as why in order to understand whatever activity may be under analysis. In order to be able to answer the why, the drive to go deep into the rabbit hole is essential.

Critical thinking
Being able to analyze and solve problems also is important. The hunter must always keep an open mind and be able to consider alternative solutions to the problem. Thinking like an attacker usually helps frame an investigation from a different angle and could be the key to uncovering evil within your systems.

Technical expertise
A wide array of technical knowledge is essential. A person who is an expert in network and knows very little about other disciplines such as forensics, applications, databases, etc., may not be able to see the big picture. Ideally, the hunter has cross-discipline knowledge and knows who to reach out to when more in-depth analysis is required.

Ability to connect the dots
This is one of the most important aspects. Many analysts struggle when presented with multiple sets of information and therefore are unable to connect the dots and put together the puzzle. An efficient hunter should be able to understand the data and its business context, perform the appropriate correlations, and reach conclusions.

Professionals with this sort of talent and skill are scarce. Remember that in many cases it makes perfect sense to develop hunting talent in-house. An employee who has worked in a few IT or information security disciplines who knows your business brings great value to the table. Look around and see who is up to the challenge.

Editor’s note: Roger O’Farril will be presenting further insights on this topic at ISACA’s CSX North America conference, to take place 15-17 October in Las Vegas, Nevada, USA.

Roger O’Farril, Information Security Team Lead, Federal Reserve Bank of Chicago

[ISACA Now Blog]