One of my favorite papers to quote in security talks has nothing at all to do with security: Power, Politics and MIS Implementation. It essentially concludes that executive fiat isn’t effective in getting people to buy into new MIS systems that they find distasteful to use. Forgive the antiquated MIS reference, but we’re talking circa 1983. Back in my IBM 360/370 COBOL days actually.

Today’s security is the MIS of yesterday. To wit, read Employees’ Behavior towards IS Security Policy Compliance whose conclusions are not dissimilar.

In my experience, to achieve voluntary enrollment — which should always be our goal in everything security — security policies must:

• Cite the business motivation behind the policy umbrella ( e.g. “To remain an extraordinary company, we must continually earn our customers’ trust…”)

• Adopt the same tone, voice and legibility as your company’s Employee Handbook. Which usually isn’t designed to scare people into compliance, in case you hadn’t noticed.

• Cite the business rationale, spun positively (e.g. “Like our other software development rigors, secure coding practices are widely recognized as tonic for the reliability of our mission-critical systems…”)

• Recognize that the business knows it’s not always in its best interest for everyone to follow every policy to the letter, and when that inevitably occurs in a  crisis, what to do about it (e.g. “Use your best judgment, after seeking a second opinion unless that’s impossible, and notify the CISO within 12 hours.”)

• State to whom to appeal when a formal request for a policy exception is denied. Even if you know that the requester will have to file six forms in triplicate, have a human tell them that, not the policy.

• If you need legalese-rich preambles (e.g. “This policy changes from time to time, sometimes without prior notice…”) — which I do advise with your Legal department’s oversight — make its text collapsible with those nifty [+] widgets, so readers can get right to the point without having to scroll beneath the fold.

Finally, never stop asking people at all levels how good a job you did at delivering it. If you haven’t sold them in principle, you’re nowhere near done.

I hate it when Toffler wakes me up in the morning. Some things are too damn shocking, and stressful, and disorienting to learn from him early in the day.

“Future shock is the shattering stress and disorientation that we induce in individuals by subjecting them to too much change in too short a time.” –Alvin Toffler

On the upside, I didn’t get a call from the CIA telling me my city was in blackout. Thanks to mindless sociopaths who, I’ll assert, are conceivably responsible for the deaths of newborns and elderly in critical care. That’s no stretch, any more than were the security community’s predictions of crises like these when the Internet first leaned mainstream.

“Our technological powers increase, but the side effects and potential hazards also escalate.” –Alvin Toffler

What are the odds we’ll see lots more like this? Silly question. As Schmidt points out in the article reference above, 85% of critical infrastructure in the U.S. is controlled by the private sector. Not that I needed any supporting data though.

“You can use all the quantitative data you can get, but you still have to distrust it and use your own intelligence and judgment.”  –Alvin Toffler

I’ve said it before and I’ll say it again: Get to know your neighborhood security geek. Or Toffler. They’ve both seen the future.

Earlier today, while online shopping, I was reminded of how the web experience has not improved usability-wise or security-wise since Netscape Navigator 1.0, circa 1995. I say reminded, because I’ve asserted this for years. I say devolved, because I can mathematically prove it with my patent pending HCI-SEC “Not Yet Peer Reviewed But Surely Correct” Formula (TM), as I do at the end of this litany. (For the record, I was not shopping at Amazon.com where I spent seven years and still shop with gusto.)

Below is my 22-step shopping, bordering on stopping, experience. As Criss Angel says, don’t try this at home, I’m a highly trained professional.

1. Added two identical items to merchant’s shopping basket
2. Entered the checkout process, anticipating 45 seconds to my next work task
3. Discovered that PayPal payment was required
4. Opened a new window to PayPal. Opened Keychain Access. Entered lengthy, not-so-random Keychain password. Dug out lengthy, random Paypal password
5. Failed PayPal login, presumably due to a previous cut-and-paste erro [sic]
6. Went through PayPal “I forgot my password,” creating a new random one, making it longer for good measure. Carefully saved it back into Keychain Access
7. Discovered I needed my PayPal security token. Found it in the last place I looked. Weird
8. Discovered I had never completed my now 9-months old PayPal “expanded use” configuration, so I could purchase with my credit card rather than my checking account. Learned it’s documented on a 9-months old statement. Realized I almost never use PayPal
9. Opened a new window to my issuing bank’s site. Dug my lengthy, random password out of Keychain Access. Used the wrong password (I have two accounts) the first time. Got logged in
10. Located my 9-month old statement, praising the gods of Internet Accessibility that it was still online, unlike unrelated statements I need at a different financial institution. Located my expanded use code next to the $1.95 PayPal charge
11. Returned to PayPal window. Login timed out
12. Dug PayPal password out of Keychain Access. Got logged in
13. Got distracted by an unnamed family member who confuses “do not enter” sign with “please enter and ask me what I want for dinner”
14. Returned to PayPal window. Login timed out
15. Returned to Keychain Access. Login timed out there too. Re-entered Keychain password
16. Dug PayPal password of Keychain Access. Got logged in. Fought temptation to “upgrade” all passwords to one character
17. Finished PayPal’s expanded use configuration. Traction!
18. Returned to window with merchant’s shopping basket. Unintentionally hit “back” button which nullified my shipping and billing information
19. Re-entered the checkout process. Halfway through realized the quantity said “1″ not “2″ which required me to re-re-enter the checkout process. Started questioning how badly I need these items
20. Discovered I needed to re-authenticate to PayPal within the merchant’s checkout process
21. Dug PayPal password out of Keychain Access
22. Completed my order!

