In the first two parts of this covered the idea of security and physical security.  We now move into access security.  Access security is a highly religious topic, bent with emotions, misinformation, egos, principals and typically (worthless) corporate policy so prepare for battle on this one if you dare tackle it.  Let's dive right into this using our previous example of an office building and I'm looking for a port to plug into the network.  How long will that take?  Virtually no time, they're everywhere, which leads me to my first not-really bold statement of this post.

Network access cannot be controlled.  More...

In part 2 of X, I'm going to cover the aspects of physical security.  This doesn't seem like rocket science, but again, I'm surprised how the same breaches happen again and again so it's necessary to cover it.  Physical security is often overlooked.  If a bad guy has access to the server room, network gear, etc, he owns it, not you.  The biggest, baddest security is worthless if it's taken out by pulling a power cord -- game over and time to update the resume. More...

In this world we live in today, there are many issues that hit in the security realm but I'm astonished at how the same issues keep coming up so I feel it's necessary to go over them as best I can.  Some things may shock you, freak you out, piss you off and generally make you think I'm full of it. More...

I've been on a bit of a security throw back the past few days and I've bounced around the web reading, reviewing, relearning some stuff, which I'm happy to report, nothing has changed.  At all.  Not even a little bit.  Consider this blog entry by a security optimist.  He's hopeful there's a more better way to solve the security resistance, so I posted the following comment, less some unnecessary info.

Users are focused on their job, nothing more.  Security must be either transparent or enforced by the bosses/masses.  Take this example...

You have a 3 year old that's obviously sick.  At first, the idea would be to allow the child to take something to make him/her better, willingly, but after say, 5 attempts, the forceful method is used and the child gets better.  The child learns as bad as this is, it's better to take it willingly because in the end, the outcome is favorable.  Where's the gap? 

Security from a users perspective never goes from "sick" to "better" based on their actions.  It never went from "better" to "sick" based on their actions either.  This goes for most managers and home users too.  It's the "all of a sudden" syndrome.  Even worse, it's really hard to get back to "better" when the "sick" level has been reached, especially when things like credit cards, SSNs, etc have been compromised.  Bad day, UpdateResume();

The insane amount of work comes by making it transparent and necessary.  It's really easy to flip a switch and say "its on"; it's hard to have someone come into a room then a camera and a finger print reader decides if they're allowed to see the room and then the lights come on and the door opens based on that decision.  It's even harder to determine "what is necessary" and for what people at what time.  There's no magic formula.

I believe that in small shops, this is easily obtainable thanks to sense of ownership.  Large companies, not so much.

If the custom module wasn't enough, I'm now wondering off into encryption land.  A quick scouting of the System.Security.Cryptography namespace shows me a ton of stuff to play with.

Ooo, AES.  I like AES.  It runs on my router(s) @ home and is viciously annoying to crack (TKIP f0r t3h w1n!!!11).  Cool, let's use that, its good enough for top secret docs for the gov so it should be good enough for me.  But, as with anything else, there's a catch or ...20.  Here's some basic considerations.

Will this data be searched? 

Searching encrypted data is a royal PITA and a huge overhead.  Example : saving data to a db with encryption happening in the business layer.  A perfectly viable user says to the application "hey, find this" -- you cannot directly ask the database to find it, it is impossible, so every search that happens comes across, ALL OF IT (say 2 million records), decrypts, the search happens, find the records necessary and passes that on.  Not very reasonable nor scalable.  2nd option for this is do it on the sql server itself.  Fundamentally I have a problem with this for 2 reasons.  1, a purely architecture standpoint, this should never be passed off to the data source.  In the real world, it's probably ok to offload some of that overhead, but still, using the OSI model alone says "no no" -- encryption happens in the presentation level and offloading it means you pass though all 7 layers ONCE before you encrypt -- bad bad bad.  2nd, unless the data connection between app/server is encrypted to hell and back itself, your encryption is trumped and effectively worthless.

How much protection is necessary?

The question of the ages.  Understanding the CISSP-ism of protection and risk management: the amount of protection spent on it should be equal to the amount of total loss of one breach by the inverse of the possibility of recurrence.  So say the data is worth 10 million dollars for ONE loss.  The probability of loss is once every 5 years.  10m/5y = 2 million a year should be spent to protect it.  No really.  Now, if there's no REAL value to the data, ie, its personal junk you keep at home for giggles, then whatever the server can handle works fine.  Otherwise, use reasonable + 1.

I'll stop there.  Other questions can range from "Who needs access to it?" to "Where will the server be physically housed" -- but thats somewhat outside of the scope of this post.  Not saying they're unimportant, just "too much" for this post.  I think my first task will be working on getting something simple to encrypt, like a file or a string and work up from there to see how much overhead this thing creates.

One often overlooked aspect of programming is that evil legal side.  Case in point, you are keeping user records of some kind.  Now, I'm not talking about SSN, Health Records (HIPPA) or bank info.  No, I'm speaking of retaining a users home phone, address, first name, last name, etc.  At what point does this fall into the legal consideration category?  The answer is "check your local codes".  Yea, it sucks, but there's hope.

