Unit 6: The Security Pillar - Subjective Questions

AWS Identity and Access Management (IAM) is a web service that enables you to securely control access to AWS services and resources for your users. It allows you to manage authentication (who can sign in) and authorization (what they can do).

Core Components:

• Users: An IAM user represents a person or application that interacts with AWS. Each user has unique credentials.
• Groups: A collection of IAM users. Permissions assigned to a group apply to all its members, simplifying permission management.
• Roles: An identity with permissions that can be assumed temporarily by trusted entities (users, applications, or AWS services) without long-term credentials.
• Policies: JSON documents that define permissions. They specify the Effect (Allow/Deny), Action, Resource, and optional Conditions.

How they work together:

1. An entity (user/role) attempts to perform an Action on a Resource.
2. IAM evaluates all applicable policies.
3. By default, all requests are implicitly denied.
4. An explicit Allow grants access, but an explicit Deny always overrides any Allow.

This model ensures the principle of least privilege, granting only the permissions required to perform a task.

The root user is created when an AWS account is first set up and has complete, unrestricted access to all resources and billing. Compromise of the root account can be catastrophic.

Why it is critical:

• It cannot be restricted by IAM policies.
• It can close the account, change billing, and access all services.

Best Practices for Protection:

• Do not use the root account for daily tasks. Create individual IAM users/roles instead.
• Enable Multi-Factor Authentication (MFA) on the root account for an extra layer of security.
• Delete or deactivate root access keys — programmatic access via root should be avoided.
• Use a strong, unique password.
• Lock away root credentials and use them only for tasks that strictly require root (e.g., changing account settings).
• Set up account recovery contacts and monitor account activity.

By minimizing root usage and enforcing MFA, the attack surface is dramatically reduced.

Fine-grained authorization refers to the ability to grant very specific, precise permissions down to individual actions, resources, and the conditions under which they apply, rather than broad all-or-nothing access.

Mechanisms to achieve fine-grained authorization:

• Resource-level permissions: Policies can specify exact resource ARNs (Amazon Resource Names) so permissions apply only to specific resources (e.g., a single S3 bucket).
• Policy Conditions: The Condition block adds constraints using keys and operators. Examples:
  • Restrict access by IP address (aws:SourceIp)
  • Require MFA (aws:MultiFactorAuthPresent)
  • Restrict by time (aws:CurrentTime)
  • Restrict by tags (aws:ResourceTag)
• Attribute-Based Access Control (ABAC): Uses tags on resources and principals to dynamically determine access.

Example Policy Snippet:

{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mybucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "192.168.1.0/24"}
}
}

This grants read access to objects only when the request originates from a specific IP range, demonstrating precise, context-aware control.

A Permission Boundary is an advanced IAM feature that sets the maximum permissions an IAM entity (user or role) can have. It acts as a guardrail — the entity can never exceed the permissions defined by the boundary, regardless of what its identity-based policies allow.

How it works:

• Effective permissions = intersection of the permission boundary AND the identity-based policies.
• Even if an identity policy grants s3:*, if the boundary only allows s3:GetObject, then only GetObject is effectively allowed.

Difference from standard IAM policies:

Why they are useful:

• Delegated administration: Allows admins to let developers create roles/users while ensuring they cannot escalate privileges beyond the boundary.
• Preventing privilege escalation.
• Enforcing organizational governance.

In essence, boundaries define the ceiling, while policies define the actual grants within that ceiling.

An IAM Role is an IAM identity with specific permissions that can be assumed by trusted entities. Unlike users, roles do not have long-term credentials (password or access keys). Instead, when assumed, they provide temporary security credentials via AWS STS (Security Token Service).

Key Characteristics:

• No permanent credentials — reduces risk of leaked keys.
• Trust Policy: Defines who can assume the role (the trusted principal).
• Permission Policy: Defines what the role can do once assumed.
• Credentials are temporary and auto-expire.

Common Use Cases:

• EC2 Instance Roles: Grant applications on an EC2 instance access to AWS services without storing keys.
• Cross-Account Access: Allow users from one AWS account to access resources in another.
• Federated Access: Enable users authenticated via corporate directory (SAML) or web identity (Google, Facebook) to access AWS.
• Service Roles: Allow AWS services (e.g., Lambda) to act on your behalf.

