Microsoft Defender for Endpoint を用いた
OS 更新状況可視化システムの構築
掛井 将平 1) ，守屋 賢知 2) ，齋藤 彰一 1) ，松尾 啓志 2)
1) 名古屋工業大学 サイバーセキュリティセンター
2) 名古屋工業大学 情報基盤センター
kakei.shohei@nitech.ac.jp

Constructing an OS Update Status Visualisation Systemusing Microsoft Defender for Endpoint
Shohei Kakei1) , Masanori Moriya2) , Shoichi Saito1) , Hiroshi Matsuo2)
1) Cybersecurity Center, Nagoya Institute of Technology
2) Information Technology Center, Nagoya Institute of Technology

概要
名古屋工業大学サイバーセキュリティセンターでは，センターの実務者が学内計算機の OS 更新状況を確認する
手段と，計算機の利用者・管理者が OS 更新の要否を確認する手段を提供するために OS 更新状況可視化システムを構築した．構築したシステムを利用して OS 更新状況の傾向を分析したところ，新しいバージョンのリリースにあわせて比較的速やかに OS が更新されている様子が確認できた．一方で，本学の OS 更新の目安である二か月よ
りも古いバージョンの OS を利用している計算機が 140 台前後を推移している様子も確認できた．

より，脆弱性の存在を利用者に知らせることでソフト

1 はじめにウェアの更新を促すことができるが，同時に攻撃者にWindows や macOS，Linux などの基本ソフトウェも脆弱性の存在が知られることとなる．Windows でア（Operating Systems，OS）はハードウェアの抽象化

は，Windows Update を通してセキュリティパッチ

やハードウェア資源のアクセス制御などの計算機の基が提供されており，2023 年上半期には 600 件以上の本的な機能を担っている．計算機上で実行されるアプ

脆弱性が修正*2 されている．これら全ての脆弱性が必

リケーションは OS を介してハードウェアの資源を利

ずしもすぐに悪用されるわけではないが，脆弱性が公用しており，マルウェアや不正アクセスから計算機を開されている状況を鑑みると可能な限り迅速にセキュ保護するには OS のセキュリティ対策が重要である．

リティパッチを適用することが望ましい．しかしなが

例えば，2022 年 3 月ごろに観測された学術機関を標的ら，河田らによる企業・団体勤めの Windows 利用者とした攻撃の事例では，Windows のリモートコードを対象としたアンケート調査 [1] によると，約 41% の実行可能な脆弱性である MS13-098/CVE-2013-3900

利用者が Windows Update の適用を後回しにしておの利用が観測されている*1 ．

り，その主な理由は「業務が忙しい」であった．

IPA が公開する「情報セキュリティ 10 大脅威 2023」

名古屋工業大学サイバーセキュリティセンターでの組織向け脅威の 8 位に「脆弱性対策情報の公開に伴は，計算機のセキュリティのチェックに Microsoft

う悪用増加」が挙げられている．いわゆる，N デイ脆Defender for Endpoint（MDE）を利用しており，日々弱性と呼ばれる脆弱性を悪用した攻撃であり，セキュの CSIRT 活動に活用している．MDE はマルウェア

リティパッチ（修正プログラム）や回避策が公開されなどによる脅威の検出や調査を支援するシステムであてから利用者が対策を講じるまでの期間（N 日）にり，MDE がインストールされた計算機の情報を収集実施される攻撃である．セキュリティパッチの公開にすることもできる．サイバーセキュリティセンターで*1*2

https://www.trendmicro.com/ja_jp/research/23/a/targeted-attack-campaign-earth-yako.html

531

https://msrc.microsoft.com/update-guide/vulnerability

はこれまで，MDE がインストールされた計算機の OS

2.2

MAINS データベースの更新状況を実務者が確認し，更新が必要な計算機の名古屋工業大学情報基盤センターでは，学内ネット

管理者にメールで連絡を行っていた．しかし，OS 更ワーク（LAN）としてキャンパス情報ネットワーク

新状況の集計は手作業であったため月に一回の頻度で（MAINS）を構築し，その運用，保守を行っている．

しか作業できず，更新が必要な計算機の存在を迅速にMAINS には研究室や個人の PC，スマートフォンな

