構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

講習修了証がやってきた

「情報処理安全確保支援士 講習」という文字が書かれた封書がやってきて、

「あれ?今年のオンライン講習は終わったし、まだ集合講習の年じゃないんだけど?」

と不思議に思ってよく見たら、オンライン講習の修了証でした。

f:id:hmatsu47:20170628235150j:plain

 

但し、合格証などと違って、紙はペラペラです(余計なコストは使わなくてもいいけど)。

これ、オンライン講習システムからダウンロード・印刷するものだと思っていましたが、講習システムから出せるのは「受講証明書」でした(Struts 1のアクション名は「syuryo.do」ですが)。

同封されていた紙に「オンライン講習B」という文字も見えたので「??」となりましたが、こちらは講習受講計画でした。

 

 

登録セキスペの登録申請準備以降の記事一覧はこちらです。

本の紹介/謙虚なコンサルティング クライアントにとって「本当の支援」とは何か

自分自身はコンサルタントではないのですが、勤め先は経営コンサルティング会社なので、タイトルが気になって買ってしまいました。

経営コンサルティング会社に勤めていて言うのはどうかと思いますが、(コンサルティング領域によって差があるものの)コンサルタントはあまり信用していません…。

謙虚なコンサルティング|書籍|英治出版

読み進めてみて、「謙虚な」の意味が少し自分のイメージと違う気がしないでもなかったのですが、「偉ぶらない」などの意味のほか、(原題が「HUMBLE CONSULTING」なので)「humble opinion」という言い回しに引っ掛けている部分もありそうな気がしました。

 

著者の言う「謙虚なコンサルティング」とは、(よくあるような)診断や分析をもとに「医者」のように振る舞い助言を与えるものではなく、「クライアントが直面している困難に謙虚な気持ちで共感的に向き合」うことで、クライアント自身が本当の問題に向き合って問題解決していくことができるように協力・支援していくこと、のようです。

 そして、「謙虚なコンサルティング」を行うためには、クライアントとの間に「取引上の、お役所的な、ほどほどの関係」(=レベル1の関係)ではなく、「個人的で打ち解けた(=パーソナライズされた)関係」(=レベル2の関係)が必要だ、ということです。雑に言えば、クライアントからホンネを引き出すためにはレベル1の関係では不十分、ということですね。

私の身の回りのコンサルタントを見ていると、表面上は「謙虚でない」コンサルタントのほうが、「謙虚に見える」コンサルタントよりも、この本の著者が言うところの「謙虚なコンサルティング」に近い考え方でクライアントに接しているような気がします。

なので、最初のほうで書いたように「謙虚な」の意味がイメージと違うかもしれない、と思ったのですが。

 

なお、「監訳者による序文」には「部下や同僚の力になりたいマネジャーやリーダーにとっても、本書は必携の一冊といえるだろう」とありますが、特に上司の部下への接し方については、文字通り見た目も「謙虚な」を意識したほうが良いかもしれません。

というのも、「部下の意見をよく聞いて理解している」ことを自認する上司ほど、部下との間で(この本でいうところの)レベル1の関係を脱していないことが間々あるからです。そして、その原因として、上司が部下に接するときの態度が(上司自身も無意識に)威圧的・指導的になっていることが考えられるからです。

この本に書かれているように、社会が複雑化して問題解決が困難になればなるほど、問題解決に必要な専門知識やスキルは直に接している人たち(コンサルタントから見ればクライアント側の人たち、管理職から見れば実務を行っている部下たち)が握る(一方でそれ以外の人に理解し難い)傾向がより強くなり、それゆえ問題解決を「直に接していない側の人」主導で行うことが難しい…という状況になってきています。

それなら、専門知識やスキルが乏しいコンサルタント/管理職が、変に診断・分析を行って見当違いな助言・指示をするよりは、本人たち=(コンサルタントにとっての)経営者・従業員/(管理職にとっての)部下のホンネを聞き出し、本当の問題の所在を明らかにし、意識させることで、本人たち自身で解決していくことができるようにしていくほうが良い、というわけですね。

 

 

いくら「部下の意見を聞く」という「行為」だけをしたところで、その態度が威圧的であれば、部下はホンネを言わず(上司に怒られそうな)都合の悪いことは隠そうとするので、問題の「真の所在」は明らかにならず、効果のある対処は難しいです。

私は管理職ではないので部下はいませんが、管理者の立場やベテラン支援者的な位置づけでプロジェクトに参加することがよくあるので、気を付けたいポイントです。

 

2017年6月度 ISACA名古屋支部特別講演会/ ITリスク学再考 IoT時代のリスク評価(6/17)

3ヶ月ぶりの参加です。

6月は月例会ではなくて年次総会だったため、講演会前の発表等が延びて予定時刻より少し遅れての開始となりました。

2017年06月度 ISACA名古屋支部年次総会及び特別講演会 | ISACA NAGOYA (JP)

 

内容はそれなりのボリュームがあったので、要点(と思しきところ)のみ箇条書きで列挙します。

ITリスク学について、詳細は講演者(佐々木良一東京電機大学教授)の著書などを参照してください。

www.kyoritsu-pub.co.jp

