Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time
Hi everyone! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 2.5 million people through life’s big transactions, with a core aim to protect many more.
We have the following open positions:
- Security Engineer - we’re looking for a security generalist who’s happy to get stuck into everything from architecture and assessments to policy and compliance.
- Lead React Native Engineer - we're looking for a highly experience React Native engineer with solid mobile experience to take the lead on our new app experience.
Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time
Hi everyone! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 2.5 million people through life’s big transactions, with a core aim to protect many more.
We have the following open positions:
- Security Engineer - we’re looking for a security generalist who’s happy to get stuck into everything from architecture and assessments to policy and compliance.
- Senior Software Engineer - we use Go, Typescript, Next.js and Temporal on GCP but are open to people with a different tech stack.
This article is interesting to me mostly because it appears totally incoherent.
> “Western politicians do not appear to be strong-arming the nerds to produce favourable numbers. At the same time, international statistical bodies worry about the example of Dominik Rozkrut, who at the end of last year was mysteriously dismissed as Poland’s chief statistician.”
At the same time as not strong arming these bodies, at least one might be? What is the implication here?
> “Economic “surprises” in rich countries, where the reported data point either beats or falls short of analysts’ expectations, soared during the pandemic. Years later, surprises remain 30% bigger than before it.
The confusion represents a reversal of a trend. In 1941 Britain’s…”
How is less trust/revisions in the data today connected with what Britain was doing 70+ years ago? We seem to just have two things said next to each other as if they were related?
Am I just being dumb or is this just ramblings, whether or not you agree with the headline?
> At the same time as not strong arming these bodies, at least one might be? What is the implication here?
Yes, exactly. Most don't but one looks like it might be.
> How is less trust/revisions in the data today connected with what Britain was doing 70+ years ago?
Because up until the pandemic the data had been getting steadily better with fewer "surprises", now it seems to have stagnated: "Two factors have now brought progress to a halt."
On the first point, ok sure - it may be the case that most aren’t but one is. So… what’s the reader supposed to take away from that? What’s the problem we’re looking at here - malpractice or corruption? Just both but maybe one more than the other? Seems like bad writing to me.
Second point - ok, great. Let’s actually structure the article around that. “We think that cuts in statistical departments, coupled with lower and more complicated survey engagement, have made it harder to rely on the data those departments produce”. Great, nice, coherent argument.
I’m totally not trying to get at you, I just think TFA did a pretty bad job of explaining the problem it’s trying to highlight.
Hmm. I am trying not to assume too much, but I will attempt to respond based on summaries of some real events in Russia and corporate America.
In organizations, where leadership style resembles Christmas tree more than a pyramid, people invariably are beholden to the leader. Depending on the organization's culture, the leader may allow little to no dissent. While leader may not explicitly tell you to do X, their wishes are known and some people do respond with trying to 'guess' what their leader wants.
In other words, the implication may be that no one is overtly influencing other people, but, in an attempt to save their positions, people produce documentation their leader may want to see.
Which, honestly, happens a lot more often than it should.
Thanks and yes, I agree with you! Reality is muddy and complicated and political tendrils reach deeply into all government functions. I would like to ask though: what do you think the author wants us to believe? a) that data is more unreliable because of corrupt influence, or b) data is less reliable because of statistical department cuts and a partisan audience? If it’s b, why mention a? It’s not that I disagree with b or a, just that if you are arguing for one, why mention the other except to say “yeah, this happened but it doesn’t contradict my view because x”
Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time
Hi everyone from the Thirdfort team! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 1.5 million people through life’s big transactions, with a core aim to protect many more.
We have the following open positions:
- Senior DevOps Engineer - cloud hosted using GCP
- DevOps Engineer - cloud hosted using GCP
- Senior Software Engineer - we use Go, Typescript,Next.js but are open to people with a different tech stack.
- Frontend Engineer - we use Go, Typescript,Next.js but are open to people with a different tech stack.
I think a lot of comments here might be missing the point of this standard - it’s not specifically designed just for startups or to cover general organisation security (like EDR). It’s a product feature oriented checklist that should help short circuit some aspects of supplier security due diligence and establish a set of product security features that any B2B product with ambitions to sell to enterprise customers would benefit from aspiring to, and anyone buying can leverage. That means large multi-product businesses looking to ship an MVP for a new service as well startups with a bright idea but a possibly limited understanding of enterprise IT compliance needs.
I’ve got some experience as Head of Cyber/InfoSec at a couple of startups/scaleups and I see this as potentially useful in a bunch of ways if broadly adopted. It establishes a baseline both for our own products and our suppliers, attests to stuff that actually affects how we integrate with and operate a third party product (ISO 27001 gives me no clue whether you support SSO, have viable logs that I can actually ship to the SIEM etc.) and hopefully simplifies both the due diligence we do on our suppliers as well as that done on us by our customers by allowing us to reduce a good chunk of the product feature questions to “does your product meet the MVSP standard”.
As head of security, did you ever try to get devs to remediate a ton of appsec vulns during early days, or ask them to build data flow diagrams?
My criticism of this is that you can secure the product with solid defense in depth on the enterprise/infra side in a way that is:
- minimally invasive to devs
- aligns with what is likely there to slot into - what SAST tool can you pay for that early on at a startup, let alone slot into a non-existent DevOps pipeline. $1-200k SIEMs existing at a series A/B that prob has 1-2 sec engs?
- get a WAF for a bandaid fix for the appsec problems initially until you can hire product security folks
I think these are broadly reasonable points and when there is no existing security team (I’m joining to set one up) I usually start with going after infra, picking the low hanging fruit and carefully planning out any points of friction with a user base that isn’t used to having a security team. That’s often a journey that involves basic cloud controls, restructuring IAM, bringing in MDM, pushing for license upgrades for key SaaS apps that force you to pay the SSO tax, making sure the WAF and DoS protections are actually doing something useful, documenting the security signals we have and those we need, rolling out and drilling an actionable incident response plan etc. I came from software engineering into appsec, prodsec and then into security management and possibly as a result of that I don’t push for plugging a dependency/static analysis tool into a work item tracking system and fire hosing engineers with CVEs in code paths they never hit. I do want to see that they can keep up with general patching though - can they, on a regular (think weekly/monthly) cadence upgrade their libraries and frameworks to the latest patch version and still ship with quality that week?
But when you look at some key aspects of that infra/biz app security journey at a largely cloud based young business - like taking more control of IAM across SaaS, bringing together activity from those multiple cloud systems and creating alerts that actually matter - that all involves knowing your vendor supports SSO, possibly also SCIM, has logs that contain relevant data that can be exported/streamed into a SIEM. Some of the stuff this standard demands is going to be fairly core to securing business infra. I just get bored talking to vendors that want to wave an ISO cert at me as if that somehow makes it ok they don’t give me access to audit logs.
I’m broadly aligned with what your focus is on what to do first.
Your approach seems to self-evidently present the issue with this proposed framework.
If:
- the goal of a startup security program is to meaningfully protect revenue (two parts to this IMO: prevent catastrophic breach, and have a sec program that can pass RFPs and SOC2 eventually)
- RFPs can start early and often
and:
- for a small sec program, ideally you shoot for a very tight overlap of the above (tangible risk controls that helps sales)
- the goal of the MSVP is to slot into the RFP process to provide meaningful controls
Then:
- we’ve both independently laid out that a bulk of the work for early wins is on enterprise and infra, and it’s not worth hammering devs beyond the obvious (patches acceptably safe package management, no horrible API or authn/z risks)
- majority of what you’ve covered and I’ve covered aren’t on the proposed MSVP
So putting that together, it makes me feel that MSVP misses the mark vs its goals. The authors claim that it’s supposed to be more product related, but much of it is not product-related. These parts also largely don’t at all cover the obvious things you’ve laid out. And, the product-related parts get right into the dev’s space, such that you’d need a very security-committed dev or a very over-tasked sec eng to do it all. It seems to be a bad blend of not pragmatic for the realities of startup sec via not understanding how one can get defense in depth product wins without doing strictly “prodsec” and why that’s a solid approach.
I have been responsible for these controls in multiple startup and smaller businesses selling into Fortune 500, including setting up security "programs", and agree with everything you say.
Ultimately it boils down to:
> Convince whoever is asking you are following whatever process they are asking about so they can check a box.
They call it security theatre for a reason. Of course if you don't want to be lying, well, you gotta implement a lot of this stuff as at least written policies. Also, auditors have a tendency to ask for evidence...
Hi everyone! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 2.5 million people through life’s big transactions, with a core aim to protect many more.
We have the following open positions:
- Security Engineer - we’re looking for a security generalist who’s happy to get stuck into everything from architecture and assessments to policy and compliance.
- Lead React Native Engineer - we're looking for a highly experience React Native engineer with solid mobile experience to take the lead on our new app experience.
Come take a look at our open roles: https://www.thirdfort.com/jobs/