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.

1. The password to my network must NEVER be used for anything else. Violating this rule is worth your job.
2. 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).
3. 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).
4. When in doubt close the browser (and if you like for good measure open up task manager and kill all browser processes).
5. 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.
6. 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.
7. 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.

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...

If you are interested watch the podcast url or my blog (here) for the first show when it releases.

Security is a war, and the hackers are not slowing down their attacks.

The thesis is that we are seeing a steady stream of over hyped security "issues" that tend to remind me more and more of the ads for the evening news that say things like "Your water could be killing your children, details at 11". We plan to discuss how this trend is hurting actual preparedness for the real threats.

Hope to see some of you there.

Too many organizations think that they can ignore code once it has been written, but the price of secure code (like freedom) is constant vigilance.

The subject of the email was the same as this post (Virus Prevention Advice and Policy) and below is the text:

It is that time again and we are starting to see warnings about worms and viruses passed along by friends and family so I wanted to take this opportunity to remind everyone of how we keep our own network safe and free of these destructive monsters.

Some rules of the road for using company email and company computers:

1. If you did not expect it then don't click on anything in it. This general rule will help you deal correctly with most emails and web pages. If you go to a site expecting to download something be sure that you are on the correct site (many common typos of URLs host malicous copies of the popular site). If your brother sends you a message called, "Kids latest pictures" and it was not something you expected, do not click on links or attachments until you have verified that it was indeed sent by him. Our last major virus here at the company was the result of just such a message being clicked on by an employee who did in fact get pictures from her brother quite often, but this time it was a virus that was sent by her brother's computer instead. It took us 2 days to clean up the mess. A better policy is to only open personal email attachments at home while you are not connected to our network.

2. Be paranoid, but try not to be crazy. If you get an email from yourself that is some form of spam then welcome to the club. We can't stop the spammer in Asia from using your email address to send the world spam and if you use the address long enough it will certainly happen that you and others you know will get spam that looks like you sent it. It will pass, but we can't fix it. See rule #1 as this fact should also make you more cautious of anything you get that you didn't expect even if you converse with the user often.

3. A great many viruses and malware are picked up by browsing the web. Visiting site like Youtube.com and MySpace.com is often a bad idea unless you know exactly what you are doing, why and accept the consequences if the result is 2 days of lost time to the company.

4. There is a reason you can't install things on your computer. We limit what the average user can install on their computer so that if a mistake is made, it is less likely to have a lasting effect on our network. In most cases, if it isn't already installed on your computer you don't need it. There are exceptions, but be sure you have a cogent argument for why you need Software X on your work PC. We also use specific version of MS Office products as a hedge against system outages. We do pay attention to the newest versions and will upgrade when the time is right, but no sooner. If there are business reasons why you need a specific version of something please let me know and we can make a business decision.

5. Keep up the good work. We have an amazing track record here for having staff that do the right thing. Most companies get hit by a virus once a quarter or more and we are typcially only seeing an event every other year. This is in spite of the fact that we do not block sites or regularly check browsing logs to police what people are doing. My only caution on this point is that while we all enjoy this open environment it is dependent on our continued vigilence.

If you have any questions please feel free to contact me or anyone else on the technical staff and we will be happy to help you navigate the mean streets of the Internet.

Thanks Patrick

Most companies pay lip service to security, but the emphasis is just not there.  There is bluster and maybe even a few conversions soon after an embarrassing security breach, but all too often a scapegoat is found, fired and then it is back to business as usual.

The missing element is real financial cost.  Looks like Massachusetts and hopefully the feds will change that with new laws that make companies that get hacked pay for the cleanup. 

I really like this kind of accountability.  While I don't think it will be a panacea solving all our problems it will put those to blame for these problems clearly on the hook for paying to clean them up.

Hopefully other states and Congress follow the lead of Massachusetts.

Time magazine's cover story is about how people are scared of very, very unlikely things such as bird flu which hasn't killed anyone in the US while the regular flu kills tens of thousands each year.

Security is the same way.  I often see organizations worrying about "Carlos the mad hacker" when their own IT staff might be the real threat.

Microsoft has just released their new Anti-XSS library which helps developers do the right thing more often without as much effort as before.

If you are interested in this (and trust me, you are) your first stop is to go to the tutorial and see how it is done.  As you will see it isn't stupid simple, but an improvement.

Once you get confortable then go to the official page and download the library and make it part of all your web projects.

Chad Hower is a smart guy and I came across his post on protecting the software you write from pirates right at a time that we were revisting the question ourselves.

