【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
ゆうちょ銀行のプレスリリース

【転載】セキュリティの転換期--IT担当者が目指すべき姿~経営層は「ウチは大丈夫か?」ではなく「セキュリティで心配事はないか?」と聞け!~

it-analyst.jpg

第14回:セキュリティの転換期--IT担当者が目指すべき姿:

今回の対談テーマは「セキュリティ」。2020年は多くの企業がテレワークを急ぎ採用し、そのセキュリティ対策に頭を悩ませた担当者は多いだろう。新しい働き方に合わせたセキュリティ対策について、ガートナーの矢野薫氏に提言してもらった。

----

 本連載は、元ソニーの最高情報責任者(CIO)で現在はガートナー ジャパンのエグゼクティブ プログラム グループ バイスプレジデント エグゼクティブパートナーを務める長谷島眞時氏が、ガートナーに在籍するアナリストとの対談を通じて日本企業のITの現状と将来への展望を解き明かしていく。
 今回のテーマは「セキュリティ」だ。テクノロジーの進化は企業に大きな変革をもたらすとともに、新たな脅威を生み出している。これが企業経営にも影響を及ぼす時代となった。近年はクラウド/モバイルの利用拡大やデジタル化の普及によりITインフラ環境が大きく変化し、情報資産の保護の在り方も根本的に見直すべき時が来ている。特に、2020年前半は多くの企業がテレワークを急ぎ採用し、そのセキュリティ対策に頭を悩ませたIT部門やセキュリティ担当チームは多いだろう。“ウィズコロナ”時代にセキュリティ担当者はどう向き合えばいいのか――新しい働き方に合わせたセキュリティ対策の指針について、矢野薫氏に提言してもらった。

“奥深き”セキュリティの世界に魅了された

長谷島:ガートナーのアナリストになろうと思ったきっかけを教えてください。
矢野:10年以上セキュリティ分野に携わっています。偶然に入ったセキュリティの世界の奥深さにまず驚きました。掘れば掘るほどに面白いことが分かり、「やめられない!」という状態になりました。セキュリティのベンダーに在籍していた頃はテクノロジーの観点でセキュリティを扱い、コンサルティングファームでは戦略の策定やアーキテクチャー設計を行っていました。ガートナーに入社するきっかけは、アナリストの仕事は、ベンダーやコンサルタントとも違う形でセキュリティに向き合えるものだと知ったからです。

矢野薫氏
ガートナー ジャパン リサーチ&アドバイザリ部門 ITインフラストラクチャ&セキュリティ セキュリティ担当シニア プリンシパル アナリスト
入社以前は、外資系セキュリティベンダーにおいてデータ保護、認証、セキュリティモニタリング、リスク管理ソリューションなどを担当。その後、外資系コンサルティングファームにおいて、国内主要企業に対するセキュリティ戦略策定プロジェクトやセキュリティアーキテクチャのグランドデザイン策定のプロジェクトなどに数多く従事。セキュリティについての幅広い知見を基に、今後のセキュリティの在り方について戦略、テクノロジー、運用などさまざまな切り口で提言している。



“情報”や“サイバー”、セキュリティは過渡期

長谷島:非常に興味深いですね。企業のITマネジメントの中で、情報セキュリティが非常に重要な領域として取り上げられてきた歴史は何年くらいでしょうか。
矢野:1990年代後半頃からが「企業セキュリティの黎明期」だと考えられます。ここまで身近になったのは20年くらいですね。
長谷島:この20年ほどでITは加速度的に進化し、その適用範囲や方法も劇的に変化していると思います。その中で、特に昨今の情報セキュリティではどんな領域がホットですか。
矢野:そもそも、セキュリティの黎明期に、私たちセキュリティに携わる人はセキュリティを「情報セキュリティ」と呼んでいました。それは紙媒体の情報がデータ化され、それを守るところから派生しています。2000~2010年くらいまでは「情報セキュリティ=セキュリティ」でした。
 その潮目が変わったのが、2011年頃です。新しく「サイバーセキュリティ」という言葉が出てきました。日本でも大きなセキュリティインシデントがたくさん起き、新聞各紙が一面で一番大きなフォントで「サイバー」という文字を載せたのもその時期ですね。
長谷島:当時の状況は今でもよく覚えています。
矢野:「社内にあるものが、外部からの攻撃にさらされる」ことが突然出てきたのが、この時期に潮目が変わった要因です。そしてこのような、既存の防御をすり抜けてくる外部からの脅威のことを“サイバー攻撃”と呼び始めました。
 そこから「サイバーセキュリティ」という新しい領域が語られるようになりました。例えば、マルウェア対策などの領域が出てきたのも2011年頃です。それ以降、情報セキュリティ対策に、新たにサイバーセキュリティ対策が加わることになったのです。
 そして現在、わたしたちは“情報セキュリティでもなくサイバーセキュリティでもない”企業全体のセキュリティの本当の在り方に立ち戻らなければいけない時期にいると思います。もう一度基本に戻り、デジタル化とともに進めるべき新しいセキュリティを考える過渡期にいるのだと言えます。

