Somebody on LinkedIn asked the above question to a group I'm part of. I decided to answer it thinking "Oh, I can chime in with a quick little answer", but the more I wrote the more complex the answer became.

Here is my response:

I think the question is far more complex right now actually. For example, what constitutes "Linux" or "Windows"? If we're talking only about the kernel, then they're about the same (both extremely secure). They've certainly made different design decisions, but at the end of the day kernel exploits for either OS are extremely rare.

If you're talking about how the core OS protects its users from malware and other attacks an argument could be made for the forced low privileged user mode of Linux is more secure. However there are huge advancements on both sides to reduce the risk of malicious code executing without the user's knowledge ASLR, DEP, NX bits, and stack canaries all exist to reduce this risk, and are included in Linux, Windows, Mac OSX and others. So I'd say it's a wash there too.

If we want to talk about the applications that ship with the OS we might be getting closer to an answer, but there is still a lot of security and process in place.

Where things really start to diverge is user base and the complexity and security of the applications those users install on their machines.

OS security is largely a "solved" issue, the amount of risk you inherit from your OS pales in comparison to the amount of risk you inherit from the applications you install and your behavior on your computer. As someone who breaks software daily I can say we look first at the applications and the security controls in that application (input validation, logic assumptions, authentication, authorization, SQL injection, Buffer Overflows, Format String Vulnerabilities, etc.)

If we concede it's the applications that are going to give you the risk, then which OS provides the best protections for developers so they can make the best decisions in security? There are great resources for both, but I would lean toward Microsoft being the bigger driving factor in security for software developers today. They spend so much effort surfacing information to help developers and testers make the right decisions it can be almost overwhelming, but the information is there and from a trusted source.

That's quite a longer answer than what I was expecting to write. I think this question is far more complex than can be answered quickly. I'd love to do a complete study to compare the overall security of these systems (including OSX, and maybe some mobile platforms as well).

My feeling is that the biggest wins for security should be Application Focused, not OS focused. Use the OS, the programming language and the technology that you understand, then learn about security and build a secure system from the ground up. That's how we will make big leaps toward a more secure system.

Periodically I post about security on my Security Innovation Blog. Here is my most recent blog post over there. You can see I started out thinking I might scare some other people with these stats, but they're so huge (and gotten even bigger and more frequent since this post) that it's hard to even keep up. Since I wrote this we saw the start and end of http://lulzsecurity.com/ and the loss of many many more breaches. Yikes I say, Yikes. It's time for us to step up, in a Major Way.

In the wake of the Sony Security Breaches (breaches, you say? As in plural? Yes, read on for more information) I decided to update some of our instructor led training slide decks.

The first few slides of our security awareness courses include a number of slides intended to scare people into paying attention to the threat of security issues. We do this by showing the largest, most costly and most impactful data breaches and security vulnerabilities in recent history.

Instead I scared myself. There is no statistic I could find to show that things are getting better or more secure in general.

I should say before I list off all these terrible statistics that largely the companies we work with are, in fact, getting more secure over time. I've seen some of our clients go from unknowingly writing insecure applications to having robust and mature Secure Software Development Lifecycles that drastically reduce the overall number of issues we find in quarterly assessments. These micro-trends, unfortunately, seem to be the exception to the rule.

These companies should also stand as a reference point for other companies who are finding themselves a target for attackers or that fear they are not doing enough to protect themselves and their customers from this type of attack.

Another correlation a colleague of mine, Tom Samstag, found while researching is the negative attention of a large data breach. After public attack hackers seem to swarm in, focusing their attention on other arms of the company. This makes sense from the attacker's perspective, the initial breach acts as a beacon to identify companies that do not have proper security measures in place.

We see exactly this this happening to Sony right now.

One month after their infamous Playstation Network breach on April 26^th Sony BMG suffered another breach on May 23^rd, then Sony Pictures was hacked less than two weeks later on June 2^nd. It seems the hackers smelled blood and came running, I wonder what will be next?

Of course it's easy to pick on Sony, but they're not the only company who has lost large amounts of data in recent months, far from it.

