DEV Community: Sena Yakut

AWS re:Invent 2023: Security Session Notes 📝

Sena Yakut — Sat, 02 Dec 2023 22:04:35 +0000

AWS re:Invent 2023 is completed in Las Vegas. I’ve watched some security-focused sessions and announcements online and I want to share my notes with you. I hope you will enjoy it! Let’s start! 🥰

🧐 Sessions that I’ve recommended:

💁‍♀️ Move fast, stay secure: Strategies for the future of security (SEC237):
In this innovation talk, we start with “Security is a people issue. Computers do not attack each other.”

Security operations like playing chess, we need to predict the attackers’ actions. In this game, technology and humans are together.
Human and AI. We need both of them for better security. AI increases work efficiency, but we still need people to decide. AI cannot decide. We need talented engineers to decide.
In the cybersecurity area, we have a talent gap. Security knowledge is not enough, we need engineers who understand the organizational logic of the company. With the AI popularity, we have lots of concerns and lots of to-dos as security professionals. You should ask yourself and your environment if you’re building your app with AI or build AI: “Where is my data?”, “What happens with my query and any associated data?”, “Is the output of these models accurate enough?” From AWS's perspective = “Your data is your data.”

💁‍♀️ Elevate your security investigations using generative AI (SEC244):

In this session, we learn about Amazon Detective and the newest announcements. There are 3 different challenges in security investigations and we can solve them with Amazon Detective:

Analysts cannot review every high-priority security issue.
Shortage of skilled security professionals.
Increasing cost and complexity with investigating potential security findings.

Amazon Detective collects security logs from different services and analyzes them with different ML algorithms.

We have a new feature called “Finding Group Summary”. With this feature, the findings are summarized with correlated behaviors and are more understandable.
Another one is integration with Security Lake for root cause analysis. Amazon Detective uses the prepared queries or tunes them to meet the specific security needs of any investigation.

In the session, we also have an example scenario that we can analyze with Detective. It helps us to understand the use cases and new features in detail.

If you want to use Amazon Detective for your workloads, this is the pricing.

💁‍♀️ Amazon S3 security and access control best practices (STG315):

In this session, I felt like I was taking a security specialty exam course, and liked it. We saw lots of different usages of different approaches to secure our S3 buckets.

Firstly, we should know AWS S3 is secure by default: Encryption (SSE-S3) by default, S3 blocks public access enabled by default, and S3 ACLs are disabled by default. In the S3 access management process, it’s important to understand IAM (obviously), bucket policies, and conditions.
For access management, AWS recommends not using ACLs anymore. If you want to track your ACL usage, you can use S3 Inventory reports, CloudTrail, and S3 access logs.
For encryption, AWS has different options for our objects. This cool table summarizes it. You can choose the best option for your regulatory and security needs.
If you have strict regulatory needs about your data, consider dual-layer server-side encryption. All details are here.
If you want to decrease your costs of encryption/decryption processes, you can use S3 bucket keys. The logic is simple here: In the first request, we’re going to request to KMS, in Nth requests, we’re going to S3 bucket keys that are time-limited within Amazon S3. It also works with multi-tenant environments.
If you want to simplify the security management for S3, you can use S3 access points. Each S3 access point has its own DNS name and point policy. NEW: S3 Access Grants: And wow, we have a new access control mechanism. You can define granular access to your Amazon S3 data based on applications, personas, groups, or organizational units.

💁‍♀ ️Governance and security with infrastructure as code (DOP209):

This is a developer-focused talk. We can learn how to catch issues early with cdk-nag, validate your pipelines with cfn-guard, and protect your accounts from unintended changes with CloudFormation hooks.

💁‍♀️ Safeguarding infrastructure from DDoS attacks with AWS edge services (NET201):

Interesting session about DDoS attacks and mitigation tactics.

💁‍♀ ️Streamlining security investigations with Amazon Security Lake (SEC234):

We heard about Amazon Security Lake in re: Invent 2022. In this session, we will gain visibility for comprehensive security investigations and swift incident responses in hybrid environments.

💁‍♀ Centralize user activity from external sources in AWS CloudTrail Lake (COP341):

This is a quick demo session and I like it. We will learn how we can use AWS CloudTrail Lake to centralize user activity from external sources in one place.

🧐 Announcements that I’ve noted:

- Integrating Amazon Inspector scans into your CI/CD pipeline: You can use Amazon Inspector as your scanner for your images. It’s an important update for DevSecOps.

- IAM Access Analyzer now simplifies inspecting unused access to guide you toward the least privilege: We love the “at least privilege principle”. As you know, it’s hard to provide an audit of this in all AWS accounts. AWS IAM Access Analyzer now simplifies inspecting unused access. Note: Please read the pricing guide before you start to use this.

- Amazon Inspector agentless vulnerability assessments for EC2 (preview): Amazon Inspector now offers continuous monitoring of your Amazon EC2 instances for software vulnerabilities without installing an agent or additional software. You can use this feature within the hybrid mode.

- Introducing Amazon GuardDuty ECS Runtime Monitoring, including AWS Fargate: Your first to-do in an AWS account, enable GuardDuty. In containerized environments, it’s important to add threat intelligence for it. AWS announces Amazon GuardDuty ECS Runtime Monitoring, an expansion of Amazon GuardDuty that introduces runtime threat detection for Amazon ECS workloads — including serverless container workloads running on AWS Fargate.

- Amazon Inspector expands AWS Lambda code scanning with generative AI-powered remediation: For the reducing time to fix it’s an important update. AWS includes assisted code remediation using generative AI and automated reasoning to Amazon Inspector. Note: I’ve tested this feature and got some errors about it. I’ll reach out to the support team.

- AWS Config launches generative AI-powered natural language querying (preview): We can ask questions like: “Show me all non-compliant S3 buckets in my organization.” It simplifies the investigation and search of AWS resource configurations and changes for our resources.

- AWS announces CloudWatch Logs Anomaly Detection and Pattern Analysis: Anomaly detection is important for our production workloads. Using these new features, we can identify unusual events, and use these accelerate our investigation.