Benefits: Enhanced security through temporary credentials, no key rotation burden, and support for the principle of least privilege.

Service-level protection involves applying controls that govern access to AWS services at a broad organizational or resource level, ensuring services are used securely and within policy.

1. Service Control Policies (SCPs):

• Part of AWS Organizations.
• Define the maximum available permissions for accounts in an organization.
• Act as a guardrail across all IAM users and roles in member accounts, including the root user.
• Example: Deny the ability to disable CloudTrail across all accounts.
• Like permission boundaries, SCPs do not grant permissions — they only limit them.

2. Resource-Based Policies:

• Attached directly to a resource (e.g., S3 bucket policy, SQS queue policy, KMS key policy).
• Specify who (principal) can access this resource and under what conditions.
• Enable cross-account access without roles.

Enforcement Model:

• A request is allowed only if both the identity policies AND the SCP permit it, and resource policies grant access.
• Any explicit Deny overrides.

Together, these create layered, service-level governance that enforces organization-wide security standards.

Detective controls are security mechanisms designed to identify, detect, and alert on potential security threats, anomalies, or policy violations after they occur (or as they occur). They do not prevent incidents but provide visibility and enable timely response.

Role in the AWS Security Model:

• Provide continuous monitoring and logging.
• Support auditing and compliance requirements.
• Enable incident detection and response.
• Help identify misconfigurations and unauthorized activity.

Examples of AWS Detective Services:

• AWS CloudTrail: Records API calls and account activity.
• Amazon CloudWatch: Monitors metrics, logs, and triggers alarms.
• AWS Config: Audits and tracks resource configuration changes.
• Amazon GuardDuty: Intelligent threat detection.
• Amazon Inspector: Automated vulnerability assessment.
• Amazon Detective: Investigates and analyzes security findings.
• AWS Security Hub: Centralizes security findings.

Relationship to other controls: Detective controls complement preventive controls (IAM, SCPs) and responsive controls (automated remediation), forming a complete defense strategy.

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account by recording actions taken by users, roles, and AWS services.

What it Captures:

• Management Events: Operations performed on resources (e.g., creating an EC2 instance, modifying IAM policies).
• Data Events: Resource-level operations on data (e.g., S3 object-level GetObject, Lambda Invoke).
• Insights Events: Unusual API activity patterns.

Each log entry records:

• Who made the request (identity)
• When it occurred (timestamp)
• What action was performed
• Source IP address
• Request parameters and response elements

Contribution to Security & Compliance:

• Audit trail: Provides a complete history of API activity for forensic investigation.
• Compliance: Helps meet regulatory requirements (PCI-DSS, HIPAA, etc.).
• Security analysis: Detects unauthorized or anomalous activity.
• Integration: Logs can be delivered to S3 for long-term storage and analyzed with Athena or sent to CloudWatch Logs.

Best Practice: Enable a multi-region trail, enable log file integrity validation, and protect trails from being disabled using SCPs.

Amazon CloudWatch Logs is a service for collecting, monitoring, storing, and analyzing log data from AWS resources, applications, and services in near real-time.

Key Features:

• Log Groups and Log Streams: Organize logs by source.
• Metric Filters: Extract metric data from log events.
• Alarms: Trigger notifications based on log patterns or thresholds.
• Log Insights: Query and analyze logs interactively.
• Retention Policies: Control how long logs are stored.

CloudWatch Logs vs. CloudTrail:

Using them together:

• CloudTrail can deliver its logs to CloudWatch Logs, enabling real-time monitoring.
• You can create metric filters and alarms on CloudTrail events — e.g., trigger an alert whenever someone disables encryption or modifies security groups.
• This combination enables proactive detection of suspicious activity, bridging auditing and real-time alerting.

Amazon Athena is an interactive, serverless query service that lets you analyze data directly in Amazon S3 using standard SQL. It is commonly used to query large volumes of log data such as CloudTrail logs, VPC Flow Logs, and ALB access logs.

How it Works:

1. Log files (e.g., CloudTrail logs) are stored in an S3 bucket, typically in JSON or compressed format.
2. You define a table schema in Athena (using the AWS Glue Data Catalog) that maps to the structure of the log data.
3. You run SQL queries against the data without loading it into a database.
4. Athena scans the S3 data and returns results.

Example Query (CloudTrail):

SELECT eventtime, eventname, useridentity.username, sourceipaddress
FROM cloudtrail_logs
WHERE eventname = 'ConsoleLogin'
ORDER BY eventtime DESC;

Benefits:

• Serverless: No infrastructure to manage.
• Cost-effective: Pay only for data scanned per query.
• Scalable: Handles petabytes of log data.
• Fast ad-hoc analysis: Enables quick forensic investigation and security auditing.
• Standard SQL: No need to learn new query languages.

This makes Athena ideal for on-demand security investigations and compliance reporting over historical log data.

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. It continuously monitors and records resource configurations and allows you to automate evaluation against desired settings.

Key Capabilities:

• Configuration History: Records how resource configurations change over time.
• Configuration Snapshots: Point-in-time view of all resources.
• Relationship Mapping: Shows how resources relate to each other.
• Change Notifications: Alerts when configurations change.

AWS Config Rules:

Config Rules represent your desired configuration state. AWS Config evaluates resources against these rules and marks them compliant or non-compliant.

• Managed Rules: Predefined by AWS (e.g., check if S3 buckets are encrypted, if EBS volumes are encrypted).
• Custom Rules: Defined using AWS Lambda for organization-specific requirements.

Example Use Cases:

• Ensure all S3 buckets have encryption enabled.
• Verify security groups do not allow unrestricted SSH (port 22) access.
• Confirm CloudTrail is enabled.

Benefits for Auditing:

• Continuous compliance monitoring.
• Change tracking for forensic analysis.
• Automated remediation when combined with Systems Manager.
• Compliance reporting for governance frameworks.

Amazon GuardDuty is an intelligent threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and unauthorized behavior. It uses machine learning, anomaly detection, and integrated threat intelligence.

Data Sources Analyzed:

• CloudTrail Event Logs (management & S3 data events)
• VPC Flow Logs (network traffic metadata)
• DNS Logs (domain query activity)
• EKS audit logs, RDS login activity, S3 data events (optional protections)

Types of Threats Detected:

• Reconnaissance: Port scanning, unusual API activity.
• Instance compromise: Communication with known malicious IPs, cryptocurrency mining, malware.
• Account compromise: Unusual console logins, disabled logging, unauthorized deployments.
• Bucket compromise: Suspicious S3 data access patterns.

Key Features:

• No agents required — purely analyzes existing logs.
• Findings are prioritized by severity (Low, Medium, High).
• Integrates with Security Hub, CloudWatch Events, and Lambda for automated response.

Benefit: Provides continuous, intelligent threat monitoring without impacting performance or requiring deployment of software.

Amazon Inspector is an automated vulnerability management service that continuously scans AWS workloads for software vulnerabilities and unintended network exposure.

What it Scans:

• Amazon EC2 instances — for OS and software package vulnerabilities (based on CVEs).
• Amazon ECR container images — scans container images for vulnerabilities.
• AWS Lambda functions — scans function code and dependencies.

How it Works:

1. Automatic discovery of resources — no manual scheduling needed.
2. Continuously assesses resources against a database of Common Vulnerabilities and Exposures (CVEs).
3. Evaluates network reachability to identify exposed resources.
4. Generates findings with a risk score (contextualized by exploitability and reachability).

Key Benefits:

• Continuous & automated — scans trigger automatically when resources change.
• Prioritized findings using the Inspector risk score.
• Integration with Security Hub and EventBridge for workflow automation.
• Reduced manual effort compared to traditional scanning.

Difference from GuardDuty: Inspector focuses on vulnerabilities (weaknesses) in resources, while GuardDuty focuses on active threats and malicious behavior.

Amazon Detective is a security service that helps you analyze, investigate, and identify the root cause of potential security findings or suspicious activities. It automatically collects log data and uses machine learning, statistical analysis, and graph theory to build a linked set of data that enables faster, more efficient investigations.

