防衛省がサイバーセキュリティ防衛技官募集~公的機関のサイバーセキュリティ担当業務ってどうなんだろう?~

画像
防衛省がサイバーセキュリティ関連業務に従事する防衛技官(係長級)を募集している。

ーー

同省が募集するのは、自衛隊指揮通信システム隊にてサイバーセキュリティ技術に関する知見を活用し、サイバー攻撃等の脅威から情報システム等の防護やサイバーセキュリティに関する人材育成、隊員の能力向上等に係る業務を行う防衛技官(係長級)。

同省では、民間企業、官公庁等にて正社員・正職員として従事した職務経験が2020年10月1日現在で通算13年以上となる、1962年4月2日から1989年4月1日までに生まれた、IPAが示すITスキル標準のレベル3以上またはこれに相当する民間資格を保有する者で、職務経験を通じて体得したサイバーセキュリティに関する知識及び技能を有する者を募集している。

概要は以下の通り。

・スケジュール

募集期間:10月7日から12月10日

第1次試験合格発表:12月18日

最終合格発表:2021年2月1日

・選考方法

第1次試験:書類選考、小論文試験

・採用予定数

若干名

・応募方法

防衛省統合幕僚監部Webサイトから書類をダウンロードし必要事項を記載し郵送。

サイバーセキュリティ防衛技官募集、実務経験13年以上の31歳から58歳(防衛省)

ーー

ということなのだが、業界周辺の見る目は厳しい。

例えば、
とか、

とか、
とか。

防衛省ではないが、公務員つながりで、以前元国税調査官の方から公務員の実態の話を聞いたことがある。

民間企業は現在労働環境の改善が進んでいて残業時間規制とか休日労働規制とかが進んでいるが、公務員はこの辺が全く進んでおらず、民間企業をしのぐブラックな職場環境らしい。

あと、公務員といえば、定期的な人事異動があるが、サイバーセキュリティ担当って典型的なジョブ型になるため、この定期人事異動がキャリアパス形成の観点で結構大きなリスクとなる。

あとは給料が安い。
業界的にこの給与水準だと、奴隷募集と思われても正直仕方がない。
民間企業の係長相当職と同じレベルを求めるのであれば、6-700万位の給与水準にしないと、正直厳しいのかと思う。

一方で、日経新聞の記事にも取り上げられていたように、わが国日本は完全にサイバー防衛後進国となっている。

サイバー部隊の構成員数を比較しても、アメリカ6,000人規模、中国100,000人規模、ロシア1,000人規模、北朝鮮6,800人規模に対して、日本は220人程度である。

対北朝鮮に対しては、経済規模では500倍の差があるにもかかわらず、サイバー部隊構成員数では30分の1しかないという、忌々しき事態に陥っている。

職場環境は悪い、キャリアパスは視界不良、給料は安い、けど国家防衛という非常に大きなやりがいは得られる。

う~ん。ちょっと考えてみるかな。。。

【PPAP撲滅運動大喜利】ハーンは鎌倉幕府に「****」と手紙を送ったが何度も無視され日本に攻め込んだ(転載)



大喜利『パスワード付ZIPファイルは無意味だから止めて』と何度も手紙を送ったが無視されたので攻め込んだ「神風(日本企業特有の空気)」:


新型コロナウイルス感染症(COVID-19/武漢ウイルス)は私たちの生活を大きく変えました。いや、現在進行形で変えている最中かもしれません。これを面倒なことだと思うか、それとも降ってわいた有史以来のチャンス(?)と思うかはその人次第。ならば、これを機に一気に生活を変えるとまではいかなくても「変えることを考えるきっかけの検討」程度でも始められれば、それは非常に大きな一歩なのではないでしょうか。

とはいえ「何を変えるのか」を考える段になると、一体何をどう変えればいいのか戸惑う人もいるでしょう。この際、今まで当たり前だったプロセスをどう効率化できるかを考えてみましょう。つまり、そこから「何を捨てるか」「実はムダだったものは何か」を考えるのです。今回はセキュリティ記者として個人的に「この際捨てるべし!」と考えるものを紹介します。