On the whole I agree with Chad, while he comes off as against anti-piracy in the beginning of the post, in the end you realize that he is just advocating for a measured response.  I couldn't agree more.

This is very much the whole, "In order to save the village we had to destroy it lesson" where you get very diminishing returns if you go too far off the deep end in trying to make your code pirate proof.

As Vista nears launch there are some things you will want to know.  Will it support your hardware?  Where are the secret buttons that make it usable?

Today's post helps answer that second one.

By all reports UAC (User Account Control) can drive even the most security minded user insane with death of a thousand dialogs.

While I don't recommend just shutting off any feature that is designed to increase security in the OS (as UAC is), still we have to get work done and it might help you navigate so that you can reenable it once your system is as you like it.

Having said that, Steven Smith of ASPAlliance.com pointed me at this article that shows several ways to shut UAC off.

Steve Riley had a good long post on his blog about Mandatory Integrity Control as it is implemented in Vista that drew even longer comments.

Great concept, as you will see from several of the comments, this isn't the first implementation, but I expect it will be the first to get nearly universal distribution ;)

The big concern is whether the bugs will be worked out for release.  I am betting yes, though I expect a Service Pack will come someday to bring the real value of this home.

My prolific friend Phil forwarded me a story about Chinese hackers trying to do in the US Commerce Department.

There are a couple of interesting points in this story:
1. Why would you need to take Internet access away from users?  Aren't they behind firewalls?  Were the hackers luring them to specific sites to hack them?
2. With over 1,100 laptops missing, I just buy that no data was compromised.  Even if it was an ex-employee the data is compromised.  And if the theft occurred in 2001 then I find it even harder to believe.

I hope the CIO at the Commerce Department isn't gullable enough to believe this obvious spin.

The topic of the AT command and the command prompt came up on an internal list I am on with Microsoft the jist of which was, "How do I securely turn this junk off".

The answer is that to some degree the command prompt and especially when coupled with the Task Scheduler is a security hole that is closable, but not trivially.  You can patch it using things like this http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/93465.mspx?mfr=true
and you if you really want to wipe out the user's option you should reset the task scheduler service to use a low / no priv account and disable it (I am paranoid, but I have my reasons). The problem is that the perspective of most that come up against this is that you shouldn't have to do this, but the reality is that you do.

For a scary look at why simply taking the RUN command off the Start menu is not enough try the following:
Open up "Help and Support" from the Start menu and seach for "command". 
Select the entry that describes how to "Test a TCP/IP configuration using the ping command"
You will see that there is a link that will open up a command prompt (it doesn't run as System, but it runs). 
That is the XP version. 

The Windows 2003 Server one takes more searching, but it is there.

The issue is not that the functionality exists, we all want functionality.  The problem is when it is hard (or impossible) to shut something off effectively it is maddening and often leaves people dismayed.

Time for an analogy:
I have doors on my house that I leave unlocked all the time.  The dogs and other things in the house keep it secure (if you know me then you know what I mean), but if I wanted to secure those doors and found that I could lock them, but the manufacturer set them up so that the hinges were on the outside and manipulatable by an intruder then I would be unhappy.  Most security outrage and dismay comes from features that just didn't take security into consideration for the times when I don't want the user to do anything except what the user is told they can do.
 
This will always be an arms race.  If one of our professional security gurus such as Duane Laflotte wants to get in and has physical access to a workstation or server then he can get in, but there is a point where I will say, yes I accept that there are some things I can't defend against.  If you use a tank to blow in my front door, I won't moan to the manufacturer about them not being tank proof, that is what the mines are for ;)
 
Is Vista the solution to all security problems?  I doubt it.  I expect that there will be improvement based on features I already know are in the most recent builds, but I won't judge the security of Vista until after it ships (and won't pay all that much attention to it until then either) since the devil is in the details and the truth is in the final bits.  Submarines either leak or they don't.  The OS will be judged in much the same way in regards to security.

Ultimately information is power.  Nowhere is that more true than in the realm of security.  I suggest that you learn all you can and I will do what I can to help.

If you want to keep track of how prevelent phishing attacks are from month to month (and I do) then you should check AntiPhishing.org.  The site is pretty meager in most regards, but the front page has a bar chart that is pretty staggering when you realize that they are only measuring people who have actually figured out that there is a phishing attack in progress (a fraction of the population I am sure) and further restricted by the fact that those astute people had to know about and be willing to take the time to report it to AntiPhishing.org.

I find these statistics interesting to have as spin seems to creep into everything nowadays.  I like to lay my hands on hard numbers and make up my own mind.