長谷島眞時氏
ガートナー ジャパン エグゼクティブ プログラム グループ バイスプレジデント エグゼクティブパートナー
1976年ソニー入社。Sony Electronicsで約10年にわたり米国や英国の事業を担当し、2008年6月ソニー 業務執行役員シニアバイスプレジデントに就任し、同社のIT戦略を指揮した。2012年2月の退任後、2012年3月より現職。この連載では元ユーザー企業のCIOで現在は企業のCIOに対してアドバイスしている立場としてITアナリストに鋭く切り込む。



セキュリティの意思決定はますます難しくなってきた

長谷島:なるほど! 言い換えれば、企業や組織が想定する諸々のリスクがあり、「リスクマネジメント」という枠の中で、セキュリティが非常に大事なコンポーネントとして位置付けられるようになったと理解してもいいのでしょうか。従来はITの一部分だったものが、リスクマネジメントの軸にシフトしつつあると考えてもいいですか。
矢野:そうですね。外的要因としては、企業IT環境の変化が挙げられます。2000年代はIT活用が進んでいたものの、実は環境はまだそれほど変わらなかったともいえます。社外向けのサービス展開や、データ活用への着目が企業として増えましたが、それでも今のようなクラウドやモバイルのような変化はありませんでした。状態としての変化が少ない環境でのセキュリティリスクマネジメントの手法は既に確立されています。
 むしろ今、私たちが見るべきは“動く”ものへの対応です。例えば、「ITをどこでも使う」「オンプレミスからクラウドにシフトする」「攻撃・防御などの手法が変わる」などが起こっています。そうした状況をセキュリティ担当者は、「リスクが大きくなった、多様化した、流動的になった」と捉えます。以前のやり方をそのまま使うことができなくなってきているので、新しい時代のセキュリティが求められているのです。
長谷島:単に守ればいいということではなくて、「守ること=新しいテクノロジーの良い部分を活用できない」という風になってしまうと、企業の競争力やイノベーションなどに大きな影響を与えることになりますよね。一方で、野放しにして負えないレベルのリスクを負うことも許されないという中で、「どこに軸を置いて」「どの範囲までやるのか、やらないのか」を判断するのが難しい時代が来ているということでしょうか。
矢野:はい、以前よりもセキュリティに関する意思決定は難しくなっています。これまで単純に意思決定できていたのは、セキュリティの主目的が「守る」だったからで、「守れるか、守れないか」という二元論でした。現在は「セキュアに使う」ことが主目的です。「どうセキュアにするか」は二元論で語り切れないので、セキュリティは今まで以上に難しくなっています。

テレワーク推進でセキュリティ問題が変質

長谷島:私たちは新型コロナウイルスのいろいろな問題への対応に迫られていますが、その中でテレワークや在宅勤務を利用し始めています。準備状況はともかく、まずはやらざるを得ないというプレッシャーを受けています。多くの企業が一気にテレワークを採用する中で、セキュリティに対する考え方にもさまざまな葛藤があったのではないでしょうか。
矢野:テレワークのような新しい働き方でITが果たす役割は非常に大きいと思います。セキュリティの観点では、テレワークによって突然セキュリティがユーザーの身近な存在になりました。ユーザーからすれば、今までのセキュリティはファシリティーに近い感覚で、身近な存在ではなく会社の中に潜んでいたセキュリティが多かったのです。
 身近になった例としては、パスワードなどのユーザー認証が挙げられます。認証強化が必要となれば、実際にパスワードに加え、追加の認証を実行するのはユーザー自身です。これまでもセキュリティと利便性はセットで語られてきていましたが、コロナ禍によってテレワークが突然始まったことで、この両立が大きな議論を呼ぶようになりました。
長谷島:従来のセキュリティの考え方は、より絶対的な価値観として「守る」があり、そのためにしなければいけないことをルールとして定めてきました。テレワークが進んだことで働きやすさや使いやすさなど、今までセキュリティを考える上であまり重視されてこなかった要件や条件を重視する必要も出てきました。「0(ゼロ)か、1(イチ)」という判断の問題ではなく、両方の程度の問題という非常に扱いづらいテーマになってしまいます。セキュリティ問題のテーマが変質してきたようにも見えますが、いかがでしょうか。
矢野:確かに今までは「二元論」、つまり「トレードオフ」の考え方として「セキュリティを取るか、利便性を取るか」という議論がありました。ファシリティー寄りだった時代のセキュリティは、例えば、あるユーザーのアクセスを制限するには他のユーザーのアクセスも制限するしかありませんでした。しかし時代が変わり、そのようなアクセス制限では業務上困る人も出てきてしまうというわけです。
 現在のテクノロジーを駆使すれば、二元論ではなくて両立することは十分できるようになりました。セキュリティと利便性を両立するための方法や考え方があり、セキュリティ担当者の方も、セキュリティの状態を常にウォッチし続ける新たな活動も必要です。企業がデジタルを軸に顧客サービスの展開や従業員の業務環境を進める上では、もう、「セキュリティと利便性、どちらが先?」という話ではなくなりました。テクノロジーを適切に活用することで、二元論ではない新しいセキュリティのやり方が追及できるようになります。

日本独特の現場担当者の特徴

