The last few years have proven challenging for even the most agile of companies. The shift to remote work during the pandemic, which now appears to be the status quo for the foreseeable future, pushed corporate networks to their limits. Providing consistent, reliable, and secure remote access to internal resources for employees, partners, and contractors has become more important than ever before.
For Adobe, the challenge was compounded by the fact that we added thousands of new employees during the pandemic, which placed even greater pressure on our VPN solution. In order to meet the connectivity requirements of the burgeoning number of remote connections to our corporate resources, we needed to rethink our VPN environment from the ground up. We also needed to ensure our VPN environment more fully matched the risk and decisioning capabilities of our zero-trust enterprise networking platform.
Migrating to a new, more robust VPN solution has allowed us to perform advanced security posture checks and tighten Access Control Lists (ACLs) and naming services. These changes have helped Adobe improve our overall security posture as well as our intelligence gathering efforts. More specifically, we can better monitor and manage VPN connections to our network, especially those coming from third parties, thereby improving our ability to allow valid connections while blocking malicious actors.
Let’s dive deeper into the key components of our advanced VPN security strategy, so you can apply some of what we learned to improve the security posture of your own VPN deployments.
Improving Security Policy Management
One of the most exciting capabilities offered by the new VPN environment is a set of APIs with which we can interface with, allowing us to not only improve overall security policy management but also conduct endpoint security posture checks during authentication. With the ability to pull different connection attributes from the solution — such as IP address, VPN group owners, and traffic hits — we can analyze and manage connections based on these attributes.
We realized that this new capability could fundamentally change how we manage risk inherent in remote connectivity, enabling us to better pinpoint and block the most critical risk factors while limiting negative impact on valid connections. First, we needed to create a risk framework to interface with the VPN APIs.
Designing the Risk Framework
Before we put virtual pen to paper, we outlined four (4) primary goals of the new risk framework:
- Ensure the application of “principle of least privilege” to any new and existing connectivity in Adobe’s VPN environment
- Confirm that existing high-risk connectivity is properly identified and addressed
- Verify that any future requests are properly vetted before granting access
- Provide a risk-based view for policy owners and members to understand what connectivity is in place
While Adobe has always enforced a least privilege policy over our VPN usage, we needed additional guardrails to help avoid the natural user temptation to request more access than needed. To counter this behavior, our framework codifies the conditions that introduce risk into our systems.
Defining Risk
In order to implement the strategy above, we needed to define what risk means to Adobe in terms of traditional VPN rules. Using the standard VPN rule elements — Source User, Source Location, Destination Address, and Service/Application (TCP/UDP and port number), we defined the following rules:
Other risk factors for which we defined rules in our framework include:
- Any user source group with more than 10 members
- Vendor worker location
- Traffic size
- Traffic patterns
Applying the Risk Framework
To apply the rules and identify the defined risks, we built a portal using Python and Django that automatically flags risks in the policy based on their risk classification:
As illustrated in the graphic above, the application pulls data from both Active Directory and our VPN solution. Then, we match the policy that is pulled directly from our firewalls and attribute ownership to a specific user or group within Active Directory.
Extending the Risk Framework
While the high- and medium-risk rules outlined above are the most commonly applied in Adobe’s VPN environment, our risk framework is infinitely customizable and allows us flexibility to apply connectivity rules in ways we previously could not. Using this risk framework, we can now:
- Assign ownership of specific rules to internal teams requesting third-party access, making them responsible for allowing risky access to their vendors. Attributing ownership to specific teams allows security teams to trace back responsibilities and verify what existing connectivity is required.
- Give internal teams the ability to understand what a high- or medium-risk rule is and how it can be addressed. The risks provide data for security teams to work with stakeholders and help ensure connectivity exists only where it is specifically required (e.g., giving access only to a specific IP rather than an entire subnet).
- Dynamically analyze subnets and IPs to identify a wide variety of security threats, including subdomain takeovers, access/authorization bugs, and malicious traffic.
- Dynamically search policies based on owner, IP, subnet, service, or application using jquery/datatables. This allows us to search and filter connectivity by any characteristic, saving time for both our security teams and owners of VPN rules.
Overcoming Challenges
As with any new technology solution, migrating to a new VPN provider brought with it people and process challenges. While implementing the new risk framework and making policy changes to VPN rules, we faced two (2) primary challenges:
- User impact. Deleting high-risk policies that have significant usage can be problematic and removing high-risk traffic requires a careful balance between user impact and potential outages. One of the best ways to address this is with proper communication. We found that working directly with users on securely designing proper traffic flow is the best way to minimize impact to users.
- New policies. Constant onboarding of new partners around the globe requires ever-changing connectivity requests and access to resources which, in turn, can introduce new risks that must be identified and mitigated. To address this challenge, we proactively work with requesters to ensure they understand the policy they own and the resources to which they are requesting access, In addition, we reactively deploy code that automatically identifies risks as soon as any change is made — as defined in the risk framework above.
Looking Ahead
Typical for Adobe, our VPN strategy won’t remain status quo for long; we’re already planning a range of enhancements to our strategy and risk framework that we’ll be rolling out in the near future. Some of these include:
- Generating immediate feedback for stakeholders so fewer risky requests are submitted.
- Implementing a machine learning framework to automatically flag and identify risks as traffic patterns change.
- Establishing automatic rule deletion based on rule usage. For example, if a rule has not been used for 90 days, it will be deleted automatically.
- Applying a recertification process to give policy owners the opportunity to perform review of connectivity on a specific cadence they define with security.
Migrating to our new VPN network has allowed us to focus on higher, more critical risks to help us shape the policy review process both programmatically and for folks reviewing the policy. As we continue to address evolving risks, there will be continual opportunity to iterate to better secure our environment for all.
