avatarTeri Radichel

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

3690

Abstract

oints.</li></ul><div id="5289" class="link-block"> <a href="https://readmedium.com/aws-fips-codecommit-vpc-endpoint-returns-public-ip-address-a74efe06357f"> <div> <div> <h2>AWS FIPS CodeCommit VPC Endpoint Returns Public IP Address</h2> <div><h3>May be as designed but if not, someone should check this — and if by design it makes network security configuration…</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*4oxP4LXk8l8c3mpRvO7ejg.png)"></div> </div> </div> </a> </div><ul><li>Make sure all organizational restrictions via SCPs work — via the entire organization, an organizational unit, or an account. I’ve tried to use organizational values in policies before and they did not work.</li></ul><figure id="e825"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*F9okk2Z2zL4J69ViWdgYoA.png"><figcaption></figcaption></figure><div id="c1ff" class="link-block"> <a href="https://docs.aws.amazon.com/organizations/latest/userguide/orgs_permissions_overview.html"> <div> <div> <h2>Managing access permissions for your AWS organization</h2> <div><h3>undefined</h3></div> <div><p>undefined</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/)"></div> </div> </div> </a> </div><ul><li>Make sure that every request has all the global values that are available for conditions.</li></ul><div id="a91b" class="link-block"> <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html"> <div> <div> <h2>AWS global condition context keys</h2> <div><h3>Describes each of the AWS global condition keys available to use in IAM policies.</h3></div> <div><p>docs.aws.amazon.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/)"></div> </div> </div> </a> </div><ul><li>Make sure VPC flow logs are showing all expected activity. If they are not, something may be routing incorrectly.</li><li>Errors in CloudFormation or other SDKs that bubble up from the original source need to make sense for all error types of all actions.</li><li>Validate that no invalid values can enter the software and produce unexpected events. That is prevented by explicitly checking for a list of valid values wherever possible and rejecting anything that doesn’t match. Invalid values passed into systems is the root cause of most security vulnerabilities.</li><li>Do not allow teams to log invalid values that won’t work in policies. For example, if you can’t use a domain name in a policy, then teams should not be allowed to log a domain name in that field.</li><li>Every service needs a link to security best practices in the same place on the left navigation menu. This should be customer security best practices that customers should be doing for that service.</li><li>Every service needs a link to service specific infrastructure details such as end to end encryption, what can and cannot be encrypted with a customer KMS key anywhere customer data or logs are stored, what is and is not logged, etc.</li><li>Every service needs a link to a SPECIFIC page that

Options

lists the infrastructure security that applies to every AWS Service like the now deprecated white paper on that topic.</li><li>CloudFormation support with sufficient examples at the bottom of the page.</li><li>A link to the CloudFormation resource page in the left menu.</li><li>A link to the AWS CLI commands in the left menu.</li><li>A link to the IAM actions and conditions in the left menu.</li><li>Any other relevant links to SDKs and tools in the left menu.</li><li>Menus across services should be consistent so customers always know where to look for the above resources when using a new service.</li><li>Make sure any recommended tools in the documentation can be deployed via a private AWS network when customers are using a VPC Endpoint. In fact, all AWS deployments need to address this issue. Infiltrated code causes the largest breach of US governments in history — the Solar Winds breach.</li></ul><div id="892d" class="link-block"> <a href="https://readmedium.com/solar-winds-breach-eae3ca6773d"> <div> <div> <h2>SolarWinds Breach</h2> <div><h3>Articles by Teri Radichel on the SolarWinds Breach</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/0*oxYjpzo3-Mkah5zV.png)"></div> </div> </div> </a> </div><ul><li>Get a penetration test for all new services that includes fuzzing by an external third party. (That’s what I do if you need help and I’m an <a href="https://aws.amazon.com/developer/community/heroes/teri-radichel/">AWS Security Hero</a> if you were not aware.) I’ve found issues in AWS products before using this method on client penetration tests and directed the client to speak to AWS about it.</li></ul><p id="e89e">Those are just some of the things I have seen recently or in the past. I’m sure people who work on AWS day in and day out and have seen issues can think of others.</p><p id="724a">Follow for updates.</p><p id="4a3a">Teri Radichel | <i>© <a href="https://2ndsightlab.com/?source=post_page---------------------------">2nd Sight Lab</a> 2023</i></p><div id="8b5f"><pre><span class="hljs-section">About Teri Radichel:

⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab</pre></div><div id="caae"><pre><span class="hljs-section">Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</span>
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation</pre></div><div id="5a42"><pre>Follow <span class="hljs-keyword">for</span> more stories like <span class="hljs-keyword">this</span>:

❤️ Sign Up my Medium Email List ❤️ Twitter: <span class="hljs-meta">@teriradichel</span> ❤️ LinkedIn: https:<span class="hljs-comment">//www.linkedin.com/in/teriradichel</span> ❤️ Mastodon: <span class="hljs-meta">@teriradichel</span><span class="hljs-meta">@infosec</span>.exchange ❤️ Facebook: 2nd Sight Lab ❤️ YouTube: @2ndsightlab</pre></div><figure id="7286"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*4oxP4LXk8l8c3mpRvO7ejg.png"><figcaption></figcaption></figure></article></body>

Security Standards for All AWS Services

A checklist for Amazon product teams — for testing AWS Security for new and existing AWS Services

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Bugs | AWS Security | Secure Code

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I wonder if AWS has a checklist of things that QA teams need to test before new services or changes to services are released. If such a list exists, and it probably should, here’s what I would recommend adding to the list.

Also, it seems like some of these things could easily be automated, like checking that the correct IP address and principal get logged and works properly in a corresponding SCP, and that all actions and all details for all actions get properly logged.

Here’s my list. This is not a complete list by any means. It is a list of things I have noticed recently.

  • Every service needs the ARN and other details used in policies or to review logs on the dashboard for that resource.
  • All actions need to be logged in CloudTrail.
  • Actions need to consistently log user-friendly error messages, when they occur that tell the user precisely how to fix the problem. (Ideally linking to specific associated documentation — #awswishlist)
  • The user, resources, and other details in the event should properly be populated in the CloudTrail list.
  • The search function in CloudTrail needs to work correctly for each field and query option. This should be re-tested after every change to code that may affect it.
  • No actions should be recorded as “root” unless it was, in fact, the root user that performed the action.
  • All actions should be recorded with the AWS principal who took the initial action that ultimately triggered the event — not an AWS service name.
  • If the AWS Service name is in fact triggering the initial event rather than a user, then the service may be listed.
  • Indicate where a service-linked or IAM role triggered an action. ServiceLinked roles are not subject to SCPs. Customers should be able to query on all actions taken by ServiceLinked roles.
  • Include the IP address not only a domain name in CloudTrail logs. Domain names don’t work for security incident response as a domain name can refer to many IPs, not a specific device. They are also subject to things like cache poisoning and DNS rebinding which makes domain names point to invalid IP addresses.
  • All actions should be logged with the principal and the IP address at which that principal is located — not some internal AWS IP address — otherwise policies don’t work.
  • If the service works with a VPC Endpoint (which all should) test all actions to make sure they occur on private IP addresses and work with any SCPs that require actions to be taken via VPC Endpoints.
  • Make sure all organizational restrictions via SCPs work — via the entire organization, an organizational unit, or an account. I’ve tried to use organizational values in policies before and they did not work.
  • Make sure that every request has all the global values that are available for conditions.
  • Make sure VPC flow logs are showing all expected activity. If they are not, something may be routing incorrectly.
  • Errors in CloudFormation or other SDKs that bubble up from the original source need to make sense for all error types of all actions.
  • Validate that no invalid values can enter the software and produce unexpected events. That is prevented by explicitly checking for a list of valid values wherever possible and rejecting anything that doesn’t match. Invalid values passed into systems is the root cause of most security vulnerabilities.
  • Do not allow teams to log invalid values that won’t work in policies. For example, if you can’t use a domain name in a policy, then teams should not be allowed to log a domain name in that field.
  • Every service needs a link to security best practices in the same place on the left navigation menu. This should be customer security best practices that customers should be doing for that service.
  • Every service needs a link to service specific infrastructure details such as end to end encryption, what can and cannot be encrypted with a customer KMS key anywhere customer data or logs are stored, what is and is not logged, etc.
  • Every service needs a link to a SPECIFIC page that lists the infrastructure security that applies to every AWS Service like the now deprecated white paper on that topic.
  • CloudFormation support with sufficient examples at the bottom of the page.
  • A link to the CloudFormation resource page in the left menu.
  • A link to the AWS CLI commands in the left menu.
  • A link to the IAM actions and conditions in the left menu.
  • Any other relevant links to SDKs and tools in the left menu.
  • Menus across services should be consistent so customers always know where to look for the above resources when using a new service.
  • Make sure any recommended tools in the documentation can be deployed via a private AWS network when customers are using a VPC Endpoint. In fact, all AWS deployments need to address this issue. Infiltrated code causes the largest breach of US governments in history — the Solar Winds breach.
  • Get a penetration test for all new services that includes fuzzing by an external third party. (That’s what I do if you need help and I’m an AWS Security Hero if you were not aware.) I’ve found issues in AWS products before using this method on client penetration tests and directed the client to speak to AWS about it.

Those are just some of the things I have seen recently or in the past. I’m sure people who work on AWS day in and day out and have seen issues can think of others.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
AWS
Service
Security
Testing
Checklist
Recommended from ReadMedium