長谷島:セキュリティのみならず、ITマネジメントでは、良い意味でも悪い意味でもいろいろな所で「日本らしさ」があると思います。二元論的なものから変わりつつある中、セキュリティの世界で日本企業の課題に対する取り組みの特徴、これは変えるべきだという点はありますか。
矢野:良くも悪くも「真面目である」点ですね。
長谷島:IT担当者は真面目な方が多いですよね。
矢野:そうです。概ね真面目ですが、あまりに真面目過ぎてしまうと、弊害もあると思います。IT担当者やセキュリティ担当者はすごく真面目なので、どうにかしてセキュリティも利便性も頑張ろうと毎日一生懸命働いています。頑張り過ぎる一方で、「他社や他部門への頼り方」は慣れていないと思います。
 本来であれば、現場の人は「この部分はCIO(最高情報責任者)に頼もう」となり、CIOも「この部分は経営陣みんなでセキュリティの判断をしていこう」ということを考えるわけですが、現実はなかなかこうはならず、どちらかというとIT部門内で「自分たちでどうにか賄っていこう」というような姿勢が強いように思います。
 しかし、今やセキュリティはビジネスとともにあります。そうした現状においては、ただIT部門や現場の担当者だけが頑張って疲弊するのはいいことではありません。経営側も、IT部門だけに任せずに組織全体としてやるべきことの役割分担を一緒になって考えていく必要があると思います。

「うちは大丈夫か?」のチェーンメール、組織間コミュニケーションの壁

矢野:ほかにも日本らしい風潮は、例えば、「『うちは大丈夫なのか?』チェーンメール」が挙げられます。経営層はセキュリティの専門家ではないので分からない点があるのは当たり前ですが、CEO(最高経営責任者)がCIOに「うちは大丈夫か?」と確認することが多いのです。さらに、CIOからIT担当やセキュリティチームにそのまま「うちは大丈夫か?」という確認が落ちてきます。ここには重要な問題が隠されています。「大丈夫なのか?」という限定的な聞き方なので、現場は「大丈夫」を前提とした話しかできません。
 この点は、聞き方を変えるだけでコミュニケーションが変わると思います。経営陣は、「大丈夫なのか?」ではなくて、「セキュリティで心配事はないか?」と聞くこともできるはずなんです。CIOもIT部門の担当者も毎日真面目に頑張っているけれども、「セキュリティに100%はない」ので心配な点があるのは当然なわけです。「心配なことは何なのか?」と上司が聞いてくれると、セキュリティの本当の問題に関して現場の担当者も話しやすくなります。これでようやく、企業全体でセキュリティの本質論ができるようになります。
 もちろん経営陣が技術的なことを全て理解するのは難しいですが、現場の心配事については把握しておく必要があると思います。日本企業の生真面目さの中で生まれてしまった“組織内のサイロ化”は、言葉を変えるだけでも改善できる余地があるでしょう。
長谷島:他社でセキュリティインシデントが起きると、経営陣は心配になって必ず「うちは大丈夫か?」と聞いてきますよね。彼らは「うちは大丈夫です!」という答えを期待していいますよね。
矢野:そうです。そこで話を落ち着かせようとバイアスがかかってしまうんです。実際にはこのバイアスを外し問題の本質に光を当てる必要があるわけですが、光を当てるためのコミュニケーション技術は、本当は難しいものではありません。そして問題が明らかになって初めてきちんとエスカレーションできるようになるわけです。今後デジタルビジネスを進める上ではなおさら「誰が」「何を」ハンドルするのかをはっきりさせることが重要になります。真面目な日本人気質に合う新しいやり方と光の当て方が大切になると思います。

「二元論」で議論しがちな日本人の悪い癖

長谷島:非常に興味深いですね。日本のITマネジメントは、トレードオフの問題を扱うのが非常に下手だと思います。トレードオフの問題を二元論にすり替えがちで、セキュリティはその典型でしょう。昔から分かっていることは、「完全にセキュアな世界はない」ことです。セキュリティでは“程度の問題”を議論する必要があり、おっしゃったように「何か心配はないか?」という会話をすれば、程度の問題として議論できるようになります。
 セキュリティの重要性が高まると、何かトラブルが発生すればCIOやIT・セキュリティの責任者が腹をくくれば済む問題ではなく、会社のリスクとも直結していきます。経営層もそのレベルでもって腹をくくるしかありません。ところが二元論的なやり方では、現場に対して「大丈夫です」という返答を強いるわけです。その部分を打開するには、お互いを理解して、ここまではリスクを甘受しようという会話や意思決定のプロセスに変わっていく必要があるのではないでしょうか。
矢野:セキュリティはリスクの議論なので、「できる、できない」の議論ではありません。先ほどお話した「程度」の問題であったり、完全ではないセキュリティにおいてどちらを優先するかという「プライオリティー」の問題も出てきたりします。その際は、「誰が」「どの順番で」「どれくらい」について考慮することになりますが、現在はそれらが多様化しています。
 テレワークはその好例でしょう。緊急事態宣言における自粛要請下で、企業が守りたいものは大きく2つありました。「ビジネスを継続したい」ということと、「従業員の健康も守りたい」ということです。「出社させない」「満員電車で通勤させない」という状況でも業務を可能にするためにテレワークが推進されてきました。中には、あまりにも突然始まったのでセキュリティの整備が間に合わず、対策が不十分なケースも出てきました。
 そのような状況を「できる、できない」の二元論では乗り切ることができません。「ビジネスは継続させるが、出社する従業員は最小限にする」「従業員の健康のために出社はさせずテレワークを導入する」「今のIT環境ではセキュリティのリスクが高いのでテレワークの対象範囲を狭める」という“程度”の判断こそが企業に求められます。事業全体に関する意思決定です。こうした意思決定はIT部門だけで負える責任ではありません。以前から言われている「セキュリティは経営課題」の一例だと思います。
