(2010-06-17) Chasing waterfalls

(This text was originally published in the EZSecurity News letter for december 2009)

Chasing waterfalls
Design is not optional if you want to save money and keep your hair. Ive seen so many systems rushed into production during my years in the it-industry. And the outcome has always been the same: unforeseen consequences, problems and huge expenses. I like to think of it as starting with a small river and ending up with a water fall. Every corrective action along the line becomes more and more expensive. If you factor in man hours and downtime, maybe the increase will even be exponential. The good news is that most design work can benefit from reviewing best practices and to find the easiest possible solution. Ive seen many over-engineered solutions that try to do everything. They demand enormous amount maintenance effort.

I try to sum it up in a few words:
First ask yourself what is the effect you want to achieve. E.g. I need to be sure my data is secure from tampering and disclosure while enabling me to send it to selected people.

Then ask the question What do I need done?, and answer it without mentioning any technologies. E.g. What do I need done? I need to send text files to a person and knowing that that he/she is the only one that can read it. You really shouldnt write things like I need to use SFTP to transfer a PGP-encrypted file to a UNIX server. Consider the needs and then the methods.

Then define the goals of the design. (What must it do? What is not permitted? Who is the user? Have I understood their needs? Have THEY understood their needs?)

Talk with people.

The road is long from here on and there are thousands of books, courses and seminars outlining the process in detail. I cant do that here. But my point is that those questions are seldom asked. Ive heard suggestions STARTING with we should use syslog to send out logs to a central server. The proper response is Why? What are you trying to do? Are you trying to solve a problem or increase security? Why syslog? Who is it for? When must it be done? How much can it cost? What happens if we dont do this? What could happen if we do?. At this time, the person asking the question really gets confused. They already have an idea of what theyre trying to do, and theyve thought out a plan. But they dont have a design. And as an infrastructure technician I used to take the suggestion and rush of to work, bumping into problems all along the way.

The most common problems I see with new systems include:

Lack of design (see above).

Lack of scalability (How do we handle an increase of data and usage?).

No planning ahead. (How much will usage increase one year? Five years? How and when will new features be implemented?).

Lack of time. Design suffers due to lack of time, which is because of bad planning. And planning is like designing time, isnt it? Get it?

Lack of processes (How do we test the new releases? How do we handle emergencies? How do we make sure we dont run out of resources such as disk space?).

Lack of process automation. As much as possible should be automated and require a minimum of human interaction. This is very true about upgrades and maintenance.

No adherence to best practices. Most products have best practices, outlining how to configure and install them in a correct way. Some products can be very forgiving whereas others will work poorly unless setup well. (Microsoft SharePoint anyone?).

Lack of documentation. If you never want to get a system out of your hair, fail to document it. Everyone will ask you about it until the day you die. And then they will come with flowers and more questions to your tomb! Document the system and the processes.

A plan to handle major upgrades. Servers age, operating systems become obsolete and new technologies become available.

A way to avoid resource dependence. It really comes down to documentation and a process to handover the systems to the people that will care for it when youre no longer responsible for it.

Not thinking about security. Security is aa process not a product, Sun-Tzu did NOT say that. It was Bruce Schneier. In the IT-security world, Schneier is our Sun-Tzu. All parts of the system should be designed and built in a secure manner. And maintained that way

Lack of exit plan. One day the system has outlived its purpose. You knew this when you set it up. Who will say when the time has come? Ive seen many systems alive, since no one knows if their still in use. Rather safe than sorry.

Also remember decay is the supreme power of the universe. Unless you make sure so maintain the system, it will become more and more shoddy and finally it will fail.

Ive learnt much from my own experiences and even more by listening to other people telling their horror-stories. I want to send a special thanks to Olle Ojala, for his input about building good designs. Please comment on this if you have any ideas.

Tags: Bruce Schneier, design
Posted: 2010-06-17 by Erik Zalitis
Changed: 2010-06-17 by Erik Zalitis

News archive