知らせることができなかった．また，日ごとの更新状どが接続され，教育や研究，事務などに活用されてい況を記録できず，OS の更新を依頼後に状況が改善しる．MAINS に接続して，MAINS 内のリソースやイていることを確認できなかった．そこで本稿では，一ンターネットを利用するには計算機の認証が必要であ連の作業を自動化することを目的に開発した OS 更新

り，有線接続の場合は MAC アドレス認証，無線接続

状況可視化システムを説明し，本システムを用いて調の場合は IEEE 802.1X 認証が適用される．MAINS

査した OS 更新状況の結果について報告する．OS 更データベースは MAC アドレス認証で MAINS に接続

新状況可視化システムにより，計算機の管理者は自身する計算機を管理するデータベースであり，MAC アが管理している計算機の OS の更新の要否を，実務者

ドレスを MAINS データベースに登録することで，明は全体の OS 更新状況を確認することができる．

示的な認証なしに MAINS に接続できる．学内に常設される計算機や毎日持参する計算機など，日々の活動

2 関連システムで利用される計算機が登録されている．

本章では，構築した OS 更新状況可視化システムにMAINS データベースに MAC アドレスを登録する

関係する三つのシステムについて説明する．これら三際に，当該計算機の利用者情報を登録する必要がある．

つのシステムが持つ情報を連携することで，どの計算計算機が登録されると，固定 IP アドレスが割り当て

機が，どのバージョンの OS を利用し，誰が管理してられ，MAINS データベース上で MAC アドレス，IP

いるかが分かる．

アドレス，利用者情報を確認できるようになる．今回

2.1 Microsoft Defender for Endpoint

構築したシステムでは，MDE から取得した OS の情

Microsoft Defender for Endpoint（MDE）は，エ

報と利用者情報を MAC アドレスと IP アドレスで対

ンドポイントで動作するセンサを用いて，リスクベー

応付けている．

スの脆弱性検出や修復機能などを提供するセキュリ

2.3

統一データベース

ティソリューションである．エンドポイントにインス

MAINS データベースと同様に，本学情報基盤セン

トールされたセンサが侵害の検出，イベントの調査，

ターでは，教職員と学生の氏名や ID，メールアドレ

セキュリティ分析のための情報などのセキュリティ関ス，所属，指導教員などの情報を管理する統一データ

連情報を収集し，その情報を組織のテナントに送信す

ベースを構築し，その運用，保守を行っている．統一

る．テナントへのアクセスは Microsoft 365 Defender

データベースは，本学構成員に関する情報を統一的に（M365 Defender）ポータルを使用し，ここからエンド管理する基盤であり，その情報は学内システムへのシポイントのセキュリティを管理できる．例えば，検知

ングルサインオンにも利用されている．今回構築したされた侵害の一覧やエンドポイントで発生したイベンシステムでは，計算機の利用者への連絡のためのメー

トのタイムラインを確認できる．

ルアドレスの取得や，利用者が学生の場合にその指導

MDE の特筆すべき機能の一つとして，Advanced
Hunting が挙げられる．Advanced Hunting を利用することで，定期的に収集されているエンドポイン
トの各種情報（OS や OS バージョン，IP アドレス，

教員を検索するために利用している．

3 OS 更新状況可視化システムの構築
3.1

設計方針

MAC アドレス，セキュリティアラートなど）を過去

N デイ脆弱性の脅威を踏まえると，可能な限り最30 日に遡って検索できる．これらの情報はいくつかの新のバージョンの OS を利用することが望ましい．しテーブルで管理されており，Kusto Query Language

かし，個々の計算機の管理者に OS の更新を逐一依頼（KQL）を用いて検索できる．今回構築したシステム

することは作業コストの観点から現実的でなく，管理では，Advanced Hunting を用いて学内の計算機の各者が主体的に OS 更新の要否を確認できる環境を用意

種情報（MAC アドレス，IP アドレス，OS，OS バーすることが望ましい．その上で，一定期間対応されてジョン）を収集している．

いない計算機について，その管理者にサイバーセキュ

532リティセンターから連絡することで，管理者と協働で状況を Pass（更新不要）と判定し，そうでなけれ計算機のセキュリティを確保できる体制の整備を目指

ば Error（要更新）と判定する．また，作成されたす．以上を踏まえて，以下の二つの方針をたてる．

セキュリティ情報は後述する OS 更新状況可視化
モジュールで利用するために，セキュリティ情報• 方針 1：計算機の管理者が OS の更新の要否を確

