賢明な企業は、Infrastructure as Codeのコンセプトを採用していますが、アプリケーションの構築以外でも、安全なコードの作成に大きく貢献できるのは、あなたのような開発者です。最初は長い道のりに思えるかもしれませんが、仲間の中で目立つためには、その道のりに価値があります。

最新の「Coders Conquer Security」シリーズの次の章を始める前に、機密データ保存の脆弱性をゲーム化した課題をプレイしていただきたいと思います。今すぐプレイして、Kubernetes、Terraform、Ansible、Docker、CloudFormationの中から選んでください。

どうでしたか？もし、あなたの知識にちょっとした工夫が必要なら、ぜひ読んでみてください。

最近では、パスワード、個人情報、財務記録などの重要なデータを安置する際にハッシュ化することは、サイバーセキュリティ対策の要となっています。多くの意味で、これは最終的な防御策であると同時に、最良の防御策の一つでもあります。なぜなら、攻撃者が他の防御手段を突破して重要なファイルを入手したとしても、それらが適切にハッシュ化されて保存されている限り、攻撃者にとってはあまり意味がないからです。

また、暗号化されたファイルは、ネットワークの他の部分とは別のキーやパスワードを持つことができるため、悪意のあるインサイダーに対する強固な二次的保護としても機能します。このような場合、システム管理者や管理者の資格を侵害したハッカーなどは、保護されたディレクトリを閲覧することはできても、暗号化キーが別の場所にある場合、そこにある暗号化ファイルを解除することはできません。

もちろん、すべての暗号化保護方式は、最も強力なコンピュータでも解読できない強力な暗号規格を持つことが前提となります。

なぜ安全でない暗号が危険なのか？

コンピュータ技術においては、強力な暗号化アルゴリズムを作ることと、それを解読することは、長い間競争してきました。1977年に米国連邦政府が開発したDES（Data Encryption Standard）は、56ビットのアルゴリズムで、当時のコンピュータの相対的な性能から見て安全であると考えられていました。

しかし、コンピュータは進化し、人々はコンピュータを共同でネットワーク化して、その能力をさらに高める方法を見つけた。1999年には、電子フロンティア財団とDistributed.netが協力して、DESで保護された文書の暗号化をわずか22時間で解除することに成功した。突然、DES暗号で保護された文書は、もはや安全ではなくなってしまったのだ。

信じられないかもしれませんが、一部の組織ではいまだに重要なファイルをDESアルゴリズムで保護していたり、同様に弱い暗号化保護を行っています。1999年当時、56ビットの暗号を解読するには分散型ネットワークが必要でしたが、現在では、十分な性能を持つスタンドアロン型のコンピュータであれば、少し時間をかければ解読することができます。また、ハッカーたちは、グラフィックス・プロセッサ・ユニット（GPU）のバンクを利用したクラッキング専用マシンを開発しました。これらのGPUは、その作業に非常に適しており、比較的安価に入手でき、ローカルにネットワークを構築することができます。

今日、重要なファイルを安全ではない、あるいは弱い暗号アルゴリズムで保護することを選択した場合、ほとんどのハッカーがそれらのファイルを破壊して読めるようにするまでに、それほど時間はかからないでしょう。もし、あなたがデータ漏洩の被害に遭った場合、十分に保護されていなかった場合は、いずれファイルが漏洩することを想定しなければなりません。

例えば、以下のKubernetesのコードスニペットでは、NGINX ingress controllerレベルの情報を保護するために弱い暗号アルゴリズムを使用しています。

apiVersion: v1
kind:ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers:DES-CBC3-SHA
ssl-protocols:"TLSv1.2"

この例では、情報の保護にDES暗号スイートが使用されています。しかし、攻撃者はこれを簡単に解読し、機密情報にアクセスすることができます。

強力な暗号アルゴリズムを使用することが推奨されています。以下のKubernetesの例では、NGINX ingress controllerレベルの情報を保護するために強力な暗号スイートが使用されています。

apiVersion: v1
kind:ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers:|
ecdhe-ecdsa-aes256-gcm-sha384:ecdhe-rsa-aes256-gcm-sha384:
ecdhe-ecdsa-chacha20-poly1305:ecdhe-rsa-chacha20-poly1305:
ecdhe-ecdsa-aes128-gcm-sha256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA256
ssl-protocols:"TLSv1.2"

この例では、攻撃者が機密情報にアクセスできる可能性を回避するために、強力な一連の暗号が使用されています。

強力な暗号化で重要な情報を守る

現在では、ほとんど破られない強力な暗号が利用できます。2001年、米国国立標準技術研究所（NIST）は、DESに代わる新しい暗号化技術を開発しました。AES（Advanced Encryption Standard）と呼ばれるこの技術は、128ビット、192ビット、256ビットの3種類の異なる鍵長を使用します。最も安全性が高いのは256ビットのAES暗号ですが、現在の技術では3種類ともほとんど解読できないとされています。スーパーコンピュータを使った実験では、AESで保護されたほとんどの文書を解読するには、何千年もの時間をかけて作業を続ける必要があるとされています。

重要なファイルを適切に保護するために、開発者はまずそのファイルを特定する必要があります。ネットワーク上のすべてのファイルを暗号化する必要はありません。常に暗号化と復号化を繰り返すことで業務が滞る可能性があるからです。しかし、人事記録、顧客データ、財務情報などの重要なファイルは十分な保護が必要です。基本的には、セキュリティと実用的なシステムのバランスを取ることが重要です。

そして、そのデータはAES規格のいずれかで暗号化されなければなりません。絶対に悪用されてはならない重要な情報の場合は、256ビットの暗号化も可能です。

もうひとつ考慮しなければならないのは、暗号化を追加するということは、サイトにパスワードを増やすようなものだということです。つまり、認証されたユーザーが暗号化キーを管理する必要があるということです。ワークフローのボトルネックになるのを防ぐために、鍵管理プラットフォームの導入を検討し、鍵を管理して安全に保管することをお勧めします。また、鍵の集中管理を行わない場合でも、すべての鍵とパスワードが保護されていることを確認し、最も安全なデータ保管庫に権限のないユーザーが立ち入らないようにしてください。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォーム内のIaC チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。

セキュアなインフラストラクチャ・アズ・コードを組織内に導入する際、あなたはどのように取り組んでいますか？多少の学習曲線はあるかもしれませんが、ロープを学ぶことは、自分のスキルセットをレベルアップさせ、同僚の中で際立った存在になり、より多くのエンドユーザーのデータを安全に保つための大きなチャンスとなります。

最新の「Coders Conquer Security」シリーズの次の章を始める前に、機密データ保存の脆弱性をゲーム化した課題をプレイしていただきたいと思います。今すぐプレイして、Kubernetes、Terraform、Ansible、Docker、CloudFormationの中から選んでください。

どうでしたか？もし、あなたの知識にちょっとした工夫が必要なら、ぜひ読んでみてください。

最近のコンピュータ・セキュリティでは、ほとんどの場合、パスワードが使われています。二要素認証や生体認証など、他のセキュリティ方法を採用していても、ほとんどの組織では、保護の一要素としてパスワードによるセキュリティを採用しています。多くの企業では、パスワードを独占的に使用しています。

