Zenn
🤖

RISKENのスキャン機能を試す

2021/11/21に公開
AWS
GitHub
Google Cloud
WordPress
risken
tech

RISKENというセキュリティのモニタリングツールを色々さわっていきたいと思います

RISKENを動かす

前回、RISKENというセキュリティモニタリングツールをローカルPCで動かしてみた という記事でローカル環境でRISKENを動かす手順を記載しました。今回はこちらの続きです。

デモ動画

雰囲気こんな感じです、というデモ動画です

https://youtu.be/3HbIpBDmSRw

プロジェクトを作成する

RISKENはまず最初にプロジェクトというものを作る必要があるので、適当に作ります

  • Project > New 画面にいきます
  • 適当なプロジェクト名を入力します

Project

WordPressのWEBサイトをスキャン

WEBサイトのスキャンをかけることができます。試しにWordpressの機能を使ってみます

＊絶対に他人のサイトはスキャンかけないでください

スキャン設定

  • Diagnosis > WPScan 画面にいきます
  • 右上の NEW をクリックして Target URL を登録します
  • 登録後に一覧をクリックして、左下のSCAN ボタンをクリックするとスキャンが開始されます

wordpress

スキャン詳細

実態としては主にWPScanというツールを使ってスキャンされます。詳細についてはドキュメントを参照。

OSINTスキャン

OSINTツールを使ってインターネットに散らばっているセキュリティリスク情報を収集します。ためしにドメイン監視をやってみたいと思います。

スキャン設定

  • OSINT > OSINT 画面にいきます
  • 右上の NEW をクリックして以下を登録します
    • ResourceType: Domain
    • ResourceName: your-domain.com
  • 登録後に一覧をクリックして、左下のSCAN ボタンをクリックするとスキャンが開始されます

domain

スキャン詳細

登録されたドメインのサブドメイン情報を収集し、各ドメインについてスキャンが実行されます。サブドメイン情報の収集は各種サーチエンジンにインデックスされた情報を検索します。（なので、インターネット上に公開していないドメインは収集されません）

  • stgやjenkinsなどのキーワード（Detect Wordで設定）を含むドメインが公開状態になっていないか
    • stg-app.your-domain.com
    • jenkins.your-domain.com
    • ...
  • httpsのサイトを発見した場合はサーバ証明書の有効期限が迫っていないか、切れていない
  • サブドメインテイクオーバーのセキュリティリスクがないか

などをチェックします

詳細についてはドキュメントを参照。

ソースコードのシークレットスキャン

GitHubリポジトリのソースコードに対してクレデンシャルスキャンをかけることができます。

スキャン設定

  • Code > Gitleaks 画面にいきます

  • 右上の NEW をクリックして以下の情報を登録します

    • Name: test
    • Type: User
    • TargetResource: gassara-kys (ユーザ名 OR Organization名)
    • GitHubUser: RISKEN
    • PersonalAccessToken: xxx (ご自身のトークンを設定してください 詳細は GitHubドキュメント参照)
    • ScanPublicRepository: ON

  • 登録後に一覧をクリックして、左下のSCAN ボタンをクリックするとスキャンが開始されます

github

スキャン詳細

上記の設定例で登録した場合、 gassara-kys というGitHubユーザののPublicリポジトリがすべてスキャンされます。
主に Gitleaksというツールでクレデンシャル情報がリポジトリに保存されてないかがチェックされます
詳細についてはドキュメントを参照。

AWSへのスキャン

AWSのスキャンを行うためには、IAMの認証情報が必要になります。
スキャン元 のAWSアカウントと、 スキャン先 のAWSアカウントが存在するイメージです。

アカウントA -> (RISKENのAWSスキャン) -> アカウントB

ただし、アカウントAとアカウントBは同一でも問題なくスキャンできます。（自分自身のプラットフォームをスキャンする）

今回はひとつのアカウントでAWSスキャンを実行してみます。
RISKENのローカル環境側の準備もあり、説明が長い＆ややこしいんですが、書いてみます。
ざっくりの流れは以下です。

  1. スキャン元のAWSアカウントでIAMユーザを発行する
  2. 上記IAMユーザの認証情報をRISKENに設定する
  3. スキャン先のロールを作成する
  4. スキャンする

IAMユーザ発行

