A Single Cloud Compromise Can Feed an Army of AI Sex Bots

Organizations that get relieved of credentials to their cloud environments can quickly find themselves part of a disturbing new trend: Cybercriminals using stolen cloud credentials to operate and resell sexualized AI-powered chat services. Researchers say these illicit chat bots, which use custom jailbreaks to bypass content filtering, often veer into darker role-playing scenarios, including child sexual exploitation and rape.

Image: Shutterstock.

Researchers at security firm Permiso Security say attacks against generative artificial intelligence (AI) infrastructure like Bedrock from Amazon Web Services (AWS) have increased markedly over the last six months, particularly when someone in the organization accidentally exposes their cloud credentials or key online, such as in a code repository like GitHub.

Investigating the abuse of AWS accounts for several organizations, Permiso found attackers had seized on stolen AWS credentials to interact with the large language models (LLMs) available on Bedrock. But they also soon discovered none of these AWS users had enabled full logging of LLM activity (by default, logs don’t include model prompts and outputs), and thus they lacked any visibility into what attackers were doing with that access.

So Permiso researchers decided to leak their own test AWS key on GitHub, while turning on logging so that they could see exactly what an attacker might ask for, and what the responses might be.

Within minutes, their bait key was scooped up and used in a service that offers AI-powered sex chats online.

“After reviewing the prompts and responses it became clear that the attacker was hosting an AI roleplaying service that leverages common jailbreak techniques to get the models to accept and respond with content that would normally be blocked,” Permiso researchers wrote in a report released today.

“Almost all of the roleplaying was of a sexual nature, with some of the content straying into darker topics such as child sexual abuse,” they continued. “Over the course of two days we saw over 75,000 successful model invocations, almost all of a sexual nature.”

Ian Ahl, senior vice president of threat research at Permiso, said attackers in possession of a working cloud account traditionally have used that access for run-of-the-mill financial cybercrime, such as cryptocurrency mining or spam. But over the past six months, Ahl said, Bedrock has emerged as one of the top targeted cloud services.

“Bad guy hosts a chat service, and subscribers pay them money,” Ahl said of the business model for commandeering Bedrock access to power sex chat bots. “They don’t want to pay for all the prompting that their subscribers are doing, so instead they hijack someone else’s infrastructure.”

Ahl said much of the AI-powered chat conversations initiated by the users of their honeypot AWS key were harmless roleplaying of sexual behavior.

“But a percentage of it is also geared toward very illegal stuff, like child sexual assault fantasies and rapes being played out,” Ahl said. “And these are typically things the large language models won’t be able to talk about.”

AWS’s Bedrock uses large language models from Anthropic, which incorporates a number of technical restrictions aimed at placing certain ethical guardrails on the use of their LLMs. But attackers can evade or “jailbreak” their way out of these restricted settings, usually by asking the AI to imagine itself in an elaborate hypothetical situation under which its normal restrictions might be relaxed or discarded altogether.

“A typical jailbreak will pose a very specific scenario, like you’re a writer who’s doing research for a book, and everyone involved is a consenting adult, even though they often end up chatting about nonconsensual things,” Ahl said.

In June 2024, security experts at Sysdig documented a new attack that leveraged stolen cloud credentials to target ten cloud-hosted LLMs. The attackers Sysdig wrote about gathered cloud credentials through a known security vulnerability, but the researchers also found the attackers sold LLM access to other cybercriminals while sticking the cloud account owner with an astronomical bill.

“Once initial access was obtained, they exfiltrated cloud credentials and gained access to the cloud environment, where they attempted to access local LLM models hosted by cloud providers: in this instance, a local Claude (v2/v3) LLM model from Anthropic was targeted,” Sysdig researchers wrote. “If undiscovered, this type of attack could result in over $46,000 of LLM consumption costs per day for the victim.”

Ahl said it’s not certain who is responsible for operating and selling these sex chat services, but Permiso suspects the activity may be tied to a platform cheekily named “chub[.]ai,” which offers a broad selection of pre-made AI characters with whom users can strike up a conversation. Permiso said almost every character name from the prompts they captured in their honeypot could be found at Chub.

Some of the AI chat bot characters offered by Chub. Some of these characters include the tags “rape” and “incest.”

Chub offers free registration, via its website or a mobile app. But after a few minutes of chatting with their newfound AI friends, users are asked to purchase a subscription. The site’s homepage features a banner at the top that reads: “Banned from OpenAI? Get unmetered access to uncensored alternatives for as little as $5 a month.”

Until late last week Chub offered a wide selection of characters in a category called “NSFL” or Not Safe for Life, a term meant to describe content that is disturbing or nauseating to the point of being emotionally scarring.

Fortune profiled Chub AI in a January 2024 story that described the service as a virtual brothel advertised by illustrated girls in spaghetti strap dresses who promise a chat-based “world without feminism,” where “girls offer sexual services.” From that piece:

Chub AI offers more than 500 such scenarios, and a growing number of other sites are enabling similar AI-powered child pornographic role-play. They are part of a broader uncensored AI economy that, according to Fortune’s interviews with 18 AI developers and founders, was spurred first by OpenAI and then accelerated by Meta’s release of its open-source Llama tool.

Fortune says Chub is run by someone using the handle “Lore,” who said they launched the service to help others evade content restrictions on AI platforms. Chub charges fees starting at $5 a month to use the new chatbots, and the founder told Fortune the site had generated more than $1 million in annualized revenue.

KrebsOnSecurity sought comment about Permiso’s research from AWS, which initially seemed to downplay the seriousness of the researchers’ findings. The company noted that AWS employs automated systems that will alert customers if their credentials or keys are found exposed online.

AWS explained that when a key or credential pair is flagged as exposed, it is then restricted to limit the amount of abuse that attackers can potentially commit with that access. For example, flagged credentials can’t be used to create or modify authorized accounts, or spin up new cloud resources.

Ahl said Permiso did indeed receive multiple alerts from AWS about their exposed key, including one that warned their account may have been used by an unauthorized party. But they said the restrictions AWS placed on the exposed key did nothing to stop the attackers from using it to abuse Bedrock services.

Sometime in the past few days, however, AWS responded by including Bedrock in the list of services that will be quarantined in the event an AWS key or credential pair is found compromised or exposed online. AWS confirmed that Bedrock was a new addition to its quarantine procedures.

Additionally, not long after KrebsOnSecurity began reporting this story, Chub’s website removed its NSFL section. It also appears to have removed cached copies of the site from the Wayback Machine at archive.org. Still, Permiso found that Chub’s user stats page shows the site has more than 3,000 AI conversation bots with the NSFL tag, and that 2,113 accounts were following the NSFL tag.

The user stats page at Chub shows more than 2,113 people have subscribed to its AI conversation bots with the “Not Safe for Life” designation.

Permiso said their entire two-day experiment generated a $3,500 bill from AWS. Most of that cost was tied to the 75,000 LLM invocations caused by the sex chat service that hijacked their key.

Paradoxically, Permiso found that while enabling these logs is the only way to know for sure how crooks might be using a stolen key, the cybercriminals who are reselling stolen or exposed AWS credentials for sex chats have started including programmatic checks in their code to ensure they aren’t using AWS keys that have prompt logging enabled.

“Enabling logging is actually a deterrent to these attackers because they are immediately checking to see if you have logging on,” Ahl said. “At least some of these guys will totally ignore those accounts, because they don’t want anyone to see what they’re doing.”

In a statement shared with KrebsOnSecurity, AWS said its services are operating securely, as designed, and that no customer action is needed. Here is their statement:

“AWS services are operating securely, as designed, and no customer action is needed. The researchers devised a testing scenario that deliberately disregarded security best practices to test what may happen in a very specific scenario. No customers were put at risk. To carry out this research, security researchers ignored fundamental security best practices and publicly shared an access key on the internet to observe what would happen.”

“AWS, nonetheless, quickly and automatically identified the exposure and notified the researchers, who opted not to take action. We then identified suspected compromised activity and took additional action to further restrict the account, which stopped this abuse. We recommend customers follow security best practices, such as protecting their access keys and avoiding the use of long-term keys to the extent possible. We thank Permiso Security for engaging AWS Security.”

AWS said customers can configure model invocation logging to collect Bedrock invocation logs, model input data, and model output data for all invocations in the AWS account used in Amazon Bedrock. Customers can also use CloudTrail to monitor Amazon Bedrock API calls.

The company said AWS customers also can use services such as GuardDuty to detect potential security concerns and Billing Alarms to provide notifications of abnormal billing activity. Finally, AWS Cost Explorer is intended to give customers a way to visualize and manage Bedrock costs and usage over time.

Anthropic told KrebsOnSecurity it is always working on novel techniques to make its models more resistant to jailbreaks.

“We remain committed to implementing strict policies and advanced techniques to protect users, as well as publishing our own research so that other AI developers can learn from it,” Anthropic said in an emailed statement. “We appreciate the research community’s efforts in highlighting potential vulnerabilities.”

Anthropic said it uses feedback from child safety experts at Thorn around signals often seen in child grooming to update its classifiers, enhance its usage policies, fine tune its models, and incorporate those signals into testing of future models.

Update: 5:01 p.m. ET: Chub has issued a statement saying they are only hosting the role-playing characters, and that the LLMs they use run on their own infrastructure.

