This issue is sponsored by Invary. Check out Invary's ability to detect hidden rootkits, a task that modern threat detection solutions fail in action » HERE.
This week TLDR i.e. 2 minutes version (For executives):
AWS Wickr is now FedRAMP Moderate authorized.
AMI Block Public Access now enabled for all new accounts & existing accounts with no public AMIs.
Amazon EC2 now supports setting AMIs to a disabled state.
Trending in Cloud & Cyber Security (News, Blogs, Tweets etc):
AWS Security Blogs (& Bulletins):
CISA, NSA, FBI, MS-ISAC Publish Guide on Preventing Phishing Intrusions. Link.
Passkeys are now enabled by default for Google users. Link.
WhatsApp introduced the ability to have two WhatsApp accounts logged in at the same time. Link.
Okta acknowledged adversarial activity that leveraged access to a stolen credential to access Okta's support case management system. Link.
This week Long i.e. 5-10 minutes version (For architects & engineers):
AWS Wickr has successfully obtained FedRAMP Moderate authorization, granting you the ability to utilize Wickr for safeguarding communications that must comply with FedRAMP Moderate standards. Wickr is a secure messaging and collaboration service that employs end-to-end encryption to ensure the privacy, security, and compliance of your communications. Wickr safeguards one-on-one and group messaging, voice and video calls, file sharing, screen sharing, and location sharing through 256-bit encryption. Each message, call, and file is encrypted on the sender's device using a unique secret key, remaining secure during transit. Only intended recipients and your organization have access to the content. Administrators can establish Wickr networks via the AWS Management Console, granting you full control over your data. This control encompasses the management of information governance policies, the configuration of ephemeral messaging settings, and the deletion of credentials for lost or stolen devices. Additionally, you can log both internal and external conversations within a Wickr network to a private data repository under your management, ensuring compliance with data retention and auditing requirements. Wickr is accessible under FedRAMP Moderate authorization within the AWS US East (Northern Virginia) Region. Link.
Amazon EC2 has now set the Amazon Machine Image Block Public Access (AMI BPA) feature to be active by default for all new AWS accounts. Moreover, this setting has been enabled for existing AWS accounts that have not possessed a public AMI since July 15, 2023. AMI BPA acts as a safeguard, preventing an AWS account from inadvertently sharing an AMI publicly within a specific AWS Region. This enhancement significantly bolsters security and privacy for AWS customers. Previously, AMI BPA was not enabled by default for any AWS accounts. However, in this update, it will automatically be turned on for all newly created AWS accounts. In addition, AMI BPA will also be activated for those existing AWS accounts that have not owned a public AMI since July 15, 2023. Should there be a need to make an AMI public, you can choose to deactivate AMI BPA using the AWS CLI, SDKs, or Console. It's important to note that this change will have no impact on existing AWS accounts that already possess public AMIs. Link. I checked a random AWS Account/region where I had never enabled the flag and now it’s enabled by default.
AWS users now have the ability to deactivate their unused or outdated Amazon Machine Images. Disabling an AMI alters its status to "disabled," shifts it to private if it was previously shared, and prohibits the creation of new EC2 instances from that disabled AMI. This new capability allows customers who deal with AMIs on a large scale to simplify and streamline their workflows. Before this update, customers faced the challenge of removing unused and outdated AMIs by de-registering them. This was not always feasible due to various factors such as regulatory compliance, IT governance, or internal policies. Consequently, the number of active AMIs grew, causing increased management complexity, affecting discoverability, and potentially introducing risks to the security and integrity of newly launched instances. With the introduction of the ability to disable an AMI, customers can now keep their old and obsolete AMIs while preventing the launch of new instances from potentially vulnerable or non-compliant AMIs. Disabled AMIs are not visible by default when using the DescribeImages API call, making it easier to find AMIs by decluttering the AMI catalog. If an AMI is accidentally disabled or if a previously disabled AMI is needed to launch new instances, customers can easily re-enable it with a straightforward API call. Link.
Thank You for reading! If you enjoyed this newsletter, I’d be grateful if you could forward it to your professional circle.
Best,
AJ