Welcome back to CyberRays. This, of course. I'm your instructor, Brad Roads. So let's
jump into the processes and things that influence processes as an S e.
So in this lesson, we're gonna talk about organizational authority.
We're gonna talk about security policies because those influence process, we're gonna talk about software assurance briefly because that's very important. And we're gonna talk about the cybersecurity, our cybersecurity maturity, model, certification, CMM. See, this is one that if you're going to work supporting a U. S. Government or
Department of Defense type organization, see, MMC is becoming something you have got to understand as a busy
so author organizational authority is interesting.
when you create a system
A some point somebody has to approve that that system is good to operate. So let's go back to our smartphone example. You build a smartphone very complex system. It operates 24 73 65. Um, it has security requirements. It's got user interface requirements.
It's got to connect to a cell number. I mean, think of a
A smartphone as one of the ultimate systems engineering problem sets
Well, at some point, somebody in that organization has to approve for that particular model smartphone to go to market, right? And so an organizational authority. What I want you to remember is some of that approves that system to go into operations, and somebody had to make that call. And so, in the commercial world in the industry, right,
that varies by organization, the decision makers could be your CEO. It could be a CEO, a C so
unaudited officer of privacy officer, it just depends on the organization. Um, it's really interesting today. How many will call them? C Suite? People think that they have a stake in decisions on systems and putting them into operations
when we go and then look at, say, government systems, right? If you're talking about, say, the U. S. Government, that system is very formalized. There are formal roles that we'll talk about in a later lesson that you're gonna need to understand and know, because when we put a system in tow operations safe for the for the U. S. Federal government, that system has to have an 80 0, in a
operate. Uh, that 80 0 is on Lee gonna last for so long. It has to be reassessed regularly and reapproved by the organization authorities. So from a process perspective, that's one of your jobs is an ISI is doing those kinds of work to track, say, a T. O s
security policies? Well, security policies drive us out into the types of processes we need to put in place. Um, we're gonna talk a lot throughout the course of our time together. About change management
change Management is a huge thing. If you build a complex system, and then you just will nearly change something and break a bunch of stuff. And you didn't do change management. Somebody's liable for that. And that's a problem. We're gonna talk about access control. We're talking about data classification, data support and operations. Right. So so much of what we do today is data. So when you think about
processes you do is an ISI,
you need to understand, process flows from, you know, data construction through data protection to data end of life. And so, as an ISI, that's engineering, right? That is literally what are my requirements for my data? What's the architecture from my data? What is the disposal plan for my data? So that whole set of things is done right there.
Um, other policies and things that affect the way we do our processes as NIST, the National Institute for Standards and Technology. If you work for the U. S. Government or as a contractor for the U. S. Government, you will see those used quite frequently.
And then the other thing. I want you to keep in mind here that many times our processes, as it sees, are influenced by jurisdiction and law. So if you were to operate and say California,
right, you have an entirely different set of laws that you have to do with them, save, say, Vermont, or say over in Europe. And so the way you do your processes and the and how transparent they are and what they do are definitely gonna be type two. The laws, regulations and rule sets based on the jurisdiction you find yourself in
software assurance. So we've talked about the system development life cycle as being focused on systems and the systems engineering aspect. Well, here we're gonna talk real briefly about software assurance. As a
on ISI, you need toe have processes in place that help you understand whether you have ah software deployed or in your environment that is free from badness free from vulnerabilities. Um, one of the biggest challenges with software today is that when we create software and anybody could create software, right, we have not done it securely.
Many cases Softwares created just to get something toe work. You see that A lot in agile,
which is okay. And security is an afterthought. It gets bolted on at the end and ultimately costs a whole heck of a lot more. And so the definition of software assurance there is from the Committee on National System or Security systems, CNS s 4009. And this is when you should understand, is an ISI and understand that that these standards and requirements
right, Especially if you're working for a government organization.
Finally, we have the C m M. C. And that's the cybersecurity maturity model certification. And so this is basically demonstrating the maturity of an organization to protect itself from a cybersecurity perspective. It goes from level one to level five. Level five is clearly the most mature,
um, and and level zeros. We've got some practices, say mid level managed is where we've got some policies and a plan, and then optimizing is where we actually practice and
implement the plans and do the right things and standardize our documentation across everything. Well,
if you are going to be an ISI and you're gonna work for either a government organization in the United States or D o. D, or whatever the case may be or you're gonna be a contractor working for one of those organizations, you are now required
to meet these levels this and demonstrate a certain see mm mm sea level. And what does this mean? So that means that if a Sanusi you're gonna be building the processes that support getting to this right and actually practicing them. But contracts are going to be awarded or not awarded to your organization if you're a contractor,
if you don't meet the minimum level of specified for that contract. So let's say
the government specifies that level three is the minimum level. You need to have to run a specific contract or operating a specific contract, and you're only level two. Guess what you are likely going to be disqualified from actually getting that contract. So keep that in mind, is an ISI. You need to understand. See MMC and the processes it takes to get there.
So in this lesson, we covered organizational authority various between government, industry. All of those things we talked about security policies and how they influence the processes that we use is an ISI. We talked briefly about software assurance and why that's important. And then we looked at the C. M. M. C. The cybersecurity maturity model certification
and the fact that if you are going to be a government contractor or work in the government,
you are going to have to actually utilize this standard to either judge contracts or try to be awarded contracts based on the fact that you actually meet the appropriate level of maturity for an organization.
We'll see you next time.