r3b1s

California's 2025 Tech Legislation: AI Transparency, Chatbots, and Privacy

Sun, 09 Nov 2025 00:00:00 GMT

California has enacted a suite of new legislation with a diverse set of impacts. Among other things, these bills are intended to:

Increase transparency in the process of building frontier AI models (defined later).
Ensure the well-being of individuals interacting with AI chatbot services.
Combat social media addiction.
Protect children and minors.
Prevent stalking via connected devices.

Most businesses operating in the State of California -- remotely or otherwise -- will likely need to implement compliance measures by the relevant deadlines to maintain their bottom line. Because California is the 4th largest economy in the world, this affects many businesses.

Much of the AI-specific legislation is aimed at large organizations with copious resources, so SMBs need not worry about those portions -- but the breach notification and chatbot rules apply to businesses of all sizes.

There's A LOT to cover here, so I'll be focusing on global impacts.

AI Legislation

It is important to note that California has been the USA's leader in sounding the horn on data, privacy, and AI legislation.

As of November 2025, AI's Black Box Problem remains unsolved: even the developers of large AI models cannot fully explain why a model produced a given output, because its behavior emerges from billions of learned parameters rather than legible, human-written rules. This makes model behavior difficult to audit, predict, or guarantee -- which is precisely why transparency legislation focuses on disclosure of processes rather than inspection of the models themselves.

SB 53: Transparency in Frontier Artificial Intelligence Act

Full Bill Text [3]: https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB53

Culminating a multi-year policy-making process, the ratification of the Transparency in Frontier Artificial Intelligence Act (TFAIA) [3] is perhaps the most noteworthy of the entire package. It's the first piece of comprehensive AI legislation regulating the development of frontier foundation models -- that is, cutting edge AI models -- in the U.S.

Last year, after vetoing a similar bill (California Senate Bill 1047 of 2024), Gov. Gavin Newsom tasked the Joint California Policy Working Group on AI Frontier Models to deliver a report "focused on artificial intelligence (AI) frontier models." [1][2] This report ultimately guided the creation of the finalized bill.

Fostering public trust in AI developers and service providers is the predominant goal:

It's meant to foster an environment of transparency surrounding the innovation and development of cutting edge, highly-capable foundation models.
Large frontier developers must write, publish, and actually follow a frontier AI framework describing how they incorporate national/international safety standards, assess catastrophic risk, and govern secure deployment. The framework must be reviewed and updated at least annually.
A transparency report must be published whenever a new frontier model (or a substantially modified version of one) is released -- covering its capabilities, intended uses, and restrictions.
Critical safety incidents must be reported to California's Office of Emergency Services within 15 days of discovery -- or within 24 hours if the incident poses an imminent risk of death or serious physical injury.
Whistleblower protections shield employees who report catastrophic-risk concerns, and large frontier developers must maintain an anonymous internal reporting channel.
Enforcement falls to the Attorney General, with civil penalties of up to $1 million per violation. Notably, there is no private right of action -- contrast this with SB 243 below.
The bill also establishes CalCompute, a consortium tasked with designing a public compute cluster to support safe, equitable AI research.

For context, the bill's section 1(f) [3] defines a foundation model as:

(f) "Foundation model" means an artificial intelligence model that is all of the following:

(1) Trained on a broad data set.

(2) Designed for generality of output.

(3) Adaptable to a wide range of distinctive tasks.

A short, high-level summary of the law can be gleaned from section 1(k) [3]:

"With the frontier of artificial intelligence rapidly evolving, there is a need for legislation to track the frontier of artificial intelligence research and alert policymakers and the public to serious risks and harms from the very most advanced artificial intelligence systems, while avoiding burdening smaller companies behind the frontier."

Large companies at the frontier of AI research are the primary focus, but a provision for smaller businesses is made with section 1(n) [3]:

"In the future, foundation models developed by smaller companies or that are behind the frontier may pose significant catastrophic risk, and additional legislation may be needed at that time."

The law applies only to organizations meeting these thresholds:

Compute Threshold: Definition of a "frontier model" -- section 2(i)

(i) (1) "Frontier model" means a foundation model that was trained using a quantity of computing power greater than 10^26 integer or floating-point operations.

(2) The quantity of computing power described in paragraph (1) shall include computing for the original training run and for any subsequent fine-tuning, reinforcement learning, or other material modifications the developer applies to a preceding foundation model.

