Application Security

I used to be an application security “expert”. This post is not a crash course in application security. It is a post about those who ask us to implement security in their application with no clues on what they really want.In fact, this definition is too vague. It applies to all the project managers I know. Lets say this post is about the worst of them … those who will never understand what they want … and what they have. We all know one of these dummies.

Let me picture what I found in the last company I did security development for. I am sure it will sound familiar to you as well. Over the last ten years, a huge management application have been developed in a large enterprise. Today, all the business of hundreds of users of the company passes through this application.

The fun part now. The client application is written in VB6 … oh, sorry, this is not a client application, this is THE application. This app talks directly to an Oracle database where all the sensitive data is stored.

Ok ok, that’s not that bad, I know. Let me continue. At the beginning, all users were assigned a database account to control access to the database on a per user basis. One day, when the application reaches more than 20 users, it became a problem to manage all these different accounts in the database so, the security guy of the month suggested to implement an in house security infrastructure.

That would have been a terrific opportunity to add an application server between the database and the clients to secure the database. That WOULD have been … Yep, you got it, they didn’t. Their in house security infrastructure code has been implemented in the VB6 application and all the security data (roles, users, privileges) have been stored in the … database.

Now they needed a way to access the database without storing the username and password of the schema owner on the client side. That would have been an excellent opportunity to create a login scheme using data encryption, secure communications and “grant execute” packages to process logins. Once again, they decided to go deeper into their in house solution by encrypting the username and password of the schema owner in the database.

They used symmetrical encryption so they had to distribute the encryption key to all VB6 applications. How they did that? I guess they tried to find a good solution. I guess (hope) the solution they came out with is due to a tight schedule or a terrible manager. They decided to copy the encryption key into the registry of all users computers.  Imagine how easy it is to deploy a new password or encryption key. In fact, it is so complicated and involve so many peoples that it has never been done in the last 5 years.

On top of that, I found, by reading the code that the “encryption” algorithm was, in fact, an in house encryption algorithm. A couple of XOR and left and right bit shifts … Good enough they said.

That’s where I came in. Following a security audit, they asked my team to find a solution to their security problems. That resulted i a tsunami of meetings with all these guys who had approved the previous developments. Even after all these failures, they were not aware of the real problems they had … and they were ready to sign with the first one who would came in with an “in house” solution.

There are not many things you should know about application security but you need to understand them well, otherwise, you will end up with a brilliant “in house” solution. So, what are these base concepts we need to know?

  1. Never underestimate the capacity of hackers of malicious users. There is no such thing as a “good enough” security model or encryption algorithm. It’s safe or it is not.
  2. As of today, you should NEVER write these huge applications without a central application server to manage authentication and services access. Never write again one of these 2Tiers applications. NEVER!
  3. Avoid “in house” security infrastructures development. If you ever end up creating a ROLE table in a database, please,sit back and ask yourself “Could there be a ready to use solution out there that fits my needs?” YES there is … There are in fact many many solutions you can use.
  4. Your rich client application should not be aware of security rules. Never enforce security rules in the client application. It’s easy to crack a piece of software or to intercept data on the wire. This is a corollary of the rune #2 but I want to make it clear. The client application is where the enemy sit!

There are many more thing you should know to develop a good security infrastructure but, if you are a decision maker in your enterprise, please remember these simple rules. You will save a lot of headache, time and money …

You think my list of rules in incomplete? Go ahead, complete my list by leaving a comment.

Philippe Chrétien

Leave a comment

Your email address will not be published. Required fields are marked *