矢野氏と長谷島氏は、不十分なコミュニケーションや「二元論」といった思考はちょっとした工夫でより良いものに変化し、組織を適切な方向に動かしていけるとアドバイスする
矢野氏と長谷島氏は、不十分なコミュニケーションや「二元論」といった思考はちょっとした工夫でより良いものに変化し、組織を適切な方向に動かしていけるとアドバイスする

コロナ禍におけるテレワークとセキュリティ対策の進め方

長谷島:新型コロナウイルス対応という意味では、多くの企業が緊急的にテレワークをサポートしたり、諸々の問題に目をつむりながら対応したりしています。今後どこか落ち着いた段階で、どの部分を恒久的な措置として継続するか、緊急対応なのでもう一度見直してルール化する必要があるなどを考えていく必要がありますね。
矢野:はい。例えば、政府が推進してきた「働き方改革」が身近ですが、働き方改革と現在のテレワークの意味合いは違うものだったと思います。今回のように多くの従業員が電話やネットワークなどの技術を使って継続的に社外から仕事をするというものについては、十分な準備ができていた人たちはわずかだったと思います。
 特に多くの企業で準備が不足したのは「ルールブック」を作ることでした。業務を行う上で必須の知識や円滑に行うための注意事項を慌てて定義することは大変だったと思います。恒久的なテレワークにおけるセキュリティ対応としては、明確なルールブックの策定がスタートになるのではないでしょうか。
長谷島:コロナ禍で言えることは、必ず働き方や世界が大きく変わるということです。「会社に行って仕事をする」というのが当たり前ではなくなる世界、仕事や個人によって適切な場所を選べるような柔軟な働き方に向かってこの硬直化した日本が一気に舵を切ろうとしています。そうした変化に耐えられるような仕組みやルールなどを再整備していく必要がありそうですね。
矢野:おっしゃる通りです。既存のテクノロジーを活用すれば、テレワークをある程度実践できることが図らずも証明されました。また、ウェブ会議でもここまではできるという実績もできました。しかし緊急時対応では慌てて環境を整備したので、抜けてしまったセキュリティ対策があるかもしれません。
 この緊急対応で良かった点を挙げると、「セキュリティ面でもちょっとした実証実験ができた」ということだと思います。このようなセキュリティ設定でもユーザーはなんとか耐えられるんだな、これ以上は業務が阻害されるんだなというような実績を得られ、ある意味パイロットができたと考えることができます。恒久的な対応としてのテレワークセキュリティを考える際は、一度気持ちを落ち着かせてルールブックの策定から取り組んでほしいと思います。
長谷島:働き方改革の一部としてのテレワークは、良い部分や悪い部分をトレードオフの問題として議論してきたように思います。そこではなかなか踏み切れなかったけれども、コロナ禍で取り組んでみたら、普通の状況では経験できなかったことを経験できたことが良かったかもしれません。恒久的な対応を進める上で見直しが必要になるとしても、今回強引に背中を押されたたことで、テレワークが加速したことは価値があったかもしれませんね。
矢野:私たち日本人は程度の問題を扱うのが苦手ですから、できる限り議論の対象の範囲を小さく切って明確にすることも大切だと思います。対象の範囲が広すぎたり抽象化したりしてしまうと、具体的な”程度”が、なかなか見えてこないのです。
 先ほど情報セキュリティからサイバーセキュリティへの変遷の話をしましたが、現在はセキュリティの転換期にあると考えています。一つのセキュリティイシューに対して、全員が何らかの形で意思決定に関与していくことになり、それをすぐに実行に移すことが重要になりますが、加えて、今までのIT部門の良さはそのまま引き継いでほしいと思います。今までにない新しいタイプのセキュリティにつながると思います。

セキュリティ業務は「こんなにかっこいい」とアピールすべし

