Ford going to ditch microsoft?

[theoldwizard]

Many times security edicts come from outside the IT department, which is sometimes a good thing.

Several years ago, Ford and all publicly held corporations had to comply with something called the Sarbanes-Oxley Act. CEO/CFO and other senior management became legally/financially responsible for the data that was reported in finance statements. Of course, for most corporations, this meant first documenting what did exist and defining procedures so that the data was both accurate and secure.

 

In Ford's case, IT and Finance came up with a HUGE set of procedures and processes. Once it was reviewed and approved by multiple middle levels of management, it was sent up to very top and requested that these become the "law of the land" punishable by dismissal. Fine. I have no problem with that for Finance data and probably even Human Resource data.

 

The problem was, IT requested and received, permission to make these apply to all computers in the entire corporation. There was a limited window for coming into compliance, but no funding or assistance to become compliant for computing that was not already within the span of control of IT.

 

Fast forward 12+ years. Nothing has changed. Certain engineering organizations still run their own computers, but they are certainly not "in compliance".

[akirby]

Boy you don't realize how IRONIC that statement is !

 

Powertrain software has ALWAYS been done on "servers" (the term "server" did not exist 30+ years ago; they were just large "time sharing" machines) and still is today.

 

The management is so naive they think the software engineers are actually doing development work on their desktops when the only thing they use them for is to remotely log into multiple flavors of Un*x servers.

 

IT is very good at say "You shouldn't be doing this" and very bad at stepping up and actually helping to migrate to something they do approve !

 

Unfortunately that's pretty common in a lot of companies. And it just encourages developers to go outside the process to get their work done. Fortunately our desktop folks are part of the IT organization so it's a little easier.

 

Virtualized servers and desktops are making it a lot easier.

[NickF1011]

 

but they are certainly not "in compliance".

As with most things government, there's almost always ways to get exemptions.

[fordmantpw]

SOX compliance essentially amounts to the developer building the script, then the DBA running the script without actually looking at it or knowing what it does, but the DBA has to run it because the developer has no permissions. Then, any issues with the script are darn-near impossible to fix since the DBA doesn't have a clue as to what any errors that occurred during said running of the script mean.

 

At least, that's the way it works at the client I'm working with. And yes, every single app has to be SOX compliant, no matter how important it is.

[akirby]

SOX compliance essentially amounts to the developer building the script, then the DBA running the script without actually looking at it or knowing what it does, but the DBA has to run it because the developer has no permissions. Then, any issues with the script are darn-near impossible to fix since the DBA doesn't have a clue as to what any errors that occurred during said running of the script mean.

 

At least, that's the way it works at the client I'm working with. And yes, every single app has to be SOX compliant, no matter how important it is.

 

The way it should work is you develop and test the script in the dev/test environment where the developers do have access. Once it's tested it goes to production where you have separation of duties - no developer access, prod support, dba and sys admin only. But if there is a problem we grant the developer temporary access to troubleshoot which is tracked and documented so it's auditable. Sounds like your client got carried away with separation of duties and failed to apply common sense.

[fordmantpw]

 

The way it should work is you develop and test the script in the dev/test environment where the developers do have access. Once it's tested it goes to production where you have separation of duties - no developer access, prod support, dba and sys admin only. But if there is a problem we grant the developer temporary access to troubleshoot which is tracked and documented so it's auditable.

 

I have no problem with that, as it should work that way. However, part of the point of the DBA running the script is another set of eyes on what is being modified. But, the DBA's don't even look at the script and just run it. So, what's the point of having the oversight if they are just going to run what you send them without so much as looking at the tables you are modifying the data in?

 

Sounds like your client got carried away with separation of duties and failed to apply common sense.

 

Yep, that's exactly what happened. A couple of the folks in charge of security are a tad over the top. And the crazy thing, we can't even use complex passwords because you can't use special characters with the system they use to sync passwords across systems. So, let's take security over the top, but not start with the most basic of all security items.

 

Ah well, venting won't fix it.

[akirby]

 

I have no problem with that, as it should work that way. However, part of the point of the DBA running the script is another set of eyes on what is being modified. But, the DBA's don't even look at the script and just run it. So, what's the point of having the oversight if they are just going to run what you send them without so much as looking at the tables you are modifying the data in?

 

 

