攻撃者が狙う重要情報の宝庫!
―スマホアプリのセキュリティ―

Share

私たちが日常的に利用するスマホアプリのサービスは、開発者によって多様な機能が連携され、提供されています。しかしスマートフォンは、サイバー攻撃のターゲットになってしまう魅力的な重要情報の宝庫となっており、攻撃者に狙われることも多いです。本記事では、なぜスマホアプリが狙われるのか?スマホアプリのもつ脆弱性情報のご紹介をしつつ、セキュリティ対策にむけた考え方を解説していきます。

なぜスマホアプリは攻撃者に狙われるのか

一人一台以上のスマートフォンを所持・活用しているのが当たり前とされる現代において、私たちは日常的に様々なスマホアプリを利用しています。それらのスマホアプリがサービスとして提供されている裏では、スマートフォンが備えている多様な機能とスマホアプリとが開発者によって連携され、それによりスマホアプリのサービス提供が実現しています。利用者がアプリ上でのみ操作を行っているつもりでも、実際はアプリとスマートフォンの持つ機能が連携することで、便利なサービスを利用できているのです。

しかし便利な一方で、スマホアプリはサイバー攻撃のターゲットとされることも多くあります。なぜならスマホアプリは以下の3つの特徴を持っているためです。

重要情報の宝庫

スマホアプリではWebアプリよりも多くの重要情報が扱われます。例えば連絡先情報、メールや通信のログ、GPS(位置情報)、決済情報、さらには利用者が何を好むかといった趣味嗜好など個人に関する情報が多様に含まれています。これらの情報が集まっているスマホアプリは、攻撃者にとっては魅力的な重要情報の宝庫といえます。

もし攻撃者に狙われた場合、これらの重要情報が漏洩してしまう可能性があります。

ユーザ側での端末管理

Webアプリではサービス提供者が管理しているサーバ側で情報を保持していましたが、スマホアプリでは各ユーザ端末側に情報が保持されているものが多くあります。Webアプリの場合はサービス提供者側がセキュリティソリューションを活用したりすることでセキュリティ対策を行っていましたが、スマホアプリのように各ユーザ端末側で情報が保持されている場合、セキュリティ対策の実施はユーザ個人に依存するため、セキュリティ対策が十分に行われていないこともあります。特にスマートフォンに関するセキュリティ対策情報は、パソコンのセキュリティ対策に比べてユーザにあまり認知されていないため、ユーザのセキュリティ意識がパソコンよりも薄い状況にあります。

もしスマートフォンのセキュリティ対策が十分にされていなかった場合、脆弱な状態や設定のまま放置され、そのままアプリ連携や端末間での共有がなされることで、ユーザが意図しない手段や経由により不正アクセスが行われる可能性があります。

常時外部と接続状態

Webアプリはブラウザからアクセスしますが、スマホアプリではアプリごとに独自開発された機能によってアクセスします。また、スマートフォンは常時電源がオンになっており、インターネットにも常時接続されている状態です。

そのため、例えばあるスマホアプリで非暗号化通信での情報のやり取りなどが行われて重要情報が外部から見えるような状態であった場合に、常時接続状態であるスマートフォンは攻撃者に狙われる隙が生まれやすくなってしまいます。これにより不正利用・操作や、通信内容の盗聴・情報改竄が行われる可能性があります。

攻撃者にとって重要情報の宝庫であるのにも関わらず、セキュリティ対策がユーザ側に依存し、また常時インターネットに接続状態となっているため、攻撃の隙も生まれやすい。これがスマホアプリが攻撃者に狙われやすい理由です。またBYOD(Bring Your Own Device)を導入している企業も増えてきたため、個人のスマートフォンが攻撃されることで、企業への攻撃の踏み台にされる可能性もあります。

スマホアプリにおける情報漏洩の事例

実際に近年起きたスマホアプリにおける情報漏洩は下記のようなものがあります。

スマホアプリにおける脆弱性の届出状況

