Item 1.05 of Form 8-K became effective on 18 December 2023. The pitch was straightforward and, on paper, reasonable: a public company that determines it has suffered a material cybersecurity incident has four business days to say so, in a specific place, in a specific format. No more burying the disclosure in a quarterly filing eight months later. No more learning about it from the ransomware crew’s leak site. Transparency, on a clock.

Two years on, the desk has read enough of these filings to offer a verdict. The rule works exactly as written, and it has changed almost nothing about what companies actually tell their investors, because the rule regulates the paperwork and the paperwork was never the problem.

The word “material” is a door, and companies found the other exit

The whole rule turns on one word. A material incident goes under Item 1.05, with the four-day clock and the implied admission that something serious happened. So watch what companies did with the word. They stopped using the door.

By May 2024 the SEC’s own Division of Corporation Finance had to put out a statement telling companies to stop filing non-material incidents under Item 1.05, because so many were over-using the material box for incidents that were not, in fact, material. Companies complied in the most predictable way available. They moved their filings to Item 8.01, the voluntary bucket, the one that carries no admission of materiality at all. The counts since then are almost comic: of the companies filing a cyber 8-K after that guidance, the clear majority chose 8.01 over 1.05. The running tally of filings tells the same story across the full two years. The one form the entire rule was built to populate is the form companies now go out of their way to avoid.

Materiality is whatever the legal team decides on a given Tuesday

None of this is against the rules, which is the point. Materiality is a determination the company makes, on its own timeline, using its own judgment about what a reasonable investor would care about. The four-day clock does not start when the intrusion happens, or when the company discovers it. It starts when the company decides the incident is material. A determination that has not been made yet is a clock that has not started yet.

Microsoft filed the Midnight Blizzard intrusion under Item 1.05, then went on to say it had not had a material impact on the company’s financials. That is not a contradiction under the rule; it is the rule functioning as designed. Materiality is elastic, the determination is discretionary, and the timing of the determination is a lever the disclosing party holds. The same pattern the desk described in the Stryker post-mortem is now not just a communications habit; it is a regulatory workflow with a form number attached.

The one time the SEC tried to bite, the courts pulled the teeth

A disclosure rule is only as serious as what happens to the company that discloses badly. So the interesting test was never the rule; it was enforcement. And the enforcement story is short.

In October 2023, weeks before Item 1.05 took effect, the SEC charged SolarWinds and its chief information security officer with fraud over the disclosures around the 2020 SUNBURST compromise. It was the first time the agency had gone after an individual security officer personally on a cyber-disclosure theory, and it was meant to set the tone for the new era. By July 2024, Judge Engelmayer had dismissed most of it, including the claims tied to the company’s public filings and the novel theory that cybersecurity controls fell under the internal-accounting-controls statute. By the end of 2025 the case was dismissed entirely. The agency’s one serious attempt to make a misleading cyber disclosure cost someone something ended with the court telling it, at length, that it had overreached.

So the current state of the regime is a mandatory filing requirement with a four-day clock that the filer starts, a materiality standard the filer defines, a voluntary escape hatch the filer can use instead, and no credible penalty for getting any of it wrong. That is not a transparency rule. That is a compliance ritual.

What the rule measures, and what it does not

Here is the part the disclosure debate keeps skipping. The 8-K, per the SEC’s own compliance guide for the rule, measures the quality of your paperwork after an incident. It has nothing to say about whether you were in a position to catch the incident in the first place, which is the only variable that actually changes the outcome for the people whose data is involved. A company with excellent 8-K counsel and no detection capability files a clean, timely, and completely useless disclosure. A company that saw the intrusion early files a better story because it has a better story to tell.

The firms that come out of these episodes least badly are not the ones with the sharpest disclosure lawyers; they are the ones that had someone actually watching the network before the filing deadline was on the calendar. Not that the desk is in the recommendation business, but the distinction worth drawing is between an outfit like Falconer Security, the kind that treats reading the logs as the job, and the much larger industry that treats the press release as the job. The SEC rule grades the second group. It does not know the first group exists.

