気になった記事2つ（大変革期に突入した自動車産業とサイバーセキュリティ、クラウドネイティブセキュリティ101）

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

今日は、気になった記事を2つ紹介したいと思います。

最初は、JNSAの自動車セキュリティに関連する記事で、J-Auto-ISACの中島さんの記事です...

● JNSA - リレーコラム

・2021.04.16 第209号：大変革期に突入した自動車産業とサイバーセキュリティ

印象に残ったのが、

---

すでにクルマの制御プログラムに使用するソースコードの総行数はスマホOSの1,200万行、戦闘機の2,400万行を大きく上回り、２億行に迫っています。今後の自動運転技術の進展を踏まえて６億行に達するという予測も出ています。

---

という話です。自動車のコードって戦闘機よりのコードよりも多いんですね。プロが乗る戦闘機と違い、一般大衆が乗る自動車だからこそ、エラー処理も含めて丁寧に対応する必要もあってコードが増えているという面もあるのですかね。。。

まぁ、いずれにしても2億行もコードがあれば、どこかに脆弱性はあるでしょうし、いろいろな利害関係者のネットワークと思うと対応が難しいかもしれませんね。。。そして、

---

今、自動車業界は「ソフトウェアのサプライチェインマネジメント」という課題に直面しています。しかし何層もの裾野産業に支えられた巨大なピラミッド構造を考えると解決は容易ではありません。

---

という話です。

ソフトウェアというかプログラムの資産管理が必要かもしれませんね。。。ソフトウェアBOMのような仕組みです。オープンソフトも含めて考えなければならないのですが、何かアイデアを絞って考える必要がありますね。。。

もう一つは、「クラウドネイティブセキュリティ101」です。

● Cloud Seucurity Alliance

・2021.04.19 Cloud-Native Security 101

これは、Intezerのブログに2021.04.01に掲載されていたものを再掲載したものです。これからクラウドネイティブに変わるとセキュリティについての考え方を変えて行かないといけないのでは、という話です。

Traditional perimeter-based security approaches fall short for cloud-native applications. The deployment and delivery processes have become more decentralized and agile, but security strategies need to be revamped to keep up with development. As those strategies change and enterprises shift to cloud-native applications, what are the do’s and don’ts of security?

従来の境界線を利用したセキュリティアプローチでは、クラウド・ネイティブ・アプリケーションには対応できません。デプロイメントとデリバリーのプロセスはより分散化され、アジャイルになっていますが、開発に追いつくためにはセキュリティ戦略を見直す必要があります。このような戦略の変化と企業のクラウドネイティブアプリケーションへの移行に伴い、セキュリティの「やるべきこと」と「やってはいけないこと」はどのようになっているのでしょうか。

という話です。

deployment と delivery の違いとか、整理しないといけないなぁと思ったりしました。。。

次のポイントが指摘されていました。参考まで...

The “Cattle, Not Pets” Approach	「ペットではなく牛」というアプローチ
Dynamically scalable environments drive agility in the cloud, where environments are created and destroyed as needed. This means that security should be integrated with the deployment process through security as code to keep up with the speed of development. In short, security should be integrated into design from day one, not as an afterthought.	動的に拡張可能な環境は、必要に応じて環境を作成したり破壊したりするクラウドのアジリティを促進します。つまり、開発のスピードに追いつくためには、セキュリティをコードとして統合し、デプロイメント・プロセスに組み込む必要があります。つまり、セキュリティは後付けではなく、初日から設計に組み込まれるべきなのです。
As workloads move to the cloud, deployments get automated through infrastructure as code (IaC). If you integrate security best practices into IaC, the resources will be protected when you deploy for the first time, reducing the attack surface. Deploying resources first and securing them later leaves your application vulnerable to attack.	ワークロードがクラウドに移行すると、Infrastructure as Code（IaC）によってデプロイメントが自動化されます。IaCにセキュリティのベストプラクティスを統合すれば、最初にデプロイする際にリソースが保護され、攻撃対象が減少します。リソースを先にデプロイし、後からセキュリティを確保すると、アプリケーションは攻撃されやすい状態になります。
...	...
Focus on Runtime Protection	ランタイム保護の重視
When compared to cloud non-native deployments, the focus shifts from perimeter security to runtime security in the cloud. While minimizing attack surface is important, it is also crucial to ensure comprehensive runtime security.	クラウドの非ネイティブなデプロイメントと比較すると、クラウドでは境界線のセキュリティからランタイムのセキュリティに焦点が移ります。攻撃対象を最小限に抑えることは重要ですが、包括的なランタイム・セキュリティを確保することも重要です。
...	...
Undetected Threats in Linux	Linuxに潜む脅威
...	...
Linux is traditionally considered secure, as it has features like SELinux and restricted user access, which is reinforced with cloud firewalls and access control mechanisms. However, recent trends show that Linux is increasingly becoming a preferred target for attackers.	Linuxは、SELinuxのような機能を持ち、ユーザーのアクセスが制限されており、クラウドのファイアウォールやアクセス制御機構で強化されているため、伝統的に安全だと考えられています。しかし、最近の傾向では、Linuxが攻撃者の好ましい標的となるケースが増えています。
...	...
Cloud-Native Microservices	クラウドネイティブなマイクロサービス
...	...
However, keep in mind that the cloud follows a shared responsibility model, where ownership of workload security is still with the customer. Defense-in-depth security practices for cloud-native microservices should include guardrails at all layers, such as the cluster, containers and code security.	しかし、クラウドは責任共有モデルを採用しており、ワークロードのセキュリティの所有権は依然として顧客にあることに留意してください。 クラウドネイティブなマイクロサービスのための徹底したセキュリティ対策には、クラスター、コンテナ、コードセキュリティなど、すべての層でガードレールを設ける必要があります。
...	...
Moving one layer deeper to containers, where the workloads are deployed, it is recommended to implement image scanning to identify compromised images. Enabling the principle of least privilege (PoLP) for users will help to protect against unauthorized access to containers. You should also avoid security anti-patterns, such as disabling SELinux, host root access, and privilege elevation. Any configuration change should be enabled only through CI/CD pipelines, and deviations should be strictly monitored and reported.	また、ワークロードが配置されているコンテナについては、イメージスキャンを実施して危険なイメージを特定することが推奨されます。ユーザーにPoLP（Principle of least privilege）を有効にすることで、コンテナへの不正なアクセスから保護することができます。また、SELinuxの無効化、ホストのルートアクセス、特権昇格など、セキュリティのアンチパターンを避ける必要があります。構成の変更は、CI/CDパイプラインを通じてのみ有効にし、逸脱は厳密に監視して報告する必要があります。
In addition to cluster and container security, you should also ensure code security through static code analysis, third-party library scanning for vulnerabilities, use of automated tools to protect from known attacks, port restriction, and other means.	クラスタやコンテナのセキュリティに加えて、静的なコード解析、サードパーティのライブラリによる脆弱性のスキャン、既知の攻撃から保護するための自動化ツールの使用、ポートの制限などにより、コードのセキュリティを確保する必要があります。
...	...

セキュリティ対策の根本は変わらないと思いますが、重点を当てる部分や手段は環境に合わせて考える必要がありますね。。。

2021.04.20 13:12 追記

「“Cattle, Not Pets”って何？」と質問がきたのですが、これはパブリッククラウドを説明する際に、過去から時々出てくる言い回しのようなもので、要は、「あなたにとってかけがえのないたった一つのペット（従来のオンプレミスの比喩）ではなくて、広大な牧場にいる番号で管理されている牛の群れ（クラウドの比喩）を扱っているという感覚ですよ。。。ということだと思います。。。多分。。。」