3.15 Hardware and Software Risks

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

6 hours 30 minutes
Video Transcription
as we move forward, let's go ahead and look at some more specific types of risks that we might identify, particularly in the world of information security. So in that case, we're gonna have to look at hardware risks, software net risks. We're gonna have to think about risks related to the network. What think about emerging technology?
So let's go ahead and get started with software well, with hardware and then software risks.
So when we're looking at our existing environment, we've got to start well, not necessarily the first place you start. But I generally tend to start with hardware. What's the hardware that we have within our environment and what are the risks associated with it?
So when we talk about hardware, of course, we're talking about those physical elements of a system. Those things you can touch
so processor memory keyboards, monitors on unknown known right, all those things that you can physically touch on a system. Well, unfortunately, all of those elements each and every one of them have their own risks associated.
So, for instance, when we talk about
the group of hardware's a whole, probably the greatest risk that I see is organizations using outdated hardware with the idea of If it ain't broke, don't fix it.
So what that's really saying is, let's just wait till this gets broken and usually it's Let's wait till this gets broken spectacularly, and then we'll think about fixing it So outdated hardware.
It is generally not capable of performing with the industry standard for security or for performance. It's just not up to par. So on a regular basis we need to go back and evaluate our hardware for risks. We have to think about hardware that's perhaps Miss configured or configured with
default settings.
We have to think about lack of configuration management again. I'm not gonna read all of thes, but some that are particularly important where I've got hardware on my network. But it's not really documented. The type of hardware, the hardware configuration, we've got to think about who can physically access the hardware.
Uh, not making this up. I went to take my kids out to get their pictures done for Christmas last year,
and I went to ah little photography place in the mall, and I went to the restroom while everybody was getting ready and I kid you not on the back of the toilet at the photo shop was their router.
And so all the cables going up into the roof. But right, there's their router.
You know what? That's really poor physical access control. I know that shocking to you that that's not a great idea. But I would recommend that your routers, your network devices be protected, right? Very easy for a man in the middle of denial of service attack.
And if you think about all the money that's flowing through a photography store
around Christmas time for kids, you know everybody's just throwing money to get those kids pictures done so really big concern.
Um, also, we would have to think about hardware that is not discarded properly. I used to buy computers back in the for 86 days. I used to buy computers, ham radio shows and yard sales,
and I take him home and I was stunned. Not a single system had been wiped clean of information. One of them even had a family's Quicken information.
It's like, really, that's a pretty big deal.
So we've got to make those considerations now, um, with software risks, you know, and I think if we just talk about risks associated with software you guys could probably come up with with quite a few. But let's start by looking at the S T l C the software development
life cycle.
So of course, the idea being that we need to implement risk management or we need to evaluate each step of the S T l C from a risk management perspective.
So you will come across a large number of different software development life cycles. I so has this, you know, set of steps. NIST has a set of steps. The one in front of you currently Do I think it's from this? I can't remember the NIST special publication, but ultimately
this tends to be the one that I'm currently seeing more and more on various exams, whether C I S S P or
says over schism mercy risk. So I would focus on this S t. L C model, so initiation, development, implementation operation and then disposal and what you'll see over here on the right is for each of the phases of the splc.
We've got to think about particular risks or you could say risk particular to that face
So as we move forward, the risks were getting more and more specific to the product and really more and more specific how the impact could carry over to our organization. I would recommend reviewing the slide and being pretty comfortable with the right hand column about risk management activities at each phase.
Now, some of the greater categories of software risk, you know,
unpatched software.
Um, it's software that's improperly configured with software development. The very 1st 1 Know that data validation that's huge. We see that it's an impact databases all over the place,
making sure that we have version in control. We have changed management with software
backdoor software that gets installed on the system, sometimes referred to his maintenance hooks when they're installed intentionally by developer so a developer might install maintenance hook that helps them quickly get back into the actual code. But if we don't remove those maintenance hooks, then all of a sudden we have back doors.
So all of those software
risks you can think of those air absolutely right, and I would make sure that I'm thinking about that. In contrast to the software development life cycle, once again just going back to this that we have to plan security for a system and we have to implement security at each phase of the S T L C
no longer at the end or at, um,
operation. You know, so long we function on that. We focused on functional operation of software. While security needs to be considered part of the functional baseline,
meaning, we don't just say is it secure
and doesn't work? We say, Does it work securely or it doesn't work at all.
Hey, so once again, just a collection of software risks. But I'm sure you guys can think of others. They would apply as well.
Up Next