皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨日だったでしょうか。

Bluetoothの通信傍受などの脆弱性情報が出ていましたので、今日はそれをお伝えします。

Bluetoothに通信傍受などの脆弱性

Bluetoothの認証団体Bluetooth SIG（Special Internet Group）は、複数のOSやファームウェアにおけるBluetooth実装に脆弱性が存在し、中間者攻撃による通信傍受や改ざんの可能性があるとしてBluetoothの仕様を更新したことを発表しました。

これは、ペアリング技術などに脆弱性の影響があるとされており、暗号化通信を行うパラメータが十分に検証されない脆弱性が存在するともされています。

ただし、この脆弱性をついた攻撃を受けてしまうケースとして、同じ脆弱性を持つ2つのデバイス間の無線通信範囲内に攻撃者がいる場合で、脆弱性が片方のデバイスのみの場合は攻撃は受けないとされています。

現時点での被害は確認されていないようではありますが、CERT/CCが脆弱性を確認している製品としては以下のものがあります。

・Apple

・Broadcom

・Intel

・QUALCOMM

各ベンダーからのアップデート情報はまだ出ていないと思われますが、該当ベンダーの製品を使われている方は各ベンダーのアップデート情報の確認が推奨されています。

お気を付けください。

＜参考＞『Bluetooth SIG Security Update』

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

あるセキュリティベンダーの調査レポートによると、IEやエクスプローラーになりすますウイルスによる感染被害が日本でも出ています。

今日はそれについてお伝えします。

IE・エクスプローラーへのなりすましウイルス

このウイルスは『URLZone』というもので、存在そのものは10年以上前に見つかったものですが、数年前まではヨーロッパを中心とした被害であったものが、ここ最近は日本が中心になっているようです。

特徴としては、IEやエクスプローラーになりすますことと、サンドボックス環境でのウイルスを検知がしにくいこととされています。

感染経路の一つはメールで、『注文書や請求書』など、業務関連のメールに見せかけたメールに添付されている文書ファイルなどから感染することが明らかになっています。

詳細な内容はさておき、このようなウイルスへの感染を防ぐには、受信したメールをよく確認することです。

差出人、件名、本文、これらを見て、普段から取引のある相手であれば差出人であるメールアドレスはわかりますし、件名や本文に関しても書き方には特徴があるはずです。

それらが不明なものであったり、怪しいものである場合には間違いなく添付ファイルをクリックしてはいけません。

社内ルール的に可能であれば、『Firefox Send』などを使い、暗号化されたストレージ経由にて書類の受け渡しを行うなどし、メールではファイルの受け渡しを行わないようにすることも被害を防ぐ方法の一つです。

普段から無意識にメールのやりとりを行われている事業者の方、一度、社内のルールを見直してみてはいかがでしょうか。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ある方の記事で、要件定義にまつわる訴訟事例を拝見しました。

そこにあったのは、ベンダーには厳しいと思われる判決内容でした。

要件不備の責任を問われたベンダー

システム開発業者Aは、旅行会社Bの航空チケット発券システムを受託し、開発したが、システムの機能不足で稼働できず、訴訟になってしまったという話しで、その記事に書かれている機能不足とは、『遠隔地からデータベースを操作できる機能が不足していた』というもののようです。

この訴訟の結論を先に言うと、

要件の不備の責任の一端はベンダーにもある。

という判決で、

ベンダーは、ユーザーの業務をよく学び、実際のオペレーションを理解した上で、ユーザーが作成する要件定義書の過不足をチェックしなければならない。

という判断であったと、その方の記事には書かれています。

では、何故このような事態になってしまったのでしょうか？

要件定義の手順ミスの可能性

この訴訟、少々推察にはなってしまうものの、要件定義における手順にミスがあったと思えます。

まず、業務分析の段階において、システム開発の対象となるすべての部分を明示してもらうように促していない可能性があります。

次に、ユーザーが作成した要件定義書であれ、双方においてすべての要件に対して読み合わせと合意を行っていない可能性もあります。

これ、私であれば要件定義書に書かれている内容がすべてであることを明記し、読み合わせ後、合意した旨を責任者・担当者などに押印してもらいます。

（これを行っても解釈の疑義が生じることはあり得ます。）

要は、要件定義書に書かれている以上も以下もないということと、それに対してすべての関係者が合意したという証を残すということです。

もう1つ、ユーザーもベンダーが当然知っているだろうという勝手な思い込みは危険です。

要件定義書から漏れていることがあるならば、それはしっかり指摘をすべきではないでしょうか。

そういった漏れなどを無くすためにも要件定義を行っているわけですから。

ご参考までに。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

近年では、取引先とのやりとりをメールで行うことは当り前の時代になっていますが、今まで送れていたメールが突然エラーとなって返ってくることになったら困りますよね。

今日はそんな事例をお話しします。

セキュリティ製品の導入

メールを受信する側が何らかのセキュリティ製品を新たに導入した場合、送信したメールがブロックされてしまうことがあります。

セキュリティ製品を専門で取り扱っているベンダーはスパムメールに対するデータベースを保持しており、日々それを更新してユーザーが利用するセキュリティ製品に配信したりしています。

その影響により、今まで普通に送信できていたメールが突然相手側でブロックされてしまうといったことも起きてしまうケースがあります。

つまり、セキュリティベンダーのデータベース上にスパムリストとして登録されてしまっていることがあるのです。

もちろん、それに検知されない＝それを利用していない相手への送信はブロックされません。

（それ以外にもスパムリスト入りしているものがあれば別です。）

リレーサーバなどのスパムリスト入り

中小・零細、小規模事業者などの場合においては、自社にメールサーバを立てたり専用サーバを借りるケースは少なく、大半は共用型のレンタルサーバを契約し、その中でメール設定をして利用するケースが多いです。

この場合、DNSなどの設定上は独自ドメインであったとしても、実際にはレンタルサーバ会社側にて異なる設定をしているケースがあります。

例えば、レンタルサーバのIPアドレスが何らかの原因で一部のスパムリストに登録されてしまったとします。

その場合、そのIPアドレスの情報を持つメールからの受信を拒否してしまう相手もいます。

（相手側の契約しているレンタルサーバなどがそのスパムリストを参照している。）

これを回避するため、原因の特定と問題の解消がなされるまでの間、一時的にリレーサーバ経由にてメールの送信を行うようにしたりすることがあるのですが、その場合、相手側に届くメールのIPアドレスの情報はリレーサーバのものとなり、そのIPアドレスやリレーサーバのサブドメインなどがスパムリスト入りしていることによってブロックされてしまうこともあるのです。

（前述のものを含め、これらは解除申請をしないと正常には戻りません。）

このようなケースの場合、一部の相手だけに対してメールが送信できずにエラーで返ってきてしまうわけですから、どこかのスパムリストに入ってしまっている可能性が高いです。

その場合であっても、自身で勝手に解除申請をしてはいけません。

これらは問題解決がなされていることを前提に解除申請を行いますので、まずは契約のレンタルサーバ会社などに相談し、適切な対処を行ってもらうことが一番です。