米国 FTC ブログ 機能停止を回避し、広範囲にわたるシステム障害

こんにちは、丸山満彦です。

システム更新によるプログラムのバグにより、世界レベルで大規模なシステム障害が発生し、エアライン等に混乱が生じたりしたことも踏まえて？、米国連邦取引委員会が、「機能停止を回避し、広範囲にわたるシステム障害を防ぐ」というブログを載せていますね...

ポイントとしては、

• 厳格なテスト
• 段階的なロールアウト手順
• リスクを最小限に抑える API の開発と使用

というのが挙げられていますね...

会計監査の世界では、昔からIT全般統制の一部として、システムの完全性、可用性についても一部評価されていましたので、上記の内容をみれば、なるほどと思うことも多いように思います...

ということで、基本は重要(^^;;

● U.S. Federal Trade Commission - Office of Technology Blog

・2024.08.13 Avoiding Outages and Preventing Widespread System Failures

Avoiding Outages and Preventing Widespread System Failures	機能停止を回避し、広範囲にわたるシステム障害を防ぐ
Widespread software outages can often be prevented. Resilience – a software program's ability to handle and maintain critical functionality in the face of bugs or other unexpected conditions – is essential given the significant role software plays in the infrastructure of the economy. As with previously discussed security principles, many common types of software flaws can be preemptively addressed through systematic and known processes that prevent or minimize the likelihood of outages. Systematic processes for software resilience include rigorous testing of both code and configuration, incremental rollout procedures, and the development and use of APIs that minimize risk.	広範囲にわたるソフトウェア停止は、しばしば防ぐことができる。レジリエンス（バグやその他の予期せぬ状況に直面しても、重要な機能を処理し、維持するソフトウエアプログラムの能力）は、ソフトウエアが経済のインフラストラクチャーにおいて重要な役割を果たしていることを考えると、不可欠である。先に説明したセキュリティ原則と同様に、一般的なソフトウエアの欠陥の多くは、機能停止の可能性を防止または最小化する体系的かつ既知のプロセスによって、先手を打って対処することができる。ソフトウエアのレジリエンスを向上させる体系的なプロセスには、コードとコンフィギュレーションの両方に対する厳格なテスト、段階的なロールアウト手順、リスクを最小限に抑える API の開発と使用などがある。
Agency staff have acknowledged that resilience can be threatened by lack of competition in critical inputs. Dominant firms pushing maximum adoption of their digital products and services can create single points of failure for entire industries, within and beyond the digital economy. As the number of users relying on the same enterprise software increases, so too can the scale of disruption caused by outages of that software. Every software outage is an opportunity to take a critical look at systems in place to achieve resilience and assess these systems for appropriateness and sufficiency.	省庁のスタッフは、重要なインプットにおける競争の欠如によってレジリエンスが脅かされる可能性があることを認めている。デジタル製品やサービスの最大限の普及を推進する支配的企業は、デジタル経済の内外を問わず、業界全体にとっての単一障害点を生み出しかねない。同じエンタープライズ・ソフトウェアに依存するユーザー数が増えれば、そのソフトウェアの停止によって引き起こされる混乱の規模も大きくなる。ソフトウェアが停止するたびに、レジリエンスを達成するために導入されたシステムを批判的に見 直し、これらのシステムが適切で十分であるかどうかを評価する機会が訪れる。
Beyond code, configuration and data changes can lead to failures. An inability to treat these with the same care and robust processes can lead to outages. Software is made up of code, instructions that tell the computer how to operate. But these instructions may reference configuration files or other data which can also lead to failures. Consider a local ice cream store with a mobile app. The app may contain code for displaying a menu based on a set of items defined in a configuration file (or received from a server). Even if the code for displaying the menu doesn't change, a change to the configuration file could trigger a previously unknown bug — for example an apostrophe being added for the first time with "Cookies 'n Cream" — causing the app to crash.	コードの変更だけでなく、設定やデータの変更も障害につながる可能性がある。これらの変更を同じ注意深さと堅牢なプロセスで処理できないと、サービス停止につながる可能性がある。ソフトウェアはコードで構成されており、コードはコンピュータに操作方法を指示する命令である。しかし、これらの命令は設定ファイルやその他のデータを参照することがあり、それも障害につながる可能性がある。モバイルアプリを導入している地元のアイスクリーム店を考えてみよう。このアプリには、設定ファイル(またはサーバーから受信)で定義されたアイテムのセットに基づくメニューを表示するためのコードが含まれている可能性がある。メニューを表示するためのコードに変更が加えられていなくても、設定ファイルに変更が加えられた場合、例えば「Cookies 'n Cream」の最初の文字にアポストロフィが追加されるなど、これまで知られていなかったバグが引き起こされ、アプリがクラッシュする可能性がある。
The principle of treating code, configuration files, and data changes with the same care is especially critical when building software run by banks, hospitals, and transportation services. Software vendors must use appropriate software architecture and processes to guard against unexpected failures from both code and non-code changes.	コード、コンフィギュレーション・ファイル、データの変更を同じように慎重に扱うという原則は、銀行、病院、交通機関が運営するソフトウェアを構築する際には特に重要である。ソフトウェア・ベンダーは、適切なソフトウェア・アーキテクチャとプロセスを使用して、コードとコード以外の変更の両方による予期せぬ障害に備えなければならない。
Everything Everywhere All at Once may be a great movie – but it's a poor strategy for deploying software changes. Even the most rigorous testing environment can't mirror the diversity of real-world computers. When deploying changes to automatically updating software, one common strategy to mitigate this risk is to initially deploy to a small subset of machines, and then rolling out to more users after it’s confirmed that the smaller subset has continued to function without interruption. It's important to consider this strategy for not just code changes, but also updates to configuration and data.	Everything Everywhere All at Once（すべてを一度に）」は素晴らしい映画かもしれないが、ソフトウェアの変更を展開する戦略としては不適切だ。どんなに厳密なテスト環境でも、実世界のコンピュータの多様性を反映することはできない。自動更新ソフトウェアの変更を展開する場合、このリスクを軽減するための一般的な戦略の1つは、最初に少数のマシンのサブセットに展開し、少数のサブセットが中断することなく機能し続けることが確認された後に、より多くのユーザーに展開することである。コードの変更だけでなく、設定やデータの更新についても、この戦略を検討することが重要だ。
Auto-updating software can be an important mechanism to ensure that critical security or stability updates get deployed in a timely manner. For security software, it can help ensure companies using the software are running a version able catch the latest threats. Yet, software vendors may unnecessarily risk causing widespread outages by deploying these updates broadly without a mechanism to detect and reverse changes that cause major issues for a high percentage of machines before the software is widely deployed.	ソフトウェアの自動更新は、重要なセキュリティ更新や安定性更新をタイムリーに展開するための重要なメカニズムになり得る。セキュリティ・ソフトウェアの場合、そのソフトウェアを使用している企業が、最新の脅威に対応できるバージョンを実行していることを保証するのに役立つ。しかし、ソフトウェアベンダーは、ソフトウェアが広く展開される前に、高い割合のマシンに重大な問題を引き起こす変更を検知し、元に戻す仕組みがないまま、これらのアップデートを広く展開することで、不必要に広範囲に機能停止を引き起こすリスクを負う可能性がある。
Platforms and operating systems that fail to provide resilient APIs risk the stability of the whole system. An API, or application programming interface, is a way for two pieces of software to communicate in a structured way. For example, the local ice cream store's app may use the phone's location API to tell a customer how far they are from the store. A poor API design could mean that a mistake by the app's programmer causes the customer's whole phone to crash, rather than just the app itself. Building APIs that account for human error can help programmers by limiting the damage from mistakes and preventing small issues from becoming larger ones.	レジリエンスAPIを提供できないプラットフォームやオペレーティングシステムは、システム全体の安定性をリスクにさらす。API（アプリケーション・プログラミング・インターフェース）とは、2つのソフトウェアが構造化された方法でコミュニケーションするための方法である。例えば、地元のアイスクリーム店のアプリは、携帯電話の位置情報APIを使用して、顧客に店舗からの距離を伝えるかもしれない。APIの設計が不十分だと、アプリのプログラマーのミスによって、アプリそのものではなく、顧客の携帯電話全体がクラッシュしてしまう可能性がある。ヒューマンエラーを考慮したAPIを構築することは、ミスによる被害を抑え、小さな問題が大きな問題に発展するのを防ぐことで、プログラマーを助けることができる。
However, creating resilient APIs is not an excuse to lock competitors out of the access they need to build effective alternatives. In order to be competitive with a platform or operating system vendor's own offerings, some types of software require broad, low-level access (the ability to read detailed information and control aspects of the inner workings of a system). Some might argue that allowing such access to third parties requires companies to sacrifice resiliency, and that they can only have one or the other. But just as competition through interoperability can coexist with privacy and security, so too can interoperability coexist with reliability. When platforms or operating system build safer versions of these interfaces, they must do so in a way that, to the fullest extent possible, supports, rather than suppresses, the ecosystem of existing and emerging products. Incumbent companies shouldn't use API changes in the name of resilience as an excuse to cut off broad access for competitors, especially not while continuing to retain broad access for their own offerings.	しかし、レジリエンスAPIを作ることは、競合他社が効果的な代替手段を構築するために必要なアクセスを締め出す言い訳にはならない。プラットフォームやオペレーティングシステムベンダーが提供するものと競争力を持つためには、ソフトウェアの種類によっては、広範で低レベルのアクセス（詳細な情報を読んだり、システムの内部動作の側面を管理したりする能力）が必要になる。このようなアクセスをサードパーティに許可すると、企業はレジリエンスを犠牲にしなければならず、どちらか一方しか手に入れることができないと主張する人もいるかもしれない。しかし、相互運用性を通じた競争がプライバシーやセキュリティと共存できるように、相互運用性も信頼性と共存できる。プラットフォームやオペレーティングシステムがこれらのインターフェースの安全なバージョンを構築する際には、可能な限り、既存製品や新興製品のエコシステムを抑制するのではなく、むしろサポートするような方法で行わなければならない。レジリエンシーの名の下にAPIを変更することは、競合他社への幅広いアクセスを遮断する口実としてはならない。
Widespread software outages can lead to substantial consumer injury including the inability to access critical services and financial loss. Given the enormous impacts on consumers, small businesses, and the public that arise from failures in computer systems, FTC staff will continue to monitor such developments and investigate when warranted. The FTC has long examined companies' computer systems to determine whether proper steps were taken to secure the systems and the consumer data they hold. The FTC’s record investigating computer systems has shown that there are steps companies can take to minimize the likelihood of bad outcomes. While the state of the art in software continues to improve, there are known approaches that systemically and preemptively address many potential issues, either entirely preventing them or dramatically reducing the likelihood of them occurring.	広範なソフトウェア停止は、重要なサービスへのアクセス不能や金銭的損失など、消費者に多大な損害をもたらす可能性がある。コンピュータ・システムの障害によって消費者、中小企業、一般大衆に甚大な影響が及ぶことを考慮し、FTCのスタッフは今後もこのような事態の発生を監視し、必要な場合には調査を行う。FTCは長年にわたり、企業のコンピューター・システムを調査し、システムおよびシステムが保有する消費者データのセキュリティに適切な措置が取られているかどうかを判断してきた。FTCのコンピューター・システムに関する調査実績は、企業が悪い結果を招く可能性を最小限に抑えるために講じることのできる措置があることを示している。ソフトウエアの技術水準は向上し続けているが、潜在的な問題の多くに体系的かつ先制的に対処し、その発生を完全に防止するか、あるいはその可能性を劇的に低減するアプローチが知られている。
Thank you to the staff who contributed to this post: Simon Fondrie-Teitler, Hannah Garden-Monheit, Wells Harrell, Amritha Jayanti, Erik Jones, Stephanie T. Nguyen, Shaoul Sussman, Grady Ward, Ben Wiseman.	この投稿に協力してくれたスタッフに感謝する： Simon Fondrie-Teitler、Hannah Garden-Monheit、Wells Harrell、Amritha Jayanti、Erik Jones、Stephanie T. Nguyen、Shaoul Sussman、Grady Ward、Ben Wiseman。

---

ちなみに、

映画 Everything Everywhere All at Once

 ・[wikipedia]

予告編

・[YouTube]

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.08.11 CROWDSTRIKE ファルコンのトラブルの根本原因分析報告書 (2024.08.06)

・2024.08.05 米国 GAO ブログ CrowdStrikeの混乱がソフトウェア・アップデートによる主要なサイバー脆弱性を浮き彫りにする (2024.07.30)

・2024.07.20 米国 CISAもCrowdStrikeの更新の問題について情報提供をしていますね...はやい...