There are many varying opinions on almost everything, but Compliance is one of those topics like economics, everyone has a different opinion it seems.

I was reading an article by one of the Systems Engineers at Network Appliance entitled, "Six Tips for Archive and
Compliance Planning" and while I agree with most of the points Mike Riley makes, I had to think a bit about his words on Encryption.

He isn't saying not to use encryption, on the contrary, he is saying that encryption is a must, but the advice is sound.  Be careful what you do and the ramifications.  With compliance systems, often search and rapid retrieval are key and these are some of the most plausible arguements against specific applications of encryption.

As always, look before you leap.  I guarentee that if you think about where you should be using encryption you are already ahead of most.

I was just thinking about one of the bugs listed in the latest hotfix from MS and realized that while aspx and config files are not at risk since they are mapped to aspnet, the express database if stored in App_Data probably is.

We don't typically use SQL Express, but my bet is that this is the greatest risk factor for this bug.  Thoughts?

When I see an article like this one in eweek, I always wonder about how the people doing this cool thing will make enough money (or any money) so they can continue to do these cool things.

Basically they are using the Google Search APIs to ferret out sites on the Internet that are hosting malware.  I think this is great, but the article didn't say how this cool thing would be actually used to benefit the world.  If they notified site owners that they had malware and pointed out exactly what was where then there is no profit in this (Do I sound like a Ferengi here?) which means it isn't likely to be sustainable.  But what if they notified sites the first time (civil minded) and offered to keep them updated in the future for a nominal annual fee.

I find that many great ideas languish and die because people want to hold onto the open source kind of dream and for some reason either don't see how to help the community in a self sustaining way or are just worried about being accused of just being out to make a buck.

If you are into threat modeling (and you should be) then you should check out the latest version of the product formerly code named "Torpedo".  I think this is the first product to make real strides (bad pun intended) toward making threat modeling more approachable for the average developer.

Get it at:
http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/

At Code Camp 5 in Waltham this past Sunday I was delivering my session entitled "All you need to know about Membership", when I learned that I didn't know everything I need to know about membership.

Someone asked if the scripts were available that aspnet_regsql.exe uses to create the membership table.  My answer was that I hadn't seen them so I assumed they were baked into the exe.  WRONG!  Our good buddy and fellow Code Camp presenter, Dan Krhla, pointed out that in the same directory that you find the aspnet_regsql.exe (namely C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) you also find the scripts that the tool users including InstallMembership.sql.  There are a bunch of them and you have to install them in order (installcommon.sql first, etc.).  They offer some good insights and I have already spent a bit of time on them myself.

Thanks again Dan and I am happy that the question came up so I could learn something too.  This is why I really love the Code Camp.

MS has committed, at some level, to support VB6 on Vista.  In an article from February there are some details, but we now know that if you have a VB6 application that you cannot live without, you will probably be OK for years to come.

This is both good news and bad news.  While I feel the pain of people who depend on these legacy tools for their products to work, I can't help wincing when I see this because old tools support old techniques and technologies that are often just not up to the task of building secure applications.  Everything from cryptography to SQL Injection have evolved as have the tools to combat them.

If you are using / depending on VB6 then congratulations, but my advice is to get off of it (from a seasoned VB developer) unless you can really and truly convince yourself that it poses no weaknesses in security based on your use of it.  Eventually you will have to jump.

A friend of ours, Phil, sent Duane and I a link to an article about web attacks (Phil does this alot).  He commented that he hadn't heard of CRLF Injection before and while I had heard of it, I realized that I wasn't comfortable explaining it on the spot with examples so I read the link.

While I think the writeup is good and felt refreshed of information on the topic (as esoteric as it is given how often we still find SQL Injection), I was struck by one badly worded comment in the text.  Namely the section that says, "The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should "remove everything but the known good data" and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server".  The premise is well intended, but did you see the flaw?  Why would you remove anything from a submission that has anything bad in it?  OK, maybe there are innocent times when a user will insert something that doesn't belong. However if you are doing the filter thing and you find something bad, overtly bad then you shouldn't remove it, you should end the user's session and redirect them to an error page (or some other circle of hell).

If a criminal came to your house and tried to open a window only to find it locked would you then allow them to keep trying?  If you can determine that the input was actually harmful (the opposite of good data) then you should think hard about maybe dumping the user and not going any further in their processing.

If you make your applications work more like the way the real world works then they are more likely to survive in the real world.

</rant> ;)

