Change Details

Stick with me through this rather unfortunate tale. Currently if a malicious actor gets on our network they are able to listen to some unencrypted traffic that is going over it to internal services. The problem for us is that LDAP auth is used for everything in our office and some systems do not securely transfer those credentials. In our effort to be super secure™ we only allow SSH access to repos so all users must first add a public key or generate a new key. If the attacker is able to glean a users LDAP information they can log in and add an SSH key and pull down our repos. Although sending an email out when an SSH key is added will not eliminate this issue it will alert the user to an action that they did not take and allow the user to quickly revoke the key as well as quickly enabling us to perform some kind of super corporate postmortem.

We can improve the ability of installs to react to and recover from attacks that involve session compromise by emitting notifications when high-security actions are taken. The primary line of defense against this class of attacks should be proactive MFA, but improved reaction and recovery mechanisms can provide greater confidence and defense-in-depth. In particular: - Account objects like SSH keys should use transaction infrastructure and have a full create/edit/delete log like most other objects do. There is no technical or product reason that they do not today. - High security actions, including modifying SSH keys, should tie into new notification infrastructure which can emit email today and SMS (or other out-of-band, high-urgency) notifications in the future. We don't need to build this today, but should put some infrastructure in place to anticipate it. - The existing primary email change notifications should likely fold into this new security event infrastructure. - (Possibly also reasonable is emitting security event notifications when an install exceeds an action rate limit? This is not normally a high-security action but falls into the same general class of sensitive events. I'm not sure if all of these overlap with high-security actions already or not.) --- //Original Report// Stick with me through this rather unfortunate tale. Currently if a malicious actor gets on our network they are able to listen to some unencrypted traffic that is going over it to internal services. The problem for us is that LDAP auth is used for everything in our office and some systems do not securely transfer those credentials. In our effort to be super secure™ we only allow SSH access to repos so all users must first add a public key or generate a new key. If the attacker is able to glean a users LDAP information they can log in and add an SSH key and pull down our repos. Although sending an email out when an SSH key is added will not eliminate this issue it will alert the user to an action that they did not take and allow the user to quickly revoke the key as well as quickly enabling us to perform some kind of super corporate postmortem.

We can improve the ability of installs to react to and recover from attacks that involve session compromise by emitting notifications when high-security actions are taken. The primary line of defense against this class of attacks should be proactive MFA, but improved reaction and recovery mechanisms can provide greater confidence and defense-in-depth. In particular: - Account objects like SSH keys should use transaction infrastructure and have a full create/edit/delete log like most other objects do. There is no technical or product reason that they do not today. - High security actions, including modifying SSH keys, should tie into new notification infrastructure which can emit email today and SMS (or other out-of-band, high-urgency) notifications in the future. We don't need to build this today, but should put some infrastructure in place to anticipate it. - The existing primary email change notifications should likely fold into this new security event infrastructure. - (Possibly also reasonable is emitting security event notifications when an install exceeds an action rate limit? This is not normally a high-security action but falls into the same general class of sensitive events. I'm not sure if all of these overlap with high-security actions already or not.) --- //Original Report// Stick with me through this rather unfortunate tale. Currently if a malicious actor gets on our network they are able to listen to some unencrypted traffic that is going over it to internal services. The problem for us is that LDAP auth is used for everything in our office and some systems do not securely transfer those credentials. In our effort to be super secure™ we only allow SSH access to repos so all users must first add a public key or generate a new key. If the attacker is able to glean a users LDAP information they can log in and add an SSH key and pull down our repos. Although sending an email out when an SSH key is added will not eliminate this issue it will alert the user to an action that they did not take and allow the user to quickly revoke the key as well as quickly enabling us to perform some kind of super corporate postmortem.