- Amazon Detective announces investigations for IAM: Amazon Detective provides an investigation of AWS IAM entities for anomalies. This new capability helps us determine whether IAM entities have potentially been compromised or involved in any known scenarios.
- You can now customize security controls in AWS Security Hub: We always need customization based on our environments for security posture management. With custom control parameters, Security Hub evaluates the control against the value that we specify. There are some customization examples from AWS:
*[CloudWatch.16] — CloudWatch log groups should be retained for a specified period: You can specify the retention period.
*[IAM.7] — Password policies for IAM users should have strong configurations: You can specify parameters related to password strength
*[EC2.18] — Security groups should only allow unrestricted incoming traffic for authorized ports: You can specify which ports are authorized to permit unrestricted incoming traffic.
*[Lambda.5] — VPC Lambda functions should operate in multiple Availability Zones: You can specify the minimum number of Availability Zones that produce a passed finding.

- Amazon CodeWhisperer offers new AI-powered code remediation, IaC support, and integration with Visual Studio: We love the shift left principle as DevSecOps engineers and security professionals. With an AI-powered code remediation feature, it provides generative AI-powered code suggestions to help remediate identified security and code quality issues. Fix before exist.

Thanks for reading! Stay secure in the cloud! 🌤

🎆Party Time: Your Security Supporters with PartyRock

Sena Yakut — Sun, 19 Nov 2023 10:42:21 +0000

PartyRock is announced on 16th November, as an Amazon BedRock Playground. You can build your generative AI-based applications without writing any code. It’s cool because people who don’t know writing code can also use generative AI with this.

For a limited time, we can use PartyRock in a free trial without the need to provide a credit card or sign up for an AWS account, so that we can begin learning fundamental skills without the worry of costs.

As a security professional, I’ve decided to use PartyRock for my security interests. I’ve created 5 different applications, let’s see all of them!

🧠Secure Code Studio:
Writing codes based on security best practices is an important topic for your static code security. This app will generate secure code snippets and validate them against best practices. You need to add programming language and code details. After that application generates code and recommendations for you.

Also, you have already code parts and if you’re not sure if your code is secure or not, you can check from my Secure Code Studio.

🦸‍♀️Application Security Assistant:
We’re developing, maintaining, and using lots of different applications every day. For the application security side, we need to think of lots of details. This assistant allows you to discuss application security with an AI. Provide details in the input below, and the assistant will analyze and make recommendations. Provide details in the input below, and the assistant will analyze and make recommendations. If you want, you can chat and get details about your environment. For example, I asked for vulnerability management for my mobile applications and the assistant sent me the recommendations, and example tools that I can use.

🏃‍♂️Cloud Security Coach:
In this application, you will meet your personal cloud security mentor! You can ask whatever you want related to cloud security for different cloud providers. I think it can be important in your daily work or certificate exams as a quick reminder.

👩🏻‍💼Cloud Security Interview Assistant:
Before your cloud security-related interviews, this cool interviewer helps you with all processes. You can chat with the AI according to the questions. Also, it may help you interview in English.

☄️IconGen: Security-themed Icon Generator for Blogs:
When I write a blog, I struggle to choose a unique icon according to my blog topics. This icon generator will help us create custom icons for our security blog posts and articles. Just enter some keywords below and it will generate a relevant icon image.

Thanks for reading! Stay safe in the cloud! 🌩️

Understand Amazon GuardDuty Findings

Sena Yakut — Wed, 01 Nov 2023 07:59:00 +0000

Amazon GuardDuty is a threat detection service that continuously monitors our AWS accounts and environments for malicious activity and delivers all details. When you create an AWS account, it is strongly recommended to enable this cool service. It’s very easy to enable and use. In this blog, after we have enabled Amazon GuardDuty, we will discuss what we should do with the findings and how we know we’re in danger. Let’s start together!

1) Create alarms for the findings: If you’re enabled Amazon GuardDuty, it does not send you the findings alerts automatically. You need to implement a flow for your workload. You can use CloudWatch alarms or 3rd party solutions for this. It’s very important to do this, you cannot monitor GuardDuty findings every minute of every day, it’s impossible. You can see the instructions here.

2) Prioritize with the severity: GuardDuty has default severity for every finding. But it can be different for your environment. You need to understand the findings and impact clearly and prioritize for yourself. There are some examples of it:

- Policy: IAMUser/RootCredentialUsage: This finding’s default severity is low. But if it’s not expected from your side, it can be very critical for you. Your root credentials can be compromised and you need to take action about it. We still need to prioritize this finding from our perspective.

- Exfiltration: S3/AnomalousBehavior: This finding’s default severity is high. For this, you need to analyze the S3 bucket details. Does it have the important objects or not? Test or prod environment? Who can access this bucket normally? What is the anomalous behavior? Do we expect this? After answering them, maybe you can decrease the severity of the finding.

3) Check the actor and action: The actor, included in GuardDuty details, means the one carrying out suspicious activity. You should check and verify the actor's details. We need to know who did what and when it happened. For example, there is an IP that uses aws-cli and GetObject operation to our S3 bucket.

We need to check the IP's reputation and whether malware activities are reported or not from this IP. You can use VirusTotal and other solutions for this.

If you want, you can automate this check with the APIs of VirusTotal and send notifications to yourself if the IPs are malwared. You can also automate the blocking process of these IPs from your using AWS resources such as NACLs, bucket policies, etc.

4) Control the resource logs: After checking action and actor, checking your resource logs can be very helpful in detecting some details about the threat. For example, let’s assume you have a Lambda service that accesses your S3 bucket, and the finding is related to that bucket. If you’re logging some details about the incoming requests, you can get them from CloudWatch and analyze them. Also, if you have enabled the VPC logs, ELB, or S3 access logs, you can also get details from them, which operations are blocked from the suspicious IP, which operations were rejected or allowed what endpoints were called, etc. We can clearly say logging is a serious thing for your security, in many ways.

5) Check your activities: It’s important to know what happens in your environment. Maybe one of your team members login the AWS account from vacation and GuardDuty detected this IP as an anomaly. Or maybe you have a test bucket that only your intern can access and she tries something and GuardDuty detects the different API calls as an anomaly, again. Before you panic, communicate with your team members. Visibility is everything.

6) Start malware scan: GuardDuty automatically starts a malware scan after generating a finding indicative of malware in your EC2 instance or a container workload. Also, you can start a malware scan if you suspect something or just to be sure. You can use your EC2 instance ARN for this.

If the malware is detected, it’s important to get a snapshot of the resource to analyze. You should enable this option if you’re not enabled yet:

