Peregrine

In the UK, some parents are buying body armour for their children. This seems to be mostly into response to a couple of recent murders of London teenagers.

I can understand parents wanting to protect their children. Security isn’t always about the actual security. Sometimes, the perception of security is more important than the value of the actual security itself. In this case, parents have a greater peace of mind so they feel more secure.

But what about the children? Do you think that they might be a bit more emboldened knowing they have the armour on? In that case, such children are actually at a much greater risk then they were before. Do you think some would take it off as soon as Mom & Dad are out of sight? After all, many kids have done the same with their clothing.

P.S. If the story was about body armor in the U.S., I would have spelt armour differently.

I came across this article at Microsoft today. A Google search for vista networking stack shows several commentaries about the Microsoft article. One writen commented about how bugs that were erradicated 15-20 years ago in TCP/IP stacks are back in Microsoft’s new stack.

Taking a look at the bullet points in the article, the very first one jumps out and says to me, “I’m the #1 reason that Microsoft reimplemented their TCP/IP stack from scratch.” That one reads:

Dual IP layer architecture for IPv6

After all the embarasing failures to produce a workable IPv6 stack (I first remember seeing “beta” code from Microsoft in 1999), it would seem they finally realised that the whole thing would have to be rearchitected.

Most of the bullet points in the article are fluff with a little bit of BS thrown in there two (obviously, the marketing department is still in full control of the Microsoft’s website). Lest you think I’m only here to bash Microsoft, here are some things that looks like improvements to me:

The interfaces in the current TCP/IP stack for TCP/IP security (filtering for local host traffic), the firewall hook, the filter hook, and the storage of packet filter information has been replaced with a new framework known as the Windows Filtering Platform (WFP). WFP provides filtering capability at all layers of the TCP/IP protocol stack. WFP is more secure, integrated in the stack, and much easier for independent software vendors (ISVs) to build drivers, services, and applications that must filter, analyze, or modify TCP/IP traffic. For more information about WFP, see Windows Filtering Platform.

This isn’t exactly new. Windows has had hooks into some parts of the network stack. Windows XP Service Pack 2 added some more key hooks. But one of the problems with the pre-Vista implementations is that tools which used these hooks couldn’t be guaranteed to always be able to process traffic. Although I haven’t gotten in-depth details of WFP, what I have read about it’s architecture it looks like it’s much more robust and complete.

The Next Generation TCP/IP stack can offload the processing of TCP and other types of traffic to Network Driver Interface Specification (NDIS) miniport drivers and network interface adapters. Offloading TCP and other protocol processing can improve performance for high-bandwidth networks or high-volume servers.

Although some NICs (mainly 3Com) have offloading engines that can take much or most of the load of IP and/or Ethernet packet/frame contruction and processing from the main CPU, thus freeing it for other tasks, the networking configuration of a particular Windows machine often prevented such offloading from occuring. Although I do not know any of the details as to why this happened, I have been told (by people who would have such detail) that it was due to the networking architecture of Windows. Again, I don’t have much detail on the architecture of this new feature in Vista, but what I have read leads me to believe that the new stack will make these NICs more useful as well as being easier for driver writers to implement.

The architecture of NDIS 5.1 and earlier versions limits receive protocol processing to a single processor. This limitation can inhibit scaling to large volumes of network traffic on a multi-processor computer. Receive-side Scaling resolves this issue by allowing the network load from a network adapter to be balanced across multiple processors. For more information, see Scalable Networking with RSS.

This is a much needed improvement for some systems, like Data Center Server (which already had something similar) and some beefier Windows Server boxes, but will not benefit end users much. If you were running a game that only utilized 1 of your multiple processors, theoretically, having the ability for the other processor to take over the networking processing would improve performance. Realistically, I doubt you could see the difference. Still, this is another welcome improvement in design.

The Next-Generation TCP/IP stack has an infrastructure to enable more modular components that can be dynamically inserted and removed.

Welcome to the 21^st century! Linux has done that since kernel 2.0 was released (the first version that supported kernel modules).

The Next-Generation TCP/IP stack uses a new method to store configuration settings that enables more dynamic control and does not require a computer restart after settings are changed.

Of course, Windows 2000 supposedly eliminated almost all the code paths where networking changes that would require a reboot. I remember a Microsoft event where they told me that NT 5.0, as it was still called at that point, only had 6 remaining code paths (down from 27 or so) with the whole OS where a configuration change would require a reboot. However, in practice, most people experienced a need to reboot the system to make common networking configurations changes actually effective approximately 1 out of 2 times such changes were made.

One could also read, “We changed the configuration storage methods so you won’t know where to look anymore,” into that one.

From a security perspective, I’m very concerned about their new Inspection API (emphasis added):

The Next Generation TCP/IP stack exposes an Inspection API, which provides a consistent, general-purpose interface to perform deep inspection or data modification of packet contents. The Inspection API is part of WFP. The Next Generation TCP/IP stack provides access to the packet processing path at the Network and Transport layers.

So, it’s easy to hook into the Inspection API and use that to modify network traffic. It looks like it would also be trivial to inject any traffic you wanted to. Given the definition of the word inspection, I wouldn’t expect to find a modification mechanism integrated into the same sub-system.

Having a good set of instrumentation hooks into the entire network stack is important for certain types of software development, security research, auditing and a few other things. None of these should be taking place on production machines. However, it looks like Vista does not provide a way to disable the Inspection API. This could be used by a malicious program to monitor any network traffic it wanted to, or even to implement network communications that could possibly be entirely hidden from other programs (including security tools) and users. At the very least, the Inspection API should not be installed as part of the OS. Even the ability to disable it might not be enough, especially given Microsoft’s security track record.

