SECUAD 10/7

secuad

午後対策

  • 恐ろしく眠くて、全く問題に集中できませんでした。ピンポイントに15分くらい仮眠したら大分すっきりしたけど、疲れの蓄積が半端じゃないのだろう。きっと。
  • セキュリティポリシーの障害情報の取り扱いを周知徹底させる。
    • 周知徹底して事故が減ればいいんですけどねえ。
    • 実際には、アウトソース先にこちらのポリシーを押しつけるなんて事は不可能でしょう。むこうだってsharedで業務やっているわけだから。まあ、アウトソース契約の値段にもよるのでしょうけど。
    • そう言う状況で守らせようとすると、監査するとか脅すとか、そう言う話になっちゃうような気もする。
    • っていうか、ポリシーの周知徹底なんてやってて当然でしょうが。
  • バッチ運用後の影響範囲の調査
    • パッチ適用
      • プログラム変更
        • 動作確認
          • 頻度大
            • 確認範囲大
              • コストに跳ね返る
    • なるほどね！
  • 不具合の緊急性を判断し、緊急性が高いものに対して、優先的に対処する。
    • リスク -> 優先順位がある。
    • 脆弱性があっても、当面リスクがなければ放置しておいてもよい。
      • 何でもかんでもやるのは無駄なコスト
    • 緊急性が高いものは緊急対応、低いものは定期対応と使い分ける。
  • K社に支払う事故対応サービス用とA社の対応費用の差額が、2営業日以内が最も低い。
    • 対応コストと機会損失の比較ですね。
  • 問題文にヒントがない場合、一般論をもとに応える。
  • IDとPWの問題
    • 推測されないパスワードは、記憶するのが難しい。
    • 定期的にパスワードを変更する手続きが面倒である。
      • パスワード == 人が記憶する
      • 複雑なものは覚えられないよ！
      • 紙に書いたりするのでリスクが上がる。
  • 人事異動で所属が変わると、公開鍵証明書の変更が必要である。
    • 証明書の発行は面倒
    • 変更されてもかまわない情報を鍵にするべきである。
    • 人事異動で失効しないように設計に留意するって問題文に書いてありますね。
  • 公開鍵証明書を失効させる。
  • 新しい鍵のペアを生成し、公開鍵証明書の発行を申請する。
    • ここで、「再発行手続きを行う」ではだめなんだろうか？
    • 認証局は社員の私有鍵を保存しない
    • 社員は配布されたツールを用いて新しく鍵ペアを生成してから公開鍵を取得する。
    • 秘密鍵の管理がずさんすぎませんかね！？
  • 前：初期パスワードとパスワードの有効期限を通知
  • 後：証明書発行通知と受領確認の連絡依頼
    • 初期パスワードを神出や渡していたのをメール化したいというのが根本
      • 本人かどうか？（真正性）
      • 受け取ったかどうか？
      • 盗聴されていないか？
        • パスワードに有効期限設定
        • 返信を促す
    • 対策としてこれって有効なんだろうか？
  • B社はクライアント認証なので、認証時点で証明書が有効であればよいのに対して、W社はデジタル署名なので、署名時点にさかのぼって有効でないと、署名を確認できないから。
    • なるほど！！
    • サーバ証明書とクライアント証明書の違いは、このように書けばよいらしい。
    • 本人確認の認証と内容確認（改竄、否認防止）の署名の違い。
    • クライアント認証
      • パスワードの代わり
      • 本人確認の認証を試みた時点で有効で蟻さえすればよい。
      • 比較的直近で更新を試みても十分
      • 配布範囲も本人だけだし。
    • サーバ証明書
      • 否認防止、改竄検出
      • 対外的にも用いる
      • 署名時点にさかのぼって有効である必要がある。
      • 問題文には署名の有効期限が書いてないけど、多分一年とか二年という設定なんだろう。
      • 早めに対処が必要。
  • 宛先アドレス
    • メールの宛先だけじゃないかもしれないので、あやふやな書き方を推奨。
    • IPアドレスであることまで相当するのか。目から鱗だった。:-)
  • 「改竄」を検出したり、----を防止するために、----を行う。
    • 答えには、「盗聴を防止するために、暗号化を行う」となっていた。
    • でも、「否認を防止するために、署名を行う」でも間違ってはないような。
    • ああ、そうか。前段にある「配送経路状での」が何処にかかるかによるんだ。
      • 配送経路上での改竄＆盗聴か、配送経路上での改竄or否認ってことか。
      • まあ、盗聴の自然だろうから、そういう風に考えよう。配送経路上での脅威は、改竄と盗聴。
      • ああ、いずれにしても、署名では宛先の改竄は防ぎようがないので、暗号化の方がが望ましいのかな。
  • パスワードを他人に教えない。
  • パスワードを引き継がない。
  • ヒントがないので一般論。
    • 事故を管理者に報告しない
    • システム全体に被害が拡大する
      • 自分のPCがやられてうろたえる -> エスカレーションしない -> よく分からないまま事象が進行する
      • まあ、確かに最悪だな。
      • 事故の正確な情報を記録しない -> 事故原因の調査が出来ない。
  • ウイルスを削除しようとして、パソコンの必要なシステムファイルを削除してしまう。
  • ネットワークから切り離さずに対応することで、ネットワークを介してウイルスが拡散する。
  • パスワードによる認証を行う
    • なりすまし対策は、暗号化ではない。
    • 真正性確認のための認証を行う。
      • 確かに、それをこのインフラでやるならID/PWですわね。
      • さらに形態で出来る炉シューションであることが求められている。
      • 携帯でID/PW入力って、かなり困難なんですが。orz
  • 本人確認を十分に行わず、電話でパスワードを教えた。
  • 営業部長の居場所を確認した上で、本人の携帯に電話して、本人を確認する。
    • 書くのは行為の問題点であって、その結果生じるリスクとか、行為の理由ではないことに注意。
    • でも、この人、本人確認してからどうするんだろう？まさか、そのまま携帯電話でパスワード教えるんじゃないよね？
  • 問題文をよく読もう！
    • 応えるのは禁止規定
    • ウイルス対策・情報漏洩の観点から、やってはならないこと。
      • 貸与されたノートパソコンにソフトウェアをインストールしたり、設定を変えることを禁止する。