7) Get an action: If you complete all the steps and there is a real threat, please get an action. Every resource has different actionable points, you need to check all of them. If this is an expected behavior in your environment, you can archive the findings and sleep well.

Thanks for reading! Stay safe in the cloud! 🦸🏻‍♀️

Your Daily CVE Reminder 🦸🏻‍♀️

Sena Yakut — Sat, 14 Oct 2023 07:17:14 +0000

Common Vulnerabilities and Exposures (CVE) lists publicly disclosed security vulnerabilities and exposures. Every day, there are lots of vulnerabilities published and it’s hard to track all of them. We need to know what the critical/high ones are, whether are we affected, what should we do, etc. To achieve this, we will construct a daily reminder mechanism for critical and high CVEs using Slack and AWS Serverless technologies. If you’re using Slack I highly recommend integrating this as soon as possible. If you’re not, you can update the code easily with other notification channels, still highly recommended. You can get all the code from here. Let’s start together!

🫀 AWS Services & Technologies that we’ve used:

AWS CDK
AWS Lambda
Amazon EventBridge
Slack Webhook
NIST Vulnerability API, you can reach from here.

👩🏻‍💻 In our CDK code, I want to explain some parts that can you understand and update easily. In lib/cve-daily-reminder-lambda.ts we’re creating Lambda function and EventBridge rule. I set the reminder schedule as every day at 8 AM with UTC+3. If you want to change, you need to do this from this code. Also, you need to add your Slack Webhook URL in there. If you don’t know how to generate your webhook URL, you can check here.

import {Stack, StackProps, Duration} from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';

export class CveDailyReminder extends Stack {

  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id);

    const myLambda = new lambda.Function(this, 'LambdaFunction', {

      environment: {
        SLACK_WEBHOOK_PATH: '',  //add your SLACK_WEBHOOK_PATH here.
      },
      runtime: lambda.Runtime.NODEJS_LATEST, 
      code: lambda.Code.fromAsset('lib/lambda'),  // directory containing your Lambda code
      handler: 'index.handler',
      timeout: Duration.minutes(15) 
    });


    const rule = new events.Rule(this, 'Rule', {
      schedule: events.Schedule.cron({ 
        // Scheduled to run every day at 8 AM Turkey time (UTC+3)
        // Note: CloudWatch cron uses UTC time
        minute: '0',
        hour: '5', // 5 AM UTC is equivalent to 8 AM Turkey time (UTC+3)
        day: '*',
        month: '*',
        year: '*',
      }),
    });

    // Add the Lambda function as the rule's target
    rule.addTarget(new targets.LambdaFunction(myLambda));


  }
  }

In our Lambda code logic, we will only get Critical and High CVEs for now. If you want you can customize the logic and get all of them. Lambda source code in lambda/index.mjs file:

      if (jsonData.vulnerabilities && Array.isArray(jsonData.vulnerabilities)) {
          const extractedData = jsonData.vulnerabilities.map(cveObj => {
            const { id, vulnStatus, descriptions, references, metrics } = cveObj.cve;
            const description = descriptions.find(desc => desc.lang === "en")?.value || 'Description not available';
            const baseScore = metrics?.cvssMetricV31?.[0]?.cvssData?.baseScore;
            const baseSeverity = metrics?.cvssMetricV31?.[0]?.cvssData?.baseSeverity;
            if (baseScore && baseSeverity) {
              return {
                cveId: id,
                vulnStatus: vulnStatus,
                description: description,
                baseScore: baseScore,
                baseSeverity: baseSeverity,
                references: references.map(ref => ref.url),
              };

            }
            return null;
          }).filter(item => item);
          const highAndCritical = extractedData.filter(item =>
            item.baseSeverity === 'HIGH' || item.baseSeverity === 'CRITICAL');

          highAndCritical.forEach(item => {

            let text = '';
            const firstSentence = getFirstSentence(item.description);
            text += `:large_red_square: *CVE ID*: ${item.cveId}\n*Base Score*: ${item.baseScore}\n*Base Severity*: ${item.baseSeverity}\n*Description*: ${firstSentence}\n*References*: ${item.references.join(', ').substring(0, 3000)}\n\n`;

            sendToSlack(text);

          });
        }

Notes for updates in Lambda: Slack webhooks are expecting a JSON type that you need to send. If you don’t send this, you will get errors. You can get all the details from there.

After deploying the solution with AWS CDK, you can get daily CVEs and details in your Slack channel successfully.

We need to review all of them daily. If our systems are affected, we need to take action about it. Stay safe! 🤞

Understanding Container Security

Sena Yakut — Fri, 21 Jul 2023 06:35:16 +0000

Containerized architectures are one of the most popular technologies for developers. There are many advantages to migrating to the containers, I think the most important advantage is flexibility. You can build your Docker images and containers only once, and deploy wherever you want. In addition to this advantage, there are also lots of security challenges. Many attack surfaces surround your container environment if your container structure has lots of security misconfiguration and vulnerabilities. While being very flexible, you may encounter attackers and lots of exploit scenarios in your containers.

Container security has lots of aspects. As security professionals, these are our responsibilities in a container environment:

Secure your codebase
Secure your app
Secure all libraries that you’ve used
Secure your network/communication
Secure your CI/CD processes

In this blog, we will talk about container security challenges and what should you do about them. Let’s start together! ✍️

Container Security Challenges

1) Vulnerability Overload 🥴: There are lots of vulnerabilities in different layers in a container image or containers in runtime. Developers are confused about the prioritization of these vulnerabilities, how to fix them without any functional errors, and who is responsible for remediating them. Prioritization is important because if you have 100 critical vulnerabilities in a container cluster, you need to know which are the most critical ones. At this point, analyzing the vulnerability scan results is an important task for you.

2) Container security is challenging 😮: There are a lot of layers and aspects in a container such as networking, codebase, and libraries that are used, etc. We need to know all details about all of these topics and you need to get action about them. Also, if there is a vulnerability in a container system, you need lots of information about some questions like: “What is the exact vulnerability scenario in there?”, and “How is this vulnerability affect our system?”.

3) Difficulty in Integration 🧗🏻‍♀️: There are lots of scanning, vulnerability management, and alerting tools about container security. In your company, you need to decide what is the best tool for managing your container environment. In addition to this, you need to think about our CI/CD pipeline and at which point you need to integrate these tools in order to be protected.

