ダークウェブでヒットマン(殺し屋)を雇うとどうなる? / The Operator of a Dark Web Assassination Site Was Arrested in Russia(転載)~ロシアの事例~


ダークウェブ上のウェブサイトで暗殺請負をしていたロシア人の男が逮捕される。詐欺ではなく本当に依頼通り殺害していた模様😱😱 technadu.com/operator-dark-…
technadu.com/operator-dark-…

ロシアのイジェフスク在住のセルゲイ・マグダノフ(38歳)が、自身のダークウェブ・プラットフォームを通じて注文された殺人事件に関与したとして逮捕されました。この事件は、2020年に開始されたFSBと内務省の捜査が成功したことを受けて、モスクワ市裁判所の手に委ねられています。当時、ロシア警察は、ウラジミール地方の麻薬ディーラーがライバルに命じられて起こした二重殺人事件の捜査に呼ばれ、これが最終的にマグダノフのデジタルトレースにつながった。

犯人が殺害を指示したサイトを知っていた警察は、そのプラットフォームとさらに多くの事件を結びつけ、点と点を結ぶことで、マグダノフにたどり着くことができました。この男は、暗号通貨と法定通貨の両方で支払いを受け付けており、偽のIDで登録したウォレットを使用していました。彼の家を襲撃したところ、500枚以上の銀行カード、1,000枚のSIMカード、多額の現金、数台の携帯電話とコンピューターが見つかりました。その場ですべてを押収し、分析にかけました。

ロシアでは、ダークウェブを利用した暗殺者の雇い入れは、残念ながらごく一般的に行われています。インターネット空間のプライベート性は、注文する側にとっても、犯行を行う側にとっても理想的だからです。マグダノフが逮捕され、機材が押収されたことで、近い将来、より多くの証拠が発見され、さらなる逮捕者が出る可能性があるが、サービスの利用者が注意を払っていれば難しいだろう。可能性としては、暗号通貨の取引履歴を追跡するのが一番ですが、その方法でもほとんどの場合は限られた結果しか得られないでしょう。

マグダノフは、仲介者としてプラットフォームを運営していただけでなく、殺人にも積極的に関与していた。捜査当局によると、彼は殺人の組織化、準備、武器・弾薬の入手、さらには犯行場所や暗殺者への指示にも関与していたという。このように、この男は殺人と違法な武器売買の容疑をかけられていますが、捜査が終了するまでは、さらに罪状が追加される可能性があります。

ダークウェブスキャナ - 電子メールとパスワードがハッキングされていないか確認する / Dark Web Scanner – Find Out If Your Email And Passwords Have Been Hacked(転載)

パンダセキュリティは、ウォッチガード社の協力を得て、ダークウェブをスキャンして、お客様のアカウントに関連する情報が協力されているかどうかをチェックするツールを作成しました。

パンダセキュリティでは、サイバー犯罪者から自由に使えるツールがないことが多いユーザーのオンラインセキュリティを守るために、「ダークウェブスキャナー」を無料で提供しています。

実際、サイバー攻撃は、暗い画面にバイナリコードが並んでいるという、一般的に想像されているイメージとは大きく異なります。一度に何十万人ものユーザーに影響を与えるデータ侵害は、多くの場合、単純な方法で行われ、サイバー犯罪者は、気づかれないことが多いツールの見かけ上の無害さを利用して大成功を収めています。

必要な予防措置を講じているにもかかわらず、故意にデバイスを使用している間に、パスワードや個人情報が流出したり、ディープウェブ上で販売されたりする可能性があります。お客様のデータが盗まれた場合、ハッカーはそのデータを使って、お客様の現在の口座にアクセスしたり、お客様の資産にアクセスしたり、お客様のアイデンティティを盗むことができます。

パンダセキュリティのコンシューマープロダクトマネージャーであるAlberto Añón氏は、「データ、特にログイン認証情報の盗難が、サイバー犯罪者にとって非常に重要な資金源になっている時代です。」と語っている。

お客様の個人情報が盗まれたかどうかを確認する方法

パンダセキュリティは、シンプルで無料のソリューションを提供しています。WatchGuardのサポートにより、ダークウェブをスキャンし、お客様のアカウントに関連する情報が侵害されていないかどうかをチェックするツールが開発されました。その名も、「Dark Web Scanner」です。