ITリスク学研究会 | 日本セキュリティ・マネジメント学会

 

・リスクの定義

 ⇒「将来の帰結に対する現在における予測」という見方が下敷きになっている

  常に不確実性を伴う

  ISO/IEC 27005:2008によるITリスクの定義

   リスク=資産価値×脅威×脆弱性

・ITリスク問題が重要になった背景

 ⇒社会全体のITシステムへの依存増大による

・ITリスク学の確立

 ⇒2008/5に研究会立ち上げ、ITリスク学の定義、全体像と構成要素、研究課題の明確化、研究課題の解決に向けての活動を経て、2013/2に本を出版

・ITリスク学の定義

 ⇒不正によるものだけでなく、天災や故障ならびにヒューマンエラーによって生ずるITシステムのリスクならびにITシステムが扱う情報やサービスに関連して発生するリスクを、リスク対策の不確実性や、リスク対リスクの対立、関与者間の対立などを考慮しつつ学際的に対処していくための手段に関する学問

・ITリスク学再考

 ⇒必要性の高いテーマを先行的に扱っていたのは良かったが、範囲が広すぎ、掘り下げが不十分だった

  リスク評価・リスクコミュニケーションの部分に重点化すべき

  IoTによりリスク評価も新しいアプローチが必要

・多重リスクコミュニケータ(MRC)

 ⇒背景:①多くのリスクが存在→リスク間の対立を回避する手段が必要

     ②1つの対策だけでは目的達成が困難→最適な組み合わせを求めるシステムが必要

     ③多くの関与者が存在→関与者間の合意が得られるコミュニケーション手段が必要

  対応:①リスク・コストを制約条件とし、残存リスク等を最小化する対策組み合わせ問題として定式化

     ②関与者の合意が得られるまで制約条件値などの値を変えつつ最適化エンジンを用い解を求める

・MRCに関する最近の研究

 ⇒1. 合意形成対象者が1,000人を超す問題への適用

  2. 機能の拡張→被害発生防止対策と復元対策の両方を考慮した対策案最適組み合わせ法、動的リスクを考慮した多重リスクコミュニケータ、経営者とのリスクコミュニケーションも考慮した多重リスクコミュニケータ、多段にわたる攻撃のリスク評価のためのリスク解析法(EDC法)の開発

・EDC法

 ⇒イベントツリー分析法+ディフェンスツリー分析法

イベントツリー分析法

 ⇒事象の発生から時系列順にどのような事象に発展するかを分析

ディフェンスツリー分析

 ⇒攻撃に対しトップダウンにその要因を分析する

  アタックツリー分析に対策を加えたもの

・EDC法の実適用

 ⇒東京電機大学の次期セキュリティ対策

  コストをかけてもリスク値があまり下がらない対策がある

  結果、入口対策4:内部対策2:出口対策2を組み合わせることに

  ※詳細は機密情報なのであくまでイメージとして提示

・IoT時代に予想される攻撃

 ⇒被害大型化、被害形態多様化(完全性・可用性喪失が主)、攻撃対象多様化、犯罪組織高度化

  ネットワーク側から入力中心のIoT機器→制御系の危険性が高い

  人命が失われる場合も

  無防備な機器が多い(防犯カメラ等)

  DDoS攻撃の踏み台

  Censysを使った機器検索

  セキュリティ意識等とフィッシング被害等との相関

  IoTのサプライチェーンにおける脅威(メーカの本国政府へのデータ送信疑惑)

IoTセキュリティガイドライン

 ⇒5つの指針・21の要点

  実現・実行可能性は「?」

・IoTの階層別セキュリティ対策

 ⇒システム層(Data Center)、サブシステム層(Gateway)、IoT機器層

  セキュアゲートウェイ(サブシステム層→IoT機器層)

  認証チップ(IoT機器層→システム層)

  種々の対策の組み合わせ(全体)

・STAMP法=概念

 ⇒MITのLeveson教授が提唱

  安全解析のパラダイムシフト

  従来手法:アクシデントは構成機器の故障やオペミスで起きると仮定

  新手法(STAMPなど):アクシデントは構成要素間の相互作用(信号有無、タイミングのずれ等)から創発的に発生すると仮定

  「STAMP手法に関する調査報告書」を公開:IPA 独立行政法人 情報処理推進機構

・STPA=安全解析手法(ハザード分析)

 ⇒STAMPモデルの3要素(相互作用を表すコントロールストラクチャー、アルゴリズムと対象プロセスを表すプロセスモデル、守るべき安全制約)を用い、コントロールを行う側とその対象プロセスとの間の相互作用において、安全制約が不適切であったり守られない状態になったりするシナリオを中心に分析

  安全分析/解析手法であるため、セキュリティを導入する新手法(新技法)の開発とデザインへの取り込みが重要に

  ※そこを今世界に先駆けてできるように頑張っている

  EDCもIoT向けのアプローチとして使えそう

・まとめ

 ⇒IoTシステムのセキュリティ対策→今後ますます重要に

  IoTシステムのリスク評価・リスクコミュニケーションも大切

  セーフティとセキュリティを同時に考えていく必要→対応は簡単ではない

  研究者が限られる→学会・研究会を通じた情報交換が大切