Page |1

ISO/IEC 27001:2022 introduces a streamlined and updated approach to managing information

security controls compared to the previous 2013 version. The core controls are now organized into
four broad themes and presented in Annex A of the standard. These are sometimes referred to as the
baseline or reference controls.

Here are the 93 baseline controls from ISO/IEC 27001:2022 Annex A, categorized under the four
control themes:

1. Organizational Controls (37 controls)

Examples include:

• A.5.1 Policies for information security

• A.5.7 Threat intelligence
• A.5.9 Inventory of information and other associated assets
• A.5.23 Information security for use of cloud services
• A.5.30 ICT readiness for business continuity

2. People Controls (8 controls)

Examples include:

• A.6.1 Screening
• A.6.3 Information security awareness, education and training
• A.6.4 Disciplinary process
• A.6.5 Responsibilities after termination or change of employment

3. Physical Controls (14 controls)

Examples include:

• A.7.1 Physical security perimeter

• A.7.4 Physical security monitoring
• A.7.8 Equipment siting and protection
• A.7.9 Security of assets off-premises

4. Technological Controls (34 controls)

Examples include:

• A.8.9 Configuration management

• A.8.10 Information deletion
• A.8.11 Data masking
• A.8.16 Monitoring activities
• A.8.23 Web filtering
• A.8.34 Protection of log information

Highlights of the 2022 Update:

• The total number of controls was reduced from 114 (in 2013) to 93.
• New controls were added, such as:
o Threat intelligence (A.5.7)
o Information security for cloud services (A.5.23)
 Page |2

o Data masking (A.8.11)

o Web filtering (A.8.23)
• Controls were grouped by themes, making implementation more manageable and aligned
with modern risk scenarios.

Information Security for Use of Cloud Services (Control A.5.23 – ISO/IEC 27001:2022)

This control is one of the new additions in the 2022 revision of ISO 27001, introduced to address the
security challenges of using cloud services—whether public, private, or hybrid.

Objective of A.5.23

To ensure that security risks associated with the use of cloud services are identified, assessed, and
managed, and that cloud services are used securely and responsibly.

Key Concepts & Requirements

1. Risk Assessment of Cloud Services

o Before adopting any cloud service, organizations must assess:
▪ The sensitivity of the data stored or processed in the cloud
▪ The impact of potential incidents (data breaches, outages)
▪ The jurisdiction and location of data storage
2. Due Diligence in Cloud Provider Selection
o Evaluate the security posture of the cloud service provider (CSP)
o Confirm the provider complies with standards (e.g., ISO 27017, ISO 27018, SOC 2)
o Ensure transparency in terms of services, security measures, and auditability
3. Contractual & Legal Considerations
o Contracts should cover:
▪ Data ownership and control
▪ Service Level Agreements (SLAs) for availability and incident response
▪ Liability in case of breaches or data loss
▪ Compliance with data protection regulations (e.g., GDPR)
4. Security Responsibilities & Shared Responsibility Model
o Define who is responsible for what (e.g., encryption, access control)
o Understand that in cloud, responsibilities are shared between the provider and the
customer
5. Access Control and Authentication
o Ensure strong identity and access management (IAM) is enforced for cloud resources
o Use multi-factor authentication (MFA) for sensitive operations
6. Data Protection and Encryption
o Encrypt data in transit and at rest
o Control and manage encryption keys, especially in multi-tenant environments
7. Monitoring and Logging
o Ensure appropriate logging of access and activities in the cloud
o Integrate cloud logs into central SIEM systems if possible
8. Incident Management
o Cloud providers should support your incident detection and response plans
o You should have processes in place to respond to cloud-related incidents

How It Applies in Practice

For example, if your organization is using Microsoft Azure, Amazon Web Services (AWS), or Google
Cloud Platform (GCP), you need to:
 Page |3

• Conduct a risk-based assessment of what data/services you’re hosting there

• Define controls for data access, monitoring, backup, and recovery
• Ensure vendor SLAs meet your security requirements
• Align usage with your information security management system (ISMS)

What Are Encryption Keys?

Encryption keys are strings of bits used by encryption algorithms to convert plaintext (readable data)
into ciphertext (scrambled, unreadable data) and vice versa. They are a critical component of
cryptography, ensuring data remains confidential and secure.