私たちはパスワードを多用しており、その作成方法にはルールがあるほどです。これは、ブルートフォース攻撃や不正な推測に対する脆弱性を減らすためのものです。もちろん、未だに脆弱なパスワードを使用している人もいて、NordPass社の最近のレポートでもそれが証明されています。2020年になっても、人々が最も重要な資産を守るために、12345や、chocolate、password、godなどの推測可能な言葉を使っているとは信じがたいことです。

強力なパスワードの使用を望まない人は常にいますが、ほとんどの専門機関では、ユーザーに一定の方法でアクセスワードやフレーズを作成することを義務付けています。パスワードは8文字以上で、大文字と小文字の両方で構成され、少なくとも1つの数字と特殊文字が必要であるというルールは、もう誰もが知っていることでしょう。

悪いことに、ユーザーが最強のパスワードを作るためのルールを守ったとしても、それがすべて平文で保存されていたら意味がありません。12345というパスワードは、ハッカーがパスワードファイル全体を読み取ることができれば、Nuts53!SpiKe&Dog12と同じくらい悪いものになってしまいます。

なぜパスワードを平文で保存することが危険なのか？

パスワードを平文で保存することは、システムとユーザーの両方を危険にさらすことになるため、よくありません。ハッカーがシステムへのアクセスに使われたすべてのパスワードを見つけて読み取ることができれば、大惨事になることは明らかです。ハッカーは、管理者資格を持つユーザーを見つけるだけで、システムやサイト全体を危険にさらすことができます。また、適切なユーザー名とパスワードを使用しているため、内部のセキュリティでは侵入を発見できなかったり、被害が拡大してからでは間に合わなかったりします。

平文で保存されたパスワードを攻撃者が簡単に盗めるようになると、多くの人がパスワードを使い回してしまうため、ユーザーにとっても不都合が生じます。パスワードの作成が非常に難しくなったため、多くの人が覚えているパスワードを複数のサイトで使いまわしています。攻撃者がパスワードファイルを侵害した場合、ほぼ確実に同じ名前とパスワードを使って他のシステムにアクセスしようとするため、ユーザーは二次的な犯罪に巻き込まれる危険性が高くなります。

誤ってパスワードをプレーンテキストで保存してしまったり、それが将来的に大きな問題を引き起こす可能性があることに気づかなかったりすることは比較的簡単です。例えば、以下のコードはTerraformテンプレートを使ってAWSリソースを定義する際に、パスワードを保存するためによく採用される方法です。

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}。

この例では、AWSのMySQLデータベースインスタンスを管理するためのパスワードが平文で保存されています。つまり、ソースコードリポジトリにアクセスできる人なら誰でも読めてしまうし、コピーもできてしまうのです。

パスワードの保護は、フレームワークによって異なりますが、保護方法はどのプラットフォームにも存在します。例えば、MySQLのパスワードは、AWS Secrets Managerのような安全なストレージに保存することができます。

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}。

この例では、TerraformテンプレートはAWS Secrets Managerサービスからパスワードを取得し、テンプレートファイルに平文で保存されることはありません。

平文保存を避けてパスワードを保護する

パスワードは王国の鍵であり、決して平文で保管すべきではありません。たとえ組織の内部の人間であっても、保護されていないパスワードの大規模な保管場所にアクセスすべきではありませんし、このようなことはビジネスプロトコルとして認められるべきではありません（最近では、暗号化された認証情報の共有を可能にするパスワードマネージャがたくさんあります。また、悪意のある内部の人間がファイルを盗み見て、アクセスすべきでないところにアクセスしてしまう危険性もあります。

また、外部からの攻撃では、SQLインジェクションのような単純な脆弱性によってデータベースへのバックドアが発見され、パスワードが保存されているディレクトリにもアクセスされた場合、二重の苦しみを味わうことになります。これは、実現するにはあまりにも多くのエラーを伴う手順だと思いますか？悲しいことに、2011年に発生したソニーの情報漏えい事件では、まさにこのシナリオが起こりました。100万件以上の顧客のパスワードが平文で保存されており、Lulzsecのハッキンググループは、一般的なSQLインジェクション攻撃によって、これらのパスワードにアクセスしたのです。

すべてのパスワードは、サポートするフレームワーク内で利用可能なあらゆる防御策によって保護されるべきです。Terraformでは、パスワードをテンプレートファイルに保存してはいけません。インフラストラクチャ・プロバイダーによっては、AWS Secrets ManagerやAzure Key Vaultのような安全なストレージを使用することが推奨されます。

ユーザーに安全なパスワードの作成を強制するのは良いアイデアですが、それに加えてバックエンドでも役割を果たす必要があります。パスワードを平文で保存しないようにすることは、ユーザーとシステムの保護に大いに役立ちます。パスワードを平文で保存することの主な危険性は、アクセス制御が不十分なことです。つまり、誰でも見ることができるのです。特にIaC環境では、突然多くの人が機密情報にアクセスできるようになるため、パスワードを適切にハッシュ化し、どうしてもアクセスが必要な人だけに許可を与えることが必要です。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性について、また、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守る方法について、より詳しい情報をご覧いただけます。また、Secure Code Warrior トレーニングプラットフォーム内のIaC チャレンジのデモを試すことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

ソフトウェア制作に携わったことのある人なら、セキュリティを考慮する際に、開発者とそのコードを精査するセキュリティ専門家との間に起こりうる緊張感を知っていることでしょう。

昔は、開発チームがコードの出荷をできるだけ遅くして、セキュリティの専門家が脆弱性をチェックできる期間を意図的に短くすることが珍しくありませんでした。結局、何か問題があった場合にリリースを遅らせることができますし、次の素晴らしい機能の構築に着手したいという気持ちがすでにありました。しかし、これは最終的にはマイナスの影響をもたらしました。コードが最終的にチェックされたとき、時には外部からの侵入がすでに発生した後に、コードはまだ開発者に跳ね返り、彼らのソフトウェアの赤ちゃんはセキュリティチームから醜いと言われ、彼らは数ヶ月前に最後に触ったコードをホットフィックスするためにすべてを捨てなければなりませんでした。

この機能不全は現在も続いていますが、大きな問題があります。それは、より多くのコードが開発され、データ侵害が発生した場合の社会のリスクがはるかに大きくなっていることです。このような古臭い戦いを続けている時間はもはやありません。2020年には、私たち全員が同じ側に立って悪者に対抗する時が来たのではないでしょうか。

私たちは、セキュリティが組織全体、そしてSDLC全体で共有された責任であると考えられる段階に到達しなければなりません。これは、本格的なサポート体制の整ったDevSecOps環境に取り組めば、確実に実現できます。さらに、適切なトレーニングとツールを使って開発チームのセキュリティに火をつけると、バグを潰すだけでなく、長い間、手薄になっていたセキュリティ専門家の負担を軽減する強力な力となります。

私の最新のウェビナー「How to put the "Sec" in DevOps」をぜひ見ていただきたいと思います。

