Roles and Responsibilities for Managing an Enterprise Web Site

The intent of this post is to create a summary definition of roles required to adequately manage an enterprise website. It is designed to be used in tandem with a RACI (Responsibility, Accountability, Consultable, and Informed) document to provide a unified management model for the web Infrastructure developed.

Each role is neither inclusive nor exclusive in that any one person can qualify for more than one role, and more than one person can qualify for the same role, as long as each role has been fulfilled adequately.

In a future post I will discuss the creation of a RACI document.

Roles

  • Database Administrator

Database administrators are charged with controlling website data resources, and use repeatable practices to ensure data availability, integrity and security, recover corrupted data and eliminate data redundancy, as well as leverages tools to improve database performance and efficiency.

  • Application Administrator

Application Administrators are charged with installing, supporting, and maintaining applications, and planning for and responding to service outages and other problems including, but not limited to, troubleshooting end-user issues at the application level.

  • Server/Operating System Administrator

Server Administrators are charged with installing, supporting, and maintaining servers and other systems, as well planning for and responding to server outages and other problems including, but not limited to, troubleshooting Application Administration issues at the Operating System level.

  • User Account/Permissions Administrator

Account Administrators are charged with managing user accounts as well as permissions for users within the system. This includes, but is not limited to, locking and unlocking user accounts, as well as resetting passwords.

  • Hardware Administrator

Hardware Administrators are charged with managing server hardware and resources. This includes, but is not limited to, deployment of servers as well as troubleshooting issues such as faulty hardware.

  • Network Administrator

Network Administrators are charged with managing physical network resources such as routers and switches and logical network resources such as firewall rules and IP settings. This includes, but is not limited to, managing routing rules as well as troubleshooting connectivity issues.

These roles were created in an attempt to define job responsibilities at an executive level.  A RACI document is then suggested as the next step to define what each role entails at the management level.

ASP.NET Application Deployment Best Practices – Part 2

In my previous post I started a list of best practices that should be followed for deploying applications to production systems.  This is continuation of that post.

  • Create new Virtual Application in IIS

Right-click [website app will live in] > Create Application

Creating a new application provides each ASP.NET application its own sandbox environment. The benefit to this is that site resources do not get shared between applications. It is a requirement for all new web applications written in ASP.NET.

  • Create a new application pool for Virtual App
    • Right click on Application Pools and select Add Application Pool
    • Define name: “apAppName” - ‘ap’ followed by the Application Name
    • Set Framework version to 2.0
    • Set the Managed Pipeline mode: Most applications should use the default setting

An application pool is a distinct process running on the web server. It segregates processes and system resources in an attempt to prevent errant web applications from allocating all system resources. It also prevents any nasty application crashes from taking the entire website down. It is also necessary for creating distinct security contexts for applications. Setting this up is essential for high availability.

  • Set the memory limit for application pool

There is a finite amount of available resources on the web servers. We do not want any one application to allocate them all. Setting a reasonable max per application lets the core website run comfortably and allows for many applications to run at any given time. If it is a small lightweight application, the max limit could be set lower.

  • Create and appropriately use an app_Offline.htm file

Friendlier than an ASP.NET exception screen (aka the Yellow Screen of Death)

If this file exists it will automatically stop all traffic into a web application. Aptly named, it is best used when server updates occur that might take the application down for an extended period of time. It should be stylized to conform to the application style. Best practice is to keep the file in the root directory of the application renamed to app_Online.htm, that way it can easily be found if an emergency update were to occur.

  • Don’t use the Default Website instance
    • This should be disabled by default
    • Either create a new website instance or create a Virtual Application under existing website instance

Numerous vulnerabilities in the wild make certain assumptions that the default website instance is used, which creates reasonably predictable attack vectors given that default properties exist. If we disable this instance and create new instances it will mitigate a number of attacks immediately.

  • Create two Build Profiles
    • One for development/testing
    • One for production

Using two build profiles is very handy for managing configuration settings such as connection strings and application keys. It lessens the manageability issues associated with developing web applications remotely. This is not a necessity, though it does make development easier.

  • Don’t use the wwwroot folder to host web apps

Define a root folder for all web applications other than wwwroot

As with the previous comment, there are vulnerabilities that use the default wwwroot folder as an attack vector. A simple mitigation to this is to move the root folders for websites to another location, preferably on a different disk than the Operating System.

