Okay, So after talking about the disciplines within the organization, the various roles people fulfill, Ah, one count just for a minute about controls. And, ah, one of the things we say a lot of in this class is layer defense, layer defense, layer defense. And primarily I talk about physical,
technical and administrative controls. Now they'll call in procedural controls, and that's fine. The ideas we put processes and policies in place. The point to understand Here is the way to protect your resource is is not through anyone means
there is no one element or no one security mechanism you can implement that will keep your data safe. Your network safe.
So what do we do? We put in a series of defenses. As a matter of fact, if we go back and talk about the security breach with R S A. And R. S. A. Was the company that had the secure token devices, the onetime passwords, and they had a security breach.
And what happened was there was a targeted email
sent to three individuals within the company. Remember, spear fishing is a topic we talked about well, in addition to spear fishing, It was also wailing because the three people that were targeted were very high up in the organization
once again, the ideas that they often have a high degree of access to the network because they sign the paychecks,
but they don't always have the skill toe have that degree of access So long. Story short. What happened is this email that had malicious content, specifically an attachment. The technical controls work
the spam filter, moved those e mails out of in boxes and placed him into a junk mail folder. But it only takes one.
And it took that one person to say, Hey, why is this in my junk mail folder? This looks good. Oh, and there's an attachment.
Let me open that up. Backdoor software installed on the system and the rest is history, So this is a perfect example. Technical controls can only do so much when you have people not following policy. When you have a situation where principle of least privilege isn't enforced,
administrative controls could have fixed that.
I mentioned the breach with Target 70 million credit cards compromised. Why? Because an H back vendor was able to access a system that could ultimately connect to the production network,
and there was a ex filtration of 70 million credit cards.
Well, how do you fix that problem?
An administrative policy that enforces separation of Judy's
physical security means don't allow this network to be physically connected to that network, and I'm not saying either of those will prevent this, but they certainly would go a long way towards so you cannot rely too heavily on technical controls. And yes, this is a technical exam.
But technical is just a piece of the big picture,
and this exam addresses that fact as well. So make sure when you're looking to implement solutions, you look for a well balanced approach policy. That's procedural control, technical controls, Yeah, encryption and authentication and those ideas and then also physical controls. Lock your doors.
Have security guards got guard access to your building.
Shut off physical ports that aren't in use, so always look for that layer defense. Now, within each of the categories of procedural, technical and physical, there are also different functions of controls. For instance, some controls are designed to prevent or deter,
and we've talked about this and other chapters.
We want proactive controls and we want reactive controls. So when we talk about a proactive control, we refer to that as a safeguard. And the job of the safeguard is to stop the attack, keep it from happening in the first place. Deterrents, a sign that says, Do not trespass
that will keep some people from trespassing
a cz. Matter of fact, I was working on a military base and our training room was down one hallway, but they had lots of hallways, and every one of them looked alike. So I had gone to the restroom, got up to the cafeteria to get a cup of coffee, and when I came back,
I turned down the wrong hallway and I went to go into the room where the training should have been
if I'd been on the right hallway
and the door was closed and it said,
um, use of deadly force is authorised with anyone attempting to access this room, that was a really good deterrent. As a matter of fact, I step slowly away from the room, turned around, found the right hallway and kept on moving. Now, how expensive was that sign? What,
three bucks? 10 bucks. Whatever
a good deterrent is very cost effective.
Now. If I was a determined intruder, that doesn't mean that would have stopped me. But for a lot of people,
a deterrent will work, sometimes thes losses to confidentiality, integrity and availability again or not by determining triggers.
Okay, sometimes they're accidental. Sometimes intruders or just going around knocking on doors? Not not not not not not a CZ. A matter of fact, we've had a string of car break ins in our neighborhood,
but they weren't really break ins. It wasn't that somebody was bashing out windows stealing people's stuff. What it is is we've got neighborhood kids going around three in the more more trying doors. Is the store unlocked? Is this door unlocked? Is the store and long. And when they find one that is, they go in and rifle through people's stuff and steal. Um,
it's not that you can't bypass a door lock,
but it's a deterrent, right? And really, it's actually designed to prevent crime, but we know any preventive mechanism can be avoided, So put your time up front. It's cheaper to prevent the crime to keep the crime from happening in the first place.
then it is toe. Ever go back and recover your losses,
but we can't count on our safeguards. Always working, they can be bypassed like we've just said. So what I want is I want a burglar alarm. I want an intrusion detection system on the network. I want auditing. I want to monitor and no
if a breach has been committed.
So when we talk about these controls, yeah, we want physical, administrative and procedural. But within each category. So there are controls designed to deter within procedural, maybe an employee handbook that lists the rules.
There are employees. Procedures that are designed to prevent
separation of duties prevents you from having access to this file or folder.
Um, there are corrective means termination policy. So the point. I want to make yours within each of the three main categories. You have various functions of controls. You want to make sure you have a well rounded, layered defense.
Now, as we move forward, we're shifting gears a little bit and you can see my slide references. Something called the waterfall model. Now, when we're talking about operational security
excuse me. What the waterfall model has to do with is This generally has to do with system development, particularly software development. So if your organization produces proprietary software, whether to sell to the general public or you have a team in house and you very well may
to produce software for use within your organization,
the waterfall model has traditionally been a very popular means of developing software. Here's a testable idea. The software development model is designed for long term projects. Okay, so you want this from a testable perspective.
So I have a very long term project. Maybe I'm developing an operating system and think about all the code and how much effort would go into writing an operating system that would be a long term project.
And because the waterfall method is so long term in project,
you can have a very large gap between when requirements are defined and when the product is produced.
So what that means is, if it takes me two years to design a product that you told me what you wanted it to do, you know, back in February of 2008
there's the real potential for changing requirements. There's the real potential for environments to change, so it's very difficult to take these long term models and make them successful if you are in an environment that's frequently changing,
and that's just something that you might see on the test, that's a downfall of the waterfall module
is because there's such a long time between when the product is developed and when the requirements were specified,
you have the potential for requirements to change and do not meet the requirements. As a matter of fact, for those of you that are familiar with agile, which are book doesn't which which this class doesn't address. But I'll tell you, the whole purpose of agile is the fact that
requirements change. We need new functionality from our applications. So we're gonna break the requirements up. We're going to sign them two teams based on little functions, little pieces of functionality,
and that way is requirements do change. We can kind of snap out what we don't need any more and snap in what we do. So I just wanted to reference agile just very briefly, But I do think you'll see question, perhaps on the waterfall model, and again, this addresses software development.
So what this does is it defined several distinct phases, specifically five distinct phases that are involved in developing software. Software development is very much a project and should be managed as such. So if you are creating proprietary software in house,
you need a project manager for this. And they need to have strong management skills
as a matter of fact, more so than technical development skills. I would rather have a project manager who's managed project successfully. There's a lot more to management than just knowing a particular discipline.
All right, so the five phases of the waterfall model, we've gotta requirements phase. So of course, this is where your customer has the input. Sometimes this is called the problem phase because the customers coming to us and saying Here's the problem that we need solved. We need an application that will do this. This, this and this
and we're collecting their requirements.
Don't forget to consider security. Have the customer help us identify their security requirements. As in if this is a database for health care provider, they're gonna identify their requirements, is needing to store data and the means that's compatible with HIPPA. We've got to get that defined.
Okay, now we move into the design phase where we figure out how to do with the customer wanted a lot of times. This is called the problem phase. This is the solution phase. Our team figures out how to meet the requirements of the customer.
Also, we figure out OK, You told us you need to store data in compliance with HIPPA. What does that even mean? And how are we going to write code that will protect the data that will enforce stool factor authentication that will enforce privacy and all those ideas. So this is the piece where our team figures out how it's the planning piece.
now, implementation in testing. So, by the way, this is the planning. Peace? Absolutely, that starts. But this is also where the code gets written. We design and we write the code. Now we're gonna implement the software in a lab environment. We're not throwing it out into production, saying up hope this is ready.
We're gonna implement this in a lab environment, and we're gonna put it through a series of
tests and we're gonna have baseline expect patients for that product
and are functional. Baseline must include security
for so long we have asked two questions with software development. Does it work? And is it secure?
The question needs to be. Does it work securely or it doesn't work at all?
Okay, so with inflammation, implementation and testing, we're testing for function with security
a. Then the verification pay at stage verification. That word,
uh, it can be defined as being the correctness of a product.
Is the product correct?
What makes it correct? Does it meet the customer requirements as documented and specified and bio, By the way, most projects fail because of poorly defined requirements or lack of change control if requirements change. So down here, we want to make sure that we've built the correct product,
and this is the piece
for those of you in government. Were products get certified, which means they're evaluated from a technical security standpoint, and then accreditation is management's acceptance of the system. And then what do we do? It gets rolled out, and we go into the day to day operations where we continue to monitor the application.
We ought it to make sure it's performing as it should.
Upgrades as necessary updates, patches of systems, anything that we have to do to keep it, keep it running securely as necessary