Class 11: Secure Protocols, Email Security, DNS Security, and Application Protections

Secure protocol

A secure protocol protects network communication with security features such as encryption, authentication, integrity checking, or certificate validation.

Example: An administrator uses encrypted remote management instead of a clear-text protocol.

Memory trick: Secure protocol = protected conversation.

Trick question tip: Encryption, protected credentials, certificates, and secure alternatives are secure-protocol clues.

Insecure protocol and clear text

An insecure protocol lacks adequate protection and may transmit readable clear-text data such as credentials, commands, or content.

Example: A packet capture reveals an unprotected login request.

Memory trick: Clear text means anyone who sees it can read it.

Trick question tip: Readable intercepted traffic means the protocol lacks confidentiality protection.

HTTP versus HTTPS

HTTP sends web traffic without built-in encryption, while HTTPS protects HTTP with TLS.

Example: A login page uses HTTPS instead of HTTP to protect submitted credentials.

Memory trick: The S means secure.

Trick question tip: HTTP commonly uses TCP port 80; HTTPS commonly uses TCP port 443.

Telnet versus SSH

Telnet sends remote-management sessions in clear text, while SSH encrypts logins, commands, and session traffic.

Example: A network engineer disables Telnet and permits SSH for router administration.

Memory trick: Telnet tells; SSH secures.

Trick question tip: Remote command-line management should use SSH rather than Telnet.

SSL versus TLS

SSL is the older deprecated predecessor to TLS, while TLS is the modern protocol family used to secure network communication.

Example: A server disables SSL and older TLS versions and allows only approved TLS settings.

Memory trick: SSL is old; TLS is current.

Trick question tip: The term SSL may appear informally, but the secure modern choice is TLS.

TLS certificate and CA

A TLS certificate binds a server identity to a public key, and a Certificate Authority signs certificates so clients can validate trust.

Example: A browser trusts a web server certificate because it chains to a trusted CA.

Memory trick: Certificate links identity to key; CA signs trust.

Trick question tip: Certificates support authentication and key trust, not just encryption.

Certificate management

Certificate management includes obtaining, installing, configuring, monitoring, renewing, revoking, and replacing certificates.

Example: Administrators track expiration dates so a web service does not break trust.

Memory trick: Certificates need lifecycle care.

Trick question tip: Expired, misconfigured, untrusted, or revoked certificates can break secure protocols.

Cryptographic key handling

Cryptographic key handling includes generating, storing, distributing, protecting, rotating, revoking, and destroying keys.

Example: A private key is stored securely and replaced after suspected exposure.

Memory trick: Protect the keys that protect the data.

Trick question tip: Strong encryption is weakened if private keys are exposed or mishandled.

Secure protocol overhead and complexity

Secure protocols can add processing, certificate management, troubleshooting difficulty, and configuration complexity, but they protect sensitive traffic.

Example: Encrypted traffic is harder to inspect directly, so administrators rely on logs and approved tools.

Memory trick: Security adds work but protects data.

Trick question tip: Complexity is not a valid reason to use clear-text protocols without documented justification and compensating controls.

Default ports and security through obscurity

A default port is the usual port associated with a protocol, but changing a port does not make an insecure protocol secure.

Example: A management service moves to a nonstandard port but still requires encryption and strong authentication.

Memory trick: Moving the door is not locking it.

Trick question tip: Changing ports may slow discovery but should not replace hardening or secure protocols.

TCP versus UDP

TCP is connection-oriented and reliable, while UDP is connectionless and lower-overhead but does not guarantee delivery or ordering.

Example: File transfer favors TCP, while streaming or voice may favor UDP.

Memory trick: TCP checks; UDP sends fast.

Trick question tip: Reliability and ordering point to TCP; real-time speed and connectionless traffic point to UDP.

Protocol selection

Protocol selection chooses communication methods based on data sensitivity, security requirements, performance, compatibility, cost, risk, and policy.

Example: Sensitive file transfer uses a secure protocol instead of a clear-text legacy option.

Memory trick: Choose the protocol by risk and purpose.

Trick question tip: Sensitive data should trigger secure protocol selection and documentation.

Secure protocol exception

