閉める
閉める
明日に向けたネットワーク
明日に向けたネットワーク
サポートするアプリケーションとユーザー向けに設計された、より高速で、より安全で、回復力のあるネットワークへの道を計画します。
          Netskopeを体験しませんか?
          Netskopeプラットフォームを実際に体験する
          Netskope Oneのシングルクラウドプラットフォームを直接体験するチャンスです。自分のペースで進められるハンズオンラボにサインアップしたり、毎月のライブ製品デモに参加したり、Netskope Private Accessの無料試乗に参加したり、インストラクター主導のライブワークショップに参加したりできます。
            SSEのリーダー。 現在、シングルベンダーSASEのリーダーです。
            SSEのリーダー。 現在、シングルベンダーSASEのリーダーです。
            Netskope、2024年ガートナー、シングルベンダーSASEのマジック・クアドラントでリーダーの1社の位置付けと評価された理由をご確認ください。
              ダミーのためのジェネレーティブAIの保護
              ダミーのためのジェネレーティブAIの保護
              ジェネレーティブ AI の革新的な可能性と堅牢なデータ セキュリティ プラクティスのバランスを取る方法をご覧ください。
                ダミーのための最新のデータ損失防止(DLP)eBook
                最新の情報漏えい対策(DLP)for Dummies
                クラウド配信型 DLP に移行するためのヒントとコツをご紹介します。
                  SASEダミーのための最新のSD-WAN ブック
                  SASEダミーのための最新のSD-WAN
                  遊ぶのをやめる ネットワークアーキテクチャに追いつく
                    リスクがどこにあるかを理解する
                    Advanced Analytics は、セキュリティ運用チームがデータ主導のインサイトを適用してより優れたポリシーを実装する方法を変革します。 Advanced Analyticsを使用すると、傾向を特定し、懸念事項に的を絞って、データを使用してアクションを実行できます。
                        レガシーVPNを完全に置き換えるための6つの最も説得力のあるユースケース
                        レガシーVPNを完全に置き換えるための6つの最も説得力のあるユースケース
                        Netskope One Private Accessは、VPNを永久に廃止できる唯一のソリューションです。
                          Colgate-Palmoliveは、スマートで適応性のあるデータ保護により「知的財産」を保護します
                          Colgate-Palmoliveは、スマートで適応性のあるデータ保護により「知的財産」を保護します
                            Netskope GovCloud
                            NetskopeがFedRAMPの高認証を達成
                            政府機関の変革を加速するには、Netskope GovCloud を選択してください。
                              一緒に素晴らしいことをしましょう
                              Netskopeのパートナー中心の市場開拓戦略により、パートナーは企業のセキュリティを変革しながら、成長と収益性を最大化できます。
                                Netskopeソリューション
                                Netskope Cloud Exchange
                                Netskope Cloud Exchange(CE)は、セキュリティ体制全体で投資を活用するための強力な統合ツールをお客様に提供します。
                                  Netskopeテクニカルサポート
                                  Netskopeテクニカルサポート
                                  クラウドセキュリティ、ネットワーキング、仮想化、コンテンツ配信、ソフトウェア開発など、多様なバックグラウンドを持つ全世界にいる有資格のサポートエンジニアが、タイムリーで質の高い技術支援を行っています。
                                    Netskopeの動画
                                    Netskopeトレーニング
                                    Netskopeのトレーニングは、クラウドセキュリティのエキスパートになるためのステップアップに活用できます。Netskopeは、お客様のデジタルトランスフォーメーションの取り組みにおける安全確保、そしてクラウド、Web、プライベートアプリケーションを最大限に活用するためのお手伝いをいたします。

                                      A MITRE-based Analysis of a Cloud Attack

                                      Jan 23 2020

                                      When you look at the details surrounding attacks in the cloud, how easy is it for you to quickly determine what happened and how to prevent a similar attack in your own environment? Applying the MITRE Att&ck Cloud Matrix is a great resource to classify and understand cloud-based attacks.

                                      In this post, we will revisit a previous blog post to demonstrate how MITRE’s new Cloud Matrix can be applied to help us analyze the threat and prevent it from happening in your environment. We’ll recount the scenario, which exposes data in a storage bucket hosted by the Google Cloud Platform (GCP). Then we will examine some mitigations provided by MITRE, and look at how we could implement these in GCP.

                                      Summary of the Scenario

                                      The original scenario was an attack in which I escalated my privileges to remove a security perimeter established around a storage bucket that was storing sensitive data. The security perimeter only allowed people to access the bucket if they were coming from the correct IP address range. Below is a diagram, along with the steps taken to complete the attack.

                                      The attack followed these basic steps:

                                      1. A service account credential was accidentally exposed, which had OSLogin permissions (allows someone to SSH to virtual machines).
                                      2. Using the exposed credential, I SSHd into a publicly exposed virtual machine.

                                      The virtual machine was running with the default service account for Google Compute Engine (which has too many permissions), and the scope associated was, “Allow full access to all Cloud APIs.”

                                      1. Using the default service account, I listed the other service accounts in that project.
                                      2. I located a service account that had admin permissions and activated that service account from the virtual machine. At that point, I had administrative privileges at the Organization level.
                                      3. Using the admin service account, I removed a VPC Security Perimeter.
                                      4. After removing the VPC Security Control Perimeter, I accessed the data in the storage bucket that was previously protected.

                                      The attack’s impact was the exposure of sensitive data. 

                                      Breaking Down the Att&ck

                                      Below are the tactics, techniques, and mitigations found in MITRE’s Cloud Matrix matched with parts of the attack. The numbers match with the attack steps in the section above. The text in italics under the MITRE mitigation column was taken directly from MITRE’s Cloud Matrix.

                                      Along with MITRE’s Techniques and Mitigations, I’ve added some specific mitigative steps to take for GCP.

                                      Step 1

                                      Description: A valid credential was found in source control that was publicly exposed.

                                      Scan your source code for credentials, and then update any credentials found. This is not specific to GCP. However, the GCP service account credential is an RSA key, so you will need to be sure that your scans include private RSA keys.

                                      Step 2

                                      Description: A SSH connection was established from outside the organization to a virtual machine hosted by GCP using the exposed credential.

                                      Only allow SSH authentication from allow listed IP addresses. This can be configured in GCP firewall rules.

                                      Step 3 + 4

                                      Description: The credentials of the publicly exposed virtual machine were used to assume another identity that has administrative privileges in GCP.

                                      The publicly exposed workload had a service account with no scope limitations, so its full capabilities would be allowed. In this case, the full capabilities meant that the virtual machine’s identity could be used to enumerate and impersonate other service accounts in the same GCP project.

                                      To prevent this, you would need to scan the compute instances in your environment and make sure the “scopes” are not set to ‘Allow All’ while using the default service account. More information about service accounts and scopes for the compute engine is available here.

                                      In addition, an administrative service account with an Organization-level binding had been created in the same GCP project as a publicly exposed workload. To prevent this, there are two main steps you can take:

                                      1. Do not give service accounts administrative privileges. In addition, do not bind them at the Organization level.
                                      2. If you must give a service account some administrative privilege or a binding at the Organization level, create that service account in a private project. Any publicly exposed workloads should be in projects separated from administrative service accounts.

                                      Step 5

                                      Description: A cloud perimeter control was removed, which protected sensitive data in part of the GCP environment.

                                      GCP does not currently allow using conditions in Identity and Access Management (IAM) policies, but it is available in beta, and may change. Much like AWS, the conditions may allow us to set permissions that will only work from certain IP addresses.  More information about it is available here.

                                      Step 6

                                      Description: Sensitive data was accessed from an IP address outside of the organization.

                                      We did have a VPC service control perimeter, which disallowed access from outside IP addresses. However, the attack removed that control. The preventative steps in for the other techniques should prevent this from happening. However, we should also be alerted to the modification or removal of a VPC service control perimeter. In order to generate that type of alert, you must monitor the audit logs. More information on audit log monitoring is available here.

                                      Conclusion

                                      Without using the MITRE Att&ck Cloud Matrix, a common approach to this incident would be to make sure that no credentials are leaked like this in the future. However, as you can see from all of the content above, there are a number of other mitigations that should be considered as well.

                                      Due to the abstract nature of the cloud, and the immense amount of services and configuration settings that could be deployed, it’s difficult to understand all the factors involved in an attack. The exercise of applying MITRE’s Att&ck Cloud Matrix, discovering possible mitigations in the matrix, and then mapping those mitigations to your specific environment should be something employed to maintain a strong security posture. This exercise will also help you understand and evaluate security tool features that are important for your own use cases as well.

                                      author image
                                      Colin Estep
                                      Colin Estep has 16 years of experience in software, with 11 years focused on information security. He's a researcher at Netskope, where he focuses on security for AWS and GCP.
                                      Colin Estep has 16 years of experience in software, with 11 years focused on information security. He's a researcher at Netskope, where he focuses on security for AWS and GCP.

                                      Stay informed!

                                      Subscribe for the latest from the Netskope Blog