“Our own LLMs run on our own infrastructure,” Chub wrote in an emailed statement. “Any individuals participating in such attacks can use any number of UIs that allow user-supplied keys to connect to third-party APIs. We do not participate in, enable or condone any illegal activity whatsoever.”

Cisco Simplifies Cloud Security with AWS Cloud WAN Service Insertion

Drs-Malware-Scan - Perform File-Based Malware Scan On Your On-Prem Servers With AWS

Perform malware scan analysis of on-prem servers using AWS services

Challenges with on-premises malware detection

It can be difficult for security teams to continuously monitor all on-premises servers due to budget and resource constraints. Signature-based antivirus alone is insufficient as modern malware uses various obfuscation techniques. Server admins may lack visibility into security events across all servers historically. Determining compromised systems and safe backups to restore from during incidents is challenging without centralized monitoring and alerting. It is onerous for server admins to setup and maintain additional security tools for advanced threat detection. The rapid mean time to detect and remediate infections is critical but difficult to achieve without the right automated solution.

Determining which backup image is safe to restore from during incidents without comprehensive threat intelligence is another hard problem. Even if backups are available, without knowing when exactly a system got compromised, it is risky to blindly restore from backups. This increases the chance of restoring malware and losing even more valuable data and systems during incident response. There is a need for an automated solution that can pinpoint the timeline of infiltration and recommend safe backups for restoration.

How to use AWS services to address these challenges

The solution leverages AWS Elastic Disaster Recovery (AWS DRS), Amazon GuardDuty and AWS Security Hub to address the challenges of malware detection for on-premises servers.

This combo of services provides a cost-effective way to continuously monitor on-premises servers for malware without impacting performance. It also helps determine safe recovery point in time backups for restoration by identifying timeline of compromises through centralized threat analytics.

• AWS Elastic Disaster Recovery (AWS DRS) minimizes downtime and data loss with fast, reliable recovery of on-premises and cloud-based applications using affordable storage, minimal compute, and point-in-time recovery.

• Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.

• AWS Security Hub is a cloud security posture management (CSPM) service that performs security best practice checks, aggregates alerts, and enables automated remediation.

Architecture

Solution description

The Malware Scan solution assumes on-premises servers are already being replicated with AWS DRS, and Amazon GuardDuty & AWS Security Hub are enabled. The cdk stack in this repository will only deploy the boxes labelled as DRS Malware Scan in the architecture diagram.