On a scale of 1 to 10, 1 being X11 and 10 being my patent pending Autonomic Inhalation Ordering System (TM), I’d give this experience a usability score of 2 (because I actually completed the order) and a security score of maybe 5 (because I don’t believe I have a Russian mafia keylogger installed).

According to my aforementioned HCI-SEC Formula, 2 plus 5 equals 7, assuming of course we don’t do the Olympic thing and throw out low and high scores (tempting as that is in this case). That equates to 35% which, unless one of my graduate school professors is grading on their infamous curves, is an F.

Now turn back the clock to 1995. In those days, SSL was shiny new, and “shopping basket” was synonymous with “monolithic three-page form submit.” From both usability and security usability perspectives, given that these defined state of the art, I’d have had to give each something close to a 9. Even my retired professors would call that at least a B.

B. F. QED

Years in the making, the One Laptop Per Child “XO” is finally shipping!

If you haven’t heard of it yet, forget everything you know about laptops. This is by far the most innovative laptop — make that end user computer — to date. I won’t bother to reiterate the specs here.

Inside of one generation, OLPC is going to change almost everything for children in developing countries. Watch and see.

Better yet, get involved, and get rewarded for it. Between now and November 26, 2007, buy a laptop for a child in a developing country for a mere US$399 (your weekly Starbucks allowance) and you’ll reap a lifetime of good karma. Oh, you’ll also get a free unit for that special kid in your life (you), a $200 tax deduction and 1 free year of T-Mobile Hot Spot service. My coffee grounds tell me you’re about to increase your Starbucks allowance.

And here’s some security frosting (pun intended) for the cake: OLPC is hiring Security Software Engineers to work on Bitfrost, which has Simson Garfinkel’s HCI-SEC research written all over it. Go to work there and you just might reap two lifetimes of good karma. Your individual mileage may vary.

I’ve already put my money where my mouth is and bought two earlier today.

While looking into some of the finer points of SSL EV, I landed at Microsoft. Clicking on the fourth search result shown in the adjascent picture (”Extended Validation SSL Sites”) prompted my up-to-date Firefox (and Safari and Opera) to initiate what is without question the single least understandable and therefore the most unforgivable computer/human dialog in the history of technology.

In essence my browser said: “I don’t have a clue about who owns this website, so let me enlighten you with an incomprehensible dissection of its X.509 certificate so you can judge for yourself.”

Ok, this isn’t an EV-specific issue. And sure, I get X.509, but Quintessential Person sure doesn’t. And though I’m not a Microsoft basher these days, they have no business using a certificate authority that only IE 7 knows about. All in all, this qualifies as Bad Security.

1. Great Security • n., see good is as good as it gets

2. Good Security • n., see rare and quiet about it

3. Passable Security • n., see optimistic auditor

4. Weak Security • n., see no, it isn’t a business driver

5. Newsworthy Security • n., see damn, it is a business driver

6. No Security • n., see unlikely despite what security team says

7. Bad Security • n., see anything in the name of security that gives it a bad name

ITCi invites you to attend this unique education and networking event focused on solving your most complicated and pressing security, audit, content, and risk management challenges.  Expert presentations and networking events will expose you to best practices, peer experiences, and authoritative advice that will give you insight and information on how to create strong and defensible IT compliance programs.

See the Conference at a Glance for more details. RiskBlogger’s very own Jim Reavis is a session chair, and Larry J. Hughes, Jr. is lead presenter for two sessions.

I wrote the other day about what a big fan I am of PCI, and why I’m happy merchants are rebelling against it.

Although this is a win-win of sorts, I nevertheless can’t help but see this playing out in a way that gives security a bad rap:

1. We build and start using pieces of technology under one set of assumptions. “Let’s build us some networks and databases to share information!”
2. Later, we start using that technology more and more under an expanded or different set of assumptions. This is usually a long, iterative process. Eventually, it’s “Let’s transmit credit cards over our networks and store them our databases!”
3. Much later, we recognize that some of our incremental uses have long since introduced serious risks. “Oops!”
4. We ignore those risks as long as we can. “These are not the security ‘droids you’re looking for!”
5. Once our hand is forced — “PCI fines are how big?” — we invest enormous sums retooling technology we created way back in step 1 to support all the new cases we garnered during steps 2-4.

Often step 5 is the right way to go. Business pragmatism has a way of dictating this, as it did the whole process in fact, and generally speaking I don’t have a problem with it. So long as we’re honest about it.

But smokescreens aren’t honest. This is where the credit card companies have failed us. Had they been honest with us a few years ago, they would have mandated a five-year program to wean the industry off of legacy credit card processing and on to SET.

The reason they didn’t, of course, is obvious. With SET, who inherits the burden of liability that results from card theft?

But despair not, merchants. Even without SET there are still plenty of good ways to offload liability from credit card theft. It’ll take strength in numbers to convince the card companies to cooperate though. The technology itself isn’t as revolutionary as you might think, as I can attest from championing preparations for it at Amazon.com.