3 ms·

In theory I totally agree with the concept of using secure defaults. In practice, however, I have seen far too many developers spend hour after hour trying to

In theory I totally agree with the concept of using secure defaults. In practice, however, I have seen far too many developers spend hour after hour trying to unwind a byzantine labyrinth of iptables and strange network configurations, weird firewall rules and corporate policies, never mind mangled DNS, to think that the correct solution is merely "secure defaults". At the end of the day, developers get paid to "make it work" and unfortunately that strongly incentivizes the "open by default" configuration mindset.

mtgx 10y ago
Maybe developers should get paid "not to put us in the headlines with 1 billion accounts breached".
- user5994461 10y ago
  Maybe developers should care about not having their companies in the headlines instead of just pushing things out as quickly as possible.
cookiecaper 10y ago
Most developers past a certain seniority level know better than to run on a production database on a public interface without at least setting up good authentication. I think in many cases, it's just an issue of something slipping through the cracks. A few example scenarios where this can happen: one may open a port temporarily in testing before something goes live and forget to close it back up. Legacy applications may be dependent on certain services at certain ports and it may not be trivial to change those, or even add authentication to them. The whitelist rules allowing communication can get mangled or misconfigured, especially if the legacy application's IP jumps around; in frustration, an admin may set the rules too wide to try to encompass all potential IPs, assuming that no one in the same /16 is going to try to break in soon and they'll come back and fix this in like a week or something. One may spin up a test instance into a wide-open security group and assume that someone else is going to come through and sweep it up, and before you know it that test instance is hosting real data and no one has tried to clamp it down, or that firewall rules for that port are not necessary because the authentication/whitelisting will occur on the software side, and then fail to set that up correctly, or run an insecure version of the software. There's that old saying: "A person isn't stupid; people are". The constraints of the business often make it so that compromises have to be made and what we'd consider a "good solution" is politically intractable. No one likes that, but it's the environment many of us have to work in, like it or not. All we can do is scream at the wall until at least one exec goes through a traumatic security event. It usually takes a significant breach to scare the exec team straight.

mtgx 10y ago

Maybe developers should get paid "not to put us in the headlines with 1 billion accounts breached".

user5994461 10y ago
Maybe developers should care about not having their companies in the headlines instead of just pushing things out as quickly as possible.

cookiecaper 10y ago

Most developers past a certain seniority level know better than to run on a production database on a public interface without at least setting up good authentication. I think in many cases, it's just an issue of something slipping through the cracks. A few example scenarios where this can happen: one may open a port temporarily in testing before something goes live and forget to close it back up. Legacy applications may be dependent on certain services at certain ports and it may not be trivial to change those, or even add authentication to them. The whitelist rules allowing communication can get mangled or misconfigured, especially if the legacy application's IP jumps around; in frustration, an admin may set the rules too wide to try to encompass all potential IPs, assuming that no one in the same /16 is going to try to break in soon and they'll come back and fix this in like a week or something. One may spin up a test instance into a wide-open security group and assume that someone else is going to come through and sweep it up, and before you know it that test instance is hosting real data and no one has tried to clamp it down, or that firewall rules for that port are not necessary because the authentication/whitelisting will occur on the software side, and then fail to set that up correctly, or run an insecure version of the software. There's that old saying: "A person isn't stupid; people are". The constraints of the business often make it so that compromises have to be made and what we'd consider a "good solution" is politically intractable. No one likes that, but it's the environment many of us have to work in, like it or not. All we can do is scream at the wall until at least one exec goes through a traumatic security event. It usually takes a significant breach to scare the exec team straight.