Risk Management for Vendor Ecosystem

Many orgs focus too long on assessing the risk before deciding to onboard a vendor.

Multiple control frameworks (COBIT, ISF, ISO, NIST, HITRUST) include hundreds of questions that are often redundant.

Furthermore, these assessments couple the vendor governance witht the actual solution.  Hence, orgs spending weeks on evaluating each vendor.

The solution here is a laser-focused framework that includes a base for the vendor, along with specific questions for the solution.  I would also advocate for a vulnerability scan of the solution by the specific org doing the assessment. 

Vendor (Security) Reviews are not Solution Security Reviews

 A vendor's (security/privacy) holistic governance is not the same as the security/privacy posture of the solution a larger organization is looking to procure.

The reality is that many startups/SMBs have solutions that are (considerably) different, from a cyber perspective, then their general posture.  Many (startup/SMB solutions) are based/hosted with cloud service providers (CSPs), and.therefore, require a separate level of review.

Third-party risk management (TPRM) processes and teams are prevalent in corporate organizations; however, experience shows a generic coupling of the solution with the vendor that seems inadequate.

So, it is advocated that larger organizations focus on high-level governance for the vendor-at-large, coupled with low-level verification of the solution at hand. 

How is this accomplished?  Well, focus on control frameworks (NIST, ISO, SIG, HITRUST, ISF, COBIT) for the vendor, coupled with specific deep-dives on the solution at large.  Deep-dives should include recent vulnerability scans/penetration tests/risk assessments of the specific solution from an objective third-party, with a control mapping of said solution back to organizational governance, as well as benchmarks against CSP well-architected frameworks (that are prevalent these days). 

 

Dont Replicate Your Data Center Setup in the Cloud

 A multitude of corporate IT/Cyber departments attempt to replicate their network architecture in the cloud.  Unfortunately, that is not the way to go regarding cloud transformation.  When organizations use the cloud it makes the most sense to leverage native solutions as much as possible.

While trusting cloud service providers (CSP) completely is not prudent, many CSPs have matured their services, especially security-centric solutions.  With that said, if there are any doubts/concerns, the most pragmatic choice is to leverage enterprise data protection solutions before data is migrated to the cloud.  Said solution could negate concerns about a CSP's data handling procedures.

Are SOC2 / ISO 2700x / HITRUST Attestations Enough for PaaS / SaaS Providers

 The short answer is, not alone.  Attestations outside of penetration testing reports, or the ability for an org (that desires to provision said provider's services) to run a vulnerability scan, are not acceptable.

As an individual who has provided internal security assessments, as well as many external, the scope of attestation much too often is extremely limited in scope.  Therefore, these reviews do not provide an adequate benchmark of security &/or privacy compliance or posture.

So, kick the proverbial tires; while not requiring an expensive onsite audit....

     

Well-Architected Frameworks for Cloud Service Providers (CSP)

 CSPs now have created thought leadership for architecting cloud-based workloads:

Amazon (AWS): https://docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf

Microsoft Azure: https://azure.microsoft.com/en-us/blog/introducing-the-microsoft-azure-wellarchitected-framework/

Google (GCP): https://cloud.google.com/architecture/framework

Oracle (OCI): https://www.oracle.com/cloud/architecture-center.html

AWS Lambda, Serverless Function-as-a-Service (FaaS), Primer

AWS paved the way via FaaS years ago.  However, I have yet to find a succinct, aggregation of best practices on how to use & deploy these solutions.  So, here you go:

Overview/Serverless Application Model (SAM): https://d1.awsstatic.com/whitepapers/serverless-architectures-with-aws-lambda.pdf; https://aws.amazon.com/blogs/compute/building-well-architected-serverless-applications-approaching-application-lifecycle-management-part-1/; https://aws.amazon.com/blogs/compute/category/compute/aws-serverless-application-model/; https://docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf

Orchestrating serverless services: https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/

Tracing & monitoring Lambda: https://www.infoq.com/articles/tracing-aws-lambda-functions/; https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-cloudwatch-metrics-logging.html

Negating latency challenges with cold starts: https://epsagon.com/development/how-to-minimize-aws-lambda-cold-starts/

Securing Lambda functions: https://medium.com/orchestrated/steps-to-secure-aws-serverless-lambda-part-1-a6e5d1b05f45

Edge functions: https://www.stackery.io/blog/lambda-at-edge/

Securing edge functions: https://aws.amazon.com/blogs/networking-and-content-delivery/authorizationedge-how-to-use-lambdaedge-and-json-web-tokens-to-enhance-web-application-security/ 

Tagging: https://www.cloudforecast.io/blog/aws-tagging-best-practices/

Layer-7 Logging

PPT on Layer-7 Logging