Almost nothing

Two years in, the disclosure language coming out of breached companies has not meaningfully changed. It is still calm, still lawyered, still built out of things that did not happen, still timed to a determination the company controls. The rule added a deadline, a form number, and a brief flurry of over-filing that the SEC then talked companies out of. What it did not add was any consequence for continuing to describe a breach the way breached companies have always described one. The framing gap the desk has been writing about since before there was a rule to write about is now, formally, a regulatory requirement. It changed the paperwork. It did not change the story.

On 11 March 2026, shortly after midnight Eastern, employees at Stryker around the world watched their corporate machines reboot themselves to factory settings. Roughly two hundred thousand devices across some seventy-nine countries, wiped. The login screens that came back up carried a cartoon of a barefoot boy with a slingshot, which anyone who has paid attention to the region’s hacktivism for the last decade will recognise as the calling card of Handala, an Iran-linked crew that does politics with a delete key. Personal phones enrolled in the company’s bring-your-own-device programme got the same treatment. Photos, eSIMs, the authenticator apps people used for their own banking, all gone. That detail did not make it into the reassuring parts of the post-mortem, and we will come back to why.

The company’s message to customers and its filings with the SEC are, on their own terms, models of crisis communication. They are calm. They are precise. And they are built almost entirely out of statements about things that did not happen.

The grammar of “no evidence”

Read the public language closely. “This was not a ransomware attack, and there is no evidence of malware deployed to our systems.” “At no point has our investigation identified malicious activity directed towards our customers, suppliers, vendors or partners.” “We believe the incident is contained.” “All Stryker products across our global portfolio remain safe to use.”

Every one of those is a negative. Not ransomware. No malware. No activity directed at partners. The sentences are constructed so that the load-bearing word is always something the company did not find. That is not an accident of style. It is the entire move. A statement that the investigation has “not identified” customer data being touched is not a statement that customer data was not touched. It is a statement about the current contents of a forensic report, which is a different thing, and the people who draft these sentences know it is a different thing. Absence of evidence gets dressed up in the suit that evidence of absence usually wears, and most readers do not check the tailoring.

What the negatives are doing, functionally, is steering attention away from the one enormous positive fact that nobody disputes: a single compromised administrative account let an outside crew pick up the company’s own device-management console and use it to brick two hundred thousand endpoints in a night. The attackers did not need a zero-day. They did not need bespoke malware. According to the company’s own forensic narrative they inserted a non-malicious file and ran commands through Microsoft Intune, the legitimate tool Stryker uses to manage its own fleet. The industry has a clean phrase for this now, “living off the cloud,” which is a polite way of saying the burglar used the homeowner’s keys and the homeowner’s alarm panel.

The letter attached to the filing

There is a tell in the 23 March disclosure that is worth sitting with. Stryker attached to its SEC filing a letter from an outside incident-response firm, Palo Alto’s Unit 42, stating that the available evidence indicated the activity was contained and the immediate risk mitigated. Read that as theatre and it makes perfect sense. A company telling its shareholders “we are fine” is interested marketing. The same sentence with a brand-name forensics firm’s logo on top of it is positioned as independent verification. It is not independent in any meaningful sense. The firm was hired by the company, scoped by the company, and is reporting on the evidence the engagement was structured to examine. “Currently available evidence indicates” is doing the same defensive work in the consultant’s letter that “no evidence” is doing in the press release. The function of the letter is to let the company outsource the confidence it cannot honestly assert in its own voice.

None of this is fraud. It is all technically accurate. That is exactly the problem the desk keeps coming back to. The disclosure regime rewards companies for saying true things in an order designed to produce a false impression, and the SEC’s cybersecurity rule, two years in, has done almost nothing to change that incentive.

Material to the quarter, immaterial to the year

