<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>HowTo Guides on Securosis</title><link>/research/howto/</link><description>Recent content in HowTo Guides on Securosis</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 09 Jan 2025 17:00:00 +0000</lastBuildDate><atom:link href="/research/howto/index.xml" rel="self" type="application/rss+xml"/><item><title>Defining Security Invariants</title><link>/research/howto/security-invariants/</link><pubDate>Thu, 09 Jan 2025 17:00:00 +0000</pubDate><guid>/research/howto/security-invariants/</guid><description>&lt;p&gt;&lt;em&gt;&lt;strong&gt;Note:&lt;/strong&gt; This post has been revised to include the new capabilities released by AWS prior to re:Invent 2024.&lt;br&gt;
You can also check out the re:Invent presentation we did with Securosis: &amp;ldquo;Security invariants: From enterprise chaos to cloud order&amp;rdquo; &lt;a href="DEV401_Security-invariants-From-enterprise-chaos-to-cloud-order.pdf"&gt;slides&lt;/a&gt; - &lt;a href="https://www.youtube.com/watch?v=aljwG4N5a-0"&gt;video&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Implementing Security Invariants in an AWS Management Account</title><link>/research/howto/payer-invariants/</link><pubDate>Tue, 24 Dec 2024 19:41:28 -0500</pubDate><guid>/research/howto/payer-invariants/</guid><description>&lt;p&gt;I&amp;rsquo;ve spoken a lot about &lt;a href="https://www.primeharbor.com/blog/security-invariants/"&gt;Security Invariants&lt;/a&gt;, but all of them have been implemented using Organizational Policies. That&amp;rsquo;s great, but organizational policies don&amp;rsquo;t apply to the Organizational Management Account (aka &amp;ldquo;payer&amp;rdquo;). So how does one implement invariants in a payer account?&lt;/p&gt;
&lt;p&gt;AWS would tell you that you shouldn&amp;rsquo;t be giving anyone access to the payer account, so the need for invariants should be minimal. However, that doesn&amp;rsquo;t reflect the reality that AWS never protected its customers from themselves and prevented the enabling of Organizations or Control Tower in an account with existing workloads. I would say this is a failure of Customer Obsession and demonstrates Security is not the Top Priority. AWS would hide behind shared responsibility and blame the customer.&lt;/p&gt;
&lt;p&gt;Regardless, there are many cases where workloads are in a payer account, and as a security person, you need to live with those workloads while protecting the rest of the AWS Organization. So, how do we build invariants into a payer account when SCPs and RCPs don&amp;rsquo;t apply?&lt;/p&gt;
&lt;p&gt;Enter Permission Boundaries.&lt;/p&gt;</description></item><item><title>Minimally Viable Cloud Governance</title><link>/research/howto/multicloud/</link><pubDate>Wed, 14 Feb 2024 12:02:58 -0500</pubDate><guid>/research/howto/multicloud/</guid><description>&lt;h2 id="you-are-multi-cloud-whether-you-like-it-or-not"&gt;You are multi-cloud whether you like it or not.&lt;/h2&gt;
&lt;p&gt;Most organizations have a preferred cloud provider. This is the provider where they have the most engineering expertise, have negotiated the best discounts, and have built the paved road experience.&lt;/p&gt;</description></item><item><title>Deploying AWS Backup</title><link>/research/howto/awsbackup/</link><pubDate>Tue, 05 Sep 2023 09:23:37 -0400</pubDate><guid>/research/howto/awsbackup/</guid><description>&lt;p&gt;tl;dr - here is a &lt;a href="https://github.com/primeharbor/pht-awsbackup-management"&gt;link to the scripts&lt;/a&gt;&lt;/p&gt;
&lt;h2 id="what-ransomware-in-aws-looks-like"&gt;What Ransomware in AWS looks like&lt;/h2&gt;
&lt;p&gt;In a typical ransomware attack, a threat actor will attempt to encrypt files on critical machines belonging to the victim. In exchange for a cryptocurrency payment, the threat actor will provide the decryption key and software to the victim, who then has to go through the arduous process of restoring their machines. The encrypted data is typically lost forever if the victim refuses to pay the ransom.&lt;/p&gt;</description></item><item><title>Leveraging AWS SSO (aka Identity Center) with Google Workspaces - version 2</title><link>/research/howto/aws-identity-center-google-v2/</link><pubDate>Sun, 25 Jun 2023 18:25:26 -0400</pubDate><guid>/research/howto/aws-identity-center-google-v2/</guid><description>&lt;blockquote&gt;
&lt;p&gt;This is a revised version of the original post &lt;a href="research/howto/aws-identity-center-google/"&gt;Leveraging AWS SSO (aka Identity Center) with Google Workspaces&lt;/a&gt; based on the new announcement &lt;a href="https://aws.amazon.com/about-aws/whats-new/2023/06/aws-iam-identity-center-automated-user-provisioning-google-workspace/"&gt;AWS IAM Identity Center now supports automated user provisioning from Google Workspace&lt;/a&gt; The original post is still valid, and in someways may be better, but this version has it&amp;rsquo;s own advantages.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Setting up &lt;a href="https://aws.amazon.com/iam/identity-center/"&gt;AWS IAM Identity Center (successor to AWS Single Sign-On)&lt;/a&gt;, hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.&lt;/p&gt;
&lt;p&gt;Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn&amp;rsquo;t clearly documented, and the provisioning support isn&amp;rsquo;t integrated, so here is a post to help you set it all up.&lt;/p&gt;</description></item><item><title>Leveraging AWS SSO (aka Identity Center) with Google Workspaces</title><link>/research/howto/aws-identity-center-google/</link><pubDate>Sat, 27 May 2023 06:25:26 -0400</pubDate><guid>/research/howto/aws-identity-center-google/</guid><description>&lt;p&gt;Setting up &lt;a href="https://aws.amazon.com/iam/identity-center/"&gt;AWS IAM Identity Center (successor to AWS Single Sign-On)&lt;/a&gt;, hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.&lt;/p&gt;
&lt;p&gt;Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn&amp;rsquo;t clearly documented, and the provisioning support isn&amp;rsquo;t integrated, so here is a post to help you set it all up.&lt;/p&gt;</description></item><item><title>Leveraging AWS SSO (aka Identity Center) with Azure AD</title><link>/research/howto/aws-identity-center-azuread/</link><pubDate>Tue, 16 May 2023 20:33:45 -0400</pubDate><guid>/research/howto/aws-identity-center-azuread/</guid><description>&lt;p&gt;Setting up &lt;a href="https://aws.amazon.com/iam/identity-center/"&gt;AWS IAM Identity Center (successor to AWS Single Sign-On)&lt;/a&gt; henceforth called AWS SSO (because AWS charges for egress), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.&lt;/p&gt;</description></item><item><title>Cloud Penetration Tests</title><link>/research/howto/pentest/</link><pubDate>Sat, 15 Apr 2023 11:00:04 -0400</pubDate><guid>/research/howto/pentest/</guid><description>&lt;p&gt;&lt;img src="SoYouWantToGetAPentest.png" alt="Captian America saying &amp;ldquo;So you want to get a Pen Test&amp;rdquo;"&gt;&lt;/p&gt;
&lt;p&gt;This past weekend I spoke at &lt;a href="https://bsidesnash.org/"&gt;BSides Nashville&lt;/a&gt; on offensive operations in AWS: &lt;em&gt;&lt;strong&gt;Get outta my host and into my cloud&lt;/strong&gt;&lt;/em&gt;. While I was finishing the talk, &lt;a href="https://www.nojones.net/"&gt;Nick Jones&lt;/a&gt; published a blog post of his own: &lt;a href="https://www.nojones.net/posts/on-aws-pentesting"&gt;On AWS Penetration Testing&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Incident Response in AWS</title><link>/research/howto/aws-ir/</link><pubDate>Sat, 27 Aug 2022 12:50:04 -0400</pubDate><guid>/research/howto/aws-ir/</guid><description>&lt;p&gt;At &lt;a href="https://www.bsidesatl.info/"&gt;BSides Atlanta&lt;/a&gt; today I gave a talk on how to handle an incident in AWS. The talk and this post is intended to help those already familiar with the principles of Incident Response to understand what to do when the incident involves the AWS Control Plane. You can find the &lt;a href="slides.pdf"&gt;Slides here&lt;/a&gt;.&lt;/p&gt;</description></item></channel></rss>