Microsoft Threat Modeling Tool の概要 - Azure
Threat Modeling Tool は、Microsoft セキュリティ開発ライフサイクル (SDL) の主要な要素です。 これを使用すると、ソフトウェア アーキテクトは早い段階で潜在的なセキュリティの問題を特定し、危険を軽減することができます。早い段階であれば、問題の解決は比較的容易で、コスト効率も良くなります。 そのため、開発総コストを大幅に軽減できます。 また、このツールはセキュリティの専門家ではないユーザーを想定して設計され、脅威モデルの作成と分析に関するわかりやすいガイダンスが用意されているため、すべての開発者が簡単に脅威をモデリングできます。 このツールを使用すると、だれでも次の作業を行うことができます。 システムのセキュリティ設計に関して連絡する 実績ある手法を使用して、潜在的なセキュリティの問題に関して、これらの設計を分析する セキュリティの問題の軽減策を提案および管
WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が
WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が整っているわけではないです。 徳丸先生は、一般的な開発者には最低限どのレベルのセキュリティ知識を求められていますか？ 回答の難しい質問ですが、ここは本音をさらけ出したいと思います。 私が「安全なWebアプリケーションの作り方（通称徳丸本）」を出したのが2011年3月でして、それから13年以
滅びてほしい認証系の実装の話
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine
前提として、カミナシが目指しているエンジニアリング組織の形について、CTOとして以下の三つの原則をブログ記事で明示しました。 すべてはオーナーシップ 開発チーム自身がシステムを運用する SRE、QA、プラットフォームの類を安易にチーム化しない この三つの原則は、価値ある製品を顧客に届けるためには開発チーム自身のオーナーシップが不可欠であり、そのためには各チームが自らのシステムを運用する重要性、そしてSREやQAなどを単独のチームに分けないことを示しています。 チーム化の理想としては、以下の三点が挙げられます。 フォーカスによる専門領域のExecution Level 深化 チームごとの役割分担による組織全体のExecution Level 深化 希少な人的リソースの「基盤」化 各個人が専門領域にフォーカスすることでExecution Levelを高め、チームが役割を分担することで組織全体の
![[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine](https://cdn-ak-scissors.b.st-hatena.com/image/square/22d449c58c1eb5d9e28ee9350a10c50da3956732/height=288;version=1;width=512/https%3A%2F%2Fs3-ap-northeast-1.amazonaws.com%2Fassets.offers.jp%2Fmedia%2Fwp-content%2Fuploads%2F2023%2F12%2F27105156%2Freport_quality_assurance.png)
仕様が読めるようになるOAuth2.0、OpenID Connect 入門
2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらのスライドの内容は以下の本の抜粋になります。デモの内容、このスライドでは触れていないことについてご興味ある場合は以下の本をご参照ください。 https://authya.booth.pm/items/1296585 https://authya.booth.pm/items/1550861 本発表で扱っていないセキュリティに関しては以下の本がおすすめです。 https://authya.booth.pm/items/1877818 本の評判 https://togetter.com/li/1477483
何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
富士通JapanのMICJETで相次ぎ発生した証明書誤交付についてまとめてみた - piyolog
2023年3月以降、富士通Japanが提供する地方公共団体向けの住民情報ソリューションである「MICJET」(ミックジェット)において、プログラム不具合に起因するシステム障害によりコンビニ交付サービスで他人の証明書が出力されるなどの誤交付が相次ぎ発生しています。ここでは関連する情報をまとめます。 証明書の誤交付が発生した地方公共団体 富士通Japanが提供する住民情報ソリューション「MICJET」に関連した誤交付が生じたのはこれまでに8つの地方公共団体。MICJETのコンビニ交付サービスにおいて住民票の写し、印鑑登録証明書などで誤交付が発生した。MICJETを導入している地方公共団体は全国で123。*1 誤交付を行った地方公共団体 誤交付された対象 誤交付を行っていた時期 横浜市 他人の住民票（個人番号あり）の写し1件(1名) 他人の住民票（個人番号無し）の写し5件(11名) 住民票記載事
Webセキュリティ腕試しサイトを無償公開 | News | 三井物産セキュアディレクション株式会社
三井物産セキュアディレクション株式会社（本社：東京都中央区、代表取締役社長：鈴木大山、以下 MBSD） は、Webセキュリティに関する腕試しサイト「MBSD Secu-cise (セキュサイズ)」を2023年4月24日より無償で一般公開しました。 Webアプリケーションを開発した経験のない初心者の方や、腕に自信がある方、セキュリティに興味のある方など、自身のWebセキュリティに関する技術力を確かめるために無償で利用することができます。腕試し結果はスコアで表示され、他の参加者のスコアと比較することができます。 ■MBSD Secu-ciseの概要 MBSD Secu-ciseはクラウド上に構築された環境となっており、インターネット経由で誰でも参加することが可能です。課題は全7問あり、課題の内容はWebアプリケーション診断の実案件で発生した事象を題材にしています。 ■開発者の想い この度公開さ
[前編] IDトークンが分かれば OpenID Connect が分かる - Qiita
はじめに 「解説記事を幾つも読んだけど OpenID Connect を理解できた気がしない」― この文書は、そういう悩みを抱えたエンジニアの方々に向けた OpenID Connect 解説文書です。概念的・抽象的な話を避け、具体例を用いて OpenID Connect を解説していこうと思います。 この文書では、JWS (RFC 7515)、JWE (RFC 7516)、JWK (RFC 7517)、JWT (RFC 7519)、ID トークンの説明をおこないます。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 『ID トークン』を発行するための仕様 一般の方々に対しては「OpenID Connect は認証の仕様である」という説明で良いと思います。一方、技術的な理解を渇望しているエンジニアの方々に対
![[前編] IDトークンが分かれば OpenID Connect が分かる - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/0e398d0b7573fe98df626b58b433f7bd6fc5b122/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9SUQlRTMlODMlODglRTMlODMlQkMlRTMlODIlQUYlRTMlODMlQjMlRTMlODElOEMlRTUlODglODYlRTMlODElOEIlRTMlODIlOEMlRTMlODElQjAlMjBPcGVuSUQlMjBDb25uZWN0JTIwJUUzJTgxJThDJUU1JTg4JTg2JUUzJTgxJThCJUUzJTgyJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz02YWJlMjFiMTc4NWU5MzI4ZGJkODc0NjE5OTVmYmZiOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBUYWthaGlrb0thd2FzYWtpJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zODAwMGU3ZTAzMDlmYjc4MmUzOTk1MzBiYTEzZmQ2OQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Deef5016ba3dee145a5421b2d73f9ae7c)
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した
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
開発環境のセキュリティおよびCI/CDパイプラインのセキュア化
English Version is here --- 実施: セキュリティ・キャンプ全国大会2022 発表者: Hiroki SUEZAWA (@rung) 演習レポジトリ: https://github.com/rung/training-devenv-security スライド内容 : この10年で、ソフトウェアを開発する環境は大きく変化してきました。DevOpsカルチャーの浸透や、Cloud基盤の利用の増加を受け、ソフトウェアはCI/CDパイプラインを通じてデプロイされるようになりました。また、開発はオフィス内だけでなく、会社の外でも実施されるようになりました。 本スライドでは、現代のプロダクション環境を攻撃および保護するためにはどのような手法を用いることができるのか、主にマルウェアなどを用いたクライアントサイドへの攻撃や、サプライチェーン攻撃の視点から、総合的に攻撃手法および対策
仕様起因の脆弱性を防ぐ！開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。 ダウンロードは下記のGitHubリンクよりどうぞ。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。 はじめに アプリケーションの仕様起因の脆弱性とは アプリケーションの仕様起因の脆弱性を防ぐために 仕様の脆弱性によく見られる共通点 1. ク
「Firebase Authentication 7つの落とし穴」のリスクを再整理する
https://twitter.com/kuwahara_jsri のやってる朝活Twitterスペースで以下の記事を知りました。 もちろんこういったリスクを列挙、検討するのは重要なことなのですが、 Firebase Authentication関係ない話では あれ、仕様に関して勘違いしてる？ というのがいくつかあったので、再整理していきます。リスクは列挙することには業務上あまり意味はなく、評価され、リスクを受け入れるか外すかを判断するところが重要なので。 IDaaSは脆弱性を生み出すか IDaaS を導入することにより、逆に脆弱性が生まれることもあります。（中略） Firebase Authentication は他の IDaaS と比べて設定項目が少ないという特徴があります。 もちろんここに書かれてることは間違いではありません。ただ、少し実装にフォーカスが寄りすぎていると思っています。
Web開発者はもっと「安全なウェブサイトの作り方」を読むべき - Flatt Security Blog
画像出典: https://www.ipa.go.jp/files/000017316.pdf こんにちは。株式会社Flatt Security セキュリティエンジニアの奥山です。 本稿では、独立行政法人 情報処理推進機構(以下、IPA)が公開している資料「安全なウェブサイトの作り方」を紹介します。 「安全なウェブサイトの作り方」は、無料で公開されているにも関わらず、Webセキュリティを学ぶ上で非常に有用な資料です。これからWeb開発やセキュリティを勉強したいと考えている方はもちろん、まだ読んだことのない開発者の方々にも、ぜひ一度目を通していただけたらと思います。 一方、「安全なウェブサイトの作り方」では、一部にモダンなアプリケーションには最適化されていない情報や対象としていない範囲が存在します。それらについても本記事で一部、触れていきたいと考えていますので、資料を読む際の参考にしていただ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SLSA – Open Source Security Foundation
IPA、「重要情報を扱うシステムの要求策定ガイド」を公開 3ステップでシステムの要求策定を支援
セキュリティ研修【MIXI 23新卒技術研修】
IIJ、6月16日施行の「Cookie規制」 を解説〜多くのサイトやアプリが対象になり、情報の公表などが義務に 
パスワードレス時代のOpenID Connectの活用 / 20230404-OAuth-Numa-Workshop
フロントエンド開発のためのセキュリティ入門
