If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.
Security.txt
21–30 of 148 posts
Re: Security.txt
#22As an operator of many websites... I don't want more emails from "Security Researchers" who want $100 to tell me the obvious such as, "Login form should be rate-limited" or "emails can be enumerated using password reset form" and the like...
Instead, we should have a central vulnerability repository that is open-source, standardized, public, and transparent. This repository should vet vulnerability reports before contacting the software owner prior to disclosure.
Re: Security.txt
#23I seem to remember suggesting jobs.txt as a listing for a company’s open positions. Someone even made a site promoting the idea. What I mean to say is that the concept of a domain is much deeper than html, and we use it so shallowly. The web is distributed and simple if we want it back.
That's interesting. I love the idea of sites exposing various types of data through plain text files with well-known names. Kind of like (a vastly simplified) RSS feed, but for whatever. Or something vaguely like Gopher sites, back in the day.
But then, the company would want to brand it, and the marketing team would want to track views, and the sales team would want some kind of call to action, and the product managers would want to make it cross platform and internationalized. And suddenly we're back at something that looks like HTML. sigh
Re: Security.txt
#24Earlier quoted context omitted.
If you're one person with a vanity domain, maybe. If you're running a business that operates mail, it's mandatory.
abuse@: yes. postmaster@: no. If people have trouble contacting a business by email, they don't try to use email to fix the problem. They very sensibly go to the web site and try by phone or Twitter or some other medium that isn't the one that isn't working.
I always try postmaster@ first, when reporting mail problems.
Unfortunately, I'd guess that ~75% of the domains I try to contact about that don't have it. (And only slightly better with abuse@, for that matter.)
And then there are the shops who seem to believe that sending mail from bad addresses and publishing no public email addresses for anything is cool. I'm not fond of this solution, but have started considering them spammers and blocking them entirely. (I don't particularly care about them - if they want to send email to my systems they can put their big-pants on and join the rest of the responsible operators; I just don't like seeing services balkanizing like this.)
Re: Security.txt
#25....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.
> If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything . Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's origina…
> if you are catching spam to abuse@ or postmaster@, well, do the math.
Well... the most recent time I've seen abuse@ mentioned, it was Hetzner looking at fake IPs on DDoS traffic and spamming abuse complaints at the wrong people. https://www.reddit.com/r/discordapp/comments/70dwa6/ip_banne...
Re: Security.txt
#26The first thing every attacker will do: replace security.txt
Re: Security.txt
#27Earlier quoted context omitted.
> If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything . Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's origina…
> if you are catching spam to abuse@ or postmaster@, well, do the math. Well... the most recent time I've seen abuse@ mentioned, it was Hetzner looking at fake IPs on DDoS traffic and spamming abuse complaints at the wrong people. https://www.reddit.com/r/discordapp/comments/70dwa6/ip_banne...
Hetzner is a long-running social experiment to frustrate other Internet network administrators trying to hail it on all frequencies, so that sort of thing doesn't surprise me. We should all be better actors on the Internet, as this thread underscores, and it's just too bad you sound like you're wearing a sandwich board when you advocate for it. The incentives don't line up with running a business, much like with IPv6 and BCP38.
It'd be cool if we could throw RADb, PeeringDB, RFC 2142 contacts, WHOIS data, the routing table, courtesy phones, spam blacklists, and all the other tools available to administrators in a blender and come up with a nice, centralized way to instant message the right person with root at another Internet company for any possible scenario from any possible identifiable resource involved in the Internet without having to possess the tribal knowledge you pick up after doing it a while. Such a facility doesn't line up with the decentralized nature of the Internet, which is why I think it hasn't happened yet. How would you talk people into using it, too? There's a critical mass problem. I've always wanted to build exactly that thing, but I fear nobody would use it.
Until that exists, it's important to watch your abuse mailboxes. Only point I'm making. The Internet moves fast.
Re: Security.txt
#28I can't seem to find a definition of "Partial disclosure" on either the website or the IETF RFC draft.
Yeah, I was looking for the same. All the draft [1] says is:
2.5. Disclosure:
Specify your disclosure policy. This directive MUST be a disclosure
type. The "Full" value stands for full disclosure, "Partial" for
partial disclosure and "None" means you do not want to disclose
reports after the issue has been resolved. The presence of a
disclosure field is NOT permission to disclose vulnerabilities and
explicit permission MUST be saught where possible.
[1] https://tools.ietf.org/html/draft-foudil-securitytxt-00#sect...
Re: Security.txt
#29The first thing every attacker will do: replace security.txt
Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites...
Changing things is how you get detected.
Much like that recent thread where John Kelly brought his phone in to IT because it wouldn't update and they found malware. That's an obvious failure in any "APT" hackers guide.
This isn't like modifying .bash_history to hide malicious behaviour (or worse removing command auditing entirely when it's a potential company/personal policy to activate it on all machines).
Re: Security.txt
#30so i should abandon my /return-policy.txt standard?
you're all idiots.