従業員が純粋にイントラネットで使用するアプリケーションは、安全なソフトウェア設計が必要ですか、それともOWASPガイドラインに従う必要がありますか？
私はイントラネットを介してアプリケーションを開発しており、社内の従業員のみが使用しています。ここには外部の関係者は含まれず、アプリケーションは外部通信を使用しません。
この場合、安全なソフトウェア設計が必要ですか？もしそうなら、OWASPのガイドラインに従うだけで十分でしょうか？
Kyle Fennellの回答 は非常に優れていますが、内部アプリケーションを安全に設計することが推奨される理由について説明します。
多数の攻撃が内部の攻撃者を巻き込む
このfactoidにはさまざまなバージョンがあります。 「すべての成功した攻撃の50％は内部で始まります」、「すべてのデータ侵害の3分の2は内部の攻撃者に関係しています」など.
私が見つけた統計の1つは Verizonの2019 DBIR で、彼らは次のように主張しています。
[分析されたデータ漏えい]の34％が内部関係者を巻き込んだ
正確な数が何であれ、かなりの量の攻撃には内部の攻撃者が関係しています。したがって、脅威モデルを「それは内部的なものであり、したがって安全である」とすることは悪い考えです。
安全なソフトウェア開発は、悪用を防ぐだけでなく、誤用も防ぎます
- 虐待：ユーザーは自分の利益のために悪意のあることをします
- 誤用：ユーザーは何も知らないために悪意のあることをします
私が誤用を持ち出すのは、会社に損害を与えるすべてが故意に行われるわけではないからです。時々人は間違いを犯し、人がミスを犯した場合、マシンがそれらのミスが広範囲にわたる結果をもたらすのを防ぐのは良いことです。
すべてのユーザーがすべてを実行できるアプリケーションを想像してみてください（アクセス許可の設定には長い時間がかかり、開発中には考慮されなかったためなど）。 1人のユーザーがミスをしてすべてを削除します。これにより、IT部門が心臓発作を起こし、先週のバックアップでサーバールームに全力疾走する一方で、部門全体が深刻な停止状態に陥ります。
同じアプリケーションを想像してみてください。ただし、明確に定義されたアクセス許可システムを使用しています。ユーザーが誤ってすべてを削除しようとしましたが、自分に割り当てられたタスクのみを削除しました。彼ら自身の作業は停止し、ITは先週のバックアップのデータを現在のデータとマージします。今日では、30人ではなく2人の従業員が生産的な仕事をすることができませんでした。それはあなたにとって勝利です。
「内部」は悪意のある行為者からの解放を意味するものではありません
一部の企業は、技術的には複数のチームを持つ1つの企業ですが、チームが共同で作業するのではなく、チームが互いに競合する形で分裂しています。これは起こらないと思うかもしれませんが、 Microsoftはこうだった 長い間です。
すべてのチームが内部で使用するアプリケーションを作成することを想像してみてください。従業員が作成したスクリプトを実行して他の従業員を30分間ロックアウトできるとわかったら、どうなるか想像できますか。 「そのほかのチーム」の従業員は常にアプリケーションからロックアウトされます。ヘルプデスクは5のために忙しいでしょう番目 今週、なぜ人々がアプリケーションから締め出されるのかを理解しようとする時間。
これは遠くまで行き渡ったと思うかもしれませんが、「他のチーム」よりも優れたパフォーマンスを実現するために、年末にこの甘いスイートボーナスを手に入れる人がどれほどいるかに驚くでしょう。
「内部」は「内部」にとどまらない
現在、2020年には、ご使用のアプリケーションは少数のグループでのみ使用されます。 2029年には、このアプリケーションは内部で使用される人もいれば、ベンダーや請負業者も使用する予定です。ベンダーの1つがアプリケーションの欠陥を発見した場合はどうなりますか？彼らが彼らの競争相手の1人がはるかに良い状態を得ることを見ることができたらどうでしょうか？
これは、あなたが入りたくない状況であり、あなたが防げたかもしれない状況です。
「内部」アプリケーションからのコードの再利用
データベースへのアクセスを行う内部アプリケーションを作成します。それは何年もの間うまく働き、誰も文句を言うことはありません。次に、同じデータに外部からアクセスするアプリケーションを作成する必要があります。 「簡単！」と、初心者のコーダーは思います。 「すでに存在しているコードを再利用します。」
そして今、SQLインジェクションを実行できる外部アプリケーションに行き詰まっています。突然、「内部使用のみ」のために作成されたコードは、意図的にしゃれたものではなく、外部で使用されるためです。そもそも内部コードを細かくすることでこれを避けてください。
OWASPをフォローするだけで十分でしょうか？
この質問への答えは、「何で十分か」という別の質問です。これは最初はつらいように聞こえるかもしれませんが、問題を示しています。正確に何を保護したいですか？
アプリケーションの脅威モデルを定義します。これには、どのような方法でアプリケーションの脅威になる可能性があるかを含め、これらの個々の脅威の解決策を見つけます。 OWASPトップ10で十分な場合もあれば、そうでない場合もあります。
はい、内部アプリケーションは十分な注意を払って保護する必要があります。はい [〜＃〜] owasp [〜＃〜] は、アプリケーションを保護するための良いガイドになります。 Microsoftの Security Development Lifecycle（SDL）、 も見てください。これは、ソフトウェア開発に焦点を当てたセキュリティ保証プロセスです。
なぜ？
- 多層防御。攻撃者はネットワーク防御を破ることができます。それらとあなたのデータの間に保護のより多くの層を置きます。
- 外部の脅威だけではありません。アプリケーションの脆弱性は、内部の脅威によっても悪用される可能性があります。
他の人はすでに邪悪な従業員、侵入、多層防御についていくつかの良い点を述べました...しかし、それはそれよりもはるかに実用的です。ランダムなWebページから内部のイントラネットアプリケーションを攻撃できます。
人々は一日中リンクをクリックします。同僚が共有したいものを見たため、検索結果（または広告）から、redditのようなサイトからの1,000の賛成票を含むかわいい猫の写真、フィッシングメールからの場合もあります。
攻撃者があなたにリンクをクリックさせる方法はたくさんあります。猫の写真を選びましょう：かわいい猫の写真に賛成した他の何千人もの人々にとって、それは無害でした。 OWASPガイドラインに準拠していないすばらしいイントラネットWebサイトを使用している会社の誰かがクリックするまで。
悪意のあるページへのリンクをクリックすることはほとんど無害です：ブラウザの定期的な更新により、セキュリティが確保され、Webサイトが残りのWebサイトにアクセスすることを許可しませんコンピューター。 「ほとんど無害」であるため、リンクをクリックするのは簡単です。しかし、それは、標的の企業ネットワーク内にJavaScriptコードを実行するページがあることは攻撃者にとって有利ではないという意味ではありません。
猫の写真のページには、次のようなものを含めることができます。
_1. <img src=cute_cat.jpg>
2. <iframe name=hiddenframe style='display:none'></iframe>
3. <form action='http://intranet.local/addUser.php?username=joseph&password=123456' id=myform target='hiddenframe'>
4. <input type=submit style='display:none'>
5. </form>
6. <script> document.getElementById('myform').submit() </script>
_ページを開くと、完全に見えないように、イントラネットアプリケーションで_addUser.php_ページを呼び出すことができます。（通常は作業中に）ログインしている場合、ブラウザ喜んであなたのログインCookieを追加します（イントラネットがあなたであると認識するセッショントークンが含まれています）。攻撃者はあなたのシステムにアカウントを持っています。イントラネットアプリケーションを持たない人にとっては、何もしません。
これは、クロスサイトリクエストフォージェリ（CSRF）攻撃（およびその他のいくつかの悪い習慣）の例であり、OWASPガイドラインに従うことで防止できます。このコードの機能の概要：
- 猫の写真を見せて、ページを無害に見えるようにする
- イントラネットページが読み込まれる非表示のフレーム（サブページ）を追加します。
- イントラネットに送信するフォームを追加し、攻撃者が選んだユーザー名とパスワードを使用して
addUserページを呼び出します。 - フォームを機能させるには、非表示の送信ボタンが必要です。
- フォームの終わり。
- フォームで
submit()を呼び出すと、送信ボタンがトリガーされます。
_addUser.php_ページに抗CSRFトークンがない（またはチェックされていない）場合、この攻撃は100％可能であり、過去に多くのサイトがこの脆弱性に対して脆弱でした。一例は？成績が登録された私の学校のイントラネット。私は教師にデジタルハンドインへのリンクを送信することができ、ページは（私のハンドインを表示することを除いて）バックグラウンドで私の（または他の誰かの！）成績を変更する可能性があります。
今日でもまだ一般的です。次に、もう1つの、はるかに単純な（そして害の少ない）例を示します。
_1. <img src='cute_cat.jpg'>
2. <img src='http://intranet.local/logout.php'>
_これはログアウトページを呼び出すだけです。ブラウザはその_logout.php_ページからの画像を期待しますが、画像がない場合（ログアウトページであるため）、結果を破棄します。一方、イントラネットアプリケーションはログアウトします。しばらく開いたままにしているタブから攻撃者が2秒ごとにこれをトリガーした場合、ログアウトされ続けるため、イントラネットを使用できない可能性があります。
覚えておいてください 2019年8月の巨大なCapital One違反 ？
根本的な原因は、内部のCapital Oneアプリのサーバー側リクエストフォージェリ（SSRF）の脆弱性でした。
はい、内部アプリの安全な設計について心配する必要があります。
どのプラットフォーム？私が引退する前に、私はanythingがnotが処理に失敗する可能性があるall例外を書いたことを確認する必要がありました。未処理の例外があると、ユーザーに、Microsoftに使用しないことを約束した個人情報を含む可能性のあるデータをMicrosoftに送信するように求めるポップアップが表示されます。
もちろん、ほとんどのユーザーは読むことなくすぐにOKをクリックします。マイクロソフトがその約束を守るかどうかにかかわらず、データを送信すると、病院はHIPAAに基づく訴追の対象となります。また、HIPAAでは、患者情報が検出された場合にマイクロソフトに報告するよう要求しています。
MacOSにも同様のポップアップがあり、ユーザーが事前に設定でオフにしないと、IOSは確認せずにデータを送信します。
そして、NSAの最大の競争相手の1人によってコード化されたAndroidがあります。
したがって、これらのプラットフォームのいずれでも、答えは「はい」です。
絶対100％はい。
与えられたすべての理由と1つの非常に重要な実用的な理由のために、あなたは経営陣の誰かがインターネットにそのものを置くことを決定する日を決して知りません。 「それは非常にうまく機能するので、外部の請負業者はそれを使用するべきです。」またはその他の理由。
それが起こったときに完全にリファクタリングしたいですか？
会社で発生する非常に一般的なことは、人々が内部ツールの使用を好み、それをパートナーまたは顧客に言及することであり、そのツールを外部ユーザーが利用できるようにすることへの要求があります。
はい、ツールでいくつかのセキュリティ対策を使用し、将来的にそれを保護するために自分自身をロックしないでください。 「このプロセスのrootの代わりに専用のユーザーを作成する」、「ユーザーとプロセスの可視性をツールが必要とするものだけに制限する」など、最も単純なことは長い道のりです。
私はここで全体的な声明のいくらかを投稿するつもりです、しかしあなたのアプリケーションが専門的にコード化され、ベストプラクティスに従っているならば、それは箱から出してすでにかなり安全であるべきです。 SQLインジェクションなど、少なくとも最も一般的な脆弱性は悪用できません。
そして、現在利用可能な開発フレームワークは実際にあなたの仕事をより簡単にします。一方、品質より開発の速度を優先する場合、1990年代のコーディングガイドラインに悩まされている場合、パラメーター化されたクエリを使用しない場合は、問題が発生します。
少なくとも、アプリケーションにペンテストを行って、コードに最も明らかな誤りがないこと、およびスクリプトキディが自動攻撃を起動してシステムを危険にさらすことがないようにしてください。
トムが言うように、今日隔離されているものは、管理上の決定、またはルーター/ファイアウォールの設定ミスにより、明日インターネットに公開される可能性があります。アプリケーションは、知らないうちに、または退職後に偶然に公開される可能性があります。
そして、あなたは退屈な従業員が自由時間をどのように費やしているかに驚くでしょう。私はかつて、コンピュータに習熟していない管理者のワークステーションにポートスキャナを見つけました。ツールは偶然そこに着陸しませんでした。多くの場合、従業員はあらゆる組織の弱点です。
次に、パラノイアの適切なレベルは、イントラネットがアクセスを許可している資産の種類によって異なります。アセットの機密性が高く、アプリケーションが1日ハッキングされた場合、フォレンジック調査でコードがずさんで最低限のセキュリティプラクティスに準拠していなかったことが判明した場合、仕事が停滞している可能性があります。最悪のケースのシナリオは、あなたが雇用主/クライアントによって過誤行為で訴えられることです-それは確かに時々起こるはずです。
Equifaxで働いていたIT担当者はどうなったのでしょうか。
ネットワークトポロジも考慮してください。イントラネットが社内でホストされ、LANに直接接続されている場合、イントラネットはLANおよびその他のリソースへのゲートウェイです。私が攻撃者であり、システムに侵入したい場合は、弱点、間接的だが見落とされているルートを探します。
だから私はこのような質問を言い換えます：どのような状況下で安全なソフトウェア設計が必要ないのですか？
あなたの雇用者/クライアントについて考えるだけでなく、あなたの評判についても考えてください。ある日、誰かがあなたのコードを見る可能性があります。たとえば、将来のアプリケーションの移行を任されている別のIT担当者など。あなたよりも知識が豊富で、コードを見るときに何も言えない人。