Note: 10^26 operations = 100,000,000,000,000,000,000,000,000 operations

Revenue Threshold: Definition of a "large frontier developer" -- section 2(j)

(j) "Large frontier developer" means a frontier developer that together with its affiliates collectively had annual gross revenues in excess of five hundred million dollars ($500,000,000) in the preceding calendar year.

SB 243: Companion Chatbots

Full Bill Text [10]: https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB243

Senate Bill 243 focuses on the mental well-being of users of AI chatbots. It broadly shares many goals with TFAIA [3], attempting to set healthy precedents that increase the public's trust in AI services compliant with the policy.

It mandates the implementation of "…a protocol for preventing the production of suicidal ideation, suicide, or self-harm content to the user…" [10] into most AI chatbot services. Details of such protocols must be made available on service operators' websites. Additionally, it emphasizes the use of awareness notifications to prevent users from being misled into thinking an AI chatbot is a human.

Further provisions are made for "a user that the operator knows is a minor:"

It must be disclosed to the user that they are interacting with artificial intelligence.
Users must be clearly notified and reminded at least every three hours to take a break and "that the companion chatbot is artificially generated and not human."
"Reasonable measures" must be instituted to prevent the generation of sexually explicit material.

Annual Reports: Beginning July 1, 2027, operators [of AI chatbot services] must annually deliver a report on these efforts to California's Office of Suicide Prevention. Data from such reports must be de-identified. Data from the report must be made available on the operator's website.

Section 22603(a) -- The annual report shall consist solely of these data points [10]:

(1) The number of times the operator has issued a crisis service provider referral notification pursuant to Section 22602 in the preceding calendar year.

(2) Protocols put in place to detect, remove, and respond to instances of suicidal ideation by users.

(3) Protocols put in place to prohibit a companion chatbot response about suicidal ideation or actions with the user.

Importantly, it's crucial to understand what a "companion chatbot" IS -- and what it IS NOT.

Section 22601(b)(1) -- Definition of a "Companion chatbot" [10]:

(b) (1) "Companion chatbot" means an artificial intelligence system with a natural language interface that provides adaptive, human-like responses to user inputs and is capable of meeting a user's social needs, including by exhibiting anthropomorphic features and being able to sustain a relationship across multiple interactions…

Section 22601(b)(2) -- What isn't a "Companion chatbot" [10]:

(2) "Companion chatbot" does not include any of the following:

(A) A bot that is used only for customer service, a business' operational purposes, productivity and analysis related to source information, internal research, or technical assistance.

(B) A bot that is a feature of a video game and is limited to replies related to the video game that cannot discuss topics related to mental health, self-harm, sexually explicit conduct, or maintain a dialogue on other topics unrelated to the video game.

(C) A stand-alone consumer electronic device that functions as a speaker and voice command interface, acts as a voice-activated virtual assistant, and does not sustain a relationship across multiple interactions or generate outputs that are likely to elicit emotional responses in the user.

Notably, provisions are made for those suffering injury due to non-compliance (Section 22605):

A person who suffers injury in fact as a result of a violation of this chapter may bring a civil action to recover all of the following relief:

(a) Injunctive relief.

(b) Damages in an amount equal to the greater of actual damages or one thousand dollars ($1,000) per violation.

(c) Reasonable attorney's fees and costs.

Non-AI Legislation

SB 446: 30-day Data Breach Customer Notification Limit

Full Bill Text [9]: https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB446

This bill amends Section 1798.82 of the California Civil Code -- the state's existing breach notification statute. Section 1798 is most notably affiliated with the enactment of the California Consumer Privacy Act (CCPA) in 2018.

Currently, businesses operating in California are legally obligated to disclose a compromise of California residents' unencrypted personal information in "the most expedient time possible and without unreasonable delay…" [9].

Senate Bill 446 replaces the abstract time window, mandating (under normal circumstances) a maximum limit of 30 days between the first discovery OR notification of the compromise. In other words: organizations operating in California MUST notify affected parties within 30 days of the point at which the organization becomes aware a breach occurred.

Delaying a breach's disclosure is allowed in these cases:

"…to accommodate the legitimate needs of law enforcement…"
"…or as necessary to determine the scope of the breach and restore the reasonable integrity of the data system."

Section 1(d) [9] clearly lists the requirements of a sufficient breach notification:

…(1) The security breach notification shall be written in plain language, shall be titled "Notice of Data Breach," and shall present the information described in paragraph (2) under the following headings: "What Happened?" "What Information Was Involved?" "What We Are Doing," "What You Can Do," and "For More Information." Additional information may be provided as a supplement to the notice…

In addition to the quote above, section 1(d) contains many more granular requirements for breach disclosures. It also provides a pre-built template which can be used to fill out a written disclosure.

If a single breach results in a notice that must be issued to more than 500 California residents, a copy of this notice must be submitted to the Attorney General within 15 days of notifying affected consumers:

(f) An individual or business that is required to issue a security breach notification pursuant to this section to more than 500 California residents as a result of a single breach of the security system shall electronically submit a single sample copy of that security breach notification, excluding any personally identifiable information, to the Attorney General within 15 calendar days of notifying affected consumers of the security breach. A single sample copy of a security breach notification shall not be deemed to be within Article 1 (commencing with Section 7923.600) of Chapter 1 of Part 5 of Division 10 of Title 1 of the Government Code.

In practice, this may just result in organizations feigning ignorance until they're ready to disclose publicly -- or asserting that certain compromised data was already publicly available. That defense gets stronger the more personal information users leave exposed, which is one more argument for keeping your data away from the public gaze: scrubbing old posts across platforms, and being careful about where and with whom you share information.

AB 1043: Digital Age Assurance Act

Full Bill Text [4]: https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260AB1043

This bill adds a title to section 1798 of the California Civil Code (home of the CCPA), relating to consumer protection.

Beginning January 1, 2027, the law requires "operating system providers" to include a built-in user interface and application programming interface (API) to facilitate age verification within the operating system and other applications downloaded to the device. Covered application stores are also obligated to receive and act on these age-range signals.

California Civil Code Section 1798.500(g) [4] defines "operating system provider" as:

…a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.

This broad definition raises complex compliance questions across the operating system ecosystem due to the diverse range of OS licensing -- most obviously within open source projects such as Linux.

Penalties are harsh with maximum penalties of $2,500 per child for each negligent violation and $7,500 per child for every intentional violation.

However, the bill does make provisions for providers making "good faith" compliance efforts:

California Civil Code Section 1798.503(b) [4]:

"An operating system provider or a covered application store that makes a good faith effort to comply with this title, taking into consideration available technology and any reasonable technical limitations or outages, shall not be liable for an erroneous signal indicating a user's age range or any conduct by a developer that receives a signal indicating a user's age range."

AB 566: California Opt Me Out Act

Full Bill Text [5]: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB566

This bill adds section 1798.136 to the California Civil Code (home of the CCPA), relating to privacy.

The purpose of the bill is to make the process of opting-out of data collection, sharing, & selling more accessible.

Beginning January 1, 2027, businesses developing/maintaining a web browser MUST include user-configurable functionality to automatically send an "opt-out preference signal" to businesses interacted with via the browser [5].

It's worth mentioning that aside from Google Chrome -- the world's most popular browser -- the majority of modern web browsers already support this using Global Privacy Control (GPC) signals [6][7]. In this case, it appears the State of California is forcing Google's hand.

GPC is similar to the now-deprecated Do Not Track (DNT) browser feature, which usually went ignored by third parties receiving the signal. GPC now supersedes DNT.

Regulatory pushes behind California's CCPA and the EU's GDPR are largely responsible for the development of GPC. Pursuant to the CCPA, GPC communicates a "Do Not Sell or Share" request from a user's browser to third parties. It is likely that GPC will be utilized to implement this "opt-out preference signal" in Chrome and other browsers.

To privacy advocates, this is a positive stride. Though, without jurisdiction-dependent regulatory & transparency measures, whether parties receiving these signals will actually act in accordance with user opt-out preferences is ultimately unknown. In California, such measures are mandated under the CCPA.

Other Notable Legislation

The following is a brief run-down of all other legislation relevant to information security passed as of October 13th (closing day).

Inclusion of items within this list -- as opposed to full stories above -- is NOT meant to discount their impact. This legislation has been broad and all-encompassing, therefore I chose what I felt to be the most impactful.

Amendment to the California AI Transparency Act (Assembly Bill 853)
- Delays the effective operation of the California AI Transparency Act until August 2, 2026 (from January 1, 2026).
- Adds whistleblower protections.
- CONTEXT: What is the California AI Transparency Act?
  - https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320240SB942