PrivacyRights.org tracks all data breaches, they report there have been 533,686,975 records breached in 2,511 Data Breaches since 2005. There are a lot of recognizable names in that list as well, chronologically speaking: Sony, WordPress, The Texas Comptroller's Office, Health Net Inc., Jacobi Medical Center, and American Honda Motor Company. Those companies have all lost more than one million records each in the last 6 months. Let me repeat that:

The companies named above have all lost more than 1,000,000 records each in the last 6 months.

In a recent Ponemon study it was found the average cost per record lost for the offending company was $214 per record, up from $138 per record in 2005. In this way Sony got away for cheap if the most recent numbers are correct in that their PSN breach only cost them $171 Million.

The study went on to conclude indirect breach costs, such as the loss of customers, outweigh direct costs by nearly 2 to 1. That means Sony could lose another $342 Million in customers, market share and customer confidence. In 2010 other companies spent, on average $7.2 Million per data breach. Talk about consequences!

Unfortunately it also seems more vulnerabilities are being found in software. Likely due to insecure coding practices, insufficient security measures and controls, lack of training, and the attacker threat increasing almost daily. According to an IBM study there were 4,938 vulnerabilities found in 2005, 6,543 in 2007, 6,737 in 2009 and 8,562 in 2010. See graph to the below for more data points.

If you've been waiting to see who has lost the most records in recent history, you can check out the PrivacyRights.org website, or Here is my list of shame: the most recent breaches that have lost more than 1,000,000 Records.

• Sony Playstation Network
  • 101.6 Million records lost
• WordPress
  • 18 Million records lost
• Texas Comptroller's Office
  • 3.5 Million records lost
• Health Net Inc.
  • 1.9 Million records lost
• Jacobi Medical Center
  • 1.7 Million records lost
• American Honda Motor Company
  • 4.9 Million records lost
• Educational Credit Management Corporation
  • 3.3 Million records lost
• Netflix
  • 100 Million records lost
• RockYou
  • 32 Million records lost
• U.S. Military Veterans
  • 76 Million records lost
• Heartland Payment Systems
  • 130 Million records lost
• Royal Bank of Scotland
  • 1.5 Million records lost
• Countrywide Financial Corp
  • 17 Million records lost
• Facebook
  • 80 Million records lost
• University of Utah Hospitals and Clinics
  • 2.2 Million records lost
• Bank of New York Mellon
  • 12.5 Million records lost
• TJX Corporation
  • 95 Million CC#’s lost
• Ameritrade
  • 6.3 Million customer records lost
• Hannaford Bros
  • 4.2 Million CC#’s records lost
• Fidelity National
  • 8.5 Million records lost
• Georgia Dept. of Community Health
  • 2.9 Million medical records lost

This is just a quick post because I couldn't find this information easily available on other sites. I knew there was a quick way to access the connection strings from the web.config file (and other app settings) without going through some crazy XML reader or doing something ridiculous like what http://msdn.microsoft.com/en-us/library/ms178411.aspx. I'm sure this is on the internet somewhere, but the more places the better as far as I'm concerned.

If you simply add the System.Configuration to your 'using' list you can use the ConfigurationManager class which exposes the AppSettings and ConnectionStrings easily. In this way you can access the ConnectionString from this single line instead of the block of ugliness MSDN suggests.

ConfigurationManager.ConnectionStrings["myConnectionString"].ConnectionString

Oh, by the way, this is the MSDN madness:-)

System.Configuration.Configuration rootWebConfig =
    System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/MyWebSiteRoot");
System.Configuration.ConnectionStringSettings connString;
if (rootWebConfig.ConnectionStrings.ConnectionStrings.Count > 0)
{
    connString =
        rootWebConfig.ConnectionStrings.ConnectionStrings["NorthwindConnectionString"];
    if (connString != null)
        Console.WriteLine("Northwind connection string = \"{0}\"",
            connString.ConnectionString);
    else
        Console.WriteLine("No Northwind connection string");
}

I've been working to add a few more features for WikiRater that I think are really cool. The one that I've had the most fun with so far is the "Trending Article" page. This page shows articles that are being rated right now. It works pretty similarly to reddit or hacker news, if you're familiar with them.

