Naive securty faults

Ricardo Gonzalez Vargas — Wed, 12 Oct 2005 00:10:00 GMT

Today I was as speaker @ Microsoft Architect Forum. Security practices talk.

Definitively, there are many naive security faults that IT Managers, Architects, Designers, Coders and testers do while construct software.

The basics include:

- Principle of less privilege problems à users can do more than they need.

- Assume that a firewall is a complete security solution.

- No antivirus or software patches updates.

- Buggy code

- There are more options in apps than most of the user really use.

- Trusted user input (what an error!!!)

- Fool cryptography (key management, crypto algorithms)

- Think that technology is the security solution (in most of the cases, the problem starts with people and processes)

- Bad use of security tools provided by the platform

Those are the most important conclusions.

Keep them in mind.

Cheers.

Ricardo González Vargas

Software Development Consultant

Microsoft Regional Director

Microsoft Most Valuable Professional

http://www.devsynergy.net

rgonzalez@mvps.org

How good technology could be used SO wrong

Ricardo Gonzalez Vargas — Thu, 06 Oct 2005 22:37:00 GMT

In past days, a customer (I can’t say names) ;) Asked me to help them in the solution of a .NET application deployment.

The architecture defined for this app, was based in a DNA like style, with a rich client consuming a series of COM+ based centralized components and accessing an Oracle database. The problem was in essence that they developed all the application and specifically, all the components as simple local components ( using System.ComponentModel.Component as base class for them) and nearly the time to deploy, started the process of conversion to ServicedComponents. Obviously, there were many troubles and high number of instances of components, troubles with object pools, transactions, JIT, and many others.

Another great mistake was the fact that they used intensively inheritance in components, simply to reduce little pieces of code, and not in the essential objective of inheritance that is model specialized variations of concepts in the domain of the problem.

High coupling and high number of dependencies, was also another big trouble within this application. Basically, all forms had dependencies at least with 5 to 12 components, making so dangerous to change any interface exposed by the components.

A very simple solution to many of those problems can be done with the inclusion of a Façade pattern ( GOF, 1995 http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/qid=1128633932/sr=8-1/ref=pd_bbs_1/102-8849697-5773715?v=glance&s=books&n=507846) . Even having not only one façade, there could be a very important improvement of the design giving a lower level of coupling and making the impact of changes in the model much lower.

Simple solutions, for complex problems.

Cheers,