AI and Law

Targeted restriction of a specific type of legal defense argued in court cases involving AI (Assembly Bill 316) https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB316
- Defendants having "developed, modified, or used" AI cannot assert "a defense that the artificial intelligence autonomously caused the harm to the plaintiff."
- In simple terms: If the output of an AI agent causes harm to an individual (within the state of California), the service provider -- NOT the AI agent itself -- will be held directly responsible.

Non-AI (These directly mandate the inclusion of additional FEATURES in existing software/tech stacks)

Social Media Warning Law (Assembly Bill 56) https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB56
- This is implemented under the Health & Safety Code of California
- Platforms, as defined in this bill, will have to implement notifications/warnings occurring at regular intervals. The intention is to combat social media addiction.
Connected Device Protection Requests (Senate Bill 50) https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB50
- 48 hour period.
- Stalker-prevention.
- It will likely have cross-jurisdictional implementation.
- This is a bit similar to the California Opt Out Act with the browser feature mandates.
Accessible Account Cancellation (Assembly Bill 656) https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260AB656
Data Broker Regulations and Required Registration in the State of California (Senate Bill 361) https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB361
- This is compelling if California releases publicly proprietary normally-private info on these data brokers.
Deepfake Pornography (Assembly Bill 621) https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260AB621
- Expands liability for distributing nonconsensual sexually explicit deepfakes. There may be utility in leveraging this alongside AB 316's restriction on the "the AI did it autonomously" defense.

Analyst's Comments

Taken together, this package raises real compliance burdens for large AI developers and sets new guardrails on chatbots, breach response, youth safety, and consumer privacy. Because of California's economic weight, expect spillover well beyond state lines: multi-state operators will likely just adopt the California baseline rather than fragment their products.

Key judgments

SB 53 concentrates its obligations on a small handful of large providers -- but don't expect the 10^26 compute and $500M revenue thresholds to sit still. As training practices shift (iterative fine-tuning, RL on top of prior models), the covered population could grow, and the bill's own text openly anticipates expanding to smaller developers later.
SB 243's private right of action ($1,000 per violation plus attorney's fees) is the sharpest enforcement tool in the package. Product teams should also watch the "companion chatbot" definition edges -- a productivity bot that picks up enough personality and memory could creep into covered territory without anyone deciding it should.
SB 446's hard 30-day clock will force incident-response playbooks to be rewritten. The law-enforcement and scope-determination exceptions remain, but organizations leaning on them should expect to document that reliance carefully.
AB 1043's OS-level mandate collides with how operating systems are actually governed -- especially open-source distributions -- and will likely need interpretive guidance before 2027. And while AB 566 mandates browser-side opt-out signals, whether downstream data receivers honor them still depends on enforcement.

Indicators to watch

Agency rulemaking clarifying SB 53's documentation expectations, and how "material modifications" fold into the compute threshold.
The first public operator reports under SB 243, and any enforcement actions or private suits tied to inadequate protocols.
Attorney General guidance or actions referencing SB 446's 30-day clock.
OS and browser vendor roadmaps for age signaling and opt-out preference support ahead of the 2027 deadlines.
Legislative follow-ons expanding coverage to smaller AI developers.

Sources

[1] "Joint California Policy Working Group on AI Frontier Models" https://www.cafrontieraigov.org/

[2] "The California Report on Frontier AI Policy" https://www.gov.ca.gov/wp-content/uploads/2025/06/June-17-2025-–-The-California-Report-on-Frontier-AI-Policy.pdf

[3] California Legislative Information -- Senate Bill No. 53 "Transparency in Frontier Artificial Intelligence Act" https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260SB53

[4] California Legislative Information -- Assembly Bill No. 1043 "Digital Age Assurance Act" https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB1043

[5] California Legislative Information -- Assembly Bill No. 566 "California Opt Me Out Act" https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB566

[6] "What is GPC?" https://oag.ca.gov/privacy/ccpa/gpc

[7] GlobalPrivacyControl https://globalprivacycontrol.org/

[8] California Legislative Information -- Assembly Bill No. 56 "Social Media Warning Law" https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB56

[9] California Legislative Information -- Senate Bill No. 446 "Data breaches: customer notification" https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB446

[10] California Legislative Information -- Senate Bill No. 243 "Companion chatbots." https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB243