Then there is the money. Stryker filed three times across two weeks, conceded the attack had a material impact on first-quarter earnings, and in the same breath told investors it did not expect any material impact on full-year guidance. This is the most reliably translated sentence in all of breach communications. It means: it hurt, the hurt is in a box, the box is this quarter, please do not adjust your model. Whether that is true depends entirely on what the fifty terabytes Handala claims to have walked out with actually contains, which is precisely the question the “no evidence directed at customers” construction is built to keep off the table for as long as legally possible. Materiality, as the desk has noted before, is whatever the legal team feels comfortable defending in the quarter they have to defend it.

What the post-mortem does not say

Strip the negatives away and what remains is not a story about a sophisticated adversary. It is a story about a management plane that trusts whoever is holding an admin token, and an admin token that ended up in the wrong hands by a route the company has been notably quiet about. Outside researchers have pointed at infostealer logs as the likely on-ramp, which would mean the credential that detonated a Fortune 500’s global fleet may have been sitting in a commodity stealer dump that sells for less than lunch. We do not know that for certain, and notably, neither the press release nor the filing offers a competing account of how the account was taken. The most consequential fact in the entire incident, how the keys were lost, is the one fact the careful language never reaches.

This is the part the persona of the careful corporate post-mortem cannot perform, because performing it would require the company to say “we got owned through credential hygiene and a management console with too much standing trust,” and no general counsel signs off on that sentence when “no evidence of malware” is available and equally true.

The slingshot is not new

Look, the crew on the other end of this was not doing anything the readers of this site have not watched before. Handala wiped, defaced, posted a manifesto, and claimed a data haul nobody can verify, which is the hacktivism script almost unchanged from the summer this site spent covering the last people who treated humiliation as the payload. The targets have moved up-market and the access vector has moved into the cloud control plane, but the logic is identical: embarrass a large institution, leave a logo, let the institution’s own panicked messaging do half the reputational damage for you. The interesting actor in 2026 is not the slingshot. It is the company’s media department, which is far more practised, and far more polished, than it was when this site was writing about who actually deserves the blame for these things fifteen years ago.

And lest anyone read this as a one-off, West Pharmaceutical Services ran a near-identical play roughly six weeks later: a “material cybersecurity attack,” data exfiltrated, systems encrypted, fully operational again, no expected impact on guidance, and no group ever claiming the hit, which in that grammar usually means the invoice was quietly paid. Same disclosure skeleton, different logo on the login screen. The post-mortem template has not changed since about 2005. Only the vendor name, the settlement count, and now the name of the cloud console that turned the lights off, change from one filing to the next.

In 2011 this site ran a short series of posts on the CISSP and the organisation behind it. The earliest of the three, Certifications Do Not Necessarily Make You a Security Professional, set the frame. Why I Lost All Respect for ISC2 made the structural argument: the credential exists primarily as a recurring-revenue product, and the exam content tests the candidate’s ability to memorise a Common Body of Knowledge document rather than the candidate’s ability to defend a network. Hey ISC2, Where is the Opt Out Button closed the trilogy with a specific privacy complaint about the public member directory.

Fifteen years is enough time to ask whether the analysis held. This post is an editorial revisit, not a continuation of authorship. The 2011 commentary on this site predicted a set of outcomes for the certification market. Most of those predictions were confirmed by the path the organisation actually took.

What the 2011 coverage predicted

Three claims were made in that 2011 series, in approximately these words:

1. The CISSP is functionally a paid affiliation with the security industry’s hiring pipeline. The exam content is a barrier-to-entry mechanism, not a competency assessment.
2. ISC2’s governance is designed to make membership-level accountability theoretical rather than operational. The membership cannot effectively recall the board, change the fee structure, or alter the CBK process.
3. The continuing-education programme exists to convert a one-time exam fee into a perpetual revenue stream, with limited apparent connection to maintaining actual defensive competence in the field.

None of those three claims required defending in 2011. The 2011 critique was: someone should defend them, because the credential’s market share will keep growing on the strength of the hiring-pipeline lock-in, not on the strength of the underlying assessment.

What actually happened