These two lists sum up what I believe to be a substantial set of best practices for application deployments.  The intent was not to create a list of best development best practices, or which development model to follow, but as an aid in strictly deployment.  It should be left to you or your department to define development models.

ASP.NET Application Deployment Best Practices – Part 1

Over the last few months I have been collecting best practices for deploying ASP.NET applications to production.  The intent was to create a document that described the necessary steps needed to deploy consistent, reliable, secure applications that are easily maintainable for administrators.  The result was an 11 page document.  I would like to take a couple excerpts from it and essentially list what I believe to be key requirements for production applications.

The key is consistency.

  • Generate new encryption keys

The benefit to doing this is that internal hashing and encrypting schemes use different keys between applications. If an application is compromised, the private keys that can get recovered will have no effect on other applications. This is most important in applications that use Forms Authentication such as the member’s section. This Key Generator app is using built-in .NET key generation code in the RNGCryptoServiceProvider.

  • Version and give Assemblies Strong Names

Use AssemblyInfo.cs file:

[assembly: AssemblyTitle("NameSpace.Based.AssemblyTitle")]
[assembly: AssemblyDescription("This is My Awesome Assembly…")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("My Awesome Company")]
[assembly: AssemblyProduct("ApplicationName")]
[assembly: AssemblyCopyright("Copyright © 2009")]
[assembly: AssemblyTrademark("TM Application Name")]
[assembly: AssemblyCulture("en-CA")]

Strong names and versioning is the backbone of .NET assemblies. It helps distinguish between different versions of assemblies, and provides copyright attributes to code we have written internally. This is especially helpful if we decide to sell any of our applications.

  • Deploy Shared Assemblies to the GAC
    • Assemblies such as common controls
    • gacutil.exe -I "g:\dev\published\myApp\bin\myAssembly.dll"

If any assemblies are created that get used across multiple applications they should be deployed to the GAC (Global Assembly Cache). Examples of this could be Data Access Layers, or common controls such as the Telerik controls. The benefit to doing this is that we will not have multiple copies of the same DLL in different applications. A requirement of doing this is that the assembly must be signed and use a multipart name.

  • Pre-Compile Site: [In Visual Studio] Build > Publish Web Site

Any application that is in production should be running in a compiled state. What this means is that any application should not have any code-behind files or App_Code class files on the servers. This will limit damage if our servers are compromised, as the attacker will not be able to modify the source.

  • Encrypt SQL Connections and Connection Strings

Encrypt SQL Connection Strings

Aspnet_regiis.exe -pe connectionStrings -site myWebSite -app /myWebApp

Encrypt SQL Connections

Add ‘Encrypt=True’ to all connection strings before encrypting

SQL Connections contain sensitive data such as username/password combinations for access to database servers. These connection strings are stored in web.config files which are stored in plain-text on the server. If malicious users access these files they will have credentials to access the servers. Encrypting the strings will prevent the ability to read the config section.

However, encrypting the connection string is only half of the issue. SQL transactions are transmitted across the network in plain-text. Sensitive data could be acquired if a network sniffer was running on a compromised web server. SQL Connections should also be encrypted using SSL Certificates.

  • Use key file generated by Strong Name Tool:

C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe

“sn.exe -k g:\dev\path\to\app\myAppKey.snk”

Signing an assembly provides validation that the code is ours. It will also allow for GAC deployment by giving the assembly a signature. The key file should be unique to each application, and should be kept in a secure location.

  • Set retail=”true” in machine.config

<configuration>

<system.web>

<deployment retail="true"/>

</system.web>

</configuration>

In a production environment applications do not want to show exception errors or trace messages. Setting the retail property to true is simple way to turn off debugging, tracing, and force the application to use friendly error pages.

In part 2 I continue my post on more best practices for deployment to a production environment.

Naming Conventions can be Your Enemy

Or your ally in the fight against technology management.  Earlier this week I was given the task of doing some naming for new servers, which is pretty much SOP.  Problem is, we don’t have a naming standard.  As such, I may choose a name that annoys someone, or they choose a name that annoys me.  This becomes very political.  We don’t want to name things in such a way that they annoy people.  It’s a bad idea.  And, much to my dismay, I said something this morning that was pretty much just insulting to one of my team members.

