AWS Cloud Security Assessment Project

• The objective of this project was to demonstrate how to identify and remediate security issues in an AWS environment using a running EC2 instance. I used AWS Inspector, Security Hub, Config, and GuardDuty to detect vulnerabilities, misconfigurations, and missing security controls.
• This project taught me how to evaluate findings, prioritize risks, and apply fixes effectively. For example, I identified exposed services through a public IP address, which could allow brute-force attacks against SSH, RDP, or SQL services. I also confirmed the importance of MFA, IAM credential protection, and proper password policies to prevent unauthorized access.
• I remediated issues by updating vulnerable packages (e.g., GRUB2 and Vim), enabling CloudTrail logging, configuring detailed EC2 monitoring, and enforcing IAM password complexity requirements. These changes reduced the attack surface, improved visibility, and strengthened the overall security posture of the environment.
• Below is a detailed breakdown of the vulnerabilities, prioritization decisions, and remediation steps:

  1: AWS Inspector                                                                                                                                                   a) CVE-2025-0689 - grub2-common, grub2-efi-x64-ec2 and 3 more   B) Prioritization – why these first? This CVE should be prioritized due to:

• Secure Boot Bypass Risk – Attackers could exploit this to disable boot protections, leading to system compromise.
• Widespread Exposure – Systems using GRUB2 (Amazon Linux, Ubuntu, Red Hat, etc.) are vulnerable.
• Potential Remote Exploitation – If an attacker modifies boot parameters remotely, this vulnerability could enable persistent access.

Impact – what systems/services are affected if these not resolved?   Failure to address this vulnerability could affect:

• Amazon Linux 2023 & Other Linux-Based EC2 Instances – If not patched, secure boot mechanisms could be bypassed, increasing persistence risks.
• Hypervisors & Virtual Machines – Systems running GRUB2 could be exploited to alter boot sequences, enabling deeper infiltration.
• Bootloader Security – Could undermine trust in cryptographic validation, potentially leading to kernel tampering.

Efficiency – what is the expected level of effort to address these vulnerabilities?  Effort needed to patch:

• Low to Moderate for standard updates – Amazon Linux provides patched versions of grub2-common and grub2-efi-x64-ec2.
• Moderate to High for custom implementations – If using custom GRUB2 configurations, manual recompilation may be needed.
• Verification Required – Post-update scans with AWS Inspector or manual checks should confirm mitigation.

 Recommendation – how do you recommend these vulnerabilities should be addressed?

• Update GRUB2 Immediately:

“sudo dnf update grub2-common grub2-efi-x64-ec2”

• Reinstall Bootloader:

“sudo grub2-install /dev/sdX” “sudo grub2-mkconfig -o /boot/grub2/grub.cfg”

• (Replace /dev/sdX with the correct boot disk.)
• Verify Fix with AWS Inspector – Scan EC2 instances to confirm mitigation.
• Monitor Amazon Linux Security Advisories for additional updates.

C)Running code to fix the vulnerability   D) Vulnerability completed and Fixed   A) CVE-2025-26603-vim-common, vim-data and 4 more   Prioritization – why this one first? CVE-2025-26603 should be addressed promptly due to:

• Potential for Remote Code Execution – Exploiting Vim’s vulnerability could enable an attacker to execute arbitrary commands with elevated privileges.
• High-Risk Applications – Many AWS workloads rely on Vim for configuration and scripting, making widespread exposure possible.
• User Interaction-Based Exploits – The vulnerability can be exploited when opening malicious files or interacting with specific Vim commands, posing risks in operational environments.

  Impact – what systems/services are affected if this is not resolved? Failure to patch could affect:

• Amazon Linux 2 & 2023 EC2 Instances – Systems using Vim for editing configurations may be exposed.
• Containerized Workloads – If Vim is bundled into Docker containers, unpatched versions could persist.
• Automation Scripts & CI/CD Pipelines – Vulnerable Vim installations could pose risks in environments that rely on script execution for deployment.

Efficiency – what is the expected level of effort to achieve compliance? Effort required:

• Low – If running standard Amazon Linux versions, updating Vim is straightforward with “dnf” or “yum”.
• Moderate – If Vim is used in custom-built containers or scripts, updates may require image rebuilds and testing.
• Verification Required – AWS Inspector or manual checks should confirm the vulnerability is mitigated post-update.