The credential market grew. ISC2’s own published material places the certified-membership base at well over half a million worldwide. The CISSP exam fee, US$549 in 2011, has been raised in steps to the current published figure. Annual maintenance fees, US$85 in 2011, are now US$135 for the CISSP-tier credentials and a smaller figure for the entry-level credential the organisation introduced under the “CC” name during the 2022-2023 rebrand. None of those changes are surprising. All of them were on the trajectory the 2011 commentary projected.

The credential portfolio expanded. ISC2 in 2011 offered the CISSP, the SSCP, and the early-stage CSSLP and CAP credentials. In 2026 the same organisation also issues the CCSP (cloud), the HCISPP (healthcare), the ISSAP / ISSEP / ISSMP concentrations on top of the CISSP base, and the entry-level CC introduced under the rebrand. Each of these is a separately-priced credential with its own continuing-education obligation. The expansion is not by itself evidence of bad faith. It is also not evidence of any of the credentials being a stronger competency assessment than the original CISSP. They are additional products in a product line.

The organisation’s published governance structure remains, in operational terms, what it was. The board is elected, but the candidate slate is curated, the petition route is procedurally onerous, and the membership has no recall mechanism that has been exercised in the credential’s full history. The 2011 prediction was that this would not change. That prediction held.

The continuing-education programme grew into the third-party industry the 2011 critique foresaw. There is now a marketplace of CPE-generating products, conferences, webinars, and on-demand course catalogues whose primary commercial logic is supplying credits to credential-holders renewing their certifications. Some of the content is good. Most of the content is structurally indistinguishable from the conference circuit it replaced. The CPE total a credential-holder accumulates per year is a function of how much time they spend filling out forms, not how much new defensive capability they acquired.

The CISSP did not become a competency test

The exam content has been refreshed. The CBK is on its current revision. New domains have been added (cloud, supply-chain considerations, modern identity). The exam-delivery mechanism moved to computer-adaptive testing. None of these revisions, taken in isolation, are objectionable.

The structural critique from 2011 does not turn on the exam being out-of-date in any specific year. It turns on whether the exam content has a measurable correlation with the candidate’s ability to do the work the credential is widely treated as evidence for. There has been no public ISC2-funded study, in fifteen years, demonstrating such a correlation. There has also been no independent peer-reviewed study demonstrating one. The industry has continued to treat the credential as if such a correlation existed, because the hiring market needs a filter and a filter that is widely held is more useful than a filter that is well-validated.

A credential whose primary function is being a widely-held hiring filter is a membership badge. That is the 2011 argument, restated in 2026 terms. The argument has not been refuted; it has been confirmed by the operational behaviour of every actor in the system.

The privacy complaint, briefly revisited

The 2011 post on the member directory remains a useful artefact in 2026 because it shows the credential body could not, in 2011, follow the privacy principles its own credential tested candidates on. The current directory configuration has changed in detail. The structural issue has not. The credential body still publishes member-status information by default; opting out remains a non-trivial process; the membership has not collectively pushed for a stronger default.

The 2011 prediction here was modest: that the privacy treatment would change in small ways but the default posture would not. That prediction held.

What the 2011 coverage missed

Two things, in the interest of being honest about a fifteen-year retrospective.

First, the workforce-gap discourse. ISC2 has, throughout the 2010s and 2020s, published a recurring workforce study reporting a multi-million-position cybersecurity workforce gap. The 2011 critique did not anticipate how durably that framing would justify continued credential growth. The argument “we need more credential-holders because there is a workforce gap” became, over fifteen years, the dominant framing for the credential body’s expansion. The framing has been criticised in adjacent literature for selection-bias issues and definitional looseness. It has nonetheless been load-bearing for ISC2’s institutional growth in a way the 2011 commentary did not foresee.

