CompTIA Exam Prep - ITF+, A+, Network+, Security+, CySA+

Vendor diversity means deliberately using products from more than one supplier for a given function. The argument is that a vulnerability or failure in one vendor's product does not affect everything at once. The counter-argument is that complexity is itself a source of failure. Both are true, and the exam expects you to weigh them rather than pick a side. Monoculture risk The term comes from agriculture, where a field of genetically identical plants falls to a single disease. The computing analogue is direct: an estate where every endpoint runs the same operating system, every firewall is the same model and every server the same distribution has one set of vulnerabilities, and a flaw in any of them applies everywhere simultaneously. It compounds with automation. A configuration management system that pushes the same change to ten thousand identical machines is an efficiency until the change is wrong, at which point it is an outage delivered at scale. Supply chain concentratio...

A vulnerability advisory says a flaw affects a particular product at particular versions. Your scanner says you are running something. Deciding whether those two statements describe the same thing is the matching problem, and Common Platform Enumeration is the naming scheme that makes it machine-readable. What a CPE name is A CPE is a structured identifier with defined fields: the part (application, operating system, or hardware), the vendor, the product, the version, the update or patch level, the edition, the language, and further qualifiers such as software edition, target software, target hardware and other. The structure is the point. "Version 9.0 of the web server from that vendor" is ambiguous prose; a CPE name is a string that two tools can compare without interpretation. Advisories in the national vulnerability database list the CPE names a CVE applies to, often as ranges rather than single versions. A scanner determines the CPE names present on a host, compares...

Common Configuration Enumeration assigns a unique identifier to a specific security configuration setting, so that "the password history requirement on this operating system" means the same thing across every tool, benchmark, and report that references it. It is the configuration equivalent of what CVE does for vulnerabilities, and the distinction between the two is the concept most worth getting straight. CCE versus CVE A CVE identifies a flaw in software — a defect the vendor must fix and you must patch. You did not cause it and you cannot configure it away. A CCE identifies a configuration setting you control. Nothing is defective; the software is working as designed, and the question is whether your chosen setting is the secure one. The remedy is a configuration change rather than a patch. That difference drives different processes. Vulnerabilities flow through patch management with testing and change windows. Configuration findings flow through baseline management...

Key rotation replaces a cryptographic key with a new one. The reasons are straightforward; the reason it goes wrong is that a key is rarely in only one place, and rotating it without knowing where they all are causes an outage. Why rotate at all Limiting exposure. A key compromised at some unknown point protects everything it ever encrypted. Rotating bounds that window — material encrypted under a retired key is unaffected by compromise of the current one, and vice versa. Cryptoperiod limits. Every key has a usable lifetime based on how much data it protects and how much cryptanalysis it is exposed to. Some modes have hard limits on data volume under a single key. Personnel change. Where a human ever held or could have held the key material, rotation on departure is the only way to revoke that knowledge. Compliance. Several frameworks mandate defined cryptoperiods, and an auditor will ask for evidence of rotation rather than a policy stating it happens. Practice. The u...

Quantitative risk assessment attaches monetary values to risk so that control spending can be compared against expected loss. The formulas are simple, they appear on the exam as calculations, and knowing where their inputs come from matters as much as the arithmetic. The formulas Asset Value (AV) — what the asset is worth, including replacement, lost revenue during unavailability, and the cost of consequences such as notification and regulatory penalty. Exposure Factor (EF) — the proportion of the asset's value lost in a single occurrence, expressed as a percentage. A fire destroying a building outright is 100 percent; a disk failure in a redundant array may be 5 percent. Single Loss Expectancy (SLE) = AV × EF — the cost of one occurrence. Annualized Rate of Occurrence (ARO) — how many times per year it is expected. Once every four years is 0.25; three times a year is 3. Annualized Loss Expectancy (ALE) = SLE × ARO — the expected ann...

Reading a SOC 2 report is one skill; producing one is another. This is the producer's side — what an organization actually does to get through an audit, and where the work concentrates. If you need the consumer's perspective, the report types and how to read one are under SOC 1, SOC 2 and SOC 3 . Scoping first Two decisions shape everything else, and both are frequently made badly under sales pressure. Which systems are in scope. Narrow scope means less work and a report customers may find inadequate. Broad scope means a stronger report and substantially more effort. Scope the service customers actually buy, and be able to describe the boundary clearly — auditors ask, and a vague boundary produces findings. The boundary depends on an accurate inventory, which is why organizations discover during scoping that they do not have one. That work is upstream of the audit, not part of it, and it is the same dependency described under CMDB . Which trust services criteria. Sec...

