This will be interesting.

The week of Las Vegas madness that encompasses Security BSides, BlackHat and DefCon is approaching.  I am fortunate enough to be speaking twice that week-

I will be leading Security Speed Debates at 10am on Thursday, 7/29 at Security BSides.  It is an idea I have blatantly stolen from AusCert, but ours will be better, at least partly because we don’t talk funny.  I will be joined by the lovely and talented Josh Corman and Dennis Fisher (you decide which one is which) plus a “player to be named later”.  We will each have one minute to make our cases for or against a variety of incendiary topics, then we’ll give a couple of folks watching the spectacle a chance to add their opinions.  To make it more interesting, the panelists will be assigned pro or con positions, on the spot, by coin toss.  The goals are to 1: have fun, and 2: encourage conversation.

I will also be moderating a panel discussion on PCI at DefCon at noon on Sunday.  Yes, PCI at DefCon.  We have a killer team lined up for the panel, see the lineup and summary here.  I’ll be joined by James Arlen, (aka Myrcurial), Anton Chuvakin, Joshua Corman, Alex Hutton, Martin McKeay, and Dave Shackleford.  How’s that for a team?

I think our synopsis sums it up very well:

“PCI at DefCon? Are you on drugs? Sadly, no- compliance is changing the way companies "do security", and that has an effect on everyone, defender, attacker, or innocent bystander. If you think all that 0-day you've heard about this week is scary, ask yourself this: if a company accepts credit cards for payment, which is a more immediate threat- failing an audit or the possibility of being compromised by an attacker? That is one of the reasons "they" do not listen to "us" when we try to improve security in our environments- as real as they are, our threats are theoretical compared to failing a PCI assessment. Systems are hardened against audit, not attack. Sadly, this is often an improvement, but this can also reduce security and provide a template for attackers. This panel will discuss and debate strengths and weaknesses of PCI, expose systemic problems in PCI-DSS, and propose improvements.”

If you’ll be in Vegas for the fun, consider checking these out, they should be fun.

Jack

Wildly successful social engineering

Someone has done some wildly successful social engineering.  Amazing, actually.  I am not talking about the “Robin Sage” social media/social engineering case where a lot of people who should know better gave up a lot of information in a lot of different ways.  That may be interesting (we’ll see when it is presented), but even though some of the results were sensitive, that is building on a lot of prior work.
I am talking about the coverage of that story, where the reporting has largely been horrible, gullible, naive crap.  Sorry folks, but yes, that includes coverage from people I like.  If you believe a lot of what you read, you would think that a lot of people were “duped” into following/friending/linking/whatevering Ms. Sage.  This shows a gross lack of understanding of both social networking and the security community- both on the part of the journalists, and to a lesser extent, the researcher.
The people who “over-shared” really are a problem, and it may be interesting to see what Thomas Ryan (the person behind Robin Sage) presents at DefCon.  It looks like s/he got a lot of sensitive information from people who should know better- three letter agencies, military, and more.  Interesting, but “people are stupid and gullible” is not really ground-breaking, nor is mining/abusing social networking to prove this point a new idea either.  It does sound like the scope and scale may be noteworthy.  But not new, and being a skeptic, I’m not sure it is newsworthy.
Where things fall apart is the nonsense over stories which pretty much proclaim that MILLIONS OF SECURITY PROS DUPED, and point to the number of friends/links/etc. the virtually perky Ms. Sage gathered.  I would like to point out four things:

1. Different people use social networks in different ways.  Just because someone accepts your connection request does not mean they are fooled by you.  They may not even care if you are real or fake.
• Maybe they (sadly common) think that more connections means they are more important.
• Maybe they are public figures of some kind, and accept most requests as a matter of policy.  If people are careful with what information they share, there is nothing wrong with this. Nothing. It is voluntary, get over it.  It is how Social Media and Social Networking work for many people.  If you don’t like this approach- don’t use it.
• The decision to accept may be based on connections offered (via friend-of-a-friend linking) instead of being based on the person making the request.  Again, if you are cautious about what you share, there isn’t a risk here- even if it is a pretty shallow move.  Robin certainly had some interesting friends/links to entice people.  Put another way: Some days, the wingman scores.
2. Once Robin Sage became fairly visible, the drama got interesting and a lot of people began following/linking to the myriad of Robin Sages (yes, there were clones and evil twins, too) just to watch the train wreck.  I was one of these, and like many others I had my suspicions- but didn’t care if she was real, fake, or just another troll, there was entertainment.  People were not duped, they grabbed a beer and some popcorn and watched the show.
3. Robin Sage was called out.  Spotted.  Thoroughly outed.  Many thought “something was fishy”.  Some people did actual research and provided real details.  People had to connect/accept to do the research and confirm their suspicions.  The press almost completely missed this critical point.  They also missed the fact that once this was widely known, even more people connected to and followed Robin to watch the evolving train wreck mentioned in point 2.
4. Mr.. Ryan apparently convinced (socially engineered) much of the media into thinking this was something it wasn’t, then and the result was not journalism, it was an embarrassment.