1. AWS DRS is replicating source servers from the on-premises environment to AWS (or from any cloud provider for that matter). For further details about setting up AWS DRS please follow the Quick Start Guide.
2. Amazon GuardDuty is already enabled.
3. AWS Security Hub is already enabled.
4. The Malware Scan solution is triggered by a Schedule Rule in Amazon EventBridge (with prefix DrsMalwareScanStack-ScheduleScanRule). You can adjust the scan frequency as needed (i.e. once a day, a week, etc).
5. The Schedule Rule in Amazon EventBridge triggers the Submit Orders lambda function (with prefix DrsMalwareScanStack-SubmitOrders) which gathers the source servers to scan from the Source Servers DynamoDB table.
6. Orders are placed on the SQS FIFO queue named Scan Orders (with prefix DrsMalwareScanStack-ScanOrdersfifo). The queue is used to serialize scan requests mapped to the same DRS instance, preventing a race condition.
7. The Process Order lambda picks a malware scan order from the queue and enriches it, preparing the upcoming malware scan operation. For instance, it inserts the id of the replicating DRS instance associated to the DRS source server provided in the order. The output of Process Order are malware scan commands containing all the necessary information to invoke GuardDuty malware scan.
8. Malware scan operations are tracked using the DRSVolumeAnnotationsDDBTable at the volume-level, providing reporting capabilities.
9. Malware scan commands are inserted in the Scan Commands SQS FIFO queue (with prefix DrsMalwareScanStack-ScanCommandsfifo) to increase resiliency.
10. The Process Commands function submits queued scan commands at a maximum rate of 1 command per second to avoid API throttling. It triggers the on-demand malware scan function provided by Amazon GuardDuty.
11. The execution of the on-demand Amazon GuardDuty Malware job can be monitored from the Amazon GuardDuty service.
12. The outcome of malware scan job is routed to Amazon Cloudwath Logs.
13. The Subscription Filter lambda function receives the outcome of the scan and tracks the result using DynamoDB (step #14).
14. The DRS Instance Annotations DynamoDB Table tracks the status of the malware scan job at the instance level.
15. The CDK stack named ScanReportStack deploys the Scan Report lambda function (with prefix ScanReportStack-ScanReport) to populate the Amazon S3 bucket with prefix scanreportstack-scanreportbucket.
16. AWS Security Hub aggregates and correlates findings from Amazon GuardDuty.
17. The Security Hub finding event is caught by an EventBridge Rule (with prefix DrsMalwareScanStack-SecurityHubAnnotationsRule)
18. The Security Hub Annotations lambda function (with prefix DrsMalwareScanStack-SecurityHubAnnotation) generates additional Notes (Annotations) to the Finding with contextualized information about the source server being affected. This additional information can be seen in the Notes section within the Security Hub Finding.
19. The follow-up activities will depend on the incident response process being adopted. For example based on the date of the infection, AWS DRS can be used to perform a point in time recovery using a snapshot previous to the date of the malware infection.
20. In a Multi-Account scenario, this solution can be deployed directly on the AWS account hosting the AWS DRS solution. The Amazon GuardDuty findings will be automatically sent to the centralized Security Account.

Usage

Pre-requisites

• An AWS Account.
• Amazon Elastic Disaster Recovery (DRS) configured, with at least 1 server source in sync. If not, please check this documentation. The Replication Configuration must consider EBS encryption using Custom Managed Key (CMK) from AWS Key Management Service (AWS KMS). Amazon GuardDuty Malware Protection does not support default AWS managed key for EBS.
• IAM Privileges to deploy the components of this solution.
• Amazon GuardDuty enabled. If not, please check this documentation

• Amazon Security Hub enabled. If not, please check this documentation

  Warning
  Currently, Amazon GuardDuty Malware scan does not support EBS volumes encrypted with EBS-managed keys. If you want to use this solution to scan your on-prem (or other-cloud) servers replicated with DRS, you need to setup DRS replication with your own encryption key in KMS. If you are currently using EBS-managed keys with your replicating servers, you can change encryption settings to use your own KMS key in the DRS console.

Deploy

1. Create a Cloud9 environment with Ubuntu image (at least t3.small for better performance) in your AWS account. Open your Cloud9 environment and clone the code in this repository. Note: Amazon Linux 2 has node v16 which is not longer supported since 2023-09-11 git clone https://github.com/aws-samples/drs-malware-scan

   cd drs-malware-scan

   sh check_loggroup.sh

2. Deploy the CDK stack by running the following command in the Cloud9 terminal and confirm the deployment

   npm install cdk bootstrap cdk deploy --all Note
   The solution is made of 2 stacks: * DrsMalwareScanStack: it deploys all resources needed for malware scanning feature. This stack is mandatory. If you want to deploy only this stack you can run cdk deploy DrsMalwareScanStack
   * ScanReportStack: it deploys the resources needed for reporting (Amazon Lambda and Amazon S3). This stack is optional. If you want to deploy only this stack you can run cdk deploy ScanReportStack

   If you want to deploy both stacks you can run cdk deploy --all

Troubleshooting

All lambda functions route logs to Amazon CloudWatch. You can verify the execution of each function by inspecting the proper CloudWatch log groups for each function, look for the /aws/lambda/DrsMalwareScanStack-* pattern.

The duration of the malware scan operation will depend on the number of servers/volumes to scan (and their size). When Amazon GuardDuty finds malware, it generates a SecurityHub finding: the solution intercepts this event and runs the $StackName-SecurityHubAnnotations lambda to augment the SecurityHub finding with a note containing the name(s) of the DRS source server(s) with malware.

The SQS FIFO queues can be monitored using the Messages available and Message in flight metrics from the AWS SQS console

The DRS Volume Annotations DynamoDB tables keeps track of the status of each Malware scan operation.

Amazon GuardDuty has documented reasons to skip scan operations. For further information please check Reasons for skipping resource during malware scan

In order to analize logs from Amazon GuardDuty Malware scan operations, you can check /aws/guardduty/malware-scan-events Amazon Cloudwatch LogGroup. The default log retention period for this log group is 90 days, after which the log events are deleted automatically.

Cleanup

1. Run the following commands in your terminal:

   cdk destroy --all

2. (Optional) Delete the CloudWatch log groups associated with Lambda Functions.

AWS Cost Estimation Analysis

For the purpose of this analysis, we have assumed a fictitious scenario to take as an example. The following cost estimates are based on services located in the North Virginia (us-east-1) region.

Estimated scenario:

• 2 Source Servers to replicate (DR) (Total Storage: 100GB - 4 disks)
• 3 TB Malware Scanned/Month
• 30 days of EBS snapshot Retention period
• Daily Malware scans

Service Breakdown:

Note The figures presented here are estimates based on the assumptions described above, derived from the AWS Pricing Calculator. For further details please check this pricing calculator as a reference. You can adjust the services configuration in the referenced calculator to make your own estimation. This estimation does not include potential taxes or additional charges that might be applicable. It's crucial to remember that actual fees can vary based on usage and any additional services not covered in this analysis. For critical environments is advisable to include Business Support Plan (not considered in the estimation)

Security

See CONTRIBUTING for more information.

Authors

• Rodrigo Monge
• Thierry Francois
• Diego Pérez Holguín
• Leandro Santi

Benefits of Ingesting Data from Amazon Inspector into Cisco Vulnerability Management

Co-authored by Tejas Sheth, Sr. Security Specialist, Amazon Web Services – AISPL.

Risk-based Vulnerability Management (RBVM) represents a strategic approach to cyber security that focuses on… Read more on Cisco Blogs

Italian Data Protection Watchdog Accuses ChatGPT of Privacy Violations

Google Settles $5 Billion Privacy Lawsuit Over Tracking Users in 'Incognito Mode'

Aws-Waf-Header-Analyzer - The Purpose Of The Project Is To Create Rate Limit In AWS WaF Based On HTTP Headers

The purpose of the project is to create rate limit in AWS WaF based on HTTP headers.

Golang is a dependencie to build the binary. See the documentation to install: https://go.dev/doc/install

make
sudo make install

The rules configuration is very simple, for example, the threshold is the limited of the requests in X time. It's possible to monitoring multiples headers, but, the header needs to be in HTTP Request header log.

rules:
  header:
    x-api-id: # The header name in HTTP Request header
      threshold: 100

    token:
      threshold: 1000

It's possible send notifications to Slack and Telegram. To configure slack notifications, you needs create a webhook configuration, see the slack documentation: https://api.slack.com/messaging/webhooks

Telegram bot father: https://t.me/botfather

notifications:
  slack:
    webhook-url: https://hooks.slack.com/services/DA2DA13QS/LW5DALDSMFDT5/qazqqd4f5Qph7LgXdZaHesXs

  telegram:
    bot-token: "123456789:NNDa2tbpq97izQx_invU6cox6uarhrlZDfa"
    chat-id:  "-4128833322"

To set up AWS credentials, it's advisable to export them as environment variables. Here's a recommended approach:

export AWS_ACCESS_KEY_ID=".."
export AWS_SECRET_ACCESS_KEY=".."
export AWS_REGION="us-east-1"

retrive-logs-minutes-ago is the time range you want to fetch the logs, in this example, logs from 1 hour ago.

aws:
  waf-log-group-name: aws-waf-logs-cloudwatch-cloudfront
  region: us-east-1
  retrive-logs-minutes-ago: 60

New AMBERSQUID Cryptojacking Operation Targets Uncommon AWS Services

The Wild West of AI: Do Any AI Laws Exist?

Are we in the Wild West? Scrolling through your social media feed and breaking news sites, all the mentions of artificial intelligence and its uses makes the online world feel like a lawless free-for-all.  

While your school or workplace may have rules against using AI for projects, as of yet there are very few laws regulating the usage of mainstream AI content generation tools. As the technology advances are laws likely to follow? Let’s explore. 

What AI Laws Exist? 

As of August 2023, there are no specific laws in the United States governing the general public’s usage of AI. For example, there are no explicit laws banning someone from making a deepfake of a celebrity and posting it online. However, if a judge could construe the deepfake as defamation or if it was used as part of a scam, it could land the creator in hot water. 

The White House issued a draft of an artificial intelligence bill of rights that outlines best practices for AI technologists. This document isn’t a law, though. It’s more of a list of suggestions to urge developers to make AI unbiased, as accurate as possible, and to not completely rely on AI when a human could perform the same job equally well.1 The European Union is in the process of drafting the EU AI Act. Similar to the American AI Bill of Rights, the EU’s act is mostly directed toward the developers responsible for calibrating and advancing AI technology.2 

China is one country that has formal regulations on the use of AI, specifically deepfake. A new law states that a person must give express consent to allow their faces to be used in a deepfake. Additionally, the law bans citizens from using deepfake to create fake news reports or content that could negatively affect the economy, national security, or China’s reputation. Finally, all deepfakes must include a disclaimer announcing that the content was synthesized.3 

Should AI Laws Exist in the Future? 

As scammers, edgy content creators, and money-conscious executives push the envelope with deepfake, AI art, and text-generation tools, laws governing AI use may be key to stopping the spread of fake news and protect people’s livelihoods and reputations. 

Deepfake challenges the notion that “seeing is believing.” Fake news reports can be dangerous to society when they encourage unrest or spark widespread outrage. Without treading upon the freedom of speech, is there a way for the U.S. and other countries to regulate deepfake creators with intentions of spreading dissent? China’s mandate that deepfake content must include a disclaimer could be a good starting point. 

The Writers Guild of America (WGA) and Screen Actors Guild – American Federation of Television and Radio Artists (SAG-AFTRA) strikes are a prime example of how unbridled AI use could turn invasive and impact people’s jobs. In their new contract negotiations, each union included an AI clause. For the writers, they’re asking that AI-generated text not be allowed to write “literary material.” Actors are arguing against the widespread use of AI-replication of actors’ voices and faces. While deepfake could save (already rich) studios millions, these types of recreations could put actors out of work and would allow the studio to use the actors’ likeness in perpetuity without the actors’ consent.4 Future laws around the use of AI will likely include clauses about consent and assuming the risk text generators introduce to any project. 

Use AI Responsibly 

In the meantime, while the world awaits more guidelines and firm regulations governing mainstream AI tools, the best way you can interact with AI in daily life is to do so responsibly and in moderation. This includes using your best judgement and always being transparent when AI was involved in a project.  

Overall, whether in your professional and personal life, it’s best to view AI as a partner, not as a replacement.  

1The White House, “Blueprint for an AI Bill of Rights: Making Automated Systems Work for the American People” 

2European Parliament, “EU AI Act: first regulation on artificial intelligence” 

3CNBC, “China is about to get tougher on deepfakes in an unprecedented way. Here’s what the rules mean” 

4NBC News, “Actors vs. AI: Strike brings focus to emerging use of advanced tech” 

The post The Wild West of AI: Do Any AI Laws Exist? appeared first on McAfee Blog.

Researchers Uncover AWS SSM Agent Misuse as a Covert Remote Access Trojan

TeamTNT's Silentbob Botnet Infecting 196 Hosts in Cloud Attack Campaign

SCARLETEEL Cryptojacking Campaign Exploiting AWS Fargate in Ongoing Campaign

Indonesian Cybercriminals Exploit AWS for Profitable Crypto Mining Operations

Aws-Security-Assessment-Solution - An AWS Tool To Help You Create A Point In Time Assessment Of Your AWS Account Using Prowler And Scout As Well As Optional AWS Developed Ransomware Checks

Self-Service Security Assessment too l

Cybersecurity remains a very important topic and point of concern for many CIOs, CISOs, and their customers. To meet these important concerns, AWS has developed a primary set of services customers should use to aid in protecting their accounts. Amazon GuardDuty, AWS Security Hub, AWS Config, and AWS Well-Architected reviews help customers maintain a strong security posture over their AWS accounts. As more organizations deploy to the cloud, especially if they are doing so quickly, and they have not yet implemented the recommended AWS Services, there may be a need to conduct a rapid security assessment of the cloud environment.

With that in mind, we have worked to develop an inexpensive, easy to deploy, secure, and fast solution to provide our customers two (2) security assessment reports. These security assessments are from the open source projects “Prowler” and “ScoutSuite.” Each of these projects conduct an assessment based on AWS best practices and can help quickly identify any potential risk areas in a customer’s deployed environment. If you are interested in conducting these assessments on a continuous basis, AWS recommends enabling Security Hub’s Foundational Security Best P ractices standard. If you are interested in integrating your Prowler assessment results with Security Hub, you can also do that from Prowler natively following instructions here.

In addition, we have developed custom modules that speak to customer concerns around threats and misconfigurations of those issues, currently this includes checks for ransomware specific findings.

ARCHITECTURE OVERVIEW

Overview - Open Source project checks

The architecture we deploy is a very simple VPC with two (2) subnets, one (1) NAT Gateway, one (1) EC2 instance, and one (1) S3 Bucket. The EC2 instance is using Amazon Linux 2 (the latest published AMI), that is patched on boot, pulls down the two projects (Prowler and ScoutSuite), runs the assessments and then delivers the reports to the S3 Bucket. The EC2 instances does not deploy with any EC2 Key Pair, does not have any open ingress rules on its Security Group, and is placed in the Private Subnet so it does not have direct internet access. After completion of the assessment and the delivery of the reports the system can be terminated.

The deployment is accomplished through the use of CloudFormation. A single CloudFormation template is used to launch a few other templates (in a modular approach). No parameters (user input) is required and the automated build out of the environment will take on average less than 10 minutes to complete. These templates are provided for review in this Github repository.

Once the EC2 Instance has been created and begins, the two assessments it will take somewhere around 40 minutes to complete. At the end of the assessments and after the two reports are delivered to the S3 Bucket the Instance will automatically shutdown, You may at this time safely terminate the Instance.

How to deploy this tool

• See the following guide on installation steps

How do I read the reports?

• See the following guide on accessing and reading the report outputs

Diagram

Here is a diagram of the architecture.

What will be created

• A VPC

  • This will be a /26 for the VPC
  • This will include 2 subnets both in the same Availability Zone, one Public and one Private
  • This will include the required Route Tables and ACLs

• An EIP

  • For use by the NAT Gateway

• A NAT Gateway

  • This is required for the instance to download both Prowler and ScoutSuite as well as to make the API Calls

• A Security Group

  • For the Instance

• A single m5a.large instance with a 10 GB gp2 EBS volume

  • This is the instance in which Prowler and ScoutSuite will run
  • It will be in a Private Subnet
  • It will not have an EC2 Key Pair
  • It will not allow ingress traffic on the Security Group

• An Instance Role

  • This Role is required so that Prowler and ScoutSuite can run the API calls from the EC2 Instance

• An IAM Policy

  • Some IAM permissions are required for Prowler and ScoutSuite
    • Prowler info here
    • ScoutSuite info here

• An S3 Bucket

  • This is the location where the reports will be delivered
  • It will take about 40 minutes for the reports to show up

Open source security Assessments

These security assessments are from the open source projects “Prowler” and “ScoutSuite.” Each of these projects conduct an assessment based on AWS best practices and can help quickly identify any potential risk areas in a customer’s deployed environment.

1. Prowler

The first assessment is from Prowler.

• Prowler follows guidelines of the CIS Amazon Web Services Foundations Benchmark (49 checks) and has 40 additional checks including related to GDPR and HIPAA, in total Prowler offers over 160 checks.

2. ScoutSuite

The second assessment is from ScoutSuite

• ScoutSuite has been around since 2012, originally a Scout, then Scout2, and now ScoutSuite. This will provide a set of files that can be viewed in your browser and conducts a wide range of checks

Overiew of optional modules

► Check for Common Security Mistakes module

When enabled, this module will deploy a lambda function that checks for common security mistakes highlighted in https://www.youtube.com/watch?v=tmuClE3nWlk.

What will be created

A Lambda function that will perform the checks. Some of the checks include:

• GuardDuty set to alert on findings
• GuardDuty enabled across all regions
• Prevent accidental key deletion
• Existence of a Multi-region CloudTrail
• CloudTrail validation enabled
• No local IAM users
• Roles tuned for least privilege in last 90 days
• Alerting for root account use
• Alerting for local IAM user create/delete
• Use of Managed Prefix Lists in Security Groups
• Public S3 Buckets

► Ransomware modules

When enabled, this module will deploy separate functions that can help customers with evaluating their environment for ransomware infection and susceptibility to ransomware damage.

What will be created

• AWS Core security services enabled
  • Checks for AWS security service enablement in all regions where applicable (GuardDuty, SecurityHub)
• Data protection checks
  • Checks for EBS volumes with no snapshot
  • Checks for outdated OS running
  • Checks for S3 bucket replication JobStatus
  • Checks for EC2 instances that can not be managed with SSM
  • Checks for Stale IAM roles that have been granted S3 access but have not used them in the last 60 days
  • Checks for S3 deny public access enablement
  • Checks to see if DNSSEC is enabled for public hosted zones in Amazon Route 53
  • Checks to see if logging is enabled for services relevant to ransomware (i.e. CloudFront, Lambda, Route53 Query Logging, and Route 53 Resolver Logging).
  • Checks to see if Route 53 Resolver DNS Firewall is enabled across all relevant regions
  • Checks to see if there are any Access Keys that have not been used in last 90 days

► SolarWinds module

When enabled, this module will deploy separate functions that can help customers with evaluating their environment for SolarWinds vulnerability. The checks are based on CISA Alert AA20-352A from Appendix A & B.

Note: Prior to enablement of this module, please read the module documentation which reviews the steps that need to be completed prior to using this module.

Note: This module MUST be run separately as its own stack, select the S3 URL SelfServiceSecSolar.yml to deploy

What will be created

• Athena query - AA20352A IP IOC
  • This Athena query will scan your VPC flow logs for IP addresses from the CISA AA20-352A.
• SSM Automation document - SolorWindsAA20-352AAutomatedScanner
  • This is a systems manager automation document that will scan Windows EC2 instances for impacted .dll files from CISA AA20-352A.
• Route53 DNS resolver query - AA20352A DNS IOC
  • This Athena query will scan your DNS logs for customers that have enabled DNS query logging

Frequently Asked Questions (FAQ)

1. Is there a cost?
   • Yes. This should normally cost less than $1 for an hour of use.
2. Is this a continuous monitoring and reporting tool?
   • No. This is a one-time assessment, we urge customers to leverage tooling like AWS SecurityHub for Ongoing assessments.
3. Why does the CloudFormation service error when deleting the stack?
   • You must remove the objects (reports) out of the S3 bucket first
4. Does this integrate with GuardDuty, Security Hub, CloudWatch, etc.?
   • Not at this time. In a future sprint we plan to incorporate integration with AWS services like Security Hub and GuardDuty. However, you can follow the instructions in this blog to integrate Prowler and Security Hub.
5. How do I remediate the issues in the reports?
   • Generally, the issues should be described in the report with readily identifiable corrections. Please follow up with the public documentation for each tool (Prowler and ScoutSuite) as well. If this is insufficient, please reach out to your AWS Account team and we will be more than happy to help you understand the reports and work towards remediating issues.

Security

See CONTRIBUTING for more information.

License

This project is licensed under the Apache-2.0 License.

Cisco Joins the Launch of Amazon Security Lake

Cisco supports the Open Cybersecurity Schema Framework and is a launch partner of AWS Security Lake

The Cisco Secure Technical Alliance supports the open ecosystem and AWS is a valued technology alliance partner, with integrations across the Cisco Secure portfolio, including SecureX, Secure Firewall, Secure Cloud Analytics, Duo, Umbrella, Web Security Appliance, Secure Workload, Secure Endpoint, Identity Services Engine, and more.

Cisco Secure and AWS Security Lake

We are proud to be a launch partner of AWS Security Lake, which allows customers to build a security data lake from integrated cloud and on-premises data sources as well as from their private applications. With support for the Open Cybersecurity Schema Framework (OCSF) standard, Security Lake reduces the complexity and costs for customers to make their security solutions data accessible to address a variety of security use cases such as threat detection, investigation, and incident response. Security Lake helps organizations aggregate, manage, and derive value from log and event data in the cloud and on-premises to give security teams greater visibility across their organizations.

With Security Lake, customers can use the security and analytics solutions of their choice to simply query that data in place or ingest the OCSF-compliant data to address further use cases. Security Lake helps customers optimize security log data retention by optimizing the partitioning of data to improve performance and reduce costs. Now, analysts and engineers can easily build and use a centralized security data lake to improve the protection of workloads, applications, and data.

Cisco Secure Firewall

Cisco Secure Firewall serves as an organization’s centralized source of security information. It uses advanced threat detection to flag and act on malicious ingress, egress, and east-west traffic while its logging capabilities store information on events, threats, and anomalies. By integrating Secure Firewall with AWS Security Lake, through Secure Firewall Management Center, organizations will be able to store firewall logs in a structured and scalable manner.

eNcore Client OCSF Implementation

The eNcore client provides a way to tap into message-oriented protocol to stream events and host profile information from the Cisco Secure Firewall Management Center. The eNcore client can request event and host profile data from a Management Center, and intrusion event data only from a managed device. The eNcore application initiates the data stream by submitting request messages, which specify the data to be sent, and then controls the message flow from the Management Center or managed device after streaming begins.

These messages are mapped to OCSF Network Activity events using a series of transformations embedded in the eNcore code base, acting as both author and mapper personas in the OCSF schema workflow. Once validated with an internal OCSF schema the messages are then written to two sources, first a local JSON formatted file in a configurable directory path, and second compressed parquet files partitioned by event hour in the S3 Amazon Security Lake source bucket. The S3 directories contain the formatted log are crawled hourly and the results are stored in an AWS Security Lake database. From there you can get a visual of the schema definitions extracted by the AWS Glue Crawler, identify fieldnames, data types, and other metadata associated with your network activity events. Event logs can also be queried using Amazon Athena to visualize log data.

Get Started

To utilize the eNcore client with AWS Security Lake, first go to the Cisco public GitHub repository for Firepower eNcore, OCSF branch.

Download and run the cloud formation script eNcoreCloudFormation.yaml.

The Cloud Formation script will prompt for additional fields needed in the creation process, they are as follows:

Cidr Block:  IP Address range for the provisioned client, defaults to the range shown below

Instance Type:  The ec2 instance size, defaults to t2.medium

KeyName  A pem key file that will permit access to the instance

AmazonSecurityLakeBucketForCiscoURI: The S3 location of your Data Lake S3 container.

FMC IP: IP or Domain Name of the Cisco Secure Firewall Mangement Portal

After the Cloud Formation setup is complete it can take anywhere from 3-5 minutes to provision resources in your environment, the cloud formation console provides a detailed view of all the resources generated from the cloud formation script as shown below.

Once the ec2 instance for the eNcore client is ready, we need to whitelist the client IP address in our Secure Firewall Server and generate a certificate file for secure endpoint communication.

In the Secure Firewall Dashboard, navigate to Search->eStreamer, to find the allow list of Client IP Addresses that are permitted to receive data, click Add and supply the Client IP Address that was provisioned for our ec2 instance.  You will also be asked to supply a password, click Save to create a secure certificate file for your new ec2 instance.

Download the Secure Certificate you just created, and copy it to the /encore directory in your ec2 instance.

Use CloudShell or SSH from your ec2 instance, navigate to the /encore directory and run the command bash encore.sh test

You will be prompted for the certificate password, once that is entered you should see a Successful Communication message as shown below.

Run the command bash encore.sh foreground

This will begin the data relay and ingestion process. We can then navigate to the S3 Amazon Security Lake bucket we configured earlier, to see OCSF compliant logs formatted in gzip parquet files in a time-based directory structure. Additionally, a local representation of logs is available under /encore/data/* that can be used to validate log file creation.

Amazon Security Lake then runs a crawler task every hour to parse and consume the logs files in the target s3 directory, after which we can view the results in Athena Query.

More information on how to configure and tune the encore eStreamer client can be found on our official website, this includes details on how filter certain event types to focus your data retention policy, and guidelines for performance and other detailed configuration settings. 

Participate in the public preview

You can participate in the AWS Security Lake public preview. For more information, please visit the Product Page and review the User Guide. 

re:Invent 

While you are at AWS re:Invent, go see a demo video of the Security Lake integrations in the Cisco Booth #2411, from November 29 to December 2, 2022, at the Cloud, Network and User Security with Duo demo station.

Learn more about Cisco and AWS on the Cisco Secure Technical Alliance website for AWS.

Acknowledgement

Thank you to Seyed Khadem-Djahaghi, who spend long hours working with the beta to develop this integration and is the primary for developer of eNore.

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Researchers Detail AppSync Cross-Tenant Vulnerability in Amazon Web Services

AWS User Management

Introduction In order to keep your AWS environment secure while allowing your users to properly utilize resources, you must ensure that users are correctly created with proper permissions. Also, you must monitor your environment to ensure that unauthorized access does not occur and accounts are up to date. User Account Creation and Management AWS IAM […]

The post AWS User Management appeared first on Infosec Resources.

Cloud Security Is Simple, Absolutely Simple.

“Cloud security is simple, absolutely simple. Stop over complicating it.”

This is how I kicked off a presentation I gave at the CyberRisk Alliance, Cloud Security Summit on Apr 17 of this year. And I truly believe that cloud security is simple, but that does not mean easy. You need the right strategy.

As I am often asked about strategies for the cloud, and the complexities that come with it, I decided to share my recent talk with you all. Depending on your preference, you can either watch the video below or read the transcript of my talk that’s posted just below the video. I hope you find it useful and will enjoy it. And, as always, I’d love to hear from you, find me @marknca.

For those of you who prefer to read rather than watch a video, here’s the transcript of my talk:

Cloud security is simple, absolutely simple. Stop over complicating it.

Now, I know you’re probably thinking, “Wait a minute, what is this guy talking about? He is just off his rocker.”

Remember, simple doesn’t mean easy. I think we make things way more complicated than they need to be when it comes to securing the cloud, and this makes our lives a lot harder than they need to be. There’s some massive advantages when it comes to security in the cloud. Primarily, I think we can simplify our security approach because of three major reasons.

The first is integrated identity and access management. All three major cloud providers, AWS, Google and Microsoft offer fantastic identity, and access management systems. These are things that security, and [inaudible 00:00:48] professionals have been clamouring for, for decades.

We finally have this ability, we need to take advantage of it.

The second main area is the shared responsibility model. We’ll cover that more in a minute, but it’s an absolutely wonderful tool to understand your mental model, to realize where you need to focus your security efforts, and the third area that simplifies security for us is the universal application of APIs or application programming interfaces.

These give us as security professionals the ability to orchestrate. and automate a huge amount of the grunt work away. These three things add up to, uh, the ability for us to execute a very sophisticated, uh, or very difficult to pull off, uh, security practice, but one that ultimately is actually pretty simple in its approach.

It’s just all the details are hard and we’re going to use these three advantages to make those details simpler. So, let’s take a step back for a second and look at what our goal is.

What is the goal of cybersecurity? That’s not something you hear quite often as a question.

A lot of the time you’ll hear the definition of cybersecurity is, uh, about, uh, securing the confidentiality, integrity, and availability of information or data. The CIA triad, different CIA, but I like to phrase this in a different way. I think the goal is much clearer, and the goal’s much simpler.

It is to make sure that whatever you’re building works as intended and only as intended. Now, you’ll realize you can’t accomplish this goal just as a security team. You need to work with your, uh, developers, you need to work with operations, you need to work with the business units, with the end users of your application as well.

This is a wonderful way of phrasing our goal, and realizing that we’re all in this together to make sure whatever you’re building works as intended, and only as intended.

Now, if we move forward, and we look at who are we up against, who’s preventing our stuff from working, uh, well?

You look at normally, you think of, uh, who’s attacking our systems? Who are the risks? Is it nation states? Is it maybe insider threats? While these are valid threats, they’re really overblown. You’re… don’t have to worry about nation state attacks.

If you’re a nation state, worry about it. If you’re not a nation state, you don’t have to worry about it because frankly, there’s nothing you can do to stop them. You can slow them down a little bit, but by definition, they’re going to get through your resources.

As far as insider attacks, this is an HR problem. Treat your people well. Um, check in with them, and have a strong information management policy in place, and you’re going to reduce this threat naturally. If you go hunting for people, you’re going to create the very threats that you’re looking at.

So, it brings us to the next set. What about cyber criminals? You know, we do have to worry about cyber criminals.

Cyber criminals are targeting systems simply because these systems are online, these are profit motivated criminals who are organized, and have a good set of tools, so we absolutely need to worry about them, but there’s a more insidious or more commonplace, maybe a simpler threat that we need to worry about, and that’s one of mistakes.

The vast majority of issues that happen around data breaches around security vulnerabilities in the cloud are mistake driven. In fact, to the point where I would not even worry about cyber criminals simply because all the work we’re going to do to focus on, uh, preventing mistakes.

And catching, and rectifying the stakes really, really quickly is going to uh, you a cover all the stuff that we would have done to block out cyber criminals as well, so mistakes are very common because people are using a lot more services in the cloud.

You have a lot more, um, parts and moving, uh, complexity in your deployment, um, and you’re going to make a mistake, which is why you need to put automated systems in place to make sure that those mistakes don’t happen, or if they do happen that they’re caught very, very quickly.

This applies to standard DevOps, the philosophies for building. It also applies to security very, very wonderfully, so this is the main thing we’re going to focus on.

So, if we look at that sum up together, we have our goal of making sure whatever we’re building works as intended, and only as intended, and our major issue here, the biggest risk to this is simple mistakes and misconfigurations.

Okay, so we’re not starting from ground zero here. We can learn from others, and the first place we’re going to learn is the shared responsibility model. The shared responsibility applies to all cloud service providers.

If you look on the left hand side of the slide here, you’ll see the traditional on premise model. We roughly have six areas where something has to be done roughly daily, whether it’s patching, maintenance, uh, just operational visibility, monitoring, that kind of thing, and in a traditional on premise environment, you’re responsible for all of it, whether it’s your team, or a team underneath your organization.

Somewhere within your tree, people are on the hook for doing stuff daily. Here when we move into an infrastructure, so getting a virtual machine from a cloud provider right off the bat, half of the responsibilities are pushed away.

That’s a huge, huge win.

And, as we move further and further to the right to more managed service, or staff level services, we have less and less daily responsibilities.

Now, of course, you always still have to verify that the cloud service provider’s doing what they, uh, say they’re doing, which is why certifications and compliance frameworks come into play, uh, but the bottom line is you’re doing less work, so you can focus on fewer areas.

Um, that is, or I should say not less work, but you’re doing, uh, less broad of a work.

So you can have that deeper focus, and of course, you always have to worry about service configuration. You are given knobs and dials to turn to lock things down. You should use them like things like encrypting, uh, all your data at rest.

Most of the time it’s an easy check box, but it’s up to you to check it ‘cause it’s your responsibility.

We also have the idea of an adoption framework, and this applies for Azure, for AWS and for Google, uh, and what they do is they help you map out your business processes.

This is important to security, because it gives you the understanding of where your data is, what’s important to the business, where does it lie, who needs to touch it, and access it and process it.

That also gives us the idea, uh, or the ability to identify the stakeholders, so that we know, uh, you know, who’s concerned about this data, who is, has an investment in this data, and finally it helps to, to deliver an action plan.

The output of all of these frameworks is to deliver an action plan to help you migrate into the cloud and help you to continuously evolve. Well, it’s also a phenomenal map for your security efforts.

You want to prioritize security, this is how you do it. You get it through the adoption framework, understanding what’s important to the business, and that lets you identify critical systems and areas for your security.

Again, we want to keep things simple, right? And, the third, uh, the o- other things we want to look at is the CIS foundations. They have them for AWS, Azure and GCP, um, and these provide a prescriptive guidance.

They’re really, um, a strong baseline, and a checklist of tasks that you can accomplish, um, or take on, on your, uh, take on, on your own, excuse me, uh, in order to, um, you know, basically cover off the really basics is encryption at rest on, um, you know, do I make sure that I don’t have, uh, things needlessly exposed to the internet, that type of thing.

Really fantastic reference point and a starting point for your security practice.

Again, with this idea of keeping things as simple as possible, so when it comes to looking at our security policy, we’ve used the frameworks, um, and the baseline to kind of set up a strong, uh, start to understand, uh, where the business is concerned, and to prioritize.

And, the first question we need to ask ourselves as security practitioners, what happened? If we, if something happens, and we ask what happened?

Do we have the ability to answer this question? So, that starts us off with logging and auditing. This needs to be in place before something happened. Let me just say that again, before something happened, you need [laughs] to be able to have this information in place.

Now, uh, this is really, uh, to ask these key questions of what happened in my account, and who, or what made that thing happen?

So, this starts in the cloud with some basic services. Uh, for AWS it’s cloud trail, for Azure, it’s monitor, and for Google Cloud it used to be called Stackdriver, it is now the Google Cloud operations suite, so these need to be enabled on at full volume.

Don’t worry, you can use some lifecycle rules on the data source to keep your costs low.

But, this gives you that layer, that basic auditing and logging layer, so that you can answer that question of what happened?

So, the next question you want to ask yourself or have the ability to answer is who’s there, right? Who’s doing what in my account? And, that comes down to identity.

We’ve already mentioned this is one of the key pillars of keeping security simple, and getting that highly effective security in your cloud.

[00:09:00] So here you’re answering the questions of who are you, and what are you allowed to do? This is where we get a very simple privilege, uh, or principle in security, which is the principle of least privilege.

You want to give an identity, so whether that’s a user, or a role, or a service, uh, only the privileges they, uh, require that are essential to perform the task that, uh, they are intended to do.

Okay?

So, basically if I need to write a file into a storage, um, folder or a bucket, I should only have the ability to write that file. I don’t need to read it, I don’t need to delete it, I just need to write to it, so only give me that ability.

Remember, that comes back to the other pillar of simple security here of, of key cloud security, is integrated identity.

This is where it really takes off, is that we start to assign very granular access permissions, and don’t worry, we’re going to use the APIs to automate all this stuff, so that it’s not a management headache, but the principle of these privilege is absolutely critical here.

The services you’re going to be using, amazingly, all three cloud providers got in line, and named them the same thing. It’s IAM, identity access management, whether that’s AWS, Azure or Google Cloud.

Now, the next question we’re going to a- ask ourselves are the areas where we’re going to be looking at is really where should I be focusing security controls? Where should I be putting stuff in place?

Because up until now we’ve really talked about leveraging what’s available from the cloud service providers, and you absolutely should available, uh, maximize your usage of their, um, native and primitive, uh, structures primitive as far as base concepts, not as, um, refined.

They’re very advanced controls and, but there are times where you’re going to need to put in your own controls, and these are the areas you’re going to focus on, so you’re going to start with networking, right?

So, in your networking, you’re going to maximize the native structures that are available in the cloud that you’re in, so whether that’s a project structure in Google Cloud, whether that’s a service like transit gateway in AWS, um, and all of them have this idea of a VPC or virtual private cloud or virtual network that is a very strong boundary for you to use.

Remember, most of the time you’re not charged for the creation of those. You have limits in your accounts, but accounts are free, and you can keep adding more, uh, virtual networks. You may be saying, wait a minute, I’m trying to simplify things.

Actually, having multiple virtual networks or virtual private clouds ends up being far simpler because each of them has a task. You go, this application runs in this virtual private cloud, not a big shared one in this specific VPC, and that gives you this wonderfully strong security boundaries, and a very simple way of looking at one VPC, one action, very much the Unix philosophy in play.

Key here though is understanding that while all of the security controls in place for your service provider, um, give you, so, you know, whether it’s VPCs, routing tables, um, uh, access control lists, security groups, all the SDN features that they’ve got in place.

These really help you figure out whether service A or system A is allowed to talk to B, but they don’t tell you what they’re saying.

And, that’s where additional controls called an IPS, or intrusion prevention system come into play, and you may want to look at getting a third party control in to do that, because none of the th- big three cloud providers offer an IPS at this point.

[00:12:00] But that gives you the ability to not just say, “Hey, you’re allowed to talk to each other.” But, to monitor that conversation, to ensure that there’s not malicious code being passed back and forth between systems that nobody’s trying a denial of service attack.

A whole bunch of extra things on there have, so that’s where IPS comes into play in your network defense. Now, we look at compute, right?

We can have compute in various forms, whether that’s in serverless functions, whether that’s in containers, manage containers, whether that’s in traditional virtual machines, but all the principles are the same.

You want to understand where the shared responsibility line is, how much is on your plate, how much is on the CSPs?

You want to understand that you need to harden the EOS, or the service, or both in some cases, make sure that, that’s locked down, so have administrator passwords. Very, very complicated.

Don’t log into these systems, uh, you know, because you want to be fixing things upstream. You want to be fixing things in the build pipeline, not logging into these systems directly, and that’s a huge thing for, uh, systems people to get over, but it’s absolutely essential for security, and you know what?

It’s going to take a while, but there’s some tricks there you can follow with me. You can see, uh, on the slides, uh, at Mark, that is my social everywhere, uh, happy to walk you through the next steps.

This idea of this presentation’s really just the simple basics to start with, to give you that overview of where to focus your time, and, dispel that myth that cloud security is complicating things.

It is a huge path is simplicity, which is a massive lens, or for security.

So, the last area you want to focus here is in data and storage. Whether this is databases, whether this is big blob storage, or, uh, buckets in AWS, it doesn’t really matter the principles, again, all the same.

You want to encrypt your data at rest using the native cloud provided, uh, cloud service provider, uh, features functionality, because most of the time it’s just give it a key address, and give it a checkbox, and you’re good to go.

It’s never been easier to encrypt things, and there is no excuse for it and none of the providers charge extra for, uh, encryption, which is amazing, and you absolutely want to be taking advantage of that, and you want to be as granular as possible with your IAM, uh, and as reasonable, okay?

So, there’s a line here, and a lot of the data stores that are native to the cloud service providers, you can go right down to the data cell level and say, Mark has access, or Mark doesn’t have access to this cell.

That can be highly effective, and maybe right for your use case. It might be too much as well.

But, the nice thing is that you have that option. It’s integrated, it’s pretty straightforward to implement, and then, uh, when we look here, uh, sorry. and then, finally you want to be looking at lifecycle strategies to keep your costs under control.

Um, data really spins out of control when you don’t have to worry about capacity. All of the cloud service providers have some fantastic automations in place.

Basically, just giving you, uh, very simple rules to say, “Okay, after 90 days, move this over to cheaper storage. After 180 days, you know, get rid of it completely, or put it in cold storage.”

Take advantage of those or your bill’s going to spiral out of control, and, and that relates to availability ‘cause uh, uh, and reliability, ‘cause the more you’re spending on that kind of stuff, the less you have to spend on other areas like security and operational efficiency.

So, that brings us to our next big security question. Is this working?

[00:15:00] How do you know if any of this stuff is working? Well, you want to talk about the concept of traceability. Traceability is a, you know, somewhat formal definition, but for me it really comes down to where did this come from, who can access it, and when did they access it?

That ties very closely with the concept of observability. Basically, the ability to look at, uh, closed systems and to infer what’s going on inside based on what’s coming into that system, and what’s leaving that system, really what’s going on.

There’s some great tools here from the service providers. Again, you want to look at, uh, Amazon CloudWatch, uh, Azure Monitor and the Google Cloud operations, uh, suite. Um, and here this leads us to the key, okay?

This is the key to simplifying everything, and I know we’ve covered a ton in this presentation, but I really want you to take a good look at this slide, and again, hit me up, uh, @marknca, happy to answer any questions with, questions afterwards as well here, um, that this will really, really make this simple, and this will really take your security practice to the next level.

If the idea of something happened in your, cloud system, right? In your deployment, there’s a trigger, and then, it either is generating an event or a log.

If you go the bottom row here, you’ve got a log, which you can then react to in a function to deliver some sort of result. That’s the slow-lane on the bottom.

We’re talking minutes here. You also have the top lane where your trigger fires off an event, and then, you react to that with a function, and then, you get a result in the fast lane.

These things happen in seconds, sub-second time. You start to build out your security practice based on this model.

You start automating more and more in these functions, whether it’s, uh, Lambda, whether it’s Cloud Functions, whether it’s Azure Functions, it doesn’t matter.

The CSPs all offer the same core functionality here. This is the critical, critical success metric, is that when you start reacting in the fast lane automatically to things, so if you see that a security event is triggered from like your malware, uh, on your, uh, virtual machine, you can lock that off, and have a new one spin up automatically.

Um, if you’re looking for compliance stuff, the slow lane is the place to go, because it takes minutes.

Reactions happen up top, more, um, stately or more sedate things, so somebody logging into a system is both up top and down low, so up top, if you logged into a VPC or into, um, an instance, or a virtual machine, you’d have a trigger fire off and maybe ask me immediately, “Mark, did you log into the system? Uh, ‘cause you’re, you know, you’re not supposed to be.”

But then I’d respond and say, “Yeah, I, I did log in.” So, immediately you don’t have to respond. It’s not an incident response scenario, but on the bottom track, maybe you’re tracking how many times I’ve logged in.

And after the three or fourth time maybe someone comes by, and has a chat with me, and says, “Hey, do you keep logging into these systems? Can’t you fix it upstream in the deployment, uh, and build a pipeline ‘cause that’s where we need to be moving?”

So, you’ll find this balance, and this concept, I just wanted to get into your heads right now of automating your security practice. If you have a checklist, it should be sitting in a model like this, because it’ll help you, uh, reduce your workload, right?

The idea is to get as much automated possible, and keep things in very clear, and simple boundaries, and what’s more simple than having every security action listed as an automated function, uh, sitting in a code repository somewhere?

[00:18:00] Fantastic approach to modern security practice in the cloud. Very simple, very clear. Yes, difficult to implement. It can be, but it’s an awesome, simple mental model to keep in your head that everything gets automated as a function based on a trigger somewhere.

So, what are the keys to success? What are the keys to keeping this cloud security thing simple? And, hopefully you’ve realized the difference between a simple mental model, and the challenges, uh, in, uh, implementation.

It can be difficult. It’s not easy to implement, but the mental model needs to be kept simple, right? Keep things in their own VPCs, and their own accounts, automate everything. Very, very simple approach. Everything fits into this s- into this structure, so the keys here are remembering the goal.

Make sure that cybersecurity, uh, is making sure that whatever you build works as intended and only as intended. It’s understanding the shared responsibility model, and it’s really looking at, uh, having a plan through cloud adoption frameworks, how to build well, which is a, uh, a concept called the Well-Architected Framework.

It’s specific to AWS, but it’s generic, um, its principles, it can be applied everywhere. We didn’t cover it here, but I’ll put the links, um, in the materials for you, uh, as well as remembering systems over people, right?

Adding the right controls at the right time, uh, and then, finally observing and react. Be vigilant, practice. You’re not going to get this right out of the gates, uh, perfect.

You’re going to have to refine, iterate, and then it’s extremely cloud friendly. That is the cloud model is, get it out there, iterate quickly, but putting the structures in place, you’re not going to make sure that you’re not doing that in an insecure manner.

Thank you very much, uh, here’s a couple of links that’ll help you out before we take some Q&A here, um, trendmicro.com/cloud will get you to the products to learn more. We’re also doing this really cool streaming.

Uh, I host a show called Let’s Talk Cloud. Um, we uh, interview experts, uh, and have a great conversation around, um, what they’re talking about, uh, in the cloud, what they’re working on, and not just around security, but just in building in general.

You can hit that up at trendtalks.fyi. Um, and again, hit me up on social @marknca.

So, we have a couple of questions to kick this off, and you can put more questions in the webinar here, and they will send them along, or answer them in kind if they can.

Um, and that’s really what these are about, is the interaction is getting that, um, to and from. So, the first question that I wanted to tackle is an interesting one, and it’s really that systems over people.

Um, you heard me mention it in the, uh, in the end and the question is really what does that mean systems over people? Isn’t security really about people’s expertise?

And, yes and no, so if you are a SOC analyst, if you are working in a security, uh, role right now, I am really confident saying that 80%, 90% of what you do right now could be delegated out to a system.

So, if you were looking at log lines, and stuff that should be done by systems and bubble up, just the goal for you to investigate to do what people are good at in systems are bad at, so systems mean, uh, you know, putting in, uh, to build pipeline, putting in container scanning in the build pipeline, so that you have to manually scan stuff, right to get rid of the basics. Is that a pen test? 100% no.

Um, but it gets rid of that, hey, you didn’t upgrade to, um, you know, this version of this library.

[00:21:00] That’s all automated, and those, the more systems you get in place, the more you as a security professional, or your security team will be able to focus on where they can really deliver value and frankly, where it’s more interesting work, so that’s what systems over people mean, is basically automate as much as you can to get people doing what people are really good at, and to make sure that the systems catch what we make as mistakes all the time.

If you accidentally try to push an old build out, you know that systems should stop that, if you push a build that hasn’t been checked by that container scanning or by, um, you know, it doesn’t have the appropriate security policy in place.

Systems should catch all that humans shouldn’t have to worry about it at all. That’s systems over processing. You saw that on the, uh, keys to success slide here. I’ll just pull it up. Um, you know, is that, that’s absolutely key.

Another question that we had, uh, was what we didn’t get into here, which was around the Well-Architected Framework. Now, this is a document that was published by AWS, uh, a number of years back, and they’ve kept it going.

They’ve evolved it and essentially it has five pillars. Um, performance, efficiency, uh, op- reliability, security, cost optimization, and operational excellence. Hey, I’ve got all five.

Um, and really [laughs] what that is, is it’s about how to take advantage of these cloud tools.

Now, AWS publishes it, but honestly it applies to Azure, it applies to Google Cloud as well. It’s not service specific. It teaches you how to build in the cloud, and obviously security is one of those big pillars, but it’s… so talking about teaching you how to make those trade offs, how to build an innovation flywheel, so that you have an idea, test it, uh, get the feedback from it, and move forward.

Um, and that’s really, really key. Again, now you should be reading that even if you are an Azure, or GCP customer or, uh, that’s where you’re putting your most of your stuff, because it’s really about the principles, and everything we do, and encourage people to build well, it means that there’s less security issues, right?

Especially we know that the number one problem is mistakes.

That leads to the last question we have here, which is about that, how can I say that cyber criminals, you don’t need to worry about them.

You need to worry about mistakes? That’s a good question. It’s valid, and, um, Trend Micro does a huge amount of research around cyber criminals. I do a whole huge amount of research around cyber criminals.

Uh, my training, by training, and by professional experience. I’m a forensic investigator. This is what I do is take down cyber crimes. Um, but I think mistakes are the number one thing that we deal with in the cloud simply because of the underlying complexity.

I know it’s ironic, and to talk about simplicity, to talk about complexity, but the idea is, um, is that you look at all the major breaches, especially around s3 buckets, those are all m- based on mistake.

There’ve been billions, and billions, and billions of records, and, uh, millions of dollars of damage exposed because of simple mistakes, and that is far more common, uh, than cyber criminals.

And yes, cyber crimes you have [inaudible 00:23:32] worry. You have to worry about them, but everything you’re going to do to fix mistakes, and to put systems in place to stop those mistakes from happening is also going to be for your pr- uh, protection up against cyber criminals, and honestly, if you’re the guy who runs around your organization’s screaming about cyber criminals all the time, you’re far less credible than if you’re saying, “Hey, I want to make sure that we build really, really well, and don’t make mistakes.”

Thank you for taking the time. My name’s Mark Nunnikhoven. I’m the vice president of cloud research at Trend Micro. I’m also an AWS community hero, and I love this stuff. Hit me up on social @marknca. Happy to chat more.

The post Cloud Security Is Simple, Absolutely Simple. appeared first on .

Automatic Visibility And Immediate Security with Trend Micro + AWS Control Tower

Things fail. It happens. A core principle of building well in the AWS Cloud is reliability. Dr. Vogels said it best, “How can you reduce the impact of failure on your customers?” He uses the term “blast radius” to describe this principle.

One of the key methods for reducing blast radius is the AWS account itself. Accounts are free and provide a strong barrier between resources, and thus, failures or other issues. This type of protection and peace of mind helps teams innovate by reducing the risk of running into another team’s work. The challenge is managing all of these accounts in a reasonable manner. You need to strike a balance between providing security guardrails for teams while also ensuring that each team gets access to the resources they need.

AWS Services & Features

There are a number of AWS services and features that help address this need. AWS Organizations, AWS Firewall Manager, IAM Roles, tagging, AWS Resource Access Manager, AWS Control Tower, and more, which all play a role in helping your team manage multiple accounts.

For this post, we’ll look at AWS Control Tower a little closer. AWS Control Tower was made generally available at AWS re:Inforce. The service provides an easy way to setup and govern AWS accounts in your environment. You can configure strong defaults for all new accounts, pre-populate IAM Roles, and more. Essentially, AWS Control Tower makes sure that any new account starts off on the right foot.

For more on the service, check out this excellent talk from the launch.

Partner Integrations

With almost a year under its belt, AWS Control Tower is now expanding to provide partner integrations. Now, in addition to setting up AWS services and features, you can pre-config supported APN solutions as well. Trend Micro is among the first partners to support this integration by providing the ability to add Trend Micro Cloud One – Workload Security and Trend Micro Cloud One – Conformity to your Control Tower account factory. Once configured, any new account that is created via the factory will automatically be configured in your Trend Micro Cloud One account.

Integration Advantage

This integration not only reduces the friction in getting these key security tools setup, it also provides immediate visibility into your environment. Workload Security will now be able show you any Amazon EC2 instances or Amazon ECS hosts within your accounts. You’ll still need to install and apply a policy to the Workload Security agent to protect these instances, but this initial visibility provides a map for your teams, reducing the time to protection. Conformity will start generating information within minutes. This information from Conformity will allow your teams to get a quick handle on their security posture and more with fast and ongoing security and compliance checks.

Integrating this from the beginning of every new account will allow each team to track their progress against a huge set of recommended practices across all five pillars of the Well-Architected Framework.

What’s Next?

One of the biggest challenges in cloud security is integrating it early in the development process. We know that the earlier security is factored into your builds, the better the result. You can’t get much earlier than the initial creation on an account. That’s why this new integration with AWS Control Tower is so exciting. Having security in every account within your organization from day zero provides much needed visibility and a fantastic head start.

The post Automatic Visibility And Immediate Security with Trend Micro + AWS Control Tower appeared first on .

Trend Micro Integrates with Amazon AppFlow

The acceleration of in-house development enabled by public cloud and Software-as-a-Service (SaaS) platform adoption in the last few years has given us new levels of visibility and access to data. Putting all of that data together to generate insights and action, however, can substitute one challenge for another.

Proprietary protocols, inconsistent fields and formatting combined with interoperability and connectivity hurdles can turn the process of answering simple questions into a major undertaking. When this undertaking is a recurrent requirement then that effort can seem overwhelming.

Nowhere is this more evident than in security teams, where writing code to integrate technologies is rarely a core competency and almost never a core project, but when a compliance or security event requires explanation, finding and making sense of that data is necessary.

Amazon is changing that with the release of AppFlow. Trend Micro Cloud One is a launch partner with this new service, enabling simple data retrieval from your Cloud One dashboard to be fed into AWS services as needed.

Amazon AppFlow is an application integration service that enables you to securely transfer data between SaaS applications and AWS services in just a few clicks. With AppFlow, you can data flows between supported SaaS applications, including Trend Micro, and AWS services like Amazon S3 and Redshift, and run flows on a schedule, in response to a business event, or on demand. Data transformation capabilities, such as data masking, validation, and filtering, empower you to enrich your data as part of the flow itself without the need for post-transfer manipulation. AppFlow keeps data secure in transit and at rest with the flexibility to bring your own encryption keys.

Audit automation

Any regularly scheduled export or query of Cloud One requires data manipulation before an audit can be performed.

You may be responsible for weekly or monthly reports on the state of your security agents. To create this report today, you’ve written a script to automate the data analysis process. However, any change to the input or output requires new code to be written for your script, and you have to find somewhere to actually run the script for it to work.

As part of a compliance team, this isn’t something you really have time for and may not be your area of expertise, so it takes significant effort to create the required audit report.

Using Amazon AppFlow, you can create a private data flow between RedShift, for example, and your Cloud One environment to automatically and regularly retrieve data describing security policies into an easy to digest format that can be stored for future review. Data flows can also be scheduled so regular reports can be produced without recurring user input.

This process also improves integrity and reduces overall effort by having reports always available, rather than needing to develop them in response to a request.

This eliminates the need for custom code and the subsequent frustration from trying to automate this regularly occurring task.

Developer Enablement

Developers don’t typically have direct access to security management consoles or APIs for Cloud One or Deep Security as a Service. However, they may need to retrieve data from security agents or check the state of agents that need remediation. This requires someone from the security team to pull data for the developer each time this situation arises.

While we encourage and enable DevOps cultures working closely with security teams to automate and deploy securely, no one likes unnecessary steps in their workflow. And having to wait on the security team to export data is adding a roadblock to the development team.

Fortunately, Amazon AppFlow solves this issue as well. By setting up a flow between Deep Security as a Service and Amazon S3, the security team can enable developers to easily access the necessary information related to security agents on demand.

This provides direct access to the needed data without expanding access controls for critical security systems.

Security Remediation

Security teams focus on identifying and remediating security alerts across all their tools and multiple SaaS applications. This often leads to collaborating with other teams across the organization on application-specific issues that must be resolved. Each system and internal team has different requirements and they all take time and attention to ensure everything is running smoothly and securely.

At Trend Micro, we are security people too. We understand the need to quickly and reliably scale infrastructure without compromising its security integrity. We also know that this ideal state is often hindered by the disparate nature of the solutions on which we rely.

Integrating Amazon AppFlow with your Cloud One – Workload Security solution allows you to obtain the security status from each agent and deliver them to the relevant development or cloud team. Data from all machines and instances can be sent on demand to the Amazon S3 bucket you indicate. As an added bonus, Amazon S3 can trigger a Lambda to automate how the data is processed, so what is in the storage bucket can be immediately useful. And all of this data is secured in transit and at rest by default, so you don’t have to worry about an additional layer of security controls to maintain.

Easy and secure remediation that doesn’t slow anyone down is the goal we’re collectively working toward.

It is always our goal to help your business securely move to and operate in the cloud. Our solutions are designed to enable security teams to seamlessly integrate with a DevOps environment, removing the “roadblock” of security.

As always, we’re excited to be part of this new Amazon service, and we believe our customers can see immediate value by leveraging Amazon AppFlow with their existing Trend Micro cloud solutions.

The post Trend Micro Integrates with Amazon AppFlow appeared first on .

The AWS Service to Focus On – Amazon EC2

If we run a contest for Mr. Popular of Amazon Web Services (AWS), without a doubt Amazon Simple Storage Service (S3) has ‘winner’ written all over it. However, what’s popular is not always what is critical for your business to focus on. There is popularity and then there is dependability. Let’s acknowledge how reliant we are on Amazon Elastic Cloud Computing (EC2) as AWS infrastructure led-organizations.

We reflected upon our in-house findings for the AWS ‘Security’ pillar in our last blog, Four Reasons Your Cloud Security is Keeping You Up at Night, explicitly leaving out over caffeination and excessive screen time!

Drilling further down to the most affected AWS Services, Amazon EC2 related issues topped the list with 32% of all issues. Whereas Mr. Popular – Amazon S3 contributed to 12% of all issues. While cloud providers, like AWS, offer a secure infrastructure and best practices, many customers are unaware of their role in the shared responsibility model. The results showing the number of issues impacting Amazon EC2 customers demonstrates the security gap that can happen when the customer part of the shared responsibility model is not well understood.

While these AWS services and infrastructure are secure, customers also have a responsibility to secure their data and to configure environments according to AWS best practices. So how do we ensure that we keep our focus on this crucial service and ensure the flexibility, scalability, and security of a growing infrastructure?

Introducing Rules

If you thought you were done with rules after passing high school and moving out of your parent’s house, you would have soon realized that you were living a dream. Rules seem to be everywhere! Rules are important, they keep us safe and secure. While some may still say ‘rules are made to be broken’, you will go into a slump if your cloud infrastructure breaks the rules of the industry and gets exposed to security vulnerabilities.

It is great if you are already following the Best Practices for Amazon EC2, but if not, how do you monitor the performance of your services day in and day out to ensure their adherence to these best practices? How can you track if all your services and resources are running as per the recommended standards?

We’re here to help with that. Trend Micro Cloud One – Conformity ‘Rules’ provide you with that visibility for some of the most critical services like Amazon EC2.

What is the Rule?

A ‘Rule’ is the definition of the best practice used as a basis for an assessment that is run by Conformity on a particular piece of your Cloud infrastructure. When a rule is run against the infrastructure (resources) associated with your AWS account, the result of the scan is referred to as a Check. For example, an Amazon EC2 may have 60 Rules (Checks) scanning for various risks/vulnerabilities. Checks are either a SUCCESS or a FAILURE.

Conformity has about 540 Rules and 60 of them are for monitoring your Amazon EC2 services best practices. Conformity Bot scans your cloud accounts for these Rules and presents you with the ‘Checks’ to prioritize and remediate the issues keeping your services healthy and prevent security breaches.

Amazon EC2 Best Practices and Rules

Here are just a few examples of how Conformity Rules have got you covered for some of the most critical Amazon EC2 best practices:

See how Trend Micro can support your part of the shared responsibility model for cloud security: https://www.trendmicro.com/cloudconformity.

Stay Safe!

The post The AWS Service to Focus On – Amazon EC2 appeared first on .

Smart Check Validated for New Bottlerocket OS

Containers provide a list of benefits to organizations that use them. They’re light, flexible, add consistency across the environment and operate in isolation.

However, security concerns prevent some organizations from employing containers. This is despite containers having an extra layer of security built in – they don’t run directly on the host OS.

To make containers even easier to manage, AWS released an open-source Linux-based operating system meant for hosting containers. While Bottlerocket AMIs are provided at no cost, standard Amazon EC2 and AWS charges apply for running Amazon EC2 instances and other services.

Bottlerocket is purpose-built to run containers and improves security and resource utilization by only including the essential software to run containers, which improves resource utilization and reduces the attack surface compared to general-purpose OS’s.

At Trend Micro, we’re always focused on the security of our customers cloud environments. We’re proud to be a launch partner for AWS Bottlerocket, with our Smart Check component validated for the OS prior to the launch.

Why use additional security in cloud environments

While an OS specifically for containers that includes native security measures is a huge plus, there seems to be a larger question of why third-party security solutions are even needed in cloud environments. We often hear a misconception with cloud deployment that, since the cloud service provider has built in security, users don’t have to think about the security of their data.

That’s simply not accurate and leaves a false sense of security. (Pun intended.)

Yes – cloud providers like AWS build in security measures and have addressed common problems by adding built in security controls. BUT cloud environments operate with a shared responsibility model for security – meaning the provider secures the environment, and users are responsible for their instances and data hosted therein.

That’s for all cloud-based hosting, whether in containers, serverless or otherwise.

Why Smart Check in Bottlerocket matters

Smooth execution without security roadblocks

DevOps teams leverage containerized applications to deploy fast and don’t have time for separate security roadblocks. Smart Check is built for the DevOps community with real-time image scanning at any point in the pipeline to ensure insecure images aren’t deployed.

Vulnerability scanning before runtime

We have the largest vulnerability data set of any security vendor, which is used to scan images for known software flaws before they can be exploited at runtime. This not only includes known vendor vulnerabilities from the Zero Day Initiative (ZDI), but also vulnerability intelligence for bugs patched outside the ZDI program and open source vulnerability intelligence built in through our partnership with Snyk.

Flexible enough to fit with your pipeline

Container security needs to be as flexible as containers themselves. Smart Check has a simple admin process to implement role-based access rules and multiple concurrent scanning scenarios to fit your specific pipeline needs.

Through our partnership with AWS, Trend Micro is excited to help ensure customers can continue to execute on their portion of the shared responsibility model through container image scanning by validating that the Smart Check solution will be available for customers to run on Bottlerocket at launch.

More information can be found here: https://aws.amazon.com/bottlerocket/

If you are still interested in learning more, check out this AWS blog from Jeff Barr.

The post Smart Check Validated for New Bottlerocket OS appeared first on .