ログはどうしたら使い物になるのか。 ログを活用するための考え方とは？ ～「宝の山」を「ゴミの山」に変えないために～

Infoscience Corporation

www.infoscience.co.jp info@logstorage.com Tel: 03-5427-3503 Fax: 03-5427-3889

2015年3月5日

インフォサイエンス株式会社 プロダクト事業部

情報漏洩対策の最後の砦「ログ管理」の現実解

Contents

1. インフォサイエンスのご紹介

2. 情報セキュリティとログ

3. 内部脅威とログ

4. 外部脅威とログ

5. ログ管理システム構築の基本

[参考] クラウド環境に於けるログ管理

インフォサイエンス株式会社 概要

設立

1995年10月

代表者

宮 紀雄

資本金

1億円

事業内容

• パッケージソフトウェアの開発

• データセンタ運営

• 受託システム開発サービス

• 包括システム運用サービス

所在地

東京都港区芝浦2丁目4番1号 インフォサイエンスビル

統合ログ管理システム「Logstorage」

導入社数 1,600社

8年連続 シェアNo.1

Logstorage

51.1%

A社

21.2％

B社

8.8％

C社

(7.9%)

D社

(5.3%)

E社

(3.5%)

その他

(2.2%)

情報セキュリティに対する脅威

1位 オンラインバンキングやクレジットカード情報の不正利用

2位

内部不正による情報漏えい

（昨年11位）

3位

標的型攻撃による諜報活動

（昨年1位)

4位 ウェブサービスへの不正ログイン

5位 ウェブサービスからの顧客情報の窃取

6位 ハッカー集団によるサイバーテロ

7位 ウェブサイトの改ざん

8位 インターネット基盤技術の悪用

9位 脆弱性公表に伴う攻撃の発生

10位 悪意のあるスマートフォンアプリ

「情報セキュリティ 10大脅威 2015」/ IPA (2015.2.6)

ログ管理の目的

個人情報保護法

プライバシーマーク

ISO27001/ISMS

経産省/クラウドセキュリティガイドライン

PCI DSS

様々なルールや脅威への対応のために、ログの管理が行われている

金融商品取引法

不正アクセス禁止法

情報セキュリティの最後の砦であるログ管理は、

あらゆる法令・ガイドラインで対応が求められている

マイナンバー/番号法

サイバーセキュリティ基本法

不正抑止

予兆検知

事後調査

情報セキュリティに於けるログ管理 3つの目的

APT/標的型攻撃

個人情報・機密情報漏えい（内部犯行）

情報漏洩事件とログ

漏洩企業 事件発覚

漏洩件数

犯人

事件後の対応策（ログ関連）

A社

2007年

863万件

業務委託先の社員

ログのチェック頻度を高める。

B社

2009年

148万件

社員

(システム部の部長代理)

顧客情報検索のログデータの監視、顧客情報

へのアクセスログの検証強化。

C社

2014年

2,070万件 業務委託先の社員

アクセスログの監視設定の強化。（定期

チェック）

[共通点]

- 犯人は漏洩したデータに対してアクセス権限を持っていた。

- 犯人は情報を外部記憶媒体に保存して持ち出した。(CD-R, USB接続の記憶媒体など)

- 犯人は金に困っていた。

- ファイルサーバやデータベースアクセス等のログは取得されていたが、顧客から問合せがある

まで犯行を見つけることができなかった。

- 事件後、対策の1つとしてログの監視強化を挙げる。

守るべき情報の所在

内部漏洩の典型例

データベース

流出経路

ログ管理システム

ログ送信?

外部記憶媒体

File Server

DB Server

持出し

作業員

（

アクセス権限有り

）

ログ送信

参照

典型的な例

デバイス制御を過信

モニタリング

されていない

ログをそもそも見ていないか、ログを見るための軸を持っていない。

その結果、「抑止」が効いていない。

PC

Mail

Server

Web

Proxy

Server

印刷

複合機

B社 記者会見

Q. 情報をログで管理してチェックすればもっと早く不自然な情報の取得に気付くことができたのでは？