履歴データベースに日ごとに記録される．計算機

認できることの管理者と利用者は自身の計算機のセキュリティ• 方針 2：一定期間更新されていない計算機の管理

情報を MAINS データベースから確認できる（図者に OS の更新を依頼できること

2）．

方針 1 について，学内の計算機の情報が登録されていOS 更新通知モジュール 本モジュールは，MAIS デー

る MAINS データベースに OS の更新の要否を載せる

タベースに記録されているセキュリティ情報を用ことで，管理者による確認ができる．方針 2 について，

いて，MDE がインストール済みかつ OS の更新

OS のバージョンのリリース日と更新状況のチェックが必要な計算機の管理者に OS 更新通知をメー

日の差から，一定期間以上の古いバージョンの計算機

ルで送信する．MAINS データベースには，計算をリストアップし，その管理者に連絡を行う．計算機

機の情報とその利用者の情報が格納されているの利用者が教職員の場合は，その教職員を管理者とし，が，利用者が学生の場合もある．そのときは，統計算機の利用者が学生の場合は，その学生を監督する

一データベースから主指導教員と副指導教員の情立場のある主指導教員と副指導教員を管理者として連報を取得し，これらを管理者とする．なお，利用絡する．連絡先は，統一データベースの情報を参照す

者が教職員の場合は，その者を管理者とする．管ることで取得できる．

理者と通知対象の計算機の関連付けができたら，また，実際に OS が更新されたかどうかを把握する

統一データベースから取得した管理者の連絡先にには，連絡後に実務者が継続的に OS の更新状況を確認する必要がある．そこで，以下の方針を追加する．

OS 更新通知メールを送信する．
OS 更新状況可視化モジュール 本モジュールは，セキュリティ情報を日ごとに集計し，各種集計値• 方針 3：日ごとの OS の更新状況を時系列で確認の推移や割合をグラフで可視化する．例として，できること「OS のバージョンごとの計算機の台数の推移」や

方針 3 について，方針 1 で MAINS データベースに掲「OS 更新状況が Error となっている計算機の台数

載した情報を日ごとのバックアップを記録しておくこの推移」，「OS 更新状況が Error となっている計とで，OS の更新状況を時系列で確認できる．以上，三算機のバージョンの内訳」などを集計している．

つの方針に従って OS 更新状況可視化システムを構築
する．

3.2

3.3

構築したシステムの実装と処理の流れ

Ubuntu 22.04 の計算機上に，OS 更新状況可視化シ構築したシステムの構成構築したシステムの構成を図 1 に示す．本システム
は三つのモジュールから構成される．

ステムを構築した．各モジュールを Ruby 3.2.2 で実装し，OS 更新状況可視化モジュールの OS 更新状況の可視化部分を Ruby on Rails 7.0.8 による Web ア

セキュリティ情報作成モジュール 本 モ ジ ュ ー ル は ，プリケーションとして実装した．セキュリティ情報履

MDE のインストール状況と OS の更新状況を

歴データベースには Postgresql 15.3 を使っている．

表す情報（セキュリティ情報）を作成する．M365

3.3.1

セキュリティ情報の作成

Defender の Advanced Hunting を利用して，計算本処理では，M365 Defender から各計算機の OS の機ごとにその計算機の「MDE のインストールのバージョンを取得し，OS 更新の要否を判定し，その有無」，「OS のバージョン情報」を取得する．取得

結果をセキュリティ情報として MAINS データベーした情報は，当該バージョンのリリース日から判スに記録する．まず初めに，セキュリティ情報作成

定された OS 更新の要否と合わせて MAINS デー

モジュールが Advanced Hunting により M365 De-

タベースに記録される．セキュリティ情報の作成

fender の DeviceInfo テーブルと DeviceNetworkInfo

は一日一回行われ，その作成日と当該バージョン

テーブルから必要な情報を取得する（Phase A-1）．

のリリース日の差が二か月以内であれば OS 更新

DeviceInfo テーブルからは，OS やそのバージョン情533

Microsoft 365
DefenderThe Internet

OSバージョン

OSバージョン，リリース日

Phase A-1

IPアドレス，MACアドレス，
OSバージョンなど
名古屋工業大学

Phase A-4

Phase A-2

セキュリティ
情報

OSバージョン，リリース日