A secure protocol exception is a documented, approved justification for temporarily using an insecure protocol when a secure alternative is not feasible.

Example: A legacy device uses an insecure protocol only while replacement is planned and compensating controls are applied.

Memory trick: Exception means documented risk, not convenience.

Trick question tip: Insecure protocols require justification, risk acceptance, and compensating controls.

SFTP versus FTPS

SFTP secures file transfer over SSH, while FTPS secures FTP using TLS.

Example: One partner uses SFTP through SSH, while another uses FTPS with certificates.

Memory trick: SFTP rides SSH; FTPS rides TLS.

Trick question tip: The similar names are a common Security+ trap.

TLS handshake

The TLS handshake authenticates parties as required, negotiates security parameters, and establishes protected session keys.

Example: A browser and server exchange hello messages, certificate information, key-establishment data, and finished messages before encrypted traffic begins.

Memory trick: Handshake sets up the secure conversation.

Trick question tip: TLS version, cipher suite, certificates, and key establishment are handshake clues.

Cipher suite

A cipher suite is a named set of algorithms used by TLS for key exchange, authentication, encryption, and integrity.

Example: A server supports only approved modern cipher suites.

Memory trick: Cipher suite = crypto recipe.

Trick question tip: Disable weak cipher suites rather than merely listing them later.

TLS downgrade attack

A downgrade attack attempts to force a connection to use a weaker protocol version or cipher suite.

Example: An on-path attacker tries to make a client and server use older TLS settings.

Memory trick: Downgrade means force weaker security.

Trick question tip: Disabling old versions and weak algorithms helps prevent downgrades.

TLS 1.2 versus TLS 1.3

TLS 1.2 can be secure when configured with approved cipher suites, while TLS 1.3 removes many legacy features and improves handshake efficiency and downgrade resistance.

Example: A service enables TLS 1.3 and keeps TLS 1.2 only with strong settings for compatibility.

Memory trick: TLS 1.3 is cleaner, faster, and safer.

Trick question tip: TLS 1.0 and TLS 1.1 are legacy and should not be used for modern secure deployments.

LDAP and LDAPS

LDAP accesses directory services, while LDAPS protects LDAP communication with TLS.

Example: An application queries a directory securely using LDAPS rather than clear-text LDAP.

Memory trick: LDAP reads the directory; LDAPS protects it.

Trick question tip: Directory queries involving users, groups, computers, or printers point to LDAP or LDAPS.

LDAP bind types

An anonymous bind requires no credentials, a simple bind uses a username and password, and SASL supports stronger authentication mechanisms.

Example: A directory service disables anonymous access and requires secure authenticated binding.

Memory trick: Anonymous is no proof, simple is basic, SASL is stronger.

Trick question tip: Anonymous directory access is risky because it can expose information to anyone.

SASL

Simple Authentication and Security Layer is a framework that adds authentication mechanisms to protocols such as LDAP.

Example: A directory service uses a stronger SASL method instead of a clear-text simple bind.

Memory trick: SASL strengthens protocol authentication.

Trick question tip: SASL is a framework, not one single password or encryption method.

SNMP

SNMP monitors and manages network devices by collecting status information and sometimes changing device settings.

Example: A monitoring server checks switch interface status and device health.

Memory trick: SNMP watches network equipment.

Trick question tip: SNMP versions and community strings are common exam clues.

SNMPv1 and SNMPv2 risk

SNMPv1 and SNMPv2 rely on community strings that may be transmitted without strong protection and are often left as defaults.

Example: An attacker captures a community string and reads device information.

Memory trick: Community string = weak shared password.

Trick question tip: Default public or private community strings are major SNMP risks.

SNMPv3

SNMPv3 adds stronger security features such as authentication, integrity, and encryption for device monitoring and management.

Example: A network team upgrades monitoring to SNMPv3 and disables older versions.

Memory trick: SNMPv3 is the secure SNMP choice.

Trick question tip: Use SNMPv3 when secure network-device monitoring is required.

Email protocol roles

SMTP sends mail between clients and servers or between mail servers, while POP3 and IMAP retrieve mailbox messages for users.

Example: A user submits mail through SMTP and reads mail through IMAP.

