Part 06 - Common Architectures

Video Activity

This lesson covers the following types of security and common architectures: • Distributed computing o Client-Server o Peer to Peer (P2P) • Service Oriented architecture • Rich Internet application o Client Side Threats o Server Side Threats o Aggregation and Inference • Ubiquitous computing o Wireless networking o RFID (Radio frequency ID) o NFC (...

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

Already have an account? Sign In »

12 hours 41 minutes
Video Description

This lesson covers the following types of security and common architectures: • Distributed computing o Client-Server o Peer to Peer (P2P) • Service Oriented architecture • Rich Internet application o Client Side Threats o Server Side Threats o Aggregation and Inference • Ubiquitous computing o Wireless networking o RFID (Radio frequency ID) o NFC (Near Field Communications) o LBS (Location Based Services) • Cloud architecture

Video Transcription
moving forward. We're gonna look at security and common architectures that Aaron use and we'll take a look. A distributed computing, some ideas behind service oriented architectures, rich Internet applications. We'll talk about the idea of ubiquitous computing and then cloud architecture.
So as we talk about distributed computing,
you know, one of the things that we would look at is we look at, um,
client server environment where we have a server and we have the clients, you know, in comparing this back to the days of main frames. So with mainframes, we had a huge mainframe that was protected. This was the system that did actually all the processing. And then on client desktops, we had
dumb terminals.
That's not a distributed environment. That's a centralized environment, because all the processing, all the work, all the effort, everything was being done on the mainframe, and the client simply had the terminals on their desk cop.
So we moved from there to a distributed environment of client server where we had processing on both ends. So in a client server environment, where we talk about the idea of thin clients versus fat clients, well, if you go back to mainframes. Mainframes gave us
the ultimate thin clients through the use of terminals.
And when we talk about thin clients, we talk about low, low, low and functionality.
You know, apart from the mainframe, what can you do on a terminal?
you know. Does the terminal have a drive to input information? No. Doesn't have a drive to export information? No. Doesn't have an operating system on which you can perform various functions? Not really. So the idea of a system that has very low computing capabilities, very low hardware requirements and functions.
That's a
then client.
So what's interesting is, you know, we went from the mainframe environment to a client server environment and the benefit Waas. Let's have these computers on everybody's desktops that air powerful computing machines. You know, let's go out and spend two grand on everybody's individual systems, and let's give them the power to do the processing right there.
Now the problem with that is the life span of a computer is about a year and 1/2 maybe a little bit more.
if I've got 200 computers that I've spent two grand apiece and they have to be upgraded every three years. That one's up being very costly.
So the idea of then clients has come back around in that we do a lot through, um,
Web forms. We do a lot through terminal service's and remote access, and ultimately, what that allows us to do is to keep our desk cop clients without having to constantly upgrade and update them.
So when we have this remote access server, that's where the software's actually running or the server form, or whatever that might be.
That's the these air, the systems that we have to invest the money in. We have to make sure those are robust systems. This is where we patch our software. This is where we control our software. So it really gives us the benefit of centralization. Even though we're in a distributed environment. Having very thin clients saves me money as well.
It's also benefit from a security means
because what I could then do is I can take out, um, the media drives on my thin clients. I can take out the USB. I can take out the DVD and rewriteable drives because
the processing is happening on the remote access servers, so we could make those clients very, very thin. And if you don't have any way of importing or exporting media or information, that certainly provides me benefit security.
Other things that we think about with client server environments, we think about scale, ability, client server environments, very easy to add host to and can grow in a very large environment. We have to think about availability. So we incorporate redundancy into that client server design
and usually with client servers again very much a centralized environment. So we maintain the servers. Also, what happens with a client server environment is we create our security policies on the server on the domain, controller, the client's log into the domain controller and get their policy.
So that's centralized as well. We like centralisation
because it cuts down on our efforts, and it's easier to secure and manage
now. Prior to client server environments, we did have a peer to peer networks which were used in the workplace. Now we mostly see peer to peer networks for file sharing, you know, from from end user to end user being able to share files. You know, a lot of the torrent software
Napster really was one of the first most popular PTP sharing
mechanisms. So, um,
we've got both of those means is distributed computing.
We move on to talking about the idea of service oriented architecture, and this really goes back into the idea that I was talking about earlier. I talked a little bit about modular ization, if you will, and
what we want is instead of an application that does. Everything is, we think about term functions in terms of service is, and we have each module perform a particular service, and that service can be used again and again, and that could be used in different contexts. So
basically, when we talk about a service oriented architecture,
it is a much more efficient means of development. And it's a much more vendor. Neutral means. So,
um, we get this integration or this communication between multiple vendors because we're using these neutral service is
I hope that makes sense. So there's some ideas that go along with service oriented architectures. Um, loose coupling means that the individual modules can't be too dependent upon one another. They have to maintain a degree of independence
abstraction. Usually when we talk about these objects, they're not concerned with all the other details of how everything else works. They perform a specific function of specific service, if you will.
Ah, and the rest is dealt with. The rest is up dressed. It's abstracted from the specific service.
Other ideas like reusable, stateless, discoverable. These ideas all come into play with service oriented architecture. And again, the idea is, let's have a means of
vendor neutral communication functionality that's reusable in modular and design.
Internet rich applications are rich Internet applications, you know, with all the functionality we have through our Web applications,
what we're seeing is Adweek. As we add additional functionality, we're seeing threats increase again. That idea of reducing the attack surface will. The tradeoff for that is we have less functionality.
So if we want a great deal of functionality and interaction, we're likely going to increase the attack surface. So when we talk about these rich Internet applications, we have to look a client side threats and server side threats
with threats to the client. So essentially, you know we'll go to a Web page and will visit a Web page that will run a script on our system, you know, Java script is very, very powerful.
Activex controls very, very powerful. So when we visit a trusted website and we allow the scripts to run on their system, that presents a threat.
Now, just a couple of clients. I'd script threats, cross site scripting and
the sea surf attack, which is a cross site request. Forgery, sometimes pronounced Ceasar
uh, these were both threats and the client side.
What happens with cross site scripting
is an attacker would taken advantage advantage of a trusted website that does not provide proper input validation.
So essentially, it's code injection on a Web site that doesn't provide the appropriate validation. And then what they're essentially looking to do is to trick me as a client into going to that website where the malicious code wraps around and runs in my browser.
one way to think about that is a cross site script takes advantage of my trust for a website.
Hey, a sea surf takes advantage of a Web sites trust in me.
And here's what I mean when I establish a connection, say, for instance, to my bank, I've got a session and I obsession i d in session related information, and that's how that bank knows that I've already authenticated. I'm already validated. And I should have access. That keeps me from having the wall again, again and again and again
for every single request that make.
But the problem with that is,
if someone
could possibly compromise that information and use my session, i d maliciously. That's how men in the middle or that's how session hijacks happen.
And so across site request forgeries Essentially gonna take advantage of me running, uh, having two sessions going at the same time a session going on with my bank and then another application open, Possibly some sort of Internet chat or some sort of message and capability with the attacker.
So the way this might work might be I'm gonna send you an email until you that your Bank of America account has been compromised. Call this phone number and will assist you with correcting the problem.
All right, So you call me, and I'm gonna have you log on to your base.
Okay? Go ahead and log on to your banking application.
Now, in this other application, I want you to go, and I want you to click a link on an email that I send you, and I'm gonna help you troubleshoot the problems. Well, of course, when you click on that link of the email that I send you, you're launching an application that will maybe steal that session information that might be in cookies that might be stored unencrypted,
Uh, and even if it is encrypted, if I can use it again, I don't really care that I couldn't decrypt it.
So ultimately, with the cross site request forgery, I'm gonna steal that authentication that session based information and use it to impersonate a legitimate users.
So one testable idea cross site scripting takes advantage of a user's trust of a website.
Cross site request. Forgery takes advantage of a Web sites trust of the user.
So if you think about that, that should make sense.
Now. Those were a couple of threats to the client side application. Certainly, the server side has many threats as well. Probably the biggest threat when we talk about Web applications to a backend server is code injection
and with code injection. You know so many of our applications require user input,
whether it's your username password, city state address, I may be asking you for customer service feedback, whatever that might be. And we solicit that information through Internet forms.
Well, the problem is, what goes in those forms is eventually going to go to my back in database, and if it could be entered into the database, the Basin database can process.
So what we want to make sure is that no one's entering commands like Drop table into my database, and there is no person out there whose name should be dropped. Johnny drop tables. So we have to cleanse our data. We have to make sure our dad is inspected
and we want to validate. Make sure that there is no data control language being entered.
We want to regulate the data type so that people aren't using bad alphabet for daytime fields. We also want to do things like, um, check for the size the field size, and we do that through an interface.
I don't know if you remember me earlier talking about Clark Wilson security model
that essentially said, Keep your protected resource is away from untrusted users forced them through an interface. That's exactly what does the inspection with their server side threats, we have something called a common Gateway interface script, the CG I script.
That interface is what's responsible for doing the input validation.
So just ideas that kind of all come around and tie in together.
Other threats against a server aggregation and inference is information is collected.
Um, that information can be accumulated
and inference means I pull all this information together. And then I take that next step and I make an assumption.
So some ways that we can prevent aggregation and inference. We mask out sensitive information like I've already mentioned. We do masking with credit card numbers, Social Security numbers, passwords. So we a limit. What information or we limit when information is is capable of being seen.
And then the idea with Appalling and Stan she ation pollen Stan, she ation is actually a big word for lying.
Um, that's exactly what Polly and Stan she ation is multiple instances of an event.
So the idea is
if there's information that we want to protect,
just by saying this is high value information or top secret information
that really lets an attacker No. Hey, this is good stuff.
So rather than marking something is top secret What we might do is we might inter false information
like, for instance, let's say I logged into a database that tracks the whereabout of where our ships are going.
Okay? And I see that we have a ship that's going to, ah, location that's marked this topsy
well, all of a sudden, it's intriguing to me that's high value information
Now, if instead, when I log on with unclassified access, it tells me the ship is delivering food to the coast of Africa.
All of a sudden, that's not of interest to me.
But someone who logs in with the higher level of classifications sees that the ship is actually delivering munitions somewhere in the Middle East will. Certainly, that becomes much more meaningful. So the idea is, if you log on with lower access or lower clearance, you get one set of information,
and if you log on with a higher level of clearance, you might get
actual events. That's Polly in Stan, she ation. We often see that used with databases,
all right, a couple of other ideas here. Ubiquitous computing computers are everywhere. Everywhere you look, we see wireless technology, whether it's the controls on our vehicles, whether it's pacemakers and other health related information in a wireless networking
is everywhere.
Any time we're communicating wirelessly anytime of computers involved, anytime there's transmission of information across a media but type of media,
we have the potential for eavesdropping. We have the potential for manipulation and so on.
Or if I D's, um, with, uh, we're seeing the chips on the credit cards were seeing the chips on the password on the passports we see the R F I D chips on our transponders were going through the easy pass a toll booths, so certainly we see a lot of these.
The near field communications are becoming very, very popular
if you have a hotel room key that you no longer feed through the slot, but you just hold it near the slot that's in FC Communications. They're also things like location based service is. There's a GPS that allows tracking. They're all sorts of means of computing that we see out there today.
So the more computers there are, the more vulnerabilities
we we go this path for ease of use, and it certainly has its vulnerabilities. But we also have to look at the threats that come as well
Up Next

Our free online CISSP (8 domains) training covers topics ranging from operations security, telecommunications, network and internet security, access control systems and methodology and business continuity planning.

Instructed By