これは、24時間のサミットイベント「AllTheTalks」の一環として行われたもので、深く掘り下げた内容になっています。

• 旧来の開発手法がセキュリティのベストプラクティスを困難にした理由
• なぜDevSecOpsが一般的なセキュリティ脆弱性を阻止するための最新のゲームチェンジャーなのか
• 組織における共有責任としてのセキュリティとは何か
• 開発者が自信を持って安全なコードを出荷できるようにするには、開発者が好きなこと（ヒント：素晴らしい機能の構築）を犠牲にすることなく、どのようにすればよいのでしょうか。

お会いしましょう。

昨今のサイバーセキュリティに対する脅威は、どこにでもあり、絶え間なく続いています。私たちの生活がデジタル化されればされるほど、サイバー犯罪者にとっての脅威は大きくなります。また、プログラムが導入された後に、攻撃対象のあらゆる側面を把握して防御しようとすることは、ほとんど不可能になっています。

このような症状を軽減するためのアプローチがありますが、その1つがInfrastructure as Code（IaC）のコンセプトを採用した賢明な組織です。もちろん、どのような開発でも、セキュリティ上の落とし穴があることは言うまでもありません。開発者は、アプリケーションをホストするための重要なインフラを生成するコードを作成しているため、プロセスのあらゆる段階でセキュリティを意識することが重要です。

では、クラウドサーバ環境に慣れていない開発者は、どのようにしてスキルアップし、ノウハウを学び、セキュリティ意識を高めて構築に臨めばよいのでしょうか。ここでは、IaCの一般的な脆弱性に取り組むため、「Coders Conquer Security」シリーズを作成しました。ここからの数回のブログでは、開発者が組織内でコードとしての安全なインフラを展開するためのステップに焦点を当てます。

さあ、始めましょう。

アメリカの旧西部には、山賊に襲われるのではないかと疑心暗鬼になっていた男の寓話がある。そのために彼は、頑丈な玄関ドアを設置したり、窓をすべて塞いだり、手の届くところにたくさんの銃を置いたりと、あらゆる種類のセキュリティに投資しました。それでも、ある夜、寝ている間に横のドアの鍵をかけ忘れて強盗に入られてしまった。窃盗団は、セキュリティの不備を見つけて、すぐにその状況を利用したのです。

インフラのセキュリティ機能が無効化されていることは、それとよく似ています。ネットワークに強力なセキュリティインフラがあったとしても、その要素が無効化されていては意味がありません。

飛び込む前に課題を提示します。

上のリンクをクリックすると、ゲーム性のあるトレーニングプラットフォームに移動し、今すぐ無効化されたセキュリティ機能の脆弱性の解消に挑戦することができます。(注意してください。しかし、ドロップダウンメニューを使えば、Docker、CloudFormation、Terraform、Ansibleから選ぶことができます）。)

あなたはどうでしたか？まだまだ課題があるという方は、ぜひ読んでみてください。

セキュリティ機能は、さまざまな理由で無効になることがあります。アプリケーションやフレームワークによっては、デフォルトで無効になっていて、機能を開始するためにはまずオンにする必要があります。また、管理者が特定のタスクをより簡単に実行できるように、特定のセキュリティ機能を無効にしている可能性もあります（例：AWSのS3バケットを公開する）。作業終了後、管理者は無効にした機能を再び有効にすることを忘れてしまうかもしれません。また、今後の作業を容易にするために、無効にしたままにしておくこともあるでしょう。

無効化されたセキュリティ機能が危険な理由

1つ以上の無効なセキュリティ機能を持つことは、いくつかの理由でよくありません。一つは、そのセキュリティ機能は、既知のエクスプロイト、脅威、または脆弱性から保護するためにインフラストラクチャリソースに搭載されています。それが無効になっていると、リソースを保護することができません。

攻撃者は常に、簡単に利用できる脆弱性を最初に見つけようとし、スクリプトを使って一般的な弱点を洗い出すこともあります。これは、泥棒が通りにあるすべての車をチェックして、鍵のかかっていないドアがないかどうかを確認するのと同じで、窓を破壊するよりもずっと簡単なことです。ハッカーは、一般的なセキュリティの防御策が不発であることに驚くかもしれません。しかし、そうなれば、それを悪用するのに時間はかからないでしょう。

第二に、優れたセキュリティを導入しておきながら、それを無効にしてしまうと、誤ったセキュリティ意識が生まれます。管理者は、誰かがその防御機能を無効にしたことを知らなければ、一般的な脅威から守られていると思うかもしれません。

無効化されたセキュリティ機能を攻撃者がどのように利用するかの例として、AWS S3のセキュリティ機能であるパブリックアクセスのブロックを考えてみましょう。Amazon S3のブロックパブリックアクセスを使えば、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限するための集中管理を簡単に設定することができます。しかし、S3バケットへのアクセス時に問題に遭遇した管理者の中には、できるだけ早くタスクを完了させるために、バケットを公開することを決める人もいます。もしそのセキュリティ機能を有効にするのを忘れてしまうと、攻撃者はそのS3バケットに保存されている情報に完全にアクセスすることができ、情報の漏洩だけでなく、データ転送料による余分なコストが発生してしまいます。

実際のコードを比較してみましょう。以下のCloudFormation snippetsをご覧ください。

ヴァルネラブル。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

確保。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

セキュリティ機能の無効化を防ぐ

無効にしたセキュリティ機能が組織に悪影響を与えないようにするには、ポリシーと実践の問題があります。非常に特殊な状況下でのみセキュリティ機能を無効にすべきであるという確固たるポリシーを設定する必要があります。問題の解決やアプリケーションの更新のために、機能を一時的に無効にしなければならない場合は、その記録を取る必要があります。必要な作業が完了した後、機能が完全に再有効化されていることを確認する必要があります。

業務を効率化するためにセキュリティ機能を恒久的に無効にしなければならない場合は、影響を受けるデータに他の保護機能を提供し、デフォルトの保護機能がない場合でもハッカーがアクセスできないようにする必要があります。必要な保護機能が無効化されている場合、攻撃者が鍵のかかっていないドアを見つけ、その状況を悪用するのは時間の問題です。

より多くのことを学び、自分自身に挑戦する。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

この記事を読んで、この脆弱性を見つけて修正する準備はできましたか？Secure Code Warrior プラットフォーム上のIaC のゲーム化されたセキュリティチャレンジに挑戦して、サイバーセキュリティのスキルを磨き、最新の状態にしましょう。

このシリーズでは、Infrastructure as Codeの脆弱性のトップ8を毎週紹介しています。

このブログでは、開発者が組織内にセキュアなインフラを導入する際に、まったく新しいレベルのセキュリティ意識を身につけることができます。

ところで、前回のブログで紹介した「セキュリティの設定ミス」はどうだったでしょうか？もし、今すぐにでも、機能レベルのアクセスコントロールの脆弱性の行方に取り組みたいという方は、プラットフォームにお越しください。

