
Ask HN: Where to start with enterprise-level security and procedures? - aosaigh
I&#x27;m the only developer on a small web application that is targetting enterprise customers.<p>After meeting with our first client&#x27;s security team it&#x27;s clear that we don&#x27;t have any of the procedures in place that these clients are used to vendors having with regard security and oversight.<p>While our app and infrastructure has been built with common-sense security and best practises, we haven&#x27;t put in place things like vulnerability scanning, anti-malware, patch management procedures etc.<p>Where and how can a developer like myself get started with<p>1. Understanding the length and breath of _what_ exactly we should be implementing from a security standpoint<p>2. Actually implementing it<p>3. Documenting procedures
======
rosswilson
I’m building a side project that has an enterprise customer, and the
Enterprise Ready website was a good intro to the concepts that enterprises
value: [https://www.enterpriseready.io](https://www.enterpriseready.io)

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.

~~~
HereBeBeasties
I think that site pretty much nails it, especially SSO (depending on what
you're doing you probably want LDAP, SAML and OIDC/OAuth2) and audit logs.

It misses a couple of other nice to have differentiators, though:

The ability to pay by invoice to their purchasing department (you probably
want to insist people do this upfront and yearly and not monthly, to avoid the
pain of chasing people). Plenty of enterprises won't be able to buy your
product without this.

Some decent consideration given to self-service (which RBAC might cover, but
best to be explicit), by which I mean that you can delegate admin control such
that you don't need to put in tickets with the team that runs the system in
order to get changes made to its configuration. (Example: GitHub enterprise
let's you set up multiple orgs, so you can give each dept. or team an org to
do what they like with.)

If you put some thought into granular permissions from the beginning (in the
GitHub case, for example giving away perms to create repos, but not allowing
that user to change how auth works for the org, for example) you will avoid
pain later.

APIs. Dependent on product, but ideally design your UI so that it is backed by
an API that lets me do everything programmatically, so I can drive your
product with other integrations via we hooks, or GitOps, or whatever else I
want to do.

------
goatinaboat
Have one of your team train and take a cert like CISSP. Even if you don’t
believe in certs going through the process will show you exactly what large
organisations consider to be “best practice”. There will almost certainly be a
CISSP at your client who will take you seriously once you are “one of the
club”. And it will be a nice bit of resume padding for the future anyway.

------
twunde
I'm honestly surprised that nobody b here has mentioned getting a compliance
certificate like a SOC2. Within the US that's what's expected by these
security teams. Take a look at Comply:
[https://github.com/strongdm/comply](https://github.com/strongdm/comply)

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

------
pixl97
While probably a larger scope than you are looking for, the fed.gov has
written volumes on security policies in the NIST 800 series.

[https://whatis.techtarget.com/definition/NIST-800-Series](https://whatis.techtarget.com/definition/NIST-800-Series)

------
diminish
beyond a security risk/mitigation analysis - we currently embed security
inside our development, test and deployment process using gitlab's sast/dast
and other scanning features.

in short, gitlab enables us to avoid merging vulnerable code as much as
possible - see the
[https://docs.gitlab.com/ee/user/application_security/](https://docs.gitlab.com/ee/user/application_security/)
or if you prefer more marketing jargon here
[https://about.gitlab.com/solutions/dev-sec-
ops/](https://about.gitlab.com/solutions/dev-sec-ops/)

------
Terretta
If an NYC area startup, especially fintech, would like an eye popping
immersion course into the needs of not just enterprise but _heavily regulated_
enterprise with internal and external auditors, I’d be happy to invite you
work with my team.

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/](https://www.enterpriseready.io/) is good,
but just a part of what’s needed for regulated compliance.

------
djsweet
I recently left the US Federal “Cyber” space, which involves practically
everything that enterprises claim they want with respect to “security”. I also
work for a company looking to get into the enterprise space, so have some
experience on the side of spinning up these practices.

> 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.

------
reed_t
rosswilson and HereBeBeasties hit the nail on the head with their replies. As
my company (a 3 year old enterprise SaaS platform raising a Series A) lands
more clients, our highest-priority feature requests have been around (1)
granularity of permissions, (2) granularity of workflow rules, (3) ability for
clients to administer their own roles and permissions (through a UI or using
SAML metadata), (4) APIs, and (5) reporting, in that order.

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.