Basic Concept

• Plaintext → (Encrypt with key) → Ciphertext

• Ciphertext → (Decrypt with key) → Plaintext

Without the correct key, encrypted data is practically impossible to decrypt (assuming strong
encryption).

Types of Encryption Keys

1. Symmetric Keys

• Same key is used for both encryption and decryption.

• Fast and efficient.
• Must be securely shared between sender and receiver.

Examples:

• AES (Advanced Encryption Standard)

• DES (now outdated)

🔸 Use case: Encrypting databases, internal files, backups.

2. Asymmetric Keys (Public Key Cryptography)

• Uses a key pair: one public key and one private key.
• Public key encrypts the data, private key decrypts it.
• Eliminates the need to share secret keys.

Examples:

• RSA
• ECC (Elliptic Curve Cryptography)

🔸 Use case: Secure email (PGP), digital signatures, TLS (HTTPS).

Key Management Is Crucial

Improper management of keys undermines security, regardless of how strong the encryption is.

Key management involves:

 Page |4

• Generating strong keys securely

• Storing them in secure places (e.g., hardware security modules – HSMs, key vaults)
• Rotating keys regularly
• Revoking or destroying compromised or unused keys

🔒 ISO/IEC 27001 references key management in several controls (especially A.8.24: Use of
cryptography).

What is Cryptography?

Cryptography is the science and art of securing information by transforming it into a form that only
authorized parties can understand. It protects data from unauthorized access, tampering, or forgery,
whether the data is stored or transmitted.

In Simple Terms:

Cryptography turns your message into a secret code (called ciphertext) that only someone with the
right key can decode back into the original message (plaintext).

Core Techniques in Cryptography

1. Encryption

• Converts plaintext into ciphertext using an encryption algorithm and a key.

• Types:
o Symmetric encryption (same key to encrypt/decrypt)
o Asymmetric encryption (public/private key pair)

2. Hashing

• Converts data into a fixed-length string (hash value).

• One-way function – can’t be reversed.
• Used for password storage, integrity checks (e.g., SHA-256, MD5).

3. Digital Signatures

• Ensures authenticity and integrity of a message.

• Uses asymmetric keys (sender signs with private key, receiver verifies with public key).

4. Key Exchange

• Securely shares keys between parties (e.g., Diffie-Hellman algorithm).

What is MFA (Multi-Factor Authentication)?

Multi-Factor Authentication (MFA) is a security method that requires users to provide two or more
independent credentials (factors) to verify their identity before granting access to a system,
application, or account.

Why MFA Matters

MFA greatly reduces the risk of unauthorized access, even if a password is compromised—because
attackers would also need the second (or third) factor.
 Page |5

Use Case MFA Methods Involved

Online banking login Password + OTP sent to phone
Workplace VPN access Password + hardware token (e.g., RSA SecurID)
Google/Microsoft login Password + Authenticator app (TOTP or push notification)
Biometric smartphone unlock Fingerprint + device PIN

Variants of MFA

• 2FA (Two-Factor Authentication): MFA with exactly two factors

• Adaptive/Contextual MFA: Adds or removes factors based on risk (e.g., location, device)
• Passwordless MFA: Uses biometrics or trusted devices without traditional passwords

MFA and ISO 27001

In ISO/IEC 27001:2022:

• MFA is recommended as part of Access Control (e.g., A.5.15: Access Control Policy)
• Supports strong authentication practices, especially for remote access, privileged accounts,
and cloud services

Security Tip

MFA is only effective if:

• Users don’t reuse passwords

• MFA methods (e.g., SMS) are secure—prefer authenticator apps or hardware tokens
• There are protections against phishing and SIM swap attacks

How RSA SecurID Works

At the core is a time-synchronized one-time password (OTP):

1. The user has an RSA token (either physical or software-based).

2. The token generates a new numeric code every 60 seconds (usually 6 or 8 digits).
3. To log in, the user provides:
o Their username
o A PIN (something they know)
o The token code (something they have)
4. The authentication server checks if the token code matches what is expected at that time for
that specific token.

Token Type Description

Hardware Token Small key fob with LCD displaying OTP
Software Token Mobile or desktop app that shows OTP
Cloud-based Integrated with RSA Cloud Authentication Service
Biometric Options RSA supports integration with biometrics
 Page |6

