emremm

5 năm trướcdiscuss

Much :)

5 năm trướcdiscuss

Legal is often where agreements go to die. This is a tough one, and one that so far, we've opted out of until we can create a better process for doing so than what exists out there.

FWIW, I think pima (pima.app) does a pretty good job with this.

emremm

5 năm trướcdiscuss

Did you seriously just join HN to try and troll our Launch HN post? If so, I'm sorry, I hope you find better uses of your time. We're trying to solve a problem for founders and infosec teams alike. You're perfectly entitled to your opinions and judgements. Feel free to build something and share it with the community if you disagree with our approach. You can get in touch with us through our website if you'd like to try the product. Thanks!

emremm

5 năm trướcdiscuss

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!

emremm

5 năm trướcdiscuss

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

emremm

5 năm trướcdiscuss

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.

emremm

5 năm trướcdiscuss

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.

emremm

5 năm trướcdiscuss

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.

emremm

5 năm trướcdiscuss

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

emremm

5 năm trướcdiscuss

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)

emremm

5 năm trướcdiscuss

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.

emremm

5 năm trướcdiscuss

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.

emremm

5 năm trướcdiscuss

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

emremm

5 năm trướcdiscuss

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.

emremm

5 năm trướcdiscuss

inserts celebration gif here

emremm

5 năm trướcdiscuss

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.

Submissions

Launch HN: Stacksi (YC W21) – Doing Security Questionnaires, So Your Team Isn't

comments