Summary of "Cybersecurity Bootcamp – Day 1 (Cybersecurity Fundamentals – IAM)"

Main ideas & lessons from the session (Cybersecurity Fundamentals – Day 1: IAM)

Bootcamp structure & goals

• The webinar is a 4-hour Zoom bootcamp session, combining:
  • Content delivery (about 15–30 minute chunks)
  • Live Q&A (10–15 minute breaks)
• Speakers may not answer every live question due to pacing. Unanswered questions are intended to be compiled into a later Q&A repository.
• The learning approach emphasizes that recordings may be needed because concepts may not “land” on the first listen.

---

Security fundamentals: CIA triad + security domains

What “security” is trying to achieve

Security protects:

• Organizations’ assets
• Organizations’ people
• Organizations’ systems/data

Three major security properties (CIA triad):

• Confidentiality: prevent unauthorized disclosure (privacy of systems/data)
• Integrity: prevent improper changes to data/systems
• Availability: ensure systems/services remain usable when needed

Real-world examples used to explain CIA

• Confidentiality
  • Secret drug formula exposure
  • Medical record privacy breaches (e.g., learning about someone’s health events)
  • Bank account numbers being stolen
• Integrity
  • Financial fraud (e.g., zeroing out savings)
  • Medical dosage alteration leading to death
  • Cloud/system tampering (wrong number of VMs / system state changes)
• Availability
  • Kidnapping preventing delivery of a presentation
  • Cloud provider outage (e.g., a hacked provider goes down)
  • DDoS overwhelming capacity (servers can’t handle demand)

Risk management as a foundational domain

Risk management involves:

• Identifying assets
• Classifying assets
• Assessing risk
• (Later) Prioritizing risk

Key principle:

• 0-risk is impossible. Aim for risk that is “tolerable”, and focus on the most-likely attacks.

Other security domains (besides IAM)

Later coverage is indicated to include:

• Network security: firewalls, IDS/IPS, traffic rules, worm/DDoS handling
• Data security: privacy, masking, tokenization, encryption
• Secure software / code security: input validation, secure procedures, avoiding vulnerable code
• Cryptography
• Physical security

---

Identity & Access Management (IAM): what it is and why it matters

IAM is treated as the “new perimeter”

Security historically focused on the network perimeter, but now identity becomes the new perimeter.

Common identity threats highlighted:

• Social engineering
• “Vishing” (phishing via phone to trick people)
• MFA fatigue attacks

IAM core components introduced as “types” or “layers”

IAM is presented as multiple related subdomains:

1. Identity Access Management (IAM)
   • Determines who you are and what you can do
2. Identity Governance & Administration (IGA/IG)
   • Governs access lifecycle (who gets access, approvals, reviews, compliance)
3. Privileged Access Management (PAM)
   • Protects privileged “keys of the kingdom” (admin/service privilege)
4. Customer/Consumer Identity (CIM/SIМ described as consumer IAM)
   • Scales identity for millions of external users (customers/partners/vendors), optimized for UX and compliance

---

Detailed IAM methodology & concepts covered

1) Identity: what kinds of identities exist

• User accounts tied to roles (regular employees)
• Contractors (limited access, shorter term)
• Non-human accounts / service accounts
  • Should have ownership (assigned responsibility), often via administrators or teams
  • Non-human identities include systems, computers, services, automation

2) Authentication vs Authorization (explicitly separated)

• Authentication: prove who you are
  • Examples: passwords, MFA, passkeys, hardware dongles
• Authorization: what you’re allowed to do
  • Examples: role-based permissions determining access to systems/resources

3) Authentication evolution (passwordless + MFA + passkeys)

Motivations:

• Password theft is common
• MFA adoption via policy (example referenced: Biden-era executive order requiring MFA for federal employees)

MFA limitations/attacks:

• MFA fatigue (flooding approvals until users comply)
• SIM swapping / phone compromise scenarios

Direction suggested:

• Move away from traditional passwords toward passkeys
  • Examples: registered key via a password manager, or a physical USB/dongle-style key
• Prediction:
  • Many organizations/banks will shift further away from passwords around 2026–2027

4) SAML as an internal authentication approach (employee-focused)

SAML is positioned as:

• Using assertions (XML-based)
• Often supporting SSO-style reduced login prompts (“login fatigue”)

Conceptual “triangular” flow:

• Identity Provider (IDP) issues assertions/tokens after verifying the user
• Service Provider (SP)/resource provider accepts the assertion
• Access is granted based on what the identity can do

Assertion/token answers:

• Who you are
• What you can do

Q&A emphasis:

• SAML’s “security” framing is that the IDP acts as a secured gatekeeper and authentication includes required second factors
• Token capture alone isn’t sufficient without the right second factors/additional protections

5) OIDC/OAuth2 concepts (modern token-based authentication)

