From ba29e231ffdb9c247276aa43e6a061ae4099590f Mon Sep 17 00:00:00 2001
From: midas <midas@mullsec>
Date: Tue, 4 Feb 2025 10:29:52 +0100
Subject: [PATCH] conclusion update

---
 opsec/cloud_provider_adversary/index.html | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/opsec/cloud_provider_adversary/index.html b/opsec/cloud_provider_adversary/index.html
index d4da2d0..03eae2b 100644
--- a/opsec/cloud_provider_adversary/index.html
+++ b/opsec/cloud_provider_adversary/index.html
@@ -264,7 +264,18 @@ in this post we are going to do a threat modelling exercise:<br><br>
                     Following her analysis, Alice understands that having a VPS gives her no privacy from her cloud provider. That all of her traffic and data can easily be seen, copied or moved. 
                     <br><br>
 
-                    A bare-metal server would give her more privacy and better protection from a malicious cloud provider. She can still put in place mitigations measures through her SOPS (standard operating procedures).
+                    Thus, if she needs to run a sensitive service on a VPS it will only ever be a short-lived one. Such a VPS will live on borrowed time from the moment it is started because as soon as the service provider will decide to look into it it will be easily identified and shut down. <br><br>
+
+                    One way to avoid such issues and the availability implications is to run a fleet of VPSes with load balancers and redirectors. That way, any instance being shutdown by the cloud provider becomes a non-event that does not impact overall availability. This requires the following:
+
+                    <ul>
+                        <li>Automation: spinning up a new instance must be fast, automated and standardized</li>
+                        <li>Logistics: you must identify various providers and have a way to create dormant accounts with them and schedule a "cool off" period when one shuts down an instance</li>
+                        <li>Monitoring: you must be immediately made aware when a service goes down in order to spin up a new one </li>
+                    </ul>
+
+                    <br>
+                    Keep in mind that availability is only a third of the equation, integrity and confidentiality are also in jeopardy as soon as the cloud provider takes notice. You will have to put in place mitigations measures through your SOPS (standard operating procedures).
 
                     <h2><b>Organizational mitigations</b></h2>
 
@@ -274,6 +285,11 @@ in this post we are going to do a threat modelling exercise:<br><br>
                         <li>Use of a separate server with higher security requirements for critical data</li>
                     </ul>
 
+                    <h2>Bare-metal options</h2>
+
+                    A bare-metal server would give her more privacy and better protection from a malicious cloud provider.
+
+
           
 	       </div>
 			</div><!-- /row -->