セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか - ぶるーたるごぶりん
セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか 自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。 新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。 ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。 本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になる
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
セキュリティエンジニアとして就職してからそろそろ3年経ちます。独断と偏見に基づき、IT初心者・セキュリティ初心者・セキュリティエンジニアの3つの時期に分け、費用対効果の良い勉強法を紹介していきたいと思います。 セキュリティエンジニアとは 「セキュリティエンジニア」という言葉は範囲が広いですが、私が今回記載する内容は脆弱性診断やペネトレーションテストに寄った内容となっています。インシデント対応やアナリスト業務などは専門ではないので、あくまで診断系の人が書いているということをご認識おきください。 そもそもセキュリティエンジニアにどのような職種が含まれるかはラックさんが分かりやすい資料を出しているのでそちらをご覧ください(サイバーセキュリティ仕事ファイル 1、サイバーセキュリティ仕事ファイル 2)。 IT初心者時代 セキュリティを学ぶ以前に基礎となるITを学ぶ時代を考えます。 学校教育 学生の場
なぜMACアドレスとIPアドレスは両方必要なのか？
この記事は，ネットワークの学習の序盤につまずくポイントである 「MACアドレスとIPアドレスってどっちか片方だけじゃだめなの？」「レイヤ2と3って結局何が違うの？」 という疑問について，私なりの回答をまとめた記事です。世に不正確な記事が出回っているように見受けられるので，正確な回答をまとめたく、長文になってしまいました。とはいえ，初学者向けにかなり初歩的なところから書いたつもりですので是非読んでみてください。 この記事について この記事を読むと何が分かるか MACアドレスとIPアドレスの役割の差が分かる レイヤ2（＝同一サブネットの通信）とレイヤ3（＝サブネット間の通信）の仕組みが分かる ネットワーク設計時にレイヤ2・レイヤ3のいずれで設計すべきか判断できる なお，教科書的な説明ではなく，概念や捉え方の説明となっていますので，試験勉強には役立ちません。実務としてネットワーク設計を行う方の役
2023年1月5日以降、2億件を超えるTwitterアカウントのデータを公開したと主張する投稿がハッカーフォーラムで行われていたことを複数の報道機関が報じました。*1ここでは関連する情報をまとめます。 自分が影響を受けたのかを確認するには 約2億件のデータに自分のメールアドレスが含まれているか（影響対象か）はHave I been pwnedを使って確認することが可能。 メールアドレス入力後に「pwned?」をクリックし、「Twitter (200M)」と表示された場合は、今回のデータに含まれている。（それ以外のリークに含まれていた場合は別のリーク情報も表示される。） メールアドレスがリークデータに含まれていた場合にTwitter (200M)が表示。 Twitter APIの脆弱性より流出したデータと主張 Twitter APIに第三者が他人のアカウント情報を取得できる脆弱性が2021年
こんにちは、ZOZOテクノロジーズで執行役員CTOをしている @kyunsです。 本記事はCTOA Advent Calendar2020の 16日目の記事となります。 この記事ではZOZOでの2年半を振り返り、テックカンパニーを目指す中でCTOとしてどのようなことに取組み、結果としてどういう変化が起きたかについて紹介したいと思います。 同じような立場のCTOやこれからエンジニアリング組織を強化していきたい方々の参考に少しでもなればと思います。 自己紹介と背景 私はヤフーに2006年に新卒で入社し、3年働いた後に当時一緒に働いていた金山と一緒にVASILYというスタートアップを創業し、受託アプリ開発や「IQON」というサービスを開発していました。 何度かの資金調達などを経て、最終的に2017年にZOZOへ売却し、ZOZOの完全子会社となりました。その後、2018年の4月には当時のスタートト
「CEOに身代金を要求したい」 こんにちは、PSIRTマネージャのただただし（tdtds）です。この記事はfreee Developers Advent Calendar 2021 18日目です。 freeeにjoinしてから早くも14ヶ月がすぎました。freeeでは毎年10月に全社障害訓練をしていて、昨年は入社したてで右も左もわからないままAWS上の本番環境（のレプリカ）に侵入してDBをぶっ壊す役目をさせられたのも良い思い出です*1。 で、上の「CEOに身代金を要求したい」という物騒な相談は、今年の訓練計画の話です。話を持ち掛けてきたのはCIOの土佐。昨年は主要サービスが落ちて、開発チームが対応にあたる中、ビジネスサイドも顧客対応などで訓練参加しましたが、今年はさらに、経営サイドまで巻き込もうというゴール設定がされたわけですね。腕が鳴ります。 ゴールは「CEOに4BTCを要求する」 ゴー
[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO
[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 DevelopersIO 2021 Decadeで登壇した動画や資料を掲載、解説をしています。AWSのセキュリティについて網羅的に扱っています。ちょー長いのでご注意を。 こんにちは、臼田です。 みなさん、AWSのセキュリティ対策してますか？(挨拶 ついにやってまいりました、DevelopersIO 2021 Decade！私は「[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]」というテーマで登壇しました。 動画と資料と解説をこのブログでやっていきます。 動画 資料 解説 動画はちょっぱやで喋っているので、解説は丁寧めにやっていきます。 タイトル付けの背景 今回何喋ろうかなーって思ってたら、2年前のDeve
![[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/675b9f7ba022b69269412062d62e4128f16d5b33/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F10%2F2021_aws_security_all_1200_630.jpg)
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
この記事は第5回Webシステムアーキテクチャ研究会の予稿です。 はじめに Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。 このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などのコンピュータ工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフト
カテゴリー DX (2) 一般 (58) 研究会 (6) 働き方 (4) 技術 (351) Edge AI (2) Edge Computing (12) Erlang (1) FIWARE (2) Fog Computing (9) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (4) RealTime Web (14) SRE (2) Webサービス (42) インフラ (7) コンテナ (3) ストレージ (92) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (214) 仮想化 (110) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティング
JP Contents Hub
AWS 日本語ハンズオン Amazon Web Services(AWS) の 日本語ハンズオンやワークショップを、カテゴリごとにまとめています。 右側の目次や、ヘッダー部分の検索ボックスから、各コンテンツにたどり着けます。 また、Ctrl + F や command + F を使ったページ内検索もご活用いただけます。 料金について ハンズオンで作成した AWS リソースは通常の料金が発生します。作成したリソースの削除を忘れずにお願いします。 もし忘れてしまうと、想定外の料金が発生する可能性があります。 画面の差異について ハンズオンで紹介されている手順と、実際の操作方法に差異がある場合があります。 AWS は随時アップデートされており、タイミングによってはハンズオンコンテンツが追いついていない事もあります。 差異がある場合、AWS Document などを活用しながら進めて頂けますと幸い
2022年4月に発生したアトラシアンのサービス停止に関するインシデント事後レビュー | Atlassian Japan 公式ブログ | アトラシアン株式会社
本ブログは、こちらに掲載されている英文ブログの意訳です。万が一内容に相違がある場合は、原文が優先されます。また、PDF版をダウンロードいただけます。 はじめに – 共同創業者兼共同最高経営責任者より 2022年4月上旬に発生した障害により、お客様へのサービス提供が中断されたことをお詫び申し上げます。私たちは、当社の製品がお客様のビジネスにとってミッションクリティカルであることを理解しており、その責任を重く受け止めています。今回の全責任は私たちにあり、影響を受けたお客様の信頼を回復するために尽力しています。 アトラシアンのコア バリューの 1 つに「オープンな企業文化、デタラメは無し (Open company, no bullshit)」というものがあります。この価値を実現する取り組みの一環として、インシデントについてオープンに議論し、学びにつなげています。そして、このインデント事後レビュ
書籍「Webエンジニアのための監視システム実装ガイド」発売！
システム監視の入門書籍を書きました わたしが執筆したWebエンジニアのための監視システム実装ガイドが2020/3/24に発売されますました。 予約受付中です。 物理書籍・Kindle共に販売中です。 PDF版なら検索もできちゃいます。 ※このエントリを書いている時点でまだ表紙がfixしていませんが、黒バックにウミガメ写真になる予定です 運用監視の会社でCTOとして勤続12年の知見を詰め込んだ、システム監視について幅広く取り扱った実践的な入門書です。 読者の方に体系的な知識と価値基準を獲得してもらえるよう努めました。 監視テクノロジの歴史や特徴、監視システムの基本動作と動作方式ごとの特徴、時系列データベース、DevOpsやSREなどのWebシステム運用の文化、SLO、SLI、Availability、Observability、自己修復システム、Chaos Engineering、監視方式の
監視について思うとこ - y-ohgi's blog
TL;DR 監視はユーザーにサービスを提供できているかを観測するための行為 SLI/SLOを定めて、SLOを守れるようにモニタリングする ダッシュボードは定常的に表示しておくものと障害時に活用するものを作ると良い アラートはレベル分けして人間が対応しなければならないものだけ人間へ通知する 監視とは サービスを健全に動作させ続けるために監視を行います。 「健全に動作している」の定義はサービスによって異なり、ユーザーにWebページを見せることができることだったり、バッチが正常に終了することだったりします。 最終的にユーザーに正常にサービスを提供できていることを観測するために行うことに変わりはありません。 さてユーザーにサービスを提供するために何を監視しましょうか？ クラウド前提であれば個人的にリソースベース（CPU/Memory）より、 SLI/SLOをベース に監視する事が望ましいと考えてい
わたしが執筆した サーバ/インフラエンジニアの基本がこれ1冊でしっかり身につく本 が2021-04-14に発売されます！！ 物理本：2021-04-14発売 Kindle：2021-04-09発売 PDF/EPUB：2021-04-09発売 →Gihyo Digital Publishing ※電子版が先行発売。時代ですねぇ 今回は表紙がとてもポップで、いままでの著書にはない雰囲気。これはこれでとてもいいカンジ。 つかいかた Webエンジニアの初期研修の1冊にピッタリだと思います。 ぜひお手にとってください！ 今回の サーバ/インフラエンジニアの基本がこれ1冊でしっかり身につく本 はインフラエンジニアの卵のためのファーストステップ本です。 広く浅くいろいろなトピックを摘めるようにしています。 本書を専門分野への足がかりにしてください。 Webエンジニアがインフラのことも知っていきたい！とい
はじめに 国内の情報セキュリティに関連する組織・情報源をまとめてみました。 組織内でセキュリティ情報を展開するときは、権威があって日本のサイトだと伝わりやすい気がします。 国民のための情報セキュリティサイト 総務省が運営しています。ITの基礎知識から一般利用者・組織向けのセキュリティ情報が掲載されています。 まさに国民のためという感じがします。 NISC 内閣サイバーセキュリティーセンター 内閣官房が運営しています。様々なセキュリティ情報があります。 SNS関連アカウントもあり情報にアクセスしやすそうです。 サイバー警察局 警察庁が運営しています。セキュリティ事案への注意喚起などが行われています。 国家公安委員会 「重大サイバー事案に係る警察活動への苦情申出」などを受け付けているようです。 防衛省 サイバーセキュリティ 注意喚起や活動内容が掲載されています。 外務省 サイバーセキュリティ
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
暗号資産を取り扱う米国のCoinBaseは、2019年6月に発生したFirefoxの脆弱性（当時ゼロデイ）を悪用した攻撃への対応を2019年8月9日にセキュリティ担当者がBlogで明らかにしました。ここでは一連の対応の顛末についてまとめます。 対応公開までの経緯 情報の公開を行ったのは米暗号資産取扱い事業者 Coinbaseのセキュリティ担当者 Philip Maritin氏。 2019年6月20日にTwitterで第一報レベルの情報共有が行われていた。 1/ A little more context on the Firefox 0-day reports. On Monday, Coinbase detected & blocked an attempt by an attacker to leverage the reported 0-day, along with a separ
【15分で確認】AWSでクラウド設計する時に覚えておきたい設計原則・アーキテクチャ３選 - Qiita
何となくAWSでクラウド設計をしていませんか AWSを利用する際、多くの方が「設計」というプロセスを簡単に飛ばしてしまう傾向にあります。しかし、クラウド環境の効果的な活用には、適切なアーキテクチャ設計が不可欠です。世の中には、システム設計をする上で指針となる設計原則がいくつかあります。本記事では、以下の３つをピックアップをしてご紹介します。 本記事で取り扱う内容 ■ マイクロサービスアーキテクチャ ■ AWS Well-Architected Framework ■ The Twelve-Factor App 1. マイクロサービスアーキテクチャ マイクロサービスは、独立した小さなサービス群でソフトウェアを構築するアーキテクチャです。これにより、迅速なイノベーションと新機能の迅速な展開が可能となります。一方、モノリシックアーキテクチャは、全てが一つのサービスとして結合され、変更や障害が全体
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
今年の医療情報技師能力検定試験に向けて、医学医療編・医療情報システム編の学習を進めてきました。toB系プログラマとして働き始めてから見てこなかった単語や発想がたくさんあって面白かったので、印象的だったところをまとめます。 医療現場はロールベースかつイベントドリブン 医療現場では（乱暴に言うと）各部門やシステムの間を「オーダ」をはじめとしたメッセージが飛び交っている、というモデル化ができそうです。 多くの役職だと何ができるかが法で定められていて、そうした役割をどう組み合わせるかも予め想定されており、そのコラボレーションをメッセージで行っているということです。 これはけっこう医療現場というものを特徴づけるものだと思っていて、パッと思いつくところでも以下のような事が考えられます： 業務の属人性を下げるための仕組みとして機能することが期待される。 アクターのTODOや期待されるアウトプットが明確。
セキュリティエンジニアを目指す人に知っておいてほしい制度やガイドライン・サービスのまとめ - FFRIエンジニアブログ
はじめに 研究開発第二部リードセキュリティエンジニアの一瀬です。先日は「セキュリティエンジニアを目指す人に知っておいてほしい組織」を公開しました。今回は、セキュリティエンジニアを目指す人に知っておいてほしい制度やガイドライン、サービスについてまとめました。こちらも、セキュリティエンジニアとして働いていると日常的に会話に出てくるものばかりです。これからセキュリティを学ぼうという方の参考になれば幸いです。なお、記載した情報はすべて執筆時点 (2023 年 7 月) のものです。 はじめに 制度・ガイドライン セキュリティ設定共通化手順 (SCAP) 共通脆弱性識別子 (CVE) 共通脆弱性評価システム (CVSS) ISMS適合性評価制度 政府情報システムのためのセキュリティ評価制度 (ISMAP) CSIRT Services Framework PSIRT Services Framewo
侵入型ランサムウェア攻撃を受けたら読むFAQ
ランサムウェアを用いた攻撃は、一台から数台の端末の感染被害から、業務停止を引き起こす大規模な感染被害に至るものまでさまざまです。本FAQでは、企業や組織の内部ネットワークに攻撃者が「侵入」した後、情報窃取やランサムウェアを用いたファイルの暗号化などを行う攻撃の被害に遭った場合の対応のポイントや留意点などをFAQ形式で記載します。 JPCERT/CCでは、こうした攻撃を他のランサムウェアを用いた攻撃と区別し、「侵入型ランサムウェア攻撃」と呼びます。 ネットワーク内部の複数のシステムでファイルの拡張子が変わり開封できなくなった、自組織から窃取されたとみられるファイルを暴露する投稿が行われた、または攻撃者から通知が届いたなどの状況を確認している場合、この攻撃の被害を受けている可能性があります。被害に遭われた企業や組織のCSIRTおよび情報セキュリティ担当の方は、インシデント対応を進める上での参考
Webアプリケーションの障害対応について改めて意識すべき点ややれると良いことをまとめる - stefafafan の fa は3つです
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
こんにちは。アドカレ12/24の記事を簡単にではありますが書かせていただきました。(25日のポストで遅刻ですが) Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2023 - Qiita はじめに 本日のテーマ：思わず天を仰いでしまうID関連システムトラブル 本日のテーマは、みんな大好き「トラブル」の話です。CIAM(Consumer Identity and Access Management)領域のさまざまなシステムにさまざまな立場で関わり、さまざまなトラブルに遭遇してきた経験を踏まえて、クリスマスの合間の気楽な読み物として記載しましたので、一息ついていただければ幸いです。 今回はトラブルの中でも思わず「天を仰いでしまう」激ヤバトラブルにフォーカスして、私的ランキング形式でお届けしたいと思います。 天を仰ぐトラブルとは？ 私
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
1年以上も検出できなかった「史上最大級の高度な攻撃」、同じ弱点は世界中に：この頃、セキュリティ界隈で（1/2 ページ） 米連邦政府機関や大手企業がSolarWindsの管理ソフト経由でサイバー攻撃を受けた事件は、調査が進むほど事態の深刻さと影響の大きさが浮かび上がっている。信頼できると思っていた取引先が踏み台にされたサプライチェーン攻撃は、厳重なセキュリティ対策に守られたはずの組織でさえ見抜けなかった。同じような弱点は至る所にある。 一連の事件が発覚したのは2020年12月。だがSolarWindsのこれまでの調査によれば、最初の不正アクセスは2019年9月に発生していた。同年10月にリリースされた同社の管理ソフト「Orion」の更新版には実験的な攻撃コードが仕込まれ、2020年2月にはフル機能を装備したマルウェア「Sunburst」が導入されて、3月から同マルウェアの拡散が始まった。 S
2020年6月に発生したドメイン名ハイジャックのインシデント対応について - coincheck tech blog
はじめまして、サイバーセキュリティ推進部の喜屋武です。 今回は2020年6月に発生したお名前.com上の当社アカウント乗っ取りによる「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚までの経緯とその後のインシデント対応についてご説明します。 1 発覚までの経緯 1.1 サービスの応答時間の遅延の確認 当社利用のドメイン登録サービス「お名前.com」で発生した事象について（最終報告） | コインチェック株式会社 でもタイムラインを記載しましたが、最初の異変は日頃からモニタリングしているサービスのレスポンスタイムが著しく遅延していたことでした。 当時のサービスのレスポンスタイム この異常を確認し、SRE チームが調査に乗り出しましたがこの段階では他に問題は確認されず、レスポンスが遅延している原因の特定には至っていませんでした。 1.2 他部署やユーザーからの問い
“LLM for SRE“の世界探索 - ゆううきブログ
ChatGPTが登場した当初、対話や要約、翻訳、コード生成などの典型的な言語タスクができても、SREやAIOpsの研究開発にはあまり関係ないのではないかと正直思っていた。AIOpsでは典型的にはいわゆるObservabilityデータ（メトリクス、ログ、トレースなど）が入力となるため、自然言語ではなく数値のデータを解析することが求められる。自然言語のタスクを研究対象としていなかったため、AIOpsとChatGPTに強い関係性は見いだせなかった*1。 しかし、自分で大規模言語モデル（Large Language Model: LLM）を日常的に使用したり、表題にあるようにSREのためのLLM（LLM for SRE, LLM4SRE）に関する論文を読むうちに、LLMのテキスト生成器としての性質よりもその優れた推論機械としての性質に注目するようになった。特にSREの障害診断は、人間の専門家が推
こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。 目的 朝当番制度は、下記を目的に運用しています。 Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う サービス品質の継続的な改善 パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する 担当エンジニアの育成 Classiシステムの全体像の理解 担当外のアプリケーション(リポジトリ)の理解 システム監視の入門(Datadog) インシデントハンドリングの入門 背景と課題 朝当番制度は、下記の背景と課題感からスタートしてい
朝日新聞編集委員（サイバーセキュリティ担当専門記者）須藤龍也 四国山地をつらぬく吉野川沿いにひらけた人口８千人ほどの徳島県つるぎ町。手延べそうめんの里で知られる静かな中山間地域の病院がいま、サイバー攻撃を受け、困難と立ち向かっている。 県西部で唯一お産を引き受けるなど、基幹病院である町立半田病院だ。10月31日未明、ランサムウェア（身代金ウイルス）によって、患者の診察記録を預かる電子カルテが失われるなど甚大な被害を被った。 救急や新規患者の受け入れを中止し、手術も可能な限り延期するなど、この日から病院としての機能は事実上、停止した。 日本におけるランサムウェアの被害で、住民生活を脅かす深刻な事態に発展した初のケースとみられる。復旧作業は今も続いており、来年1月の通常診療再開を目指している。 この未曽有の脅威から、私たちが学ぶことは何か、考えてみたい。 プリンターが吐き出した「犯行声明」 L
意外と知られてない？AWS Prescriptive Guidance（AWS規範的ガイダンス）めっちゃ使えるよ | DevelopersIO
AWS Prescriptive Guidance（AWS規範的ガイダンス）について紹介されているものが少なったので、ひょっとして未だ認知度低いんじゃないか？ということで紹介したいと思います！ AWS Prescriptive Guidance（AWS規範的ガイダンス） Amazon Web Services (AWS) Prescriptive Guidance provides time-tested strategies, guides, and patterns to help accelerate your cloud migration, modernization, and optimization projects. These resources were developed by AWS technology experts and the global communi
注意喚起や情報共有活動における受信者側の「コスト」の問題について ー情報発信がアリバイや成果目的の自己目的化した行為にならないためにー - JPCERT/CC Eyes
Top > “脆弱性”の一覧 > 注意喚起や情報共有活動における受信者側の「コスト」の問題について ー情報発信がアリバイや成果目的の自己目的化した行為にならないためにー JPCERT/CCも関わった、「サイバー攻撃被害に係る情報の共有・公表ガイダンス」[1]が今年３月に公表されました。このガイダンスでは、被害組織同士、あるいは被害組織と専門組織間のやり取りを通じた情報共有活動や被害公表をスコープとしており、主に被害組織が情報を発信する場合を中心に解説しています。他方で、多くの組織においては、情報共有活動において「情報を受け取る」側であることが大半です。また、情報共有活動に限らず、注意喚起情報など日々多くの情報を受け取っています。 今回はこの「情報の受け取り」に係る課題、特に、“自己目的化”した注意喚起や情報共有（提供）が受け取り手側にコストを与えてしまう問題点について解説し、より効果的な注
3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その3 AWS固有の優位性について) - Qiita
3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その3 AWS固有の優位性について)AWSAzureGoogleCloud はじめに 今年のはじめに書いた3大クラウドの比較シリーズに関して長いこと続編を書いてませんでした...。 最近、知人/友人のみならず取引先からも「AWSやGCPに関して続編書かないんですか？」と言われることが増えてきたので、今回はAWSを本番運用していて感じたAWS固有の優位性について感想を述べていきます。 AWS 固有の優位性 周知の事実ではありますが、AWSは長年クラウドベンダーとして世界トップシェアを維持し続けています。 AWSをクラウド基盤として利用しているサービスを一切利用せずに1日を過ごすことは不可能なんじゃないかというレベルで日本国内では利用されています。 もはや電気/ガス/水道等の社会インフラに近い状態です。 そして
はじめに 弊社では、最近BEC（ビジネスメール詐欺）のインシデント対応を行いました。この事案に対応する中で、マイクロソフト社（*1）やZscaler社（*2）が22年7月に相次いで報告したBECに繋がる大規模なフィッシングキャンペーンに該当していた可能性に気づきました。マイクロソフトによると標的は10,000 以上の組織であるということから、皆様の組織でもキャンペーンの標的となっている可能性や、タイトルの通りMFA（多要素認証）を実施していたとしても、不正にログインされる可能性もあり、注意喚起の意味を込めてキャンペーンに関する情報、および実際に弊社での調査について公開可能な部分を記載しています。 *1: https://www.microsoft.com/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm
JPCERT/CCは、Internet Week 2016 ~ 2019にて「インシデント対応ハンズオン」と題し、標的型攻撃を受けた際のセキュリティインシデント（以下、インシデント）調査手法に関するハンズオンを行ってきました。受講者の方から高く評価していただいていた「インシデント対応ハンズオン」ですが、公開の要望が多かったため、この度、GitHub上でコンテンツを公開することとしました。コンテンツは以下のURLから確認できます。 Log Analysis Training https://jpcertcc.github.io/log-analysis-training 本コンテンツは実際の標的型攻撃の事例をもとに作成しており、攻撃者のネットワーク侵入時にどのような痕跡がログに残るか、また、侵入の痕跡を発見するためにどのようなログ取得設定が必要か、をシナリオに沿って理解できる内容になっていま
「AWSセキュリティ成熟度モデルで自分たちのAWSセキュリティレベルを説明できるようにしてみよう」というタイトルで登壇しました | DevelopersIO
こんにちは、臼田です。 みなさん、AWSのセキュリティ対策してますか？(挨拶 今回はAWSセキュリティ成熟度モデルを活用して組織のセキュリティレベルを上げよう！というイベントで登壇した内容の解説です。(ちょっと前のイベントですが) 最近私が注目しているAWSセキュリティ成熟度モデルについての解説になります。 資料 解説 アジェンダは以下のとおりです。 セキュリティ対策頑張ってるってどうやって言えばいいんだ？ AWSセキュリティ成熟度モデルとは 使い方・コツ 説明できたら次のステップ セキュリティ対策頑張ってるってどうやって言えばいいんだ？ まずは課題の話から。 AWSに限らずですが、セキュリティ対策はITを扱う上で基本的なことでもあり、しかし継続的に取り組まなければいけない一筋縄ではいかない課題です。 そんな中で例えば上司から「AWSのセキュリティ対策ちゃんとやってる？」と聞かれたときにあ
より安全にご利用いただけるようになったClassiのご報告と今後の取り組みについて | Classi（クラッシー） - 子どもの無限の可能性を解き放ち、学びの形を進化させる
1.はじめに 2020年4月（昨年）、当社サービス「Classi」に不正アクセスがあった件に関し、過去一年間、弊社はこれを重く受け止め、お客様に安全にClassiをご利用いただく事を当社事業の最優先事項とし、各種対策を年間を通じ実施してまいりました。 今年度も、昨年度から継続して、サービスのセキュリティを重視した全社的な対策を実行していく所存でございますので、以下に発生直後の対応、及び今日までに実行いたしましたセキュリティ強化対策を含めて、今後の取り組みについてご報告いたします。 現在に至るまで同様の不正アクセスは起こっておらず、セキュリティ状況についても外部企業の第三者調査の結果、他社と比較して標準水準以上に強化できていると評価いただいております。また2021年3月のISO/IEC27001に基づく情報セキュリティマネジメントシステム(ISMS)の継続審査 においても、マネジメントシステ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
セキュリティエンジニアを3年続けて分かったおすすめ勉強法
Twitterから流出したとみられる約2億件のデータについてまとめてみた - piyolog
ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る｜kyuns /キュン 今村雅幸
【マジで】サイバー演習シナリオの作り方【怖い】 - freee Developers Hub
Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ
リモートワークによる孤立から結束へと向かうチームビルディング
書籍「サーバ/インフラエンジニアの基本がこれ1冊でしっかり身につく本」発売！
国内の情報セキュリティに関連する組織・情報源について - Qiita
Coinbaseがうけた標的型攻撃とその対応についてまとめてみた - piyolog
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
元toB系プログラマが医療情報技師の勉強をして面白かった部分 - Kengo's blog
思わず天を仰いでしまうID関連システムトラブル - =kthrtty/(+blog)
このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
1年以上も検出できなかった「史上最大級の高度な攻撃」、同じ弱点は世界中に
開発メンバーの保守運用スキルを上げるため実施している朝当番制度の紹介 - Classi開発者ブログ
ランサムウェア、徳島県の病院から学ぶこと – SoftwareISAC
MFA（多要素認証）を突破するフィッシング攻撃の調査 | セキュリティ研究センターブログ
ログ分析トレーニング用コンテンツの公開 - JPCERT/CC Eyes