Security Concepts for Solutions Architects

Security is a foundational element in solutions architecture, crucial for protecting data, preventing cyber threats, ensuring compliance, and maintaining business continuity. Solutions architects must embed security into every stage of the development lifecycle, from planning to maintenance, rather than treating it as an afterthought. This document covers these topics from a beginner to an advanced level.

1. Core Security Principles

1.1. The CIA Triad

The CIA triad is a model designed to guide policies for information security within an organization.

• Confidentiality: Ensuring that sensitive information is accessible only to authorized individuals.

  • Use Case: Protecting customer data in a CRM system. Only authorized sales and marketing personnel should be able to access customer contact information and purchase history. This can be achieved through a combination of encryption, access control lists, and data classification.

• Integrity: Guaranteeing that data remains accurate, complete, and unaltered throughout its lifecycle.

  • Use Case: Ensuring the integrity of financial transactions. When a customer makes a purchase on an e-commerce website, the transaction details (e.g., amount, credit card number) must be protected from tampering. This can be achieved using hashing algorithms and digital signatures.

• Availability: Ensuring that systems and resources are accessible and usable when needed by authorized users.

  • Use Case: Ensuring the availability of an e-commerce website during a flash sale. The website must be able to handle a large volume of traffic without crashing. This can be achieved through load balancing, redundancy, and disaster recovery planning.

1.2. The AAA Framework

The AAA framework is a security framework that provides a foundation for controlling access to resources.

• Authentication: The process of verifying the identity of a user or system.

  • Use Case: A user logging into a mobile banking app. The user must provide their username and password, and may also be required to provide a one-time password (OTP) sent to their phone (MFA).

• Authorization: The process of granting or denying access to a resource based on the user's identity and permissions.

  • Use Case: A manager approving an expense report. The manager has the authorization to approve or deny expense reports, while other employees do not.

• Accounting: The process of logging user activity to be used for auditing and billing purposes.

  • Use Case: Tracking user activity for compliance with regulations like GDPR. All user activity, such as accessing customer data or making changes to the system, must be logged and auditable.

1.3. Non-Repudiation

Non-repudiation is the assurance that someone cannot deny the validity of something. It is a way to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.

• Use Case: A legally binding digital contract. When two parties sign a contract electronically, they use digital signatures to ensure that neither party can later deny having signed the contract.

2. Security Architecture and Design

2.1. Defense in Depth

Defense in depth is a security strategy that uses multiple layers of security controls to protect an organization's assets. The idea is that if one layer of security is breached, the next layer will provide protection.

• Use Case: A layered security architecture for a cloud-based application.
  • Perimeter Layer: A web application firewall (WAF) to protect against common web attacks, and a network firewall to restrict traffic to and from the application.
  • Authentication and Authorization Layer: Multi-factor authentication (MFA) for all users, and role-based access control (RBAC) to restrict access to sensitive data and functionality.
  • Application Layer: Secure coding practices to prevent vulnerabilities like SQL injection and cross-site scripting (XSS), and regular vulnerability scanning.
  • Data Layer: Encryption of data at rest and in transit, and regular data backups.
  • Monitoring and Logging Layer: Centralized logging and monitoring of all security events, and automated alerts for suspicious activity.

2.2. Security by Design

Security by design is the practice of building security into the design of a system from the very beginning. This is in contrast to the traditional approach of adding security on as an afterthought.

• Use Case: Developing a secure API. The API should be designed with security in mind from the start, including:
  • Authentication and Authorization: All API requests must be authenticated and authorized.
  • Input Validation: All input from the client must be validated to prevent injection attacks.
  • Output Encoding: All output to the client must be encoded to prevent XSS attacks.
  • Rate Limiting: The API should be rate-limited to prevent denial-of-service attacks.

2.3. Threat Modeling

Threat modeling is a process for identifying, analyzing, and mitigating threats to a system. It is a proactive approach to security that can help to prevent attacks before they happen.

• Use Case: A threat model for an online banking application.
  • Identify Assets: The most valuable assets are customer data (e.g., account numbers, balances, transaction history) and the application itself.
  • Identify Threats: The threats to these assets include:
    • Unauthorized access to customer data: An attacker could steal customer data by exploiting a vulnerability in the application or by tricking a user into revealing their login credentials.
    • Fraudulent transactions: An attacker could use stolen credentials to make fraudulent transactions.
    • Denial of service: An attacker could launch a denial-of-service attack to make the application unavailable to legitimate users.
  • Identify Mitigations: The mitigations for these threats include:
    • Strong authentication and authorization: MFA, RBAC.
    • Secure coding practices: Input validation, output encoding.
    • Vulnerability scanning and penetration testing.
    • Intrusion detection and prevention systems.
    • DDoS protection services.