A. 権限を持った者が決まった方法を装って行った場合には、異常を知らせるサインは出なかった。

お客様から問い合わせが何件も重なり始めておかしいと気づいた。

Q. すべての情報をCDにコピーしたのは、不自然な行為ではなかったのか。

A. 結果としては不自然な行為だったが、

絶対にないかと言われれば、ない行為ではない

。それだけを取り

上げて変な行動だと気がつくというのは、管理の問題なのか調査中。

B社 記者会見でのやりとり

・データベースに直接アクセスせず、複数のサーバーを経由して顧客情報をコピーした。

・データベースにアクセス出来る権限は犯人を含め数人しかいなかったが、経由したサーバには数百人が

アクセス可能だった。

・犯人：「

ばれないと思った

」

C社 犯人の犯行・供述

どちらの企業もログ管理は行っていたが、「抑止」が効いていない

住基ネット不正利用とモニタリング

・I市 市民部市民課の職員(50代)が、業務とは関係なく住基ネットを利用し、自らがファンである 有名

タレントの情報を検索。

・

約2時間後、全国の住基ネットシステムを管理するセンターからタレントに関する情報検索があったと

の通報

があったため発覚。その後、職員は懲戒処分を受ける。

・職員：「魔が差した」

事件の概要

「完全な」ログのモニタリングは不可能。しかし、モニタリングしている

事実を継続して示す事により、抑止効果を高めていく他無い。

・N市 市民課の支所の職員(30代)が、業務とは関係なく住基ネットを利用し、有名人2人の情報を検索。

・

翌日、全国の住基ネットシステムを管理するセンターから著名人に関する情報検索があったとの通報

があったため発覚。その後、職員は懲戒処分を受ける。

・市が過去の記録を調査したところ、別の職員(60代)の不正利用(友人10人の情報検索)も発覚。

・2人の職員：「端末を操作する機会がなく、練習した」

内部漏洩 ログ管理の現実解

・「事後調査」のために、必要なログは全て取っておく必要がある。

・しかし、全てのログをモニタリングするのは不可能。

・データを持ち出すのは、権限を持っているユーザ。モニタリング対象を、権限を持つユーザに絞る。

・システム担当とモニタリング（セキュリティ）担当は分ける。

・一発アウトのログだけではなく、業務上発生し得ても漏洩リスクのあるログも捕捉する。

・ログを捕捉したら当該社員に確認を取るなどして「抑止」を図る。

ログモニタリングの対象を絞り、「抑止」に重点を置く

ログモニタリングは性悪説に立った社員の監視？

・個人情報や企業の機密情報など、社内にはカネになりそうなデータが溢れている。

・抑止により「魔が差す」「ばれないと思われる」状況を無くす。

・社員の潔白を証明することにもなる。

「予兆」を見つけ、「抑止」を効かせるログ管理

アクセス件数の閾値設定

- データベースからの取得行数のチェック

- 個人情報が含まれるファイルに対するアクセスを、個人情報件数でチェック

外部への情報持ち出し

- USB接続ログのチェック

- 添付ファイル付きメール送信ログのチェック

- 外部アップロードログのチェック

申請データとログの突き合わせ

- 申請外のアクセスが無いかチェック

相関

チェック

アクセス権を持つ者に対するログのモニタリング例

ログの自動チェック

ルール設定

チェックNGユーザ

に対するヒアリング

ルール改善

NG

このフローを仕組みとして作る

ログモニタリング例／申請外のアクセスを自動検知 [1/2]

運用担当者(外部委託)

システム管理者

（作業承認者）

システム利用者

お客様データセンター

お客様オフィス

システム

利用

③作業・メンテナンス

②申請データ

アップロード

④アクセス

ログ収集

①作業申請

・承認

⑤突合

レポート出力

申請外のアクセスを自動検知

申請外の作業や、休日・平日深夜早朝のアクセスなど、疑わしいログを自動的にリストアップ

ログモニタリング例／申請外のアクセスを自動検知 [2/2]

システム

ユーザID

作業開始時間

作業終了時間

SystemA

suzuki

2012/03/21 10:00:00

2012/03/21 12:00:00

マスタデータ（作業申請）

