3 ms·

That's an interesting turn of events. I was always told to use open source because it is safer (due to it being available publicly and all), but is it really sa

That's an interesting turn of events. I was always told to use open source because it is safer (due to it being available publicly and all), but is it really safer to expose every bit of detail to all gov, grey, white and would-be black hats? I have been told this is true ever since the dotcom boom but the elevated state of global hacking now has had me double guessing that assumption. But let's be honest here, the only other large-scale "trusted" enterprise vendors are Microsoft and Oracle and their developers are getting to be way more expensive than a typical "open-source developer". And do we really want to trust those who already betrayed us way back when? So what are the probable solutions here? Most niche (and sometimes widely-used) open-source libraries are notoriously buggy, lack documentation, and usually don't have more than a few real contributors. Hybrid model perhaps? But what does that really mean?

derekp7 9y ago
Have there ever been exploits in closed source software, including 0-day exploits? Most definitely. So you would want to use the highest quality software you can for a given purpose, but even that isn't enough. In reality, the answer is defense in layers. First layer -- if you are running on RedHat or CentOS, make sure to have SElinux in enforcing mode, and resolve any SElinux errors the correct way. Second layer -- separation of concerns. The same way that many businesses accounting operations are set up, you need to have a security breach at several layers at the same time to have an issue. This may mean that having the public facing web server talk to an app on an internal server, using a defined API, and that internal server only has firewall rules open for what is required. That internal app server then may have access to a database server in another security zone, making requests utilizing specific API patterns. At each level, have auditing software to look if any of those patterns change unexpectedly. Also, rate-limit the amount of data that can be pulled from the DB server on a daily basis -- this would mitigate a massive data dump situation. You could go even further, and have the web-facing side talk to an internal web server, after going through a layer that validates each request fits a given pattern. Of course this is a pain to keep updated as the app gets updated, but then again when the consequences of a security breach are high enough, this level of pain is worth it.
liberte82 9y ago
The closed-source model is essentially security through obscurity, which has been rightfully and thoroughly debunked as a legitimate practice. The right solution is to use the right tools for the job - which is often open source, but that doesn't mean using it blindly and not taking responsibility for it, and actively keeping up to date with exploits and patches.

derekp7 9y ago

Have there ever been exploits in closed source software, including 0-day exploits? Most definitely. So you would want to use the highest quality software you can for a given purpose, but even that isn't enough. In reality, the answer is defense in layers. First layer -- if you are running on RedHat or CentOS, make sure to have SElinux in enforcing mode, and resolve any SElinux errors the correct way. Second layer -- separation of concerns. The same way that many businesses accounting operations are set up, you need to have a security breach at several layers at the same time to have an issue. This may mean that having the public facing web server talk to an app on an internal server, using a defined API, and that internal server only has firewall rules open for what is required. That internal app server then may have access to a database server in another security zone, making requests utilizing specific API patterns. At each level, have auditing software to look if any of those patterns change unexpectedly. Also, rate-limit the amount of data that can be pulled from the DB server on a daily basis -- this would mitigate a massive data dump situation. You could go even further, and have the web-facing side talk to an internal web server, after going through a layer that validates each request fits a given pattern. Of course this is a pain to keep updated as the app gets updated, but then again when the consequences of a security breach are high enough, this level of pain is worth it.

liberte82 9y ago

The closed-source model is essentially security through obscurity, which has been rightfully and thoroughly debunked as a legitimate practice. The right solution is to use the right tools for the job - which is often open source, but that doesn't mean using it blindly and not taking responsibility for it, and actively keeping up to date with exploits and patches.