Within 5 minutes I was able to find the state of Ohio's code regarding (legalese warning!) Private disclosure of security breach of computerized personal information data which is a fancy way of saying if someone steals enough stuff to grant the ability to steal someones ID or other non-public records.  The Federal govt has a law(s) for it, but local laws usually reach further and are more clear (as clear as a law can be) as to the actions necessary for this (typically notification and credit monitoring).  In this case, here's what the Ohio Law says "Private" information would be... Article 1349.19 section 7 chapter B items 1-4 (I don't make this stuff up)

(b) “Personal information” does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records or any of the following media that are widely distributed:

(i) Any news, editorial, or advertising statement published in any bona fide newspaper, journal, or magazine, or broadcast over radio or television;

(ii) Any gathering or furnishing of information or news by any bona fide reporter, correspondent, or news bureau to news media described in division (A)(7)(b)(i) of this section;

(iii) Any publication designed for and distributed to members of any bona fide association or charitable or fraternal nonprofit corporation;

(iv) Any type of media similar in nature to any item, entity, or activity identified in division (A)(7)(b)(i), (ii), or (iii) of this section.

If you can't get it though normal means (public records, mass media or publication), its considered private information.  Still leaves room for "what is public" but something to consider.

I've been tasked with enabling Windows Authen to the current project I'm working on which "back in the old days" of IIS6 was uber easy -- tell it to use windows for the authentication, set your allow/deny groups, done, move along.  With IIS7 you get this really nasty rude surprise...

Woah, ok, fine cousin Vinnie I'll just ...um, go over here for a while.  Jesh.

So I go bouncing around the net and I keep seeing posts about going into vista and enabling various stuff for IIS ...I go take a look and well well well, what do we have here?  Windows Authen, thank you very much ...along with all the other useful stuff.

Ooook, now let me guess, you have to go turn it on (yep!) so into the Inetmgr.msc, click on authentication, and no surprise...

Right click, enable, annnnddd back to the page.  But how do you know its working?  Here's a test I came up with on the fly to verify the stuff is doing its thing.  Just as a note, you have windows authen enabled and anonymous enabled for the following tests.

Go into your root page, whatever that may be (default.aspx?) and drop in a LoginName control onto the page (look under Login in your toolbox), drop it on the page somewhere obvious, the top works great.  Dump this into your web.config somewhere under <system.web>, you've probably seen this before...

<authentication mode="Windows"/>
<authorization>
     <deny users="?"/>
</authorization>

so you've seen this, the ? disables all anonymous users.  Load your page up and you'll see <domainName>\<userName> on the screen (assuming you are on a domain).  Great, it works, now change <deny users="?"/>  to <deny users="*"/> (This'll disable ALL users) -- You'll get a prompt (!) and a nasty 401.2 error when you click cancel.  Switch back to the ? and go back into inetmgr and disable windows authen.  Refresh the page and you'll get the same 401.2 error.

I almost forgot, if you take away the <deny users="?"/> you'll see NO username at the top (its anonymous after all!)

I swear, I don't go lookin for this stuff, but I'm very excited when I do.  Jeremey Allison is a huge supporter of open source code and in my opinion, does -NOT- like microsoft at all.  He's been cautiously outspoken them and their security practices which the obligatory response comes "who isn't?".  Well, interestingly (but not unexpected) enough, he's ran into a big surprise ...his code isn't secure and raised quite a stink.  I'm not dogging him for it, I'd be the first to admit my code isn't perfect (stop laughing!) but at least he's admitted it which begs the question -- did he tell on himself because there was no one else to blame?  Further, its written in C.  Do I think C is dead? Oh god no.  Is it dated?  Probably.  Do I think there's "better"?  Sure.  Is it practical?  mmmm, that's unclear with the answer of "probably not" (anyone got a c#/java version of samba sitting around?).

I find phishing scams amusing.  Always have, always will and I became worried for a while...I haven't seen anything different, new come across my email in a while.  Yes I have a life.  Moving on, I use to write tech articles regularlly for the office, and when I would get a "new" scam, I'd send it out and explain what all was going on and -why- this is stupid to respond.  Well, I found a new one!  This one is semi-new though -- consider it a repackaged "I'm a very wealthy foreign blah blah with a bajillion dollars I'd like to send you" ...but only slightly.  Here's the wording...(see the attached file as well, right here) 

We hereby confirm the receipt of part payment of US$8,500,000.00 dollars only, into our ESCROW vault / account with the HSBC Bank in London by order of the Foreign Debt Recovery Committee on Overdue Contract / Lotto Award / Inheritance payments in Africa / Overseas via the African Development Bank (ADB), as indicated in our database.

Yay!  How amusing.  Same kind of idea "we got money to give you now hand over your first born with a dna sample and your mothers madien name" sure to follow.  And to no surprise...

Kindly provide us with the below information to reconfirm your details in our database and for our prompt payment procedures.

Beneficiary's name / Age: ………………………………………………… Company's name / Rank in office: ………………………………………… Address:……………………………………………………………………

Tel: …………………………………………… Fax: ………………………

Receiving Bank: ……………………………………………………………

Address: ……………………………………………………………………

Bank Routing Number: …………………………………………………… Account number: ……………………………………………………………

Ding ding ding!!!  Congradulations!  You have successfully given someone just enough info to let your money go out the window.  Doesn't it feel good that 8.5mil is on its way?  This comment I find MOST amusing.

Once again, you are strictly warned against your further communication with your unscrupulous associates

What great advice not to share things with my not-so-careful "associates" because they might want some of my 8 million.  Well, I'm off to fill this out and next time you'll hear from me, I'll be on an island somewhere with a little umbrella in my drink!

I just ran across this article this morning while I was doing the "getting latest" dance with TFS.  I haven't had a chance to really go though the article (although this project update is nailing my cpu for 100% during this entire blogging ...DataCompare is killing me) but the short of it appears there's a way to break the encryption based on "secret numbers" the algorithm knows about.  I might go as far as to tear into the 160 page doc and see what they're talking about but either way, "that ain't cool".