【レポート】「TISが描く将来のセキュリティ×クラウド運用の形~エンタープライズセキュリティ運用が描く未来~」AWS Summit Tokyo 2019 #AWSSummit

AWS Summit Tokyo 2019のセッションレポートです。こちらでは「TISが描く将来のセキュリティ×クラウド運用の形~エンタープライズセキュリティ運用が描く未来~」の内容をレポートします。
2019.06.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

本ブログでは『TISが描く将来のセキュリティ×クラウド運用の形~エンタープライズセキュリティ運用が描く未来~』に関する内容をレポートしたいと思います。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

TIS株式会社 プラットフォームビジネスユニット エンタープライズセキュリティサービス部 エキスパート

河田 哲

今まで多くの企業において分離されていたクラウド運用とセキュリティ運用を統合した、新たな運用分析基盤「エンタープライズセキュリティ運用サービス」をご紹介します。AWSのサービスや、様々なデバイスからのログの収集と分析による脅威の発見→通知→対処までをワンストップでサービス提供し、グローバル対応などの多種多様なご要望にお応えする事で、お客様のコア業務への集中に貢献します。

 

レポート

  • クラウドセキュリティの今
    • セキュリティ対策していますか?
      • 出来ているかどうかはモノサシがまちまち
      • 判断が難しい
    • 一般的なAWS環境を想定
      • 脆弱性をついた不正アクセスがあった
      • 不審なファイルを社員が発見
      • 経営層から対策の指示がだされた
      • 対応としてSOCを用意したり暗号化を実施したりした
      • その後、リスト型攻撃の対策をした
        • WAFを入れたり2要素認証を入れたりした
      • どんどんセキュリティ対策が増えていった
    • セキュリティ対策は維持する必要があるので、継ぎ足しで運用が破綻する
    • コストも膨大になる
    • 個々の運用だけを考えると良くないのでセキュリティ・バイ・デザインが必要
  • セキュリティ・バイ・デザインを意識したAWS環境とは
    • セキュリティ・バイ・デザインとは
      • 手戻りの減少・低コスト・保守性の向上を実現する
    • TISが掲げるセキュリティ・バイ・デザイン
      • 情報資産の区分・価値を明確にする
      • 情報資産LVに合わせたサービス機能選定
      • 被害を極小化するための仕組みを検討
      • 以上により利便性とセキュリティを両立する
    • AWSでは責任共有モデルがある
      • お客様がやらなければ行けない範囲を適切に判断する
    • 資産の区分や価値を明確にする
      • 資産に対して可用性・完全性・機密性を分類
      • 文書化する
      • テンプレートを使って可視化する
        • 例えば可用性であれば、復旧目標時間をベースに検討する
      • 個人情報を扱う場合のリスク観点の例
        • 可用性: 数時間の停止は許容される
        • 完全性と機密性は高とする
      • 情報資産価値にあった対応方針
      • 情報資産Lvに合わせたサービス機能選定
        • セキュリティ機能選定
        • 設計 -> 評価
        • 個人情報を扱わない場合のリスク観点
          • 可用性・完全性は高
          • 機密性は低
        • 更改サイトへの攻撃はL7レイヤへのDDoSや不正なコードのインジェクションはリスクが高い
        • コンテナイメージの脆弱性もリスクが高い
        • 対策としてはAWS WAFを入れる
          • CloudFrontによりDDoSも止める
        • コンテナイメージのチェックはイメージファイルの脆弱性チェックとイミュータブルの徹底
      • コンテナセキュリティ標準はNIST SP800-190がある
        • ポイントがまとめられている
        • コンテナ固有OSを利用
        • 同一の目的、資産価値を持つコンテナを1つのグループにまとめる
        • コンテナ固有の脆弱性管理をする
        • コンテナホストに対してセキュリティ対策を実行する
        • コンテナに対応したランタイム防御ツールを使用する
        • AWSでも上記のうちいくつか考慮が必要
        • 運用で回避できないのはイメージファイルチェックとランタイム防御ができない
      • aquaで対応することができる
        • ポリシー定義によりイメージスキャンが可能
        • 実行中のコンテナを監視してポリシーに従って制御できる
    • 被害を最小化する仕組み
      •  インシデントレスポンスが重要視される背景
        • 標的型攻撃の認知件数が増えている
        • 侵入から検知までの平均期間は内部では下がっている
        • 気づいてからどうするかが重要
      • 早期発見を行う
      • 発覚した後、インシデントレスポンスで状況の確認や再発防止策の検討を行っている
  • インシデントレスポンス体制構築の壁
    • サイバーセキュリティ経営ガイドライン
      • 「経営者のリーダーシップのもとで、サイバーセキュリティ対策を推進していくための指針」
      • これをモノサシとしてまずはアセスメントする
      • 3原則と10項目ある
    • 対応方法
      •  経営者がすべての責任を負いCISOに支持
      • CISOは方針に従い体制を作る
      • CSIRTは対応法を具体的に整備・実装する
    • 全部やると膨大な労力と時間を要する
    • コア業務への影響もある
    • 課題
      • セキュリティ人材が不足している
      • 人材収集や教育は大変
      • CSIRTでは日々の対応・今起きていることの把握・事後の対応が必要
    • 最終的にはSOC(CSIRTとの連携)が大切になるができる企業の方が稀
      • ノンコア業務なのでセキュリティ運用はつらい
      • 自社で難しければCSIRT機能を含めてアウトソースする
  • エンタープライズセキュリティ運用サービス
    • LACと協業した
    • いくつかの包括的なソリューションを提供
    • 脅威インテリジェンスセンター
      • 運用管理だけでなく、セキュリティ監視、インシデント対応支援、情報提供、脆弱性管理を含んで提供する
      • CSIRTで定義されるベースのセキュリティ運用をサービスで網羅
      • 従来のMSSよりもより網羅したサービスとして提供する
      • Rapid7での脆弱性検知内容などの情報を提供
      • SIEMとしてsplunkでのログ収集とSOC基盤をTISでもつ
      • LACのJSOCと連携
      • お客様窓口を通してサービス提供
      • インシデント発生後の対応もTISでハンドリング
    • 業界別運用テンプレートを用意
      • 様々なガイドライン・基準・標準がある
      • PCI-DSS・NIST・FISC等
      • 例えば金融テンプレート
        • システムと運用で基準に準拠できるテンプレートを用意
  • ノンコア業務をTISで請け負って、本業務に集中していただくことができる

感想

セキュリティ対策は一枚岩では行かなくて、いろんな側面で取り組む必要があって課題になりやすいです。

継ぎ足しではなくセキュリティ・バイ・デザインで取り組んでいくことは非常に重要です。

また、CSIRTの役割をおまかせできるサービスはとても魅力的ですね。ぜひおまかせしたいですね。