I could have given loads of excuses, but it wouldn’t have mattered.  I was being petty.  Man, that’s a bad idea in an office.  It divides teams, and man, that’s *really* bad in an office.  The reason it came about was because a few people were talking about moving into “fun” server names, as apposed to functional server names.  Examples of this would be Cygnus or Badger, as apposed to GR-SQLCluster1.

The reasons behind it being:

  • It’s more secure if the attacker doesn’t know what the server does, based on it’s name
  • Server roles change over time, so GR-SQLCluster1 might become relegated to an apps server
  • Sections of functional names become redundant
  • Organize names by type; i.e. birds, galaxies, different words for snow, etc

At first glance, they make great sense.  However, after a little time to digest the reasons, a few things become clear.

  • If an attacker is able to get to the server, to the point that they can know the name, you are already screwed
  • A good practice is to rebuild the server if it changes roles, and with that change the name
  • People don’t want to connect to the Badger Server
  • You need a reference list to figure out what the Cygnus server does/where the Cygnus server physically is
  • If you want to create DNS entries to provide functional names to it, that’s another level of complexity to manage
  • What happens when you run out of server names?

Given this list, it now becomes an interesting debate.  But I have one question for you:

As a developer, would you name a variable ‘badger’ if it was holding a shopping cart?  Not a chance.  You would only do that if it were badger related, and even then you are better off with ‘meanLittleWoodlandCreature’ in case you change something.

In my response I called the security reason laughable.  Again – petty and a really, really, really bad idea when in a team discussion.  Obviously I was in a pissy mood for some reason, or maybe a greater than thou mood thinking I knew more about the topic.  I tend to do that.

I think what really made me do it was that we are developers, not administrators.  It’s not our job to name servers.  So why were we?  I didn’t want to piss anyone off, I just wanted to name the server so we could move on to the next stage of the deployment.  This situation could have easily been averted.

If we had a naming convention for our servers, regardless of fun vs functional, I could have followed the convention and washed my hands of the problem.  So I guess the question is, why don’t we have one?  Lot’s of companies don’t have them.  And I think it’s because of stagnant server growth.

If you are only setting up a couple servers every so often, you aren’t bogged down with these types of questions.  You have time to discuss.  The problem we are having, I think, is because we have increased our server growth dramatically in the last little while, which hasn’t given us enough time to discuss names as a group.  I was rushing to get the server into production because the administrators were busy working on other tasks that were filed under the category “Do Now Or ELSE!”

So I think we need a naming convention.  A functional naming convention.  It will prevent a world of hurt down the road.  Now to get buy in, and ask for forgiveness.  I still have lots to learn.

Move Their Cheese! (and Change the Design)

I tend to complain a lot.  Which frankly, doesn't do much for what I'm complaining about.  In most cases, it comes down to "okay, here is a problem, now someone else go and fix it."  There is a direct correlation to how many people I annoy too.  The number of people I annoy increases as the magnitude of my complaining-ness (hey, a new word) increases:

upGraph

If I wanted to change something, obviously I’m going about it the wrong way.  However, there is a direct correlation between how often I do something wrong and the likelihood I will get it right.  See previous image.  What that means is if I keep screwing something up, eventually I am bound to get it right.  However, what is not necessarily apparent in the chart is that if I do nothing, I won’t improve upon my actions.  Maybe it is apparent, I don’t know – I’m still working on it.

The reason I bring this up is because I keep hearing people bash/complain/hate the Office Ribbon and application Ribbons through Windows 7:

ribbon2007 The major complaint has been that people couldn’t find what they are looking for anymore.  There aren’t any menus, so they can’t figure out how to set [insert obscure property].  It doesn’t make sense to them.  They now have to change the way they think about the application.  What is unfortunate about this is that menus are a horrible interface.  You shouldn’t have to dig through 6 layers of menus to change a single property, and that’s what Office 2003 became.  The Ribbon has it’s own problems, but it also increases user productivity greatly when the user knows how to use the Ribbon effectively.  Which in lies a major problem.

Most end-users don’t like when you move their cheese.

Well now we have a problem because people also want improved systems.  Improve the system, but don’t change it.  This paradox is why fundamentally different – game changing – designs aren’t seen all that often.  We stick with what we already know because if we deviate people will complain.  It’s a very tough way to create a better interface.

So how do you create a better interface?  You keep changing it.  Guaranteed the first couple of designs are going to annoy people: i.e. the Ribbon.

This is good.