Security Features

• Time-based OTPs: Codes change every minute and are synchronized with RSA server.
• PIN-protection: Tokens are often paired with a personal PIN.
• Tamper-resistant hardware: Hardware tokens are hard to clone or reverse-engineer.
• Centralized management: Admins can revoke tokens, enforce policies, monitor access.

Typical Use Cases

• VPN or remote access to corporate networks

• Secure access to cloud services (via integration)
• Access to enterprise applications (SAP, Salesforce, etc.)
• Government or military secure systems

Pros of RSA SecurID

• Proven, enterprise-grade security

• Works in offline environments (hardware tokens don’t need connectivity)
• Central management and integration with identity systems

Cons

• Hardware tokens can be lost or damaged

• Deployment and licensing can be expensive
• May be overkill for small organizations or low-risk environments

RSA SecurID and ISO 27001

RSA SecurID helps meet access control requirements in ISO/IEC 27001, such as:

• A.5.15 – Access control policy

• A.5.17 – Authentication information
• A.5.18 – Secure log-on procedures

What is Design Effectiveness and Operational Effectiveness (in the context of IT controls)?

These two terms are critical concepts in IT control assessments, especially in audits (like ISO 27001,
SOC 1/2, or internal control reviews such as SOX).

1. Design Effectiveness

Design effectiveness assesses whether a control is properly designed to prevent or detect specific risks
before they occur.

A control is design effective if:

• It addresses a specific risk or control objective

• It includes clear procedures, roles, and tools
• It is appropriate for the environment (e.g., frequency, automation, relevance)

Example: A control says: “Access to critical systems must be approved by a manager before
provisioning.”
 Page |7

• Design effective if:

o There’s a documented process
o The access management system supports approval workflows
o Approval is required and logged

2. Operational Effectiveness

Operational effectiveness checks whether the control is actually being followed and works in practice
over a period of time.

A control is operationally effective if:

• It has been consistently applied

• There is evidence of execution (e.g., logs, approvals, tickets)
• It performs as expected during testing or sampling

Example (continuing from above):

• Operationally effective if:

o Access requests over the past 3–6 months consistently show manager approval
o No unauthorized access was granted
o The audit log confirms adherence

Use Case: Design Effectiveness Passes but Operational Effectiveness Fails

This scenario is very common in IT audits and helps show the gap between policy and practice.

Control: User Access Approval for Critical Systems

Control Objective: Ensure only authorized users can access critical financial systems.

Design Effectiveness – PASS

• There is a formal documented policy:

“All access to the financial system must be approved by the user’s manager and reviewed by
IT security before being granted.”

• The access management system:

o Has built-in approval workflows
o Logs all requests and approvals
o Sends alerts for unauthorized access attempts
• Role descriptions and responsibility matrices are clearly defined.

Conclusion: The control is well-designed to prevent unauthorized access.

Operational Effectiveness – FAIL

• During an audit of the last 6 months:

o 4 out of 10 sampled user access requests had no manager approval
o 2 accounts were provisioned before the approval was granted
o 1 terminated employee retained access for over 30 days
 Page |8

• IT security was unaware of one critical access request because the workflow was bypassed
manually
• Logs show inconsistent use of the approval workflow

Conclusion: The control exists, but it is not being followed consistently.

Impact

• The organization is exposed to insider threats, regulatory non-compliance, or audit failures

• Even with a solid control design, failure in operation invalidates its effectiveness

Root Cause Example

Human error Admin forgets to request approval
Process shortcuts Urgent access granted manually
Lack of oversight No regular review of access logs
Technical misconfiguration Workflow engine bypassed due to system bug

How to Fix It

1. Training: Educate stakeholders on the importance of following the access policy.

2. Automation: Enforce approval steps in the access management system (no manual overrides).
3. Monitoring: Run weekly access audits or alerts for deviations.
4. Accountability: Escalate repeated process violations to management.

Common Information Security Interview Questions

1. What is the CIA triad? Explain each component.

Tip: Confidentiality, Integrity, Availability — explain with examples.

2. What are the different types of cybersecurity threats?

Phishing, malware, ransomware, DoS/DDoS, insider threats, zero-day exploits, etc.