セキュリティ情報
履歴データベース

MDEインストール済み計算機
Phase A-3

セキュリティ情報

セキュリティ情報作成モジュール

MAINSデータベース

セキュリティ情報，計算機とその利用者の情報

Phase C-1

セキュリティ情報

Phase B-2

OS更新状況可視化モジュール

指導教員の情報OS更新通知モジュール

管理者の連絡先情報

統一データベース

Phase B-3
Phase C-2

Phase B-4

OS更新状況

OS更新通知実務者

セキュリティ情報

Phase B-1

MDEインストール済み計算機の管理者（教職員）

図1

構築した OS 更新状況可視化システムの全体像するようにしている．次に，DeviceNetworkInfo テー
ブルからは，MAC アドレスと IP アドレスの情報を取得する．図 4 に，DeviceNetworkInfo テーブルから必要な情報を取得する KQL を示す．DeviceNetwork-

Info テーブルも DeviceInfo テーブルと同様に，最新の情報だけが記録されているわけではない．そのため，

DeviceId ごとに最新の行のみを抽出するようにしている．また，異なる DeviceId に同じ IP アドレスが紐づいている場合があるため，IP アドレスごとに最新の行のみを抽出するようにしている．以上の操作により取得した両テーブルを DeviceId をキーに結合することで，どの計算機がどのバージョンの OS を利用しているかが分かる．
次に，OS バージョンファイルを用いて，Phase A-1で取得した各計算機の OS のバージョンのリリース日を調べる（Phase A-2）．セキュリティ情報作成モ
ジュールの実行日とリリース日の差が二か月以内であれば OS 更新状況を Pass と判定し，そうでなければError と判定する．
図 2 MAINS データベースの画面（OS が要更新の例）

次に，MAC アドレス，IP アドレス，OS，OS バー
ジョン，OS 更新状況を MAINS データベースに保存

報，MDE のインストール状態などを取得する．図 3

する（Phase A-3）．

に，DeviceInfo テーブルから必要な情報を取得する

最後に，セキュリティ情報作成モジュールの実行日

KQL を示す．DeviceInfo テーブルには，DeviceId ごを名前としてセキュリティ情報履歴データベースにとの最新の情報が記録されているわけではなく，各計

テーブルを作成し，Phase A-3 で記録したデータと同算機から収集された情報が履歴データとして記録されじデータを本テーブルに記録する（Phase A-4）．

ている．そこで，DeviceId ごとに最新の行のみを抽出

534

DeviceInfo | where isnotempty ( OSPlatform ) | where isempty ( MergedToDeviceId )| s u m m a r i z e a r g _ m a x ( Timestamp , ∗) by D e v i c e I d // S e l e c t l a t e s t rows per D e v i c e I d| project DeviceId , DeviceName , OSPlatform , OSDistribution ,OSVersion , OSVersionInfo , OnboardingStatus

図 3 DeviceInfo から OS やそのバージョンの情報，MDE のインストール状態などを取得する KQL

DeviceNetworkInfo | where isnotempty ( IPAddresses ) and isnotempty ( MacAddress )| mv-expand parse_json ( IPAddresses )| extend IPAddress = tostring ( IPAddresses . IPAddress )| where has_any_ipv4_prefix ( IPAddress , ’ 133.68. ’ , ’ 10. ’ )| distinct Timestamp , DeviceId , DeviceName , IPAddress , MacAddress| s u m m a r i z e a r g _ m a x ( Timestamp , ∗) by D e v i c e I d// Select latest rows per D e v i c e I d| s u m m a r i z e a r g _ m a x ( Timestamp , ∗) by I P A d d r e s s // S e l e c t l a t e s t rows per I P A d d r e s s| join ( D e v i c e I n f o | s u m m a r i z e a r g _ m a x ( Timestamp , ∗) by D e v i c e I d| p r o j e c t DeviceId , M e r g e d T o D e v i c e I d ) on D e v i c e I d| where isempty ( MergedToDeviceId )| project DeviceId , DeviceName , IPAddress , MacAddress

図 4 DeviceNetworkInfo から MAC アドレスと IP アドレスを取得する KQL

表1

調査における基礎情報

育用 PC や事務用シンクラ等の情報基盤センター管理

項目

数値

端末を除く），教職員の人数と学生（研究室配属済み）

