Welcome back to Cyberia. I'm Kelly Hander Han, your subject matter expert, and we're gonna begin the section on organizational security. So looking at the company as a whole, looking at the various places from which threat and risks potential for loss can come in
and then talking about some of the ways we're gonna mitigate those strategies or some of those mitigation strategies were gonna put in place.
All right, so first piece, we're gonna look at the various disciplines within an organization and talk a little bit about responsibilities across the board. The impact of inner organizational change. The only thing constant is change. So an environment as it exists today
is open to changes in the future, whether it's just from growth, whether it's for mergers or acquisitions,
whether it's from D mergers, which meaning breaking apart the company into smaller units or perhaps smaller companies on their own,
figuring out what communications, what security controls would be most appropriate.
And then talking about the security, uh, involved in the technical life cycle.
Now, as you'll remember one of the foundational principles of security, it's separation of duties. Let's make sure no one individual has too much power, Too much authority on the network. Let's make sure that confidentiality is enforced by separating out duties and following principles of Lise privilege and need to know.
So what we want to think about is what each individual discipline within the organization has to do. Is Farrah security goes.
I have spent a ton of time on this, but we do wanna cover some basic principles. So right at the top, we see sea level management. That's exactly where they should be up at the top. These air those people with season their title. Chief risk officer, chief executive officers, chief financial officers.
When it comes right down to it, the ultimate responsibility for the security within an organization goes to your sea level managers, the board of directors. These air the people that are ultimately liable. So when we talk about issues of liability, when we talk about issues of culpable negligence,
when we talk about failing to properly protect the company's assets,
that comes down on the sea level managers so ultimately it's their responsibility to set the policy for the organization and to oversee the development of the policies Maur at a functional level procedure standards guidelines.
They're also responsible for making sure that we have preparedness in the event of a disaster or some sort of significant incident within our organization.
So ultimately, the buck stops here. You're chief executive officers. These air gonna be the ones chief risk officers, information security officers, and so on these air the ones to whom the responsibility belongs. Programmers, developers. Obviously, they're responsible for the quality of their work. They're responsible for writing the code.
They are responsible for integrating security in the code
two degree degree to which they are supported now. And I know that sounds kind of difficult, but the idea is, and we've talked about this earlier. Traditionally, we have not written software to be secure. We've written software toe work. And if you go back to T. C p I. P is a protocol, you know, going back to the sixties,
we have this protocol that was designed to transmit
information across secured physical links. So at that point in time protocol, security was not considered necessary. And so many of the protocols that we have been used today so many of the service's were designed for a time where the links were physically secure.
So what that means is software hasn't been written. Protocols haven't been written to be secure from the inside out. So we need a riel shift in philosophy from our programmers. But ultimately, are programmers have to be supported by senior management. And a lot of times, and I've worked in a lot of software development projects.
When push comes to shove in times of the essence,
security gets pushed through the corner in favor of functionality. So, yes, our programmers have to write secure code. They have to integrate security throughout the software development life cycle. But they need the training, the support from senior management
database administrator. So these are the ones responsible for maintaining ah, and keeping up or the upkeep of our databases. Of course, Now they're the ones for the design responsible for the design and the structure of the database,
the internal security of a database. And let me tell you, there a couple of things that are really important
with databases, a couple of concerns specific to databases. I'm gonna jot these up on the board. One of the main concerns with databases,
things like code injection,
you know, a database is a living, breathing piece of software to collection of related information and data. Bases get modified all the time. Customer transactions, employees interaction. So databases are designed to be modified.
One of the ways that we control what goes into our database
is through the use of forms or database views. If ever you've heard the phrase garbage in garbage out, it has never been more true than with a database. So if I give the general public, maybe I have ah, database and I have a Web based form.
Maybe I'm looking for people in the inter back
Internet. Give me See that.
Maybe I'm looking for customers who've placed orders with me to detail their customer satisfaction. Or maybe I'm just giving people a form to find out their user name and their address, and so on. The bottom line is, any time I open up input that ultimately winds up in my database,
that's a threat. We have the potential for harm here. You don't need to know sequel to know that a command like drop tables not a good command, not very helpful to the database, the tables, the basic unit of storage in our database.
Anything that can be input could ultimately wind up being processed on the back end,
so we have to be very, very careful. So when we talk about ideas like code injection, what we're concerned with is someone inputting data control language or some sort of malicious code into our database is causing a loss on the back end.
So with code injection, one of the things that we look to do
is we look to do input validation to protect our databases from input
data typing field length watch for data control language.
Uh, these are all things that I would look at from an input validation standpoint.
So if we talk about input validation, making sure that what someone enters into our Web based forms is legitimate and would cause no damage on the back end. So if you think about it, if I go to Amazon, for instance, and let's say I wanted to make a purchase, and maybe I want to purchase a book or some other
unnecessary plastic object which Amazon sells, pointing up.
If I want to purchase an item, do I get access to I log on to Amazon's database and go in and remove one from their inventory and figure out the total based on elements in the database. Of course, I don't what Amazon what Amazon gives me is they give me a front end application
and I enter my information in that application. And it's the job of what's called ah C G I script stands for common Gateway interface. It's the job of the script or some other mechanism to validate. Would I input in the form proposes or poses no threat on the backend database,
the way the things that it looks for. For instance, when it asks me my state, I may have mentioned you guys, I'm from North Carolina. Originally, there are many different ways you could input North Carolina.
As a matter of fact, if I had a class of 20 people, I could say, How many of you if I ask you what state I'm from, would write out North Carolina? I usually get three report four people that would do that.
Uh, how about in Carolina? How about in period C period in? See, There's so many different ways to abbreviate in so many different ways to indicate the state of North Carolina
garbage in garbage out
all of these different ways of entering what's really, you know, tow us the same information very different to a database. So rather than Amazon given me 50 characters to type out my state name, they're gonna give me too. I am less likely to mess that up.
But even more so than that, with their most likely to do, is not even give me two spaces. What do they give me? Instead?
They're gonna give me a drop down arrow, a drop down box where I choose my state name.
That's that front end application validating. Would I input Now? Don't get me wrong. I can still choose the wrong state issues North Dakota instead of North Carolina. There is only so much Amazon can do to help me out there.
But it's the job for databases in specifically database administrators to design a structure that forces the users into something called the well formed transaction
Garbage in, garbage out.
um, so it's up to the database administrator to provide that for Matt. And what they want to do is they wanna give me a specific data type. For instance, the currency field. You shouldn't be entering letters into a currency field.
So by data typing that field, I'm gonna limit the input.
I'm gonna limit field links. I'm gonna give you 15 characters for your first name. If your name is longer than 15 characters, it'll just be truncated.
Um, so, Dad, a length data control language. Like I said, there are certain commands that if entered into a form, could be processed on the back end. You should never have a customer named Johnny drop tables,
and we need to scan for other sequel type commands. Things like brackets and apostrophes can wreak havoc on the back end. So our input validation should require some sort of skin for those things. Make sure we have the appropriate data types. Make sure we have the appropriate field links
and checking for any sort
of data control language. Okay, so that's the responsibility of the interface to check for those things. And that's one of the ways that we protect our databases.
All right. Another concern with databases,
and inference are two other attacks and quite honestly, these air the most common attacks to databases.
Most people in the technical field will tell you the greatest threat to a database is code injection, and I do not discount that. That's a very serious threat,
but if you look at the definition of a database, it's simply a collection of related information.
My roll index is a database and code injection is just relevant to technical data bases to software driven databases, right. But databases have been around forever, and inference an aggregation have been along around as long as their databases. Let me give you an example for
aggregation and inference.
I went to lunch with some friends of mine that I used to work with, and it's been maybe eight or nine years months ago. It's It's been a little bit of a while, but one of my friends,
uh, is just a terrific gossip. She has always got the news on everybody.
So at lunchtime she kind of scooted up her chair like she's gonna tell me something good. So my years perked up. I do not spread gossip,
but I'll listen. I'll tell you that much right now. So this friend of mine, she said, Hey, did you know that Holly was pregnant?
And I said No, that's great news. Good for her when she tell you
And my friends response just totally cracked me up because she said, Oh, she didn't tell me.
Well, how'd you know?
And she said, Well, we went out a happy hour with her last Friday and she didn't drink.
Mary ran into her last Wednesday, and she was coming back from the doctor.
When Susie ran into her last Tuesday morning, she was sick as she could be. And it wasn't even nine o'clock.
now what, my friend and what makes a gossip? A good gossip. Their ears were always open, and they're always pulling together information
to a less seasoned gossip that might have seemed unrelated information,
Aggregation says. There's a whole lot of information out there that's not necessarily protected. But when you pull it together, you might be able to take the next step, which is inference and take that and make an assumption. So aggregation is the pulling together of information.
Inference is really where the attack comes,
and that's the making assumption. And by the way, my friend, our friend Holly, was pregnant so This was a successful aggregation in inference attack. And that's been around with databases forever. If you walk into my office and you see a roll index and you see certain customers names with gold stars by him,
what could you assume
you could infer that those air valuable customers to may?
Okay, so inference an aggregation, these air. Very valid tools.
Now, if Holly didn't want that information to be public, she had a couple of choices.
First of all, she could have said none of business.
So, Holly, how come you're not gonna drink with us tonight? None of your business.
Where have you been? It's two o'clock in the afternoon. None of your business.
You don't look like you feel well, are you okay? None of your business.
But the problem with none of your business. Oh, to me, that's game on. It's my business now.
So bites indicating that information is top secret or classified. You've actually told someone the value of that information.
So what would Holly's better choice have been? She should ally.
She should have said, Well, the reason I'm not drinking tonight it's because I'm designated driver for a party later. Nobody thinks anything else about it.
Hey, it's two o'clock in the afternoon. You just getting back? Yeah, I've been to the dentist instead of the doctor nobody thinks about
you. Don't look well. Are you sick? This morning you had no college friend come into town, and we stayed up all night.
A better, more polite name for lying is called Polly and Stan. She ation. And that is the best defense against aggregation and inference. The defense there is Polly in Stan, she ation
and Polly and Stan. She ation is spelled very close to what I have there on the board. I make no promises, but it's close enough.
Polly in Stan, she ation Multiple instances. Think about this. If you work in the naval naval yard and you see that, um, they're preparing a ship.
They're going through their routine maintenance before they send a ship out there loading the ship with some sort of supplies. It seems to be pretty clear that they're preparing the ship to go on a mission.
Well, they could classify and say that ship's location, final destination and contents top secret.
But by saying this is top secret, they have just told me that that's valuable information, and this is high value information. So now maybe I want to try to figure out what that ISS
However, if instead, if I log on to a system
as someone that doesn't have clearance,
I'll see that that ship is maybe going to deliver food off the coast of Africa.
Okay, basic, boring information.
However, if I log onto the database with somebody with higher clearance level, I see it's true destination, and its true destination is they're going to deliver supplies and munitions to troops in the Middle East.
So the idea is with Polly and Stan, she ation. It really is more than just lying. Three ideas To protect information within a database, you may use views to control what certain users are able to see based on their level of clearance. And that's a way to keep people from aggregating and inferring information.
Okay, so Polly and Stan she ation,
and that's the responsibility again for database design. So we've got to think about the threats to databases. And remember, if I'm an attacker,
what I want in the database the old joke Why did you rob the bank because that's where the money is. Why'd you attack the database? That's where Target 70 million credit card numbers are right. So we've got to think about ways that we protect our databases, and a lot of that goes onto the shoulders of
a database administrator building in some of these controls.