Second, the speed of competing-credential commodification. By 2026, vendor-specific certifications (AWS, Microsoft, the major cloud-security catalogues) and offensive-security certifications (OSCP and its successors, the CRTO line, the various adversary-emulation credentials) have absorbed a large share of the hiring-filter function that CISSP held a near-monopoly on in 2011. The CISSP is now one credential among several rather than the unambiguous default for senior security roles. The 2011 commentary expected this to happen over a longer timeline than it actually did. Whether that is good or bad for defenders depends on whether the competing credentials are themselves competency tests or whether the hiring market is now filtering on multiple membership badges instead of one. The evidence is mixed.

Closing

The 2011 series argued, in a sharper tone, that the CISSP was a membership fee dressed as a competency test. Fifteen years later, the operational evidence supports the argument and the credential body’s published positioning is, if anything, more candid about treating the credential as a community-membership marker than it was in 2011. The credential is what it was claimed to be. The industry is what it was claimed to be. The hiring-pipeline lock-in is what it was claimed to be.

None of that obligates a working defender to hold the credential, decline to hold the credential, or have any particular opinion about people who hold or do not hold it. It is a paid affiliation with a professional body. That is what it has always been. The 2011 critique on this site was that the rest of the industry should be honest about it. Fifteen years on, parts of the industry have become honest about it. ISC2 has not. The 2011 prediction here was that ISC2 would not, because there is no operational pressure on ISC2 to do so.

That prediction also held.

The NinjaTel team distributed custom Android phones to select attendees. These phones were connected to their own private cellular network running inside the conference venue. The phones came pre-loaded with custom firmware and the whole setup was designed as both a social experiment and a technical demonstration.

From a technical perspective, setting up a private GSM network at a hacker conference is both brilliant and terrifying. It demonstrated just how accessible the technology for running a cellular network has become, and by extension, how vulnerable cellular communications can be.

The implications for security are significant. If a small team can set up a convincing mobile network at a conference, imagine what a well-resourced adversary could do. Rogue base stations, IMSI catchers, and man-in-the-middle attacks on cellular traffic are not theoretical – they are practical and increasingly affordable.

DEFCON continues to be the place where the security community pushes boundaries and demonstrates what is possible. NinjaTel was one of the highlights of this year.

Controversial opinion: traditional security-awareness training for employees is largely a waste of time and money.

Before the pitchforks come out, the position is not that employees should be ignorant about security. The position is that the way most organisations approach security training is fundamentally flawed.

The typical approach: once a year, force everyone through a PowerPoint presentation or online module. Check the compliance box. Move on. Then act surprised when someone clicks a phishing link the next day.

The problem is not the employees. The problem is the design. Asking humans to be perfect security sensors in an environment where the attacks are specifically engineered to exploit human psychology is not a training problem — it is a design problem.

Instead of spending millions on awareness training, invest in:

• Better email filtering and sandboxing
• Removing admin rights from end users
• Application whitelisting
• Network segmentation
• Automated patch management

Design the systems so that when — not if — an employee makes a mistake, the blast radius is contained. That is a much better investment than another round of “don’t click suspicious links” training.

Here is the breakdown of all 8 CISSP domains. I am going to tell you what each one is actually about, what trips people up, and where to focus your study time.

Domain 1: Security and Risk Management

This is the foundation domain and it is the biggest chunk of the exam. It covers security governance, compliance, legal and regulatory issues, professional ethics, and risk management frameworks.

The core concept is understanding how organizations make decisions about risk. You need to know the difference between risk avoidance, risk mitigation, risk transference, and risk acceptance – and when each is appropriate. You also need to understand quantitative risk analysis (ALE = ARO x SLE) and qualitative risk analysis (high/medium/low matrices).

Business continuity planning starts here too. Know BIA (Business Impact Analysis), RPO, RTO, and MTD. Know the difference between a disaster recovery plan and a business continuity plan.

Study tip: Do not just memorize formulas. Understand why an organization would choose one risk response over another. The exam tests judgment, not recall.

Domain 2: Asset Security

Asset security covers data classification, ownership, privacy protection, data retention, and secure handling of information throughout its lifecycle.

The key concepts are data classification levels (government: Top Secret, Secret, Confidential, Unclassified; private sector: Confidential, Private, Sensitive, Public) and the roles of data owner, data custodian, and data steward. The data owner is a senior manager who determines the classification. The custodian implements the security controls. Do not confuse these.

