Three steps to boost Amazon S3 data security

The amount of data in modern systems has skyrocketed beyond what traditional security tools can handle. As organizations embrace AI to boost productivity, security teams face mounting pressure to protect sensitive information across sprawling cloud infrastructures and applications. The velocity of data creation, combined with complex multicloud environments, makes traditional security approaches insufficient. AI systems introduce additional complexity—they require broad data access to function effectively, yet this same access creates new attack vectors. Security teams must now secure not just the data itself, but also how AI systems interact with and process that data.

The Codefinger attack from earlier this year demonstrates this risk. This ransomware attack targeted users of Amazon S3 buckets, encrypting files using AWS’s own server-side encryption capabilities. The attackers exploited AWS’s built-in features, demanding payment in exchange for decryption keys. This attack highlighted a critical weakness – attackers weaponizing cloud platforms’ native security features against their users.

The significance of the Codefinger attack extends beyond its technical sophistication. By leveraging victims’ own infrastructure, attackers can execute breaches more efficiently and at lower cost, suggesting similar attacks will become more frequent.

What steps can organizations take to protect themselves? Data security and governance require precise visibility and control. Organizations need to know what sensitive data they possess and strictly manage how it can be accessed. In the case of Codefinger, companies can execute the following three technical steps immediately.

Audit identities with SSE-C privileges

The first step is to audit identities (human and non-human) that can use SSE-C, and compare that list to a master list of authorized users to SSE-C. Start by removing highly privileged identities that have been inactive for over thirty days. Eliminate unnecessary SSE-C privileges from identities that don’t require them. The key permissions required for ransom via SSE-C are s3:GetObject and s3:PutObject. After cleaning up these permissions, segregate those left with SSE-C privileges and make sure they do not have access to disable object versioning, destroy backups, destroy existing logs, or disable logging. Monitor for the following permissions being co-mingled with SSE-C permissions:

Deletion of logs

s3:DeleteBucket – Allows deletion of log containing bucket

s3:DeleteObject – Allows deletion of specific objects in a bucket

Deletion of backups

s3:DeleteObjectVersion – Allows deletion of specific versions of objects

backup:DeleteRecoveryPoint – Allows deletion of AWS Backup S3 recovery points

Object versioning

s3:PutBucketVersioning – Allows enabling or suspending versioning

Logging and audit configuration

s3:PutBucketLogging – Allows enabling, disabling, or altering bucket logging configurations

s3:GetBucketLogging – Provides visibility into the current logging configuration

s3:PutBucketPolicy – Allows modification of bucket policies, which could disable logging indirectly or prevent access logging from being written

s3:PutBucketAcl – Allows modification of bucket access control lists (ACLs), potentially disrupting access logging

This audit of inactive or unauthorized users that already have access to your data first and delegating specific permissions to the identities left is a vital part of this threat mitigation process. By this point, you should be able to see all authorized permissions that are provided to both human and non-human identities clearly before moving forward with any other steps.

Log data events in Amazon S3

The second step is to log data events in S3, using either CloudTrail Data Events or S3 Server Access Logs. AWS omits S3 GETs and PUTs by default, limiting attack investigation capabilities. A way around this is to enable data event logging in S3 through CloudTrail Data Events or S3 Serve Access Logs.

CloudTrail Data Events offer greater detail than S3 Serve Access Logs. However, they are billed per data event volume, so costs can rise quickly for buckets with high change rates. S3 Server Access Logs are not billed for log generation, but only for storage.

Whichever log destination bucket you choose, make sure it is in a secure location and that you are enacting object versioning to make it easier to recover files from the last known good state.

Take a risk-based approach to data security

Last, and most critically, organizations need to discover and classify every piece of data in order to understand which assets are to be acted on and when. Taking a comprehensive scan and ensuring accurate classification of your structured, semi-structured, and unstructured data can help identify risk that is imminent versus risk that can be de-prioritized. Beyond ransomware protection, identity management and data exposure controls are equally important for responsible AI deployment. Organizations rapidly adopting generative AI often overlook the scope of access these systems have to sensitive data. Ensuring that AI systems can only reason over authorized and properly secured versions of corporate data is paramount, especially as the regulatory landscape continues to evolve. This comprehensive approach to data security addresses both traditional threats and emerging AI-related risks.

Unprecedented threats require new security standards and controls

The security community faces unprecedented threats requiring coordinated action between private industry and government agencies. Recent attacks highlight severe gaps in data protection standards, especially around AI systems. AI accelerates business operations but introduces new risks. Sensitive data can leak into AI models during training and out of sensitive models during inference; once a model is trained, governing its outputs is non deterministic. These AI security challenges directly relate to the identity and data controls discussed above. Without sufficient access management and data classification, organizations cannot prevent unauthorized data from entering AI training pipelines and being exposed through inference.

The current changing regulatory environment adds complexity. Recent changes to cybersecurity executive orders have disrupted established collaboration frameworks between government and industry. This policy shift impacts how organizations develop secure AI systems and address vulnerabilities in our national security infrastructure. One thing is certain: The threats we face—from nation-state actors to increasingly sophisticated cybercriminal groups—won’t wait for political consensus. Just as with ransomware protection, organizations must take proactive steps to secure their AI systems regardless of regulatory uncertainty.

Forward-thinking enterprises and technology providers must act now to strengthen their security controls. Building protection mechanisms after AI systems are deployed costs significantly more and will leave organizations exposed. The same methodical approach to identity governance and data classification that protects against threats like Codefinger provides the foundation for secure AI implementation. The security measures implemented today will determine how well organizations can defend against tomorrow’s threats.

Pranava Adduri is CTO of Bedrock Security.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.