[HN Gopher] Launch HN: Stacksi (YC W21) - Doing Security Questio...
___________________________________________________________________
Launch HN: Stacksi (YC W21) - Doing Security Questionnaires, So
Your Team Isn't
Hi HN, We're Emre and JJ, the co-founders of Stacksi
(https://www.stacksi.com), a product that helps fill out security
questionnaires so smart people can focus on higher-value tasks
(like actually managing security, or engineering or selling, or
really anything but filling out forms). At our last company, we
were the ones who filled these things out. We hated doing it, but
got them done because we had to in order to close deals that could
meaningfully impact the trajectory of the company. If you've had
to deal with these, you understand that they're the worst way of
broadly assessing a company's security with a reasonable time /
cost tradeoff...except for every other method that we currently
have at our disposal. Problem is, that they're often 200+
questions sent to salespeople and forwarded ASAP to some other poor
soul (often some sort of engineer). The questions asked (e.g. what
is your company's encryption standard? or "what events do your logs
capture?") - assuming that they're even correctly phrased - touch
sufficiently detailed aspects of a company's security practices
that make it difficult for someone who doesn't have at least some
security / compliance background (e.g. a salesperson) to answer
properly. All of this means that high-capability individuals (CTOs
in earlier-stage companies, Solutions and Security Engineers in
later-stage ones) end up spending significant amounts of time
answering the same questions that they answered a few days ago,
just phrased sufficiently differently that rote copy-paste isn't a
viable solution. This is what we're trying to fix. We do it, in a
nutshell, by taking two things: 1) a company's security docs (e.g.
policies, diagrams, vuln scans) and 2) the questionnaire in
whatever format it's in (GRC portals, web forms, excel, word, PDF,
tea leaves). Putting those two things together, we get the
questionnaire done accurately and quickly using a human-in-the-loop
model. (We combine a tuned BERT model searching on the company's
docs with manual review by a human on our team). The product works
something like this: Upload your docs; Upload the file, schedule 15
minutes to review with us in the next couple days, then forget
about the questionnaire until the review call and do other work. In
the background, we index all of your documentation and run a search
for each question to find the most relevant sections of your
documentation. Once that process is complete, a human on our team
reviews what the system has output to make sure that answers are
accurate and high quality. We then mark it as reviewed and you
receive notification. When Stacksi's internal review is done, our
team takes a few minutes to review it with you (usually within ~48
hours so we have enough time to ensure quality across many
questionnaires), and then you send it back to the company that
asked for the assessment. In instances where your docs don't touch
on specific information (often comes up with questions around app-
specific authentication options like "Does your application support
SSO with our Identity Provider, [INSERT IdP here]?"), our software
also has collaboration features to make it easy for teams to work
together to get the questions answered without pulling out all
their hair deciphering asinine questions or nagging teammates for
answers. It then uses those answers to inform future
questionnaires. We currently charge for questionnaires per-
question ($2), so companies don't have to pay through the nose to
get help or commit to a subscription. We've gotten some feedback
that we are under-pricing right now (maybe too much), but our goal
right now is to grow the number of customers we're working with
rather than trying to squeeze every penny out of every customer.
The more customers we have, the better our product gets for
everyone, since (quality) data is the biggest driver of a good vs
garbage model. For that reason we want to make it as much of a no-
brainer as possible for people to sign up and get started. We're
super focused on making sure the NLP handles the majority of the
work and not making this a business that relies on having a bunch
of questionnaire savants reviewing questionnaires all day every
day. Our goal is for a human to spend <15 seconds per question in
review and thus, we're pricing this as a software product, not a
services product. We also hope that pricing this way puts us in
better alignment with our customers' success (the more time we save
them, the more we earn, without locking them into a contract that
forces them to pay whether they get questionnaires or not). Some
bigger customers actually want the subscription for financial
predictability reasons, so we've started supporting that, too.
Finally, for companies that don't yet have policies written, we
help customers create and manage them, and charge separately (kind
of like Clerky, but for security policies). We want to support
builders in growing their companies (in our own small way) and
allow talented people to put their skills to more productive use
than filling forms. We would love feedback from the community, and
we're happy to answer any questions that come up!
Author : emremm
Score : 123 points
Date : 2021-03-19 13:28 UTC (1 days ago)
| wgyn wrote:
| Filling out questionnaires is such a time suck. It's extra
| painful because different companies use different standards
| (CAIQ, SigLite, VSAQ). Hopefully they solve the near-term
| questionnaire problem, but I'm also excited to see them
| eventually tackle the underlying problem--we _want_ to prove to
| potential customers and users that we take security seriously,
| but right now it 's prohibitively tedious and time-consuming to
| do so.
| lbriner wrote:
| Can't wait to use something like this, definitely a pain point to
| fix!
|
| One of the hardest parts though is when the question is too
| abstract so even as a human, I'm not sure what they are asking
| and in what context.
|
| For example, a typical question would be "What encryption do you
| use at your company"? Dumb question and no accurate answer that
| would take less than 10 pages. How would you deal with these?
| joetheone wrote:
| These types of questions are exactly why we have a human-in-
| the-loop model :)
|
| Our AI is probably not going to touch this as it's very
| unlikely a good answer in in your documentation, so a real
| person will take a stab at it and then flag it for review with
| you. We've seen a number of these BS types of questions and can
| generally give an answer that will satisfy the client, and we
| can review it with you to make sure you're happy with it.
| an_opabinia wrote:
| I don't know. Answering these questions took like an hour, and
| everyone will find the markdown SOC2 docs generator.
| joetheone wrote:
| If you're not answering many questionnaires, it's totally
| possible that you don't need help. We have customers who are
| filling out 5-10 of these per week, and the time really adds
| up.
|
| We also have absolutely no requirement for our customers to
| generate docs with us. Any high quality security documentation
| will do. If you want to spend the hours required to take
| something open source and adjust them to your needs, more power
| to you!
| soumyadeb wrote:
| This can be super useful if it works. Congrats on the launch!!
| joetheone wrote:
| Thanks for the kind words! If you ever have a questionnaire
| that needs answering or just generally have questions about
| security & compliance, drop us a line and we'd be happy to chat
| :)
| newman8r wrote:
| What happens in the event a question is answered incorrectly, and
| the company loses a contract because if it? Does Stacksi assume
| the liability, or provide some sort of insurance in this case?
| emremm wrote:
| Good question. Short answer is no, we don't insure you in the
| deal.
|
| I'd be willing to bet (and infosec folks doing assessments
| should chime in here), but it's rarely, if ever, a binary
| decision on a single question (unless you have absolutely no
| encryption on a service that's handling sensitive information).
| It's a consistent degree of carelessness and lack of attention
| paid to basic security blocking and tackling.
|
| You'll typically lose deals in security review because you've
| done no vulnerability scanning, have never done a pen test, are
| using outdated encryption, don't demonstrate that you properly
| protect data - and oh, by the way, you want to handle
| customers' or employees' sensitive personal information. If
| that's the case, your company should spend a month patching up
| these basic security gaps and delay on returning the security
| questionnaire.
|
| Ultimately, we allow companies to edit and change responses
| (and require approval of any Stacksi-generated ones) to make
| sure that the responses are an accurate representation of the
| company's security processes and policies.
|
| That's the purpose of having multiple levels of review.
|
| Things go like this: AI takes first pass / Human on Stacksi
| team reviews for accuracy and quality / Stacksi Account Manager
| reviews with the customer.
|
| I think our current customers would attest to the level of
| quality we're able to attain with this approach.
| sverhagen wrote:
| I think this is the wrong answer. Of course you aren't
| liable, your value proposition shouldn't be shifting the
| liability, it should be just about shifting the bulk of the
| work. Any company worth their salt doesn't have one person
| working on RFPs or such, so you can help reduce the team, but
| your customer should still do a review. That way they still
| save money on the (more tedious) initial preparation, while
| still being in charge of the end result.
| joetheone wrote:
| What you describe is exactly what we do. Every single
| answer output by Stacksi is required to be explicitly
| approved by a member of our client's infosec team before it
| can be exported and used. Questions that we don't know the
| answer to or that we have taken an educated guess at are
| explicitly flagged as such and our reviewed together by our
| team and the questionnaire reviewer at the client.
|
| I see Stacksi as giving our client's an extra pair of hands
| on their team to help with this tedious work. We're a jr.
| team member though, so our work needs to be checked over
| before being sent :)
| newman8r wrote:
| Thanks. I think you're probably right about that being
| relatively rare. I'm curious how often these deals are lost
| due to the security questionnaire at all.
| joetheone wrote:
| I'd love to see stats on that. I'd bet that rather than
| losing the deal entirely, the more common case is that the
| deal gets delayed (possibly significantly) if something is
| flagged in a security review. After all, even standards
| like PCI & SOC2 include provisions for compensating
| controls :)
| simonturvey wrote:
| Do you support a kind of internal "yes, but..." note so that
| opportunities for improvement can be drawn from the
| questionnaires themselves and tracked? I always wanted that to be
| way easier.
| emremm wrote:
| Yes. (no but)
|
| The way that our system is built, every question has (up to)
| three possible inputs:
|
| A selection An additional detail An attachment
|
| When we parse a questionnaire, the system picks up whether
| there's a selection option available and shows that
| accordingly. Every question can have a detail or attachment.
|
| Recorded a quick video here to give a bit better overview:
| https://www.loom.com/share/ed32e33598404bc7a883a66653c99258
|
| You can also add an internal comment (by tagging someone like
| in Slack) to discuss with colleagues. That info stays on the
| internal system and doesn't get sent to the customer when the
| questionnaire is exported / sent off.
| jamespaden wrote:
| How do you differ from Skypher.co, which is another YC company?
| We're about to sign up with them.
| joetheone wrote:
| Admittedly, I have not seen any of Skypher besides their
| website.
|
| That said, the biggest differentiator that I see is that we use
| a human in the loop model, while Skypher is a purely software
| solution.
|
| In other industries, an AI that can answer even 90% of the
| questions well would be a fantastic result. On a security
| questionnaire, that's going to lead to more back and forth,
| more meetings, and more work for the vendor (in this case you).
| Our reviewers are there to make sure that every question is
| answered perfectly.
|
| If Skypher solves the problem for you, great!
| emremm wrote:
| Overall, this is an underserved market, and saving smart
| people time on security questionnaires is a goal we both
| have.
|
| Here's what I know about our product - we can ensure that the
| quality of the responses are exceptionally high - our
| customers tell us that they're at or better than the
| responses that their teams would be providing.
|
| Ultimately, what I think that translates to is more time
| saved on our customers' end and less back-and-forth with
| their prospect's infosec team to get the deal closed.
| __jf__ wrote:
| Who's sending these questionnaires, when and why? I'm asking
| because I work in infosec and have never seen one.
| ssss11 wrote:
| I work for a reasonably large corporate in regulated space
| holding client data, and yeah, our infosec are regularly
| sending security questionaires. They go to new vendors, or
| existing vendors when we plan to purchase something new from
| them. I believe they're reviewed periodically as well.
|
| No one likes wasting time filling out forms, but in large
| businesses, theres a need to ensure the whole service (incl.
| subcontractors/vendors/data processors) are operating properly.
| So yeah some confirmation is needed... 200 page docs though?
| Geez. I think ours is ~15.
| joetheone wrote:
| I've never seen a 200 page one, but 200+ questions is fairy
| common. At 15 pages yours probably clocks in around there at
| least :)
| ssss11 wrote:
| Oh sorry I misread what the length was! :)
| joetheone wrote:
| No worries. 15 pages sounds like a doozy!
| joetheone wrote:
| Hi there!
|
| Questionnaires get sent when companies want to do business
| together that requires sharing sensitive info with each other.
|
| I envy that you have never had to deal with these!
| xtracto wrote:
| Im head of engineering at a ~70 people B2B startup and man I
| HATE these things with passion. I get one almost every other
| week and yes, they are indeed 200+ questions. Even after you
| are PCI, SOC2, ISO27001, etc compliant some companies REQUIRE
| you to fill these things. It is a HUGE pain and time consuming
| chore.
| joetheone wrote:
| You sound like you should talk to us and get your time back
| :)
|
| A lot of auditors make it seems like once you have your SOC2
| or ISO27001 certification that you'll be free from these
| forever, but our finding is that it might get you out of 20%
| of these at best, and for the rest it's basically table
| stakes.
| sz4kerto wrote:
| Genius. I know HN comments should have more substance, but what
| else can I say.
| joetheone wrote:
| We appreciate the comment :)
| roland35 wrote:
| My last role involved doing security audits if all of our
| vendors. I knew these forms weren't fun and now I feel bad!
| Luckily I don't have to do that anymore.
| joetheone wrote:
| No need to feel bad It's a cost of doing business :)
| turnerc wrote:
| Damn these security questionnaires are a pain and I appreciate
| this product, might not be best to feature Anthem on your
| frontpage about a security related product though...
|
| Additionally I'd be a little wary of handing off all my
| documentation to a third-party how do you protect this?
| Grimm1 wrote:
| Hi guys I have to say first the product solves some very annoying
| things people have to do so that's great. I have more of an aside
| though -- I really like your landing page is that custom?
| emremm wrote:
| Much appreciated!
|
| Like JJ said, we use Webflow for hosting the landing page and
| customized a template (softbit)
| https://webflow.com/templates/html/softbit-saas-website-
| temp....
|
| Credit for customization of the design goes to the awesome
| Cristi Hurhui (https://dribbble.com/CristianHurhui)
| joetheone wrote:
| It's a webflow template: https://softbit-template.webflow.io/
| neilv wrote:
| Three questions about liability and acceptance:
|
| 1. How do you handle any liability from having security-sensitive
| internal docs/info about all your customers?
|
| 2. How do you handle any liability from mistakes you make while
| answering questions? (Of course, both "good" and "bad" incorrect
| answers can be very bad, for your customer and/or their
| prospective/customer -- an incorrectly "bad" answer might cost a
| sale/relationship, and an incorrect "good" one might be relied
| upon and lead to a compromise incident or regulatory
| noncompliance.)
|
| 3. How many prospective/customers of your customers will _accept_
| security questionnaire answers prepared by an outside firm? How
| many will require the diligence and assurances to come from
| sufficiently knowledgeable _in-house_ people, with the company
| standing behind it?
| emremm wrote:
| These are good questions. I might even say...a
| mini...questionnaire?
|
| Seriously speaking - you bring up some interesting questions. I
| used our tool to respond to your questions, because I think it
| helps illustrate the point (see link below)
|
| https://www.loom.com/share/22ccb2188c3744cd82f17baa31cfb2e9
| danrozz wrote:
| Oh and, "How many prospective/customers of your customers
| will accept security questionnaire answers prepared by an
| outside firm?" Was answered by saying that being a third
| party- hey! That brings value right there! Huh? You're
| helping answer questionnaires. The risk is that your
| bullshitting my clients by writing technical, impressive
| answers but you don't work at the company. You don't know if
| - do you check if it's 256 bits or 512 bits? And why it's
| better or worse to use one or the other? No-You're not
| designing, implementing, monitoring, or auditing in any way,
| are you? Your deliverable is to eat data and format/match it
| to the questionnaire. How is your product actually add value
| to infosec and GRC? I can't use an answer written by you that
| explains that your company is actually adding value other
| than making answering questionnaires more efficiently. I
| mean- that's a good thing- but it doesn't validate you and
| answer the question above.
| joetheone wrote:
| Every single answer that comes out of Stacksi needs to be
| approved by an employee of the client before it can be
| exported and downloaded.
|
| The vast majority of answers to questions comes directly
| from a client's own security policies, which we
| (admittedly) trust are up to date and accurate. We do our
| best to ensure that we don't use files that were uploaded
| more than 6 months ago in our algorithms, but if we're
| getting bad inputs to the system you're going to get bad
| outputs. When our reviewers do write something new, we
| check with the client to make sure it is accurate and
| again, it needs to be explicitly approved by someone on the
| client's team who has the rights to review questionnaires.
|
| I don't see how this is any different from a jr. employee
| at a company answering a questionnaire based on the
| policies and then asking their boss to review. The jr.
| employee is definitely not going to go through every system
| themselves to verify that the policies and documentation
| are accurate. They are going to assume the policies are
| good and then double check with a trusted source (their
| boss on the infosec team), exactly what we are doing.
|
| We understand that right now we're not actually helping
| companies be more secure, and we've never claimed to be
| doing that. One of our first priorities moving forward is
| to develop additional tools to actually validate that what
| is being said in security policies is what is in place.
| We're not there yet because we are a small and young
| company, but we will get there :)
| danrozz wrote:
| Sorry- but the responses were regurgatory and vapid.
|
| A question for how you would deal with a client's IP was not
| really answered. Yes or no questions: Do you have some kind
| of liability insurance? What actual operational controls do
| you have to keep client information secure? Saying things
| like, "only people who are authorized to see the data can see
| the data." Doesn't say anything meaningful. What tools do you
| use? Actually use? Do you have samples of the reports, if you
| have them?
|
| I've been at start-ups and those were superficial answers
| that I could send if a client/partner/vendor needed to check
| a box.
|
| But I've also worn the hat of asking for those to be filled
| out and really caring about the answers. I wouldn't take
| anything I've heard so far as an indication of anything other
| than buzzword competency in a information security and
| compliance vocabulary. Sorry.
| joetheone wrote:
| If you want to go in depth on our operational or security
| controls in due diligence as a potential customer, we'd be
| happy to do so over email. You could even send us a
| questionnaire ;)
|
| However, you'll have to forgive us for not posting all of
| that in a HN comment. I understand that you "wouldn't take
| anything that you've heard so far as an indication of
| anything other than buzzword competency" but I assume you
| also probably wouldn't be conducting such diligence in HN
| comments.
| sverhagen wrote:
| You share what you want to share, of course, but they're
| also just challenging their (I have to assume: earnestly)
| perceived holes in your business model, you could just
| trying to answer in general terms, without having to post
| the detailed legalese here.
| joetheone wrote:
| You're right.
|
| My answers go something like this:
|
| 1. We handle a company's security documentation the same
| way companies treat any sensitive info they are storing
| (credit card data, PII, etc). We store it encrypted at
| rest and in transit, ensure that only employees who need
| access to said data have that access, require 2FA on
| everything, require sufficiently strong passwords,
| encrypt the hard drives of our laptops, virus scan every
| file that is uploaded before use, virus scan our servers
| daily, virus scan our laptops daily, etc, etc. We are not
| SOC2 compliant today but are heading down that path so
| that we can provide our customers with the confidence
| that we can be trusted with their information.
|
| 2. We have liability insurance for our own company, but
| we do not take liability for our answers because every
| single answer is required to be reviewed by an admin or
| security team member of our client before it can be
| exported from Stacksi. If an answer has not been pulled
| directly from a client's policies, we specifically
| highlight it and review it with the client to ensure that
| it is accurate and that they are 100% comfortable with
| it.
|
| 3. I have no idea what an assessor might think of one of
| their vendors using a company like Stacksi to help handle
| questionnaires, and I imagine it would vary wildly from
| person to person. However, I see Stacksi exactly the same
| as having an extra team member on your infosec team who
| exclusively handles inbound questionnaires. You (their
| boss) make sure they are familiar with the policies and
| procedures of your company, and then you review their
| work to ensure that it is accurate. Does it really matter
| whether that person is a full time employee or your
| company, an infosec contractor who helps out part time,
| or a service like Stacksi?
| securitypal wrote:
| Congrats Stacksi on the launch!
|
| Super exciting to see more companies solving the security
| questionnaire pain points :)
|
| Hope we both can solve this problem for the market and make it a
| win-win for all security, sales, and engineering leaders!
| nickdothutton wrote:
| Some of you might find this post interesting. The first step down
| the path to automating compliance.
| https://blog.eutopian.io/a-universal-lemma-for-compliance/
| emremm wrote:
| Appreciate the way you've thought about this, Nick. I like the
| suggestions that you bring up to at the end:
| What if we could produce compliant configuration snippets for
| live systems? What if we could express internal
| compliance policy in parsable form? What if we could
| automatically apply configurations and re-test? What if
| automatic attestation was cryptographically signed by both
| parties? What if this was so frictionless it could be
| done daily or on-demand?
|
| Ultimately, security is _hard_ and finding ways to simplify and
| automate protocols will make everyone better off.
| psoots wrote:
| I can't believe these questionnaires have become so pervasive
| that it's spawning an industry. I hate these things. They are
| such a burden on the small, niche software vendor.
| joetheone wrote:
| We totally agree! At our last company these were a major PITA
| and slowed us down a lot because when we first started working
| with other businesses, we were not prepared to handle them at
| all. We want to help remove the burden from small software
| vendors, and we think our pricing model is super user friendly
| :)
| Beefin wrote:
| Despise security questionnaires, so a very important problem
| you're solving.
|
| My company just onboarded RFPIO, which I'm super happy with which
| addresses everything it seems you're offering.
|
| How is Stacksi different than RFPIO?
| emremm wrote:
| Glad our product resonates!
|
| A couple points of differentiation:
|
| 1) First-shot completion: Our system typically gets 90%+ of the
| questionnaire completed with no user involvement. I don't think
| RFPIO (or other RFP-focused platforms) do that.
|
| 2) Guidance & Support: Some of the stickiest parts of RFPs are
| the questions that are either WTF? or that you answer "No" to
| and determining how to manage that. Does it actually matter
| that you don't have a WAF (depends on the rest of your
| architecture)? Does it actually matter that you're still using
| TLS 1.1 (probably want to change that)? Should you fix those
| things? RFP systems don't help with that; ours does (largely
| because we've put a human in the loop).
|
| What I've heard from our customers using those systems is that
| RFP systems help (after you've spend time on curation) with
| ~30-60% of questions. If the questionnaire is 200 questions,
| that still leaves you with somewhere on the order of 100
| questions to answer.
|
| Ultimately, RFPIO provides a software tool only; we're
| providing a software-enabled service.
|
| The time your team spends on questionnaires is reflected in
| that.
| joecasson wrote:
| Another tool that I've been happy with is Loopio. They do
| have the "Magic" capability that tries to automate answers.
| Given the consistent structure of security questions, they
| had a higher match / completion rate, but their UX was a
| little difficult to navigate. Again, software only solution,
| but something that might be interesting for comparisons.
| joetheone wrote:
| Loopio and RFP.io are direct competitors. They are both
| good tools, but are designed for RFP response in general
| and not security specific. RFPs do tend to have security
| sections, so there is some overlap for sure, but these guys
| by definition are focusing on a wider problem and don't
| dive as deep into security.
|
| A number of our customers combine our service with loopio
| or rfp.io and we are perfectly fine with that.
| ahstilde wrote:
| Stacksi makes so much sense. It is always frustrating when a
| senior engineer is pulled into doing security questionnaires.
|
| I had the pleasure of interviewing Emre for my podcast. If anyone
| want's a listen, check it out: https://www.aakash.io/all-schemes-
| considered/stacksi-emre-mu...
| secfirstmd wrote:
| This is very cool. Kudos for tackling this. At Security First
| (https://www.secfirst.org) we build free open source apps and
| tools for helping people learn about and manage physical and
| digital security. At one stage we spent a lot of time looking to
| how to built out smart forms like this for stuff like incidents.
| It gets very very complicated very quickly in terms of building
| out the backend brains of it. So massive kudos to you for
| tackling this challenge, I can only image how difficult it was. I
| look forward to testing it and seeing how we might be able to use
| it with groups like journalists and activists at risk. It's kinda
| hard to know at this stage from what's on your site but will
| there be some kind of api we can use with it?
| emremm wrote:
| Very cool! Security awareness and training that doesn't suck
| (I'm talking to you, Java "training" Applets from 2000) is
| probably one of the highest impact "soft" things that companies
| can do to _actually_ make their company (and people) more
| secure.
|
| We've built on top of an API (primarily for data I/O), but
| haven't exposed anything for public consumption yet (the API's
| only used by our app), simply because we have so much to tackle
| already that we're not ready to support a developer community
| using the API quite yet.
|
| Like you said, building arbitrary logic into forms is hard...
| secfirstmd wrote:
| Awesome, look forward to seeing how it goes!
| m0hit wrote:
| Wow! Looking forward for you to succeed. Filling out security and
| privacy questionnaires, especially when growing fast leads to so
| much wasted time.
|
| More importantly, because of the rush the knowledge generated
| during the answering of questions is not captured in a reusable
| format.
|
| I'm curious if could generate Security and Privacy white papers
| for companies that need to arm their sales/marketing teams using
| the information collected while fill out incoming questionnaires.
| emremm wrote:
| Appreciate the support and love the feature suggestions!
|
| Definitely something we'll be thinking about. Would love to run
| it by you as we build!
| ComodoHacker wrote:
| OK, but can we do better? Is there a better way to assess supply
| chain security risks than these questionnaires?
| joetheone wrote:
| This is actually what we're trying to build towards :) Our
| first products rely on the policies that company's put together
| themselves, but we're building towards tools that they could
| use to show more convincingly that information written in
| policies is actually put into practice.
| emremm wrote:
| No doubt. We're sure there will be better ways, and we'd like
| to help in getting there. Rather than die on that battlefield
| before we've built something meaningful, we're working to help
| at least solve the immediate need that companies face. We're
| fans of refactoring rather than blow up and replace right off
| the bat, with the thinking that it'll be a lot easier to change
| things from a position of relevance and experience. Personally,
| I'd love to move to a more protocol-based approach that has
| verification behind it.
| xtracto wrote:
| That's wat certifications are supposed to be used for (PCI,
| SOC2, ISO27001). But even if your company has them, some
| businesses want you to fill these horrendous questionnaires.
| joetheone wrote:
| Yep. Having them now gets you a seat at the table, but
| (usually) does not get you out of the questionnaire entirely.
| jasonkimtech wrote:
| Filling out questionnaires is definitely painful but reviewing
| them can be as well. Are you guys planning on building any
| tooling to make the review process for teams onboarding vendors
| easier?
| joetheone wrote:
| We definitely think about that, but our previous experience is
| as startup founders so we're starting out by addressing a
| problem we know very well.
| emremm wrote:
| FWIW, we'd love to help there eventually, we just think that
| the vendor side of the market is so abysmally underserved
| that we wanted to start there.
|
| The goal of this whole thing is to speed up the entire
| process of security review and _actually_ reduce 3p vendor
| risk while getting business done.
|
| I guess we've got our work cut out for us...
| robertlagrant wrote:
| > the vendor side of the market is so abysmally underserved
|
| We've found that, trying to sell into the NHS. 150 trusts,
| all with different questionnaires.
| joetheone wrote:
| That sounds terrible! Im so sorry!
| mwcampbell wrote:
| > Finally, for companies that don't yet have policies written, we
| help customers create and manage them, and charge separately
| (kind of like Clerky, but for security policies).
|
| And with that, you likely just won my company as one of your
| earliest customers.
| emremm wrote:
| _inserts celebration gif here_
| TheTaytay wrote:
| Seriously. Shut up and take my money.
| joetheone wrote:
| We'd love to! Reach out to us!
| mrclark411 wrote:
| Any thoughts on the NDA signing portion of the process when
| answering requests for detailed, private documents?
|
| Getting legal involved is a whole other level of time/expense.
| joetheone wrote:
| Stacksi is happy to sign (and has signed!) numerous NDAs with
| our clients.
|
| If you're talking about the NDA process between vendors and
| assessors, that is a whole different can of worms which we have
| not really waded into at this point.
|
| In my experience as a startup founder, the easiest way to
| handle these types of situations is to just read over and sign
| whatever NDA the bigger company has sent over.
| dctoedt wrote:
| > _the easiest way to handle these types of situations is to
| just read over and sign whatever NDA the bigger company has
| sent over._
|
| That can cause problems down the road for a receiving party.
| For example:
|
| 1. Some NDAs include terms that assign ownership of newly-
| developed IP to the big company -- this once resulted in
| Stanford University losing part-ownership of one of its
| biotech patents to Roche, in a case that Stanford
| (unsuccessfully) took all the way to the U.S. Supreme Court.
| [0]
|
| 2. Many, many old-fashioned NDAs still require the receiving
| party to return or destroy all of the disclosing party's
| confidential information. That can be quite burdensome and
| expensive for electronically-stored information. (Imagine
| having to search all your emails and backups to identify the
| disclosing party's confidential information.) And in any
| case, as insurance for possible future litigation, the
| receiving party would want to keep an archive copy to
| document what it received -- and by implication, what it
| _didn 't_ receive -- from the disclosing party. [1]
|
| [0] Federal Circuit case: https://scholar.google.com/scholar_
| case?case=679137785502826... Supreme Court case: https://scho
| lar.google.com/scholar_case?case=168732492844241...
|
| [1] Additional information:
| https://toedtclassnotes.site44.com/Notes-on-Contract-
| Draftin... (my course materials for the law-school business
| contracts class I teach; it's a still-crude interim draft)
| joetheone wrote:
| You're totally right, which is why I said to read over the
| NDA before signing :)
|
| I fully admit that we do not have the legal expertise to
| try and tackle that problem at this point.
| billyhoffman wrote:
| First, thank you so much for this! I hate these things.
|
| However answering these questions without nuance and context can
| at best cause a lot more back and forth between company and
| vendor, and at worse kill the deal immediately. Example:
|
| Bad way, no context: Do you have external certification for
| HIPPA/PCI compliance: No.
|
| Better way: Do you have external certification for HIPPA/PCI
| compliance: No, because product does not collect, store, or
| process health data or payment card data.
|
| How do you handle cases like this in an automated fashion?
| emremm wrote:
| Great question. I agree, answering a question like that in a
| thoughtless way can make your company look pretty
| unprofessional.
|
| We build a 'profile' of the company - what it does, they
| systems used, the type of data it handles (and doesn't) to
| answer these questionnaires.
|
| Part of the purpose of having a human-in-the-loop - especially
| for the first 1-2 questionnaires, is to support this type of
| review and ensure that answers are a sufficiently high quality.
|
| As a general rule of thumb when answering security
| questionnaires (which our system supports), any "negative"
| answer should have additional clarification. FWIW, I'd say that
| a more appropriate answer to that question would be N/A instead
| of No to avoid confusion, assuming that the company doesn't
| handle any PHI / CHD.
| sverhagen wrote:
| I use TurboTax. Before that I went to a big box tax preparer.
| They made me find, and bring, and drive back home to get the
| ones I forgot, all the documents they need, to essentially
| fill out their own equivalent of TurboTax, all the while me
| keeping an eye that they don't mistype something, because at
| the end of the day, I'm responsible. I spent more time than
| the tax preparer.
|
| This is pretty much the experience I expect. And I just don't
| see how this can be automated well (yes, I read the human-in-
| the-loop remark, but also the 15 seconds one), if there's
| such unstructured data, both on the input as well as the
| output side of this process. It seems to me you're just going
| to be renting out a glorified copywriter or editor.
| joetheone wrote:
| The ultimate success or failure of our business depends on
| our ability to get our NLP to deliver high quality answers
| and minimize the time our own internal reviewers need to
| spend on each questionnaire. We are making progress here
| every day, but still need to get better.
|
| It's totally fair to be skeptical that we can pull that
| off. I will say though that we are fanatical about NOT
| making this a business where we hire lots of humans to be
| reviewers. We'd rather fail than hire an army of low wage
| workers to do the soul sucking job of reviewing other
| people's questionnaires all day every day.
___________________________________________________________________
(page generated 2021-03-20 23:02 UTC)