
コーダーがセキュリティインフラを征服するコードシリーズ:安全でない暗号
Shrewd organizations are embracing the concept of infrastructure as code, and it is developers like you who can make significant contributions in crafting secure code, even outside of building an application. It may seem to a long road to travel at first, but the journey is worth it to stand out among your peers.
Before we get started on this next chapter of our latest Coders Conquer Security series, I'd like to invite you to play a gamified challenge of the sensitive data storage vulnerability; play now and choose from Kubernetes, Terraform, Ansible, Docker, or CloudFormation:
How was that? If your knowledge needs some work, read on:
These days, having critical data like passwords, personal information and financial records hashed while at rest is a cornerstone of any cybersecurity defense. In a lot of ways, it acts as both a last line of defense and also one of the best kinds of protection. That's because even if an attacker is able to break through other defenses and obtain critical files, as long as they are properly hashed and stored, that won't do them very much good.
This also acts as solid secondary protection against malicious insiders because encrypted files can have separate keys or passwords from the rest of the network. In that case, someone like a system administrator or a hacker who has compromised an administrator's credentials might be able to browse into a protected directory, but still not be able to unlock the encrypted files they find there if the encryption key is held elsewhere.
Of course, all encryption protection methods rely on having strong encryption standards that can't be broken by even the most powerful computers.
Why is insecure cryptography dangerous?
When it comes to computer technology, being able to create strong encryption algorithms and the ability to break them have been in competition for a long time. Back in 1977, the federal government in the United States developed the Data Encryption Standard (DES), a 56-bit algorithm which was considered secure at the time given the relative power of computers.
But computers evolved, and people found ways to network them together collaboratively to increase their power even further. In 1999, the Electronic Frontier Foundation along with Distributed.net worked together to publicly break the encryption on a DES-protected document in just 22 hours. Suddenly, any document protected by DES encryption was no longer safe.
Believe it or not, some organizations still protect their critical files with the DES algorithm or with similarly weak encryption protection. And while it took a distributed network to break 56-bit encryption in 1999, today almost any sufficiently powerful standalone computer can do it given a modicum of time. Hackers also have created dedicated cracking machines built from banks of graphics processor units (GPUs). Those GPUs are exceptionally good at that task, are relatively inexpensive to obtain and to network locally.
If you choose to protect your critical files with an insecure or weak cryptographic algorithm today, then it won't take long before most hackers can break down those files and make them readable. If you suffer from a data breach, then you have to assume that the files will eventually be compromised if they were not sufficiently protected.
For example, the following Kubernetes code snippet is using a weak cipher algorithm to protect the information at NGINX ingress controller level:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: DES-CBC3-SHA
ssl-protocols: "TLSv1.2"
In that example, the DES cipher suite has been used to protect the information. However, an attacker could easily decipher it and access sensitive information.
It's recommended to use strong cipher algorithms. In the following Kubernetes example, strong cipher suites have been used to protect the information at NGINX ingress controller level:
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"
In that example, a strong suite of ciphers has been used in order to avoid attackers gaining potential access to sensitive information.
Protecting critical information with strong encryption
Strong encryption is available today that is nearly unbreakable. In 2001, the National Institute of Standards and Technology (NIST) created a new encryption technology to replace DES. Called the Advanced Encryption Standard (AES), it uses three different key lengths, either 128, 192, or 256 bits. The 256 bit AES encryption is the most secure, though all three are considered almost completely unbreakable given today's technology. Tests with supercomputers have found that it would take thousands of years of constant work to break most AES protected documents.
To properly protect critical files, developers should first identify them. There is no need to encrypt everything on a network, as that might slow operations with the constant encrypting and decrypting process. But critical files like personnel records, customer data, and financial information need adequate protection. Essentially, it's a balancing act between security and having a workable system.
And that data should be encrypted to one of the AES standards, even going as far as 256-bit encryption for truly critical information that shouldn't ever land in the wrong hands.
One other thing to consider is the fact that adding encryption is like adding more passwords to a site. That means that authorized users will need to keep track of the encryption keys. To prevent this from becoming a workflow bottleneck, consider implementing a key management platform to keep track of those keys and to keep them safe. And even if you don't end up using centralized key management, be sure that all keys and passwords are protected to ensure that unauthorized users are kept out of your most secure data vaults.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws. You can also try a demo of an IaC challenge within the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。

Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Matiasは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れているときには、マティアスは上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。