(上のリンクからKubernetesのチャレンジにアクセスできますが、プラットフォームにアクセスしたら、ドロップダウンを使ってAnsible、CloudFormation、Terraform、Dockerからも選択できます。お好みでどうぞ)

現在配備されているほとんどのアプリケーションは、何らかのアクセス制御メカニズムを持っており、要求された機能を実行する権限がユーザーにあるかどうかをチェックしています。これは、アプリケーションを作成する際に、機能性と同様に、優れたセキュリティの基礎となるものです。実際、すべてのWebアプリケーションには、異なる権限を持つユーザーがプログラムを使用できるようにするためのアクセス制御が必要です。

しかし、アクセスコントロールのための同じ検証機能が、インフラレベルで行われていなかったり、誤って設定されていたりすると、問題が発生します。インフラレベルのアクセスコントロールが完璧に行われていないと、企業全体がハッカーに開放されてしまい、ハッカーはその脆弱性をゲートウェイとして、不正なスヌーピングや完全な攻撃を行うことができます。

実は、機能の欠落や設定ミスによるアクセス制御の脆弱性を利用することは非常に簡単です。攻撃者は、過度な技術を必要としません。アプリケーションをサポートしているフレームワークの中で、どのようなコマンドが機能を実行するかを知っていればよいのです。もし知っていれば、あとは試行錯誤するだけです。攻撃者は、許可されていないはずのリクエストを継続的に送信することができ、1つでも成功すれば、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開されることになります。

Missing Function Level Access Control Exploitsの仕組みとは？

機能レベルのアクセス制御が組織に入り込んでしまう方法はいくつかあります。例えば、機能レベルのアクセスをアプリケーションに任せて、基盤となるインフラで検証しないことがあります。また、インフラストラクチャレベルのアクセス制御が誤って設定されることもあります。管理者は、上位のユーザだけが見ることができるはずのインフラストラクチャリソースへのアクセス方法を、権限のないユーザは知らないだろうと想定し、「Security by Obscurity」モデルを使用する場合がありますが、これはほとんど機能しません。

Security by Obscurityの例としては、以下のURLが攻撃を受けやすいと考えられます。

http://companywebsite.com/app/NormalUserHomepage

認証されたユーザーがForced URL Browsingと呼ばれる技術を使用すると、管理者にしか表示されないページに到達しようとする可能性があります。例えば、以下のような例が考えられます。

http://companywebsite.com/app/AdminPages

サーバー側の検証がない場合、攻撃者は単に管理ページを表示し（その名前がリクエストと一致する場合）、新しいページから管理者が行うあらゆる追加機能にアクセスできるようになります。サーバが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページの名前が何であれ、それが分かるまで単に試し続けることができます。

攻撃者にとって、不足している機能レベルのアクセス制御を悪用することも同様のプロセスです。不正なページを閲覧しようとするのではなく、機能リクエストを送信します。例えば、管理者権限を持つ新しいユーザーを作成しようとする場合です。その場合のリクエストは、フレームワークにもよりますが、以下のようなものになります。

POST/action/createuser name=hacker&pw=password&role=admin

機能レベルのアクセス制御が存在しない場合は、上記の例が成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者として再ログインすると、そのネットワークやサーバの他の管理者と同じアクセス権と権限を持つことになります。

機能レベルのアクセスコントロールができない場合の対処法

機能レベルのアクセス制御の脆弱性を悪用することは、攻撃者にとって非常に容易であるため、これらの脆弱性を発見し、修正し、防止することが非常に重要です。ありがたいことに、いくつかのノウハウと基本的なInfrastructure asCodeのセキュリティトレーニングがあれば、これはそれほど難しいことではありません。

主な保護策は、インフラレベルでのロールベースの認証を実装することです。この機能をアプリケーションに任せてはいけません。仮にアプリケーションが処理したとしても、インフラ側で認証を行うことで、見落としがないようにすることができます。理想的には、認証は集中管理された場所（例えば、AWS IAM、Azure IAMなど）から行われ、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用されるべきです。これらの認証プロセスは、フレームワーク自体から来ることもあれば、使いやすい外部モジュールから来ることもあります。

最後に、組織は最小特権の概念を受け入れるべきです。すべての行動や機能はデフォルトでは拒否され、認証プロセスによって有効なユーザに必要な権限が与えられるべきです。必要な機能を実行するのに十分な権限を、必要な期間だけ与えるべきです。

機能レベルのアクセス制御ができなくなると、壊滅的なダメージを受けます。しかし、幸いなことに、インフラレベルの適切な認証方法を組織に組み込むことで、この問題を簡単に防ぐことができます。

アクセス制御のバグを発見する準備ができたと思いますか？これらのDockerのコードスニペットを比較してみてください。

ヴァルネラブル。

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

確保。

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

より多くのことを学び、自分自身に挑戦する

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

また、先ほど見逃してしまった方は、Secure Code Warrior プラットフォーム上で、IaCのゲーム化されたセキュリティチャレンジに挑戦し、あらゆるサイバーセキュリティのスキルを磨いて最新の状態に保つことができます。

次の章をお楽しみに

本記事は、組織内の PCI-DSS コンプライアンスに関するミニシリーズのパート 2 です。この最終章では、CTO と CISO が、サイバーリスクを低減し、プロセスをシームレスに成功させるために、そして開発者にとっても少し楽しいものにするために、どのようにトップから指揮を執ることができるかを詳しく説明します。パート1をご覧になりましたか？ こちらをご覧ください。AppSecのスペシャリストがどのようにしてこのチャンスをつかみ、より良いセキュリティ成果を得ることができるかをご覧ください）。)

PCI-DSS のベストプラクティスは、間違いなく共通の責任ですが、CISO と CTO は、繁栄する積極的なセキュ リティプログラムを構築する上で、その大きな影響力をトップから活用することができます。CISO と CTO は、エンドユーザに対するサイバーセキュリティの信頼性とそれに関連する感情の代弁者であり、意識を早期に高めることで強力なトリクルダウン効果を発揮し、開発者や AppSec の専門家が社内の強固なセキュリティ体制に貢献するために必要な知識、ツール、サポートを得られるようにします。

コンプライアンスを維持することは重要ですが、全員が「なぜ」に賛同し、成果を実感し、適切な方法で育成されれば、プログラムは法律を超えて自然なものになります。

CTOとCISOは、相互の信頼関係を築く役割を担っている

最近、あるサイトにアクセスした際に、クレジットカードの詳細情報を渡すのをためらったことはありませんか？近所のピザ屋さんのオンライン注文に使われている怪しげなウェブアプリでもない限り、このような経験をすることはあまりないのではないでしょうか。

もちろん、データ違反を公表していなければの話ですが。

世界的な宿泊施設大手のマリオットは、3年以内に2回目の情報漏洩を公表し、今回は520万人の顧客記録が盗まれました。2018年に発生した大規模な情報漏えい事件では、3億8300万人の顧客が危険にさらされ、暗号化されていない500万人分のパスポート番号と800万人分のクレジットカード番号が盗まれましたが、今回は支払い情報はまだ盗まれていないようです。

