The Security-First Mindset to Unlocking the AWS Opportunity

Amazon Web Services has proven over the last 15+ years since EC2 was launched to be the cloud market leader, and any company born in the cloud often selects AWS to get off the ground. This has created a thriving global community and marketplace of cloud-first developer tools at possibly the greatest scale currently available.

The opportunities that both its console and marketplace have unlocked for technology-first companies is immense. That is why most companies early on build a co-selling and partner strategy with AWS, to achieve faster time to market and adoption of their complementary products and services.

To unlock this opportunity, there are a few boxes that need to be checked within the Amazon Partner Network to be eligible to list services in its marketplace and other AWS channels.

AWS is known to be a customer-obsessed company, and therefore any company that would like to provide services to its existing client base through its co-selling channels is required to abide by its minimum requirements for security and privacy. This security baseline is called the Foundational Technical Review (FTR), and is essentially a number of policies and controls companies need to comply with and activate to achieve this security baseline.

Jit, as a company built on AWS serverless architecture and whose product serves developer-first companies with cloud native security demands, understood that AWS would be a natural partner for achieving greater product adoption. In this post, we will dive into how Jit used dogfooding practices to rapidly comply with FTR and be listed in the AWS marketplace in a matter of weeks, and what you can do to accelerate your AWS FTR and partner network strategy.

What You Need to Know about FTR

FTR, like many other common and well-known industry standards, is essentially a list of items in several categories from security controls, to processes and culture, as well as policy and governance for AWS to ensure that any joint users can trust the services they select from within the partner network.

The FTR covers areas related to:

• Identity and access management
• Operational security
• Network security
• Backup and recovery
• Cross-account access
• Resiliency
• Regulatory compliance validation

This is not an exhaustive list, but only a few of the areas that need to be assessed against specific checks. These are subject to change based on whether you are a partner that is deployed on AWS — and this post covers FTR from the perspective of a customer hosted or deployed on AWS. This foundational review is intended to verify architectural soundness as well as an expected service level and support that AWS requires for its clients, and basically the minimum requirements to becoming an AWS trusted vendor.

Why FTR Seems Daunting

The AWS FTR process may seem daunting to many, as those leading it are often not security experts. What they see can appear to be a long list of requirements that are vague and abstract, and it’s hard to understand how to practically apply these in their architecture and systems. This is because the list is largely a self-assessment that ends up requiring quite a bit of work on both sides, without the ability to really verify aside from a few automated checks. This is then followed by a manual review by a PSA (Partner Solution Architect).

That’s why at Jit we understood that in 2023, we likely can and should do better to streamline this common process through automation to be more aligned with our core belief of shying away from point-in-time audits as much as possible and work toward replacing them with continuous security and compliance.

This is often the same dread engineering teams encounter when undergoing compliance processes, a topic we have discussed in detail historically. However, this list, like other known industry standards and frameworks, such as MVSP (minimum viable secure product), are just security plans. If there is one thing that we have learned at Jit, it’s that checklists and plans are built to be automated.

We had success with operationalizing this with OWASP’s DSOMM and even the OWASP Serverless Top 10 for our own serverless deployments. So like all of our security plans, we decided to become “user zero and do the work to automate FTR and quickly ramp up the security aspects that make up the lion’s share of the review.

Mapping Requirements to Actions … Then Automating!

The biggest lift with automating the FTR process was mapping the requirements to practical controls that fulfill the need. Below we will dive into some examples of how to take FTR from theory to practice, and the places this can be automated with or without Jit (shameless plug).

Identity and Access Management

This covers aspects related to how you manage identity and access within your solution, such as:

• Credential management
• Credential storage
• Least privilege
• Authentication
• Auditing

All of these are well-known areas that require security attention in any engineering organization, though without a defined list, these are easy to overlook. That is why it is recommended to use defined security checklists when implementing security, similar to playbooks for security incidents, to ensure you check all the boxes. The interesting part is that a lot of these technical requirements can be automated once you understand the controls you need to have in place.

So if we take credential management and storage, by making it a practice to use a secret scanner that runs, just like your CI/CD checks run on each pull request (PR), you will be sure you will never commit any hard-coded secrets or credentials to production. Most importantly, even on the off chance that you do this inadvertently, with such control in place, you will be alerted so that those credentials won’t leak any further and you will be able to quickly recycle them. Credential storage, rotation and least-privilege access (ensuring the least number of resources have access to only the truly required level of access ) can also be activated and validated by integrating a secret store and defining its policies in your automated pipeline checks.

Regular (in this case quarterly) audits to ensure you continue to comply with these requirements, what we call continuous security, is also a policy that can easily be defined and automated in a security plan. It ensures these validations are made at the required point in time. However, if we really want to implement the ideal process, that would involve continuously verifying that there is no redundant access, with controls that run these checks continuously and not as point-in-time security, as part of a change-based process. This will enable organizations to do away with expensive quarterly point-in-time audits, or leverage these solely for quick “sanity tests” or a failsafe, for an ongoing automated process.

Operational Security

Operational security in the context of FTR basically maps to one very big bucket that requires coverage, which is vulnerability management. This means that you not only need a way to identify vulnerabilities in your system, and continuously identify vulnerabilities in your system on an ongoing basis, you need a feasible action plan to remediate them, including your third-party dependencies.

There are plenty of tools available today — open source and commercial — for nearly every stack and programming language. Automating this has become a baseline security requirement for any engineering organization, but doing so before code is deployed to production is the biggest win. By identifying vulnerabilities — doing so before they are committed (like through an IDE plugin) is even better — you can save many hours of toil in hunting down these risks after the fact — from code ownership, to actually finding the line of code and understanding how to fix it. Once you build vulnerability scanning into your PR gating processes, you will see your vulnerability backlog start to decrease and greater sanity in vulnerability management achieved for your developers.

Network Security

One of the areas the network security validation covers is “least permissive rules” for security groups, very similar to least privilege. It’s yet another control that can be implemented and automated through Policy as Code. There are various open source tools available that enable you to define the GitOps policies you’d like to apply for network access (and other product and platform access). They can not only be activated but also continuously monitored for continued compliance in the long term.

Once the controls that map to each of these requirements are identified, the automation becomes the easy part, which can be applied through common open source or even already adopted commercial tooling, making the deployment a matter of a click of a button. This will not bring you 100% of the way to completing the FTR, though. Just like with other standards such as SOC2, there will still be some administrative aspects to cover. It will, however, cover the large portion of getting you through your foundational technical review, and the hardest parts to actually achieve when doing so manually.

FTR for Fun and Profit

If you are looking to get started on your AWS partner journey and are in panic mode with the FTR checklist, keep calm, automate and orchestrate. It is possible to cover most of the complex technical aspects through best-of-breed open source tools that can be automated through CI/CD pipelines, and even through security orchestration platforms that will consolidate the different controls and centralize them in a single place for continuous management and monitoring.

Jit is working toward automating this entire process through our own platform, by building an automated FTR plan that got us through the process quickly. Once the automated FTR plan is productized and put through the battery of tests to ensure quality and control, it will become available to the global AWS community to help streamline this process for anyone looking to unlock the opportunity available through the AWS community.

A final note on compliance frameworks and checklists that can seem daunting at first glance. Once we discover that a single security plan gets us much of the way to achieving another framework or checklist, such as SOC2 or MVSP, we learn that DevSecOps can derive the same benefits of automation and reuse other engineering disciplines that have been employed for years. Adopting this mindset of automation and reuse will be a big win for the security industry as a whole.

‍

Originally posted on The New Stack, Aug 9th, 2023.

‍