 So, good morning to everybody, hope you have a great stay in IIT Bombay. Just wanted a couple of, I just had a couple of questions before we actually start with a program in detail. How many of you have taught network security, computer security, data security, information security, whatever you call it, in your college? How many of you have not taught it at all? So, you do have some background in it, so the question that we had in mind was before we started this thing and planned the entire program is to what level of detail should we go? Should it be a breadth thing or a depth thing or what? So, because most of you have taught this thing and I'm sure you're familiar with the basics of cryptography, yes or no? If somebody, what are digital signatures, digital certificates and so on and so forth, we will go rather quickly through it. If you have a problem with the speed, just let me know as soon as you can so that we can slow down. So, please look at your schedule, we have tried to put together something that covers almost every aspect of security. So, on the first day that is today, this first session is going to be just an introductory session where we will talk about some of the terms, what are the different attacks that you might have seen, what are the vulnerabilities, what are the defenses? So, that's this first session 9.30 to 11. Then we have a tea break and then we proceed to the basics of cryptography. So, what I decided to do unless the audience would like it is to talk about AES, the Advanced Encryption Standard, but not about elliptic of cryptography, but that's getting a little bit too detailed and we might not have time. So, as you probably realize, this is just a five day program and we're spending about half the time on hands-on lab sessions because we feel that's an important component. So, there is something to be sacrificed when you have a limited amount of time and so as a result, we may not get into the depths of things, but we do have question-answer sessions and we also do, will be available, those of you who would like to know some of the advanced aspects of anything that we talk about are most welcome to contact us, that is myself or Professor Shiva, or even some of our TAs. So, let me also just point them out to you, we have about a large number of TAs, approximately 20 or so TAs that will be assisting you in every aspect of your lab and even beyond. So, the TAs are out there, we'll introduce them at some point. They're sitting at the last two rows and they've done an exceptional job of trying to put together various experiments and various tools. As you know, tools are an important part also of this course and we will be starting with, for example, on the very first day some basic Linux commands which are related to networking and security. So, I'm just telling you what the labs are going to involve and we'll cover some of that material in the lectures, but the labs give you an opportunity to actually have some hands-on experience. Now, don't get intimidated with the lab. It's not like we expect you to do seven hours of work in three hours because the lab duration is typically three hours or less. We will give you a couple of questions, you have to answer some mandatory questions right in the lab just so that we feel satisfied that you're learning something and then there are a whole lot of extra questions which you can try in your own leisure time. So, you can try it when you go back to your guest house room or even when you get back to your place of work. The different lab tools that we have put together are Viashark, besides the Linux commands, we have Viashark. We have Nessus. How many of you are familiar with Viashark? Okay, so I think this is an extremely important tool to be able to capture packets and to be able to look at the different headers and make sense of what you're seeing. The packets are different, the protocols are different layers. The IP layer, the network layer, the transport layer, the application layer, and also because this is a security related course, we will be looking at SSL, which all of us use. I think this is one of the most important security protocols. When you do HTTPS with your banking server or with your e-commerce server, then you're invoking the SSL protocol, which is implemented in your browser, so it's transparent to you, you don't see it. But nevertheless, as a security person, you would like to know what is happening below the hood, so to speak. And what are the kinds of messages that are being exchanged between the client and server? How do you create a secure tunnel and so on? So, there is one lab on Viashark, which starts today and which continues tomorrow. The next question is, how many of you have actually taught web security as part of a security course? So as you know, this is another important topic, so we decided to include this also because you're going to encounter it more and more in the days to come. And everything is moving towards the web. I mean, you're talking about doing your income tax payments on the web, buying things on the web, etc., etc., banking on the web, transactions, etc. So it's very, very important that we understand what are the vulnerabilities of the web and even as we move to bigger and greater features on the web, like HTML version 5, for example, that opens the door to more and more vulnerabilities and more and more attacks. So we will have one session on the web beginning tomorrow and that will continue on to Tuesday. So the web security that is put on Sunday actually overlaps and overflows into Tuesday. And on Sunday itself, we will also have in the lab some of the Viashark that we couldn't complete on Saturday will overlap and continue on Sunday. Besides that, there will be some tools that you should try to get familiar and you should try to download onto your laptops, either here or if you can or when you go back. And those tools are things like Nmap and Nessus and Snot. Any of you have heard or seen or used Snot? Okay, there are a couple. So this is an important tool for intrusion detection and intrusion prevention. So we will talk about the theory of intrusion detection and prevention. But you can also see how Snot rules are framed and what they exactly do. How they help us to prevent denial of service attacks, for example, or port scans and the like. So as far as the lecture sessions are concerned, we will have cryptography after this is over. And then tomorrow we will have security protocols and then software security, which includes a little bit of web security before you actually start the web security lab. And then on Monday, we will have securing the IT infrastructure. So how do you actually handle, for example, logs? How do you find out who's sending emails and who's sending too many emails and that kind of thing? Then there'll be a following session on malware, the different types of malware. There are different types, like for example viruses, worms, Trojans, etc. Can we think of some case studies? Can we look at bots and see what causes them? And more importantly, how to protect against them? And then there's network security, which deals with DOS, DDoS, ARP spoofing, DNS spoofing, even attacks on the wireless infrastructure. And finally, how do you protect against them through intrusion detection? And then Tuesday is an all lab day. So there are two labs both in the morning and in the afternoon. The afternoon lab is a combination of a demo on penetration testing, followed by a hands-on experience with something called DVWA, which stands for Damn Vulnerable Web Application. I don't know if anyone has seen this, but it's a good tool which enables you and your students later on to be able to hack into a web application. So a web application has been designed for you by these people, not designed by us, designed by these people to be deliberately vulnerable. And your task is to attack the web application using two very well-known web attacks. One is SQL injection, and the other is cross-site scripting. So you attack the application, and the application is designed with security level one, that is, it's not very secure at all. So you should be able to attack it. Then you try to attack the same web application with security level two. So they have fortified the application, they've made it stronger and less vulnerable, and you're expected to attack that. Try and see if you can attack that as well. And then the great challenge will be to attack the web application at security level three. So some of that thing will be done in the lab on Tuesday. And then on Wednesday, we have some sessions, a logistic session which the staff will talk about. Certain logistic aspects of this course and the following workshop which will come up in the month of June, or July, sorry. And a little bit about access control at the system level, and that is the operating system level, and access control at the network level, which is via firewalls. And then some more of cryptography, in particular the discrete log problem, and some further aspects of cryptography. And then that's followed by a wrap up session, and more question answers. You can keep your questions for the session. You can ask me questions during the session. You can keep the questions for later, and just put it in a piece of paper or put it through Moodle or something, so that we can accumulate the questions and answer them, because there may be many redundant questions. And then we can answer them in that question answer session, which is on the last day, before we hand out the certificates, if you have finished the course successfully. So with that brief introduction, I will commence with the basics of cybersecurity and then we'll go on just after the tea break to the basics of cryptography. So I like this quote very much. It says, security engineering, especially in this third wave. Just look at this quote very carefully. We have seen reliability, performance and all these other things. Now here comes another requirement on security. But just look at how a security person should think. Security engineering, especially in this third wave, requires you to think differently. You need to figure out not how something works, but how something can be made not to work. You need to imagine an intelligent and malicious adversary inside your system. Remember, Satan's computer, constantly trying new ways to subvert the working of the system. So not how to work, but how not to make it work. That's what's in the mind of the security person. You have to consider all ways your system can fail. Most of them having nothing to do whatsoever with the design of the system. You have to look at everything backwards, upside down and sideways. You have to think like an alien. So this is a quote by a very well-known security analyst by the name of Bruce Schneider. There are quite a few books and articles that he's written which are very insightful. So the outline of this talk is basically cyber attacks. We'll just look at the whole space of attacks. Actually, you can't look at the entire space because the number of attacks runs into hundreds if not thousands. Cyber attacks, then we look at vulnerabilities. What's behind these attacks? Just basic terms and so on. Cyber defenses, including some terms related to cyber security. And finally, some security principles. So the first question in anybody's mind is why would somebody attack a system? Why would somebody attack the cyber infrastructure of an organization? So one of the things is theft of sensitive information. You want to get credit card numbers of the guy who's running the e-commerce site. Or for example, you want to disrupt service like a denial of service attack. You must have heard of many of these attacks launched against e-commerce sites, even against the White House, against different companies like Google and Microsoft and so on and so forth. Their sites have been attacked by a DDoS distributed denial of service attack. But why would you want to do all these things? What is the goal? Maybe money extortion, for example, you want to tell them that I'm going to attack your site and you better pay up. If you don't pay up, it'll be attacked further and you will suffer more losses to your organization. So disruption of service. Illegal access to resources. For example, I want to access a supercomputer in one particular site because I have a lot of applications that demand great amounts of computing power. So these are the possible attacks. In this slide you will see the attack goals right on top. And then you will see attacks that most lay people are familiar with. And then if you want to get technical, some of the technical terms that you might use for the different attacks. And finally, the vulnerabilities. So what are the vulnerabilities? What are the weaknesses that enable these attacks to take place in the first place? So many of these terms you must be familiar with. And of course there are tens and tens of more terms that one can put on this slide. So phishing attacks, skimming attacks, session hijacking, impersonation, DDoS and DDoS attacks, various kinds of malware attacks, various worms and trojans and so on, DNS cache poisoning, ARP cache poisoning. MIM, what is that? Man in the middle attacks, for example, that occur on various protocols, including replay attacks. So these are specific to security protocols. Privilege escalation attacks, side channel attacks, a very insidious kind of attack that has been rearing its head a lot recently. How many of you have heard of side channel attacks? One. So this is a nice area of research if some of you are pursuing further studies or if you've got students who are trying to get more insight into these things. So I take a credit card, for example, and I try to figure out the new credit cards are like smart cards. Okay, so they are much stronger than the old credit cards. The old cards had just the mag stripe. The new credit cards that RBI is mandated for the future will have actually smart cards in them. So smart cards actually are cards with a processor. It just looks like a credit card, the same aspect ratio, but it's got a processor inbuilt. And that processor, believe it or not, is strong enough to even run Java. So you can actually download Java applets onto the smart card and run them. So it's got much more security. But nevertheless, you can still attack these smart cards. For instance, if there's a private key on the smart card, which is guaranteed not to leave the card. You can still figure out, for example, parts of that private key. Using side channel attacks by monitoring power consumption, by monitoring timing, and all sorts of other things. You can actually figure out in these very strange ways. That's why it's called side channel. Because it's not the regular kind of attack. It's through these different side channels, power, timing, etc. And then we have different vulnerabilities, as you can see out there. So these are vulnerabilities in protocols, in the design of the protocol, in the implementation of the protocol, in the software that has been designed, etc., etc. So these vulnerabilities are of different types. And we'll talk about them in great detail as the course goes along. So here are some of the attacks. We don't have time to cover too much. I think this session ends at 11, but I'll just talk about some of these things. So phishing attacks, most of you have heard of this. Lures its victim to a fake website. So I've included a reference over there where you'll find this material in greater detail in the textbook. So wherever you see chapter 18, it refers to chapter 18 of the text. So it lures its victims to a fake website. For example, an online bank. And the fake website has the look and feel of the authentic bank with which the victim has an account. So you feel quite comfortable looking at this new site. You just don't realize it is a hacked website of the original. The victim is then induced to reveal sensitive information, such as her login name and password, which are then passed on to the fake website. So very bad news, you get into the site because you click on some link. Or this thing is sent to you through an email. And that thing looks like the real site. So you have no hesitation. It says something very nice. Like, you know, we need you to update your password, just give us your old password, or we need you to log in just to make sure you're one of the valid customers, et cetera, et cetera. And you have no feel for what exactly is behind this thing. Basically what they're trying to do is trying to get you to type in your password, login name, and then ship it off to the attacker's website. So the problem over here, the vulnerability over here is social engineering. We were not careful with what we clicked in an incoming email, for instance. Or when we went to a website, we clicked on some link over there. And something happens on the screen. And lo and behold, you have lost some of your information. Then there are farming attacks, which are similar to fishing attacks, but are based on DNS cash poisoning, for example. Then, of course, there's this business of eavesdropping on a communication link, eavesdropping or snooping on communication links. And of course, the way to handle that is by encrypting messages and disguising your message. Then there's this business of identity theft. You must have heard of this. So what does identity mean in identity theft? Now, if you just ask a normal person who's non-technical and you say identity theft, what do you think that person is going to understand? What is that person's identity? Who cares? I've got my name and my address. Who cares if somebody knows my name and address? Right, that's the first thing that you think about. So the question is, what is exactly identity? So in security, there are some important words like risk, vulnerability, policy, identity is another word. Identity theft, what exactly constitutes identity? So one might say, okay, it's nationality, language, religion, caste, etc., etc., in the context of India. But that's not what we mean over here. What we mean by identity is things like something that you want to keep absolutely private, like for example, a password or a pin or a credit card number. You don't want hackers to get a hold of all this. So this is what we mean by identity theft. We mean theft of this sensitive, private information. I just mentioned about side channel attacks. So there have been many cases of people actually leaving their credit card somewhere and even though it's pin enabled, for instance, still a hacker can get a hold of it and can perform skimming attacks to get things like the pin inside the credit card or the private key inside the credit card. And I already mentioned about side channel attacks. So these are very, very interesting attacks which some of our students over here at the graduate level are working on trying to implement some of these side channel attacks. These are really, really amazing attacks on, for instance, AES. How I can get the key? AES is supposed to be a very secure cryptographic algorithm. How many of you have heard of AES? Very good, Advanced Encryption Standard. So we'll just review this thing a little bit. But the question is how secure is this? So it was supposed to be very, very secure. But lo and behold, if you just look at the web and Google around, you will see there have been attacks that have been successful on AES. And these attacks are of this very strange type. It's a cache-based, everybody knows what is cache, right? C-A-C-H-E. Cache-based side channel attacks. We won't have time to talk about these things, but in the question-answer session, we can address some of these issues. And I will also give you papers that I've written with some of my students over here at IAT. Impersonation. There are various dictionary attacks. What is a dictionary attack, for example? So you have a list of passwords, a possible password that people could use, and you try to guess that password. So you know, for example, you don't know the person's password, but you know a function of that password, some sort of a one-way function of that password. Everybody knows what's a cryptographic hash, right? So take the hash of a password, for example. Now, knowing the hash of the password, because the cryptographic hash is a one-way function, you can't go backwards and conclude what is the password. But what I can do is, once again, I exploit the fact that there is this social engineering business. I know that people have very simple passwords. Most people, or at least many people, have simple passwords like 1234567, or the name of their spouse, or child, or parent, or something like that. So what I do is, for individuals in an organization, I make a list of 100 million possible passwords. And if I know the hash of that password, then I just run a program with a big loop that runs through all of those possible passwords. So for example, maybe the password is 1234567, or ABCDE, or it was X, Y, Z, 1, 2, 3, et cetera, et cetera. I make a list of all possible potential passwords, and I run the hash function through all those passwords, and I see the result. Okay, and then I match that result with the hash of the password that I found. Okay, so this is a dictionary attack. I don't know the actual password. I know the hash of the password, and I have a possible list. I'm not saying 100% I can guarantee your password really on that list of 100 million things that I have, but it might be. So I run through each and every of those candidates passwords, and I see which one, and I run through it. I compute the hash of each of them, and I see where it matches with the actual hash, which I must have got from some file, for example, that the system administrator gave me. And then I can guess the password. So there's a hacker that lives somewhere on the central suburbs of the city who met me once and surprised me by saying that he had the hashes. I mean, he had the passwords of at least 10 of my colleagues. Can you believe what a shock this was? And he said, do you want to know what's, I'll tell you the password. And then he gave me the name of one particular password, and I immediately realized it's the spouse's name of one of my colleagues. Now how did this guy get all this information? He is not, he didn't get it actually by coming to IIT Bombay. He got it sitting outside in his home, which is outside IIT in a different suburb. And from there, he was able to hack and get passwords of at least 10 of my colleagues. So there are various, various ways in which you can get them, but one such way is this dictionary attack. You've heard of denial of service attacks. So basically what you do over here, again, we'll talk about this in greater detail in the section on network security. So you try to bombard the victim with all sorts of packets. You can use ICMP packets or you can use TCP packets that set up a TCP connection, for example. And when you bombard this victim, what happens? The victim's resources are being used. Which resources? Computing resources, memory resources, communication resources. And at some point, if you keep bombarding mercilessly this victim, at some point that guy is going to get crippled and he's either going to slow down or he's going to completely grind to a halt. And that's exactly what the attacker wants. So imagine an attacker who is your competitor, you run an e-commerce site. And your competitor wants to get some of your business. So he wants to frustrate some of your customers. So what he will do is he will bombard your site with a DDoS attack. So that people will abandon your site and possibly go to him. So this is a problem that many businesses have faced. And the question is, is there some real, real solution that always works against this problem or not? So this is, again, a very active area of research. Malware attacks, so worms, viruses, Trojans, bots, etc., etc. So we will talk again about these things in greater detail in that section on malware. So there have been many different types you've heard of all of these viruses like Code Red, for example. So the main difference between a worm and a virus is that a virus infects a file and spreads from one file to another. While a worm is a mobile thing, it moves from computer to computer, for example. So we look at the different kinds of worms like internet scanning worms, email worms, P2P worms, mobile worms and viruses, etc., etc. So you don't need to copy anything in the slide. We will make all these slides available to you. So you can just look at it and try to get some feel for it. As I said, this is an only introductory session. So all of these things will be talked about in greater detail in one of the subsequent sessions. Then there are another thing that's become very popular and widespread these days are bots. Bots are malware hosted by a compromised machine connected to the internet and remotely controlled by a bot master. So this is a very dangerous thing. What I can do is I want to spy on your organization. So somehow I'm able to sneak in and this is what many organizations face. So somehow I'm able to sneak in a bot into your organization and actually command it and keep sending commands. Now this is a very interesting difference between the earlier internet scanning worms which rocked the world in the year 2004 and so on. Code red and slammer are two internet scanning worms. The bot is diametrically opposite to this. Those worms moved very, very fast and they were very conspicuous because they were bringing down many, many systems spreading rapidly. In the course of 24 hours, for example, they brought down tens of thousands of systems worldwide. These are mostly web servers running some Microsoft thing that they brought down in the span of just one day. Now this is a completely different animal, the bot. I send a bot into your organization and the guy who's sending it is either a bot master or he's acting on behalf of a bot master. So he sneaks in this bot into your organization that lies very low. It doesn't say anything much. You don't even detect it because it's not talking much. Unlike the internet scanning worm which is continuously talking. The bot is not talking at all, it's just lying very low. Periodically, maybe once a day, it's exchanging commands and responses with the bot master. So the bot master is saying, do this, do that. Don't talk to me for the next one week. After one week, do this, go to that particular website and get this malicious code from there and download it onto your system and so on and so forth. Because of this very low level of communications, it's very difficult for IDSs, intrusion detection systems, to be able to detect the presence of the bot. What's worse is the bot master can say, don't talk to me for the next two months. But exactly on this day, on July the 1st, you start bombarding this particular web server, say the Google web server. And not only that, the bot master might have under its control hundreds of thousands of bots. So this is a real world thing. A real world threat. The bot master has under his control actually millions of bots. So those bots might be sitting inside your laptop and your friend's laptop all around the world. And they even partition these bot nets. So all these bots, these 100,000 bots are under me. I will sell you, you're a criminal. I will sell you 100,000 bots. That means you have control over this bot net and you can instruct the bots in your bot net, in your subbot net, to do something terrible like sending spam or launching a DDoS attack or putting spy laggers on some machines and all sorts of things. So this bot net problem is a very serious problem. And once again, we'll talk more about it in the section on malware. So this is one of the more recent types of malware compared to, say, worms viruses and the traditional worm virus Trojan thing. Then when we talk about networking protocols, so these are standard networking protocols like TCP. It's almost the case that, give me any protocol and we'll be able to find out some vulnerability in the protocol. Now you really shouldn't say that the guys who came up with the protocol are stupid. TCP and IP have worked very well for what, 50, 60 years. They came up long, long time ago in the early 60s, 1960s or so. TCP and IP came up and at that time security was never an issue. Nobody ever thought of security. What do they think about? They thought about does it work? Does it transfer packets from one computer to another computer around the country or around the world? They thought about functionality. They thought about reliability. They thought about performance. But nobody ever thought about security in the 60s, in the 70s and so on. Security has become a big issue only after 1980 or so. That is the reason because they didn't think about security, you can find loopholes both in the design of protocols as well as in the implementation of protocols. And you take your favorite protocol, whether it's TCP, whether it's IP, whether it's ARP, whether it's ICMP, whether it's UDP, any of the wireless protocols, Ethernet and onwards, almost all of them, if you sit down carefully, you'll be able to find some vulnerability in either the protocol design or in the implementation, the software implementation of the protocol. So that results in things like address spoofing, for example, a very simple attack on IP. You can spoof the addresses. There is no way for me when I see a packet that's come to me and I see the IP address. There is no way for me to, with certainty, say that this is actually the sender's IP address. He could have spoofed the IP address. Session hijacking, ERP cache poisoning and DNS cache poisoning, for example, various man-in-the-middle attacks. So the last two relate to security protocols, which also call cryptographic protocols, things like your SSL or IPsec. So these are security protocols per se, as opposed to regular networking protocols like TCP and IP. Now that we've talked about attacks and attack goals, the next thing is vulnerabilities. So this is an important thing. When you see an attack as a security professional, as a computer professional, the question that should automatically come to your mind is, why did this attack take place in the first place? Okay, what was behind the attack? What's the weakness? What's the vulnerability behind the attack? So what exactly is vulnerability? It's a weakness or a lacuna in policy. Now look at the number of terms over here. Policy, procedure, protocol, hardware or software within an organization that has the potential to cause it damage or loss. So it's not just hardware or software. We are comfortable with hardware and software, but it could also be something in policy and procedure. How many organizations, for example, permit or don't do anything about visitors or guests bringing in pendrives into the organization and connecting pendrives and getting out sensitive files onto their pendrive. Can you think of it? So are we really a security conscious people as a people, as the Indian people? Are we security conscious or are we very lax about security? So it could be a lacuna in the policy. The policies were not solid enough. They were not well thought out. The procedures, what is the exact procedure when you enter this high security organization? You have a company, tomorrow it's a startup, tomorrow it'll be a bigger company, and then what are the procedures for visitors entering? Is there a certain policy? They are checked at security. They are baggage detected security. Do you check for the right things? Can they just bring a mobile phone inside? What are the potential things that the mobile phone can do and so on and so forth? So the procedures, once again, in the protocol itself, in the hardware, in the software. So these are vulnerabilities that you can see all over the place, and as I said before, even vulnerabilities in human behavior and human action. What is that human behavior? Clicking on a link, for example, either on your cell phone or on your laptop. So human vulnerabilities. Induced by careless, unthinking human behavior. Clicking on a link and an email message from a questionable source. So imagine if educated people like us do this. Just imagine, now that computers, tablets, cell phones are even used by semi-literate people, maybe the Panwala, selling you a Pan, for example, he's using a cell phone, he sees something, he just clicks, and says yes to this message. That opens the door to all kinds of malware, all kinds of bots, et cetera, that might enter his cell phone. And from there, they may spread to other people's cell phone. So clicking on a link and an email message from a questionable source. These human vulnerabilities are typically related to attacks like phishing and cross-site scripting. So we'll talk about cross-site scripting in greater detail and you'll see there's an element of social engineering and human vulnerability in it, besides vulnerability in the design of the web server. Protocol vulnerabilities. Once again, almost all of these protocols, and that is one little exercise for you, to take your three favorite protocols and identify what are the vulnerabilities in those protocols leading to which attack. So can you think of a vulnerability in TCP? And what attack does it lead to? Or in some wireless protocol like VEP? And what does that lead to? Or in ARP? What does that lead to? Anybody has an answer to that right now? ARP cache porting. So what is the vulnerability in that? Yes. You are able to change the binding that is available in the ARP cache, the MAC address and the IP address. Very good. So the ARP cache basically has a binding between MAC address and IP address. You give it an IP address and out pops the MAC address. And the fact of the matter is that anybody can change this binding. So if I want the MAC address of a particular device or a machine and I've got the IP address and I broadcast I say that I want the MAC address corresponding to this IP address, the fact of the matter that that mapping between IP address and MAC address could have been updated by any machine, including some hostile machine on the network. So what somebody can do is, if I'm trying to talk to this guy, he can say that this guy's MAC address is the attacker just behind me. So when I want to send a message to him, it will not go to him, it'll go to the attacker. And the attacker will read everything that I'm trying to send to him. So this is a standard man in the middle attack about which we'll have much more to say in the section on, I believe it is network security. Yes. TCP. TCP, tell me. TCP both the side, we are having buffers. Yes. So the main problem of buffer overflow, we can bombard the packets on the sender receiver side. Yes. So the vulnerability is what? So what he's saying is that in the case of TCP, the vulnerability, at least the attack is a DOS attack. So this kind of DOS attack is referred to as a SIN flood attack. You are bombarding a machine with, what are these SIN packets? When we talk about TCP, when I'm, the first thing I need to do because TCP is a connection oriented protocol, I need to establish a connection that is done via the three-way handshake. So if I am the initiator, I send a SIN packet. When I say SIN packet, what do I mean? With a SIN flag set. And then this guy responds with the SIN flag and the ACT flag set. That's the second message in the three-way handshake and then I respond with the ACT flag set. So it is this three-way thing before which I can only, this has to be established before I can send data. And now what this guy can do, or say I'm the attacker, and that's the victim, I can bombard that victim with fake SIN packets. I can pretend that I'm a legitimate guy, for example. I'm a customer, I'm a new customer, and try and send him SIN packets with a SIN flag set. He will be very happy and think I'm a new customer and be all out to welcome me, but actually I'm an attacker. Now the problem is, when I initiate this communication, as he said, that guy, the victim, will reserve some amount of buffer space. Say for example, four kilobytes of buffer space for every single connection attempt. So if I start doing this very much, and not only that, but I get several zombies to act on my behalf, like those bots that we talked about, and all of them start sending him the SIN request packets, then he'll be reserving 4K, 4K, 4K, and there's a possibility that the amount of memory reserved for him will be exhausted and he will necessarily slow down. And also the other thing is, he's got to expend computational resources to look at the packet and to process that packet. So there's a certain amount of computational overhead, in this case as well. So that's the TCP vulnerability. The vulnerability is that these messages have not been authenticated. So always ask yourself, if this is the problem, then what is the corresponding vulnerability? In this case, I don't know who's this guy who's trying to request a connection with me. So I just entertain this new request by reserving so much space, and then I find this is not a real request, but some phony request. So like that, you can look at every single of these protocols, ARP, TCP, some of the wireless protocols, and it's very, very interesting to see what could be the kinds of vulnerabilities, and then, of course, finally, how to fix them. So we'll talk about that in a second. So once again, vulnerabilities, first, social engineering kinds of vulnerabilities, in human behavior. Second, in the protocol itself, which could be design, or it could be implementation of the protocol. Then software vulnerabilities. This is a very, very interesting field, and we'll talk about it in great detail tomorrow. I believe there's a session tomorrow on this, but in a nutshell, what is software vulnerability? So when you write software, the first thing you think about, imagine all of us have written programs. We talk about writing, say, a sorting program to sort a number of elements. The first question is, does it really sort well? So the question's about functionality. Does it do its job? Then does it do its job reliably? Then does it do its job with acceptable performance? Is it very, very slow? If I've got to sort, say, one terabyte, does it take forever and ever, or can I get the result in reasonable time, and so on and so forth? But the new kid on the block is software security. As I said, talk a lot about this on Tuesday, but before that, some of the main vulnerabilities in software, for example, web application software is on the website, is that the input that has been received is not sanitized properly. So how many of you here are familiar with SQL injection? Okay, so do you see that as a problem, and can you think of what is the vulnerability behind it? Just go in your mind and ask yourself, what is the vulnerability behind an SQL injection attack? Just think for a minute. We'll come to all of those things later. I don't want to spend too much time on it because we've got another 15, 20 minutes before the end of the session. But just ask yourself, if you know SQL injection, the attack, what is behind the attack, what could I have done to prevent this attack from taking place in the first place? Then look at XSS, then look at Buffer Overflow, and each time ask yourself, if you know what's Buffer Overflow, so we'll talk about that with a demo on it. What is behind this attack? Why does this attack take place? Does it only take place with a C-language program, or also could it take place with a Java program, and so on and so forth? So data validation doesn't take place? Yes, so data validation doesn't take place. We could discuss that a little bit more, but in a nutshell, that's the answer. There is no data validation on the server end, that is at least for, is that true also for Buffer Overflow? SQL injection. So ask yourself for SQL injection, then go ahead and ask yourself, what about for cross-site scripting, XSS, and maybe something else like CSRF, cross-site request forgery, and then for Buffer Overflow. For all of these is a data validation, for some of these is a data validation. Is that a good defense? How should the defense take place? Et cetera, et cetera. Sir, to prevent that SQL injection attack, we can put some pattern-based recognition, because in password we are passing some special characters to make that political condition true. That is the basic attack in the SQL injection. So if we are just matching the pattern that these special characters are not allowed in the password field, then it can be prevented. So that is another, some of the, that is the one of the way. So what is the attack first? When you say SQL injection, what is the attack? So you said something about the password field. Yes, in SQL injection, we are bypassing that login and authentication of that particular website. So to bypass that particular login and password, we are just using one pattern, which always correct, which always become true, like one equal to one or whatever. So it is just accepted in password field and we are just bypassing that password. So in a nutshell, what you are doing is you are changing the semantics of the SQL query. Whatever you typed in over there will get planted into the SQL query. And that was the problem. That was the vulnerability. The guy who designed the web software just took whatever you typed in the password field on your web form, just took it without thinking, without doing any extra work, just took it and put it inside the SQL query and rendered the entire SQL query, which then went to the SQL engine and got executed. What you should have done is seen that this looks like, doesn't look like a name. It looks like, say it's the login name field, for example. It doesn't look like a person's name. It looks like part of the SQL query. So what's he doing? Can anybody have a name like where X is equal to Y or where X is equal to X and stuff like that with quotes and so on? Doesn't look like a normal name. There must be something fishy that's going on over there. So he didn't do validation on the server side. And so there are some standard techniques to avoid this problem, which we'll again talk about in detail when we mention web security. And you'll also see this in the lab. So there'll be a lab on SQL injection, which will start, I believe, tomorrow. So now you've talked about vulnerabilities. The next thing is defenses. So what sort of defenses can we deploy for each of these possible attacks? And of course, there are hundreds of these attacks. So the different ideas over here prevention, detection, recovery and forensics. So very briefly, what are some preventive strategies? Let's take encryption. Does it prevent something? Is it preventive or is it reactive? It's obviously preventive because you're deploying encryption at the server, at the sender end, at the receiver end, encrypting every single message so that an attacker cannot eavesdrop and read the message. So it's a preventive sort of strategy. Access control. You're preventing an intruder by making sure that the guy who's coming into your system, who's logging into your system, is authenticated. Could be password authentication, biometric or whatever. Code testing, code auditing. You're taking all that web code, web application code this guy has written, and you're passing it through a very strict auditor that's checking for all sorts of these things like XSS and SQL injection and so on. So these are preventive strategies. What are examples of detection? Best example is intrusion detection systems, which work via anomaly detection. Am I seeing something that is not normal? Every day I see these amount of TCP packets in a 10 minute interval. Approximately this, this is the normal range. Today I'm seeing instead of 100 packets, I'm seeing 10,000 packets. Something makes me deeply suspicious. Anomaly detection. Another thing is this guy logs in every day. Typically from nine to five, he's a regular guy who comes to the office at regular times. Suddenly at four o'clock in the morning, this guy is logged in five times. Isn't that strange? Why should he do this? Who does, who handles all these? These are anomalies, and these are handled by an intrusion detection system. So there are two types of systems that can be deployed in an organization, intrusion detection, intrusion prevention. So this is the role of the IDS, which operates either by anomaly detection or by signature detection. I look at a signature of message, for example, sending me, if I detect this pattern of bits, then I suspect it's this particular worm. So that would be signature detection. Similarly you've got integrity checks on messages and so on using an MD5 hash of the content of file, for example. Some terms that we should be familiar with, security policy and mechanism. So security policy is a set of rules and practices that regulate how an organization manages and protects its computing and communication resources from unauthorized use and misuse. So this has become a very important issue with all major companies these days. So you have banks, for example, and it's so important that in the organization you'll have a special guy who has a very high designation. He's called a CISO. What does CISO stand for? Chief Information Security Officer, just like the CEO and the CIO is another guy who's got a fairly high position in the organization who handles all these security things. And under him sit all the system administrators and the entire security staff. A security mechanism is a technique or device used to implement a security policy. So what could be an example of a security policy in my organization? For instance, all BTEC students can only log into these websites and not anything else. So I'm giving you a list of websites which is on a white list. You can only go to these websites but nothing else. As an example, it's an extreme example of a policy. So the administration in this campus sets this policy up and then it's to be implemented. And the next question is how is it implemented? What is the mechanism to implement it? And the answer to that will be something like a firewall, for example. A firewall would check and see this request is coming from this person who happens to be an undergraduate student. He's not able to access these particular sites on this black list or he's able to access only these sites on a white list. And accordingly would allow him or prohibit him. So that's the implementation using a firewall. So the policy is a high level statement by high level people, managers and so on. And it's to be implemented by technical people by configuring the firewall with proper rules. Access control authorization. So access control, the process of preventing unauthorized access to a computing or communication resource. A very similar idea is authorization, basically associated with permissions. So you have permissions, a principle has permissions. Principle means a subject. A principle has permissions to access these particular files with only read permission and these files with both read and write permission, et cetera, et cetera. So you have it at the operating system level, you have it at the network level. Access control and authorization. Then the other terms, you must have seen all of this. So I'm just going through this very quickly. Entity authentication and message authentication. So in every protocol that we talk about, security protocol, there will be two phases. The first phase is what's called entity authentication and fill in the blanks. Key exchange. So the first step of the protocol is entity authentication and key exchange. Basically, I'm talking to HDFC Bank. I just want to make sure that guy at the other end is in fact HDFC Bank. And likewise, he might want to make sure that I am the right person I claim to be. So that is entity authentication. But that is not enough. Of course, besides that, we have to exchange keys which will be used to encrypt all messages going back and forth and to integrity protect our messages. So that's the idea of entity authentication and key exchange, basically session key exchange. The other aspect is message authentication. Can anybody think of the difference between these two? Yes. So are they different than is entity authentication different from message authentication? No, it's different. Entity authentication is the source, is correct entity or not. Message that is originator is, the sender is genuine or not. Okay. So look at it this way. I'm trying to talk to this bank. Okay, the first thing is, I should know it's really HDFC Bank. That guy should really know it's me. So that is entity authentication. Now that's not enough. Subsequent to that, I'm exchanging 20 messages with him back and forth, back and forth. Fine, we were initially in the loop, but now what if somebody hijacks the whole thing? So for every single message that is sent from me to him or from him to me, it needs to be authenticated. And that is done using, this thing is called message authentication, which is typically done using. What do I do for that? I wanna make sure that the message that is coming is really his message that was composed by him and that was not tampered with in transit. A digital signature may be too much, right? What is the name for that thing? Yeah, so you use a keyed hash to integrity protect the message. And that thing that you use, which looks like a digital signature, but it's not as complicated, is called a MAC message authentication code. So we will actually, in the lab, you will actually see where these things are in the SSL protocol. Every subsequent message with the bank will have to be integrity protected with a MAC. So MAC is not a simple CRC. It's much more complicated than that because it involves the cryptographic hash. These things are very obvious, confidentiality and integrity. Integrity is the most important, right? So there might be cases, again, think about this. There might be cases when you're talking to somebody on the web where you don't require too much confidentiality, but almost always you require integrity. I really want to know it's come from him and not somebody posing as him, that particular message, and I don't want it to be tampered with along the way. If I'm buying t-shirts from an e-commerce site, do I really care whether it's encrypted? He tells me the t-shirt costs 500 rupees. What is so secret about it costing 500? But surely I don't want somebody to change that 500 to 5000 or change it to 50. So it should not be tampered with, and surely if I'm asking for t-shirts from that particular shop, it should come from that shop and not somebody posing as him. So integrity protection is absolutely fundamental, even more so than confidentiality. So as we will see in the SSL discussion, this is an absolute must. It must be integrity protected, but confidentiality is an option. And then non-repudiation goes even further, a guarantee against repudiation or denial by a party of the fact that it created the message or sent a particular message. So this guy sends me a message saying that he owes me 10 lakhs, and then tomorrow very conveniently denies that he sent me this message. What can I do when I go to a court of law? I mean, this guy really owes me 10 lakhs, and tomorrow he says no. I never said that I don't need to pay you anything. Would you be happy with that situation? So normally what you do is you have a digital signature, I mean, sorry, you have a manual signature, but in cybersecurity what we do is we have a digital signature. So I'm sure most of you know how a signature is formed and so on. So we'll go through that very, very briefly in the next session when we talk about cryptography, because that's one of the important things also. Okay, so this last little section over here is on security principles. When I was writing this book and thinking about it, you see a lot of security looks like an art. You just try this and it works and maybe it doesn't work and so on. It's not really a science. And I wanted to see what are the scientific principles, just like software. Software design can be just like an art. I just write a program, I don't really think about it. And if it's a very large program, how do I design whether it's 20 classes or 200 classes in this particular application? It's all kind of like guesswork. Can we not make it more scientific? Software design. So the answer to that as anybody knows, how can you make software design more scientific, more structured, even object-oriented software design? You would use something like design patterns. Are you familiar with this term design patterns? There's a singleton pattern and the wrapper pattern and the observer pattern, all wonderful things which are embedded in your Java APIs, for example. You can actually see those things, the observer pattern, et cetera, when you write, when you invoke certain Java APIs. What's behind the design of the Java APIs? Likewise, when you write your own applications, it would be a good idea if you can liberally use these patterns. But first of course you have to understand them. So there's a whole subject on object-oriented design and design patterns and UML and so on and so forth. So I thought could we not have some basic principles in security, can we not enumerate them for training the next generation of people that comes into security? So the first thing is, everybody thinks it's a big technical thing. Here's the firewall, here's the IDS and so on. But it's not just that. If you go to companies and you talk to people over there, you talk to banks and so on, you'll find that it's not just getting a big firewall and getting a great IDS, et cetera. It's much more than that. It's a human problem to start with. It's like washing your hands. They talk about security hygiene. Be careful with your passwords. Be careful with so many different things. Do's and don'ts. You can carry this, you can not carry that, et cetera. So security is as much a human problem rather than a technological problem and must be addressed at different levels. So as I mentioned before, the CISO and many, many more people should get involved. It was the case 10 years ago when nobody in the company was involved with security, maybe except the system administrator. Not so anymore. There's an entire dedicated security department in most main organizations, telecom companies, banking companies, et cetera, et cetera. Another thing, nobody considered security at all in the past, whether it's design of a protocol or design of software. Security should be factored in at inception. Don't just think about performance and reliability. Also factor in security in everything that you do, whether it's a hardware product or whether it's a protocol or whether it's a piece of software that you're writing. It should be factored in early on during the design phase of a new product and then carried forward right through implementation and testing. Don't design the product, release it, and then say, okay, I forgot about security, now let's see, now let's patch this up, let's patch that up. That wouldn't work, that's not professional. You can't make something secure if you don't know how to break it. So what does that mean? I make something and I challenge all of you to break it. Only all of you for the next one year try, try, try and say, I cannot break this, only then I'm sure that what I made is secure enough. And because people didn't do this, this is a good example, security by obscurity or by complexity is often bogus. So I hide the cryptographic algorithm in the hope that nobody knows what I'm really doing and I say this is very secure. Nobody knows the cryptographic algorithm, only myself and four other people, but we don't realize that the rest of the world is smarter than we are. And pretty soon somebody's going to re-engineer the entire thing and figure out what was the security algorithm. And that has happened so many times in cell phone security for example and so on and so forth that now the security community is finally decided that the secrecy should be not in the, not in this but in that, fill in the blanks. The secrecy should be in the key, not in the algorithm. So whatever algorithm, whatever cryptographic algorithm I use for whatever purpose whatsoever, whether it's to compute the hash or whether it's to compute a secret key cryptographic scheme or a public key cryptographic scheme, everything is very well known and very well documented. There's no secrecy in it. There's only secrecy in the actual keys that are used in the private key or in the secret key. Always consider the default deny policy for adoption and access control. So what does that mean? So on a cell phone for example, if you're going to upload, sorry, download some software onto your cell phone, always for example, you ask the person, do you want this thing to be downloaded? Just don't allow anything to be downloaded by default. So ask, type your name and your password if you allow this foreign thing to enter into your system. So the default deny policy is the conservative approach in which the subject's request is denied unless it is on a white list. The default permit policy grants the subject's request unless the subject is on a black list or there are certain blacklisted attributes. So by definition, at the end of the stop the guy and say wait, I want to check you. Don't just have some weird policy that says if this guy is wearing a green t-shirt or a red t-shirt, then you stop him otherwise you allow him to go. Okay, stop everyone over there, show me ID card, et cetera, et cetera, and only then can you proceed. So this is these two main policies in terms of firewalls or any access control device. Default deny and default permit. Another thing that has caused many attacks and entry should be given the least amount of privilege or permissions to accomplish a given task. If you hire a maid to clean your house, will you give her the keys of your safe or just leave those keys there for her to just see and when no one is looking, she can just go and open something? Obviously not, you should be very careful. You should be given the keys only to the thing you need. If you need the jadu and the water and whatever, give them the keys only to that room where she can get those things and use it. Don't, there's no sense in giving the keys to something which stores something precious like your jewels and so on. So give them the least privilege that is necessary so there is all the level of privilege. Give them only the least level of privilege and permissions to accomplish that particular task. Defense in depth. So this is very much used by the military for example. You don't have just one firewall in your organization, you have several layers of firewalls. In case the first firewall is breached by the enemy, then hopefully the second firewall can catch the attack packets and stop them. So that's exactly what is done. You have level one firewall, level two firewalls, sometimes even level three firewall. So this principle is security through depth or defense through depth or defense in depth. And then another principle is identify vulnerabilities and respond appropriately. So what does this mean? Risk is equal to roughly proportional to the product of your assets. So think of an organization and you're trying to protect some assets. So the assets that you're trying to protect, what is the value of those assets? What are the vulnerabilities and what is the final threat over here? So all these three things are important. If there's no threat then what's there to protect? Because normally security is an expensive proposition. You have to hire all these experts into your organization and you have to hire all the, I mean you have to buy all this equipment which could be VPNs and IDS devices, firewalls, et cetera. Should I really be spending all that money? First question is, what are the assets that you're trying to protect? If the assets are worth just two lakhs, maybe it's not worth protecting anyway and spending 20 lakhs on security. It doesn't make any business sense. Are they vulnerable? If there's no vulnerability then what are you trying to protect and why are you buying all this expensive equipment? And thirdly, is there any threat? If there is no perceived threat, actual or perceived threat, then once again beware and be careful before you invest 20 lakhs in all these security devices. And finally, in every branch of engineering you have seen trade-offs. So what are the standard trade-offs between say performance and cost? I want to improve the performance of this application so I put more processes, put more cores into my system for example, or I put more disks and so on and so forth. So there is performance versus cost but there's also security versus performance. If I have got more security, just think of encryption. Encryption is costly in terms of CPU cycles. So you have got more security when you deploy encryption but at the cost of performance. Security versus cost, as we just said, you put all those devices and you bear the brunt of higher costs. And then one of the things that's very irritating is security versus convenience. So just visit an airport and just see what has happened after September the 11th. There's so much more checking and you get irritated because they open your bags and so on and so forth. But that's the price you have to pay for enhanced security. You want enhanced security? Then you have to go through this extra amount of inconvenience. So these are some of the trade-offs. You may not like all this inconvenience, change your password, make sure you have at least eight digits and so on and so forth. But hey, you want to be secure then you've got to go through all this pain. So that's it. We'll have T now and then we'll come back and continue with crypto. Thank you.