Enterprise Architecture

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

10 hours 8 minutes
Video Transcription
So we're gonna go ahead and pick up with siege it in our session three as we planned. So what we've talked about to this stage we've talked about various elements off our, um
our enterprise governance and how governance of the enterprise
requires governance of I t. And that i t governance is a subset of enterprise governance. And so what that means, like we've seen in so many places so many times and time again, is that the i t. Is in support of the business
in the business values. I t. Because without i t
the functions of the business don't perform properly. So we talk about some frameworks. Some of the frameworks that we talked about we talked about, I so 27,001. And we talked about how that provides pretty much the entire cradled grave cycle off
on information security management system and I s m. S
and that by using these frameworks within the organization, we provide the structure and the support. Um, So, for instance, if we decide that we want to be that we want to manage our environment,
then we have the structure in which to do so. Swee said I So 27,001. 27,002 gave us some best practices.
We also looked at cope it And we talked about how Kobe it takes those enterprise goals that we have and maps those all the way down to specific actionable objectives within i t. So we know Kobe. It's gonna be testable because it comes from, um
I saca's well
so, guys. Thank you, Paul. You know, I knew when I was asking for folks to speak up and let me know if you could hear me if half and Paul didn't say hello. I knew nobody was hearing May because you guys are right there jumping in when I need you. So I appreciate it. We're not sure what happened, but
the good news is perfect is on the case. He is on it,
and it is gonna go smooth for the rest of the day. Right?
All right. So we also looked at ite ill, and I tell you, they will be asking you about these other frameworks. They're not gonna go profoundly in depth, but particularly the one from the ones for my sacha. So Kobe, it, um
and then vow i t. Which talks about the difficulty
that organizations have had traditionally in figuring out What is it that I t really delivers? We know we've got a lot of nerdy people there down in the basement, and they're doing a lot of things. They're always busy. They never have time, drink a lot of coffee. But what is it they do and how does that help us as an organization?
So the job of al i t.
Is to directly trace the i T activities to value for the organization and to facilitate that understanding off what the value delivery is.
So that took us up to I till which gave us, ah service management I t service management and what those various services are within an organisation. And, of course, the idea just being that we all produce something, there's always a service, right?
So how we manage those services and give those, ah, the customers the value that they expect in relation to
the service? We talk about our assets, we talk about the purpose of the services and how those services operate through the use of processes and so on.
So we've covered a lot in just couple of days, and now that brings us up to enterprise market texture, enterprise, architecture. So, you know, we've said I t architectures, a subset of enterprise architectures,
But let's talk a little bit more in depth about how this works.
So when we define enterprise architecture, really architecture,
you know, just by itself it's kind of that visual representation or it's ah, it's a representation of a concept, or of a theoretical framework off the components and how they relate to each other at a specific point in time.
So, for instance, when we talk about an enterprise architecture,
so the framework of thes components. If I were to ask you to define your organization to define your business, you know, if you think of the architecture that would be asking you, what are all the elements of your business that work together for a common goal?
And that's how cut I kind of see and architectures the elements that
work together for the common goal and how those various elements are integrated and how they relate to one another. So in your organization, think about all the various divisions or departments. Think about the locations you have to think about the various business units.
Think about the individual employees.
All of these are elements of the enterprise architecture.
So ultimately what we're trying to do is to align all of the's
elements so that we do effectively and efficiently work together. And I guess when I say that these are the elements that work together, I guess that's really more that they don't have to work together. The goal is to have everything working together, right? I mean, you can have these elements and their across purposes sometimes.
But the purpose of having a standardised
enterprise wide framework is so that we are collaborative in nature. Were working together.
All right, So when we talk about enterprise architecture and then in relation to information, we've got to talk about how information is going to flow within the organization, how it's gonna move both logically and physically.
You know it will describe the physical connections, yes, but also the logical flow from
Group Two group from individual to individual. We've got to describe if we are gonna have classified data or other labels because classifications is just one form of labeling, you can label information other ways as well,
what are our expectations for the applications and how they interact with the information, how users
interact with applications? You know, What are those structural defenses that we have integrated to prevent users or untrusted entities from accessing Trusted Resource is so ultimately, it's It's just that it's the big picture of how everything flows together.
So this is the enterprise architecture model from NIST, and it's the idea that one thing builds on another, builds on another, builds on another.
So what you see is at the base of our triangle,
our technical infrastructure, right?
But the technical infrastructure, How do I know what technical infrastructure is best for my particular environment? How do I know? Have a segment, the network? How do I know what technology to implement? How do I know? What systems and host and how do I know about any of that? Well, like always, we start at the top.
We start with
the business,
and we look at what the business mandates and requires what the objectives are and so on. While the type of business were in drives, the type of information that were in
right so or what the type of information we collect in what we need. And then how we store that information is data and how it's accessed is gonna drive what applications we use
and then the applications that we need and that structure for the data is going to drive. What are technical infrastructure is
so once again
just a little bit more zoomed in on what we do describes the information we need. The information we need is gonna dictate that we store it is data and we access. It is status. So how that drives the applications we use and those applications sit on top of a technical infrastructure.
So, um,
yeah, so here's just a little sample of an enterprise architecture, So this isn't, ah 100% exactly matched to that chart, but it's it's just a good overview off. You know, a document on the inner the Internet architectures.
Let me try that again on the enterprise architecture.
So ultimately, what we see here is that we're looking at the business unit
and we're looking at the various standards that the business unit has to adhere to any sort of reporting requirements, compliance issues, um, stakeholder objectives. So ultimately, those air the requirements or that's the architecture off the business,
right? All those things that we put in place so that we can maintain compliance, deliver value
to our organization.
All right, so the information, then that's gonna be required. Documents.
Ah, protecting the information accordingly. Like implementing security and making sure that we have integrity and so on, all the way down to the delivery systems, which are generally referred to as the technology. Okay, so just kind of an overhead mapping.
Um, So business architecture, Like we said at the top, this is where we examine the mission of the organization or those elements that are essential to the mission. So we have to be in compliance. We certainly want to be profitable.
And if our business isn't about profit, then we want to reach our goals and objectives. Right.
So we started the top. What is the business about? And this needs to be specified, right? So we have to maintain compliance with HIPAA, you know, and this is kind of tied into the vision of the organization organisational strategy, the organizational,
Um, yeah, the organisational strategy and organisational goals and objectives. So the business architecture and then again coming down to information. Architecture.
So what is the information we use in order to accomplish what we want to accomplish?
Well, we're health care facility, so we're gonna have personal health care information that healthcare information is going to include patient records. It's going to include payment information.
Um, yeah. Half. I agree with you there. So many different frameworks here,
You know, SAB son toga off Jericho. We teach that with the cloud security class. I tells its own beast. I agree with you, you know, And
it Sometimes it can be difficult because different agencies and different organizations really push certain frameworks over others. I mean, you know, of course, I sacha is gonna be heavy on Kobe. It Val, I t maybe in support of Kobe, but, yeah, I agree with you.
You can spend and you have been taking a lot of certification exams. I know.
So I'm curious. How many of those different frameworks have you had to just drill, drill, drill with flash cards or whatever other tool we have,
So absolutely, you know, these architecture frameworks ca NBI
a lot to memorize,
but the idea is when we find the one that best suits our environment to bring it back into our organization and provide that support and structure where perhaps we've had none,
right? We're still We're not gonna change the nature of our business. But what we're looking to change is the efficiency and the standardization of our business. Okay, so once we decide our information, architecture and down there with classification
My goodness,
that's a lot of study in half. You you definitely get a tip of the hat from me or a toast of the I normally have coffee with me, but the toast of the water to you.
Um, so the information architecture. What's our information, then? Of course. How are we gonna store it? How are we going to retrieve it? How are we gonna organize it?
Well, how are we going to allow the information flow to move between departments and between individuals? You know, we talk about, um
ah, business models or security models or confidentiality models. And how are we going to define that information flow? You know, information very rarely flows in a flat structure, right in appear structure, often down of a certain degree of sensitivity may flow up
for somebody with higher levels of access perhaps could flow down.
you know, from department to department from segment this segment from layers of trust toe untrusted. So ultimately, the information systems architectures gonna kind of describe that flow.
And then we get into the data architecture. This really could be called the application Architecture because it's that application that accesses the data and how the applications air designed how the applications are created to share the information to the degree that they meet the objectives.
That's the data or the application architecture
and then all the way down to the technology infrastructure, which ultimately is going to revolve around the hosts. It's going to revolve around the network configurations. It's gonna really revolve on the hardware, software and firmware of our systems and our devices. OK,
this is just a little bit more explicit. And to me, this just map so perfectly to co bit what we've talked about, what's didn't mean to get ahead of myself what we've talked about with Kobe, it should go back a couple of slides where we talk about how the cascade the goals Cascade
stakeholder needs go down to enterprise goals. Enterprise goals toe I t. Goals I t goals go down to enablers or those mechanisms that make it all happen, right? So that's exactly what we're seeing when we go back. And we look at enterprise architecture,
business drives, information, information describes how the data is going
or will require certain type of data, characterization and flow, which will be provided by the applications, which are provided by the technical structure.
So all of this is saying the same thing, right? And I think, have, if you're like I am, I don't mind knowing all of the's different architectures and studying them. But so many of them are ultimately just doing the same thing, using some slightly different, um, slightly different technology,
right? Our terminology. Just a slightly different approach. But what we're all doing
is taking the needs of the business and enabling the business through the use of technology. And that's really what our goal is. So at that point in time, it does get just a little bit, you know, tedious. But
you can never learn to many frameworks. That's what I always say.
I've never said that my life never
All right, so
that's nests model and that takes us up to business strategy.
as we get to the strategy of the organization, so we have can't create time done for break. I saw that, too half I looked and I was like, Oh, it's almost plate
time Except we started, like So I'm so sad. I'm so said we will still take a break. I'll tell you that much,
All right, so
with their business strategy,
and so we've talked about our security strategy. But, you know, enterprise governance is much bigger than just i t.
And so once again, what is the business stretch? What are we trying to do? How do we make the decisions that we make in our organization to move forward in one direction or to another?
So there are a couple of techniques that will use when we're examining a particular strategy, and this can apply to determining what direction we take, what endeavors we pursue what projects were willing to take on.
But this is a tool called the BCG Matrix, and that stands for the Boston Consulting Group. And ultimately, what
they push forward is a way to improve our strategic position through the management of our portfolio.
So ultimately what we're looking at is we're trying to determine what the's endeavors and where they fall based on how attractive they are to the industry and how attractive they are to the industry's usually tied to, you know, Is that industry growing? Is it profitable? Right,
So I love this. Ah, the BCG matrix is broken down into two main directions. The growth rate of the market versus the market share. Okay, so when we're we're examining this,
we see that our endeavours may fall in one of four categories.
So with the idea of trying to figure out where our endeavors are, where projects are, what elements of our port folding folio and where they fall, well,
we can look at their either star question mark a cash cow or a dog.
And there's my pug, By the way, if you want a chance to appreciate a fine looking dog that cover up the other graphic that was there,
All right, so when we talk about our star, we're looking at a high market share. We're looking at high market growth, high growth potential, high profit. Essentially. So these are those investments that have a high earning potential.
They're stable. It's an environment that's growing,
Um, And so, of course,
with our strategy in relation to those elements that we consider to be stars, we're going to invest right wing, invest for that growth potential, spend some money because with its increased growth rate, it's high growth rate.
We want to be prepared to market and to maximize the growth potential.
We're not just going to sit back and rake in money, although that's not that's never been a complaint of mine. We're gonna be aggressive, and we're gonna go after maximizing potential.
Okay, now the cash cow. This is something that's been like a consistent source of income.
However, the growth rate really isn't there. It's not necessarily a, um,
really dynamic industry that's growing, growing, growing.
But it's one of those things that's been consistent and steady. It may not be there very long because, as we see, the growth isn't there. And at the point of time that things stopped growing, they start to die, right? We're not there with the cast cow yet, but when we have those elements, I love the strategy.
Milk it.
It's a cash cow. Milk it and all that means is we're not spending a lot of money. We're not investing a lot of time and energy in these elements. What we are doing is saying will reap the benefits as long as there there were to focus our attentions more on the star.
All right. And then we have those question marks and move Bashar, if I'm pronouncing your name right, I just wanted to get back with you and let you know. Yes, there will be recording of all the lectures of all off the courses.
And, um, we have perfect who is our moderator.
And he will provide you with the information on how to access thes because we're aware of the fact that not everybody can make it all classes all the time. So, yes, these are available. All right, so we've got our stars, which we wish everything was a star for us. But hopefully we have a few of those in our back pocket. We've got cash cows.
These have been the things that have been around for a long time.
They don't require a lot of investment or effort. They just recurring. They basically provide recurring capital, which is very nice.
It's not gonna be there forever, but we'll take it while it is.
And then Oh, good. I'm glad I pronounced your name. Right. Good. Um, and then the question mark, these are sometimes referred to as the problem child or the problem Children. And these air those areas that, you know we're having to put money out. It's generally not turning around the profit, but
there's a growth rate
in the industry, right? It's growing. I'm just not making any money out of it. So the question is, is this something I can make work? So at this point in time, these are the ones we have to really analyze and say, Do we just drop him, or do we
invest some money and see what can be done to turn them in
to a better performing investment like a star would be So here the strategy is just to analyze, and by the way, this is definitely testable, definitely testable here, Um, probably 56 questions just on the BCG matrix matrix.
Specifically what? Your strategies are in relation to each of these.
Okay, so these question marks its in an area of growth, but we're just not making money off of it right now. As matter of fact, we're losing money.
I and then we have the dog, and I take it sense it that because this is a negative term and look at that good looking pug. I don't know how you could take that and make it a negative, But the's air, the things that we have, um, you know, in our portfolio that just
are not making us money,
they may not be costing us money. A lot of times they are, though we have. You know, we're putting money out their areas that just really aren't growing or they're not growing in a stable manner, you know, one step forward, two steps back.
So within our portfolio, we examine these things and we have to determine you know what? This is a dog. We gotta we gotta let this go
and go ahead and defensed. So what I would know is I would know the four elements. What they indicates matter, fact, everything on this chart is testable for the exam. They get right into this matrix.
All right, so once again, another technique for determining whether or not we take on a particular project. Whether or not we pursue and Endeavour is we have to do what's called a SWAT analysis and SWAT stands for strength,
opportunities and threats.
So ultimately, what we're trying to figure out is, what are those internal and external elements that are gonna influence the success of this undertaking? So what's going to enable it? And what are the things that might prevent us from being successful and you'll hear SWAT analysis also quite a bit.
So when we're looking at strengths is exactly
what you would think. But we have to look at strengths in relation to a specific endeavour, so we may be a very strong organization. We may have a very solid technology team, but maybe we don't have. Um,
maybe we don't have an expert of cloud application security, right? So we may be very strong and other elements, but that would actually be a weakness in relation to cloud related projects. So when we're looking at our strengths, what do we do well
and what do we do well in relation to our specific objective project, whatever,
what is going to give us a competitive edge over our customers we do something unique. What is it? Are we better with customer service or we better technology? Are we better communicators? What element are we better meeting customer requirements. So we want to document this.
All right, What do we have in house?
What strengths do we have that we can bring to the table? What are the skills? Sometimes you might hear skills
associated with strength. All right. Any sort of tangible assets Do we have, um, equipment, proprietary technologies, proprietary techniques.
Do we have intellectual property? You know, do we have some trade secret that's gonna make the difference in this particular endeavor? So we want to list all of our positives
but then we know you can't just look at your positives. You've also got a look at the negative. So what are our weaknesses? What are the things that we lack? And the trick here is to be really objective about both of these. We don't want to over sell our strengths. We don't wanna underestimate the weaknesses. Right. So
we've got to think about what we lack.
Um, And what are the things that we have room for improvement with, right. So how can we better improve ourselves in relation to our competitors. Do we need to develop our technical skills? Do we need to, um,
enhance our employees based knowledge based? We need to train better. What is that?
Any sort of limitations? You know, if we're within a particular structure, we have constraints. What are those constraints? Are we limited with capital? Are we limited with, um ah, support from senior management? What are limitations, pay? And then anything
that is that we can perceive
would make accomplishing this endeavor difficult.
All right, so strength versus weaknesses
Now the next element, opportunities and threats. So when you do risk management 99 times out of 100 when people talk to you about risks, we perceive risks to be negative, right? That's just kind of the general sort of generic idea. I've never heard it by say, Oh,
there's a risk I might win the lottery tonight.
We don't really think of that is a risk, right, But Pernis 31,000 risk is both positive and negative. The key element of a risk is that it's an unknown event. It's an event with uncertainty now that could be negative or positive,
So a positive risk is called an opportunity.
A negative risk is called the threat.
All right, So for the opportunities in this endeavor, in relation to a particular endeavor or strategic move, what are the opportunities for gain?
Right? What are those things? We want to take advantage. How can we maximize the potential for opportunities?
So do we have a new technology that we think would be that would be appreciated by specific demographic? Are there elements where we've determined Ah ah, viable need where no other vendor exists or very few vendors produced the same type of product?
Um, do we have the invented the
potential of making mawr and selling less based on some sort of proprietary technique that we're aware off? But what are those opportunities that are associated with this endeavor
and hopefully being able to tie our strengths into accomplishing the opportunities?
But again, you can just look at the good. You gotta look at the downside as well. So negative risks are threats. Well, you know, certainly one risk is as soon as you come up with a brilliant idea and get to market, 30 other people are trying to do the exact same thing, right?
So are there gonna be emerging competitors coming quickly?
Oh, are am I producing something for a market that's volatile here today? Gone the next. So, you know, if I'm developing a technology product by the time I get to market with it, is it gonna be obsolete? You know, one of the things that I think about in relation to that
is, I think about, you know, um,
one of Steve Jobs passions and that he was heavily involved with before his death was toe work on Apple TV. And, you know, the focus was on, of course, streaming instead of traditional television delivery. But the thing about that Waas is, by the time
all the bugs were worked out, all the kinks there were already
it was already row, coup, Netflix streaming, Amazon prime and all these others. So all this effort in research and development, and by the time that made it to the market, it was just one of many. Right? So that's a threat. Competitors coming in, coming in fast.
Um, changing regulatory environment. I worked in the healthcare field for years, and every time the wind blew Medicare Medicaid. They were changing the requirements for billing,
so that could be very difficult to work very hard to go one direction. Ah, same thing when I worked at the Department of State. Political changes would indicate changes in direction. So when we're looking about this as an organization taking a step in one direction or another,
we ideally would like to go through the SWAT analysis.
Is this the best choice for us? You know, if you've ever had somebody you trying to make a decision, they say, Sit down, write down a list of the pros and cons That's essentially what we're doing here. When we're doing SWAT analysis, we're looking at it a little deeper. But ultimately we're trying to figure out Is this a move we should make or not?
And are we qualified
to maximize the opportunities and minimize the threats?
All right, now, whatever our endeavor and whatever decisions are as we move forward, you know, our focus is on controlling the environment. And so when we talk about controls were talking about, you know, whether they're manual controls, but
any way of implementing safeguards to support the business and to support I t. so they could be manual. They could be automated controls catering towards specific activities of the business, like perhaps, you know, auditing the financial function. And then we think about
more general
controls related to the technology we use.
So we have to ensure that we have a balance
for our controls, that we, as you know, many of us come here as technology people. We don't want to be too focused on the technology, right. We need to make sure we have administrative, technical and physical controls that are implemented for the organization.
But for I t. As well,
right? So when we talk about administrative controls there those policies and procedures that have to come from senior management
that give voice to senior management's approach and their priorities where they mandate
the actions and the, uh, acceptable activities within their environment.
Then, of course, we have our technical controls and and we do tend to be in this field very technically focused. We think about you know that the encryption mechanisms and algorithms in the protocol security and we think about firewalls and all those elements, and that's a piece. But security will always transcend
Security will always be much larger than just which firewall we fit in this slot, right? The administrative controls air, really the basis, and it's that understanding of our objectives and how to meet them at senior management or the governance level
that's gonna enable
the technical controls all the way down at the bottom. Right
and then, of course, physical security facility security, physical security, control and protections, environmental controls, those types of ideas. So as we move forward to talking about implementing controls, we just have to stress that controls fall across many boundaries.
All right, um, and the location, Or maybe it should be the context of controls. So the idea is security should be baked in and not sprayed on. The controls must be built into our processes. Are services
our systems
as opposed? Toe added on later, You know, just mentioning that idea of balance controls well with physical controls and facility security. For instance, we can take a building and try to make it secure by adding closed circuit TVs or guard dogs, security guards and those sorts of things.
we can build a building, a facility that secure by design and then at on security. So what I mean by that is you know, there certain things that we can do that just will inherently improve security from design up.
So if you've ever been walking down a stairwell, and this is one of those things that women tend to be much more mindful than men. But still, you know, if you're walking down. If you park in a parking garage, for instance, and I'm coming down the stairwell and it's, you know, cordoned off, it's not, um,
it's it's walled off. It's not
open air in the stairwells. You know, you've got your cement steps and you're going down and you're looking through down at the bottom. You don't know what's going on underneath you, and that's a very functional design, But it's not a very secure design. Where is instead, we have an open air stairwell,
the steps. Maybe you're made of mesh
so I can see exactly what's going on beneath me. That's just a more secure design. We can add CCTV or add lighting, but we've already got natural lighting to start with. So when we start our foundation on security, then we're always going to have greater security.
We won't leaves dependent
on the add on security. Same thing with their network technologies are network protocols are devices, you know, our environment, all of those elements. So the idea is that security control should be a priority of our design. It should be a part
off, not an afterthought.
You know, if I had a dime for every vendor that releases software to hit a deadline with the attitude of Wilson at a patch later, I would be rich person, right? Don't most vendors. I mean, I I don't ever want to be the first kid on my block to have a Microsoft product.
Um, and it's not that Microsoft's any different than most of the other vendors, right? Most vendors do this. Here's a product. Two weeks later, hope here's your product. Now it works. Three months later, here's your project, and now it really works. And six months later, here's your project at work securely
right. We've gotta change our focus.
Okay. Now, um,
application controls database controls things like input validation, ideas like sanitization of
information, isolation of layers of trust, integrity checks, right. These controls in the idea I don't really like the term here location of controls. So I'm just gonna put let's call that integration of controls. And again, if you're wondering,
Didn't she write those slides? Why she changed them. Now
you know, that's how I roll. That's all I got for. That's just how I roll. You know what sounds really good At 7 a.m. Doesn't always sound so good at 3 55 So I just wanted to change that for us. Mubasher, I love your comment on continuous improvement. You know, when you're teaching a class like this continuous process, improvement
is always good. I never know if people will shake their head when I make these little adjustments
or if they will support the process. So thank you for supporting the process. All right, so we get back and we're talking about controls and we're looking at the controls to implement, and we have to have a degree of confidence in the controls that we implement, right?
We've gotta have some means of determining or of
making, you know, making a decision. So that's where we look to third party audit. Perhaps that's where we look to external agencies, neutral observers. We look to the media, but any rate
we look to external assessment of a product or control before we implemented
Now, whether that control is a system, whether it's a product, whether it's, you know, even implementing sort of, ah, complete environment, almost, we have to look at two aspects of it. Trust and assurance.
Now trust is sometimes called function,
and more recently, it has been called function. But you could hear it is trust either function or trust. All right, So when we look at the trust of a system, it's what is the product do in relation to security?
So, for instance, if I'm looking at a system
I would look at OK, does it support auditing? Does it provide a firewall? Does include a firewall. Does it analyse communications channels? Does it detect covert traffic channels? Does it, um, examine
ah and provide mechanisms to prevent race conditions or timing incidents?
So those would all be questions about the function of a product? Does it do what I needed to do, right? What does it do? And that really is what you can sum up trust or function into. What does it do doesn't do what I needed to do
now the problem with that is it may do what you needed to do but doesn't do it. Well.
For instance, um, if you've ever bought any product, that's really cool and it is awesome for like a week before it breaks.
And you know, I'm kind of one of those people that used to watch a lot of late night TV Now that I have two kids, late night TV, for me is like a 30. But, you know, back in the day, I used to stay up kind of late and or, you know, you doze off on the couch and you wake up at 2 a.m. And there's some infomercial product that you just have to have.
You know,
I have never cooked a rotisserie chicken in my life. But by golly, one night at 2 a.m. I was determined I needed that device to set it and forget it. But anyway, so these air products that do really cool things, But because the products are often made cheaply
with poor processes, poor testing,
they have a high function. But a low assurance assurance is the reliability of the process. Now, actually, once again here we go Continuous process improvement, the reliability of the process. So trust is, look at the product process is
or assurances Show me the process.
So when I look at whatever element that we're evaluating, I want to see what it does, what security mechanisms it provides. Great.
But then I'd also like to see OK, show me how you tested this product. How was the product designed? How was security implemented throughout the phases of development? How we're changes. What was your change control process? All of those are elements of assurance.
So when we evaluate a product, we want to get an assurance
and a trust rating or on evaluation based on trust insurance, I guess, is the way we want to say it.
So traditionally, we've used different pieces of criteria in order to evaluate systems right, because we need a means of evaluating the security components and elements of a system. And we can't go to the vendors because we know the vendors aren't objective.
So what have we done traditionally? Well, we look outside
and I've already talked about the CMM. I I believe we've talked about the CMM I, uh here, which is the capabilities maturity model integrated
and the capability maturity model integrated is a means of evaluating the maturity of project management process.
And we've already said I know we've talked about it here, right? We did. That is the review. So that's a way to evaluate an organization or they level three or not.
All right, now
when we look at the Orange Book, this was a book that was used is called the Tick SEC trusted computer security evaluation criteria.
And the tick SEC has traditionally been used in the U. S. Government when I say it has been used, it was used
up until the mid nineties, I would say as a means of determining,
of determining whether or not a system was fit for use in a particular environment. And it was a very rigid system.
Um, and it was a system that had a series of checklists and a device would get a grade A, B, C or D.
All right. And then when we look at that, A, B, C or D, um, you would have to have all of the elements in place to get that C rating or your D had to have all of the elements for B. And if not, we would get a C.
So ultimately all of those, you know, pieces would come in to give a system a great isn't overall, but it also didn't separate out trust versus assurance. So that was a problem.
All right, then the Europeans came up with evaluation criteria, called it SEC, and that was to flexible. So then we moved towards something called the common criteria
and what the common criteria did. And I'm just gonna flip through the slides because we really don't need to go in great depth.
Um, So what we have is we have now the common criteria that's in use.
today. And whereas the tick sec was for the U. S. Government, the IT SEC was for the Europeans.
There was we let those pesky Canadians have some say with a document called the CTC Peck.
Ah, and so all of those elements come together in a document called the Common Criteria.
So when we look at the common criteria,
what we have is we have the origin of a system coming from a document called the Protection Profile.
Okay, the protection profile.
Now the protection profile is a set of requirements. Usually this is for use in, um, government environment
again. But many other organizations use products evaluated by the common criteria, so it's not specific to the government and again, even if government agencies requires, not just for the U. S. Government. So an agency that wants a secure system will create a document called the Protection Profile,
and that protection profile will go through and specify what the security needs of the organization are. So I need 20 systems that are capable of storing sensitive but unclassified information. They need to operate in this format. They need tohave,
ah, mandatory access control for security and all these different pieces.
Okay, so that's the common criterias protection profile. It comes from the client
from the customer.
All right, so a vendor Here's Hey, here's a customer with some money. They want something
so I'll build that product
and I'll build that product And that product will be called a tow. A target of evaluation. You release a need. I have a product that will meet those needs. Here's the target of evaluation. It's the system.
And then the vendor will also supply document called the security target
and the security target will detail how the target of evaluation meets the protection profile.
Okay, so how the security target meets the protection profile is a document. It's like a brochure of the product. Right? Here's how our product does what great things we do.
All right. Now,
well, actually, let me just keep going here. Now, the next thing that happens is the vendor usually pays for an auditor to come out and to examine the target of evaluation they've created versus the protection profile that the government agency supplied for us. Okay, So
the requirements are matched to the product, right? And they're evaluated
and based on how well the requirements described the product, the auditor assigns the product and e a l level an evaluation assurance level.
And the ratings come from 1 to 0. And essentially as
the levels, the evaluation assurance levels describe the stringency of the testing process. All right, so e a l one means All right, this is accurate. Up through our first test.
Any ale to We applied to different tests 345 And each test gets more more methodology. Uh, pathology.
Each test is very methodical and is well defined. And the, uh the complexity increases each time, so your higher your e a l level, the better the product meets the requirements.
Okay, so,
um, the way this works a lot of times, though, is most of the times vendors don't just sit back and wait for a product to be released. Right? A vendor is going to come up with the idea for a product. They'll produce the product, and then ultimately, they look to sell the product, right?
Build the product, look to sell the product.
So in that instance, there is no protection profile from the client, right? The vendor just has a product.
So the vendor builds the product, and then they release the document, the security target that describes how the product works.
Now, this is like Ford Bill building a Ford Escape and then producing a brochure that tells me how great the Ford escape this.
Is that really going to be something that's reliable? I'm gonna read the security target from the vendor that built the product. Well, no, that's not gonna be reliable. So in that case, where there is no protection profile, what actually happens is the vendor turns over the toe and the security target to 1/3 party auditor
and the e A. L is based on how well the toe
or how well the security target
describes the toe.
So basically they can get evaluated on how accurate their brochure is, so to speak. So, for instance, I read the document. It sounds like gosh, Ford escape. Sounds like a great car. But here's the brochure from Ford,
so I don't necessarily trust that. But then if, um,
ah, uh, Consumer Reports says every single word of the pro sure for the Ford Escape is 100% accurate and hear all the ways we've tested it Well, now all of a sudden, that brochure means something.
So that's just kind of an overview of the common criteria, and I would, And that would be testable because that's an important way that we evaluate controls and systems to enter Teoh implement.
All right, so those are some of the various ratings that Yale ratings from the common criteria,
and ultimately this is all about certification. When we talk about certification, we're talking about the technical evaluation of a product
and with that technical evaluation of a product it's does it provide the degree of security that's necessary in a particular environment? So just because the products certified for this environment, of course, it's not necessarily certified for something else.
Now, with the certification, once the product is certified and tested in its E a l level for whatever, then it's up to the enterprise to determine whether or not we want to implement that product.
That's the accreditation piece. So certification does it work? Accreditation. Do I need It is basically how that you know how that winds up coming to play,
All right. So ultimately our security controls and our systems go through the process to get technically evaluated or certified, then we choose to implement those mechanisms, and they're now a credit.
All right Now, the last handful of slides are about communication and the importance of communications. And, you know, with communications these air kind of soft skills, right? I don't think they're going to be a ton of test questions about communication, and quite honestly, I find it much easier
to teach somebody technical skills,
thin soft skills. You know, I feel like almost anybody can learn the technology if you apply yourself and you're given a chance to work with the news. But, man, so many of these soft skills are really just kind of person, Errol. His personality driven. And they're sort of intrinsic there. People that are just good communicators,
But whether or not you individually or good communicator or not doesn't matter. We have to understand the importance and placed the right emphasis on communication from our organization.
Right. We want to provide a transparency to our customers. Yes, we will be covering balanced scorecards, and those will be in the Let's see if I have them in this section. Nope. Those will be in the next section, but definitely cover balanced scorecards.
Um, so that will be Thursday, that we'll talk about those.
All right, so we just want to make sure that we're communicating. Communication gets buy in from our stakeholders. It promotes trust. It helps us raise awareness. It gives us a means to really impart our philosophy
and our ethics and our strategy to our users.
Clear communication is essential. And when we talk about who we communicate with our stakeholders
and we communicate in some form or fashion to all of our stakeholders, whether it's our shareholders, whether it's our, um, our customers, whether it's the community in which we operate, whether it's with their employees and we're always communicating something.
So we have to think about that because sometimes what we're communicating
is not necessarily what we desire to communicate.
You know, if there is, um, you know, I always think about politics and no, I'm not getting political. But you know, when some sort of hot push button issue comes up
and they'll ask maybe a senator for their opinion and they say, No comment. Will that comments right there right by me saying, I don't want to talk about that. That's a communication in and of itself or if an organization has a breach, but they don't address it
and the media determines and it's taking a long time for that organization to come out, make a public statement. That's communication.
So we always have to maintain a communication strategy, and we want to ensure that we facilitate that community communication to our stakeholders.
All right, now, this next topic enabling change. This is going to continue through next week session, but just in laying down kind of the foundation here when we are looking to step in
and change in organization, redirect our focus, focus in a new direction, implement a new philosophy Ah, a new culture with security in mind or value delivery or whatever it is we're bringing to an organization. Change is slow.
People are resistant to change. I swear, I know people that I could give a $1,000,000 to and they dio
Now I have to get a bigger wallet.
And many of us feel that way about change because we've been bucked by change. We have seen things that were supposed to be good
go all the heck. When the implementation happened, things weren't carried out. There was a good communication. So when we're looking at enabling change,
um and I like this, this definition it's a systematic process of ensuring that all stakeholders are prepared and committed to the changes involved in moving from a current state to a desired state, our current state of governance
to a future state of government.
Now all stakeholders air prepared and committed to those air very lofty goals but to do our part to ensure that the stakeholders are prepared to do our part to ensure that they're committed to sell the stakeholders to get by in right
to make sure we're ready to move forward.
So change preparing for change, getting buy in for change, getting users in stakeholders to commit the change. That's a hard process. And a lot of that goes back to what we talked about earlier with value delivery.
Let me tell you what we're gonna do for you.
Don't just tell me you've decided because of blah, blah, blah. We've decided to make all these changes. How is that change gonna help me? What's in it for me? Because ultimately that's what everybody wants to know Anyone. All right, So when we're looking at change, we've got to figure out what is the impact?
How is that going to help us accomplish our objectives?
We gotta think about communicating, empowering users to be part of the change, right? Getting feedback, supporting our our employees to contribute
planning and teamwork. And then, ultimately, that gap analysis of closing in from current state to desired state.
All right, so
that brings us to the end
of our questions. Do I really just have to questions,
huh? Well, this will be an easy review all in.
So just a quick review of the material that we've talked about. In addition to corporate governance, which of the following is a key component toe an enterprise governance framework?
Okay, so in addition to corporate governance, the business governance, right? So more about the business strategy and objective the missions of the business that all has to be objectively decided.
Yes, change is difficult and slow.
Um, I agree with you 100% there. So, you know, and I agree we've got to think about those. This kind of goes back to our SWAT analysis and trying to figure out, you know, what are those threats that could prevent us from being successful?
Many times. There's a mindset
of if it ain't broke, don't fix it.
Right there is that mindset of Well, it's working well. Doesn't mean that it's working. It just means that it hasn't had a catastrophic failure yet.
You know, it means that we haven't had a compromise, so we won't have a compromise that doesn't make sense so many times. It's the mindset of those that perceive themselves to be impacted by the change, and often the folks that perceive themselves to have be impacted the greatest
often are impacted at a very low level.
So ultimately, we have to make sure that we go through that process. You know, the same processes of analysis. And we have to figure out, you know, what are those elements? Absolutely, you know, But I love your point. Change is difficult and it is slow.
And, you know,
the longer I work in this business,
the more I understand that, and the more I can understand the reasons that change is slow and changes air difficult. But I'll tell you earlier on in my career, um,
I would find myself very frustrated because we would, you know, have a problem. I'm very much a solution oriented problem, a person. And I'm one of those annoying people that if you tell me a problem, I'm going to start to solve it, and I'm moving pieces around, and so I always tend to think any problem can be solved.
Let's go
right, But change is slow because I'll tell you many of the changes I've acted upon quickly. Go, go, go!
I've made mistakes with right and you learn. And that's why I know change not only is slow, but it has to be slow because we have to evaluate for those changes. And we have to anticipate we have to look at dependencies and down the line, So yeah, absolutely.
All right. And the primary benefit of using a generic maturity model within an I T governance framework is so basically, we're just saying, Okay, maturity models are valid. But why would we use a generic one instead of one? That is perhaps,
more did more specific, because we want that benchmark out there. So we wanna have a means of benchmarking toe. Look at where we are in relation toe other less specific instances.
All right, Any tips on how to do prioritization? How to keep all parties on board involved
and balanced conflicting needs? Man, that is, um
that is an excellent question.
And what I have is this
the way I would treat this process is as a project.
Now, I'm not saying I go all in and have a project charter, but I would take advantage of some of the tools that we use in project management, and I would apply them to this situation. One of the things I would start off with is a stakeholder register, and I would document who my stakeholders are.
And I would use that stakeholder register
in order to prioritize those into key stakeholders those that have a high level of influence, a high level of power and those who are impacted by the results of the project.
So the first thing that I would do is really work on getting a good understanding of who the stakeholders are and what their relevance is. Many times, like I said, the person making the most noise really doesn't have a lot of say in the matter.
Um, I would then develop my strategy based on the key stakeholders, you know, prioritization. Based on the priorities of the stakeholders, I would try to translate those stakeholder needs. So I would meet with the key stake holders,
and I would probably just survey those that aren't key stakeholders. I wouldn't really sit down with the face to face meeting,
but I do want to at least gather up everybody's needs. Um not promising anybody your needs will get met. But I do want to know in relation to this process in relation to the changes. What do you want to see? What would help you accomplish your job? Better.
So then, at that point, I have to take what I've collected. You know that data and I've got to analyze it.
And I've got a look at this in big picture. So I think the biggest piece is that this is something that takes time, and it takes structure and organization to move through. It can't be. Let's have a meeting and let's make this happen, right? So I really would
I would manage it as a project.
Start with my stakeholders, take their needs, prioritized them, break that down into scope essentially and kind of, you know, translated through those proper through those sort of priorities that we use when we do manage projects. Because it really
you know, when you're looking at shifting your government structures,
you're governance structure. That is a project.
So, you know, that's what I'm thinking there.
I hope that you know that I feel like that's one of those things. We should go get coffee and sit and talk about for a couple of months over. But, you know, I would really have a very structured approach to that.
All right, Whatever
Up Next