なぜ、SSL-VPN製品の脆弱性は放置されるのか ～“サプライチェーン”攻撃という言葉の陰で見過ごされている攻撃原因について～ - JPCERT/CC Eyes
Top > “インシデント”の一覧 > なぜ、SSL-VPN製品の脆弱性は放置されるのか ～“サプライチェーン”攻撃という言葉の陰で見過ごされている攻撃原因について～ サイバーセキュリティを取り巻く「用語」は元々英語由来のものが多く、翻訳することで元々のニュアンスが消えてしまう場合や、そのまま「カタカナ語」として使われ、意味が伝わりにくい場合もあります。特に、新たな攻撃手法やリスクについて、行政やセキュリティ専門組織、メディアを通じた情報発信において多用される「キーワード」の意味が正しく伝わらなければ、見当違いな対策につながってしまう恐れがあります。 今回は「サプライチェーン攻撃」として取り上げられることがある、大企業の下請企業が侵入型ランサムウェア攻撃被害に遭うケースを「大企業のサプライチェーン」の観点ではなく、主な侵入原因であるSSL-VPN製品の脆弱性放置の問題というインシデント対応
「AWS全体のセキュリティ管理と快適なセキュリティ運用」というタイトルで登壇しました | DevelopersIO
こんにちは、臼田です。 みなさん、AWSできるマンの人材育成してますか？(挨拶 今回は、2022年4月8日に実施したAWSトレーニング・人材育成ウェビナー 今あなたが学ぶべきAWSセキュリティにてお話した内容をブログにまとめます。 資料 解説 私の内容の解説の前に少し追加の情報を。 今回のイベントでは私の前に「怖がらずにセキュリティと向き合うために」というタイトルで、アマゾン ウェブ サービス ジャパン合同会社 セキュリティ アシュアランス本部 本部長の松本照吾さんにご登壇いただきました。怖がらずにセキュリティと向き合うために、どう考えてどう取り組めばいいか、大変良く分かる内容でした。ぜひ松本照吾さんが他の場で登壇されるのを見かけたら、話を聞いてみてください。 では私のセッションの話を。 私のセッションのテーマは「AWSセキュリティを理解して便利に運用しよう」です。よく一般ではITのセキュ
Let's EncryptのDST Root X3ルート証明書の期限切れとOpenSSLの影響についていろいろ試してみた
Let's Encryptでこれまで長く使用されてきたIdentrust社発行のDST Root X3ルート証明書が、日本時間2021年9月30日23時1分15秒に期限切れになりました。十分時間を取って事前に移行計画や影響範囲、救える環境、救えない環境などアナウンスをしてきましたが、やはり、期限切れ以降、様々なサービスや製品で接続できないといった声が上がってきました。 特にOpenSSLに関しては、OpenSSL 1.0.2以前に影響があると9月13日に事前の注意喚起がOpenSSL公式ブログであったにもかかわらず、製品やサービスの奥底で使われていて気づかなかったのか、様々なOSや製品で古いものが組み込みで使われていたために影響が広かったように思います。 OpenSSLからの注意喚起の概要 2021年9月30日にLet's EncryptのDST Root X3ルート証明書の期限が切れるに
え、HTTPSの転送なのにファイルも暗号化するんですか？？？
TL;DR 基本的には二重での暗号は不要 ただし、転送後も暗号化したまま使うなら、転送前から暗号化するのは良い ルールXを無邪気に追加して不整合のあるセキュリティルールを作ってはいけない はじめに 社内のセキュリティルールやスタンダードを決めるときに、HTTPSなのにVPN必須になってたりファイル暗号も必須になってたりするケースたまに見ます。今回は、それは実際に必要なことなのか？ セキュリティ的に有効なのか？ という点で考察をしていきたいと思います。 背景 二重三重に暗号化しても性能ペナルティが無いなら「なんとなく安全そうだから」でOKにしてしまいがちなのですが、これはよく考える必要があります。 というのも 「ルールXを追加することで既存のルールAと不整合が出る」 ってことは割とよくあるからです。具体的には「SCPのファイル転送は（SCPのセキュリティに不備があった時の）安全性のためにファ
SELinux を踏み台サーバに使ってみた話
これは ビットバンク株式会社 Advent Calendar 2020 の 17 日目の記事です。 はじめに 皆さん setenforce 1してますか？ AWS エンジニアの koarakko です。 普段は DevOps や 統制周りの業務を担当しています。 今回は踏み台サーバでの SELinux 活用事例を交えながら実際にポリシー調査から実装までの方法を紹介したいと思います。 SELinux を本番利用している環境は少なく、貴重な経験ができたと自負しています。 この記事を読むことで SELinux の本番利用の一助になれば幸いです。 当社の踏み台の活用背景 踏み台サーバは本番アプリサーバにログインする場合に経由サーバとして利用しています。 OS は RHEL 8 で2台構成です。 当社では踏み台サーバを２年程度使っていますが、この間に踏み台サーバの置き換えもしています。 以前は am
OAuth 2.0 を参加者全員がある程度のレベルで理解するための勉強会を開催しました | DevelopersIO
現在私は barista という OpenID Connect と OAuth2.0 に準拠したID製品の実装を行っています。 また、私の所属する事業開発部では prismatix というEC、CRM の API 製品の開発を行っていますが、この prismatix の認可サーバーとして barista を利用しています。 barista チームの増員や、prismatix の認可についての理解を促進するため OAuth 2.0 をある程度しっかりと理解しているメンバーを増やしたかったので、勉強会を開催しました。 勉強会の内容 概要 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本を全員で輪読 OIDC 編はこのあとやる予定 攻撃編もやりたい RFC 読んだりもしたい 参加者全員が以下を満たすことが目標 OAuth 2.0 の意図を理解
SSLサーバー証明書は2年物を買ってはいけない - orangeitems’s diary
SSLサーバー証明書は2年物を買うべきではない 今日の今日、今の今知ったことですが、たくさんの人に知られるべきだと思ってまとめます。サーバー証明書を購入する時、たいてい「１年」「２年」が選べると思います。更新作業は面倒なので、２年を選びたくなる方がいらっしゃると思いますが、この「２年」に大きな落とし穴があります。端的に言えば「１年」を購入するべきです。 その理由は、AppleのSafariにあります。 その理由 下記の記事を見てください。 ssl.sakura.ad.jp AppleがSafariブラウザにおいて、2020年9月よりSSL証明書の最大有効期間を398日に短縮すると発表しました。突然発表された本対応の経緯やその影響、私たちがこれから取るべき対策についてご紹介します。 Appleの発表は2020/3/3です。もう一か月も経過するのに結構誰も知らないのではないかと思います。最近の
焼肉サブスクの脆弱性 - Qiita
※規約違反として限定公開にされました。Qiita運営からのメールに「Qiitaだけじゃなくて他サービスの規約違反もあかんのやで」という文言があったので、そのへんに気をつけて修正しました。 本記事はすべてフィクションです。実在する企業とは一切関係ありません 焼肉サブスクに２２日通った。 その中で、色々な脆弱性が見受けられたため、詳しく書く。 ※この記事で紹介する脆弱性を実際に突いてサービスを不正利用すると、詐欺罪に問われる可能性があるので、絶対にやらないこと。また、この記事は啓蒙を目的としており、システムの悪用を推奨していない。 焼肉サブスクのシステム サブスクプラットフォームに登録し、クレカでサブスクパスに課金する。 店でパスの画面を見せる。画面には１日１回だけ押せるボタンがあり、ボタンを店員の目の前で押すことで、サービス権を行使する。食べ放題が無料になる 最後にレジで会計するが、食べ放題
利用省庁ゼロで廃止された政府共通プラットフォームのセキュリティ機能についてまとめてみた - piyolog
2019年10月8日、読売新聞は総務省が開発費約18億円をかけ政府共通プラットフォーム上に導入したセキュリティ機能が各省庁から一度も使用されずに廃止されたと朝刊一面で報じました。ここでは関連する情報をまとめます。 誰も使わなかったセキュリティ機能 報じられたのは「セキュアゾーン」と呼称されるセキュリティ機能。*1 政府共通プラットフォーム上に実装され、インターネットからは遮断された環境で利用する。 2015年6月に発生した日本年金機構の不正アクセス事案を受け導入が決定されたもの。 平成27年度総務省所管の補正予算案で「一億総活躍社会の実現に向けて緊急に実施すべき対策」の1つに計上されていたとみられる。 (2) 政府情報システムのセキュリティ対策 33.8億円 政府共通プラットフォーム及び新たな共通ネットワークにおけるセキュリティ対策（情報システムのインターネットからの分離、インターネット接
18億円の国のサイバー攻撃防止機能 未使用で廃止 使い勝手悪く | NHKニュース
サイバー攻撃などからの情報の漏えいを防ぐため、およそ18億円をかけて開発された国の情報管理システムが、運用を始めてから２年間一度も使われず廃止されていたことが会計検査院の調査で分かりました。 この機能はおよそ18億円かけて開発され、外部からのサイバー攻撃などを防ぐとされていましたが、会計検査院が調べたところ、平成29年度の運用開始から２年間一度も使われていなかったことが分かりました。 インターネットから遮断されているため、データを入力する際に手間がかかるなど使い勝手が悪かったということです。 維持費もかかるためことし３月にすでに廃止されたということで、会計検査院は運用を行っていた総務省に再発防止を求めることにしています。 総務省は「検査を受けている最中なのでコメントできない」としています。
総務省からのJPドメイン名の管理・運用に係る要請受領について | 2019年 | JPドメイン名についてのお知らせ | 新着情報一覧 | JPRS
2019/04/26 公開 JPRSは、本日、総務省からJPドメイン名の管理・運用に係る要請を受領しました。 JPRSでは、引き続きJPドメイン名の信頼性確保のための取り組みを進めてまいります。
運用担当者のためのAWS改善マップ | DevelopersIO
Trusted Advisor AWS Trusted Advisorは、コスト、パフォーマンス、セキュリティ、耐障害性、サービスの制限について、アドバイスしてくれるサービスです。 サポートプランによって、チェック項目が異なります。 セキュリティについては、セキュリティグループの無制限アクセス、S3バケット許可などをチェックしてくれます。 セキュリティについては、赤の指摘項目は0にしましょう。 insightwatch insightwatchは、弊社が提供するサービスです。 AWSアカウントが、ガイドラインに沿ったセキュリティのベストプラクティスで運用されているかチェックします。 複数アカウントをチェックしやすいため、たくさんのアカウントを運用されているかたに特にお勧めします。 どなたでも無料でご利用いただけます。 IAMの見直し、定義 IAM のベストプラクティスに基づいた見直しを行い
IPAテクニカルウォッチ「CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント」：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構）セキュリティセンターは、ウェブサイトへの情報セキュリティインシデントが後を絶たないことを受け、ウェブサイトの構築・運用に用いられるCMS（コンテンツマネジメントシステム）に着目し、その脅威と対策、および構築・運用のポイントを解説した“IPAテクニカルウォッチ”「CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント」を9月28日（水）に公開しました。 下記より「CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント」についてのレポートPDF版をダウンロードしてご利用いただけます。 1．CMSとは 2．CMSで構築されたウェブサイトを狙う攻撃と対策 3．CMSを使ったウェブサイト構築・運用のポイント 4. チェックリスト 【別冊付録】ウェブサイト構築・運用のポイント 1. ウェブサイトを構築する上での注意点 2. ウェブサイトの運用開
これからのITインフラ運用で「品質」「スピード」「セキュリティ」を実現する10の具体策
これからのITインフラ運用で「品質」「スピード」「セキュリティ」を実現する10の具体策：システムインテグレーションとセキュリティ（6）（1/2 ページ） 社内システムの開発・運用担当者向けにセキュリティ対策のポイントを紹介する本連載。最終回は、セキュリティを含めた「ITインフラ運用」全般の勘所を解説します。 連載目次 社内システムの開発・運用担当の方々に向けて、社内システムにおけるセキュリティ対策のポイントを解説する本連載。前回は、「社内メールシステム」に焦点を当て、セキュリティ対策の勘所を紹介しました。今回は、これからの企業の「ITインフラ」を健全に保つ運用方法について、セキュリティ対策だけでなく、より包括的にポイントを整理します。 ITインフラ運用で実現すべきこと ITインフラは、「ハードウェア基盤」と「ソフトウェア基盤」から構成されます。ハードウェア基盤は、サーバ、ネットワーク、スト
安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
ウェブサイトの脆弱性や運用管理の不備を悪用された情報漏えいやウェブページの改ざんなどの被害が多数発生しています。情報漏えいやウェブページの改ざんなどの被害が発生すると、ビジネスやサービスの中断、停止、またそれによって生じた損失への補償など、事業に直接的な影響が生じる恐れがあります。 安全にウェブサイトを運用管理するためには、下記図が示す対象ごとに適切な対策を実施することが必要です。どれが欠けても、ウェブサイトの安全性は確保できません。 ウェブサイト運営者、システムおよびネットワーク管理者は、下記の「ウェブサイトのセキュリティ対策のチェックポイント20ヶ条」を確認し、対策がとられていない項目があった場合には早急に対策をしてください。 ウェブサイトのセキュリティ対策のチェックポイント20ヶ条 ここに記載されている対策は、定期的に確認する必要があります。 1．ウェブアプリケーションのセキュリティ
ウェブサイトに侵入された大学のリリースに見る侵入対策への誤解
ここ数日大学等のウェブサイトに対する侵入事件の報道やプレスリリースが続いています。 スケジュール管理ウェブサイトの改ざんについて – 早稲田 サイバー攻撃：徳島大電子会議システムサーバー乗っ取り - 毎日新聞 これらを読んで気になったことがあります。大学側が一定のセキュリティ対策を施していたが、それでも侵入されてしまったような論調だからです。まずは早稲田大学の事例ですが… ３．不正侵入の原因について スケジュール管理サーバにはアンチウィルスソフトウェアをインストールし、最新のパターンファイルを装備していました。しかし、当該サーバのOSのセキュリティパッチは最新のものではなく、また当該サーバに対しファイアウォールによる監視が行えていなかったため、不正侵入を防御できませんでした。現在は、OSのセキュリティパッチを最新のものに更新し、ファイアウォールの監視対象として防御しています。 スケジュール
JPRS/（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について（2014年11月5日公開）
--------------------------------------------------------------------- ■（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策 について（2015年5月26日更新） 株式会社日本レジストリサービス（JPRS） 初版作成 2014/11/05（Wed） 最終更新 2015/05/26（Tue） （JPドメイン名におけるレジストリロックサービスの提供を反映） --------------------------------------------------------------------- ▼概要 JPRSでは2014年9月から10月にかけ、国内の組織が運用する複数の.comサイ トが、ドメイン名の登録情報の不正書き換えによるドメイン名ハイジャック の被害を受けたという情報を入手しました。この攻撃手法では
ソニー銀行は金融機関としてAmazonクラウドをどう評価し導入したのか？ AWS Summit Tokyo 2014
ソニー銀行は金融機関としてAmazonクラウドをどう評価し導入したのか？ AWS Summit Tokyo 2014 7月17日と18日の2日間にわたって都内で開催された「AWS Summit Tokyo 2014」での大きなトピックは、金融機関がクラウドの採用を明らかにしたことでした。1日目の基調講演ではマネックスグループ代表執行役社長CEOの松本大氏が登壇し、クラウドの採用を表明。 そして2日目のセッションでは、ソニー銀行のシステム企画部 マネージャー 基盤統括担当 大久保光伸氏が、同社によるAmazonクラウドの評価と導入について詳しい説明を行いました。 1年前のAWS Summit Tokyo 2013は、企業の基幹業務をクラウドへ移行する事例が相次いで発表されたイベントでした。それから1年がたち、金融機関もついにクラウドを基盤として採用し始めたことになります。 本記事では、ソニー
大規模障害から1年余り、あの企業が「その後」を語った
「この度は取材をお受けしましたが、どう対応したらよいか。今でも迷いがあります」。担当者は取材の冒頭で、心境をこう吐露した。 記者は取材のためレンタルサーバー事業を手掛けるファーストサーバ（本社：大阪市）を訪れた。1年半ほど前に、顧客企業が利用していたサーバー約5700台のデータをほぼ消失させる大規模障害を起こした事業者だ。 今回の取材は、過去に失敗を経験した複数の企業や公的団体に申し込んだ。目的は、「IT運用の失敗から技術者がどう学び、再発防止に取り組むべきか」をまとめる企画記事を執筆するためだ。 中でもファーストサーバは、運用のプロであるべきITベンダーが、一部とはいえ現場担当者のずさんな運用作業を見逃していた実態が明るみになり、個人としても大きな衝撃を受けた。失敗を経てどう体制を立て直したのか、大いに興味があった。 「非技術者」にも分かる再発防止策を：ファーストサーバ 簡単に、ファース
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
