Macrocosmic Technologies

I just got an MSI Wind U100, and am almost impossibly impressed with it. I’m a pretty good typist, somewhere in the 90 WPM range, and I have had little problem adjusting to the keyboard. The only things I’m having a bit of an issue with are that the left shift key is smaller than standard, and there’s a key that is too close to the period key, so I sometimes get a double key combination when I really am just trying to type a period.

I’m slowly assembling the pieces to create a truly portable Hackintosh. I’ve got the wireless card on order, as well as the 2GB stick of memory, replacing the built-in 1GB. This allows for more stable overclocking of the 1.6 GHz Atom processor. I have yet to decide if I’ll dual boot between OSX and XP, or just dive on in to OSX.

As far as out of the box performance, the unit is no slouch. No one will ever confuse it with a Core 2 Duo, but considering I’ve been on battery for 2.5 hours and am at 50 percent of battery remaining, I have no complaints.

While planning the redesign of an enterprise application at my employer, we’re using the Microsoft patterns & practices Application Architecture Guide as one of our design guides.

We started by baselining the current application against the guide, and found it deficient in every single outlined quality attribute. Specifically, the quality attributes outlined are availability, conceptual integrity, flexibility, interoperability, maintainability, manageability, performance, reliability, reusability, scalability, security, supportability, testability, and usability. Unfortunately, these deficiencies are what lead to the biggest pain points, both for the business and the technologists trying their level best to deliver the optimal solution to it.

Obviously, there are tradeoffs inherent in these quality attributes. One obvious tradeoff is security versus performance and usability. All three are important in nearly every application, but depending upon the threat profile of the application, security may take precedence over nearly every other attribute.

According to the document, during the design process, the following guidelines should be considered:

• Quality attributes are system properties that are separate from the functionality of the system.
• From a technical perspective, implementing quality attributes can differentiate a good system from a bad one.
• There are two types of quality attributes: those that are measured at run-time, and those that can only be estimated through inspection.
• Analyze the tradeoffs between quality attributes.

Some of the questions from the guide include:

• What are the key quality attributes required for your application? Identify them as part of the design process.
• What are the key requirements for addressing these attributes? Are they actually quantifiable?
• What are the acceptance criteria that will indicate you have met the requirements?

TFS gives you some powerful, but somewhat obscure, functionality for undoing users’ checkouts, deleting workspaces, and more. As a TFS admin, you run into cases where a user’s workspace has become irretrievable, whether due to the user no longer being available to the project or a loss of data on the part of the user. The command for this (covered in MSDN) is:

tf workspace /delete hisworkspace;DOMAIN\OtherUser

If you want something a little more granular, you can undo the lock on a checkout, but not lose the change. This command (also covered in MSDN) is:

tf lock /lock:none $/project/path/filetounlock.cs

If you truly want to undo a checkout, losing the change, you can use this command:

tf undo /workspace:OtherUserWorkspace;DOMAIN\OtherUser $/project/path/filetowhack.cs

If the developer has moved on, whether to another project, another company, or it was their gear that moved on and took their project with it, deleting the workspace will likely work best. You don’t have to worry about unlocking their files, and you don’t have to wander all over your source tree taking care of files individually.

I presented a few days ago at Cleveland’s Information Security Summit. My topic was originally to be about Threat Modeling, using a system-centric approach to analyzing the threats, assets, and vulnerabilities of an application. Because there was another session being presented on threat modeling, I wanted to offer something unique. To that end, I reworked the presentation to include a section about the Security Development Lifecycle and how threat modeling fits within it.

While the slide deck won’t give you all the information from the session, it will provide you with the highlights. The PDF version can be found here.

You know, I REALLY don’t like just regurgitating whatever Bruce Schneier is writing about, but sometimes, he’s got some GREAT stuff on his blog. He points us toward a product called KRYPTO 2.0.

From the site: Krypto uses repeated 256 bits (full bits) a coding purely been based on information of the keys file, which are the technically highest coding depth at all on computers possible are.

Now, I understand that the author is German, and that it’s fairly evident English is NOT one of his primary languages, but it’s still no excuse.

This is also reminiscent of a presentation I was witness to recently. The author of a product for biometric encryption claimed that his product’s encryption was superior because it used Super S Blocks, rather than that dusty old crap everyone else uses. Now, mind you, this product was also explained as using the biometric identifier (such as a fingerprint) as the
key, rather than having the identifier open a certificate which serves as the key. Sucks when you have to revoke the credential, huh? Well, at least you still have nine other fingers that are perfectly functional!

Bruce Schneier has recently written an interesting piece in his blog about Caller ID. In it, he writes about an AP article that details the failings of Caller ID. He asks a VERY good question. Namely,

Q: What’s worse than a bad authentication system?
A: A bad authentication system that people have learned to trust.

This is why it is imperative that when building a system used for authentication, it must be secure. The more widely utilized the system is to be, it becomes that much more important.

The article goes through real-life examples of forged caller ID information, including a congressman who was targeted by having his phone appear as the caller ID, a SWAT team operation in response to a call from a spoofed phone number, breaking into voicemail boxes that automatically authenticate based on the caller ID, and even how caller ID spoofing played a role in the 2004 “hack” of Paris Hilton’s cell phone.

More interestingly, the article touches on how the last scenario, an example of “pretexting”, is a textbook example of social engineering. With the caller appearing to be the legitimate user, the target is lulled into a lowered sense of security. It’s been used to obtain all sorts of information, but most recently, has come under fire as shady operators make pretext calls to wireless carriers to obtain copies of cell phone bills, including calls placed and received.

I’ve been playing with two pieces of hardware recently. One is the Linksys NSLU2. This device runs the Intel XScale processor with BusyBox linux. Off the shelf, it’s a way of turning your USB disks into NAS. With custom firmware, you can run pretty much whatever your want on it. Imagine one box running your file shares, caching proxy, and web server, all for under $100.