マリオットブランドに対する顧客の信頼度がまだ低かったとしても、もうすぐ底をつくと言っても過言ではありません。このような事態に陥ると、CISOはサイバー脅威との戦いでカモにされているような気がして、夜も眠れなくなります。Equifax、Yahoo、Sony、Targetなど、大規模な情報漏洩に見舞われた大手企業の例を見ても、盗まれたデータ記録は数十億件、被害額は数千億ドルにのぼり、経済的には顧客の心に穴が開いたような状態になっています。企業にとっては最悪の事態であり（Target社は2014年の情報漏えい事件の後の四半期に4億4,000万ドルの減益を報告しています）、個人の責任は通常問われませんが（結局のところ、ソフトウェアのセキュリティは共有の責任であるべきなのです）、たまたま当時これらの組織で働いていたとしたら、輝かしい履歴書には書きたくないことです。

決済、センシティブなデータ、そして好意的な顧客感情という無形の金を扱う組織において、コンプライアンスを達成するために強固なセキュリティプログラムを見送ることは、企業がリスクを抱えているだけでなく、イノベーションに大きく遅れをとっていることを示しています。

お客様と組織の関係における信頼性の問題は、誰もが気になるはずです。

IT部門、開発部門、セキュリティ部門が侵害された後に直面するストレスや災難を別にすれば、信頼の要素は、新しい会社の長期的な成功や、既存の会社が継続的に成長するための主要な要素です。信頼を失った結果、会社が経済的に落ち込むことになれば、失うものは明らかに仕事です。

PCI-DSS規制は、企業に責任を負わせるものであり、上記の通り、これらの綿密な計画を無視することは非常に大きな意味を持ちます。しかし、PCI-DSS規制は、導入されたセキュリティプログラムとその中で働く人々によってのみ有効です。PCI-DSS規制に真剣に取り組み、意識を高く持ち、他の企業の模範となれば、非常に良い意味での差別化を図ることができます。

意識がすべてです。

セキュリティ意識向上プログラムが機能していないと、PCI に準拠しようとしてもほとんど意味がありません。ベストプラクティスガイドラインでは、組織全体のセキュリティ意識が最も重要な部分を構成しています。ベストプラクティスガイドラインでは、組織全体のセキュリティ意識をどのように部門横断的な役割で実施できるか、また、正しく実施している企業ではどのように見えるかについて、独自のトレーニングモジュールを提供しています。

セキュアなソフトウェア開発の現在のゴールドスタンダードであるDevSecOpsに向けて、共有責任としてのセキュリティが基本となりますが、企業は、ベンダーやコントラクターを含むすべての人がセキュリティを意識し、ベストプラクティスに従っていることを確認するために、時間、費用、労力を費やす必要があります。

セキュリティを意識した開発者は、コンプライアンスを意識した開発者である（そして、そこに到達することは退屈ではない

PCI-DSS に準拠した「認定」デベロッパーになることに関しては、明白な選択肢はそれほど多くありません。なぜでしょうか？それはおそらく、「1回で完了する」というわけにはいかないからでしょう。

OWASPは、一般的な脆弱性を阻止する方法を学ぶという点では、地球上で最も優れた組織の 1 つであり、そのトップ 10 は、開発者向けの PCI-DSS ガイドラインに正式に記載されています。しかし、セキュリティを常に念頭に置き、スキルを磨くには、時間と継続的な努力が必要です。しかし、セキュリティを意識してスキルを磨くには、時間と努力が必要です。

積極的なセキュリティ文化は、組織の中で「あればいい」というものではありません。セキュリティに真剣に取り組んでいるのであれば、それは会社の日常業務の一部である必要があります。

開発者は、脆弱性を阻止するための最前線にいます。開発者は、PCI-DSS に準拠するために必要なサポート、ツール、トレーニングを受けているでしょうか？

実際のところ、適切なトレーニングとは、よりシームレスなものであり、講義のように感じるべきではなく、日々行われている作業に大いに関連するものでなければなりません。そして、このような実践的なトレーニングは、スキルアップの機会であり、脆弱性を阻止し、チームの他のメンバーと協力してより高い水準のコードを作成することに真剣に取り組んでいる開発者にとっては、プラスにしかならないキャリアアップの機会なのです。

あなたのセキュアコーディングスキルを今すぐ試してみませんか？ ミッションを選択してください.

本章は、組織内での PCI-DSS コンプライアンスの成功をテーマとした 2 部構成のパート 1 です。この章では、AppSec スペシャリストが開発マネージャと密接に協力して、開発者に力を与え、SSDLC を強化し、一般的な法律から具体的な成果を得る方法について詳しく説明します。

コンプライアンス」という言葉は、あまり刺激的ではありません。フォーマルで、ドライで、指示的で......少し制限的なトーンでもあります。色で言えば、ベージュ色です。そして、クリエイティブな環境やイノベーションとは相反するもののように思われます。

私自身も開発者の一人ですが、「コンプライアンスを守る」という経験は、通常、（縦方向に）ガイドラインを読んだり、プレゼンテーションを見たりした後、機能のコーディングに戻り、お客様に使っていただけるソフトウェアを作ることに集中することを意味していました。しかし、コンプライアンスのガイドライン、特にセキュリティのベストプラクティスに関するガイドラインは、通常、開発者を対象にして書かれているわけではないので、必要な行動が不明確になることがあります。このようなシナリオでは、現在の目的に沿って仕事をすることがあまりにも簡単になってしまいます。

セキュアなソフトウェア開発は、もはやどの企業にとっても「あったらいいな」程度のものではなく、すべての組織で最重要課題となっています（あるいはそうあるべきです）。開発者は、コードに最初に触れる立場にあるため、他のチームと同様に、セキュリティ・コンプライアンス対策に関与する必要があります。

でも、ちょっと待って...聞いてください。これは、誰もが硬直した、創造性のない開発やソフトウェアの成果の奴隷にならなければならないということではありません。つまり、ビジネスは、より高い水準のコードを一緒に作る機会と力を持っているということです。これまでのところ、開発者がセキュリティを優先させるための適切なツールを自由に使えなかったという事実に、世界は少しずつ追いついてきています（サイロ化されたセキュリティの専門家が単独で責任を負うことはできません）。しかし、業界がDevSecOpsの未来に向けて、セキュリティを共通の責任として捉え、成功のための準備を整えれば、繰り返される脆弱性の流れを食い止めることができるでしょう。

PCI-DSS ガイドラインは、私たちの多くが日常的に利用しているカード決済ゲートウェイのオンラインセキュリティコンプライアンスについて規定しています。このガイドラインは世界的に適用されており、Eコマースビジネスの様々な側面でのコンプライアンス文書とともに、開発者がその義務に沿った基準を維持するために何をしなければならないかが詳細に説明されています。

Cyber Security Ventures社は、2021年にはゼロデイ侵害が1日1件になると予測しており、ソフトウェア・デリバリー・プロセスに携わるすべての人がこの問題に立ち向かうことができます。

ここでは、PCI-DSSの推奨事項と、それがチーム全体でどのように機能するかについて説明します。