「このPanda Domeの新機能は、お客様からのご要望と、ますます複雑化するデジタルの世界に適応するための絶え間ない必要性から生まれたものです。パンダセキュリティは、ユーザーの皆様のサービスとセキュリティを継続的に向上させることをお約束します」とパンダセキュリティのコンシューマープロダクトマネージャー、Alberto Añón氏は付け加えます。

ダークウェブスキャナーは、マイパンダアカウントからアクセスできます。

しかし、My Pandaアカウントをお持ちでない方は、パンダセキュリティのお客様でなくてもDark Web Scannerをご利用いただけます。

CISAによるランサムウェアの攻撃から企業を守る方法 / Here’s how to secure your company against ransomware attacks, according to CISA(転載)


Here’s how to secure your company against ransomware attacks, according to CISA:

ランサムウェアによる攻撃は、民間企業、重要インフラ、政府組織に深刻な損害と莫大な経済的損失をもたらし続けています。ここ数年、法執行機関やセキュリティ企業は、Colonial Pipeline社やソフトウェア企業Kaseya社に対する最近の攻撃を含め、数多くのランサムウェア攻撃に対応してきました。

Cybersecurity Ventures社によると、ランサムウェアによる攻撃は、2031年までに被害者に年間2,650億ドル以上の損害を与えると言われています。専門家によると、ランサムウェアの攻撃によって引き起こされるセキュリティ侵害は、2秒ごとに発生していると考えられています。

この予測は、近年、この犯罪行為が著しく加速しているという観察に基づいています。

先日、米国のサイバーセキュリティ・インフラセキュリティ庁(CISA)は、ランサムウェア攻撃に起因するデータ漏えいを防止するためのガイダンスを発表しました。このガイダンスは、政府機関や民間企業がランサムウェア攻撃やそれに伴うデータ漏洩を防止することを目的としています。

「すべての組織は、ランサムウェアの被害に遭うリスクがあり、システムに保存されている機密データや個人データを保護する責任があります。このファクトシートは、重要インフラ組織を含むすべての政府機関および民間企業に対し、ランサムウェアによるデータ漏えいの防止と対応に関する情報を提供するものです」とCISAのガイドラインに記載されています。

"CISAは、組織が意識を高め、勧告を実施することを奨励する"

同局は、サイバー攻撃を防ぐための以下の提言を含むファクトシートを発表しました。

  • オフラインで暗号化されたデータのバックアップを維持し、定期的にバックアップをテストする。政府の専門家は、定期的にバックアップを実行することを推奨しています。バックアップは、その完全性を確認するために定期的にテストする必要があります。ランサムウェアの系統などの脅威がバックアップを暗号化するのを避けるために、バックアップをオフラインで維持することが不可欠です。

  • 基本的なサイバーインシデント対応計画回復力計画、および関連する通信計画を作成、維持、および実施する。米国政府機関は、ランサムウェアのインシデントに対する対応と通知の手順を含むべきサイバーインシデント対応計画を定義することの重要性を強調しています。また、政府の専門家は、被害者が重要な機能へのアクセスやコントロールを失った場合に備えて、業務を準備するためのレジリエンスプランの作成を推奨しています。

  • インターネット上の脆弱性や設定ミスを緩和し、攻撃対象を減らす。組織は、リモート・デスクトップ・プロトコル(RDP)やその他のリモート・デスクトップ・サービスを監査し、それらのサービスのベストプラクティスを推進する必要があります。使用されていない RDP のポートを閉じること、特定の回数の試行後にアカウントをロックアウトすること、多要素認証 (MFA) を適用すること、RDP のログイン試行をログに記録することなどが重要です。組織は、定期的に脆弱性スキャンを実施し、インターネットに接続するデバイスの脆弱性を特定して対処する必要があります。CISAは、インターネットに接続するシステムのソフトウェアを更新し、効率的なパッチ管理プロセスを実施することを推奨します。また、システムの設定を慎重に行い、業務で使用しないポートやプロトコルを無効にする必要があります。専門家は、SMB(Server Message Block)プロトコルのインバウンドおよびアウトバウンドを無効化またはブロックし、古いバージョンのSMBを削除または無効化することも推奨しています。

  • 強力なスパムフィルターを有効にし、ユーザーの意識向上とトレーニングプログラムを実施することで、エンドユーザーに届くフィッシングメールのリスクを軽減することができます。フィッシングの疑いを識別し、報告する方法を従業員に教育することが重要です。

  • 最新のアンチマルウェア・ソリューションとアプリケーションの使用、アプリケーション・ホワイトリストの導入、ユーザーおよび特権アカウントの制限、多要素認証(MFA)の有効化、サイバーセキュリティ・ベスト・プラクティスの実施など、優れたサイバー・ハイジーンを実践する。また、CISAは、MFAをサポートするすべてのサービスでMFAを有効にすることを推奨します。MFAは、ウェブメール、仮想プライベート・ネットワーク(VPN)、および重要なシステムへのアクセスを許可するアカウントを保護するために非常に重要です。
