Places To Go
News and Reviews....
People To See
Places To Go
Sunday, December 04, 2005
A friend of mine who is doing business with us posed an interesting question about the digital nature of our contracts. He said that with paper contracts you have the original that can be examined for changes and modifications. You can’t white out a term or condition or add a few zeros to you compensation without someone being able to prove that you altered your copy. Plus the both parties tend to keep a physical copy for comparison in case of one party contesting the contract. In many cases we do business with contractors via a contract that is emailed as a PDF or sometimes as a Word document. The contractor prints the contract and signs it. Often we get only the signature page faxed back to us.
My security minded friend points out that, “it is easy to add or remove any word using any number of tools, in other words I may add an extra zero for my salary or change any thing, so how this issue is solved using digital contracts?”
My answer is that we ask the contractor to fax back the contract with a signature. Our records in email show us sending them a specific document. Without email documentation confirming changes or a new document sent to them there is support that the signature is based on the document we sent. While it is possible to change systems, it usually leaves detectable footprints and it is unlikely that we would do contracts with 10 or 20 people in the same geography or job type and dramatically change the contract for one individual. In this case if the company typically uses similar contracts it can be a benefit in supporting their side of the claim. Ultimately the courts typically do the right thing in this regard and can decide when something has been altered, even when done expertly.
Even so, there is nothing like a confirming email after the contract is sent and another after the signature is received that covers the essence of the deal to add proof of your intentions in the face of an altered contract.
If you want the real answer then you likely have to ask your own legal counsel as I am not actually a lawyer or trained in the law beyond the basics of military law. The point of this is that here is another vector for manipulation and attack. Have you planned for how you would respond?
Monday, November 21, 2005
I try to read the blog of Dave Hitz, one of the founders of Network Appliance, and while I don't link all the time I found one of his entries pretty on topic.
Like my title above, Dave stole the most provocative words from his post to stir interest. His post is titled, "Beware of Cyanide Gas".
Another fine example of security is such an arms race. I recall talking to clients just a couple of years ago and the standard was that server disks should be wiped and then destroyed. That is still the standard, but the definition of destroyed keeps moving on us. Dave points out the ridiculously small slivers of intact disk platter needed to read data and the reaction of one our our more security conscious customers was, "I guess we will have to add an acid bath after we sledge them...".
A big part of this battle is just staying in formed on what can be done and then figuring out whether you care or not. If you have passwords and huge databases with Social Security Numbers or Credit Card numbers then letting someone read even one sliver of the platter may be disaster (though small by today's standards as massive security blunders go).
Always think about the level of response based on the threat. If a serial killer escapes in your neighborhood then you are justified to double the locks on the doors and get a bigger dog, but if they escaped 3,000 miles away from you with no history or indication that they would come looking for you then you are overreacting. If you apply these same standards to your electronic response then you will probably come out alright.
Lastly, as always watch out for the cyanide gas!
Thursday, November 10, 2005
I had a conversation with a friend of mine recently about the physical protection of his home. I have a bit of a reputation as a gun enthusiast that is somewhat earned. What surprised my friend and got him to urge me to post this entry is that my advice was a surprise to him and something he admits he had never heard before from anyone.
The issue wasn't computer or even company security, but security at home. How do I protect my family in a world where convicts escape, kids kill and home invasion is a common occurence? I do have weapons including an AK47, but they are not ready at a moments notice. I have kids so I have bolts out and disassembled, ammo stored away from the weapons and trigger locks (in the case of the AK there is a cable locked through the barrel). I can't just run and grab one of these weapons for the defense of my home and that works since that isn't my plan. We have 3 dogs who average about 70 pounds each and should they alert me to a problem I am most likely to grab my paintball gun or a wooden sword to join the fray. If I confront an intruder in my house with a paintball gun then there are several advantages. I won't be having rounds going through walls and hurting my family or pets, I won't be causing a fire or water damage with paintballs, but if I put 20 rounds into someone at close range they will be down. Anyone who has played paintball knows what I mean, especially if they have been hit from 10 feet or less (not recommended). I live in NH which means that I am unlikely to be prosecuted should I kill someone invading my home, but why make killing the person a goal? I view it as impossible for a court to convict someone if they choose an obviously non-lethal weapon especially when given more deadly alternatives.
I know this seems to be off the topic of security as it relates to technology, but if you have been reading my posts you know that I don't see a distinction in most cases. Security is security. I would welcome your comments on how this concept (well recieved by all I have discussed it with) might apply to technical security. I will reserve my analogies for now.
Thursday, November 03, 2005
Mark Russinovich is a brilliant guy and likely not so popular with the people at Sony these days. Mark was testing out some root kit detection and removal software and discovered that in their exuberance to implement Digital Rights Management Sony has created a very ham handed solution that behaves more like a rootkit than some of the very worst actual rootkits out on the Internet.
Read Mark's Blog which details his discovery or go to theregister.co.uk article that summarizes it. Good reading about bad code!
Monday, October 31, 2005
A friend of mine has a system that will require them to generage a large number of username and passwords for their users and they want to use usernames that make sense to the users. That is a common request, but he is concerned that a saavy user could deduce the username of others based on theirs. This is a real possibility (or likelihood) if you use any of the standard methods such as employee number (just guess sequential numbers) or combinations of first and last name.
My response is as follows:
It is as always a tradeoff...
If you use a determinable username then the password must be that much more secure. Ultimately we accept that user names are often guessable (in most systems), but just because that is a normally accepted risk it does not follow that it is OK. Password guessing is a numbers game. If we go to the simplest case of a single character password using a standard character set (alpha upper case + alpha lower case + digits = 26 + 26 + 10 = 62 possible characters) then there are only 62 guesses needed to get in once the username is known. As we add more characters to the minimum password length then we approach numbers where brute force attacks will take a long time provided the password is not in a dictionary (my dictionary for such attacks has over 5 million words and well worn passwords). At 6 characters you are at 56,800,235,584 (over 56 billion) possible combinations assuming the simple character set I mention above. On average an attacker trying every single possible combination will stumble on the correct one before they finish every combination. Keeping that fact out of the discussion we have to decide if we think a user can hit the site 56 billion times in a reasonable span of time to guess the password. Drive minimum password length to 8 characters and we are at a healthy 218,340,105,584,896 (over 218 trillion) which is where I like to be.
This is very secure given one critical assumption. It is assumed that the overhead of making a web request to test a guess adds enough overhead that you can't hope to achieve millions of guesses per second or even per minute. If this assumption falls then my conclusion below for a web based system is out the window. Windows hashes of 8 characters fall very quickly even with larger character sets because I can crack them locally leveraging the full power of my processor and not bound by network latency (which is huge in comparison to local throughput).
Bottom line is that if you are comfortable with 8 character passwords that are complex enough (not findable in any competent hacking dictionary) then you can publish the user names on your home page and it won't matter (but I wouldn't because I am paranoid).
One final analogy to wrap up: If you had a combination lock with the typical 4 numbers on tumblers (locker lock or suitcase lock). There are 10,000 combinations from 0000 to 9999. If someone could deftly try one per second then in under 3 hours it would be open without exception. But if they could only try once per hour (due to surveillance or some other factor then it would take well over a year. Complexity is comprised of number of characters times character set available. Vulnerability is measured in potential passwords divided by the speed at which they can be tried. I prefer adding techniques that detect and deter brute force attacks, but that is a topic for another day.
Tuesday, October 25, 2005
Thom Robbins of MS is introducing a really cool competition called the "Launch 2005 Screencast Contest". The concept is that you get a free 30 day copy of Camtasia and record one or more demos with audio. The entries will be screened and the winners in the major launch cities will win some useful stuff.
Thom breaks it all down on his blog here.
I did one of these during the break at the last Code Camp and it was actually pretty cool. My demo is up on Channel 9 and I am definitely going to be doing some more (though if I know Thom, I am not allowed in the contest).
Monday, October 17, 2005
In the media and likely on your network! I am suprised (pleasantly) to see so much attention being paid to a lurking menace. Jon Box
recently posted about it on his blog and called for a few of us to comment (which I did).
The fact of the matter is that Rootkits
are like the devil, their greatest trick is to convince the world that they aren't there. They don't show up in task manager or on service lists. That is the whole point.
Luckily as I said the media is getting in on the scoop as in addition to Jon, Eweek has posted a pretty good article
on the topic. When you read this you should ask yourself two questions. First how do I check for these things and get rid of them if they are found and second how do I see what is actually stored on my network. It turns out that the hacked server becomes file server for media files is a common theme. I recommend solid auditing and solid storage reporting as the primary ways of getting a handle on this. For the reporting side we use Storage M&A by NTP Software
. It has the added benefit of helping protect you by keeping forbidden file types (i.e. *.vbs and even *.exe) from being written to your drives. Exception based policies allow you to be flexible when needed, but you fix it if you don't know it is broken.
Friday, October 14, 2005
My nephew, John Hynds, also happens to be a security consultant (big surprise) and he pointed me at a recent what we think it a perfect example of a Cross Site Scripting (XSS) exploit as carried out against MySpace.com.
We find that most people have trouble understanding Cross Site Scripting as an exploit as opposed to more transparent attacks like brute force or even SQL Injection.
One key take away from this is that while you are welcome to try to detect when a user inputs malicious data, but that is a war of escalation. Instead you should concentrate on only allowing valid data, it is much easier to screen and less likely to fail as MySpace.com did in this example.
Thursday, October 13, 2005
I have been out of it for about a week due to travel to present 7 sessions at TechEd Hong Kong, but now I am back. It was a great event and as usual was characterized by very high energy keynotes!
The highlight for Bruce Backa and I in our presentations was our last session on Server Control Development for ASP.Net 2.0. The demo of a control that leverages AJAX style updating to the content really churned the audience and opened some eyes. I have been asked to provide the source code to that particular demo (for session WEB428) so here it is: WEB428Done.zip (51.22 KB)
I have to thank everyone who got us to go over there (for our fourth time!) and to Andres Sanabria from Microsoft for the slides and the framework for this particular demo.
Friday, October 07, 2005
The vulnerability scanner called Nessus will no longer be available under a GPL license starting with the next version (version 3.0).
The announcement pointed to the fact that the community has done very little to help the product evolve, but many competitors have exploited the loophole of providing hardware appliances to cut the makers of Nessus.