ログデータ

時刻

アクション

ユーザID

2012/03/21 13:12:31

ログオン

yamada

2012/03/21 14:49:35

ログオフ

yamada

2012/03/21 10:31:23

ログオン

suzuki

2012/03/21 12:38:21

ログオフ

suzuki

システム ユーザID 作業開始時間（申請）

作業終了時間（申請）

ログオン時間

ログオフ時間

判定結果

SystemA

yamada

申請なし

申請なし

2012/03/21 13:12:31

2012/03/21 14:49:35

×

SystemA

suzuki

2012/03/21 10:00:00

2012/03/21 12:00:00

2012/03/21 10:31:23

2012/03/21 12:38:21

×

突合

作業申請と作業ログの突合レポート

事前申請通りの作業が行われているか自動チェック。

判定結果「×」となっているユーザに対しヒアリングを実施。

突合レポート(Logstorageにより自動出力)

運用担当者(外部委託)の

アクセスログ・モニタリング

ログモニタリング例

・申請外の入室、サーバアクセス

・サーバルームの操作端末で外部記憶媒体を使用

・入室していないユーザが端末にログイン

・サーバルームから、ネットワーク上の別サーバ/PCに

ファイルコピー

・サーバルームにて作業後オフィスに戻り外部記憶媒体

を利用

・etc…

データベース

File Server

DB Server

サーバルーム

取得可能なログ

・入退室ログ

・ファイルサーバアクセスログ

・DBアクセスログ

・PC操作ログ

オフィス

ログモニタリング例／振る舞いの組み合わせで検知

行動の組み合わせで検知

作業の組み合わせとして疑わしいログを自動的にリストアップ

「高度標的型攻撃」対策に向けたシステム設計ガイド

(2014年9月)

高度標的型攻撃において、偽装メールやマルウェア感染は、外部からのリモート操作を行うための 通信

経路を確保するための手段に過ぎず、攻撃の核心部は侵入後に外部の攻撃者によって行われる、情報シス

テム（組織内部）への侵入行為による情報の窃取・破壊です。すなわち、攻撃の本質は「感染拡大ではな

く 侵害の拡大！」にあると言えます。

マルウェアに侵入された後の「内部対策」にフォーカス。

早期発見を可能にし、侵害拡大を防ぐ。

サブタイトル：入口突破されても攻略されない内部対策を施す

IPA/「高度標的型攻撃」対策に向けたシステム設計ガイド P.19「攻撃の本質」

システム構成イメージ

ユーザセグメント

感染端末

サーバセグメント

ログ ログ

侵害の拡大

ルータ

Firewall

Internet

Internet

ログ

AD

プロキシ

ファイル

「通常」と異なる通信の流れを捕捉する

DB

ログの統合管理

分析レポート生成

攻撃用サーバ

(C&Cサーバ)

■サーバログ

・サーバが発信元のログ（かつアクセス先がサーバでない）

⇒

サーバがマルウェアに感染している可能性

・短時間に大量に「Logon Failure」が出ている端末

⇒

マルウェアに感染したサーバ/ユーザ端末がドメインアタックを

している可能性

■ユーザ端末ログ

・宛先がサーバでない

・不特定多数のユーザ端末にアクセスしている

・トラップアカウントが使用されている

⇒

ユーザ端末がマルウェアに感染している可能性

ログモニタリング例／マルウェア内部拡散検出

レポート名

レポート内容

ログ取得・分析対象

サーバからクライアントへのアクセス

認証ログ(LogonまたはLogon Failure)の宛先がサーバでないアクセスを発見する。

サーバ

ADへのログオンアタック

クライアント毎のLogOn Failure件数を集計し、大量のアクセス試行を発見する。

サーバ/ユーザ端末

クライアントからクライアントへのアクセス

宛先がサーバでないアクセスを発見する。

ユーザ端末

不特定多数へのアクセス

クライアント毎のアクセス先件数を集計し、大量のアクセス試行を発見する。

ユーザ端末

トラップアカウントを利用したアクセス

ユーザ端末にトラップアカウントを仕込み、当該アカウントを用いたアクセス元を発見する。