✨ Security Points of Containerized Design ✨
As we mentioned before, you should think of every potential attack vector at each stage of a container’s lifecycle.

1) 🤔Vulnerable Application Code: Lots of code parts are added to a container environment in your daily work. You’re using lots of libraries, third-party codes, and our business logic codes. You need to be careful about secure code best practices when you’re writing your application code.

You need to follow OWASP guides about secure code design.
You need to scan your code with SAST tools like SonarQube, Veracode, etc. These tools help to understand the security of your code.
Scanning your container images for vulnerabilities is a good approach. But this scanning is not one time job, it should be done regularly (weekly, monthly, etc.) You need to follow vulnerability reports and fix all of the vulnerabilities as soon as possible. I recommend some open-source tools that could be useful: Trivy, Docker-Bench, Grype.

2) 🤔 Badly Configured Container Images & Containers: If an attacker is able to modify the Dockerfile, it’s possible for them to take malicious actions such as adding malware or crypto-mining software into the image, accessing build secrets and privilege escalation, etc. These are very dangerous activities for container systems. To prevent this, we need to write our Dockerfiles with security best practices. Here are some best practices that I’ve recommended:

You should use an image from a trusted registry. Please do not use any base images that are not verified, or built by someone that you do not know. Attackers love this way to catch you.

You should use smaller base images for your infrastructure. When you use the smaller one, you have less unnecessary code and a smaller attack surface.

Please do not be root and run any code with root in your Dockerfile. You should always define a user with at least a privilege approach. Root users are always critical to us.
Remote code execution scenarios are critical for containers. You should check your RUN command to prevent running the codes that you don’t have or attackers can. You should audit your RUN command logs regularly. Also, access control is critical at this point. You need to clarify and define which users in your system have the change RUN command.

For your Dockerfiles, you can also scan them. There are lots of tools that can check your Dockerfiles. They will validate if Dockerfile is compliant with Docker best practices such as not using root user, making sure a health check exists, and not exposing the SSH port. You can use Snyk and Checkov.

3) 🤔Exposed Secrets: Exposed secrets are a nightmare for us. As in every environment, we’ve mentioned “Please do not hardcode your credentials.” You should not store sensitive data in different layers in your containers. You think if you’re using the remove command everything is fine, but believe me, it’s not. Your credentials are still in layers and docker history and attackers can get these credentials by reversing your container image. To prevent exposure, you should rotate & encrypt your secrets regularly, not store them in .env files and you can use secret management tools like Vault.

4) 🤔Image Storage Security: We’re using AWS ECR, DockerHub as image storage. While you’re using and pushing your images, you need to be sure these are not publicly accessible. Attackers love founding publicly accessible Docker images, reversing them, and getting all your system details, credentials, etc. Also, to ensure your docker data integrity and docker content trust, your Docker images should be signed and verified on runtime. We don’t want to use images that attackers changed and pushed our docker storage area.

Access control is a critical topic there. You need to decide which users in your company should access which Docker images with which access roles. You should check your image tags and YAML files before running them in your production cluster. You should be aware of everything about your Docker images.

5) 🤔Insecure Networking: Every external attack reaches your container deployment across a network area. So you need to implement a strong secure network infrastructure for your containers. You need to implement a VPC, default deny mechanism on NACLs, security groups, and firewalls. You should restrict your container ports wherever possible. For network traffic, you always think of using Web Application Firewall (WAF) solutions. WAF helps to prevent lots of attacks such as RCE, SQL injection in addition to network layer attacks. And as you know, you need to always use TLS for your encrypted traffic. Attackers love HTTP, not HTTPS.

Thanks for reading! Stay safe in containers! 👻

Remotely Connect to Your Instances without a Public IP Address

Sena Yakut — Wed, 28 Jun 2023 08:06:10 +0000

We’re using bastion hosts to connect our EC2 instances via SSH or RDP for years. Using these hosts causes operational challenges (updates, additional configurations, audits, etc.) and additional costs. In addition to hosts, AWS has two different solutions to connect your instances. The first solution is AWS Instance Connect, but we need a public IP address to use it. The second solution is System Manager, but we need agent-based connectivity.

🌹 From now on, we’re able to use EC2 Instance Connect for all remote connections without public Ips, Internet Gateways, and bastion hosts.

EC2 Instance Connect combines authorization with IAM restrictions and network controls with security group rules. This feature is also auditable with AWS CloudTrail. Today, we will configure and understand the EC2 Instance Connect Endpoint step by step. Let’s start together! ⛅️

Step 1: IAM Permissions to use EC2 Instance Connect Endpoint
First of all, to create an EC2 Instance Connect Endpoint, you need these permissions:

ec2:CreateInstanceConnectEndpoint
ec2:CreateNetworkInterface
ec2:CreateTags
iam:CreateServiceLinkedRole

You can do some restrictions about EC2 Instance Connect remote port, your EC2 private IP address, or tunnel duration that we’ve built between EC2 Instance Connect and your instance. You can see all example policies and scenarios that are related to IAM from here.

Step 2: Security Groups Configurations

For the EC2 Instance Connect Endpoint, AWS recommends outbound rule should allow outbound traffic to the specified destination (specific security group of your EC2 instances).
For your resources, if the preservation of client IP is set to false in the EIC configuration, you should allow inbound traffic from the EIC security group and inbound traffic from the VPC CIDR. For other preservation issues, you can check this documentation.

Step 3: Create EC2 Instance Connect Endpoint
For creation, you should VPC à Endpoints and select “Create Endpoint”. Your endpoint and resources should be in the same VPC.

You should select private subnet and the security group that you’ve created. If you select subnet in different availability zone from your resources, additional data transfer costs can occur.

After that, you need to wait until the status is “Available”. You can create 1 EC2 Instance Connect Endpoint per VPC & per subnet.

Step 4: Connect your EC2 Instance
From AWS Console, you need to select EC2 Instance Connect Endpoint.

We got a successful connection!

From our client, you can use this command:

ssh -i ‘key_file’ ubuntu@instance_id -o ProxyCommand=’aws ec2-instance-connect open-tunnel — instance-id instance_id’

We got successful connection again!

🫠 Advantages of using EC2 Instance Connect Endpoint:

We do not need agent configuration.
We do not need publicly accessible resources.
We can audit all connections via AWS CloudTrail.
No additional cost, we only pay for the data transfer.