MDE インストール済み計算機の台数
Windows11
Windows10
macOS

1,970
924
958
88
1,130
2,631

の人数は表 1 の通りである．

教職員の人数研究室配属済み学生の人数

OS 更新状況可視化システムのリリース後のタイム
ラインを表 2 に示す．6/2 に本システムをリリース
し，セキュリティ情報が MAINS データベースに追加されたことを業務掲示板に掲示した．その後，更新状
況の調査用の機能の実装を進めて，8/18 から日ごとの3.3.2 OS 更新通知の送信
本処理では，OS 更新通知モジュールが OS の更新が必要な計算機の管理者に OS の更新を依頼するメールを送信する．まず初めに，MAINS データベースに記録されている計算機のうち，OS 更新状況が Error の計算機とその利用者の情報を抽出する（Phase B-1）．
利用者が学生の場合は，その主指導教員と副指導教員を統一データベースから検索する（Phase B-2）
．最後に，管理者のメールアドレスを統一データベースから取得し（Phase B-3），管理者に OS 更新通知を送信す
る（Phase B-4）．

新を促すために，セキュリティ情報を確認することと更新依頼メールを受信した際には OS の更新を行うことを業務掲示板にてアナウンスした．そして，9/19 に
その時点で OS が二か月以内に更新されていない計算機の管理者宛てにメールによる更新の依頼を行った．
このとき，対象となった計算機の台数は 172 台で，管理者の人数は 88 人であった．

4.2

調査結果

本節では，OS 更新状況可視化システムで得られた
日ごとのセキュリティ情報を用いて，8/18 以降の OS

3.3.3 OS 更新状況の表示
本処理では，OS 更新状況可視化モジュールがセキュ
リティ情報履歴データベースに記録された日ごとのセ
キュリティ情報を取り出し（Phase C-1）
，日ごとに集計した結果を実務者に提示する（Phase C-2）
．集計結
果は，後述する 4 章の図 5 や図 8 などのグラフの形式で提示される．

更新状況の調査結果を説明する．
まず，OS のバージョンごとの利用台数の推移を示す．本学で利用されている様々な計算機のうち，比較的利用台数が多い Windows11 22H2（OS build

22621），Windows10 22H2（OS build 19045），macOS
13 Ventura の結果について，それぞれ図 5，図 6，図 7に示す．なお，実線は執筆時点でリリースから二か月

4 OS 更新状況の調査
4.1

OS 更新状況の記録を開始した．9/11 には，OS の更以内のバージョンを，破線は執筆時点でリリースから二か月以上経過しているバージョンをそれぞれ表し，

概要

3 章で説明したシステムを導入し，MDE インストー
ル済み計算機を対象に OS の更新状況の調査を行った．なお，MDE インストール済み計算機の台数（教535

凡例のカッコ内の数字は当該バージョンのリリース日を表している．また，観測されたバージョンのうち，直近にリリースされた八つのバージョンのみを示している．全体的な傾向として，いずれも特定のタイミ

表 2 OS 更新状況可視化システムのリリース後のタイムライン
日付

内容2023-06-02
2023-08-18
2023-09-11

MAINS データベースにセキュリティ情報の掲載を開始を業務掲示板にてアナウンス
OS 更新状況の記録を開始
セキュリティ情報の定期的な確認と OS 更新依頼メールを受信した際の OS の更新を
業務掲示板にて依頼

OS が二か月以内に更新されていない計算機（172 台）の管理者（88 人）にメールで
OS の更新を依頼

500
450
400
350
300
250

30
25

計算機の台数

200
150
100

20
15
10
5

50
0

集計日
2359 (230914)
2283 (230912)
2134 (230808)
2070 (230726)

2361 (230926)
2213 (230810)

23/09/27

23/09/25

23/09/23

23/09/21

23/09/19

23/09/17

23/09/15

23/09/13

23/09/11

23/09/09

23/09/07

23/09/05

23/09/03

23/09/01

23/08/30

23/08/28

23/08/26

23/08/24

23/08/22

23/08/20

23/09/27

23/09/25

23/09/23

23/09/21

23/09/19

23/09/17

23/09/15

23/09/13

23/09/11

23/09/09

23/09/07

23/09/05

23/09/03

23/09/01

23/08/30

23/08/28

23/08/26

23/08/24

23/08/22

23/08/20

23/08/18

0