The other fun feature is the Random Interesting Article. This will find an article with an average rating of 8 or higher. If you're logged in it'll make sure you don't get an article you've already rated.

Finally if you're logged in and browse to your User Page you can see a list of all the articles you've rated, and what you rated them. This is a nice feature if you want to try to track down that elusive "Alphabetizer" or "Nice Distribution" achievement.

I'm going to write a follow up post on the inner workings of these features, but for now. If you haven't already go sign up and check out the cool new features!

A great way to make sure you don’t get distracted from the tasks that are most important is to keep a todo list. I used to keep three todo lists, one for today, one for this week and one for “someday.” My technique goes something like this:

The Technique
At the beginning of the week I outline all the accomplishments I want to make for the week then I prioritize them and put the most important (ranked by impact) at the top, and least important at the bottom.

At the beginning of each day I select the number of items off that list (and sometime break them up into subtasks) that I think I can accomplish during that day. As my day goes along I can refer back to this list to know the next thing I need to accomplish. I never have to question whether or not I’m working on the most important thing because I’ve already prioritized my tasks at the beginning of the day.

At the end of the day or at the beginning of the next day I look at my list and if I haven’t checked each task off I try to figure out why and what I could change to ensure I get better results the next day. Reasons may include: I under estimated the amount of work each task was going to require; I wasn’t feeling well and didn’t have the amount of energy I thought I would have; I got distracted by another task.

If the issue was that I under estimated the amount of work each task was going to take I try to learn from that mistake so my estimation can be better for tomorrow or next time.

I understand that some days I will be more focused or have more energy than others, and that’s OK. If it becomes a chronic issue though, there may be something else to blame. Am I lacking the inspiration I need to be excited about this task? Are there other external factors at play (sleep, stress, summer sunshine, winter powder)? If I lack the inspiration I try to find my “why.” If it’s an external distraction that’s keeping me from focusing I try to reset my focus by carving out time to dedicate to those things.

The last reason I don’t get everything done I want to is usually the most common. I got distracted by another task. If I see that I didn’t accomplish everything I wanted to accomplish that day because I was distracted by some other task I have to ask myself if that was the correct decision. Was that task more important than the thing that I didn’t get to? If I can honestly answer yes, then it was the right choice, and I did what I should have done. If it was less important than what was dropped I reassess my prioritization and make sure the task gets done the next day.

I use a similar technique to ensure that I’m staying on tasks at the beginning and end of each week. Assess what I accomplished (either on the list or not on the list) and analyze what I did not accomplish.

The Tools
In order to use this technique you must be absolutely diligent about keeping track of your tasks and results. This means that if you do something that’s not on your list make sure you write it down for later assessment.

I started this technique with a basic pen and paper approach. My office mates would often laugh at my notebooks that had lists and lists written all over them each item scribbled in and crossed out. I get great pleasure out of crossing items off my list, but keeping my list in order is very difficult, and usually requires rewriting the list or keeping the list double spaced so you can squeeze items between. Additionally I’m a nerd, by any measure, so I seek digital solutions that will give me the most efficiency, so this is clearly not the ideal solution.

I burned through many task list applications, web sites all met with greater or lesser success. I’ve tried Remember the Milk, Evernote, and Google Tasks Lists. I liked Google Tasks the best because of its blazing speed and ease of use. Remember, for a todo list to be useful it has to be nearly transparent to your daily work, or you won’t use it.

My wife turned me on to teuxdeux which I really like. It’s fast and easy to use, but it adds the ability to add tasks to different days of the week. This lets me plan a little better and lets me offload tasks that have specific deadlines early so I don’t have to think about them before they’re done.

No matter which tool you end up using the important part is to assess your progress through the tasks you outline for yourself and to write down every task you accomplish during the day. The great thing about writing down everything you do and crossing it off is that you have a beautiful list of accomplishments. Exactly what I need after a long day at work!

As I previously mentioned I’ve been writing a bit of Ruby on Rails. I’m surprised at how quickly I can slap something together and get results, especially prototypes, up and running quickly. 

