Crowe Solutions Architecture Blog : architecture

Web Application Security – beyond authentication and authorization

Daan De Brouckere — Wed, 05 Mar 2008 19:57:00 GMT

How much time do you usually spend securing a new system? Does security play a major role in your software architecture? How much security is enough?

Securing web applications traditionally consists of two components referred to as authentication and authorization. Authentication is wrapped up in the log-in process, during which your system needs to identify the user or other system attempting to gain access. Application developers will create log-in pages or leverage Single Sign-On solutions to address the authentication issue. In addition, HTTPS will be used to encrypt the communication between your end-users and the system. Authorization, on the other hand, is the process by which the system verifies that a user (or external system) has the permission to execute a particular function within the system. This may be addressed by implementing a role-based security model.

Is this enough? Well… that all depends on what kind of system you need and what kind of legal implications apply (such as HIPAA).

Security must be addressed in each of the following phases of the software development lifecycle.

Requirements
During requirements gathering and scope definition, one must understand what the security requirements are. Don’t just ask for them, but lead with questions and what-if scenarios.

Architecture and Design
When defining your architecture, consider the different components that will be needed to provide adequate security. Will security be encapsulated as part of each module, or will the modules in the middle tiers assume that a different tier has taken care of security?

Development
Have you identified secure coding practices as part of your coding standards such as minimizing the attack surface and establishing security defaults?

Testing
Have you planned for security testing that addresses common attacks and checks for vulnerabilities?

Deployment
Is your connection from application to database running with more privileges than necessary? Is the right security infrastructure in place, including firewalls and intrusion detection systems?

As you’re evaluating your current system or building the next generation of products, please take a moment to think about security beyond authentication and authorization. I’m not suggesting that every system needs to be secured like Fort Knox, but rather that you consciously think about the appropriate level of security for your system and document it as part of your system architecture and development process.

There are many references out there to help you improve software security. I would recommend the Open Web Application Security Project (OWASP) to start.

Cyclomatic Complexity Podcast

Mark Strawmyer — Wed, 23 Jan 2008 04:50:00 GMT

I sat down with Larry Clarkin recently to do a podcat for The Thirsty Developer, which is a podcast that Larry and Dave Bost have started. Larry and Dave are both Developer Evangelists for Microsoft that I'm fortunate to interact with in the community.

The topic of the discussion was in regards to Visual Studio Team Suite 2008 and some of the great features in the Developer Edition and how they're helping our Crowe project teams in their effort. As a bonus I got to say cyclomatic complexity, which while a tongue twister is fun to discuss.

Take a listen. I'd love to hear some feedback.

Value of Guidance Solutions / Frameworks

Mark Strawmyer — Wed, 02 Jan 2008 15:27:00 GMT

I was recently engaged in discussions about the use of design patterns that resulted in my reflecting on projects I've seen where I judge design patterns to have been used successfully. Design patterns can indeed add significant value to a solution and its long term viability and success. They can also add a great deal of complexity based upon the pattern in question. The more main stream the more likely the code will pass the maintenance test where another developer can pick up the code and successfully make modifications or additions that properly adhere to the pattern in play. The more obscure the pattern the less likely another developer can easily maintain.

As I reflected on times where I've seen patterns be successful I kept coming back to a commonality of what I refer to as a guidance solution or guidance framework being in place early on. This boils down to work being done up front to put in place a detailed example of how code will be written. It involves items such as creating a solution, putting stubs for various code projects that will hold the UI, data layer, business logic, etc, Enterprise Library or other core components included, and then building out some portion of the solution that hits the database or performs some other item of functionality that will be fairly common within the code base. An ASP.NET web project example would be getting the solution setup, establishing multiple projects to hold different tiers of code, getting the authorization provider up and going, and building a secured maintenance page that retrieves and allows updates of data from a data source. Plugging in the use of data retrieval, error handling, audit trail, and logging, and demonstrated use of design patterns such as MVC, MVP, factory, etc to provide a concrete example. This stubbed out solution then serves as a working example for other developers to emulate in writing their code so they aren't starting from scratch themselves.

Guidance Solutions / Frameworks certainly don't guarantee success by any means, but the times I've seen them in play from the start other developers have been able to roll on to the project and contribute fairly rapidly without an extreme learning curve. The key being that it needs to be done up front to maximize the value and serve as an example for consistency from the start. Otherwise there is an inevitable part of the project where refactoring is forced to take place to bring consistency to a code base riddled with inconsistency as many of the developers chose different approaches to common items such as database access, logging, and exception handling. Having the guidance framework in place from the start helps avoid this what can be time consuming and costly quality issue phase on projects. Even better is if the up front work is done with more common practices that are well known and will require less education within the team and a higher chance it will be willingly adopted over having to force adoption.

Code Reviews and Maintainability

Mark Strawmyer — Wed, 26 Dec 2007 15:06:00 GMT

Its continually amazing to me how discipline can go a long way to helping ensure a solution has long term maintainability. Making sure you set parameters and agreed upon standards at the start of a project and then having the mettle to ensure that regardless of how tirelessly you're having to write code you take the time to stay within the parameters. More often than not when I'm reviewing a solution I see a lack of standards or consistency and excuses such as "there isn't time for it" is almost always the explanation offered or implied. Or even more shockingly you find an experienced developer that is coding with discipline, but not caring that others aren't and not sharing their best practices. Open forum peer reviews and discussion of code is something I am a big proponent of in projects especially early on. It helps ensure that folks are on the same page in terms of style, practices, and that the solution is getting off to the right start. This is great for reviewing key and common elements of a solution even if it is only practiced early in the project and then abandoned as the project is more mature in the lifecycle. The downside though is that it isn't realistic to expect that all code can be reviewed by such a process as there is often way too much code.

Enter tools. Even if there are no explicit standards being followed, there are code analysis and metric tools that can be a big help to making sure the overall solution is more maintainable and performant. Code analysis will examine the code and look for situations where items may be less than optimal or could be done another way for better performance, maintainability, security, etc. Common situations are things such as over use of string concatenation where specially designed and class library provided string building objects would be better or inconsistent use of naming conventions.

Code metric tools will examine things such as the overall number of lines of code, depth of inheritence, and cyclomatic complexity which is the number of branches that can be taken within a specific block of code. The higher the cyclomatic complexity the harder it will be to unit test the code as there are more conditions to test.

There are a number of tools out from vendors such as IBM (Rational), Compuware (DevPartner), and Microsoft (VSTS). Microsoft recently released the Developer edition of its Visual Studio Team Suite that now includes code metrics and analysis. I've been experimenting with it and using it to look at a bunch of different code and I've been pretty happy with it and its ease of use and understanding so far.

I highly recommend that developers and development teams adopt a tool to help automate code reviews and perform code analysis and metrics if you're not already. Even the most disciplined developer will benefit from having an automated review of their code. It only takes a couple of minutes based on the tool and size of the code base and the results can give you plenty to think about and decide to take action on or not. Its a great way to learn additional best practices you may not have been aware of by examining the output of the automated review. Each developer should be responsible for running such as tool against their code and remediating issues prior to having flagged an item as complete. Again, it is a decision making process as you won't want to blindly make all changes suggested, but such a process prior to turning in code will go a long way to helping overall maintainability.