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.

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.

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?

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.

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!

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!

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.