Memory trick: SMTP sends; POP3 and IMAP retrieve.

Trick question tip: Sending mail points to SMTP; accessing a mailbox points to POP3 or IMAP.

Secure email transport ports

SMTPS or authenticated mail submission commonly uses secure submission on port 587, POP3S commonly uses 995, and IMAPS commonly uses 993.

Example: A mail server requires authentication on port 587 and mailbox access through IMAPS.

Memory trick: 587 submit, 995 POP3S, 993 IMAPS.

Trick question tip: SMTP sends; POP3S and IMAPS secure mailbox access.

STARTTLS

STARTTLS upgrades an existing clear-text protocol session to use TLS when both sides support it.

Example: A mail connection begins normally and then negotiates encryption before sensitive exchange.

Memory trick: Start clear, then start TLS.

Trick question tip: STARTTLS depends on proper configuration and downgrade protection.

Email spoofing and phishing

Email spoofing forges sender information, while phishing uses deceptive messages to steal information or trigger unsafe actions.

Example: A message pretends to come from an executive and links to a fake sign-in page.

Memory trick: Spoofing pretends; phishing tricks.

Trick question tip: Sender forgery points to spoofing; credential theft or malicious links point to phishing.

Spam

Spam is unsolicited or unwanted email, often sent in bulk and sometimes used to deliver scams, phishing, or malware.

Example: An email gateway filters large volumes of unwanted promotional and fraudulent messages.

Memory trick: Spam = unwanted bulk email.

Trick question tip: Anti-spam filtering is commonly handled by email gateways.

SPF

Sender Policy Framework verifies whether the sending server is authorized to send mail for a domain using a DNS TXT record.

Example: A receiving server checks whether the sender’s IP address appears in the domain’s approved sender list.

Memory trick: SPF checks sending server permission.

Trick question tip: Authorized sending IP addresses and DNS TXT records point to SPF.

DKIM

DomainKeys Identified Mail lets a sending domain digitally sign email so receivers can verify selected message content was not modified.

Example: A receiving server checks a DKIM signature using a public key published in DNS.

Memory trick: DKIM signs the message.

Trick question tip: Digital signature, message integrity, and DNS public key point to DKIM.

DMARC

DMARC uses SPF and DKIM results to define how receiving servers should handle messages that fail authentication checks.

Example: A domain tells receivers to quarantine or reject messages that fail validation.

Memory trick: DMARC tells receivers what to do with failed mail.

Trick question tip: Policy actions such as none, quarantine, reject, and reporting point to DMARC.

SPF versus DKIM versus DMARC

SPF checks whether a sending server is authorized, DKIM verifies a message signature and integrity, and DMARC tells receivers what policy action to take when alignment fails.

Example: SPF validates the sending IP, DKIM validates the signature, and DMARC rejects spoofed mail.

Memory trick: SPF server, DKIM signature, DMARC decision.

Trick question tip: Sender IP means SPF; signed message integrity means DKIM; reject/quarantine policy means DMARC.

S/MIME

S/MIME uses certificates to provide email encryption and digital signatures for confidentiality, integrity, authentication, and non-repudiation.

Example: A user signs an email and encrypts it to the recipient’s certificate.

Memory trick: S/MIME secures the message body.

Trick question tip: SPF, DKIM, and DMARC authenticate domains; S/MIME can protect message content.

Secure email gateway

A secure email gateway filters inbound and outbound email for spam, phishing, malware, malicious links, spoofing, policy violations, and data leakage.

Example: A gateway blocks a malicious attachment and flags suspicious sender authentication results.

Memory trick: Gateway checks mail before users get it.

Trick question tip: Email filtering, attachment scanning, link rewriting, and DLP point to a secure email gateway.

Attachment sandboxing

Attachment sandboxing opens suspicious email attachments in an isolated environment to observe behavior before delivery.

Example: A document attachment is detonated safely and blocked when it attempts malicious actions.

Memory trick: Sandbox tests the file safely.

Trick question tip: Opening files in isolation to observe behavior points to sandboxing.

URL rewriting and link protection

URL rewriting changes links in email so clicks pass through a security service that checks destination risk at click time.

Example: A link that was safe at delivery is blocked later after its destination becomes malicious.