長谷島:日本でセキュリティに携わっている人たちの中で、「セキュリティの仕事に従事することが楽しい」と捉えている人が少ないように思いますが、いかがですか。
矢野:現場の人たちは楽しんでいると思います。ただ、「この頑張りを周りには分かってもらえていない」という悲しみもあります。自分が携わっている仕事の価値や会社への貢献度を社内で理解してもらえているかどうかについて、自信を持っている人は多くないかもしれません。
長谷島:評価される側という受け身な姿勢に甘んじているということですね。でも、セキュリティの重要性や担当者がしていることを正しく伝える努力は必要だと思います。特に経営陣を含めて、マネジメントが正しくセキュリティの問題に対峙することをしないと、セキュリティ担当者の仕事がやりづらくなっていると感じます。他のIT部門も含めて受け身の姿勢から変えていく必要があると思います。真面目なのか、いい人が多いのか、自らをアピールすることに対して非常に不器用だと感じます。何かアドバイスはありますか。
矢野:2019年のガートナーの「セキュリティ&リスク・マネジメント サミット」の懇親会であいさつする機会がありました。その時に、「セキュリティ担当者は、本当はとてもかっこいい仕事をしているのに、かっこいいと思われていないのが悲しい。もっと多くの人にかっこいいと思われるように私も頑張ります」とお話したのですが、なんと会場から拍手が起きました。その後もそれに共感したという方にたくさんお話させてもらいました。恐らくこれが、今のセキュリティ担当者の本音なのだと思います。
 実際、セキュリティ担当者の“かっこいいアピール”、かっこよく見せる技は幾つかあると思います。ダッシュボード風の資料は現場の現状をリアルタイムに見せたり、分かりやすく説明したりすることで、セキュリティ担当者の業務をアピールできますし、経営にも受け入れられやすいようです。しかし、ただ単にダッシュボード風にすればよいということではなく、その際の伝え方にもコツがあります。IT部門は、経営層や他の業務部門の人が日常用いている端的な文系の言葉で自分たちの価値を伝えていく必要があるでしょう。物事を簡単に説明できるようになるための訓練は、今日から準備を進めてもらいたいです。しかも、これにより、セキュリティの問題にちゃんと光を当てることができるという効果も期待できます。それは、物事の本質を捉えないと文系の言葉で説明のしようがないからです。
長谷島:他部門にも理解してもらう努力は必要ですね。私は、マネジメントに携わる読者の皆さんにお願いしたいことがあります。それは、もう少しテクノロジーに関して理解する努力をしてほしいということです。テクノロジー駆動型の世界になっている中、今回のコロナ禍が私たちに何を教えてくれたかというと、働き方改革もワクチン開発や感染者のトレースなども結局全てにテクノロジーが関わってくるということです。
 これだけ社会も企業もテクノロジーに依存する時代になり、その流れはもう止めようがないものだと言えます。テクノロジーを理解するためのもう少しの努力が必要だと思いますね。

今後求められるセキュリティ人材の姿

長谷島:セキュリティのテクノロジーが高度化、複雑化する中で、企業はセキュリティ人材を内製化するべきでしょうか。自前では限界が来ていることもあり得えます。セキュリティのいやらしいところは、規模の大小を問わずリスクは平等であることです。特に規模が小さい組織ではどういう風に考えればいいのでしょうか。
矢野:セキュリティの運用においては、全部ではありませんが、定型的なものがあります。このような定型化できるものについては外部のリソースを積極的に活用することは検討できるものとなりますし、既にたくさんの選択肢があります。ただ、セキュリティは何も定型的なものばかりではありません。プライオリティーに関する議論、程度についての議論など、企業としての意思決定の部分は企業リスクおよびビジネスと直結しているため、残念ながら定型化できず、外部に委ねることはできません。このような非定型のセキュリティ業務を担える人材は内部で育成する必要があるのではないかと思います。
長谷島:本日は貴重なお話をどうもありがとうございました。
バックアップ

【転載】東映ビデオ 約1万件のクレジットカード情報&セキュリティコードお漏らし~想定損害賠償額は8億程度か~

東映子会社のECサイトに不正アクセス カード情報1万件に流出の可能性 - ITmedia NEWS
東映ビデオ クレカ情報流出か - Yahoo!ニュース news.yahoo.co.jp/pickup/6372515: 東映ビデオ クレカ情報流出か - Yahoo!ニュース news.yahoo.co.jp/pickup/6372515

手映画会社東映の子会社「東映ビデオ」は1日までに、映画のDVDなどを販売していたオンラインショップのサイトが不正アクセスを受け、約1万件のクレジットカード情報が流出した可能性があると発表した。
 同社によると、昨年5月から今年5月までに同サイトでカード決済した人のカード番号、名義人の氏名、有効期限、セキュリティーコードが漏れた可能性があるという。
 今年5月11日にカード会社から漏えいの可能性を指摘され同日、サイトを停止。第三者機関に調査を依頼していたという。東映ビデオは「多大なるご迷惑およびご心配をおかけする事態となり、深くおわびします」としている。


バックアップ

【転載】ブラウザにパスワード管理を任せるのはアリ? ~ちなみにトレンドマイクロのパスワードマネージャーはデータ消失したのでおススメしません!!~

ブラウザにパスワード管理を任せるのはアリ? 1PasswordやLastPassみたいな専用ツールのメリットは?

ブラウザにパスワード管理を任せるのはアリ? 1PasswordやLastPassみたいな専用ツールのメリットは? | ギズモード・ジャパン:

ウェブブラウザのパスワード管理機能が便利なので、最近はパスワードを考えたり覚えたりしなくなっちゃいました。でも、たまたまブラウザが使えない状況になると、ログイン画面で立ち往生することも。ほかの方法を考えた方が良いかな。

そもそもウェブブラウジング目的で開発されたウェブブラザですが、さまざまな機能が追加され、今やありとあらゆることに使われる万能ツールになりました。その機能の1つがパスワード管理です。推測されにくいパスワードを生成してくれたり、パスワード漏えいを警告してくれたりする機能まで追加された今、ブラウザを専用のパスワード管理ツール代わりに使うのはアリでしょうか。

ブラウザのパスワード管理機能をチェック