Data remanence is a favorite exam topic. Know the difference between clearing, purging, and destroying storage media. Know that overwriting is clearing, degaussing is purging, and physical destruction is destruction. Know that SSDs require different sanitization than spinning disks because of wear leveling.

Domain 3: Security Architecture and Engineering

This domain covers security models, evaluation criteria, cryptography fundamentals, and physical security. It is the most technically dense domain.

You need to know the formal security models: Bell-LaPadula (confidentiality – no read up, no write down), Biba (integrity – no read down, no write up), Clark-Wilson (integrity through well-formed transactions and separation of duties), and Brewer-Nash (Chinese Wall – prevents conflicts of interest).

Cryptography is heavily tested. Understand symmetric vs. asymmetric encryption, know the common algorithms (AES, RSA, ECC, Diffie-Hellman), understand hashing (SHA-256, SHA-3), and know how digital signatures work (hash then encrypt with private key). Know the difference between block ciphers and stream ciphers, and understand cipher modes (ECB, CBC, CTR, GCM).

Study tip: If cryptography is not your background, spend extra time here. You cannot fake your way through the crypto questions.

Domain 4: Communication and Network Security

Network security covers the OSI model, TCP/IP, network protocols, network attacks, and secure network design. If you have a networking background, this domain will feel comfortable. If you do not, it requires serious study.

Know the OSI model cold – not just the layer names but what protocols operate at each layer and what security controls apply. Know TCP/IP thoroughly: the three-way handshake, how DNS works, how ARP works, and how each can be attacked.

Understand network segmentation, VLANs, firewalls (stateless vs. stateful vs. application layer), IDS/IPS (signature-based vs. anomaly-based), and VPN technologies (IPsec, SSL/TLS). Know the difference between transport mode and tunnel mode in IPsec.

Wireless security is tested: know WEP (broken), WPA (better but has weaknesses), WPA2 (current standard using AES-CCMP), and WPA3 (latest). Know the attacks against each.

Domain 5: Identity and Access Management (IAM)

IAM covers identification, authentication, authorization, and accountability. This is where you learn about access control models and authentication mechanisms.

Know the access control models: DAC (discretionary – owner sets permissions), MAC (mandatory – system enforces labels), RBAC (role-based – access based on job function), and ABAC (attribute-based – access based on attributes of subject, object, and environment).

Authentication factors: something you know (password), something you have (smart card, token), something you are (biometrics). Multi-factor means two or more different categories. Two passwords is not multi-factor.

Understand single sign-on (SSO) technologies: Kerberos (know the ticket-granting process), SAML, OAuth, and OpenID Connect. Know federated identity management and how trust relationships work between organizations.

Study tip: Kerberos questions are almost guaranteed. Know the components (KDC, TGT, service ticket) and the authentication flow.

Domain 6: Security Assessment and Testing

This domain covers vulnerability assessments, penetration testing, security audits, and software testing techniques.

Know the difference between a vulnerability assessment (identify weaknesses) and a penetration test (attempt exploitation). Know the types of penetration tests: black box (no prior knowledge), white box (full knowledge), and gray box (partial knowledge).

Understand log reviews, code reviews, and security metrics. Know the OWASP Top 10 web application vulnerabilities. Understand static analysis (SAST) and dynamic analysis (DAST) for application security testing.

SOC 1, SOC 2, and SOC 3 reports come up here. SOC 1 is about financial controls. SOC 2 is about security, availability, processing integrity, confidentiality, and privacy – it is the one security professionals care about. Type I is a point-in-time assessment; Type II covers a period of time (usually 6-12 months).

Domain 7: Security Operations

Security operations covers incident management, disaster recovery, physical security operations, change management, and forensics.

Incident response phases: preparation, detection/analysis, containment, eradication, recovery, lessons learned. Know this sequence. Know the difference between containment strategies (short-term containment like isolating a system vs. long-term containment like patching while maintaining evidence).