Memory trick: Rewrite links to check them later.

Trick question tip: Time-of-click protection and rewritten email links point to URL protection.

DNS

DNS translates human-readable domain names into IP addresses and other records needed for network services.

Example: A client queries DNS to find the address of a mail or web service.

Memory trick: DNS is the internet phonebook.

Trick question tip: Name resolution problems and domain records point to DNS.

DNS record types

Common DNS records include A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail exchange, NS for authoritative name servers, PTR for reverse lookup, and TXT for text-based policies.

Example: A domain publishes MX records for mail and TXT records for email authentication.

Memory trick: A and AAAA address; MX mail; TXT policies.

Trick question tip: SPF, DKIM, and DMARC commonly use DNS TXT records.

DNS zone transfer risk

A DNS zone transfer copies zone data between servers, but unauthorized transfers can expose internal hostnames and network structure.

Example: An administrator restricts zone transfers to approved secondary DNS servers.

Memory trick: Zone transfer copies the map.

Trick question tip: Unauthorized access to full DNS zone data points to zone-transfer risk.

DNS cache poisoning

DNS cache poisoning inserts false DNS information into a resolver cache so users are sent to the wrong destination.

Example: A poisoned cache directs users to an attacker-controlled address.

Memory trick: Poisoned DNS gives the wrong answer.

Trick question tip: Wrong destination after name resolution points to DNS poisoning.

DNSSEC

DNSSEC adds digital signatures to DNS data so resolvers can validate authenticity and integrity of DNS responses.

Example: A resolver rejects a tampered DNS response because the signature validation fails.

Memory trick: DNSSEC signs DNS answers.

Trick question tip: DNSSEC protects integrity and authenticity, not confidentiality.

DoH versus DoT

DNS over HTTPS sends DNS queries through HTTPS, while DNS over TLS sends DNS queries through a dedicated TLS-protected DNS channel.

Example: A client encrypts DNS queries so they are not readable on the local network.

Memory trick: DoH uses HTTPS; DoT uses TLS directly.

Trick question tip: Both protect DNS privacy in transit but can complicate enterprise monitoring.

DNS filtering

DNS filtering blocks or redirects name-resolution requests for malicious, prohibited, or risky domains.

Example: A resolver refuses to resolve a known phishing domain.

Memory trick: Block the name before connection starts.

Trick question tip: DNS filtering is efficient but usually less detailed than full web-content inspection.

Application protection

Application protection uses secure coding, input validation, code signing, sandboxing, exception handling, memory safety, least privilege, and update controls to reduce software risk.

Example: A developer validates input, signs releases, and runs risky code in an isolated environment.

Memory trick: Protect the app before and while it runs.

Trick question tip: Application protections often target injection, memory issues, untrusted code, and unstable failures.

OWASP and OWASP Top 10

OWASP provides application-security guidance, and the OWASP Top 10 identifies major categories of common web application security risks.

Example: A development team uses OWASP guidance to prioritize injection and access-control testing.

Memory trick: OWASP helps secure web apps.

Trick question tip: Common web vulnerabilities and mitigation guidance point to OWASP.

Software assurance maturity model

A software assurance maturity model helps organizations measure and improve how well security is integrated into software development.

Example: A company reviews its secure coding, testing, and deployment practices to improve maturity.

Memory trick: Maturity model shows how grown-up the security process is.

Trick question tip: Measuring and improving secure development practices points to a maturity model.

Untrusted input

Untrusted input is any data supplied to an application that cannot be assumed safe, correct, or authorized.

Example: A web form receives text from an unknown user and validates it before processing.

Memory trick: Treat outside input like it might lie.

Trick question tip: User-supplied data should be validated before use.

Input validation

Input validation checks whether data matches expected type, format, length, range, and business rules before processing.

Example: A form accepts only valid dates in the required format.

Memory trick: Check input before trusting it.

Trick question tip: Preventing injection and rejecting malformed data point to input validation.

Client-side versus server-side validation

Client-side validation runs on the user’s device and improves usability, while server-side validation runs on the trusted server and enforces security.

Example: A browser checks an email format before submission, and the server validates it again before processing.

Memory trick: Client helps users; server protects the app.