3. Explain the difference between symmetric and asymmetric encryption.

Symmetric uses the same key; asymmetric uses a public/private key pair.

4. What is a firewall, and how does it work?

Controls traffic based on rules, can be network or host-based.

5. How do you secure data in transit and at rest?

Encryption protocols like TLS for transit, AES for storage.

6. What is multi-factor authentication (MFA)? Why is it important?

Two or more authentication factors; reduces risk of compromised credentials.

 Page |9

7. What are some common vulnerabilities and how do you mitigate them?

Examples: SQL injection, cross-site scripting (XSS), buffer overflow; mitigation via validation,
patching, firewalls.

8. What is the difference between vulnerability assessment and penetration testing?

Assessment finds weaknesses; pentesting attempts to exploit them.

9. How would you handle a security breach?

Incident response plan, containment, eradication, recovery, lessons learned.

10. Explain the concept of least privilege.

Users have only the permissions necessary to perform their jobs.

11. What is social engineering? How can organizations protect against it?

Manipulating people to give info; training and awareness help defend.

12. What experience do you have with security frameworks or standards?

ISO 27001, NIST, CIS Controls, GDPR, HIPAA, PCI-DSS, etc.

13. How do you stay updated with the latest security threats and trends?

Following blogs, threat intelligence feeds, forums, certifications.

14. Describe how you would secure a cloud environment.

Identity & access management, encryption, logging, shared responsibility model.

15. What tools have you used for monitoring or securing networks?

• SIEMs (Splunk, QRadar), firewalls, IDS/IPS, antivirus, vulnerability scanners.

Behavioral/Scenario Questions

• Tell me about a time you detected or prevented a security incident.

• Describe a challenging security project you worked on.
• How do you balance security needs with business requirements?
• Have you ever had to convince management to invest in security? How?

common behavioral interview questions in Information Security. These answers are structured with
the STAR method (Situation, Task, Action, Result) to help you frame your responses clearly and
impactfully.

1. Tell me about a time you detected or prevented a security incident.

• Situation: At my previous company, we noticed unusual login patterns during off-hours on

our VPN.
 P a g e | 10

• Task: I was tasked with investigating to determine if this was a breach or false alarm.
• Action: I analyzed VPN logs, correlated with user activity, and identified that several
credentials were compromised in a phishing attack. I immediately worked with the IT team to
block affected accounts, forced password resets, and implemented MFA across the VPN.
• Result: The attack was contained without any data loss, and the company strengthened access
controls to prevent future incidents.

2. Describe a challenging security project you worked on.

• Situation: We had to migrate sensitive customer data to a new cloud provider under tight
deadlines.
• Task: I was responsible for ensuring the data remained secure during and after the migration.
• Action: I conducted a thorough risk assessment, implemented encryption both in transit and at
rest, configured strict IAM policies, and set up continuous monitoring with alerts for unusual
activity. I also coordinated training sessions for the team on cloud security best practices.
• Result: The migration was successful without security incidents, and compliance audits
afterward showed full adherence to security policies.

3. How do you balance security needs with business requirements?

• Situation: In one case, the sales team requested easier remote access to CRM systems, which
posed a security risk.
• Task: I needed to provide access while maintaining security controls.
• Action: I proposed implementing a VPN with MFA, along with device compliance checks. I
worked closely with sales to ensure the solution was user-friendly but secure, providing
training and support.
• Result: The solution was well adopted, improving productivity without increasing risk, and
management appreciated the balanced approach

4. Have you ever had to convince management to invest in security? How?

• Situation: Our company lacked a centralized log management system, increasing risk and
complicating audits.
• Task: I needed to convince management to invest in a SIEM tool.
• Action: I prepared a business case highlighting recent industry breaches, potential financial
and reputational losses, and how SIEM would enhance incident detection and compliance. I
also included cost-benefit analysis and phased implementation plans.
• Result: Management approved the investment, and after deployment, we detected and
resolved multiple threats early, demonstrating clear ROI.

Steps to Prepare for an IT Internal Audit

1.Understand the Audit Scope & Objectives

• Clarify which systems, processes, or controls will be audited.

• Know the audit standards (e.g., ISO 27001, SOX, COBIT).

