忙しい人のための Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities メモ

こんにちは、ひろかずです。

2017年7月に「Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities」が公開されました。
日本語翻訳されていないので、なかなか読めていない方もいると思います。
リリースから少し時間が経ってしまいましたが、読了したので一筆書きます。

どんなドキュメントか

OWASP Top10 で上っている各項目についての解説と、各項目についてAWS WAFでどのような対応ができるかを記載したもの。
Conditionを作る上でのアドバイスも記載されている。

参照ドキュメント

Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities

A1 – Injection

SQLインジェクション攻撃は、比較的簡単に検出できるが、バックエンドの構造によって複雑さが変わるため、アプリケーション側での対応も必要。
cookieやカスタムヘッダをデータベース参照に使う場合は、Conditionで検査対象とするように設定すること。
リクエスト中にクエリを流す事を是としているサービスの場合、対象URLを検知除外(バイパス)するような設定を検討すること。

A2 – Broken Authentication and Session Management

String Matchを活用して、盗まれた(怪しい)トークンを「安全のために」ブラックリストに登録する
デバイスのロケーションが異なるトークンを検出する等、ログから悪性利用をしているトークンを分析して、ブラックリストに登録するような使い方。
Rate-basedルールを用いて、認証URLを総当り攻撃を防ぐ施策も有効。

A3 – Cross-Site Scripting (XSS)

XSS攻撃は、HTTPリクエストで特定のキーHTMLタグ名を必要とするため、一般的なシナリオで比較的簡単に軽減できる。
BODYやQUERY_STRING, HEADER: Cookieを検査するのが推奨される。
URLを検査対象とすることは一般的ではないが、アプリケーションが短縮URL使っていると、パラメータはURLパスセグメントの一部として表示され、クエリ文字列には表示されない(後でサーバー側で書き換えられる)
CMSエディタ等、たくさんHTMLを生成するサービスには効果は薄い。
対象URLを検知除外(バイパス)する場合は、別途対策を検討すること。
加えて、<script>タグを多用するイメージ(svgグラフィックフォーマット)やカスタムデータも誤検知率が高いので調整が必要。

A4 – Broken Access Control

2017年から新たに登場
認証ユーザーの制限が適切に動作せず、必要以上に内部アプリケーションオブジェクト(不正なデータの公開、内部Webアプリケーション状態の操作、パストラバーサル、リモート/ローカルファイルの呼び出し)を操作できるというもの。
機能レベルのアクセス制御の欠陥は、一般的に後で追加されたアプリケーションで発生する。
アクセスレベルは、呼び出し時に一度検証されるが、その後に呼び出される様々なサブルーチンについては、都度検証されない。
呼び出し元のコードが、ユーザーの代わりに他のモジュールやコンポーネントを呼び出す暗黙的な信頼ができてしまう。
アプリケーションが、アクセスレベルやサブスクリプションレベルに応じてコンポーネントへアクセスさせる場合は、呼び出しの都度、検証する必要がある。

AWS WAFとしては、「../」や「://」をQUERY_STRINGやURIに含むかを検証することで、リモート/ローカルファイルの呼び出しを検出できる。
これも、リクエスト中に「../」や「://」を含む事を是とするアプリケーションには効果は薄い。
管理モジュール、コンポーネント、プラグイン、または関数へのアクセスが既知の特権ユーザーのセットに限定されている場合、Byte_MatchとIPSetの組み合わせでアクセスを制限することができる。

認証要求がHTTPリクエストの一部として送信され、JWTトークン(のようなもの)でカプセル化されている場合

  • Lambda@Edgeファンクションを用いて、関連リクエストパラメータがトークン内のアサーションおよび承認と一致することを確認することで、権限不適合リクエストはバックエンドに届く前に拒否することができる。

A5 – Security Misconfiguration

セキュリティの影響を受けるパラメータの設定ミスは、アプリケーションだけではなく、OSやミドルウェア、フレームワーク全てにおいて発生し得る。
セキュリティの影響を受けるパラメータの設定ミス例

  • ApacheのServerTokens Full(デフォルト)構成
  • 本番Webサーバーでデフォルトのディレクトリ一覧を有効にしたまま
  • エラーのスタックトレースをユーザーに戻すアプリケーション
  • PHPの脆弱なバージョンと組み合わせて、HTTPリクエストを介して内部サーバ変数を上書き

AWS WAFとしては、パラメータの設定ミスを悪用するHTTPリクエストパターンが認識可能な場合に限り対応可能。

  • A4 – Broken Access Controlと同様に、特定パスやコンポーネントに対してByte_MatchとIPSetの組み合わせでアクセスを制限を行う。(Wordpress管理画面 等)
  • 脆弱なPHPを利用している場合、QUERY_STRING中の“_SERVER[“を遮断する。

その他に考慮できること

  • Amazon Inspectorでの設定ミスの捜査(rootログイン許可や脆弱なミドルウェアバージョン、脆弱性の対応状況)
  • Amazon InspectorでのCISベンチマークとの適合性チェック
  • AWS ConfigやAmazon EC2 Systems Managerを用いた、システム構成変更の検出

A6 – Sensitive Data Exposure

アプリケーションの欠陥による機密情報の暴露をWAFで緩和するのは難しい。
この欠陥には、一般に不完全に実装された暗号化が含まれる(弱い暗号の利用を許容していること)

AWS WAFとしては、HTTPリクエスト中の機密情報を識別するパターンをString-Match Conditionで検出することで、機密情報へのアクセスを検出することができる。(ホストするアプリケーションに対する深い知識が必要)
アプリケーションが、アップロードを許容する場合、Base64を示す文字列の一部を検出するString-Match Conditionが有効(BodyはBase64でエンコードされているから)
一般的ではない手法

その他に考慮できること

  • AWS内の機能を使って、接続ポイントにて、ELBで強い暗号化suiteを使用するように制限する
  • クラシックロードバランサの場合、事前定義・カスタムセキュリティポリシーで制御できる。
  • アプリケーションロードバランサの場合、事前定義セキュリティポリシーで制御できる。
  • Cloud Frontでも利用するSSLプロトコルを制限できる。

A7 – Insufficient Attack Protection

2017年から新設
このカテゴリは、新しく発見された攻撃経路や異常なリクエストパターン、または発見されたアプリケーションの欠陥にタイムリーに対応する能力に重点を置いている。
幅広い攻撃ベクトルが含まれるので、他のカテゴリと重複する部分もある。

確認ポイント

  • アプリケーションに対して、異常なリクエストパターンや大量通信を検出できるか?
  • その検出を自動化できる仕組みはあるか?
  • 不要な通信に対して、ブロックできる仕組みはあるか?
  • 悪意のあるユーザーの攻撃開始を検出できるか?
  • アプリケーションの脆弱性に対するパッチ適用までの時間はどの程度かかる?
  • パッチ適用後の有効性を確認する仕組みはあるか?

AWS WAFで何ができるか

  • Size-Content Conditionを使うことで、アプリケーションで利用するサイズ以上の通信を検出・遮断できる。
  • URIやクエリ文字列のサイズを、アプリケーションにとって意味のある値に制限すること。
  • RESTful API用のAPIキーなどの特定のヘッダーが必要になるようにすることもできる。
  • 特定IPアドレスからの5分間隔での要求レートに対する閾値設定。(例えば、UserAgentとの組み合わせでのカウントも可能)
  • Web ACLはプログラマブルで反映が早いのが利点(CloudFrontに対しても約1分で反映)
  • ログの出力傾向から分析して、Web ACLを自動調整する機能も構築できる。

AWS WAFのセキュリティオートメーション機能の活用

  • Lambdaを使って、4xxエラーを多く出しているIPアドレスを特定してIPブラックリストに登録する。
  • 既知の攻撃者に対しては、外部ソースのIPブラックリストを活用する。
  • ボットとスクレイバに対しては、robots.txtファイルの ‘disallow’セクションにリストされている特定URLへのアクセスを行ったIPを、IPブラックリストに登録する。(ハニーポットと表現されています)

A8 – Cross-Site Request Forgery

CSRFは、WebアプリケーションのStateを変更する機能を対象としている。
State変更に係るURLやフォーム送信などのHTTPリクエストを考慮する。
「ユーザーがその行動を取っている」ということを必ず証明する機構がなければ、悪意のあるユーザーによるリクエスト偽造を判断する方法はない。

  • セッショントークンや送信元IPは偽造できるので、クライアント側の属性に頼るのは有効ではない。
  • CSRFは、特定のアクションのすべての詳細が予測可能であるという事実(フォームフィールド、クエリ文字列パラメータ)を利用する。
  • 攻撃は、クロスサイトスクリプティングやファイルインクルージョンなどの他の脆弱性を利用する方法で実行される。

CSRF攻撃への対処

  • アクションをトリガーするHTTPリクエストに予測困難なトークンを含める
  • ユーザー認証プロンプトの要求
  • アクション要求時のキャプチャの提示

AWS WAFで何ができるか

  • 固有トークンの存在確認
  • 例えば、UUIDv4を活用して、x-csrf-tokenという名前のカスタムHTTPヘッダーの値を期待する場合は、Byte-Size Conditionが使える。
  • ブロックルールには、POST HTTPリクエスト条件に加える

その他にできること

  • 上記のようなルールでは、古い/無効な/盗まれた トークンの検出については、アプリケーションでの対応が必要
  • 例えばの仕組み
  • サーバが、一意のトークンを隠しフィールドとしてブラウザに送信し、ユーザーのフォーム送信時の期待値にする。
  • 期待したトークンが含まれないPOSTリクエストを安全に破棄できる。
  • 処理後のセッションストアからトークンは削除しておくことで、再利用がされないことを保証。

A9 – Using Components with Known Vulnerabilities

既知の脆弱性を持つコンポーネントの利用
ソースや、商用/オープンソースのコンポーネント、フレームワークを最新に保つことが重要
最も簡単な攻撃ベクトルで、その他の攻撃手法の突破口にもなる。
脆弱なサブコンポーネントに依存するコンポーネントの利用しているケース。
コンポーネントの脆弱性は、CVEにて管理/追跡されないので、緩和が難しい。

  • アプリケーション開発者は、それぞれのベンダー、作成者、またはプロバイダとのコンポーネントのステータスを個別に追跡する責任を負う。
  • 脆弱性は、既存のバージョンを修正するのではなく、新機能を含む新しいバージョンのコンポーネントで解決される。
  • そのため、アプリケーション開発者は、新バージョンの実装、テスト、デプロイの工数を負担する。

基本的な対処に

  • アプリケーションの依存関係と基礎となるコンポーネントの依存関係の識別と追跡
  • コンポーネントのセキュリティを追跡するための監視プロセス
  • コンポーネントのパッチやリリース頻度、許容されるライセンスモデルを考慮したソフトウェア開発プロセスとポリシーの確立
  • これらにより、コンポーネントプロバイダーがコード内の脆弱性に対処する際に、迅速に対応できる。

AWS WAFで何ができるか

  • アプリケーションで使用していないコンポーネントの機能に対するHTTPリクエストをフィルタリングおよびブロックによる、攻撃面の削減
  • 例)HTTPリクエストを直接/間接的にアセンブルするコードへのアクセスのブロックする
  • String-matchコンディションを用いたURI検査(例えば、”/includes/”の制限)
  • アプリケーションでサードパーティのコンポーネントを使用しているが機能のサブセットのみを使用する場合は、同様のAWS WAF条件を使って、使用しないコンポーネントの機能への公開URLパスをブロックする。