こんにちは、AppSecとComplianceチームの皆さん。すべての開発者トレーニングは同じではない

大企業（あるいは中小企業）の開発者が、現場で受けるトレーニングについて意見を述べることはほとんどありません。スター社員を確保するために、包括的なプログラムを提供している企業もありますが、まだまだ一般的ではありません。セキュリティ・トレーニングの必要性は、皆を退屈させずに組織のコンプライアンスを開始するだけでなく、開発チームとの冷え切った関係を温めるための絶好の機会となる。

PCI コンプライアンスの観点から見ると、PCI のガイドラインには、ペイメントゲートウェイを実行するソ フトウェアに期待される成果が具体的に示されています。その他の目的として、アプリケーションのハー ド化（悪意のあるコードの注入や改ざんを阻止するために不可欠）、最小権限制御、および一般的な 脆弱性に対する十分な認識が、最低限必要とされています。カード会員データを扱うすべての担当者は、適切なトレーニングを受ける必要があります。また、開発者にとっては、プロセスの最初から安全なコードを書くことができるかどうかは、このトレーニングによって決まります。

公式のBest Practices for Maintaining PCI-DSS Complianceドキュメントでは、セキュリティ意識、開発者のニーズ、および適切なトレーニングに関する直接的なコンセプトが詳細に説明されています。

著作権 © 2006 - 2020 PCIセキュリティ基準協議会, LLC.すべての権利を保有しています。

これは、開発者に必要なスキルを身につけさせるために必要な、具体的で詳細なトレーニングにつ いての洞察を与えるものですが、特定の種類の教育ソリューションが他のものよりも効果的であると いうことを示すものではありません。開発者のための PCI-DSS ガイド』はもう少し直接的で、最も一般的な脆弱性の発見と修正を学ぶための 1 つのベンチマークとして OWASP トップ 10 を挙げており、またいくつかの認定プログラムも紹介しています。

しかし...ここで問題が発生します。様々な職場でのトレーニングやコンプライアンスの取り組みでご存知のように、それらは品質や将来の成功に大きな差があります。開発者に関して言えば、多くのセキュアコーディングトレーニングプログラムは、私たちのニーズや仕事のやり方、さらには私たちの日常の仕事には何の意味もないようです。このシナリオでは、すべてのトレーニングが同じように作られているわけではなく、すべてのトレーニングがより安全なソフトウェアを生み出すわけでもありません。これはもちろん、あなたが望む結果とは正反対であり、あなた自身の仕事のストレスが大幅に軽減されることはありません。負担を減らし、一般的な脆弱性が潜在的な災害を引き起こすのを阻止したいのであれば、橋を架ける必要があるでしょう。

エンジニア・マネージャーを味方につけて、セキュリティ・スキル・ギャップを埋める

エンジニアリングマネージャーと直接協力して、目的に合ったソリューションを見つけ、しかも実際にそれを実行しなければならない人々に受け入れられることは、セキュリティの成果を上げるための早道です。エンジニアリングマネージャーは、自分たちのチームについてより直接的な洞察を得ることができ、これまでコンプライアンストレーニングを困難にしていた障害について話すことができます（ほとんどの場合、素晴らしい体験ではないということ以外に）。

教室でのトレーニング、ビデオ・オン・デマンド、一回限りの演習では、最新の状態を維持することは非常に困難です。これらは静的なソリューションであり、変化し続けるサイバーセキュリティ業界の状況に対応することはできません。最終的には、エンジニアリングマネージャーは、時間を費やすことに見合う価値を求めています。そして、彼らと協力して、より安全でコンプライアンスに準拠したコードという、全員が共有する目標を達成するための実行可能なオプションを提供することが重要です。

では、良いトレーニングとはどのようなものでしょうか。セキュアなコーディング方法を、一度だけの大きな情報で学ぶことにはほとんど意味がありません。少しずつ学ぶことで、記憶に残りやすく、状況に応じて適用しやすくなります。また、日常的に使用する言語やフレームワークを使用する必要があります。個人的には、挑戦したいし、自分の努力に目的を見出したいと思っています - 私たちは今でも十分忙しいのですから。

上述した PCI-DSS のベストプラクティスに準拠するためには、選択したソリューションによっては、管理者は、ビジネスで使用されているすべての言語とフレームワークをカバーするために、さまざまなcourses をパッチワークのようにつなぎ合わせなければならないことに気づくかもしれません。これは、ソフトウェアのセキュリティと脆弱性の低減に影響を与えていると AppSec およびコンプライアンスチームが評価するのが難しいことは言うまでもありませんが、物事が非常に厄介になるときです。早く結果を出そうと間違った選択肢に飛びつくのではなく、協力して適切なものを見つけましょう。さもなければ、フランケンシュタインのようなトレーニングソリューションになってしまうかもしれません...それはとても恐ろしいことです。

この PCI-DSS ミニシリーズのパート 1 をご覧いただきありがとうございます。最終章では、CISO と CTO がどのようにしてこの文化の変革を支援し、チームを活性化させることができるか、また、セキュリティの最前線である開発者集団がどのようにして PCI-DSS の認識とコンプライアンスを活用できるかについて説明します。

技術そのものと同じように、コードを開発するためのツールやテクニック、最適なプロセスも急速に進化しています。私たち人間は、より多くのソフトウェア、より多くの機能、より多くの機能を求めてやみません。そして、かつてないほど速く、より質の高い、さらには安全なソフトウェアを求めています。ほんの数年前、アジャイル開発は、大きな仕事を小さなピースに分割し、お客様からの迅速なフィードバックサイクルに迅速に適応するために使用される次の大きなものでした。それ以前は、ウォーターフォール方式が主流でした。

多くの人や組織がウォーターフォールからアジャイルへと移行している一方で、 -- 現実的に考えて、まだ全員がそこに到達しているわけではありませんが -- すでに新たな問題に遭遇しています。開発チームとその運用担当者が依然としてサイロで作業しているのです。このような環境の中で、小規模なチームがアジャイルな方法で作業を行い、迅速なデプロイメントを実現するにはどうすればよいのでしょうか。

開発（Development）と運用（Operation）を組み合わせた造語であるDevOpsは、新しいソフトウェアを作成する際に、開発チームと運用チームの両方の機能を統合するために作られました。これは、新しいソフトウェアを開発する際に、開発チームと運用チームの機能を統合するために作られたもので、従来は運用チームに丸投げしていたものを、開発者が主体的に運用するためのものです。

確かに、1日に数回でも速く出荷することができるので、アジャイルの流れに沿っているように見えます。しかし、DevOpsではエンジニアと運用担当者が混ざった1つの大きなチームを作ることになり、実際にはアジャイルに沿ったものではないかもしれません。最終的には、DevOpsはアジャイルを進化させたものと考えるのがベストです。なぜなら、この2つの方法論は多くの点で似ており、違いを補い合っているからです。DevOpsでは、自動化された継続的なインテグレーションとデプロイメントのパイプラインを促進します。これは頻繁なリリースを可能にするために不可欠ですが、チームレベルでは十分ではありません。アジャイルは、チーム、特に小規模なチームが、このような迅速なリリースや変化する要件に対応しながら、タスクを遂行し、協力し合うことを可能にします。これは確かに理想的なことであり、このプロセスによってチームは最終目標に向かって進むことができますが、問題がないわけではありません。

