ペネトレーションしのべくん

さようなら、すべてのセキュリティエンジニア

システム開発におけるセキュリティガイドラインの理想について

会社でシステム開発・運用におけるセキュリティガイドラインを作っていて考えたことです。そういうものを作らなければならない人たちの参考になるかもしれません。

何のために作るか

  • セキュリティにおける、組織としての落としどころを明らかにするために作る
    • セキュリティは「やり過ぎ」と「やらなさ過ぎ」どちらも起きる可能性がある
    • 「やらなさ過ぎ」を気にして、一般的なことを書いてもしょうがない

何を書くか、書かないか

  • 「会社として決めなければならないこと」だけ書きたい
    • 例
      • ログは何を、どれぐらいの期間保存しなければならないのか？
      • ユーザーのパスワードは何文字〜何文字を許容しなければならないのか？文字種は？
      • OSSの脆弱性にどう対応していくのか？
        • 全てのOSSを常に最新バージョンにはしておけない
  • SQLiとかXSSとかはなくて当たり前なので書かない（書きたくない）
    • 何を以てそれらがないと判断するかは決めておく必要がある

誰に書くか

  • 読者の想定レベルが重要
    • 「徳丸本の内容が理解できている」が一番ちょうどいい
      • SQLiとは？XSSとは？なんて、会社の資料で解説したくない
      • 徳丸本の内容を理解・実践できない開発者がシステム開発すべきでない（過激派）
      • 外注の場合はどうなるのか？
        • 発注担当者は徳丸本を理解していなければならないか？
          • それは望めない場合も多い
          • 責任転嫁するしかない
            • 自社の開発者、もしくは品質管理部門
            • 発注先の開発会社
            • 脆弱性診断の発注

何で書くか、どうやって検証するか

  • ガイドラインが守られているかを検証するスキームが必要
    • セキュリティガイドラインは、何もしないと事故が起きてはじめて違反に気づくことになる
      • これでは遅い（組織に被害が出ているので）
  • 何で書くかは、検証方法を見越して検討する必要がある
    • 遵守状況を可視化できるといい
    • WordやExcelだけで管理するのは文明人のふるまいではない
      • インターフェイスとしてそれらを使うだけならギリギリ許容できる（ただしWord、テメーはダメだ）
  • なんかそういうSaaSあるのでは？

誰が書くか

  • 徳丸本の内容が理解できるなら絶対に自分たちで作ったほうがいい
    • 外注はズブの素人でもない限りやめたほうがいい
      • 5000兆歩譲って外注するにしても、アウトラインだけとか
      • 個人的に非常に体験が悪かったので
        • お前が外注ヘタなだけじゃねえかと言われるとぐうの音も出ない