What IS the Dark Web Anyway?

Mon, 18 Aug 2025 00:00:00 GMT

What imagery does the phrase "Dark Web" evoke in your mind?

To most, the Dark Web is an urban legend -- a monster hiding under the bed, a space normally safe and purposeful turned enigmatic and sinister. In the last twenty years the term has become a catch-all scapegoat whenever hidden, illicit activity is uncovered online. I'd like to demystify that notion. Would you be surprised to learn that crime is a far cry from the original intent behind the technologies making up most of the Dark Web?

What if this shadowy back alley is one of the last places you can walk unseen? One of the few online spaces where a semblance of privacy, anonymity, and freedom of speech persist? This is the first in a series of articles on the Dark Web, Darknets, and enhancing one's privacy online.

Legitimate Uses of the Dark Web

Culturally, the Dark Web isn't often associated with lawful activities -- and for good reason, given the amount of prominent crime that occurs there. Despite that, Darknets remain useful tools for many legitimate purposes. Tor, for instance, was built not to facilitate crime but to prevent surveillance and tracking.

The Dark Web can be used for:

Privacy -- control over access to one's personal data, especially powerful in authoritarian contexts.
Anonymity -- a distinct concept often conflated with privacy: the freedom to act without those actions being linked to your identity.
Freedom of speech -- as close to a guarantee as one can get online, once confidentiality and integrity are built into the protocol itself. This enables censorship circumvention, protection of dissidents, whistle-blowing, privacy-oriented marketplaces, and OSINT research -- though it can just as easily facilitate mis- and disinformation, so question every source.

This article is not a guide or "how-to" for any particular activity; it simply aims to communicate the legitimate, ethical use of the Dark Web as a resource.

The Surface Web, and What Lies Under

When people think of accessing the Dark Web, the first thought is usually the Tor Browser. Tor has become virtually synonymous with the Dark Web, when in fact the Tor network is only one Darknet used to anonymize traffic. But what is a Darknet? First, some key terms:

World Wide Web -- the internet as accessed through a browser.
Surface Web -- the portion of the Web that is (or can be) indexed by standard search engines; the easiest part to access.
Deep Web -- the portion NOT indexed by search engines: backend dashboards, databases, anything private and otherwise inaccessible.
Dark Web -- the portions of the Web hosted on individual Darknets.

Because the Dark Web isn't indexable by standard search engines, it can be considered to exist nested within the Deep Web.

Darknets: Building Blocks of the Dark Web

Clearnets

Clearnets comprise the default "layer" of the Web most people are accustomed to. Communication on a Clearnet is usually not anonymous or privacy-friendly -- most sites fingerprint users through IP address, screen size, and more. A Clearnet is the polar opposite of a Darknet; the Surface Web can itself be thought of as one very large Clearnet.

Darknets

A Darknet is an overlay network layered on top of existing communication protocols, providing anonymity, privacy, and therefore plausible deniability. It acts as a "mask" that obfuscates information tied to the user, often running on network segments that would otherwise be part of a Clearnet.

How much anonymity a Darknet actually guarantees depends on how its protocols and software were designed -- usually informed by a threat model for the project. To access a specific Darknet you need software built for it; Tor uses Onion Routing (hence "The Onion Router") and requires the Tor Browser or an equivalent purpose-built client.

For a Darknet to function well it typically needs significant user buy-in. Tor routes traffic through a randomized sequence of relays run by many different parties -- some passionate volunteers, others with less clear motivation, which is worth weighing against your own threat model. A non-exhaustive list of notable Darknets: Tor, I2P, Hyphanet, GNUnet. Many lesser-known projects exist too, with varying levels of community support, and plenty have been abandoned outright.

Bringing It All Together

From a bird's-eye view, this is the essence of the Dark Web: a grouping of individual Darknets that are largely segmented from one another, though intercommunication between them is sometimes possible -- a topic for another post.

This was the first in a series on the Dark Web, Darknets, and enhancing your privacy online. Thanks for reading -- more entries to come.

Sources

Go back to the index.

Are First Principles Becoming a Distraction?

Sun, 01 Jun 2025 00:00:00 GMT

I'd like to explore the uncertainty many are grappling with in balancing fundamental understanding against the immediate results enabled by AI tools. For clarity, I use "first principles" and "fundamentals" interchangeably here.