How it Works:

• Automatically ingests data from CloudTrail, VPC Flow Logs, and GuardDuty findings.
• Builds a behavior graph — a unified, interactive view of resources, users, and their activities over time.
• Establishes baselines of normal behavior to highlight anomalies.

How it Assists Security Teams:

• Visualizations: Provides interactive dashboards showing entity relationships and activity trends.
• Root cause analysis: Helps answer "what happened, when, and how" for a finding.
• Reduced investigation time: Pre-aggregates and correlates data so analysts do not manually gather logs.
• Context for GuardDuty findings: Deep-dive into the entities involved in an alert.

Difference from GuardDuty: GuardDuty detects threats and raises findings; Detective helps investigate those findings to understand their scope and cause.

AWS Security Hub is a cloud security posture management (CSPM) service that provides a comprehensive, centralized view of your security state across AWS accounts. It aggregates, organizes, and prioritizes security findings from multiple AWS services and third-party tools.

Key Functions:

• Centralized Findings: Collects findings from GuardDuty, Inspector, Macie, Config, IAM Access Analyzer, and partner solutions into a single dashboard.
• Security Standards & Compliance Checks: Runs automated checks against frameworks such as:
  • CIS AWS Foundations Benchmark
  • PCI-DSS
  • AWS Foundational Security Best Practices
• Normalized Format: Uses the AWS Security Finding Format (ASFF) so findings from different sources are comparable.
• Security Score: Provides an overall measure of compliance posture.

Integration & Automation:

• Integrates with Amazon EventBridge to trigger automated responses and remediation (via Lambda or Systems Manager).
• Supports multi-account management via AWS Organizations.

Benefits:

• Single pane of glass for security visibility.
• Reduced alert fatigue through aggregation and prioritization.
• Continuous compliance monitoring across the environment.

Protecting network boundaries involves controlling and filtering traffic entering and leaving your AWS environment to prevent unauthorized access and attacks. AWS provides a layered set of tools.

1. Security Groups:

• Act as a stateful virtual firewall at the instance (ENI) level.
• Control inbound and outbound traffic by rules.
• Stateful: Return traffic is automatically allowed.
• Only support Allow rules.

2. Network Access Control Lists (NACLs):

• Operate at the subnet level.
• Stateless: Must explicitly allow both inbound and outbound traffic.
• Support both Allow and Deny rules.
• Provide a secondary layer of defense.

3. AWS WAF (Web Application Firewall):

• Protects web applications from common Layer 7 exploits (SQL injection, cross-site scripting).
• Uses customizable rules to filter HTTP/HTTPS requests.
• Integrates with CloudFront, ALB, and API Gateway.

4. AWS Shield:

• Provides DDoS protection.
• Shield Standard: Free, automatic protection against common attacks.
• Shield Advanced: Enhanced protection, 24/7 response team, and cost protection.

Layered Defense: Combining these creates defense in depth — Security Groups and NACLs handle network-level filtering, while WAF and Shield protect against application-level and volumetric attacks.

Data encryption is the process of converting data into an unreadable format (ciphertext) using cryptographic keys so that only authorized parties can decrypt and read it. It is a fundamental security control for protecting data confidentiality.

1. Encryption at Rest:

• Protects data stored on disk or in storage services.
• Examples: encrypted S3 objects, EBS volumes, RDS databases, DynamoDB tables.
• Prevents data exposure if physical media is compromised.

2. Encryption in Transit:

• Protects data moving across networks between clients and services.
• Uses protocols like TLS/SSL.
• Prevents eavesdropping and man-in-the-middle attacks.

Comparison:

AWS Key Management Service (KMS):

• A managed service to create and control cryptographic keys.
• Supports Customer Managed Keys (CMK) and AWS Managed Keys.
• Integrates with most AWS services for seamless encryption.
• Provides key rotation, access control via policies, and CloudTrail logging of key usage.
• Uses envelope encryption — data is encrypted with a data key, which is itself encrypted by a master key.

Best Practice: Enable encryption both at rest and in transit, use KMS for centralized key management, and apply least-privilege key policies.