Recommendation – how do you recommend this compliance rule should be addressed?   Update Vim Immediately With: “sudo dnf update vim-common vim-data --releasever=2023.7.20250414”

• (Amazon Linux 2 users should use yum instead.)
• Verify Fix with AWS Inspector – Scan EC2 instances to confirm mitigation.
• Check for Vulnerable Containers – Ensure Vim versions inside Docker containers are updated.
• Restrict Untrusted Vim Scripts – Apply controls to prevent execution of unverified “.vimrc” files and macros.

  C) Vulnerability before the fix D) Vulnerability fixed and showing it complete    2: AWS Config  

1. cloudtrail-s3-dataevents-enabled-conformance-pack-ly8zmmii3

  Prioritization – why this one first?

• Critical Data Visibility – CloudTrail logs data events for S3, ensuring detailed auditing of access and modifications.
• Prevent Unauthorized Data Access – Potential data exfiltration or unauthorized changes can go unnoticed without monitoring.
• Regulatory Compliance – Many standards (CIS, NIST, GDPR, PCI DSS) require logging data access events to secure sensitive information.

Impact – what systems/services are affected if this is not resolved? If S3 data event logging is disabled:

• S3 Buckets – No visibility into who accessed or modified data, increasing security risks.
• Security & Compliance Frameworks – A Lack of logs may cause non-compliance with governance requirements.
• Incident Response & Forensics – Security teams cannot investigate breaches effectively without logs.

Efficiency – what is the expected level of effort to achieve compliance?

• Low Effort – Enabling S3 data event logging in CloudTrail is a one-step configuration.
• Minimal Impact – Logs are stored in S3 and CloudWatch, requiring no additional infrastructure.
• Ongoing Monitoring Needed – Regular log analysis is required to detect anomalies.

Recommendation: How do you recommend that this compliance rule be addressed?

1. Enable CloudTrail S3 Data Event Logging

1. • Open AWS CloudTrail Console → Select your active trail.

1. • Click Event Selector → Enable S3 Data Events → Choose "All Buckets" or specify targets.

1. Store Logs in an Encrypted S3 Bucket

1. • Ensure log integrity validation is enabled.

1. • Apply SSE-KMS encryption to secure CloudTrail logs.

1. Set Up Alerts for Anomalies

1. • Create CloudWatch Alarms for unusual S3 data access patterns.

1. • Use Amazon SNS Notifications for security teams.

1. Verify Compliance in AWS Security Hub

• Check findings related to CloudTrail logging gaps.
• Run AWS Config scans to confirm logging is enabled.

C) Shown below is the solution to the vulnerability                             D) Shown below is the vulnerability being compliant after fixing                               A) ec2-instance-detailed-monitoring-enabled-conformance-pack     Prioritization – why this one first?

• Improved Performance Visibility – Enables real-time metrics for CPU utilization, disk I/O, and network traffic.
• Faster Issue Detection – Helps pinpoint performance bottlenecks and anomalies quickly.
• Recommended for Mission-Critical Workloads – Essential for maintaining availability and optimizing resource usage.

Impact: What systems/services will be affected if this is not resolved? If detailed monitoring is not enabled:

• EC2 Instances – Limited visibility into real-time performance data, making troubleshooting harder.
• CloudWatch Metrics – AWS only provides basic metrics every five minutes without detailed monitoring, reducing incident response speed.
• Auto Scaling & Cost Optimization – Inefficient scaling decisions due to incomplete performance data.

Efficiency – what is the expected level of effort to achieve compliance?

• Low Effort – Enabling detailed monitoring is a simple toggle within EC2 settings.
• Minimal Impact – Does not require application changes but slightly increases CloudWatch costs.
• Ongoing Maintenance – Metrics must be monitored proactively to take full advantage.

Recommendation: How do you recommend that this compliance rule be addressed?

1. Enable Detailed Monitoring in EC2

1. • Open AWS EC2 Console → Select the instance.

1. • Click Modify Instance Settings → Check Enable Detailed Monitoring.

1. Configure CloudWatch Alarms for Critical Metrics

1. • Set up alarms for CPU utilization, network traffic, and disk I/O spikes.

1. • Use SNS notifications to alert security teams.

1. Integrate with AWS Cost Management

1. • Review CloudWatch usage to ensure cost efficiency.