生活のあらゆる側面で各種オンラインサービスに頼り切っている現状を考えると、そうしたサービスへのログインを管理することの重要性は極めて高く、ブラウザのパスワード管理機能が日進月歩するのも当然でしょう。ウェブサイトのログイン情報をすべて記憶し、複数のデバイス間で同期してくれることなどは、あって当然の機能ですね。

「Chrome」「Safari」「Firefox」でアクセスしたサイトでオンラインアカウントを新規作成しようとすると、破られにくいパスワードとして、規則性がない文字列を提案してくれます(いずれ、このパスワード提案機能は「Microsoft Edge」にも搭載されるでしょう)。しかも、パスワード提案はこちらが何もしなくても自動実行されます。新しいサービスへログインしようとしているユーザーに気づいたブラウザが、パスワード入力用フィールドへ候補を自動的に表示します。

xx02Image: Google Chrome

ChromeとSafariはパスワードのチェック機能があり、何度も使い回していると警告したり、推測されにくいと評価したりしてくれます。また、Google(グーグル)のパスワード チェックアップにアクセスするか、macOS版Safariで環境設定メニューのパスワードタブを選ぶか、iOSの設定からパスワードとアカウントを開くかすれば、安全確認しておいた方がよいパスワードを調べられます。パスワードを変える必要が生じた場合に備え、変更用リンクも表示されていて便利です。

FirefoxとChrome、そしてmacOS Big SurおよびiOS 14のSafariは、パスワードが流出したかどうかをパスワード管理画面内で確かめられます。さらに、Firefoxはブラウザと独立して機能するデータ侵害確認ツールも提供していて、Firefox Monitorにメールアドレスを登録しておけば、自分のデータが流出すると知らせてくれます。

モバイルOSのメーカーでもある Google (グーグル)とApple(アップル)は、こうしたパスワード管理機能をそれぞれAndroidとiOSにも入れています。Googleの対応しているAndroidアプリであれば、Googleアカウントをユーザー認証に使って、Chromeに保存しておいた情報で自動ログインできるのです。保存済みパスワードを確認するには、ブラウザでパスワード マネージャーにアクセスしましょう。Androidの設定画面からGoogleを選んでGoogle アカウントの管理をタップし、上部のセキュリティへ移動してパスワード マネージャーを開く方法もあります。

xx03Image: iOS

一方のiOSは、以前から、アプリ用パスワードを保存したうえでユーザーのApple IDと連携させてきました。iOSでアプリにログインしようとすると、SafariやiOSにデータが保存されていれば、以前使ったログイン情報を使うかどうか表示されます。保存済みパスワードなどの情報は、iOSの設定でパスワードとアカウントを開くと確認でき、必要に応じてここで修正も可能です。

このように、ウェブブラウザは多くのパスワード管理機能を備えていて、どんどん機能が追加されています。これでもアカウント情報の安全確保には十分ですが、専用ツールには、もう少しいろいろな機能が備わっています。

専用パスワード管理ツールのできること

パスワード管理に特化したツールは、枚挙にいとまがない状態です。以前から使われてきた1Password、Bitwarden、Dashlane、Keeper、LastPassなどだけでなく、新しいツールもあれやこれや登場し続けています。ここでは各ツールの機能や価格は比べず、ブラウザのパスワード管理機能にはない、専用ツールのメリットを紹介します。

まず、環境を問わず使えることが、専用ツールのもっとも重要なメリットでしょう。使っているすべてのスマートフォン、ウェブブラウザ、PCで情報が同期され、Windows、macOS、iOS、Androidのあいだでパスワードが共有され、特定のデバイスに縛り付けられません。

xx04Image: Dashlane

2つ目のメリットは、家族で使いやすい点です。家族用の料金プランが用意されていることもありますし、パスワードの共有にも適しています。たとえば、あるサイトを子供に使わせる場合や、あるアプリのログイン情報を同僚と共有する場合、専用ツールを使った方がはるかに簡単です。ログイン用パスワード以外にも、防犯システムの解除コードや、Wi-Fiパスワードなどの保存と共有にも使えます。

住所、クレジットカードやパスポートの情報など、大切なデータをたくさん保存しておけるこの機能は、パスワード管理ツールの付加的なメリットです。確かに、ブラウザやモバイルOSにも名前や住所といった情報を自動入力する機能はあります。ただし、パスワード管理ツールの方が、保存できる情報の種類も活用方法も上回っています。

これは、ほかの機能にも当てはまることです。たとえば、強力なパスワードを新規生成する機能はブラウザにも専用パスワード管理ツールにもありますが、専用ツールは生成するパスワードの長さや使える文字種を指定できるなど、操作可能な範囲が広くなっています。これ以外の機能でも、専用ツールはコントロールの幅が広く、選択肢が多い傾向があります。

xx05Image: 1Password

パスワード管理ツールはパスワード管理に特化したツールであるのに対し、ChromeやSafari、Firefox、Edgeは機能盛りだくさんを目指している、という違いがポイントです。グーグルやアップルがパスワード管理とセキュリティを軽視しているわけではないでしょうが、ことソフトウェアに関しては、専用ツールがあるなら使ってみるのが吉です。

