Tuesday, 11 August 2015

Challenges of securing cars

22:44 Posted by G No comments
Interestingly Autocar's Matt Prior has just written on the subject - here

Following on from my earlier post about the challenges of securing the software used in cars, here's my thoughts in more depth:

The car just becomes another piece of software to maintain - You may well have seen a number of stories in the press recently about software in cars being hacked.  The biggest story was the one affecting Jeep, needing to recall 1.4m vehicles (link).  The details of the hack are scary, in that the security researchers that found the vulnerability didn’t need physical access to the car, just a connection to the Sprint mobile network, and then could target any of the 1.4m Jeep vehicles.  It’s staggering to think this level of security testing wasn’t undertaken by the vendor.

However Jeep weren’t the only company found out recently.  Ford (link) and BMW (link) have also had to release security patches.  What concerns me most is; what appears to be happening to the car industry now is what happened to the software industry about 15 years ago, when Microsoft was in the press almost weekly with reports of it terrible software security.  Back then in 2002 Bill Gates wrote the famous ‘Trustworthy computing memo’ which stated “… if we don’t do this, people simply won’t be willing - or able - to take advantage of all the other great work we do,”.  Microsoft took the unprecedented decision to stand down all 9,500 Windows developers for 8 weeks to focus purely on security. (1,300 man years of work). 

However with car manufacturers having to integrate diverse vendor’s software (infotainment, ABS, Steering, Throttle, climate control, stability, traction control systems, all of which may be written by different suppliers), not only so they work safely (although that doesn’t always work - see this long and very scary article on Toyota which essentially says it wasn’t even possible to test if their software was roadworthy).  Alongside the challenge of integrating disparate software, which is certainly not a skill most car makers will have extensive experience of, combined with needing to think about security at all stages, rather than just testing before the car gets released, is a huge mind-shift change, and one illustrated by the Microsoft example that takes time and huge investment, neither of which the car industry has.  The final danger is that the motor industry is a very marketing and consumer demand led business, so I can easily see a situation when ease of use for the customer trumps security, and weaknesses are consciously built into systems, making them far easier to attack.

What can be come about this? well it will be interesting to see how the industry evolves.  Tesla, so often the darling of the car industry was also shown to have vulnerabilities this week, but this required physical access to the vehicle which is much less of worry.   Tesla are in a better position as software was designed in from the inception of the vehicle so the design team are already thinking about security from the when the car was on the (virtual) drawing board.  I wonder if traditional car manufacturers can keep up with the software development world, This article on LinkedIn (link) illustrates the number of lines of code in a modern car (a staggering 100 million), which is greater than the combined lines of code of a Boeing 787, the space shuttle and Windows Vista, which I find a terrifying statistic.

Tesla are turning this to their advantage.  A recent tweet from Elon Musk their charismatic CEO told owners of their P85D cars “0-60 acceleration time will improve by ~0.1 sec soon via over-the-air software update to invertor algorithm”.  While quite cool that you get additional performance ‘for free’, and they are currently talking about adding a collision avoidance feature in a future update, it does ask an interesting question of insurers. 

Historically when you bought your car the features stayed constant over its lifetime, so insurers needed little data beyond make, model and year.  However with the concept of over-the-air updates how will insurers price car insurance? Will you need to declare that your car is running the latest firmware or to have to guarantee that you will keep in updated within 30 days of an update being released ?  And as we all know from updates to our mobile devices you probably don’t want to upgrade on day one in case there’s a bug in the software which renders your car un-driveable.  This is certainly a topic that's going to gain many more column inches over the coming months.

Friday, 7 August 2015

Delivery Engineering Team

17:02 Posted by G 1 comment
Interesting to read Greg Dziemidowicz's Blog (link), thanks to the great DevOps weekly from @GarethR, about how he runs a Delivery Engineering team.

Image - Greg Dziemidowicz


Where I work we setup a Platform Services team run by Jon Fletcher. There's a big disconnect in my view for anyone how has a DevOps team.  We provide a DevOps service, so we help others get better at DevOps concepts, but its not the teams job to do the releases, we help others get better at theirs.  In my mind if you've got a DevOps team doing releases you've just added a silo rather than trying to break them down.

I like Greg's definition of what his team does :

" Delivery engineering team enables others to deliver business value faster "

I was also interested to see his team are responsible for helping reduce new developer laptop setup time, this isn't something our team gets involved in, but it's a fairly easy extension to the teams existing responsibilities.

I think it's equally important to be clear on what's out of scope, the team doesn't do release support, but as they own the DevOps platforms (Puppet, Jenkins, Octopus etc.) they are responsible for support of the platforms that our other teams use.

FinTech - marrying up finance and tech start-ups

14:43 Posted by G No comments
There's lots and lots in the press, and the word FinTech is certainly getting a workout (too much many would say).  This Bloomberg article caught my eye, not only as it's a good example of a bank doing it's own incubating and working directly with start-ups, but because of the synergy between the two companies.


  "Wells Fargo’s investment in Context360 is part of a technology incubator program the bank began last year to spur innovation. In April it selected the San Mateo, California-based startup and two other firms out of almost 300 applicants for one-time investments of between $50,000 and $500,000."

"Customers may be more receptive to offers or notifications if phone sensors show they are commuting by train, watching soccer practice or otherwise in a place where they can look at their phone. The results could theoretically be used by Wells Fargo to tailor alerts that would hit customers’ phones just when they are engaging in an interaction that might require the bank’s products -- like a car loan.

Or it could be used to detect fraud by checking that a phone and credit card are in the same place, and stopping a transaction if they aren’t."