Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Try Vanilla Forums Cloud product

Security Tracker

x00x00 MVP
edited November 2014 in Feedback

I believe I mentioned this in passing with @businessdad‌ and @Linc‌

In my personal opinion it would be a good idea to have a security tracker.

Given the sensitive nature of security issues as has been mentioned by Linc, and I agree, security issues need to be submitted confidentially amongst trusted parties.

This has be happening quite well recently. However there lacks a formal process, and critically a tracker to keep track of outstanding issues, and interface for which to do it.

Not only is important that security issues are address in a timely manner. It is also import to be seen to addressing these issues (with divulging the sensitive materials).

I'm not proposing a bespoke solution, but to to search for existing software that would fit the bill. Something that allows the person who has found the security exploit to submit that information, to be shared.

Where I think the being seen to care would fit in, would be (perhaps controversially), to grade the open security issues and then declare then information publicly. I understand this is a big deal, but on the other hand it provides confidence that things will be dealt with, and I think they will be dealt with in a timely manner.

This shows trust, and this should be hopefully reciprocated.

Also formally making people aware they need to update, in core would be a good feature to have eventually.

grep is your friend.

Bleistivt

Comments

  • businessdadbusinessdad Stealth contributor MVP

    I think it would be a very good idea. It's always a pain to admit that there are holes in a product, but keeping the users informed (without disclosing the exact details) shows sense of responsibility. It would also give the reporter the feeling that the contribution was acknowledged and is being taken care of. Another good side effect is that such disclosures would be less likely to appear in places like ExploitDB, which usually contain all the steps to reproduce them, available publicly.

  • Good points

    grep is your friend.

  • Any suggestions as to software?

    grep is your friend.

  • x00x00 MVP
    edited November 2014

    You could use Asana. Have an external form. Then use the API to create a task, and a guest user with task only permissions.

    https://asana.com/guide/learn/basics/permissions

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff

    Good input, thanks. I'm raising this with the rest of the team. My preferred solution would be a private GitHub issue tracker.

  • I don't know enough about private GitHub to know how it would work. Worth investigating anyway.

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff

    @x00 said:
    I don't know enough about private GitHub to know how it would work. Worth investigating anyway.

    A normal repo, just without the code and with a whitelist of users who can see it.

  • The problem with that is they can see all the issues. You might not want that.

    grep is your friend.

  • Or would you handle issue submission some other way?

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff
    edited November 2014

    @x00 said:
    Or would you handle issue submission some other way?

    I would continue to handle submission via email as we currently do. The issue tracker I see as purely organizational. I don't want anyone needing to create special accounts to tell us about a security issue. Some of those folks don't exactly want to be known.

  • Yes but can they submit to the tracker? I'm not saying they want to to be know but their anonymity is their purgative.

    It somewhat defeats the purpose of having a tracker, if nobody is aware of it.

    The reason for suggesting the tracker was to foster cooperation, in a sand-boxed way. Not to to tell you how to mange projects internally.

    grep is your friend.

  • Also if I submit a security issue, it reasonable to comment, help, make suggestions, step to repeat, etc.

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff

    @x00 said:
    The reason for suggesting the tracker was to foster cooperation, in a sand-boxed way. Not to to tell you how to mange projects internally.

    I think the proper way to cooperate would be over email to support at vanillaforums.com. Having an additional management system with its own login that's only used when a security issue is reported sounds like managerial overhead that will go unused when the rubber hits the road.

    Also if I submit a security issue, it reasonable to comment, help, make suggestions, step to repeat, etc.

    You had a bad experience reporting via private message here, and I apologize for that. We now run reports thru our support team to make sure there is another group keeping watch and making sure the developers respond in a timely way.

    The purpose of the tracker, from my perspective, is simply to increase visibility between developers and make sure a process is followed. Better communication is what we need, not another piece of special software.

  • I don't have a problem cooperating over email, but you can send that email to the tracker, or invite an email on a issue. Therefore it is kept together rather than risk getting lost.

    I wasn't suggesting separate logins, necessarily.

    grep is your friend.

  • People who summit security report are valuable to you, including them in the process is no bad thing.

    Then eventually you could invite them as a security team contributor.

    The sense there is no process is a sense of futility from the outside.

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff
    edited November 2014

    The emails to support are collected in a private category on the .com Help forum, so they do get collected & managed as 1 ticket already that has an open or resolved status. So, I think maybe we're already doing what you're requesting as far as coordinated feedback to the reporter now. My thoughts were about how to better internally manage those issues because I don't think we're quite "there" yet.

  • So that user can follow the progress of the security issue? the one that submitted the issue?

    Why not create a github issue from it. Then use the webhooks to post back to the ticket.

    I think the person that submits the issue has some right to know what step you are taking on the issue, especially if they have provided detailed information themselves. They may be able to assist further.

    grep is your friend.

  • In other words they share, you share. Give and take, in private mutual conversation.

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff
    edited November 2014

    I think that is the responsibility of the developer handling the security issue and it's at their discretion to reveal information to the reporter and work with them depending on who they are.

    What if they report vulnerability X, and that causes us to uncover more serious problems Y & Z when we start investigating the issue? I don't want to leak further problems until they are solved.

    Support tickets are a good way to close the feedback loop to the reporter. I do not, however, think reporting a security issue gives someone the automatic right to sit in on our entire process for fixing it.

  • I let you be the judge of that, but is some cases it might be worthwhile depending on the nature of the report, and what they have to offer.

    grep is your friend.

  • From what you described it is on a single ticket? Would then not make more sense to open a ticket each issue?

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff

    Emails to support get put into a ticket (really just a discussion that has an open / resolved status). The trouble is that any replies go to the reporter, so we don't tend to collect internal information on them, and they disappear into 1 developer's inbox (whoever takes it). Hence proposing a private issue tracker to run alongside it for actually working thru the issues and then reporting back via the ticket.

  • ok that makes sense, so each report still get a ticket. Can they comment on the ticket, using that email?

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff

    Yes, and any reply by them re-opens it regardless of whether it's been marked resolved previously.

  • Nice. I think this need some awareness. Even on the OS site.

    grep is your friend.

  • You might create a specific support ticket just for security. This could automatically create the github issue opaquely. Misplaced ones you could use the manual create gitub issue.

    grep is your friend.

  • LincLinc Director of Development Detroit Vanilla Staff

    I like letting it go into the main support queue and letting the staff deal with it manually so that there is maximum visibility internally. I could see a security-only email/ticket queue being shunted to developers who are overburdened.

    I did add a note to the README a few weeks ago to specify that security issues should go to support at vanillaforums.com.

  • Nobody reads the README :p

    grep is your friend.

  • One more question

    If you are going to have an internal private repo using the issue tracker for security issues. How about the idea of using webhooks so when you label an issue, it would update a public record of how many issues of that label are open?

    https://developer.github.com/webhooks/#events

    grep is your friend.

Sign In or Register to comment.