IPAおよびJPCERT/CCが発表している「ソフトウェア等の脆弱性関連情報に関する届出状況[2022年第2四半期(4月~6月)]」によると、2022年の第2四半期(4月~6月)までで届出が出されている脆弱性を製品種類に分けて集計すると、スマホアプリの脆弱性はソフトウェア製品全体の8%となっており、ウェブアプリケーションソフトとルータに次いで多く検出されている結果となりました。スマホアプリ開発段階で脆弱性を見落とされて、そのままリリースされてしまった場合、スマホアプリを利用するすべての人々に影響が及ぶ可能性があり、情報漏洩事故につながってしまう恐れがあります。

スマホアプリのセキュリティの対策にむけて

誰もがスマートフォンを利用しているからこそ、実際に被害に遭う可能性を誰しもが持っています。また、攻撃の影響は多くの人々に及ぶことが想定されます。ユーザ目線では被害を受けないための、またスマホアプリを提供する側目線では被害を防ぐためのセキュリティ対策を心掛けることが重要でしょう。

今回はスマホアプリを提供する上で重要な考え方や手段を大きく3つご紹介します。

脆弱性情報の収集

脆弱性情報を取りまとめている機関*1等から定期的に脆弱性情報を収集し、セキュリティの最新情報や対策方法を取り入れることで、普段からセキュリティに対する意識を高める必要があります。

セキュアコーディングを意識した開発

セキュアコーディングとは開発段階で攻撃に耐え得る堅牢なプログラムを書くことを指します。セキュアコーディングのガイドライン「Androidアプリのセキュア設計・セキュアコーディングガイド」を活用することで、スマホアプリ開発段階から脆弱性の有無を知り、より早い対策を実施することができます。また、より早い段階で対策ができれば、リリース後の手戻りやコストの発生も防ぐことができます。このようなシフトレフトを実践することも重要な考え方の一つです。

セキュアなアプリケーション開発の考え方について、SQAT.jpでは以下の記事でご紹介しています。
こちらもあわせてご覧ください。
Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

信頼できる第三者機関の脆弱性診断サービスを実施

企業として実施できるセキュリティ対策として、信頼できる第三者機関による脆弱性診断が挙げられます。第三者の専門家からの診断を受けることで、現状の問題点や対応の優先順位などリスクを可視化することができるため、早急に効率よく対策を実施するのに役立ちます。

APIのセキュリティ対策

APIのセキュリティ対策のサムネ

スマホアプリと切っても切れないものとして、API(Application Programming Interface)が存在します。スマホアプリはAPIを経由してサーバとやり取りをしているケースが多く、セキュリティ対策を行ううえでAPIを無視することはできません。

APIにおいてもWebアプリと同様に様々なセキュリティリスクが存在しますので、スマホアプリ、Webアプリと同様に最適なセキュリティ対策をとることが大切です。

APIのセキュリティに関する10大リスク

APIにおけるセキュリティ対策を講じるうえで役立つ情報として、Webアプリケーションセキュリティに関する国際的コミュニティOWASP(Open Web Application Security Project)が公開している「OWASP API Security Top 10」があります。

SQAT.jpでは以下の記事でご紹介しています。あわせてご覧ください。
APIのセキュリティ脅威とは

スマホアプリ脆弱性診断とは

「スマホアプリのセキュリティ対策」に既述した脆弱性診断サービスですが、そういったサービスの活用がなぜ必要なのでしょうか。その理由は図の通りです。

スマホアプリ脆弱性診断とはのサムネ

スマホアプリ診断で検出される脆弱性項目例

例えば弊社のスマホアプリ診断において検出数の多い脆弱性項目としては、下記のようなものがあります。このような脆弱性はなかなか開発段階で自社の目線からすべて網羅するのは難しく、脆弱性診断サービスを使うことで効率よく発見することが可能です。

重要情報の漏洩

<例>
・スマートフォン内部の記憶媒体領域(ストレージ等)に認証情報が保存されている
・スマホアプリからサーバ側に通信を行う際に、URLパラメータ等が暗号化されていないままの状態であるために認証情報が露呈している

重要情報がスマホアプリ側だけではなく、ユーザのスマートフォン内部など他の領域で確認できる状態であるために、攻撃者に情報が漏洩してしまう可能性があります。

不正な行動・操作が可能

<例>
・信頼境界へのアクセスが厳密に制御されていない状態である
・外部アクセスの制御不備などにより、スマホアプリの権限外のユーザによるアクセス制御が可能である