And this is just the worst of it this week.  Half baked ideas, giant (and flawed) leaps of logic, obvious vendor spin, and more were on parade this week.  Maybe it was the heat and no one could think clearly.  Maybe it was Vacation from Healthy Skepticism Week and no one told me.  I don’t know, but I’m not happy about it.

Jack

[Note: since posting, the question of linking to specific examples has come up. I debated it while writing this post, but in the end I decided that the issue was so pervasive that calling out specific writers or articles would not have been productive.]

Security BSides Las Vegas announcements

The venue for Security BSides Las Vegas is phenomenal.  As great as that is, BSides is about content and community, and I’m happy to spill a few details about content.  The first few talks confirmed are great and there are plenty more killer talks to be announced.  Here are a few teasers:

David Mortman has assembled an all-star panel including Marisa Fagan, Erin Jacobs, James Arlen, Dave Lewis, Leigh Honeywell, and Rafal Los for “Mentoring, Mentee-ing (Telamachusing? Manatee-ing?) In Information Security: A How-To Panel.”: Come and learn how to get the most of out the Mentor/Protégé relationship from our panel of experts.

HD Moore will present “Fun with VxWorks”: this talk focuses on the VxWorks operating system, how it works, what devices use it, and how to compromise it.  The content will include background information on VxWorks itself, a checklist of common vulnerabilities, mappings from these vulnerabilities to shipped products, and a live demo of gaining access to a widely deployed commercial product.

Gene Kim will present “Mobilizing the PCI Resistance: Lessons Learned From Fighting Prior Wars (SOX-404)”: I have noticed that there is a growing wave of discontent from the information security and compliance movement around complying with the PCI DSS… My desired outcome is to find fellow travelers who also see the pile of dead bodies in PCI compliance efforts... and catalyze a similar movement to achieve the spirit and intent of PCI DSS.

Bruce Potter will bring bring us “How to Make Network Diagrams that Don't Suck”:  We've all been there.  You walk in to a network blind and the first thing you ask for is a network diagram.  What gets handed to you has apparently fallen out of a bowl of ramen and on to the page.  Overlapping lines, big arrows, and host names in print so small that only insects can read it.

Egyp7 will deliver “Beyond r57”: PHP is an easy language to learn and is among the most popular in the web development world.  Because of this, many PHP applications are written by novice programmers with little knowledge of writing secure code.  Combine that fact with a few poor design decisions and you end up with vulnerabilities in PHP applications being published daily.

And that is barely scratching the surface.  There will be plenty more, and there will be informal and impromptu talks, too.  And healthy conversations.  Maybe an argument.

And a first for BSides, we will be arranging a press area for BSides LV.  It is the place to be, and we want to provide those covering the event a place to hold interviews and get work done.

 

Jack

I just want to fix my car.

I'll close out my series of car rants with this one, on our ability to repair our cars.  This is not a new battle, but the front has moved into new territory.  The “Experimental Security Analysis of a Modern Automobile” paper touched on the subject briefly, pointing out that some of the “vulnerabilities” they reported could be addressed by locking down diagnostic and repair procedures.  They also stated that:

“...individuals desire and should be able to do certain things to tune their own car (but not others).”

Starts off good, then takes a dive.  So, who gets to decide what you can to to your car?  That is academic arrogance and lack of perspective there folks.  Yes, if I want to use my car on public roads, I have obligations to my fellow drivers and to the law.  If I am on a racetrack, the obligations are to my fellow drivers and the rules of the sanctioning body.  In the fields of my farm, the regulators, manufacturers, and pointy-headed academics can [insert your own creative answer here] themselves.

And on the commercial side:

“Similarly, how could mechanics service and replace components in a locked-down automotive environment? Would they receive special capabilities? If so, which mechanics and why should they be trusted?”