Technical Debt is generally defined as the eventual consequence of building software in a quick and dirty way. This most commonly occurs when a developer jumps directly into writing code without architecting or thinking through the solution. Usually a solution is spit out prematurely and will quickly fall over under heavy load or stringent testing.

The opposite of this would be to slowly build skills, tooling, requirements, specifications, tests, libraries, etc. until the problem is well defined and it’s just a matter of converting requirements and specifications into code. The problem with this is it is SLOW.

Other development techniques have been developed to bridge this gap. To provide the right amount of guidance when it’s necessary, but not so much that we develop requirement paralysis. TDD and Agile are two techniques that come to mind, but other technological solutions such as Object Oriented Programming, fantastic libraries and frameworks also help us get results and make headway quickly.

Still there will come a time, even with TDD, Agile, OOP, and a framework that makes you happy, when you have to decide between the right way, and the right-now way. At these times it’s important to know how to weigh those decisions properly. Here are some questions that might help you decide whether to build up technical debt or to build your software in a more measured way.

How long until the next version? – if this is a quick demo version that will be completely replaced it makes more sense to build it quickly leveraging anything you can get your hands on, using the skills you have now, rather than trying to learn a new tool. However, if this version has to stand on its own for an extended period of time, real customers will use it or if it will have to stand up to heavy live testing or load then you may not be able to cut corners.

How many customers are likely to become dependent on this? – Don’t forget that you may not just building up technical debt for yourself, but also for your customers who rely on stable software to build their solutions on. Changing large amounts of the software under existing customers can be difficult, you may even lose some of them to a competitor. Preserving perfect backwards compatibility makes it easier for your customers but forces you to shoulder the whole burden of your technical debt. Making this decision too many times can cause you to lose revenue to support and maintenance staff.

Is there an easy way out? - Using layers of abstraction to firewall the well architected pieces from the “quick and dirty” pieces is a good way to be able to componentize pieces that need to be replaced later. Before laying down thousands of lines of code ask yourself “How easy will it be to replace the technical debt pieces?” and if it’s going to be easy or there’s a way to make it easier on yourself then you might have the right decision. If your technical debt is taking a large dependency (for example a framework that is not well supported and will need to be replaced) then it may not make sense.

How likely will it be that you’ll have time to pay down your technical debt? – If you work at a company like most of the people I talk to you probably have a stack of todo items five feet tall and the only way anything ever gets done is if it is figuratively and sometimes literally on fire. If that’s the case then paying down the technical debt when you have a chance so you do it right the first time makes the most sense which will reduce future headaches. However if you need to release something right away and you know you can schedule time to return to the pieces that need attention you may be able to take on some debt without too much risk.

What kind of load will your application be under in this version? – If you’re anticipating very heavy load immediately upon release performance needs to be in the forefront of your decision making. One of the best examples of this is twitter; they were able to slide by on a shaky ruby-on-rails application until they grew to be one of the most visited sites on the internet. When they were in the throes of their growth pains we saw the fail whale often. They’ve had to quickly pay down their technical debt by replacing most of the backend of twitter with scala, memcache and starling, erlang, MySQL, Mongrel and more.

How much (real) market pressure is there to release a solution immediately? – Sometimes we feel every day we don’t release is another day people are filling the terrible hole in their lives with some other product. Unfortunately or fortunately this is often not the case. If we look at many examples of current market leaders they weren’t the first to market, but the best. The first mp3 player wasn’t the iPod, the first windowed GUI operating system wasn’t Windows, the first (nor the last) social media site was facebook. If you’ve promised a customer or client a solution it’s good to be on time, but if you don’t have customers shipping a half-baked product may give any potential customers such a bad taste in their mouth they won’t reconsider when you’ve had a chance to repay that technical debt you built up.

Many times it’s more important to get something out to get traction. As I mentioned in my “Let the pedestrians define the walkways” blog sometimes it’s better to get traction and feedback with people now and build up a little technical debt than to build a perfect solution that nobody can use.

Remember until you release nobody cares how fast, well architected, well commented or beautiful your software is.