ユーザ端末

ADサーバ

乗っ取り

感染端末

拡散・情報取得

感染サーバ

感染端末

【レポート例】

マルウェアの早期検出による侵害防止

分析ポイント

【ログ解析の観点】

■ファイアウォールログ

・プロキシサーバを経由しないアクセス

⇒

接続元端末がマルウェアに感染している可能性

■プロキシサーバログ

・短時間に大量にプロキシサーバへの認証に失敗している端末

・コネクトバック通信を行っている端末

⇒

接続元端末がマルウェアに感染している可能性

ログモニタリング例／マルウェア外部通信検出

レポート名

レポート内容

ログ取得・分析対象

ファイアウォール遮断ログ

Proxyサーバを経由せず、直接外部に80,443ポートで通信を行おうとしたユーザ端末を発見する。

ファイアウォール

プロキシサーバへの認証失敗

Proxyサーバの認証ログを分析し、コネクトバック通信の予兆を発見する。

プロキシサーバ

コネクトバック(*)通信

プロキシサーバ経由の通信を一度切断し、強制切断時に発生するログから、C&Cサーバへの再接続を行うコネクトバック通信を

_{発見する。}

プロキシサーバ

【レポート例】

マルウェアの外部通信を検出

感染サーバ

感染端末

プロキシ

外部通信

ファイアウォール

【ログ解析の観点】

分析ポイント

攻撃用サーバ

(C&Cサーバ)

ログ管理システム構築の基本

ログ管理の前にやっておくべきこと

実現するための課題

・ログはあちこちに点在している。

・ログのフォーマットもバラバラ。ログがつながらない。

・ログの内容が読めない。

ログモニタリングの目標

・策定したルールとログを自動的に突き合わせ、チェックしていく仕組み。(予兆検知と不正抑止)

・インシデント発生時の迅速なログ追跡。(事後調査)

・守りたい情報が何で、どこにあるのかを明確にすること。

・守りたい情報に対し、アクセス権の管理を行うこと。

統合ログ管理システムとは

・ログの「管理」に関わる様々な課題・問題への対応

- サーバ・機器上でログが改ざんされるリスク／ログ保管容量・期間の問題

・ログの「分析」に関わる様々な課題・問題への対応

- ログの可読性／複数ログの追跡性／多様な分析要件

各種認証システム・サーバ

(DB/ファイル/Web/Mail)

ネットワーク機器

(FW/Router/LB)

複合機・プリンタ

PC・デバイス

ログを可視化・モニタリングするための仕掛け

_{統合ログ管理システム}

高圧縮保管

改ざん検出

自動レポート出力

横串・横断検索

アクセス制限

ログ分析・グラフ化

リアルタイムアラート

統合管理されたログ

ログ

ログ

個別のログ管理から統合ログ管理へ

クラウドサービス

入退室管理

ログ ログ ログ ログ ログ

統合ログ管理システム「Logstorage」

ログ収集機能

[受信機能]

・Syslog / FTP(S) / 共有フォルダ / SNMP

[ログ送信・取得機能]

・Logstorage Agent

・Logstorage EventLogCollector

・Logstorage SecureBatchTransfer

ログ保管機能

ログ検知機能

検索・集計・レポート機能

・ポリシーに合致したログのアラート

・ポリシーはストーリー的に定義可能(シナリオ検知)

・ログの圧縮保存／高速検索

・ログの改ざんチェック機能

・ログに対する意味（タグ）付け

・ログの暗号化保存

・保存期間を経過したログを自動アーカイブ

・ログの保存領域管理機能

・ログの検索／集計／レポート生成

・検索結果に対する、クリック操作による絞込み

<Logstorage システム構成>

ログ収集実績

［OSシステム・イベント］

・Windows ・Solaris ・AIX ・HP-UX ・Linux ・BSD

［Web/プロキシ］

・Apache ・IIS ・BlueCoat ・i-FILTER ・squid ・WebSense ・WebSphere ・WebLogic ・Apache Tomcat ・Cosminexus

［ネットワーク機器］