2.Review Relevant Policies and Procedures

• Ensure policies and procedures are up to date and align with standards.
• Identify any gaps or outdated documentation.

3. Conduct a Self-Assessment
 P a g e | 11

• Perform an internal risk and controls assessment.

• Identify weaknesses or compliance gaps.

4. Gather Documentation and Evidence

• Collect control evidence: logs, access records, change management tickets, system
configurations, etc.
• Prepare an audit evidence repository for easy access.

5. Communicate with Stakeholders

• Inform relevant teams about the upcoming audit.

• Clarify roles and responsibilities for audit support.

6. Remediate Known Issues

• Address known control failures or vulnerabilities before the audit.

• Document remediation steps and status.

7. Prepare Staff

• Train or brief employees on audit expectations and potential questions.

• Ensure key personnel are available during the audit.

8. Mock Audit / Walkthrough

• Perform internal walkthroughs or dry-runs of controls.

• Validate control operation and evidence readiness.

Steps to Prepare for an

IT External Audit

External audits usually have a formal scope and are often conducted by independent auditors for
compliance or certification.

1. Understand Audit Scope and Standards

• Confirm audit scope, criteria, and timeline with auditors.

• Examples: ISO 27001 certification, SOC 2, PCI-DSS, GDPR compliance.

2. Review Previous Audit Reports

• Identify past findings and remediation.

• Ensure recurring issues are resolved.

3. Update Policies and Procedures

Make sure all documents reflect current operations and standards.

4. Ensure Evidence Readiness

 P a g e | 12

• Organize logs, reports, and control evidence systematically.

• Use a secure shared repository for auditors.

5. Perform Pre-Audit Internal Assessment

• Conduct a thorough internal audit or self-assessment.

• Correct any gaps proactively.

6. Engage Stakeholders and Communicate

• Notify management, IT teams, and business units.

• Define contact points for auditors.

7. Prepare for Interviews

• Train personnel likely to be interviewed.

• Practice clear, concise, and honest communication.

8. Arrange Logistics

• Set up audit workspace if needed.

• Ensure remote access or physical access is arranged.

9. Follow Up and Track Issues

• After audit, track and remediate any findings promptly.

• Prepare management responses and corrective action plans.

Additional Tips

• Keep documentation clear, concise, and up to date — auditors rely heavily on this.
• Automate evidence collection where possible (e.g., SIEM logs, change management tools).
• Treat audits as opportunities to improve security posture, not just compliance checkboxes.
• Maintain continuous compliance — audits are easier if controls run daily.

What is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It is a global security standard
designed to ensure that all companies that process, store, or transmit credit card information maintain
a secure environment.

Purpose:

To protect cardholder data and reduce credit card fraud.

Key Requirements (12 Core Controls):

1. Install and maintain a firewall to protect cardholder data.

2. Do not use vendor-supplied defaults for system passwords.
3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open networks.
5. Use and regularly update antivirus software.
 P a g e | 13

6. Develop secure systems and applications.

7. Restrict access to cardholder data by business need-to-know.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
10. Track and monitor all access to network resources and cardholder data.
11. Test security systems and processes regularly.
12. Maintain a policy that addresses information security.

Who Must Comply?

Any entity that accepts, transmits, or stores credit card data — including merchants, payment
processors, financial institutions, and service providers.

PCI Compliance Levels (for merchants):

Based on transaction volume, ranging from Level 1 (highest) to Level 4 (lowest), with different
reporting requirements.

1. Penetration Testing (Pentest)

Purpose: Simulate real-world attacks to identify exploitable vulnerabilities in systems, networks,

applications, or processes.

Details: Involves ethical hackers (internal or external) trying to break into systems.

• Goes beyond scanning — actively exploits weaknesses.

• Can be black-box (no prior info), white-box (full info), or gray-box (partial info).
• Tests configuration issues, authentication flaws, business logic errors, etc.

Outcome: Detailed report with proof-of-concept exploits, risk ratings, and remediation steps.

2. Secure Code Scanning

Purpose: Identify insecure coding practices and software vulnerabilities in source code during
development.

Details: Uses Static Application Security Testing (SAST) tools.

• Scans source code, bytecode, or binaries without executing them.