Shrewd organizations are embracing the concept of infrastructure as code, and it is developers like you who can make significant contributions in crafting secure code, even outside of building an application. It may seem to a long road to travel at first, but the journey is worth it to stand out among your peers.
Before we get started on this next chapter of our latest Coders Conquer Security series, I'd like to invite you to play a gamified challenge of the sensitive data storage vulnerability; play now and choose from Kubernetes, Terraform, Ansible, Docker, or CloudFormation:
How was that? If your knowledge needs some work, read on:
These days, having critical data like passwords, personal information and financial records hashed while at rest is a cornerstone of any cybersecurity defense. In a lot of ways, it acts as both a last line of defense and also one of the best kinds of protection. That's because even if an attacker is able to break through other defenses and obtain critical files, as long as they are properly hashed and stored, that won't do them very much good.
This also acts as solid secondary protection against malicious insiders because encrypted files can have separate keys or passwords from the rest of the network. In that case, someone like a system administrator or a hacker who has compromised an administrator's credentials might be able to browse into a protected directory, but still not be able to unlock the encrypted files they find there if the encryption key is held elsewhere.
Of course, all encryption protection methods rely on having strong encryption standards that can't be broken by even the most powerful computers.
Why is insecure cryptography dangerous?
When it comes to computer technology, being able to create strong encryption algorithms and the ability to break them have been in competition for a long time. Back in 1977, the federal government in the United States developed the Data Encryption Standard (DES), a 56-bit algorithm which was considered secure at the time given the relative power of computers.
But computers evolved, and people found ways to network them together collaboratively to increase their power even further. In 1999, the Electronic Frontier Foundation along with Distributed.net worked together to publicly break the encryption on a DES-protected document in just 22 hours. Suddenly, any document protected by DES encryption was no longer safe.
Believe it or not, some organizations still protect their critical files with the DES algorithm or with similarly weak encryption protection. And while it took a distributed network to break 56-bit encryption in 1999, today almost any sufficiently powerful standalone computer can do it given a modicum of time. Hackers also have created dedicated cracking machines built from banks of graphics processor units (GPUs). Those GPUs are exceptionally good at that task, are relatively inexpensive to obtain and to network locally.
If you choose to protect your critical files with an insecure or weak cryptographic algorithm today, then it won't take long before most hackers can break down those files and make them readable. If you suffer from a data breach, then you have to assume that the files will eventually be compromised if they were not sufficiently protected.
For example, the following Kubernetes code snippet is using a weak cipher algorithm to protect the information at NGINX ingress controller level:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: DES-CBC3-SHA
ssl-protocols: "TLSv1.2"
In that example, the DES cipher suite has been used to protect the information. However, an attacker could easily decipher it and access sensitive information.
It's recommended to use strong cipher algorithms. In the following Kubernetes example, strong cipher suites have been used to protect the information at NGINX ingress controller level:
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"
In that example, a strong suite of ciphers has been used in order to avoid attackers gaining potential access to sensitive information.
Protecting critical information with strong encryption
Strong encryption is available today that is nearly unbreakable. In 2001, the National Institute of Standards and Technology (NIST) created a new encryption technology to replace DES. Called the Advanced Encryption Standard (AES), it uses three different key lengths, either 128, 192, or 256 bits. The 256 bit AES encryption is the most secure, though all three are considered almost completely unbreakable given today's technology. Tests with supercomputers have found that it would take thousands of years of constant work to break most AES protected documents.
To properly protect critical files, developers should first identify them. There is no need to encrypt everything on a network, as that might slow operations with the constant encrypting and decrypting process. But critical files like personnel records, customer data, and financial information need adequate protection. Essentially, it's a balancing act between security and having a workable system.
And that data should be encrypted to one of the AES standards, even going as far as 256-bit encryption for truly critical information that shouldn't ever land in the wrong hands.
One other thing to consider is the fact that adding encryption is like adding more passwords to a site. That means that authorized users will need to keep track of the encryption keys. To prevent this from becoming a workflow bottleneck, consider implementing a key management platform to keep track of those keys and to keep them safe. And even if you don't end up using centralized key management, be sure that all keys and passwords are protected to ensure that unauthorized users are kept out of your most secure data vaults.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws. You can also try a demo of an IaC challenge within the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

