Michael N. Dundas

Well written article by a former manager / advisor to me entitled “What I didn’t get for Christmas.”

I was catching up on some of my reading last night when I couldn’t sleep. A friend of mine had posted a link to an article on the difference between ‘traditional workers’ and ‘web workers’. Personally, I definitely fall into the ‘bursty’ or ‘web worker’ category and my office I realize has a ‘mix’ of both types.

I as most in Canada have been following Maple Leaf Foods and the listeriosis outbreak. I drive approximately an hour for work 3 or 4 times per week and usually listen to CBC. Along with reading a few news articles on the web has allowed me to keep up with the public version of events.

Michael McCain really impressed me. His public apology was probably the most genuine and sincere I have ever seen from a CEO. I think a lot of businesses could learn from him. I suppose that it could all be staged, but regardless it was a nice change from what a business typically does when they are the center of an issue with negative tones.

I was reading about a press conference Michael McCain gave on August 27th and suddenly something didn’t make sense. Michael McCain said that Maple Leaf should bear all the costs and responsibilities of the outbreak. Specifically:

“I absolutely do not believe this is a failure of the Canadian food safety system or the regulators,” he said at a news conference in Toronto on Wednesday afternoon. “Certainly knowing there is a desire to assign blame, I want to reiterate that the buck stops here.”

Contrast McCain’s statement with an Interview on CBC (podcast of Interview is here) on August 25th with Linda Smith, a spokesperson for Maple Leaf Foods. Throughout her interview Linda Smith ensured the public that Maple Leaf Foods followed the protocols of the Canadian Food Inspection Agency and Health Canada exactly and never deviated from them. Comments in the interview included:

• manage exactly to the CFIA protocol
• manage to absolute exactitude
• We live and breath those protocols and have never deviated from those protocols
• All facilities follow to an exactitude the Heath Canada’s management protocols
• We did everything that we are suppose to do
• Moving forward going beyond protocols and testing all products. With a hold and release procedure
• Followed the food safety standards to the letter or exceeded those requirements.

I am not a food services expert, but common sense dictates that either Michael McCain or Linda Smith must be mistaken. If Maple Leaf Foods did follow all the protocols then there is obviously a problem with the protocols and they need to be reviewed at a government level. If Maple Leaf Foods didn’t follow the protocols, then Linda Smith is mistaken. So which one is correct?

UPDATE:
Post on how the CFIA is still continuing a plan to lower inspection requirements for domestic meat products.

Ever wonder how true those software piracy statistics regarding the amount of pirated software, amount of money and jobs lost, and other statistics are? Well like most things, you can ‘adjust’ them to your benefit.

An excellent analysis by Mike Masnick on some of the latest numbers. The part I like the best is that the group responsible for producing these numbers, the Business Software Alliance has been made aware of it, but chooses to ignore it.

I was having lunch with a friend of mine today. He brought up “The Tiger Effect” that had happened during the U.S.Open. Specifically he asked what is going to happen to service providers in a few weeks when the Beijing 2008 Olympics commences? If the U.S. Open was able to cause a noticable effect, then theoretically the Olympics would be worse.

I think there are many factors that will affect the network response and what service providers will be faced with when people are viewing the Olympics online. Design of the networks used by the Olympics, deployment of the Internet feeds, scaling of the servers, application choices to deliver the content, how everything is configured and many other factors. With the U.S. Open it all culminated to the one event at a specific time. This could happen with the Olympics, but it might be seen as more of a constant increase in streaming protocols and HTTP as there are many events simultaneously. Of course the finals for each event could have similar characteristics to the U.S. Open along with the opening and closing ceremonies, potentially with many more viewers. What I wonder is if any service providers are proactively preparing for this possibility? I guess we will see.

It looks like “The Tiger Effect” had an ‘effect’ on the stock price of Nike as well.

When I first set this blog up, it was just to see what blogging was like and if it was useful. I don’t just blog for the sake of blogging, but I like the idea of things I find interesting or am working on in one place that is easily accessible and I can go back and reference if necessary.

Since most of my days (and nights) over the last few years have been dealing with tier 1 service providers around the world and their security, I figured it would mainly be based on those experiences and the security research that I do. I couldn’t think of a good name, so I picked the obvious ’security’ — not very creative.

The problem with the title ’security’ is that the blog is turning out to encompass more than just security. It has technical papers I have written, comments on things that I feel are important such as physical security, privacy concerns and whatever else I want to write my comments on and track. I considered starting multiple blogs but I have enough trouble keeping one blog and often times a issue in security can start with a technical paper which grows to discussions about architecture and then to politics, law etc. I want to be able to keep these things together.

With respect to technical security publishing, I am still working on what I can technically publish and what I can not. Given the work we do and our customers, I have to be careful what I write about on the blog. Since I work for a company that relies on research to build products that assist our customers, I have to ensure that I won’t expose our systems or our customers systems in anyway. That being said, my goal is to have either my research and articles published here, or at least comments on it and reference to a publicly available version of it.

I wrote a blog post the other day and referenced ‘Kaizen’. This seems like a good title to me, so I’ve switched the name of the blog. No big deal, but for anyone wondering why it changed now you know. If you go to the old URL http://security.michaeldundas.com it will continue to work. That URL now goes to a web server that will issue a HTTP 301 code which is a notification of a website that is moved permanently and redirect you to the new URL which is http://kaizen.michaeldundas.com.