また、このファクトシートでは、組織が顧客や従業員の機密データを保護することを推奨しています。

CISAは、組織に以下を推奨します。
  • 組織のシステムにどのような個人情報や機密情報が保存されているか、誰がその情報にアクセスできるかを把握する。

  • 米連邦取引委員会(Federal Trade Commission)の個人情報保護に関するガイドに記載されている物理的なセキュリティのベストプラクティスを実施する。

  • 機密性の高い個人情報が保存されているコンピュータやサーバを特定し、保存中および転送中の機密情報を暗号化し、悪意のあるまたは不要なネットワークトラフィックからネットワークやシステムを保護するためにファイアウォールを導入するなど、サイバーセキュリティのベストプラクティスを実施します。また、米国政府機関は、組織はネットワークセグメンテーションの適用を検討すべきであるとしています。

  • サイバー・インシデント対応およびコミュニケーション・プランに、データ侵害インシデントに対する対応と通知の手順が含まれていることを確認する。
CISAでは、サイバーインシデント対応計画の実施について、以下のような対応をとることを推奨しています。

  • 影響を受けたシステムを特定し、直ちに隔離することで、ネットワーク運用の安全性を確保し、さらなるデータ損失を防ぎます。影響を受けたシステムをオフラインにすることができない場合は、ネットワークケーブルを抜いたり、Wi-Fiから外したりして、ネットワークからシステムを切り離します。影響を受けた機器をネットワークから取り除くことができない場合や、ネットワークを一時的に停止することができない場合は、インシデントを回避するために、それらの機器の電源を切ります。

  • その後、影響を受けたシステムの復旧・回復のためにトリアージを行い、重要度に応じて優先順位をつけます。

  • 行われた活動を記録し、予備的な分析を行う。脅威となる人物に身代金を支払ってはならない。このガイドラインでは、社内外のチームや利害関係者を巻き込んで、影響を受けた組織がセキュリティ侵害を緩和し、対応し、回復するためにどのような支援ができるかを伝えることを提案しています。組織は、影響を受けたシステム上の関連するログやアーティファクトを収集し、それらを分析することで、侵害の指標を抽出し、それを用いて感染の程度を判断する必要があります。

  • もちろん、米国政府機関は、ランサムウェアの被害者がCISA、最寄りのFBI支部、FBIインターネット犯罪苦情処理センター、または最寄りの米国シークレットサービスの事務所に事件を報告するよう呼びかけています。

CISAは7月、CISAのサイバーセキュリティ評価ツール(CSET)のための新しいランサムウェア自己評価セキュリティ監査ツール「Rransomware Readiness Assessment(RRA)」を公開しました。RRAは、組織が情報技術(IT)、運用技術(OT)、産業用制御システム(ICS)の各資産に対するランサムウェア攻撃にさらされているレベルを判断するために使用することができます。

最近話題の API や REST API 基礎編(転載)~REST は、REpresentational StateTransfer の略称~


最近話題の API や REST API ってなに? ~基礎編~:

最近よく耳にする「API」という単語ですが、「API って実際に何をしてくれるのか?」と思ったことはないでしょうか?

当記事では「API とは何か?」、更に「REST API とは何か?」についてはじめての方にもわかりやすく解説します。

1. APIとは


API は「Application Programming Interface」の略称です。

API を使用すると、2つの異なるソフトウェアが相互に通信できるようになります。 

API を使うことで実現できる事は、人がソフトウェアに対して操作を行うことに似ているので、人が電子メールソフトウェアを操作する事を例に考えてみます。

人の場合、「メッセージを開く」、「内容を確認する」、「メールを返信する」、「フラグを立てる」など操作を手動で行います。