みんな知ってる「PPAP」を何とかしよう

ここでいうPPAPとは、ピコ太郎さんがミームとして全世界に広げた“ペンパイナッポーアッポーペン”ではありません。PPAPとは、日本情報経済社会推進協会(JIPDEC)の大泰司章氏が取り上げたプロトコルで、皆さんが職場で身近に感じていて、「アレ、本当に効果あるの?」と思っているITしぐさです。

職場から今すぐなくしたい「PPAP」とはすなわち、

  • P:パスワード付きZIP暗号化ファイルを送ります
  • P:パスワードを送ります
  • A:暗号化
  • P:プロトコル
というもの。さて皆さん、心当たりはありましたか。普段職場でメールをやりとりしていると、「PPAP」方式で添付ファイルが送られてくるケースがいまだにあると思います。

一見、このやり方は非常に手軽に実現できる“セキュリティしぐさ”のようでしょう。しかし、実はセキュリティ面でリスクをはらむだけでなく、非効率な部分もあるのです。

例えば、添付ファイルにパスワードがかかっていると、職場で運用されているマルウェアフィルターをすり抜けてしまいます。また、攻撃者がターゲットにした企業のメールを盗聴していた場合、添付ファイルの付いた1通目、パスワードを記した2通目の両方が見られている可能性が高く、そもそも秘匿効果は薄いとされています。

ではなぜ、「PPAP」はなくならないのでしょうか。恐らく、多くの組織では運用ポリシーで推奨されているからではないでしょうか。また、企業のセキュリティを評価する指標に採用されている場合もあるようです。誰が始めたかは分かりませんが「それをやれと言われたから、皆が疑問を差し挟まずに従ってしまう」――PPAPがはびこるのは理由はその程度のはずです。中には、添付ファイルをメールに付けて送信すると自動で暗号化し、パスワードを別送する“PPAP自動化”の仕組みを採用している企業もあるはずです。

PPAPだけではありません。職場にいつの間にか浸透し、誰も疑問に思わないけれど、実は無意味に近い施策――。これこそ、今のタイミングでしか捨てられないものなのではないでしょうか。

では、PPAPを本気でなくしたい場合はどうすべきでしょうか。今のタイミングでメールやファイル保護のシステムを新たに内製する方法は、さすがに現実的ではありません。最も効率的なやり方は、クラウドサービスを使う方法でしょう。電子決裁システムとしてグループウェアを利用できるでしょうし、PPAPに関してはオンラインストレージをフル活用することが解決策になり得るはずです。

そもそも、職場にPPAPが導入された理由の一つは、メールの誤送信対策のはずです。つまり、パスワード付きのファイルを本来送ってはいけない相手に誤って送ってしまっても、2通目のパスワードを誤送信しなければ情報漏えいとはならない……はずです(弱いパスワードであればそうはならないでしょうが)。

クラウドストレージを使った誤送信対策は簡単です。まず、これまでメールに添付していたファイルをクラウドストレージにアップロードします。その上で共有権限を設定し、リンクをメールで適切な相手に送信するのです。万が一間違った送信先にメールを送ったとしても、共有権限をオフにすることで閲覧できなくなります。もっと手軽に送信したい、クラウドストレージ契約するにも時間がかかるというならば、以前の連載記事で紹介した「Firefox Send」を活用するのもいいでしょう。少なくとも、PPAPよりは細かいコントロールが可能になると思います。

【転載】「システムを隠す」ことでセキュリティを高めるのは本当に悪なのか?~”リスク=機会×影響度”で、”機会”に視点を当てた対策を考える~


この記事面白い 「システムを隠す」ことでセキュリティを高めるのは本当に悪なのか? - GIGAZINE gigazine.net/news/20200915-…: この記事面白い

「システムを隠す」ことでセキュリティを高めるのは本当に悪なのか? - GIGAZINE

gigazine.net/news/20200915-…

----

「システムを隠す」ことでセキュリティを高めるのは本当に悪なのか?