23/08/18

計算機の台数

2023-09-19

集計日2215 (230822)
1992 (230711)

図 5 Windows11 22H2（OS build 22621）のバー

6.0 (230921)
4.1 (230621)

5.2 (230907)
4.0 (230518)

5.1 (230817)
3.1 (230407)

5.0 (230724)
3.0 (230327)

図 7 macOS 13 Ventura のバージョンごとの推移

ジョンごとの推移

800

イミングであったが，2134 は 9/19 の時点でリリース

700から二か月以内のバージョンであったため，連絡の対600

象に含まれていなかった．その他の要因として，9/19

500

は週明けのタイミングであり，計算機の再起動により

400
300

OS の更新が進んだと考えられる．

200

3448 (230912)
3208 (230711)

集計日3393 (230822)
3324 (230808)
3155 (230627)
3086 (230613)

23/09/27

23/09/25

23/09/23

23/09/21

23/09/19

23/09/17

23/09/15

23/09/13

23/09/11

23/09/09

23/09/07

23/09/05

23/09/03

23/09/01

23/08/30

23/08/28

23/08/26

23/08/24にバージョンの入れ替わりが開始した．19045.3448 が23/08/22

Windows10 に関して，Windows11 と同様に 9/13

0

23/08/20

100

23/08/18

計算機の台数2 に示したように，9/19 は OS の更新を依頼したタ3271 (230725)
3031 (230523)

図 6 Windows10 22H2（OS build 19045）のバー

増加した一方で，19045.3393 と 19045.3324 が減少した様子が図 6 から確認できる．3448 は 9/12 にリリースされたバージョンであり，リリースと同時に 3393と 3324 から同バージョンへの入れ替わりが始まった

ジョンごとの推移と思われる．入れ替わりの速度の鈍化も Windows11

ングを境に比較的速やかにより新しいバージョンへのと同様に 9/16 から確認でき，その後，9/19 に 3324 か入れ替わりが発生している様子を確認できた．また，らの入れ替わりが進んだ様子が確認できる．3324 はWindows に関しては，入れ替わり発生後，一度そのス

9/19 の時点でリリースから二か月以内のバージョン

ピードが鈍化した後に，再度入れ替わりが進んでいるであり，連絡の対象に含まれていなかったため，週明様子を確認できた．

けのタイミングによる計算機の再起動により OS の更Windows11 に関して，9/13 にバージョンの入れ新が進んだと考えられる．

替わりが開始した．22621.2283 が増加した一方で，macOS に関して，9/8 にバージョンの入れ替わりが22621.2215 と 22621.2134 が減少した様子が図 5 から開始した．13.5.2 が増加した一方で，13.5.1 が減少し確認できる．2283 は 9/12 にリリースされたバージョ

た様子が図 7 から確認できる．13.5.2 は 9/7 にリリーンであり，リリースと同時に 2215 と 2134 から同バースされたバージョンであり，リリースと同時に同バージョンへの入れ替わりが始まったと思われる．9/16

ジョンへの入れ替わりが始まったと考えられる．

ごろに入れ替わりの速度が鈍化した後，9/19 に 2134

次に，OS の更新状況が Error の計算機の台数の推からの入れ替わりが再度進んだ様子が確認できる．表移を図 8 に示す．これは，最低でも二か月の間 OS が

536

180

認できる．一方で，1 年以上前にリリースされたバー

160

ジョンを利用している計算機が 10 台見つかった．こ

140
計算機の台数120のような長期間 OS が更新されていない計算機に関し

100
80ては，利用しているソフトウェアの関係で更新ができ

60ていない可能性が考えられる．

40
20

23/09/27

23/09/25

23/09/23

23/09/21

23/09/19

23/09/17

23/09/15

23/09/13

23/09/11

23/09/09

23/09/07

23/09/05

23/09/03

23/09/01

23/08/30

23/08/28

23/08/26

23/08/24

23/08/22

23/08/20

23/08/18

0

集計日

計算機の台数

4.2 節で示したように，OS の更新状況が Error の計
算機の台数が 140 台（MDE インストール済み計算機

図 8 OS の更新状況が Error の計算機の台数の推移の約 7%）前後を推移していることが本調査で分かっ

35

た．なんらかの理由で，OS が更新されていない計算

30

機が一定数存在しているものと思われる．今回の調25

