Intrusion Detection and Prevention
In this course, we will discuss the fundamentals of intrusion detection and prevention on Amazon Web Services. We will explore the difference between IDS and IPS, and the difference between host-based intrusion prevention, and network-based Intrusion prevention. We’ll also discuss the various AWS architectures, how do you place an IPS, how do you write rules, how do you respond to the incidents that have been detected, and finally the partner solutions available for intrusion prevention with Amazon web services.
- This course is for developers or operations engineers looking to deploy security solutions applications in production AWS platform
- People studying for the AWS Security Specialty Certification exam
- Implementation experience with enterprise security packages
- Familiarity with industry compliance and security standards including PCI DSS, ISO 27001, HIPAA, and NIST
- Experience of architectures meeting industry standards such as SAS70, SOC1, FISMA, etc.
- Fundamental understanding of TCP/IP protocols and packet analysis
- Recognize and explain the basics of Intrusion detection/prevention
- Recognize and explain best practices in designing intrusion detection/prevention architecture
- Recognize and explain the different types of rules that can be written
- Recognize and explain core concepts of Incident response
- Recognize and be able to implement how to go about writing rules
- Gain an introduction to the various partner solutions available for IDS/IPS on AWS
This Course Includes
35 minutes of high-definition video.
What You'll Learn
- Course Intro: What to expect from this course:
- Fundamentals of Intrusion Detection and Preventions: In this lesson, we’ll define intrusion detection, and discuss AWS responsibility for security in the cloud, firewalls, and alerts.
- IDS/IPS in Detail: In this lesson, we’ll dig deeper into the system architecture associated with IDS/IPS.
- Rule Writing: In this lesson, we’ll go through rule options.
- Responding to Incidents: In this lesson, we’ll look at how incidents are detected and the process for responding to them.
- Architecting IDS/IPS for AWS: In this lesson, we’ll look at the various flavors of AWS architectures available and how we will architect the location and the placement of IDS and IPS devices in these architectures.
- Administering and Managing the IDS/IPS: In this lesson, we’ll spend some time talking about some best practices in administering and managing your IDS and IPS.
- Partner Solutions: In this lesson, we’ll look at the partners who offer IPS.
- Conclusion: A summary and review of what you have learned.
Now, let's go on to rule writing in IDS and IPS. You need to have a basic understanding of this concept. As I mentioned before, most IPS products come with a full set of rules and signatures, and the security architect only needs to tweak or customize these rules.
Once again, I stress that it's the responsibility of the vendor of the IPS and the IDS product to ensure that these rules are updates on a regular basis, every time a major attack is detected. If you feel that your vendor is not doing justice, then it is time to look at a new vendor. A rule in an IDS/IPS environment is made up of two parts: the rule header, and the rule options. The rule header determines what action a rule takes, and the criteria that needs to be met before such action is taken.
It is very important to know the difference between a header and an option. A header basically determines what you are looking for, meaning, are you looking for an ICMP packet? And if an ICMP packet is detected, what is the action that needs to be taken? The rule options contain information about the alert that needs to be raised. Let's get into some more details in a later slide. So the rule header can fully be broken up into these parts. Action, protocol, address, port, direction, address, port. Action is the action that needs to be taken when the criteria is met. For example, the actions that can be taken are alert, log, or pass.
So, there may be a situation where you just want to be alerted when, say, an ICMP packet is detected. There may be other situations where you just want to log it, you don't wanna be alerted. You just wanna log it. For example, say the password entered wrongly. See, password entered wrongly once is not such a big deal. But, if it was entered multiple times, then it's an issue. So in those situations, what happens is we just log it. Now this log is then usually fed to an SIM, like say enVision or SIT Analytics platform.
It is there that these logs will be analyzed, and then an alert will be raised, because maybe there are 10 passwords entered wrongly for the same account. But at this level, it's just a log, a single log, nothing to be alerted about. So I want you to kind of understand where the IPS fits in at a difference and depth mechanism, so there's the firewall, then there's a network intrusion prevention, and then there is a both ways intrusion prevention, and then there's an SIM at the end of it. So every action has a different meaning at every level.
And then, of course, there's the pass, meaning just let it go. If this was the condition, let it go. So the protocol tells you what this action, or the rule, is related to, which protocol it's related to. So it could be a TC/IP, or ICMP. The address, see there are two addresses. So one is the from address, and the other one's a to address. Again, port, there are two of them, so one's a from port, the other one's a to port. And the direction of traffic.
So, one's going left to right, the other one's coming right to left. So, if you went, if you used the arrow that went right to left, then the from and to would be switched. Also, if you used both arrows, that means that this rule applies to traffic going both ways. So you have to notice the key thing here is, you can actually write a rule just for traffic going one way. So your rule does not automatically apply traffic going both ways. It actually applies only to traffic going one way, and you can actually specify the direction going from the company to the Internet, or from the Internet to the company, or both ways.
The rule options has two parts, a keyword and an argument. Now let's look at a hypothetical example of a rule header and rule option. So here we have a hypothetical rule. It says alert, if you see any TCP traffic going towards 192.168.1.2, port 80, from any any. The first any, is any address, and the second any, is any port. So, it raises the alert. And what is the alert it raises? It raises the message, TCP traffic. And that's the options part of the rule. And you see that in Snort, it's usually put within brackets. But it might vary, depending on the product that you're purchasing, but I'm going with the most simplest example, which is Snort. And since it is available for free and it's open source, I can discuss it in this course.
Vish Chidambaram is an award-winning enterprise security leader with 18+ years of experience, skilled in areas spanning Automation, Security Operation Analytics and Reporting, Threat Management Life cycle, Agile/DevOps environments, SaaS/Cloud security, Business Development/Consulting, Program Management and more. Most recently Vish was the CISO at Rubicon Project, which is a SaaS based ad marketplace. Here he was responsible for securing a high performance SaaS platform with 40 billion transactions per day. He pioneered the integration of security in DevOps, by using automation, orchestration and machine learning tools. He is passionate about teaching security and believes staying current is particularly relevant in the security industry. He also mentors security professionals and advises them through career transitions. Details can be found at datacoreacademy.com or get in touch by writing to firstname.lastname@example.org. His LinkedIn page can be found at: https://www.linkedin.com/in/vish-chidambaram/