こんにちは、Japan Digital Designでセキュリティをやっている唐沢です。ネタもないのにJDD Advent Calendarに手を上げてしまったので、こちらの記事を書いています。
JDD Advent Calendar) https://adventar.org/calendars/5160

平井デジタル改革相の自動暗号化ZIPファイル廃止宣言を皮切りに、パスワード付きファイル送信の問題がにわかに盛り上がりを見せています。せっかくですので、セキュリティに携わる者としてこのトピックを取り上げたいと思います。ここでは以下のように用語を定義します。

パスワード付きファイル(PPAP)とは

この記事では、情報処理学会の座談会で紹介されていた定義を採用させていただきます。ちなみにPPAPの由来は、「(P)パスワード付きZIPファイルを送付 → (P) パスワードを送る → (A)暗号化 → (P) プロトコル」の略です。

1 通目にZIP を暗号化して添付ファイルを送って，2 通目でパスワードを送るというやり方です．2 つの軸があって，パスワードを同じ経路を送るか，違った経路で送るか．もう1 つは，すべての添付ファイルを暗号化するか，自分で判断して特定のファイルだけ暗号化するか．自動で添付ファイルを暗号化して送るソリューションを使うと，すべての添付ファイルを暗号化し，同じ経路でパスワードも送信することになる．これを，この議論ではPPAPと呼びたいと思います．

いまさらPPAPについて何を書くのか

世の中では「何故PPAPが生まれたのか」「何故やめるべきなのか」「どうすればやめられるのか」といった議論が花盛りなわけですが、そういった議論は他に譲りたいと思います。「PPAPはどういった脅威から何を守ろうとしていたのか」ということを考えたいと思います。それを考えることによって、今後PPAPをやめていく多くの組織で「安全に」やめるための参考になると思うからです。

PPAPは何を守ろうとしていたのか

PPAPが守ろうとしていたもの、それはメールによって送信されるファイルです。メールに添付したファイルを暗号化するのは、そのファイルを情報セキュリティ上の脅威から保護するのが目的でしょう。外部組織と共有するファイルと言い換えても良いかもしれませんが、ここではメールで送られるファイルのみを対象にしようと思います。では、メール送信するファイルに対する情報セキュリティ上の脅威とは何でしょうか？それを明らかにすることで、「PPAPはどういった脅威から何を守ろうとしていたのか」を明確にできるはずです。

STRIDEで脅威を分析

情報セキュリティ上の脅威を明らかにするために、すなわち脅威分析（Threat Modeling）を行います。その手法は様々ですが、ここでは脅威を洗い出す手法として代表的なSTRIDEを採用することにします。STRIDEは、Loren Kohnfelder 氏と Praerit Garg氏によって開発された脅威分析手法で、例えばMicrosoft社では同社の製品をセキュアに開発するために活用されています（参考）。
具体的には、脅威を以下の6つの観点で洗いだします。この観点を網羅的に検討することで漏れが少なくなると言われています。それぞれの観点の頭文字をとって「STRIDE」と名付けられています。
1. Spoofing / なりすまし
2. Tampering / 改ざん
3. Repudiation / 否認
4. Information Disclosure / 情報漏洩
5. Denial of Service / サービス妨害
6. Elevation of Privilege / 権限昇格

ファイルの外部共有に対する脅威分析

では、さっそく脅威分析をしてみましょう。本来はデータフロー図(Data Flow Diagram)を作成して要素ごとに分析するなど細かい手順があるのですが、今回は簡易的にやってみます。STRIDEの6つの観点に沿って、メールでファイルを送信する際にどういった脅威がありうるかを整理します。
具体的な検討の前に、以下の前提を置きたいと思います。

• メールのシステムは信頼できるものとします。「メールシステムが乗っ取られる」等を挙げるときりがないためです。
• 実際にPPAPによってこれらの脅威から守られていたかどうかは無視します。「PPAPが守ろうとしていた脅威」を挙げるのが目的ですので。
• 現実的な発生可能性は無視します。例えば現代のメールは多くが暗号化通信されているので途中で盗み取られるという可能性は低いわけですが、可能性としてゼロではないのと、まさにそういった盗聴が怖いという建前でPPAPが生まれた背景もあるため、この前提を置きます。
• メールを送信する側の組織の立場に立った脅威のみを対象とします。つまり、ファイルを共有された側の脅威については対象外とします。

（余談ですが、PPAPに対する批判の一つに「Emotetなどでメールに添付されるマルウェアがパスワード付き添付ファイルになっていて、ゲートウェイ製品の検知をすり抜けやすくなっているのでPPAPをやめるべきだ」というものがあります。これは個人的には筋の良くない議論だと思っていて、例えばPPAPの代わりにファイル共有サービスによるファイルの授受が一般的になったら、攻撃者はこれを悪用するだけだと思いますし、あまり本質的な議論ではないかなと思うのです。）

1. Spoofing / なりすまし
   ・メールの送信先がなりすまされている（Aさんに送るつもりだったのに、BさんがAさんになりすましているようなケース）
