September 14th, 2007
Bolting on Security
To build security in your project, you need to make it a consideration from the start. Bolting it on afterward is always a recipe for disaster, and unless you start over with a complete application rewrite you are likely to fail to secure your application in some subtle manner or another. If you are in a hurry to get Version 1.0 out to meet a limited opportunity or to meet a costly deadline to miss, it may be acceptable to a business to provide incomplete security in an application to get the product out the door. However, the application needs to have been designed for its security profile from the start or its security can never be completed.
For example, let us say I have an application that needs strong password controls to be secure, but the developers are running out of time to ship. For Version 1.0, I, as a decision maker for the business, might want to drop the password controls on the application. However, I must be certain that the password controls remain in the architecture design or else the application will end up deployed and used in a manner that would defeat ever trying to add password controls later. In particular, if I need a mechanism in the application that allows it to facilitate a user changing his expired password but I then deploy the application to users without any authentication at all, then I will likely find myself completely unable to add the strong password controls later. Firstly, I would need to somehow find out what users I have. Since none have ever authenticated, I have no idea who is even using the system! And now I am expected to add strong password controls?
This kind of thing happens all the time, but often more subtly. Many of the Microsoft protocols suffered security issues for years because they had to provide backward compatibility with older Windows desktops. I am not even certain to what degree the Windows 2003 servers protocols still suffer from many of those same issues, but I know that allowing traffic through a firewall on port 445 between Windows hosts is still something to be eyed with great suspicion. It is somewhat because that one port allows so many services: file sharing, printing, and authentication are the most common. But one can accomplish many of the same things on a Unix system over port 22 with SSH, and that port is not one that needs to be scrutinized nearly as much. Perhaps it is because the SSH protocol is much better documented than the Microsoft protocols, or at least much better understood by many more people. Perhaps it is because Windows systems are more often the targets of viruses.
Anyway, while I wish that every application could build in security in every release, I understand that a security-starved Version 1.0 will occasionally need to see the light of day. When you are involved in such a Version 1.0, just remember to keep security in your architecture. Allow it manifest in Version 1.1 or even Version 2.0 if necessary by keeping the goal in mind. Just do not expect that you can cut it out of your architecture completely and then bolt it on later—you cannot; the smartest people in the world have already tried, and we know how your story will end. Security cannot be bolted on as an afterthought.
September 15th, 2007 at 1:49 am
Security can never be bolted on afterwords, that’s true, but they security apparatus’s can be extended. Extension with security will never make you’re application more secure, that’s impossible, since how secure you’re application is is lowest common denominator.
What extension can do is provide user conveniences. Security in Windows 2003 at a protocol level is basically the same as 2000. Unfortunately both still by default enable support for the Windows 98 protocols. Windows 2008 changes this, but anyone can disable the Windows 98 protocols as is. So there we see subtraction adding to security.
At the same time, Windows 2003 and Windows 2008 make an administrator’s job much easier without reducing security. In an effective sense they raise it by making it more likely they’ll know how to or have time to make the appropriate choices. Though pure security may not change much, effective does. Of course, management may instead take the efficiency improvements and roll them into staff cuts or more work, or more process, but that is an age old cause of many problems.
As far as 445 goes, I’m not sure why it’s more highly scrutinized than 22. It may be a mistake that 22 isn’t more scrutinized. I’ve heard of plenty of attacks that originated here. In fact, most UNIX attacks I recall any details of did. Perhaps it’s just a community bias that would leave such blind spots.
I’d say in both cases, that these are need to know ports. Applications services should use ports that are easier to separately monitor and control if you’re approaching it from a security perspective. If you approach it from any other perspective they should use ports 80/443 exclusively to subvert all security restrictions. ;p
September 15th, 2007 at 5:45 pm
I agree port 22 is often not scrutinized as much as it should be, but having previously been at a company that did scrutinize some port 22 connections before allowing it in the end, I can say that with SSH the protocol and server binaries are documented to a degree that makes it possible to answer the hard questions during the scrutiny. This is not so with port 445.
And let us not even get started with how ports 80 and 443 are abused through firewalls!