この操作を人ではなくプログラム (Bot) で自動化したい場合、人が電子メールソフトウェアに対して行った「メッセージを開く」などの操作を代わりに実行するのが「API」です。


また API を使用すると、多くの機能を備えたアプリケーションの開発がリスク、コストを抑えて開発可能になります。

例として、レストランおすすめアプリを作成するとします。

アプリではユーザーがレストランを検索するときに、アプリが現在地情報を元にレストランのリストを作成するようにします。

このようなアプリを作成する時、昔はレストランのデータと位置情報のデータを自社のサーバー内に格納して、データを抽出するような作り方していました。

自社内で完結する設計のアプリは、アプリ全体が責任範囲となり、開発、保守工数を多く見積もる必要があります。


そこで登場するのが API です。

サードパーティから提供されている、レストランデータとマップデータを取得可能な API を探します。

API を活用することで、アプリは自社のサーバー内にデータを持つ必要がなく、API 経由でレストランデータとマップデータを得ることができるのです。


2. REST とは


REST は、REpresentational StateTransfer の略称です。

REST は API を構築するためのフレームワーク(枠組み、ルール)のひとつです。

REST に沿って作られた API (REST API)  は、シンプルでわかりやすいのが特徴です。

REST と API を組み合わせると、アプリケーションやユーザー発行する HTTP リクエストをシンプルにデザインする事ができます。

3. REST API とは


REST API の特徴として、「A に対して B をする」という作りになっています。

ここの「A に対して」を API までのリソースパス、「B をする」を HTTP 動詞と呼びます。

先のレストランアプリの例で考えてみましょう。

以下のように REST API が作成できると考えられます。

  • 「マップデータ」(リソースパス) に対して現在位置を「取得する」(HTTP 動詞)

  • 「レストランデータ」(リソースパス) に対して現在位置付近のレストランを「取得する」(HTTP 動詞)

では、もう少し具体的に、リソースパスや HTTP 動詞がどのようなものなのか、Webex の API を例に確認してみましょう。

Webex の API である「Webex ユーザーの登録者リストを取得する」API を例に確認していきます。

リソースパス


実際に「Webex ユーザーの登録者リストを取得する」API のリクエストを見てみましょう。

WebexAPI の仕様は「Cisco Webex for Developers」で確認できます。

次の仕様が、Webex ユーザーの登録者リストを取得する API です。


web サイトへアクセスする際に入力する URL に似ている構造をしています。

URL に似ているということで、ブラウザのアドレスバーから要求を送信する事ができます。

名称は URL(Uniform Resource Locator)ではなく「URI(Uniform Resource Identifier)」と呼びます。

 

この「URI」を構成する項目に「リソースパス」が存在します。

URI = プロトコール + ドメイン名 + リソースパス + パラメータ

 

「https://webexapis.com/v1/people」を「プロトコール」「ドメイン名」「リソースパス」「パラメータ」に分けてみると以下の通りです。

プロトコール :https
ドメイン名 :webexapis.com
リソースパス :v1/people
パラメータ :なし
 

「プロトコール」は http または https、「ドメイン名」は WebexAPI、GoogleAPI など各種 API で決まっているため、「リソースパス」が変更されることでどの API が呼び出しされるか決まります。

また、「パラメータ」は任意項目です。

 

リソースパス「v1/people」から「人」に対する操作であることがわかります。

HTTP 動詞


REST API に設定する HTTP 動詞は以下のものがあります。

HTTP 動詞 Action
POST 作成
GET 取得
PUT 更新
PATCH 更新
DELETE 削除

もう一度仕様書を確認してみます。


WebexAPI にリソースパス「v1/people」は2種類あるため、「https://webexapis.com/v1/people」で要求すると、「人々をリストする」と「人を作成する」のどちらの API が要求されたのか判断ができません。

ここで「HTTP 動詞」である「GET」を付けて送信すると、「人々をリストする」が要求されていることが判断できるようになります。 

「HTTP 動詞」と「リソースパス」が確認できたところで、REST API の構成である「A に対して B する」に戻ってみると、「人に対して取得する」となります。

障害多発のみずほ銀行のことを「みすぼらしい銀行」という人が多いらしい(転載)


みずほ銀行のことをみすぼらしい銀行って言ってる人いそうだなと思って検索したらいっぱいいた。

