この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
2017/06/01（木）に行われましたAWS Summit Tokyo 2017 Day3 「AWS で実現するセキュリティ・オートメーション」のセッションレポートになります。
(2017/06/16追記：)イベント公式の関連資料及び動画が公開されましたので展開します。
- AWS Summit Tokyo 2017 セッション資料・動画一覧 | AWS
- 関連資料(PDF)：ダウンロード
- 関連動画(YouTube)：
セッション概要
セッションの登壇者及び概要は以下の通りです。
桐山 隼人氏 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
クラウドは、今までやってきたことを効率的にするだけでなく、今までできなかったことを可能にします。本セッションでは、セキュリティをクラウド環境で実現することで可能となる、運用統合と自動化(オートメーション)をご紹介します。セキュリティ・オートメーションは、貴社の運用が変わるだけでなく、セキュリティ戦略そのものを見直すきっかけにもなります。オートメーションによる次世代のセキュリティを考えてみませんか？
セッション内容
- セキュリティ・オートメーションという言葉はあまり普及していない
- まだクラウドに移行できない会社の理由の一つにセキュリティがある
- 逆に、クラウドに移行した人たちの理由にもセキュリティがある
- このような認識の違いが生まれるのは、まだ普及していないと言える
本セッションのポイント
- オートメーションは戦略策定の礎
- セキュリティ・オートメーションを前提に設計されたAWSサービス
- セキュリティ戦略基盤となるAWSクラウド環境
オートメーションは戦略策定の礎
- オートメーションとは自動化のこと
- 自動化によって得られる効果
- コスト削減
- 生産性向上
- スピード向上
- 人為ミス削減
- 上記は最初の目的だが、もっと重要な事がある
- 効率化だけではない価値の例
- セールスフォースオートメーション
- 営業プロセスの効率化
- 営業活動の確信
- 分析による案件角度の判断
- 見込み客への集中
- マーケティングオートメーション
- マーケティングの効率化
- マーケティング活動の確信
- 案件化率の高いリードの判断
- 案件化に至るresources最適化
- やることとやらないことを決められる = 戦略
- セキュリティ・オートメーションも最終的にはこれに行き着く
- セキュリティへの投資も青天井なので、オートメーションでやることとやらないことを決めたい
- セールスフォースオートメーション
- オートメーションがもたらすもの
- まずは多種多様なデータ集約
- 次に可視化と効果測定
- それを用いて分析による意思決定
- 上記３店の土台がオートメーション
- このサイクルを回すことが重要
セキュリティ・オートメーションを前提に設計されたAWSサービス
- セキュリティ対策の分類
- 分類の方法はいくつかある
- 対策主体による分類
- 人・組織・技術
- 対策対象による分類
- サーバ・ネットワーク・クライアント
- 対策場所による分類
- 入り口・内部・出口
- 対策主体による分類
- オートメーションを意識したプロセス・継続性を表現できる分類は？
- 適応型セキュリティアーキテクチャ(ガートナーが発表している)
- 防御の考慮点
- 従来、セキュリティ対策と言われていたもの
- しかし標的型攻撃などにより100%防御は不可能
- 検知の考慮点
- 高い検知精度
- 各種イベントに相関したインシデント特定
- 重要なインシデントの判別・優先順位付け
- 対応の考慮点
- 一次対応の速さ = 損害額の最小化
- 事後調査を意識したログ設計
- 恒久的な対応は仕組み化して事故の再発防止
- 予測の考慮点
- 以上に気づくための定常状態の把握
- アノマリなどと言われている
- 次の防御策を選択する耐えのリスク分析
- 以上に気づくための定常状態の把握
- それぞれをばらばらで行うのではなく、継続的な監視と分析を行いサイクルを早く回す必要がある
- 防御の考慮点
- 適応型セキュリティアーキテクチャ(ガートナーが発表している)
- 分類の方法はいくつかある
AWSのサービスのマッピング
- AWSのセキュリティオートメーションテンプレート
- フロー例
- Lambdaで適時的に実行している
- SpamhausのDROPリストなどをダウンロード
- AWS WAFでIPセットを更新
- WAFによるブロック
- スケールアウトによる問題の抑制と通知
- 上記ではすり抜けてしまう場合の対策
- 非ブラックIPからの大量トラフィックが発生する
- オートスケールでスケールアウトして自動トラフィック分散
- スケーリングイベントの通知をSNSで行う
- 通知からLambdaを実行する
- 高リスク端末に対する内部対策のフロー例
- 端末自動隔離とバックアップ
- LambdaからInspectorでEC2に対して脆弱性診断
- 結果をSNSで通知
- LambdaからNACL/SGのポートブロックによる端末隔離
- ブロックログをVPC Flow Logsに表示する(検知の仕組み)
- フォレンジックのためにEBSのsnapshotを取得
- CloudTrailでバックアップのログを保存
- 上記ではすり抜けてしまう場合の対策
- これらのフローを人を介さずに実行することが出来る
セキュリティ戦略基盤となるAWSクラウド環境
- オートメーションは効率化だけではなく、意思決定のサイクルの基盤
- AWS環境でのログはインフラ全体で取得可能
- ネットワーク・OS・アプリケーション全てのレイヤーで、ログを取得し、S3に集約する
- オンプレミスでは非常に大変だがAWSでは標準機能で簡単
- CloudTrailによる監査ログも同時に取れる
- セキュリティ・ダッシュボード
- VPC Flow Logs / Elasticsearch / Kibanaで可視化
- Domain Generation Algorithms
- 実際にはIPアドレスだけで脅威を判斷することは必ずしも適切ではない
- DGAによるドメイン名からの通信をブロックしたい
- 世の中の悪い人は自分たちでドメイン名を決める
- ドメイン名の生成は自動化されていて、それがDGA
- 正しいドメイン名の例: images-amazon
- DGAによるドメイン名の例: 30ac09876567ad9f
- AWS WAF + Amazon Machine Learning
- DGAで生成されたドメイン名を学習させて、怪しいドメインはWAFに登録する
- リスクベースのセキュリティ戦略
- リスク分析
- 脅威
- 異常検知
- ヒューリスティック
- 脅威インテリジェンス
- 脆弱性
- 脆弱性スキャン
- ベンチマーク
- パッチ適用
- 情報資産
- ユーザ振る舞い検知
- 情報漏えい防止
- 機械学習
- 脅威
- AWSのサービスを組み合わせるとリスクに基づいたセキュリティ対策の意思決定が可能
- リスク分析
感想
AWSのサービスを組み合わせることにより、様々なセキュリティ対策の自動化が出来ることがわかりました。
また、既に具体的な対策の方法はAWSが公開しているので、これを利用しない手はないですね！
それぞれの公開されている自動化の検証もしてみたいですね。
18
