CISA Encryption, PKI, Cloud, Virtualization, Mobile and IoT Security

Symmetric encryption uses one shared secret key to encrypt and decrypt, asymmetric (public key) encryption uses a mathematically linked key pair, and practical systems combine them: a fast symmetric cipher protects the data while public key methods deliver the symmetric key and sign the result. An IS auditor does not need the mathematics, but must recognise which technique delivers which property and where each one is weak.

Hybrid (envelope) encryption is the normal answer for large transfers: the sender generates a random symmetric session key, encrypts the data with it, then encrypts (wraps) that session key with the recipient's public key. Only the recipient's private key can unwrap it, so the session key never travels in clear text. Secure email and many file-transfer tools wrap the session key this way. Modern TLS (version 1.3) also relies on public key methods to set up the session key, but through key agreement (ephemeral Diffie-Hellman), so the recipient's public key never wraps the key itself.

Which key does what

• Confidentiality to one recipient: encrypt with the recipient's public key (directly, or by wrapping a session key). Only the recipient holds the matching private key.
• Origin and nonrepudiation: sign with the sender's private key. Only the sender holds it, and anyone can verify with the sender's public key.
• Both at once: wrap the session key with the recipient's public key and sign a hash with the sender's private key. Swapping either key breaks one of the two properties: wrapping with the sender's own public key means the recipient cannot decrypt, and a shared-key MAC in place of a signature gives no nonrepudiation.

Encrypting with the recipient's public key alone says nothing about who sent the message, because that key is public and anyone could have used it. When an auditor finds a scheme that only encrypts, the remaining exposure is usually authentication of the sender, not eavesdropping.

A common weakness is a sound cipher with an unsound key channel, such as a symmetric key emailed to a partner. The weakness is the channel, not the key, so every replacement key inherits it; wrapping the key with the partner's public key (or using an established key-exchange protocol) does.

A hash proves data has not changed, a message authentication code (MAC) proves it has not changed and came from someone holding a shared key, and a digital signature proves it has not changed and came from the one holder of a private key, which is what gives nonrepudiation. None of the three makes data unreadable; that is encryption's job.

Hash functions

A hash function maps any input to a fixed-length digest. It is one-way (the input cannot be recovered from the digest) and a one-bit change in the input produces a completely different digest. Recomputing a hash and comparing it with a trusted earlier value shows whether data changed; it cannot show who changed it or restore the original.

The value of a hash depends on where the reference copy lives. A checksum stored next to the file it protects can be replaced by whoever alters the file. Integrity evidence for logs or archives therefore needs the reference hashes recorded in a separately secured repository the custodians of the data cannot modify. This gives tamper evidence while leaving the data freely readable, which encryption would not.

On a channel an attacker can modify, a plain hash appended to a file only detects accidental corruption: the attacker changes the file and recomputes the hash, because no key is needed, and the choice of hash algorithm cannot change that. A MAC (commonly HMAC) mixes a secret key into the calculation, so only key holders can produce a valid value; a digital signature achieves the same with a private key.

How a digital signature works

Conceptually, using the RSA model (algorithms such as DSA and ECDSA compute and verify the signature differently, with the same result):

1. The sender hashes the message.
2. The sender encrypts (signs) the digest with its private key; the result is the signature.
3. The receiver decrypts the signature with the sender's public key, hashes the received message and compares the two digests.
4. A match proves the message is unaltered and was signed by the holder of the private key. The sender's certificate ties that public key to an identity.

Because an HMAC key is known to both parties, it cannot settle a dispute between them: the service could have produced any HMAC the customer could. Where a business needs to hold a party to a transaction, it needs signatures with keys only that party controls.

Encryption is only as strong as the management of its keys, so an IS auditor reviewing encryption spends most of the effort on the key life cycle: generation, distribution, storage, use, rotation, backup or escrow, revocation and destruction. Algorithm choice and key length rarely matter as much as who can reach the key.

What to look for