スマホアプリではAPIや他のアプリとの連携、スマートフォン内部の記憶領域など、外部との通信が頻繁に行われます。その中で、信頼できない外部からのアクセスを制御するといった対策が厳密に行われていないために、攻撃者から不正な操作の実行や、データ改竄および不正利用される可能性があります。

難読化処理の未対応

<例>プログラムコードが難読化されていないため、リバースエンジニアリングによるソースコード解析が可能な状態である

攻撃者により、スマホアプリの機能およびロジック分析が行われた場合、弱点をついた攻撃手法の分析や技術情報の解析につながる可能性があります。

誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。

スマホアプリ脆弱性診断のサービスバナー

スマホアプリ脆弱性診断に+α

開発者視点でのスマホアプリの品質管理、セキュアコーディング、セキュリティ設定のチェックにはソースコード診断サービスもあわせて実施することを推奨しています。スマホアプリに潜在する脆弱性をソースコードレベルで診断することで、さらなるセキュリティ向上にお役立ちできます。


スマホアプリの進化にあわせた対策を

スマホアプリは様々なかたちで利用され、日々利便性が向上されています。それに伴い開発・提供者側はより高度な機能を活用し、扱う分野や範囲も広がってきています。すでに述べてきたように、機能の利便性の反面、Webアプリと比べてスマホアプリは独自のリスクを抱えています。そのため、基本的なセキュリティ対策はもちろん、より強固なセキュリティ対策を行うことが、サイバー攻撃を防ぐカギとなります。

Security Report TOPに戻る
TOP-更新情報に戻る


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

Share

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、トータルコストを低減しつつ、さらなるクオリティ向上を実現する手法です。セキュアなWebアプリケーション開発プロセスの実現のためには、この考え方が重要です。しかし、多くの企業・組織にとって、DevSecOpsの実現には様々な課題があるのが実情です。 本記事では、開発の現場担当者が感じている課題を整理したうえで、セキュアなWebアプリケーション開発にむけて、どのように取り組むべきかについてご紹介します。

OWASP Top10に新たな項目

2021年9月、「OWASP Top 10 2021」が発表されました。Webアプリケーションセキュリティに関する最も重大な10項目のリスクを取り上げたものです。前回発表された2017年版(OWASP Top 10 2017)から4年ぶりの更新となります。

※OWASP(Open Web Application Security Project)…Webアプリケーションセキュリティに関する国際的コミュニティ

2017年版Top 10の各項目は、2021年版ではそれぞれ順位を上げ下げしつつ、一部統合されて7項目となり、完全に消えたものはありませんでした。そして、新たなカテゴリが3項目追加される形で計10項目となりました。

OWASP Top 10 – 2021

A01:2021 –アクセス制御の不備
A02:2021 –暗号化の不備
A03:2021 –インジェクション
A04:2021 –NEW セキュアでない設計
A05:2021 –セキュリティ設定のミス
A06:2021 –脆弱かつ古いコンポーネントの使用
A07:2021 –識別と認証の不備
A08:2021 –NEW ソフトウェアとデータの整合性の不備
A09:2021 –セキュリティログとモニタリングの不備
A10:2021 –NEW サーバサイドリクエストフォージェリ(SSRF)

NEW」は2021年度版で追加された項目
https://owasp.org/Top10/ より弊社和訳

新設された3項目のうち2つが、システム開発のプロセスにかかわる内容に焦点を当てています。

● セキュアでない設計(Insecure Design)
  ポイント:設計における管理策の欠如、ロジックの検証が不十分である等
  推奨対策:シフトレフトによる開発ライフサイクルの実践 等
● ソフトウェアとデータの整合性の不備(Software and Data Integrity Failures)
  ポイント:安全でないデシリアライゼーション、
  信頼できないコンポーネントの利用、CI/CDパイプラインにおける検証不備 等
  推奨対策:データの整合性チェック、コンポーネントのセキュリティチェック、
  CI/CDのセキュリティ対策

※シフトレフト…開発工程のより早い段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方

ここで推奨対策例として出てきた「シフトレフト」と「CI/CDのセキュリティ対策」はアプリケーション開発プロセス手法である「DevSecOps」実現に欠かせません。