DevOpsのベストプラクティスを用いて作成されたソフトウェアは、最初のボス戦であるセキュリティチームで躓く可能性があります。従来のウォーターフォール型のAppSecの専門家が、ツールや複雑な手作業によるレビューでコードを検査すると、受け入れがたいリスクや脆弱性が発見されることが多く、それらを事後的に修正しなければなりません。完成したアプリにセキュリティ修正を後付けするプロセスは、迅速でも簡単でもありません。そして、組織にとってははるかにコストがかかります。

では、ウォーターフォール、アジャイル、そして現在のDevOpsを経て、世界が動いているとしたら、その解決策は何でしょうか？また、開発者として、このようなアプローチの変化に対応するためにどのような役割を果たしているのでしょうか？

開発技術は常に進化し続けていますが、幸いなことに、今回はそれほど大きな変化ではありません。組織は、"DevOps "に "Sec "を加えればよいのです。そして、DevSecOpsが誕生しました。DevSecOpsの主な目的は、開発チーム、運用チーム、そして最後にセキュリティチームの間の障壁を取り払い、オープンなコラボレーションを実現することです。DevSecOpsは、ソフトウェアエンジニアリングの手法であると同時に、ソフトウェア開発ライフサイクル全体を通してセキュリティの自動化と監視を提唱する文化となっています。

これは、組織レベルの別のプロセスのように思われるかもしれませんし、構築すべき機能の長いリストを持っている開発者にとっては、「料理人が多すぎる」プロセスかもしれません。しかし、DevSecOpsの手法は、セキュリティを意識した開発者が真価を発揮する機会を与えてくれます。

DevSecOpsの明るい未来

では、なぜコーダーがDevSecOpsエンジニアになりたいのでしょうか？おそらくあなたは、DevOps（あるいはアジャイル）の経験はあるものの、次のステップとしてDevSecOpsに精通したいと考えているのではないでしょうか。まず最初に、それが非常に賢明な行動であることを知っておくといいでしょう。それは、コストのかかるサイバー攻撃から世界を安全にすることを目指しているからだけではありません。専門家によると、有能なサイバーセキュリティ人材の需要は、終わりが見えないほどに急増しているそうです。DevSecOpsをマスターした人は、長くて有益なキャリアが期待できます。

なぜなら、ソフトウェアベースのツールを使って脆弱性をスキャンするような従来のサイバーセキュリティ戦術とは異なり、DevSecOpsでは、コードを書くときにセキュリティを実装する方法を知っている人が必要だからです。Booz, Allen and Hamilton社のアナリストが「5 Myths of Adopting DevSecOps」と題したブログで指摘しているように、企業はDevSecOpsを必要としており、さらには必要としているが、単にそれを購入することはできない。DevSecOpsは、ソフトウェア開発ライフサイクル全体において、部門横断的なチームが技術を統合し、コラボレーションを行うための手法であり、熟練した人材、変更管理、複数の関係者による継続的なコミットメントが必要となる。

Booz, Allen and Hamilton社によると、企業はリリース管理ソフトウェアなど、DevSecOpsの特定の側面を支援するアプリケーションやツールを購入することができますが、「実際にそれを実現するのはデリバリーチームです」と述べています。彼らこそが、DevSecOpsが提供する継続的な改善と、その文化的・パラダイム的な変化を推進しているのです。

組織は、実行可能なDevSecOpsプログラムを「買う」ことはできません。さまざまなツール、社内の知識、セキュリティ文化を向上させるガイダンスを用いて、ビジネス上の意味も含めて構築し、維持しなければなりません。それは簡単なことではありませんが、不可能なことではありません。

DevSecOpsの活動に参加するにはどうすればよいか

DevSecOpsエンジニアになるための最初のステップは、DevSecOpsがテクニックの集合体であるのと同様に、文化であることを理解することです。自分が作成するコードの一部としてセキュリティを実装しようとする意志と、コード作成時にセキュリティ上の欠陥や脆弱性を積極的に探し、それらが本番環境に入る前に修正することで、組織を積極的に保護しようとする意欲が必要です。ほとんどのDevSecOpsエンジニアは、自分の職業とスキルセットを非常に真剣に考えています。DevSecOpsの専門組織は、自分たちの信念を記したマニフェストを持っています。

マニフェストは軽い読み物ではないので、このマニフェストは少々重苦しい。しかし、その核心には、すべての優れたDevSecOpsエンジニアが受け入れることを学ぶべき、いくつかの真実があります。

• アプリケーション・セキュリティ・チームはあなたの味方であることを認識してください。ほとんどの組織では、アプリケーション・セキュリティの専門家は開発者と対立しています。AppSecチームは開発者にもあまり好意的ではありません。というのも、彼らは一般的なセキュリティバグを引き起こすことで、完成したコードが本番稼動するのを遅らせてしまうからです。しかし、賢いDevSecOpsエンジニアは、セキュリティチームの目標が、最終的には開発者やコーダーと同じであることを理解しています。親友になる必要はありませんが、穏やかで協力的な仕事上の関係を築くことが成功には欠かせません。
• セキュアコーディング技術を実践し、磨きをかける。アプリがまだ作られていない段階で脆弱性を見つけることができれば、その抜け道を塞ぐことで将来のハッカーを阻止することができます。もちろん、そのためには、脆弱性への理解と、それを修正するためのツールが必要です。Secure Code Warrior のブログページでは、お客様が遭遇する最も一般的で危険な脆弱性についての洞察や、実践的なアドバイス、知識を試すための課題などを紹介しています。最も重要なことは、セキュリティを常に念頭に置き、既存の知識を基にした一口サイズのトレーニングを受ける時間を確保することです。開発者とセキュリティとの関わりは、目立たないものであったり、ネガティブなものであったりするのが一般的ですが、セキュリティのスキルアップは素晴らしいキャリアアップにつながりますし、面倒なものである必要はありません。
• 覚えておいてください。DevSecOpsのスーパースターは、自組織のポジティブなセキュリティ文化に貢献しています。アプリに問題があっても迅速に提供するといった過去の目標にこだわるのではなく、開発コードの脆弱性を発見して修正することを最優先することが重要です。セキュリティは全員の仕事であると考え、効果的で安全性の高いアプリケーションを毎回展開することで得られる称賛と報酬を全員で共有する必要があります。

セキュアコーディングとセキュリティのベストプラクティスを根底から支持し、トレーニングソリューションを推奨し、DevSecOpsの速いペースの世界でコーダーが取り残されないようにすることで、組織内の素晴らしいセキュリティ文化の醸成を支援することができます。良いコードとは安全なコードであり、熟練したセキュリティ意識の高い開発者はパズルの重要なピースです。個人的にも仕事上でも、努力する価値は十分にあります。毎年、何十億もの個人情報が漏洩しており、その数は増え続けているため、私たちはあなたを必要としています。最前線で活躍し、デジタル世界の悪者から身を守るために、あなたの力を貸してください。