• Separate storage. Keys belong in a key management system or hardware security module (HSM) with its own access control and logging, not in a file or configuration on the server that holds the encrypted data. A key stored beside the data means one server compromise or one stolen backup image yields both.
• Segregation of duties. Encryption protects against people who can reach the data but not the key. If one database administrator can both run the database and retrieve its master key, encryption gives no protection against that person. The preventive fix is to separate the roles: key custodians have no database administration rights, and administrators cannot retrieve keys. Approval by a peer from the same team, or review after the fact, is weaker than keeping the roles apart.
• Generation and randomness. Keys should be generated by approved, well-seeded generators, ideally inside the HSM or the device that will use them.
• Rotation and cryptoperiods. Keys are replaced on a defined schedule and immediately on suspected compromise. Rotation limits how much data one key protects; it does not fix exposure in storage or distribution.
• Dual control and split knowledge for master keys and HSM administration, so no single person can extract or replace them.
• Destruction when a key's life ends, recorded so it can be evidenced (see crypto-erasure below).

Escrow: encryption keys yes, signing keys no

Keeping a recoverable copy of encryption keys is good practice: if an employee leaves or a key is lost, encrypted business data must still be readable. Keeping a copy of signing private keys destroys nonrepudiation, because anyone with access to the escrow could have produced a signature, so the signer can credibly deny it. The sound design separates the two key types: signing keys are generated on the user's own token or device and never copied, while encryption keys are escrowed under strong control. The existence of the copy is the problem, so no protection around it restores nonrepudiation.

Data needs a protection matched to each state it passes through: in transit (crossing a network), at rest (on disks, backups and media) and in staging or processing (sitting in folders, queues or memory before and after a transfer). A control for one state does nothing for the others, so an auditor follows the data end to end rather than accepting "it's encrypted".

In transit

TLS (current versions) and VPN tunnels encrypt the session between two endpoints. Once data lands, the session protection ends. A file sent over TLS and then left for days in a staging folder that server administrators can open is exposed at rest, whatever protected the transfer. Access rules administered by the very people to be kept out cannot keep them out. Encrypting the staged files under a key held by the application or service, which the administrators cannot reach, is what protects them.

At rest: the layer decides who is kept out

So when administrators must not see sensitive fields such as card numbers, the data has to be encrypted or tokenized before it reaches the database, with keys managed outside their control. Strengthening TDE itself does not change the fact that the database returns clear text to every authenticated session.

Portable devices

For laptops and removable drives the control that keeps data confidential after loss is full-disk encryption with authentication before the operating system starts (pre-boot authentication, often with a TPM). Controls enforced only by the running operating system are bypassed by removing the drive, and controls that deter theft do nothing once the device is gone.

Crypto-erasure

Destroying the keys that protect encrypted data renders every copy unreadable, wherever it sits: replicas, versions, snapshots and backups. In a cloud service, where the customer cannot inspect or sanitize the provider's media, deleting customer-controlled key material (keys generated in, and never exported from, the customer's own key service) is the strongest evidence that the data can no longer be read. Evidence that covers only the copies the customer can see, or that rests on the provider's word, is weaker.

A public key infrastructure (PKI) is the set of roles, policies and systems that binds public keys to identities through certificates, so that relying parties can trust a key they did not exchange in person; an auditor judges a PKI by its documented practices, the protection of its CA keys and how fast it can withdraw trust.

Roles

Before relying on an external CA, an auditor starts with its CPS, because it sets out how applicants are vetted and keys are protected, then looks for independent audit evidence that the CA follows it.

Protecting the root

An online root that issues every certificate directly is a single point of failure: if it is compromised, every certificate loses its basis of trust and the whole PKI must be rebuilt. Good practice keeps the root CA offline (often powered down in a vault, keys in an HSM, ceremonies under dual control) and uses it only to certify subordinate issuing CAs. A compromised subordinate can then be revoked and replaced while other branches stay trusted.

Revocation: CRL and OCSP

A certificate's expiry date is not the whole story; a CA can withdraw it early, for example after key compromise or when the holder leaves. Relying parties learn of this from:

• Certificate revocation lists (CRLs): signed lists of revoked serial numbers published periodically. A relying party that downloads the list weekly will keep accepting a certificate revoked just after the last download, for up to a week.
• Online status checking (OCSP): the relying party asks the issuer for the certificate's status when it is presented, which closes the freshness gap. More frequent CRL downloads narrow the gap but do not remove it.

When a private key is lost or stolen, the first action is to request revocation of the certificate bound to it, so that relying parties checking status reject anything the thief signs. Until the certificate is revoked, signatures made with the stolen key still validate, so every other response comes after.

In cloud computing, responsibility for operating controls is split between provider and customer according to the service model, but accountability for the customer's data never moves: the organization that owns the data answers to its customers and regulators whatever the contract says.

The split tells the auditor where to test directly. For IaaS, the provider's assurance report can cover facilities, physical access and the hypervisor, but the customer's own virtual machines (operating system patch levels, hardening, application controls) are outside it and must be tested by the customer's auditor.

Using a SOC 2 Type II report

A SOC 2 Type II report gives an independent opinion on whether the provider's controls were suitably designed and operated effectively over a period (a Type I report covers design at a point in time only). Before relying on one, check:

• Scope: the services, locations and systems you use are actually covered.
• Period and opinion: exceptions noted and their effect; if the period ended some time ago, a bridge (gap) letter from the provider covers the interval.
• Complementary user entity controls (CUECs): controls the provider assumes each customer operates, such as periodic review of its own users' access. The provider's service commitments and system requirements are achieved only if those customer controls also work, and the opinion does not extend to them. The customer's auditor must test them at the organization; the service auditor does not.
• Subservice organizations: under the inclusive method, a subservice organization's controls (for example a third-party data centre) are described and tested in the report. Under the carve-out method they are excluded, with only the expected complementary subservice organization controls listed. With carve-out, the report gives no assurance over that party, so the user auditor needs separate evidence, typically the subservice organization's own report.

A cloud contract is the customer's main control over a provider, and the clauses an IS auditor checks first are those that give continuing evidence about the provider's controls, fix where data lives, and let the organization leave with its data. Each clause addresses a specific risk, so the "best" clause depends on the risk named.

An ISO/IEC 27001 certificate answers a different question from an assurance report: it attests that an information security management system exists and was found conforming at certification and surveillance audits for its stated scope; it does not report how specific controls operated over a period.

Data residency

Where a law requires personal data to stay in a country and the provider by default spreads data and backups across regions, the first step is to resolve the legal constraint: obtain contractual commitments on where primary and backup copies reside (and later verify them). Most residency rules concern where data is held, not only who can read it, so controls that protect confidentiality do not by themselves satisfy them.

The broader vendor-selection and contract management process (due diligence, ongoing monitoring of suppliers) is taught with IT vendor management; this lesson covers the clauses that matter specifically for cloud services.

Virtualization concentrates risk in the hypervisor and its management console, because every guest depends on them for isolation, so the greatest single exposure in a virtual environment is compromise of hypervisor administration. Whoever controls the management console can start, stop, copy, reconfigure and reconnect every guest it manages.

Risks an auditor reviews

• Hypervisor and console access: few named administrators, strong (multi-factor) authentication, a separate management network, logging of console actions and timely hypervisor patching.
• Inter-VM traffic visibility: traffic between guests on the same host and the same virtual switch or segment is switched by the hypervisor and never reaches the physical network (traffic routed between segments by a physical router or firewall does leave the host). A network intrusion detection system on a physical switch port cannot see it. Virtual network monitoring or virtual firewalls are needed where guests of different trust levels talk to each other.
• Mixed trust zones: running development and production, or cardholder and general workloads, on the same host places systems of different trust levels side by side. Combined with blind inter-VM traffic, a compromised low-trust guest could attack a high-trust one unseen. Separate hosts or clusters per trust zone, or virtual segmentation with monitoring, address it.
• Snapshots and images: a VM snapshot or disk image captures the whole disk and sometimes memory, including database contents and credentials. An image kept where a broad group of staff can read it bypasses every access control inside the guest, including the database's. Images need the same classification and protection as the data inside them.
• VM sprawl: easy provisioning leaves idle, unpatched and unowned machines. Inventory, ownership and decommissioning keep it in check.
• Templates: hardened golden images should be maintained and refreshed so new guests start from a secure baseline.