If you keep failing at designs, that means eventually you are bound to figure out what kind of interface works best.  You will never figure it out if you never change.  Without MicroBating MasterSoft’s (hey look, two new words) ego, I must say that Microsoft is doing well in this area.  They keep making lousy design decisions.  See Expression Blend UI, and listen to most non-technical office workers using Office 2007.  I’m sure there are quite a few instances in other applications as well.  However, and I must make this clear, Microsoft is doing the right thing.  They are actively trying to create better interfaces.  Yes, it will piss people off (it’s pissed me off quite a few times), but at least they are making the effort.  And that’s what counts.

EDIT: P.S. I do like the Ribbon.

Presenting at Techdays 2009!

Still working out session details, but it looks like I will be presenting in Ottawa and Montreal for Techdays 2009.  I will be loitering around at the Toronto event soaking up all the techie-goodness, so come find me at any of the three events.  We can talk shop, shoot the breeze, or just mill about having a good time.

I promise I won’t embarrass anyone.  Except maybe myself.  But that’s a warning for all occasions.

Here are the dates of the events across Canada.  Buy your tickets before the early-bird deal runs out!

City Date Venue
VANCOUVER SEPTEMBER 14-15 Vancouver Convention Centre
TORONTO SEPTEMBER 29-30 Metro Toronto Convention Centre
HALIFAX NOVEMBER 2-3 World Trade & Convention Centre
CALGARY NOVEMBER 17-18 Calgary Stampede
MONTREAL DECEMBER 2-3 Mont-Royal Centre
OTTAWA DECEMBER 9-10 Hampton Inn & Convention Centre
WINNIPEG DECEMBER 15-16 Winnipeg Convention Centre

The Early Bird price is $299.  The regular Price is $599.

I will post more on the sessions I will be presenting at a later date when I get the full details.

See you there!

Make it Right: Revisited

In the previous post Make it Right I asked the question

Why aren’t more people making it right?

I was curious why people don’t take the time to write software properly.  There are lots of jokes about bad software development:

If houses were built the same way programmers build programs, we’d all be living on the street.

Unfortunately it’s a fair statement.  Most programs out there suck*.  I used to come back with the argument that people have been building houses for thousands of years, but software for only a few decades.  There are bound to be issues.  But then it occurred to me.

Mike Holmes is all about making it right, as I said in the previous post.  His TV show was about fixing the problems that professionals made.  Professionals who have been building the same thing people have built for thousands of years.  Wait a minute.  I just flawed my own argument.

Houses are built the same way programmers build programs.

Why?

I see three very apparent reasons.

  1. Cheapness – People want software built quickly, as cheap as possible.
  2. Laziness – Why strain your mental processing or follow best practices when you can just do whatever first comes to mind?
  3. Uneducated – Sometimes (a lot of times) the person doing the building/development just doesn’t know what they are doing.

There are numerous other reasons why, but these three are by far the biggest across all aspects of building stuff.  I think they answer the basic question asked earlier, but now I have another question.

Why do we let people who are lazy or uneducated build applications for us, just so we can save a few bucks?  We will end up paying loads more in support after the fact…

*I said programs, not programmers.

Make it Right

For the last couple months I’ve had a strange fascination with the TV show Holmes on Homes.  By no means am I construction-literate.  When I want something built with wood, I buy it.  The fascination is not about the construction, or even his manly good looks (FYI: I meant it in the friendly-way, not the friendly-way), but the premise of the show.

Mike Holmes is about doing a job right.  It doesn’t matter what the job is; it HAS to be done right.  Period.  No if’s, and’s, or but’s.  We need more people like him.

This applies to Information Technology as well.  Take the Security Development Lifecycle for example:

Do it right first: securing new code helps keep down compatibility and roll-out costs.

Why aren’t more people making it right?

Security, Architecture, and Common Sense

Good enough is sometimes not good enough.  I’ve been doing a lot of thinking lately (well, I’m always thinking), and security has been an issue that has come up a lot.  Frankly, I’m a two-bit software developer.  I know my code isn’t the best, nor the most secure.  I use strong passwords, encrypt my sensitive data, and try to limit access to the applications for those who need to use it.

In theory this works.  Problem is, it’s a lame theory.  There are so many unknown factors that have to be taken into account.  Often times they aren’t.

When I go to build an application I spend time designing it and architecting it.  This is usually the case for most developers.  What I’ve noticed though, is that I don’t spend time securing it.  I can’t.

