Programmierer erobern Sicherheitsinfrastruktur als Code-Serie: Deaktivierte Sicherheitsfunktionen
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
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 and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
Angreifer versuchen immer zuerst, leicht ausnutzbare Sicherheitslücken zu finden, und können sogar ein Skript verwenden, um häufig auftretende Schwachstellen ausfindig zu machen. Es ist nicht unähnlich wie ein Dieb, der alle Autos auf einer Straße überprüft, um zu sehen, ob irgendwelche Türen unverschlossen sind, was viel einfacher ist, als ein Fenster einzuschlagen.
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
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 and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
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 and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
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 and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
Inhaltsverzeichniss
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
The Power of OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
.png)