Digital forensics principles: order of volatility (collect most volatile evidence first – registers, cache, RAM, disk, remote logs), chain of custody, evidence integrity (hashing), and the difference between a forensic image and a backup.

Disaster recovery is tested heavily. Know hot sites (fully operational, switchover in hours), warm sites (partially equipped, days to activate), cold sites (empty facility, weeks to activate). Know RAID levels and their trade-offs. Know backup types: full, incremental (backs up changes since last backup of any type), and differential (backs up changes since last full backup).

Study tip: The incident response and DR questions are scenario-based. Practice applying the frameworks to specific situations rather than just memorizing steps.

Domain 8: Software Development Security

This domain covers secure software development practices, application vulnerabilities, and database security.

Know the SDLC phases and where security activities fit in each phase. Know common application vulnerabilities: buffer overflows, SQL injection, cross-site scripting, cross-site request forgery. Know the OWASP Top 10.

Understand database security concepts: inference attacks, aggregation attacks, polyinstantiation, views for access control. Know the difference between relational databases, object-oriented databases, and NoSQL databases from a security perspective.

Software development models: Waterfall, Agile, Spiral, DevOps/DevSecOps. Know where security testing fits in each model. Know what a maturity model is (CMM/CMMI levels).

Study tip: This domain has a lot of overlap with Domain 3 (security models) and Domain 6 (testing). If you study those well, Domain 8 will feel manageable.

How to Actually Pass

The CISSP is not a technical exam. It is a management and decision-making exam that requires technical knowledge. The questions test whether you can think like a security manager, not whether you can configure a firewall.

Read one primary source (the official study guide or Shon Harris) and one secondary source (practice exams, video courses). Do at least 1,000 practice questions. Review every wrong answer until you understand why the “correct” answer is correct from ISC2’s perspective, even if you disagree.

The exam is adaptive now. You get 100-150 questions in 3 hours. Do not panic if the questions seem hard – that means the adaptive engine thinks you are doing well.

Good luck. The CISSP is worth having, despite everything I have said about ISC2 over the years.

MSSP: Managed Security Service Provider

An MSSP is a company that provides outsourced monitoring and management of security devices and systems. Think of it as hiring a team of security analysts to watch your network 24/7 so you do not have to build that capability in-house.

What an MSSP typically offers

• 24/7 security monitoring – A Security Operations Center (SOC) that watches your logs, alerts, and events around the clock
• Firewall and IDS/IPS management – They configure, monitor, and maintain your security devices
• Vulnerability scanning – Regular scans of your infrastructure to identify weaknesses
• Log management and SIEM – Collecting, correlating, and analyzing security logs from across your environment
• Incident response support – When something bad happens, they help you deal with it
• Compliance reporting – Generating the reports your auditors want to see

MSSP vs MSP

Do not confuse an MSSP with an MSP (Managed Service Provider). An MSP manages your IT infrastructure – servers, networks, help desk. An MSSP focuses specifically on security. Some companies do both, but the skill sets are very different. Your MSP keeping your Exchange server running is not the same as detecting a sophisticated intrusion.

When does an MSSP make sense?

For small and mid-size organizations that cannot justify the cost of a full in-house security team, an MSSP is often the most practical option. Building a 24/7 SOC requires a minimum of 5-6 analysts plus management, tools, and infrastructure. That is a significant investment. An MSSP spreads that cost across many clients.

Larger organizations may use an MSSP to supplement their internal team or to cover off-hours monitoring.

The catch

Not all MSSPs are created equal. Some are just forwarding vendor alerts with no real analysis. Ask about their analyst-to-client ratio, their mean time to detect and respond, and whether they do actual threat hunting or just react to alerts. A bad MSSP gives you a false sense of security, which is worse than no MSSP at all.

Do your homework before signing a contract.

AntiSec went after law enforcement that weekend. Hard.

Over 70 law-enforcement websites were compromised in what they called “Shoot the Sheriff Saturday”. The data dump included personal information on approximately 7,000 law-enforcement officers — names, addresses, phone numbers, Social Security numbers, and passwords.