IAMポリシーの作成

  • IAMユーザにアタッチするためのポリシーを先に作成します
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "*"
        }
    ]
}
  • IAMユーザを作成し、上記のポリシーをアタッチします
  • 作成後アクセスキー情報を保存しておきます

IAMユーザ

IAMユーザのクレデンシャルをRISKENに設定する

以下をRISKENのコンテナの環境変数にわたす必要があります。

キー 値 説明
AWS_ACCESS_KEY_ID 先程作成したIAMユーザの AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY 先程作成したIAMユーザの AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN - STSで一時的なキーを利用する場合に設定してください.

ローカル環境の場合は以下の手順で設定します

$ export AWS_ACCESS_KEY_ID="xxx"
$ export AWS_SECRET_ACCESS_KEY="xxx"

Kubernetes適用

以下のコマンドで更新します

$ make local-apply

スキャン設定

次にRISKEN側のスキャン設定を先にしておきます

  • AWS > AWS 画面にいきます
  • 右上の NEW をクリックして以下の情報を登録します
  • AWS名とAWSアカウントID（１２桁のID）を設定し、REGIST をクリックします

AWS

  • 登録後、一覧データをクリックします
  • 右上のSETUP ALLをクリックします
  • 以下を入力し、ATTACH ALL をクリックします
    • AssumeRole: arn:aws:iam::{スキャン対象のアカウントID（12桁）}:role/RISKEN
    • ExternalID: xxx (自動生成ボタンで設定してください)

  • Assume Role に設定しているロールARNは次のステップで作成しますが、RISKENというロール名にしています
  • External ID も次のロール作成時に必要になるのでメモっておきます

スキャン用のIAMロールを作成する

IAMポリシーを作成する

  • スキャン用のロールにアタッチするためのポリシーを先に作成します
    • SecurityAudit というマネージドポリシーだと、 CloudSploit というスキャナが権限不足なので、補足するためのポリシーをアタッチします。
    • もし、 CloudSploit を利用しない場合はスキップして問題ありません
  • RISKEN という名前でポリシーを作成します
  • 以下ポリシードキュメントです
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ses:DescribeActiveReceiptRuleSet",
                "elastictranscoder:ListPipelines",
                "servicequotas:ListServiceQuotas"
            ],
            "Resource": "*"
        }
    ]
}

スキャン用のロールを作成する

  • マネージメントコンソールでロール作成する場合の手順です
  • Another AWS account を選択し、IAMユーザのAWSアカウントを設定します
  • ExternalID（外部ID） に、先程自動生成した文字列を設定してください

AWS Role

  • IAMロールを作成し、先程作成したのRISKENポリシーと SecurityAuditポリシーをアタッチします
    • スキャン用のロールに設定される権限は参照系の権限のみです
    • また、個人情報が保存されてる可能性のあるリソースへのアクセス権もありません
    • 例えば、S3の場合にはバケットの設定は見れますが、GetObjectなどはありません

詳細はRISKENのドキュメントに記載されています

スキャン実行

  • AWS > AWS DataSource 画面にいきます
  • 各種データソースをクリックして、SCANをクリックするとスキャンがはじまります

DataSource

スキャン詳細

上記の設定例では、自分自身のAWSアカウントをスキャンするものでした。
AWSの場合、データソースというスキャナが複数存在します。
各データソースがどういった解析を行うのか、どういったスコアになるのかというのはこのブログでは触れませんが、詳細はドキュメントを参照してください。

GCPへのスキャン

GCPのスキャンもAWSと同様、IAM（サービスアカウント）の認証情報が必要になります。

サービスアカウント -> (RISKENのGCPスキャン) -> GCPプロジェクト

GCPについてもスキャンを行う前にRISKENローカル環境側の準備から説明します

Googleサービスを動かす

サンプルmanifest でそのまま動かした場合にはデフォルトではGCPプロジェクトをスキャンするための Googleサービス が起動していません。(起動時にGoogleのサービスアカウント情報が必要なため)

以下の手順で動かしてみます

  1. サービスアカウント発行
  2. k8sマニフェスト更新（Googleサービスを起動するため)
  3. サービスアカウントのクレデンシャル設定（環境変数）
  4. Kubernetes適用（Googleサービス起動）

サービスアカウント発行

GCPのスキャンはサービスアカウントの認証情報を用いてGoogleの各種APIを叩きます。
サービスアカウントを発行するためには、GCPプロジェクトが必要です。

