投稿者: ＰＣクラブ

　　Ｅｘｃｅｌレガシーとは
　　　　業務部門がExcelを使って作成し利用してきた業務システムのこと
　　　　　　現場の非定型業務処理の中心をなすシステム

　　　　技術的な問題点
　　　　　　・ブラックボックス化
　　　　　　　　マクロを含んだシートの作成者が不在になっている
　　　　　　　　改良の積み重ねとドキュメント不備で誰も内容が分からなくなっている
　　　　　　・部分最適
　　　　　　　　その場その場で作成したため、各部署での最適に止まっている
　　　　　　・後継者不足
　　　　　　　　若い世代には単なる文房具であり、使い込む対象ではなくなっている

　　　　内部統制上の問題点
　　　　　　・スプレッドシートの特性
　　　　　　　　中身のロジックが精査できない、間違いが検知できない
　　　　　　・情報漏洩の恐れ
　　　　　　　　簡単に持ち運びされ、コピーされ易い
　　　　　　・データが自由に入力され、変更される
　　　　　　　　数字の信憑性が疑われ、基幹システムとの間で食い違いが発生する
　　　　　　　　恣意的に数字が加工される恐れがある

　　対応策
　　　　・基幹システムのデータベースに基づくデータ活用を図る
　　　　・マクロの利用を抑えて、情報加工のプロセスを標準化・可視化する
　　　　・属人性を廃し、誰でも利用できる仕組みを確立する
　　　　・基幹システムと連携させて、全体最適を踏まえた上で部分最適を図る

　　　　・情報の一元管理
　　　　　　Ｗｅｂ上で更新させる
　　　　　　グループウェアで共有させる
　　　　・組織的な運用体制を確立する
　　　　　　ガイドライン等を作成して、利用環境を整備する
　　　　・ＸＭＬ化する
　　　　　　タグ付きのテキストデータとなり、プログラムからアクセス可能となる
　　　　　　　　データの更新と利用が分担可能になる

　　補足
　　　　ピポットテーブルの活用
　　　　　　・基幹データベースのデータが利用できる
　　　　　　　　ＢＩツールのフロントエンドツールとして使う
　　　　　　　　データベースから引き出したデータを直接加工する
　　　　　　・利用し易い
　　　　　　　　Excelに慣れていれば違和感無く利用できる
　　　　　　・プロセスが可視化できる
　　　　　　　　マクロを使用しないので、標準化された手順で理解され易い
　　　　　　・開発や運用が楽になる
　　　　　　　　

　　

（１）Ｗｉｎｎｙによる情報漏洩
　　Ｗｉｎｎｙ経由で情報が漏洩する仕組み
　　　　・Ｗｉｎｎｙネットワークから「Ａｎｔｉｎｎｙ」というウィルスを含むファイルをＤＬする
　　　　・「Ａｎｔｉｎｎｙ」を実行することに依って感染する
　　　　・「Ａｎｔｉｎｎｙ」はその後、ＰＣ内部のデータをＷｉｎｎｙネットワークにＵＬする
　　　　・ＵＬされたデータをＷｉｎｎｙユーザがＤＬして拡散する

　　情報漏洩のデータ確認
　　　　・漏洩を連絡してきた第三者から入手する
　　　　・専門家（ベンダー）に依頼して入手する
　　　　・Ｗｉｎｎｙを使って探し出す
　　　　　　２次被害の拡大が考えられるので、別途ネットワークやＰＣを用意する

　　　　データを取得できた場合には、速やかにＷｉｎｎｙキャッシュから削除する
　　　　　　これ以上、データを公開されたままにはしない

　　情報漏洩の源を突き止める
　　　　・ファイル名から、ＯＳのユーザー名を特定する
　　　　・ファイル内容から、作成者や使用目的等から源を絞り込む

　　他に漏洩していないかを調査する
　　　　・共有フォルダーの設定内容を確認し、他に漏洩していないかをチエックする

（２）内部関係者による情報漏洩
　　顧客からの問合せで発覚することが多い
　　　　問合せを受けて、対処のシステムを調査する

