Part 4 - Why is Software Unsecure

Video Activity

This lesson focuses on the reasons why software is insecure and the reasons discussed in this unit are: • Lack of training • Lack of funding • No prioritization of security • Security as an afterthought Also talked about in this lesson are Internet Protocol Version 4 (IPv4) and IPv6. IPv4 is has no inherent security however IPv6 has security by IPS...

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

Already have an account? Sign In »

5 hours 54 minutes
Video Description

This lesson focuses on the reasons why software is insecure and the reasons discussed in this unit are: • Lack of training • Lack of funding • No prioritization of security • Security as an afterthought Also talked about in this lesson are Internet Protocol Version 4 (IPv4) and IPv6. IPv4 is has no inherent security however IPv6 has security by IPSec, which is a secure framework for traffic.

Video Transcription
Now, as we've been talking about the importance of security in software in our applications in the entire life cycle process, the question becomes, Well, why haven't we done it before? Why is software so inherently insecure? The principles that we're talking about make perfect sense.
And yet we've seen,
um, unsecure software, year after year, vendor after vendor, you know, implementation after implementation. So why is software currently unsecure? Well, first of all, I had asked the question earlier, How many's you've been through some sort of introduction to programming class?
And many of you, I'm sure, said, Yeah, I've been through them.
And then I say, Well, how much of that training included instructions on writing, secure code and almost always The response I get is absolutely nothing. That was my personal experience as well. I went through programming classes in high school and in college, and not one bit of the class focused on secure code.
It was always on functional code
with the idea of well will field security later, they're always service pacts and hot fixes that we can release. So the option that we're not training our programmers to write secure code and that our philosophy is security can always come later.
Um, you know, look, a t c p i p.
Specifically, let's look at I p the protocol of the Internet Internet protocol I P version for which is what we're currently on until we moved to I p version six. Now I love this I p version six until we move there because
I've been in I t for 20 years and it feels like we've been moving towards I P six the entire time
it's coming. It's coming. It's coming where many countries air already exclusively on I p version six were really dragging our heels here in the U. S. And I think to some degree a lot of us are hoping it will go the way of the metric system. You know, if you think about that, how many countries air on the metric system
pretty much everybody except us.
And I think we're gonna be the last holdouts to move over toe I p version six. Why?
It looks hard.
It looks hard there. Coghlan's and they're in 100 and 28 bit. Why are there letters in my numbers? It's in Hexi Decimal, you know I think that there really is an internal foot dragging that's going on. Um,
then I do realize their costs associated with the upgrade in the changes, and I do understand all that piece. But at some point in time, we have to make the decision that we're either going to i p Version six or we're not
now one point in time. The impetus to go to I p Version six waas We're running out of I p addresses. And even though at one point in kind that looked like a major issue, it really isn't an issue today because of network address. Translation. If you're familiar with network address translation,
it's a means of masking internal I P addresses
and having only one extra I p address. So where is we were concerned about having, You know, I've got 500 hosts that need to be having the network on the Internet. I need 500 unique I P addresses. Will we no longer have to think that way? And often we have multiple layers of Nat behind that behind that.
So we really are not as concerned about moving I p six because of running out of I p addresses.
We need to think about moving the I p version six because we're unsecure in I p version four.
What I mean by that is when we look at this protocol, there is absolutely no built in security. There is nothing that inherently secures I. P v four.
It wasn't designed to need protocol security because originally it was designed to be used to provide communication across very secure physical links by the government by the government in the military.
So when I have these highly secure physical links, I don't think so much about protocol security.
But what we find happens is often a mechanism that was created for one environment, sort of outgrows that one use and then finds itself in different environments that it wasn't specifically designed for. So now we have this protocol that was designed for very secure environment.
Being used to help us connect to the Internet, which we know is is not a secure environment.
The Internet's a bad neighborhood,
So what we've got to do is we've got to go back and secure it as an afterthought, and any time we have to go back and fix something as opposed to designing it right from the start. It's always more effort, and it's never gonna be quite a successful as if we have integrated security,
a lack of funding. You know, when we develop software and we have a due date of April 15th that software better be due on the 15th.
And I'm not gonna provide additional. Resource is I'm not gonna provide additional funding. I'm not gonna provide. There's additional things that are necessary support so that my software developers can make sure the code is secure. Ah, lot of times we look just on function, produce it and again will secure it later.
Security isn't a high enough priority,
so it's very easy to blame. The developers Will. You guys aren't writing secure code, but really, what it comes back to is the requirements when it comes back to the project managers and our understanding that security costs money.
If I were to say you will pay for security somewhere along the line, would that be true?
And I say it's absolutely true. You can pay for security up front and you can write secure code. You can do tests and validations. You can work and focus on your process, and that will be your expense with security.
Or you can write unsecure code and the cost will come in compromises and in attacks. So it's our choice where we're going to spend money on security, but it makes a lot more sense to spend that money up front.
Up Next