システムやアルゴリズムの構造を秘匿することでセキュリティを高める「隠ぺいによるセキュリティ(Security by Obscurity)」は、現代では本質的な安全性を確保できていないとされています。しかし、セキュリティの専門家であるUtku Şen氏は「隠ぺいによるセキュリティは過小評価されている」と指摘しています。

Security by Obscurity is Underrated – Utku Sen - Blog – computer security, programming
https://utkusen.com/blog/security-by-obscurity-is-underrated.html

脆弱性のあるシステムを攻撃者から隠すことでセキュリティを高めようとする「隠ぺいによるセキュリティ」は、ひとたびシステムの構造が外部に漏れると攻撃を防ぐ手だてがないことから、現代では効果のないセキュリティ対策とされています。数多く存在するオープンソースのソフトウェアがセキュリティを担保できているのは、隠ぺいによるセキュリティに頼っていないからと考えられているわけです。

しかし、Şen氏は「隠ぺいによるセキュリティ」は必ずしも悪というわけではないと指摘しています。セキュリティに関するコミュニティ「OWASP」によると、サイバー攻撃のリスクは「リスク=機会×影響度」の式で計算できるとのこと。攻撃がもたらす被害の大きさである「影響度」と、攻撃を受ける可能性を指す「機会」のうち、どちらか一方でも減らすことができればリスクを軽減することができます。式にある2つの要素のうち、機会を減らすためには、セキュリティ機構を層状に構築し、攻撃者が最初のセキュリティを通過しても、他のセキュリティに引っかかるようにする必要があります。

Şen氏は層状のセキュリティ機構のひとつとして、隠ぺいによるセキュリティは有用であると主張。例えば、サーバーへのSSH接続に「デフォルトの22番ポート経由で、『123456』のパスワードを設定しているrootユーザー」を利用している場合、サーバーが総当たり攻撃を受ける可能性は非常に高いですが、使用するポートを22番から64323番に変えて「隠ぺい」することで、攻撃を受ける機会を減らすことが可能であるとのこと。

実際にŞen氏がTwitterで「攻撃対象サーバーのポートが開いているかどうかポートスキャンで調べる際、すべてのポートをスキャンしますか」とアンケートを実施したところ、およそ半数の回答者は「デフォルトのポートしかスキャンしない」と回答しており、ポートを変更するだけで攻撃を受ける機会をおよそ半分に減らせることがわかります。

SSHの例の他にも、コードを難読化したり、ランダムな変数を利用したりしてソフトウェア構造を隠ぺいすることは攻撃に対して有効であるとのこと。また、大統領の移動にはダミーの車が何十台も用意される例のように、サイバーセキュリティのみならず現実の世界においても隠ぺいによるセキュリティは利用されているとŞen氏は指摘しています。




Şen氏は「隠ぺいによるセキュリティは、それだけでは不十分ですが、コスト無しでリスクを減らすことができるセキュリティ層として機能します」と語っています。

【転載】IIJ Technical NIGHT vol.9 | セキュリティアナリストのお仕事──分析、AI、ツール開発



この記事では、講演で使用する資料を公開します。

テーマは「セキュリティアナリストのお仕事──分析、AI、ツール開発」

IIJのSOC(Security Operation Center)での取り組みを紹介します。
サイバー攻撃に対応するため24時間ネットワークを監視するSOC。しかし、武器がなくては日々のセキュリティ・インシデントに立ち向かう事はできません。IIJでは、SOCのアナリストを支援する武器として、一般的に流通している情報やツールのほかに、社内のエンジニアが独自の方法で分析したり、ツールの開発を行っています。

今回はその中から、「インシデントを発見するためのインテリジェンス構築」と「インシデント分析のためのツール開発」における3つの取り組みを、実際にSOCで働いている中の人が紹介します。

講演資料

Session1:あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~

講演者:セキュリティ本部 セキュリティビジネス推進部 セキュリティオペレーションセンター 古川 智也

Session2:セキュリティとAIと私

講演者:セキュリティ本部 セキュリティビジネス推進部 セキュリティオペレーションセンター 守田 瞬

講演者:セキュリティ本部 セキュリティビジネス推進部 セキュリティオペレーションセンター 熊坂 駿吾