　　漏洩の可能性が高いと判断されたら、緊急対策本部を設置する
　　　　・システム担当者
　　　　・問い合わせ窓口担当者
　　　　・法務・公報・総務担当者
　　　　・経営者

　　システム担当者の調査対象
　　　　・いつ・・・・・事件発生日時の調査
　　　　・誰が・・・・・実行者の調査
　　　　・どれ・・・・・漏洩した情報の調査
　　　　・どうやって・・方法を調査
　　　　・どれくらい・・漏洩した情報量の調査

　　具体的な調査対象
　　　　・入隊室管理のログや管理簿
　　　　・本番・開発環境のサーバーのディスク
　　　　・ＤＢサーバーのアクセスログや作業記録
　　　　・ＤＢへのアクセス権限の設定状況
　　　　・Ｗｅｂサーバーへのアクセスログ
　　　　・セキュリティーホールへの対応状況
　　　　・アウトバウンド通信のログ
　　　　・管理者による端末操作ログ
　　　　・外部メディアの管理簿
　　　　・関係者の行動履歴

　　被害の状況説明や状況報告
　　　　・情報漏洩の概要
　　　　・漏洩した期間・日時
　　　　・漏洩した件数
　　　　・漏洩した項目（個人情報、カード情報等）
　　　　・漏洩の原因
　　　　・二次被害の有無
　　　　・再発防止策
　　　　・問い合わせ先情報

（３）ＳＱＬインジェクションの発生
　　検知する方法（かなり難しい）
　　　　・ＩＤＳ（侵入検知システム）、ＩＰＳ（進入防御システム）を利用する
　　　　・Ｗｅｂアクセスログ、ＤＢ監視ログを監視する
　　　　　　特に【ＧＥＴ】でのパラメータ渡しには注意が必要

　　実際には下記の様なことで発覚する
　　　　・身に覚えのないテーブルが作成された
　　　　・利用者から警告メッセージが表示された
　　　　・情報が漏洩しているとの連絡を受ける

　　事後対策
　　　　・Ｗｅｂサイトを即時に停止する（経営層の判断を仰ぐ）
　　　　・攻撃手法やＷｅｂアプリの欠陥を特定する
　　　　　　想定するデータ型、桁数、値の範囲のチエックを確認する
　　　　・脆弱性の排除を行う
　　　　・データ復旧・パスワードの再発行等
　　　　・Ｗｅｂサイトを再開する

（４）バッファーオーバーフローによる情報漏洩
　　下記の様なことで発覚する
　　　　・サーバーがダウンする
　　　　　　サーバーがハングアップする
　　　　　　ブルースクリーンを表示し停止する
　　　　・プログラムが異常終了する
　　　　　　強制終了になる
　　　　　　各種ログに異常終了のログが残る
　　　　・ファイルの改竄
　　　　　　システムファイルが更新される
　　　　　　無関係なファイルが作成される
　　　　・異常な通信
　　　　　　想定していない外部サーバーへの通信が発生する
　　　　　　無関係なサーバーへのアクセスが増加する

　　復旧作業のポイント
　　　　・パッチを適用して脆弱性を修正する
　　　　・必要のないネットワークアクセスを制限する
　　　　・必要のないプログラムをインストールしない
　　　　・作業はネットワークに繋がないで行う

　　　　・サーバーのクリーンインストール（これがベストな対応）