Imagine building a house.  You put locks on the doors, bars on the windows, and someone breaks in.  Why?  Because someone left the key in the door.  You can’t build against that.  You just can’t.

You can follow the Security Development Lifecycle, which I recommend to each every single developer I meet.  There are tons of resources available.  But it can only go so far.  It’s designed more for being part of the iterative processes, not the architecture.  Or at least, that’s how most people interpret it.

So?

My last post talked about Single Sign-On (SSO).  It’s a great sellable feature for any product.  What most people don’t realize though is the inherent security benefit to it.  With it, that means one less password to remember, one less password that could get intercepted, one less password to change every month.  This is a fundamental architectural issue.  But at the same time, it’s common sense.

What is sometimes the simplest idea, is usually the correct solution

What the hell does that mean?  It means keep it simple.  Security is simple.  Keep data from prying eyes, and keep it from getting lost.  This is common sense.

Security is not difficult to comprehend.  It becomes difficult when academics get involved.  Spouting theories and methodologies scares people into thinking security is extremely difficult to implement.  It’s not!

Follow the Data

Understanding the flow of data is crucial in properly architecting an application.  It’s crucial in properly securing an application as well.  SSO is a perfect example of this.

The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end data systems. Using SSO, you can access data from server computers and services that are external to Office SharePoint Server 2007. From within Office SharePoint Server 2007 Web Parts, you can view, create, and change this data. The SSO feature ensures that:

  • User credentials are managed securely.

  • User permission levels that are configured on the external data source are enforced.

It makes perfect sense.  It’s simple when you think about, and it affects every subsystem of SharePoint.  Make security a feature.

What Makes us Want to Program? Part 2

In my previous post I started talking about part of my personal history with software development, and when QBasic got me hooked.  I ended the post talking about the move to Canada.  We arrived in Canada literally a week (7 days exactly) before Grade 9 started.  After getting enrolled in school, I tried to find something to keep my mind occupied.  It was either that or contemplate what Grade 9 would be like for someone who used to live 3000 miles away in another country.  And winter.  Still 4 months away, but definitely something I didn’t want to think about.  Being that we moved to a house in the country, I couldn’t just walk around town either.  Mental occupation was harder than I thought.

So what does a 14 year old boy, new to the country, living in the middle of nowhere, do to keep himself from going crazy?  Install Linux of course!  I needed something to keep my interest, as well as to keep the gears in my head moving.  If memory serves, I started out with a vanilla copy of Red Hat Linux.  It was pretty easy to install, but being new to the OS architecture, the device mapping was a little confusing.  After a couple months of studying the Linux architecture, I started writing shell scripts, and even delved into the source code.  After testing some minor modifications to different components I started to learn the basis for the C/C++ languages.  Imagine that, a 14 year old kid understanding the basis for C++.

While trying to keep my mind still occupied, I came across an interesting find: The National Security Agency’s Security Enhanced Linux Kernel.  If compiled and installed wrong, you will destroy the build.  Learned that the hard way…  And seeing as I couldn’t find a proper driver for my modem anyway, I gave up on Linux and moved back to XP.  Not that the internet was all that useful anyway; I was connecting at 28.8 half the time.

Going back to the image in Part 1, I met an interesting character in school.  He turned out to be one of my best friends, and fellow developers, Greg. We started working on some odd projects here and there in VB, until I was tasked with building a web store.  Since I had never actually brought HTML and Dev together, I was a little nervous about what I was getting myself into.  Going with what I knew well, I started in ASP with VB code.  This was not ASP.NET.  Earlier, I had said I never found VB all that intuitive as a language.  The syntax never really made sense to me.  So my friend suggested I take a look at PHP as an alternative.  I liked it.

PHP had the flow of C, and the usefulness of VB.  With PHP I got the store finished and launched.  The site worked great.  I was 15.

Once the first spring of my existence in Canada rolled around, a couple friends and I decided to start a band.  We sucked.  But seeing as one of the other members was Greg, we had an awesome website.  We had media streaming, custom modified forums, and full site statistics.  The statistics were built around the forum.  The site pulled data from recent posts, recent events, and recent user logins, and compared the data to the media streams.  We could see who was doing what.  Mind you, there was only about 50 people who loitered around the site, but the site was a great proof of concept for what we could do.

Following the demise of the band, Greg and I were invited to a Microsoft hosted event.  It was here that I fell in love with ASP.NET.  Which I will discuss in Part 3.