Candy security
The title of this article is a term I discovered through the book of Kevin D. Mitnick, The art of deception, page 79. It means that the company has strong security perimeter with the outside world, but once you got through, nothing can stop you.
In movies and games, hacking into systems is often a fast and straightforward process. Find a PIN code digit by digit, and you can shut down a nuclear reactor, or transfer billions of dollars to your account, or... whatever.
There is no reason for the real life to be the same. In real life, hacking happens in steps. Someone finds a path injection which makes it possible to make an XSS exploit, which in turn makes it possible through a PC of an employee to gain access to security cameras. From there, the hacker achieves to monitor the LAN traffic, get a password of a guy who can log in to the server containing the root certificate; in turn, it makes it possible to decrypt the remaining traffic, hack into more machines, and through them, get to the target.
Unless companies do whatever it takes to simplify the job of a hacker.
One of the unfortunate facts is that most companies, including the large ones, are reasoning in terms of us vs. they, or, if you want, company vs. outside world. They pretend that the bad guy is somewhere outside, and a wall from the outside world will keep him outside indefinitely. This, in turn, leads to the belief that a magical solution to keep bad guys outside exists. It could be anything: a firewall, a router or a trusted system administrator.
This works well, until you find that the bad person is already inside.
Sometimes, it is a disgruntled employee or an insider who is paid by your competitor.
Believing that every employee can be trusted is so stupid that I won't waste my time commenting on this aspect.
Often, it is an employee who acts as a mule. He's not even aware that he helps the attack. It could be someone who was tricked through social engineering, or who brought an infected device to work, or who was a victim of an XSS vulnerability.
Companies believe that (1) teaching security to employees would help, or that (2) it is possible to remove this risk by giving to employees the devices which are tightly controlled by the company. Both assumptions are wrong. People are people, and there are always ways to screw up.
From time to time, it is someone who got through the firewall or a router or a trusted system administrator, by exploiting a vulnerability which has nothing to do with firewalls, routers or system administrators.
Every server and every application present an attack vector. A slight configuration mistake in a product you use or a tiny bug in a code you write could be exploited to get in. Given, on one side, the complexity of the systems used by companies, and on the other side, the lack of skills from the IT personnel, it is not surprising to find that there are dozens or hundreds of vulnerabilities; and it takes only one of them to get inside.
Since the company focuses on the separation between we and them, the effort goes into securing the frontier. Once the bad guy is inside, he is presented with amazing opportunities. Such as do an SSH to the log machine and get rid of the logs incriminating the attacker. Or have fun with your backups before playing with your databases.
For the past weeks, I was strengthening the security of specific machines. For instance, a bunch of application servers are now using TLS between them and the reverse proxies, and authenticate those reverse proxies by using client-side certificates. This means that when some machine, such as the DNS server, is compromised, an attacker would still be unable to perform MITM attack, or to sniff the traffic, or to pretend to be the legitimate client. To compromise the application server, an attacker would need to either gain root access to the reverse proxy, or find a configuration error in Apache to bypass certificate validation.
There were times where the same server would host the application, the database and a dozen other services. Compromise the server, and you get access to everything. Now that different components are hosted on dedicated machines, there is really no need to have the same level of security as before. Gaining root access to the database server should give you the ability to trash the data, but it shouldn't make it possible to use SMTP or change the application logic in order to attack the users or monitor the surveillance cameras.
This is why I strongly encourage the teams who adopted the microservices approach to ensure every service they release is available through internet. Knowing that the service is expected to be accessed only by trusted personnel gives a false sense of security: most developers will take advantage of that in order to avoid working on complex security subjects. However, when you know that the service can be accessed from anywhere, you start thinking if the feature you're implementing could be exploited by a malicious person or if it is really necessary to configure the server so openly.