Being compliant with PCI DSS and being able to prove it are different things. The proof is a set of validation documents, and knowing which applies to whom is the practical part of the standard. For the requirements themselves, see the PCI DSS article linked at the end. The three documents SAQ — Self-Assessment Questionnaire. A structured checklist the merchant completes themselves, with a yes/no answer for each applicable requirement. Used by merchants who are not required to undergo an external audit. ROC — Report on Compliance. A detailed report produced by a Qualified Security Assessor after an on-site assessment, documenting how each requirement was tested and what evidence was examined. Required for the largest merchants and many service providers. AOC — Attestation of Compliance. The signed declaration that the assessment was completed and states the outcome. It accompanies either an SAQ or a ROC. The relationship matters and is the most likely exam point: the SAQ or R...

Security Technical Implementation Guides are hardening standards published by the Defense Information Systems Agency. They are mandatory for US Department of Defense systems, and they are used well beyond that because they are free, detailed, and maintained — for many products a STIG is the most thorough public hardening guidance available. What is in one A STIG covers one product or product family: an operating system version, a database, a browser, a network operating system, an application server. Inside are individual requirements, each with a stable identifier, a severity category, a statement of the requirement and why it exists, an explicit check procedure describing how to determine compliance, and an explicit fix procedure describing how to remediate. The check-and-fix pairing is what distinguishes STIGs from most hardening guidance. A requirement is not a suggestion to "restrict access" — it is a specific command to run, a specific expected output, and a specif...

Computer misuse legislation exists in some form in most jurisdictions, and the concept every version turns on is authorization . Accessing a system without it, or exceeding what was granted, is the offence — and that single concept is why documented permission is the first artefact in any security engagement. This is general context rather than legal advice; specifics vary by jurisdiction and a lawyer is the right source for a real situation. Authorization is the hinge The technical act is frequently identical on both sides of the line. Sending a request to a web server is either ordinary use or the start of an offence, depending entirely on whether the sender was permitted. That is why intent and skill are not the determining factors people expect. A researcher who finds a flaw, reports it responsibly and profits in no way has still accessed a system without authorization if they had none, and jurisdictions differ considerably in how sympathetically that is treated. "Exceed...

FIPS 140-3 is the US and Canadian standard for cryptographic modules, and validation against it is mandatory for federal systems and increasingly demanded in regulated sectors. It certifies the module — the hardware or software boundary performing cryptography — not the product containing it, and the distinction is where most confusion lives. The four security levels Level 1 requires approved algorithms and correct implementation, with no physical security requirements. A software cryptographic library running on a general-purpose computer is typically Level 1, and this covers the large majority of validations. Level 2 adds tamper evidence — seals or coatings that show if the module was opened — and role-based authentication. Level 3 adds tamper resistance and response: the module actively detects intrusion and zeroises its keys when it happens. It also requires identity-based authentication and physical or logical separation of the interfaces carrying ...

NIST SP 800-61 is the incident handling guide most certification exams base their incident response questions on. Its central contribution is a four-phase lifecycle that is explicitly cyclical rather than linear — and the cycle is the part people get wrong. The four phases 1. Preparation. Everything done before an incident: the response plan, the team and its roles, communication paths, tooling and access, logging and retention, training, and tested procedures. It also covers preventing incidents in the first place, which sits slightly awkwardly in an incident handling guide and reflects that preparation is where most of the leverage is. 2. Detection and Analysis. Recognizing that something has happened and determining what. This includes monitoring sources, triaging alerts, correlating events, establishing scope, assessing impact, and prioritising. The guide is blunt that this is the hardest phase, because the signal is buried in ordinary activity and the initial report is...

Buying a penetration test is a procurement problem before it is a technical one. Two providers quoting the same engagement can differ by a factor of five in price and by rather more in what you actually receive. Accreditation and scoping are the two levers that decide which you get. What accreditation signals CREST is an accreditation body for penetration testing and incident response providers, widely recognized in the UK, Europe, Asia-Pacific, and increasingly elsewhere. It accredits organizations against assessed standards for methodology, data handling, personnel vetting, quality assurance, and complaints handling, and it certifies individual testers by examination at several levels. The organizational accreditation is the part buyers underuse. It says the company has documented processes, that reports go through review, that testers are background checked, and that there is a route to escalate when something goes wrong. Individual certification says a named person passed a pra...