みずほ銀行で2021年9月8日に起こったシステム障害の原因が分かった。同行の勘定系システム「MINORI」において司令塔の役割を果たす「取引メイン(取引共通基盤)」のディスク装置の故障がきっかけで、一部のATMやインターネットバンキングが一時停止した。

具体的には、9月8日午前9時20分ごろ、取引メインのディスク装置が故障。みずほ銀行は取引メインのディスク装置が故障すると、同装置を切り離し、「常に同期をとって稼働している状態」(広報)の別のディスク装置だけで処理を継続する仕様だったが、その過程で「瞬断」が発生した。

この影響を受けて、最大100台ほどのATMやインターネットバンキングの「みずほダイレクト」が一時停止。同日午前10時半までに復旧した。みずほ銀行を巡っては2021年2月以降、顧客に影響が及ぶシステム障害が何度も表面化しており、今回で7回目となる。

ITmedia Security Week 2021 autumn振り返り~徳丸さんセッション。事例ベースなので、納得感がある。2段階・2要素認証はもはや常識になりつつあるか~


 徳丸さんのセッションが大変勉強になったので、メモ。

これまでのクラウドにまつわる事件・事故事例。


過去の事件・事故は下記参照

産総研

シオノギアメリカ

韓国NAYANA

仏OVHcloud

ふくいナビ

Salesforceの一連の事故

岡山大学病院

