Introduction
Resilient patching (RP) is a robust control that neutralizes attacks and helps you win the patching race by allowing the DevOps teams extra time to test patches and upgrade vulnerable software. However, it is more than a temporary mitigation, and is forward-looking in terms of outcomes. With RP, you patch once and prevent forever!
A New Approach Towards Building Resiliency
Traditionally, preventive controls have focussed on intrusion prevention. Make one mistake, and the intruder wins. Mistakes come in various forms: human error or misconfiguration, human greed or phishing, application vulnerability, supply chain compromises, credential compromise, and the list goes on. Instead of chasing intrusions, it is far easier to harden your apps. Let the intrusion happen, because with RP it will be dead on arrival and jailed at birth.
Cloud Risks
Cloud represents a new consumption model and brings its own new set of risks. There is shared responsibility with the service provider, which changes based on whether the consumption is for IaaS, PaaS, or SaaS services.
With IaaS, the cloud provider is only offering hardware infrastructure. The operating system and associated apps, the applications you write, along with the supply chain, are yours to secure.
SaaS is the other end of the spectrum, where the app is managed and operated by the service provider. Even in this case, you are still responsible for (encrypting) your data and the access controls around API use. This is the absolute minimum security you need on the cloud.
Cloud risks can broadly be categorized under these three buckets
- Application vulnerabilities: this includes your own apps, your supply chain, and open source utilities that come bundled with the OS.
- SaaS configuration: secure configuration of SaaS in general, and specifically around IAM and access controls. These are also apps but consumed as a service.
- User and partner access: apart from apps, some outsiders can cause trouble, namely (privileged) users and partners.
RP for Application Vulnerabilities
This is the sweet spot and the obvious usage for resilient patching. With RP, you can patch any app, any language, from any source without touching the app.
These external controls ensure the apps always adhere to the least privilege with deviations locked out. RP can be applied as code, with gitOps, ensuring the controls always stay in sync with the deployed apps. There is no risk of configuration errors as the technology is self-correcting and self-revealing.
RP for SaaS API Access
The problem with SaaS mostly revolves around identity and access control. SaaS has a secret problem because secrets and credentials (also known as service accounts) are used to establish identity. On top of it, configuring the least privileged policies is no child’s play, and it gets exponentially complex as the number of apps and SaaS services grows in your environment.
RP can be used to automate access control policies around SaaS/API access. Creating explicit policies around which apps from your environment can access the SaaS APIs naturally satisfies the need for least privilege access.
RP obviates the need for credential management because the access controls are identity-based and secret-free. Only legitimate apps can access SaaS APIs, and mere possession of secrets/credentials does not grant access. This is what locks down an intruder from enjoying the same access as your legitimate applications.
Remember, intruders, are dead on arrival and jailed at birth with RP.
RP for partner access
Partners usually have well-defined entry points through which they access your services. By applying the resilient patch on the partner-facing apps, you can rest assured that any filth coming from outside cannot pollute your environment.
Learn More
Short demo video links on Resilient Patching:
Log4shell (remote code execution)- CapitalOne attack
detection andprevention (SSRF vulnerability) Equifax (remote code execution)