The Cybersecurity Poverty Line and Its Impact on Secure Remote Access to the Cloud


What I learned at RSA

There was a lot of talk about change, transformation, shifting left, disruption and more at RSA. There was also a recognition that 100% protection is a myth. This does not absolve organizations of the responsibility to protect data, secure access and prevent malware or ransomware from running rampant.

Here are the things that stood out.

1. Baby and bathwater, access and the ecosystem

It’s an old adage: don't throw the baby out with the bathwater. An extension of that is the sea of resources that your ecosystem of employees, partners, third parties need access to. They access critical resources, from anywhere all the time, and can potentially, often inadvertently, introduce threats into your system. The solution to that risk is not eliminating anywhere anytime access or eliminating resources. Because that ship has sailed.

A common approach is to create a robust perimeter and delegate responsibility of access to each member of the ecosystem. First, in the digital first world, the notion of a well-defined perimeter is obsolete (more on this later). Second, as Chris McCurdy, VP of Security Services @IBM stated in the session on Staying Secure, “all of our collective actions or inactions impact each other at a scale we have never imagined.”

Organizations cannot delegate responsibility for security. They need to implement zero-trust for secure remote access to the cloud applications and resources. Cyber security is a shared responsibility and shared risk.

One approach is where large organizations mandate expensive and cumbersome overhead on their ecosystem of partners. But that would just mean shrinking the pool of partners they can work with. That has the unintended impact of eliminating all the partners that live below the Security Poverty Line. In the interest of full disclosure I have borrowed the term coined by Wendy Nather.

Such approaches limit the ability of organizations to operate efficiently and harness the power of smaller potentially innovative organizations. Often organizations cannot dictate the security stack of their ecosystem of partners. Dictating the stack limits or eliminates a significant number of partners they work with. The tradeoff might be acceptable in some situations, but often hampers business agility.

This requires that organizations find efficacious yet cost effective ways to leverage the capabilities. They must do this while maintaining a high standard of security without placing an onerous burden on their partners.

Organizations must find a way to work with a wide array of ecosystem partners. They must be able to keep pace with the rapid changes in types of application. They must remain independent of underlying architecture or platforms, and stay agnostic to the device(s) the user chooses. The approach must work across cloud infrastructure, SaaS, cloud applications and private applications.

2. User experience and security

More than one keynote speaker addressed the friction between security and convenience (ease of use). I have written about this before, but it deserves repeating. We have come to accept that there needs to be a compromise between user experience and security. There are multiple contributors in the battle between user experience and security.

A contributor is the pace of innovation. How can you blame innovation, isn’t that a good thing? The speed of change is not satisfying and enthralling, but has transformed the way we live and work. The challenge with that speed of change is that security tools seem to lag the change in Infrastructure.

Todd Gillis (VMware), in his session on Security Beyond the Perimeter and Endpoint, talked about the speed of change. As infrastructure has continued to evolve, security tools that were in place were twisted to accommodate the new cloud world. This approach created security gaps and compromised user experience.

A narrative has developed that the tools were contributing to friction in the user experience. It is true the tools are contributing to a compromised user experience. It is critical to note though, that many of these tools were never designed for this hybrid cloud world. Now organizations face the dual challenge of improving customer experience and effectively secure remote access to the cloud.

The change in architecture is accompanied by a change in mindset. Operations teams were focused on availability, not security. Since customers focused on availability, tools vendors built were built to provide availability at the expense of security. The digital transformation, explosion of data and interconnection between organizations has driven a change in focus to secure availability.

Another contributor is the fragmentation of tools. Take the example of securing access. There is one solution to secure access to SaaS. There is another way to secure Internet access. A third for private applications. One to emulate the environment for contractors (virtual desktop interface) and one to connect to networks (VPN). The user is required to have agents and a different experience for each type of access.

Further, tools like VPNs provide broad access to corporate networks, bear less relevance in a borderless cloud centric world. Not only do they compromise user experience, they don’t secure access to the cloud, the fabric of the digital enterprise. Moreover, the alphabet-soup of tools puts an onerous burden on organizations that live below the security poverty line referenced above.

I heard it over and over again, security needs to be an enabler not a blocker. Security also needs to be perceived as an enabler not a blocker. We must find ways to consolidate tools and ensure that users aren't forced to circumvent security to reduce friction. If the “best” tools are bypassed there is no security. Yes, there is a better approach to provide zero trust secure remote access to the cloud.

3. Identity is the Monarch

Identity as the perimeter (or monarch) requires rejecting the notion that once a user has access to a network they are trusted to access all resources. Identity being the monarch means verifying access to a specific resource against access policies and context of access to the resource. The resource could be an application, an account on a cloud platform, or a file within an application.

In a digitally transformed world users have a unique identity associated with each application. An identity to access the HR application, the sales application, the development environment, and the network. This is sometimes referred to as identity sprawl. In this world of identity sprawl – each identity is associated with a set of access rights to a specific application.

In order to implement zero trust, identity must be verified, level of access determined based on context, and only then granted. In this model the identity of the entity accessing any resource must be known, verified and trusted. This is the only way to meet the essential tenet of zero trust. Don’t trust always verify.

This must apply to access to applications, infrastructure, resources, including shared resources – think shared accounts used to deploy software. Identity as the monarch dictates that the identity be validated for every access of resources, when the resource is accessed. A one-time verification is no longer sufficient.

The security tools must integrate with certificate management systems, existing identity providers (IdP) and more. If not designed from the ground up to integrate with the infrastructure the security tools can become complex. It’s critical that security solutions seamlessly integrate with the tech stack used to secure remote access to the cloud. And the integration should not just shield users from the underlying complexity, but make the process easier.

A secure access solution should simplify the process by eliminating the need for different tools for different types of access. It can simplify and enhance security posture by eliminating the need to keep local copies of passwords, certificates or keys. The unique identity associated with the user, context and destination of access should be considered before granting access to resources.

The goal is not to have applications eliminate the notion of identity or eliminate identity sprawl. The goal is to eliminate the security gaps associated with having multiple identities and levels of authorization associated with a user.

The ability to integrate with existing mechanisms of determining and verifying identity is essential. This approach not only simplifies the deployment, but also helps manage the cost and complexity involved in implementation. The ability to reuse existing infrastructure is essential for organizations at or below the security poverty line.


These are by no means the only lessons I learned at RSA 2022. But these are the ones that resonated with me and, in my opinion, deserve the most attention. They are the most critical and impactful elements to be addressed in securing remote access to the cloud. Curious what Appaegis does and what part we play in your journey to secure remote access to the cloud? You can learn more by clicking here.


Learnings from RSA 2022


Back to Blog

Related Articles

Securing the Software Development Lifecycle with Zero Trust Architecture

New Features in Appaegis Isolation Access Cloud (IAC)

With the new year come new beginnings. Here is the first in our series of regular updates on new...

Top 3 Challenges to Securing Vendor Remote Access

Shifts Driving the Need for A Modified Approach to Secure Cloud Access The global IT...