組織の中で、セキュリティーリスク対策が大事なのは、みなさん総論は賛成。しかしながら、各論に入ってくると、どうしても各社の事情が入ってきて、2線の取り組みが、1線組織からするとあまり支援やサポートっぽく見えないことがある。ざっくりいうと、2線がセキュリティポリシーや規約・基準を作ると、1線の組織(特に幹部)、「うちにはさー、セキュリティ人材がいないからさー」とのくだり。誰しもが聞くやり取りではないだろうか。こういうギャップを埋めつつ、なんとか無理せず守れる環境づくりを目指したい。
続きを読むCOSOの3つのディフェンスラインモデル
今回は、内部監査人協会(IIA)の3つのディフェンスラインモデルの活用*1を元に、セキュリティや品質向上の観点で考えてみたい。3つのディフェンスラインモデルというのは字数が多くなるので、普段は3線モデルと自分たちは呼んでいる。
この報告書の資料自体、2015年に公表されたものだが、今でも参考になるところが非常に多い。まずは、第1・第2・第3で並べて書いたもの。最近は、情報セキュリティの対策強化の観点で引用することが多いが、実際はセキュリティは単なる一要素であり、実際にはガバナンス全般の対策強化の考え方である。
この中で、第1のディフェンスラインとなるのは、経営者のコントロール配下である。会社であれば企業であるし、会社の中でマイクロマネジメントを推奨しているのであればよりその組織の部分集合が第1線である。社長が会社の経営を適切に回し、情報セキュリティ責任者がセキュリティリスクを抑止するために必要な対策を行うのが、まずは基本である。
続いて第2のディフェンスラインとなるのが、1線を統括監理する役割の部署。グループ会社であれば、ホールディングであろうし、それ以外にも1線を監理することを所掌に置かれているところが第2線となる。セキュリティだけでなく、財務管理やリスクマネジメント等、専門人材を第1のディフェンスラインで十分に揃えることが厳しいことから、第2線は第1線がうまくいくように対応していく。その手法として、以下の点が挙げられている。
第2ディフェンスラインでの支援手法 |
このうち、下線を引いた5点が、このモデルを実行的にするための肝だと思う。
1.リスクを管理するためのプロセスとコントロール・・・第1線も本来コントロールをしている。だけど2線が出てくることで、何を言われるのかと構えてくる。2線としても、すべてのリスクに対して支援はできないので、まずは自分が担当するリスクと、コントロール手法を明示する。
2. 2線のコントロールは、通常1線からみると、存在がウザい。だけど経営層の要望が何かを示し、それに基づいて評価軸、アセスメントを作る。
4. 観測を続けると問題が見つかったり、新たなリスクが見えてくる。継続的な観測、モニタリング、アセスメントの中で、なにかその予兆が見えないかどうかを見えるようにしたい。まずは異常値が何かを定義し、それを青黃赤の信号に変える。この信号のロジックがリスクのコントロールの肝であるし、通常は信号を見る人は信号を見て進むのか止まるのか、行動を変える。ただし、立場の違うヒトが信号を見て勝手に大騒ぎされないように、自分の見るべき信号かどうかを明示しておく必要がある。
6. 組織のリスクは、通常1線で洗い出してコントロールする。2線の役割は、1線の管理内容を踏まえて、どうしても見られないものを見えるようにしたり、1線で苦労する新たなリスクに気がつけるように観測を進める。この観測は1線にも協力をお願いしないといけないので、2線としても何をどう監理するのかは、いくら経営層のお墨付きだとは言っても、第1線がわかるように説明責任がある。
8. 1線と2線が良い制御関係を作ったら、1線のヒトに役立つガイドラインや研修を行うのは効果的。1線は通例、たくさんのルールの中で何をやっていいのか混乱していることが多いので、混乱しないようにリファレンスをつくるとか、研修で理解いただくのは大事。
ここまで落とし込んでから、フィロソフィを関係組織で握れると、統制も楽しくなる(ことを期待している。いつも)
回るセキュリティ。回らないセキュリティ。(単なる愚痴)
セキュリティは大事だからさ、なんか対処をしておいてくれよ、とか
セキュリティは大事だから、万全にしておいてくれよ、とか
難しいねぇ。セキュリティ。何かのセキュリティソリューションを入れれば万全、ってわけでもない。だからといって、業務の回らないセキュリティも守られない。
以前、例え話で言われたのが、
「セキュリティって、つまりは風呂桶に何箇所も穴が空いてて、放っておくと水が漏れるって、話だろ。だから、セキュリティソリューションという絆創膏で何個塞いだ、と言ってくれると、わかりやすいじゃないか。」
それはそれで・・・という印象。
他方で、セキュリティに関する専門家、先生にかかると、これが賢いから、全然違う方に行く。「技術的にはね、理論上はね」、とか想像だにしないことを、いろいろ考えることができる。
でもそれは、大抵お金がかかる。手間がかかる。
例えばパスワード。ログインパスワードは10桁以上にしてね。暗号化キーは15桁以上ね。そのほうが、総当たり攻撃に対する耐性が高くなります。そりゃそうだ。
でもねぇ。そのパスワードを覚えてられないから、一定のサイクルにしたり、同じにしたり。なので実際は生体認証とか、パスワードレス、ワンタイムパスワードとか、純粋なパスワードでないものも組み合わせる。
つまり、パスワードの耐性と、業務のしやすさは両立しないといけない。何も考えないと、通常はセキュリティは業務の足かせにしかならないと言われやすい。
境界制御じゃないよ、ノントラストだよと言われて久しい。
ソフトウェア、ハードウェア、プロトコル、チップ。さまざまなものに脆弱性は発生し、それに対するパッチを当てる。これも、長いパスワードを適用しなさいに、通じるものがある。すべてを安全に、信頼のおける世界を作っていく、そういうルールとか、フレームとかを検討し、作り、普及していく、これも大事。
ただしフレームから、「このソフトでこう管理してください」と手順に落とし込む時点で、無理が生じる。フレームはコントロールなので、コントロールを伝承することはできる。他方で、「この製品でこう管理する」はルール、手順なので、こちらは通例固められないし、ルールに落とし込むときには、環境に応じてコントロールは調整しないといけない。例えば、一人しかいない宇宙ステーションにパスワードが必要な機器があった場合、そんなものを10桁以上になんか、する必要がないのだ。
基準は基準、ポリシーはポリシー、次に管理が来るはずで、手順は参考文書にはなるけど、管理と併記して書いてはいけない。そこに手順を書いてしまうから、回らない業務、回らないセキュリティが生まれてしまう。
逆に、セキュリティを守れと脅迫されてしまう人たちは、「何でもいいから手順を示してくれれば守ります」と手順を要求してしまう。リスクを把握せず、管理を意識せず、手順だけを守って、何を守れるというのだろう?
仕事のお金を使ってる?
お金を使う話。もちろん、仕事の上で。
お金を使うとなると、決裁も取らないといけないし、費用対効果もみないといけない。いつの間にか、お金を使わないことがいいことになってる。
でもねぇ。お金を使わないですめばいいけど、お金くらいは使えるようになっておこうよ。
最初、予算計上されているかな。まあ、予算を取るところから苦労して、逆に予算を取ったら、予算は執行しなければならなかったりして。
まあ、会社のお金ですからね。会社に貢献する方向で、同意を得ればいいじゃん。本当に必要なときは、計画外でもお金は使える。それくらいの覚悟というか、開き直りをしている方が、健全なお金の使い方に慣れる。
最近、お金を使わないで、大人しくしていることが、正しいと思っているヒトがいる。いままでお金をかけてやっていたことを、お金を使わないでできるようになるんだったら、それはすごいよ。でもね、そうじゃなければ、お金の使い方は覚えたほうがいい。お金の使い方、それ自体が仕事の本質かもしれないよ。例えば、小売業だって、商品買うのも、店内改装するのも、広告するのも、ヒトを雇うのも。
小売じゃなくて、大企業だって、基本は同じ。まあ、いわゆる、投資って言ったほうがいいかな。
クラウドサービスの法的リスク
安くて便利なクラウドサービス。まあ、料金は従量制で高くなることもあるから、まずは便利なクラウドサービス。IaaS、SaaS、PaaSいろんなレイヤがあるけど、クラウドサービスでのセキュリティで、確認を問われるのが、法的リスク。どこの国で裁判するかの管轄法と、どこの国の法律で管轄するかどうかの準拠法の話である。
調べたことがある人はご存知かもしれないが、日本でサービスに加入に入っているんだから、データも日本の何処かにあって、管轄法も準拠法も日本でしょ、と思い込んでいるかもしれないが、そういう方々は自分が使っているクラウドサービスの契約書に目を通してみるとわかる。契約書が長くても、法的事項は最後に書いてあることが多いので、そこを見ればすぐに分かる。最近のツールは優秀なので、ホームページなら技術的にはどこの国のサーバに保管されているかはすぐにわかるので、結構有名なサイトでも、海外にあるんだなー、なんてのは、外形的に見てもわかる。
で、クラウドで何をするか、だし、公開情報や機密外情報であれば問題ないんだけど、業務に使うものだと一部リスクがある。最近、気がついたのが、動画作成ソフト。前に使っていたVyondがこっち側の問題は使えなくなってしまった(注:Vyondは何も悪くないですよ)し、年約15万円のライセンス費も個人の趣味で負担するには重たいかなと思って、Youtubeでも推している個人向け動画作成ソフトを使い始めた。
一応、どのクラウドサービスでも法的リスクは気にしているので、サービス加入の契約書を見ると裁判は日本の国内法。ほう、これならいいやとサービス契約し、しばらくは慣れのために公的情報を使って動画を作ってみる。AI機能も入っているので、伝えたいメッセージだけ書くと、AIが動画コンテンツを作ってくれて、BGMまで流してくれる。絵心のない私には、非常にありがたいソフトだ。
でも、使い勝手はVyondとは違うので、苦労しながら使い方を格闘して2週間、おおよそ作れそうだと確信してきたので、そろそろ業務的なものも作ろうかなと思った矢先、メッセージが出てきた
「クラウドの拡張ができます(無料)」
それほどたくさんのコンテンツは作ってないけど、AIが動画を作るから領域を思ったよりかかるのかな、と思ったら、拡張のためには、追加で利用契約を承認のボタンを押せと書いてある。
一応サービス契約時は国内法と書いてあったからな、と思ったところ、無料のクラウド拡張の契約にかかれていたのは、管轄法も準拠法も、いわゆる第3国の国名と地名。
「おー、この段になってから聞いてくるのか」と萎えてしまったので、この動画ソフトの利用は終了。早速解約しておかなきゃ、ということにした。
この動画ソフト、AI画像作成がベータ版って書いてあるんだけど非常に秀逸で、他の生成AI以上の完成度のイラストをホイホイ作ってくれる。これはすごいなと関心してたんだけど、こうなってくると、そういう動画も本当に著作権フリーになるかは非常に怪しい。
ということで、また次の動画ソフトを物色中。業務の動画だから委託すればいいのかもしれないけど、そうするとどうしても動画に魂が入らないと、結構内製したくなる。(後任に「こんな職人芸は、引き継げない」と嫌がられるのだが)
なにかいい動画ソフトがないかな。お小遣いで済むくらいの。
※ もちろん、クラウド自体のセキュリティリスクで情報窃取されるリスク等もあるけど、今回は法律リスクの点だけのメモです
運用監視の基礎知識!情報システムの運用とは?
今回は「運用監視」について、まとめてみる。研修を通じて「運用監視」をきちんと理解してほしい、という声がきっかけだ。
ここでいう運用監視というのは、組織が事業・サービス向けに構築した情報システムの運用監視のこと。開発フェーズのあとの、運用フェーズのことだ。ITSSというスキルセットでITエンジニアのスキルを語っていた頃の話だったり、ITILで定義されているような知識体系の話。もちろん、運用監視に関わろうというヒトにはそういう話も必要にはなってくるけど、今回は入門編。「へー、運用監視って大事なんだね。なんとなくわかった」と言ってもらえるが目標。
自分が初めて運用の部門に配属になった大昔、(その前まで属していた開発フェーズの)その後の工程くらいに思っていた。閉域網の中で情報システムを取り扱っていたし、ほとんどがオンプレでのシステム構築だから、開発に費用も期間もかかるし、それなりに大切に扱うものだともコンセンサスがあった。
今はどうだ。クラウドやSaaSを使うことが前提になり、システムは閉域網ありきで語ることができなくなった。穿った言い方をすれば、MSがOffice365になんかにするから、Officeから抜けられない企業は(Direct Accessを使うとはいえ)一定のポートを外部向けにオープンにすることが前提となった。またマルウェアを介した感染と合わせて、サイバーセキュリティに完全なネットワーク設計を行っても境界で防御なんてできなくなった。
で、最初に戻って、運用監視(の業務の意義)ってなんですか、の答えですが、「事業・サービスの安定稼働のために定期的に必要な確認を行うのが監視、監視の結果でリスク等を観測した場合や、予めカレンダーで定めて、必要な対処を行うのが運用」である。
ここで、高可用性を担保するための、システムの冗長化にも触れる。
システムは故障する。故障に際して、いちいち事業・サービスをとめられないから、単一な障害で止まらないような仕掛けを作る。例えばN+1のコンピュータを同時に動かして、何かが止まったら動いているコンピュータに処理を引き継いで、サービスを止めない仕組み、これが冗長化。
そもそも運用監視の目的は事業・サービスを安定して提供することなので、単純な故障が起きても大騒ぎする必要はない。事業・サービスが使えていればいいのだ。
なので、社会インフラ事業を提供する会社、通信や電気、水道サービスを提供する会社の冗長化はそれなりに堅牢に設計されているし、PoCのようなサービスに堅牢な冗長性は必要はない。冗長化ができていれば、故障部位が自動的に切り離されたり、縮退運転で安全にサービスを運用できれば良い。
で、またまた最初に戻る。監視というのは、サービスの安定提供のために何らかの対処が必要な状態になっていないかを監視すること。運用というのは、監視またはタイムスケジュールに基づき、必要な対処なり、オペレーションをすることが運用だ。セキュリティリスクも、事業やサービスを止めるかもしれない1つのカテゴリーであって、目的ではない。
例えばOffice365の運用監視をしていれば、その目的はOffice365の提供だし、Office 365の機能を1つの部品と見立てて提供しているAサービスの監視についての目的は、Aサービスが安定提供できることである。
もちろん、不幸にしてAサービスの全部を止めてしまうような障害もあり得る。例えば、複数系統化された電源供給が全面的に相当期間止まってしまった場合、システムは稼働できず、Aサービスも停止する。その際のBCP(Business Continuity Plan)は並行して考えておく。(けど、今回は長くなるので、そちらの深掘りはやめておく)
Office365を監視しているヒト(多分、MSから委託されたヒトだと思いますが)や、Aサービスを監視しているヒトが、同じイベントを見つけることもある。例えばOffice365自体の障害であれば、Office365だけでなく、それをベースにしたサービスも止まる。)この点を気にして、複数のヒトが同じものを監視するのは無駄との考え方もある。ただ、最近はこの辺の監視はほぼ無人化するから、センサーのそれぞれが監視することは、ダブルチェックにすればいいだけで、監視の棲み分けまでは気にしない。この場合はAサービスはAサービスの視点で監視するし、Office365の障害とわかった時点で、Office365の復旧までどう凌ぐかが、Aサービスの運用監視の仕事である。他方、Office365の監視のヒトは、Office365をどう復旧できないといけないかに奮闘しないといけない。見方を変えれば、両者は全然別物なのだ。
IIAの3ラインモデル
最近、3ラインモデルの推進、実践に関わる仕事が続いている。自分としてのマイブームなんだけど、世の中でも普及しつつある考え方なのかな。
まずは日本内部監査協会の解説資料
https://www.iiajapan.com/leg/pdf/data/iia/2020.07_1_Three-Lines-Model-Updated-Japanese.pdf
他、各会社が解説記事を書いている。こんなポンチ絵が載っている。
単に自分が目にしてなかっただけなんだと思うけど、昨年度まではあまり見たことない図だった。簡単に図の補足をすると、組織のガバナンス統治モデルとして、第1~第3ラインに役割を分けて定義されている。ここで扱われるテーマは、いつも述べているセキュリティが扱われることもあるが、いわゆる内部統制、内部ガバナンスのためのモデルなので、セキュリティは単にその中の1要素である。
第1ラインというのはいわゆる現場の人。様々なリスクをヘッジしながら事業を安定運用し、拡大することを推進するヒト。上記の図には製品やサービスと書いてあるけど、まあ、継続的に顧客に対して製品やサービスを提供するのが事業なので、特に違和感があるわけではない。
第2ラインは、「リスクに関連する事項について、専門知識の支援、モニタリングの提供及び異議申し立て」、と、ある。この役割に、このところ連続して当たっている。
専門知識というのは、セキュリティ対策もそうだし、IT化とか、DX化とか、そういうことを進めることを支援する役割。よく、◯◯人材が◯万人不足するという、正しさの検証のしようがない記事を見ることがある。世の中の傾向として、インターネットが当たり前になったのでセキュリティは大事だし、人手不足・品質と効率化のためにDXも大事。いまさらIT化の重要性は論じるまでもなく、だ。
第2ラインとしては第1ラインを支援する。支援しているつもりなんだけど、第1ラインからすると、第2ラインは鬱陶しかったり、屋上屋を架しているようにも見える。この点は、トップダウンに進めることが楽なこともあるけど、逆に第2ラインが提供する規程が的はずれだったりすると、第1ラインみんなを振り回してしまう。この点はよく現場を知り、適切な規程を定めて、継続的にモニタリングする。
第3ラインは、ちょっと立場的に離れて監査を実施する。監査権を持つ監査人が監査することもあるが、オオゴトになるから、通常は内部監査人が内部監査として監査して第1ラインにリスクを示して改善策の立案を求める。第1ラインが対策立案に苦労していると、第2ラインが支援して、第1ラインのガバナンス推進を支援する。
こんな感じ。
最近は、大企業も多角化で、組織グループ内にさまざまな事業を持っているし、逆に様々な事業の基盤(概ねIT基盤かな)を統合して、俯瞰的に対策を出すのもこのモデルが引用される。
で、よくわからないなーとなると、そんなときにコンサル会社に支援を頼むんだろうなぁ。でも、コンサル会社はIT基盤のことは、通常知らないことが多い。しらんけど。