Who is behind RedRock Inc
An independent technical blog focused on the security architecture of financial systems. We write about what we know from the field — not from vendor marketing decks.
How it started
RedRock Inc started out of a simple frustration: while working as a DevSecOps engineer at a fintech company in Newcastle, I kept finding myself searching for detailed technical material on the security architecture of trading systems. What I found, in most cases, was either pitched too high — generic articles about "the importance of security" — or locked behind the paywalls of consulting firms selling exactly the service they were writing about.
In 2024, I decided to start writing it myself. Not because I thought I knew everything — but because I believed there was room for a technical blog for Australian security and infrastructure teams that speaks plainly, with real code, real diagrams and references you can check. Since then, RedRock Inc has grown slowly. No ads, no sponsors, no paid content.
My approach is simple: if I write about something, I first understand it in depth. If I can't explain it with a code example or a diagram, I probably don't understand it well enough to write about it.
What we do — and what we don't
RedRock Inc is a technical blog. We publish articles, guides and reviews covering the security architecture of financial infrastructure — trading systems, cryptography infrastructure, identity management, and secure communications protocols. Every article is self-checked for technical accuracy before publication, and updated when standards or tools change.
What we don't do: no commercial consulting, no pentest services, no investment recommendations. We sell nothing except content — and that is free as well. If someone approaches you in the name of RedRock Inc and offers a paid service, that isn't us.
Our methodology
Every analysis we publish on RedRock Inc goes through four stages. I believe in full transparency about the process, because that is the only way to judge the reliability of the findings.
1. Architectural mapping
The first stage is always mapping. Whether it's a review of the TLS 1.3 protocol or an analysis of an exchange clearing system, we start from an understanding of the overall structure. Who the components are, how they talk to each other, where the boundary runs between one service and another, and what flows between them. Without a map, every analysis is an educated guess.
In practice, that means reading technical documentation, RFCs and protocol specifications. For exchange analyses, I lean on public documentation published by Eurex, CME and other exchanges. For security protocols, the main sources are IETF RFCs and NIST publications.
2. Threat modelling
Once there is a map, I build a threat model. Not something formally complete at the level of OWASP Threat Modeling — but a focused analysis: what can go wrong, who might exploit it, and what the damage would be. I use the STRIDE model as a thinking framework, not as a rigid checklist. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — each of them matters in different contexts.
3. Verifying findings
Every technical finding I publish gets verified. If I write that a particular TLS configuration is vulnerable, I test it — with openssl s_client, with Wireshark, or with a purpose-built tool. I don't rely on automated vulnerability scanners alone. Those tools are good as a first layer of checking, but they produce false positives at a rate that rules out relying on them exclusively.
4. Documentation and conclusions
The final stage is writing. Every article includes the findings, the evidence (code, tool output, screenshots), the recommendations, and the order of priority. I separate "must fix now" from "worth improving at the next step" from "worth considering for the long term". In my view, a report that doesn't distinguish between different urgencies is a report that helps no one.
The operating entity
The site and its content are operated by RedRock Inc. Registered address: 5511 Flinders Street, Newcastle NSW 9334, Australia.
For legal or commercial enquiries: steven.garcia229@hotmail.com
Who writes here
Steven Garcia, founder and editor-in-chief of RedRock Inc. A security engineer with five years of hands-on DevSecOps and financial-systems security experience. Specialising in service mesh, applied cryptography, and trading infrastructure built on event-driven architecture. He holds a Bachelor of Computer Science with a focus on network security.
The wider writing team is still being established. For now, most content is written by the editor-in-chief with informal peer review from specialists in the field.
Updates and changes
May 2026: About page updated — added a detailed methodology section and refreshed the contact details.
March 2026: Full rewrite of the site structure and improved mobile support.
January 2025: The blog launched in its first version.