Product Design (Software)

00:00

Hi, I'm Matthew Clark, and this is less than 5.4 product design software.

00:06

In this lesson, we will take a look at software development, including interdependencies and challenges,

00:13

and we will talk about software design concepts and conclude with a short case study.

00:18

There are a lot of software considerations when it comes to security, including planning for multiple devices and multiple APS where end users may talk to UM I o t devices through gateways or through mobile lapse or through Web pages.

00:34

You have to plan for end user privacy, including giving and users stability to opt in or opt out and ability. Exercise the right to be for gotten

00:42

as well, securing in user specific data and anonymous izing that data when collected into big pools

00:50

as well as securing the supply chain as well.

00:53

And considerations for security is related to the device. The cloud in the mobile app from securing that application data and securing the encryption keys to providing for correct logs, protecting databases and, of course, planning for firmware.

01:10

I really like this picture time, cost and quality. You can have any two of these just choose wisely.

01:17

I o. T devices of many constraints that software developers have to account for,

01:21

and resource constraints tend to be one of the biggest factors to plan for. For example, a developer may be working with the MIPS, or arm processor, but developing code as if it would run on a more powerful Intel. Chua

01:34

software has to be written for the environment in which will run

01:38

I O T devices tend to have less. Memory is well, and this has to be taken into account when designing processes

01:45

and with sensors, especially storage is going to be more like flash. Maybe there'll be an SSD, but certainly not hard This

01:53

so the developer has to plan for the efficient use of code and including only libraries that are absolutely required.

02:00

Remember as well that flash has a limited number of rights, so power could be an issue, especially if the device goes off battery.

02:08

This can cause issues in which you may not be immediately consider or immediately aware of. For example, updating the flash on an embedded censor that runs off of a battery can reduce the lifespan of that battery,

02:22

and this problem is multiplied. If the device is in a difficult to reach location or the battery is just not serviceable.

02:29

If a requirement is not properly planned for during their apparent requirements, gathering process thin. Trying to code for it later can also cause issues,

02:38

especially if there's not proper hardware support for what you're attempting to do in software.

02:44

So remember that every decision has a positive and a negative effect. And sometimes there's a second or even third order effect that you might not even realize until you get further down the road and testing the device within the overall ecosystem.

02:59

And finally, remember that hardware doesn't always act exactly as planned. Most of us have had an experience where, according to the hardware specifications, some software was supposed to run. And of course it didn't or there are problems.

03:15

Software development for I O. T. Can be more difficult than other types of software development. I ot developers air generally using a limited software stack running on constrained hardware. Resource is

03:27

so if a coding bug makes its way past Q and out into the field, it's not always an easy process updated

03:34

as field updates can be difficult to manage, depending on the I o T. Application

03:38

and hardware development doesn't always make for good, standard, agile environments

03:45

many times due to the nature of dealing with the hardware itself. The waterfall method Maybe more appealing, of course, software development can be run in virtual environments and can be tested in simulation. But to truly know of something was gonna work or not. You have to wait for the hardware to be completed.

04:02

And while modern software developers tend to like the agile method

04:06

and it supports multiple pushes of code base to production

04:11

in the real world, you don't often push code to update I o T devices multiple times a day like you can with an a p i r A Web page Alexa Circular Light Turning red a few times a day is going to drive someone crazy.

04:26

One thing to keep in mind is that changes. The software must be backward compatible.

04:31

You can't make a change the software that will break devices released years ago

04:36

and which are currently sitting dusty on some long forgotten warehouse shelf and then sold to an unsuspecting customer because the big box store such chooses to suddenly liquidate inventory

04:48

devices have to also be able to survive updates or the lack of updates,

04:53

and you have to be able to support all versions of the firmware that you've released in perpetuity forever. With no exceptions,

05:00

the sun s mess January of 2020 is a good riel world example of the issues that can arise when manufacturers decided to stop supporting older versions of their products but no longer providing updates.

05:15

This should underscore the importance of having and commuting, communicating a device life cycle.

05:21

Mhm.

05:21

So let's finish by talking about the 2018 t Mobile AP I incident.

05:27

And this was an incident that occurred that I really didn't remember. I might not even have been aware of it when it happened. There's so many different things that go on.

05:35

But this is a pretty good one, too. Review, I thought, and fit in nicely in the software section.

05:41

Granted, there are a lot of issues with software vulnerabilities, bad coding, lack of security controls on just, you know, things that make your make you scratch your head that we could talk about. In fact, you could probably take entire lesson about software issues.

05:58

Um, but we need something really short and small it easy toe easy to digest in this one seemed to be a pretty good fit. So let's go through the problem. And then let's talk about some of the ways in which we could have controlled this.

06:10

The problem was that the sub domain, the promo tool dot t mobile dot com, which could easily be found on search engines,

06:16

contained a hidden A P I that would return the T mobile customer data simply by heading the customers cell phone number to the end of the Web address.

06:26

Although the A P I was meant to be used by a T mobile staff toe look up account details, it wasn't protected with a password and get easily be used by anyone.

06:36

And the type of data it returned was lots of, you know, valuable information about the customer, including their full name, their postal address, their building account number and, in some cases, information about tax identification.

06:50

So there's several things that T Mobile should have done. First of all, they should review the code prior to releasing it. They should have reviewed the a P I. It looks like the only security control that they released was security by obscurity, which is not really a security control It all. It's just hoping and praying and and looking the other way.

07:11

Um, T Mobile did pull the A P I offline the day after it was reported in early of April 2018

07:17

by security researcher Bryan Stevenson, who was later awarded $1000 in a bug bounty.

07:25

And the T Mobile spokesman said that their Bug bounty program exists so that researchers can alert them of vulnerabilities, which was what happened there, and they supported that type of responsible in coordinated disclosure on We're gonna talk about developing a responsible disclosure program and bug bounties in a future lesson. And here's another great example of

07:45

company who has won

07:46

it is actively using it.

07:48

Um, so these are the things that you have to plan for if you have security. If you have technology that's out there, you need to have security with it. And really, the only way toe be absolutely certain that your security is working is to provide a mechanism for C feedback,

08:03

which is what happened here, which was good.

08:07

Well, that's it for this lesson. So what do we do well. We took our brief trip into the mysterious world of software and the product design process.

08:16

We looked at different security considerations. We discussed constraints and challenges, and we reviewed case study with T Mobile.