Thanks for reading! Stay safe in the cloud! 👻

Use Amazon CodeWhisperer for Your AWS Security

Sena Yakut — Sun, 16 Apr 2023 17:52:36 +0000

Amazon CodeWhisperer is an AI code service that provides real-time code suggestions in your Integrated Development Environment (IDE) to help you quickly write your code. On April 13th, Amazon CodeWhisperer is generally available. There are two tiers, Individual and Professional. For the Individual tier, it’s free to use 🧐, and easy to integrate and I recommend enabling this cool service in your IDE if you did not yet. If you’re using the Individual tier, you can get code recommendations, reference tracking, and security scans for your project. You can use Amazon CodeWhisperer with Python, Java, JavaScript, TypeScript, C#, Go, Rust, Kotlin, Scala, Ruby, PHP, SQL, C, C++, and Shell Scripting.

Today, I will show you some code generations example to secure your AWS account easily with this cool code generator. Let’s start together!😵

Setup Your Account

1) I’ll use Visual Studio Code in this blog however, Amazon CodeWhisperer can be integrated with JetBrains, AWS Cloud9, and AWS Lambda. If you don’t have AWS Toolkit in your VSCode, you need to install it in the extensions part. If you already have, you need to be sure it’s up to date.

2) After that, I’m choosing AWS Builder ID connection, it’s also free and you do not need to have an AWS account for this.

3) We will get authorize request panel.

4) And we need to accept AWS Toolkit for VSCode to access our data!

After all steps, you can use Amazon CodeWhisperer suggestions in your IDE. 👻

Use CodeWhisperer as AWS CIS Recommender

The CIS AWS Foundations Benchmark provides lots of security configurations and best practices for our AWS environment. It’s important to know the issue and remediate and automate remediation related to CIS Benchmarks. There are lots of tools, integrations, and scripts for CIS Benchmark and you can use that. But if you do not want to use this, you already do not know the processes on this and you want to get all the control, you can write your own CIS Benchmark controller. For this process, we’re using Amazon CodeWhisperer.

I’ll choose some random controls from CIS Benchmark v1.5.0. You can see all controls from here.

1) Ensure multi-factor authentication (MFA) is enabled for all IAM users

MFA is important for your all accounts. We also check this in our AWS Account. When I say something about this process to Amazon CodeWhisperer, it generates for me.

2) You need to check that the AWS IAM user key age is greater than 45 days or not

It is recommended that all credentials that have been unused for 45 or greater days be deactivated or removed. They can be used for bad activities in your account. Let’s try this control.

3) MFA should be enabled for the ‘root’ user account

The ‘root’ user account is the most privileged user in an AWS account. It’s so important to enable MFA in this account. I’m writing to VSCode from the AWS CIS Benchmark document.

This is from the CIS Benchmark:

And this is from us:

4) Ensure AWS Config is enabled in all regions

AWS Config is a web service that performs configuration management and logging changes. It’s recommended to enable it.

5) Ensure CloudTrail logs are encrypted at rest using KMS CMKs.

We love encryption in AWS. It is recommended that CloudTrail be configured to use SSE-KMS. I’m converting AWS CIS Benchmark controls to a sentence and explain to AWS CodeWhisperer as much as I can.

After all of that, let’s run our functions!🙀

Use CodeWhisperer as Code Scanner

Static code scanning is important in your CI/CD pipeline and DevSecOps processes. After the security scanning is finished with CodeWhisperer, security issues in the scanned files are highlighted in the problems panel. Let’s try this with a vulnerable command injection attack code scenario from SonarQube Library.

We can easily see this issue has been found by AWS CodeWhisperer.

I strongly recommended using the security scan module for your IDE. It finds your security vulnerabilities before you go to 🧠production🧠.

Thanks for reading! Stay safe in the cloud! 🤞 ⛅️

Hacking AWS Account via AWS Lambda SSRF

Sena Yakut — Wed, 29 Mar 2023 03:27:37 +0000

Server-side request forgery (SSRF) attack is used for abusing functionality on the server to read or update internal resources. The main idea behind an SSRF attack is to manipulate the input parameters of an application that interact with external systems, such as URLs, IP addresses, or file paths. By injecting a special URL that is important for internal systems, an attacker can force an application to access an internal resource that is not intended to be exposed. Besides SSRF is very dangerous for traditional web applications, it’s also a threat for cloud resources. Today, we will see an example SSRF scenario on AWS Lambda and how it can be dangerous for your AWS environment. Let’s start together!

AWS Lambda SSRF Scenario:
1-) Let’s assume that we’ve a sample webpage that we will upload our contents to apply a job opportunity.

2-) We need to review the source code of the page. It includes a request to API Gateway endpoint to upload our CV.

3-) Let’s try to call the same API endpoint on Postman or Burp Suite. This is an expected usage of the API. But we think there is a problem to read the pdf files content because body message is not completed. But we assume the cv file is tried to read (this is a file operation). So, we can try SSRF and get some data if we are lucky. But how can we do this on AWS API Gateway / AWS Lambda?

4-) In AWS Lambda, AWS credentials are stored in environment variables. To get them, you need to access a path like file:///proc/self/environ. We can try:

After we’ve tried with /proc/self/environ, we get lots of details!! Let’s analyze the response.

5-) There are lots of AWS credentials. As you see, we get DB username, password, and hostname but we have also AWS credentials. Let’s extract them and use in an AWS profile.

6-) We’ve created the AWS profile.

7-) You need to use get-caller-identity function to return details about the IAM user or role whose credentials are used to call the operation.



aws sts get-caller-identity — profile <your-profile>

8-) We need to know the policies that are attached to this AWS Lambda role.



aws iam list-attached-role-policies — role-name <role-name> — profile <your-profile>

9-) Yes, we get administrator access! 🤯 We can create an IAM user via AWS CLI.



aws iam create-user — user-name <username> — profile <your-profile>

10-) You should create login profile with password.



aws iam create-login-profile — user-name <username> — password <my-password> — profile <your-profile>

11-) We need to attach administrator policy to this user.



aws iam attach-user-policy — policy-arn arn:aws:iam::aws:policy/AdministratorAccess — user-name <username> — profile <your-profile>

12-) We’ll able to access the account with administrator rights! That’s all! 🤭 🤫

