2024/10/5 YAPC::Hakodate 2024
背景 サイバーインシデント発生時にセキュリティ担当者はその被害の封じ込め、復旧対応のために現場から経営層までさまざまな部署の担当者と円滑に連携して対応していく必要があります。このように組織一体となってサイバーインシデントに対応し、状況を回復していく力を「サイバーレジリエンス」といいますが、このサイバーレジリエンスを実現していくためには多くの企業が以下のような課題を抱えていると考えています。 1.同じ企業の中の部署であっても、それぞれの部署がもつ専門性や文化の違いからサイバーインシデント対応において必要な連携の 中でコミュニケーションエラーが発生しやすい可能性がある。 2.サイバーインシデントを体験したことがある担当者が限定的であるため、対応のために必要なコミュニケーションスキルに個人差 がある可能性がある。 そこで本プロジェクトでは、事業会社において、サイバーインシデント対応時の他部署との
神奈川県ネット出願システムのGmailへのメール到達性問題は、不適切なサーバー設定、大量メール送信、DNSミス、バウンスメール処理不備、急激な送信量増加、準備不足、新ドメインの低信頼性が複合的に作用して発生したと推測されます。 2024年1月、神奈川県のネット出願システムでGmailにメールが届かないトラブルが発生しました。 身内が受験するため、出願システムのトラブルに巻き込まれた当事者として原因調査を試みていました。 先日『日経クロステック』より、本件について取材を受ける機会がありました。 取材協力した記事で取り上げられた問題について、さらに深堀り、詳細な分析を行った内容を以下に紹介いたします。 問題の概要 概要 志願者登録時、二次元コード読み取りと空メール送信が必要 "@gmail.com"アドレスへの返信メールが届かない不具合発生 原因 システムのメールサーバ設定が不十分 大量メール
2024年6月9日、KADOKAWAやニコニコ動画などを運営するドワンゴは、同グループの複数のWebサイトが6月8日未明より利用できない事象が発生と公表しました。システム障害の原因はランサムウエアによるもので、ニコニコ動画は復旧まで約2か月を要しました。またリークサイトから盗まれたとみられる情報を取得してSNSへ公開するなど悪質な情報拡散が確認されました。ここでは関連する情報をまとめます。 1.KADOKAWAグループのデータセンターでランサムウエア被害 公式及び報道より、データ暗号化の被害にあったのはKADOKAWAグループ企業 KADOKAWA Connectedのデータセンター(DC6)で運用されていたプライベートクラウドやそのクラウド上で稼働していたドワンゴ専用サーバー。またドワンゴの認証基盤であったActive Direcotryサーバーも攻撃者の制御下に置かれた。 侵害活動の拡
近年、ビジネスを取り巻く環境は大きく変化しています。国際環境に目を向けると国家間の対立などにより、事業者にとっては周辺国のリスクを考慮したサプライチェーンの見直しが必要になってきています。 また、技術環境に目を向けると、国家間の距離をなくすインターネット上に生成AIなどの技術が加わり言語の壁も低くなってきています。今まで国際的な対立は対岸の出来事と思われていましたが、非軍事領域でのサイバー攻撃は、今まさに国内でも行われている状況です。 現状、戦後最も厳しく複雑な安全保障環境に直面し、サイバー攻撃による重要インフラの機能停止や破壊、機微情報の窃取などは、国家を背景とした形でも平素から行われています。重要インフラは国民生活や経済活動に欠かすことができずこれらの脅威によって重要インフラが停止した場合の影響は計り知れません。 このようなことから、重要インフラ事業者向けに今まで想定しないようなリスク
2024年6月21日にデジタル庁からデジタル認証アプリの発表がありました。 このデジタル認証アプリで何ができるのか、ざっくり整理してみました。 この記事で対象としている方 デジタル認証アプリの概要についてざっくり理解したい方 デジタル認証アプリについて今北産業してほしい方 この記事では技術的な話はなるべく避け、全体像を整理していきます。 技術的な話を理解したい方は、参考リンクより他の方が書かれた記事を参照してみてください。 「デジタル認証アプリ」はどんなものか? 「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。 (デジタル認証アプリサービスサイトより引用) デジタル認証アプリは、デジタル庁が提供するデジタル認証アプリサービスAPIと組み合わせて1つのサービス(デジタル認証アプリサービス)を構成しています。デジタル認
TL;DR Fakenet-NG を改造して、証明書のエラーなく任意の通信先に対して HTTPS の通信を行わせるための備忘録です 実質 MitM をさせる Proxy を作るための話になります TL;DR はじめに 環境構築 0. 事前準備 1. 通信先情報の取得 ドメイン(ホスト名) IPアドレス 2. 自己署名証明書の作成 3. Proxy Listener への組み込み 4. テスト おわりに はじめに マルウェア解析の動的解析環境(Sandbox 環境)を構築する際、TLS/SSL を用いた HTTPS 通信をどのようにして取得して分析可能とするかというのは一つの至上命題です。マルウェアがC2サーバと通信する際に TLS/SSL を使う場合はもちろんそのやりとりの中身を記録したいですし、解析環境検知のためにメジャーなWebサービスに対して HTTPS でダミー通信を発する場合もあ
年表について NPO日本ネットワークセキュリティ協会(JNSA)が設立された2000年から2024年まで、社会で起きた出来事と共にサイバーセキュリティに関連した話題を年表にしました。JNSAの活動も併せてご覧いただけます。 当年表は、JNSAメンバーが調査に基づき作成したものです。 リンクでの参照や内容に不適切な点がある場合は、こちらの引用問合せをご利用下さい。なお、ご連絡いただいた内容への個別のご返信は行っておりません。 (ご注意とお願い)当コンテンツは、JNSAが独自の見解で編集しております。掲載している時事の話題やリンク先については、当時を振り返ることができるテーマとできるだけわかりやすい解説があるURLを選定しており、政治的、社会的な意図があるわけではございません。また掲載内容については、ご自身の責任の下で閲覧、利用下さいます様お願いいたします。
FIDOアライアンスが仕様を策定した「パスキー」は、パスワードではなく生体情報を用いて認証する「FIDO 2.0」を「Webauthn」標準に基いて利用して得た資格認証情報をデバイス単位で管理運用する技術です。このパスキーが抱える問題点について、Webauthn標準に関わったエンジニアのFirstyearことウィリアム・ブラウン氏が自身のブログで解説しています。 Firstyear's blog-a-log https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ Webauthnがパスワードに代わる認証技術として大きな可能性を秘めていると考えていたブラウン氏は、2019年にオーストラリアからアメリカに渡り、友人と共にWebauthnのRust実装であるwebauthn-rsの開発を始めました。その過程で
総務省は、今般、令和4年10月に公表した「クラウドサービス利用・提供における適切な設定のためのガイドライン」の内容を、わかりやすく解説するために「クラウドの設定ミス対策ガイドブック」を策定いたしました。 総務省では、クラウドサービス利用・提供における適切な設定の促進を図り、安全安心なクラウドサービスの利活用を推進するため、クラウドサービスの提供者・利用者双方が設定ミスを起こさないために講ずべき対策や、対策を実施する上でのベストプラクティスについてとりまとめた「クラウドサービス利用・提供における適切な設定のためのガイドライン」を、令和4年10月に策定・公表しました。 今般、クラウドサービスを利用する事業者において、情報の流失のおそれに至る事案が引き続き発生している中で、本ガイドラインの活用促進を図るため、ガイドラインの内容をわかりやすく解説した「クラウドの設定ミス対策ガイドブック」を策定しま
総務省は、本日、LINEヤフー株式会社(代表取締役社長 出澤 剛、法人番号 4010401039979、本社 東京都千代田区)に対し、同社における、不正アクセスによる通信の秘密の漏えい事案に関し、通信の秘密の保護及びサイバーセキュリティの確保の徹底を図るとともに、再発防止策等の必要な措置を講じ、その実施状況を報告するよう、文書による行政指導を行いました。 LINEヤフー株式会社(代表取締役社長 出澤 剛。以下「LINEヤフー社」という。)からの報告により、同社及び同社のITインフラの運用に係る業務委託先であるNAVER Cloud社が、それぞれセキュリティに係るメンテナンス業務を委託していた企業においてマルウェア感染が生じたことを契機として、NAVER Cloud社の社内システムが侵害されるとともに、同社を介して、同社とネットワーク接続のあったLINEヤフー社の社内システムに対して不正アク
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
こんにちは。アドカレ12/24の記事を簡単にではありますが書かせていただきました。(25日のポストで遅刻ですが) Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2023 - Qiita はじめに 本日のテーマ:思わず天を仰いでしまうID関連システムトラブル 本日のテーマは、みんな大好き「トラブル」の話です。CIAM(Consumer Identity and Access Management)領域のさまざまなシステムにさまざまな立場で関わり、さまざまなトラブルに遭遇してきた経験を踏まえて、クリスマスの合間の気楽な読み物として記載しましたので、一息ついていただければ幸いです。 今回はトラブルの中でも思わず「天を仰いでしまう」激ヤバトラブルにフォーカスして、私的ランキング形式でお届けしたいと思います。 天を仰ぐトラブルとは? 私
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く