Yep, that's exactly what happened. A couple of the folks in charge of security are a tad over the top. And the crazy thing, we can't even use complex passwords because you can't use special characters with the system they use to sync passwords across systems. So, let's take security over the top, but not start with the most basic of all security items.

 

Are the DBAs prohibited from looking at the script, or do they just choose not to? We require the DBAs to review and approve any script they run just to make sure they don't see any gotchas like cartesian products, etc. Not allowing that is just stupid.

 

We use RSA tokens for password security which works better and sidesteps the password rules and reset issues.

[fordmantpw]

 

Are the DBAs prohibited from looking at the script, or do they just choose not to? We require the DBAs to review and approve any script they run just to make sure they don't see any gotchas like cartesian products, etc. Not allowing that is just stupid.

 

We use RSA tokens for password security which works better and sidesteps the password rules and reset issues.

 

They aren't prohibited at all...they are supposed to look at them, just don't, and it isn't enforced. They're just too busy, and it takes a week to get me a copy of yesterday's backup of our (still very small) database. I don't want it restored, I just want the backup file and I will restore it to my local machine for comparison.

 

We used to use RSA tokens for remote access, but now use Syferlock's GridGuard (http://www.syferlock.com/?q=basic-page/solutions). It's actually pretty cool, and much handier than having to carry a token around with you.

[akirby]

I have a soft token on my laptop and phone so it's a no-brainer.

[fordmantpw]

I have a soft token on my laptop and phone so it's a no-brainer.

 

Ahh, I see. We had the physical devices that I ended up giving to my kids to play with until the battery died.

[theoldwizard]

The way it should work is you develop and test the script in the dev/test environment where the developers do have access. Once it's tested it goes to production where you have separation of duties - no developer access, prod support, dba and sys admin only.

That is 4 different people. Most engineering departments running their own computer systems are lucky if they have 1 and a part time backup for when that person is sick or on vacation.

 

Sounds like your client got carried away with separation of duties and failed to apply common sense.

That would describe Ford IT exactly.

[fordmantpw]

That is 4 different people. Most engineering departments running their own computer systems are lucky if they have 1 and a part time backup for when that person is sick or on vacation.

 

That's a different story. If you don't have an IT department, then you make do with what you have. If you have an IT department, the engineering group should be working through them for development and deployment of apps.

[2014FusionSE6Spd]

I hope they dont, unless it was in favour of a better system. But I think a better system at this point in time doent involve the computer but mileage. lol

[Botts]

They aren't switching to Microsoft, are they?

 

Every operating system has pros and cons. Maybe Google is offering their OS cheaper to gain market share? In the end, it's just the O/S. Has nothing to do with the application which runs on top of it with HTML 5.

 

The only objection I've heard to QNX is that it's owned by RIM whose consumer smartphone business is in trouble. And again - that has nothing whatsoever to do with QNX or its future as a mobile operating system.

Google's OS is free, so it by definition is cheaper than QNX or MSFT.

 

I'd seriously doubt that QNX is in trouble, or lacking a future. Apple wouldn't have picked it to try CarPlay if they were concerned about future viability. Apple's got a lot of reputation on the line with CarPlay.

 

I just hope that Ford doesn't abandon current Sync customers. I have a brand new Focus ST on route with MFT, and I seriously hope it continues to get updates into the future. Or, that iDatalink comes out with a Maestro to enable full removal of MFT.

 

With everyone saying that the problem exists with the user, I disagree. While MFT does function, and is stable now, it is certainly not intuitive or quick. I learned it in a 2,000km drive in a rented Explorer with MFT, and it functioned well for me, but if you were to give it to my mother for example, it would be an utter failure. GUI design, and interface is crucial in a system like MFT which is going to be used by users who don't want to play with it to get good, but just want it to work.

 

 

I'd love for Ford to just adopt iOS in the car. It's the logical move to have all the processing on your phone.

 

Then as your phone evolves, your car won't be holding it back.

There is no such thing as iOS in the car. It's carplay now, and it's powered by QNX, which is the software Ford is apparently switching to.

Edited April 2, 2014 by Botts

[NickF1011]

 

Google's OS is free, so it by definition is cheaper than QNX or MSFT.

 

Well, at the very root for the OS itself, sure. But most of the costs aren't in what you're paying for the license for the base OS.

[Bailey151]

