3 ms·

Nowadays, I tell developers and product owners around me that cybersecurity is basically about 'doing IT well.' There tends to be this attitude at my $BIGCORP

Nowadays, I tell developers and product owners around me that cybersecurity is basically about 'doing IT well.' There tends to be this attitude at my $BIGCORP that its a box you tick or its something you do to get done - when in actuality its a way of living. The majority of exploits take advantage of basic mistakes in configuration or code. Most of those issues are well understood, which is why you've seen this rise of detection tools and automation. Big hacks nowadays are necessarily a daisy-chain of exploits, because we're better at security at certain layers. But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.

d4mi3n 5y ago
I think this is a good take, though depending on your domain and the maturity of your security program you eventually reach a point where the blast radius from misconfiguration becomes manageable through mitigations you have in place. Past that point, it’s daisy chains of exploits as you say. It’s not uncommon for sophisticated attackers to sit on a number of 0-day exploits until they find a venue to deliver them. This is one of the reasons the Log4j announcement was scary—it opened up a venue to a wide variety of applications and infrastructure that were previously protected through other means. > But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release. I’ve found a big part of a good security program is helping an organization calibrate it’s actual risk appetite. If business ending events are known and understood, everyone should know in what cases a security issue becomes a blocker.
xkcd-sucks 5y ago
> There tends to be this attitude at my $BIGCORP that its a box you tick or its something you do to get done - when in actuality its a way of living. In many companies, it is just a box to be checked (by a separate Compliance department who does not have access to the codebase only emails to designated contacts in Engineering), and thinking about it beyond that will merely impede one's ability to achieve designated objectives. For anyone actually "making stuff" in this kind of environment, security is (at best) documenting having followed procedure to deflect blame if something bad happens.

d4mi3n 5y ago

I think this is a good take, though depending on your domain and the maturity of your security program you eventually reach a point where the blast radius from misconfiguration becomes manageable through mitigations you have in place. Past that point, it’s daisy chains of exploits as you say. It’s not uncommon for sophisticated attackers to sit on a number of 0-day exploits until they find a venue to deliver them. This is one of the reasons the Log4j announcement was scary—it opened up a venue to a wide variety of applications and infrastructure that were previously protected through other means. > But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release. I’ve found a big part of a good security program is helping an organization calibrate it’s actual risk appetite. If business ending events are known and understood, everyone should know in what cases a security issue becomes a blocker.

xkcd-sucks 5y ago

> There tends to be this attitude at my $BIGCORP that its a box you tick or its something you do to get done - when in actuality its a way of living. In many companies, it is just a box to be checked (by a separate Compliance department who does not have access to the codebase only emails to designated contacts in Engineering), and thinking about it beyond that will merely impede one's ability to achieve designated objectives. For anyone actually "making stuff" in this kind of environment, security is (at best) documenting having followed procedure to deflect blame if something bad happens.