専用ツールは余計な道具を増やすようにも感じられるかもしれませんし、月々の支払いが多少増える可能性もあるでしょう。それでも、私たちの経験上こうしたツールを導入する価値はとても大きいと思います。ウェブブラウザの管理機能がどんどん改良されているのも事実ですが、パスワードをしっかり管理したいのであれば、専用ツールが答えです(ちなみに、ブラウザに保存されているログイン情報は、専用ツールにインポートできるはずです)。

【転載】NTTデータがサイバーセキュリティに関係するグローバル動向レポートを公開

株式会社NTTデータNCB

NTTデータがサイバーセキュリティに関係するグローバル動向レポートを公開:

株式会社NTTデータは9月11日、第1四半期(2020年4月〜6月)でのサイバーセキュリティに関するグローバル動向について調査をし、結果を取りまとめたレポートを発表した。
レポートでは、新型コロナウイルス感染拡大によって働き方が変化し利用が増加したZoom(ズーム)に関するセキュリティの問題や、テレワークについてのセキュリティリスク、テレワークで利用されるVPN(社外と社内のネットワークを繋ぐ仮想の専用線)製品の脆弱性を取り上げている。


その他にも情報漏えいや、VPNサービスのパルスセキュアに生じた脆弱性、マルウェアやランサムウェア、この四半期を踏まえた今後のサイバーセキュリティ動向についての予測を行なっている。
新型コロナウイルス感染拡大に伴い、世界中でテレワークが推進されるようになったことでオンライン会議ツールのZoomが一躍脚光を浴びたが、レポートではZoomで発見された脆弱性やユーザーのプライバシー保護に関する問題点、利用する上での注意点についても説明を行っている。 今後のサイバーセキュリティ動向についての予測では、テレワークによってオンラインでのコミュニケーションが普及することで、なりすましや詐欺などの新たなリスクが生まれるため、本人確認や情報の信頼性を確認する方法を向上させる必要性に言及。


他には2020年上半期で約9,000件の脆弱性が報告されているVPN製品の脆弱性を狙った攻撃が増加すると予測していて、該当する製品を利用する際は脆弱性に関する情報を収集し、その都度適切な対応をすることが重要だと説明している。
【関連リンク】 ・サイバーセキュリティに関するグローバル動向四半期レポート(2020年4月~6月)を公開(NTTDATA)

https://www.nttdata.com/jp/ja/news/information/2020/091101/



バックアップ

【転載】東証のシステム障害、原因はまさかの設定ミス!?

富士通社長が謝罪「原因究明に全力」 東証システム障害: 日本経済新聞
東証のシステム障害、原因は自動切換用の設定:

東京証券取引所は、10月1日に株式売買システム「アローヘッド」で障害が発生し、終日取り引きができなくなった問題で、その後の調査結果を明らかにした。

今回の障害では、両現用で動作する冗長構成の共有ディスク装置の1台においてメモリの故障が発生。故障発生時はフェイルオーバーによって1台構成で動作するしくみのはずが、想定通り機能しなかった。

同取引所では、システムを納入した富士通と原因究明を進めてきたが、障害時の切り替え機能において、メモリ故障に起因する障害パターンの場合に、故障検知時の自動切替えが機能しない設定となっていたことが判明したという。

設定を見直すことで、メモリ故障に起因する障害であっても自動切り替えは可能で、原因の判明を受けて東証では10月4日に設定を変更。2台ある共有ディスク装置双方の死活監視機能によって自動切り替えが動作することを確認した。

同取引所では、さらなる原因分析やシステム設定の点検など進めるとともに、再発防止策を引き続き検討するとしている。

20201006_jx_001.jpg

【転載】Magecart攻撃とは

MageCart攻撃で告発された3人が逮捕される – マルウェアガイド

ワーナーミュージックへのMagecart攻撃:

ワーナーミュージックグループの米国オンラインストアがMagecartによるものと思われる攻撃を受けて、カード情報が流出した様です。

www.teiss.co.uk

ワーナーミュージックグループは、今年4月25日から8月5日の間に、ハッカーが米国を拠点とする多くのeコマースWebサイトを侵害し、侵害されたサイトでアイテムを購入したユーザーの個人情報を盗んだことを明らかにしました。
(中略)
カリフォルニア州司法長官に提出されたデータ侵害事件の通知で、ワーナーミュージックグループは今年の4月25日から8月5日の間に、正体不明のハッカーが外部サービスプロバイダーによってホストおよびサポートされている多くのeコマースWebサイトを侵害したと述べました。次に、ハッカーはスキミングコードをWebサイトに埋め込み、サイトのチェックアウトページで訪問者が入力した情報を引き出します。

2020年4月25日から2020年8月5日の間にショッピングカートに商品を置いた後に影響を受ける1つ以上のWebサイトに入力した個人情報は、権限のない第三者によって取得された可能性があります。これにはあなたの名前が含まれている可能性があります、メールアドレス、電話番号、請求先住所、配送先住所、支払いカードの詳細(カード番号、CVC / CVV、有効期限)

(Teiss記事より引用)※機械翻訳


