SPC Unit 2: Complete Concepts Guide
Unit 2: Access Control and Identity Management -> Generated and Prepared By Thiruselvan (ThiruXD)
TABLE OF CONTENTS
- Access Control Requirements for Cloud Infrastructure
- User Identification Techniques
- Authentication and Authorization Mechanisms
- Role-Based Access Control (RBAC)
- Multi-Factor Authentication (MFA)
- Single Sign-On (SSO)
- Identity Federation
- Identity Providers and Service Consumers
- Storage Access Control Options
- Network Access Control Options
- Operating System Hardening and Minimization
- Verified and Measured Boot
- Intrusion Detection Systems (IDS)
- Intrusion Prevention Systems (IPS)
2.1 ACCESS CONTROL REQUIREMENTS FOR CLOUD INFRASTRUCTURE
Definition
Access control ensures that only authorized users, systems, and services can access cloud resources. In cloud environments, access control requirements are more complex due to distributed nature, multi-tenancy, and dynamic scaling.
Core Access Control Requirements
1. Identity Management
- Definition: Managing digital identities of users, services, and devices
- Requirements:
- Unique identification for every entity
- Lifecycle management (creation, modification, deletion)
- Attribute management for identities
- Integration with identity sources (LDAP, Active Directory)
2. Authentication
- Definition: Verifying the identity of users or systems
- Requirements:
- Support for multiple authentication methods
- Strong password policies
- MFA capability
- Password-less authentication options
- Secure credential storage
3. Authorization
- Definition: Determining what authenticated users can do
- Requirements:
- Fine-grained permissions
- Role-based and attribute-based access control
- Least privilege principle
- Dynamic authorization based on context
- Segregation of duties
4. Accountability
- Definition: Tracking and logging all access activities
- Requirements:
- Comprehensive audit logging
- Tamper-proof logs
- Real-time monitoring
- Alerting on suspicious activities
- Compliance reporting
5. Administration
- Definition: Managing access control system
- Requirements:
- Centralized administration
- Delegated administration capabilities
- Self-service options for users
- Approval workflows
- Privilege management
6. Federation
- Definition: Trust relationships between different identity systems
- Requirements:
- Standards-based federation (SAML, OAuth, OpenID Connect)
- Cross-domain identity management
- Single sign-on capability
- Identity provider integration
Access Control Models
| Model | Description | Use Case |
|---|---|---|
| DAC (Discretionary Access Control) | Resource owner determines access | Small teams, personal files |
| MAC (Mandatory Access Control) | System-enforced based on labels | Government, military systems |
| RBAC (Role-Based Access Control) | Access based on user roles | Enterprise applications |
| ABAC (Attribute-Based Access Control) | Access based on attributes | Dynamic, context-aware systems |
| ReBAC (Relationship-Based Access Control) | Access based on relationships | Social networks, collaborative systems |
Cloud-Specific Access Control Requirements
| Requirement | Description | Example |
|---|---|---|
| Multi-tenancy | Isolation between tenants | Tenant-specific access policies |
| Scalability | Support for millions of users | Distributed identity management |
| Geographic Distribution | Regional compliance | GDPR, data residency |
| API Security | Secure programmatic access | API keys, OAuth tokens |
| Service-to-Service | Workload identity | Service accounts, roles |
| Just-in-Time Access | Temporary elevated access | Privileged access management |
| Zero Trust | Never trust, always verify | Continuous verification |
Access Control Policy Components
POLICY STATEMENT
├── Subject: Who (User, Service, Device)
├── Action: What (Read, Write, Delete, Execute)
├── Resource: Which (Data, Service, API)
├── Environment: Where (Network, Location, Time)
└── Decision: Allow or Deny (with conditions)Best Practices for Access Control in Cloud
- Centralized Identity Management: Use cloud-native IAM services
- Enforce Least Privilege: Grant minimal required permissions
- Regular Access Reviews: Periodically review and revoke unused access
- Privileged Access Management: Control and monitor administrative access
- Automated Provisioning: Use automation for user lifecycle
- Continuous Monitoring: Monitor and alert on suspicious access
- Compliance Integration: Align with regulatory requirements
- Disaster Recovery: Have backup identity sources and failover
2.2 USER IDENTIFICATION TECHNIQUES
Definition
User identification is the process of uniquely recognizing and distinguishing users in a system. It forms the first step in access control, establishing who is requesting access.
Identification Techniques
1. Username/PIN Based Identification
- Description: User selects a unique identifier
- Characteristics: Simple, widely used, requires uniqueness
- Examples: Employee ID, email address, custom username
- Limitations: Identity theft, username guessing, reuse across systems
2. Biometric Identification
- Description: Uses physical or behavioral characteristics
- Types:
- Fingerprint recognition
- Facial recognition
- Iris/Retina scanning
- Voice recognition
- Behavioral patterns (keystroke dynamics)
- Advantages: Hard to forge, convenient
- Challenges: Privacy concerns, accuracy, cost
3. Certificate-Based Identification
- Description: Uses digital certificates issued by trusted authorities
- Components: Digital certificate (X.509), Private key, Certificate Authority
- Applications: SSL/TLS, smart cards, email (S/MIME)
- Advantages: Strong authentication, non-repudiation
4. Token-Based Identification
- Description: Uses physical or virtual tokens
- Types:
- Hardware tokens (smart cards, USB keys)
- Software tokens (mobile apps)
- One-Time Password (OTP) tokens
- Cryptographic tokens
- Examples: RSA SecurID, YubiKey, Google Authenticator
- Advantages: Strong security, resistant to replay attacks
5. Attribute-Based Identification
- Description: Uses combination of attributes to identify user
- Attributes Used: Department, Job function, Security clearance, Location, Time
- Applications: Context-aware identification
User Identification in Cloud Environments
Identity Sources
| Source | Description | Use Case |
|---|---|---|
| Cloud Native Identity | Provider’s identity service | AWS IAM, Azure AD |
| Corporate Directory | Enterprise identity source | Active Directory, LDAP |
| Social Identity | Social media accounts | Google, Facebook, LinkedIn |
| Federated Identity | Trusted external identity | SAML, OAuth providers |
| Customer Identity | Application-specific identities | Customer portals |
User Lifecycle Management
USER LIFECYCLE
├── Onboarding
│ ├── Identity creation
│ ├── Attribute assignment
│ ├── Credential issuance
│ └── Access provisioning
├── Active
│ ├── Authentication
│ ├── Access management
│ ├── Profile updates
│ └── Activity monitoring
├── Suspension
│ ├── Temporary suspension
│ ├── Access revocation
│ └── Notification
└── Offboarding
├── Identity deletion
├── Access revocation
├── Data transfer
└── Audit loggingIdentification Security Considerations
- Uniqueness: Identifiers must be unique across the system
- Non-repudiation: Cannot deny identity
- Integrity: Identifiers cannot be tampered
- Confidentiality: Protection against disclosure
- Scalability: Support for large user bases
- Privacy: Balance between identification and privacy
- Auditability: Logging of identification events
Best Practices for User Identification
- Use Unique Identifiers: Ensure no two users share the same ID
- Protect Identifiers: Treat usernames as semi-sensitive
- Support Multiple Methods: Provide flexibility for different scenarios
- Implement Strong Password Policies: Enforce complexity requirements
- Use Federation When Possible: Leverage existing identity providers
- Monitor for Anomalies: Detect unusual identification patterns
- Implement Passwordless Options: Reduce password-related risks
- Follow NIST Guidelines: Use NIST SP 800-63 digital identity guidelines
2.3 AUTHENTICATION AND AUTHORIZATION MECHANISMS
Overview
Authentication verifies identity, while authorization determines permissions. Together, they form the core of access control in cloud systems.
Authentication Mechanisms
1. Password-Based Authentication
| Aspect | Details |
|---|---|
| Description | User provides username and password |
| Security | Base level; vulnerable to attacks |
| Best Practices | Strong passwords, hashing (bcrypt, Argon2), salting |
| Modern Approaches | Password-less, password managers |
| Cloud Implementation | IAM password policies, password rotation |
Password Security Best Practices:
- Minimum length: 12+ characters
- Complexity: Mix of character types
- No common patterns or dictionary words
- Regular password changes (if needed)
- Password hashing with strong algorithms
- Account lockout after failed attempts
2. Multi-Factor Authentication (MFA)
(Detailed in section 2.5)
3. Certificate-Based Authentication
| Aspect | Details |
|---|---|
| Description | Uses digital certificates to prove identity |
| Components | Public/private key pair, certificate issuance |
| Security | Very strong, non-repudiation |
| Use Cases | Enterprise VPN, SSL/TLS, smart cards |
| Cloud Implementation | Client certificates, service accounts |
4. Token-Based Authentication
| Aspect | Details |
|---|---|
| Description | Uses tokens (JWT, SAML) for authentication |
| Types | Bearer tokens, access tokens, refresh tokens |
| Security | Strong when properly implemented |
| Use Cases | APIs, mobile apps, web applications |
| Cloud Implementation | OAuth 2.0, OpenID Connect |
5. Biometric Authentication
| Aspect | Details |
|---|---|
| Description | Uses biological characteristics |
| Types | Fingerprint, facial, iris, voice |
| Security | Very strong, unique to individual |
| Cloud Implementation | Mobile device authentication |
6. Passwordless Authentication
| Aspect | Details |
|---|---|
| Description | No password required |
| Types | Magic links, one-time codes, biometrics |
| Security | Stronger than passwords |
| Use Cases | Consumer applications, enterprise |
Authorization Mechanisms
1. Role-Based Access Control (RBAC)
(Detailed in section 2.4)
2. Attribute-Based Access Control (ABAC)
| Aspect | Details |
|---|---|
| Description | Access based on attributes of user, resource, environment |
| Components | Attributes, policies, engines |
| Advantages | Fine-grained, dynamic, context-aware |
| Example | “Allow if user.department = resource.department AND time > 9AM” |
| Cloud Implementation | AWS IAM conditions, Azure AD Conditional Access |
3. Policy-Based Access Control (PBAC)
| Aspect | Details |
|---|---|
| Description | Access decisions based on policies |
| Standards | XACML, ALFA |
| Components | Policy Enforcement Point (PEP), Policy Decision Point (PDP) |
| Advantages | Centralized policy management, consistent enforcement |
4. Relationship-Based Access Control (ReBAC)
| Aspect | Details |
|---|---|
| Description | Access based on relationships between entities |
| Examples | Google Drive sharing, Facebook privacy settings |
| Advantages | Intuitive, supports complex sharing |
Authentication vs Authorization
| Aspect | Authentication | Authorization |
|---|---|---|
| Purpose | Verify identity | Determine permissions |
| Question | “Who are you?” | “What can you do?” |
| When | First | After authentication |
| Methods | Password, MFA, Certificates | Roles, Policies, Attributes |
| Example | Login with credentials | Access to specific files |
Authentication Flow in Cloud
USER REQUEST
│
▼
┌─────────────────────────────────────┐
│ 1. AUTHENTICATION │
│ - Verify user identity │
│ - MFA check │
│ - Session creation │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 2. AUTHORIZATION │
│ - Check permissions │
│ - Evaluate policies │
│ - Apply conditions │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 3. ACCESS GRANTED/DENIED │
│ - Resource access │
│ - Logging │
│ - Monitoring │
└─────────────────────────────────────┘Best Practices for Authentication and Authorization
- Implement MFA: Always require MFA for administrative access
- Use Strong Password Policies: Minimum 12 characters, complexity
- Enforce Least Privilege: Grant only necessary permissions
- Regular Access Reviews: Review and revoke unused permissions
- Monitor and Log: Track all authentication attempts
- Implement Secure Storage: Hash passwords, protect tokens
- Use Federation: Leverage trusted identity providers
- Apply Zero Trust: Never trust, always verify
- Session Management: Appropriate timeouts and expiration
- Rate Limiting: Prevent brute force attacks
2.4 ROLE-BASED ACCESS CONTROL (RBAC)
Definition
RBAC is an access control model where permissions are assigned to roles, and users are assigned to roles. It simplifies access management by separating user assignment from permission assignment.
Core Concepts
1. Roles
- Definition: Job functions or responsibilities within the organization
- Characteristics: Named, defined, reusable
- Examples: Administrator, Developer, Auditor, Student, Faculty
2. Permissions
- Definition: Authorization to perform specific actions on resources
- Scope: Actions (read, write, delete, execute) on resources (files, services, APIs)
3. Users
- Definition: Individuals or entities that access the system
- Assignment: Users are assigned to roles
4. Sessions
- Definition: User’s active session with assigned roles
- Activation: Users may activate subset of roles
RBAC Models
Flat RBAC
- Simple, no hierarchy
- Users directly assigned to roles
- Suitable for small organizations
Hierarchical RBAC
- Roles inherit permissions from parent roles
- Organizational structure reflected
- Easier administration
ORGANIZATIONAL ROLE HIERARCHY
CEO
├── VP Engineering
│ ├── Engineering Manager
│ │ ├── Senior Engineer
│ │ └── Junior Engineer
│ └── Architect
├── VP Operations
│ ├── Operations Manager
│ │ ├── System Administrator
│ │ └── Network Engineer
│ └── Security Officer
└── VP Finance
├── Finance Manager
│ ├── Accountant
│ └── Auditor
└── Compliance OfficerRBAC Components
1. Users
- Definition: Entities accessing the system
- Identity: Unique identifier, credentials
- Attributes: Department, location, job title
2. Roles
- Definition: Collection of permissions
- Structure: Can be hierarchical
- Lifecycle: Created, modified, deleted based on business needs
3. Permissions
- Definition: Authorization to perform actions
- Structure: Resource + Operation
- Examples: S3:GetObject, EC2:TerminateInstances
4. Role Assignments
- Definition: Mapping between users and roles
- Constraints: Mutually exclusive roles, prerequisites
- Approval: Workflow-based assignment
RBAC Policy Example
ROLE: Exam_Administrator
PERMISSIONS:
- Create_Exam:
Resource: ExamDatabase
Action: INSERT
- Modify_Exam:
Resource: ExamDatabase
Action: UPDATE
Condition: status = 'DRAFT'
- Grade_Exam:
Resource: ExamDatabase
Action: UPDATE
Condition: status = 'SUBMITTED'
- View_Results:
Resource: ExamDatabase
Action: SELECT
Condition: exam_completed = TRUE
CONSTRAINTS:
- MFA required for all actions
- Cannot grade own exam
- All actions logged
- Session timeout: 30 minutesRBAC Implementation in Cloud
AWS IAM RBAC Example
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::student-documents/*",
"arn:aws:s3:::student-documents"
]
},
{
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::student-documents/*"
}
]
}Azure RBAC Example
{
"properties": {
"roleName": "Exam Grader",
"description": "Can view and grade student exams",
"assignableScopes": [
"/subscriptions/xxx/resourceGroups/exam-env"
],
"permissions": [
{
"actions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/read",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
],
"notActions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/delete"
]
}
]
}
}RBAC Best Practices
1. Role Design
| Practice | Description |
|---|---|
| Least Privilege | Grant only needed permissions |
| Segregation of Duties | Prevent conflicts of interest |
| Role Minimization | Use minimal number of roles |
| Descriptive Names | Clear role purpose and scope |
| Regular Review | Review role relevance |
2. Role Assignment
| Practice | Description |
|---|---|
| Automation | Use scripts for bulk assignments |
| Approval Workflow | Management approval for elevated access |
| Temporary Assignment | Time-bound roles when possible |
| Supervised Access | Monitor privileged access |
| Just-in-Time | Grant access only when needed |
3. Role Management
| Practice | Description |
|---|---|
| Centralized Control | Single source of truth |
| Version Control | Track role definition changes |
| Audit Trail | Log all role changes |
| Testing | Validate roles before deployment |
| Documentation | Clear role descriptions |
RBAC in Multi-Tenant Environments
Tenant-Aware Roles
├── Tenant Admin
│ └── Manage resources within tenant
├── Tenant User
│ └── Access own tenant resources
├── Tenant Auditor
│ └── View logs within tenant
└── Global Admin
└── Manage all tenantsAdvantages and Limitations
Advantages
- Simplified Administration: Manage roles instead of individuals
- Consistency: Uniform access across systems
- Scalability: Works for large organizations
- Compliance: Easier to audit and demonstrate
- Separation of Duties: Clear boundaries
Limitations
- Role Proliferation: Too many roles become unmanageable
- Static: Changes require role updates
- Context Blind: Doesn’t consider dynamic attributes
- Overlapping: Potential for excessive permissions
2.5 MULTI-FACTOR AUTHENTICATION (MFA)
Definition
MFA requires users to provide two or more verification factors to gain access. It significantly reduces the risk of unauthorized access even if passwords are compromised.
Authentication Factors
1. Knowledge Factor (Something You Know)
- Examples: Password, PIN, security questions, passphrase
- Security Level: Low to Medium
- Risks: Forgotten, stolen, guessed
- Best Practices: Strong passwords, regular updates
2. Possession Factor (Something You Have)
- Examples: Smartphone, hardware token, smart card, USB key
- Security Level: High
- Risks: Lost, stolen, duplicated
- Best Practices: Physical security, remote wipe capability
3. Inherence Factor (Something You Are)
- Examples: Fingerprint, facial recognition, iris scan, voice recognition
- Security Level: Very High
- Risks: Privacy concerns, false positives/negatives
- Best Practices: Backup authentication method
4. Location Factor (Somewhere You Are)
- Examples: GPS, IP address, network range
- Security Level: Contextual
- Risks: VPN/proxy bypass
- Best Practices: Used in combination with other factors
5. Behavior Factor (Something You Do)
- Examples: Keystroke dynamics, mouse movement, typing pattern
- Security Level: Additional security
- Risks: Behavioral changes
- Best Practices: Continuous monitoring
MFA Methods
| Method | Factors | Security Level | User Convenience |
|---|---|---|---|
| SMS OTP | Password + SMS Code | Medium | High |
| Authenticator App | Password + Time-based Code | High | High |
| Hardware Token | Password + Physical Token | Very High | Medium |
| Biometric | Password + Fingerprint/Face | Very High | Very High |
| Email OTP | Password + Email Code | Low-Medium | High |
| Push Notification | Password + App Approval | High | Very High |
| FIDO/U2F | Password + Hardware Key | Very High | High |
TOTP (Time-Based One-Time Password)
TOTP GENERATION FLOW
SECRET KEY (shared)
│
▼
┌─────────────────────────────────────┐
│ HMAC-SHA1(secret, current_time) │
│ │
│ current_time = floor(UnixTime/30) │
└─────────────────────────────────────┘
│
▼
DYNAMIC TRUNCATION
│
▼
6-DIGIT CODE (e.g., 456789)
│
▼
USER ENTERS CODE
│
▼
VERIFICATION AT SERVERMFA Implementation in Cloud
AWS MFA Configuration
Root User Account
├── Virtual MFA Device
│ ├── Google Authenticator
│ ├── Authy
│ └── AWS Authenticator
├── Hardware MFA Device
│ ├── Gemalto
│ └── YubiKey
└── Security Keys
└── FIDO2
IAM Users
├── Optional MFA
├── MFA Delete Protection
└── MFA Age PolicyAzure AD MFA Configuration
Azure AD Multi-Factor Authentication
├── Conditional Access Policies
│ ├── Require MFA for all users
│ ├── Require MFA for admin roles
│ ├── Require MFA for specific applications
│ └── Location-based policies
├── Authentication Methods
│ ├── Microsoft Authenticator
│ ├── Phone call/SMS
│ ├── FIDO2 security keys
│ ├── OATH hardware tokens
│ └── Temporary Access Pass
└── Risk-based MFA
├── User risk level
├── Sign-in risk level
└── Real-time risk detectionAdaptive MFA (Risk-Based Approach)
ACCESS REQUEST
│
▼
RISK ASSESSMENT
├── User Risk (Low/Medium/High)
│ ├── Login pattern
│ ├── Device reputation
│ └── Location history
├── Context Risk
│ ├── New location
│ ├── New device
│ └── Unusual time
└── Application Risk
├── Sensitive data
├── Administrative access
└── Financial operations
│
▼
DECISION
├── No MFA (Low Risk)
├── Standard MFA (Medium Risk)
├── Strong MFA (High Risk)
└── Block Access (Critical Risk)Best Practices for MFA
1. Implementation Best Practices
| Practice | Description |
|---|---|
| Mandatory MFA | Require for all users, especially admins |
| Multiple Methods | Provide backup options |
| Easy Setup | Simple onboarding process |
| User Education | Train users on MFA use |
| Recovery Process | Secure account recovery |
2. Security Best Practices
| Practice | Description |
|---|---|
| Secure Backup Codes | Store backup codes safely |
| Prevent Man-in-the-Middle | Use TLS for all communication |
| Rate Limiting | Prevent brute force attempts |
| Session Management | Proper token expiration |
| Monitor MFA Changes | Alert on MFA modifications |
3. User Experience Best Practices
| Practice | Description |
|---|---|
| Remember Trusted Devices | Reduce MFA frequency |
| Grace Periods | Allow occasional exceptions |
| Progressive Enforcement | Gradual implementation |
| Feedback | Clear success/failure messages |
| Support | Easy access to help |
2.6 SINGLE SIGN-ON (SSO)
Definition
SSO allows users to authenticate once and access multiple applications without re-entering credentials. It improves user experience while maintaining security.
SSO Architecture
Basic SSO Components
┌─────────────────────────────────────────────────────────────┐
│ SSO ARCHITECTURE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌──────────────────┐ │
│ │ USER │────▶│ SSO PROVIDER │ │
│ │ (Browser) │ │ (Identity Hub) │ │
│ └─────────────┘ └──────────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌───────────────────────────┐ │
│ │ │ SERVICE PROVIDERS │ │
│ │ ├───────────┬───────────────┤ │
│ └────▶│App 1 │App 2 │ │
│ │(SaaS) │(Internal) │ │
│ └───────────┴───────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘SSO Protocols
1. SAML (Security Assertion Markup Language)
| Aspect | Details |
|---|---|
| Purpose | Web browser SSO |
| Format | XML-based assertions |
| Components | Identity Provider (IdP), Service Provider (SP) |
| Flow | User → SP → IdP → SP → Resource |
| Use Cases | Enterprise applications, SaaS |
SAML Flow:
1. User requests access to SP
2. SP redirects to IdP with SAML request
3. User authenticates at IdP
4. IdP issues SAML assertion
5. User redirected to SP with assertion
6. SP validates assertion and grants access
7. Session created at SP2. OAuth 2.0
| Aspect | Details |
|---|---|
| Purpose | Authorization framework |
| Format | Tokens (JSON) |
| Components | Resource Owner, Client, Authorization Server, Resource Server |
| Flows | Authorization Code, Implicit, Client Credentials, Resource Owner |
| Use Cases | API access, delegated permissions |
OAuth 2.0 Flow:
1. User requests access to resource
2. Authorization Server authenticates user
3. User grants/consents to permissions
4. Authorization Server issues access token
5. Client presents token to Resource Server
6. Resource Server validates token
7. Access granted to resource3. OpenID Connect (OIDC)
| Aspect | Details |
|---|---|
| Purpose | Identity layer on OAuth 2.0 |
| Format | ID Token (JWT) |
| Components | RP (Relying Party), OP (OpenID Provider) |
| Use Cases | Authentication for modern applications |
OIDC Flow:
1. User requests authentication
2. OP authenticates user
3. OP issues ID Token (JWT) + Access Token
4. Client validates ID Token
5. Client can request user info
6. User authenticated4. WS-Federation
| Aspect | Details |
|---|---|
| Purpose | Web services federation |
| Format | XML |
| Components | STS (Security Token Service), RP (Relying Party) |
| Use Cases | Windows-based environments |
SSO vs Traditional Authentication
| Aspect | Traditional | SSO |
|---|---|---|
| Login Count | Multiple | Once |
| Password Management | Each app | Centralized |
| User Experience | Friction | Seamless |
| Security | Varies | Consistent |
| Administration | Per app | Centralized |
| Audit Trail | Disjointed | Unified |
SSO Implementation in Cloud
AWS SSO
AWS Single Sign-On
├── Identity Sources
│ ├── AWS SSO Directory
│ ├── Active Directory
│ └── External IdP (SAML 2.0)
├── Applications
│ ├── AWS Accounts
│ ├── Third-party SaaS
│ └── Custom apps (SAML/OIDC)
├── User Management
│ ├── Groups
│ ├── Permission sets
│ └── User provisioning (SCIM)
└── Monitoring
├── Audit logs
├── CloudTrail integration
└── Usage metricsAzure AD SSO
Azure AD Single Sign-On
├── Enterprise Applications
│ ├── Gallery apps
│ ├── Non-gallery apps
│ └── Custom apps
├── Authentication Methods
│ ├── SAML
│ ├── OpenID Connect
│ ├── Password-based
│ └── Linked SSO
├── Access Management
│ ├── Conditional Access
│ ├── Identity Protection
│ └── Privileged Identity Management
└── Integration
├── Azure AD Connect
├── Application Proxy
└── SCIM provisioningBenefits of SSO
For Users
- Reduced Password Fatigue: Only one password to remember
- Improved Productivity: Less time logging in
- Better Experience: Seamless access to applications
- Fewer Password Resets: Less frustration
For Administrators
- Centralized Management: Single identity source
- Consistent Policy: Uniform enforcement
- Simplified Provisioning: Automated access
- Better Compliance: Comprehensive auditing
For Security
- Stronger Authentication: MFA implementation
- Reduced Attack Surface: Fewer credentials to protect
- Centralized Monitoring: One place to see access
- Faster Incident Response: Quick revocation
SSO Security Considerations
| Risk | Mitigation |
|---|---|
| Single Point of Failure | Redundancy, backup authentication |
| Credentials Theft | MFA, risk-based authentication |
| Session Hijacking | Short-lived sessions, secure cookies |
| Privilege Creep | Regular access reviews |
| Insider Threats | Monitoring, privileged access management |
Best Practices for SSO
- Use Modern Protocols: SAML 2.0, OIDC over legacy SAML 1.1
- Implement MFA: Always require MFA for SSO
- Monitor Login Activity: Detect unusual patterns
- Regular Certification: Review access periodically
- Secure Session Management: Proper timeout configurations
- Use Just-in-Time Provisioning: Create accounts on first login
- Enable Single Logout: Also support logging out of all applications
- Test Recovery Scenarios: Have backup authentication methods
2.7 IDENTITY FEDERATION
Definition
Identity federation establishes trust relationships between organizations to enable identity and authentication sharing across security domains. It allows users from one organization to access resources in another without separate credentials.
Federation Trust Model
ORGANIZATION A (Identity Provider)
│
│ ESTABLISH TRUST
│ (Mutual Trust Agreement)
▼
ORGANIZATION B (Service Provider)
│
│ USER FROM ORG A
▼
ACCESS TO ORG B SERVICESFederation Types
| Type | Description | Example |
|---|---|---|
| Cross-Organization | Different companies | Enterprise partners |
| Cross-Cloud | Multiple cloud providers | AWS + Azure + GCP |
| Cross-Platform | Different platforms | SaaS + On-premises |
| Cross-Domain | Security domains | Department boundaries |
Federation Standards
1. SAML 2.0 Federation
Components:
- Identity Provider (IdP): Authenticates users
- Service Provider (SP): Provides services
- Metadata: Configuration and trust information
Trust Establishment:
1. IdP publishes metadata (entityID, endpoints, certificates)
2. SP imports IdP metadata
3. SP publishes metadata
4. IdP imports SP metadata
5. Trust established for:
- Authentication requests
- Assertion validation
- Signature verification2. OAuth 2.0 Federation
Use Cases:
- Delegated access between applications
- API access across organizations
- Social login integration
Key Concepts:
- Authorization server
- Resource server
- Client application
- Access tokens
- Refresh tokens
3. OpenID Connect Federation
Extensions:
- Federation trust negotiation
- Dynamic registration
- Trust frameworks
- Cross-provider verification
Benefits:
- Interoperability
- Dynamic trust establishment
- Consumer-driven identity
4. WS-Federation
Features:
- Browser-based SSO
- Security token exchange
- Trust negotiation
- Relying party trust
Protocols:
- WS-Trust (token exchange)
- WS-Federation (federation metadata)
- WS-Security (message security)
Federation Implementation
AWS Identity Federation
AWS Identity Federation
├── Federation Types
│ ├── SAML 2.0 Federation
│ │ ├── AWS Single Account
│ │ └── Multiple Accounts (Custom SAML)
│ ├── Web Identity Federation
│ │ ├── Cognito User Pools
│ │ ├── Amazon (Login with Amazon)
│ │ ├── Facebook
│ │ └── Google
│ └── Custom Identity Broker
│ └── API-based federation
├── Federation Mechanisms
│ ├── SAML Assertions
│ ├── IAM Roles (AssumeRoleWithSAML)
│ ├── IAM Roles (AssumeRoleWithWebIdentity)
│ └── STS (Security Token Service)
└── Use Cases
├── Enterprise SSO
├── Mobile Apps
├── Partner Access
└── Customer IAMAWS Federation Flow:
1. User authenticates with Corporate IdP
2. IdP issues SAML assertion
3. User requests access to AWS
4. SAML assertion presented to AWS STS
5. STS validates assertion
6. STS issues temporary credentials
7. User accesses AWS resources
8. Credentials expire after 1-12 hoursAzure AD Federation
Azure AD Federation (Continued)
├── Federation Features
│ ├── Single Sign-On
│ ├── Conditional Access
│ ├── Self-service password reset
│ ├── Group-based access
│ └── Seamless SSO
├── Authentication Protocols
│ ├── SAML 2.0
│ ├── WS-Federation
│ ├── OAuth 2.0
│ └── OpenID Connect
└── Benefits
├── Centralized identity management
├── Consistent user experience
├── Enhanced security
└── Reduced administrative overheadAzure AD Federation Flow:
USER (Corporate Network)
│
▼
┌─────────────────────────────────────┐
│ 1. Access Azure AD Application │
│ (e.g., Office 365) │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 2. Redirect to Corporate AD FS │
│ (Federation Server) │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 3. Authenticate with Corporate ID │
│ (Domain credentials + MFA) │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 4. AD FS Issues SAML Token │
│ (Signed and encrypted) │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 5. Token Presented to Azure AD │
│ (SAML assertion validation) │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 6. Access Granted to Resource │
│ (Seamless SSO experience) │
└─────────────────────────────────────┘Google Cloud Identity Federation
Google Cloud Federation
├── Identity Providers
│ ├── Google Workspace
│ ├── SAML 2.0 Providers
│ ├── OIDC Providers
│ └── Social Providers
├── Workforce Identity Federation
│ ├── SAML federation
│ ├── OIDC federation
│ └── Attribute mapping
├── Workload Identity Federation
│ ├── Google Cloud to AWS
│ ├── AWS to Google Cloud
│ └── Azure to Google Cloud
└── Use Cases
├── External user access
├── Partner collaboration
├── Cross-cloud workloads
└── Multi-cloud strategiesFederation Benefits
1. User Experience
- Seamless Access: No multiple login prompts
- Single Credential: One identity for multiple services
- Consistent UI: Uniform authentication experience
- Faster Access: Reduced login friction
2. Security
- Centralized Control: One place for security policies
- Consistent Enforcement: Uniform security everywhere
- Improved Compliance: Better audit trails
- Easier Revocation: One place to revoke access
3. Administration
- Simplified Management: One identity source
- Reduced Costs: No duplicate systems
- Better Visibility: Complete audit trail
- Standardization: Common authentication patterns
4. Business Benefits
- Agility: Faster partner onboarding
- Scalability: Support for growth
- Cost Reduction: Lower management costs
- Competitive Advantage: Better user experience
Federation Security Considerations
| Challenge | Mitigation |
|---|---|
| Trust Management | Digital signatures, certificates |
| Spoofing Attacks | Metadata validation, endpoint verification |
| Token Theft | Short-lived tokens, encryption |
| Session Hijacking | Secure cookies, HTTPS |
| Identity Propagation | Claims-based authorization |
| Privacy Concerns | Minimal data sharing, user consent |
Best Practices for Identity Federation
- Use Strong Authentication: MFA at Identity Provider
- Secure Federation Metadata: Validate and protect metadata
- Limit Trust Relationships: Only federate when necessary
- Regular Certificate Rotation: Update federation certificates
- Monitor Federation Activity: Log and alert on suspicious access
- Use Claims-Based Authorization: Fine-grained access control
- Implement Session Management: Appropriate timeouts
- Test Federation Regularly: Validate trust relationships
- Document Federation Agreements: Clear responsibilities
- Plan for Revocation: Quick response to compromises
2.8 IDENTITY PROVIDERS AND SERVICE CONSUMERS
Definition
The identity management ecosystem consists of Identity Providers (IdPs) that authenticate users and Service Providers (SPs) that consume identity information to provide access.
Identity Provider (IdP)
Definition
An Identity Provider is a system that creates, maintains, and manages identity information and provides authentication services to service providers.
Types of Identity Providers
| Type | Description | Examples |
|---|---|---|
| Enterprise IdP | For organizations | Active Directory, LDAP, Oracle IDM |
| Cloud IdP | Cloud-based identity | Azure AD, AWS IAM, Google Cloud IAM |
| Social IdP | Social media identity | Google, Facebook, LinkedIn |
| Federated IdP | Cross-domain trust | InCommon, eduGAIN |
| Customer IdP | B2C identity | Auth0, Okta, ForgeRock |
IdP Functions
IDENTITY PROVIDER FUNCTIONS
├── Identity Management
│ ├── User provisioning
│ ├── User lifecycle management
│ ├── Identity repository
│ └── Attribute management
├── Authentication Services
│ ├── Authentication verification
│ ├── Credential validation
│ ├── MFA enforcement
│ └── Password management
├── Federation Services
│ ├── SAML assertions
│ ├── Token issuance
│ ├── Trust management
│ └── Metadata exchange
└── Integration Services
├── API management
├── SCIM provisioning
├── Event notifications
└── Custom extensionsService Provider (SP)
Definition
A Service Provider is a system that provides services and relies on an Identity Provider for authentication.
SP Functions
SERVICE PROVIDER FUNCTIONS
├── Authentication Processing
│ ├── Redirect users to IdP
│ ├── Accept authentication assertions
│ ├── Validate assertion signatures
│ └── Create local sessions
├── Authorization
│ ├── Evaluate access policies
│ ├── Apply permissions
│ ├── Enforce access controls
│ └── Audit access events
├── User Experience
│ ├── Seamless login
│ ├── Session management
│ ├── Error handling
│ └── Logout processing
└── Integration
├── IdP metadata import
├── Certificate trust
├── Attribute mapping
└── Error handlingTrust Relationship
Trust Establishment Process
TRUST ESTABLISHMENT PROCESS
┌─────────────────────┐ ┌─────────────────────┐
│ IDENTITY PROVIDER │────▶│ SERVICE PROVIDER │
└─────────────────────┘ └─────────────────────┘
│ │
│ 1. Exchange Metadata │
│ 2. Share Certificates │
│ 3. Define Attributes │
│ 4. Test Connectivity │
▼ ▼
┌─────────────────────────────────────────────────┐
│ TRUST RELATIONSHIP ESTABLISHED │
├─────────────────────────────────────────────────┤
│ • Metadata validated and configured │
│ • Certificate thumbprints exchanged │
│ • Attribute mapping defined │
│ • SSO endpoints configured │
│ • Error handling procedures defined │
│ • Testing and verification completed │
└─────────────────────────────────────────────────┘Trust Components
| Component | Description | Security Consideration |
|---|---|---|
| Metadata | IdP and SP configuration | Validate authenticity |
| Certificates | Digital signatures and encryption | Regular rotation |
| Assertions | Identity statements | Validate signatures |
| Attributes | User information | Minimal data sharing |
| Endpoints | Communication URLs | Validate and secure |
SAML 2.0 - IdP and SP Roles
SAML Federation Model
SAML FEDERATION MODEL
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────┐ SAML Request ┌─────────────────┐│
│ │ │───────────────────▶│ ││
│ │ IDENTITY │ │ SERVICE ││
│ │ PROVIDER │◀───────────────────│ PROVIDER ││
│ │ │ SAML Response │ ││
│ │ (IdP) │ │ (SP) ││
│ │ │ AuthnRequest │ ││
│ │ │◀───────────────────│ ││
│ │ │ │ ││
│ └─────────────────┘ SAML Assertion ──────────────────┘│
│ │ (Subject, Attributes) │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────┐│
│ │ USER AGENT (Browser) ││
│ └────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘Attribute Exchange Example
ATTRIBUTE EXCHANGE EXAMPLE
Identity Provider Attributes
├── Subject ID: john.doe@university.edu
├── eduPersonAffiliation: student
├── eduPersonPrimaryAffiliation: student
├── displayName: John Doe
├── mail: john.doe@university.edu
├── eduPersonScopedAffiliation: student@university.edu
└── employeeNumber: 2024-12345
Service Provider Attributes
├── Local Username: jdoe
├── Department: Computer Science
├── Role: Student
├── Enrollment Status: Active
├── Courses: CS101, CS201
└── Access Level: StandardCloud IAM as Identity Provider
AWS IAM as IdP
AWS IAM IDENTITY PROVIDER
├── Identity Sources
│ ├── IAM Users (Built-in)
│ ├── IAM Roles (for services)
│ ├── SAML Providers
│ ├── OIDC Providers
│ └── Web Identity Providers
├── Authentication
│ ├── Username/Password
│ ├── Access Keys
│ ├── MFA
│ └── Temporary credentials (STS)
├── Authorization
│ ├── IAM Policies
│ ├── Permission Boundaries
│ ├── Service Control Policies
│ └── Resource Policies
└── Federation
├── Enterprise SSO
├── Identity Center
├── Cognito (customer identity)
└── External IdPsAzure AD as IdP
AZURE AD IDENTITY PROVIDER
├── Identity Types
│ ├── User identities
│ ├── Application identities
│ ├── Managed identities
│ └── External identities
├── Authentication
│ ├── Password authentication
│ ├── Passwordless authentication
│ ├── Federation (AD FS)
│ └── External providers
├── Authorization
│ ├── Azure RBAC
│ ├── Conditional Access
│ ├── Identity Protection
│ └── Privileged Identity Management
└── Integration
├── Application Gallery
├── Custom apps (SAML/OIDC)
├── Legacy apps (Application Proxy)
└── API managementBest Practices for IdP and SP Integration
For Identity Providers
- Centralized Management: Single source of truth
- Strong Authentication: Implement MFA
- Attribute Standardization: Use standard schemas
- Metadata Protection: Secure IdP metadata
- Regular Audits: Review identity data
- Automated Provisioning: SCIM compliance
- Monitor for Anomalies: Detect suspicious activity
- Plan for Scalability: Handle growth
For Service Providers
- Trust Validation: Verify IdP trust
- Attribute Mapping: Define attribute usage
- Session Management: Appropriate timeouts
- Error Handling: Graceful failures
- Monitor Access: Track user access
- Regular Updates: Keep certificates current
- Test Integration: Validate federation
- Define Access Policies: Clear authorization rules
2.9 STORAGE ACCESS CONTROL OPTIONS
Overview
Storage access control ensures that only authorized users and services can access, modify, or delete stored data. Different storage types require different access control approaches.
Storage Types in Cloud
| Storage Type | Description | Examples |
|---|---|---|
| Object Storage | Unstructured data | AWS S3, Azure Blob, GCS |
| Block Storage | Raw storage volumes | AWS EBS, Azure Disk |
| File Storage | Network file systems | AWS EFS, Azure Files |
| Database Storage | Structured data | RDS, DynamoDB, Cosmos DB |
| Backup Storage | Backup and archive | AWS Backup, Azure Backup |
Access Control Mechanisms
1. Object Storage Access Control
AWS S3 Access Controls:
S3 ACCESS CONTROL HIERARCHY
┌─────────────────────────────────────────────────────┐
│ BUCKET LEVEL │
├─────────────────────────────────────────────────────┤
│ │ │ │
│ ▼ ▼ │
│ Bucket Policy IAM Policy │
│ (Resource-based) (User-based) │
│ └─────────────────┐ ┌─────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────┐ │
│ │ ACCESS │ │
│ │ DECISION │ │
│ └──────────────┘ │
│ │ │
│ ▼ │
├─────────────────────────────────────────────────────┤
│ OBJECT LEVEL │
├─────────────────────────────────────────────────────┤
│ │ │ │
│ ▼ ▼ │
│ ACL (Object) IAM Conditions │
│ (Legacy) (Fine-grained) │
│ │
└─────────────────────────────────────────────────────┘Access Control Types:
| Type | Description | Use Case |
|---|---|---|
| IAM Policies | Identity-based | General user access |
| Bucket Policies | Resource-based | Public access, cross-account |
| ACLs | Legacy access | Simple object permissions |
| Presigned URLs | Temporary access | Time-limited access |
| Access Points | Application-specific | Large-scale access |
Example S3 Bucket Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowStudentAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/Students"
},
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::student-data/*",
"arn:aws:s3:::student-data"
],
"Condition": {
"StringEquals": {
"s3:prefix": "${aws:username}/*"
}
}
},
{
"Sid": "DenyDelete",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::student-data/*"
}
]
}2. Block Storage Access Control
AWS EBS Access:
EBS ACCESS CONTROL
Volume Level
├── Encryption
│ ├── Default encryption
│ ├── Customer-managed keys
│ └── AWS-managed keys
├── IAM Permissions
│ ├── Attach/Detach volume
│ ├── Create snapshot
│ ├── Delete volume
│ └── Modify volume
├── Network Access
│ ├── EC2 instance association
│ ├── Security groups
│ └── Subnet placement
└── Snapshot Access
├── Create snapshot
├── Share snapshot
├── Copy snapshot
└── Permission management3. File Storage Access Control
AWS EFS Access:
EFS ACCESS CONTROL
File System Level
├── IAM Authorization
│ ├── IAM policies
│ ├── IAM roles
│ └── Access points
├── Network Security
│ ├── VPC placement
│ ├── Security groups
│ ├── Mount targets
│ └── Network ACLs
├── POSIX Permissions
│ ├── Owner/Group
│ ├── Read/Write/Execute
│ ├── Sticky bit
│ └── SUID/SGID
└── Access Points
├── Root directory
├── POSIX user/group
└── POSIX permissions4. Database Storage Access Control
DATABASE ACCESS CONTROL
Network Layer
├── Private endpoints
├── Security groups
├── VPC placement
└── IP whitelisting
Authentication Layer
├── IAM authentication
├── Password authentication
├── Certificate-based
└── Integrated authentication
Authorization Layer
├── Database roles
├── Granular permissions
│ ├── SELECT, INSERT, UPDATE, DELETE
│ └── CREATE, ALTER, DROP
├── Row-level security
├── Column-level security
└── Stored procedures
Audit Layer
├── Connection logs
├── Query logs
├── DDL logs
└── Access logsRow-Level Security Example (SQL):
-- Row Level Security for Multi-Tenant Database
CREATE POLICY tenant_isolation ON student_records
USING (tenant_id = current_setting('app.tenant_id')::text);
-- Column-Level Security
CREATE VIEW student_data AS
SELECT
id,
name,
CASE
WHEN has_privilege('full_access')
THEN ssn
ELSE 'XXX-XX-' || RIGHT(ssn, 4)
END AS ssn,
email,
enrollment_date
FROM students;Storage Access Control Best Practices
1. General Best Practices
| Practice | Description |
|---|---|
| Least Privilege | Grant minimal required access |
| Encryption Everywhere | Encrypt at rest and in transit |
| Private Access | Use private endpoints when possible |
| Regular Audits | Review access permissions |
| Lifecycle Rules | Automate data management |
| Versioning | Enable for recovery |
| Immutable Backups | Protect against ransomware |
2. Object Storage Best Practices
| Practice | Description |
|---|---|
| Disable Public Access | Block public bucket access |
| Use Access Points | Simplify access management |
| Require Encryption | Encrypt all stored objects |
| Implement Lifecycle | Automate transitions/deletion |
| Enable Logging | Track access patterns |
| Use Pre-signed URLs | Temporary access only |
3. Database Storage Best Practices
| Practice | Description |
|---|---|
| Network Isolation | Private subnets only |
| Strong Authentication | Use IAM when possible |
| Granular Permissions | Row/column-level security |
| Regular Backups | Point-in-time recovery |
| Audit Logging | Track all database activity |
| Encryption | Encrypt at rest and in transit |
2.10 NETWORK ACCESS CONTROL OPTIONS
Overview
Network access control (NAC) regulates who and what can connect to network resources. In cloud environments, NAC protects against unauthorized access, reduces attack surface, and enforces security policies.
Network Access Control Mechanisms
1. Security Groups
Definition: Virtual firewalls that control inbound and outbound traffic at the instance level.
SECURITY GROUP RULES
┌─────────────────────────────────────────────────────────┐
│ SECURITY GROUP (Web-Tier) │
├─────────────────────────────────────────────────────────┤
│ INBOUND RULES │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Source │ Protocol │ Port │ Description │ │
│ ├─────────────┼──────────┼──────┼──────────────────┤ │
│ │ 0.0.0.0/0 │ TCP │ 443 │ HTTPS Traffic │ │
│ │ 0.0.0.0/0 │ TCP │ 80 │ HTTP Traffic │ │
│ │ SG-App │ TCP │ 8080 │ App Communication │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ OUTBOUND RULES │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Destination │ Protocol │ Port │ Description │ │
│ ├───────────────┼──────────┼──────┼──────────────────┤ │
│ │ 0.0.0.0/0 │ TCP │ 443 │ Outbound HTTPS │ │
│ │ 0.0.0.0/0 │ TCP │ 53 │ DNS Queries │ │
│ │ SG-Database │ TCP │ 3306 │ Database Access │ │
│ └────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘2. Network ACLs (NACLs)
Definition: Stateless firewalls that control traffic at the subnet level.
Comparison: Security Groups vs NACLs:
| Aspect | Security Groups | Network ACLs |
|---|---|---|
| Level | Instance | Subnet |
| State | Stateful | Stateless |
| Rules | Allow only | Allow and Deny |
| Order | Evaluated all | Evaluated in order |
| Rules Limit | 60 per group | 20 per NACL |
| Association | Multiple instances | Multiple subnets |
3. VPC/VNet Segmentation
Components:
VPC SEGMENTATION
┌─────────────────────────────────────────────────────────┐
│ VPC (10.0.0.0/16) │
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ PUBLIC SUBNET (10.0.1.0/24) │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Load │ │ Web │ │ Web │ │ │
│ │ │ Balancer │ │ Server 1│ │ Server 2│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ Internet Gateway (0.0.0.0/0 → IGW) │ │
│ └───────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ PRIVATE SUBNET (10.0.2.0/24) │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ App │ │ App │ │ App │ │ │
│ │ │ Server 1│ │ Server 2│ │ Server 3│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ NAT Gateway (For outbound internet) │ │
│ └───────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ DATABASE SUBNET (10.0.3.0/24) │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Database│ │ Database│ │ Backup │ │ │
│ │ │ Primary │ │ Replica │ │ Storage │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ No Internet Gateway │ │
│ └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘4. Private Endpoints
Definition: Private endpoints connect VPCs to supported Azure/AWS services using private IP addresses.
Benefits:
- Traffic stays on private network
- No internet exposure
- Enhanced security
- Simplified network architecture
Implementation:
PRIVATE ENDPOINT ARCHITECTURE
VPC A (10.0.0.0/16)
│
│ Private Endpoint
│ (10.0.1.100)
▼
┌─────────────────────────────────────────────────────────┐
│ MANAGED SERVICE │
│ ┌───────────────────────────────────────────────────┐ │
│ │ • Azure SQL Database │ │
│ │ • AWS S3 │ │
│ │ • Cloud Service APIs │ │
│ │ • Database Services │ │
│ └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘5. VPN and Private Connectivity
| Option | Description | Use Case |
|---|---|---|
| Site-to-Site VPN | Connect on-premises to cloud | Hybrid cloud |
| Direct Connect | Dedicated private connection | High bandwidth |
| VPN Gateway | Cloud VPN service | Secure connectivity |
| Client VPN | Individual user access | Remote workers |
| Transit Gateway | Hub-and-spoke connectivity | Large networks |
6. Web Application Firewall (WAF)
Protection Against:
WAF PROTECTION CAPABILITIES
┌─────────────────────────────────────────────────────────┐
│ WEB APPLICATION FIREWALL │
├─────────────────────────────────────────────────────────┤
│ OWASP Top 10 Protections │
│ ├── SQL Injection │
│ ├── Cross-Site Scripting (XSS) │
│ ├── Command Injection │
│ ├── Path Traversal │
│ ├── CSRF │
│ └── File Inclusion │
├─────────────────────────────────────────────────────────┤
│ Custom Rules │
│ ├── Rate limiting │
│ ├── IP whitelisting/blacklisting │
│ ├── Geo-blocking │
│ ├── Header validation │
│ └── Parameter validation │
├─────────────────────────────────────────────────────────┤
│ Bot Protection │
│ ├── Bot detection │
│ ├── Challenge mechanisms │
│ ├── Bot blocking │
│ └── Captcha integration │
└─────────────────────────────────────────────────────────┘7. DDoS Protection
Layered DDoS Protection:
DDOS PROTECTION LAYERS
Layer 1: Edge Protection (CDN)
├── Anycast network
├── Content caching
├── Traffic filtering
└── Geo-distribution
Layer 2: Network Layer Protection
├── Traffic scrubbing
├── Bandwidth monitoring
├── Packet filtering
└── Rate limiting
Layer 3: Application Layer Protection
├── Web Application Firewall
├── Rate-based rules
├── Signature-based filtering
└── Behavioral analysis
Layer 4: Resource Protection
├── Auto-scaling
├── Service quotas
├── Resource limits
└── Circuit breakersNetwork Access Control Best Practices
1. Design Best Practices
| Practice | Description |
|---|---|
| Least Privilege | Allow only required traffic |
| Segmentation | Separate network tiers |
| Micro-segmentation | Fine-grained controls |
| Defense in Depth | Multiple security layers |
| Zero Trust Network | Verify every request |
2. Implementation Best Practices
| Practice | Description |
|---|---|
| Private Subnets | Keep sensitive resources private |
| Restricted Security Groups | Minimal open ports |
| VPN Access | Secure remote access |
| Private Endpoints | No public exposure |
| Regular Audits | Review network rules |
3. Monitoring Best Practices
| Practice | Description |
|---|---|
| VPC Flow Logs | Track network traffic |
| Security Group Audits | Review rules |
| IDS/IPS | Threat detection |
| Anomaly Detection | Unusual traffic patterns |
| Compliance Checks | Policy enforcement |
2.11 OPERATING SYSTEM HARDENING AND MINIMIZATION
Overview
OS hardening reduces vulnerabilities by securing the operating system configuration. Minimization reduces attack surface by removing unnecessary components.
OS Hardening Principles
1. Principle of Least Functionality
- Remove unnecessary services
- Disable unused ports
- Uninstall unused applications
- Remove unnecessary user accounts
- Disable unnecessary protocols
2. Principle of Secure Configuration
- Strong default configurations
- Security baseline enforcement
- Regular security updates
- Configuration management
- Compliance verification
OS Hardening Areas
1. User Account Management
USER ACCOUNT SECURITY
Account Policies
├── Password Policy
│ ├── Minimum length: 12+ characters
│ ├── Complexity: Mix of characters
│ ├── Password history: 5+ passwords
│ ├── Maximum age: 30-90 days
│ └── Account lockout: 5 failed attempts
├── Account Management
│ ├── Disable guest accounts
│ ├── Remove default accounts
│ ├── Disable unused accounts
│ ├── Separate admin accounts
│ └── Regular account reviews
└── Privilege Management
├── Separate roles
├── Least privilege
├── Just-in-time access
├── Session recording
└── Audit logging2. File System and Access Control
FILE SYSTEM SECURITY
File Permissions
├── Read/Write/Execute restrictions
├── Ownership verification
├── Sticky bit on shared directories
├── SUID/SGID management
└── File integrity monitoring
Directory Protection
├── Root directory restrictions
├── User home directory permissions
├── Temporary directory security
├── System directory protection
└── Application directory isolation
File System Encryption
├── Full disk encryption
├── Partition encryption
├── File-level encryption
├── Encryption key management
└── Secure key storage3. Network Configuration
NETWORK HARDENING
Network Services
├── Disable unused services
├── Service-specific firewalls
├── Port monitoring
├── Protocol restrictions
└── Service binding control
Network Security Settings
├── TCP/IP stack hardening
├── DNS security
├── DHCP configuration
├── ARP protection
└── IPsec configuration
Network Monitoring
├── Network traffic logging
├── Intrusion detection
├── Anomaly detection
├── Performance monitoring
└── Security event logging4. System Services and Processes
SERVICE HARDENING
Service Management
├── Disable unnecessary services
├── Start services only when needed
├── Run with least privileges
├── Limit service accounts
└── Regular service reviews
Process Security
├── Process isolation
├── Memory protection
├── Resource limits
├── Privilege separation
└── Process monitoring
Application Security
├── Application whitelisting
├── Execution restrictions
├── Secure installation
├── Code signing
└── Runtime protection5. Logging and Monitoring
LOGGING CONFIGURATION
Log Types
├── System logs
├── Security logs
├── Application logs
├── Access logs
└── Audit logs
Log Configuration
├── Enable comprehensive logging
├── Set appropriate log levels
├── Define log rotation
├── Configure log retention
└── Secure log storage
Log Monitoring
├── Real-time monitoring
├── Alert generation
├── Security analytics
├── Compliance reporting
└── Incident investigationHardening Standards
1. CIS Benchmarks
CIS BENCHMARK CATEGORIES
For Linux/Unix Systems
├── Initial Setup
│ ├── Filesystem configuration
│ ├── Bootloader security
│ └── Kernel hardening
├── Services Configuration
│ ├── SSH hardening
│ ├── Network services
│ └── System services
├── Network Configuration
│ ├── IP forwarding
│ ├── Packet filtering
│ └── TCP/IP settings
├── Auditing and Logging
│ ├── Audit configuration
│ ├── Logging services
│ └── Log rotation
├── Access, Authentication, Authorization
│ ├── Password policies
│ ├── PAM configuration
│ └── SSH security
├── System Maintenance
│ ├── Software updates
│ ├── File integrity
│ └── Security reporting
└── System Hardening
├── Kernel parameters
├── File permissions
└── Security limits2. NIST Guidelines
NIST SP 800-123 (Guide to General Server Security):
NIST SERVER HARDENING GUIDELINES
Planning and Implementation
├── Security requirements definition
├── Risk assessment
├── Security controls selection
├── Implementation planning
└── Testing and validation
Security Controls
├── Access control
├── Audit and accountability
├── Identification and authentication
├── System and communications protection
├── System and information integrity
└── Configuration management
Maintenance
├── Patch management
├── Vulnerability scanning
├── Security monitoring
├── Incident response
└── Change managementMinimization Strategies
1. Remove Unnecessary Components
COMPONENT MINIMIZATION
Remove Unnecessary:
├── Services and daemons
├── Applications and packages
├── Libraries and dependencies
├── Protocols and features
└── User accounts and groups
Minimize Configuration:
├── Default configurations
├── Sample applications
├── Test scripts
├── Development tools
└── Debugging tools2. Minimal Installation
| Approach | Description | Use Case |
|---|---|---|
| Minimal ISO | Base OS only | Production servers |
| Slim Installation | Essential packages | Container images |
| Custom Build | Tailored packages | Specialized workloads |
| Base Image | Standard minimal | Consistent deployment |
3. Container/Image Minimization
CONTAINER MINIMIZATION
Base Image Selection
├── Alpine Linux (5MB)
├── Distroless (Google)
├── Ubuntu Core
├── BusyBox
└── Custom minimal images
Image Optimization
├── Remove package manager
├── Delete build dependencies
├── Remove temporary files
├── Minimize layers
├── Clean package caches
Security Hardening
├── Non-root user
├── Read-only filesystem
├── Resource limits
├── Capability dropping
└── No sensitive data in imageAutomation of Hardening
Ansible Hardening Example (Continued):
line:"{{ item.line }}"
loop:
-{regexp:'^PASS_MAX_DAYS',line:'PASS_MAX_DAYS 90'}
-{regexp:'^PASS_MIN_DAYS',line:'PASS_MIN_DAYS 7'}
-{regexp:'^PASS_WARN_AGE',line:'PASS_WARN_AGE 14'}
-name: Install security packages
apt:
name:
- fail2ban
- aide
- auditd
- rkhunter
state: present
-name: Configure kernel parameters
sysctl:
name:"{{ item.name }}"
value:"{{ item.value }}"
state: present
reload:yes
loop:
-{name:'net.ipv4.tcp_syncookies',value:'1'}
-{name:'net.ipv4.conf.all.rp_filter',value:'1'}
-{name:'net.ipv4.conf.default.rp_filter',value:'1'}
-{name:'net.ipv4.icmp_echo_ignore_all',value:'1'}
-name: Set file permissions
file:
path:"{{ item }}"
mode:'600'
loop:
- /etc/ssh/sshd_config
- /etc/shadow
- /etc/gshadow
handlers:
-name: restart sshd
service:
name: sshd
state: restartedOS Hardening Checklist for Exam
Linux/Unix Hardening Checklist
LINUX HARDENING CHECKLIST
[ ] BIOS/UEFI SECURITY
[ ] Boot password set
[ ] Secure boot enabled
[ ] Boot order restricted
[ ] USB ports disabled if not needed
[ ] SYSTEM CONFIGURATION
[ ] Latest security patches installed
[ ] Unnecessary services disabled
[ ] Unused network protocols disabled
[ ] System time synchronized (NTP)
[ ] USER ACCOUNTS
[ ] Default users removed/disabled
[ ] Guest account disabled
[ ] Strong password policy enforced
[ ] Login attempt limits set
[ ] sudo access restricted
[ ] No root SSH login allowed
[ ] FILE SYSTEM
[ ] Proper file permissions set
[ ] File integrity monitoring configured
[ ] /tmp and /var/tmp mounted with noexec
[ ] /home mounted with noexec,nosuid
[ ] NETWORK SECURITY
[ ] Firewall configured (iptables/ufw)
[ ] Unused ports closed
[ ] Network services restricted
[ ] SSH hardening completed
[ ] LOGGING
[ ] System logging enabled
[ ] Audit daemon configured
[ ] Log rotation configured
[ ] Remote logging setup
[ ] SECURITY TOOLS
[ ] Anti-malware installed
[ ] IDS/IPS configured
[ ] Vulnerability scanner setup
[ ] Monitoring agent installedWindows Hardening Checklist
WINDOWS SERVER HARDENING CHECKLIST
[ ] SECURITY POLICIES
[ ] Password policy configured
[ ] Account lockout policy set
[ ] Audit policy enabled
[ ] User rights assignment reviewed
[ ] USER MANAGEMENT
[ ] Local Administrator password changed
[ ] Guest account disabled
[ ] Local accounts with weak passwords identified
[ ] Admin accounts restricted
[ ] PATCH MANAGEMENT
[ ] Windows Update configured
[ ] Update schedule defined
[ ] Critical updates tested
[ ] Automatic updates configured
[ ] NETWORK SECURITY
[ ] Windows Firewall enabled
[ ] Inbound rules restricted
[ ] RDP secured (NLA required)
[ ] Unused services disabled
[ ] LOGGING
[ ] Event logs enabled
[ ] Audit log settings configured
[ ] Log size limits set
[ ] Centralized logging configured
[ ] SECURITY FEATURES
[ ] UAC enabled
[ ] DEP enabled
[ ] Windows Defender configured
[ ] Secure boot enabled2.12 VERIFIED AND MEASURED BOOT
Overview
Verified and measured boot are security technologies that establish a chain of trust from the hardware initialization through the operating system boot process, ensuring only trusted software is loaded.
Key Concepts for Exam
1. Trusted Boot Chain
TRUSTED BOOT CHAIN
┌─────────────────────────────────────────────────────────────┐
│ HARDWARE ROOT OF TRUST │
│ │
│ BIOS/UEFI Boot ROM (Immutable) │
│ └── Contains Hashing Algorithm and Public Key │
│ │ │
│ ▼ │
│ Boot Loader (GRUB/Windows Boot Manager) │
│ └── First stage signed by trusted key │
│ │ │
│ ▼ │
│ Kernel Image │
│ └── Signed by trusted authority │
│ │ │
│ ▼ │
│ Operating System Boot │
│ └── All modules and drivers verified │
│ │ │
│ ▼ │
│ Applications and Services │
│ └── Secure execution environment established │
│ │
└─────────────────────────────────────────────────────────────┘2. Secure Boot
Definition: A UEFI feature that ensures only signed, trusted operating system bootloaders can start.
Components:
- UEFI Firmware: Modern BIOS replacement
- Secure Boot Keys: Platform Key (PK), Key Exchange Key (KEK), Signature Database (db)
- Forbidden Signature Database (dbx): Blocked bootloaders
Secure Boot Process:
1. System Powers On
2. UEFI Firmware Initializes
3. Firmware verifies Platform Key (PK)
4. Firmware loads and verifies bootloader signature
├── Signature matched against db (allowed)
├── Signature matched against dbx (blocked)
└── Signature validated using PK/KEK
5. Bootloader loads and verifies kernel image
6. Kernel loads and verifies modules/drivers
7. OS boots with verified components
8. TPM measures each component (if available)3. Measured Boot
Definition: A process that records (measures) the hashes of all boot components in the TPM (Trusted Platform Module) to create a cryptographic chain of trust.
TPM (Trusted Platform Module):
- Dedicated cryptographic processor
- Secure storage for keys, passwords, certificates
- Platform integrity measurement
- Hardware root of trust
Measured Boot PCR (Platform Configuration Register) Values:
PCR[0] = SHA256(BIOS Code)
PCR[1] = SHA256(Boot Settings)
PCR[2-3] = Option ROM Code
PCR[4] = SHA256(Bootloader Code)
PCR[5] = SHA256(Bootloader Configuration)
PCR[6] = SHA256(Kernel Image)
PCR[7] = SHA256(Initramfs)
PCR[8-15] = SHA256(Critical System Files)4. Windows Trusted Boot Components
WINDOWS TRUSTED BOOT
SECURE BOOT
├── UEFI Firmware verification
└── Windows Boot Manager (bootmgfw.efi) - Signed by Microsoft
TRUSTED BOOT
├── Windows Kernel (ntoskrnl.exe) - Signed by Microsoft
├── Verified by Windows Boot Manager
└── Integrity checked against measured configuration
EARLY LAUNCH ANTI-MALWARE (ELAM)
├── Driver verification
├── Checked against known malware signatures
└── Logged for security monitoring
MEASURED BOOT
├── Complete Boot Measurements
├── Stored in TPM PCRs
└── Available for remote attestationBenefits of Verified and Measured Boot
| Benefit | Description |
|---|---|
| Prevent Malware | Block rootkits and bootkits |
| Integrity Assurance | Ensure system hasn’t been tampered |
| Remote Attestation | Verify system state remotely |
| Chain of Trust | Cryptographic trust establishment |
| Compliance Support | Meet regulatory requirements |
Key Management in Secure Boot
KEY MANAGEMENT IN SECURE BOOT
Platform Key (PK)
├── Owned by OEM/Platform Owner
├── Establishes ownership of system
└── Used to sign KEK
Key Exchange Key (KEK)
├── Owned by Microsoft/OEM
├── Used to sign db and dbx
└── Can be updated by PK owner
Signature Database (db)
├── Contains authorized signatures
├── Used to verify boot components
└── Updated by KEK
Forbidden Signature Database (dbx)
├── Contains revoked signatures
├── Blocks untrusted components
└── Prioritized over dbCloud Implementation
| Cloud Provider | Feature | Description |
|---|---|---|
| AWS Nitro System | Secure Boot | UEFI Secure Boot enabled by default |
| TPM 2.0 | Available for attestation | |
| Signed AMIs | Verified boot images | |
| Azure Trusted Launch | Secure Boot | UEFI Secure Boot |
| vTPM | Virtualized TPM for VMs | |
| Boot Integrity Monitoring | Continuous verification |
Exam Key Points
- Secure Boot ensures only signed bootloaders run
- Measured Boot records hashes in TPM
- TPM provides hardware root of trust
- Trusted Boot chain starts from immutable hardware
- Windows Trusted Boot includes Secure Boot, Trusted Boot, ELAM, Measured Boot
- Cloud providers offer Trusted Launch/Secure Boot features
2.13 INTRUSION DETECTION SYSTEMS (IDS)
Definition
An Intrusion Detection System (IDS) monitors network traffic or system activities for malicious activities or policy violations and alerts administrators when detected.
IDS Types
1. Host-Based IDS (HIDS)
Definition: Monitors individual hosts for suspicious activities.
HIDS Components:
HIDS COMPONENTS
System Call Monitoring
├── File system changes
├── Process execution
├── Registry changes (Windows)
├── System log analysis
└── Application logs
File Integrity Monitoring
├── Critical system files
├── Configuration files
├── Application binaries
└── User data files
Policy Enforcement
├── Security policy compliance
├── Usage patterns
├── Resource consumption
└── User activityHIDS Examples:
- OSSEC (Open Source)
- Tripwire (File Integrity)
- AIDE (Advanced Intrusion Detection Environment)
- Windows Defender
2. Network-Based IDS (NIDS)
Definition: Monitors network traffic for suspicious patterns.
NIDS Components:
NIDS COMPONENTS
Packet Sniffing
├── Packet capture
├── Protocol analysis
├── Payload inspection
└── Traffic reconstruction
Signature Detection
├── Known attack patterns
├── Vulnerability signatures
├── Protocol anomalies
└── Exploit attempts
Anomaly Detection
├── Baseline learning
├── Unusual traffic patterns
├── Behavioral analysis
└── Heuristic detectionNIDS Examples:
- Snort (Open Source)
- Suricata
- Zeek (formerly Bro)
- Cisco IDS/IPS
3. Network Behavior Analysis (NBA)
Definition: Analyzes network traffic to detect anomalous behavior.
NBA FUNCTIONALITY
Baseline Creation
├── Normal traffic patterns
├── Typical user behavior
├── Application usage
└── Network utilization
Anomaly Detection
├── Traffic volume spikes
├── Unusual protocol usage
├── Data exfiltration patterns
└── Command and control traffic
Threat Detection
├── Zero-day attacks
├── Advanced persistent threats
├── Insider threats
└── Compromised systems4. Protocol-Based IDS
| Protocol | Monitoring Focus |
|---|---|
| HTTP/HTTPS | Web attacks, SQL injection, XSS |
| DNS | Tunneling, domain generation algorithms |
| SMTP | Spam, phishing, malware attachments |
| FTP | Anomalous file transfers, brute force |
| SMB | Ransomware, lateral movement |
| SQL | Database attacks, injection |
IDS Detection Methods
1. Signature-Based Detection
Definition: Matches activities against known attack signatures.
| Aspect | Detail |
|---|---|
| Advantages | Low false positives, Fast detection, Known attack identification |
| Disadvantages | Cannot detect unknown attacks, Requires regular updates |
| Example | Pattern: .*UNION.*SELECT.* for SQL injection |
2. Anomaly-Based Detection
Definition: Detects deviations from normal behavior patterns.
| Aspect | Detail |
|---|---|
| Advantages | Can detect zero-day attacks, Adapts to environment |
| Disadvantages | Higher false positives, Complex configuration |
| Methods | Statistical analysis, Machine learning, Behavioral analysis |
3. Hybrid Detection
Definition: Combines signature and anomaly-based detection.
HYBRID DETECTION APPROACH
Signature Detection (Known attacks)
+
Anomaly Detection (Unknown attacks)
=
Correlation Engine
├── Combine detection methods
├── Reduce false positives
├── Enhance detection accuracy
└── Prioritize threatsIDS Components
| Component | Function |
|---|---|
| Sensor/Analyzer | Collects and analyzes data |
| Management Console | Centralized administration and monitoring |
| Database | Stores events, signatures, and logs |
| Alert System | Generates and distributes alerts |
IDS Implementation in Cloud
AWS IDS Solutions
| Service | Function |
|---|---|
| AWS GuardDuty | Threat detection, continuous monitoring |
| Amazon Detective | Security investigation, root cause analysis |
| AWS Security Hub | Security posture management, compliance checks |
| AWS Network Firewall | Network filtering, IPS capabilities |
Azure IDS Solutions
| Service | Function |
|---|---|
| Azure Security Center | Threat protection, vulnerability assessment |
| Azure Sentinel | SIEM, threat intelligence, automated response |
| Azure DDoS Protection | Traffic monitoring, attack mitigation |
| Azure Firewall | Network filtering, threat intelligence |
Exam Key Points
- IDS monitors and alerts, does NOT block
- HIDS monitors individual hosts
- NIDS monitors network traffic
- Signature-based detects known attacks
- Anomaly-based detects unknown/zero-day attacks
- Hybrid detection combines both approaches
- NBA analyzes behavior patterns
2.14 INTRUSION PREVENTION SYSTEMS (IPS)
Definition
An Intrusion Prevention System (IPS) builds upon IDS by not only detecting threats but also actively blocking or preventing them in real-time.
IDS vs IPS Comparison (IMPORTANT FOR EXAM)
| Aspect | IDS | IPS |
|---|---|---|
| Purpose | Detection | Prevention |
| Action | Alert only | Alert + Block |
| Location | Out-of-band | Inline (in traffic path) |
| Response | Passive | Active |
| Speed | Speed not critical | Must be very fast |
| Risk | Low | Medium (may block legitimate) |
IPS Types
1. Network-Based IPS (NIPS)
Definition: Inline device that monitors and blocks network threats.
NIPS ARCHITECTURE
┌─────────────────────────────────────────────────────────────┐
│ NIPS APPLIANCE │
│ │
│ INGRESS TRAFFIC │
│ ───────────────────────────────────────────────────────▶ │
│ │ │
│ ▼ │
│ Signature Detection Engine │
│ ├── Pattern matching │
│ ├── Protocol analysis │
│ └── Exploit detection │
│ │ │
│ ▼ │
│ Response Engine │
│ ├── Block traffic │
│ ├── Reset connections │
│ ├── Drop packets │
│ └── Alert generation │
│ │ │
│ ▼ │
│ EGRESS TRAFFIC │
│ ───────────────────────────────────────────────────────▶ │
│ │
└─────────────────────────────────────────────────────────────┘2. Host-Based IPS (HIPS)
Definition: Software installed on hosts to monitor and prevent malicious activities.
HIPS FUNCTIONS
System Call Interception
├── Monitor process execution
├── Check system calls
└── Block unauthorized actions
File System Protection
├── File integrity monitoring
├── File access control
└── Directory protection
Application Control
├── Application whitelisting
├── Execution control
└── Process monitoring
Behavior Blocking
├── Anomalous behavior detection
├── Suspicious activity blocking
└── Heuristic analysis3. Wireless IPS (WIPS)
Definition: Monitors and prevents threats in wireless networks.
WIPS FUNCTIONS
Rogue Access Point Detection
├── Monitoring for unauthorized APs
├── Classification of legitimate APs
└── Automatic containment
Wireless Attack Prevention
├── De-authentication attacks
├── Evil twin detection
├── Man-in-the-middle prevention
└── Ad-hoc network detection
Wireless Policy Enforcement
├── SSID policy
├── Encryption requirements
└── Authentication requirementsIPS Response Actions
Active Response Actions
| Action | Description | When Used |
|---|---|---|
| Block | Drop malicious packets | Confirmed attacks |
| Reset | Reset TCP connections | Suspicious sessions |
| Quarantine | Isolate infected hosts | Compromised systems |
| Rate Limit | Reduce traffic speed | DoS attacks |
| Reconfigure | Update firewall rules | Dynamic protection |
Passive Response Actions
| Action | Description |
|---|---|
| Alert | Generate security alert |
| Log | Record event details |
| Report | Generate incident report |
| Notify | Send notification |
| Correlate | Connect related events |
Response Modes
| Mode | Description |
|---|---|
| Inline Mode | Traffic passes through IPS, can block in real-time |
| Passive Mode | Monitors only, sends alerts (like IDS) |
| Inline with Tap | Monitors without inline blocking |
IPS Implementation in Cloud
AWS IPS Solutions
- AWS Network Firewall: Managed firewall with IPS capabilities
- AWS WAF: Web application firewall
- Third-party IPS: Palo Alto, Cisco, Fortinet (VM-series)
Azure IPS Solutions
- Azure Firewall: Threat intelligence-based filtering
- Azure DDoS Protection: Attack mitigation
- Third-party IPS: Azure Marketplace solutions
Exam Key Points
- IPS actively blocks threats (inline)
- IPS is faster than IDS (must process in real-time)
- IPS has risk of false positives blocking legitimate traffic
- NIPS monitors network, HIPS monitors host
- IPS can reset connections, drop packets, quarantine hosts
- IPS adds active prevention to IDS detection
- Cloud IPS implemented via network firewalls and WAFs
QUICK REVISION TABLE FOR EXAM
Access Control Models
| Model | Description | Key Feature |
|---|---|---|
| DAC | Owner controls access | User-driven |
| MAC | System-enforced labels | Government use |
| RBAC | Role-based | Enterprise use |
| ABAC | Attribute-based | Dynamic, contextual |
| ReBAC | Relationship-based | Social networks |
Authentication vs Authorization
| Aspect | Authentication | Authorization |
|---|---|---|
| Question | “Who are you?” | “What can you do?” |
| When | First | After authentication |
| Examples | Password, MFA | Roles, Policies |
MFA Factors (Something You…)
| Factor | Examples |
|---|---|
| Know | Password, PIN |
| Have | Phone, Token |
| Are | Fingerprint, Face |
| Where | GPS, IP Address |
| Do | Keystroke dynamics |
SSO Protocols
| Protocol | Purpose | Format |
|---|---|---|
| SAML | Web SSO | XML |
| OAuth 2.0 | Authorization | Tokens |
| OpenID Connect | Authentication | JWT |
| WS-Federation | Web services | XML |
IDS vs IPS
| Aspect | IDS | IPS |
|---|---|---|
| Action | Alert | Alert + Block |
| Location | Out-of-band | Inline |
| Risk | Low | Medium |
Secure Boot Keys
| Key | Purpose |
|---|---|
| PK | Platform Key - Establishes ownership |
| KEK | Key Exchange Key - Signs db/dbx |
| db | Signature Database - Authorized |
| dbx | Forbidden Database - Revoked |
END OF UNIT 2 COMPLETE CONCEPTS GUIDE, SAY ‘HELLO’ TO ThiruXD 🥲