Completely not security related, but physics related. I’ve always liked Physics and even managed to take a first year physics course as an option while I was in University. A colleague of mine Mou Mukherjee pointed me to software called Phun a 2-D physics sandbox. A youtube video showing it actually being demoed can be seen here. Kind of cool. I’m going to download it and play with it when I get some time.

My title “The network never lies” might seem a little bit naive. It might be better to say “the network lies the least.” That has been my experience to date. At my first real job I was working at a bank taking care of their Internet connections (this is going back 10 years or so). My manager there (probably my best manager and by far smartest manager to date if you include technical understanding and abilities, and political experience) when engaged in solving a problem time and time again always ignored the application logs and errors initially. He would take a look at them briefly, but if it wasn’t obvious in the first few minutes, he would pull out the network analyzer. He’d pull back some packets, take a look and in a few minutes say “there is the problem.” Sure enough it was, often completely different than the error messages the application or the logs were showing. He said to me one time while working on a problem “The network never lies.”

Now I may also be a bit biased as my background is networking and I’ve worked with networks for a long time SNA, Novell, and IP. Regardless of the type of network I find the same thing. By simply using Wireshark or another packet analyzer you can save so much time solving the problem.

Case in point. A friend of mine has a law office and about 15 employees. Years ago, she was in a bind with a really bad consulting firm and being friends she asked me to assist. I redesigned her network, as well as her applications, security, permissions, etc. Basically the entire network, servers, and applications. The office is completely paperless and has been for about 7 years now. Unfortunately, most legal applications require Microsoft proprietary servers, and databases so although there is some Linux emulation in the environment it is minimal. Recently a new large server was purchased and the environment was to be totally upgraded and placed on the new server. The new environment includes Vmware, as well as the latest in Microsoft products.

During my holdiays, I have been leading the charge to properly get the new system set up, data migrated, backups working, security in place etc. One of the first steps was to set up a new active directory instance and make it a primary domain controller and have it take over the FSMO roles. Creating a new active directory server and connecting it to the existing active directory instance was trivial. Attempting to migrate the FSMO roles, caused multiple failures with erroneous error messages. These errors created hours of searching the error messages on Google and Microsoft support sites, and reading forums on the problems and causes. Most solutions turned out not to work, or were not the actual problem. Most of the error messages presented by Microsoft were not even close to what the real problem was. Frusterated, I started Wireshark, and captured a trace. Low and behold, a DNS query for some long weird string was failing. The long string turned out to be the GUID. Manually entered this and presto, FSMO roles migrated with no issues. Why a GUID? Why not just a server name? No, no that would be to simple, let’s make it complex?!?!

In my line of work, I am constantly told by software engineers statements such as “Look at the logs”, “what is in the database”, “why do you need to know that?”, “you don’t need to see that information”, “you don’t need tcpdump” and other similar lines. I of course always disagree with them which I suppose frustrates them. My experience above always seems to work or at least greatly reduce the time to solve a problem. Look at the network is the lesson from years ago I am reminded of time and time again.

Now maybe I am a bit biased. My background is networking and security. I’ve always liked networking and my understanding of it is pretty good. I would suggest however that applications, sub systems, and kernels need to be smarter on logging errors, especially in the Microsoft world. They should always have the ability to easily turn on a debug mode without having to go to a registry, flip a bit in Hex, and reboot or some other complex sequence of events. And why is everything in the Microsoft world so interdependent? DNS is required for Active Directory and it has to be Microsoft DNS, without a lot of work to use a different DNS. Microsoft Exchange requires IIS web server to be running? It’s like a big monolithic interdependent system design. I guess I am digressing and this is a different topic for a later time.

Moral of my story is: The network never lies (for the most part anyway), and Wireshark or a packet analyzer is a good friend when it comes to solving application problems.

My wife and my ‘non-security’ friends think I am too paranoid. According to them, I overreact to simple situations and am too cautious. I’ll admit there may be some truth to that, but this is a perfect example of why I feel I respond this way. A family sound asleep in their home. Husband hears what he thinks is a robber outside. He grabs a kitchen knife and goes out to investigate. He is met by a swat team that has surrounded his house. He and his wife are handcuffed. They are released when the police determine that there is not a kidnapper holding them at gun point in their house. Why did they think that was the case you ask? Someone hacked the 911 emergency system and placed a call that appeared to come from that house saying they had a gun, had already murdered one person and were going to shoot others.

I don’t think the police did anything wrong or overreacted, but it could have gone bad. The husband could have been shot by an officer reacting without thinking due to lack of experience or fear. The simple answer is ‘well he should have just called the police and not investigated himself.’ Although that may be true for this particular circumstance, there could be other circumstances where it is not that simple. Do you call the police as soon as you hear a noise? I don’t. I usually grab my kali sticks and go take a look. You can’t burden the police with every single issue without checking the seriousness of it first. If everyone just called the police as soon as they heard a suspicious noise or saw suspicious activity, the system would break down and the bad buys would win because the police would be busy constantly answering false alarms. In my city if I call the police for a noise that turns out to be nothing, they will actually fine me.

Six months later they finally caught the person that did this. Hopefully, I am just being my paranoid self but I fear this is just a small sign of things to come. Too many things hooked up by networks and computers and not enough time, money, and expertise spent on actually securing systems.

A colleague of mine had a reference to these Internet maps on his blog. Thought it was cool, so I am adding it as well. They use The Dimes Project data to map the Internet. I was chatting about the sample sizes as that could seriously affect the graph. If there are only a handful of people in Australia for example that are involved with the Dimes Project versus many more in Europe, that would obviously affect the look of the graph. Still neat though.