Over the past few months, Casa Hacker has been hardening its platforms. Hardening, in the jargon. In practice: tightening what was loose and closing what had been left open out of habit.
It went end to end — from the servers we use every day to team training and considerable changes to our systems. It wasn’t maintenance. It was a precondition.
A precondition because we wanted to move ahead with our plans for artificial intelligence and cognitive computing, and there was no way to do that on a foundation nobody had reviewed. An AI platform built on loose foundations isn’t an AI platform. It’s a risk with a nice interface.
So that was the order: the house first, then whatever we want to put inside it. Security and privacy by design — not as a layer applied at the end, because a layer applied at the end is a patch, and patches peel off.
Casa Hacker has defended data protection for years. Above all the rights of the data subject: the person the data belongs to. That isn’t a communications posture. It’s how Brazil’s General Data Protection Law was conceived, and we agree with it.
And if we think the law matters enough to defend it publicly, the least we can do is implement it in here. Step by step. Including the boring steps, the ones nobody sees and that make for no publication at all.
What “encrypted” means here
Every conversation between the outside world and Casa Hacker travels encrypted, through a single entrance. There is no second door, no shortcut for one particular system, no “just for now” exception — which is exactly the kind of exception that stays.
Past that door, our systems talk to each other without touching the internet. They speak inside the machine itself.
And then there’s the other half, the one almost nobody asks about: data at rest. Our databases and sensitive files live inside an encrypted volume. If someone carried the disk away, they would be carrying noise.
The copies
What we keep is copied out of Brazil every day: three countries, on three continents. Encrypted before it leaves — filename and contents alike. Anyone intercepting it wouldn’t even know what the file is called.
Two decisions inside that deserve saying out loud, because both have a price.
The server encrypts its own copies and cannot read them back. The key does not live there. Whoever compromises the server does not read the history. The price is that we now depend on key custody held elsewhere: lose the key, lose the backup. We took that risk with our eyes open, because the other risk is worse.
The copies can be written, never erased. Someone with full control of the server cannot delete what has already been stored. That is the difference between having a backup and having a backup that survives precisely the day you need it.
Keeping isn’t enough. You have to rehearse the way back.
A backup that has never been tested is faith, not a backup.
Every week an automated process reaches one of the most distant copies, downloads it for real — over the internet, as it would on a bad day — and checks that the package is intact and opens with the right key.
Being exact about what that rehearsal proves and what it does not: it proves the copy exists outside this building, that it arrives whole, and that it is readable by whoever holds the key. It is not a full restoration of a running system. That remains an exercise with human hands on it. We write this down because “we have tested backups” is a sentence many organisations use when what they tested was a script’s exit code.
Zero trust — including in ourselves
The name for this is zero trust. It isn’t our invention: the concept was born at an American consultancy in 2010, became a technical standard published by the United States standards institute, and is now ordinary security practice. What it says is simple and uncomfortable — being inside is not a credential.
In practice, here: every access to data is logged, and whoever accesses it has to keep proving they are who they say they are. It isn’t one login in the morning and free movement until nightfall. It’s identification every time, with more than one factor — and one of those factors runs through a platform that exists only for people at Casa Hacker.
That last detail is what most reduces the risk that isn’t technical. Most successful attacks today don’t break anything open: they convince someone. A factor that cannot be asked for over the phone, pasted into a chat, or reproduced by someone who does a good impression of a badge takes social engineering out of the game in a good share of cases.
What holds this up at our edge is Cloudflare’s access platform. Our internal admin panels aren’t protected only by the application’s own password: they sit behind an identity check that happens before the request reaches the system. Whoever fails that check never speaks to the application — it doesn’t even learn of the attempt.
Identity comes from our corporate directory, not from a parallel account list. That matters more than it sounds: when someone leaves the organisation, switching off the corporate account closes access to everything at once. There is no list of systems where that person “also had a login” — the list nobody can find precisely on the day they need it.
Sessions expire. Access granted is not access forever. And machine accounts — the kind one program uses to talk to another — have their own rules, separate from people’s. Treating a program and a person by the same yardstick is how you lose control of both.
Devices count too. Team equipment is enrolled with a profile defined by the organisation, and that profile is not negotiable on someone’s own machine: you can’t switch the protection off because it got in the way that day. Security the user can disable in two clicks is a suggestion, not a control.
Each person sees what their work requires
Nobody here has access to everything. Each person has a role, and the role defines what they can reach — the technical name is separation of duties, or role-based access control.
It is annoying. Genuinely annoying: it generates access requests, waiting, and “I can’t open this”. We chose annoying. Broad access is comfortable right up to the day a single compromised account becomes the whole organisation.
The edge: Project Galileo
There’s something that has to be said without false modesty: organisations like ours get attacked. Not by accident, and not because we have money — but because of what we say, who we serve and where we are. Civil society, journalism, human rights and education in peripheral territories come under fire regularly. And almost no organisation in this field has the budget for enterprise-grade security.
Project Galileo, from Cloudflare, exists precisely because of that mismatch. Created in 2014, it gives enterprise-level protection, free of charge, to vulnerable public interest organisations. Casa Hacker is part of it.
In practice, that changed the design of our edge — the border between the internet and us. It’s worth explaining what each piece does, because “we’re protected by Cloudflare” means nothing on its own.
The attack doesn’t arrive. Against denial-of-service attacks — the kind that takes a site down by volume, not by flaw — the defence isn’t withstanding the blow. It’s the blow not arriving. Malicious traffic is absorbed in a network distributed across the world, with capacity we would never have and wouldn’t sensibly try to build. Our server doesn’t get stronger: it gets out of the way.
Only the legitimate gets through. Every incoming request is inspected before being forwarded. A request carrying a known attack pattern dies at the edge, not on our server. What keeps the machine standing isn’t our ability to withstand a malicious request — it’s that the request was never delivered.
DNS is a door too — and it opens both ways. Almost everyone thinks of security as watching the entrance. But a compromised device isn’t dangerous because someone comes in through it: it’s dangerous because it tries to get out, looking for the server of whoever infected it. We use monitored DNS filtering exactly there. Before any connection exists, at the moment a name becomes an address, known malicious destinations are blocked. It is the cheapest and most underrated defence there is: it acts before the attack has anywhere to call.
Policy travels with the person, not with the office. Team devices run the client of Cloudflare’s access platform. That means the same rules apply at the office, at home, in a coworking space or on a phone on the bus. It’s the opposite of the old model, where the office network was “the safe place” and everything else was an exception — a model that died, and that many organisations still pretend is alive.
An application firewall we audit every day. Security filters have a classic side effect: blocking real people. A form that won’t submit, an attachment that fails, a person who gives up. And nobody finds out, because someone blocked by mistake doesn’t open a ticket — they leave.
So our filter isn’t merely switched on: it is audited. Every day an automated process examines what was blocked in the previous hours and separates what was an attack from what may have been someone legitimate, and the result lands in an internal channel where the team sees it. If that monitor goes quiet, it counts as an incident — a silent monitor is indistinguishable from “everything is fine”.
That distinction is the difference between security and obstruction. Blocking is easy. Knowing who you blocked by mistake is the work.
Anti-bot checks without a toll on actual humans. Our public screens — including the whistleblowing channel — use an anti-bot verification that works without puzzles, without “click every traffic light”, and without tracking people across the internet. This isn’t about comfort: a whistleblowing channel has to resist automated flooding and, at the same time, cannot charge the person reporting the price of being identified. Reconciling those two was hard until recently.
Two quieter pieces close the block. Our domain is cryptographically signed, which stops anyone from convincing the internet that Casa Hacker’s address is some other server. And connections happen only over modern versions of the encryption protocol, with the edge itself checking our server’s certificate before speaking to it. Nobody gets in the middle of that conversation.
Notice that this last piece is the same idea as the previous section. Zero trust isn’t a product you buy: it’s the decision not to have a privileged place. The edge is where that decision becomes configuration.
We don’t cut corners on security
This is a budget choice, and it shows up in the tools.
Our infrastructure runs on Red Hat Enterprise Linux 10. It isn’t the cheapest system to operate, and it isn’t the easiest. It’s the one with a long, predictable life cycle, security fixes with a deadline and someone accountable, centrally managed cryptographic policy, and a compliance ecosystem that lets us audit the machine against an external standard instead of against our own opinion.
And a good part of what we build — including the system where the organisation’s sensitive data lives — is written in Rust. The reason is direct and it isn’t fashion: an enormous share of the serious security flaws in the history of software comes from memory-handling errors, and Rust was designed to make that entire class of error impossible to compile. It’s security that doesn’t depend on whoever wrote the code being alert that day.
It costs more in development time. It’s a demanding language that argues with whoever is writing. We accept that argument, because it happens before the code reaches production — and not afterwards, with real people’s data in the middle.
A social organisation choosing the more robust tool over the cheaper one is a political decision about whom this data belongs to.
Secure software from where it is born
Platform security doesn’t start at the server. It starts with how software gets there.
Here, three principles govern that.
By default, nothing runs. Our server’s configuration refuses any application image on principle. Every software origin has to be explicitly authorised to be executed at all, and the operating system’s own pieces only run if their cryptographic signature matches the vendor’s key. The default posture is “no”, and every “yes” was a recorded decision.
Exact version, not a label. Applications run at a version identified by the fingerprint of the content, not by a nickname like “the latest one”. Nicknames shift under your feet; fingerprints don’t. That means we know exactly what is running, and that an update is always a deliberate act — never a surprise that arrived overnight.
Nothing enters without review. Code changes go through a reviewed proposal and automated verification before becoming production.
How we know we’re secure: by measuring
This is the part that separates security from talk about security.
There is an international standard for secure server configuration, maintained by an independent organisation, the CIS. It’s a long, boring list of hundreds of objective checks — the kind of document nobody reads for pleasure, and that is exactly why it’s useful: it has no opinion about us.
We audited our machine against that standard, at the level recommended for a production server, before starting the work. Then we audited again at every stage. Today our compliance sits at a high level — well above what we found in the first measurement, and above what is common in infrastructure at organisations our size.
What matters here isn’t the score. It’s two other things.
The first: the ruler came before the work. The first measurement was taken to find out where we stood, not to prove we were doing well. Without that baseline, “we improved security a lot” would be a sentence with nothing behind it.
The second: we are not at 100%, and we don’t intend to pretend otherwise. Part of what’s missing is deliberate deviation, documented with the reason — settings the standard recommends that would break the database or the applications, and where we consciously chose working software and recorded the choice. Security without a working service isn’t security: it’s a server that’s switched off.
Artificial intelligence comes in through the same door as everyone else
Back to the beginning: all of this existed so that we could move ahead with AI on a defensible foundation.
When that foundation was standing, AI came in obeying the same rules. No exception was opened for it — and that’s worth saying, because opening an exception for the new system is exactly how gaps are born.
In practice: an AI assistant has no account of its own and no permissions of its own. It acts on behalf of a person, with that person’s explicit authorisation, and the access granted is necessarily less than or equal to what that person would already have on screen. Nobody gains permission by connecting an assistant.
Every action the AI can take was classified, one by one, by how much it hurts. A reversible action executes and is logged. An action with effects outside the organisation returns what would happen and stops, waiting for confirmation. An action that moves money or assets requires a recorded dry run and human confirmation.
And identifiable personal data is substituted before any excerpt leaves for an external service, with a record of how much left.
The full account of that work — including the six hypotheses of ours that measurement disproved — is in the previous publication.
Who authorises a data transfer
Data only leaves this organisation with authorisation from our data protection officer. It isn’t a shared authority, and it isn’t approval by convenience of whoever happens to be doing the task.
Yes, that creates a bottleneck. It’s the bottleneck we want. Data that leaves the organisation without someone accountable for having let it go is data nobody can explain later — and “later” tends to be in front of a data subject, a funder or a regulator.
A real example, because a principle without an example is decoration.
When we decided to put our traffic behind that edge protection, a conflict appeared that no manual resolves: routing traffic through an external network means that network sees what passes. For most of our systems that is acceptable and is governed by a data processing agreement. For the whistleblowing channel it was not — because its design stores the reporter’s address irreversibly, on purpose, so that not even we can know who it was.
The decision was not the technology team’s. It went to the data protection officer, was decided on a legal basis and recorded in writing in our architecture documentation, along with the contract that supports it. And the most sensitive system of all was deliberately left outside the edge: we accepted losing protection against attack in order not to lose anonymity.
I write this because it is the kind of decision where security and privacy pull in opposite directions, and someone needs the authority to say which of the two gives way. If that person doesn’t exist in your organisation, the decision will be taken all the same — by whoever is doing the configuring, alone, at eleven at night.
Knowing where each piece of data is
There’s a part of this work that isn’t about any intruder. It’s about the person the data belongs to.
We maintain a platform that centralises the mapping of personal and sensitive data spread across our systems — what exists, where it is, why it’s there and how it is being processed.
The reason is direct. The law gives the data subject the right to request access, correction, portability and deletion of their own data. Except that right is worth nothing if the organisation doesn’t know where the information is. An organisation that needs three weeks and a task force to answer “what data do you hold about me?” is not complying with the law — it is pretending to comply, and counting on nobody asking.
Here, when a data subject asks, the answer comes out in a few clicks. That’s what the mapping is for: not to have a published policy, but to be able to answer.
Training, because the failure is almost never the machine’s
Every year the team receives training, and through the year it receives briefings — what is allowed, what isn’t, how to protect the data of those who trusted us, and how to recognise an attempted scam.
We insist on this because almost no incident starts on a server. It starts with someone in a hurry, with a request that looked legitimate, with a message that arrived at just the right moment. You can encrypt everything and still lose everything to a “just confirm this for me quickly”. There is no configuration against that. There are trained people.
What you can take from here
If this text is useful to another organisation in our field, may it be useful for these five points — none of which depend on budget:
Measure before improving. Run an audit against an external standard before touching anything. Without a baseline, you have no way of knowing whether you improved, nor of proving it to whoever funds you.
Ask help from those who offer it. Enterprise-grade protection exists free of charge for public interest organisations. Project Galileo is a real path, and most eligible organisations simply don’t know it exists. The same goes for more: corporate identity, zero trust access and anti-bot verification all have free tiers that cover an organisation our size.
Deal with what goes out, not only what comes in. DNS filtering is cheap, quick to switch on, and covers the most common real compromise scenario.
Decide who authorises what, in writing. Defined roles and one person accountable for data transfers are worth more than any tool. That costs no licence at all — it costs a decision.
Publish your limits. Saying what you don’t yet do is what gives weight to what you say you do.
We like to say that the peripheries are not a place of waiting, they are a place of beginning. That holds here too. Information security has become, in many people’s minds, a thing for banks and multinationals — something a social organisation can’t reach and therefore doesn’t even try.
It isn’t true. What most of this requires isn’t money: it’s deciding that the data of a young person from the periphery deserves the same care as the data of a bank’s customer.
It does. And that is why we put the house in order.
References and further reading
- Slack — Security at Slack: how Slack protects your data. The publication that inspired this one. https://slack.com/intl/pt-br/blog/collaboration/security-at-slack-how-slack-protects-your-data
- Law No. 13.709/2018 — Brazil’s General Data Protection Law (LGPD). https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
- National Data Protection Authority (ANPD), Brazil. https://www.gov.br/anpd/pt-br
- Cloudflare — Project Galileo. Free enterprise-grade protection for public interest organisations, since 2014. https://www.cloudflare.com/galileo/
- Cloudflare — Project Galileo anniversary report: cyberattacks against civil society. https://cfl.re/cyberattacks-against-civil-society-project-galileo-anniversary-report
- Cloudflare One — documentation for the access and filtering platform. https://developers.cloudflare.com/cloudflare-one/
- Cloudflare Turnstile — anti-bot verification without user tracking. https://developers.cloudflare.com/turnstile/
- NIST SP 800-207 — Zero Trust Architecture. The standard that formalised the concept. https://csrc.nist.gov/pubs/sp/800/207/final
- Forrester Research — No More Chewy Centers: Introducing the Zero Trust Model of Information Security (John Kindervag, 2010). The work that coined the term.
- Google — BeyondCorp. The first large-scale implementation of the model. https://cloud.google.com/beyondcorp
- CIS Benchmarks — Center for Internet Security. The secure configuration standard we audit our servers against. https://www.cisecurity.org/cis-benchmarks
- Casa Hacker — The AI that interests us does not answer email. The account of the data work this publication rests on. https://casahacker.org/publicacoes/a-ia-que-nos-interessa-nao-responde-e-mail/