COBIT is a governance framework for enterprise IT, published by ISACA. It is not a security framework, and the difference is the thing exam questions test: COBIT answers who decides, who is accountable, and how do we know IT is delivering value , while security frameworks answer what controls should exist . Governance versus management COBIT draws a hard line between the two, and it is the framework's central idea. Governance is the board's responsibility: evaluating options, directing the organization, and monitoring whether direction is being followed. It sets objectives and decides risk appetite. Management is the executive team's responsibility: planning, building, running and monitoring activities within the direction governance has set. Most organizations conflate them, and the practical symptom is a board being asked to approve technical decisions it cannot evaluate, or an IT function setting its own risk appetite by default. Separating the two is what COBIT ...

A certificate is only meaningful because something you already trust vouches for it. Public key infrastructure is the arrangement of who vouches for whom, and its structure is designed around one assumption: that a signing key will eventually be compromised, and the damage must be survivable. Why roots sign intermediates rather than end entities A root certificate authority's private key is the anchor of trust for everything beneath it, and its public certificate is embedded in operating systems and browsers. It cannot be revoked in any practical sense — revoking it means every device with it in its trust store must be updated, which for a widely distributed root is effectively impossible. So the root key is kept offline , in hardware, under multi-person control, brought out rarely and ceremonially. It signs a small number of intermediate certificates and nothing else. Intermediates do the day-to-day issuing. They are online, they are exposed, and — crucially — th...

Data protection law appears on security exams as vocabulary and accountability rather than as legal detail. The terms are consistent across regimes even where the specifics differ, and knowing who is responsible for what is the part that affects how systems are built. Controller and processor The distinction everything else hangs on. A controller determines the purposes and means of processing — why the data is collected and how it will be used. The controller is accountable for compliance and is who a regulator and a data subject deal with. A processor processes data on the controller's behalf, following instructions. A cloud provider hosting a customer's database is typically a processor; the customer is the controller. The exam point: accountability does not transfer to the processor. Engaging a processor does not move responsibility, which is the same reasoning as under the cloud shared responsibility model and under supply chain security . A controller must contr...

A risk register is the list of identified risks and what is being done about each one. Most organizations have one, and most of them are a spreadsheet nobody has opened since the last audit. The difference between a register that works and one that does not is a small number of design decisions. The fields that matter A risk statement that names cause, event and consequence. Not "ransomware" — that is a topic. Something closer to: unpatched internet-facing systems could be exploited, leading to ransomware deployment, resulting in loss of production for several days. A statement in that shape is assessable and actionable; a one-word entry is neither. A business owner. The person accountable for the risk, which is the business leader whose function bears the consequence, not the security analyst who found it. This is the field organizations get wrong most often, and it is the one that determines whether anything happens. Security teams do not own business risk; they ident...

An Information Sharing and Analysis Center is a sector-based organization through which members share threat information with each other. The argument is simple: an attacker targeting one hospital is likely targeting others, and the first victim's indicators are the second's early warning — if the first tells anyone. Why sector-specific matters Generic commercial feeds describe the whole internet's threat landscape, and most of it does not apply to you. A sector ISAC filters by relevance: the campaigns hitting organizations with the same systems, the same regulators, the same suppliers and the same adversaries. The technology overlap is the practical reason. Hospitals run the same clinical systems as other hospitals; utilities run the same control platforms; financial firms run the same trading and payment infrastructure. A vulnerability or a technique affecting one member is frequently applicable to most of them, and the shared context means the advice can be specific ...

A vendor hands you a SOC 2 report and the procurement process treats it as a pass. It is not a pass — it is a document describing what an auditor examined, over what period, and what they found. Reading it properly takes twenty minutes and regularly changes the decision. The report types SOC 1 covers controls relevant to a customer's financial reporting . Its audience is auditors, and it is the right report for a payroll processor or a service that touches your financial statements. It says little about security. SOC 2 covers controls against the trust services criteria — the security-relevant report and the one usually meant. It is restricted-use, shared under agreement, and it contains genuine detail about controls and findings. SOC 3 is a public summary of a SOC 2 with the detail removed. It tells you an audit happened and produced an opinion; it does not let you assess anything. A vendor offering only a SOC 3 has not given you what you need. Note also that an att...