Preventions / Recommendations:

Validate every input.
Always follow at least privilege principle in AWS IAM roles.
Add authentication & authorization to your public API endpoints.
Blacklist/Prevent Unused URL Schemas (like file://)
For other details, please see OWASP Cheat Sheet.

Thanks for reading! Stay safe in the cloud! 🤞 ⛅️

Passing AWS Security Specialty Exam — My Tips and Notes

Sena Yakut — Sun, 05 Feb 2023 17:24:20 +0000

I recently passed the AWS Security Specialty exam and want to share my experiences, study resources, and process with you. I hope these tips will help you to pass your exam. Let’s start together!

This cool exam takes 170 minutes.
It costs 300 USD. If you have any coupons/vouchers, you can use this.
The exam includes 65 questions with multiple choice or multiple responses.
You can attend the exam via Pearson Vue testing center or online proctored.
AWS recommends five years of IT security experience in designing and implementing security solutions and at least two years of hands-on experience in securing AWS workloads. But this is only a recommendation, not an obligation. You can still prepare for the exam.
You need to know AWS like a solution architect. So, it’s important to get AWS Solutions Architect certificates before this exam.

Read the AWS Documentation about the Exam

If you decide to take this certificate, you first need to read AWS documentation about the exam. These documents include general information about the exam, its scope, and some sample questions. For sample questions, I solved them on the first day of my study schedule and after that, I also solved them before the exam day. It helps you to understand your progress.

For the exam guide, you can use this.
For the sample questions, you can use this.

In addition to this, it’s important to know “AWS Well-Architected Principles”. It helps us build secure, high-performing, resilient, and efficient infrastructure for our workloads. The security side is important for this exam. You can read the security pillar whitepaper.

Use AWS Training Module

This module is so helpful for starting your certification process. This is not for just the Security Specialty, there are lots of training videos, documents, and exams to help your cloud journey or other certifications. The following ones that I’ve used in my process:

Also, there are Cloud Quests that help you build practical AWS Cloud skills. I’ve solved the Security and Solution Architect badges, but they require a subscription. You can read more about it here.

Use Video Resources

For this exam, there are not so many video resources like full courses. But I can recommend some videos that saved me.

For AWS IAM: Become an IAM Policy Master in 60 Minutes or Less (I watched this twice)
For AWS KMS: AWS #KMS — Key Management Service — Customer Master Key, Data Key, Envelope Encryption (This is a clear explanation, but you must read new AWS documents. There are some changes in AWS KMS like multi-region support.)
AWS Well-Architected: AWS re:Invent 2022 — AWS Well-Architected Framework security pillar: Cloud security (This is from the latest re:Invent)
AWS Security Reference: AWS re:Invent 2022 — Revitalize your security with the AWS Security Reference Architecture

Practice with Example Questions

Practicing is always important. There are lots of questions in different places but I’ve seen there are lots of wrong or old responses (AWS changes lots of services or adds details every year.) So, it’s important to get clear and right exam samples. For me, the most useful ones are AWS training module questions and Whizlabs. There is a free test if you want to check. Feel free to solve this if you want to decide to buy the tests. If you buy it, there are four full exams with unique exam practice questions.

Which AWS Services should You Know Mostly?

This is a general and challenging security exam, so you should know all of AWS security services mostly. But from my experience strongly recommend you need to know AWS KMS, AWS IAM, AWS Organizations, and AWS networking and logging and monitoring concepts and services such as AWS CloudTrail, AWS VPC Flow Logs, etc. in all aspects. Before the exam, you need to read all whitepapers about all security services. You can take some small notes to remember anything quickly. And it’s also important to do some practice labs about all of them. It’s more important to practice something than just read it.

My Personal Comments & Suggestions for You

I have other AWS certificates, but I think this is one of the most challenging. I’m working as Cloud Security Engineer, and I know the general cyber security and cloud security concepts since university, but in the exam, there are lots of focused and long questions about AWS security services.

Lots of the questions include multiple responses with example scenarios so I think it’s important to use these services in your work or training process. You need to practice with every security service in AWS.

If you do not know general security concepts, you should learn all of them such as encryption & hashing methods, algorithms, and encryption in transit/rest concepts.

For the studying process, I strongly recommend solving all test questions again and again. You should ensure to know all the questions in the example exams. I’m not saying memorize everything. You need to know why we select this option. You need to know all concepts.

In the exam, always think worst-case scenario. Some questions ask you about “cost optimization or highly available architecture”. But when you’re selecting this, you do not want to be hacked. So please ensure that you select the most secure option with other conditions.

Some questions are more challenging than others. If you do not know anything about these, skip them, and solve questions that you are more confident about. And then, you can come back to these, take a deep breath, and try to understand the case.

For selecting the right exam time, you should not choose midnight time because I was very tired and did not sleep well. It was hard to focus on the long questions and scenarios in a situation like this.

I hope my advice and recommendations will help you in this exam process.

Thanks for reading! Stay safe in the cloud! 🤞 ⛅️

AWS Certified Security – Specialty - Credly

Earners of this certification have an in-depth understanding of AWS security services and the shared responsibility model (between AWS and the customer). They demonstrated the ability to design, implement, and troubleshoot various security models in the AWS Cloud. Badge owners can leverage various security models for organizations of all sizes.

credly.com

Your AWS EC2 Has Been Hacked. What Will Happen Now?

Sena Yakut — Sun, 08 Jan 2023 06:59:12 +0000

Let's assume our worst nightmare occurred: One of the most important production environments that are built on AWS EC2 services was hacked. What are the required steps for returning to your normal application behavior? What needs to be done for your forensic analysis? What steps should be done to not should be repeated? Do you prepare your incident response plan? In this blog, we'll answer these questions. Let's start together!

Preparation
This step needs to be considered before the hacking. The preparation step is one of the critical tasks of your cloud security assessment and incident response plan. You need to be sure about your controls are in place that help you in the detection of anomalies within your AWS EC2 environment.

Some examples of preparation that need to configure:
Ensure your logging services are enabled on AWS such as CloudTrail, VPC Flow Logs, and AWS ELB Access Logs.
Always think of encryption in rest and encryption in transit. Use AWS KMS encryption wherever possible (in an EC2 scenario, think AWS ELB, EFS, etc.)
Review your attack surfaces and read AWS Security Reference Architecture for following security best practices in your environment.

Detection
This step can be achieved if you're all set in Step 1. Otherwise, you've been hacked for months, and attackers could be possible in your environment to wait for the right time to get full access or exploit you.

Detection is so critical; we need to configure AWS security services to do this:

Based on Step 1, to gain visibility of your possible attack surfaces and your activities, you need to enable logging and monitoring services.
For anomaly detection, you should think about implementing notifications and alarming with AWS EventBridge.
Enable AWS GuardDuty which is a threat intelligence service.
Enable AWS Config for analyzing all the changes in your AWS environment.
Use AWS Detective for analyzing the hacking scenario. Which IP? What happened?

After Step 1 and Step 2, you can only detect the attack. But you're still hacked. What should you do as a cloud security engineer?

Containment

You need to do some configurations and changes after you understand that you're under attack. One of the most things that have been done is terminating compromised instances immediately. You should not do that; we need this instance for investigation and forensic analysis. Automation is the key here because it's a more simple and quick way to deny attackers.

These are the following steps to do:

Detach this instance from any autoscaling group and ELB target group immediately. You don't want your customers connecting the compromised instance.
Remove the earlier security group that is attached to your instance. Create a new security group. The new security group has included 0.0.0. 0/0 ingress and egress rule. Attach the new security group to the compromised instance. Delete the ingress and egress rule. You should think removing all rules in the existing security group is a solution, but it's not a solution for tracked connections. You should automate this process. Maybe you can create a Python function with AWS Lambda that can be invoked with an instance ID parameter.
If you're using AWS EC2 Instance roles to access your AWS resources, roles create temporary credentials for you. If you're not disabling these, an attacker can still use them. To remove all actions from the temporary credentials, you should attach an explicit deny policy to your AWS EC2 role. If you're using hardcoded AWS credentials in your instance (you should not do this by the way), you need to disable them. Deleting AWS credentials directly can occur production issues if you're using the same credentials on different environments.

Analysis

After completing the containment, you need to take a snapshot of the compromised EC2 instance immediately. You should not shut down the instance (We need information that can be deleted during the shutdown process).

Besides all of these:

Take a memory dump of all processes in your instance.
You need to create a new EC2. Install all your forensic and analysis tools in it. Also, you can create a new instance with an EBS snapshot that you've created from the compromised instance. For the security group, whitelist only newly created instance IP. You need to connect the EC2 instance with an EBS snapshot from the newly created EC2.
If there is any log file in the server, extract all of them for detailed analysis. If not, use AWS CloudWatch, CloudTrail, and other logging options.
Analyze and list the IP list that attacks you. If these IP addresses belong to AWS, report this abuse from here.
Use AWS Config details for all your resource state changes.
If you're using 3rd party tools, you should also review their details.
Terminate the compromised instance after completing the EBS volume step.

Recovery & Lessons Learned

In Step 4, you did all your analysis about why this attack happened, how much did it affect our application and what should we do if it happens again. So, it's recovery time with a healthy, non-compromised instance. You need to create your AWS EC2 instance again.

Infrastructure as Code options such as AWS CloudFormation can help you about building a new server with configurations that you've determined. Also, if you have AMI from the backups (not compromised ones), you can create your AWS EC2 instance also. But please, you should not do mistakes that are configured before the incident happened.

After all these steps, you should monitor regularly for detecting something happening in your environment. In Step 5, you should learn your security issues, vulnerabilities that cause attacks, and your attack surfaces. Maybe you opened to an SSH port with a simple username/password combination, maybe you have a library that can be affected by a Log4j attack, or maybe you have an admin panel that is available all over the world. Who knows? You should know. You need to think about all the aspects of security incidents and hacking scenarios. Before all of these happened, you should use all logging and monitoring options, and all security services wherever possible. Also, you need to create an incident response plan for answering the "What should we do if it happens again?" In addition to this, you need to practice, practice and practice. You need to set "game days" to simulate your attack scenarios. This is not only a technical view, but we also need to see the team's reactions to a security attack.

Thanks for reading! Stay safe in the cloud! 🤞 ⛅️

Monitor Your Cloud Environment with AWS Trusted Advisor ☁️

Sena Yakut — Mon, 26 Dec 2022 20:32:27 +0000

Cloud security monitoring and increasing visibility are two main important things in the cloud. It helps us to build automated solutions for identifying risky or malicious behavior in the cloud environment. It is also required for every major regulation such as HIPAA, PCI DSS, etc.

Every day there are lots of AWS services that we’re using and gaining visibility and creating monitoring solutions are our responsibility. As your cloud environment grows, there could be many security problems if you don’t know where they are and whether are they configured properly from a security perspective. In AWS, there are lots of security services, and using and managing them is our responsibility. One of them is AWS Trusted Advisor a service that analyzes your AWS environment and provides recommendations for you in five categories: Cost optimization, security, fault tolerance, performance, and service limits.

In this blog, we’re focusing on the security part of the AWS Trusted Advisor. But you should consider the other parts of improving your environment such as cost, performance, etc.

In the AWS Trusted Advisor, there are lots of controls for security configurations of your AWS resources, some examples are the following:

Security Groups — Specific Ports Unrestricted: This control checks security groups for rules that allow unrestricted access to specific ports such as SSH and RDP. Unrestricted access increases opportunities for malicious activity (hacking, denial-of-service attacks, loss of data).
Amazon RDS Public Snapshots: This control checks the permission settings for your Amazon RDS DB snapshots and alerts you if any snapshots are marked as public. When you make a snapshot public, you give all AWS accounts and anonymous users access to all the data on the snapshot. If sharing snapshots is a requirement for you, you can mark the snapshot as private and then specify the user or accounts you want to share.

In AWS Trusted advisor, some security controls are enabled by default and free, and some of them are needs upgrading your AWS Account and you need to pay for it. These controls are more deep-dive solutions and recommendations for you.

Automated Monitoring of Trusted Advisor Security Checks:
From a cloud security perspective, enabling AWS Trusted Advisor is not enough. We need to automate and get action about controls. But AWS Trusted Advisor scenarios are different plan by plan. You can use the Trusted Advisor console to access checks in the security category if you have a Basic/Developer Support plan. If you have other plans, in addition to all of these, you can use AWS Support API to access all Trusted Advisor checks. You can also Amazon CloudWatch or EventBridge events to monitor and alarm.

Using Trusted Advisor with Different Scenarios:
1) You have a strict security policy for your databases. You do not want publicly accessible snapshots in your test and production environment. Also, you should not configure the security group rule of your databases overly permissive. If these actions are taken, there should be an incident response plan, to roll back all these configurations.
Solution: You can use AWS Trusted API metrics for this incident response plan. You can set an Amazon EventBridge Rule for these checks:

