サマリ ISO-2022-JPという文字エンコーディングの自動判定を悪用したクロスサイト・スクリプティング(XSS)攻撃について説明する。これは、文字エンコーディングを適切に指定していないウェブコンテンツに対して、文字エンコーディングをISO-2022-JPと誤認させることでバックスラッシュが円記号と解釈されることによりエスケープ処理を回避する攻撃である。本稿で紹介する攻撃は、従来からのセキュリティベストプラクティスである「文字エンコーディングの明示」に従っていれば影響を受けることはない。 はじめに クロスサイト・スクリプティング対策として、記号文字のエスケープ処理に加えて、コンテンツの文字エンコーディングをレスポンスヘッダやmetaタグで明示しましょうと言われてきました（参照）。その背景として、UTF-7という文字エンコーディングを悪用したXSSの存在がありました。この攻撃については以下

List of all executables vulnerable to the WorstFit Attack! This is the tracking list for all vulnerable executables affected by WorstFit Attack. You can refer to this mapping viewer to check how crazy the best-fit mapping is! For more info, please refer to our research: WorstFit: Unveiling Hidden Transformers in Windows ANSI! Found a WorstFit Vulnerability? Try to add it to the list! 😉

危機管理室の吉本です。 デジタルIDの認証に関するガイドラインであるNIST SP800-63-4のSecond Public Draft（第2次公開草案）が更新されていたので、変更箇所をまとめてみました。全体で467ページと相当なボリュームがあるので今回調べたのは、主に話題になっているSP800-63B-4のパスワード要件についてです。初期公開草案からなにが変更されているか知りたかったので調べたことをまとめます。 NIST SP800-63-4とは NIST SP 800-63-4は、アメリカ国立標準技術研究所（NIST）が提供する、認証やID管理に関する「デジタルアイデンティティガイドライン」の第4版を指します。 全体概要の文書と3つの関連文書に分かれており、下記のタイトル毎に策定されています。 SP 800-63-4：Digital Identity Guidelines（デジタルア

2024/10/5 YAPC::Hakodate 2024

1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin

A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team

背景 昨今のサイバーセキュリティの取り組みの一環として、「脅威インテリジェンス」が注目されていますが、その取り組みが指し示す内容や、事業会社が具体的に実施すべき事項があまり明確にされていないなどの課題があると感じました。 そこで当プロジェクトでは、様々な文献やツール、サービスを利用し、脅威インテリジェンスの概要・概念からその効果、ライフサイクルを整理し、またプロジェクトメンバーで実際に脅威インテリジェンスの取り組みを実践することで、事業会社が取り組む内容の一部をケーススタディとしてガイドラインにて紹介しています。 ガイドラインを活用することで、経営層に脅威インテリジェンスの必要性と導入を提案でき、また運用箇所に目的と運用事項を説明できる内容で構成しています。 また、従来組織が取り組んできたフレームワークやガイドライン、チェックリストをベースとした「コンプライアンス型アプローチ」では、昨今の

SANS Asia Pacific DFIR Summit 2023 Keynote | CSIRT に求められる情報収集と分析の要点 講演者: 根岸征史 組織の CSIRTにおいてサイバー攻撃による被害の発生を未然に防ぐ、あるいは最小限に抑えるためには、日々の情報収集と分析、そして影響評価にもとづく適切な対応が不可欠です。本セッションでは最近のインシデント事例などをもとに、CSIRTにおける情報収集、分析、評価の課題を検討し、解決の方向性を探っていきます。 #APACDFIRSummit #Cybersecurity #DFIR

背景 本プロジェクトは、ICSCoE7期生において、実業務で脆弱性対応を行う際に、日々公表される全ての脆弱性に対応しきれないという問題や、CVSS（Common Vulnerability Scoring System）基本値のスコアを脆弱性の対応優先度を決めるために利用するには不十分であると考え、これを解決すべく立ち上げられた。CVSS基本値が脆弱性そのものの深刻度を評価する点では有用であるものの、脆弱性の悪用状況やユーザの環境情報を考慮していないため、脆弱性対応の優先度を決定するために、単体で使用するのは適切ではないと考えた。また、CVSSやEPSS（Exploit Prediction Scoring System）などのリスク評価値を脆弱性対応の優先度付けに使用する場合、適切な閾値を設定する必要があると判断した。これらを踏まえて、評価値の妥当性や効率的な運用方法がないかという点につ