Shrewd organizations are embracing the concept of infrastructure as code, and it is developers like you who can make significant contributions in crafting secure code, even outside of building an application. It may seem to a long road to travel at first, but the journey is worth it to stand out among your peers.
Before we get started on this next chapter of our latest Coders Conquer Security series, I'd like to invite you to play a gamified challenge of the sensitive data storage vulnerability; play now and choose from Kubernetes, Terraform, Ansible, Docker, or CloudFormation:
How was that? If your knowledge needs some work, read on:
These days, having critical data like passwords, personal information and financial records hashed while at rest is a cornerstone of any cybersecurity defense. In a lot of ways, it acts as both a last line of defense and also one of the best kinds of protection. That's because even if an attacker is able to break through other defenses and obtain critical files, as long as they are properly hashed and stored, that won't do them very much good.
This also acts as solid secondary protection against malicious insiders because encrypted files can have separate keys or passwords from the rest of the network. In that case, someone like a system administrator or a hacker who has compromised an administrator's credentials might be able to browse into a protected directory, but still not be able to unlock the encrypted files they find there if the encryption key is held elsewhere.
Of course, all encryption protection methods rely on having strong encryption standards that can't be broken by even the most powerful computers.
Why is insecure cryptography dangerous?
When it comes to computer technology, being able to create strong encryption algorithms and the ability to break them have been in competition for a long time. Back in 1977, the federal government in the United States developed the Data Encryption Standard (DES), a 56-bit algorithm which was considered secure at the time given the relative power of computers.
But computers evolved, and people found ways to network them together collaboratively to increase their power even further. In 1999, the Electronic Frontier Foundation along with Distributed.net worked together to publicly break the encryption on a DES-protected document in just 22 hours. Suddenly, any document protected by DES encryption was no longer safe.
Believe it or not, some organizations still protect their critical files with the DES algorithm or with similarly weak encryption protection. And while it took a distributed network to break 56-bit encryption in 1999, today almost any sufficiently powerful standalone computer can do it given a modicum of time. Hackers also have created dedicated cracking machines built from banks of graphics processor units (GPUs). Those GPUs are exceptionally good at that task, are relatively inexpensive to obtain and to network locally.
If you choose to protect your critical files with an insecure or weak cryptographic algorithm today, then it won't take long before most hackers can break down those files and make them readable. If you suffer from a data breach, then you have to assume that the files will eventually be compromised if they were not sufficiently protected.
For example, the following Kubernetes code snippet is using a weak cipher algorithm to protect the information at NGINX ingress controller level:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: DES-CBC3-SHA
ssl-protocols: "TLSv1.2"
In that example, the DES cipher suite has been used to protect the information. However, an attacker could easily decipher it and access sensitive information.
It's recommended to use strong cipher algorithms. In the following Kubernetes example, strong cipher suites have been used to protect the information at NGINX ingress controller level:
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"
In that example, a strong suite of ciphers has been used in order to avoid attackers gaining potential access to sensitive information.
Protecting critical information with strong encryption
Strong encryption is available today that is nearly unbreakable. In 2001, the National Institute of Standards and Technology (NIST) created a new encryption technology to replace DES. Called the Advanced Encryption Standard (AES), it uses three different key lengths, either 128, 192, or 256 bits. The 256 bit AES encryption is the most secure, though all three are considered almost completely unbreakable given today's technology. Tests with supercomputers have found that it would take thousands of years of constant work to break most AES protected documents.
To properly protect critical files, developers should first identify them. There is no need to encrypt everything on a network, as that might slow operations with the constant encrypting and decrypting process. But critical files like personnel records, customer data, and financial information need adequate protection. Essentially, it's a balancing act between security and having a workable system.
And that data should be encrypted to one of the AES standards, even going as far as 256-bit encryption for truly critical information that shouldn't ever land in the wrong hands.
One other thing to consider is the fact that adding encryption is like adding more passwords to a site. That means that authorized users will need to keep track of the encryption keys. To prevent this from becoming a workflow bottleneck, consider implementing a key management platform to keep track of those keys and to keep them safe. And even if you don't end up using centralized key management, be sure that all keys and passwords are protected to ensure that unauthorized users are kept out of your most secure data vaults.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws. You can also try a demo of an IaC challenge within the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Matiasは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れているときには、マティアスは上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
Shrewd organizations are embracing the concept of infrastructure as code, and it is developers like you who can make significant contributions in crafting secure code, even outside of building an application. It may seem to a long road to travel at first, but the journey is worth it to stand out among your peers.
Before we get started on this next chapter of our latest Coders Conquer Security series, I'd like to invite you to play a gamified challenge of the sensitive data storage vulnerability; play now and choose from Kubernetes, Terraform, Ansible, Docker, or CloudFormation:
How was that? If your knowledge needs some work, read on:
These days, having critical data like passwords, personal information and financial records hashed while at rest is a cornerstone of any cybersecurity defense. In a lot of ways, it acts as both a last line of defense and also one of the best kinds of protection. That's because even if an attacker is able to break through other defenses and obtain critical files, as long as they are properly hashed and stored, that won't do them very much good.
This also acts as solid secondary protection against malicious insiders because encrypted files can have separate keys or passwords from the rest of the network. In that case, someone like a system administrator or a hacker who has compromised an administrator's credentials might be able to browse into a protected directory, but still not be able to unlock the encrypted files they find there if the encryption key is held elsewhere.
Of course, all encryption protection methods rely on having strong encryption standards that can't be broken by even the most powerful computers.
Why is insecure cryptography dangerous?
When it comes to computer technology, being able to create strong encryption algorithms and the ability to break them have been in competition for a long time. Back in 1977, the federal government in the United States developed the Data Encryption Standard (DES), a 56-bit algorithm which was considered secure at the time given the relative power of computers.
But computers evolved, and people found ways to network them together collaboratively to increase their power even further. In 1999, the Electronic Frontier Foundation along with Distributed.net worked together to publicly break the encryption on a DES-protected document in just 22 hours. Suddenly, any document protected by DES encryption was no longer safe.
Believe it or not, some organizations still protect their critical files with the DES algorithm or with similarly weak encryption protection. And while it took a distributed network to break 56-bit encryption in 1999, today almost any sufficiently powerful standalone computer can do it given a modicum of time. Hackers also have created dedicated cracking machines built from banks of graphics processor units (GPUs). Those GPUs are exceptionally good at that task, are relatively inexpensive to obtain and to network locally.
If you choose to protect your critical files with an insecure or weak cryptographic algorithm today, then it won't take long before most hackers can break down those files and make them readable. If you suffer from a data breach, then you have to assume that the files will eventually be compromised if they were not sufficiently protected.
For example, the following Kubernetes code snippet is using a weak cipher algorithm to protect the information at NGINX ingress controller level:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: DES-CBC3-SHA
ssl-protocols: "TLSv1.2"
In that example, the DES cipher suite has been used to protect the information. However, an attacker could easily decipher it and access sensitive information.
It's recommended to use strong cipher algorithms. In the following Kubernetes example, strong cipher suites have been used to protect the information at NGINX ingress controller level:
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"
In that example, a strong suite of ciphers has been used in order to avoid attackers gaining potential access to sensitive information.
Protecting critical information with strong encryption
Strong encryption is available today that is nearly unbreakable. In 2001, the National Institute of Standards and Technology (NIST) created a new encryption technology to replace DES. Called the Advanced Encryption Standard (AES), it uses three different key lengths, either 128, 192, or 256 bits. The 256 bit AES encryption is the most secure, though all three are considered almost completely unbreakable given today's technology. Tests with supercomputers have found that it would take thousands of years of constant work to break most AES protected documents.
To properly protect critical files, developers should first identify them. There is no need to encrypt everything on a network, as that might slow operations with the constant encrypting and decrypting process. But critical files like personnel records, customer data, and financial information need adequate protection. Essentially, it's a balancing act between security and having a workable system.
And that data should be encrypted to one of the AES standards, even going as far as 256-bit encryption for truly critical information that shouldn't ever land in the wrong hands.
One other thing to consider is the fact that adding encryption is like adding more passwords to a site. That means that authorized users will need to keep track of the encryption keys. To prevent this from becoming a workflow bottleneck, consider implementing a key management platform to keep track of those keys and to keep them safe. And even if you don't end up using centralized key management, be sure that all keys and passwords are protected to ensure that unauthorized users are kept out of your most secure data vaults.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws. You can also try a demo of an IaC challenge within the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
目次
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。

Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約[ダウンロード]始めるためのリソース
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.




%20(1).avif)
.avif)