When this rule is triggered, you can invoke an AWS Lambda function that rolls back all the changes such as deleting overly permissive rules in the security group and disabling publicly accessible snapshots. You can use AWS SDK functions for these. This is the architectural design:

Note: You need to upgrade your support plan for this. The Basic Plan which is enabled when you create a new account does not support AWS Trusted Advisor metrics. You have only a console view in this plan.

2) Your security team wants to get a weekly summary security report of your environment. Do you need a custom solution or AWS Trusted Advisor can do that?

Solution: In the Trusted Advisor, there is a “Notification” solution. You can receive the email notification for Trusted Advisor Recommendations once a week. You need to add your security, billing and operations contact e-mail addresses. You can also set up a Slack solution with this.

There are some useful links that I want to share with you if you want to implement them:

Trusted Advisor with AWS Organizations: AWS Premium Support customers can use Trusted Advisor from an Organizational View. This provides a general and centralized view of all AWS Trusted Advisor recommendations.

Trusted Advisor Tools: This is a perfect GitHub repo for automating Trusted Advisor checks with AWS CloudFormation templates.

Trusted Advisor Best Practices: There are some best practice rules for AWS Trusted Advisor by TrendMicro.

Thanks for reading! Stay safe in the cloud! 🤞 ⛅️

AWS re:Invent 2022: Security Session Notes 📝

