After meeting with our first client's security team it's clear that we don't have any of the procedures in place that these clients are used to vendors having with regard security and oversight.
While our app and infrastructure has been built with common-sense security and best practises, we haven't put in place things like vulnerability scanning, anti-malware, patch management procedures etc.
Where and how can a developer like myself get started with
1. Understanding the length and breath of _what_ exactly we should be implementing from a security standpoint
2. Actually implementing it
3. Documenting procedures
From my (limited) experience, one thing that enterprises love is asking you to fill out a 30 page security questionnaire. They take an age to complete so be aware of this if you’re thinking of going down the enterprise-sales path. I think it’s one of the big reasons that “contact us for pricing” exists for very large customers.
That will get you your security policies and an overview of what your looking for. If you do decide to get certified make sure to how a vendor that does both consulting and auditing. There will be some that will guarantee that you pass. Yes it's a pain, but it's table stakesb for big Enterprise customers in the US
in short, gitlab enables us to avoid merging vulnerable code as much as possible - see the https://docs.gitlab.com/ee/user/application_security/ or if you prefer more marketing jargon here https://about.gitlab.com/solutions/dev-sec-ops/
With your software hardened for certification after a 6 to 12 month cycle of risk and compliance sprints, you’d be able to both reference acceptance by one of largest banks in the world, and speak the language of future buyers.
Of course, be an idea a bank like us can use, and be willing to have an open mind about the value of building a robust platform.
// Heads up: sibling link to https://www.enterpriseready.io/ is good, but just a part of what’s needed for regulated compliance.
> After meeting with our first client's security team it's clear that we don't have any of the procedures in place that these clients are used to vendors having with regard security and oversight.
As mentioned in other answers, your potential customers will often give you an absolutely brutal questionnaire about this in the early exploration phase. Something that may surprise you though is that many “requirements” can actually be waived or reduced in scope, especially if the individuals investigating your product have some clout within the organization.
Be attentive to the actual needs of these customers, not the “hard requirements” of the paperwork, but make sure that as part of the legal paperwork all of your “we won’t have this ever, we don’t have this yet, we have this in x capacity” answers are all in writing. You might be surprised how many of these “requirements” don’t actually matter once these answers are written down.
Note that I mentioned “we don’t have this yet” as a valid answer. Some of the requirements presented might actually be things you know you need to implement, but don’t have the capacity to do so immediately. In my experience, customers appreciate your honesty about these sorts of requirements and can temporarily waive them with the understanding that they will be made available at a later date. Be sure that you mean what you say here: saying “we’ll have this at some point” can eventually become a point of contention if you don’t ever actually implement these features.
> While our app and infrastructure has been built with common-sense security and best practises, we haven't put in place things like vulnerability scanning, anti-malware, patch management procedures etc.
I have no idea what your tech stack looks like, but if you use cloud services at any level, you should look into how your cloud providers fare against the provided requirements.
Other answers have mentioned NIST SP 800-53 as a potential starting point for security requirements. This set of standards includes the concept of “inherited controls,” where the security requirements can be fulfilled by your upstream service providers without any additional effort on your part. This same concept also applies to the private enterprise space.
As an example, if you use a “serverless” architecture from a major cloud provider, you can automatically assume compliance with “anti-malware,” host-level vulnerability scanning, and patch management requirements. If you host your source on Github, you can legitimately claim Github’s built-in dependency vulnerability alerting as source-level vulnerability scanning.
If you happen to be running your own infrastructure here, your employer should seriously consider a migration to managed services wherever it makes sense to do so. Technical compliance with security requirements is a huge operational overhead. There’s a reason the US Federal Government has given up on in-house hosting and is now buying cloud services from Amazon and Microsoft.
> 3. Documenting procedures
At a tactical level, in order to close a sale or get your security validation, you’ll want to take the approach of “document first, implement eventually.” The best technical implementation of security controls in a NIST SP 800-53 scenario will utterly fail validation without adequate documentation, but you could skip actual implementation entirely and still squeak through an assessment with no more than an answer of “we promise to follow our own documentation.” counter-response.
Sure, you’ll eventually need to implement the documented procedures and follow the documented policy. This is going to sound extremely cynical, but so long as the fault of non-implementation can be externalized from the rest of the organization, the end customers will be happy enough to keep paying you. This is why documentation is so much more important than implementation: end customers and vendor organizations get to state that they already went through their due diligence by writing everything down, and point fingers at individuals when things aren’t following the documentation.
Your first couple security reviews are going to be a beast. They'll take time and you'll have a lot of technical and process remediations to do. When you go into a security review, make sure that the IT team on the other end understands what you do, what kind of data you'll be handling (if any), who at their company will have access, etc. You'll get the same security questionnaire as any other external vendor, but if your application is less sensitive you can sometimes make a strong case that the bar should be lower for you in certain areas. Sometimes (not always) you can use "we don't handle sensitive data" as a mitigation instead of building out an unecessary security feature.
If you haven't already, you'll need to create a set of Security Policies that you (and your future team) will follow. This can start out as a short document explaining your software development lifecycle and some common-sense policies like "we use MFA wherever possible" and "we encrypt data in transit and at rest." You'll end up making a lot of revisions to this document early on as you go through your first security reviews and start to align your process with what your clients expect and require. You can refer back to this document in security reviews as supporting evidence of your best practices.
The best thing you can do early on is track all of the technical and process requests from these security reviews, even the ones you don't incorporate. Keep a spreadsheet listing all of the technical and process requests from each of your clients and how your organization compares (e.g. "Client A requires 10 iterations before password re-use; we require 12" or "Client B has asked for strong encryption on passwords; we use PBKDF2 with a SHA256 hash"). This will make it easier to fill out future security reviews and it gives you a list of requirements when you consider changing something like your authentication user experience.
Find a third-party Penetration Testing as a Service company that you trust and start working with them right away. Getting an annual third-party pentest will be a requirement for almost any enteprise client, and it will give you a good idea of where you stand before heading into a security review. Our partner (BreachLock) also does monthly scans against our production website to make sure we haven't introduced any obvious security bugs.
It does get easier: once you've passed a handful of security reviews you'll be in a better position to push back on unreasonable requests. First off, you'll know what's reasonable and what's not. Second, you'll have enough other security considerations in place that you can make a good case for mitigation.
Finally, an aside... I want to reiterate the importance of keeping audit logs above and beyond what your clients might request. If you use a package that tracks every change to your models and who made those changes (django-audit-log or sqlalchemy-continuum in Python world) you'll be able to check the "audit trail" box during security reviews. But a hidden benefit is that you'll have a wealth of data you can mine for reporting later. You won't know what your clients want to report on until they're using your product, so keeping all of this data makes it much more likely you can do some archaeology and give them historical reports when you (and your clients) find out what's most important to them.