The problems with Internet security and the “Default Deny” stance
http://www.flickr.com/photos/imuttoo/3935553419/
On the Securosis blog there has been two posts recently (here and here) about security and taking a default deny position as the best approach to securing a particular service or network. At a high-level, you block every port / service / protocol that is not defined as being required and then wait to see who complains. As people complain, you investigate the complaints and figure out what policy changes are required and make them. The end result is a secure policy allowing only the required access. At least that is the theory.
I believe that “default deny” is a excellent security goal. That being said, obtaining that goal has to be weighed against other objectives. Often, I find many security professionals proclaiming that ‘default deny’ must be deployed, everyone has to make it happen, regardless of the cost to the company, regardless of the risk to the project. The general sense is that if default deny can not be completely reached, the project should not go forward or should be held up.
This sets a very adversarial tone for everyone involved in the project. It creates a very binary choice, “you are either with us or against us”, there is no in between. While this is great in the movies, for the most part, it is not real life. That positioning breaks down communication, it puts the team on the defensive, and it creates a environment where the team does not want to talk, work, or involve the security experts. They are seen as unreasonable and unrealistic. Have you ever been ordered by law enforcement to “stand back”, “show me your driver’s license”, or told you can not cross this line with no explanation as to why? How does it make you feel? Did this attitude earn your respect or lessen your respect for them?
The default deny stance is easy, minimal work, and most importantly risk free for the security members of the team. While that is not a bad thing, it often increases the amount of work for others on the team as well as their responsibility. In a simple case, if on a project by blocking port 1234/tcp, I force the team to have to re-program the socket interface on the application, which in turn generates a code review, which then generate more work for the Q/A team. If the team overrides the security experts and says we are not doing that work, the security members can now claim they did their part, the team did not listen and so if there is a breech it is not their fault. This does not promote a collaborative team environment.
Humans naturally fear the unknown. It explains why as a society we overreact to terrorists that attempt to blow up planes or all rush to get the latest vaccine for a new strain of bacteria. In both cases we are more at risk of death from being hit by a car in our daily travels yet we show no fear that will occur. This irrational fear is re-enforced in courses and books on security. The result is we see “default deny” as a valid and only solution. The result is security professionals promoting often with a very hard line just that.
“Default deny” ideally assumes that their is an understanding of a service or application in its entirety. From the end user interface right down to the bits that traverse the wire in detail under all conditions. Years ago this was possible, however todays applications are rarely the result of one teams code from the ground up. APIs of third party vendor systems are called, third party libraries are used for communication, storage, authentication and many other functions and features. Today, it is unreasonable to assume that a particular team will understand everything at all levels given the nature of how services on the Internet are built and deployed. Security professionals are correct in pointing out this is a risk, however it is a risk that is not going to go away and security models have to adapt to manage and minimize the risk. A simplistic “Default deny” does not accomplish this.
I have consulted for several very large tier 1 service providers. The default position tends to be a “Default permit”. From there they determine what is ‘bad’ and craft security policies to deal with and minimize the risk. While enterprises can afford to take a more “Default deny” approach, this will become more and more difficult. As services are more and more build by external vendors, use third party APIs and libraries, interact more and more with cloud computing, permit access on PDA devices for services, and the many other services available and yet to be available a different approach is needed. “Default deny” is a great goal for security of a project, however it needs to be prioritized with and assessed from a risk perspective with other goals of a project.
Do you think that the security community of today needs to change their approach, and behaviour?
I have always taken a minimalistic approach – ask what and why something is what it is and how can it be misused… if it is not needed and can be misused, eliminate it or work to minimalize the vector of “attack”, log un-expected, and follow up.
When I was in highschool… we had a print ballance system. The printers were shared on a Novel server which enforced how many printouts it issued. All the printers / servers were fully routeable and I discovered you could print directly to the printers print server and bypass the queues. Effort was spent on preventing the mis-use of the printers when used as expected, but no effort was given to the un-expected use.
In order to work and be in school, I had to be able to administer machines remotely from the school network. What I did was run an SSH server on port 443 on my home network. I would use the mindterm java ssh applet to allow me to tunnel VNC and RDP to whatever I needed access to. Once I even used a reverse tunnel to connect the a local socket on my SSH server to the school printers queue so that I could print my homework from my home machine to the local printer.
What the school needed was a tough writen security policy, a log of all un-expected events and an administrator who looked at the logs and was able to give me hell when he caught me doing things I was not supposed to. They may not have been able to catch my tunneling but they could have tracked my printer misuse and found out the other. I never did anything disruptive… but the only thing that stopped me was my character.
@JaymeSnyder
Minimalistic approach is the right idea I think. What bothered me about the articles I was reading were:
a) the general attitude of “stupid users” and we in security “know best”. I see that a lot and I hate it. I feel it is one of the main reasons the I.T. and security industries are viewed the way they are as ’separate’ from the real business.
b) Some of the articles are not very realistic. Like I said, try walking into a major financial institution, deploying a security service under tight time-lines where you had to Q/A the big things and hope for the best and telling the client that their major financial services that make them money might experience some issues till the security is figured out and they will just have to deal with it. Doesn’t work. Security is a risk assessment, like crossing the street or buying stocks. If opening port xxx/udp allows a major service to function, there are no known serious vulnerabilities, do you just block it because someone might attack it in someway? Try and sell that to the executives. I have never seen it work successfully and it only damages your reputation as a consultant.