Trick question tip: Client-side validation can be bypassed, so server-side validation is required.

Injection attack

An injection attack inserts malicious input that an application interprets as a command, query, script, or code.

Example: A malicious input attempts to change how a database query runs.

Memory trick: Injection sneaks commands through input.

Trick question tip: SQL injection, command injection, code injection, and XSS are injection-related risks.

SQL injection

SQL injection uses malicious input to alter database queries and access, modify, add, or delete data improperly.

Example: A login field is protected with parameterized queries so input is treated only as data.

Memory trick: SQLi attacks the database through input.

Trick question tip: Database query manipulation points to SQL injection.

Code injection

Code injection causes an application or interpreter to run attacker-supplied code.

Example: Input handling blocks unexpected executable commands from being processed.

Memory trick: Code injection makes the app run attacker code.

Trick question tip: Executing attacker-supplied commands or scripts points to code injection.

Parameterized query

A parameterized query keeps SQL instructions separate from user-supplied values so input is treated as data rather than executable query syntax.

Example: A submitted name is passed as a parameter instead of being concatenated into a database command.

Memory trick: Separate the command from the data.

Trick question tip: Parameterized queries are a primary defense against SQL injection.

Digital signature for software

A digital signature on software helps verify the publisher and confirm the code has not been altered since signing.

Example: An installer displays a verified publisher because the software is properly signed.

Memory trick: Signature proves source and integrity.

Trick question tip: Unsigned or improperly signed software creates trust warnings.

Code signing

Code signing applies a digital signature to software, scripts, drivers, or updates so systems can verify origin and integrity.

Example: A deployment tool allows only signed packages from approved publishers.

Memory trick: Signed code is easier to trust.

Trick question tip: Code signing reduces tampering risk but does not prove the software has no vulnerabilities.

Structured exception handling

Structured exception handling defines how an application responds to errors so failures do not expose sensitive details, crash unsafely, or allow exploitation.

Example: An application handles invalid input gracefully instead of exposing stack traces.

Memory trick: Handle errors safely.

Trick question tip: Graceful error handling reduces information leakage and unstable failure behavior.

Buffer overflow

A buffer overflow occurs when an application writes more data into memory than a buffer can hold, potentially overwriting adjacent memory.

Example: A program rejects oversized input instead of allowing it to corrupt memory.

Memory trick: Too much data spills past the buffer.

Trick question tip: Memory size, stack, overwritten return address, or unsafe memory operations point to buffer overflow.

Memory-safe coding

Memory-safe coding prevents unsafe memory operations through bounds checking, safer languages, compiler protections, and careful input handling.

Example: A developer avoids unsafe functions and validates input length before copying data.

Memory trick: Do not let data spill into memory it should not touch.

Trick question tip: Memory safety reduces buffer overflow and similar memory-corruption risks.

Sandboxing

Sandboxing runs code in an isolated environment so crashes, malware, or suspicious behavior are contained away from the host system.

Example: A suspicious file is opened in a sandbox before being allowed on user endpoints.

Memory trick: Sandbox = safe play area.

Trick question tip: Isolated execution for testing or containment points to sandboxing.

Application allowlisting

Application allowlisting permits only approved software to run and blocks unapproved or unknown programs.

Example: A workstation runs only applications from a managed approved list.

Memory trick: Only approved apps run.

Trick question tip: Allowlisting is stricter than blocklisting and helps stop unknown malware.

Application blocklisting

Application blocklisting blocks known prohibited or malicious software while allowing other applications by default.

Example: Endpoint controls block a known unauthorized tool.

Memory trick: Blocklist says what cannot run.

Trick question tip: Blocklisting is easier to deploy but weaker against unknown malicious software than allowlisting.

Secure protocol and application defense in depth

Secure communication and application protection combine TLS, certificates, strong keys, secure email controls, DNS protection, input validation, code signing, sandboxing, and monitoring.

Example: A hosted app uses HTTPS, SPF/DKIM/DMARC for mail, DNSSEC where appropriate, and secure coding controls.

Memory trick: Protect the channel, the message, the name lookup, and the application.

Trick question tip: No single protocol or coding control solves every communication and application-security risk.