These three AWS services serve distinct but complementary security purposes.

Comparison Table:

How they Complement Each Other:

1. Inspector proactively identifies vulnerabilities before they are exploited (e.g., an outdated package with a known CVE).
2. GuardDuty continuously detects active threats — e.g., an instance communicating with a malicious IP.
3. Detective then helps investigate a GuardDuty finding, building a timeline and relationship graph to determine the scope and root cause.

Integrated Workflow Example:

• Inspector flags a vulnerable EC2 instance →
• GuardDuty later detects that instance making suspicious outbound connections →
• Detective is used to investigate what activities occurred, which users/resources were involved, and the full attack path.

All three feed findings into Security Hub for centralized visibility, forming an end-to-end detect-assess-investigate pipeline.

AWS evaluates every request through a well-defined policy evaluation logic to decide whether to Allow or Deny an action. Understanding this is key to designing secure access.

General Principles:

• Default: All requests are implicitly denied.
• Explicit Allow: Required to grant access.
• Explicit Deny: Always overrides any Allow (highest priority).

Evaluation Steps (simplified):

1. Authentication: Verify the identity of the principal.
2. Gather all applicable policies:
   • Identity-based policies
   • Resource-based policies
   • Permission boundaries
   • Service Control Policies (SCPs)
   • Session policies
3. Check for explicit Deny — if any policy denies, the request is denied immediately.
4. Evaluate SCPs — the action must be allowed by SCPs (if in an organization).
5. Evaluate Permission Boundaries — the action must be within the boundary.
6. Evaluate Identity/Resource policies — at least one must explicitly allow.

Interaction Summary:

• Effective permissions = Intersection of (Identity Policies) ∩ (Permission Boundary) ∩ (SCPs), plus resource policies — with any explicit Deny winning.
• For the request to succeed, every applicable guardrail (SCP, boundary) must allow it, AND an identity or resource policy must grant it.

Example: If an identity policy allows s3:*, but the permission boundary only permits s3:GetObject, and the SCP allows all S3 — the effective permission is just s3:GetObject (the intersection). If a resource policy explicitly denies the user, access is denied.

This layered model enforces least privilege and defense in depth.

A robust detective controls strategy provides continuous visibility, detection, and auditing across the environment. The following integrated approach combines the key AWS services into a cohesive monitoring pipeline.

1. Logging and Auditing Foundation — AWS CloudTrail:

• Enable a multi-region, organization-wide trail.
• Deliver logs to a dedicated, protected S3 bucket with log file integrity validation.
• Capture both management and data events.

2. Configuration Auditing — AWS Config:

• Enable Config to record all resource configurations and changes.
• Apply Config Rules (managed and custom) to enforce compliance (e.g., encryption enabled, no public S3 buckets).
• Use automatic remediation where appropriate.

3. Real-time Monitoring & Alerting — Amazon CloudWatch:

• Send CloudTrail logs to CloudWatch Logs.
• Create metric filters and alarms for critical events (root login, security group changes, disabling of CloudTrail).
• Use SNS for notifications.

4. Threat Detection — Amazon GuardDuty:

• Enable across all accounts for intelligent, continuous threat detection.
• Analyze CloudTrail, VPC Flow Logs, and DNS logs.

5. Centralized Aggregation — AWS Security Hub:

• Aggregate findings from GuardDuty, Inspector, Config, and others.
• Run compliance standards (CIS, AWS Best Practices).
• Provide a single pane of glass and security score.

6. Investigation — Amazon Detective (optional add-on):

• Investigate and perform root-cause analysis on findings.

7. Automated Response:

• Use EventBridge to trigger Lambda functions or Systems Manager runbooks for automated remediation.

Analysis Layer — Athena:

• Query historical CloudTrail logs in S3 using SQL for forensic investigations.

Overall Flow: Logs/configs collected (CloudTrail, Config) → Monitored & alerted (CloudWatch) → Threats detected (GuardDuty) → Aggregated (Security Hub) → Investigated (Detective) → Remediated (EventBridge + Lambda). This creates a continuous, automated detect-and-respond loop embodying defense in depth.