• Detects issues like:
o SQL injection
o Cross-site scripting (XSS)
o Hardcoded credentials
o Insecure APIs

Tools: SonarQube, Checkmarx, Veracode, Fortify, GitHub Code Scanning.

Outcome: Report with code-level issues and suggestions for secure coding practices.

3. Vulnerability Assessment (Testing)

 P a g e | 14

Purpose: Automated scanning of systems to identify known vulnerabilities (software bugs, outdated
versions, misconfigurations).

Details: Less aggressive than pentests.

• Uses tools like Nessus, Qualys, or OpenVAS.

• Regularly scheduled as part of patch management or system hardening.

Outcome: Vulnerability report with CVSS scores, affected assets, and recommendations.

4. SOC 2 Type II Report

SOC 2 = Service Organization Control Type 2

Purpose: Third-party audit report evaluating a company’s controls over data based on Trust Services
Criteria:

• Security
• Availability
• Processing integrity
• Confidentiality
• Privacy

Type II: Covers effectiveness of controls over time (typically 6–12 months), unlike Type I, which
only tests at a single point in time.

Who needs it?

• SaaS providers
• Cloud services
• Managed IT providers

Issued by: Independent CPA or audit firm.

Outcome: Formal report validating a company’s controls — often required by enterprise clients.

Activity Purpose Depth Frequency Regulatory Use

Quarterly / Not mandatory but highly
Pentest Simulated attack Deep
Annually recommended
Secure Code Fix insecure coding
Medium CI/CD pipelines SDLC / DevSecOps
Scan early
Vulnerability Identify known Weekly /
Broad Compliance & hygiene
Scan flaws Monthly
Third-party control
SOC 2 Type II High Annually For vendor trust / compliance
audit

What is a SIEM Tool?

SIEM stands for Security Information and Event Management. A SIEM tool is a software solution
that collects, aggregates, analyzes, and correlates security events and logs from various sources across
an organization to:
 P a g e | 15

• Detect threats
• Investigate incidents
• Trigger alerts
• Generate compliance reports

Core Functions of a SIEM Tool

Function Description
Gathers logs from servers, firewalls, applications, endpoints, databases, cloud
Log Collection
services, etc.
Event Correlation Connects related events from different sources to detect patterns or anomalies.
Notifies security teams about potential incidents (e.g., brute force attempts,
Alerting
data exfiltration).
Dashboards Visualizations for real-time monitoring and threat tracking.
Incident Response Helps investigate and respond to threats faster using playbooks or integrations.
Compliance Generates audit-ready reports for standards like PCI DSS, ISO 27001, HIPAA,
Reporting SOC 2.

Popular SIEM Tools

Tool Notes
Powerful and widely used; supports custom dashboards and advanced
Splunk
analytics.
IBM QRadar Enterprise-grade with strong correlation and threat detection.
Microsoft Sentinel
Cloud-native SIEM with AI/ML capabilities.
(Azure)
Elastic Security Built on the ELK stack; open-source friendly.
LogRhythm Integrated threat intelligence and response automation.
AlienVault (AT&T Affordable option for small/mid-size businesses with built-in threat
USM) intelligence.
ArcSight (Micro Focus) Mature SIEM with advanced correlation capabilities.

Benefits

• Early threat detection

• Better incident response
• Centralized visibility
• Helps meet compliance requirements
• Reduces dwell time (how long threats go unnoticed)

Real-Life Use Case

A SIEM tool can detect:

• A login from an unusual location

• A spike in outbound traffic from a server
• Multiple failed logins in short time (potential brute force)
 P a g e | 16

It can correlate these events, flag them, and alert your SOC (Security Operations Center).

Interface, API, and Middleware — and how they relate to each other in a typical IT or software
environment:

1. Interface

Definition: An interface is a point where two systems, components, or users interact.

Types:

• User Interface (UI): What a human sees and interacts with (e.g. buttons, forms on a website).
• Software Interface: How two programs or systems communicate internally (includes APIs,
libraries, etc.).

Think of it as a bridge or touchpoint between two separate parts of a system.

2. API (Application Programming Interface)

Definition: An API is a set of rules and protocols that allow one software application to interact with
another.

Key Concepts:

• Allows programs to talk to each other.