Lifelong learning is essential for a lasting infosec career. For the past year or so, as I've worked to expand my knowledge and skill set, I've dealt with a persistent internal dilemma.

I like to know the bare truth behind systems -- how individual first principles come together to make a larger whole. That doesn't seem like a problem on its face; the fundamentals are the most important thing, no? At least that's what my teachers did their best to hammer home. Lately, that lesson keeps getting called into question.

In cybersecurity -- and similarly in many IT fields -- practical necessity often forces us to learn tools rather than the underlying first principles. The industry is results-oriented: knowing how to quickly secure systems, respond to incidents, or manage infrastructure often matters more immediately than grasping the theory behind every practice. That pragmatism isn't inherently flawed -- it's effective -- but it creates tension around long-term retention and adaptability. As AI tooling grows more sophisticated, it becomes even easier to focus purely on immediate outcomes at the expense of deeper understanding.

First principles remain of extreme importance -- you need some understanding of a system before you can truly validate its safety. That said, there's no such thing as a "perfect" security attestation. Security is fluid, and ensuring it requires ongoing vigilance. So we rely on our tools to get the job done, because we often have little time for much else.

More and more, we're outsourcing our understanding of a domain to the LLM. What use is there in cognitively front-loading all the fundamentals when the model can worry about them? And if it doesn't have the capability, can't you just fill the gaps as needed?

Students and knowledge workers in IT-oriented fields face this dilemma as the age of AI progresses. The value of putting in the effort to learn first principles versus relying on outsourced intelligence is genuinely difficult to calculate, and it's always in flux as model capability continues to enable more sophisticated agentic behavior.

On one hand, AI tooling can show you the bigger picture -- it can augment your ability to understand fundamentals; it's an amazing learning tool. On the other, it gives you an intelligent cudgel to smash problems with: tell it to do Z without knowing X and Y yourself, because it already has the information it needs -- usually.

It's hard to avoid the sentiment online that young and future generations could be at a career disadvantage as AI capability outpaces the rate at which humans acquire similar skills. Optimists claim AI will merely automate the boring parts, freeing cognitive space for what only humans are good at. There's no telling whether that will hold. And there lies the dilemma -- at this point, it's impossible to know.

I don't mean to portray AI tools negatively; they've been of great use to me. Still, whenever I'm studying on my own -- the fundamentals of some IT domain, a programming language -- I find myself asking: are first principles becoming distractions? Am I wasting time mastering them while others leap into AI tools and find rapid success? Would diving straight into results-oriented projects offer a faster, equally robust understanding? And how does relying on these models square with personal privacy, given how often they handle sensitive data behind closed doors without clear guarantees of trust?

It's a real rabbit hole. I remain resolved that an understanding of first principles will always matter, and that some measure of human intervention in our systems will always be necessary -- but I grow uncertain how practical and feasible they'll remain as time passes.

Are these tools changing how you learn, or how you approach problems? Do you feel over-reliant at all? What are your feelings on the bigger picture?

Go back to the index.

Preparing for a Blue Team Competition

Thu, 27 Feb 2025 00:00:00 GMT

This past February, I began volunteering in WGU's Cyber Club, which afforded the opportunity to participate in the 2025 NCAE Cybergames -- a single-day, blue-team-oriented competition aimed at first-time competitors. This is one of my first experiences on a team-based defensive engagement like this. Our teams hadn't yet competed but had been hard at work preparing.

The NCAE has its own YouTube playlist covering fundamental Linux skills -- high-level, comprehensive, and lengthy. It's a great introduction, but it doesn't hint at the vast amount of other knowledge a team might want after watching.

With a background in software development, I'd call myself fairly capable at the terminal, but nothing truly prepared me for the open-endedness of all the potential skills a team could bring in. There's an overwhelming number of approaches to take, which made it hard to land on any single "comprehensive" practice plan -- so, alongside my own research, I sought the help of others. Here's what they told me. This competition mostly uses Linux hosts, so I don't give Windows-specific advice below.

Credits -- thanks to w33t (w33t.io) and echotango for taking the time to offer their expertise.

Core Skills

0) Research / OSINT Skills

Knowing how to quickly and tactically prompt search engines and other tools gets you needed information fast -- and knowing when to question the results matters just as much. This isn't "formal" research, it's the proverbial google-fu. When you don't know something, be prepared to figure it out on the fly.