3. Zero Trust Architecture

Zero Trust is a security model that is based on the principle of "never trust, always verify." In a Zero Trust architecture, no user or device is trusted by default, even if it is on the corporate network.

3.1. Core Principles

• Verify Explicitly: Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.
  • Use Case: A user trying to access a sensitive application from a new location might be required to provide additional authentication, even if they have already logged in. The system might also check the user's device to ensure that it is compliant with security policies (e.g., has the latest security patches installed).
• Use Least Privilege Access: Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive polices, and data protection.
  • Use Case: A developer might be granted temporary access to a production database to fix a bug. The access would be automatically revoked after a certain period of time, and the developer would only have access to the specific data they need to fix the bug.
• Assume Breach: Minimize blast radius and segment access. Verify all sessions are encrypted end to end.
  • Use Case: A network might be segmented into smaller, isolated zones, so that if one zone is compromised, the attacker cannot easily move to other zones. All traffic between zones would be encrypted, and all access would be logged and monitored.

3.2. Key Components

• Identity and Access Management (IAM): A central component of Zero Trust, IAM is used to authenticate and authorize users and devices. This includes technologies like MFA, SSO, and privileged access management (PAM).
  • Use Case: A user logs in to their corporate portal using SSO and MFA. The IAM system then grants them access to the applications and resources they need to do their job, based on their role and permissions.
• Micro-segmentation: The practice of dividing a network into small, isolated segments to limit the blast radius of an attack.
  • Use Case: A hospital network is segmented to isolate patient data from the rest of the network. This prevents an attacker who compromises a user's laptop from accessing patient data.
• Endpoint Security: Protecting endpoints, such as laptops, servers, and mobile devices, from attack. This includes technologies like antivirus, anti-malware, and endpoint detection and response (EDR).
  • Use Case: An EDR solution is used to detect and respond to malware on a user's laptop. The EDR solution can automatically quarantine the laptop and notify the security team.
• Security Analytics: Collecting and analyzing security data to detect and respond to threats. This includes technologies like SIEM and SOAR.
  • Use Case: A SIEM system is used to collect and analyze logs from all of the devices on the network. The SIEM system can detect suspicious activity, such as a user trying to access a sensitive application from a new location, and generate an alert.

4. Cloud-Native Security

4.1. The 4 Cs of Cloud-Native Security

• Cloud: The underlying infrastructure, which is provided by the cloud provider. Security at this layer is the responsibility of the cloud provider.
  • Security Concerns: Physical security of data centers, network infrastructure, and hypervisor.
  • Examples: AWS, Azure, Google Cloud.
• Cluster: The container orchestration layer, such as Kubernetes. Security at this layer is a shared responsibility between the cloud provider and the customer.
  • Security Concerns: Securing the Kubernetes API server, etcd, and other control plane components. This includes using strong authentication and authorization, and regularly patching the cluster.
• Container: The container runtime, such as Docker. Security at this layer is the responsibility of the customer.
  • Security Concerns: Securing the container image, the container runtime, and the container itself. This includes scanning container images for vulnerabilities, and using a secure container runtime.
• Code: The application code. Security at this layer is the responsibility of the customer.
  • Security Concerns: Secure coding practices, input validation, and output encoding. This includes using a secure framework, and regularly scanning the code for vulnerabilities.

4.2. Cloud Security Posture Management (CSPM)

CSPM is the process of identifying and remediating misconfigurations in cloud environments. CSPM tools can be used to scan for misconfigurations, such as open S3 buckets, and to automate the remediation of these misconfigurations.

• Use Case: A CSPM tool is used to scan an AWS environment for misconfigurations. The tool finds an open S3 bucket that contains sensitive data. The tool automatically remediates the misconfiguration by closing the S3 bucket.

4.3. Cloud Workload Protection Platform (CWPP)

CWPP is a security solution that is designed to protect workloads in cloud environments. CWPPs can be used to protect workloads from a variety of threats, such as malware, exploits, and denial-of-service attacks.

• Use Case: A CWPP is used to protect a web application running in a Kubernetes cluster. The CWPP can detect and block attacks, such as SQL injection and cross-site scripting (XSS). The CWPP can also provide visibility into the security posture of the workload.

5. Application Security

5.1. Secure Software Development Lifecycle (SDLC)

The secure SDLC is a process for building security into the software development lifecycle.

5.2. OWASP Top 10

The OWASP Top 10 is a list of the 10 most common web application security risks. The 2021 list includes:

1. A01:2021 - Broken Access Control: Failures in enforcing restrictions on what authenticated users are allowed to do. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or modify other users' data.
   • Example: An application allows a user to change their password by sending a request to https://example.com/changepassword?user=someuser. An attacker can change the user parameter to another user's username and change their password. A proper implementation would only allow a user to change their own password, based on their session information.
2. A02:2021 - Cryptographic Failures: Failures related to cryptography, which often lead to sensitive data exposure.
   • Example: An application stores passwords in plaintext in the database. If the database is compromised, all the passwords will be exposed. Passwords should always be hashed and salted before being stored.
3. A03:2021 - Injection: Flaws that allow an attacker to inject malicious data into an application. This can be used to execute arbitrary code, steal data, or take control of the application.
   • Example: A web application uses a SQL query to get data from a database. The query is constructed by concatenating a user-supplied string to the query. An attacker can supply a malicious string that will cause the query to return all the data in the database. Parameterized queries should be used to prevent SQL injection.
4. A04:2021 - Insecure Design: A new category for 2021, this focuses on risks related to design flaws.
   • Example: A web application does not have a proper password policy, allowing users to choose weak passwords. This makes it easy for an attacker to guess passwords and take over user accounts. A strong password policy should be enforced, and users should be required to change their passwords regularly.
5. A05:2021 - Security Misconfiguration: This includes issues like unpatched flaws, default configurations, and unnecessary services.
   • Example: A web server is configured with a default username and password. An attacker can use this to gain access to the server and take control of the application. Default credentials should always be changed.
6. A06:2021 - Vulnerable and Outdated Components: This category covers risks associated with using components with known vulnerabilities.
   • Example: A web application uses a third-party library that has a known vulnerability. An attacker can exploit this vulnerability to take control of the application. A software composition analysis (SCA) tool should be used to scan for vulnerable components.
7. A07:2021 - Identification and Authentication Failures: This category covers risks associated with broken authentication and session management.
   • Example: A web application does not properly invalidate session tokens after a user logs out. An attacker can use a stolen session token to gain access to the user's account. Session tokens should be invalidated on the server-side after logout.
8. A08:2021 - Software and Data Integrity Failures: A new category for 2021, this focuses on risks related to software updates, critical data, and CI/CD pipelines without verifying integrity.
   • Example: A web application downloads a software update from a third-party server without verifying the integrity of the update. An attacker can intercept the update and replace it with a malicious update. The integrity of software updates should always be verified using a digital signature.
9. A09:2021 - Security Logging and Monitoring Failures: This category covers risks associated with insufficient logging and monitoring.
   • Example: A web application does not log failed login attempts. This makes it difficult to detect and respond to brute-force attacks. All security-relevant events should be logged and monitored.
10. A10:2021 - Server-Side Request Forgery (SSRF): A new category for 2021, this covers risks associated with SSRF flaws.
    • Example: A web application allows a user to specify a URL to be fetched by the server. An attacker can use this to make the server fetch a malicious URL, which could be used to attack other systems on the internal network. The application should validate all user-supplied URLs and restrict access to internal resources.

5.3. SAST, DAST, and SCA

• Static Application Security Testing (SAST): A type of security testing that analyzes the source code of an application for vulnerabilities.
• Dynamic Application Security Testing (DAST): A type of security testing that analyzes an application while it is running.
• Software Composition Analysis (SCA): A type of security testing that analyzes the third-party components of an application for vulnerabilities.
• Use Case: These tools are used in a CI/CD pipeline to automatically scan for vulnerabilities.
  • SAST: A SAST tool is used to scan the source code for vulnerabilities every time a developer commits new code.
  • SCA: An SCA tool is used to scan the third-party components for vulnerabilities every time a new component is added to the application.
  • DAST: A DAST tool is used to scan the running application for vulnerabilities in a staging environment before it is deployed to production.

6. DevSecOps

DevSecOps is a culture and a set of practices that aims to build security into the DevOps process.

6.1. Principles

• Shift Left: The practice of moving security testing and other security activities to the left in the development lifecycle.
  • Example: Instead of waiting until the end of the development cycle to perform a security review, security is involved from the very beginning. Security requirements are defined at the beginning of the project, and security testing is performed throughout the development process.
• Automation: The use of automation to improve the speed and efficiency of the security process.
  • Example: Using automated tools to scan for vulnerabilities, perform security testing, and deploy security controls. This frees up security engineers to focus on more strategic tasks.

6.2. Security as Code

Security as code is the practice of treating security configurations as code. This allows security to be versioned, tested, and deployed in the same way as application code.