その他にできること

  • ペネトレーションテスト。マーケットプレイスで買える。申請が必要だが、一部事前承認を受けているサービスでは申請が不要なこともある。(マーケットプレイス上のマークで識別可能)
  • 展開とテストのプロセスに統合して、潜在的な脆弱性を検出するとともに、展開されたパッチが対象となるアプリケーションの問題を適切に緩和する。

A10 – Underprotected APIs

2017年版の新カテゴリ
特定アプリケーションの欠陥パターンではなく、潜在的な攻撃ターゲットを示す

  • UIを持たないアプリケーションは増えてきている。(UI/API両方使えるサービスも同様)
  • 攻撃ベクトルは、A1-A9までと変わらないことが多い。
  • APIはプログラムからのアクセスのために設計されているので、セキュリティテストでは、追加の考慮事項がある。
  • APIは、(Rest,SOAP問わず)複雑なデータ構造での動作とより広い範囲の要求頻度と入力値を使用するように設計される事が多い。

AWS WAFでできること

  • A1-A9での対応と変わらないが、対APIとして追加でできる事がある。
  • 強化が必要な主要コンポーネントは、プロトコルパーサ自体(XML,YAML,JSON 等)
  • パーサーの欠陥を悪用しようとする特定の入力パターンをString-match Condition、またはByte-Size Conditionを使用して、そのような要求パターンをブロックする。

旧OWASP Top10 A10 – Unvalidated Redirects and Forwards

リダイレクトや転送要求を検証しない場合、悪意のある当事者が正当なドメインを使用してユーザーを不要な宛先に誘導する可能性がある。

  • 例)短縮URLを生成する機能がある場合、URLジェネレータがターゲットドメインを検証しないことで、悪意を持ったユーザーが正式サービス上から悪意のあるサイトへの短縮URLを発行できる。

AWS WAFでできること

  • まず、アプリケーションでリダイレクトとフォワードがどこで発生するのかを理解する(リクエストパターン等)
  • アプリケーションが使用する、サードパーティコンポーネントも同様にチェックする。
  • エンドユーザからのHTTPリクエストに応じてリダイレクトと転送が生成された場合は、AWS WAFでリクエストをQUERY_STRINGやURIに対するString-Match Conditionでフィルタリングする(リダイレクト/転送の目的で信頼されているドメインのホワイトリストを維持する)

Cloud Formationテンプレート

Web ACLと、このドキュメントで推奨されている条件タイプとルールを含むAWS CloudFormationテンプレートが用意されています。
今回は、解説を割愛します。

所感

AWS WAFの設定は基本的にDIYですが、実装のポイントをOWASP Top10になぞらえて、その対応を解説する良いヒント集だと思いました。
AWS WAFを設定する人は、一読するのがいいですね。
外部にAWS WAFの設定を依頼する人は、アプリケーションの特性をよく理解している人を立てて、設定する人とよくコミュニケーションを取ることが重要だとわかります。
セキュリティ製品の真価を発揮するには、保護する対象のサービスへの理解とサービスへの適合化が必要なのは、どんなソリューションにも共通しますね。

今日はここまでです。
お疲れ様でした。

続きを読む

Deep Security User Night #5 レポート

こんにちは、ひろかずです。

Deep Security User Night #5に行ってきたので一筆書きます。
会場は前回に続きHAPON新宿
日本地図をモチーフにした机がオシャレな空間です。

プシュッと開けてからスタートです。

お品書き

  • Google Cloud Platformの紹介とセキュリティとDS on GCPの話
  • 我が家の箱入り娘を世間に晒すのは危険なのでDeep Securityに見守ってもらった話
  • Deep Security APIを活用したルールアップデートの自動化について

Google Cloud Platformの紹介とセキュリティとDS on GCPの話

Google Cloud Japan
金子さん

トレンドマイクロとは長い付き合い
よなよなエール好き(箱買い派)

2017/6にDeep SecurityがGCPに対応
AWSに比べてまだまだ機能は足りないけど、これから
評価ガイドあります!(スタートアップガイド)

  • IaaSにManagerを立てて、保護サーバーにAgentを入れる方式

GCPの概要
Google関連サービスは、10億を超えるユーザー
どういうインフラで動いてるの?

  • バカでかいデータセンター
  • データセンターから自作
  • ラックも自作
  • 国内サーバベンダーより多くのサーバを作ってる
  • コンポーネントを極限まで削っているので、セキュア
  • 管理は自動化。分散処理基盤がある。
  • データセンター as a Computer
  • その一部を切り出すのがGCP
  • 東京リージョン開設時は超忙しかった
  • インフラ規模のインフラ(プラネットスケールインフラストラクチャ)
  • 3年間で3兆円の投資

セキュリティ頑張ってます!

  • すべてのレイヤーに厳しいセキュリティが施されている
  • Googleのセキュリティ専任部門(750人)
  • FISCにも対応!
  • NICに特注チップを付けて、変なところにパケットを飛ばさないようにチェック
  • データは暗号化され、分割と難読化でディスク単位では読みだせないようにしている。
    データは、GCP内でやり取りされる(VMコピー時に、通信はインターネットに出ない)

HTTP(S)ロードバランサ

  • 1IPでリージョン跨ぎの負荷分散
  • 暖気申請なしで100万リクエストに対応

IaaSの特徴

  • ライブマイグレーション
  • 勝手にやってくれるクラウドサービスはGCPだけ。
  • KVMベースのハイパーバイザで対応している
  • 1000VMが5分で起動する
  • VMネットワークは16Gbps
  • GCPカスタムマシンタイプ(GPU特化型とか)

BigQuery

  • SaaSのようなデータウェアハウス
  • 72GBのフルスキャンが6.7秒
  • 大量サーバとストレージ、ペタビットネットワークによる超並列処理クエリ
  • 1TBを1秒でスキャンするために、10000ディスクスピンドルを用意する考え方

そろそろDeep Security

  • BigQueryでDSのログを検索(1.32TB, 40億レコード)
  • 4.2秒で検索!

我が家の箱入り娘を世間に晒すのは危険なのでDeep Securityに見守ってもらった話

フューチャーアーキテクト株式会社
日比野さん

Deep SecurityとElasticSearch

  • ハニーポットに対する通信をDSでの検知状況を可視化
  • パロアルトのファイアウォールも用意
  • ハニーポットはコンテナ
  • 今回は、サーバ型、低対話型のハニーポットを用意
  • 低対話型は、簡単だが取れる情報はそれなり

標的型攻撃の攻撃フェーズに対してハニーポットが取れる情報

  • 偵察
  • 情報探査
  • 情報集約
  • 情報送信

ハニーポット書籍

  • 実線サイバーセキュリティモニタリング
  • サイバー攻撃の足跡を分析するハニーポット観察日記

今回のハニーポットは、Open Canaryを採用(コンテナでデプロイ)

  • Dockerコンテナ実行環境を用意して、
  • ログはLogStashでElasticSearchに送信
  • ハニーポットのAWS適正利用規約がある(事業者によって異なるので注意)
  • Deep Securityは、10.1を使用
  • DSaaS環境を利用(今回は双方向通信を採用)
  • Deep Securityのログは、UDP514で通信させた

Paro Alto

  • 15日間は無料
  • ライセンス高いから、忘れずに消す!

ログの可視化には、ElasticStackがおすすめ!

  • Kibana
  • Elastich
  • X-Pack(有償サブスクリプション:レポーティング、アラート、グラフ、ML)
  • 最新版5.5で構築し、Syslog受信したログをElasticSearch

結果

  • 中国、台湾が大活躍
  • 8/31-9/3ごろまで
  • ピーク時6000件のログがでた(ParoAlto)
  • 平日は、MSSQL(1433)が多かったが、土日はSSHが爆裂
  • 攻撃で使われるアカウントやパスワードは、リストに載っているものがやはり多かった(デフォルトパスワードは、やはり危険)
  • 機械学習は、閾値を設けた使い方が有効そう
  • Deep Securityのログの正規化は簡単にできた。
  • ファイアウォール機能で遮断していたので、侵入防御やセキュリティログ監視は反応しなかった。

まとめ

  • ログは事実だが、それだけでは意味がある分析結果は得られない
  • とりあえずログを集めるのはNG
  • 何をなすためにログを集めるのかという必要性を理解して、小さく始めるのがいい
  • ログの結果から対策に活かすPDCAが大事!

Deep Security APIを活用したルールアップデートの自動化について

アイレット株式会社
恩田さん

Deep Securityは、securitypackというサービスで使っている。
ルールアップデートしてますか?

  • 手動や自動で適用してもいいけど、いきなり防御されたら大変
  • アップデート処理は、アクセスが集中するので処理が重くて大変!

DeepSecurity API

  • REST
  • Sorp

REST API

  • 機能がだいぶ足りない
  • 新しい機能が実装されている

SOAP API

  • 古典的な機能が実装されている
  • 機能の数は多数

SDK

  • 統一されたフロントを提供するので区別しなくていい(機能の60%)
  • dsm.py:マネージャークラス
  • polices.py:ポリシークラス, ルールクラス
  • が、GitHubプロジェクトは全然動いてない
  • なので、足りない部分は実装しよう!

