Comment by Bhilai | Hacker News Reader

Comment by Bhilai | Hacker News Reader

I feel security programs are all about small nuances and there is plethora of generic advice out there. So, though this is good generic advice overall but I would have loved to see some more details.

> With this freedom, teams have the responsibility of securing their services, and ensuring security issues are fixed within an established timeframe.

How does the security team ensure that security bugs are being addressed. Individual engineering teams sometimes do not have visibility into the whole system and may think of an issue as low severity but combined with another bug in another system and its now a sev:high (SSRF type of things.) With individualized team dashboards, how does the security team handle this.

> The Security Team is currently rolling out metrics to our service dashboards tracking out of date patches, with an alarm to page the team when security patches are left unapplied. Giving the teams visibility into the risks lets them prioritize and schedule their patching, instead of relying on the security team to monitor patch levels.

How is the compliance to security policies ensured ? What if a team does not want to patch or the patch breaks their existing tools. A key element is these faced paced dev->deploy environments is exceptions. How are those handled and tracked ?

It varies widely from company to company. It depends on how dangerous of a bug it is as well as the exploitability; this determines the remediation period. Usually, very severe bugs like heartbleed or front facing deserialization are fixed within 1-7 days, whereas a CSRF in some random POST call could be 90/180 days depending on how a company treats less severe bugs.

You have a security guy assigned to keep track of bugs and is notified after the remediation window has passed. It's usually assigned to the person that found it because they are able to easily understand the issue and then verify the fix. They will confirm it has been fixed for all the machines it was found on, then close the ticket out. However, often bugs that are considered unlikely to be exploited will be kicked back, and long chains of emails between the security guys saying "Please fix this bug! I'm just trying to do my job", and developers saying "We have 0 dev cycles and a release coming up, not a high priority! Can't you just close it?"

This email thread goes on for weeks/months, and the security guys push the redemption period to help developers meet their deadline. It gets pushed back so many times that the security guys get sick of reporting it because they know it's a low severity issue, but still is a problem none the less. They push it up the chain of command and force the PM of the project sign off on the risk associated with what could happen if exploited, they almost always have it fixed immediately then it's closed.

Reply on news.ycombinator.com