Part 10 - Common Architectures

Video Activity

This lesson covers security and common architectures that are presently in use with cloud design: • Distributed computing o Client-server o Peer-to-Peer (P2P) • Service oriented architecture • Rich Internet application o XSS o CSRF • Ubiquitous computing o Wireless networking o Radio Frequency ID (RFID) o Near Field Communications (NFC) o Location ...

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

Already have an account? Sign In »

5 hours 31 minutes
Video Description

This lesson covers security and common architectures that are presently in use with cloud design: • Distributed computing o Client-server o Peer-to-Peer (P2P) • Service oriented architecture • Rich Internet application o XSS o CSRF • Ubiquitous computing o Wireless networking o Radio Frequency ID (RFID) o Near Field Communications (NFC) o Location Based Services (LBS) • 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, er, 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
terminals. That's not a distributed environment. That's a centralized environment, because all the processing, all the work, all that the effort, everything was being done on the mainframe, and the client simply had the terminals on the desktop.
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, just 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 thin 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 desk cops that are 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 thin 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, and we have to make sure those were robust systems. This is where we catch 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 server, 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 the security realm, other things that we think about with client server environments. We think about scale, ability, client server environments, very
easy to add host, too,
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 centralization because it cuts down on our efforts, and it's easier to secure in to 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
P two p sharing
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 a dress. 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,
uh, vendor neutral communication functionality that's reusable and 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 psi serve these air 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
A a C 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 game 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, where that's how session hijacks happen.
And so across site request forgeries. Essentially gonna take advantage of me running. Ah, 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 bank. 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.
Ah, 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. 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 controlling which being entered.
We want to regulate the data type so that people aren't using Balfa bet 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 in inference is information is collected, 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 have limit what information or we limit what information is is capable of being seen.
And then the idea with Paulie and Stan, she ation Paulien Stan she ation is actually a big word for lying.
Um, that's exactly what Polly and situation 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 is top secret.
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 this 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 the higher level of classifications sees that the ships 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. You know, wireless networking is everywhere.
Any time we're communicating wirelessly anytime of computers involved, anytime there's transmission of information across the 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 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
ISC2 Certified Cloud Security Professional (CCSP)

This online course will guide you through the contents of the CCSP certification exam. Obtaining your CCSP certification shows that you are a competent, knowledgeable, cloud security specialist who has hands-on experience in the field.

Instructed By