My Database Managment System Project

Blogs to track my database managment system project. The main target of this project is learning. I am not planning to compete with SQL server - At least not now!

My Photo
Name:
Location: Cairo, Egypt

I am an Eyptian developer @ optimize software company.

Sunday, June 19, 2005

Security : The sub-feature of every feature

I continued working on requirements specification for my database engine project. The first thing that I need to specify is security features. What are they? What security features am I going to implement, and what features am I going to ignore.

My previous knowledge about security was very small. I knew some specific security subjects such as buffer overruns, some authentication, authorization and encryption techniques, but I needed a bird's eye view on the security in general. How can I make my application secure? And how can I test its security?

So I started looking for good books about this subject. I found an excellent book called "writing secure code" which was an excellent start for me to look at the security as a whole.

The first thing that I discovered is that the second statement that I wrote in this blog is wrong. As the book says, security features is different from secure features. Every feature, every function, every line of code, and every design decision, have to take security rules, threats and recommendations into account.

So, I should have written my statement like this “The first thing that i need to specify is security rules, threats and recommendations that I am going to work with in this project.

So instead of putting security as an item in the requirements documents, I have to make separate documents for security and call them security documents.

An example of a wrong development plan mentioned in the book was like this:

Milestone 0: Designs complete
Milestone 1: Add core features
Milestone 2: Add more features
Milestone 3: Add security
Milestone 4: Fix bugs
Milestone 5: Ship product

This methodology in application development is wrong for the following reasons:

  • Adding security later is wrapping security around existing features, rather than designing features with security in mind.
  • Adding any feature, including security, as an afterthought is expensive.
  • Adding security might change the way you've implemented features. This too can be expensive.
  • Adding security might change the application interface, which might break the code that has come to rely on the current interface.
  • While working on milestones 0 to 3 without security in mind, make sure that there are security bugs in the code and the design. When coming to milestone 4, you will have to rebuild the design and code that contains security bugs (probably most of the application). This will need an excess cost and time. Remember what I have said before about the exponential increase in cost of fixing bugs when discovered in the design or code stages.
In a lot of situations, developers tend to ignore security bugs to reduce cost and time, especially if the bug was discovered near the releasing time of the application. They may think of fixing it in the next releases or versions. This is extremely dangerous.


If the customers discovered that the application doesn't work as advertised, your reputation will go down, and your customers will leave you to another company.

Also fixing security bugs after production is very expensive. Microsoft security response center believes that a security bug that requires a security bulletin costs in the neighbor hood of $100000.

Fixing security bugs frequently introduces Regression Bugs to the system. Regression bugs happen when a feature works fine and after some changes it doesn't work as before. This requires a strong testing for the application after fixing security bugs.

Of course security increases cost and time, but remember the good word in software engineering: "Features, cost, schedule: choose any two".if you want to have good features for your application, then security is a must and you have to endure the excess cost and time.

Generally, security is more difficult than many items in software production for the following reasons:

1- Security is difficult to measure:

For example, if you are making a program that solves differential equations, then you can test this feature easily. Give the program a set of differential equations of different inputs and degrees. If the program gave the right answer, then this feature is working well.

You cannot do the same with security. You cannot easily say:” My application is secure, and no one can hack it or stop it". There's no 100% secure application. All what security experts trying to do, is making the process of attacking the system as much difficult as possible. The most secure application is the one that you haven't written yet. Believing in a 100% secure application is like believing in tooth fairy.

So how can I measure the security level of my application?
Some of Microsoft guys classify an application as a secure application if 12% of the time and cost were given to security.

I think this is a wrong method of measuring security. Since security is a sub-feature of every feature, it is difficult to say how much of time and cost was specified to security alone.
Also the security level required depends on the nature of the application. The level of security required for an online money transfer application is not the same as that required for a computer game.

2-The attacker always has the advantage, the defender is always in a dilemma:
This is the nature of security generally either in software or in any other field.
These are the reasons:

  • The defender must defend all points; the attacker can choose the weakest point.
  • The defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities.
  • The defender must be constantly vigilant; the attacker can strike at will.
  • The defender must play by the rules; the attacker can play dirty. The defender has various well-understood white-hat tools (for example, firewalls, intrusion-detection systems, audit logs, and honey pots) to protect his system and to determine whether the system is under attack. The attacker can use any intrusive tool he can find to determine the weaknesses in the system

In addition to the general difficulties of security, I have security difficulties that are special to my application. I am going to discuss them in my next blog (God willing).

0 Comments:

Post a Comment

<< Home