Having dev/ops experience is a huge plus, there is a lack of security practitioners that know the pains of developers that and are able to offer technical security advice from experience.
A good place to start is by trying to distill some of your hard earned experience into a two hour session for a technical audience in the gaming industry, and offer that to potential clients.
As a starting consultant, this is a low-risk way for clients to gauge your expertise and can give you a foot in the door, or at minimum valuable feedback.
Are there common security standards or regulatory compliance drivers for the gaming industry?
Understanding the external security drivers for a company and being able to translate these drivers into pragmatic requirements or processes gives you a leg up compared to generic security consultants.
Having knowledge of common frameworks can be beneficial. Look into NIST CSF, OWASP SAMM and the OWASP DSOMM (In order from high-level to hands-on)
If you want to pad the CV with some certifications, have a look at Paul Jerimy's certification roadmap. https://pauljerimy.com/security-certification-roadmap
Skip the basic ones (such as security+), especially since you have dev experience. Go for CISSP if you want to offer managerial advice or go for the technical certs (eg. cloud provider certs) if you want to be more hands-on
Seek out your local OWASP chapter and attend some local meetups and security conferences. Talk to your peers at these events and learn what positions they hold, what challenges they have and what tips they may offer.
Many OWASP projects are looking for (dev) contributors. Have a look and see if you can contribute to some projects with your experience. This is a learning opportunity and you're helping the community, being a contributor can be a great way to show your expertise to potential clients.
If you are using OWASP projects, the OWASP slack channels can be quite active and good learning resources too. OWASP conferences often have free or low-cost training too, as part of the conference.
I do not know of a go-to checklist but as I work in the industry, I hope I can provide some tips from experience.
Any service that is needed for the day-to-day working of your business should be properly secured. You mention DNSSEC but it starts with the user accounts that are used to log in to your registrar, hosting provider, payment provider, any SaaS...
Generate unique, strong passwords for every business related service. Use a password vault like keepass or a service like 1password for secure storage and ease of use.
Multi-factor everything you can, and prefer to use an app or physical token over SMS-based multifactor. I have recommended Twilio Authy a lot due to the multi-device support and google authenticator compatibility.
Use DNSSEC for your domain(s), enable SPF, DKIM and DMARC for your mail, set up TLS for your website(s). Depending your needs, cloudflare has some great options for the latter.
Security of the endpoints and endusers greatly depends on wether your employees BYOD, what the network looks like and most of all, what you are protecting.
I recommend to search for some public "acceptable use policy" or "security policy" documents, especially in the context of ISO27001 and create an own policy based on that, depending on your needs and environment. Even better than policy is proper training for employees on security hygiene, how to avoid phishing and if relevant, secure development. Ceate an open environment for employees to report potential issues or mistakes.
Regarding secure development, OWASP is a great resource for anything application security.
You're recommending this startup do DNSSEC. Can you rattle off some pre-acquisition startups of any note that have DNSSEC-signed their domains? Slack, for instance, is DNSSEC-signed (signing infamously took them off the Internet for the better part of a day) --- because Salesforce, their acquirer, required it; they did the same to Heroku (which also suffered a DNS outage).
My point is not so much to litigate DNSSEC itself (although I'll do that) as it is to establish the ground truth that DNSSEC-signing is not a norm among tech companies. It would be a particularly weird bit of ops overhead for a young startup to invest in.
If you'd like some tips on how to quickly test whether a startup (or a large list of them) have signed their domains, I'm happy to help.
It might not be the norm, my recommendation here was based on the OP mentioning it themselves, on experience with smaller companies and from my own experience working for a TLD (consider me biased)
Norms change and from my perspective there is still a big ongoing effort to push DNSSEC adoption worldwide.
I'm curious to know why you'd argue against DNSSEC and what your experiences are with operational overhead.
If you like, substitute "best practice" for "norm". The point I'm making is that almost nobody does DNSSEC, including but not limited to the startups with the best-regarded security teams. I'm wary of pointing the "security teams" part out because it leaves the impression that maybe companies without security teams do normally turn DNSSEC on, but that's not the case: almost nobody turns DNSSEC on. It doesn't solve real problems, and it creates a bunch of new problems.
Again, a good way to rebut this would be to present examples of established startups that have DNSSEC-signed their domains. For instance: you could take the top startups list from YC (it's on the front page, and you can pull the domains out easily in the Chrome console) and then check all of them to see if they're signed.
A bunch of them are! About 8%. But that's because a bunch of them are not in North America, and European registrars in particular automatically DNSSEC-sign new zones. But take a wild guess about Stripe (huge security team). Or Instacart. Or Cruise. Or Brex (banking!). Or Reddit. Or Gusto. Zapier. Segment. Vanta (the YC standard for SOC2, FWIW).
To the extent "no DNSSEC" is a norm, and not a best practice (it is both), that norm is unlikely to change; I think DNSSEC adoption is likely to decline (as it has in some previous years). It just doesn't work.
A good place to start is by trying to distill some of your hard earned experience into a two hour session for a technical audience in the gaming industry, and offer that to potential clients. As a starting consultant, this is a low-risk way for clients to gauge your expertise and can give you a foot in the door, or at minimum valuable feedback.
Are there common security standards or regulatory compliance drivers for the gaming industry? Understanding the external security drivers for a company and being able to translate these drivers into pragmatic requirements or processes gives you a leg up compared to generic security consultants. Having knowledge of common frameworks can be beneficial. Look into NIST CSF, OWASP SAMM and the OWASP DSOMM (In order from high-level to hands-on)
If you want to pad the CV with some certifications, have a look at Paul Jerimy's certification roadmap. https://pauljerimy.com/security-certification-roadmap Skip the basic ones (such as security+), especially since you have dev experience. Go for CISSP if you want to offer managerial advice or go for the technical certs (eg. cloud provider certs) if you want to be more hands-on
For additional training, have a look at the list that NIST compiled: https://www.nist.gov/itl/applied-cybersecurity/nice/resource...
Seek out your local OWASP chapter and attend some local meetups and security conferences. Talk to your peers at these events and learn what positions they hold, what challenges they have and what tips they may offer. Many OWASP projects are looking for (dev) contributors. Have a look and see if you can contribute to some projects with your experience. This is a learning opportunity and you're helping the community, being a contributor can be a great way to show your expertise to potential clients. If you are using OWASP projects, the OWASP slack channels can be quite active and good learning resources too. OWASP conferences often have free or low-cost training too, as part of the conference.