JTCのセキュリティマネージャのニキヌスです。 これまでの記事で事業会社におけるセキュリティ業務を紹介（※）してきました。 今回は、地味だが大変な「相談対応」の話です。 私が所属するセキュリティチームには、毎日、約2000人のIT部門メンバから大量の相談が届きます。 これを4～5名で対応していますが、中にはそちらに手を取られて自分のプロジェクトが進められなくなったり、労働時間が伸びてしまったりする人もいます。 相談をどう効率よくうまく捌くか？は意外と文章化されていないように思うので、これまでに身につけた自分のやり方を書いてみます。 セキュリティ相談とは 相談のゴール 相談対応の流れ 1. 相談内容の把握 2. 責任範囲の確認 3. 全体像の把握 4. 脳内簡易脅威モデリング 5. 論点の整理 6. 調整～回答 さいごに （余談）セキュリティ相談 今昔物語 ※セキュリティ業務に関する過去記事

Developer Productivity室の @uncle__ko です。 サイバー攻撃のニュースなどが盛り上がり、セキュリティについて取り沙汰されることが多い昨今。 開発生産性においてもセキュリティ対策はとても重要です。 今回は開発生産性とSecurity Shift Leftについてまとめようかと思います。 DORAの定義するCapabilitiesにおけるSecurityFourkeysなどを提唱しているDORA（DevOps Research and Assessment）が、組織がソフトウェアの提供と組織のパフォーマンスの向上を促進するためにもつべきものを定義していたりします DORA | CapabilitiesDORA is a long running research program that seeks to understand the capabilities

An essential part of shipping software securely is red teaming. It broadly refers to the practice of emulating real-world adversaries and their tools, tactics, and procedures to identify risks, uncover blind spots, validate assumptions, and improve the overall security posture of systems. Microsoft has a rich history of red teaming emerging technology with a goal of proactively identifying failure

「ISC2 Japan Chapter勉強会 2024/07」の登壇スライドです。 ※ Speaker Deck上だと太文字が滲んでいるため、手元にダウンロードしてPDFを見ると鮮明に閲覧することができます。 - https://sites.google.com/isc2chapter.jp/mee…

2024年7月11日に実施された「Classmethod Odyssey 情シスとセキュリティ編」の登壇資料です。 こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。 本日開催された「Classmethod Odyssey ONLINE 情シスとセキュリティ編」で登壇する機会を頂きました。 本記事はその登壇資料紹介となります。 資料 セッション概要 近年被害が拡大しているDDoS攻撃。そんなDDoS攻撃を緩和する対策はWAFの活用や攻撃対象領域の縮小など様々ありますが、その中でも特にAWSサービスを用いた方法について分かりやすく網羅的にご紹介します。 DDoS対策の参考になりそうなブログ セッション内で紹介したAWSのサービス、機能について参考になりそうなブログをいくつかご紹介します。(後日追記あるかも) CloudFront+S3による静的サイトにCogni

こんにちは！イーゴリです。 AWS にとって、クラウドのセキュリティは最優先事項です。(AWS公式ページ) AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。AWS Well-Architected Frameworkを考慮しながらの設計を推奨します。AWS Well-Architected Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。 とてもざっくり説明しますと、AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基本的に「セキュリティ」の柱を技術的観点から見てみたいと思います。 AWS Well-Architected Framew

ウェルスナビの開発に関する記事を定期的に発信しています。 「ものづくりする金融機関」への取り組みを知っていただければ幸いです。

デジタル社会を実現するためには、「共通ルール」の下で関係者が協働し、価値を生み出すことが重要です。 デジタル社会推進標準ガイドライン群は、サービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理についての手続・手順や、各種技術標準等に関する共通ルールや参考ドキュメントをまとめたものです。 各ドキュメントの位置づけには、次の2種類が存在します。 標準ガイドライン（Normative）：政府情報システムの整備及び管理に関するルールとして順守する内容を定めたドキュメント実践ガイドブック（Informative）：参考とするドキュメントこれまでは、「デジタル・ガバメント推進標準ガイドライン群」という名称で各種ガイドラインを策定しておりましたが、デジタル庁として政府内部だけでなく社会全体のデジタル化を推進するという観点から、これらのドキュメント体系の名称について「デジタル社会推進標準ガイド

日々巧妙化しているサイバー攻撃に対応していくには政府組織内におけるサイバーセキュリティ対策をより高度化していく必要があります。米国政府では、サイバーセキュリティ対策を高度化するにあたり、CDM（Continuous Diagnostics and Mitigation）プログラムの導入が進んでいます。日本政府においても、米国のCDMプログラムを参考に、常時リスク診断・対処（CRSA: Continuous Risk Scoring and Action）システム（以下、「CRSA システム」という。）の導入を進めています。 概要CRSAとはCRSAとは、組織のセキュリティポリシー等に準拠するために情報システムに導入された必要なコントロール（管理策）に関して、以下を実施します。 リスク診断：必要なコントロールと実際の状態とのギャップやリスクを可視化対処：可視化されたギャップやリスクの是正対応