手順については公式のヘルプを参照してください。

ここで発行したキーは後ほど利用します。

k8sマニフェスト更新

  • k8s-sample をcloneしたディレクトリに移動します
  • 一度ローカルで起動したことがある場合には、 overlays/local/google.yaml というファイルが作成されてるかと思います。
  • ファイル内のReplicaSetの設定を 0 -> 1 へ更新します
    • sed コマンドの場合は以下を実行します
sed -i "" -e 's/replicas: 0/replicas: 1/g' overlays/local/google.yaml

サービスアカウントのクレデンシャル設定

以下をRISKENのコンテナの環境変数にわたす必要があります。

キー 値 説明
GOOGLE_SERVICE_ACCOUNT_JSON 先程作成したサービスアカウントのクレデンシャル（JSONフォーマット）
GOOGLE_SERVICE_ACCOUNT_PRIVATE_KEY 先程作成したサービスアカウントの RSAプライベートキー
GOOGLE_SERVICE_ACCOUNT_EMAIL -

ローカル環境の場合は以下の手順で設定します

$ export GOOGLE_SERVICE_ACCOUNT_JSON='{"type":"service_account","project_id": ...'
$ export GOOGLE_SERVICE_ACCOUNT_PRIVATE_KEY='-----BEGIN PRIVATE KEY-----\\n...'
$ export GOOGLE_SERVICE_ACCOUNT_EMAIL='your-sa@your-project.iam.gserviceaccount.com'

ローカル環境の場合に限りますが、shell scriptで上記の値を整形している都合上、改行部分の変換が必要になります

  • GOOGLE_SERVICE_ACCOUNT_JSON: 改行部分をすべて取り除いて１行にしてください
  • GOOGLE_SERVICE_ACCOUNT_PRIVATE_KEY: 改行コード \n 部分をすべて \\n に置換してください

Kubernetes適用

以下のコマンドで更新します

$ make local-apply

スキャン設定

RISKEN側の設定

  • Google > GCP 画面に遷移します
  • 右上の NEW をクリックして以下の情報を登録します
  • GCP名とGCPプロジェクトID、検証コード（自動生成ボタンで生成）を設定し、REGIST をクリックします
    • 検証コード は後ほど利用するのでメモしておきます

GCP

GCPの組織IDはSecurityCommandCenter（SCC）という脅威検知のセキュリティサービスが有効な場合には設定してください。（SCCは組織レイヤのサービスです。）
今回はスキップします。

GCPプロジェクト側の設定

スキャン対象のプロジェクトに検証コードを登録します
  1. GCPマネージメントコンソールを開きます
  2. スキャン対象のGCPプロジェクトに切り替えます
  3. IAMメニューのラベルを開きます
  4. 新たに以下のラベルを追加してください
    • キー: risken
    • 値: {RISKENで設定した検証コード}

詳細はこちらのドキュメント を参照

RISKENのサービスアカウントをIAMに登録

先程発したサービスアカウントをGCPプロジェクト側で許可します
以下のフローです

  1. RISKEN用のカスタムロールを作成する
  2. IAMでサービスアカウントを設定、上記1のカスタムロールを設定

詳細はこちらのドキュメント を参照してください

スキャン実行
  • Google > GCP DataSource画面にいきます
  • 画面右上のSETUP ALLをクリック
  • ATTACH ALL をクリックしてデータソースを有効化
  • 一覧の各種データソースをクリックしてSCANをクリック

GCP DataSource

スキャン詳細

上記の設定例では、GCPプロジェクトをスキャンするものでした。
GCPの場合、データソースというスキャナが複数存在します。
各データソースがどういった解析を行うのか、どういったスコアになるのかというのはこのブログでは触れませんが、詳細はドキュメントを参照してください。

結果を確認する

  • http://localhost/#/finding/finding 画面にいきます
  • スキャンの結果収集されたセキュリティリスク情報を確認することができます
  • Score や DataSource, Tag などでフィルタすることもできます

finding
detail

まとめ

ローカル環境のRISKENで以下のスキャンを動かしてみました

  • WEBサイトスキャン
  • ドメイン関連のスキャン
  • ソースコードスキャン
  • AWSスキャン
  • GCPスキャン

AWSとGCPに関してはIAMの設定が必要だったので準備がちょっと大変なのですが、ほかは割とさくっとスキャンできたんじゃないかと思います。

Discussion