査では計算機に注目して分析を行ったが，各計算機の20

OS の更新は管理者の責任のもとで行われることを考15

慮すると，管理者ごとに OS 更新状況の傾向を分析す

10

ることが望ましい．その際，情報セキュリティの問題

5
1290–1299

1150–1159

980–989

1110–1119

リリース日からの日数

590–599560–569

500–509

410–419

370–379

320–329

260–269

220–229

190–199

160–169

140–149

120–129

100–109

90–99

70–79

は人の心理が大きく関与することから，管理者の属性
60–69

0

や性格などの要因によって更新状況の傾向に違いが表れることに注意が必要である．
情報セキュリティ対策において，計算機の利用者の図 9 OS 更新状況が Error の計算機の OS のリリー
ス日からの経過日数の内訳

心理的な側面に焦点をあてた研究が行われている．諏

更新されていない計算機の台数の推移を表す．全体的に緩やかに減少しつつも特定のタイミングでの急増減が見られる．調査期間内おける急増は 8/21 と 9/11 の二回，急減は 9/4 直後と 9/19 直後の二回であった．
急増の二回はどちらも特定の OS のバージョンがリリースから二か月経過したタイミング*3 であり，日常的に OS が更新されていなかった計算機の存在が原因であったと考えられる．急減の二回について，後者
はメールによる OS の更新を依頼したタイミングであり，その効果によるものと思われる．一方，前者について，直接的な要因は分からないが，9/2 と 9/3 に一部の棟で計画停電があったため，それによる計算機の再起動が理由の一つとして考えられる．
最後に，OS の更新状況が Error の計算機がどの程度古いバージョンを利用しているかをリリース日からの経過日数ごとに集計した結果を図 9 に示す．最も割合が多かった日数が「70–79 日間」で，次いで「100–109
日間」，「140–149 日間」であった．この結果から，OSの更新を忘れて Error と判定されたが，その後 OS の更新が実施されて，Error が解消されている様子が確*3

5 今後の課題

8/21 は macOS の 13.4.1.0 が 16 台，12.6.7.0 と 11.7.8.0
が 1 台ずつあり，9/11 は Windows10 の 19045.3208 が 30
台，Windows11 の 22621.1992 が 14 台，22000.2176 が 2
台あった．

537

訪ら [2] は，利用者のセキュリティ行動に影響を与える要因を知識，態度，行動を三つのグループに分類し，それら要因から構成される情報セキュリティ行動モデ
ルを構築している．20 代から 50 代までの 400 人を対象とした質問紙調査によりモデルを分析した結果，貢献感と無効感による情報セキュリティ対策における社会的ジレンマの存在を指摘している．社会的ジレン
マを抱える利用者は，情報セキュリティ対策に対する重要性を認識しているものの，自分一人だけが対策を実施してもセキュリティ事故の防止や緩和に繋がるわ
けではないと考える傾向がある．また，セキュリティ
行動の阻害要因とコスト感の影響の分析において，セキュリティ知識が高まるほどセキュリティ対策として実施しなければならないことが増えて，コスト感が上昇することも指摘している．そのため，セキュリティ
知識を高めるだけでなく，具体的な対策手順や実施方法も併せて伝えることが重要と結論付けている．
佐野ら [3] は，行動経済学で用いられている行動変容ステージモデルを参考に，利用者のセキュリティ
対策への意識や実施状況に基づき，利用者を「無関心
期」
，
「関心期」
，
「準備期」
，
「実行期」
，
「維持期」の五つのステージに分類するセキュリティ行動変容ステージ
モデルを提案している．15 歳から 69 歳までのパソコン利用者 1,748 人を対象とした質問紙調査によるモデルの検証を行い，パソコン利用者は無効感の一因子に負の相関があり，貢献感とセキュリティ対策に対する

6 おわりに関心の二因子がステージに正の相関があると分析して本稿では，MDE と MAINS データベースと統一いる．特に，関心とステージ間に強い相関があること

データベースを組み合わせて構築した OS 更新状況可を指摘しており，セキュリティ対策への関心を高める

視化システムの説明と，本システムを使った OS 更新

ようなアプローチがステージの向上に効果的であると状況の調査について報告した．本システムの導入によ結論付けている．また，文献 [4] において，Windows

り，OS の更新が必要な計算機の管理者のみに一か月