・Cisco PIX/ASA ・Cisco Catalyst ・NetScreen/SSG ・PaloAlto PA ・VPN-1 ・Firewall-1 ・Check Point IP ・SSL-VPN ・FortiGate ・NOKIA IP ・Alteon ・SonicWall ・FortiGate ・BIG-IP ・IronPort ・ServerIron ・Proventia

［クライアント操作］

・LanScope Cat ・InfoTrace ・CWAT ・MylogStar ・IVEX Logger ・MaLion3 ・秘文 ・SeP ・QND/QOH

［データベース］

・Oracle ・SQLServer ・DB2 ・PostgreSQL ・MySQL

［サーバアクセス］

・ALogコンバータ ・VISUACT ・File Server Audit ・CA Access Control

［データベース監査ツール］

・PISO ・Chakra ・SecureSphere DMG/DSG ・SSDB監査 ・AUDIT MASTER ・IPLocks ・Guardium

［メール］

・MS Exchange ・sendmail ・Postfix ・qmail ・Exim

［ICカード認証］

・SmartOn ・ARCACLAVIS Revo

_{［その他］}

・VMware vCenter ・SAP R/3 (ERP) ・NetApp (Storage) ・EMC (Storage) ・ex-SG (入退室管理) ・MSIESER ・iSecurity ・Desk Net’s ・HP NonStop Server …その他

［運用監視］

・Nagios ・JP1 ・Systemwalker ・OpenView

［アンチウィルス］

・Symantec AntiVirus ・TrendMicro InterScan ・McAfee VirusScan ・HDE Anti Vuris

［Lotus Domino］

・Lotus Domino ・Notes AccessAnalyzer2 ・Auge AccessWatcher

［複合機］

・imageRunner ・Apeos ・SecurePrint!

日本国内で利用されているものを中心に

_{250種類以上}

のログ収集実績

【Logstorage アライアンス製品（連携パック）】

Palo Alto Networks

next-generation firewalls

SecureCube / AccessCheck

LanScope Cat

Amazon Web Service (CloudTrail)

CWAT

Sendmail

InfoTrace

Auge AccessWatcher

MylogStar

PISO

i-FILTER

IVEX Logger シリーズ

SecurePrint!

MaLion

Chakra Max

VISUACT

SSDB監査

File Server Audit

使えるログにする為の、最低限の準備

・そもそも何が記録されているかわからない

▲ 操作とログが紐付かない。

・操作や値がコードで記録されている

▲ マニュアルと突き合わせないと意味がわからない。

・複数のログ間で、「ユーザID」などのキー情報の体系が統一されていない

▲ ログを追跡できない。

・何かを判断するための情報が足りない

▲ 部単位でのログ分析や、接続元IPアドレスからの脅威分析などが出来ない。

使えないログの例

ログの可視化／Windowsイベントログ

人間が読んで理解できる形式への変換が必要

日時

サーバ名

アクション

ドメイン名

ユーザ

ファイルパス

ファイル名

成功／失敗

2013-03-01 00:00:00

FS01

ファイル読み込み

infoscience

yamada

D:¥common¥

顧客リスト.xls

成功

2013-03-01 01:00:00

FS01

ファイル書き込み

infoscience

yamada

D:¥common¥

顧客リスト.xls

成功

2013-03-01 02:00:00

FS01

ファイルリネーム

infoscience

yamada

D:¥common

コピー ～ 顧客リスト.xlsx

－

日時

サーバ名

アクション

ドメイン名

ユーザ

接続元ホスト名

接続元IPアドレス

成功／失敗

2013-03-01 00:00:00

FS01

ログオン（ローカル認証）

infoscience

yamada

－

－

成功

2013-03-01 01:00:00

FS01

ログオン（リモート認証）

infoscience

yamada

YAMADA-WORK

192.168.0.1

成功

Windowsイベントログの例

Logstorage 機能

GeoIP

URLカテゴリDB

コードマスタ

ログの可視化／外部データとの連携

外

部

デ

ー

タ

連

携

活用例

組合わせるデータ

様

々

な

ロ

グ

デ

ー

タ

ログと内・外の様々なデータを組合せる事でログ活用の範囲は拡大する