2. Tampering / 改ざん
   ・メールで送信したファイルが途中で盗み取られて改ざんされる
3. Repudiation / 否認
   ・該当なし
   メールを送信したことの否認、ファイルを添付したことの否認ということはあり得ますが、前述したとおり「メールのシステムは信頼できる」という前提を置いているので、メールサーバーなどにログが残っていて送信したことの否認は考える必要はなさそうです。
4. Information Disclosure / 情報漏洩
   ・メールで送信したファイルが伝送経路上で盗み取られて漏洩する
   ・メールを誤送信してファイルが漏洩する
5. Denial of Service / サービス妨害
   ・該当なし
   （メールシステムは信頼できる前提のため）
6. Elevation of Privilege / 権限昇格
   ・ファイルにアクセスする権限を奪取される（例えば、添付ファイルのパスワードが破られるなど。）

まとめ

この記事では、「PPAPはどういった脅威から何を守ろうとしていたのか」を明らかにすることを試みました。そのために、STRIDEという方式でメールでファイルを送信するという行為に対する脅威分析を行いました。結論として、「PPAPは以下の脅威からメールで送信するファイルを守ろうとしていた」ことが言えそうです。

• 【なりすまし】メールの送信先がなりすまされている（Aさんに送るつもりだったのに、BさんがAさんになりすましているようなケース）
• 【改ざん】メールで送信したファイルが途中で盗み取られて改ざんされる
• 【情報漏洩】メールで送信したファイルが伝送経路上で盗み取られて漏洩する
• 【情報漏洩】メールを誤送信してファイルが漏洩する
• 【権限昇格】ファイルにアクセスする権限を奪取される（例えば、添付ファイルのパスワードが破られるなど。）

もし現在PPAPの代替サービスを考える場合、以上を参考にしていただき、それぞれの脅威に対してPPAPと比較して同等以上に保護される方式を検討いただくと良いでしょう。

最後に私の雑感としては、ここまで挙げた脅威が発生する可能性は低いのではないかと思います。現在のメールの伝送経路が大多数暗号化されているためです。よって、機密性が相当高いものを除いては、ファイルにパスワードなどつけずに、そのままメールに添付して送付しても良いのではないかと感じます。（元も子もない結論ですが。）

最後まで読んでいただき、ありがとうございました。

こんにちは。Japan Digital Design（JDD）で、セキュリティ担当を務めている唐沢です。

2019年6月25日(火)～26日(水)にボストンで開催された「AWS re:Inforce 2019」に参加してまいりましたので、その内容をシェアします。といっても、すでに多くのセッションはYouTubeで公開されておりますので、気になるセッションを直接聴きたい方はこちらをどうぞ。

https://aws.amazon.com/jp/blogs/security/reinforce-2019-wrap-up-and-session-links/

「AWS re:Inforce」は例年開催されている「AWS re:Invent」からの初のスピンオフスイベントで、セキュリティをテーマにしたカンファレンスです。今年は7,000人が参加したそうです。JDDからは社長以下5人が参加し、2日間みっちり勉強してきました。会場はボストンのウォーターフロントにほど近い「Boston Convention & Exhibition Center (MCCA)」で、東京ビッグサイトの１つの展示棟より一回り小さいくらいでしょうか。ちなみに来年はヒューストンで開催されるようです。

キーノートセッションを振り返りつつ、re:Inforce全体を概観したいと思います。

AWSのセキュリティ機能

キーノートはAWSのCISOであるSteve Schmidtさんです。FBIのテクノロジー部門に10年以上勤めた後にAmazonにジョインし、2010年からAWSのCISOを務めてらっしゃいます。その後、AWS Principal TechnologistのAbbyさん、Liberty Mutual社サイバーリスク担当役員のBrianさん、Capital One社CISO Michaelさんが入れ替わり登壇しました。

新機能だけではないですが、いくつか気になったAWSのセキュリティ機能をピックアップします。

AWS Iot Device Defender
IoTのセキュリティをワンストップで提供するソリューション。特にパッチマネジメントを提供してくれるのは開発者にとってうれしい機能なのではないでしょうか。

GuardDuty
新機能ではありませんが、「とりあえず有効にしておいた方が良い」と言われる脅威検知サービス。AWS環境内のモニタリングにより異常を検知してくれます。「GEが週末のうちに旧来のIPSからGuardDutyへの移行を完了した」との言は導入の容易さを物語っていました。確かに有効にするだけなので導入は容易ですね。（運用が容易かは把握できていないのですが）

AWS Security Hub
re:Inforce当日にGAした機能で今回の目玉の一つではないでしょうか。re:Invent 2018で発表済みの機能ではありますが、やはりセキュリティ関連のオペレーションを中央管理できる本機能は私のような統制する側の人間にとってはとても魅力的です。関連セッションの１つ「How to Act on Your Security & Compliance Alerts with AWS Security Hub (FND218)」も立ち見が出る人気ぶりでした。このセッションではSecurity Hub利用企業の事例も紹介されているので、これから導入を検討される方の参考になるのではないかと思います。