バッファーオーバーフローの仕組み
　　・プログラムがメモリーにデータを書き込む際に
　　　　プログラムが事前に確保したメモリー領域を超えてデータを書き込む
　　　　　　(例題）入力内容を極端に長くして、その途中にプログラム部分を書き込んでおく
　　・書き込まれたデータが悪用される
　　　　プログラムであれば制御が渡りさへすれば、直ぐにでも動き出す

ＳＱＬインジェクションの仕組み
　　・ＳＱＬ検索条件入力の際に【true】になる構文を紛れ込ませる
　　　　条件文のor結合節に必ず【正】となる条件文を挿入する
　　・検索条件を設定しているはずが、必ず【正】になり”条件無し”の状態になる
　　　　select節であれば、無条件に全データをselectしてしまう

インシデント・ハンドリングとは
　　セキュリティー被害への対応策を体系化したもの
　　　　５段階に分類して記述する

　　現状調査、原因究明、被害拡大防止をインシデント・レスポンスと言う
　　　　これだけでは不十分で事前の準備と事後の不備見直しを含んで
　　　　インシデント・ハンドリングと言う

　　準備　被害発生を前提に行動指針を決めておく
　　　　（１）対応方針の策定
　　　　　　被害が発生した場合について、周知徹底のために明文化しておく
　　　　　　緊急度をレベル分けし、レベルごとに行動基準を作成しておく

　　　　　　レベル分けの基準例
　　　　　　　　・被害のタイプによるレベル分け
　　　　　　　　　　外部からの攻撃、内部の不正行為による情報漏洩　等々
　　　　　　　　・被害の重要度によるレベル分け
　　　　　　　　　　被害にあったシステム、漏洩したデータ　等々
　　　　　　　　・必要時間によるレベル分け
　　　　　　　　　　システム停止時間、システム復旧時間　等々

　　　　（２）担当者の任命
　　　　　　誰が中心になって被害に対するかを決めておく
　　　　　　対策チームのメンバーは被害の種類によって変えていく

　　　　　　担当の基準例
　　　　　　　　・ウィルス感染の場合
　　　　　　　　　　現場のＩＴエンジニアで十分
　　　　　　　　・顧客情報または機密情報の漏洩の場合
　　　　　　　　　　上位の意思決定者の存在が不可欠となる
　　　　　　　　　　広報担当や法務担当が必要になる

　　　　（３）連絡体制の整備
　　　　　　緊急時に必要なメンバーを招集できるよう整備しておく
　　　　　　　　連絡先リストを作成する（常に最新の状態に更新すること）
　　　　　　対策窓口を設置し周知徹底させる

　　　　（４）経営層の承認
　　　　　　人員や予算の確保に経営層の承認や関与が必要である
　　　　　　緊急時に関連部署への協力要請等に欠かせない
　　　　　　　　事前に被害額を見積もったり、他の事例を紹介しておく

　　発見　セキュリティー被害かどうかを迅速に確かめる
　　　　（１）セキュリティー被害発生の確認
　　　　　　単純な運用ミスでないかを確認する
　　　　　　　　・大量のシステムエラー
　　　　　　　　・システムの停止や誤動作
　　　　　　　　・警告メッセージの表示
　　　　　　　　・ユーザからの通報
　　　　　　被害の種類を特定する
　　　　　　　　・証拠を収集する
　　　　　　　　・自分の目で確認する
　　　　　　　　・アクセスログの調査

　　　　（２）関係者への連絡
　　　　　　セキュリティー対策窓口に連絡する
　　　　　　窓口担当者は、対処方針に従ってメンバーを招集する
　　　　　　　　弁護士、警察官、プロバイダー等も必要なら招集する

　　　　（３）証拠の保全
　　　　　　メモリー、ディスク等のデータをバックアップする
　　　　　　　　取得時刻を明らかにしておく
　　　　　　特定のデータ（ログも含む）は消失・改竄を防ぐ

　　原因特定と被害拡大防止　被害状況次第ではシステム停止も検討する
　　　　（１）原因の特定
　　　　　　ログ等の情報から原因を分析し特定する
　　　　　　　　セキュリティー侵害の手法を熟知している技術的なスキルが必要になる
　　　　　　　　セキュリティーポリシー等のルールにも詳しい必要がある

　　　　（２）システムの停止
　　　　　　そのまま運用するか、停止するかを決める
　　　　　　　　内部ユーザーや外部ユーザーに連絡する
　　　　　　管理者のユーザーＩＤやパスワードを変更後再発行する
　　　　　　　　関連するシステムの管理者パスワードも変更する

　　　　（３）問題点の解析
　　　　　　原因の特定とシステムの脆弱性を解析する
　　　　　　　　・ＯＳにセキュリティーホールがあった
　　　　　　　　・アプリケーションプログラムのミス
　　　　　　　　・通信ポートが開いていた
　　　　　　　　・ネットワーク設定のミス
　　　　　　商用の解析ツールを使用する
　　　　　　　　日ごろから使用経験を積んでおく

　　復旧　原因を排除し、システムを復元する
　　　　（１）原因の排除
　　　　　　同じ原因で被害に遭うことを防ぐために対策を打つ
　　　　　　　　・外部からの進入の場合には、進入経路を絶つ
　　　　　　　　　　バックドアや盗聴ツールを疑って探し出し手を打つ
　　　　　　　　・ウィルスやワームの進入の場合には、パッチを当てる
　　　　　　　　　　場合によっては、ウィルスソフトベンダーの手を借りなければならない

　　　　（２）防御策の強化
　　　　　　個別に対応する
　　　　　　　　・ＤoＳ攻撃には、ＩＰアドレスでフィルタリングする
　　　　　　　　　　対象アドレスが多すぎる場合は、新しいサーバーに移設する
　　　　　　　　・不正進入の場合には、不要なサービスの停止やパスワードを変更する
　　　　　　　　・内部からの情報漏洩の場合には、アクセス権限や入退室ルールを見直す

　　　　（３）システムの修復
　　　　　　バックアップデータからシステムを復旧する
　　　　　　　　被害の原因を一緒に戻してしまわないようにする

　　　　（４）システムの検証
　　　　　　正常な状態であるかどうかを検証する
　　　　　　　　専門家のツールを使って検証する、ことも考慮しておく

　　　　（５）システムの監視
　　　　　　復旧させた後も、暫くは監視を強化する

　　事後検討　振り返って、今後の被害を防止する
　　　　（１）事後検討レポートの作成
　　　　　　被害の原因や内容、講じた対策、使用したリソース、費用、人員等々をまとめておく

　　　　（２）反省会の実施
　　　　　　上記レポートをレビューする
　　　　　　恒久的な対策等を検討する
　　　　　　　　表面的な原因でなく、根本原因を把握して対応する

　　　　（３）改善策の実施
　　　　　　恒久的な改善策を施す
　　　　　　　　暫定的な改善策に陥らないように工夫が必要
　　　　　　他のシステムへも実施する

　　異なるコンピュータ同士がデータをやり取りするには何らかの取り決めが必要
　　　　ネットワーク構造の設計指針であるＯＳＩ（OpenSystemsInterconnection：開放型システム間相互接続）に基づく

	上位層	第７層	アプリケーション層	ユーザーが直接操作するアプリケーション・ソフトに関する取り決め
		第６層	プレゼンテーション層	通信のためのデータ形式とアプリケーション層で取り扱う データ形式（文字コード、圧縮形式、暗号化方式）を相互に変換するための取り決め
		第５層	セッション層	アプリケーションごとに、送信者と受信者が互いの存在を確認してから データを送りあう（セッションの確立）ための取り決め
	下位層	第４層	トランスポート層	ネットワーク層以下の層で伝送されるデータが確実に受信者に届いている ことを保障するための取り決め
		第３層	ネットワーク層	中継装置（ルーター）を経由して、データを最終的に目的地まで 伝送するための取り決め
		第２層	データリンク層	同じ種類の通信媒体（電線、光ケーブル、無線等）で直接つながっている コンピュータ同士でデータ伝送する際の取り決め
		第１層	物理層	通信媒体に応じた信号の種類・内容やデータの伝送方法に関する取り決め

　　ネットワーク機器とＯＳＩ基本参照モデルの関係
　　　　Ｌ１（物理層）
　　　　　　リピータハブ（電気信号を増幅してデータ伝送する）
　　　　Ｌ２（データリンク層）
　　　　　　スイッチングハブ（ＭＡＣアドレスを参照して特定の通信ケーブルだけにデータを伝送する）
　　　　Ｌ３（ネットワーク層）
　　　　　　ルーター（ＩＰアドレスを参照してネット上の経路を決定しデータを目的地まで届ける）
　　　　Ｌ４（トランスポート層）
　　　　　　ハード機器ではなくソフト（ポート番号による仮想通信経路でアプリを識別する）

　　ＴＣＰ／ＩＰで規定するデータ
　　　　Ｌ４（トランスポート層）
　　　　　　セッション層から伝送データが送られてくる、ＴＣＰヘッダーを付加する
　　　　　　　　送信元と受信元のポート番号、シーケンス番号等々
　　　　Ｌ３（ネットワーク層）
　　　　　　伝送データにＩＰヘッダーを付加する
　　　　　　　　送信元と受信元のＩＰアドレス、ＴＴＬ（TimeToLive）等々
　　　　Ｌ２（データリンク層）
　　　　　　伝送データにＭＡＣヘッダーを付加する
　　　　　　　　送信元と受信元のＭＡＣアドレス、デーア開始符号等々
　　　　Ｌ１（物理層）
　　　　　　電気信号（光信号、電波信号）に変換する
　

ソーシャル・エンジニアリング
　　・人間の心理的なスキを利用して情報を引き出したり実行させたりする

　　・不正アクセスの事前準備として、巧みにパスワードを聞き出す

様々な手法
　　・電話を使ったなりすまし
　　　　上席の管理職になりすましシステム部門に電話し情報を引き出す
　　・トラッシイング（ゴミ箱あさり）
　　　　ゴミ箱の中をあさって、廃棄された書類から重要情報を盗み出す
　　・ショルダー・ハッキング
　　　　入力者の後ろに近ずき肩越しにパスワードを盗み見る
　　・ＷｅｂＳｐｏｏｆｉｎｇ
　　　　サイトのデザイン等を真似して偽のサイトに誘い込む
　　　　紛らわしいＵＲＬを用意して偽のサイトに誘い込む
　　・パスワードを絡め取る
　　　　会員登録の際に入力させたパスワードを別の場所で使う
　　・構内侵入
　　　　同伴者のふりをして侵入する
　　　　訪問のついでに構内を歩き回る
　　・点検作業を偽装する
　　　　点検作業員になりすまし、盗聴器や隠しカメラを仕掛ける
　　　　点検作業員になりすまし、盗聴器や隠しカメラを取り外す
　　・覗き見
　　　　訪問販売員として近づき、さりげなく周囲の情報を除き見る
　　　　席を外したりすると大量の情報が覗き見られる

対策方法
　　・先ず疑って信用しない
　　　　何度でも相手の身元を確認する
　　・情報は管理して放置しない
　　　　身の回りを整理・整頓して盗み易くしない

クラッキング（Cracking）とは
　　コンピュータネットワークに繋がれたシステムへ不正に侵入したり
　　　　コンピュータシステムを破壊・改竄するなど、コンピュータを不正に利用すること

Ｗｅｂアプリケーションの特徴
　　ＷｅｂブラウザーからのＨＴＴＰリクエストに対して
　　ＷｅｂサーバーはＨＴＭＬの形式にしてＨＴＴＰレスポンスを返す

　　非常に簡潔な基本原理から成り立っており
　　　　使い易いメリットが改竄し易いデメリットにもなっている

主なクラッキング手口

	クラキング手口	概要
	クロスサイト・スクリプティンング	スクリプトの入力を許可しているＨＴＭＬフォームの脆弱性を利用して悪意のあるコードを実行させる
	Ｃｏｏｋｉｅの改竄	Ｗｅｂブラウザー側に保存されているＣｏｏｋｉｅの値を変更することで、第三者になりすましたりして不正な値をサーバーに送信させる
	ｈｉｄｄｅｎフィールドの改竄	ＨＴＭＬのｈｉｄｄｅｎフィールドの値を書き換えて、 不正な値をサーバーに送信させる
	強制ブラウジング	リンクを辿るのではなく、Ｗｅｂブラウザーのアドレス欄に意図的なＵＲＬを指定して強制的に特定のサイトを参照する
	セッション・ハイジャック	セッションＩＤを盗み出して第三者になりすます
	不正なコマンドの実行	ＨＴＭＬフォームに悪意のあるコマンドを入力してサーバー側で実行させる
	不正なＳＱＬ文の実行	ＨＴＭＬフォームに悪意のあるＳＱＬ文を入力して サーバー側で実行させる
	バッファー・オーバーフロー攻撃	サーバー側が想定しているバッファ・サイズ以上の大量データを送り付けることでバッファーを溢れさせ、任意のコードを実行することにより、プログラムの制御を乗っ取る