Matias Madou, Ph.D. のCTO兼共同設立者。 Secure Code Warrior.セキュリティの専門家であり、長年の開発者であり、Fortniteジャンキーでもあります。

ゴキブリは核爆発でも生き延びることができる」という有名な説がある。しかし、ゴキブリの体は単純な構造をしているため、体の大きさの割には非常に丈夫で、ほとんどの条件で駆除することができません。

ずっと考えていたのですが、もしゴキブリに相当するものがデジタルの世界にあるとしたら、それはコード上のSQLインジェクション（SQLi）の脆弱性ではないでしょうか。これは20年以上前から知られている脆弱性ですが、企業は何度も何度も被害に遭っています。また、イリノイ州で発生した選挙ハッキング事件では、20万人分の有権者記録が流出し、FBIはすべてのIT管理者にセキュリティ対策の強化を急ぐよう勧告しました。

ImpervaのHacker Intelligence Initiative Reportによると、2005年から2011年の間に報告されたデータ侵害の83％にSQLi攻撃が使用されていたことが明らかになりました。OWASPのトップ10では、インジェクションの脆弱性が依然として第1位の脅威となっています。比較的単純な脆弱性であるにもかかわらず、死滅することはありません。

この同じ脆弱性が、いまだにかなりの数のアプリケーションのセキュリティスキャンに登場しているのは馬鹿げていると思います。私たちは、この脆弱性がどのように動作するかを知っていますし、それを阻止する方法も知っています。どうしてこんなことが可能なのでしょうか？実は、私たちのソフトウェア・セキュリティには、まだまだ改善の余地があるのです。

Veracode社の「State of Software Security Report」は、2017年に行われた40万件のアプリケーションスキャンに基づいていますが、OWASPトップ10ポリシーに合格したアプリケーションはわずか30％という驚くべき統計が明らかになりました。これは、過去5年間の一貫したテーマであり、新たにスキャンされたアプリケーションのほぼ3分の1にSQLインジェクションが出現しています。また、CISOは、十分なセキュリティ人材を確保することができず、苦しい戦いを強いられているようです。一般的に、アプリケーションセキュリティのスペシャリストと開発者の比率は、1:100という不十分なものです。

なぜソフトウェア・セキュリティは生命維持装置のようなものなのか？

セキュリティに精通した人材が不足していることは周知の事実ですが、開発者が問題が発生したときにそれを修正していないことや、そもそも脆弱性を発生させないための能力が明らかに不足していることにも注意を払う必要があります。同じVeracode社のレポートによると、開発者が抱える脆弱性のうち、文書化された緩和策が存在するのは14.4%に過ぎませんでした。言い換えれば、ほとんどの脆弱性は開発時に緩和策が講じられずに提出されたということです。脆弱性のうち、最初の90日間でクローズされたものは3分の1以下であり、42％の脆弱性は開発期間中にクローズされなかった。

私はセキュリティの専門家、CISO、CEOと常に話をしていますが、多くの企業が、発見された脆弱性のうち緩和できないものが多いことに苛立ちを感じ、脆弱性のスキャンを完全にやめて、指をくわえて最善の結果を期待しているという逸話を耳にしました。

なぜAppSecの専門家はこのような事態を招いてしまうのでしょうか？

間違いではありません。AppSec担当者は、コード上の問題を痛感しています。結局のところ、それが彼らのコアスキルの1つであり、チームの貴重なリソースとなっているのです。しかし、彼らはしばしばいくつかの要因に阻まれています。

例えば、AppSecマネージャが問題を発見し、開発者に「コードを修正できますか？この重要な質問に対する答えは、組織によって異なりますが、一般的には、開発者は、厳しい機能提供スプリントに対応するために、単にこれらの問題を修正する時間がなく、それを支援する適切なツールもありません。AppSecの専門家は、脆弱性を特定することはできるかもしれませんが、その場で修正するためのスキルやアクセス権を持っていないことが多いのです。

また、すべての問題には、解決策を見つけ、それを実装し、テストするというプロセスが必要であることを認識しなければなりません。コードにわずかな問題が見つかっただけでも、必要なリソースはもちろんのこと、修正にかかる時間も膨大なものになります。ソフトウェアに混入する可能性のある脆弱性は700以上あり、そのすべてを一人の人間が防御することは不可能だと言われています。そのため、多くの企業はOWASPトップ10のみを遵守しています。その間、開発者は機能を作り続け、その結果、自分が書いたコードに脆弱性を導入し続けます。

解決策は何ですか？

単純な事実として、私たちは開発者に対して、安全なコーディングを成功させるためのツールやトレーニングを提供していません。組織が開発者に適切なセキュリティ・スキルを持たせることを強制するような規制はなく、ほとんどの大学やインターンシップでは、若手開発者が安全なコーディングをするための準備ができていないという悲しい現実があります。

飛行機を飛ばそうと思ったら、訓練、実務経験、メディカルチェック、安全知識、試験など、非常に厳格なプロセスを経て飛行できるようになります。このような準備とスキルの検証を経ずに空に放たれるとは、誰も想像できないでしょう。しかし、コードライティングでは、このようなことが日常的に行われているのです。  

私たちは、安全なコードを書くために、開発者の教育に時間を費やす必要があります。しかし、ソフトウェア開発のペースが速く、優秀な開発者やセキュリティの専門家が不足している今日の世界では、その優先順位は決して高くないようです。今こそ、私たちはこの問題に取り組むべきです。

世界経済フォーラムが最近発表した見出しには、こう書かれていました。"セキュリティなくしてデジタル経済はありえない」と叫んでいますが、それに付随するコンテンツでは、デジタルトランスフォーメーション戦略の中核にセキュリティを据えることの必要性が説かれています。"セキュリティは企業を守るものであり、企業がイノベーションを起こし、新しい製品やサービスを構築することを可能にします。防御の役割を超えて、セキュリティは企業に戦略的な成長の優位性をもたらします」と述べています。

セキュアコーディングのスキルと成果を向上させることで、組織に強力なサイバープロテクションのレイヤーを追加し、より良い、より速いコードの作成を支援します。開発者は、セキュリティの専門家になる必要はありませんが、サイバー攻撃に対する最初の防衛線となるよう、積極的かつ実践的な権限を与えられる必要があります。開発者は、次のセキュリティとイノベーションのヒーローになる可能性があります。彼らは非常に賢く、創造的な問題解決者であり、一般的に自分のスキルを高めることに熱心です。彼らの強みを活かし、彼らにふさわしい専門的なトレーニングを行い、より高いソフトウェア・セキュリティ基準を約束してください。詳しくは、ホワイトペーパーをご覧ください。

飛行機を飛ばそうと思ったら、訓練、実務経験、メディカルチェック、安全知識、試験など、非常に厳格なプロセスを経て飛行できるようになります。このような準備とスキルの検証を経ずに空に放たれるとは、誰も想像できないでしょう。しかし、コードライティングでは、このようなことが日常的に行われているのです。