1) Conceptual Knowledge

Fundamental concepts and frameworks within networking and security. Without at least a surface-level understanding of these, it's hard to communicate with teammates about specific elements of the engagement.

The TCP/IP model -- the OSI model, while popular, isn't how the internet actually works (ask John Strand).
Least privilege
System monitoring
Network monitoring

2) Linux Fundamentals

In a competition like this, you'll feel dead in the water without rudimentary command-line knowledge. Ideally you'll have some passing knowledge of the system as a whole. Roughly in priority order:

Navigating the filesystem -- cd, ls, cat, cp, mv, and a basic understanding of the Filesystem Hierarchy Standard.
Bash -- overall syntax, operators, stdout vs. stdin vs. stderr, input/output redirection, piping.
Users and groups; sudo.
Process management -- ps, kill.
Service configuration -- systemctl, systemd (to a minimal extent).
Networking and protocols -- opening/closing ports, DNS configuration (the NCAE uses bind in its tutorials), routing.

3) Knowledge of Communication Protocols

Some of the Linux skills above require familiarity with widely used protocols. If you're touching network configuration, you'll need to understand what you're working with -- though a comprehensive knowledge of each protocol isn't required, just enough to acquire the skills necessary to protect your environment.

Know these no matter what: TCP, UDP, IP (v4, and v6 if in scope), ICMP, SSH.
Know what these are, tailored to your role: DNS, FTP, SSL/TLS.
May not always apply, depends on the scenario: NFS, SMB, Syslog.

Gaining a Competitive Edge

This is a bare-bones list -- dive deeper into each topic, ideally with direct advice from someone more experienced, if you want competitive results.

In the NCAE, teams get external network access and few restrictions on tools they import, as long as everything used is disclosed or already public. Don't assume you can bring in any cutting-edge defensive solution, though -- you rarely know the state of each endpoint. The NCAE's practice environment uses Kali Linux 2021.1 as its attack box, a rolling distribution whose package repos will refuse to install onto such an out-of-date system anyway. That's seemingly by design: the organizers want you to get creative, so much so that in cases like this they'll downright force you to.

Realizing this, our teams started brainstorming, with more help from w33t and echotango. This is a growing list, in no particular order:

A shared cloud sandbox for practice -- Digital Ocean + Terraform?
A list of IoCs to triage -- which indicators of compromise carry the largest risk? netstat and ss are good for spotting some of them.
Pre-built scripts & configs -- an Ansible playbook (run over SSH from a player's own machine, for compatibility) to set up user accounts, groups, and least-privilege permissions; pre-built bash scripts for initial setup; a secure SSH config; a vulnerability-analysis script.
System & network monitoring -- syslog for simple, compatible monitoring, ideally automated.
Deterrence -- per-host firewalls (iptables/ufw) where available.
Operational security -- unique, memorized passwords with a backup in case of compromise; a secure way to share them; SSH keys used with extreme caution on potentially vulnerable hosts; regular backups, or at least a SHA256 hash to verify integrity before trusting one.
Least privilege -- tailor folder and file permissions to specific roles.
Monitoring processes -- lsof -i -n and lsof -p <pid> to find open backdoors, ls /proc and /proc/<pid>/cmdline to trace where a process was invoked, strings against a suspicious executable.
Common services worth knowing, even unmentioned by organizers -- nginx, SQL/Postgres/Flask, certbot (dry-run first to avoid rate limits).

Roles and an engagement playbook were both still work-in-progress at the time of writing -- delegating tasks (someone watching connections for intrusions, and so on), and a roughly ordered sequence of steps to run through on connecting to the environment: get spice-vdagent working for shared clipboard, get accounts provisioned fast, open external access through the router first, run the Ansible playbooks over SSH, inventory and vuln-scan every host, take manual rsync backups, remediate and harden, then stand up monitoring. Coordination is the constant: make sure your actions don't conflict with a teammate's.

Two general tips: with this many options, don't consider too many at once -- pick a tool to get experience with it, and move on if it isn't working out. And the Black Team is usually there to help when needed.

Fin

That's all I have for now, but I'll keep updating as preparations continue. There's much more I could cover in preparing for an event like this, but as is always the case in security, staying current means always learning. Security is never a guarantee -- all you can do is build the best castle you can, repair your walls as needed, and hope your enemies don't bring a trebuchet.

Go back to the index.