雑記系ブログ。セキュリティとか、マイルとか、投資とか、、、 / Miscellaneous Blogs. Security, miles, investments, etc
障害多発のみずほ銀行のことを「みすぼらしい銀行」という人が多いらしい(転載)
ITmedia Security Week 2021 autumn振り返り~徳丸さんセッション。事例ベースなので、納得感がある。2段階・2要素認証はもはや常識になりつつあるか~
徳丸さんのセッションが大変勉強になったので、メモ。
これまでのクラウドにまつわる事件・事故事例。
過去の事件・事故は下記参照
・産総研
クラウドサービス事業者が行うべき主要な情報セキュリティ対策(by 総務省)
■利用者側の重点対応項目(1)認証の強化・ID管理
・SaaSの安全な利用の勘所は認証・ID管理にあり
・認証の強化・ID管理の原則
-ポリシーで2段階・2要素認証を強制する
-伝統的なIPアドレス制御はクラウド利用の阻害要因になるので、別の方法での対策が望ましい
-一人1ID、最小権限の原則の徹底
-退職者・異動者のアカウントの早期の削除・無効化
-利用するSaaSの機能を有効活用する(とはいえ、SaaSの種類が増えると管理は大変)
・クラウド型ソリューションによる対策は?
-IDaaS(Azure AD、Octa、HENNGE....)
■なぜVPN経由でSaaSを使うのか
・インターネットの出口でProxy、Webフィルタリング、次世代ファイアウォール等のセキュリティソリューションを適用しやすい。
※そもそもVPN経由でSaaSを使うと産総研みたいなインシデントは起きない。
■利用者側の重点対応項目(2)設定管理
・Salesforceの一連の事故のように、権限設定の間違いが大半
・古くはGoogleグループの一覧の事故(2013年~)
-古くて新しい話題
・Googleグループの設定不備は利用者による確認は容易だったが、Salesforceの事例は利用者での確認は容易ではない。
・シャドーITとの合わせ技の事例も多数。
■利用者側の重点対応項目(3)シャドーIT対策
・シャドーITとは
-統制の及ばないIT利用のこと
-無料のSaaSを部門あるいは個人で「独自に」利用するケースが多い
・ポリシーでの基本が対応
-そもそも「やってはいけないこと」と認識していない素朴なケースが多い
-組織のポリシーで「やっていいことと駄目なこと」をさだめ、徹底を求める
-ポリシーが厳しすぎると、こっそり使う社員が出てくるので、ポリシーの「さじ加減」が重要
・クラウドソリューションによる対策は?
-CASB(Cloud Access Security Broker)
-クラウドプロキシ(Cloud Proxy)
※費用の問題もあるが、まずはポリシーがないとツールの活用もできない
■まとめ(というか基本)
・とにかく認証・ID管理の強化が重要
・企業のポリシーを定め、SaaS利用の統制と利用ノウハウの集約
・SaaSのセキュリティ設定
・利用規模が大きい場合は、IDaaS、CASB、クラウドプロキシ等、クラウド型セキュリティソリューションの活用を検討する
JALマイルでJAL国際線特典航空券が一層取りやすくなるタイミング(転載)~特典航空券解放のロジックを理解するとハッピーがあるかも!?~
- ワクチン接種率は上昇中
- 感染者数は増加しているが、死亡率は低下中
- 基本マイル数
- JAL国際線特典航空券PLUS
- 360日前の10:00に予約開始(この時点では基本マイルで取れる枠数はビジネスクラスで1便2席、ファーストクラスで1便1席が今は基本になっていると思われる)
- 搭乗の1週間ほど前から直前開放で枠が増える
- 予約開始後2週間ほどで枠が増える!?
- 1便目:3席
- 2便目:9席以上
- 3便目:8席
- 1便目:4席
- 2便目:すでに枠なし
- 3便目:4席
- 360日前10:00の予約開始時
- 予約開始後2週間(正確には路線により11〜14日後)の開放枠
- 搭乗1週間前の直前開放
バンコク・エア、ランサムウェア攻撃によるお客様の個人情報流出を確認 / Bangkok Air confirms passenger PII leak after ransomware attack(転載)~PIIは個人を特定できる情報のことで、Personally Identifiable Informationの略です。~
業界標準や、監督官庁の提示している基準・ガイドライン(転載)
Webアプリケーションの構成要素には、アプリケーション、プラットホーム、ネットワークなどの構成要素があります。アジャイル開発では、1〜2週間といった非常に短い単位で開発を進めていきます。このサイクルをアジャイル開発でよく使われる「スクラム」では、スプリントと呼びます。スプリントで開発する機能を優先度の高い順から選択して、選択した機能の開発とリリースを繰り返していきます。しかし、以下表のような非機能要件は、ある程度事前に検討して環境を準備していく必要があります。
大項目 | 中項目 | 説明 |
---|---|---|
可用性 | 継続性、耐障害性、災害対策、回復性 | システムサービスを継続的に利用可能とするための要求 |
性能・拡張性 | 業務処理量、性能目標値、リソース拡張性、性能品質保証 | システムの性能、および将来のシステム拡張に関する要求 |
運用・保守性 | 通常運用、保守運用、障害時運用、運用環境、サポート体制、その他の運用管理方針 | システムの運用と保守のサービスに関する要求 |
移行性 | 移行時期、移行方式、移行対象(機器)、移行対象(データ)、移行計画 | 現行システム資産の移行に関する要求 |
セキュリティ | 前提条件・制約条件、セキュリティリスク分析、セキュリティ診断、セキュリティリスク管理、アクセス・利用制限、データの秘匿、不正追跡・監視、ネットワーク対策、マルウェア対策、Web対策、セキュリティインシデント対応/復旧 | 情報システムの安全性の確保に関する要求 |
システム環境・ エコロジー | システム制約/前提条件、システム特性、適合規格、機材設置環境条件、環境マネージメント | システムの設置環境やエコロジーに関する要求 |
非機能要件定義として挙げた例は、情報処理推進機構(IPA)が公開している「非機能要求グレード2018」から抜粋したものです。ラックのシステムセキュリティデザインサービスでは、このうちセキュリティに関わる範囲をセキュリティ要件として整理しています。
セキュリティ要件の作成においては、開発アプリケーションの特性に応じて、次表のような業界標準や、監督官庁の提示している基準やガイドラインを参考にする必要もあります。
適用例 | 要求仕様 | 刊行 | 特徴 |
---|---|---|---|
金融業界向け | 金融機関等コンピュータシステムの安全対策基準・解説書 第9版 | 金融情報システムセンター(FISC) | 金融業界向け対策基準で、主に銀行が広く利用される対策基準 |
金融分野における個人情報保護に関するガイドライン | 金融庁 | 金融業界向け対策基準で、金融業界全般で利用されるガイドライン | |
Webアプリのセキュリティ対策 | 安全なウェブサイトの作り方 | 情報処理推進機構(IPA) | 官公庁、公共のシステム構築案件に多く用いられるセキュリティ対策の要求仕様 |
認証、認可 | NIST Special Publication 800-63-3: Digital Authentication Guideline | 米国立標準技術研究所 | ダイレクトバンキング等でも用いられる、サービス利用ユーザのライフサイクルに関する要求仕様 |
ネイティブアプリ (スマホアプリ) | OWASP Mobile Application Security Verification Standard | OpenWebApplicationSecurityProject | スマホネイティブアプリ開発時に、多く用いられる要求仕様 |
アプリケーションのセキュリティ対策 | OWASP ASVS(アプリケーションセキュリティ検証標準) | OpenWebApplicationSecurityProject | 金銭取引が行われるシステム構築時に、多く用いられる要求仕様 |
クラウド運用 | ISO27017 | 日本品質保証機構 | クラウドの利用/提供に関するセキュリティ要求事項を定めた規格 |
システム非機能要求事項全般 | 非機能要求グレード2018 | 情報処理推進機構(IPA) | 機密性、可用性、完全性等の観点でシステムの非機能要求事項を定めたガイドライン |
データの秘匿化や暗号化 | 電子政府推奨暗号リスト | CRYPTREC | 総務省、及び経済産業省が推奨する暗号技術の評価 |
参照すべきガイドラインや基準は多岐に渡り、随時更新されていきます。こうしたガイドラインや基準には、具体的な実装方式などは記載されていないこともあるので、ガイドラインや基準を満たす実装方式についても情報収集と判断が必要になります。ラックのセキュリティコンサルティングサービスは、様々な業界のお客様を支援していますので、常に最新の業界動向に応じた要件と、具体的な実装方法を提示することが可能です。
2021年7月16日~31日 サイバー攻撃のタイムライン / 16-31 July Cyber Attacks Timeline(転載)
少し休んでから、7月2回目のサイバー攻撃の年表がようやく出ました。休暇期間中は、脅威の状況にも少し変化があったようです。この2週間で収集したイベントは82件で、前の期間に比べてかなり減少しました。
82件のうち21件(25%)がランサムウェアによるもので、直接的または間接的にランサムウェアの影響を受けていますが、特定できない障害が多数発生していることから、実際の件数はもっと多いかもしれません。Kaseyaを襲った事件のような有名な事件は起きていないようですが、発生率は依然としてかなり高いといえます。
この夏は、新たな大規模暗号ハッキングも発生しました。特にTHORChainは2回攻撃を受け、理論上の盗難総額は約1,500万ドル相当になりました(ただし、作者とされる人物が10%の懸賞金を要求したケースもあります)。
サイバー・エスピオナージの分野では、APT29(新しいキャンペーンが発見され、そのインフラは停止されました)、APT31(フランスの組織を標的としています)、Mustang Panda(東南アジアの組織を標的としています)、Tortoiseshell(防衛および航空宇宙産業に従事する従業員および請負業者を標的としています)などの旧知の企業による新しいキャンペーンに加え、Praying Mantis、GhostEmperor、Ekipa(ロシア人および親ロシア派の個人を標的としたクリミア発の新しいキャンペーン)などの新しい脅威アクターも登場し、非常に混雑した状態が続いています。
JNSAのインシデント損害額調査レポート(転載)
JNSAのインシデント損害額調査レポート
JNSA(特定非営利活動法人日本ネットワークセキュリティ協会)からインシデント発生時にかかるコスト調査のレポートが出ていました。
国内外のセキュリティベンダーを中心に、サイバー攻撃損害コストの調査データはいくつも出ていますが、関係者アンケート回答からの”雰囲気”集計した様にも思えるモノも多い気がします。
そんな中、このレポートはインシデントで実際に発生する可能性がある損害コストが、見落としがちな部分も含めて書かれているので、例えばサイバー保険加入の稟議資料(費用対効果)を作成する場合や、インシデントレスポンスプランを策定(改訂)する際に役立つのではないかと思います。
費用が想像しにくいフォレンジック調査費用も書かれており、業者によってばらつきはあるものの、といったイメージが付きやすいのではないでしょうか。
(個人情報漏えい対象者等への)おわび状の費用や、新聞掲載の費用などが掲載されています。事業内容やインシデントの規模によって費用が変わるものの、「最大リスク」を試算する上で、参考値となるかと思います。
サイバー保険やセキュリティ対策費用(あるいは情報システム部門の増員)の妥当性を検討する上で、こうした費用試算をしておく事は、経営陣への説明という意味でも有効かと思います。
JNSAが出したレポートという事でも客観性が出てくるかと思いますので、こうした業務に携わる方は、レポートを一読される事を強くお勧めします。
DarkWebの調査費用が意外と高いと感じましたが、DarkWeb接続に(やや)専門的な知識が必要で、調査すべき対象サイトの把握が難しい(どこに出てくるか分からない)点、そして継続調査や、サンプルデータの購入費用などを考えると仕方が無いのかも知れません。
SeatSpy社がスクリーン・スクレイピングの被害者であると主張 - 非常に斬新な証拠を入手 / SeatSpy claims it is the victim of screen scraping(転載)
普段は穏やかな航空会社の特典航空券提供ツールの世界で、興味深いスパイ活動の主張がなされている。
SeatSpyは、ブリティッシュ・エアウェイズやヴァージン・アトランティック航空の特典航空券を探している人にとって、とても便利なウェブサイトです。ワンクリックで1年間のあらゆるルートの空席状況を確認することができます。さらに、Eメールアラートを設定することで、ご希望のルートに空席が出た場合に連絡を受けることができます。
ブリティッシュ・エアウェイズのAviosの空席状況を追跡するのは、必要以上に複雑です。ほとんどの航空会社は、特典用の座席を特定の「チケットバケット」に分類し、AmadeusまたはSabreにアクセスできる人なら誰でも見ることができます。Aviosはこのような仕組みではないため、空席状況を簡単に確認する方法はありません。
BAが自社用に作成したフィードを介して、このデータにアクセスすることが可能でした。これにより、2017年には「Reward Flight Finder」が、2019年には「SeatSpy」が発売されました。
ある時点で、ブリティッシュ・エアウェイズはこのデータへの第三者のアクセスをブロックすることを決定しました。これにより、SeatSpyとReward Flight Finderの両方に深刻な問題が発生しました。
SeatSpy社はこの問題を解決し、現在は少なくとも1時間に1回はデータが更新されているとしています。
先日、SeatSpyは、自社のデータがスクリーン・スクレイピングされていると主張するブログ記事をウェブサイトに掲載しました。この記事では、第三者に代わって自動検索を実行している偽のSeatSpyアカウントが「数百」見つかったとしています。
興味深いのは、SeatSpyがどのようにしてその証拠を見つけたかだ。
これは、BA Southampton - Nice間のビジネスクラスの「リアル」リワードデータを削除したもので、このルートはSeatSpyユーザーが積極的に追跡していないルートでした。
SeatSpyは、そのデータを偽のデータに置き換え、特定の日付に偽の座席を表示しました。
これは、しばらくしてReward Flight Finderのサイトに掲載されたものです。
残念ながら、このデータはReward Flight Finderから削除されていますが、私はそこで見たことを確認しています。