1/15
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai | Chat |
|---|
No analytics yet
Send a link to your students to track their progress
SNMPv1
The original version of Simple Network Management Protocol (SNMP), used for monitoring and managing network devices (routers, switches, servers, etc.).
Uses "community strings" (essentially plaintext passwords) for authentication, such as a "public" string for read-only access and "private" for read-write access.
Transmits all data, including these community strings, in cleartext with no encryption, making it highly vulnerable to interception and unauthorized access.
Lacks robust error handling and has limited functionality compared to later versions.
Considered insecure and largely deprecated in modern environments due to its lack of authentication integrity and encryption.
SNMPv2c
An enhanced version of SNMP that introduced improvements like better performance, additional data types, and improved error handling (e.g., GetBulkRequest for retrieving large amounts of data more efficiently).
Still relies on the same community-string-based authentication model as SNMPv1 ("c" stands for "community-based").
Like SNMPv1, community strings and all data are transmitted in cleartext, meaning it still lacks encryption and strong authentication, leaving it vulnerable to sniffing and credential interception.
Widely used due to its added functionality, but still considered insecure for sensitive environments.
SNMPv3
The most secure version of SNMP, introducing significant security enhancements over v1 and v2c.
Provides user-based authentication (verifying the identity of the requester using usernames and cryptographic authentication, such as HMAC-MD5 or HMAC-SHA) instead of simple community strings.
Supports encryption (privacy) of SNMP messages, protecting data confidentiality in transit (commonly using DES or AES).
Offers three security levels: noAuthNoPriv (no authentication, no encryption), authNoPriv (authentication only), and authPriv (authentication plus encryption) — the most secure option.
Recommended for modern, security-conscious network management, as it directly addresses the vulnerabilities present in v1 and v2c.
Stateful Firewall
A type of firewall that monitors and tracks the state (or "context") of active network connections, such as TCP handshake status, rather than evaluating each packet in isolation.
Maintains a state table that records details of ongoing connections (source/destination IP, port, sequence numbers, connection status), allowing it to determine whether incoming packets are part of a legitimate, already-established session.
Provides more intelligent and context-aware filtering than a stateless firewall, since it can automatically allow return traffic for connections that were legitimately initiated internally, without needing an explicit rule for every possible response packet.
More effective at blocking certain types of attacks (like spoofed packets that don't belong to a valid session) compared to simple packet-filtering (stateless) firewalls.
RAID 0+1
A nested/hybrid RAID level that combines striping (RAID 0) and mirroring (RAID 1).
Data is first striped across two or more disks for performance (RAID 0), and then that entire striped set is mirrored to another identical set of striped disks (RAID 1).
Provides improved read/write performance (from striping) plus redundancy (from mirroring).
Fault tolerance is limited: if one disk fails in a striped set, that entire stripe set is considered failed, but the mirrored set can take over; however, if a second disk fails in the surviving mirrored set, the entire array fails, so it can tolerate some but not all two-disk-failure scenarios depending on which disks fail.
Requires a minimum of 4 disks and has relatively low storage efficiency (only 50% of total raw capacity is usable) since half of the total disks are used purely for mirroring.
RAID 2
A RAID level that uses bit-level striping (splitting data at the bit level across disks) combined with dedicated Hamming code error-correction/parity for fault tolerance.
Requires specialized, synchronized disk hardware and dedicated parity disks, making it complex and expensive to implement.
Largely obsolete and not used in modern systems, since modern hard drives already have built-in error detection/correction, making RAID 2's approach redundant and inefficient.
Not commonly tested or referenced in practical/modern IT environments due to impracticality.
RAID 5
A RAID level that uses block-level striping with single distributed parity, meaning the parity information is spread evenly across all disks in the array rather than stored on one dedicated disk.
Requires a minimum of 3 disks.
Provides fault tolerance for exactly one disk failure. If a single disk fails, data can be reconstructed using the parity information from the remaining disks.
Offers a good balance of storage efficiency, performance, and redundancy, making it one of the most commonly used RAID levels for general-purpose servers and storage.
Vulnerable to data loss if a second disk fails before the array finishes rebuilding after the first failure (a period sometimes called the "RAID 5 write hole" or rebuild vulnerability).
RAID 6
Similar to RAID 5 but uses double distributed parity, storing two independent sets of parity data across the array instead of one.
Requires a minimum of 4 disks.
Can tolerate up to two simultaneous disk failures while still being able to reconstruct all data, providing significantly higher fault tolerance than RAID 5.
Offers strong redundancy for critical systems where data availability is paramount, at the cost of slightly reduced write performance (due to the overhead of calculating and writing two parity sets) and somewhat lower storage efficiency compared to RAID 5.
Well-suited for large-capacity drives and critical servers, since larger drives take longer to rebuild after a failure, increasing the risk window during which a second failure could cause data loss, RAID 6's double parity mitigates this risk.
NIST 800-53
A U.S. government publication from the National Institute of Standards and Technology (NIST), formally titled "Security and Privacy Controls for Information Systems and Organizations."
Provides a comprehensive, standardized catalog of security and privacy controls designed to protect federal information systems and organizations from a wide range of threats, including cyberattacks, natural disasters, structural failures, and human error.
Organizes controls into families/categories such as access control, incident response, audit and accountability, configuration management, risk assessment, system and communications protection, and many others.
Used primarily by U.S. federal agencies to comply with the Federal Information Security Management Act (FISMA), but is also widely adopted by private-sector organizations and contractors as a best-practice framework for building strong security programs.
Provides a tiered/baseline approach, allowing organizations to select control baselines (low, moderate, high impact) based on the sensitivity and criticality of the systems and data being protected.
Frequently referenced alongside other NIST publications, such as NIST 800-37 (Risk Management Framework) which describes the process for applying and managing these controls throughout a system's lifecycle.
Regularly updated to address emerging threats and technology changes (e.g., cloud computing, supply chain risk, privacy engineering).
VPC (Virtual Private Cloud)
A logically isolated, private section of a public cloud provider's infrastructure (such as AWS, Azure, or Google Cloud) that allows an organization to run its resources in a secure, segmented virtual network.
Provides control over networking components similar to a traditional on-premises network, including custom IP address ranges (subnets), route tables, network gateways, and security groups/firewall rules.
Allows organizations to isolate their cloud resources from other tenants on the same physical cloud infrastructure, even though the underlying hardware is shared among multiple customers.
Enables segmentation within the cloud environment itself, such as separating public-facing resources (like web servers) from private/internal resources (like databases) using public and private subnets.
Often connected back to an organization's on-premises network via VPN or dedicated private connections (like AWS Direct Connect or Azure ExpressRoute), extending the organization's private network securely into the cloud.
Provides enhanced security and control compared to using default/shared cloud networking configurations, since administrators can define granular network access controls, monitor traffic flow, and restrict exposure to the public internet as needed.
Distinct from a CASB: a VPC is a network isolation/architecture construct, whereas a CASB is a security policy enforcement tool that manages user access and actions on cloud services.
. Fog computing
A distributed computing architecture that extends cloud computing and services closer to the edge of the network, positioned between centralized cloud data centers and end devices/IoT sensors.
Reduces latency and bandwidth usage by processing data closer to where it's generated, rather than sending everything back to a distant centralized cloud for processing.
Commonly used in IoT environments, smart cities, industrial control systems, and other scenarios requiring real-time or near-real-time data processing.
Acts as an intermediary layer of computing resources (routers, gateways, edge servers) between end devices and the cloud.
VM escape
An attack technique in which malicious code running inside a guest virtual machine breaks out of its isolated environment to gain unauthorized access to the underlying hypervisor or host system.
Exploits vulnerabilities in the hypervisor's isolation mechanisms, which are meant to keep each VM completely separated from the host and from other VMs running on the same physical hardware.
Considered a critical and highly dangerous vulnerability because a successful escape can allow an attacker to compromise the entire virtualized environment, including other tenants' VMs on shared infrastructure (a major concern in multi-tenant cloud environments).
Mitigated through regular hypervisor patching, strong isolation configurations, and minimizing unnecessary features/attack surface on the hypervisor.
Container breakout
An attack technique in which malicious code running inside a containerized application (such as a Docker container) escapes the container's isolated environment to gain unauthorized access to the underlying host operating system.
Exploits weaknesses in the container runtime's isolation mechanisms (since containers share the host OS kernel, unlike VMs which have their own separate OS), making container isolation inherently different and sometimes considered weaker than VM-level isolation.
Allows an attacker who breaks out of a container to potentially access the host system directly, as well as other containers running on that same host.
Mitigated through practices like running containers with least privilege, avoiding running containers as root, using container security tools, and keeping the container runtime/orchestration platform (like Docker or Kubernetes) patched and properly configured.
Distinct from VM escape specifically because it targets the host OS/container runtime directly (since containers don't have a hypervisor layer the way VMs do), rather than targeting a hypervisor managing separate guest operating systems.
POP3S
is POP3 (Post Office Protocol version 3) run over an encrypted connection — either implicitly via SSL/TLS on port 995, or via a STARTTLS upgrade on the standard POP3 port. POP3 itself is a protocol for downloading email messages from a mail server to a client, typically removing them from the server afterward (unlike IMAP, which keeps mail synced on the server). The "S" just adds transport-layer encryption so credentials and message data aren't sent in plaintext while being retrieved — it protects the connection between client and server, not the content of any individual message.
Microservices
an architectural style where an application is built as a collection of small, independent services, each responsible for a single business function (e.g., authentication, billing, inventory), rather than as one large monolithic codebase.
Each microservice runs and is deployed independently, communicates with the others over the network (commonly via APIs, REST, or messaging queues), and can be developed, updated, scaled, or restarted without requiring changes to the rest of the application. This isolation is what solves the upgrade problem in your scenario: a fix or update to one module doesn't force a redeployment of the entire platform, and a failure in one service is less likely to bring down the whole system.
Common traits include: independent deployability, loose coupling, each service owning its own data/logic, and communication over well-defined interfaces (often paired with an API gateway to route requests to the right service — which is why that option was a related but distinct concept in the previous question).
Sideloading
Sideloading
The process of installing applications on a mobile device from a source other than the device's official, sanctioned app store (e.g., installing an app directly from a downloaded file rather than through the Apple App Store or Google Play Store).
Bypasses the vetting/review process that official app stores use to screen apps for malware, privacy violations, and policy compliance, since the app is installed manually rather than through a curated, monitored marketplace.
Commonly done by transferring an app package file (like an APK on Android) directly onto the device and installing it, often requiring the user to enable a specific device setting (e.g., "allow installs from unknown sources") since it's disabled by default for security reasons.
Increases security risk because sideloaded apps can contain malware, spyware, or other malicious code that would normally be caught by an official store's review process; it also makes it harder for organizations to enforce mobile device management (MDM) policies and application allow lists.
Differs from jailbreaking in scope: sideloading only bypasses the app-store restriction to install unauthorized apps, whereas jailbreaking removes the OS's underlying security restrictions entirely, enabling both unauthorized app installs and access to system-level features/settings not normally available to the user.