• Hides complexity, exposing only what is necessary.
• Uses endpoints and HTTP methods in web APIs (e.g., GET /users, POST /orders).

Example: A weather app gets current conditions by calling a weather service API:

3. Middleware

Definition: Middleware is software that connects different applications or services, often sitting
between a frontend and backend, or between multiple systems.

Roles:

• Data translation or transformation

• Authentication/authorization
• Message routing
• Logging and monitoring
• Transaction management

Types:

• Message-Oriented Middleware (MOM): For asynchronous communication (e.g., RabbitMQ).

• Database Middleware: Connects applications to databases.
• Remote Procedure Call (RPC) Middleware: Allows remote function execution.
• API Gateway (as middleware): Controls and secures APIs.

Think of middleware as a traffic controller that ensures proper, secure, and consistent
communication between systems.
 P a g e | 17

Summary Comparison

Component Role Example Real-world analogy

Interface Interaction point Web form, login screen Door handle
Programmatic Waiter taking your
API RESTful API for payments
communication order
API Gateway, ESB, Message Translator or traffic
Middleware System integration glue
Queue cop

Risk, Threat, and Vulnerability — foundational concepts in information security and risk
management:

1. Risk

Definition: Risk is the potential for loss or damage when a threat exploits a vulnerability.

Formula (conceptual): Risk = Threat × Vulnerability × Impact

Example: If sensitive customer data (asset) is stored on a server with weak access controls
(vulnerability), and hackers are actively trying to steal data (threat), there’s a risk of a data breach.

2. Threat

Definition: A threat is anything that has the potential to cause harm to an asset.

Types of Threats:

• Natural: Earthquake, flood

• Technical: Malware, ransomware, DDoS attack
• Human: Insider threats, phishing, social engineering

Example: A cybercriminal trying to steal passwords is a threat to your system.

3. Vulnerability

Definition: A vulnerability is a weakness or flaw in a system that can be exploited by a threat.

Types of Vulnerabilities:

• Outdated software
• Weak passwords
• Misconfigured firewalls
• Lack of encryption

Example: Not patching a known security bug in a web application is a vulnerability.

Concept Definition Example

Risk Likelihood and impact of harm Data breach costing $1M
 P a g e | 18

Concept Definition Example

Threat Something that can cause harm Hacker, virus, disgruntled user
Vulnerability Weakness threat can exploit No 2FA, outdated firewall

How Does a Firewall Work?

A firewall is a security system (hardware, software, or both) that monitors and controls incoming and
outgoing network traffic based on pre-defined security rules.

Purpose of a Firewall

To act as a barrier between:

• Trusted internal networks (like your corporate LAN)

• Untrusted external networks (like the Internet)

It helps:

• Block unauthorized access

• Permit legitimate communication
• Prevent attacks like malware, port scanning, or data exfiltration

How It Works – Step-by-Step

1. Traffic Inspection

Every packet of data entering or leaving your network passes through the firewall.

2. Rule Evaluation

The firewall evaluates traffic against a set of rules (e.g., block port 23, allow HTTP on port
80).

3. Decision: Allow or Block

Based on rules, the firewall either:

o Allows traffic through

o Blocks or drops it
o Logs or alerts an admin (optional)

Types of Firewalls

Type Description Example Use

Packet-Filtering
Checks headers like IP, port, protocol Blocks Telnet traffic
Firewall
Stateful Inspection Allows only related
Tracks active connections
Firewall return traffic
Proxy Firewall Intercepts all communication between endpoints Filters web access
 P a g e | 19

Type Description Example Use

Next-Gen Firewall Combines deep packet inspection, intrusion Detects malware or
(NGFW) prevention, application awareness encrypted threats
Cloud/Virtual Deployed in cloud environments (e.g., AWS,
Firewall Azure)

Real-Life Example

Let’s say a firewall has this rule:

❌ Block all incoming traffic on port 23 (Telnet)

✅ Allow outbound HTTPS traffic on port 443

• If a hacker tries to connect via Telnet → Blocked

• If a user opens a secure website → Allowed

Firewall Use Cases

• Preventing unauthorized remote access

• Enforcing network segmentation
• Filtering web content
• Containing malware spread
• Protecting cloud workloads

Section 1: Advanced InfoSec Topics for Interview Preparation

