Okay, Uh, so we talked about monitoring the network for events, But let's talk about secure engineering and development now, because ultimately, the reason we have to monitor and the reason we have to secure and scan and do all those pieces is that
we don't develop software. We don't develop systems securely.
Now, I'm not really meaning. That is the blanket statement, it sounds like, But what I'm saying is, historically, we haven't had a focus on security, right? We've primarily focused on. Here's what the product's gonna do. We release it and then
six weeks later, we release a patch to secure it, which obviously is not a secure design process.
So what we want to make sure of is, as we're developing systems, and it seems your managers were responsible for making sure this happens, right? I'm not writing the code, but it is my responsibility to ensure there's a process in place to verify that our code is written securely.
So when we start with the concepts right in the feasibility study, can we do this? Will we do this?
We do an initial risk assessment. Okay. What are we gonna be protecting? What's it worth what are the threats and vulnerabilities? We have to look at how our framework is going to support the secure development of a product.
All right, then we have to get gather requirements, and these will be functional requirements first from the customer. The customer will give us those requirements, and we need to make sure that the customer is open with us. And it's clear with us about the amount of security that's necessary
for that product again, based on risk assessment.
Nowthe system analysis takes with the customers given us in functional. And the system analysis is where our developers say, Okay, here's how we're gonna build this problem,
the design. So, you know, we've we've mapped out the we've analyzed the system. Now we're gonna design the system. Then we're gonna actually write the code into the design. We're gonna check for security along the way, and, you know, again what we're looking to do is each step
we're focusing on security. It's not
that we look at security up front. It's not that we look at it on the tail in its that we incorporate security and everything that we do throughout the software and system development life cycle.
And then at the end, before we moved implementation, we go through testing
and testing. What were ultimately trying to accomplish is certification and accreditation and certification is the technical evaluation of a product.
Uh and really, if the security features of a product in a specific environment
in the environment for which it's designed for so certification is technical, Does it work securely is what we're looking at
and then accreditation, which more recently has been known as authorization that's management's acceptance of the product doesn't meet our needs. So at the end of this process, testing have we designed it securely. And if so, testing should yield certification
than ideally, senior senior management will say yes, This meets our needs.
Now when we are developing with security in mind, one of the things that we do is threaten modeling
and threat, modelling says. Okay, so we know what we're using this application for
what? How could it be? Miss you. So now you hear people talk about a use and misuse case. Well,
some of the more common threats within applications you can think ever you can remember the astride *** spoofing tampering, repudiation, information, disclosure, denial of service and elevation or escalation of privileges. That's what Strides stands for.
So if we're gonna look at the threats,
stride well, we also have to figure out the mitigation strategies for each of thes and figure out how to implement them. Now I do think that you need to know stride like they might even say,
You know, I can't be surprised if they said What is the D in stride?
But I wouldn't rule it out. So make sure you know this because it's such an important element
of application development, this threat model. Okay, All right, so it's smooth things. The problem. Smooth things, impersonation will. The solution is authentication, and not just authentication, but strong authentication. Multi factor proved to me. You are who you say you are
through something you know and something you have or something you have and something you are
authenticity, multi factor. More than one type of authentication.
All right, we're worried about tampering as the tea and stride. Well, let's put integrity checks in place, whether they're check sums or integrity. Validation of verification checks, hashes message digests. So ultimately, if you're worried about tampering. Incorporate integrity.
Now I love the next one. The problems repudiation. What's the solution?
Okay, so what is repudiation? So repudiation says I can't well, that I can either dispute having sent the message toward the contents of the message, That message didn't come from me. It must have been spoofed
or yeah, that message came from me. But that's not what I said. Somebody's modified,
right? So what we have is a combination of authenticity and integrity being questioned.
what's our solution for? That is a digital signature, and we're not going to get deep into crypto here. But Digital Signature takes a hash that is placed on that document for integrity.
The hash is encrypted with the sender's private key. So you know it came from that center. That's authenticity. When you get the two together, you get non repudiation. We get that through digital signature.
All right, information disclosure.
You know, if you want information to be protected from unauthorized disclosure, encryption is a quick, easy way. You think about that
to avoid denial of service, we have tohave
Excuse me, you on there to avoid denial of service we have tohave high availability. We get that through redundancy and fault tolerance, eliminating a single point of failure. Resiliency means a system that can withstand an attack. So those are the ways we get
mitigation for denial of service
and then the last escalation of privileges. So if I gain access to your system as just a regular user,
that doesn't help me a lot. So we have to control and make sure that individuals are on Lee authorized to the degree that they should be. But then we also have to make administrative accounts require strong authentication. We have to make sure that users are authorized
to add permissions to
two accounts or use escalated privileges. So when we look at those elements, those come together on the left. What's the threat
on the right? What's the mitigation?