Places To Go
News and Reviews....
People To See
Places To Go
Tuesday, July 12, 2011
A friend of mine forwarded me a link to a provocative paper by Microsoft Research that called into question whether the security advice provided to users for their online activities is useful based on a risk-reward calculation. The link and the PDF document can be found here
At first glance I thought that the paper was doing harm by dismissing user security as simply not worth attempting, but that is not the point. The point is that the advice provided to users is often hysterical and out of touch with the real world. This is something I have believed for a long time. So rather than just say,
"yes, that is right, we are screwed", I want to offer up the advice (and mandates) that my own employees and family get when dealing with the security aspects of online security. Here are my Rules of the Road if you will.
The password to my network must NEVER be used for anything else. Violating this rule is worth your job.
If your password is long enough then you never have to change it, except of course if it is known to be compromised. My password to my domain is over 50 characters and it is a pass phrase so since I have never told it to anyone, never written it down, never used it anywhere else, I feel no need to change it regularly (I do change it over time, but not monthly or even quarterly).
You should type in web sites yourself rather than click on links. If your bank sends you an email that something is wrong or they need to talk to you either open a new browser and type in the bank's URL and login that way or call the bank using the number on the back of your credit card or on your last statement. Phishing is the biggest trap out there and always being suspicious of every link in every email is the best defense unless you are a security expert with alot of knowledge of TCP/IP (hint, if you didn't understand any of that you are not that expert).
When in doubt close the browser (and if you like for good measure open up task manager and kill all browser processes).
Have a password plan. For me there are 5 levels of passwords. Level 1 is for sites I just don't care about, but need a password anyways. I use a low security password but a password none the less. It is over 7 characters and has a number in it. Level 2 is for sites that I would not want a stranger browsing as me, but are not a risk to my reputation or my finances. Level 3 are sites like social network sites where I would face some embarrassment if someone hijacked it, but not financial loss. Level 4 sites are things like banking and I have very few of these and while according to my rules I could reuse passwords on this level I choose not to. Level 5 is of course the password for my business network and it stands alone.
If you find the need to write down your passwords then either get a password keeper program like whisper32 (there are many to choose from). These programs are not hacker proof, but the hacker needs to get pretty deep to be able to even start attacking these kinds of programs.
As the X-Files taught us, "trust no one! If someone asks for your password for anything stop talking to them no matter how the topic arrives.
Those are the highlights. I don't try to make users security experts, but I seek to help them exercise some best practices. I am thinking of making this into a presentation for user groups and expanding it out with examples and much more detail.
Monday, May 23, 2011
I am happy to announce that very soon I will be providing a monthly article in the SD Times
on Microsoft Technology.
With this regular writing task to spur me on I expect (and hope) to be doing alot more blogging as well...
Sunday, February 27, 2011
Recently I have had two of my most senior employees come to me seperately and suggest new products for the company to build. I encourage this of course, but find I have to help them understand some things about what I call Disciplined Entrepreneurism.
Ultimately when you decide to build a product for general sale you have three choices:
1. Invent something
2. Copy something
3. Enhance something
Each of these has its strengths and weaknesses. For #1 you have to really have a good idea and you have to bear the burden of educating the world they need something they never had before. In path #2 you have to make sure you can do it so much better that you can overtake the current vendors. And with #3 you build an add on to an existing product as part of its ecosystem, so that means your only customers are the people who bought the thing you are enhancing.
None of these is easy and none is a "sure thing". I find that it is a slow road with luck and hard work playing equal roles in most cases. Misjudging the market is a common mistake, but not doing any market research ahead of time is by far the most common mistake.
Our head developer of our FSM product, Amr (he specifically asked me to mention him when I told him I planned to blog about this), throught that it might be a good idea for us to develop a Facebook Application. My response was to point out that Facebook, iPhone apps and other applications seem like a great way to get rich, but the failure rate is enormous
my research says that it costs tens of thousands of dollars to bring one to market successfully as very, very few make any money at all the average lose money if the idea is good enough then you have a better chance, but everyone thinks they have the killer idea. The costs go way up if you advertise it with some having spent as much as a million dollars. There really are no shortcuts to wealth
You should never just build an application. You should first figure out the odds of it actually making money otherwise you spend your life just writing code and never make any headway.
The key is to jump in before the market gets too saturated and to do some pragmatic thought about the potential of your product idea. Rather than look to Facebook or iPhone apps I think Windows Phone 7 applications is a much better landscape since there is still room for new players to make a mark. Just remember that you have to tamp down your wishful instincts...
Sunday, February 20, 2011
While I resisted Twitter for a long time, not too long ago I started following selected individuals on Twitter including Richard Campbell (richcampbell on twitter). I plan to start using Twitter myself hopefully to communicate things of value, but for now I am using it as a comsumer.
This morning Richard tweeted "Four things to write this weekend... is it wrong to do them in the order of how much they pay?". This got me thinking about my own task juggling over the years. When I was in college I learned that there are times that you have more to do than can humanly be done. This was in fact a central part of the pressure West Point put on us while we were cadets there. To cope I came to the conclusion that the juggling metaphor is quite apt. The thing to realize is that not all balls (tasks) are created equal. Some are made of rubber and some are made of glass. Rubber balls bounce and you recover even if you let them drop from time to time. Glass balls shatter if you drop them even once. The key is to identify which kind of ball a task represents and there lies the rub.
We see the same decision points when we undertake software development. I try to tell people over and over that security is a task of glass.
For the record, I think Richard has his priorities correct all things being equal...
Thursday, February 17, 2011
IBM has decided to build the mother of all Cloud Computing data centers in of all places, China. I will advise all that will listen that this is a fantastic blunder since China is the absolute worst choice for such a resource. I do not want any of my corporate code and data or the data from customers housed inside China.
Don't get me wrong, I am not xenophobic by any means and am even not violently opposed to offshore development or data centers. The problem is that China is the capital of corporate espionage and the worst offender in the world of not respecting the intellectual property of others.
This is a big win for Microsoft Azure and Amazon unless I missed similar announcements from them (which I doubt).
The first mission of a Cloud Computing provider is to provide security of the data and I just don't see that happening if the data is in China.
Tuesday, February 15, 2011
If you looked into playing with Azure in the past, but did not jump in then it is time to take another look. Microsoft has added options over the last year that really remove objections to trying it out. If you have an MSDN subscription then you pretty much get a free playground in Azure that is going to waste if you don't use it and if you don't there is still the Introductory Special that goes through the end of March that gives you access to the basics of the service at no cost.
To look it over go to the Windows Azure Offers page at Microsoft.com and get going. You might not have a project that fits the Azure model currently, but you will. I am working on a new product for DTS that will have an Azure component and while it is still off in the horizon the time to jump in is before you are behind.
Friday, January 28, 2011
I have talked to many of you over the course of the past week and have been cautious due to the fact that I was concerned for your safety. A failed rebellion is a painful thing especially when it is not known who will lead the aftermath.
Now that I see the resolve in my friends there I know that this is not a rebellion, but a revolution that deserves the support of all of us who have ever had their country ruled without democracy.
I wish I was there and could stand in the streets with you, but know that you are in my prayers and I am proud of each and every one of you. Good luck and may you win the day and your destiny In Sha Allah!
Thursday, December 30, 2010
My friend and collegue Adam Cogan
is a big proponent of documenting best practices. In fact his company, SSW
puts all kinds of lists of these best practices up on their website.
Recently Adam chimed in on a list we are both on with a link to the best practices (Rules) around setup and I realized that even if you know a topic well you should go back to the well from time to time to ensure you are still on the right path. I think back to the days when coding by stringing together user input to make a SQL statement was accepted as the way to build a login form (before the first SQL Injection attacks). You have to seek out other sources even (maybe especially) on things that you hold yourself to be an expert with. I now find myself reviewing how we do setups at DTS to make them better and finding Adam's advice to be a very good source of points to contemplate.
Monday, December 20, 2010
has a compiled document with all his blog posts on SQL Myths that I think is a must read if you consider SQL Server part of your core competence. It is probably not very interesting to pure devs, but I would still suggest you take a scan of this so you can avoid making assumptions that are either out of date or just plain wrong.
Find the link to the PDF here: http://www.sqlskills.com/blogs/paul/CommonSQLServerMyths.pdf
Friday, December 17, 2010
We have a saying in the various companies with which I associate and it is "Any fool can manage success, but it takes talent to manage a crisis". The leader, project manager, team leader, or whatever you call the person in charge has to not be wishful. This sounds easy, but in my experience it is one of the hardest things to do for any individual. We tend to be hopeful and that is the slippery slope / gateway drug to wishfulness.
The reason I say this is that my own biggest screw ups are almost all tracable to some point in the past where I assumed that something would happen more positively than it actually did. This sounds like the classic admonishment against assumption and to some extent it is, but wishful is more of the root cause and assumption the symptom.
As an infantry platoon leader in Iraq many years ago, I learned that you are never done planning for and defending against the things that can go wrong. When you envision contact with the enemy it is easy to expect that things will follow the simplest route and flow like water, but since there are humans involved this is highly unlikely to be the case. You might even get lucky and survive this way once or even twice, but that just means you are more likely to get killed when your luck runs out. I try to run projects the same way. What if the components that should work fine together don't? What if the client changes the deployment server to run a 64 bit OS instead of the 32 bit OS on the test server? What if there is an illness or death in the family of my key developer the week before delivery? You can drive yourself crazy with these things and I am here to say that you should. That is the job.
The first place to start is by making plans and schedules with milestones. If you are collaborating with others it flushes out wide variations in viewpoint quickly. Either I accept your timeline or propose another (assuming I am not totally whacked). If I propose another you might discover that it just won't work early enough to do something about it. I have seen good resources fail to deliver items well within their ability due to time wasted assuming everyone has the same, sane view of what needs to be done by when.
And to top it all off if you follow this advice and try to plan for all possible outcomes, there will still be surprises and things that you did not count on which is good because otherwise we could write a program to replace your part in the show...