I recently went home to see my parents for Thanksgiving. NPR was playing in the car and a short story came on that struck close to my heart in two ways. It was about how to pull off a seemingly effortless multi-course meal by effectively front-loading most of your heavy cooking to prep work so that all you have to do when your guests arrive is to ‘finish’ each dish. This means that absolutely everything that can be is chopped, blanched, steamed, mixed or even completely ready to serve (in the case of many deserts) before your first guest arrives.

I like to post my own thoughts here, but I just read a short blog on Derek Sivers' blog that really hit home for me. He tells the story:

A new green college campus was built, but one thing was still debated:

Where in the grass should we put the paved walkways?

Some felt the walkways should be around the edges, to leave the center green and untouched.

Some felt the walkways should cut diagonal, connecting all buildings to all buildings.

One professor had the winning idea: Don't make any walkways this year. At the end of the year, look at where the grass is worn away, showing us where the students are walking. Then just pave those paths.

I love it! I've seen so many places that have beautifully planned out landscaping that is marred by efficient pedestrians that know that the shortest distance between two points is a straight line.

He goes on to say how we can model our business after this plan. This follows the use of rapid iteration model of software development.

Listen -> Build -> Release

Listen to what people need, listen to their pain points. Build something lightweight that you think people will love and that will remove their pain, build it quickly. Release it before you think it's done. Go back to listening, listen to what they like, what they don't like, and what they want. Go back to building, build what they want. This reduces the amount of time you spend concocting crazy use cases or user models that may or may not exist or spending too much time building something that nobody wants and let's you leverage the wisdom of the crowds. When you're done building you know that you have something that people want to use because they helped you decide on the features.

One example of a company that doesn't seem to do this is of course Apple. Apple (an to an extent Google) has an incredible ability to anticipate what consumers want before they know they want it. To be a true market leader and leap over the competition risks like these are not only desirable but necessary. There is often a time when a consumer doesn't know what they want or need, they just know they don't like what's out there. What was wrong with the Philips GoGear? Before the iPod Touch came out I don't know if I could have put my finger on it. It took Apple's leap of design and development before I realized how many features were missing. This model is significantly riskier, but like all things with risk comes the potential of reward.

I use the words Goals, Results and Activities.

A quick definition might be that a Goal is a long-range target. A result helps you, your company or your team succeed. Activities are the smallest unit of work that helps accomplish a result or goal.

You can think of an activity as a single step in a journey. It always takes work to make a step, but the step does not always get you closer to your goal. Of course the lesson is to check your compass and map periodically to make sure you’re always going in the right direction.

Goals
Goals are long ranging strategic targets. They can be self created or defined by your manager or company. An example of a strategic company or team goal might be "Be profitable in Q3" or "Ship Version 3.5 of our Product." We define goals so that each individual to look up from their daily tasks and see how it fits in with the goal. This helps people know when they’re on track and helps them feel like their making a difference and not just a "cog in a wheel."

Personal Goals are a very important piece of my happiness. When I can accomplish a personal goal or can see myself making progress on a personal goal it gives me great satisfaction. Personal goals don’t have to be anything more than something you’d like to do. I can give examples of personal goals, but it is important for you to find your own passion. For me it is to Run a Marathon, Compete in an Olympic distance Triathlon and help my non-profit, Technically Learning, meet our donation goal this year.

Results
Results are all about impact. The best results have the highest impact. Impact can be defined by how much closer completing that result will get you to the goal. I’d like to dedicate an entire blog entry to getting results, but for now let’s move on to tasks.

Tasks
We define our tasks by splitting up larger blocks of work. We can then prioritize those tasks by what will give us the best results and the greatest impact. It is important to reflect daily on your task list to make sure the tasks you are completing still align with getting the best results and align with the overall goal. Don’t get so focused on the individual tasks that you lose site of the goal. Tasks are meaningless if they don’t get the results.

Have you ever known anybody that seems to be constantly busy or overwhelmed but never seems to accomplish anything? They may be simply choosing the wrong tasks and by the time they’ve completed their task list, the goal has changed and their work is lost.

Remember: high activity does not necessarily imply high impact.