• Zero Trust Architecture: Emphasizes "never trust, always verify"—ensures least privilege
access across users, devices, networks.

• Data Loss Prevention (DLP): Prevents sensitive data leaks through policy enforcement and
monitoring (email, USB, cloud uploads).

• Endpoint Detection and Response (EDR): Real-time visibility and response for endpoint
threats. E.g., CrowdStrike, SentinelOne.

• Security Awareness Program Implementation: Phishing simulations, LMS-based training,

tracking user completion rates and metrics.

• Business Continuity vs Disaster Recovery: BC = keep business running during a disruption.

DR = restore systems after an event.

• Insider Threat Detection: Use of behavioral analytics, UEBA, unusual access logs, and
privileged user activity monitoring.

• Logging & Monitoring Maturity: Includes log correlation, alert tuning, dashboards, threat
hunting, and SIEM optimization.

Section 2: IT General Controls (ITGC)

• Change Management: Ensure that code/system changes are approved, tested, documented,
and properly deployed.
 P a g e | 20

• Logical Access Management: Control who has access to what, and ensure periodic user
access reviews and prompt termination.

• Backup and Recovery Controls: Evaluate frequency, offsite backup, encryption, and
recovery testing with evidence.

• Job Scheduling Controls: Monitor batch job completion, errors, overrides. Ensure alerts for
failures.

• Interface Controls: Validate data between systems using reconciliations, error logs, or
automated validations.

• SDLC Controls: Secure dev life cycle practices—peer reviews, code repositories, separation
of duties between developers/testers.

Section 3: ITRA (IT Risk Assurance)

• Control Risk Assessment (CRA): Identify risks, assess control design & implementation,
rate residual risk.

• Walkthroughs & Testing: Understand process, identify key controls, sample transactions,
gather evidence.

• Third-Party Risk Management: Review SLAs, collect SOC 2 Type II reports, assess
access/data protection practices.

• Information Produced by Entity (IPE): Confirm report source, accuracy, completeness, and
data integrity.

• SOX Examples: Critical controls include timely user terminations, system access approvals,
change management approvals.

Section 4: Internal Audit Interview Readiness

• Sampling Techniques: Random sampling for statistical inference; judgmental for high-risk
areas.

• Root Cause Analysis: Use 5-Whys or Fishbone method. Go beyond the surface issue to
address the real failure.

• Documentation Standards: Ensure audit evidence is complete, indexed, reviewable, and

supports your conclusion.

• Deficiency Evaluation (SOX):

o Control Deficiency: Failure in control design or operation.

o Significant Deficiency: Less severe than MW but requires management attention.

o Material Weakness: Reasonable possibility that a material misstatement won't be

prevented/detected.

• Agile/DevOps Auditing: Include sprint reviews, backlog reviews, version control checks,
CI/CD pipeline controls.
 P a g e | 21

• Integrated Audits: Combine IT and business process controls (e.g., revenue cycle with SAP
access controls).

Q: How would you assess the effectiveness of a privileged access review process?

• Check frequency and scope of reviews

• Determine if privileges align to roles

• Verify prompt de-provisioning

• Sample evidence of past reviews (e.g., approvals, corrections made)

Q: Describe how you’d test backup recovery controls.

• Review backup schedules and tools

• Request logs and reports of success/failure

• Validate restore test results

• Confirm offsite backup encryption and access controls

Q: What controls would you test for user termination in a SOX ITGC environment?

• Sample terminated users for timely account removal

• Check HR to IT system mapping

• Review automated de-provisioning evidence

• Confirm access removal from all systems (AD, apps)

Q: Explain a scenario where an IPE control failed and how you validated the report afterward.

• Cause: Manual change to filter logic

• Validation: Rebuild report from raw source

• Compare expected vs actual output

• Lock filters, document versioning and change logs

Q: How do you audit agile development environments?

• Review sprint boards, DevOps pipelines

• Confirm secure coding practices, approvals

• Check segregation of duties in CI/CD tools

• Validate backlog item traceability and defect fixes

Q: Walk me through the steps of performing a third-party risk assessment.

• Identify all vendors

• Categorize by criticality/data access

• Collect SOC reports, questionnaires

 P a g e | 22

• Assess controls: access, data handling, incident response

• Track remediation and reassess annually