タグ

ブックマーク / xtech.nikkei.com (91)

  • セキュリティー略語SASE・CSPM・SOC・SOAR・UEBA・IRM、いくつ分かる?

    近年サイバー攻撃は勢いを増していて、ここ数年はその動きがより顕著だ。その傾向はJPCERTコーディネーションセンターへのセキュリティー事故(インシデント)の報告に表れている。 報告件数は2019年度まで1万5千件から2万件程度と高水準で推移してきた。だが2020年度には前年度の2.5倍にまで増加した。 2021年末ごろからはマルウエアの活動も今まで以上に活発になっている。トレンドマイクロの調査によれば、2021年12月に国内でマルウエア「Emotet」を検出したセキュリティー機器の台数は2467台だった。これは同年11月の524件と比較し約5倍となっている。2022年1月は2398台となり、年が明けても高い水準が続く。 そのような状況に対し、セキュリティー対策を打つ側も黙って見ているだけではない。現在のサイバーセキュリティー環境に対応するような新しい製品やサービスが次々と登場。それに伴い、

    セキュリティー略語SASE・CSPM・SOC・SOAR・UEBA・IRM、いくつ分かる?
  • 京都市がシステム刷新失敗、「悲劇を繰り返すな」とご意見番

    京都市が2014年から81億円を投じて進めていた基幹系システム刷新プロジェクトが失敗した事案が、ついに訴訟合戦に突入する。2017年12月8日、京都市議会(京都市会)は門川大作市長名義で提出された訴えの提起を全会一致で可決した。刷新が遅延した原因となったバッチ処理のマイグレーション(開発言語と業務ロジックを引き継ぐ移行)を受託したITベンダーのシステムズ(東京・品川)に対する訴えである。 システムズは2億円を求め、京都市は8億円を求める 京都市の情報システム部門に当たる総合企画局情報化推進室の担当者は日経コンピュータの取材に対し、訴訟額は約8億円、正確には7億9976万2365円となると回答。内訳は既にシステムズに支払っていて返還を求める額が5億662万5000円、稼働遅延に伴う既存システムの延長稼働などの損害賠償金が2億2043万1696円、弁護士費用が7270万5669円という。 もと

    京都市がシステム刷新失敗、「悲劇を繰り返すな」とご意見番
  • 総務省がAI開発ガイドライン作成へ、透明性や制御可能性など求める

    総務省が、人工知能AI)の開発ガイドラインの策定に乗り出した。自動運転、チャットボット、マッチングなど分野を問わない共通の開発原則として、透明性や制御可能性、プライバシー保護などを企業に求める。 同省は、論点を整理した文章を2016年末に公開した。2017年1月31日まで広く意見を募集する。同年6月末に案を取りまとめる考えだ。 AIの開発指針を巡っては、欧米を中心に議論が進んでいる(表)。総務省は広く国内企業や専門家の意見を集めたうえで、経済協力開発機構(OECD)などに先進国共通のAI開発ガイドライン案として提案することで、国際的な議論を主導したい考えだ。 総務省が示す開発原則は、透明性、制御可能性、セキュリティ確保、安全保護、プライバシー保護、倫理、利用者支援、アカウンタビリティの八つだ。 透明性の原則では、AIの挙動を後から検証できるよう、入出力データやログの保存など、技術の特性に

    総務省がAI開発ガイドライン作成へ、透明性や制御可能性など求める
  • 博多駅前の陥没、NATMで掘削中に出水

    午前5時15分頃、福岡市のJR博多駅前に位置する博多駅前2丁目交差点付近で、道路が幅27m、長さ30m、深さ15mにわたって陥没する事故があった。現場の地下では、地下鉄七隈線の延伸工事を実施中。隣接工区のシールド機がUターンするための空間を、大成建設JVがNATMで構築している最中に出水した。 道路全体が大きく陥没した事故現場。陥没穴には水がたまり、巨大な池のようになった。生コン車とポンプ車が横付けされ、流動化処理土による埋め戻しが始まっている。正面奥はJR博多駅。11月8日午後3時45分ごろ撮影(写真:日経コンストラクション) 事故が起こったのは「福岡市地下鉄七隈線博多駅(仮称)工区建設工事」。施工者は大成建設・佐藤工業・森組・三軌建設・西光建設JV。契約金額は112億9800万円(税込み)、工期は2013年12月から19年3月だ。 同工区の延長は東西に合計279.3m。このうち東側の

    博多駅前の陥没、NATMで掘削中に出水
  • JTBの事故対応手順が明らかに、非公開の報告書を読み解く

    ジェイティービー(JTB)は2016年6月24日、個人情報が流出した可能性がある問題で観光庁に報告書を提出、引き続いて国土交通省で2回目の会見を開いた(関連記事:「経営課題という認識が不足」、679万人のJTB情報漏洩可能性が残す教訓)。 JTBは会見で、「観光庁への報告書とほぼ同じ内容」(JTB)とする報道用資料を配布。同社のWebサイトなどでの公表予定はないというが、マルウエアの感染からJTBの子会社やセキュリティ会社がどう対応していったかが詳細に記されている貴重な資料と言える。以下ではその内容を記述する。自分ならどう対応できたか、想像しながらお読みいただきたい。 発端は2016年3月15日。旅行商品をインターネット販売する子会社であるi.JTB(アイドットジェイティービー)がWebサイトで公開する、問い合わせを受け付ける代表メールアドレスに、攻撃者が取引先になりすました標的型メールを

    JTBの事故対応手順が明らかに、非公開の報告書を読み解く
  • 事前準備ゼロで「情報セキュリティマネジメント試験」を受けてみた

    春の嵐が吹き荒れた4月17日の日曜日。休日にもかかわらず、記者は朝から東急大井町線の尾山台駅に立っていた。経済産業省傘下の情報処理推進機構(IPA)が実施する「情報セキュリティマネジメント試験」を受験しに来たのである(写真1)。試験会場は尾山台駅徒歩15分。多摩川にほど近い東京都市大学の世田谷キャンパスである。 情報セキュリティマネジメント試験は経産省所管の国家試験「情報処理技術者試験」の新たな試験区分として今回から実施される新しい試験だ(ITpro関連記事:セキュリティの新しい国家試験「情報セキュリティマネジメント」が来春開始)。 具体的には、「情報セキュリティマネジメントの計画・運用・評価・改善を通して組織の情報セキュリティ確保に貢献し、脅威から継続的に組織を守るための基的なスキル」を認定する(外部リンク:IPA「情報セキュリティマネジメント試験」紹介ページ)。典型的なお役所文書で、

    事前準備ゼロで「情報セキュリティマネジメント試験」を受けてみた
  • 判明、ANAシステム障害の真相

    大型のシステム障害の詳細が見えてきた。全日空輸(ANA)が2016年3月22日に起こした国内線旅客システム「able-D(エーブルディ、以下では便宜上開発コード名のANACore:アナコアと称す)」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。 ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。 4台のSuperdomeをRACでクラスタリング 今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース(DB)サーバーが停止したというもの(関連記事:ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン)。今回、弊誌

    判明、ANAシステム障害の真相
  • ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン

    同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。 スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」(同)。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。 ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、うち日で8700台を販売しているが、今回の不具合は初めての事象と聞いている」(ANA広報)。なぜ「故障シグナル」が発信できなかったかは分かっていない。 1台での縮退運転を決断 4台の完全停止から37分後、ANAは1台のDBサーバー

    ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
  • クラウドは性能不足、企業システムが重過ぎる

    無限とも思えるコンピュータリソースを擁するパブリッククラウド。ところが、新年早々のユーザー企業への取材で「クラウドは性能不足」との声が相次いだ。いずれもオンプレミス(サーバー設置型)で利用する業務システムをクラウドに移行しようとして壁に突き当たった。 「まさか、最初から最高性能のサービスを使うことになるとは思わなかった」。こう話すのは、社内システムのクラウド移行を積極的に進めるA社のIT担当者。サーバーをはじめハードウエアの調達や保守作業をオフロードする目的で、IaaS(インフラストラクチャー・アズ・ア・サービス)を活用する方針である。同社がつまずいたのが、販売管理や営業支援で活用するCRM(顧客関係管理)パッケージだ。 検証目的でクラウド上で動かしてみたところ、オンプレミスよりも遅い。原因を調べると、CPUがボトルネックとなり、データベース(DB)で遅延が発生していた。IaaSでは、仮想

    クラウドは性能不足、企業システムが重過ぎる
  • なぜCCCはプライバシーマークを返上し、T会員規約を改訂したのか(前編)

    カルチュア・コンビニエンス・クラブ(CCC)は2015年11月17日、TポイントやTSUTAYAレンタルといったT会員向けサービスの規約(T会員規約)を同年12月1日に改訂すると発表した。 改正個人情報保護法に合わせて個人情報の項目を明確化したほか、個人情報の取り扱いに関するセキュリティ標準「JIS Q 15001」に準拠するとの項目を削除。同時に、このJIS Q 15001への適合性を評価する「プライバシーマーク(Pマーク)」を返上した。 これに代わり、「JIS Q 15001」「JIS Q 27001(ISMS)」などのセキュリティ標準を参考にした自社基準を策定し、「時代の変化や急速に発展するIT技術に対応できるセキュリティ環境」(CCCのお知らせより)を作るという。 CCCがT会員規約を改訂し、Pマークを返上した理由は何か。CCC 管理部 法務部 リーダーの西蔭悠史氏、同社 経営戦

    なぜCCCはプライバシーマークを返上し、T会員規約を改訂したのか(前編)
  • 損保各社がマイナンバー漏洩を補償対象、制度開始前に問い合わせ相次ぐ

    マイナンバーが漏洩した場合に保険は適用されるのか」。個人情報などの漏洩に対応した企業向け保険商品を扱う損害保険会社にこんな問い合わせが相次いでいる。突如沸いてきた企業ニーズの高まりに、各社は従来よりも補償額を引き上げたり、マイナンバー単体の漏洩も補償の対象にすると表明したりして応える考えだ(図)。 三井住友海上火災保険は、売上高5000億円以下の企業向け保険「情報漏えいプロテクター」の2015年7月以降の契約分から、費用損害の補償上限額を従来の5000万円から5億円に引き上げた。費用損害は、情報漏洩によって発生した調査対応や個人への見舞金など自己負担分の費用だ。「情報漏洩に対する意識の高まりを受けたもの」(同社)という。 東京海上日動火災保険は2015年2月に「サイバーリスク保険」を発売。マイナンバー単体の漏洩も補償対象としたほか、情報漏洩が確定する前の不正アクセスなどの調査費用も補償対

  • 第4回:特定個人情報の取扱規程を整備しよう

    連載第3回では、マイナンバー制度の安全管理措置の検討の流れや基方針の策定について触れました。今回は特定個人情報や個人番号の事務取扱規程などの整備や、組織的安全管理措置について触れます。 5合目: 特定個人情報の事務取扱規程などを整備しよう 「特定個人情報の適正な取扱いに関するガイドライン(事業者編)」(特定個人情報適正取扱ガイドライン)の「(別添)特定個人情報に関する安全管理措置」では、特定個人情報や個人番号の取扱規程などの策定が義務付けられています。 この取扱規程などは、個人番号を取り扱う事務の範囲の明確化や、特定個人情報などの範囲の明確化、事務取扱担当者の明確化の三つの明確化を受けたものです。事務の流れを整理して、個人番号や特定個人情報の安全管理措置に関する基方針を策定したうえで、特定個人情報などの具体的な取り扱いを定める取扱規程などを策定しなければならないとされています。 特定個

    第4回:特定個人情報の取扱規程を整備しよう
  • 現在主流のアプローチ「多層防御」を正しく理解する

    近年、セキュリティ対策では「多層防御」がキーワードになっている。複数の防御の“層”を作り、一つの層が破られても別の層で守られるという考え方だ(図1)。「Defence in Depth」という軍事で用いられる戦略がベースにある。標的型攻撃への対抗策として近年いわれている「出口対策」や、サイバー攻撃を受けても情報が漏えいしないようにファイルを暗号化するような対策も多層防御の一環である。 例えば、パソコンがウイルスに感染して、情報が漏洩してしまうケースを考えよう。多くの方はウイルス対策ソフトの導入など、パソコン自体のセキュリティ強化だけを考えてしまう。しかし、実はこれだけでは不十分だ。ウイルス対策ソフトをくぐり抜けるサイバー攻撃を受けると、防御がすべて破られてしまうことになる。 多層防御ではパソコン自体のセキュリティ対策だけではなく、ネットワークやサーバーなどのパソコンにウイルスが流入する経路

    現在主流のアプローチ「多層防御」を正しく理解する
  • マイナンバー制度で3つの誤解が浮上、システム対応をやり直す危険性も

    一部のユーザー企業やベンダーの間で、マイナンバー制度のシステム対応についての誤解が広がっている――。最近、マイナンバー制度に詳しい関係者からこんな指摘が出ている。 関係者の話を総合すると、誤解は大きく三つある。 一つ目は、「個人番号(マイナンバー)を暗号化すれば、個人番号として扱わなくてよい」。クレジットカード会員データを安全に取り扱うためのシステム基準である「PCI DSS」で、カード会員データを暗号化して保管する手法が挙げられている。 それを根拠に、マイナンバー制度でも、個人番号を暗号化する方法が提案されているという。一部のベンダーは、誤った理解のまま暗号化機能を実装し始めている、との指摘もある。 しかしマイナンバー制度では、暗号化しても求められる管理方法は変わらない。特定個人情報保護委員会は2015年4月にガイドラインの「Q&Aの追加・更新」を公表し、暗号化などをしても個人番号に該当

  • SIEM

    さまざまなネットワーク機器やサーバーから、多様かつ膨大なログを収集して一元管理し、それらを基に不正を検知する新しいセキュリティシステムのこと。Security Information Event Managementの略で、シームと発音する。 従来、不正検知には主にIDS(不正侵入検知システム)が用いられてきた。IDSはいわば、不正な通信を見つけるセンサー。ネットワーク上を流れるパケットを、「シグネチャー」と呼ぶルールに基づいて、リアルタイムに検査し、不正だと思われるものがあるとアラートを上げる。この目的に特化したシステムであるため、例えば、不正だと思われるパケットを検知したときに、ウイルス対策ソフトやサーバーのログを併せて分析することで、不正検知の精度を高める、ということができない。 SIEMはこの限界を突破する。ファイアウオール、プロキシーサーバー、IDSといったネットワーク・セキュリ

  • マイナンバー施行は10月5日に決定、制度の確定待たず準備を急げ - ITpro.nikkeibp.co.jp

    政府は2015年3月31日に、マイナンバー制度(行政手続番号法)の施行期日を2015年10月5日と定める政令を閣議決定した。個人番号の通知などを行い、2016年1月1日にマイナンバーの利用を始める。また厚生労働省が3月31日に、マイナンバー制度に伴う省令改正案を公表し、パブリックコメントの募集を始めた。改正案が確定するのはパブリックコメント後だが、企業は今からシステム改修などの対応を急ぐ必要がある。 厚労省令の改正案では、年金や雇用保険の申請様式などにマイナンバーの記載を追加する。それによって、2016年1月から申請者は住民基台帳ネットワークシステム(住基ネット)を利用した際に住民票などの添付が不要になる。加えて自治体などは、条例に基づいて添付する書類などを自治体内のシステム連携によって省略できる。さらに、2017年1月からは国が運営する「情報提供ネットワークシステム」を通じて他の行政機

  • 今すぐ着手、7カ月で終えるマイナンバー対応

    [3]動き出した企業から学ぶ、マイナンバー対応の実情 2015年に入って大手ベンダーなどがマイナンバーに対応するシステム改修や番号収集・管理を代行する外部委託サービスを続々と発表している。ただ、こうしたサービスを利用する企業側も準備が不可欠だ。対応を始めた企業やベンダーの動きを紹介する。 2015.03.05 [2]マイナンバー対応、経営判断が必要となる五つのポイント 企業に求められるマイナンバー対応は、着手してみて初めて大変さに気付く関係者が多い。マイナンバーを利用される個人の立場になって考えれば、なぜ複雑な対応が必要なのか分かりやすい。これまでの取材で企業の経営判断が必要となる五つのポイントも紹介する。 2015.03.04 [1]マイナンバー対応のために知っておくべき15のポイント あなたの会社でも準備を始めなければ、もう対応が間に合わないかもしれない。そんな法律がある。正式名称「行

  • プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...:ITpro

    プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに,あるいは軽視して,失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが,現場でプロマネがやってはいけないことを解説する。 関連サイト: ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画&進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘

    プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...:ITpro
  • [続報]ベネッセの再発防止策は正攻法か、奇策か

    「根的な原因は、自社の情報セキュリティへの過信、経営層のITリテラシーの不足、性善説に立った監査体制など、企業風土に起因する甘さがあったことだ」。ベネッセホールディングスの原田泳幸会長兼社長は2014年9月10日の記者会見で、今回の情報漏洩事件を受け、同社の情報管理体制を大幅に見直すことを明らかにした(関連記事:ベネッセ漏洩対象は国内総人口4割の4800万人、各世帯に500円金券を配布)。 大量ダウンロード時のアラートが無効に 今回の記者会見では、元社員が大量の顧客情報を外部に持ち出せた理由のいくつかが明らかになった。 今回新たに判明したのが、データの取り扱いに関するアラート(警告)設定の不備である。 同社の社内ネットワークには、従業員の誰かが大容量のデータをダウンロードしようとする際、システムがアラートを発する仕組みがあった。だが、情報が漏洩した顧客データベース(DB)は、このアラート

    [続報]ベネッセの再発防止策は正攻法か、奇策か
  • 第5回 著作権の帰属規定は契約で移転できる

    システム開発の成果物であるプログラムには、著作権が発生する。著作権法上は、システムを開発したソリューションプロバイダが、著作者として著作権を持つのが原則だ。だがユーザー企業は、著作権の自社への帰属を主張することが少なくない。システム開発契約では、著作権の帰属についての合意と契約が不可欠になる。 システム開発においては、開発したプログラムの著作権を、発注者であるユーザー企業が持つべきか、実際に開発を行ったソリューションプロバイダが持つべきかで争いが発生することがある。 システムを開発したソリューションプロバイダの側にすれば、プログラムコードを利用して、他のユーザー企業のシステム開発を迅速かつ効率的に行いたいという思惑がある。一方発注者であるユーザー企業にすれば、自分たちがお金を出して開発したプログラムを競合企業に使ってほしくないし、プログラムを利用されれば自社のノウハウが流出すると危惧して、

    第5回 著作権の帰属規定は契約で移転できる
    katuo_ball
    katuo_ball 2014/09/05
    著作権移転