Once again, a little historical perspective…

Manufacturers have built vehicles requiring special tools for many years, and have tried to limit access to these tools to limit independent shops’ and do-it-yourself mechanics’ ability to maintain and repair vehicles.  Manufacturers have tried to restrict access by only allowing sales of some tools to authorized dealers, and when they can’t get away with that, they resort to making tools available at excessively high prices.  Special fasteners are the most obvious example, but there are few parts of an automobile which haven’t seen bizarre adaptations which require either serious creativity, or special tools, to access or repair.

With these physical components, we do have the ability to look at them and improvise- and tool manufacturers can make their own versions of the tools like the ones shown above.  Unless they run into patent issues, of course.

Going beyond repairs, tuning used to be a lot more obvious, too.  Changing some settings, swapping a few parts, these were commonplace tuning techniques.  Even the term “tune up” tells us something- we had to tune cars regularly, adjusting carburetors and points were regular service procedures.  One very common performance swap was replacing the carburetor, this was not done simply for performance, but for the ability to fine tune the aftermarket carburetors in a way we couldn’t tune factory systems.  For example, use of the ubiquitous Holley carbs meant that with some skill and patience, and a couple of boxes of jets we could precisely refine the fuel mixture fed to the engine.

We are now in a situation where a many routine repairs require interaction with the computer systems of the automobile.  Even tasks like changing fluids or servicing brake pads can require use of the computer systems.  Depending on make and model you may need one of these ~$18,000 (USD) systems to perform simple repairs:

(Note: that’s a real system used by some European manufacturers, they really are about $18k, and are just a feeble Windows 2000 laptop in a user-unfriendly form factor).

Repair information is, and has been, a bigger problem.  Mechanical systems can be torn down, inspected, and independent publishers could (and still can) create repair manuals.  The diagnostics, and the underlying operation information, was always where we fought for information; the move to computerized systems has made this information both harder to find and more desperately needed.

We can’t just look at the problem and improvise, that’s why we need the manufacturers to cooperate in making information available, or at very least we can’t allow them to block access to information.  This is not easy, there are standards, but there are also proprietary implementations- so we are back in the awkward Intellectual Property/software patents/reverse-engineering-breaks-DMCA world that is familiar to those of us in the information security.

And it is more complicated than that- if you reverse-engineer proprietary software on your computer and alter its functionality, what are the consequences for society at large?  Altering automotive systems can have a profound impact on fuel economy, emissions, braking and other safety systems- that can have a real impact on society.  Or, at least have an impact on the car in front of you if you’ve screwed up your brakes.  Again, a little perspective: we’ve always been able to screw up our cars, we are just exposing new ways to do it. 

Let’s not ignore government’s role in this situation.  Much of the push to computerization of powertrain management systems was a reaction to ever-tightening emissions and fuel economy mandates.  It doesn’t stop with the design of the car, either; most automobiles have to undergo inspections, many modifications to the fuel and emissions systems are likely to cause your vehicle to fail.

I do think the paper has highlighted a couple of real issues, and implementing some basic safeguards such as limiting the conditions under which certain commands can be executed, and limiting which systems can issue certain types of commands should improve the security of automotive computer systems without compromising our ability to repair our vehicles.

If you are interested in this issue, check out Right to Repair.  H.R. 2057 (PDF) the proposed “Right to Repair” bill looks like a good starting point, it is proclaimed as

“A bill to protect the rights of consumers to diagnose, service, maintain, and repair their motor vehicles, and for other purposes.”

And we could all use a little protection.  Of course, we often want protection from the government, so protections mandated by the government will require a bit of scrutiny.

 

Jack

A bit of deep thought.

A couple of weeks ago Michal Zalewski wrote a guest post for Ryan Naraine over on the ZDNet Zero Day blog.  It stirred up some conversation, but I wasn’t going to comment on it until I hung out with the Pauldotcom crew for their 200th episode extravaganza and Hackers for Charity fundraiser.  The post and responses came up, and after a little deep (beer-induced) thought, I decided to share a few thoughts, and offer links to a variety of responses.

First, I almost skipped the post, the first sentence lost me:

“On the face of it, the field of information security appears to be a mature, well-defined, and an accomplished branch of computer science.”

Seriously?  Anyone who thinks that is clearly delusional.  But I know the Michal is not, he is brilliant, and Ryan encouraged me to read the entire post.  So, I did.  Even though the rest of the first paragraph really isn’t much better:

“Resident experts eagerly assert the importance of their area of expertise by pointing to large sets of neatly cataloged security flaws, invariably attributed to security-illiterate developers; while their fellow theoreticians note how all these problems would have been prevented by adhering to this year’s hottest security methodology. A commercial industry thrives in the vicinity, offering various non-binding security assurances to everyone, from casual computer users to giant international corporations.”

I am not sure how someone Michal’s age attained that level of cynicism, but it is impressive.  He goes on to say we have had no successes in software security, elegantly define the problems in a few ways, and then leave us there.  Michal appears to be making the kind of assertions that triggered my last post, I think he could really use a bit of perspective.  But enough of that, if you are interested in an interesting look at software security from a variety of perspectives check out the following links.  Note: these are some seriously smart folks, It often takes me a couple of passes at some of the ideas to get it.

Michal’s original post is here.

Amrit Williams has a great response here.

Ivan Arce responded here.  Ivan is crazy smart, and this is a thorough response.  It may take a little digesting to grasp Ivan’s points.

David Mortman has a great follow up post here.

Michal has a follow up to his post on his blog, including some comments, and links to a few responses (including some of the above).

It is an interesting series of posts.  But remember, nothing you read in any of them changes the fact that tomorrow is “Patch Tuesday”, with all the baggage that brings.  So keep a little perspective as you read the installments of this little drama.

 

Jack

Time for a new mantra.

[NOTE: On re-reading this post before publishing, I realize it sounds pretty bitter in places.  It should.  But, I do want to make clear that I respect the vast majority people who do the hard work, even when I disagree with some of what they say, or the way they say it.]
We need a new mantra in information security.  We've heard various forms of "think like an attacker" for ever.  And it is absolutely true.  But seriously, enough.  Make the point to the new, the uninitiated, those outside our craft- but otherwise, stop it.  The choir knows the tune, and the chorus, and lyrics, and can do it in rounds while drunk.
Here's my proposal:

Run a [Optional: expletive of your choice] enterprise.

Or maybe just

Run a [Optional: expletive of your choice] network.

It doesn't need to be a big one environment, but your MacBook, roommate's XP laptop, and a NAS server does not count.  You need to run a network, remediate problems, scramble and patch, screw up, get yelled at when things go down, and occasionally score victories.  You need to see things work, and see things fail.  If you are both good and lucky, you may get to see The Next Big Exploit in the wild, and watch it pass you by unscathed.
I am not saying to stop thinking like an attacker, but I am suggesting that if we accept that defenders should understand the attacker, those who do attack research should experience the world from the other side.  A classic case of this is the "technology X is fundamentally broken" statements we hear year after year, con after con.  Many people don't understand why they are ignored by management and admins when they make these absolutely true statements.  I'll tell you why, because no matter what we're told about the failures of anti-virus, web filtering, IPS, or whatever, we've seen these technologies work.  Perfect, no.  Fewer helpdesk calls, yes.  That is success.  Limited success, sure.
I just want people to tell the truth, and offer solutions, even imperfect ones.  "Technology X does not work as well as you need it to, but you can minimize the pain by doing Y" will have people at your feet begging for more.
I am not even asking for researchers to "pity the poor admin", but should a little empathy develop, I'm good with that.
By the way, some of the criminals do get this.  When the new MSRT ships and your botnet starts evaporating, you learn a lesson.  Bonus points for retiring "Criminals don't play by the rules", that is the epitome of an NSR statement.  (NSR == No [stuff], Really?)
A little perspective goes a long way- which is a very good thing, because many in our business seem to have very little perspective.

Jack

Comments broken…

It looks like commenting is currently broken on the blog, trying to figure it out.  Since I’ve been too lazy to build and run my own blogging system, I’m at the mercy of the Googleplex to get this sorted out.  Sorry…

[update: it looks like only the last post has broken comments]

Jack

Continuing the car-rant

Time to resume the review of the car security paper.  I will not pick it apart completely, but I do need to hit several more points in this post and then I'll wrap up the car rant in one more post on access to tools and information.
Backing up a bit, one thing I skipped over was the choice of automobiles.  They chose one pair of identical cars, testing one stationary and one on a test track.  Their reasoning behind the small sample, and not identifying the car, is stated as:

"We believe the risks identified in this paper arise from the architecture of the modern automobile and not simply from design decisions made by any single manufacturer. For this reason, we have chosen not to identify the particular make and model used in our tests. We believe that other automobile manufacturers and models with similar features may have similar security properties."

I am uncomfortable with these blanket assumptions for a few reasons.  First, it is irresponsible to praise or damn an entire industry based on a single sample.  Second, I assume the technology levels of auto manufacturers have been somewhat leveled by regulatory and market pressures, but it is naive to think they are all the same, or that they all treat digital security the same.  Time for another trip back in time: Going back to the pre-OBD-II days, some manufacturers had barely moved out of the seventies, while others had forged well ahead.  For example, there was some argument of the number of pins to be included in the proposed standard connector- many manufacturers complained loudly and said it was impossible to supplied the required information in the small number of connectors.  Chrysler also complained about the proposal, but their complaint was that they were already supplying more information than required in a smaller connector, Chrysler objected to needlessly adding pins.  At this time, Ford technicians were still using breakout boxes and meters for some testing while many Chrysler vehicles were connected to in-shop computers to do the same, only faster and more reliably.  At the same time (early 90's) we had data capture devices available for Chrysler products which let us capture system data while on the road.  I remember dumping the contents to the shop computer, then to floppy so that I could wave them in engineers faces at conferences.  "If you look here on the fuel injector and ignition timing traces..." was a lot better than "I don't know, but the customer still isn't happy".  Moving forward, up until a couple of years ago I know that the quality and technology of diagnostic equipment varied widely between manufacturers.  From what little I've seen from friends and clients this still appears to be true.  I do not think it is unreasonable to conclude from this that testing of multiple manufacturer's systems is warranted before making any sweeping statements.
A technical and safety nitpick: On page nine, section V. B., they discuss the setup for the stationary tests.  They raised the car on jackstands and ran the drivetrain at speeds for the tests with the wheels and powertrain unloaded.  This means the operating environment of the vehicle was artificial and bearings were spun without load- a bad idea.  Also, without the weight of the vehicle on the wheels, had something malfunctioned there could have been out-of-control vibration, possibly bouncing the car off the stands with catastrophic results.  (This one is not theoretical, I've seen bad things).  In this configuration, they tested the electronic braking system- the rear wheels were stationary while the front wheels spun at 40 MPH.  Since there are wheel speed sensors on each wheel, this put the system in an unnatural state, it is not surprising they experienced different results between the static and road tests.  They did understand this, but understanding that they were "doing it wrong" is not especially confidence inspiring.  Although they repeated some tests on the road, it just shows a basic lack of awareness- especially considering the information they could have gathered by running the system on a chassis dynamometer.  Dynos are not rare anymore, either- state emissions testing stations in many states are equipped with rudimentary ones, and performance and speed shops have reliable ones available.  Running on  a dyno would not have solved the wheel speed sensor issue, but it would have addressed load and safety issues.  As far as the the wheel speed issues, depending on the sensor it may have been possible to solve with a simple little hack of the sensor outputs while stationary.
Moving forward to page twelve, we return to good (and disturbing) information:

"The fact that many of these safety-critical attacks are still effective in the road setting suggests that few DeviceControl functions are actually disabled when the car is at speed while driving, despite the clear capability and intention in the standard to do so."

Again with the poorly implemented or enforced standard- this is critical information from the report.  They also found that it was possible to bridge the high- and low-speed busses, that is just plain wrong, and potentially terrifying.  More important findings, I really wish I wasn't questioning everything by this point.
Hopefully you have read the report, don't just accept their findings (or my observations), but put some thought of your own into it.  I hope there is follow up study, and it is done with more caution and better research.
There is one more petty thing I wish to bring up.  They refer to computer managed automobiles as "cyber-physical vehicles", what the [heck] does that mean?  We do not need more cyber-hyphenated nonsense terms.
One more quick car post is coming, then back to your irregularly-scheduled drivel.

Jack

Scalable is an abused word.

Vendors love to tell us how "scalable" their products are.  Many, however, fail to grasp that scales have two ends- if you start in the middle and only scale "up", your product is not truly scalable, so stop saying it is.

That's it, just another bit of bitterness from a small business advocate.

 

Jack

Wherein Jack plays paper shredder

In my last post I started a series of rants about cars.  As I said, it has been simmering for a while, but a paper called Experimental Security Analysis of a Modern Automobile (PDF) pushed me to write.  While the first post was not specifically about this paper, this post and some later ones will be.  I'll reiterate that there is a lot of good information in the paper, but you need to sift through a bit of arrogance and ignorance to get maximum benefit from it.  While that is almost universally true of all papers, especially academic ones (they rarely have, or even give credit to, trench-level experience), it is often hard to accept the valid parts of a paper after discovering glaring errors.
Let's start with an excerpt from the very promising abstract:

"Abstract: Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks.  While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure."

(Note: In the Olden Days, we also had systems which "pervasively monitored and controlled " cars, they were called "drivers").
Damn right, cars have become more computerized and the systems are networked- and now more vehicles have multiple wireless communication systems, most (if not all) with some level of access to the onboard networks.  There's a recipe for a playground of badness.  So is this paper.  Rather than shred it entirely, I'll call out a few things which set me off. 
But first, venture back in time with me.  In the early sixties, we had cars with electrically-controlled transmissions.  Not especially reliable, but we had them.  Cars had computers before that, but we didn't call them that.  They were called "automatic transmissions", controlled by hydraulic decision engines which selected the appropriate gear based an a variety of variable inputs- including throttle position, engine load, engine speed, road speed- all under amazing temperature and vibration extremes.  There have been a lot of interesting technologies in autos, often appearing earlier than people realize.  And tinkerers, mechanics, racers, gear-heads, whatever you want to call them started hacking cars and their systems as soon as they got their hands on them.  And it was not new with cars, we've tinkered and pushed the limits of stuff since crawling out of the primordial ooze.  I think a weekend in the pits at an SCCA event might prove eye opening for many- the creativity is amazing.
Diving into a few specifics of the paper, we don't make it out of the first page before we get our first warning:

"Through 80 years of mass-production, the passenger automobile has remained superficially static: a single gasoline-powered internal combustion engine; four wheels; and the familiar user interface of steering wheel, throttle, gearshift, and brake. However, in the past two decades the underlying control systems have changed dramatically."

Maybe we'll let this slide, a bit of hyperbole to start the paper off.  We'll ignore diesel engines, the move from manual to automatic transmissions, front to rear wheel drive, etc.  But then we get to:

"While the automotive industry has always considered safety a critical engineering concern (indeed, much of this new software has been introduced specifically to increase safety, e.g., Anti-lock Brake Systems)"

Anti-lock brakes have certainly evolved considerably, but ABS was effectively mandated for heavy trucks by US FMVSS 121 in 1975.  Yeah, Gerry Ford was in the White House, scourge of disco was beginning to destroy a generation, and polyester was an acceptable fabric for something called the "leisure suit".  Not quite "new" systems.  Maybe I'm still nitpicking.  Cars are different than trucks (but not that different in many ways).  There really is a lot of good information in this paper.  (Of course, if they had let their mechanics read it after getting their cars serviced it would have been a lot better).
Then, we get to this gem:

"In this paper we intentionally and explicitly skirt the question of a threat model. Instead, we focus primarily on what an attacker could do to a car if she was able to maliciously communicate on the car’s internal network. That said, this does beg the question of how she might be able to gain such access.

"While we leave a full analysis of the modern automobile’s attack surface to future research, we briefly describe here the two kinds of vectors by which one might gain access to a car’s internal networks. The first is physical access."

Another little insight for you: if I have physical access to your car, I can now do with a computer, cables and custom software what has been possible for almost eighty years with a pocketknife- damage your brakes.  (Note, cars have been around for over a century, but use of hydraulic brakes was not widespread until the thirties).  You can really get creative with digital attacks, but you've been able to do creative brake damage by exploiting physical and hydraulic vulnerabilities, there's plenty more than simply cutting lines which can be done.  Switching gears (sorry, had to) to traditional information security, ignoring the threat model is best practices.  No, wait, ignoring threat models it is a horrible idea, but sadly common.

"The other vector is via the numerous wireless interfaces implemented in the modern automobile."

Now we're talking, this is a huge problem (at least potentially), and it needs a lot of research.  Skipping forward to section IV. C., there is more critical information.  Not surprising, but important- there are poor standards, implemented poorly and un-enforced.  That is not shocking to those of us in infosec, but especially scary when we're talking about interaction of physical safety systems.  It is a bit depressing that they are surprised by this, and surprised how easily the systems fell to fuzzing attacks, another sign that the authors may not have the real-world experience I would like.
I'll continue the rantview in an upcoming post, but I may become snarky, and possibly mean about it.

Jack