Automatic movement of guests between hosts for load balancing is expected behaviour, not a finding, provided all hosts in the cluster share the same security configuration and trust zone.

Mobile devices are protected through mobile device management (MDM): enrollment before access, enforced settings (passcode, encryption, OS version), separation of company data, remote or selective wipe, and continuous compliance checks that cut off devices that fall out of policy.

Corporate and personal devices

• Lost corporate device: the control that protects its data is a remote wipe through MDM. Controls that only delay access or help find the device leave the data in place.
• Bring your own device (BYOD): the organization cannot reasonably wipe an employee's whole phone, and the employee legitimately knows the passcode. Keeping company email and files in a managed container (or managed apps) lets the organization revoke access and selectively wipe its data on departure or loss while leaving personal content alone.

Point-in-time versus continuous compliance

A check made once, when a device is first registered, says nothing about its state a month later. Jailbreaking or rooting breaks a device's security model: other apps may read company data and management restrictions may be bypassed. Posture therefore has to be evaluated continuously and tied to access, so that the management or conditional-access service cuts off or quarantines a device automatically when it falls out of policy. Periodic checks leave a window between them.

Testing MDM coverage

To show that every device reaching company data is managed, the auditor needs a population drawn from the systems devices connect through, not from the management tool, and then compares it with the managed list. A tool's own reports can describe only devices it already knows about, so they cannot reveal the ones that never enrolled.

Wireless security rests on per-user enterprise authentication, isolation of untrusted (guest) traffic and detection of rogue access points, while IoT security rests on knowing which devices exist, removing default credentials and containing devices that cannot be patched.

Wireless controls

• Shared keys: a long-unchanged pre-shared key known to former employees cannot be withdrawn from individuals. Rotating it on every departure works but is costly and error-prone. Moving to 802.1X with individual directory accounts solves the root cause with the least ongoing effort, since joiner-leaver processes already maintain those accounts.
• Server certificate validation: in password-based 802.1X methods (such as PEAP), the device builds a protected tunnel to the authentication server and sends credentials inside it. If devices do not validate the server's certificate (trusted CA and expected server name), an attacker with a look-alike access point and its own server collects the credentials. Certificate-based device authentication (EAP-TLS) avoids passwords altogether.
• Rogue access points: an access point that someone connects to the internal network without authorization creates an uncontrolled entry to the internal network, usually without the organization's authentication or encryption. Wireless scanning or a wireless intrusion prevention system, plus port-level network access control, detect and block them.
• Guest networks: a separate SSID and password control who joins; isolation controls where traffic goes. Guest traffic should reach the internet only, through a separate VLAN or connection, never the internal network.
• Protocols: WPA3 is the current standard and WPA2 remains acceptable where properly configured, especially in Enterprise mode; WEP and WPA are obsolete. Hiding the SSID and MAC address filtering are weak controls: names are still discoverable and MAC addresses are easily spoofed.

Internet-of-Things devices

Cameras, badge readers, building sensors and plant equipment are often bought by facilities or operations teams outside IT, so many are unrecorded. An IoT risk assessment therefore starts with a complete inventory of connected devices and their owners; every later control depends on knowing that population.

• Default or shared credentials: a password identical on every unit is effectively public. The preventive control is a unique credential set on each device during installation, before it is reachable.
• Devices that cannot be patched: when firmware is fixed and credentials are hard-coded, controls go around the device: an isolated network segment allowing only the traffic the device needs to its management systems, until it can be replaced.
• Support life in procurement: the cheapest point to fix firmware support is before the contract is signed. Require security updates for the device's planned service life; anything done after deployment costs more or leaves more risk.

Network segmentation design, firewalls and network access control in general are taught in the network and end-point security lesson; this section covers how they apply to wireless and IoT.