Sena Yakut — Sat, 10 Dec 2022 21:17:41 +0000

AWS re:Invent 2022 is completed in Las Vegas. I did not attend in person, but I’ve watched some security sessions and announcements online and I want to share my notes with you. I hope you will enjoy it! Let's start! 🤔

1- Amazon Security Lake: As you know, security data analysis is challenging. Every day, lots of logs are generated from our application environments. Transparency is high, and this is fine, but we, as a customer, gets lots of work and analysis to do. Besides this, every log is a different format and there is heterogeneity in them. We can build custom solutions to query, but this is also a complex and not flexible solution. AWS starts with the "Imagine if there was a service that…" idea to fix all these problems. The answer is "Amazon Security Lake".

Amazon Security Lake is a service that gives you the ability to centralize your security data. The main features that I've noted:

Provides collect, optimize, normalize, and analyze your log data,
Works with AWS Organizations,
Collect any region & any account with AWS services,
Log data can be immediately queried with Amazon Athena,
Retention and storage class settings,
Share your log data with 3rd party analytic tools.
Regulatory-compliant service.

2- Revitalize Your Security with the AWS Security Reference Architecture: This is a great presentation to understand the AWS Security services and SRA in general.

To use Security Reference Architecture, you need to define your security requirements first. You need to review and revise the architectural design that you've already implemented. You should learn cloud security concepts and use Infrastructure as Code wherever as possible. You must learn and understand new security concepts for your cloud environments. This process does not a one-time job, it should be reviewed and applied regularly. AWS SRA is a complex architecture if you're just learning or implementing security services, but with this session, you'll see every security service and their usage one by one in different use cases such as network security, infrastructure security, etc. I strongly recommend that watching this session if you're willing to build your own cloud security posture.

3- AWS Verified Access: In our daily workloads, we're connecting our corporate VPN and accessing our private applications in our cloud environments. What if we do not need VPN for accessing our applications? What if we can do this in an easier way? With AWS Verified Access, we can do this. This AWS service is created based on these questions: "We need simple connectivity." "We need better security." "We want to know who can access my application from what type of device and when this is happening."

AWS Verified access is built with zero trust principles and gives us better security posture. It also simplifies security operation, with just few clicks, you can set and use this service. It also logs every access request either allowed or denied. It is a requirement for troubleshooting, auditing, and compliance controls of an application.

To set up AWS Verified Access, you need to connect your trust providers (identity or device provider). After that, you need to associate your applications (CNAME and AWS ACM configurations). Lastly, you need to add access policies. AWS Verified Access policies have a new policy language that AWS Build called "Cedar". This is Cedar syntax:

If you want to use this service, AWS recommends adding your new applications to AWS Verified Access. For your existing applications, users can access the application by VPN and internet (with Verified Access), do not disable VPN directly.

4- Automate Data Discovery with Amazon Macie: AWS Macie is relaunched in 2020. It focuses on sensitive data at scale using machine learning. It is natively integrated with AWS S3, and it aims to evaluate your data security posture in your buckets.

With the "Automate Data Discovery" feature, we will be able to discover sensitive data continuously across all our AWS accounts and AWS S3 buckets by just enabling this feature. It uses intelligent sampling techniques.

With automated sensitive data discovery, you can prioritize your buckets, findings, and remediations. You can read more details here.

5- Protecting production with Amazon ECS security features:
This session is very useful to understand and implement Amazon ECS security considerations. Container technology usage and transition increase day by day. It’s important to know which parts we are responsible for in our container environments, and which implementations should we have done on the network, data, and infrastructure side. In the session, you’ll see different use cases and team groups from security perspective and possible solutions and responsibilities about them. This is an example of use cases:

6- Amazon Inspector Now Scans AWS Lambda Functions for Vulnerabilities: Amazon Inspector Now Scans AWS Lambda Functions for Vulnerabilities: I’ve mentioned about this new feature in my blog:

Security visibility and vulnerability management are important steps for your cloud environments. These two steps are not one-time jobs, these should be regular and real-time if it’s possible. AWS has lots of services and solutions for securing your cloud, gaining visibility for vulnerabilities, and remediating them as soon as possible. Every day, the AWS team finds and adds new solutions to these services. Today, we’re going to learn new features of Amazon Inspector. With this new feature that announced in re:Invent 2022, you can scan your AWS Lambda functions with Amazon Inspector.

I get all the screenshots from re:Invent 2022 videos. I'll mention other sessions or new announcements in my other blogs. You can access lots of security related sessions in this list.

Thanks for reading! Stay safe in the cloud! 🌤 ⛅️ 🌥