クラウドサービス事業者が行うべき主要な情報セキュリティ対策(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マイルでJAL国際線特典航空券が一層取りやすくなるタイミングを大公開!:

コロナ(武漢ウイルス)の影響もあり、なかなか海外旅行に行けない日々が続いていますが、
  • ワクチン接種率は上昇中
  • 感染者数は増加しているが、死亡率は低下中
などなど状況は1年前とは大きく変化しており、1年後には海外旅行に行けるのでは?と考えて、特典航空券の発券を検討している人や、すでに発券した人なんかもいるでしょう。

この記事では、JALマイルを利用してJAL国際線特典航空券を取るための裏技というかテクニックを紹介します。こういった情報は、当サイトの中でもかなり人気があるので、機会があれば記事化するようにしているのですが、この記事の情報もきっと読者の誰かに有益なものになるではないかなと思います。

JALマイルで国際線特典航空券を発券する際には、
  • 基本マイル数
  • JAL国際線特典航空券PLUS
という2つのものがあることは知っておきましょう。簡単に説明しておくと、


上記の東京=ニューヨークのビジネスクラス特典航空券は50,000マイルの日もあれば、146,000マイルの日もあります。この50,000マイルというのが基本マイル数で、基本マイル数で取れる枠といのは路線・機材・搭乗クラスによりJALが勝手に定めています(公開はしていません)。

この東京=ニューヨークの場合には予約開始日にはビジネスクラス特典枠が2席(ファーストクラス特典枠は1席)というのが現時点でのスタンダードなようですが、この2席がなくなれば終了というのが以前の制度でしたが、JAL国際線特典航空券PLUSという制度の導入により、必要マイル数がUPしてもいいなら枠を開放しますよ!!!ということが行われているわけです。

ただし、基本マイル数以上の大幅UPしたマイル数で特典航空券を取る人は少ないとは思うので、多くの人にとっては、必要マイル数がUPしているケースは売り切れと同義だと思います。

以前、記事にしたことがあるのですが、JALでは搭乗日直前に空席があると、その空席を特典航空券として開放してくれる傾向にあります。

この記事は2021/8/16に書いているのですが、7日後の2021/8/23のJALマイルを利用した国際線特典航空券の空席状況を羽田=ロンドンで調べてみましょう。

知らない人は、衝撃の結果ですよ。


ファーストクラス特典航空券が8席も空席ありとなっています。そもそもこの機材のファーストクラスは全座席数が8席なので、まだ1席も売れていない状況なら残りの全席を特典航空券の枠に開放してくれているということですよね。

これは衝撃的すぎます。

特典航空券の直前開放は、ANAではあまりはっきりとは出現しませんが、JALでは非常に重要なポイントになります。先ほど説明した「JAL国際線特典航空券PLUS」で一旦必要マイル数以上のJALマイルを支払った方でも、直前期に基本マイルで取りなおす(キャンセル料は必要になります)ということも、JALマイルでは有効に活用できる可能性があるわけです。

更にここ1年間の間に新しい技!?裏技!?が追加になっているので紹介しておきます。非常に重要です。

基本マイル数で取れるJAL国際線特典航空券の枠は、
  • 360日前の10:00に予約開始(この時点では基本マイルで取れる枠数はビジネスクラスで1便2席、ファーストクラスで1便1席が今は基本になっていると思われる)
  • 搭乗の1週間ほど前から直前開放で枠が増える
  • 予約開始後2週間ほどで枠が増える!?
という3つが基本になります。さて、ここで紹介したいのは3つめの「予約開始後2週間ほどで枠が増える!?」という内容になります。これは、おそらく以前にはなかったもので、この1年間の間に出現してきたようで、この1年の間にJAL国際線特典航空券を発券した人もそれほど多くないと思うので、知らない人だらけだと思います。

さて、具体的に紹介していきましょう。めちゃくちゃ使えますよ。


上記は、予約開始すぐのシンガポール=東京のJAL国内線特典航空券ビジネスクラスの枠です。全便ともに40,000マイル(基本マイル数)で2席の空席があります。この2席がなくなると、JAL国際線特典航空券PLUSが導入されて、必要マイル数がUPします。

さて、予約開始日から2週間ほど経過した日程で枠を調べてみましょう。知らない人は本当にびっくりしますよ。


基本マイル数で取れる枠が、
  • 1便目:3席
  • 2便目:9席以上
  • 3便目:8席
と謎に爆増しています。

エコノミークラスの特典枠でも、


予約開始日には、基本マイル数の12,000マイルで取れる枠が、
  • 1便目:4席
  • 2便目:すでに枠なし
  • 3便目:4席
となっています。エコノミークラス特典航空券の枠は基本4席となっているようですね。ただ、JAL国際線特典航空券PLUSでも20,500マイルで取れるのは悪くないと思います。

が、2週間ほど経過した便で見ると、


え???全便9席以上???

とやはり枠が爆増するんです。これってめちゃくちゃ有益な情報じゃないですか??これまで、基本マイル数で特典航空券を取れなくて、諦めていた人も多いでしょう。が、この記事を読んだ人には直前開放枠に追加して、「2週間後の開放枠」というものを利用してJAL国際線特典航空券を基本マイル数で取れる可能性が出現するわけです。

(注)2週間後ほどと書いていますが、おそらく11日〜14日後くらいに枠が増えます。路線により増えるタイミングが異なったりします。

この2週間後の開放枠は、JALが公表しているものでも何でもなく、いつまで継続される制度なのかもわかりませんし、そもそも2週間後の開放枠数も路線・機材・搭乗クラスにより異なります(シンガポール路線ではビジネスクラス枠が9席以上の開放もあるようですが、欧米路線ではビジネスクラス枠は最大5席だと思います。またファーストクラス特典航空券は2週間後の開放枠はないと思います)。ただ、この情報が家族旅行を検討している方には非常に役に立つ可能性があるとは思います。ぜひ、有効に活用してみてくださいね!!!

JAL国際線特典航空券を取るタイミングは、
  • 360日前10:00の予約開始時
  • 予約開始後2週間(正確には路線により11〜14日後)の開放枠
  • 搭乗1週間前の直前開放
という3つが最大の取りやすいタイミングなりますので、しっかりと頭にいれておきましょう。

バンコク・エア、ランサムウェア攻撃によるお客様の個人情報流出を確認 / Bangkok Air confirms passenger PII leak after ransomware attack(転載)~PIIは個人を特定できる情報のことで、Personally Identifiable Informationの略です。~


Bangkok Air confirms passenger PII leak after ransomware attack

タイで2番目に古く、3番目に大きい航空会社であるバンコクエアウェイズは、ランサムウェア攻撃に伴うセキュリティ侵害の際に、ハッカーが乗客の情報を盗んだことを認めました。

これは、LockBitと呼ばれるランサムウェアがダークウェブポータルにメッセージを掲載し、高額な身代金を支払わなければデータを流出させると脅した翌日の木曜日に、航空会社がプレスリリースで情報流出を確認したものです。

業界標準や、監督官庁の提示している基準・ガイドライン(転載)

セキュリティ診断だけでは不十分?アジャイル開発やDevOpsのセキュリティ対策 

Webアプリケーションの構成要素には、アプリケーション、プラットホーム、ネットワークなどの構成要素があります。アジャイル開発では、1〜2週間といった非常に短い単位で開発を進めていきます。このサイクルをアジャイル開発でよく使われる「スクラム」では、スプリントと呼びます。スプリントで開発する機能を優先度の高い順から選択して、選択した機能の開発とリリースを繰り返していきます。しかし、以下表のような非機能要件は、ある程度事前に検討して環境を準備していく必要があります。

大項目中項目説明
可用性継続性、耐障害性、災害対策、回復性システムサービスを継続的に利用可能とするための要求
性能・拡張性業務処理量、性能目標値、リソース拡張性、性能品質保証システムの性能、および将来のシステム拡張に関する要求
運用・保守性通常運用、保守運用、障害時運用、運用環境、サポート体制、その他の運用管理方針システムの運用と保守のサービスに関する要求
移行性移行時期、移行方式、移行対象(機器)、移行対象(データ)、移行計画現行システム資産の移行に関する要求
セキュリティ前提条件・制約条件、セキュリティリスク分析、セキュリティ診断、セキュリティリスク管理、アクセス・利用制限、データの秘匿、不正追跡・監視、ネットワーク対策、マルウェア対策、Web対策、セキュリティインシデント対応/復旧情報システムの安全性の確保に関する要求
システム環境・
エコロジー
システム制約/前提条件、システム特性、適合規格、機材設置環境条件、環境マネージメントシステムの設置環境やエコロジーに関する要求

非機能要件定義として挙げた例は、情報処理推進機構(IPA)が公開している「非機能要求グレード2018」から抜粋したものです。ラックのシステムセキュリティデザインサービスでは、このうちセキュリティに関わる範囲をセキュリティ要件として整理しています。

セキュリティ要件の作成においては、開発アプリケーションの特性に応じて、次表のような業界標準や、監督官庁の提示している基準やガイドラインを参考にする必要もあります。

適用例要求仕様刊行特徴
金融業界向け金融機関等コンピュータシステムの安全対策基準・解説書 第9版​金融情報システムセンター​(FISC)金融業界向け対策基準で、主に銀行が広く利用される対策基準
金融分野における個人情報保護に関するガイドライン金融庁金融業界向け対策基準で、金融業界全般で利用されるガイドライン
Webアプリのセキュリティ対策安全なウェブサイトの作り方情報処理推進機構(IPA)官公庁、公共のシステム構築案件に多く用いられるセキュリティ対策の要求仕様
認証、認可NIST Special Publication 800-63-3: Digital Authentication Guideline米国立標準技術研究所ダイレクトバンキング等でも用いられる、サービス利用ユーザのライフサイクルに関する要求仕様
ネイティブアプリ
(スマホアプリ)
OWASP Mobile Application Security Verification StandardOpenWebApplicationSecurityProjectスマホネイティブアプリ開発時に、多く用いられる要求仕様
アプリケーションのセキュリティ対策OWASP ASVS(アプリケーションセキュリティ検証標準)OpenWebApplicationSecurityProject金銭取引が行われるシステム構築時に、多く用いられる要求仕様
クラウド運用ISO27017日本品質保証機構クラウドの利用/提供に関するセキュリティ要求事項を定めた規格
システム非機能要求事項全般非機能要求グレード2018情報処理推進機構(IPA)機密性、可用性、完全性等の観点でシステムの非機能要求事項を定めたガイドライン
データの秘匿化や暗号化電子政府推奨暗号リストCRYPTREC総務省、及び経済産業省が推奨する暗号技術の評価

参照すべきガイドラインや基準は多岐に渡り、随時更新されていきます。こうしたガイドラインや基準には、具体的な実装方式などは記載されていないこともあるので、ガイドラインや基準を満たす実装方式についても情報収集と判断が必要になります。ラックのセキュリティコンサルティングサービスは、様々な業界のお客様を支援していますので、常に最新の業界動向に応じた要件と、具体的な実装方法を提示することが可能です。

2021年7月16日~31日 サイバー攻撃のタイムライン / 16-31 July Cyber Attacks Timeline(転載)


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(ロシア人および親ロシア派の個人を標的としたクリミア発の新しいキャンペーン)などの新しい脅威アクターも登場し、非常に混雑した状態が続いています。


【LINK URL】