アプリケーション開発における「DevSecOps」

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、結果的にトータルコストも削減でき、サービスの価値をさらに向上させる手法です。

DevSecOpsとシフトレフト(Shift Left)について、詳しくは過去記事「前倒しで対処 ー セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー」をご覧ください。

“セキュリティ”が組み込まれていないと…

DevSecOpsにおけるシフトレフト

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

DevSecOpsにおけるCI/CDのセキュリティ対策

“Sec”が入らないDevOpsにおいては、設計・実装を小さな単位で素早く繰り返し実行していく手法(アジャイル開発手法等)が一般的ですが、このスピード感をサポートするのが「CI/CD」です。

CI/CDの説明図

CI(Continuous Integration)は継続的インテグレーション、CD(Continuous Delivery)は継続的デリバリの略です。アプリケーション開発におけるコード、ビルド、テスト、デプロイといった各作業を自動化して継続的にサイクルを回せるようにする仕組みを指します。オンプレミスでもクラウド上でも展開可能で、CI/CDを提供する様々なツールやサービスが提供されています。

ただし、CI/CDはセキュリティ上のリスクにもなりえます。CI/CD環境に脆弱性が潜んでいて不正アクセスされるようなことがあれば、そこを発端に組織全体が危険にさらされる恐れもあるのです。このため、DevSecOps実現のためには、CI/CDのセキュリティ対策が不可欠です。

セキュアでない設計によるリスク

では、シフトレフトが意識されていない、セキュアでない設計にはどのようなものがあるでしょうか。ユーザの認証に用いられる情報がIDと生年月日である場合、生年月日は他者が容易に知りうる情報なので、本人確認の仕様としてはふさわしくないことがわかります。例えば、補助金の申請システムにおいて、申請者の本人確認や申請内容の検証が甘いために容易に複数の虚偽申請を許してしまうようでは、実用に耐えるとはいえないでしょう。

こうしたセキュリティについて考慮されていない設計は、弊社の脆弱性診断でも相当数検出されています。アカウントロックアウトが設定されていない、Webサーバからのレスポンスにクレジットカード番号のような重要情報が含まれている、個人情報が暗号化されないまま送信されている、といった例は多々見受けられます。放置しておくと、個人情報や機密情報の漏洩を引き起こしかねません。

プライバシーマーク推進センターによって報告された、2020年度「個人情報の取扱いにおける事故報告集計結果」によると、誤送付や紛失・盗難によらない情報漏洩のうち、プログラムやシステムにおける設計・作業ミスを原因とするものは102件あったとのことです。大した件数ではないようにも見えますが、インシデント1件あたりの漏洩件数が増加傾向にあるとの報告もあり、影響の大きさに注意が必要です。また、これらはあくまで報告があったものだけの数ですので、セキュアでない設計によるアプリケーションが人知れず稼働したままになっている危険性は大いにあるでしょう。

一般財団法人日本情報経済社会推進協会(JIPDEC)プライバシーマーク推進センター
2020年度「個人情報の取扱いにおける事故報告集計結果」(2021年10月15日更新)より

CI/CDパイプラインにおける検証不備によるリスク

コードカバレッジツールへのサイバー攻撃の概要図

CI/CDパイプラインに起因するリスクの方はどうでしょう。2021年にあるインシデントが発生しました。ソースコードのテスト網羅率を計測するコードカバレッジツールがサイバー攻撃を受けた結果、このツールを使用していた国内企業のCI環境に不正アクセスされ、重要情報を含む1万件以上の情報漏洩につながったというものです(右図参照)。

自動化、高効率化ツールによる利便性を享受するためには、そこに係るすべてのツールや工程におけるセキュリティチェックを行う必要があるのです。

DevSecOps実現を阻む壁

さて、安全なWebアプリケーション開発の重要性は認識できているとしても、実現できなければ意味がありません。とはいえ、DevSecOps実現には、多くの企業・組織において様々な障壁があるものと思われます。今回は主な障壁を「組織」と「技術」のカテゴリに分類し、それらの問題点および解決の糸口を考えていきます(下図参照)。

DevSecOps実現のためにできること

