Ask HN: Where to start with enterprise-level security and procedures?

https://news.ycombinator.com/item?id=21669408

by aosaigh • 7 years ago

37 9 7 years ago

news.ycombinator.com

I'm the only developer on a small web application that is targetting enterprise customers.

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

rosswilson• 7 years ago

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

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• 7 years ago

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.

Terretta• 7 years ago

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/ is good, but just a part of what’s needed for regulated compliance.

goatinaboat• 7 years ago

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.

reed_t• 7 years ago

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.

diminish• 7 years ago

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/ or if you prefer more marketing jargon here https://about.gitlab.com/solutions/dev-sec-ops/

pixl97• 7 years ago

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

djsweet• 7 years ago

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.

twunde• 7 years ago

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

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

Ask HN: Where to start with enterprise-level security and procedures?

Related Stories