Why do Quick-Start guides disable security?
There is an old saying that says "you'll never get a second chance to make a first impression."
If you've ever installed a piece of software, you know the drill of every "quick start" guide: disable the firewall; disable SELinux. Imagine the first impression for a security professional that has seen this en mass. We live in a world of security as an afterthought in development.
When we assume that security is too hard for the average consumer, and the enablement of basic security features are relegated to a security and hardening chapter buried deep in a thick administrative guide, software will never be created with a responsible production use mentality. The goal of every developer is to build something others will use, however the necessary security steps to avoid the dangers of software consumption never resonate until the last minute .... or until it's far too late.
Let's start with the first grave error: disabling the platform firewall. In the haste to get someone to just use a piece of software, the most important piece of the puzzle is ignored: ports and protocols. How does the software communicate internally and externally? What type of traffic and how much traffic is expected to pass through these internal and external interfaces? Rarely if ever are these questions asked at the onset of the development of a piece of software. It is typically addressed at the 11th hour - right before launch. Software producers scramble in an attempt to document and discuss production use cases, while never testing, running, or bench-marking under such conditions.
The software vendor landscape exacerbates the problem. Hundreds if not thousands of dependencies are integrated together in solutions that have never identified the total port and protocol knowledge to build a proper firewall configuration. The software vendors priority of just "getting it to work" leads to asking permission from security teams to approve a solution for public consumption with little knowledge of the software dependencies and the ports/protocols they use. Have you ever requested a list of ports and protocols from a software vendor, and paid attention to how much time it takes to get an answer or diagram, and how incorrect or antiquated it becomes so quickly? Nevermind the possibility of getting a clear answer on the traffic patterns for implementing a deny by default policy, or protecting the software from a denial of service flooding attack via rate limiting. We would never send a child to a school if we had to sign a waiver that there would be no adult supervision once children were dropped off, yet we choose to do this with the infrastructure that's supposed to protect our data every day.
The second error: disabling SELinux. For those unaware of Security Enhanced Linux, it is a set of kernel modules that establishes Mandatory Access Control (MAC) policies that confine userspace applications, system services, file access, and network resources to protect a service from impacting the integrity of the entire system. While rushing to check code in, disregarded are the boundaries developers might cross, memory they might seep into, and buffers they may expose to exploit. What read, write, execute permissions are actually necessary? What sockets need to be open/connected by which service and only under what port? Further questions brushed aside in the expediency of delivering "something" and almost never documented or referred to in administrative guides.
As this worsens with the plethora of dependencies flooding into the software vendor solution, chaos ensues with the flood of AVC denials and the protection is disabled. While the platform is already designed to leverage confinement, the new tenants force the abandonment of the ability for the platform to protect itself. We would never allow the antics of a single inmate in a prison to force the policy of the prison to allow all inmates to roam freely. Yet we choose to do this with the infrastructure that's supposed to protect our data, and then we wonder why breaches happen daily.
CHAaSM gives its clients the power to control these and other critical security issues in the modern datacenter. Contact us to find out how. Info@chaasm.com