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.

Thursday, July 07, 2005

General Security Guidelines

Writing security documents cannot be the first thing done in my database engine project. The security documents should contain many things that depend on the application structure and requirements, which has not been determined yet. For now, I can just put security guide lines to work with.
These are the most clear (until now) security guide lines that I have to follow in my application:
1-Perform Threat modeling:
Threat modeling can be done in the following steps:

  • Assemble the threat-modeling team: The team will contain me, me and me! I am working alone on the whole project.
  • Decompose the application: I haven't determined the application's design or main features till now so I cannot decompose it.
  • Determine the threats to the system: Cannot be specified due to the above reasons.
  • Rank threats by decreasing risk.
  • Choose techniques to mitigate the threats: Techniques are not the same as technologies. A technique is derived from a high-level appreciation of what kinds of technologies can be applied to mitigate a threat. For example, authentication is a security technique, and Kerberos is a specific authentication technology.
  • Choose the appropriate technologies for the identified techniques.

2-Avoid buffer overruns:
Buffer overruns are one of the most dangerous and widely spread security flaws in today's applications and libraries including the standard c++ library - The new standard library will not contain buffer overruns but Microsoft are waiting for the meeting of the ECMA to approve the new library before releasing it. see this article by Brandon Bray from Microsoft about buffer overruns:
Buffer overruns

Security threats are divided to 6 main categories, shortly known as STRIDE. These threats are:
Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service.
A Buffer overrun can lead to the 6 threats because it can allow the hacker to run his own arbitrary code.

The reasons that buffer overruns are a problem to this day are poor coding practices, the fact that both C and C++ give programmers many ways to shoot themselves in the foot, a lack of safe and easy-to-use string-handling functions, and ignorance about the real consequences of mistakes.

To avoid buffer overruns, I have to:

  • Use the Visual C++ .NET /GS compiler option. This option inserts a variable named cookie on the stack between the buffer and return address. This idea was first proposed by Crispin Cowan (and others) under the name of StackGuard .

  • Write solid code. Always validate inputs assuming that the outer world is a bad place.

  • Handle strings safely.String handling is the single largest source of buffer overruns. The ANSI string handling functions and the windows string handling functions are unsafe, and can easily allow for buffer overruns. Better string handling functions can be found in Strsafe.h. This is a header that contains a safe string handling functions that Microsoft developed during thier " Windows security push" in 2002. They wanted to increase the security of windows 2003 server, and they figured out that the ANSI and Windows string handling functions are not safe, so they made safe string handling functions for their internal use at Microsoft. Today, The Strsafe.h is found on the Microsoft's web site freely, and Developers are encouraged to use it.