Amazon Macie
クラウド上に飛び交うデータに対して発見的統制を行うために重宝するであろう機能。クラウドにデータを置くことに対する危険性を心配する声も根強いと思いますが、統制の効かない紙とチェックリストの管理とは違う未来を感じさせてくれる機能です。Macie自体のセッションはなかったように思いますが、「Beyond security & compliance, with healthcare compliance analytics」(YouTube公開なし）という医療データコンプライアンスに関するProtenus社のセッションは面白かったです。

AWS Control Tower
こちらもre:InforceでGAが発表された複数アカウント環境を統制する標準となっていきそうな機能。Guardrailsを全社や部署ごとに適用するハブとなる機能です（多くのAWS利用企業からリクエストがあった模様）。残念ながら時間の都合でセッションを聞くことができなかったのですが、「Using AWS Control Tower to Govern Multi-Account AWS Environments (GRC313-R)」などは参考になりそうです。

Traffic Mirroring
キーノートで発表された新機能の一つで仮想TAPです。EC2でNitro世代のインスタンスに限りますが、通信をキャプチャして解析することが可能です。より詳しい通信のモニタリングができるようになりました。

その他、気になった発言・トピックなど

• Security Automation
  これはキーノートでも様々なセッションでもとにかく自動化の機能/事例が何度も強調されていたように思います。クラウド使うのですから当たり前ですが、そうした設計がしやすかったり事例が豊富にあるのがAWSの良さではないでしょうか。
• “Infrastructure as code requires security as code”
  ボストンに拠点を置くLiberty Mutualという保険会社のサイバーリスク担当役員が登壇。”Rader”と名付けられた仕組みによって、クラウド上のセキュリティポリシーを自動的に強制する仕組みについて紹介していました。re:Inforceを通じて様々なセッションやワークショップで強調されていたように思いますが、資料やインタビューをベースにしたリスク統制はクラウドをベースにした速い環境変化についていくことができず、CloudWatchなどのテクノロジーをフルに活用して”security as code”を実装していく必要があり、どう実践したかを発表されていました。
• “Auditing gets transformed” （監査のトランスフォーメーション）
  前述している話と重なりますが、「年１回、紙ベース」「手書きの証跡」「手書きのコントロール」による監査から、「リアルタイムで、ほぼ瞬時の結果確認」「数学的な証跡」「自動的なコントロール」による監査に変えていこうというメッセージがありました。誤解を恐れずに言えば、「エクセルを捨て、ダッシュボードで監査しよう」ということになるでしょうか。こうした考え方は多くのセッションに見られましたし、また、この考えを実践するためのワークショップも多く開催されていました。私自身は「Building Serverless Compliance-as-code」というワークショップに参加し、CLIを使った監査のさわりを体験したり、「Scout2」「Prowler」「CS-Suite」といったオープンソースのチェックツールについてデモを見ることができました。
  目指すべき未来であることは確かでJDDでも実践していきたいと思いますが、一方で監査基準（各社のスタンダードをどこに置くか）について非技術者含めて合意をとっていくプロセスについてはベストプラクティスがなく、今後の課題のようにも感じます。
• 新しいアンチマネーロンダリング（AML）の形
  金融機関として少し面白かったのが、監査のトランスフォーメーションの文脈で出てきたAMLに関する以下の２枚のスライドです。最初のスライドにあるような現在のAMLのプロセスを、AWS Data Lake FormationとAmazon SageMakerを使って自動的に早期に実現してしまおうというアイデアです。法令上の問題もあるので簡単にはいかないと思いますが、アイデアとしては面白いと感じました。

• DevSecOps
  Schmidtさんの”I am not fan of DevSecOps”という発言に拍手が沸いていたのは笑いましたが、「開発プロセスにセキュリティを埋め込みたい」との言には納得です。個人的にCI/CDの中でどうセキュリティを確保していくべきかは今回のテーマの１つではあったのですが、時間的に適切なセッションを聞くことができず、展示スペースで色々な製品を見て回っただけになってしまったのが残念でした。コンテナイメージの検査ツールなど様々な製品がありましたが、各社の開発プロセスというものがある中で考えると、自社なりのセキュリティの埋め込み方というのを考えていくしかないんだろうという至極一般的な結論になっているのが現状です。これはAWSに限った話ではないのですし、JDDとしてのスタンダードをしっかり作っていかなければという思いを新たにしました。

追記：ボストン情報

ボストンは治安もよくきれいな街でした。（ホテルが少ないようでカンファレンス時期の価格が普段の２倍くらいになっていたのには閉口しましたが）

カンファレンス期間に入る前に現地入りしたので少し時間があり、ケネディ元大統領が愛したといわれる「UNION OYSTER HOUSE」へ。ロブスターはさすがの美味しさでした。なお、お酒を飲むには年齢確認が義務付けられているのでパスポートの携帯をおすすめします。（必ずしも聞かない店員さんもいますが）

AWS re:Inforce 2019振り返り ～Keynoteを軸にしつつ～ was originally published in Japan Digital Design Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.