脅威DB

共通IDマスタ

部署毎のログ分析

部署マスタ

ログ中のコード/IDと

メッセージの対応付け

機器によるユーザID体系の

違いを吸収

アクセス先Webサイトの

カテゴリ分析

アクセス元の

国の分析

アクセス元の

脅威の分析

ログ

Logstorage 機能

外部マスタ連携

ログの追跡

ログに対する意味づけ・タグ付け

ログ項目に対して「タグ」付けを行うことで、

異なるフォーマットのログを横断的に扱う

1,カード認証OK ,2014/6/15 08:56,

yamada

山田 太郎,ｶｰﾄﾞ操作記録,ｶｰﾄﾞ:施解錠状態,(01011001)(扉1-1),解錠 入室

入退室

2014/06/15 08:58:27,2131,0,

yamada

,192.168.0.1,PC01,192.168.111.124,SMO01.local,Windowsにログオンしました。

PC認証

qmail: June 15 15:18:57 192.168.0.100 qmail: [ID 748625 mail.info] 1239747357.775176 info msg 322844: bytes 15515 from

<

yamada

@example.com> qp 2924 uid 7791

メール送信

"ora104","192.168.0.1",“

yamada

","ROOT","ORACLEDBCOLLECT",28,"localhost.localdomain","",10,29177,"Query","2014-06-15

13:04:10","2014-06-15 13:04:10",0,"2014-06-15 13:04:10",1,0,0,2,2,223,486,"select * from user where userid=‘admin' and

password="*****“…

DBアクセス

2014-06-15 15:16:20 EventLogCollector: write

yamada

C:¥Data¥list.txt 成功 3143473 3

ファイルサーバアクセス

Logstorage 機能

ログの追跡

いつ?

誰が?

どうした?

何処で?/何に対して?

統合ログ管理システムの導入により、手間のかかるログ収集・管理基盤

を迅速に構築し、モニタリング・ルールの作成に注力する

クラウド環境に於けるセキュリティ

AWS (Amazon Web Service) の例

・AWSの「共有責任モデル」

・OS

・アプリケーション

・セキュリティグループ

・OSファイアウォール

・ネットワーク設定

・アカウント管理

・ファシリティ

・物理セキュリティ

・物理インフラ

・ネットワークインフラ

・仮想インフラ

ユーザの責任で守る

クラウドサービスへの基幹システムを含む社内システムの移行が進む中、

オンプレミスのシステムと同等の高いセキュリティレベルが求められている。

オンプレミス環境のログ管理との違い

・管理コンソールへのアクセスログ

・サービスの生成/起動/停止/削除ログ

・ユーザ管理ログ

・セキュリティポリシー変更ログ

・利用料金ログ

クラウドサービス(AWS/Azureなど)

管理

コンソール

仮想サーバ

・サービス

仮想サーバ

・サービス

仮想サーバ

・サービス

管理アクセス

HTTPS

ユーザの作成・

権限変更

サービスの

生成/起動/停止/削除

利用料金の管理

仮想Firewall

ルール・ポリシー

の設定

ユーザ管理

アラート管理

ユーザ側

管理者

クラウドサービス利用ログの監査

管理コンソール

へのログイン

仮想サーバやサービス上のログだけでなく、

サービスに対する管理アクセスのログ管理も必要

クラウドサービス上のログ取得

・AWS CloudTrail / CloudWatch Logs

インフォサイエンス株式会社 プロダクト事業部

TEL 03-5427-3503 FAX 03-5427-3889

http://www.logstorage.com/

mail : info@logstorage.com

お問い合わせ先・開発元

Logstorage 資料

URL: http://www.logstorage.com/product/product_materials.html

- Logstorage ご紹介資料

- Logstorage によるAWS利用監査・セキュリティ対策

- Logstorage 標的型サイバー攻撃対策レポートテンプレート

- Logstorage 突合レポートテンプレート

その他、ログ活用資料掲載中。

END

情報漏洩対策の最後の砦「ログ管理」の現実解

2015/3/5

インフォサイエンス株式会社 プロダクト事業部

稲村 大介