With everyone saying that the problem exists with the user, I disagree. While MFT does function, and is stable now, it is certainly not intuitive or quick. I learned it in a 2,000km drive in a rented Explorer with MFT, and it functioned well for me, but if you were to give it to my mother for example, it would be an utter failure. GUI design, and interface is crucial in a system like MFT which is going to be used by users who don't want to play with it to get good, but just want it to work.

 

 

There is no such thing as iOS in the car. It's carplay now, and it's powered by QNX, which is the software Ford is apparently switching to.

 

 

I'd vote differently - if you can't figure out MFT I'd wager a knife & fork is too complicated. I mean you start with a screen with 4 sections - want to control one in detail then push that section.....whew, I'm all worn out now.

 

And that's Carplay today.......Apple will NEVER move forward & keep this structure. They will either buy QNX or they will move it to iOS. They never have & never will give up full control. Yeah, OSX is Linux with a playskool interface ontop but it's their release of Linux. Just doesn't suit Apple's way of doing things.

 

 

Well, at the very root for the OS itself, sure. But most of the costs aren't in what you're paying for the license for the base OS.

Yep...........and winner, winner Google's OS has more holes than swiss cheese. Take some work to make it car safe.

[Botts]

Yep...........and winner, winner Google's OS has more holes than swiss cheese. Take some work to make it car safe.

You could probably resolve some of that security concern through sandboxing. But then you'd be limiting a few key features.

[expresspotato]

Yep...........and winner, winner Google's OS has more holes than swiss cheese. Take some work to make it car safe.

And how many hundreds of thousands of security updates has windows 7 had? LOL KB9808828283903303090....

 

Also OS X runs Unix under the hood, not Linux.

[rp2388]

And how many hundreds of thousands of security updates has windows 7 had? LOL KB9808828283903303090....

 

Also OS X runs Unix under the hood, not Linux.

I know I would rather have someone send out a bunch of security updates than assume my system is safe because that OS is supposedly "virus proof"

[jinx8402]

You could probably resolve some of that security concern through sandboxing. But then you'd be limiting a few key features.

 

That's already how Android works though, and it is pretty damn secure. It's users who can make the OS non secure (rooting, downloading apps outside Google Play Store etc), which is true for any platform. I get what you are saying though: Car manufacturers could sandbox further, limiting capabilities.

 

http://lifehacker.com/how-secure-is-android-really-1446328680

[Iggnutts]

background: I'm a software developer/analyst who has worked with QNX in the past. I contracted for 2 years, to help update and fix railroad user interfaces to display realtime data from track devices, and car locations. It was an OS like any other OS, it had it's good things and its bad things. QNX is used in all sorts of systems from the ones I worked on to medical devices and so on. Anything in need of a fast, small realtime OS, usually in an embedded environment (i.e. not your typical pc setup).

 

I've read some things on QNX in the auto interfaces. I think they would again build their own apps/interfaces on QNX, and also API's to allow any cell phone manufacturer to display from phone to car screen.

 

This is a good thing. Choice. Rather than nail it down to one phone OS or another, you get to display some apps from whatever phone you choose to own on top of the car manufacturers interface.

 

here's a link to a QNX web site with a video. Its mostly people waving their hands about but there is some pretty cool screen shots near the end of the video. Happens to feature a bentley, and some folks might be turned off by all the Macs being used to develop the tech, but oh well. I'm a Mac fan myself. The video features a Bentley.

 

http://www.qnx.com/products/qnxcar/

 

Another link with some pics and some video, looks like a jeep.

 

http://www.motorauthority.com/news/1079243_a-look-at-the-near-future-of-in-car-technology-qnx-car-2/page-2

[akirby]

Exactly. The OS is almost irrelevant to the end user and final product provided it is stable. And a real time OS makes more sense in a vehicle.

[guszern]

Apple, Microsoft, Google, QNX are all working hard to make systems that work well. They all know there is big money involved and want their piece of the pie. Each will have its own pluses and minuses. I just want one the looks appealing and is responsive. What's on the back end doesn't matter to me.

[fordmantpw]

I just want one the looks appealing and is responsive. What's on the back end doesn't matter to me.

 

Bingo!

 

I'm a Microsoft fan (and developer), so I would love to see MS and Ford together, but in the end, it doesn't matter what is on the back end, as long as the user is happy with what is on the front end. (I'm talking about software/hardware components here, not women)