• Use Case: Managing firewall rules as code. A tool like Terraform can be used to define the firewall rules for a cloud environment. The firewall rules can be versioned in a Git repository, and they can be automatically deployed to the cloud environment. This makes it easy to track changes to the firewall rules and to roll back to a previous version if necessary.

7. Identity and Access Management (IAM)

7.1. SSO and MFA

• Single Sign-On (SSO): A system that allows users to log in to multiple applications with a single set of credentials. SSO solutions often use protocols like SAML, OAuth, or OpenID Connect.
  • Example: A user logs in to their corporate portal and is then able to access other applications, such as their email and CRM, without having to log in again.
• Multi-Factor Authentication (MFA): A security measure that requires users to provide more than one form of authentication. The factors can be something you know (password), something you have (phone), or something you are (fingerprint).
  • Example: A user logs in with their password and then has to enter a code that is sent to their phone.

7.2. Privileged Access Management (PAM)

PAM is a security solution that is designed to manage and monitor privileged access to systems and data. PAM solutions can be used to control who has access to privileged accounts, what they can do with that access, and for how long.

• Use Case: Managing access to sensitive servers in a large enterprise. A PAM solution can be used to grant a developer temporary access to a production server to fix a bug. The PAM solution would log all of the developer's activity on the server, and it would automatically revoke the developer's access after a certain period of time. This helps to prevent unauthorized access to sensitive data and to reduce the risk of a data breach.

8. Cryptography and Data Protection

8.1. Encryption

• Symmetric Encryption: A type of encryption that uses the same key for both encryption and decryption. It is fast and efficient, but the key must be shared securely.
  • Use Case: Encrypting a large file before uploading it to a cloud storage service. The file is encrypted with a symmetric key, and the key is then encrypted with the recipient's public key. The recipient can then decrypt the key with their private key and use it to decrypt the file.
• Asymmetric Encryption: A type of encryption that uses a public key for encryption and a private key for decryption. It is slower than symmetric encryption, but it is more secure because the private key does not need to be shared.
  • Use Case: Securely sending an email. The sender encrypts the email with the recipient's public key. The recipient can then decrypt the email with their private key. This ensures that only the recipient can read the email.

8.2. Public Key Infrastructure (PKI)

PKI is a system for creating, managing, and distributing digital certificates. Digital certificates are used to verify the identity of a person or device and to encrypt communications.

• Example: When you visit a website that uses HTTPS, your browser uses PKI to verify the identity of the website and to encrypt the communication between your browser and the website. The website's digital certificate is issued by a trusted certificate authority (CA), and it contains the website's public key.

9. Network Security

9.1. Segmentation

• Network Segmentation: The practice of dividing a network into smaller, isolated segments.
• Micro-segmentation: A more granular form of network segmentation that can be used to isolate individual workloads.
• Use Case: Segmenting a corporate network. The network is segmented into different zones, such as a DMZ for public-facing servers, a zone for internal servers, and a zone for user workstations. This helps to prevent an attacker who compromises a workstation from accessing sensitive data on the internal servers.

9.2. Firewalls

• Next-Generation Firewall (NGFW): A type of firewall that provides more advanced features than a traditional firewall, such as application awareness and intrusion prevention.
• Web Application Firewall (WAF): A type of firewall that is designed to protect web applications from attack.
• Use Case: Using a WAF to protect a web application from SQL injection attacks. The WAF can inspect all incoming traffic and block any requests that contain malicious SQL code. This helps to prevent an attacker from stealing data from the application's database.

10. Security Operations and Incident Response

10.1. SIEM and SOAR

• Security Information and Event Management (SIEM): A security solution that collects and analyzes security data from a variety of sources.
• Security Orchestration, Automation, and Response (SOAR): A security solution that automates the response to security incidents.
• Use Case: Detecting and responding to a malware infection. A SIEM system is used to collect and analyze logs from all of the devices on the network. The SIEM system detects a suspicious file on a user's laptop and generates an alert. A SOAR playbook is then automatically triggered to quarantine the laptop, notify the security team, and block the file from being executed on other devices.

10.2. Incident Response

The incident response lifecycle is the process of responding to a security incident. It includes the following phases: preparation, detection and analysis, containment, eradication, and recovery.

• Use Case: Responding to a data breach. A company discovers that an attacker has stolen customer data from its database. The company's incident response team is activated and follows the incident response plan. The team contains the breach by isolating the compromised database, eradicates the attacker's presence from the network, and recovers the lost data from backups. The company then notifies the affected customers and takes steps to improve its security posture to prevent future breaches.