Protection of Information Assets (ISACA)

This is the sixth and final domain of the Certified Information Systems Auditor (CISA) exam content outline. It is split into two courses: this course, which covers Information Asset Security and Control, and a companion course covering Security Event Management. Together, the two courses make up 26% of the total CISA examination — the largest single domain weight in the exam. This course examines the process of auditing information system asset security and control: how organizations classify, encrypt, and technically protect information throughout its lifecycle — from creation and classification, through processing, storage, transmission, and display — so that information is adequately protected at all times, in all places, and in all forms. The course is organized into three parts:

1. Reviewing the assessment of security and privacy principles.
2. Auditing security implementations (identity and access management).
3. Auditing the technologies used to secure information (networks, firewalls, virtualization, cloud, wireless, telephony).

Table of Contents

• Module 1: Security and Privacy Principles
  • Information Asset Security Frameworks and Standards
  • Auditing Information Protection and Asset Management
  • Privacy Principles and Data Classification
  • Data Encryption Fundamentals and Symmetric Algorithms
  • Asymmetric Algorithms and Hybrid Cryptosystems
  • Message Integrity, Hashing, and Digital Signatures
  • Public Key Infrastructure and Encryption Implementations
• Module 2: Auditing Security Implementations
  • Identity and Access Management Fundamentals
  • Authentication Factors and Biometrics
  • Authorization and Privileged Access Management
  • Access Control Theory and Models
  • Single Sign-On, Kerberos, and Centralized Authentication
• Module 3: Securing Information Technologies
  • Network Communication Models: OSI and TCP/IP
  • Evolution of Network Transport Technologies
  • Network Security and Administration
  • Firewalls and Perimeter Defense
  • Auditing Web and Virtual Environments
  • Virtualization and Cloud Computing
  • Auditing Wireless Security
  • Telephony, Mobile Devices, and Converged Communications
• Summary
  • Self-Assessment Questions
  • Glossary Quick Reference
  • Study Checklist

Module 1: Security and Privacy Principles

Information Asset Security Frameworks and Standards

Auditing the protection of information assets is grounded in understanding the principles of security and privacy: information asset security frameworks/standards/guidelines, privacy principles, and data classification. The purpose of data classification is to ensure that all data or information receives an appropriate level of protection.

Organizations model their security programs on recognized frameworks and standards, and auditors review the program against those same standards:

Every standard has value because it provides a structure that a security program can be modeled on, and that auditors can review against. Auditing standards are also cross-recognized: a review performed against ISO 27001, for example, is generally accepted worldwide. However, every standard must be tailored to the organization — a military organization, a government agency, a not-for-profit, and a commercial enterprise are all different, so the standard must be implemented in a way suitable to that specific organizational context. The auditor’s job is not to check whether the organization did things identically to every other organization, but whether the standard was implemented appropriately for that organization — and whether it is actually enforced (e.g., configurations are checked against minimum security baselines), not merely documented.

A common cybersecurity lifecycle framework used across many standards is: Identify → Protect → Detect → Respond → Recover.

flowchart LR
    A[Identify<br/>What are we protecting?<br/>What are the threats?] --> B[Protect<br/>Implement the best<br/>controls to prevent harm]
    B --> C[Detect<br/>Monitor to notice<br/>when something happens]
    C --> D[Respond<br/>Act to limit damage]
    D --> E[Recover<br/>Return to normal<br/>operations quickly]
    E -.feedback.-> A

ISO/IEC 27001 (“Information security, cybersecurity and privacy protection”) defines the requirements for an Information Security Management System (ISMS) — what an organization must do to demonstrate compliance. As auditors, these are the seven areas we review:

flowchart TD
    ISMS["ISO 27001 ISMS Requirements"]
    ISMS --> CTX["Context of the Organization<br/>(competitive? monopoly? service org?)"]
    ISMS --> LEAD["Leadership<br/>(top-management commitment)"]
    ISMS --> PLAN["Planning<br/>(how protection will be accomplished)"]
    ISMS --> SUP["Support<br/>(financial + management support)"]
    ISMS --> OPS["Operation<br/>(reliable, consistent operations)"]
    ISMS --> PERF["Performance Evaluation<br/>(measuring to enable improvement)"]
    ISMS --> IMP["Improvement<br/>(continual improvement cycle)"]

ISO/IEC 27002 (“Information security, cybersecurity and privacy protection — Information security controls”) is the companion standard that lists the actual controls used to meet the ISO 27001 requirements. It groups controls into four clauses:

Auditing Information Protection and Asset Management

Much of what ISACA asks auditors to review here overlaps with topics already covered in the Operations domain, but the exam content outline revisits it because it is foundational.

Asset management starts with knowing what you have:

• A complete inventory of assets (in a configuration management database or asset management database), including who owns each asset and what it is used for. Organizations frequently do not actually know what assets they own.
• Diagrams, network/system layouts, flow charts, and documentation of the environment.
• Control over licensing and purchasing of new equipment and software.
• Awareness of hardware age/end-of-life and whether it is properly maintained.
• Confirmation that hardware, software, and people are correctly configured according to communicated security baselines.
• Proper storage of IT assets such as cryptographic keys and retained data, spare equipment for failures, and hardening (turning off unnecessary ports/services to reduce attack surface).
• Capacity forecasting — future bandwidth, processing power, and storage needs, rather than only reacting once resources run out.

Everything starts with policy, which states management’s intent, but policy alone is only words. It must be backed by:

flowchart TD
    P[Policy<br/>Management's intent] --> S[Standards<br/>Mandatory requirements]
    S --> B[Baselines<br/>Minimum acceptable configuration]
    B --> PR[Procedures<br/>How to do something, step by step]

When auditing policy, review whether:

• It was signed by management, demonstrating leadership commitment.
• It is up to date, reflecting current business practices and technology.
• It is aligned with business strategy and culture.
• It is legal — a policy must never strip away a person’s legal rights, and in many cases organizations are legally required to have policies addressing certain topics (e.g., data privacy).
• It has been properly communicated — a policy no one knows about is useless — and is enforced.
• Exceptions to policy are formally risk-assessed, tracked, and removed once no longer needed (an exception is not a permanent bypass).

When auditing procedures, confirm they truly support the intent of the policy, that people actually follow them, that they are documented (so auditors have something concrete to measure against), and that they are periodically reviewed/updated rather than silently ignored or inconsistently followed.

Key point: ISACA expects auditors to confirm that information asset protection is comprehensive and management-led/management-supported — and, above all, that the resulting security program is actually effective, not just documented.

Privacy Principles and Data Classification

Data protection is frequently driven by regulation (e.g., the General Data Protection Regulation, GDPR). Two criteria determine the appropriate level of protection for data:

1. Sensitivity — could disclosure or improper modification harm an individual or organization? (e.g., medical data — wrong data could contribute to death; disclosure could cause reputational damage.)
2. Criticality — would the individual or organization be harmed if the data were not available when needed? (e.g., a production line halting because inventory/cutting-diagram data is unavailable.)

Consequences of getting this wrong include regulatory financial penalties, loss of customers, and operational disruption.

Data protection standards must address the entire data lifecycle: collection, sharing (between systems and business partners), proper deletion, and storage/archiving/retention.

flowchart LR
    C[Collection] --> U[Use / Processing]
    U --> SH[Sharing<br/>between systems & partners]
    SH --> ST[Storage, Archiving,<br/>Retention]
    ST --> D[Destruction /<br/>Defensible Disposal]

Roles and responsibilities for data protection:

Access rules must ensure correct authorization is set from the moment a new user is provisioned, and terminated the moment access is no longer needed. Temporary authorizations should exist for short-term needs and be automatically removed once the time period ends. Auditors spend significant time reviewing the entire identity and access management framework to confirm privilege levels are set correctly (e.g., read-only users should never also have write access).

Common data-handling controls that should be defined per classification level and validated by auditors:

Key points: Data is one of an organization’s most valuable and critical assets, is frequently subject to local and global laws/regulations, and auditors must confirm both appropriate protection and compliance with applicable laws and standards.

Data Encryption Fundamentals and Symmetric Algorithms

Auditors must understand enough about encryption to properly assess it — encryption uses a distinct vocabulary that must be learned.

Core terminology:

A simple cryptographic exchange:

sequenceDiagram
    participant Sender
    participant Crypto as Cryptosystem (Algorithm + Key)
    participant Recv as Receiver
    Sender->>Crypto: Plaintext message M + Key
    Crypto->>Sender: Ciphertext (Cm)
    Sender->>Recv: Send Cm over an insecure channel (e.g., internet)
    Recv->>Crypto: Ciphertext (Cm) + Key
    Crypto->>Recv: Plaintext message M
    Note over Sender,Recv: Anyone intercepting Cm knows the algorithm<br/>but lacks the key, so the message stays protected.

Auditors focus heavily on key management — if the key is not protected, nothing is protected. This includes use of hardware security modules (HSMs) or secure “password wallets,” secure key generation, protected communications (e.g., certificates to confirm you are talking to a trusted party), and correct algorithm choice.

Symmetric algorithms use the same key for both encryption and decryption. They have been used since antiquity (Ancient Egypt, Rome, Greece) and remain in wide use today because they are:

• Fast, relative to other algorithm types.
• Well suited for confidential communications and storage.
• Ideal for streaming content (e.g., VoIP, satellite) where low latency matters.

How symmetric cryptography works, step by step:

1. To avoid producing identical ciphertext for repeated similar messages, a random value called an Initialization Vector (IV) (also called a “seed” or, informally, “salt”) is combined with the plaintext using an exclusive-or (XOR) operation.
2. The result is fed into the algorithm together with the key to produce ciphertext.
3. Ciphertext is transmitted over an insecure channel.
4. The key itself cannot travel with the message (an attacker would then have both), so it must be distributed through a separate, out-of-band channel (phone, courier, fax, etc.).
5. The receiver decrypts with the same key, then reverses the XOR to strip out the IV and recover the plaintext.

It is called “symmetric” because the decryption process mirrors the encryption process — both sides are essentially the same operation in reverse.

Risks of symmetric algorithms:

• The key is a shared secret — the more parties who know it, the weaker the protection.
• Keys must avoid predictable patterns and must be sufficiently long.
• Keys can be difficult to replace when hardwired into equipment (e.g., industrial control systems / SCADA sensors).
• A secure method for out-of-band key distribution is required.

Key points: Symmetric encryption is one of the most commonly used approaches because it is fast, freely available, and excellent for confidentiality — but it is entirely dependent on protecting the shared key.

Asymmetric Algorithms and Hybrid Cryptosystems

Where symmetric algorithms are thousands of years old, asymmetric algorithms emerged from the 1970s work of Diffie–Hellman. Asymmetric algorithms use a mathematically related key pair:

• A private key, which must always remain secret.
• A public key, computed from the private key through a one-way function — knowledge of the public key does not reveal the private key, so the public key can be shared freely.

Core rule of asymmetric algorithms: keys only work as a pair. Whatever is encrypted with one half of the pair can only be decrypted with the corresponding other half.

• Encrypt with a private key → only decryptable with the matching public key (this is the basis of digital signatures).
• Encrypt with a public key → only decryptable with the matching private key (this is the basis of confidential key exchange).

Asymmetric cryptography solves the symmetric key-distribution problem: instead of needing an out-of-band channel, the symmetric key can be securely exchanged over the same channel as the message. It also provides digital signatures — proof of who sent a message, and proof the message was not altered.

Hybrid cryptosystem walkthrough (Robert sending a confidential message to Sharon):

sequenceDiagram
    participant Robert
    participant Sharon
    Robert->>Robert: Encrypt message with symmetric key (AES)
    Robert->>Robert: Encrypt the AES key with Sharon's public key
    Note over Robert: Ciphertext(message) + Ciphertext(AES key)<br/>= "Digital Envelope"
    Robert->>Sharon: Send digital envelope over insecure channel
    Sharon->>Sharon: Decrypt Ciphertext(AES key) using Sharon's private key
    Sharon->>Sharon: Use recovered AES key to decrypt the message
    Note over Sharon: Only Sharon's private key can open<br/>data encrypted with Sharon's public key.

AES handles the bulk message quickly (good for confidentiality); RSA (or another asymmetric algorithm) securely transports the symmetric key. This combination — symmetric for bulk data, asymmetric for key exchange/signing — is the foundation of protocols such as TLS.

Message Integrity, Hashing, and Digital Signatures

Message integrity answers: is this message authentic, and has it been altered (by noise, static, or intentional manipulation)?

Historical/legacy integrity mechanisms included parity bits, checksums, trailer records, and Cyclic Redundancy Checks (CRC — e.g., used to validate floppy disk software). Modern integrity relies on hash functions. Any time the term “hash function” appears, it relates to message integrity.

How a simple hash function works:

sequenceDiagram
    participant Sender
    participant Recv as Receiver
    Sender->>Sender: Hash message M (e.g., with MD5) -> Digest D
    Sender->>Recv: Send message M + Digest D (over untrusted channel)
    Recv->>Recv: Hash the received message M -> Digest D'
    Recv->>Recv: Compare D' to received D
    alt D' == D
        Recv->>Recv: Message is intact/unaltered
    else D' != D
        Recv->>Recv: Message was altered in transit
    end

The digest is a fixed-length output (e.g., 128 bits for MD5) — conceptually like a QR code/UPC code calculated from the message. Changing even a single bit of the message changes at least ~40% of the resulting digest.

Because a plain hash sent alongside a message could itself be tampered with in transit, we protect the hash using symmetric cryptography — this is HMAC (Hashed Message Authentication Code), also called keyed hashing.

Digital signatures go further, proving both integrity and the identity of the sender (non-repudiation):

sequenceDiagram
    participant Sender
    participant Recv as Receiver
    Sender->>Sender: Hash message M (SHA-2/SHA-3) -> Digest D
    Sender->>Sender: Encrypt Digest D with Sender's private key -> Digital Signature
    Sender->>Recv: Send message M + Digital Signature
    Recv->>Recv: Decrypt Digital Signature using Sender's public key -> D
    Recv->>Recv: Hash received message M -> D'
    Recv->>Recv: Compare D to D'
    Note over Recv: Match proves (1) it came from the sender<br/>(only their public key could open it)<br/>and (2) it was not altered (digests match).

A digital signature is not the same as a digitized signature (a scanned image of a handwritten signature). A digital signature only exists when a message digest is encrypted with the sender’s private key. Note that the Digital Signature Standard, by itself, addresses source authentication and integrity — not confidentiality (the message itself is not encrypted unless combined with the earlier hybrid encryption approach).

Public Key Infrastructure and Encryption Implementations

Public Key Infrastructure (PKI) establishes ownership of a public key — e.g., proving that a bank’s website truly holds the public key it claims to hold, which underpins trust in SSL/TLS-based e-commerce and online banking.

flowchart TD
    Owner["Public Key Owner<br/>(e.g., a bank)"] -->|Sends public key| RA["Registration Authority (RA)<br/>(optional local representative)"]
    RA --> CA["Certificate Authority (CA)"]
    Owner -->|Or directly| CA
    CA -->|Issues, digitally signs| Cert["Digital Certificate<br/>binds public key to identity"]
    Cert --> Client["Relying party (e.g., online banking customer)<br/>trusts the certificate"]
    CA --> CRL["Certificate Revocation List (CRL)<br/>lists no-longer-valid certificates"]

Certificate authorities may be external, well-established commercial CAs, or organizations may run their own internal CA (e.g., for internal secure email) while still using an external CA for external communications. Certificates are digitally signed by the CA, and expire — but if a certificate must be invalidated before its natural expiry (e.g., an employee leaves the company), it is added to a Certificate Revocation List (CRL).

When auditing PKI, review:

• Are policies and procedures for certificate issuance trustworthy?
• Do certificates have expiry dates?
• Is there a working CRL process for early invalidation?
• Is ownership of the public key genuinely validated before issuance?

Encryption is deployed at multiple layers, and auditors must recognize which technology maps to which layer and whether it still meets current standards:

Key points: Encryption is essential to protect data in storage and transit, but it is only as effective as the training and skill applied to its implementation. Protecting information assets requires a comprehensive approach spanning managerial policy, technical controls, and physical controls (including secure key storage, potentially via an HSM).

Module 2: Auditing Security Implementations

Identity and Access Management Fundamentals

Access management/access control is often described as the heartbeat of any information protection or information security program: access control determines who can get onto systems and what they can do once there.

Identity and Access Management (IAM) responsibilities include provisioning access, managing permissions, and removing access rights when a person leaves. Security managers must review access permissions regularly; auditors act as management’s “eyes and ears” to confirm this review is genuinely happening, creating accountability by surfacing issues management must act on.

The canonical access control diagram:

flowchart LR
    Subj["Subject<br/>(user, process)"] -->|Requests access| PEP{"Policy Enforcement<br/>Point (⛔ stop sign)"}
    PEP -->|Checks| ACL["Access Control List<br/>(rules set by Asset/System Owner)"]
    PEP -->|If allowed| Obj["Object<br/>(file, database, application)"]
    PEP -->|Always| Log["Access Log<br/>(what was requested/granted)"]

The asset/system owner determines what access rules should exist; the level of access granted (read-only, write-only, read/write, full control) is written into the access control list, and the policy enforcement point both enforces the rule and records the request.

IAM comprises four topic areas, sometimes summarized as “AAAA”:

flowchart LR
    I["1. Identification<br/>Who/what is trying to access?"] --> A1["2. Authentication<br/>Prove they are who they claim"]
    A1 --> A2["3. Authorization<br/>What rights/permissions do they get?"]
    A2 --> A3["4. Accounting / Auditing<br/>Record of what was actually done, by whom"]

Identification must always be unique. Auditors are highly sensitive to shared/group IDs (e.g., a shared “administrator” account), because they eliminate individual accountability. Historically we avoided names (not unique) in favor of truly unique identifiers: account numbers, employee numbers, customer numbers, government-issued identifiers (passport, national insurance number), and — very commonly today — email addresses or user IDs. Device/service identification also needs uniqueness: process IDs, job names, IP addresses, MAC addresses, RFID tags. Trusted paths (e.g., a hardware-based Trusted Platform Module, or a direct/hardwired administrative connection to a device, historically the mainframe operator console) authenticate sensitive devices or restrict certain administrative actions to a physically direct connection.

Identification hygiene an auditor checks:

• Is the ID unique and non-shared (supports accountability)?
• Is there a proper registration process so only legitimate people receive an ID (e.g., manager approval, CAPTCHA to distinguish humans from bots)?
• Is there proofing of identity — a cognitive/knowledge-based method (e.g., “what street did you used to live on”) confirming the person requesting a password reset or permission change is the legitimate owner of that identity?

Unique, well-governed identification enables traceability — tracking all access and activity across systems, data, and buildings, and establishing solid audit trails.

Authentication Factors and Biometrics

Authentication is the validation or proof that a claimed identity truly belongs to the person presenting it. Authentication is based on one or more of three factors:

mindmap
  root((Authentication Factors))
    Something You Know
      Password / Passphrase
      Cognitive / knowledge-based secret questions
      Weakness: static, subject to replay if learned by others
    Something You Have
      ID badge / token / smartcard
      One-time password (OTP) generators
      Synchronous (time-based) vs Asynchronous (challenge-response)
    Something You Are
      Behavioral biometrics
        Keystroke dynamics (dwell/transfer rate)
        Signature dynamics (acceleration, angle, pressure)
      Physiological biometrics
        Iris scan, retina scan
        Palm print / vein scanner
        Fingerprint, facial recognition

Static “what you know” secrets are vulnerable to replay attacks if learned by another party, which is why periodic password changes (e.g., a 30-day rotation) were traditionally required. Tokens/smartcards typically generate one-time passwords (OTPs) — usable only once — either:

• Synchronous — the access control server and the token are time-synchronized (e.g., a code that rotates every 2 minutes).
• Asynchronous / challenge-response — the server issues a challenge and the token/user must respond with the correct computed value (e.g., a scratch-card or push-button token).

Biometric adoption challenges: user privacy/acceptance concerns (biometric data cannot be “changed” the way a password or ID card can if compromised), hygiene/physical contact concerns, per-person processing time (queues at entry points), cost, and ongoing maintenance/re-registration needs.

Biometric accuracy — the two error types:

flowchart LR
    LowSens["Low Sensitivity Setting"] -->|Increases| FAR["False Acceptance Rate<br/>(Type II errors ↑)"]
    HighSens["High Sensitivity Setting"] -->|Increases| FRR["False Reject Rate<br/>(Type I errors ↑)"]
    FAR -.trade-off.-> CER["Crossover Error Rate (CER)<br/>a.k.a. Equal Error Rate —<br/>point where FRR = FAR<br/>(most accurate operating point)"]
    FRR -.trade-off.-> CER

As sensitivity increases, false rejections rise while false acceptances fall (and vice versa); the point where the two curves intersect is the Crossover Error Rate (CER) / Equal Error Rate (EER) — the most accurate operating point for that device. Auditors must confirm the chosen sensitivity setting matches the organization’s risk appetite — the CER itself might still represent unacceptable risk, requiring the sensitivity to be increased (accepting more false rejections to minimize unauthorized entries).

Time- and context-bound authentication concepts:

Modern trends move away from static passwords toward QR-code authentication, push-approval via smartphone, USB security keys, and integrated fingerprint/facial recognition. However, no single factor is sufficient on its own — this is why Multi-Factor Authentication (MFA) requires two different factor categories (e.g., a PIN plus a fingerprint; a password plus an ID card), not simply two examples from the same category.

Key points: Identification and authentication form the basis for establishing access permissions and accountability; authentication proves rightful ownership of an identity using one or more of the three factors (know / have / are).

Authorization and Privileged Access Management

Authorization determines the rights, privileges, or permissions granted to an authenticated identity — read-only, write/update, or full administrative control. This is where least privilege (give the lowest access level needed to perform the job) and need-to-know (do not grant access to systems/data not required) are enforced.

Privileged and service accounts deserve particular audit attention:

• Administrators, system/network/database admins are all examples of privileged accounts, requiring Privileged Access Management (PAM).
• A common attacker goal after initial compromise is privilege escalation — assuming a higher level of access than originally obtained.
• Even legitimate elevation mechanisms (e.g., sudo-style temporary elevation on Unix-like systems) must have clear rules for use — never for routine everyday work — and usage should be logged/monitored, sometimes restricted to specific time windows (temporal access).
• Contractors frequently need elevated administrator-type access for project work; auditors must confirm those accounts are removed once the work concludes.
• Vendors have, in some documented cases, embedded backdoors for remote monitoring — auditors must identify and eliminate or disable unrestricted backdoor access.

Access lifecycle hygiene:

• Access permissions must stay current with the person’s current job — access is removed when someone changes roles internally, not just when they leave the organization.
• When employment/contract ends, the account is typically disabled (password changed immediately) rather than deleted outright — this preserves files/artifacts created under that account while preventing further use by the former owner.
• When a system is retired, it must be removed from role-based access control role assignments.
• Management should perform regular access reviews to confirm staff access remains appropriate to their current responsibilities.
• Auditors confirm someone is actually reviewing logs — looking for attempted access to unauthorized resources, logins at unusual times, from unusual locations, or from unexpected parts of the world (all potential indicators of account compromise).

Key point: IAM requires ongoing maintenance and review to ensure correct access permissions are granted only to the correct entities; auditors must review the procedures and confirm they are actually followed.

Access Control Theory and Models

Understanding access control theory helps justify and validate the implementation an auditor observes.

flowchart TD
    AC["Access Control Models"] --> DAC["Discretionary Access Control (DAC)<br/>Owner's discretion — used in ~99% of systems<br/>(Windows, macOS, etc.)"]
    AC --> MAC["Mandatory Access Control (MAC)<br/>High-security systems (e.g., military)<br/>Access mandated by policy, not just owner"]
    AC --> RBAC["Role-Based Access Control (RBAC)<br/>Permissions tied to job role/group"]
    AC --> RuleBAC["Rule-Based Access Control<br/>Explicit allow/deny rules<br/>(e.g., firewall rules)"]
    AC --> TAC["Temporal Access Control<br/>Access restricted by time window<br/>(e.g., maintenance windows)"]
    AC --> ABAC["Attribute-Based Access Control (ABAC)<br/>Access depends on extra conditions<br/>(e.g., only on-premises, only on wired network)"]

Discretionary Access Control (DAC): access is granted at the owner’s discretion and rights are “discrete” per individual (not shared as one big group). Because it is discretionary, a user who has been granted access can, in turn, share/delegate that access to others.

Mandatory Access Control (MAC): used on high-security systems (e.g., military), and it is expensive to implement. Unlike DAC, MAC requires separation of duties and labeling. Access is granted only if both conditions are satisfied:

flowchart TD
    Subj["Subject requests access<br/>(has a Clearance level)"] --> Check{"Two conditions<br/>must BOTH be true"}
    Owner["Owner grants permission"] --> Check
    Label["Object has a Classification label<br/>(e.g., Top Secret)"] --> Check
    Check -->|Owner says yes AND<br/>clearance >= classification| Grant["Access Granted"]
    Check -->|Either condition fails| Deny["Access Denied<br/>(policy violation)"]

In MAC, the asset owner sets the classification of the object, while typically the security administrator sets the subject’s clearance — this separation of duties is itself a control. A subject with only “secret” clearance cannot access a “top secret” object even if the owner grants permission, because that would violate policy. Because access depends on policy as well as ownership, delegation of access to another party is not permitted under MAC.

Additional implementation approaches:

• Rule-Based Access Control — explicit permit/deny rules (a classic firewall is a rule-based access control example).
• Role-Based Access Control (RBAC) — permissions assigned according to job role/group with identical or similar access requirements (the acronym RBAC is reserved specifically for role-based access control).
• Temporal Access Control — e.g., restricting login to all but administrators during a scheduled maintenance window.
• Attribute-Based Access Control (ABAC) — additional conditional attributes layered on top of a base permission, e.g., “you may access this file, but only from the office, not remotely,” or “only over a wired connection, not wireless.”

Key point for the exam: both DAC and MAC require the owner’s permission — the difference is that MAC additionally requires policy agreement based on clearance/classification labels.

Single Sign-On, Kerberos, and Centralized Authentication

The challenge: users need access to many different systems, each historically with its own ID, password rules, and change frequency — forcing people to remember many credentials, which encourages writing passwords down (insecure).

Single Sign-On (SSO) centralizes authentication so a user authenticates once centrally and is then trusted across multiple connected systems/applications.

sequenceDiagram
    participant User
    participant NAS as Centralized Authentication Server (e.g., NAS)
    participant App1
    participant App2
    User->>NAS: Log in once (identify + authenticate)
    NAS-->>User: Trusted session established
    User->>App1: Access request (no separate login)
    App1->>NAS: Verify session/permissions
    NAS-->>App1: Authorized
    User->>App2: Access request (no separate login)
    App2->>NAS: Verify session/permissions
    NAS-->>App2: Authorized

Benefits: one ID/password to remember (encourages stronger password choices); a single place to revoke access when a person leaves.

Disadvantages/risks:

• Single point of failure — if the central server goes down, no one can access anything.
• Single point of compromise — a successful attacker can potentially grant themselves access to everything.
• Can become inflexible: e.g., in a large company with a small branch office, a junior staff member with minimal access may be the only one available to serve a customer, but a centralized IAM group insists on a 48-hour turnaround to grant temporary access. The manager, facing customers waiting now, may resort to sharing their own credentials — meaning “secure” centralization can inadvertently create a worse real-world risk. Auditors must evaluate whether procedures allow appropriate flexibility, because security exists to help the business operate securely — not to prevent it from operating at all.

RADIUS (originally “Remote Access Dial-In User Service”) is a long-standing centralized AAA (Authentication, Authorization, and Accounting) protocol, still widely used — for example, by a wireless access point that does not itself hold every user’s permissions:

sequenceDiagram
    participant User
    participant AP as Wireless Access Point (RADIUS client)
    participant RADIUS as RADIUS (AAA) Server
    User->>AP: Connection/login request
    AP->>RADIUS: "I don't know this user — what should they have access to?"
    RADIUS-->>AP: Authenticate + authorize (grants for App A, App B, etc.)
    AP-->>User: Access granted per RADIUS response

Kerberos originated from MIT’s “Project Athena,” aiming to provide campus-wide SSO without individually managing every user’s ID on every system. It is built into many systems today (e.g., Windows Server environments) and relies on symmetric encryption with a centralized Key Distribution Center (KDC), composed of two parts:

• The Authentication Service (AS) — authenticates each user.
• The Ticket Granting Service (TGS) — issues tickets that represent authorization to authenticated users.

sequenceDiagram
    participant User
    participant KDC as Kerberos KDC (AS + TGS)
    participant Application
    User->>KDC: Request to log into an application
    KDC->>KDC: Authentication Service validates the user
    KDC->>KDC: Ticket Granting Service issues a ticket
    KDC-->>User: Ticket (time-limited, encrypted)
    User->>Application: Present ticket
    Application-->>User: Session established (encrypted communication until ticket expires)

Module 3: Securing Information Technologies

Network Communication Models: OSI and TCP/IP

The Open Systems Interconnection (OSI) model (ISO 7498) is a conceptual, standardized model — not something literally “used” directly, but valuable because it names and standardizes the functions involved in network communication.

flowchart TD
    L7["7. Application<br/>Interface to the application (e.g., email client)"] --> L6
    L6["6. Presentation<br/>Formatting/conversion (compression, ASCII/EBCDIC, encoding)"] --> L5
    L5["5. Session<br/>Establishes/manages the communication session (e.g., login)"] --> L4
    L4["4. Transport<br/>End-to-end delivery dispatcher"] --> L3
    L3["3. Network<br/>Carries traffic across one segment/hop"] --> L2
    L2["2. Data Link<br/>Link-to-link handoff (e.g., truck, then plane, then truck)"] --> L1
    L1["1. Physical<br/>The actual medium (copper, fiber/light, radio)"]

Each layer performs its own job independently (encapsulation) and only ever communicates with the layer directly above and directly below it — the application layer never talks directly to the physical layer.

TCP/IP, developed before OSI (originally by the US Department of Defense), is the model actually used in practice. There is ongoing debate over how many layers TCP/IP has (it is not standardized the same way OSI is), but a common four-layer mapping is used:

LAN vs. WAN:

• A Local Area Network (LAN) covers a limited area (part of a floor, a building, or a couple of buildings) and a limited user population — from two devices up to several hundred. Common LAN risks: sniffing/eavesdropping on unencrypted traffic, physical cable faults (e.g., a broken RJ45 clip), wireless jamming/interference (2.4/5 GHz band contention — even household examples like a neighboring drone interfering with home Wi-Fi), and malware affecting communications or connected devices.
• A Wide Area Network (WAN) connects separate LANs together (branch to head office, or to the broader internet), usually via a telecom/service provider. WAN links vary widely in reliability, bandwidth, and cost.

Early WAN links were leased lines based on circuit switching (the same model as a traditional phone call — a dedicated route is established and all traffic for that session uses it). This was inefficient. Packet switching allowed many users to share the same physical link simultaneously (conceptually like many vehicles sharing the same highway instead of each requiring a private road), driving major gains in speed, cost efficiency, and cable/fiber utilization.

Evolution of Network Transport Technologies

Auditors are not expected to become network administrators, but must understand enough of the underlying technology to meaningfully audit and advise management on whether network communications are properly managed.

flowchart LR
    Modem["Modems<br/>(modulate/demodulate digital ↔ analog<br/>over voice-grade cable)"] --> Leased["Leased Lines + CSUs<br/>(dedicated, expensive, low bandwidth,<br/>single point of failure)"]
    Leased --> X25["X.25<br/>(early packet switching, built for<br/>poor-quality cable, built-in error correction,<br/>still used e.g. for bank ATMs)"]
    X25 --> FR["Frame Relay & ATM<br/>(enabled by fiber; frames relayed<br/>hop-to-hop across a switch mesh;<br/>ATM uses fixed-size cells)"]
    FR --> MPLS["MPLS<br/>(Multiprotocol Label Switching —<br/>traffic-engineered paths, QoS/CoS,<br/>voice + data combined)"]

Key points: Advances in network media (copper → fiber → satellite/microwave/radio) enabled faster protocols, fewer errors, and greater bandwidth. Auditors should evaluate whether bandwidth meets business needs, whether there is excessive loss/congestion, and whether the architecture correctly and securely routes traffic.

Network Security and Administration

Network security ultimately exists to provide the levels of confidentiality, integrity, and availability that the business and applicable law require.

Virtual Private Networks (VPNs) establish a trusted communications path exclusively between committed parties, typically providing both confidentiality (encryption) and integrity — both of which matter, for example, for online banking.

Because network-connected devices are only as secure as the network itself, auditors must pay attention to environments where devices are managed by non-technical local staff (e.g., a small branch office where the front-line staff know the network matters but cannot distinguish a firewall from a switch). This drives the need for architecture, implementation, maintenance, and operations to receive proper attention regardless of who is physically present.

Auditor responsibilities for network security and administration include confirming:

• Staff training — people know what to watch for and what to do if something goes wrong.
• Separation of duties and job rotation to reduce error/fraud risk, with cross-training so operations continue if someone is absent.
• Audit trails for administrator-level changes, regularly reviewed.
• Capacity — sufficient bandwidth, plus failover/redundancy (e.g., alternate/diverse routing if a cable is cut).
• Monitoring for remote logins at unusual times or from unusual locations/IP addresses — an indicator of possible account compromise.
• An inventory of networks, switches, and devices, with up-to-date network layouts.
• Equipment is patched and properly maintained, with backups of configurations (e.g., firewall configs) and awareness of aging equipment/spare-parts availability.
• Performance metrics — is the network available when needed (“five nines” is a common benchmark), and is there a meaningful distinction between availability (the network is up) and uptime (the systems riding on it are actually working)?
• Change control procedures for network equipment/configuration changes.
• Devices such as firewalls and intrusion detection systems are in place and monitored, with response plans for incidents (e.g., intrusion, ransomware).
• Encryption in use meets current standards (e.g., not DES), and encryption keys are protected (including backup encryption keys — losing them can be as damaging as losing the data itself).
• Firewall logs and suspicious alarms are actually being reviewed by someone.

Firewalls and Perimeter Defense

Firewalls control traffic flowing from one network to another — not just at the perimeter facing the internet. Firewalls can protect an individual device (e.g., a laptop) or separate internal segments (e.g., isolating a research and development network from the rest of the company).

An internet-facing firewall serves two purposes: protecting against inbound attacks from the internet, and preventing unwanted outbound traffic (e.g., data loss prevention, or stopping a compromised internal machine from attacking others). The general rule is to deny by default and only permit necessary traffic (e.g., only mail or HTTP traffic where appropriate), applying rules in the correct order to both protect and enable the business.

flowchart TD
    FW["Firewall Types (increasing capability)"] --> PF["Packet-Filtering Router<br/>Cheapest, most basic"]
    PF --> APP["Application Firewall<br/>Inspects traffic type/content"]
    APP --> STATE["Stateful Inspection Firewall<br/>Tracks ongoing connection state"]
    STATE --> PROXY["Proxy Firewall<br/>Acts as intermediary for outbound requests"]
    PROXY --> NGFW["Next-Generation Firewall (NGFW)<br/>Deep packet inspection, some encrypted-traffic visibility"]

Firewalls can also serve as VPN endpoints — e.g., all traffic between a head office firewall and branch office firewall automatically tunneled via IPSec.

Attacks firewalls must help mitigate:

Common auditor findings: organizations believing a firewall alone equals security (it does not — proper configuration and monitoring are still required); firewalls circumvented via wireless (Bluetooth or 802.11); misconfigured rules that do not behave as expected; nobody reviewing logs despite clear evidence of probing/attacks; and firewalls being “blind” to certain stealthy or encrypted attack traffic.

Network security is generally implemented as layered defense / defense in depth — combining firewalls, intrusion detection systems, and network segmentation. Even with heavy technology investment, many organizations fail because the devices are not properly managed. Auditors must confirm both the technical controls exist and that trained staff actively manage/monitor/configure them.

Auditing Web and Virtual Environments

The internet was never designed for security — it is globally accessible with no guarantee traffic reaches its destination unaltered. Defenses are applied at the endpoints:

flowchart TD
    Internet(("Internet")) --> Screened["Screened Host<br/>(firewall protects hosts behind it)"]
    Internet --> DualHomed["Dual-Homed Host<br/>(separate networks, air-gapped)"]
    Internet --> DMZ["Demilitarized Zone (DMZ) / Extranet<br/>(isolated network for public-facing services)"]
    DMZ --> Bastion["Bastion Host<br/>Hardened server: unnecessary services/ports disabled<br/>Minimal attack surface for public-facing apps"]

A bastion host takes its name from a defensive tower with limited points of attack — servers hosting public-facing services (e.g., web applications) are stripped down to only what is strictly necessary, minimizing the attack surface.

Passive vs. active attacks:

Denial of Service (DoS) / Distributed Denial of Service (DDoS) are common active internet attacks, frequently launched via botnets (“robotically controlled networks”) — devices infected by “zombie” malware and coordinated via Command-and-Control (C2) servers. Botnet membership can include almost any networked device: DVRs, smart TVs, IP cameras, laptops, and desktops.

Other notable threats: spam (unwanted email, sometimes carrying malicious payloads), worms, viruses, trojans, and delayed-trigger malware like logic bombs.

Contributing factors to widespread internet attacks: attack tools are freely and easily available; many users are naive/overly trusting; and a significant share of organizations run unpatched/misconfigured systems — studies have found roughly 20% or more of connected devices are more than a year behind on patching.

Detection/prevention layers:

flowchart LR
    NIDS["Network-Based IDS<br/>(monitors network traffic)"] 
    NIPS["Network-Based IPS<br/>(attempts to block bad traffic)"]
    HIDS["Host-Based IDS<br/>(records traffic against the host)"]
    HIPS["Host-Based IPS<br/>(blocks changes; may require admin approval)"]
    NIDS --> NIPS
    HIDS --> HIPS

IDS/IPS systems can detect using different techniques:

A key weakness: encrypted traffic can blind IDS/IPS systems, since they cannot fully inspect content they cannot decrypt.

Honeypots and honeynets serve as decoys placed (e.g., in a DMZ) to attract probing attackers toward assets of no real value, allowing defenders to observe attacker tools, techniques, and origin, and use that intelligence to improve real defenses.

Key points: Internet-based attacks can originate from anywhere in the world at any time, so defensive tooling must operate continuously and diligently — matching the persistence and capability of attackers.

Virtualization and Cloud Computing

Virtualization and cloud computing are often used interchangeably but are distinct: virtualization existed long before “the cloud” as we know it today. Virtualization creates a virtual machine (VM) configuration rather than a real, dedicated physical environment — multiple VMs, potentially running different operating systems, can run on one physical device.

Benefits: if something goes wrong inside a VM, it can simply be powered down and restarted without harming the underlying hardware (this is why malware such as WannaCry checked for a VM environment and, in some cases, avoided acting since attacking a VM has limited payoff). VMs are quick to build/rebuild, support running multiple isolated environments on one physical device (a common technique for hands-on security training — e.g., simulating an attack from one VM against another), and can function as a form of sandbox, isolating problems from other systems.

Risks: VMs can be improperly configured/unpatched just like any system; they add a new layer — the hypervisor — which becomes an additional attack surface if compromised; VMs can consume significant resources, hurting performance; and there is a risk of VM escape/hopping, where data leaks between processes/VMs on the same host.

Cloud computing would not be possible without virtualization. NIST Special Publication 800-145 provides the widely used (and freely attributable) definition:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources … that can be rapidly provisioned and released with minimal management effort or service provider interaction.

This model is composed of five essential characteristics, three service models, and four deployment models (per NIST SP 800-145):

mindmap
  root((NIST Cloud Model))
    Five Essential Characteristics
      On-demand self-service
      Broad network access
      Resource pooling
      Rapid elasticity
      Measured service
    Three Service Models (NIST SP 800-145 reference)
      IaaS - Infrastructure as a Service
      PaaS - Platform as a Service
      SaaS - Software as a Service
    Four Deployment Models (NIST SP 800-145 reference)
      Public cloud
      Private cloud
      Community cloud
      Hybrid cloud

Note: not every characteristic applies to every deployment model — e.g., a private cloud may not involve true multi-tenant resource pooling.

Cloud consumers generally lose visibility into exact physical location, hardware, and operating system of underlying resources (location independence) but may still specify high-level constraints (e.g., data must remain within a given country or state).

flowchart TD
    A[Existing System] -->|Naive lift-and-shift to Cloud| B{Does it actually improve<br/>agility, resiliency, economy?}
    B -->|Yes, workload is well-suited| C[Successful Cloud Migration]
    B -->|No — e.g., latency-critical<br/>life-support system| D[Cloud may reduce agility,<br/>resiliency, and economy]

Three headline cloud benefits: Agility (no hardware procurement delay), Resiliency (automatic failover when hardware fails), and Economy (providers achieve better hardware pricing and eliminate the need to stock spare parts, shifting cost from capital expense to operational expense).

A significant audit concern is VM sprawl — virtual machines that were spun up, allocated resources, and then never powered down or decommissioned, driving up cloud billing without corresponding business value.

Key point: the role of the auditor is not to resist new technology, but to ensure adoption of new solutions (cloud or otherwise) is done with due care, with security properly considered, and that promised benefits are actually realized.

Auditing Wireless Security

The IEEE 802.11 family of standards governs wireless local area networking, with multiple generations (802.11b, g, n, ac, ax, and others) operating in different frequency bands (2.4 GHz and 5 GHz) and delivering progressively higher speed/performance.

flowchart LR
    WEP["WEP<br/>Wired Equivalent Privacy<br/>(obsolete — never use today)"] --> WPA["WPA<br/>Wi-Fi Protected Access"]
    WPA --> WPA2["WPA2"]
    WPA2 --> WPA3["WPA3<br/>(current standard)"]

Access to wireless networks may be controlled via open system authentication (anyone can connect), a shared Wi-Fi password, or (less commonly today) MAC filtering (device allow-listing).

Common wireless risks: improperly configured access points; devices physically accessible to anyone (e.g., an attacker resetting an access point in a publicly accessible area of a commercial building, bypassing its password); wireless networks placed directly on the internal network instead of a separate subnet, exposing sensitive internal data to anyone within radio range — even from outside the building.

Wireless security extends beyond 802.11 to Bluetooth (IEEE 802.15) and Near-Field Communication (NFC):

Bluetooth was designed for short-range communication (nominally under ~10 m / 30 ft), but a directional antenna can significantly extend the effective attack range, enabling eavesdropping or man-in-the-middle interception. Bluetooth is now embedded in an enormous range of devices — TVs, cooking appliances, home heating/lighting, vehicles (some vehicles can be remotely accessed via Bluetooth from another nearby vehicle), and refrigerators — each representing a new potential attack surface if connected, directly or indirectly, to a corporate network.

Industrial Control Systems (ICS) and SCADA (Supervisory Control and Data Acquisition) devices monitor and control physical/industrial processes (e.g., a laser cutting machine needing network access to receive cutting diagrams and orders, or sensors monitoring water levels in a canal). Key audit concerns:

flowchart TD
    ICS["ICS / SCADA Devices"] --> Risk1["Rarely patched<br/>(in production for years/decades unreviewed)"]
    ICS --> Risk2["Physically accessible<br/>(can be manipulated directly, e.g., causing flooding/damage)"]
    ICS --> Risk3["Legacy protocols with no built-in security<br/>(e.g., Modbus, DNP3)"]
    ICS --> Risk4["Managed by vendors/operations staff,<br/>not IT/IT-security teams"]
    Risk1 --> Mitigation["Network Segmentation<br/>(isolate from corporate/cardholder data networks)"]
    Risk2 --> Mitigation
    Risk3 --> Mitigation
    Risk4 --> Mitigation

Many ICS/SCADA protocols (e.g., Modbus, DNP3) were never built with security capabilities and, in some cases, cannot be secured even if desired — reinforcing the need for network segmentation so a compromised ICS device cannot become an entry point into, for example, credit card data or the broader corporate network.

Key points: wireless has made connectivity far easier — for legitimate users and attackers alike, since an attacker no longer needs to be physically inside the building. Wireless implementations require correct configuration and deliberate network architecture (segmentation, hardening).

Telephony, Mobile Devices, and Converged Communications

Telephony is far less operationally critical today than in the 1990s, when business continuity/disaster recovery plans often prioritized restoring telephone systems above all else. Recovery priority shifted first to text/email, and today frequently to the organization’s website.

Historically, large organizations ran a Private Branch Exchange (PBX) — an internal mini telephone switch managing extensions and voicemail, bridging internal and external calls. Misconfigured/compromised PBXes enabled toll fraud (attackers dialing in and placing long-distance calls billed to the company, sometimes costing tens of thousands of dollars) and provided attackers with a covert communications channel.

Voice over IP (VoIP) failed in its mid-1990s attempts due to insufficient network bandwidth (excessive latency and jitter — variation in packet arrival time). Once network speeds improved, VoIP became dominant, and most organizations now run voice end-to-end over IP. This consolidates telephone and data onto a single network — cheaper, but also a single point of failure, and one where eavesdropping or denial-of-service against voice traffic becomes easier than on a dedicated, separate telephone network.

The proliferation of Internet of Things (IoT) devices — many with weak or no security — has expanded the pool of devices recruited into botnets (e.g., IP cameras used to flood a victim). Devices like smart TVs, which include built-in microphones, introduce direct eavesdropping risk in spaces like conference rooms.

Bring Your Own Device (BYOD) — and its variant, Choose Your Own Device (CYOD), where the organization offers a limited list of approved devices — reduces hardware costs and lets users work on devices they prefer, but introduces auditor concerns:

• What happens to corporate data on a personal device when the employee leaves?
• Mobile Device Management (MDM) addresses this: remote wipe capability for lost/stolen devices, and sandboxing sensitive corporate data away from unauthorized access on the same device.

Other converged-communication risk areas auditors must consider:

Key points: securing network components depends on correct configuration, disciplined change control over that configuration, a maintained asset inventory, and trained users — all in service of protecting network operations and every device connected to the network.

Summary

This domain — Information Asset Security and Control — together with its companion domain, Security Event Management, accounts for 26% of the CISA examination, the single largest weighting on the exam. The role of the auditor throughout is to examine the security control review process itself: are the right frameworks in place, are they enforced, and is the resulting protection actually effective?

Golden rules to remember:

• Identity and Access Management is the heartbeat of security — it must be actively managed, not just documented.
• Data classification and encryption protect an organization’s most valuable assets — classification drives how data must be handled; encryption protects it in storage and transit.
• Without physical access security, there is no security — technical controls cannot compensate for uncontrolled physical access.
• When non-compliance is discovered during an audit, the first step is to gather more information before making any recommendation — do not jump to conclusions or remediation advice prematurely.

Exam Content Outline Coverage Map

flowchart TD
    Domain["CISA Domain 6:<br/>Protection of Information Assets (26%)"]
    Domain --> PartA["Part A: Information Asset<br/>Security and Control (this course)"]
    Domain --> PartB["Part B: Security Event Management<br/>(companion course)"]
    PartA --> M1["Information Asset Security<br/>Frameworks, Standards & Guidelines"]
    PartA --> M2["Privacy Principles &<br/>Physical/Environmental Controls"]
    PartA --> M3["Identity and Access<br/>Management"]
    PartA --> M4["Network and<br/>Endpoint Security"]
    PartA --> M5["Data Classification"]
    PartA --> M6["Data Encryption &<br/>Encryption-Related Techniques"]
    PartA --> M7["Public Key<br/>Infrastructure (PKI)"]
    PartA --> M8["Web-Based Communication<br/>Techniques"]
    PartA --> M9["Virtualized<br/>Environments"]
    PartA --> M10["Mobile, Wireless,<br/>and IoT Devices"]

Quick-Reference Table

Self-Assessment Questions

The following self-assessment questions and rationale are drawn from this domain’s official study guide and are representative of the style of question asked on the CISA exam.

Glossary Quick Reference

Study Checklist

• Explain why standards/frameworks must be tailored, not applied identically, across organizations.
• Name the ISO 27001 ISMS requirement areas and the ISO 27002 control clause groupings.
• Describe the policy → standard → baseline → procedure hierarchy and what an auditor checks at each level.
• Distinguish data sensitivity from data criticality, and name the IAM-related data-handling roles (owner, custodian, security administrator, user).
• Walk through symmetric encryption end to end, including the role of the IV and out-of-band key distribution.
• Explain the asymmetric “keys only work as a pair” rule and how it enables both confidentiality (via hybrid encryption/digital envelopes) and digital signatures.
• Differentiate hashing, HMAC/keyed hashing, and digital signatures — and what guarantee each one does and does not provide.
• Describe how a PKI certificate is issued, what a CRL is for, and what an auditor checks in a PKI implementation.
• List the four IAM lifecycle stages (identification, authentication, authorization, accounting) and give at least one audit test for each.
• Explain the three authentication factor categories and why MFA requires two different categories.
• Define FRR, FAR, and the Crossover Error Rate, and explain the sensitivity trade-off.
• Compare DAC, MAC, RBAC, rule-based, temporal, and attribute-based access control, and state the one rule that differentiates DAC from MAC.
• Describe SSO’s benefits and risks (single point of failure/compromise, inflexibility) and how RADIUS and Kerberos each implement centralized authentication.
• Compare the OSI 7-layer model to the TCP/IP 4-layer model.
• Trace the WAN technology evolution from leased lines through X.25, Frame Relay, ATM, to MPLS.
• List firewall types by capability and the classic attacks (spoofing, fragmentation, source routing, tunneling) firewalls must mitigate.
• Describe bastion hosts, DMZs, IDS vs. IPS detection methods, and the purpose of a honeypot.
• Explain the difference between virtualization and cloud computing, and list the NIST SP 800-145 five essential characteristics.
• Identify wireless risks across 802.11, Bluetooth, and ICS/SCADA, and the primary mitigation (network segmentation) for legacy operational technology.
• Explain BYOD/MDM considerations and common converged-communication risks (social media, P2P, IM, executive phishing).

Search Terms

protection · information · assets · isaca · governance · risk · compliance · networking · systems · security · auditing · access · management · network · algorithms · asset · authentication · data · encryption · fundamentals · implementations · models · principles · privacy