Okay, so we've spent a good amount of time in part one, which was determining the general security concepts and understanding a little bit about risk management, understanding some of our goals, the things that we want to accomplish in just some good foundations. So hopefully what that means is we can move through the other chapters
fairly quickly because we've already established a lot of the frame working on a lot of the things that we need to build upon.
So part two is where we're gonna focus on secure software requirements and requirements are essential. You know, if we don't collect our requirements properly and if we don't have good requirements to base off of Well, obviously nothing we do from this point forward is gonna matter, because we're not gonna be meeting the customer's needs.
And one of the things that we're gonna talk about later is when we talk about
producing a quality product, quality means the degree to which an object meets its requirements. Well, if we have poor requirements, we might design and build a product that meets the requirements. And yet the customers still not satisfied because we failed to collect accurate requirements
and good, strong, accurate requirements. And we failed to get sign off or buy in from the customer.
So all that's obviously a big deal.
All right, so what we're gonna look at in this section, we're gonna look at what we call smart requirements, which means, you know, sometimes requirements can be so vague or nebulous, they can just be floating out there. I want to develop a software program that will improve customer response or customer satisfaction.
Well, what does that even mean? That's a very vague term. That that's a great idea. Let's make things better.
But how? We want to make it easier for our users to inner incident response to our incident tracking.
Okay, fine. But again, how can I measure that? What does that really look like? In actuality? So smart is gonna give us some guidelines for what our requirements should be.
All right from there, we're gonna talk about the different types of requirements core security requirements, general requirements, operational requirements, and then some other things. So when we talk about secure course security requirements, these air the ones that, of course, we're concerned with as security professionals, making sure that we don't have
issues with input validation, making sure
that we provide cryptographic support as necessary. Anything around the the realm of C I A. Try at confidentiality, integrity and availability. Also, we've got to think about things like authenticity, authorization, um, accountability or auditing.
So any of those elements are going to come under score security requirements.
We cannot fail to document core security requirements for so long. What we've done is we focus so heavily on operational requirements, and then we decide, Well, let's secure it later. Let's make a product that works, and then we'll release a security patch down the line. We've got to stop thinking like that are
functional. Baseline includes security
so it's not, doesn't meet requirements and visit secure, but doesn't meet requirements securely or it doesn't meet requirements at all. And that's so very central to what we're doing. So we're gonna establish good core security requirements before moving on.
All right, we'll talk about some general requirements, things like error and exception management. How's that gonna work? Session management? You know, some of those more general ideas that aren't necessarily security related but are more about the basics of how the application's gonna operate,
which will lead us into operational controls that will address things like scalability, functionality, performance issues. Perhaps all of those will come under operational requirements. And then there's some other requirements that maybe don't fit nicely in any of those little boxes per se
will have things like, Maybe how do we meet international requirements? Some of the other requirements that might,
um, might be left over, so to speak. Another thing we're gonna look at is how do we get these requirements And we'll talk a little bit about some techniques for information gathering, you know, working with our customer. Um
you know, uh, in not all customers, not all stakeholders in this project and this very much is a project.
Not all stakeholders are gonna be created equally. So we've gotta figure out which stakeholders air the most important and have the greatest influence on the project. And we've got to figure out how to meet with them and make sure we understand their requirements. And we also need to be able to trace the requirements of each stakeholders
to a functional piece of the application or
off the program again. Those stakeholders that we weren't to be important. So we also want to make sure that we're not doing more work than is required. So I want to be able to take each element of the program and trace it back to meeting a specific requirement off stakeholder. Okay, so
when we talk about tracing requirements, that's what we mean.
Um, policy composition, you know, making sure that our applications supports the work of the organization as a whole, that it fits into their overall business objectives, making sure that the customer has given us the proper objectives that would satisfy that.
Ah, the next thing that will want to look at is a protection needs, elicit cation
again, pulling information from the customer. What exactly are we trying to do here? Tell us what we're protecting, what your needs are in that realm.
And then we'll do something called use and misuse modeling how function should work. And then how it could be misused for security vulnerability so that we can kind of look at it from both directions and make sure that we focus on making the use easy and the misuse much more difficult.
And then last, but not least, will mention just very briefly. Data classification will come up a little bit more later, but we'll talk about. Certainly data classifications has to be considered as we're gathering requirements because different classifications of information need to be treated differently. So that's what we're gonna accomplish in this next set,
which is obtaining secure that secure requirements.