1. • Optimize instance types based on performance trends.

  C) Vulnerability in the middle of being fixed   D) Vulnerability showing its now compliant and fixed                               A) Cloud-trail-cloud-watch-logs-enabled-conformance-pack-Ly8Zmmii3 B) Prioritization – Why This One First?

• Critical for Security Monitoring – CloudTrail logs track AWS API activity, and sending logs to CloudWatch enables real-time Monitoring.
• Incident Response Readiness – Without CloudWatch integration, detecting suspicious activity becomes delayed, increasing security risks.
• Compliance Requirement – Many security frameworks (CIS, NIST, PCI DSS) mandate log retention and Monitoring to ensure security visibility.

Impact – What Systems/Services Are Affected If Not Resolved? If CloudTrail does not forward logs to CloudWatch:

• IAM & User Activity Logs – Unauthorized access attempts may go unnoticed.
• EC2, S3, and Other AWS Services – Reduced visibility into configuration changes, API calls, and resource modifications.
• Security Operations & Forensic Analysis – Delays in threat detection and difficulty in investigating security incidents.

Efficiency – Expected Level of Effort to Achieve Compliance?

• Low Effort – Enabling CloudTrail log delivery to CloudWatch is a straightforward configuration update in the AWS Console.
• Minimal Performance Impact – It does not require new infrastructure but may slightly increase CloudWatch costs for log storage.
• Ongoing Monitoring Required – Regular log analysis ensures compliance and helps detect security issues proactively.

Recommendation – How Should This Compliance Rule Be Addressed?

1. Enable CloudTrail Logging to CloudWatch

1. • Open AWS CloudTrail Console → Select the existing trail.

1. • Click Edit → Enable CloudWatch Logs Integration.

1. • Choose an existing CloudWatch Log Group or create a new one.

1. Assign Permissions Using IAM Role

1. • Create an IAM role that allows CloudTrail to write logs to CloudWatch.

1. • Attach the required permissions (CloudWatch Logs Write Access).

1. Set Up CloudWatch Alerts for Security Monitoring

1. • Create Metric Filters to detect critical security events.

1. • Configure CloudWatch Alarms and link them to an SNS topic to notify security teams.

1. Verify Compliance & Continuous Monitoring

1. • Run an AWS Config Compliance Scan.

1. • Check AWS Security Hub for any CloudTrail logging violations.

1. • Regularly audit CloudWatch logs for anomalies.

C) Vulnerability being fixed                               D) Vulnerability showing being compliant and fixed                           4: AWS Security Hub A) Ensure IAM password policy requires at least one lowercase letter       B) prioritization – why this one first?

• Strengthens Authentication Security – Enforcing a complex password structure reduces the risk of brute-force attacks.
• Common Password Weakness – Many users create passwords with predictable patterns, increasing vulnerability.
• Regulatory Compliance – Security frameworks (CIS, NIST, ISO 27001) mandate strong password policies to protect access credentials.

Impact – what systems/services are affected if this is not resolved? If a lowercase letter requirement is missing:

• IAM User Accounts – Weak passwords make accounts easier to compromise.
• AWS Management Console & API Access – Attackers could gain unauthorized access to AWS resources.
• Multi-Factor Authentication (MFA) & Identity Protection – Even with MFA, a weak password increases the risk of credential stuffing attacks.

Efficiency – what is the expected level of effort to achieve compliance?

• Low Effort – Updating the IAM password policy is a quick configuration change in AWS IAM settings.
• Minimal Operational Impact – No downtime, but existing users may need to update their passwords.

• Ongoing Monitoring Required – Regular audits ensure compliance and detect weak password usage

Recommendation – how do you recommend this compliance rule should be addressed?

1. Update IAM Password Policy
   • Open AWS IAM Console → Navigate to Account Settings.
   • Click Set Password Policy → Enable Require at Least One Lowercase Letter.
   • Apply the changes and enforce policy updates for all users.
2. Educate Users on Secure Password Practices
   • Recommend using password managers to generate strong, compliant passwords.
   • Encourage users to follow NIST guidelines for passphrase-based authentication.
3. Enable AWS Config Rule for Password Policy Compliance
   • Open AWS Config Console → Create a rule for IAM Password Policy Validation.
   • Set alerts for non-compliant password configurations.

 C) Vulnerability being fixed                   D) Vulnerability showing that it is now Compliant and fixed