As a hobby project, I started a market research/overview of the Belgian cybersecurity ecosystem [1].
This required me to write a lot more than before, although I've always enjoyed writing.
In the beginning, I wrote beginning -> end, with just a high outline in my mind. Now, I write bullets first and then expand into paragraphs.
This has helped me write a lot quicker and I think the articles have become easier to read (which matters a lot online, where everyone reads diagonally).
Agree, it’s the only way for us to test our assumptions.
I wonder how well the experimentation approach will work in this case though, as:
1. Effects might be subtle and outside of the expected impact area.
2. Timescale might be really important (effects over a time much longer than we anticipate. Or even a timescale that makes it impossible to run many experiments in reasonable time)
We don’t know what the second and third order effects would be. We can’t even correctly predict what the weather will be 3 days in advance. No chance that we can predict what the consequences of such a significant and never been done change would be.
Seems like a high risk play, only to use as a last resort to me.
Nice feedback loop you have there! (re last point). If you can point to the actual proven ‘indicators of risk’ instead of flagging every potential issue onder the sun, everyone is going to love you!
I look forward to a summary report on incidents somewhere in the future ;)
* Do you know if there are any follow up meetings planned? Did they discuss some kind of process?
* what were the main concerns discussed?
* interesting to find out about the coalition (I was briefly involved in a similar insurance setup in my home country). Is your ‘baseline’ derived from some standard? Can I find it online?
Many big corps do have a tiered process (depending on perceived risk). A trick is to get yourself classified in the lowest possible tier.
Teaching your salespersons to help their contacts/champions with convincing their internal security to lower classification will be great ROI for you :)
The article does a great job of cutting through all the noise.
Highlighting here because it is relevant: certification is about sales.
I’d only do it once you either:
1) you spend much more time filling out questionnaires than the time/investment needed to get certified (note, they’ll still ask you to fill out questionnaires though)
2) you want to go after companies that actually care about this (banking, government). Even then, these will have shortcuts through procurement that will lower requirements (ie: innovation projects, small ticket items)
That's very interesting! What sectors were those buyers in? I've mostly worked with fortune 5000 and financial institutions.
It doesn't surprise me in the least that you didn't get any feedback. The default option for these companies is to make you accept their specific blend of security requirements... Of course, you then have to support that forever...
I've had good luck setting up a meeting with both the due diligence person and the actual buyer/champion present. It's often easier to explain your stance in person and the buyer is going to stop the due diligence person when he's getting into the weeds.
I've done more than my fair share of vendor due diligences (and audits, action plans and contract reviews,..)
To me this is a non-issue, because customers almost always ask for types of security checks, not for specific tooling (ie: asking for source code analysis vs asking for veracode).
As a rule, compliance/government folks will be concerned about the types of security measures you have in place and not about the specific implementation. Commercial source code analysis tools have varying support depending on language (as others have mentioned: some languages are harder than others). A very valid alternative is to use a linter with security checks (and potential custom rules). The advantage will be that checking will go much faster so you can do it more often (every PR instead of nightly for example). Many security conscious companies have something like this in place.
In general when you're answering security due diligence, it's your job to convince the customer you're going to keep their data safe. They will ask about certain things you don't have and it's your job to explain how you're still solving the underlying problem. Typical example: customers asking for antivirus on all systems and you using (immutable) docker containers.
By the way, the interesting thing here is not the answers to the questions, but how you organise your company to quickly and effectively (as in: no follow up meetings or worse: action plans) answer them. My pet peeve here is "customer guided security": You start from what you think you need (baseline) and you add the security measures that take the longest to explain why you don't have them. That way, you're skating through most of the due diligences and sales velocity goes up, which will make your bosses very happy.
OP mentioned he's in a business owner role. He's probably talking to customers often, possibly scoping projects or features.
In these cases, having notes will prevent scope creep and will be necessary to have customers accept the work. Customers will forget what was discussed and what was agreed to. They will want to add that "one last thing" just when you're expecting to close the project.
Even in different roles (or internally), I think many would benefit from writing down meeting notes because it anchors the discussion and creates shared understanding. Voice only will cause many to forget specifics or move the goal.
I don't think OP is in favor of writing a book for every meeting. Having notes / documentation will make you more effective. It will also lower the frequency of you and the other party having different expectations. It's a good habit to have for these reasons and the many others outlined in this thread.