【転載】Docker版OWASP ZAPを使用してWebアプリの簡易的な脆弱性診断をしてみた

image.png

Docker版OWASP ZAPを使用してWebアプリの簡易的な脆弱性診断をしてみた | Developers.IO:

こんにちは、CX事業本部の若槻です。

最近Webアプリケーション向けのセキュリティ診断ツールについて調べてみたところ、OWASP ZAPというオープンソースツールが定番としてよく使われているそうです。

今回は、Docker版OWASP ZAPを使用してWebアプリのログインページの簡易的な脆弱性診断を行ってみました。

なぜDocker版を使ったのか

OWASP ZAPにはWindows、Mac、Linuxで使えるインストーラー版およびパッケージ版と、Docker版があります。

当初はMac向けインストーラー版を使おうとしましたが、Macのセキュリティによりインストールできなかったため断念しました。
image.png

よってインストールを要しないDocker版を使うこととしました。

やってみた

今回は次のようなAmplify(CloudFront) + Reactにより実装したログインページを診断対象としました。
image.png

コマンドでDockerイメージowasp/zap2docker-stableをプルします。

% docker pull owasp/zap2docker-stable
Using default tag: latest
latest: Pulling from owasp/zap2docker-stable
423ae2b273f4: Pull complete 
de83a2304fa1: Pull complete 
f9a83bce3af0: Pull complete 
b6b53be908de: Pull complete 
dfa4c0ed9f01: Pull complete 
0d0271dc7f26: Pull complete 
ba10134fb40f: Pull complete 
a5566afd045d: Pull complete 
7b60e2849bd0: Pull complete 
daf051f52216: Pull complete 
3600cd933995: Pull complete 
a1d63c5e9c9f: Pull complete 
86279da9d5e1: Pull complete 
61d20517a689: Pull complete 
b645cc4494b6: Pull complete 
87a41273fa00: Pull complete 
dcd8983ba399: Pull complete 
424fa8727c16: Pull complete 
Digest: sha256:3563ecc53448ad224262ccea185cff8360c999c52d9c4b78630d9344dc1c3fd6
Status: Downloaded newer image for owasp/zap2docker-stable:latest
docker.io/owasp/zap2docker-stable:latest
Docker版ZAPのスキャンタイプにはいくつかの種類がありますが、今回は攻撃および負荷のあるアクセスを伴わない1分間の静的スキャンを実施するBaseline Scanを行いました。次のコマンドで実行が可能です。

docker run -t owasp/zap2docker-stable zap-baseline.py -t <対象ページのURL>
ログインページhttps://example.com/loginに対してBaseline Scanを実行してみます。