Scott Guthrie pointed me at a link to the source code for the ASP.Net 2.0 providers including the Membership and Role Management providers.  While I think the Profiles, Web Parts and Site Navigation providers are important and cool, I expect to do much more with the Membership provider.  Expect to see some customizations in presentations I give in the future.

I think this is a great step and am not surprised to see Scott doing something this cool.

Check it out!

As promised, but fashionably late as always, here are the slides from this Saturday's Mini Code Camp Security Edition.

I want to thank everyone that attended and the feedback has been great (no death treats so far)!

Membership.ppt (752 KB)
Security Best Practices.ppt (579 KB)

Check Duane's blog at www.cyberspacesamurai.com for his slides.

See you at the next Code Camp!

Thanks
Patrick

In dealing with our teams of developers and engineers I find myself preaching some basic rules that make life easier for me when I try to deal with the legion of emails I get every day.  I thought to document them and in doing so realized that they have a decidedly security slant to them (big surprise).

Here are some rules of etiquette that will allow you to survive my spam filter (outlook junk mail) and not get deleted for cause:

• Always put a subject on the message (the more specific the better).  I am noticing a ton of no subject emails in my junk mail folder and I don't scan the addresses before I delete them.  Not putting in a subject is a technique used by spammers to make you view the message.  For me and a growing number of people it backfires.  Call it a pet peeve, but if you can't be bothered to put a subject on a message then I can't be bothered to read it.
• Never send an attachment unless I expect it (you told me in a previous message that you are sending it) or you explain what and why you are sending it in a way that lets me know that you had to have written it.  Remember that anyone can send a message as you if they really want to do it.
• If you send me a link then tell me what is at the other end.  There are many sites that lure you in and do something amusing.  Why would you assume that they aren't being used to infect or subvert your computer.  There are many "drive-by" exploits that only need the page to be viewed from a vulnerable machine to do their work.
• If I know a password or other secret then you can refer to the password or secret, but avoid sending it in an email.  It just isn't a secure medium.

I could go on and on about all caps being like yelling, but that isn't my intention.  I had figured that everyone already knew about these and yet I still get these things sent to me times per day and often by very technical people.

Be safe...

When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0.  One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider.  The answer turns out to be not very far.  The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations. 

I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:

1. If you need to access your own schema that is different (in any way) from the schema provided.  Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.
2. If you need to access data in someplace that is not supported.  Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work.  The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order
3. If you need / want to insert some abstraction between the provider and the data.  Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server.  To solve that problem he wrote a provider that took a web service endpoint as its connection string.

So as you can see you are quite likely to find yourself having to write your own provider.  The good news is that it really isn't that hard to do once you have done it once or twice ;)

A recent court case was brought to my attention in which a user whose personal and financial information was stolen tried to sue the company for not using encryption on the data.  The article covering it is explains how the data was stolen and the ruling of the courts.

The question raised is whether the suit should have been supported?  While I agree with the ruling, I think that certain industries need to actually gradually design best practices like the use of encryption into their required security precautions.  This may be pandora's box, but if it is done over time then it might actually be done right (wishful thinking?).

Security is still black art to most people.  We need to define "reasonable measures" in ways that make sense to the masses.

Mark Russinovich has posted another excellent article on Spyware, this time pointing out the anti-spyware program as spyware strategem.

If you hoped that Spyware would just go out of fashion sometime this year, you are deluded.  The advent of better Rootkits, bogus anti-spyware programs (like the ones Mark points to) and the underlying profit makes this the cocaine of the Internet.  The problem is that all the victims are truly innocent in this case.

I want to thank my buddy Dan Krhla (DanK) for pointing it out for me.  He is a very good source of what is good on the Internet.

I was browsing through the list of wireless vulnerabilities on the Wireless Vulnerabilities & Exploits site (our buddy Phil C pointed it out to me) and I was reminded why I always turn Bluetooth off on my devices or avoid them altogether.

Maybe it is just that "B" is so early on, but there do seem to be way too many exploits for this technology.  Granted someone has to often use a bluetooth gun or some sort, but that isn't as far fetched and just adds to the randomness of the attack.

An improved vision of Bluetooth or it's successor:
I want to see a version of Bluetooth or some replacement technology that does the same as far as functionality goes, but that has a metal contact on both device and accessory which must be placed together with physical contact in order to exchange public keys that they will then use along with unshared private keys inside the devices to make the communication not only authorized, but encryptable.  Why is this so hard?  This idea has been with me for well over a year and I just expected someone would implement it as Bluetooth 2 or something, but if it does in fact exist, I haven't heard about it yet.

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?