« January 15, 2003 | Main | January 20, 2003 »
January 16, 2003
OnStar as an Open Platform
OnStar is a mobile data service that GM has developed and currently deploys in many of its passenger vehicles. They also sell it to other automakers for use in their vehicles. It currently serves 2 million customers and adds another 4500 subscribers every day. GM processes 200,000 calls per month for route information, another 14,000 for roadside assistance, and 15,000 for more for remote door unlocking. Add to that the 375 stolen vehicles that are recovered using OnStar each month. This would be a great jumping off point for a piece on identity or privacy, but that's not what's interesting me.
The other day, a friend and I were driving down a cold road in Provo Canyon and looked at the thermometer installed in the car to see if we should be worried about ice on the road. I remarked that it would interesting to be able to read the temperature sensors for the cars around me, particularly those ahead of me on the road. Then it hit me: OnStar could do this today. They have the GPS devices in the cars, temperature sensors, and a mobile network that links the cars to a central data facility. What would be even better is if OnStar were an open system that would allow me to write and deploy applications that made use of their fantastic resource. Think of it as "Wi-Fi meets grid computing." Alas, such is not the case, so I'll just have to wait for Tony Scott (GM's CTO) to put this on his "to do" list.
04:05 PM | Recommend This | Print This
Sleeping with the Enemy
An article in the December 2002 issue of Baseline magazine talks about securing your network from insiders. Its based on a rather fascinating story of a programmer named Chris Harn who worked for the world's largest betting software vendor, Autotote, and rigged the system to pay-off $3 million to one of his co-conspirators. The article gives the following advice:
- Limit Access - Set strict limits on who has access to production servers, where data is most sensitive, and enforce them.
- Create Activity Logs - Activate auditing mechanisms and review such logs randomly and religiously.
- Monitor the Network - Establish a separate authentication server that stores monitored data in a secure location that programmers cannot access.
- Hire Carefully - Do background checks on all staffers who have access to critical data.
- Regulate Hours - Deny employees access to the network during off-hours.
I'm not sure how, in reality, you do the last one. I bought a high bandwidth connection for each developer and encouraged them to use it because I found it was the cheapest way to get programmers to work more hours. Besides, I'm not sure its strictly necessary if you've got sufficient separation between development and production servers. Having a bright line between development and production servers is a great idea, not only for security, but reliability as well. My paper on tiered support gives much more detail about this.