DevSecOpsに特化したガイドラインが存在しないというのも、対応を難しくしている要因の1つかもしれません。とはいえ、Webアプリケーション開発におけるセキュリティ対策の課題を考慮すると、鍵となるのはやはりシフトレフトです。シフトレフトを意識しながら、システム開発プロセスに組み込まれたセキュリティ対策を実践する例として、以下のようなイメージが考えられます。

Webアプリケーション開発におけるセキュリティ対策実施の背景には、Webアプリケーションの規模や利用特性ばかりでなく、開発組織の業務習慣や文化等、様々な事情があることでしょう。例えば、セキュアコーディングのルール整備やスキルの平準化が不十分という課題があれば、まずは現場レベルでそこから取り組んでいくといったように、信頼されるWebアプリケーション構築のために、少しずつでもDevSecOpsの実装に近づけていくことが肝要です。

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

●NIST
 Security Assurance Requirements for Linux Application Container Deployments
 https://csrc.nist.gov/publications/detail/nistir/8176/final

●OWASP
 OWASP Application Security Verification Standard
 https://github.com/OWASP/ASVS

●内閣サイバーセキュリティセンター(NISC)
  情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
  https://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

テレワーク導入による開発現場での課題
―セキュアプログラミングの重要性―

Share

セキュアプログラミングは、サイバー攻撃に耐えうる、脆弱性を作りこまない開発を可能にするため、セキュリティの観点からみても重要な考え方です。特に、テレワーク環境では、エンジニアとの連携が困難になり得るため、必要以上に手戻りが発生しがちです。そこで、本記事ではセキュアプログラミング開発のための推奨対策をご紹介します。なお、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方「シフトレフト」についてもご参考ください。

企業のソースコードが流出

2021年1月下旬から2月上旬にかけて、プログラム開発プラットフォームのGitHub上で大手金融機関を含む複数の国内企業に関するソースコードの一部が公開されるというインシデントが発生しました。各被害企業からは、セキュリティ上の問題はない旨コメントされたとの報道でしたが、中には公的機関のものと思しきコードも含まれていたと想定され、ネット上が騒然となりました。

ソースコードを公開したのは、元委託業者のエンジニアでした。転職において自身の年収を査定するWebサービスを利用するため、実績として当該ソースコード群を公開状態でGitHubにアップしてしまったとのことです。

サプライチェーン問題とリテラシー問題

このインシデントの原因は、悪意の有無に関係なく、業務でソースコードを作成した者が容易にそれを持ち出せた点にあります。そこには、大きく2つの問題があると考えられます。

・サプライチェーン問題
 委託元が委託先(もしくは再委託先)でソースコード流出が発生しないような仕組みを整備できていないこと、および開発状況を監視できていないこと
・リテラシー問題
 委託先か自組織かにかかわらず、開発従事者がソースコードを持ち出して保持したり、どこかにアップしたりしても問題ないという認識であること

※サプライチェーンとは、製品やサービスがユーザに届くまでのすべてのプロセスとそれに関わるすべての企業・組織を指します。

GitHubの利用禁止は解決にならない

事態をうけて、一般社団法人コンピュータソフトウェア協会(CSAJ)と日本IT団体連盟はそれぞれ、GitHubの利用に関する要請*2を発表しました。主なポイントは以下の3点に集約されます。

1. GitHubの利用自体を禁止することは解決にならない
2. 委託先と委託元が協力し合い、サプライチェーンの把握が必要
3. クラウド・バイ・デフォルト原則ではクラウド利用者側の使い方、設定、
   リテラシーが重要

GitHubはソースコードのレビュー、および開発プロジェクト進行の課題解決を効率的に行えるクラウドサービスです。その利用自体はソフトウェア開発産業の促進に不可欠であるとした上で、サプライチェーンの問題(上記2)とリテラシーの問題(上記3)に触れています。

コード流出対策としては、「GitHub設定の定期的なチェック」「委託先企業の厳密な管理」「インシデント対応体制の整備」ということになるでしょう。

サプライチェーンの弱点が狙われる

サプライチェーンの把握については、近年、繰り返し警鐘が鳴らされています。2021年1月、独立行政法人情報処理推進機構(IPA)より発表された「情報セキュリティ10大脅威 2021」 では、「サプライチェーンの弱点を悪用した攻撃」は、昨年に引き続き4位にランクインしています。