Update の実施を促すメッセージの文面やユーザインに一回の頻度で提供していた OS 更新状況を，全てのタフェース（UI），配信タイミングが利用者の実際の利用者と管理者が任意のタイミングで確認できるよう行動を後押しするかどうかをセキュリティ行動変容スになった．

テージごとに調査している．その結果，ステージの向構築したシステムを利用して OS 更新状況の傾向を上には UI デザインの工夫が，ステージの維持には文分析したところ，新しいバージョンの OS に比較的速面の工夫が必要であることを指摘している．

やかに移行している様子が確認できた．一方で，調査

セキュリティ対策ソリューションの適切な利用や安できた計算機のうち，二か月以内に OS が更新されて全なパスワードの運用をはじめとした規約の遵守ないない計算機が約 7% 存在していることが確認でき

ど，複雑化するセキュリティ対策に情報システム利用

た．今後は，OS 更新の実効性を高める方法の検討と者が疲弊してしまう状態を「情報セキュリティ疲れ」

可視化データのさらなる分析を進めて，OS が未更新と呼ぶ．さらにこれが悪化することで，情報セキュリの計算機の台数をより低い水準に抑える．

ティ対策を実施しなくなる「情報セキュリティバーン
アウト」状態に陥ることが知られている．その場合，情参考文献

報セキュリティ対策の施策に対する効果が得られなく[1] 河田 真由子，古川 和快，角尾 幸保，“Windowsなるため，情報セキュリティ疲れ状態の把握が重要でUpdate に関するユーザの行動傾向と環境・心理学あると指摘されている [5]．畑島ら [6] は，情報セキュ的要因の関係の調査”，研究報告セキュリティ心理

リティ疲れの度合いを測定する「情報セキュリティ疲

学とトラスト（SPT），vol. 2021-SPT-43，no. 23，

労度測定尺度」を開発し，本尺度を用いて情報セキュpp. 1–8．

リティ対策を実施することによる疲弊の測定が可能であることを示している．

[2] 諏訪 博彦，原 賢，関 良明，“情報セキュリティ行動モデルの構築―人はなぜセキュリティ行動をし上記既存研究より，利用者の特性によって効果的な情報セキュリティ対策の傾向は異なり，それぞれに適ないのか”，情報処理学会論文誌，vol. 53，no. 9，

pp. 2204–2212，Sep. 2012．

したアプローチをとることが望ましい．このとき，単[3] 佐野 絢音，澤谷 雪子，山田 明，窪田 歩，“セキュに情報セキュリティ対策を指示するだけでなく，情報

リティ行動変容ステージモデルの提案とユーザ要

セキュリティ疲れの悪化に注意して，具体的かつ簡単

因の関係性の分析”，情報処理学会論文誌，vol. 63，に実行可能な手順を提示することが望ましい．上記でno. 9，pp. 1458–1472，Sep. 2022．

挙げた既存研究の知見などを参考に，本学構成員の特[4] 佐野 絢音，澤谷 雪子，山田 明，窪田 歩，磯原 隆

性の把握やその特性に応じた OS 更新状況の提示や更将，西垣 正勝，“OS 更新の促進手法に関する実証

新依頼の方法の検討が今後の課題の一つである．

実験評価”，情報処理学会論文誌，vol. 64，no. 9，

OS 更新の実効性を高める方法を検討する一方で，

pp. 1330–1348，Sep. 2023．

OS 更新状況データの活用も課題である．例えば，4.2[5] 畑島 隆，永井 啓太，谷本茂明，金井敦，“大学生節で述べたように，計算機の OS 更新状況の変化が配の情報セキュリティ疲れの可視化に関する一考察

置場所に起因する可能性がある．そのため，計算機の”，コンピュータセキュリティシンポジウム 2017

配置場所と OS 更新状況データを組み合わせた分析

論文集，vol. 2017，no. 2，Oct. 2017．

ができることが望ましい．また，今回構築したシステ[6] 畑島 隆，谷本 茂明，金井 敦，“情報セキュリティ

ムは可視化の機能に限定して独自の Web アプリケー

疲労度測定尺度 SFS-9 の開発と信頼性・妥当性のションとして実装したため，BI ツールなどを活用した検討”，情報処理学会論文誌，vol. 61，no. 9，pp.

可視化データの解析が今後の課題である．

1472–1485，Sep. 2020．

538