% docker run -t owasp/zap2docker-stable zap-baseline.py -t https://example.com/login
2020-09-10 09:03:38,813 Params: ['zap-x.sh', '-daemon', '-port', '38996', '-host', '0.0.0.0', '-config', 'api.disablekey=true', '-config', 'api.addrs.addr.name=.*', '-config', 'api.addrs.addr.regex=true', '-config', 'spider.maxDuration=1', '-addonupdate', '-addoninstall', 'pscanrulesBeta']
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
Sep 10, 2020 9:03:40 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Total of 13 URLs
PASS: Cookie No HttpOnly Flag [10010]
PASS: Cookie Without Secure Flag [10011]
PASS: Cross-Domain JavaScript Source File Inclusion [10017]
PASS: Content-Type Header Missing [10019]
PASS: X-Frame-Options Header Scanner [10020]
PASS: X-Content-Type-Options Header Missing [10021]
PASS: Information Disclosure - Debug Error Messages [10023]
PASS: Information Disclosure - Sensitive Information in URL [10024]
PASS: Information Disclosure - Sensitive Information in HTTP Referrer Header [10025]
PASS: HTTP Parameter Override [10026]
PASS: Information Disclosure - Suspicious Comments [10027]
PASS: Open Redirect [10028]
PASS: Cookie Poisoning [10029]
PASS: User Controllable Charset [10030]
PASS: User Controllable HTML Element Attribute (Potential XSS) [10031]
PASS: Viewstate Scanner [10032]
PASS: Directory Browsing [10033]
PASS: Heartbleed OpenSSL Vulnerability (Indicative) [10034]
PASS: Strict-Transport-Security Header Scanner [10035]
PASS: HTTP Server Response Header Scanner [10036]
PASS: Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s) [10037]
PASS: X-Backend-Server Header Information Leak [10039]
PASS: Secure Pages Include Mixed Content [10040]
PASS: HTTP to HTTPS Insecure Transition in Form Post [10041]
PASS: HTTPS to HTTP Insecure Transition in Form Post [10042]
PASS: User Controllable JavaScript Event (XSS) [10043]
PASS: Big Redirect Detected (Potential Sensitive Information Leak) [10044]
PASS: Retrieved from Cache [10050]
PASS: X-ChromeLogger-Data (XCOLD) Header Information Leak [10052]
PASS: Cookie Without SameSite Attribute [10054]
PASS: CSP Scanner [10055]
PASS: X-Debug-Token Information Leak [10056]
PASS: Username Hash Found [10057]
PASS: X-AspNet-Version Response Header Scanner [10061]
PASS: PII Disclosure [10062]
PASS: Timestamp Disclosure [10096]
PASS: Hash Disclosure [10097]
PASS: Cross-Domain Misconfiguration [10098]
PASS: Weak Authentication Method [10105]
PASS: Reverse Tabnabbing [10108]
PASS: Modern Web Application [10109]
PASS: Absence of Anti-CSRF Tokens [10202]
PASS: Private IP Disclosure [2]
PASS: Session ID in URL Rewrite [3]
PASS: Script Passive Scan Rules [50001]
PASS: Insecure JSF ViewState [90001]
PASS: Charset Mismatch [90011]
PASS: Application Error Disclosure [90022]
PASS: Loosely Scoped Cookie [90033]
WARN-NEW: Incomplete or No Cache-control and Pragma HTTP Header Set [10015] x 6 
 https://example.com/login/ (200 OK)
 https://example.com/login/robots.txt (200 OK)
 https://example.com/login/sitemap.xml (200 OK)
 https://example.com/login/manifest.json (200 OK)
 https://example.com/login/static/css/2.73fa334c.chunk.css (200 OK)
WARN-NEW: Content Security Policy (CSP) Header Not Set [10038] x 2 
 https://example.com/login/ (200 OK)
 https://example.com/login/sitemap.xml (200 OK)
FAIL-NEW: 0 FAIL-INPROG: 0 WARN-NEW: 2 WARN-INPROG: 0 INFO: 0 IGNORE: 0 PASS: 49
診断結果として2つのwarningが検出されました。アラートについての詳細な説明は次のページに記載されています。

今回はレスポンスにCache-ControlContent-Security-Policyなどのセキュリティヘッダーを含めていなかったため、脆弱性のリスクがあると判定されたようです。

今回のような構成でセキュリティヘッダーを追加する場合は次の記事を参考にLambda@Edgeを実装すると良いとのことなので試してみたいと思います。

おわりに

Docker版OWASP ZAPを使用してWebアプリのログインページの簡易的な脆弱性診断を行ってみました。

脆弱性診断というとセキュリティ企業に依頼して有料で行うイメージがありましたが、今回のようなオープンソースツールで簡単に実施できて、しかもちゃんと脆弱性を発見できることを知れたのは良かったです。

なお、AWSに対する脆弱性診断はポリシーに適合している場合を除いて許可されていないため、実施する場合は次のページを要確認の上ご自身の責任で行ってください。

【転載】BitTorrentでダウンロードされたものはI know what you downloadでチェックできる!?

Online Galatta - I know what you download

某所でネットに接続した時に自分のIP見てみたらTorrentでエロ同人誌ダウンロードしまくりだったので悲しい気持ちになった: 某所でネットに接続した時に自分のIP見てみたらTorrentでエロ同人誌ダウンロードしまくりだったので悲しい気持ちになった

I know what you downloadでチェックできる
iknowwhatyoudownload.com