大企業のセキュリティが堅牢になればなるほど、関連している中小企業のセキュリティホールが狙われる、という皮肉な構図が浮かび上がります。一カ所でも弱点があると、サプライチェーンに含まれる全企業・組織に危険が及ぶ恐れがあります。

テレワーク導入拡大における懸念

サプライチェーンにおけるリスク管理を困難にしている要因の1つが、テレワークの拡大です。「情報セキュリティ10大脅威 2021」第3位には、新たに「テレワーク等のニューノーマルな働き方を狙った攻撃」が登場しました。

IPAによる「ニューノーマルにおけるテレワークとITサプライチェーンのセキュリティ実態調査」中間報告 で、委託元企業のテレワーク導入経験が約5割であるのに対し、委託先IT企業の方は9割以上であることが明らかになりました。このギャップは、テレワーク環境により目の届かないところで作業されているという、委託元の不安を増大させています。

委託元と委託先の相互協力が必須

日本のあらゆる業種において見受けられる「多重下請け構造」は、ソフトウェア開発においても例外でなく、委託・再委託なしでは成り立たないのが現状です。

委託先を原因とするインシデントであっても、例えばソースコード流出により重要情報が漏洩する被害が発生した場合、実際に企業・組織名が報道され、社会的信用を失墜する恐れがあるのは委託元です。委託先に対する管理の甘さによりインシデントを招いた責任から免れることはできません。委託先も、インシデントを引き起こしたとなれば、取引停止等、事業の存続自体が危ぶまれる恐れもあります。委託元と委託先の両方がダメージを受けてしまうのです。

発注側である委託元の経営者が「セキュリティは投資」という認識を持ち、開発に必要な人員や期間、環境等のリソースを考慮した上で、委託先と互いに協力し合う必要があります。具体的には以下のような対策が挙げられます。

出典:「サイバーセキュリティ経営ガイドライン」Ver2.0(経済産業省/IPA)
中小企業の情報セキュリティ対策ガイドライン」(IPA)

さらに活発化するOSS

また、ソフトウェア開発の潮流の1つにオープンソースソフトウェア(OSS)の活用があることも、注意すべきポイントです。世界のソフトウェア開発組織によるオープンソースコンポーネントのダウンロード数は、一社平均で年間37万超に上る*2とのデータがあります。同時に、OSSプロジェクトに対するサイバー攻撃は前年比4.3倍に増加している *3とのことです。

ここ数年、日本においても、企業ばかりでなく、東京都が新型コロナウイルス感染症対策サイトのソースコードをGitHubで公開したり、総務省が住民情報システムのOSSによる開発を行うことを決定したり―といった具合に、政府や自治体もOSS採用を加速させています。

管理策として、ソフトウェアBOM(ソフトウェア部品表)の作成*4が推奨されます。製造業における部品明細と同様の考え方で、アプリケーションで使用されているOSS、各種コンポーネントやフレームワークについて可視化しておくのです。これらの情報を集約してアップデートを継続しておくと、OSSにおけるコンプライアンス問題の対策にもなります。

セキュアプログラミングの必要性と推奨対策

テレワーク時代のソフトウェア開発を取り巻く現状を見てきました。テレワーク環境では、エンジニアとの連携が困難になり得るため、開発チームのマネジメントに課題があります。また、担当者間や組織間での連携が薄まると、納品物に対するチェックが不十分となったり、必要以上に手戻りが発生したりすることで、完成したソフトウェアにセキュリティ上の問題が存在してしまう原因となり得ます。ソフトウェアの安全性を確保するため、改めてセキュアプログラミングの必要性を認識することが重要です。プログラムが意図しないデータを受信した場合も想定し、サイバー攻撃に耐えうる、脆弱性を作りこまない開発を可能にするため、以下のような対策を推奨します。

リテラシー教育
 ポリシーの整備やセキュリティ教育・訓練の実施は、組織全体のリテラシー向上に必要です。実施には、ノウハウがあり、信頼できるセキュリティ企業の力を借りるのが有効です。
・ツールによるソースコード診断
 開発のあらゆるタイミングで手軽にソースコードの安全性と品質の検査ができるのが、ツール診断の強みです。早期の段階からチェックし、コード単位で解消していくことで、結果的に一定のセキュリティ標準を満たすことができます。