• OIDC uses JSON tokens (e.g., JWT discussed)
• OAuth is used for authorization; OIDC builds authentication on top

Contrast:

• SAML: XML assertions
• OIDC: JSON tokens

6) Role-Based Access Control (RBAC) and scaling access

Example used: “Sharon” as an accounting role with limited permissions.

Principles:

• Users get access via roles
• Roles bundle permissions
• RBAC helps avoid repeating complex approval steps for every individual

“Birthright access”:

• Onboarding/role assignment should automatically grant access to new hires based on templates
• Contrasted with slow manual legacy processes

7) Attribute-Based Access Control (ABAC) + Policy-Based Access Control (PBAC)

• ABAC
  • Uses user attributes (job title, location, grade, function, etc.) for fine-grained authorization
  • Trade-off: can become overwhelming due to many attributes
• PBAC
  • Uses organizational policies to control access
  • Example: hourly employees can’t access email after 5:00

Q&A clarification:

• Attributes = data points describing the user
• Policies** = rules governing access based on context and attributes
• RBAC + ABAC + PBAC can be combined, but it takes time and engineering effort

8) Authorization “granularity” trade-off

• More granular controls (ABAC) = better precision but higher complexity (time/cost)
• RBAC is easier to operationalize at scale

9) AM ties to the CIA triad (explicit mapping)

• Confidentiality (IAM)
  • Strong authentication + strict authorization policies
• Integrity (IAM)
  • Authorization policies prevent unauthorized actions that could modify systems/data
• Availability (IAM)
  • Resilient SSO/federation
  • Redundancy and continuous login availability
  • Analogy: availability breaks when systems go up/down at critical times

10) Logging and accountability (“Accounting” in AAA)

IAM includes Authentication, Authorization, Accounting (AAA).

Accounting/logging supports:

• Forensics
• Proof of actions taken
• Accountability (users can’t deny changes)

---

Identity Governance & Administration (IGA/IG) content (joiner-mover-leaver)

Why IG exists

IG handles:

• Access lifecycle compliance
• Audits
• Identity governance
• Ensures correct approvals and reviews happen

Core lifecycle categories

• Joiners: new employees join
• Movers: role changes/promotions/transfers
• Leavers: exiting employees

Key IG functions described

• Birthright access for standardized onboarding
• Access reviews
  • Periodic re-validation that users still need access
  • Frequency depends on regulation and role sensitivity
• Offboarding enforcement
  • Disable accounts quickly via HR as “source of truth”
  • Remove access from applications

“Source of truth” and avoiding “offboarding drift”

• HR is described as source of truth
• IG/IGA should propagate changes to connected systems (e.g., AD / application provisioning)
• Warning: avoid “shadow” or siloed manual changes that don’t propagate
  • Leads to “orphan/leftover” access and often-account issues

Segregation of Duties (SoD)

IG enforces Segregation of Duties to prevent conflicts of interest:

• Accounting example: ability to write checks cannot be paired with ability to sign checks
• Dev example: developers shouldn’t have production push rights

Purpose:

• Enforce least privilege
• Prevent fraud patterns

Access request workflow (when not already provisioned)

• Users request access through an IG portal
• Workflow approvals:
  • Manager approval
  • Application owner approval (often two levels)
• If not approved: access denied and the workflow stops
• Conflict roles can be automatically denied to prevent privilege escalation

Role of IG in compliance

Without IG, organizations risk:

• Audit failures
• Fines
• Compliance exposure

IG is framed as necessary to satisfy auditors and consistently enforce policy-driven access.

---

Privileged Access Management (PAM) and “crown jewels”

Why PAM is needed

Privileged accounts are “crown jewels”.

Credential misuse/abuse is highlighted as a major breach vector. PAM helps prevent:

• Lateral movement after credential compromise
• Admin abuse
• Persistent credential exposure

PAM core practices described

• Vaulting secrets
  • Store passwords/keys in a central secure vault
  • Rotate/version secrets (just-in-time issuance)
  • Avoid exposing permanent credentials to users
• Just-in-time access
  • Grant elevated access only when needed, briefly
• Session recording/monitoring
  • Record who accessed what while using privileged access
• Check-in / check-out pattern
  • Temporary elevation and tracked usage instead of long-lived credentials
• Break-glass accounts
  • Emergency admin access accounts
  • Must be tightly controlled, audited, and policy-based
  • Often with multi-person controls and monitoring

PAM integration with cryptographic protections

• Vaulting/encryption is tied conceptually to cryptographic strength (including mentions of AES-style cryptography)

---

Consumer Identity Management (CIM/SIAM) content (customer-facing IAM)

Primary purpose

Scale authentication/authorization for customers, partners, vendors, external users (millions).

Emphasis:

• Security + scalable performance
• Seamless UX
• Self-service onboarding
• Consent handling for privacy regulations

UX/security features listed

• Social login via IDPs:
  • Google, Facebook, Apple, LinkedIn (examples given)
• Fine-grain consent
• Progressive profiling
  • Collect minimal data first, then ask for more over time (e.g., contact info steps)

High-level flow described

1. User signs into an app client
2. Redirects to an OIDC/OAuth-based system (Okta and “OIDC” referenced)
3. After authentication, system issues:
   • Authorization code
   • Then exchanges it for tokens:
     • Identity token
     • Access token
4. Application uses tokens to access backend resources and establish session access

Authorization differences in consumer contexts

• Guest vs registered user flows were highlighted
• Different authorization contexts for:
  • retail vs commercial scenarios
  • business vs other external party categories

Key constraint noted

For regulated industries (explicitly mentioned: banking/healthcare), social login may not be acceptable.

---

Zero Trust & how IAM/IGA/PAM connect to it

Integration message:

• Apply zero trust ideas: “never trust, always verify”

How IAM/IGA/PAM supports zero trust:

• Identity as the gatekeeper: who can access what
• Strong authentication + strict authorization
• Continuous verification and conditional access concepts
• Segregation of duties enforcement
• Availability/resilience: redundant authentication/federation
• Monitoring, log retention, and session revocation

---

Detailed instruction/list elements explicitly presented (methods/practices)

Risk management approach (pillars)

• Avoid the risk
  • Fix the root issue (e.g., patch instead of letting a vulnerability sit)
• Mitigate the risk
  • Reduce likelihood/impact; accept residual risk
• Transfer the risk
  • Use insurance/third parties/consultants to shift responsibility
• Accept the risk
  • Risk owner/admin signs off to formally accept residual risk

Least privilege principle (how to apply)

• Scope tokens/permissions narrowly:
  • Issue tokens only for required access
  • Avoid broad/wide resource access

Access control model selection guidance

• Use RBAC when you need scalable templating and simpler operations
• Use ABAC when you need fine-grained logic based on user/device/location attributes
• Use PBAC when authorization is driven by organizational/business policies
• You can combine RBAC + ABAC + PBAC, but it requires engineering time and governance effort

IAM ↔ CIA mapping (operational practice)

• Confidentiality: strong auth + strict authz policies
• Integrity: authz policies prevent unauthorized modifications
• Availability: resilient SSO/federation and stable access pathways

IG (governance) for joiner/mover/leaver

• Maintain HR as source of truth
• Automate propagation to AD/apps where possible
• Run access reviews periodically:
  • more often for privileged accounts
  • less often for regular accounts
• Enforce SoD to block conflicting roles
• Deny conflicting role combinations automatically during access requests

PAM practices for privileged/admin accounts

• Vault credentials (no permanent exposure)
• Issue elevated access just-in-time
• Rotate/renew secrets
• Record privileged sessions
• Restrict break-glass usage with policy + auditing

---

Speakers / sources mentioned

People / primary speakers

• Chris Johnson — Chief Operating Officer, GoCloud Careers (host/master ceremonies)
• Mike Gibbs — Founder and CEO, GoCloud Careers (security fundamentals overview)
• Isaac Kenzi — Identity and Access Management expert (main technical IAM/IG/PAM/CIM presenter)
• Leo Leah Paul — mentioned in chat as facilitating/moderating
• Tyrone — referenced as sharing links and assisting with facilitation

Other referenced organizations / external sources

• GoCloud Careers
• OASP.org / OWASP (top vulnerabilities reference, discussed as “top 10”)
• NIST 800-53 (compliance alignment)
• ISO 27001 (compliance alignment)
• CIS Controls (compliance alignment)
• HIPAA, SOX (regulated access review contexts)
• GDPR, CCPA (privacy laws compliance)
• PCIDSS mentioned (likely intended as PCI DSS) for regulated compliance context
• CrowdStrike (credential/identity breach stat mention)

Vendor/tool examples referenced

• Okta
• Saviynt (Savient/Saviynt referenced)
• SailPoint
• Microsoft Entra ID (referred to as “Entra” / “Intra”)
• Microsoft Sentinel and AWS CloudTrail (logging references)
• AWS Cognito (consumer identity example)

Compliance/terms and tech references

SAML, OIDC, OAuth, JWT, MFA, passkeys, SOD, RBAC/ABAC/PBAC, DDoS, DLP, IDP, SP, SSO, federation, tokens/assertions, plus AES-style cryptography (mentioned).

Category

Educational

---

Share this summary

Share on X/Twitter Share on Facebook Share on LinkedIn Share on Reddit Share on WhatsApp Share on Telegram

---

Is the summary off?

If you think the summary is inaccurate, you can reprocess it with the latest model.

Reprocess summary

Video