【転載】アメリカ政府は「Emotet」対策でパスワード付きzip添付ファイルのブロックを推奨



「Emotet」対策でパスワード付きzip添付ファイルのブロックを推奨 - 米政府:

2月より一時活動の収束が見られたものの、7月より活動を再開したマルウェア「Emotet」。国内外で被害が拡大しており、米政府機関や米MS-ISACが注意を呼びかけている。

2020-10-08_ci_001.jpg

「Emotet」の通信で用いられたユーザーエージェント

「Emotet」は、感染端末より受信メールなどの情報を窃取。返信に見せかけた偽メールによって受信者を信頼させ、添付ファイルを開かせることで感染を広げている。国内セキュリティ機関も繰り返し注意喚起を行ってきた。

こうした「Emotet」の活動は、国内にとどまるものではなく、海外でも7月から同様の被害が広がっており、米国をはじめ、カナダ、フランス、イタリア、オランダ、ニュージーランドなどで被害が確認されている。

米国土安全保障省のサイバーセキュリティインフラストラクチャセキュリティ庁(CISA)によれば、7月以降、米連邦政府、行政機関などを保護する同庁の侵入検知システムにおいて、「Emotet」に関する感染活動として約1万6000件のアラートを検出したという。

同庁はこれら攻撃における傾向を分析。感染活動には、Wordドキュメントである「.doc」ファイルを添付したメールを利用するほか、コマンド&コントロールサーバと「80番ポート」「8080番ポート」「443番ポート」で通信。特徴的なユーザーエージェントや、意味を持たないランダムな長さのアルファベットによるディレクトリで構成されたURIが含まれていた。

【リンク】

【転載】AWS、新政府共通プラットフォームの運用開始を発表~日本の政府機関のクラウド化が推進か?~


 アマゾン ウェブ サービス ジャパン(AWS)は10月8日、総務省による第二期政府共通プラットフォームの運用が開始されたと発表した。

 今回の政府共通プラットフォームは、政府が掲げる「クラウド・バイ・デフォルト」の原則に基づき、一部を除く府省庁の共通システムと、個別運用する中小規模システムを稼働させるITインフラをクラウド(IaaS)で共通化するもの。前総務大臣の高市早苗氏が2月に、AWSを前提に整備を進めていることを明らかにしていた

 日本政府の採用について米AWS ワールドワイド公共部門および規制産業 バイスプレジデントのTeresa Carlson氏は、「日本の各府省が最新のクラウド技術を活用して高い安全性を確保しつつ、国民中心のサービス提供を加速していくことをご支援できると確信している」とコメントしている。

 同社は、「AWSの顧客は日本にある複数のリージョンを活用した情報システム設計を通じて高い可用性を確保し、耐障害性と事業継続性をさらに高めるとともに、日本全国のエンドユーザーにこれまで以上に低遅延で行政サービスを提供することが可能」と説明する。

 また、執行役員 パブリックセクター 統括本部長の宇佐見潮氏は、「第二期政府共通プラットフォームの支援を通じて、画期的な行政サービスの提供に向けた政府情報システムの刷新に貢献できることを光栄に思う。デジタルガバメント実現に向けた政府各府省のイニシアチブを支援していく」と表明した。

第二期政府共通プラットフォームまでの流れ(総務省資料より)

第二期政府共通プラットフォームまでの流れ(総務省資料より)

【転載】なぜ業務で LINE を使ってはいけないのか

LINE(ライン) - 無料通話・メールアプリ - Google Play のアプリ

なぜ業務で LINE を使ってはいけないのか|rotomx|note:

LINE はユーザー数が 8,400万人、日本人口の約7割が利用しているという巨大なチャットツールです。メールや電話より手軽にコミュニケーションが取れることから、業務連絡にも LINE を使っている会社も多く存在します。

操作性・利便性が高い一方で、LINE を業務利用することは「シャドーIT」という状態にあたり、情報セキュリティ上のリスクを抱えています。

この  note では会社が LINE を業務利用してはいけない理由について解説します。ユーザー数の多い LINE を例として挙げていますが、これは会社で管理ができないツール全般に置き換えることが可能です。シャドーIT全般に対するリスクであり、LINE 自体の危険性を指摘するものではありません。

