みんなで使おうサイバーセキュリティ・ポータルサイト
みんなで使おうサイバーセキュリティ・ポータルサイト
毎日のように企業や組織を狙ったサイバー攻撃が繰り返され、その方法も次々と新しくなっています。皆さんの中にはひょっとして、小さな企業を十分守るだけのセキュリティの知識を身に付けるには「ある程度お金がかかるはず」と思っている方もいるのではないでしょうか? 実は、そんなことはありません! 内閣サイバーセキュリティセンター(NISC)は2019年4月19日、新たに「小さな中小企業とNPO向け情報セキュリティハンドブック 初版(Ver.1.00)」を公開しました。その内容は、セキュリティ本を上梓している筆者が「ぐぬぬ」とうなったほどです。これは、素晴らしい! 「どうしてこの人は、他人の本をそこまで推すの……?」と面食らった読者もいるかもしれません。この本を読んでほしいと私が考える根拠を、これから詳しく説明していきましょう。 NISCはこれまでも、個人向けに黄色い表紙の「インターネットの安全・安心ハン
海外からDDoS攻撃してくるカメラをシャットダウンしてしまうのは不正アクセスなのか?自首してみたが返答がない!そして泥沼のDDoSへ 顛末を記録した雑多なログになっているので整理されていない部分が多々あります. 2万文字を超えているので気合を入れて読むか適当に読み飛ばしてください. これでも不要な調査データを省いたりしてスリム化したのですが超巨大化してしまいました. 2018-11-07から自宅のネットワークの調子が悪すぎる 自宅のネットワークが死んでいました. J:COMの回線現在98%パケットロスするという状態になっています pic.twitter.com/Vfe0O3p5j2 — エヌユル (@ncaq) 2018年11月7日 今日の私 14時 サーバが落ちていることが通知される,サーバにDHCPがアドレス振ってくれてない 15時 ucomがついに死んだかと思いjcomに移行する 1
🤔 前書き 稀によくある 、AWS を不正利用されちゃう話、 AWSで不正利用され80000ドルの請求が来た話 - Qiita 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita AWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita ブコメ等で GitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、 本当にそんな BOT が動いているの? どのくらいの時間でキーを抜かれて、不正利用が始まるの? というのが気になったので、検証してみました。 GitHub にそれっぽいパブリックリポジトリを作成、権限が一つもついてない AWS のアクセスキー&シークレットアクセスキーをうっかり公開、外部から利用されるまでの時間を計測します。
こんにちは、エンジニアの cocoiti です。 竹迫 良範氏が8月1日付けでメルカリの技術顧問として就任したことをお知らせいたします。氏には、主にセキュリティ分野の体制強化にご尽力いただきます。 これまでもメルカリではセキュリティの取り組みとして、内部のエンジニアによる調査検証体制や、外部会社の調査を行っていました。今回、急成長するサービスや社員数増加に対応するため、セキュリティ分野の内製エンジニアの採用強化や、社内のエンジニアの体系的なセキュリティスキルの向上など、非連続的な成長が急務と考え、セキュリティ及び技術マネージメントに造詣の深い竹迫氏を技術顧問としてお迎えすることとなりました。 竹迫氏は現在、ゼクシィやスタディサプリなどを運営する株式会社リクルートマーケティングパートナーズにおいて内製開発エンジニア組織の体制強化と人材育成でご活躍されています。また対外活動として長年セキュリテ
(7/21) コメント欄の指摘を受け英訳追記 前文 本記事はGoogleのセキュリティ担当者 Parisa Tabriz氏(異名: Security Princess)のSo, you want to work in security?を翻訳したものです。 go for it!— Parisa Tabriz (@laparisa) 2016年12月25日 うっ…半年以上前… 意訳したりわからない部分もあったので、原稿の全てを反映できているか自信はありません。元ブログも是非ご一読ください。 —————————————- ここから翻訳 ————————————————- セキュリティ分野(コンピュータ、情報、サイバー…etc)でキャリアを積みたい人からメールをもらうことがある。素晴らしいことだと思う。テクノロジーを安全にしていくパション、創造性を持ち、ハードワークをこなせる仲間はいつだって必要
安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP(Minimal Viable Product:必要最低限の機能を備えた製品) のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完
PHP勉強会#110での発表資料です。
ゲームのチート対策について、技術的に見るとチートとはどういった行為であるのかを解説し、チート対策の原理や仕組みを解説します。Webアプリケーション開発におけるセキュアプログラミング等とは大きく異なるチート対策に特有のポイントを挙げ、同じく「セキュリティ」と呼ばれるものでも両者は大きく異なる技術分野であることを見ていきます。チートの多くは技術的にはそれほど難しいことをしているわけではなくチートの被害はいつでも発生しうるのだということ点を実感していただくために、Unityで作成したAndroidアプリに含まれる中間言語コードを改変する様子も紹介しています。 はじめに 情報システムが生活に欠かせないインフラとなった昨今、その開発と運用に携わるエンジニアの間にはセキュリティの意識が深く浸透しています。ソフトウェア開発の現在のメインストリームといえるWebアプリケーション開発の分野では、不特定多数の
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS(Hypertext Transfer Protocol Secure)は、HTTPによる通信を安全に(セキュアに)行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
■ [Security] Webとセキュリティとソフトウェア工学 超久しぶりに、かつ真面目な内容で更新です。 徳丸浩さんのTwitterでの 何度でも言うが、自力でトラブルシューティングできない人や組織は、自前でWordPres立ててはいけない / “一般ブロガーがAmazon Web Service(AWS)で独自ドメインのWordpressサイトを10分で作る方法…” に対して、 山田さんの(恐らく)達観したコメント「こうやってセキュリティが素人プログラマーや、見習いプログラマーを殺すんだろうなぁ。想像していたとはいえ、現実になってくると絶望しかない。」 を、 奥くんのコメント経由で見たわけです。 正直なところ、徳丸さんの元のコメントには100%同意で、山田さんもわかった上での達観なんだと思うのです(少なくとも「批判」ではないと思う)が、 ソフトウェア科学→セキュリティ→ソフトウェア工
RSAの公開鍵暗号技術を利用するためには、鍵や証明書のファイルを扱う必要があるため、そのファイルフォーマットについて理解しておく必要があります。 実際、いろんな拡張子が登場するので、それぞれの意味を理解していないとすぐにわけがわからなくなります。そんなときのために備忘録をまとめてみました。 ファイルの拡張子の注意点 .DERと .PEMという拡張子は鍵の中身じゃなくて、エンコーディングを表している デジタル暗号化鍵やデジタル証明書はバイナリデータなのですが、MD5のハッシュ値のような単なる 値 ではなく、データ構造をもっています。.DERや .PEMはそのデータ構造をどういうフォーマットでエンコードしているかを表しています。そのため、.DERや.PEMという拡張子からそのファイルが何を表しているのかはわかりません。暗号化鍵の場合もあるし、証明書の場合もあります。 .DER 鍵や証明書をAS
はじめに サーバ管理をしている身としては、 セキュリティ は常に付きまとう悪魔みたいなもので、このセキュリティに関しては何をどこまで頑張ればいいのか不透明な部分が多い。 脆弱性に関しては、CVEなど、毎日情報は入ってくるが、それがどのサーバの何に関連したものなのかなんていちいち調べてられないし、どの脆弱性がすぐに対応しなければいけないもので、どの脆弱性があとあと対応すればいいものなのかなんてわからない。 実際のところ、大きな話題になった脆弱性くらいしか緊急で対応してないという人は多いのではないかと思う。 そんな中、満を持して登場したのが vuls !! 各サーバの脆弱性情報を取得して、個々のサーバそれぞれでどんな脆弱性があり、どのくらいやばい脆弱性なのかを検知できるようになった! 今回はこのvulsを紹介します。 Vulsとは 公式でロゴが発表されたので、差し替えました 公式ドキュメント:
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない?どこまではわかってる?」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」をNGワードに指定 僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」 妻「うん」 僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く