Overall, however, I feel that I can agree with some of the reasons it appears were behind Microsoft’s decision to reimplement the TCP/IP stack from scratch for Vista and I feel that there are several valuable improvements.

That said, I still do not consider Windows networking stack, even the new one in Vista, to be remotely secure. There are too many unknowns and there is no proper, un-biased, third-party code scrutiny. Closed software simply can not be secure. Peer review by recognized outside experts is mandatory in order to build good security. That’s why burglar alarm companies invite ex-cons and security experts to do their best to penetrate their systems. That’s why insurrance companies do the same with all automobile security systems (as well as letting them asses the relative value of each system for their purposes). Microsoft doesn’t understand that and there’s no reason, from their perspective, that they need to; they’re in business to make money. Until the liability for bad security is placed on Microsoft (and other software vendors) there is no incentive for them to fix it.

Enjoy not just one, but two great Dilbert cartoons.

One of my sisters forwarded an email to me regarding a “new” scam:

Well, the crooks have found a way to rob you of your gift card balance. If you buy Gift Cards from a display rack that has various store cards you may become a victim of theft. Crooks are now jotting down the card numbers in the store and then wait a few days and call to see how much of a balance THEY have on the card. Once they find the card is “activated,” and then they go online and start shopping. You may want to purchase your card from a customer service person, where they do not have the Gift Cards viewable to the public. Please share this with all your family and friends…

Normally, that last line would be a sure giveaway for chain-mail. However, I’ve been looking into this one, and I think it’s legit.

The email originated with a Sheriff’s Deputy. I’m witholding his name for now, because I have not gotten his permission to publish it, yet. I have phoned him, but only left a message on his voicemail, so far. I’ll update this as I get more info.

A man in Quincy, Massachusetts was refused service at the local IHOP restaurant when he refused to turn over his driver’s license before being seated.

Hilarious.

But there’s a great security point here, too. They wanted to reduce the incidence of “dine-n-dash” events, where people skip out without paying. Holding your driver’s license would surely help, or so they thought. But they didn’t count on the reaction to this violation of privacy or, more importantly, the inconvenience this was to their customers.

Security Rule #1: Security is only as good as the weakest link.
Security Rule #2: You’re weakest link will (almost) always be the users.
Security Rule #3: To users, security = inconvenience.

Observation of End Users in the Wild: Users will fight inconvenience.

Good security is invisible to users, or at least, it isn’t overtly present and doesn’t require them to do anything. That’s why supermarkets and convenience stores place monitors where customers can see that the front doors (and other high-value areas) are being watched. People make the assumption that the camera feeds are also being recorded (which is not always true, but often).

At least this IHOP incident wasn’t condoned by corporate management.

If you care about security issues and/or your privacy at all, you should be concerned about the deployments (and pending deployments) of passports with RFID chips embedded in them.

Bruce Schneier, CTO of BT Counterpane, author and world-renowned security expert & privacy advocate gave an interview regarding RFID passports. It is available as a podcast.

There isn’t any new information in there, at least, nothing that I haven’t talked about before. However, it is an excellent, easy to understand explanation of the key issues surrounding RFID chips being embedded in government issued IDs. It’s not very long, but is good information for everyone from the technically challenged to government officials and even security experts.

The “Budapest Declaration on Machine Readable Travel Documents” is an interesting and informative read:

Abstract:

By failing to implement an appropriate security architecture, European governments have effectively forced citizens to adopt new international Machine Readable Travel Documents which dramatically decrease their security and privacy and increases risk of identity theft. Simply put, the current implementation of the European passport utilises technologies and standards that are poorly conceived for its purpose. In this declaration, researchers on Identity and Identity Management (supported by a unanimous move in the September 2006 Budapest meeting of the FIDIS “Future of Identity in the Information Society” Network of Excellence[1]) summarise findings from an analysis of MRTDs and recommend corrective measures which need to be adopted by stakeholders in governments and industry to ameliorate outstanding issues.

Thanks to Bruce Schneier for posting this on his blog.

Russel Coker recently posted an article to his blog titled, “A Good Security Design for an Office“. It’s a very good read. There’s nothing earth-shattering in there, but plenty of gems that most people either forget about or never figure out.

There are a couple of things that I wanted to comment on (there is a lot of excellent information here, so read on):
Read the rest of this entry »

No surprise here.

Since the electronic voting equipment manufacturers are completely incompetent when it comes to security, I and any other person with a working brain (when it comes to security, that is) have been expecting that we would be hearing an awful lot about machines “malfunctioning” in this year’s election.

If you haven’t caught any of the stories yet, check out Pete Ashdown’s recent post on some voting experiences that have been sent in to him, as well as this story on KFDM’s website.

There are other stories surfacing already.

Pay very close attention to your voting. Make sure the machine shows what you really wanted to vote for before you commit your vote. Double-check the printout from the voting machine and make sure that every one of the items marked is what you really wanted to vote for.

It’s your responsibility to ensure that your vote was recorded as you want it. The electronic voting systems adopted in the state of Utah are so insecure that it doesn’t matter how good the elections officials and workers are at their jobs; votes are going to be stolen this year and with greater ease than in any past year.

It’s up to you, the voter, to protect yourself and your vote.

While reading some things today, I stumbled across this MSDN Mag article titled, “8 Simple Rules For Developing More Secure Code“.

There is nothing groundbreaking in this article, but it is a good collection and summary of these important and truly basic, programming principles. Some are easier to implement in an existing development pipeline and a couple could require some very large changes. Still, it’s worth considering.