「クレカを止めても不正利用が止まらない」のメカニズム【鈴木淳也のPay Attention】
パスキーの基本とそれにまつわる誤解を解きほぐす
2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。
IT系コミュニティをタダ飯狙いの不審者からどう守るべきか。あるイベントで発生した深刻な事案と提言
タダ飯狙いでIT系コミュニティのイベントなどに入り込む人たちがいる、ということが少し前から話題になっている中で、実際に不審者がイベントに入り込もうとした事案がまた明らかになりました。 12月11日と12日の2日間、都内で開催されたコミュニティ主催の技術系カンファレンスで、おそらくは無料の食事を目当てにした不審な人物らが侵入しようとした出来事が発生していたことがイベントの当事者の発言で示されています。 スタッフとして不審者に対応した一人である鍋島理人氏は、「勉強会参加者や運営に危害が及ぶほどの脅威であり、必要なのは不審者対策そのものだと認識を改めた。というか僕はそれぐらい怖かった」とポストし、今回の事態の大きさを吐露しました（鍋島氏は以前、翔泳社でDevelopers Summit（通称デブサミ）のオーガナイザーを勤めたこともある、イベントやコミュニティの運営に関して十分な知見を備えた人物で
SDDLで学ぶWindowsのアクセス制御 - ラック・セキュリティごった煮ブログ
北原です。 今回は、Windows OSを守るセキュリティ機能の中でも重要な役割を担う、アクセス制御に関する話題を解説します。 UnixやLinuxでは「Everything is a file」と言われていますが、Windows OSではファイルやプロセスをはじめとする全てのものがオブジェクトとして管理されており、それぞれが ACL（Access Control List：アクセス制御リスト） によりアクセス制御されています。 ACLは、アカウントに与えているアクセス権限を個別に定義した ACE（Access Control Entry：アクセス制御エントリ） と呼ばれる情報のリストです。 例えば、Windows OSでファイルのプロパティを開くと、以下の図のようにACLが視覚的に確認できます。 DACLの確認例 ファイルやディレクトリなどでは、Windows OS標準の機能でこのように
踏み台にはECSコンテナを。～ログイン有無を検知して自動停止させる～ - NRIネットコムBlog
こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません！！コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ
自宅ルータの脆弱性検知システムの開発 - Sansan Tech Blog
Sansan 技術本部 情報セキュリティ部 CSIRT グループの川口です。 2023年4月からセキュリティエンジニアで新卒として、Sansan に入社しました。 現在は ログ基盤（SIEM）のログの取り込み部分の機能修正、問い合わせ対応、インシデント対応などの業務に取り組んでいます。 今回は内定者インターンシップで開発した、自宅ルータの脆弱性検知システムについて紹介します。 目次は以下の通りとなります。 開発に至った経緯 作成したシステム 技術的な話 EDR ポートスキャン チケットシステムへの起票 SOAR まとめと今後の課題 開発に至った経緯 新型コロナウイルスの流行に伴い、リモートワークという言葉をよく耳にするようになったと思います。 弊社でも緊急事態宣言下においては、原則リモートワークとなり、現在はオンライン・オフラインを併用した働き方をしています。 ここで問題となってくるのが自
CVSSとその限界 | ドクセル
長谷川陽介(はせがわようすけ) セキュリティ・キャンプ協議会代表理事 （株）セキュアスカイ・テクノロジー 取締役CTO 千葉大学 非常勤講師 OWASP Kansai ボードメンバー OWASP Japan ボードメンバー CODE BLUEカンファレンス レビューボードメ ンバー Webブラウザー、Webアプリケーションに 関する多数の脆弱性を発見。 Black Hat Japan 2008、韓国POC 2008、2010、OWASP AppSec APAC 2014他講演や記事執筆も多数。 https://utf-8.jp/ Vuls祭り#8 #vulsjp https://utf-8.jp/
OSINTツール「GreyNoise」を使ってみる - セキュリティ猫の備忘録
こんにちは、セキュリティ猫です。 久しぶりに（ホントに久しぶりに）何かを書きたい欲が出てきたので、自分でも使い方の整理・機能の確認の意味を込めてツールの使い方を扱うことにしました。 今回は、調査で便利なツール「GreyNoise」について紹介していこうと思います。 GreyNoise はじめに 【注意事項】 GreyNoiseとは？ 機能 IPルックアップ GREYNOISEクエリ言語 (GNQL) タグトレンド その他の機能 主な使い方 まとめ はじめに 【注意事項】 本記事内で、GreyNoiseの使い方や調査方法について記載しています。本内容は脅威から守るために利用しているものであり、決して悪用することはしないでください。 GreyNoiseを利用することで外部組織の情報を得ることができます。しかしながら、ここで得られた情報をもとにアクセスは行わないでください。アクセスを行う場合は自
ドメインやサブドメインを調査する話（後編） | 技術者ブログ | 三井物産セキュアディレクション株式会社
<前編> ・ドメイン・ネットワーク帯を調査する手法 ・ドメインの調査 ・JPRS whois ・ICANN Registry Listings ・ネットワーク帯（IPアドレス）の調査 ・JPNIC whois Gateway ・BGP Tool kit ・その他の調査 ・検索エンジンを使った調査 ・Webサイトのクローリング ・Google AdSense ・公的データベースの活用 ・gBizINFO ・公開情報調査（Passive型の検索サービス） ・Robtex ・PassiveDNS ・viewdns.info ・Microsoft Defender Threat Intelligence ・違うTLDを試す ・RDAP サブドメインを調査する方法 様々な手法で収集した、ドメインとIPアドレス情報をもとにサブドメインを列挙するフェーズです。ドメイン/ネットワーク帯（IPアドレス）調査
ドメインやサブドメインを調査する話（前編） | 技術者ブログ | 三井物産セキュアディレクション株式会社
気がついたら数年ぶりのBlog投稿でした。お手柔らかにお願いします。 さて、今回取り上げるのは、ドメインやサブドメイン、保有ネットワークを調査する手法（相手方に影響を与えない縛りです）を思いつくままに紹介していきます。ドキュメントとして纏まっているものもあまり見かけなかったので、重い腰を上げて書いてみました。この他にもこんな方法がある！などフィードバックを頂ければとても喜びますので、是非よろしくお願いします。 目次 <後編> ・サブドメインを調査する方法 ・IPアドレスを起点にサブドメインを探す ・公開ポートへのアクセス（Webポート） ・＜通常コンテンツの返却＞ ・＜エラーページの返却＞ ・＜リダイレクト＞ ・公開ポートへのアクセス（Webポート以外） ・証明書の確認 ・＜Webサーバの場合＞ ・＜SSL/TLSで保護されたプロトコルの場合＞ ・＜プロトコル内で暗号化(STARTTLS)
ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
サーバーセキュリティ構成の話 - Chienomi
序 最近、安易に建てられた危険なサーバーが増えているため、サーバーセキュリティを鑑みた基本的な設定や構成はどういうものかという話をする。 本記事では具体的な設定や構築を説明するが、環境や前提、用途などもあるため、これを真似すれば安全ということではない。 セキュリティは銀の弾丸があるわけではなく、全ての要素を合わせて考えたア上での最適を導かねばならない。それがセキュリティの難しいところでもある。 本記事はセキュリティが未熟だと自認する人にとっては参考になる内容だと思うが、どちらかというと、本記事の内容が当たり前に「すでに理解できている内容」になっていない人は、サーバーを建てるべきではない(危険な未熟の段階である)ということが重要であり、各々が自身の技量を測る指標として使ってもらえればと思う。 宣誓の儀 「サーバーを破られるということは、すなわち犯罪に加担するということである」 この言葉をしっ
DNSの不正使用手法をまとめた技術ドキュメントの公開 - JPCERT/CC Eyes
はじめに Domain Name System（DNS）はインターネットサービスを使用する上で欠かせない基幹サービスであり、DNSが関連するセキュリティインシデントへの対処は、健全なインターネットを維持するために重要です。本ブログでは、JPCERT/CCもメンバーとして参加しているFIRSTのDNS Abuse SIGが、2023年2月に公開したDNS Abuse Techniques Matrixについて、その日本語版をJPCERT/CCが主体となり作成および公開したので紹介します。 2023年2月、FIRSTのDNS Abuse SIGが公開したDNS Abuse Techniques Matrix - DNS Abuse Techniques Matrix https://www.first.org/global/sigs/dns/DNS-Abuse-Techniques-Matri
フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
Wi-Fiルーターのサポート期間 - Qiita
はじめに Wi-Fiルータのセキュリティについて、2023年4月5日に警視庁より「家庭用ルーターの不正利用に関する注意喚起」が行われました。この中で対策として、次の4つが挙げられています。 初期設定の単純な ID やパスワードは変更する。 常に最新のファームウェアを使用する。 サポートが終了したルーターは買換えを検討する。 見覚えのない設定変更がなされていないか定期的に確認する。 定期的な設定確認が現実的に可能なのか疑問はありますがそれはさておき、今回は３番目のサポート終了についてです。 たとえばWindowsであればいつサポートを終了するのかずいぶん前に告知がありますし、他のソフトウェア製品についてもLTS(Long Term Support)の設定があるものは計画的にアップグレードを行えます。一方で家庭用のWi-Fiルーターについて、いつサポートが終了するのかわからないまま買っていまし
フィッシングサイト自動テイクダウンの手法
はじめに 日常的なインシデント調査を効率化するために、自動化による分析は、フィッシング詐欺の分析者にとって重要な課題となっています。 クラウドベースの技術は、効率的にフィッシング詐欺の分析を自動化するための良い解決策です。 今回は、クラウドサービス上でのフィッシング詐欺分析とGoogle Safe Browsing(GSB)を活用した自動テイクダウンの方法について解説していきます。 フィッシングキットの解析結果についてこちらで更に詳しく解説しています。 対象読者 インフラ管理者 DevOpsエンジニア 脅威ハンター フィッシング攻撃の流れ よくあるフィッシング詐欺の流れを以下に示します。 攻撃者はホスティングサーバーを購入する 購入したサーバにフィッシングキットをアップロードしセットアップする 動作確認を完了させた攻撃者は潜在的な被害者に大量のフィッシングメールを送信する 被害者はフィッン
セキュリティ関連費用の可視化 ：IPA 独立行政法人 情報処理推進機構
近年、サイバー攻撃が複雑高度化しており、サイバー攻撃が事業継続に及ぼすリスクはどんな企業であっても見逃すことはできません。また、企業が新たな価値創出をし、競争優位性を高めるためにはDX(デジタルトランスフォーメーション)の推進が欠かせません。 これらの課題に取り組む上で、企業のセキュリティ対策は不可欠ですが、実際に自社にセキュリティ製品やサービスを導入するためには、社内予算を確保する必要があります。 しかし、予算権限を有する経営者は必ずしも情報システム(IT)、制御システム(OT)のセキュリティ分野に関する知見があるわけではありません。 そのため、企業のセキュリティ担当者にはセキュリティ対策を経営者が理解できるような言葉で説明することに苦悩し、自社のセキュリティ対策を遂行するための予算確保に苦労する方が多いと考えております。 セキュリティ対策を遂行するための予算を上手く確保できない原因とし
RSAの終わりの始まり - 暗号移行再び - Qiita
前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗
仮想マシンイメージの脆弱性検知をTrivyに組み込んだ話 - masahiro331の日記
はじめに 実際に作ったもの ここから先が長すぎて面倒だという方向け なぜVMのスキャンが必要なのか？ 全体像 Trivyの脆弱性検知について 開発する上での課題 アーキテクチャ Storage層 EBS Storage Virtual Machine Image層 Disk Partition層 Logical Volume層 Filesystem層 & File層 苦労したこと&学び 処理が重すぎる問題 仕様書の英語が読めない とにかく人に頼る 巨大なバイナリファイルを読むのが辛い 感謝の念（一番大事） 最後に はじめに 2022年11月にOSSのコンテナ脆弱性検知ツール Trivy に 仮想マシンイメージ（VMDKやVDIなど）の脆弱性検知機能を追加しました。 今回はこの機能を追加した苦労話や具体的な技術について解説したいと思います。 技術話を書くと、正直クソ長文章になることは明白なの
2020年6月に発生したドメイン名ハイジャックのインシデント対応について - coincheck tech blog
はじめまして、サイバーセキュリティ推進部の喜屋武です。 今回は2020年6月に発生したお名前.com上の当社アカウント乗っ取りによる「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚までの経緯とその後のインシデント対応についてご説明します。 1 発覚までの経緯 1.1 サービスの応答時間の遅延の確認 当社利用のドメイン登録サービス「お名前.com」で発生した事象について（最終報告） | コインチェック株式会社 でもタイムラインを記載しましたが、最初の異変は日頃からモニタリングしているサービスのレスポンスタイムが著しく遅延していたことでした。 当時のサービスのレスポンスタイム この異常を確認し、SRE チームが調査に乗り出しましたがこの段階では他に問題は確認されず、レスポンスが遅延している原因の特定には至っていませんでした。 1.2 他部署やユーザーからの問い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