シャドーIT とは

画像1
会社には多くの社内ITツールがあります。例えば Microsoft 365(Word、Excel、PowerPoint など)や、G Suite(Gmail、Google スプレッドシート、Google ドライブなど)、Slack 、Zoom などです。
これらは主に 組織の情報システム部門がライセンスの購入・割当を行い、アカウントをメンテナンスし、監査ログを取得しており、会社によって「管理」されています。

一方、個人的に利用しているツールやサービス、個人で購入・契約しているライセンスなど会社が把握・管理せず業務利用される「IT」をのことをシャドーITと呼びます。LINE や Facebook Messenger、最近だと Discord などが使われていることもあります。
当然それぞれの「管理」は個人に委ねられているため、会社として「管理」できません。

では会社として「管理」できないと何がダメなのでしょうか。

ライセンスの管理を行えない

画像5
社内ITツールは、情報システム部門が組織に最適なライセンスを必要な数だけ購入し、必要な社員に対して割当を行っています。LINE に関してはライセンスという概念はありませんが、有償ソフトウェアにおいてライセンスを適切な数購入せず、複数人で使い回すことが不正利用となることもあります。

また「個人利用」「学生・コミュニティ利用」は無料でも、「法人(商用)利用」が有償、または別途契約が必要というケースもあります。無料のツールだと思って業務で利用していたら意図せず不正利用してしまっている、というケースもあります。

アカウントの管理を行えない

■ アカウントの停止ができない

画像3

社内ITツールは、社員の入社や部署異動、特定のワークフローでの申請によって、アカウントをメンテンスしています。社員が退職、または休職すると、その人が利用していたアカウントは直ちに停止されます。

メールやチャットツールでの社内連絡、顧客・取引先との連絡には多くの機密情報が含まれています。これらの情報を退職者が閲覧できてはなりません。アカウントが停止されることで、退職者アカウントからはメールやチャットツール、ファイルストレージなどにアクセスすることができなくなり、社外秘などの機密情報の持ち出しや、意図しない情報流出を防ぐことができます。

しかし、社内連絡や顧客・取引先との連絡が LINE などの個人ツールで行われていた場合はどうでしょうか。LINE アカウントは個人で作成し管理しているもので、退職時に情報システム部門がアカウントを停止することができません。退職後もその人の LINE には機密情報が残り続けます。

■ 紛失・盗難に対応できない

画像2

LINE を利用しているスマートフォンを紛失、または盗難の被害にあってしまった場合はどうでしょうか。会社支給の端末であれば、MDM(モバイルデバイス管理)がインストールされており、情報システム部門からリモートでのロックや、ワイプ(初期化)をすることができます。個人所有の端末で LINE を業務利用している場合、リモートでのロック、ワイプを行うことができず、情報流出に繋がる恐れがあります。

Slack や Gmail を個人所有の端末にインストールし、ログインすることを許可している組織も多いと思います。これらのアカウントは情報システム部門で管理をしているため、紛失・盗難の申告を受け次第アカウントを停止し、ログインできなくすることで情報を守ることができます。

■ パスワードをリセットできない

画像4

最近はSSO(Single Sign On)によって、社内ITツール個別でパスワードを持っているケースも少なくなってきていますが、パスワードを忘れてしまった、何度も間違えてロックされてしまった、と情報システム部門に問い合わせたことが一度はあるのではないでしょうか。
社内ITツールであれば、管理者からパスワードをリセット(初期化)したり、ロックを解除することが可能です。一方、LINE など会社で管理できないITツールの場合は、自分自身でパスワード再発行の手続きを踏む必要があります。

■ 誤送信のリスクがある

画像7

プライベートで利用しているアカウントを業務利用している場合、社内連絡や、顧客・取引先に送るはずのトークやファイルを誤って友人など関係外の人へ送信してしまい、情報流出してしまうリスクがあります。

とくに LINE の表示名は本名フルネームではなく、ニックネームや名字だけ、名前だけといった場合も多く誤送信リスクが高いです。