データ侵害通知(カリフォルニア州司法長官室提出



キタきつねの所感

世界第3位の音楽レコーディング会社である、ワーナーミュージックがMagecartの(攻撃と思われる)侵害を受け、カード情報を漏えいした様です。

※Magecartは、MagentoをはじめとするECサイトに攻撃を仕掛けてクレジットカード情報を盗む複数の専門的サイバー犯罪集団(ハッカー)の総称です



Magecartは、Ticketmaster、Britishairways等、規模な大きな会社のECサイトへの攻撃を成功してきており、彼らの代表攻撃例にワーナーミュージックが追加される事になりそうです。



ワーナーミュージックは、全体の漏えい件数を発表していません

※意図的な「非開示」な気がします。Bleeping Computerの影響を受けたECサイト名開示の要求に対しても、ワーナーミュージックのスポークスマンは回答拒否しています。

しかし、「複数のサイト」が攻撃を受けた事をデータ侵害通知に書いていますので、新型コロナの影響が大きな米国で、大手音楽会社のECサイトが、3か月侵害を受けた事を考えると、事件の影響範囲が大きい事が予想されます。



データ侵害通知の内容は以下の通りです。

何が起こったのか?
2020年8月5日、不正な第三者が米国を拠点とする多数の電子商取引の
WMGが運営しているが、外部のサービスプロバイダがホストし、サポートしているウェブサイト。これにより、無許可の影響を受けるウェブサイトに入力された個人情報のコピーを取得する可能性のある第三者
2020年4月25日から2020年8月5日までの間にお客様の個人情報が影響を受けたことを断定的に確認することはできませんが、もしかしたらあなたの取引が危殆化している期間中に発生したものであるかどうかを確認する必要があります。もしそうであったならば、これはあなたをあなたの情報を使用して詐欺的な取引が行われています。


どのような情報が関与しているのか?
2020年4月25日から8月5日までの間に、影響を受けたウェブサイトの1つ以上に入力された個人情報。ショッピングカートに商品を入れた後の2020年は、不正な第三者によって取得された可能性があります。これは以下のような可能性があります。
あなたの名前、電子メールアドレス、電話番号、請求先住所、配送先住所、および支払いカードの詳細(カード番号、CVC/CVV、有効期限)が含まれていました。
PayPalでのお支払いは、この事件の影響を受けませんでした。

(データ侵害通知より引用)※機械翻訳


機械翻訳なので少し読みづらいですが、長い割に、8月5日に検知した事や、侵害の期間と漏えいした個人情報の中身(カード情報が含まれる)以外には、めぼしい情報は開示されていません。

しかし「個人情報のコピー」「ショッピングカートに商品を入れた後」の部分から、商品の清算ページにJavaScriptが仕掛けられ、入力された情報がハッカー(Magecart)に窃取された攻撃であった事が、透けて見えてきます。



当然の事ながらワーナーミュージック側はPCI DSSに準拠していたはずですし、Magecartの攻撃手法についてもある程度警戒はしていたと思います。しかし、現実としては3か月間侵入に気づけなかったのです。



世界的なコングロマリット企業でもハッカーの攻撃を受けてしまう。この意味は大きい気がします。



Magecartの技術が高度であった可能性は別にして、清算ページ(Checkout)周辺にスキマーを仕掛けてカード情報や個人情報を窃取する攻撃に対しては、日本企業も、もっと警戒すべきかと思います。

こうした攻撃が日本のECサイトを襲ってくる可能性を考えると、カード情報非保持(PCI DSS)だけでは守れない、改めてそう感じました。



余談です。セキュリティ会社のGemini AdvisoryがKeeper Magecartグループと呼ばれる新しいハッカーグループ(※注:Magecartは単一では無く複数のカード情報を主に狙うハッカーグループの総称です)のレポートを7月に出しており、570以上のECサイトがスキマーを仕掛けられて被害を出した事が報告されていますが、この中ではMagento CMSが主なターゲットだったと分析されており、ワーナーミュージックもそうであった可能性もあります。



Geminiの記事から引用しますが、Keeperの被害を受けたサイトがMagento CMSを使っていた比率は85.2%にも及びます。

Keeper_img5.png?fit=1024%2C625&ssl=1



Teissの記事では、ワーナーミュージックが攻撃された可能性がある脆弱点について、以下の様に書いています。

"時代遅れのコンテンツ管理システム(CMS)で運用していたり、パッチが適用されていないアドオンを利用していたり、管理者の資格情報が続々と注入されて危険にさらされていたりすると、Eコマースの加盟店はさまざまな攻撃の媒介に対して脆弱になってしまいます。

"過去6ヶ月間、ジェミニチームは、犯罪的にホストされたドメインを使用した悪意のあるコードの単純な動的注入から、Google CloudやGitHubのストレージサービスを利用し、ステガノグラフィーを使用してアクティブなドメインのロゴや画像に悪意のあるペイメントカード盗用コードを埋め込むものまで、何千ものMagecart攻撃を発見してきました。

(Teiss記事より引用)


CMSが古いバージョン・・あるいはCMSにパッチが当たってないというのは、ワーナーミュージッククラスのグローバル企業では「訴訟級」ですので、もう少し周辺を攻められたのかと想像します。例えばメインのCMSではなく、プラグインの脆弱性、あるいは更に洗練された(APT)攻撃を受けて、外部にリンクされた画像やロゴに仕込まれたスキマー経由での侵害という所が怪しいかなと思います。