セキュリティチェックシートって大変ですよね
「契約締結目前で、今日もらったチェックシートを3日後までに出せば決まりです！」
「これNGだと契約できないんですけどなんとかならないですか？」
「（書いてもらったシートをレビュー中）え！？これOKじゃなくてNGですよ！？」
「書き始めたら8時間以上かかってるんですけどこれ無償対応なんですか・・・？」
っていうことありませんか！？ない！？良かったですね！！（血涙）
ということで、結構セキュリティチェックシートで苦労しています。
過去にISMS認証を取得したときには「これでちょっとは楽になるな！よかった！」と思ったもんですが、
大きく楽になった感じはありません。
といっても、セキュリティチェックシートは次々来るので、なんとなく悟りが開けてきました。
ということで、道半ばではありますが、
- そもそもセキュリティチェックシートってなんだっけ？
- なんで苦労してるんだろう
- なにか楽になる方法はないのか
の3つ＋余談を（まとまりは無いかもしれないですが）書き殴って見ようと思います。
Qiitaの諸先輩方が書かれた同様の記事を合わせ読みして、
同じこと思ってるんだなとか、ここはこういう解釈か、なんて思って読んでもらえると嬉しいです:-)
そもそもセキュリティチェックシートってなんだっけ？
何事も納得ができないとやる気が出てこないと思います。
なんでセキュリティチェックシートを書く必要があるのか、
書かせる側/書く側の視点で書いてみようと思います。
（納得できるかはわからない）
共通
- セキュリティ事故があった場合に言質を取るため
この認識は特に書く側は強く認識したほうが良いです。
間違った情報を書いてしまったときに、「あいつら嘘ついた！」と言われちゃいます。
自分たちの身を守るためにも正直に書きましょう。
書かせる側
- 契約（予定）先を管理する必要があるから
- 契約先が自社のセキュリティ基準を満たしているか確認し、不足があるなら補ってもらうため
-
情シス/セキュリティ部門がなんか書けっていうから
- 頼んでいるフロントの方はビジネス側の人だったりするのでそういうもんだと思います。ただし、これによって落とし穴が出てきます。(次の章でも関連した内容を書きます)
書く側
- その会社と取引を行うため
あれ・・・なんか書く側のメリットが大事は大事だけどこれくらい・・・？
ということで、その取引がどんだけのインパクトなのかを理解しないと、
苦労しか感じないのではないかなと思います。
事業を理解しつつ、セキュリティチェックシート記入の運用も楽にする、
というコスパの調整が必要なのかなと思います。
なんで苦労してるんだろう
いやもうそれなんですよ。皆さん苦労されてますよね。
自分なりに原因を分解してみました。
とにかく質問の量が多い
こればっかりはどうしようもないです。
先方がゴツめのセキュリティ認証を持っていたりすると多くなる印象があります。
とにかく書ききらないといけません。
楽になるための案
負荷を分散するのが一番良い方法かと思います。
どのチェックシートも聞いてくるようなものはまとめておいて、
誰でも返答可能にしてたら良いかなと思います。
- 社内のセキュリティルール
- セキュリティ認証の登録番号
- 提供しているSaaSのセキュリティ対応内容
とかは大体聞いてきて、大体同じ内容なので、プリセット的に用意しておくといいと思います。
ただし、インフラ構成が変わったり、セキュリティルールが変わったりします。
最新化は忘れないように管理するか、中小規模の会社であればレビュアーを置くのがよいかと思います。
弊社は最終レビュアーがいて、間違ったことが書かれていないかレビューしています。
そもそも書けない
「契約するベンダーはセキュリティ基準〜に適合しているか」
「自部署の事業部長、並びに、セキュリティ部門長の承認を得ているか」
こんなこと急に聞いてこられてもビビりますよね。どういうこと？ってなると思います。
これは、依頼元のフロントの方がセキュリティチェックシートを
あんまり理解していないことで発生しているのではないかと思います。
楽になるための案
セキュリティチェックシートの設問は「社外向け」と「社内向け」の質問があるのかなと思います。
- 社外向け
- 契約先に質問をする内容
- 「御社のセキュリティは大丈夫ですか？」的な内容
- 契約先に質問をする内容
- 社内向け
- 自社の担当部署に質問する内容
- 「契約しようとしてるけど大丈夫？」的な内容
- 自社の担当部署に質問する内容
そして、「社内向け」の質問がある場合、以下のような流れがあると考えられます。
少しいじわるな吹き出しを書きましたが、
セキュリティチェックシートは契約先が書いてもらうもので、
フロントの方もまさか自分たちが書く項目があると思わなかったために
こういう流れになってしまうのは仕方がないかなと思います。
（自分が経験した中でも自部署が書く系のシートは肌感5%あるかどうかでした）
組織構造上、監査・セキュリティ部門が別の場合は、
ガバナンス維持のため社内向けの質問があるんじゃないかと思います。
全部が全部自分たち向けの質問じゃない場合もある ということを理解しておくと、
こういうケースにびっくりしないかなと思います。
こういうときは、及び腰にならず先方に相談しましょう。
何を言っているかわからない(読み替えが必要)、理解が正しいかわからない
下記の「全然関係ないことを質問してくる」に近いですが、
最近では聞かない、ナウでヤングなモボやモガが使っていただろう言葉が出てくるケースがあります。
例えば「電文」とかがそうだと思います。（まだまだナウいだろ！という方すみません）
その他にも先方独自の用語が使われているケースがあったりして、
正しい理解で書けるか不安な場合があると思います。
楽になるための案
他の記事でも書かれていましたが、
「〜は◯◯と解釈した場合、✕✕です」
と書くのが良いと思います。
もしくは、NGや回答不可として、話し合いに持っていったほうが良いです。
というのも、「そもそもセキュリティチェックシートってなんだっけ？」に書いた通り、
セキュリティチェックシートは言質を取る側面もあります。
独自の理解で書いてしまうと、トラブルのときに困る可能性があります。
イミグレーションのときにちゃんと聞き取れなかった質問を適当に答えてはいけない、
みたいな話かなと思います。
余談ですが私は初アメリカのイミグレで聞き取れなくて適当に答えたら冷ややかな空気になったことがあります:-)
オンプレじゃないのにとにかくDCの運用について聞いてくる
「AWSで運用しているのにオンプレの質問を回答しなければいけない・・・」
みたいなことありますよね。
AWS/Azureならここはスキップでいいです〜っていうシートもありますが、
回答必須！監視カメラはあるか！？
みたいなのをひたすら聞いてくるシートもありますよね。
楽になるための案
今の時代、こんなシートでいいのかを純粋に先方の担当部署に聞いてみたいですが、
逆にこういうシートを出してくるところは大きい会社がほとんどな気がします。
大きい会社の場合、シートの変更だけでもそれなりのコストがかかるだろうことを想像できます。
この想像が正しい場合、シートをレビューする人もきっと時代に合ってないと思ってくれているでしょう。
とすれば、オンプレのことが書かれているところは全部、
「AWS運用のためAWSのセキュリティルールに従う」
と書いて一旦返してしまうのが良いかなと思います。
(もちろん設問はちゃんと読みましょう)
きっと、先方も時代に合っていないことは理解していて、
社内的には「あー、AWSでしょ。OKす。」みたいな感じに対応してくれるんじゃないかと思います。
AWSであってもセキュリティ対応を詳細に書かなければいけない場合は、
「AWS社とのNDAの関係で記載不可」
で打ち返して相手の反応を伺ってみましょう。
逆に、SOCレポートの内容を書くのはNDA違反の可能性があるので気をつけてください！
その他楽になるための提案
思いついたことをつらつら書きます。
工数は確保しよう
弊社の場合、最近は長めに期間を設けるように伝えていますが、
それでも結構3営業日くらいで書いてって言ってくる方々がいます。
他社の話を聞いていると、10営業日は確保しているようです。
とにかく工数は確保するように動きましょう。
先手を打とう
「基本のチェックシートは配布しますんで、それ以外はお金ください」
という会社もちらほら見るようになりました。
事前に用意できるならやっておくのはアリだと思います。
先方にも苦労を味わってもらいましょう:)
セキュリティに関する規格等について理解しよう
セキュリティチェックシートの背景として、セキュリティ認証・規格・基準があったりします。
例えば、
- ISO27001
- ISO27017
- JIS Q 15001
- PCI-DSS
- OWASP ASVS
などなどです。
なかなか内容を見ようという気にはならないですが、ISMS認証を取得・維持している経験から、
一度は目にしてみるのもアリかなと思いました。
セキュリティチェックシートのみならず、自社やクラウドセキュリティを考える上でも勉強になると思います。
可能なら開発時からセキュリティについて考えよう
↑の理解しように関連していますが、チェックシートを書くときに困るケースとして、
「（質問は理解できるが）ぶっちゃけやってない」というケースがあると思います。
では、やっていないことが全て悪かというとそうでもなく、
明確な理由でやらなかった場合は堂々と言って問題ないと思います。（いわゆるリスク回避）
こういった、理由付けを開発のタイミングからやっておくことが大事だと思います。
OWASP ASVSの「V1.1 セキュアソフトウェア開発ライフサイクル要件」の1.1.2では、
「脅威を特定し、対策を計画し、適切なリスク対応を促進し」とあります。
(OWASP ASVS 4.0日本語訳から抜粋)
つまり、これから作るもののリスクアセスメントを行い、リスク対応を図りましょうということで、
例えばSaaSを作るなら、
- インターネット上に公開するサービスなのでDoS攻撃が考えられるだろう（脅威の特定）
- サービス停止が1時間あるごとに〜円の損失になるため対策をすべき（対策を計画）
- AWS Shieldを使用してDoS攻撃の防御とする（適切なリスク対応）
という流れが考えられます。（対策を計画の部分が若干これでいいか怪しいですが）
これを実施しておくことで、チェックシートで仮にNGがあっても理由を書き加えることもできますし、
逆に先方がシートにかかれている対策を実施してほしい理由もわかるのではないかと思います。
（とはいえ、先方的に頑なにNGは通せないと言われてしまったらかなPですが・・・）
余談
弊社ではISMS認証を取得していますが、チェックシートの記入が直接的に楽になることはなかったです。
ISMSの運用をしていて理解してきたんですが、ISMSの規格であるISO27001はざっくりいうと
セキュリティのフレームワークで、そこに具体的なルールを実装していく形になります。
（逆にそういったものなので様々な業界・会社でISMSを適用させられるメリットがあります）
悪く言うと、中身がスッカスカなルールでも規格を満たしていたらISMS認証は取得できてしまうので、
セキュリティチェックシートでは認証の取得有無関係なく具体的な質問をしてきます。
ただ、まったくもって楽にならないかというとそうでもなく、
「会社としてセキュリティマネジメントができているか」という質問については、
ISMSの要求事項として必須なため、スッと記入することができます。
例えば、
- 内部や第三者の監査を受けているか
- 情報セキュリティに関するルールがあり、定期的に見直しているか
- 情報資産の台帳を作成し管理しているか
- 情報セキュリティ基本方針が存在し、公表されているか
みたいなものです。
とはいえ、殆どの場合、セキュリティ認証は水戸黄門の印籠のようにはいかないので、
セキュリティチェックシート対策は継続して必要となりそうですね。。。
最後に
なかなかに苦労するセキュリティチェックシートですが、お願いする方もされる方も工夫して、
より一層本質的なものにしていきたいですね。
それでは、さようなら〜