The Microsoft experience reminded me of the time when security@apple.com went to the building security office, who just quietly deleted bug reports. Poor processes amd communication is one of the worst classes of security problem.
Microsoft used to have a group, Trustworthy Computing (TWC), that was where all the security expertise lived. TWC was destroyed in 2014. From the outside, it seemed like that was the point where the reporter/outside security engagement story stopped, because the people that held responsibility for it Microsoft wide were either fired or re-orged into a role where they didn't have broad authority any more. Now, you get stuff like this, where people on the "security" group (which is squirreled away in a totally different part of Microsoft) don't have visibility into the Edge bug tracker any more.
Internally, Microsoft is organized a lot like the Federal government, only worse.
One can see a rationale in not having a security group - every team should have security focus (eg by having expertise & champions within each group). You can't tack on security, you have to build it in.
I disagree - the motivations of the security group and the product group are different. If the security team is under the product team leadership, the security team is disincentivized to interrupt a product launch due to a security issue, because they're rewarded by shipping a product, not making it secure. Really, you should have both: you should have a security team that sits with the product team and works with them through the lifecycle of the product, and has continuity (i.e. it's the same security people with your product team through the life of the product, mostly), but that security team reports to different management and has their promotions, bonuses, etc. handled by a different leadership chain than the product team.
Last time I reported a security issue to Microsoft I got reply same day and a confirmation that it was in fact an issue some day later. And then a few days later they notified me that my report was eligible for a bounty (I didn't have to ask).
This was the opposite experience of my previous report where the bug was acknowledged 9 months later and then fixed another 3 later.
I wonder if it just depends on whether your report ends up in a escalation path with lots of busy people.
product-security@apple.com is the real one these days.
Of course, this gets me thinking, what kind of super powers do these addresses have that allows people to send potentially malicious things there to be disassembled and analyzed? I suspect they are quarantined in some way, but it would be interesting to hear from the ops sec crowd how this gets handled.
Often badly, I remember Tavis O crashing Symantec's email server when sending an exploit using standard username/password combos, it unzipped it and crashed itself.
Yes – I even got a nice email from someone apologizing about that and explaining that they were trying to get the security@apple.com people to at least forward messages when I did a full disclosure release after not receiving a response.
> they were trying to get the security@apple.com people to at least forward messages when I did a full disclosure release after not receiving a response
That sounds a bit dysfunctional on Apple's part that they can't exert that kind of control over their own employees for an issue with potentially enormously negative consequences.
That sounds a bit dysfunctional on Apple's part that they can't exert that kind of control over their own employees for an issue with potentially enormously negative consequences.
I'm not saying it isn't dysfunctional, but it sounds like every single large company I've ever worked with or for.
Especially when "security" is provided by a third-party security company.
Our IT people were apparently incapable of creating a way to receive emails which didn't flag zip or tar files as security threats and block it. We've had to sometimes ask people stick things in dropbox and share it with us that way.
We've had similar issues with people submitting code for remote interviews.
That seems like a better approach to me. With email, you're at best exposing a disk-filling service to the internet and most likely looking at exploits running on servers with a fair amount of interesting data. There's also a fun race condition between the time a file is scanned and when someone opens it, which isn't as solved a problem as it should be.
With requesting that people send you a URL, you're in control of when and where it's accessed and things like Safe Browsing are visible to the recipient.