■ 年齢確認が行えない

画像9

これは LINE 特有の話です。個人所有の端末でプライベートのアカウントを使いたくないので、会社支給の端末に LINE をインストールして業務用 LINE アカウントを作りたい、というケースです。

LINE は子どものトラブル防止のため、年齢確認を行わないと全ての機能を利用することができません。年齢確認は通信キャリアを通して行われます。

Softbank であれば my Softbank にログインにする必要がありますが、このログイン ID とパスワードは情報システム部門など管理者しか知りえないため、自身で年齢確認を行うことはできません

監査ログを取得できない

画像6

社内ITツール上で行われている情報は各組織のポリシーにより、一定期間ログが取得・保管されています。常に監視をしているわけではありませんが、内部不正の疑いがあるなど有事の際には、ログの内容を確認することがあります。

とくに LINE の場合、プライベートでも利用しているツールであるためメールよりも心理的な距離が近くなり、公私の区別がつきにくくなります。上司や顧客・取引先から休日など業務時間外にも連絡がくる、パワハラやセクハラなどのハラスメント行為が行われる恐れもあります。会社で管理している社内ITツールであればこれらも全て監査ログに残るため、社員を守ることができます

おわりに

上記の通り、LINE などの個人ITツールを業務利用する「シャドーIT」は多くの情報セキュリティ上のリスクを抱えています。これらは情報システムの専任者のいないスタートアップ企業や、急成長したベンチャー企業、少人数の店舗などで内部統制が追いついておらず、起こりうる状態です。

本来は全社員が利用できるメールを使って連絡を使うことが理想ですが、メールより手軽にコミュニケーションを取りたい、という思いで LINE での連絡を希望する顧客・取引先もいます。
これに対しては LINE WORKS など、情報システム部門で管理が可能な社内ITツールを検討しても良いと思います。

シャドーIT対策は闇雲に利用を禁止するだけでは、いたちごっこになりがちです。社員は個人ITツールを利用する前に情報システム部門へ相談すること、情報システム部門はそのリスクを説明した上で、適切な社内ITツールを展開することが求められると思います。

【転載】ドコモロ座と並んで話題沸騰中の「mijica」不正利用。個人的にはこんなサービスに20万人もの会員がいたことが驚きDEATH



ゆうちょ銀の「mijica」で新たな不正か カードが届く前に番号を盗み商品購入 - ITmedia NEWS:

ゆうちょ銀行は10月6日、プリペイド機能付きのVISAデビットカード「mijica」について不正に作成・利用された疑いのある事例が新たに3件見つかったと発表した。

 本人に成り済ましてmijicaを発行し、カード番号などを特定した上で、カードが届くまでの間にECサイトで利用する手口だった。9月23日までに判明した不正送金とは異なる手口。このうち2件ではECサイトで計約16万円の利用があったという。ゆうちょは既にカードの利用を停止しており、不正利用が確定次第、全額補償する方針。

photo
サービスを停止しているmijica
ゆうちょは9月23日に発表したmijicaの不正送金を受けて、内部のリスク検証を実施。検証で指摘された「不正に入手した口座情報を利用したmijicaカードの作成・利用の可能性」について、カードの申込日からユーザーの手元に届くまでの間に利用があったカードを調査したところ、不正が疑われる事例が見つかったという。調査期間は7月1日から10月3日まで。

 利用者の口座情報を不正に取得した第三者が、本人に成り済ましてmijicaの新規発行を申請した可能性があるという。カードは本来の利用者の住所に届くが、発行から到着までに約6日間かかっていた。専用サイト上でカードの下4桁の番号と有効期限を確認できることから、第三者は何らかの方法で全16桁のカード番号を特定し、本来の利用者にカードが届くまでの間に買い物を繰り返したとみられる。カード番号の特定方法については調査中という。

 ゆうちょは10月3日に専用サイトを停止。新規のmijica発行もすで停止していることから「新たな被害は発生しない」としているものの、今後、調査の対象期間をさらに遡り、同様の事案がないか調査する方針。

photo
ゆうちょ銀行のプレスリリース