まとめ

  • SOAPが解決してくれる

要望

  • アップデート配信日はサーバーを強化してください!
  • APIとUIのドメインを統一してほしい

今回も盛り上がった回でした!

今日はここまでです。
お疲れさまでした。

続きを読む

NW X Security JAWS勉強会 #1レポート

こんにちは、ひろかずです。
今日は、NW-JAWSとSecurity-JAWSの合同勉強会に行ってきたので、一筆書きます。

例によって、リアルタイムで執筆しているので、表記ゆれ、誤字、脱字等はご容赦ください。

会場は、トレンドマイクロさん(新宿)
大きい部屋並べた椅子120脚がみるみる埋まる状況でした。

今回はOSI7階層になぞらえてのセッションとのことです!

お品書き

  • L1&L2 日本一AWSに近い場所。独自に進化を遂げたエクイニクス・ジャパンの現状(仮)
  • L3&L4 AWSにおけるIPv6対応状況
  • L5&L6&L7 AWS WAF の話とSecurity Automation の紹介
  • L7+:AWSユーザー向けサイバーリスク保険の概要および活用方法
  • L0:絶対に覚えておきたい物理的標的型攻撃対策10+3のコツ

L1&L2 日本一AWSに近い場所。独自に進化を遂げたエクイニクス・ジャパンの現状(仮

エクイニクス・ジャパン
グローバル・ソリューション・アーキテクト 内田 武志さん

エクイニクス・ジャパンとは

国内600名
世界中でデータセンターを保有
データセンターとの相互接続
国内で11か所。東京10、大阪1
ダイレクトコネクトの接続拠点(世界で15か所)
接続状況はまさに小宇宙

今日の試み

DXロケーションに深堀りしていく

  • L1:光ファイバ、物理IF、DWDM
  • L2:イーサネット、VLAN

ダイレクトロケーションの構成のうち、ダイレクトコネクトルーターとカスタマーゲートウェイ間の話

LOA-CFAに従って、エクイニクスエンジニアがラック内を配線する

  • クロスコネクト構内接続:24h以内に提供
  • キャンパス内接続:24h以内に提供
  • メトロコネクト:10営業日以内に提供

ケーブルはシングルモードファイバ

ルータなどのネットワーク危機への接続
お客持ち込みから、エクイニクスレンタルまで

TY2の中にAWSDXロケーションがある(檻に入っている)
お客様ラックからTY2基幹配線を通じて接続
プレミアムロケーション(なかなか取れない!)

PeeringDBを見ると、エクイニクス内の利用ユーザーが分かる。

TY2に在庫がないので、ビットアイルを買収(TY678)
地下ケーブルを張ったので、パッチパネルを繋ぐだけで接続できる
1GB、10GB問わず

DWDM(高密度波長分割多重)とは

  • 1波長に80の通信を詰め込む。
  • 波長ごとに帯域を設定
  • もはやネットワークをスヌーピングするのは不可能
  • TY2~TY4の間は、機械的に終端しないで光信号のまま通信させる。
  • 光信号のルーティングが、鏡のようなもので行う(!)

ルーターの貸し出しや設定支援もしているよ!

L2

ダイレクトコネクトの価格表は2種類のみ1GB、10GB

サブ1G

  • レイヤ2を50MB~500MBまで分割するサービス
  • 50MBはお小遣いでDXできるレベル
  • 利用開始、停止は15分以内で行える(使わないときは止められる!)
  • ただインターネットを迂回したいのであれば50MB
  • 季節変動的なワークロードや、PoC、データ移行なら500MBという使い分けができる

まとめ

エクイニクスは、まじめに基礎的な技術を積み上げてパフォーマンスを提供できるようにしている
ダイレクトコネクトのデフォルトスペックをなるべく妨げないのが、エクイニクスのいいところ
Software制御でクラウド接続を制御していく流れ

QA

エクイニクスがデータセンターを繋ぐときは、自社持ちの伝送路?
– 複数のダークファイバをっ持つキャリアから借りている
– 伝送装置は自社
電気通信事業者?
– 電気通信事業者のライセンスは持っているけど、キャリアサービスをやってしまうとキャリアと仲良くできないので、中立的は接続の場を提供している
データセンターのテロ対策の公開情報は?
– ロケーションによる。
– 米国では、立ち入り禁止の場所に立ち入ったら、武装警官が駆けつける。
– データセンターを繋ぐブリッジなので、利用者は一つのロケーションが落ちても大丈夫な構成にしているはず。

よもやま

AWSはデータセンターの場所は公開していない。
TY2は、データが素通りするだけで、データやストレージはそこにはない。

L3&L4 AWSにおけるIPv6対応状況

アマゾンウェブサービスジャパン 
荒木 靖宏さん

最新ネタ
VPCのCIDERが編集できるようになったよ!(ipv6は未対応)

IPv6は世界中で使える

冗長化した100GbEのネットわーkうが張り巡らされた
ファイバ切られても大丈夫!
中国は除く(大変・・・)

AWSサービスは諸説あるが、ipv6
利用者は普通、VPCでv6を使いたい。
パブリック利用するサービスは、大体v6対応している。

v6の歴史

AWSはお客からサービスを考える

CLB

  • 一番先に対応したのはELB(CLB@VPCクラシックのみ)
  • CLBのインターネット側をv6で受けて、v4に変換する方式
  • v6利用はオプトイン(任意利用)
  • 2011年5月から

AWS IoT

  • ローンチ時からv6対応
  • 想定デバイス数は1億とかザラなので、スケールできるように。

s3

  • 対応時全く反響なかった
  • v6ネットワークは早いのでおススメ

CloudFront

  • 対応してます!

AWS WAF

  • ローンチ時からv6対応
  • ALBはv6対応してないので、CFのみで利用可能
  • ブラックリストIPは10000かけるけどv6からしたら少ないよね

Route53

  • NSでv6書ける
  • v4死んでもサービス継続!

ALB

  • CLBより早くて安い(ほとんどの場合)
  • これからのメインストリームなので、CLBから乗り換え推奨

VPC

  • ヂュアルスタックで利用可能
  • v4はデフォ、v6はオプトイン
  • 時々は、マネコンで表示してあげて!
  • グローバルユニキャストアドレスを使う
  • 1:1のNATは存在しない
  • 従来のプライベート安全神話は存在しない。
  • Egress Only Internet Gateway
  • 外からアクセスできないことを保証
  • GUAは、ルートテーブル、NACL、SGは自分で別途設定

ダイレクトコネクト

  • BGPでもv6対応しているので覚えてね

全体として

  • Amazon保有のv6アドレスだけで、提供している。

セキュリティの話

VPC Flow Logsもv6対応している。
s3料金のみ
kibanaで可視化するのがいいかな

L5&L6&L7 AWS WAF の話とSecurity Automation の紹介

アマゾンウェブサービスジャパン 
桐山 隼人さん

AWSは、データ領域のセキュリティはユーザー責任範囲としていたが、その領域のセキュリティを語るのは感慨深い
上司の前でのプレゼン。。。
今日のテーマは、AWS WAF
生まれたばかりのサービス
会場の半数が利用している
今日の回でWAF好きを増やしたい

いいところ

脅威から保護
API連携
簡単デプロイ
トラフィック可視化
従量課金

最近のアップデート

HIPAA準拠
レートベースルール

  • 大量リクエスト送信元IPを検知
  • 5分間隔
  • CloudWatchやLamdaのカスタム呼び出しも可能

OWASP Top10対応

  • 推奨WebACLとルールを含むCFnテンプレートあり
  • ホワイトペーパー出てる

AWS WAF Security Automation

  • つい1-2か月前にアップデートされてる(!)
  • デプロイ、アナライズ、プロテクトの自動化

デプロイの自動化

  • CFとALBむけスタックがそれぞれ用意されている。

アナライズの自動化

  • トラフィックの振る舞いから不正なアクセスの自動解析
  • ハニーポット的なAPIGatewayを用意して、にアクセスしてきているスクレイバやボットを引き寄せ
  • ログをLambdaで解析
  • IPブラックリストをダウンロードしてIPリストに登録するスクリプト(Lambdaで定期実行)

プロテクションの自動化

  • 解析結果に基づいたWAFルールの自動作成と適用

今までのインシデントレスポンス

  • これまでは、セキュリティエンジニアが手で行っていたことを代替

もう一歩先

Domain Generation Algorithmsによるドメイン名からの通信をブロックしたい

  • リファラにあるドメイン名から、DGAによるものかを自動判定するアプローチはどうか

機械学習を使う

  • 教師データ:Alexa Top 10,000, 既知のフィッシングサイト
  • 評価データ:CFのログをパース

PoCの結果は、1%の誤検知だったが、まだ進化できる。

QA

DDoS対策はどうなの?
– 来週ブラックベルトありますよ!
– L7向けの対策にはなる

L7+:AWSユーザー向けサイバーリスク保険の概要および活用方法

東京海上日動火災保険
上田 哲也さん

商品公開した瞬間に賛否分かれた
否側は、AWSは安全だという論調(リスク商品は営業妨害)
最終的にAWSのお墨付きを貰った。
クラウド推進のための商品

変遷

2016年の販売開始から、クラスメソッド、サーバーワークス、NECと事業者との業務提携

概要

AWSに障害が発生した際、AWSウーザーが被る損害を補償する
損害賠償請求・弁護士費用の他に、調査対応費用(超過人件費、情報漏えい見舞金、お詫び広告費用)も補償範囲

  • ユーザー責任部分に起因して発生した損害の補償は、個別設計が必要
  • アプリケーションの種類でりすくが全く異なるので個別になる。

QA

加入単位は?

  • アカウント単位で加入可能
  • アカウントごとに明確に業務を区分できる場合に限る

発生時手続き

  • 利用者による原因の証明が必要

支払い

  • 一括でも分割でも

購入方法

個別契約モデル

  • ユーザーが代理店を通じて契約

パートナー連携モデル

  • パートナーのサービスに入ってもらえると、自動適用されるモデル

活用方法

リスクの移転手段としての活用が有効

  • 発生時の影響が大きいリスクには移転という考え方が有効(地震や火災)

社内調整時の活用

  • クラウド使いたいけど心配対策
  • 情報漏えいなどセキュリティに不安、ネットワーク安定性に不安 など
  • 利用開始前の法務、上席対策に活用

付加価値として既存サービスに組み込む

  • サービスに入ったら、無料でついてくるよ!という見せ方
  • 無料で保険を配る場合は、免許は不要(保険募集的な説明をパートナーが行うことも可能)

プロジェクトごとに個別付保

  • 保険が必要なプロジェクトやユーザーごとに付保する。
  • 無料配布はできない。
  • 保険販売の資格を持っている人が説明しないといけない。

宣伝

プロジェクトリスク保険

  • 自社の業海洲等によって発生する損害をカバー
  • 事故が多いので、保険料が高くなってきている
  • TeamSpiritさんのサービスでは、サービス料に混ぜ込むものもある

QA

AWS障害を証明するのはユーザーだが、証明は調査料は支払われるのか?

  • 支払われる

証明できなければ?

  • 支払われない

支払いの実績はあるの?
– 守秘義務に抵触。。。

DNS障害でAPIを引けないことに起因する障害では、保険料請求はあったか?

  • なかった
  • 損害賠償請求と調査対応費用がかからないと支払われない
  • 日本はリスクが低い

対応費用の上限は?

  • デフォルト:損害賠償は1億~10億、自社対応費用は1億限定
  • 使った額が支払われる

Azure、GCPは?

  • 対応しました。
  • 名称は別で用意してます

L0:絶対に覚えておきたい物理的標的型攻撃対策10+3のコツ

Works Mobile Japan
伊藤 成幸さん

全員起立でセッション参加!
スライドの1/3が自己紹介
元陸自、海自
きりしまでソナー担当
20ミリ機関砲 アンチウェポンシステム(AWS)

呼ばれた経緯

  • 怖いお兄さんからLT依頼

レイヤ0

金曜夜に起きること

  • 酔っ払いとコリジョン
  • 同による標的型攻撃
  • 同DoS

今日は標的型

都内犯罪について

東京は日中と夜間の人口の差が激しい
無事に帰るための心構え

脅威の発見:監視振る舞い検知

  • 脅威はいきなり現れない
  • だんだん近づいてくる
  • 歩きスマホは危ない!
  • 周りをよく見て、違う動きをしている人を検出

脅威の評価:見た目、距離、火力、つよそう

  • 銃を持っている人は、時間と距離をゼロにする

脅威への対処:落ち着く、排除、離隔

  • 大声を出す(声を出して落ち着く)

通報

  • 正当防衛でも、警察は先に110番されると通報者を被害者として扱う
  • 倒したらすぐに110番!

準備

時計を外す、ヒールを脱ぐ
準備体操
元気よく!

想定シチュエーション:金曜夜に新宿駅で酔っ払いに絡まれたら

足を一歩前にして、押されても倒れないように
重心を少し下げる(少し腰を落とす)
ちょっと頭を下げる(顔を守る:ディフェンス重視)
ファイティングポーズを構えると開戦するので、ごめんなさい(手を前に)
重心がある足を意識して、ピボット(どこでも正面にできるように)

腕をつかまれたら

  • 手を開く
  • 腕が少し太くなるので、指の隙間から抜けやすくなる
  • 重心が低くないと、腕が抜けない。重心を意識!
  • 抜けたら逃げる!

抜けなかったら小手返し

  • 利き手で相手の手首を取る
  • 相手の親指の付け根を取って、そのまま捻る(手の甲にもう片方の手を添えるだけで極まる)

胸ぐらをつかまれたら

  • 半身ごめんなさいの体勢から(とにかく顔は守る)
  • 距離を詰めて、相手の顎を掌底で突きあげて、そのまま倒す

羽交い締めされたら

  • 左足を相手の足の間に入れながら、体ごと捻りかえる。
  • 相手の重心が崩れるので、後はやり放題

モノ(女性向け)

防犯ブザー
催涙スプレー

  • 最近のは麻薬中毒者にも効く
  • 護身で持っていても大丈夫との最高裁判決

ライト

  • 200ルーメンの強力なやつ
  • 押し付ければ痛い
  • 暗い場所なら、めくらましに使える。
  • フラッシュモードで相手の距離感を殺す
  • 車内では天井にバウンスさせれば書類も見える
  • ハイボールに入れればキレイ(バーで使えば女子ウケ抜群!)

素晴らしいライフハックでした!

今日はここまでです。
お疲れさまでした!

続きを読む

Deep Security as a ServiceをAWS MarketPlaceで買ってみる

こんにちは、ひろかずです。

先日、AWS Blogにて、AWS Marketplace Update – SaaS Contracts in Actionが発表されました。
そのラインナップにDeep Security as a Service(以下、DSaaS)が含まれていたので、お試しついでに一筆書きます。

メリットと注意点

メリット

  • 何と言っても、その費用です。
  • 支払いがAWSに統合されます。
  • 時間課金が可能です。AutoScaleも何のその。(Annual除く)

注意点

  • サポートが、米国(英語)になります。
  • 国内サポートを希望の人は、ライセンス販売代理店から購入してください。
  • AWSアカウントに紐付けられるDSaaSアカウントは一つのようです。

工程

  1. 事前準備
  2. DSaaSをサブスクライブする
  3. DSaaSアカウントを作成する

0. 事前準備

まず、DSaaSをサブスクライブしたいAWSアカウントにログインしておきます。
当該AWSアカウントにDSaaSの利用料が課金されます。

1. DSaaSをサブスクライブする

AWS MarketPlaceにアクセスして、Deep Security で検索します。
Marketplace1.png

以下2つがターゲットになります。
一年間に起動する数が分かっている場合は、 Annual を選ぶ感じですね。
今回は、Trend Micro Deep Security as a Serviceを選択します。

  • Trend Micro Deep Security as a Service
  • Trend Micro Deep Security as a Service – Annual

Marketplace2.png

費用を確認して、Continueをクリックします。
オンプレミスにも対応しているんですね。
システム要件を鑑みると、Smallインスタンスの利用は避けるべきですね。
Software FeesにRegionの違いはないようです。
Marketplace3.png

続けて Subscribe をクリックします。
ちなみに、AWSアカウントがDSaaSを既にサブスクライブしている場合、以下のように表示されます。
Marketplace5.png

サブスクライブか完了すると以下のように表示されます。
Set Up Your Account をクリックして、DSaaSのアカウント登録を実施します。
Marketplace4.png

2. DSaaSアカウントを作成する

先の Set Up Your Account をクリックするとDSaaSのアカウント登録設定画面が表示されます。
重要な項目に絞って解説します。
DSaaS01.png

Company/Account

DSaaSアカウント名です。
一意な名称が求められます。
ログインに必要な要素です。

Email

登録後に接続情報メールが送られてくるメールアドレスになります。
デフォルト表示のようにメールアドレス以外を設定すると、接続情報メールは送られません。
その場合は、先のCompany/AccountEmail,Passwordを控えておきましょう。

Language

言語表示です。日本語にしておきましょう。

TimeZone

DSaaS管理画面で表示される時間のタイムゾーンです。
後からでも変更可能ですが、お好みで合せておきましょう。

ひろかずは、こんな感じで設定しました。
DSaaS021.png

Sign Upをクリックするとこのような画面が表示されます。
DSaaS03.png

しばらくすると、Emailに入力したメールアドレスにアカウント作成メールが送られてきます。
DSaaS04.png

一つ目のURLをクリックすると、DSaaS管理画面が表示されます。
パスワードを入力して、Sign Inしてください。
Emailにメールアドレスを設定していない場合、DSaaS管理画面からCompany/AccountEmail,Passwordを入力してSign Inしてください。
DSaaS05.png

気になるライセンスの状態を確認します。
画面上のダッシュボードタブをクリックして、一番下にライセンスが表示されます。
既に課金されているようですね。
DSaaS06.png

アカウントの詳細 をクリックすると、状態が確認できます。
なんと、初期配置されているデモサーバが課金対象になってますね汗
DSaaS07.png

デモサーバのAWS料金は課金されませんが、License Feesはかかってしまうので、デモサーバを無効化します。
コンピュータタブを選択して、デモサーバを右クリックします。
処理無効化をクリックします。
DSaaS08.png

確認ダイアログにOKします。
DSaaS09.png

ステータスが、非管理対象(有効化が必要)となっていることを確認します。
DSaaS10.png

ダッシュボード画面からアカウントの利用状況を確認すると、0台になってますね。
DSaaS11.png

以上で、Market PlaceでサブスクライブしたDSaaSを利用する準備ができました。
今日はここまでです。
お疲れ様でした。

続きを読む

Amazon Inspectorのレポート機能を試す

こんにちは、ひろかずです。
Preview版の時にAmazon Inspectorの評価を行いましたが、それっきりになってしまいました。
Amazon Web Services ブログでレポート機能が追加されるなどのアップデートがなされたので、一筆書きます。

目的とゴール

GA/アップデート後のAmazon Inspectorを実行し、その差分とレポート機能がどんなものかを確認する。

参考ドキュメント

Amazon Inspectorユーザーガイド

お品書き

  • 仕様
  • インストール手順
  • 実行手順
  • レポート機能

仕様

対応環境とルールパッケージ

Windows対応やRHEL6系への対応は聞いていましたが、新たにRHEL7.3系に対応されていました。
日本語ドキュメントでは、RHEL7.2系までの記載でしたので、英語ドキュメントを確認するように心がけたいですね。

対応環境毎に利用できるルールパッケージが異なるので、スキャンを実施する前に確認してください。
サポートされているオペレーティングシステムに関して、提供されているルールパッケージ

ルールパッケージは、Preview版は6種類でしたが、現在は4種類にスリム化されています。

  • 共通脆弱性識別子
  • Center for Internet Security (CIS) ベンチマーク
  • セキュリティのベストプラクティス
  • 実行時の動作の分析

課金体系

課金体系として、エージェント評価という聞きなれない単語が使われていますね。
Amazon Inspector 料金
ちょっとわかりにくいですが、エージェント数 x 評価回数を示すようです。
FAQ:Q: Amazon Inspector の料金体系について教えてください。を見るとイメージし易いかもしれません。

ボリュームディスカウントにも言及されているので、たくさん利用する人は要チェックですね。

インストール手順

基本的な手順はPreview版とさほど変わりがありませんでした。
手順は、過去記事を参考にしてください。

実行手順

基本的な手順はPreview版とさほど変わりがありませんでした。
手順は、過去記事を参考にしてください。

ルールパッケージは選択可能な4種類を全て選択しました。
Inspector6.png

レポート機能

レポートの出力

スキャンが完了すると、レポートアイコンが表示されました。
Inspector8.png

クリックするとFinding ReportFull Reportが出力できるようです。
Inspector9.png

内容

全編英語です。
目次がないので、見出しを拾うと以下のようになっていました。
RHEL7.3環境で実行したので、対応していないCISベンチマークは掲載されていません。

Section 1: Executive Summary

ルールパッケージ毎の検知件数が記載されています。
report1.png

Section 2: What is Tested

利用されたルールパッケージの説明が記載されています。
スキャンした対象(Assessment Target)の条件設定が記載されています。
report2.png

report21.png

Section 3: Findings Summary

各ルールパッケージで検出された項目と緊急度が記載されています。
AWSコンソールでページ送りする必要がないのがいいですね。
report3.png
report31.png

Section 4: Findings Details

各ルールパッケージで検出された項目の対応方法が記載されています。
記載内容はAWSコンソールで表示されている内容と同じですが、一つ一つ開かなくて良いので見やすいかもしれません。
report4.png

Section 5: Passed Rules

Full Reportのみのセクションです。
クリアしたルールパッケージの内訳が全て掲載されています。
Amazon Inspectorは全てのCVEに対応している訳ではないので、検査時にチェックされたCVEを確認する上では有用でしょう。
report5.png

おわりに

脆弱性の対応状況を見える化することは、安全な運用の第一歩です。
今回のアップデートで、AWSコンソールを見なくても結果が分かるようになったのは良かったと思います。

一方で、以前検証した際に懸念した、継続的な脆弱性のハンドリングについては、課題を残したままのように思えます。
判断の履歴や対応しない(必要がないと判断された)脆弱性の管理をどのように行うかがカギだと言えるでしょう。

今日はここまでです。
お疲れ様でした。

続きを読む

Security-JAWS#5レポート

こんにちは、ひろかずです。

5/22にトレンドマイクロさんで開催されたSecurity-JAWS#5に行ってきましたので、一筆書きます。

月曜に関わらず、盛況な集まりでした。

お品書き

Session1:トレンドマイクロ株式会社 姜 貴日さん「Deep SecurityとAWS WAF、SNS、Lambdaを使ってうまいこと自動防御する」
Session2:三井物産セキュアディレクション株式会社 大橋 和正さん「インシデント別対策から見るセキュリティ運用体制〜Alert Logicのことも少し〜」
Session3:エフセキュア株式会社 河野 真一郎さん「脆弱性について疑似クラッキング(デモ)をやってみる ~脆弱性対策はとても大切。でも多くの人はそれに気づかないんだ〜」
Session4:洲崎さん「AWS使って社内CTFを開催してみた」

Session1:「Deep SecurityとAWS WAF、SNS、Lambdaを使ってうまいこと自動防御する」

トレンドマイクロ株式会社 姜(かん) 貴日さん

DeepSecurityとは

サーバ向け総合セキュリティ対策製品
IPS/IDS, セキュリティログ監視, アンチマルウェア, 変更監視
単一の機能ではなく、多層防御の考え方でセキュリティを確保する製品。
AWSコンソールとDeepSecurityManagerが連携して、インスタンスの増減を自動で反映する機能もある。

自動防御の仕組み

今回の構成は、AWS上にALB(AWS WAF)-EC2(ECS)を配置した構成。
SNSとLambdaを用意
SecurityGroupは、隔離用のもの(Outbound,Inboudなし)を用意しておく

シナリオ1(自動ブロック)

  • Deep Security Agentの侵入防御(IPS/IDS)で検知する。
  • Deep Security ManagerからイベントがSNS送信される。
  • SNSは、Lambdaに通知する。
  • Lambdaは、送信元IPをAWS WAFのIP Condition(Blocked)に登録する。

シナリオ2(自動隔離)

  • DeepSecurityAgentのアンチマルウェアで検知
  • イベントがSNS送信
  • SNSはLambdaに通知
  • Lambdaは、検知したインスタンスIDのSGを隔離用のものに差し替え、Auto Scaling Groupから切り離す。
  • Auto Scaling Groupの設定により、差し替え用インスタンスが起動される

まとめ

より、リアルに近い環境でのPoCを実施したい。
共同PoC大募集中!声かけてください!

QA

IPは、トレンドマイクロのデータベースと突き合わせるのですか?

  • 今は検知ベースです。

テンプレートは公開されていますか?

  • まだです(公開予定)

IPはころころ変わると思いますが、リフレッシュとか考えてますか?

  • そういうフィードバック大歓迎です!

DSaaSは、どこまでの規模感に対応できますか?

  • DSaaSは、中規模向け。大規模ならDSMがいい。(中規模って、どれくらい?100大規模?)
  • 国内で1000超えはない。100大規模は実績ある。

DSaaSのバージョンアップってどうなんだろう?

  • Manager側は自動でバージョンアップされます。

Session2:「インシデント別対策から見るセキュリティ運用体制〜Alert Logicのことも少し〜」

三井物産セキュアディレクション株式会社 大橋 和正さん
もともとオンプレメインのセキュリティエンジニア出身。
三井物産セキュアディレクションは、セキュリティ診断、SOC、セキュリティコンサルティングをやっている。
Alert Logicの拡販はじめました。

セキュリティ脅威の動向

IPA発表の10大脅威では、標的型攻撃、ランサムウェアが多く、公開サーバではインジェクション系が多い。
VerizonでもWebサーバに対する攻撃がダントツ

ランサムによる被害

WannaCryの詳細は三井物産セキュアディレクションのサイトで公開中!

Apache Struts2脆弱性をついた情報流出の事例

Twitterで気づく等、対応の遅れがあった

セキュリティインシデントとは?

コンピュータセキュリティに関係する人為的事象で、意図的および偶発的なもの
意図的脅威

  • パスワードリスト攻撃
  • サービス拒否攻撃
  • 情報の持ち出し(内部犯行)
  • サイト改ざん(ハクティビズム、マルウェア配布)

偶発的脅威

  • 設定ミス
  • プログラムのバグ
  • メール誤送信(情報漏えい)
  • PC紛失(情報漏えい)

なぜ事前準備が必要?

100%攻撃を防ぐことはできない

  • 攻撃技術の進歩(いたちごっこ)
  • 人間が使う以上、100%はない(オペミスはない)

天災には備えるのに、セキュリティインシデントへの備えはしないの?

  • 対応の遅れが、ユーザーからの信頼失墜に結びつく。

どのようなインシデントがあって、どのような対応をするのか準備しておく。

AWSにおけるセキュリティインシデントについて

クラウドvsオンプレ

アジリティと自動化
高可用性

おなじみAWS責任共有モデル

コンピューティング、ネットワーク、ストレージ等、クラウド基盤はAWSの責任範囲
OSレイヤ以上は、利用者側の責任ではあるが、SIerやベンダーと協力して対応して行く必要がある。
インシデントの種類をマッピングして、対応すべきセキュリティインシデントを明確にすることが大事。

Alert Logicについて

セキュリティの専門家がSOCで監視している。
リクエストとレスポンスのペイロードがコンソールで見れる。

Session3:「脆弱性について疑似クラッキング(デモ)をやってみる ~脆弱性対策はとても大切。でも多くの人はそれに気づかないんだ〜」

エフセキュア株式会社 河野 真一郎さん

セキュリティ営業3年目(2月からエフセキュア所属)
本社はフィンランド
衣装はガルパンモチーフ

まずは質問

脆弱性をついたクラッキングデモを実際に見たことある方ー!(会場は半々)

今回のシナリオ

標的型メールの添付ファイル(履歴書)を送りつけて、開いてしまった。

前提条件

アンチウィルス、メールサーバ前段のFirewallでは阻害されない

  • 標的型攻撃なので事前調査している想定

AWS接続が簡単なのは、デモのため。

デモ

開いた時点で、Windows7の一般権限は取れている。
攻撃ツールを使用してコマンドプロンプトを操作できる。
1分に一回だけ使える脆弱性をついてAdministoratorに昇格。
PowerShellでDomain Adminを取るまで約6分

OSのパッチ適用してる?

Linuxでも脆弱性管理をしていなければ、ハッカーにかかれば危ない。
OSのパッチ適用だけでは不十分(脆弱性は全体の約12%)
ミドルウェア、アプリケーションの脆弱性が85%をを占める。

宣伝

エフセキュアでは、Rapid Detection Serviceというサービスがある。
デモのような脆弱性がないかを見て欲しいひとはコンタクトして!

Session4:「AWS使って社内CTFを開催してみたよ」

洲崎さん
謎の勉強会ssmjpの運営やってます。

某社で社内CTFを開催しました

会社のHP
30人規模から70人規模に参加者が増えた
セキュリティエンジニアに楽しんで貰える
集合研修方式
Jeopardy形式
CTF終了後には問題と解説を配布(希望者には環境も)

ガジェット

状況を表示するLED看板
ラズパイでスコアサーバのWebAPIに定期的に投げる
スコアサーバは自作
運用管理ダッシュボードを用意
競技PCはWorkspacesを使いたいなー(NGだった)

得られた知見

AWSでイベントやるには申請が必要。
日本語NG。英語で申請。
EC2のみ。WorkspacesはNG。
申請時にはかなり細かく聞かれる。終わるときにはイベント設計が終わってるレベル。
申請から承認まで7日と言われたが、割とすぐに承認がおりた。

Docker(ECS)を使いたかった

時間の関係でEC2に
使えたらECRでデプロイが超ラクになる

監視サーバ

Zabbix Docker Monitoringを使ってみた。
TCPとWebサービスについて

実際にかかった金額

準備期間を含めて$2555だった。
Workspacesの検証がなければもっと安くあがっただろう

QA

参加者の平均年齢は?

  • 若手が多かったが、ベテランまで

運営は何人?

  • 5人。問題は2人で作った。大変だった。他の人も巻き込んでいきたい。

参加者スキルのピンきり具合

  • 満足度は70%(研修としては悪め)
  • 事前にフルイにかけたけど、ミスマッチした方は残念だった。
  • トップは、CTF運営経験者だった

正答率は?

  • 71.38%。8割の問題が解かれた。
  • 2割の問題が解かれなかった。(作った人は凹んでた。作ったのに解かれないのは悲しい。)

最後に

質疑応答も活発でした!
次回も楽しみですね!

今日はここまでです。
お疲れ様でした。

続きを読む

Security Groupの適切な設定のためにできる、たった2つのこと(STOP!フル開放運動)

こんにちは、ひろかずです。

構築や検証中に思うように動作しない時にSecurity Groupをはじめとするファイアウォール機能を疑いたくなりますよね。
今回は、SecurityGroupの設定が正しいか不安な時に闇雲にフル開放してしまうより効率的に切り分けをできる方法があるので、一筆書きます。

お品書き

  1. Listenポートの確認
  2. VPC FlowLogsの確認

1. Listenポートの確認

サーバで待ち受けていないポートをSecurity Groupで開放する必要はありません。
どのサービスがどのポートを使用しているかを再確認し、開放するべきポートが開放されているかを確認しましょう。

0.0.0.0:ポート番号:::ポート番号 で表現されているポートが外部からの待受を想定しているポートです。
上手くできないことに関連するポートを開放すると良いでしょう。
切り分けたい現象にもよりますが、sshやntp等の関連性が薄いサービスポートを空ける必要性は低いはずです。

出力例

netstat -luntp (Amazon Linuxの場合)

# netstat -luntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      2331/rpcbind
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      32508/sshd
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      32592/sendmail
tcp        0      0 0.0.0.0:36254               0.0.0.0:*                   LISTEN      2352/rpc.statd
tcp        0      0 :::111                      :::*                        LISTEN      2331/rpcbind
tcp        0      0 :::80                       :::*                        LISTEN      2628/httpd
tcp        0      0 :::22                       :::*                        LISTEN      32508/sshd
tcp        0      0 :::4118                     :::*                        LISTEN      15287/ds_agent
tcp        0      0 :::443                      :::*                        LISTEN      2628/httpd
tcp        0      0 :::46046                    :::*                        LISTEN      2352/rpc.statd
:

netstat -nao & Task Manager(Windows2012の場合)

コマンドプロンプトでポートとPIDを確認し、Task ManagerでPIDとサービスを確認することができます。

C:UsersAdministrator>netstat -nao

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       792
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       72
  TCP    0.0.0.0:4118           0.0.0.0:0              LISTENING       163
  TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       600
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       928
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       972
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       121
  TCP    0.0.0.0:49157          0.0.0.0:0              LISTENING       688
  TCP    0.0.0.0:49158          0.0.0.0:0              LISTENING       208
  TCP    0.0.0.0:49164          0.0.0.0:0              LISTENING       696
  TCP    172.31.40.9:139        0.0.0.0:0              LISTENING       4
  :

taskmanager.png

2. VPC FlowLogsの確認

インスタンスに紐付けられているENIで遮断している通信を確認します。
実際に目的とする動作を行い、その実施時間で遮断している通信(REJECTで検索)があるかを確認するのが良いでしょう。

VPC FlowLogsの設定の仕方はawsブログ : VPC Flow Logs – トラフィックフローの収集、閲覧を参照してください。

FlowLogs.png

このように、Security Groupで遮断された通信はひと目で判断することができます。
切り分けの観点であれば、これで十分と言えるでしょう。

おわりに

闇雲にSecurity Groupを開きすぎてしまうと、原因が特定できないだけではなく、セキュリティを著しく低下させてしまいます。
サービスの稼働を優先させた場合、設定を戻すこともままならず、セキュリティを低下させたまま運行することになるかもしれません。

検証環境や構築中の環境でも、インターネットからの脅威は本番環境と変わらずに訪れます。
むしろ、セキュリティ強度の劣る検証環境や構築中の環境は、格好の標的になるでしょう。

Security Groupフル開放によるインシデントは防げます。
本稿が少しでもその助けになれば幸いです。

今日はここまでです。
お疲れ様でした。

続きを読む

Deep Security 10 へバージョンアップする(9.5sp1 Linux/Oracle Database環境 から)

こんにちは、ひろかずです。

前回、readmeも読んだことなので、早速バージョンアップしてみたいと思います。
Deep Security10.0 アップグレードガイドブックに記載されているとおり、バージョンアップは一筋縄では行きません。

以下のような検証環境を用意しましたので、作戦を考えてみましょう。

参考情報

トレンドマイクロ社ダウンロードページ
Deep Security10.0 アップグレードガイドブック

検証環境

DSMサーバ

  • t2.large
  • RHEL-7.3_HVM_GA-20161026-x86_64-1-Hourly2-GP2 (ami-6f68cf0f)
  • Deep Security Manager 9.5.5600
  • Deep Security Agent 9.5.3.2754
  • Oracle RDS ( 11.2.0.4.v10 )

DSA導入サーバ

  • t2.large
  • amzn-ami-hvm-2016.03.3.x86_64-gp2 (ami-7172b611)
  • Deep Security Agent 9.5.3.7523

ざっくり構成

DSMdiagram.png

作戦

今回の検証環境のポイントは、Deep Security Managerが、直接アップデートできる9.5 sp1 patch3ではないことです。
前回確認したとおり、10へのアップデートには、データベーススキーマを更新することになりますが、トレンドマイクロ Q&Aページ DSMデータベーススキーマアップグレード方法では、 本製品 Q&A に記載している手順は、SQL Server 2005 や Oracle データベースはサポートしていません。 と書かれているため、一旦9.5 sp1 patch3(9.5.7008)に上げることにします。

readmeにも、9.5系旧バージョンからのバージョンアップからの注意は記載されていませんね。

というわけで、工程は以下になります。

工程

  1. バックアップの取得
  2. DSMサーバを9.5 sp1 patch3(9.5.7008)にバージョンアップする
  3. DSMサーバを10にバージョンアップする
  4. DSA(Relay)を10にバージョンアップする
  5. DSAを10にバージョンアップする

1. バックアップの取得

当然ですが、DSM両サーバのAMIバックアップと、RDSのスナップショットを取得しておきます。

1. DSMを9.5 sp1 patch3(9.5.7008)にバージョンアップする

各DSMサーバの作業ディレクトリに9.5 sp1 patch3(9.5.7008)をダウンロードします。

# curl -O http://files.trendmicro.com/products/deepsecurity/en/9.5/Manager-Linux-9.5.7008.x64.sh

実行権を付けて、インストール時に使用した dsm.properties を使用してインストールします。

# chmod +x Manager-Linux-9.5.7008.x64.sh
# ./Manager-Linux-9.5.7008.x64.sh  -q -console -varfile ./dsm.properties
Unpacking JRE ...
Preparing JRE ...
Starting Installer ...
3 11, 2017 9:02:44 午後 java.util.prefs.FileSystemPreferences$2 run
情報: Created system preferences directory in java.home.
Trend Micro Deep Security Managerサービスを停止しています...
以前のバージョンのTrend Micro Deep Security Managerを確認しています...
アップグレードの確認画面の設定を許可...
すべての設定を許可しました。実行準備ができました...
以前のバージョンをアンインストールしています
ファイルを解凍しています...
設定しています...
データベースに接続しています...
他のManagerを終了しています...
データベーススキーマをアップデートしています...
データベースのデータをアップデートしています...
データベースのデータをアップデートしています (カウンタをアップグレード)...
作業ディレクトリを作成しています...
レポートをインストールしています...
モジュールとプラグインをインストールしています...
ヘルプシステムを作成しています...
ソフトウェアパッケージをインポートしています...
廃止機能の削除...
検索キャッシュの設定をインポートしています...
パフォーマンスプロファイルをインポートしています...
インストールの記録を記録しています...
セッションをクリアしています...
プロパティファイルを作成しています...
ショートカットを作成しています...
SSLを設定しています...
サービスを設定しています...
Javaセキュリティを設定しています...
Javaのログを設定しています...
クリーンナップしています...
Deep Security Managerを開始しています...
インストールを終了しています...

もう一台も実施する必要がありますので注意です。(出力は省略します。)

できたようです。
dsm9_5_7008.png

状態も良好ですね。
dsm95state.png

お好みで、この時点のAMIバックアップやスナップショットを取得しておきます。

2. DSMを10にバージョンアップする

各DSMサーバの作業ディレクトリに10.0(10.0.3259)のインストールモジュールをダウンロードします。

# curl -O http://files.trendmicro.com/products/deepsecurity/en/10.0/Manager-Linux-10.0.3259.x64.sh

実行権を付けて、インストール時に使用した dsm.properties を使用してインストールします。

# chmod +x Manager-Linux-10.0.3259.x64.sh
# ./Manager-Linux-10.0.3259.x64.sh -q -console -varfile ./dsm.properties
Unpacking JRE ...
Starting Installer ...
3 11, 2017 9:53:36 午後 java.util.prefs.FileSystemPreferences$2 run
情報: Created system preferences directory in java.home.
無人 (サイレント) モードが開始されました
以前のバージョンのTrend Micro Deep Security Managerを確認しています...
アップグレードの確認画面の設定を許可...
アップグレードのシステムチェックを開始します。
システムチェック概要レポートが生成されました。パス: /current-work-directory/DeepSecurityInstallerReport.csv
アップグレードのシステムチェックが完了しました。
すべての設定を許可しました。実行準備ができました...
Trend Micro Deep Security Managerサービスを停止しています...
他のManagerを終了しています...
以前のバージョンをアンインストールしています
ファイルを解凍しています...
設定しています...
データベースに接続しています...
他のManagerを終了しています...
データベーススキーマを分析しています...
既存のデータベーススキーマの分析: 20 % ...
既存のデータベーススキーマの分析: 40 % ...
既存のデータベーススキーマの分析: 60 % ...
既存のデータベーススキーマの分析: 80 % ...
既存のデータベーススキーマの分析: 100 % ...
データベーススキーマをアップデートしています...
スキーマのアップデート: 20 % ...
スキーマのアップデート: 40 % ...
スキーマのアップデート: 60 % ...
スキーマのアップデート: 80 % ...
スキーマのアップデートを終了しています...
スキーマのアップデート: 100 % ...
作業ディレクトリを作成しています...
レポートをインストールしています...
モジュールとプラグインをインストールしています...
ソフトウェアパッケージをインポートしています...
廃止機能の削除...
検索キャッシュの設定をインポートしています...
パフォーマンスプロファイルをインポートしています...
インストールの記録を記録しています...
セッションをクリアしています...
プロパティファイルを作成しています...
ショートカットを作成しています...
SSLを設定しています...
サービスを設定しています...
Javaセキュリティを設定しています...
Javaのログを設定しています...
クリーンナップしています...
Deep Security Managerを開始しています...
インストールの完了...

もう一台も実施する必要がありますので忘れずに実行してください。(出力は省略します。)

インストールプロセスに システムチェック概要レポートが生成されました。 とありますね。
新機能の Better upgrade experience のことでしょうか。
中身を確認してみましょう。

$ cat DeepSecurityInstallerReport.csv
Deep Security Manager 10.0アップグレードのシステム概要レポート,,,
,,,
このレポートは、既存のDeep Securityインフラストラクチャの各コンポーネントについて、Deep Security Manager 10.0をインストール/アップグレードする準備ができているかを示したものです。,,,
,,,
アップグレードの準備が100%完了していない場合は、アップグレード手順に進む前に、表示される手順に従って準備してください。,,,
https://help.deepsecurity.trendmicro.com/ja-jp/upgrade-deep-security.html?combo=0&db=2&dsa=3&dsm=1&dsmhw=0&dsmos=0%2C1&dsr=2&dsva=&nodes=1&ten=0&i=2,,,
,,,
,,,
結果,コンポーネント,,理由
,ip-xxx-xxx-xxx-xxx.us-west-2.compute.internal (現在のノード),,
準備完了,,Deep Security Managerバージョン,Deep Security Manager 9.5.7008は10.0に直接アップグレードできます。
準備完了,,Deep Security ManagerのホストOS,Red Hat Linux 7.3はサポートされます。
準備完了,,Deep Security Managerホストのディスク容量,46 GBの空き
準備完了 (警告あり),,Deep Security Managerホストのメモリ,7.4 GBしかRAMがなく、システム要件を満たしていません。パフォーマンスが低下します。
,ip-xxx-xxx-xxx-xxx-us-west-2.compute.internal (他のノード),,
準備完了,,Deep Security Managerバージョン,Deep Security Manager 9.5.7008は10.0に直接アップグレードできます。
準備未完了,,Deep Security ManagerのホストOS,特定のLinuxディストリビューションを検出できません。
準備完了,,Deep Security Managerホストのディスク容量,46.8 GBの空き
N/A,,Deep Security Managerホストのメモリ,他のDeep Security ManagerノードのRAMについては、直接テストすることはできません。他のサーバで別のハードウェアを使用している場合は、RAMが要件を満たしているかどうかを手動で確認してください。
,,,
準備完了,データベース,,Oracle Database 11g Standardエディション
,,,
準備ができました。新しい機能を使用するには、Managerをアップグレードしてから10.0にアップグレードしてください。また、依存関係もアップグレードしてください。,Deep Security Agentバージョン,,1個のAgentがサポートされています。
,,,
準備ができました。新しい機能を使用するには、Managerをアップグレードしてから10.0にアップグレードしてください。また、依存関係もアップグレードしてください。,Deep Security Relayバージョン,,2個のRelayがサポートされています。
,,,
準備完了,Deep Security Virtual Applianceバージョン,,Virtual Applianceは検出されませんでした。
,,,

これは手厳しいですね。
メモリで怒られてしまっています。
検証用途なので、t2.large(vcpu 2, Memory 8GB)を選択しましたが、厳密には8GBに達していません

# free -m
              total        used        free      shared  buff/cache   available
Mem:           7565        1561        2501          24        3502        5652
Swap:             0           0           0

System requirementsに記載されている内訳はクリアしているので、気にせず進みましょう。

おっ、来ましたね。
login.png

状態も良好なようです。
dsm10state.png

3. DSA(Relay)を10バージョンアップする

10モジュールのインポート

[管理]タブ>[ダウンロード]とクリックし、DS10のモジュールをインポートします。
今すぐインポート アイコンをクリックすれば、インポート開始です。
DSA(Relay)を導入しているプラットフォームのものを選択しましょう。
ModuleDL_01.png

緑のチェックが入ればインポート完了です。
KSM(Kernel Support Module)も自動的にダウンロードされました。

続けてDSA(Relay)のバージョンアップ

[コンピュータ]タブから、Relayアイコンの付いているコンピュータをダブルクリックします。
DSA_update00.png

[概要]>[処理]タブ>[Agentのアップデート]ボタンをクリックします。
DSA_update01.png

バージョン10.0が選択されているのを確認して、[OK]ボタンをクリック
DSA_update02.png

無事に終わったようです。
DSA_update03.png

もう一台も忘れずにバージョンアップしておきます。(画像は省略します)

4. DSAを10バージョンアップする

10モジュールのインポート

プラットフォームがDSA(Relay)と異なる場合、先の手順と同様にモジュールのインポートを行います。
Amazon Linuxの10モジュールもインポートすることができました。
ModuleDL_03.png

Agentアップデートの手順は、先程のDSA(Relay)のバージョンアップと変わりません。
Relayの有効化ボタンをクリックしてしまうと、Agentの再導入(アンインストール/インストール)になるので注意して下さい。
DSA_update012.png

無事にできました。
DSA_update04.png

最終的なステータスも良好です。
Final_state.png

無事にバージョンアップができました。
今後は、この環境を使っていろいろ検証していきます。

今日はここまでです。
お疲れ様でした。

続きを読む

AWS re:Invent 2016 Security Follow Up に行ってきた

こんにちは、ひろかずです。
AWS re:Invent 2016 Security Follow Up に行ってきたので、一筆書きます。

  • 例によって、リアルタイム執筆ですので、誤字、脱字、表記ゆれはご容赦ください。

スタートが19:00のせいか、半分くらいの人出からのスタートです。
最終的には8割位埋まっていました。

[AWSセッション]

「セキュリティ新サービス紹介① AWS Organizations」

桐山 隼人
アマゾン ウェブ サービス ジャパン株式会社
技術本部 レディネスソリューション部
セキュリティソリューションアーキテクト

AWS Organizations は…

  • 現在プレビュー申し込みできます。

サービス概要

複数のAWSアカウントの一元管理

  • アプリケーションや環境、チームのような単位でAWSアカウントをグループ管理
  • グループポリシーを適用

AWSアカウント管理の自動化

  • コンソール、SDK、CLIでの管理操作
  • 管理操作をCloudTrailでロギング

請求の簡素化

  • 複数アカウントの一括請求(Consolidated Billing)
  • Consolidated Billing ファミリーの自動移行

主要なコンセプト(用語)

組織

  • 一元管理可能な複数のAWSアカウントのセット

AWSアカウント

  • 管理される最小単位
  • IAMを用いてAWSリソースへアクセス

マスターアカウント

  • 組織内の他アカウントの作成招待削除ができる特別なアカウント
  • 組織内コントロールポリシーの適用
  • 組織における支払いアカウント

組織単位(OU)

  • 後述

管理ルート

  • 後述

利用の流れ

1. 組織の作成

  • マスターアカウントは支払いアカウントになるので、慎重に決めましょう

2. AWSアカウントの自動作成

  • マスターアカウントからの自動作成

入力要素

  • メアド(必須)
  • アカウント名(必須)
  • IAMロール名(必須)
  • BillingへのIAMユーザアクセス(任意設定)

モードは二つ

  • FullControlモード
  • Billingモード

FullControlモード

  • Billingモードを含む
  • Billingからの昇格には、全てのAWSのアカウントからの同意が必要

Billingモード
– 課金状況を見れる

3. 既存AWSのアカウントの組織への招待

  • 招待されたアカウントは、了解/拒否を選べる。(デフォルト拒否)
  • 参加した瞬間にポリシーが適用される

4. AWSアカウントのグループ化

AWSアカウントは組織単位(OU)に所属できる

  • アプリケーションとか環境とかチームとか
  • 階層になるので、最上位が 管理ルート になる。

5. 組織Controlポリシー

  • 適用対象は、組織全体、OU、AWSアカウント
  • ポリシーは、階層構造に基いて継承される。
  • ローカル管理者からは上書きできない
  • IAMと記述方式は一緒
  • IAMユーザ、IAMロールの権限は、 組織ControlポリシーとIAMポリシーの最大公約数

どんなことができるの?

例:サービスControlポリシー

  • 呼び出しを許可するAPIを定義(ホワイト、ブラックリスト)
  • 業界で認可されたサービスのみを許可する(本番環境)
  • 開発環境はちょっと緩くすることもアリ

「セキュリティ新サービス紹介② AWS Shield」

荒木 靖宏
アマゾン ウェブ サービス ジャパン株式会社
技術本部 レディネスソリューション部 部長

AWS Shieldとは?

  • AWSが管理(マネージ)するDDoSプロテクションサービス

攻撃の種別

  • ボリューム攻撃(UDP反射型:全体の6割を占める:SSDP反射型が一番多い、その他NTPやDNS、SNMPも)
  • ステート管理攻撃(SYNフラッドとか:2割くらい)
  • アプリケーションレイヤー(F5攻撃とか、slowles:15%くらい)

DDoSを緩和する取り組み

難しさはどこに?

  • 複雑な前準備(オペレータやISPとの調整、スクレイピングサービスへのトラフィック誘導)
  • 事前の帯域確保(工事時間がかかる)
  • アプリの見直し(仕様書起こすとか大変)

難しいのはマニュアルでの対応
AWSでスクレイピングしても、ユーザーからはレイテンシ向上にしか見えない。お金は?
AWSの解

  • ありきたり攻撃の自動保護(サービス差別化につながらない部分を持つ)
  • 可用性の確保

DDoS防御はAWSにあらかじめ組み込まれている

  • 各リージョン
  • 常時オン(外部Routingなし)
  • SYB/ACK、UDPフラッド反射型
  • 追加費用無し

お客様の声

  • 大きなDDoS対策
  • 見える化
  • アプリレイヤー守ってよ

AWSの解

  • 無料サービス(Standard)
  • 有料サービス(Advanced)

Standard

BLACK Watch

  • 決定論的フィルタリング
  • 不正な形式のTCPパケットはドロップする
  • インライン検査のスコアリングに基づくトラフィック優先順位付け(優先順位の低い攻撃トラフィックを優先的に破棄)

キャパ追加

  • Routingポリシーで内部的に分散

検知と緩和を継続(ヒューリスティック異常検出:通常のベースラインから異常を知る)

  • リクエスト数/s
  • 送信元IP
  • URL
  • UserAgent

Advanced

AWS内で完結する
常時オン
レイテンシは最小限
手頃な価格
対応しているのは以下サービス(EC2は入っていない。TCPのみ。UDPは使えない。)

  • ALB
  • CLB
  • CF
  • Route53

L7は、AWS WAFの利用

  • Standard:セルフサービス(自分でカスタムシグネチャを書く)
  • Standard/Advanced:DDoSエキスパートチームからのアドバイス
  • Advanced:積極的DRT(DDoS Response Team)が関与する

DRT(DDoS Response チーム)はなにやるの?

  • 常時モニタがDRTを呼び出す
  • トリアージ
  • DRTチームがルールを書いて提供

レポート

  • ニアリアルタイムで、パケット情報見れる(サンプル取得:全部じゃない)

DRTへのコンタクト

  • 第一報はサポート経由でしてね(エンタープライズサポート)

費用

  • Standard:アドバイスに基づくスケール費用は 有料 :月額課金なし
  • Advance:アドバイスに基づくスケール費用は無料:$3000/月:一年継続コミット

[パートナーセッション]

「スポンサー側から見た AWS re:Invent の醍醐味と感じたセキュリティの流れ」

南原 正樹様
トレンドマイクロ株式会社 パートナービジネス推進本部
アライアンスパートナーグループ 担当課長代理

Trend MicroとAWS re:invent

ダイヤモンドスポンサー
並び順は一番最後(アルファベット順)
出展したのは、DeepSecurityとDSaaS
スポンサーアクティビティ(セッションは各1時間:youtubeに上ってるよ)

  • AWSに特化したセッション
  • CISOに聞いてみよう(コンプライアンス、レギュレーションの話)
  • ブースは、DevSecOpsを安全な空の旅をモチーフに表現

スポンサーで感じたこと(日本 vs 北米)

  • 日本は、捕まると長いので敬遠される。アンケート欠かされる。製品売ろう。
  • 北米は、コンタクト獲得と製品が分業。スキャンしたらノベルティたくさんくれる。コンプライアンス準拠。ビジネス視点。

来場者

  • 北米はカジュアルに自分のアイデアを語ってくる。Tシャツ大好き。

re:inventで見た気になるセキュリティの流れ

Security Automation

セキュリティオペレーションの自動化を目指すことでセキュリティ運用コストの低減と対応の迅速化を目指す。
セキュリティはインフラ構築と分離しない。併せて考える。

  • AWS WAFとLambdaとの連携(ブラックIPとか)
  • CloudTrailのIPを検査とか
  • GitHubに公開されてるよ!

Security for ServerLess

サーバレスを主体として組み上げた環境でのセキュリティのポイント

  • IAMを中心とした権限管理
  • 許可されたトラフィックの精査(サニタイズからログの精査まで)
  • 例えば、CF/WAF前、API Gateway中、Lambda後ろ、最後はDB

最後に

AWSはエコシステムとマーケットチャンス
セキュリティもニューノーマルからスーパーパワー
積極的に新しい取り組みに挑戦しよう(日本の方がセキュリティに深く真面目に考えている)

「攻撃傾向と企業が取るべきセキュリティ施策 in Las Vegas」

佐藤 裕貴様
三井物産セキュアディレクション株式会社
Alert Logic事業部 マネージャー

大橋 和正様
三井物産セキュアディレクション株式会社
プロフェッショナルサービス事業部
アカウントマネージャー

昨今の攻撃傾向

海外(Verizonレポート)

  • WebAPに対する攻撃が増えてきている。(前年度4倍)

日本(IPAレポート)

  • インターネットバンキング、標的型、ランサム、Webサービス不正ログイン、サイト改ざん

事前対策

セキュアコーディング
脆弱性診断
アクセス分離(SG、NACL、ELB)、2要素認証(IAMロール、MFA)

  • 監視ポイントが限定できて運用負荷を軽減

ログの収集

  • 平時のログ傾向を把握する
  • ログは不変であること(削除/改ざんの防止)
  • 以下の状態であること(アクセス性,検索性,継続モニタ)

セキュリティ運用の最適化

  • L1:SG,IAM
  • L2:IDS/WAF,脆弱性スキャン
  • L3:CloudTrail,SIEM

[エンドユーザー様セッション]

「ユーザーからみたre:Invent のこれまでと今後」

宮崎 幸恵 様
株式会社リクルートテクノロジーズ
ITソリューション統括部 インフラソリューション2部 RAFTEL2G

  • 2012年からre:invent皆勤賞
  • 一年おきにセキュリティ系サービスのビッグウェーブが来る傾向
  • Organizationsキター
  • 現地は熱い!体感!感じろ!

バッテリー切れでライブでかけませんでした!すみません!

「AWS re:Invent の衝撃 ~Large Scale Violence & Security Culture Shock~」

大橋 衛様
KDDI株式会社
技術統括本部 プラットフォーム開発本部
アジャイル開発センター フレームワークG 課長補佐

  • 現地は熱い!体感!感じろ!飯はマズイ!
  • 予防、検知、回復の話
  • 日本は、予防に重点を置いている制約型.検知が最小限で、回復は手動と尻すぼみ
  • 海外は、予防はsoso、検知にかなり力を入れて、回復は自動化とパワーのかけ方が日本と逆

バッテリー切れでライブでかけませんでした!すみません!

雑感

モバイルバッテリーがそろそろ必要なようです。

続きを読む

Deep Security as a ServiceでAmazon SNSトピック対応を設定する

こんにちは、ひろかずです。
少し前ですが、Deep Security as a Service(以下、DSaaS)でAWSのSNSトピック対応がされました。
当時はちょっと使いどころがピンとこなかったのですが、需要が出てきたので一筆書きます。

主な需要

  • ログの長期保存
    — DSaaS環境のログ保存期間は13週間です。

  • ログ分析
    — 何をどうするかがカギですね。

  • Lambda等でイベントドリブンでどうのこうのする
    — よく語られますがどうのこうのの部分を固めるのが先決ですね。

ざっくり構成(今回の分)

今回は、すべての需要を考慮してこんな感じで組みました。
Diagram_01.png

前提条件

  • AWSアカウントを所有していること。
  • DSaaSアカウントを所有していること。

参考情報

以下の情報を参照しながら進めています。

工程

参考情報の順番とは少し変えています。

  1. Amazon SNSトピックを作成する
  2. サブスクリプションを作成する
  3. AWSユーザーを作成する
  4. DSaaS上でSNSを設定する

1. Amazon SNSトピックを作成する

Get Startedから始めます。
リージョンは任意ですが、今回はOregonにしました。
SNS_00.png

Create topicでを選択します。
SNS_01.png

Topic名を付けて、Create Topicボタンを押下します。
SNS_02.png

できました。Topic ARNを控えておきます。
SNS_03.png

2. サブスクリプションを作成する

サブスクリプションは、需要を考慮してSQSとします。
SQS_00.png

最低限、キュー名を付けるだけです。
あとは要件次第で調整してください。
ここでは、メッセージ受信待機時間を延ばしてみました。
SQS_01.png

できました。
ARNを控えておきます。
SQS_02.png

SNSの画面に遷移

Create subscriptionボタンを押下します。
SNS_04.png

ProtocolにAmazon SQSを設定して、EndpointにSQSのARNを設定します。
Create subscriptionボタンを押下します。
SNS_05.png

subscriberが空欄ですが、サブスクリプションが作成できました。
SNS_06.png

SQS画面に遷移

キュー操作でSNSトピックへのキューのサブスクライブを設定します。
SQS_03.png

トピックの選択のプルダウンで、先程作成したSNSトピックを選択して、サブスクライブボタンを押下します。
SQS_04.png

うまくできたようです。
SQS_05.png

SNSの画面に遷移

ちょっとあちこち行ってしまいましたが、無事にサブスクライブできました。
SNS_07.png

試し切りをします。
Publish to topicボタンを押下します。
SNS_11.png

適当に内容を記載してpublish messageボタンを押下します。
SNS_12.png

SQS画面を見ると、キューが一個溜まってますね。
SQS_11.png

3. AWSユーザーを作成する

IAMの画面に遷移

ユーザーを選択し、新規ユーザーの作成ボタンを押下します。
IAM_01.png

ユーザー名を入力して、ユーザーを作成します。
ここではDSaaS-SNSという名前にしました。
ユーザーを作成したら、Access KeyとSecret Keyを忘れずに保存してください。
IAM_02.png

ポリシーを選択して、ポリシーの作成ボタンを押下します。
IAM_03.png

要はSNSにpublishする権限があればいいのですが、ここでは独自のポリシーを作成を選択します。
IAM_04.png

参考情報Deep Security Help Center記載のポリシーをベースに以下のように作成しました。
IAM_05.png

コピペ用

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Action": [
            "sns:Publish"
         ],
         "Effect": "Allow",
         "Resource": "arn:aws:sns:us-west-2:XXXXXXXXXXXX:dsaas-sns"
      }
   ]
}

できました。
IAM_06.png

作成したポリシーを選択して、ポリシーアクションからアタッチを選択します。
IAM_07.png

先程作成したIAMユーザを選択して、ポリシーのアタッチボタンを押下します。
IAM_08.png

4. DSaaS上でSNSを設定する

DSaaSの管理画面にログインし、管理>システム設定>SIEMと遷移します。
Amazon SNSのPublish Events to AWS Simple Notification Serviceにチェックを入れて、作成したIAMユーザのアクセスキーとシークレットキー、および作成したSNSトピック名を入力します。
今回は、送信するイベントの種類は全て選択したままとします。
DSaaS_01.png

SQS画面でメッセージの着信を見てみましょう。
早速システムイベントが着信してますね。
SQS_12.png

DSaaSのイベントをSNSトピックとしてSQSへキューイングすることろまでできました。
長くなったので今日はここまでにします。

お疲れ様でした。

続きを読む