Define System Security Requirements (Define System Requirements)
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
5 hours 58 minutes
Difficulty
Intermediate
CEU/CPE
6
Video Transcription
00:00
>> Welcome back to Cybrary's course.
00:00
I'm your instructor Brad Rhodes.
00:00
Let's look at the next step in the ISSE process and
00:00
that is define system security requirements.
00:00
In this lesson, we're going to talk
00:00
>> about the ISSE tasks.
00:00
>> We're going to talk about source documents again.
00:00
We're going to talk about the output to
00:00
the requirements that come out of this particular step.
00:00
[NOISE] Again, IAFT 3.1,
00:00
there are five tasks that
00:00
an SE does when they're
00:00
defining system security requirements.
00:00
One, they're going to coordinate with the customer,
00:00
shouldn't go without saying.
00:00
Two, they're going to work with the systems engineer.
00:00
[LAUGHTER] Again,
00:00
remember that information system
00:00
security engineering is a subset,
00:00
a part of systems
00:00
engineering for a much more complex system.
00:00
We're going to do requirements analysis here.
00:00
That means we're going to
00:00
gather all these requirements and
00:00
the customer coordination piece and we're going to
00:00
analyze what we've done in developing
00:00
the systems requirements related to
00:00
our information system security,
00:00
controls everything that we're going to
00:00
do as far as information security for a system,
00:00
we have to develop
00:00
those requirements in coordination with the customer.
00:00
We have to analyze those requirements.
00:00
Then probably, I would say one of
00:00
the most important step here is requirements tracing.
00:00
We have to trace those requirements
00:00
from the systems engineering
00:00
requirement that they came down from,
00:00
the systems engineering element they came down to into
00:00
our information system security engineering requirements.
00:00
Then we have to track them all the way down through
00:00
functional analysis to
00:00
those product things that we're going to be developing.
00:00
We have to be able to trace
00:00
requirements because that's how we're going to
00:00
test them ultimately to see if they are
00:00
actually been met in terms of what we've developed.
00:00
Source documents here.
00:00
Well, one is this system contexts.
00:00
We've talked about contexts before.
00:00
In terms of information system security engineering,
00:00
that's the boundaries and interfaces.
00:00
We know that if we're going to
00:00
connect a system to the Internet,
00:00
there's going to be external
00:00
boundaries, those connection points.
00:00
There's going to be internal boundaries
00:00
between different modules within the system.
00:00
We've got to understand that. Next,
00:00
we need a user perspective, and that comes from what?
00:00
It comes from the concept of
00:00
operations document or other online documentation you
00:00
might have gathered about an organization if you're
00:00
not dealing with a government entity.
00:00
Then the last is this system requirements themselves.
00:00
Remember, ISSEs work in
00:00
that subset of system security engineering
00:00
and so the system requirements document
00:00
probably has some great things that we should look at,
00:00
in terms of understanding what is
00:00
the system is supposed to do at a top-level,
00:00
so that when we build the security
00:00
requirements for we're not
00:00
building something that doesn't
00:00
work for the entirety of the system.
00:00
[NOISE] Here is the outputs of our requirements.
00:00
When we're talking about
00:00
the information system security
00:00
requirements here for our system,
00:00
developing those, well,
00:00
we've got the outputs, we've
00:00
got the requirements themselves.
00:00
What's the system or
00:00
the components or the modules
00:00
or whatever is supposed to do?
00:00
We have two kinds of
00:00
requirements that you need to remember,
00:00
we have minimum and stretches.
00:00
We have what we call threshold requirements.
00:00
That's the bare minimum that a system has to do,
00:00
or a module or whatever.
00:00
Then we have these objective requirements,
00:00
that's like a stretch like
00:00
I can get there, that would be great.
00:00
A minimum requirement might be that a system
00:00
operates 24/7, 365.
00:00
An objective requirement might be
00:00
that the system has 9, 9,
00:00
9, 9, so five-nines
00:00
availability and only goes
00:00
down for scheduled maintenance.
00:00
That sounds like an awesome objective requirement,
00:00
but at a minimum,
00:00
the system is going to operate 24/7.
00:00
Then we look at functional requirements
00:00
and that's quantity,
00:00
quality, coverage timelines, and availability.
00:00
When we think about functional requirements, here,
00:00
we're talking about what does
00:00
the system actually going to be made up off.
00:00
I need eight widgets,
00:00
and those eight widgets can be
00:00
manufactured overseas or they
00:00
can be manufactured in the United States.
00:00
What timelines do I need?
00:00
When is the system
00:00
and the functionality and
00:00
the module supposed to be available?
00:00
Another output of requirements. Here's the traceability.
00:00
We have to link all of
00:00
our requirements back to the main system.
00:00
We're building incredibly complex systems and
00:00
those incredibly complex systems mean we need to
00:00
map everything from
00:00
our information system security requirements,
00:00
all the way back up to where they
00:00
track into the system itself.
00:00
Then we need to look at constraints.
00:00
Constraints are one of those things
00:00
that we have zero control over.
00:00
Constraints come from what?
00:00
They come from cost, schedule, and scope.
00:00
If we're told you can spend $10
00:00
on that widget, we can't go beyond that.
00:00
What does that do to our widget?
00:00
That means our widget might not be
00:00
the best greatest widget ever that we wanted to buy.
00:00
It may be the widget that we
00:00
need because that's what we can afford.
00:00
We might be told,
00:00
you're not going to develop that thing,
00:00
you're going to buy it because we need it
00:00
online in a week. Well, guess what?
00:00
That's a constraint from
00:00
a scope perspective and a scheduled perspective.
00:00
Keep those in mind that these are
00:00
the outputs of requirements.
00:00
Here's my little anecdotal story for you.
00:00
If you don't take
00:00
the time to get your requirements right,
00:00
you're going to end up with a busted tree swing.
00:00
This is a famous systems engineering diagram or chart.
00:00
It has been shown in probably
00:00
every systems engineering book
00:00
since the early 2000s.
00:00
Customers come in and say,
00:00
I want a tire swing.
00:00
The client says I want
00:00
a tire swing that's got a pillow and yada, yada,
00:00
the engineer designs to do
00:00
a certain thing because they didn't
00:00
clearly hear what the customer
00:00
wanted and then the manufacturer
00:00
built it based on the requirements that they were given.
00:00
It's funny and cheeky this particular chart
00:00
but I have seen systems in
00:00
real life where the customer said,
00:00
I want a notebook that I can write out with the pencil,
00:00
and what they got was
00:00
a digital tablet that cost $100,000.
00:00
That's like an extreme example,
00:00
but that happens all the time.
00:00
Good requirements, solid requirements,
00:00
well-understood requirements in this area,
00:00
help you to save
00:00
not only your organization money
00:00
but your organization time and get the scope
00:00
right so that you build the right product or service or
00:00
capability out of the gate as opposed to having to
00:00
go back and redo it multiple times.
00:00
[NOISE] In defining system security requirements,
00:00
we're going to develop the system security
00:00
CONOPS and the baseline system security requirements.
00:00
That's what we're doing here. We're taking
00:00
all of those things, those needs,
00:00
and we're allocating them functionally into the sets
00:00
of requirements that we're going to
00:00
build to or eventually built to.
00:00
[NOISE] In this lesson, what did we cover?
00:00
We looked at ISSE tasks,
00:00
we've talked about source documents,
00:00
we've talked about the specific
00:00
outputs and requirements,
00:00
and then we talked about a brief example
00:00
of if you're going to build a tire swing,
00:00
make sure you build a tire swing
00:00
and that something that doesn't
00:00
look like a tire swing. We'll see you next time.
Up Next
Similar Content