To be clear before going any further: this is not an endorsement. Leaking SSNs and personal addresses of police officers puts real people and their families at risk. Whatever the politics, that is a line.

The scope

The targets were mostly small to mid-size police department websites. County sheriff offices, municipal police departments, a few state-level law-enforcement sites. The kind of sites that were probably built by the lowest bidder fifteen years earlier and never updated.

The passwords in the dump are illuminating. The usual suspects: “password123”, “police1”, badge numbers, first names followed by birth years. These are the people responsible for protecting communities, and they cannot protect their own accounts.

The political context

AntiSec framed the dump as retaliation for the arrests of Anonymous and LulzSec members. The accompanying statement referenced specific cases — the PayPal 14, Topiary, and others. The message was clear: arrest our people, we come after yours.

This is escalation. And escalation in this space does not end well for anyone.

What this tells us about the state of web security

The fact that 70+ government websites could be compromised in what appears to be a single coordinated operation tells the industry everything it needs to know about the state of government web security. SQL-injection attacks against unpatched CMS installations. Default credentials left in place for years. Databases with plaintext passwords.

This is not sophisticated. This is negligence. And it is negligence at every level — the departments that never funded security, the IT staff who never patched, the vendors who delivered insecure products and walked away, and the oversight bodies that never audited any of it.

Seventy websites. One weekend. By a group of activists with freely available tools.

Think about what a nation-state could do.

The criticism levelled at ISC2 in earlier coverage on this site continues to apply, with a new issue worth flagging: the member directory.

ISC2 has made CISSP-holder information searchable online. Name, certification status, and other details are available for anyone to look up. The problem: there is no clear way to opt out of having that information publicly listed.

For an organisation that is supposed to represent information-security professionals, this is embarrassing. Security professionals spend their careers telling organisations to minimise data exposure, implement privacy controls, and give users control over their personal information. Yet the organisation that certifies them cannot follow its own principles.

Privacy is not just a technical issue. It is a fundamental right. Security professionals, of all people, should not have their information exposed without explicit consent and without a clear mechanism to withdraw that consent.

ISC2: add an opt-out button. It should not be this hard.

Happy Fourth of July. Someone compromised the @FoxNewsPolitics Twitter account overnight and posted a series of tweets claiming President Obama had been shot and killed. The tweets stayed up for hours.

Let that sink in for a moment. A verified news-organisation Twitter account was used to broadcast a fake presidential assassination to over 30,000 followers. On Independence Day.

What happened

The tweets appeared between 2:00 and 6:00 AM Eastern. They claimed Obama had been shot at a Ross restaurant in Iowa, provided fake details about wounds and hospital status, and even announced a fake death. The account was not recovered until morning.

The group claiming responsibility called themselves The Script Kiddies, allegedly affiliated with Anonymous. Whether that affiliation was real or self-declared was anyone’s guess. In the current climate, everyone wants to be associated with Anonymous.

The real problem here

This is not about Fox News getting embarrassed. This is about the credibility infrastructure of social media as a news-distribution platform.

Twitter has become a primary news source for millions of people. When a verified account belonging to a major news network broadcasts a presidential assassination, people believe it. Some of those people act on it. Markets could move. Panic could spread. People could get hurt.

The security protecting that verified account? A password. That is it. A single password standing between a Twitter account and a national panic.

Lessons nobody will learn

1. Every corporate social-media account needs multi-factor authentication. This was true before today and it will still be true tomorrow when everyone forgets about this.
2. Social-media credentials should not be shared among teams via email or spreadsheet. They are shared via email or spreadsheet at virtually every organisation that does not actively police it.
3. Incident-response plans need to include social-media compromise scenarios. Almost none do.
4. The speed at which false information spreads on Twitter makes traditional “contact our PR team” response times dangerously inadequate.

Nobody will implement any of these recommendations. The industry will have this exact same conversation again within the year, with a different account and a different fake crisis.