本書では情報セキュリティ対策の一環であるセキュリティ監視を実現するための方法として、セキュリティ監視の基盤を自分で構築するために必要となる実践的な設計・実装方法について紹介します。セキュリティ監視基盤を内製する方だけでなく、既製ソフトウェア・サービスを利用して基盤構築しようとしている方にも参考になれば幸いです。

今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」(Gitがわかっているとでも思っているか?)発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"(記録ずみ解決方法を再利用)の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
この記事は Go Advent Calendar 2018 の16日目の記事です。 Golangでプログラムを書く時にログを吐くの、どうしてますか? 本記事ではログを吐く際のコツというか気にして欲しい事項と、 なぜそうなるのかを解説していきます。 一概に「ログを吐く」と言っても、 ライブラリからログを吐く場合とアプリケーションから吐く場合では 相当に事情が異なります。 TL;DR ライブラリ(パッケージ)を書く時は… まずログを吐かないことを検討しましょう。 error で返してライブラリのユーザーにログへ吐かせるかどうかを選ばせましょう。 *log.Logger を使いましょう。 デフォルトは log.Printf に対して吐き(またはそれと同等のログを吐く)、 ライブラリユーザーの設定で任意の *log.Logger に切り替えられるようにしましょう。 自前の Logger インターフ
SharePointとは SharePointはMicrosoftが提供する企業向けのサービスで、ファイル等を保存、整理、共有するためのWebサイトを作成することができるサービスです。 SharepointはMicrosoftの他のサービス(Teams、OneDrive)とも関連しており、Teamsでは、チームを作成すると自動的にSharePointのサイトも作成されます。 また、OneDriveとは機能的に似通う部分もありますが、SharePointが組織全体でのファイル共有を目的としたサービスであり、OneDriveは個人のファイルを保存、共有する目的で使用されます。 SharePointのファイル共有 Microsoftの監査ログについて説明したページでは、 SharePointの監査シナリオとして、外部ユーザーと共有されているリソースの識別について解説しています。 SharePoi
サイトの攻撃を見える化する。 Web攻撃ログ分析ツール Loggol -ロゴル Loggolは、Webサーバのアクセスログを分析し、 あなたのWebサイトがいつ 誰に どのように攻撃されているのか、 隠された攻撃の痕跡を検出します。 まずは無料トライアル Webサイトのアクセスログには、セキュリティに関する様々な情報が含まれています。 しかしながら、「分析のための人手と時間が足りない」「分析に必要な技術がない」「ログの量が多い」等の理由で、Webサイトのログを分析しないまま放置しているケースが多く見受けられます。 その結果、未知の脅威や脆弱性を狙った重大なサイバー攻撃の兆候が見落とされる可能性があり、WebサイトやWebアプリケーションのセキュリティを確保することが難しくなっています。
Hello there, ('ω')ノ この三連休で、Twitterにアップしたデジタルフォレンジックに関係するツール等は以下のとおりで。 Windowsのイベントログについて検索するのに便利なデータベースサイトは、いろいろとあります。 https://www.ultimatewindowssecurity.com/ 日本でよく知られているのは、Elastic Stackでしょうか。 https://www.elastic.co/jp/downloads/ インシデント発生前に組織がログに記録する方法と内容、それらのログを維持する方法を明確に定義することが重要で、ログ管理ポリシーや関連する手順内で確立する必要があります。NISTがログ管理の簡単なガイドを公開しています。 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
広告技術部のUTです。 最近はカービィディスカバリーをゆっくりやってます 概要 過去の失敗 どうやったか 仕組み 結果 まとめ 概要 昨今ではデータドリブンな意思決定を重視する企業がどんどん増えており、データを活用することにより事業成長へのインパクトを出そうとしています。 データを事業へと活用するためには、蓄積されるデータを分析するために保管しておく必要があります。 弊社も創業時からデータを蓄積し事業に活用することに力を入れてきた企業の一つであり、日々大量のログが収集されています。 またAWSアカウントを複数運用していますが、一番データ量の多い広告アカウントのS3にはペタバイトレベルのデータが保管されています。 普段何気なく使っているデータレイクとしてのS3ですが、少量であれば無視できるくらい小さいので、コストを気にせず使っておられる方も多いのではないでしょうか? そのようなS3でも巨大な
log4j_rce_detection.md log4j RCE Exploitation Detection You can use these commands and rules to search for exploitation attempts against log4j RCE vulnerability CVE-2021-44228 Grep / Zgrep This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log This
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く