セキュリティエンジニアによるソースコード診断
 効率的で網羅的なツール診断に加えて、より精度を上げるため、専門家による判断が必要な脆弱性の検出を行います。脆弱性を解消した状態で、安心してリリースに臨むことができます。
開発プラットフォームの設定確認・検査
 リポジトリとコードへのアクセスを許容するユーザを厳格に制限すると同時に、設定ミスがないことを継続的に確認する必要があります。開発プラットフォームとしてクラウドサービスを利用するにあたりセキュリティ設定に不安がある場合は、セキュリティ企業による検査を受けておくと安心です。
開発環境における監視
  コードリポジトリに対して監視を行い、不審なデータや挙動がないか定期的にチェックすることで、うっかりミスや悪意による改変をいち早く検知することができます。

まもなく年度末です。開発プロジェクトのラストスパートを迎えている企業・組織も多いことでしょう。テレワーク環境では、インシデントの検知・対応に混乱が生じることも予想されます。今一度、セキュアなアプリケーション開発を肝に銘じていただけましたら幸いです。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

自動車ハッキングの今

Share

SQAT® Security Report 2019年10月号掲載

自動車業界のトレンドは「Connected(コネクティッド化)」「Autonomous(自動運転化)」「Shared/Service(シェア/サービス化)」「Electric(電動化)」の頭文字をとった「CASE」という言葉に集約されつつある。自動車は外部ネットワークと繋がり、新しい価値が創出されようとしているが、販売されている自動車の多くはセキュリティ対策が不十分なため、ハッキングの脅威に晒されている。


車載ネットワーク「CAN」

自動車内には主に四種類のサブネットワークが存在している。エンジンやブレーキの制御をつかさどる「制御系」、ドアやエアコン、シートやミラーを制御する「ボディ系」、カーナビやカーオーディオを制御する「マルチメディア系」、エアバッグなどの安全機能にかかわる部品を制御する「安全系」である。そしてそれらは、多くの車では制御の要となるCAN(Controller Area Network)を中心に、様々な機能を付加する形で車載ネットワークを構成している。

自動車ハッキングにおいて主に狙われるのがこのCANである。CANは1980年代にドイツのボッシュ社で開発された非常にシンプルなプロトコルで、その簡潔性、柔軟性、低コスト性から、今なお多くの自動車で採用されているほか、鉄道、航空機、船舶にも利用されている。

自動車に最も求められるのは、「走る」「止まる」「曲がる」に関する高い安全性であるが、CANは高い電磁ノイズ耐性と早く確実なレスポンス性能を持ち、安全性に対する多くの要求に応えるものだった。

一方で車が外部ネットワークに繋がったことによって、CANはセキュリティに関する多くの問題を抱え、安全性すらも脅かされている。Flex Ray のようなCANに代わるよりセキュアなプロトコルも登場してきているが、その採用は現状ではまだまだ限定的である。

自動車の未来

コネクティッドカーの登場により外部ネットワークに繋がれた自動車は、インターネットを経由した攻撃や、車車間通信を経由した攻撃に晒されている。今後自動運転車が本格的に市場に投入されるようになれば、外部ネットワークへの接続からのリモート操作が人命にかかわる大事故につながる恐れがある。また、EV充電や課金を伴う新サービスの登場により車がクレジット情報を直接的に扱うようになれば、それを狙った犯行の発生も予想される。

Electronic Control Unitの略称。自動車に搭載された様々な機能や装置を電子制御するためのコンピュータ。現在では車載ネットワーク上に100以上のECUが接続されることも珍しくない。

自動車にもセキュリティを考えなければならない時代が来ている。
自動車向けのサイバーセキュリティガイダンスであるSAE J3061*5 を取り入れたり、設計段階からのセキュアコーディング、さらに実車に対する脆弱性診断を実施したりするなど、今後ますます対策が必要になるであろう。

(左)燃料噴射量を調整してエンジンの回転数を増やす操作 (中)(右)燃料計の表示を操作。走行中に操作されればパニックになる可能性があるほか、攻撃のための細工を施した特定の燃料スタンドに立ちよらせるために利用することもできるだろう。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像