all right. Now, our next topic is inner organizational change change within our environment. And we've actually talked about this a little bit in the couple of the other modules, so we'll move through this fairly quickly, but it's still all boils down to risk.
Any time my company does something different, we open up the door to risk the potential for loss. So we have to address we want to be proactive on. We want to talk about some of the security concerns. So when we're talking about a corporate merger,
not our problem, all the financial issues that could come up with in the business associative risk.
But from a network standpoint, we're merging with an organization that already has their network structure in place. They already have their security policies. How are we gonna merge these two? How are we going to train our organization? How we're gonna train their organization?
Which security policy trumps the other certainly will have some in common.
But ultimately we're gonna have very different security postures. So how do we address that
perimeters? Are we going to keep these two networks isolated? Maybe set up a business to business extra Nat in between them where your organization keeps its structure, my organization keeps ours and then we have an area of shared resource. Is
you know, there are a 1,000,000 different possibilities on how we do this. We're just gonna combine the networks.
But the bottom line is when your organization changes to this degree, you gotta start from scratch. You've got to go back and you've got a look at what are the assets? What am I protecting? What are the value? What is the value of those assets? What are the things that could propose harm to the assets?
How likely? Probability and impact once again.
And then what are mitigating strategy? So nothing new here. Everything here, go back and look. ATT risks
another thing to be concerned within an organization. We've got to think about regulations. We've got to think about industry standards that guide us and how we behave within the organization. What sort of procedures we put in place to make sure we meet compliance.
Now, the 1st 1 that's listed here. And if I were to really focus on any of the laws
regarding I t security, it would probably be these These four and really PC, I isn't even a law payment card industry data security standards. So basically, if you think about it, you know, think about how much money per year
credit card companies lose because of identity theft and credit card fraud.
It's in the hundreds of millions of dollars. So P C. I. D. S s sets out standards for how an organization that's gonna take credit cards essentially must protect the data.
Well, the thing about P. C. I. D. S s the payment card industry right now is self regulated, and they would like to keep itself regulated. And it's in their best interest tohave very stringent policies and procedures because they're the ones that suffer the loss.
You know, I don't know of any credit card company that currently does not offer
identity protection as in fraudulent charges appear on your card. Most credit card companies eat that loss. So what they want to do is everything in their power to make sure that loss doesn't happen. And certainly to make sure that the loss is it coming from our vendors.
So what did they do? They require a yearly audit either from a qualified third party
or some other vetted agency that requires the vendors that accept credit cards to show how they protect that data and what are the security mechanisms they put in place? So, PC Idea says, though it's self regulated, very strict
now. Fisma. The Federal Information Security Management Act came about as the E government e governance act. Uh, actually think it's government act back in 2002.
Basically, it pulls together Phipps, Federal Information Processing standards, National Institute standards and technologies.
You don't need those acronyms for the exam, but ultimately we have a set of standards and requirements for federal agencies how they must protect their information systems. The requirements that a system has to go through before it can be bought brought onto a government network
the requirements for to be used in a government environment.
Fisma addresses all of those and what I would have. It's just a short synopsis of what each of these do
now hip of Most people have heard of him, but the Health Insurance Portability and Accountability Act. It's all about protecting patient information, healthcare information that meets the standards of HIPPA. As a health care provider, I have certain requirements. I am legally obligated to protect that data according to certain standards.
And traditionally, the full weight of liability was on the health care provider
because of the high tech active 2010 that high tech act it extends liability to third party service is, for instance, if I outsource the processing of medical forms now because the high tech act the company to whom I outsource, also has a liability.
But it in no way diminishes my liability.
All right, sock Sarbanes Oxley. Ah, this was designed Thio. Go back and address the misuse of corporate funds and the lack of accountability for senior officers. And if you remember back in the nineties, we had issues with WorldCom, Arthur Andersen in Ron.
There were a lot of companies where the CEO is abused their privileges.
So now what Sarbanes Oxley does is they require a certain degree of accountability and make it a crime for misuse of company funds. So I would be relatively familiar. Eso basically Sarbanes Oxley focuses on responsibilities of a public corporation's board of directors.
It adds criminal penalties for certain misconduct,
requires the Security and Exchange Commission to create regulations to define how public corporations. This last line are to comply with the law. Okay, So how public corporations heir to comply with the law so publicly Owned companies senior management has responsibilities.
Fines could be imposed in jail time as well.
All right, now, we've talked a little bit about mergers and acquisitions in the past. So once again, Ah, the idea is risk management When we find out that we're gonna merge with an organization, First of all, we need a merger, Security Council, Uh, that should be defined by senior management.
And we're gonna pull together department heads
that are gonna take a look at how this merger is gonna affect our security posture, how we're going to integrate the two organizations and keep in mind always at the forefront. Security.
We've got to make sure that what we do doesn't bring in any additional liability that were still able to meet our legal requirements. We've got to think about a gap analysis. Where do we have to be and how do we close the gap? That's not just for mergers and organ and acquisitions.
Any time we find out, there's a policy
change, you know, I've worked with health care the health care field extensively. Medicare every year has a new sense of regulations and requirements. So what we have to do every year is a gap analysis. Here's where we are. Here is where we need to be to meet those new standards. How do we close that gap?
Hey, we have to start thinking about users within the organization following principles of Lise privilege for user's that need to escalate or elevate their privileges. We've got to consider. So ultimately, there's nothing really testable here. But all of the elements we have to think about,
and we just cannot underestimate the risks
that mergers and acquiring new organizations bring to our company,
bringing new products into the company that produces the potential for risk. And we're bringing new products in all the time I got a new firewall we're bringing in new Web server new software, whether it's commercial off the shelf software, whether it's proprietary software.
one of the things that I'll mention here that might show up on the test is the Stride model for risk assessment, the Stride model for risk assessment. It does not have to be unique to software, but it isn't it? The stride is made up based on,
for each of the things that we consider spoofing, tampering, repudiation, information, disclosure, denial of service and elevation of privileges. But ultimately, when we're thinking about risks from a software standpoint, from a new product standpoint, we have to think about some ideas spoofing identity.
What are some ways that this system could be spoofed,
that users could spoof to connect access? And I'll tell you the best defense against spoofing is strong authentication, strong authentication with authentication? The first step is an identification.
Identification is making a claim. I claim to be Kelly Hander Hand. That's fine.
Identification could be spoofed so easily, so the next step is prove it prove your claim. So authentication means I'm gonna tell you something only Kelly Hander hand should know. Or I'm going to use something like a key or swipe card. Only Kelly handwritten should have or we might use biometrics.
But the bottom line is
to control spoofing. We want to provide some kind of authenticity. That's the best way. So does this application. Does this product allow for authentication
tampering with the information? Do we have a means of locking down the information, using permissions and privileges to control who can access and what their actual access actions would be.
So maybe I'll allow you to read data without modifying it, but we've got to make that consideration.
Repudiation, audit, audit, audit, audit. What repudiation gives me is a combination of integrity and authenticity. So when we talk about non repudiation, I want to make sure. And really
you could you could say, you know, non repudiation is what we're. What our goal is
is that a user can't dispute an action nor the contents of that action. So sometimes we talk about non repudiation with email.
You want to be able to guarantee the email came from me and that what I sent you is what's been received,
so I should not be able to repudiate email. I always think that going back to kind of credit card companies when you get your credit card statement at the end of the month and you'd say, Oh, I didn't make that charge then what credit card companies used to do is they'd send you the receipt and they would show the itemized list and they'd show your signature at the bottom, so
you were not able to repudiate.
All right, we want confidentiality information disclosure needs to be prevented, or it needs to be really better way to say is it needs to be limited with people that should have access to that knowledge. So encryption service is
again permissions and writes can affect, uh, how information is disclosed.
Do we have means to, uh, prevent or at least mitigate denial of service attacks
for a specific product? How susceptible is it to a denial of service attack? Are there means within the system that can detect a d. O s? Can they terminate a. D. O S? How do we consider, or how would we protect a particular system against a knowledge service?
And then another issue of concern is elevation of privilege, elevation of privileges? When I access a system as a regular user, maybe Kelly H.
And then I find a way to add additional permissions or writes to my user account.
So maybe if I know an administrator password, I can add more access to Kelly Hander Han. If they're somehow, um if
if new privileges and rights art controlled,
then users can escalate their privilege and wind up doing things that you wouldn't anticipate a particular regular user would do.
Okay, so this is what stride is all about and the idea behind stride as you think about each of these elements when you're assessing risk for a new product on your network.