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.
Alright, now let's get in to some more detail with regard to the ideas at IPS. A Snort-based IDS, which was one of the initial ideas is in the market and the most basic consists of the following major components: a packet decoder, as I mentioned before.
The intrusion detection differs from firewalls in the sense that it looks at packet so there's a packet decoder. And there are preprocessors which is basically the part of the Snort engine that analyzes your rules. The detection engine, which brings together the rules with the packet, meaning it looks at the content of the packet with the processed rule and make sure if there's a fit.
If there is a fit, then the detection engine passes on a 'Yes' to the logging and alerting system. So the logging and alerting system is your interface with the product. So if you have asked the IDS to log and alert, then it will do so. The output module is more of a kind of a dashboard. It is possible, in some cases, to interact with the IDS directly through a command terminal and an output module is usually more for GUI interface. Today, most IDS/IPS have a output module to which we interact with. Alright, now let's look at intrusion detection system in some detail. This is a very, very simplified and very typical architecture.
So there's the connection to the internet leading in to the firewall, from there to the switch and then the servers are connected to the switch. As I mentioned before, an intrusion detection can operate when it is not inline because it does not block traffic. So it can be inline with the blocking feature switched off or it can be connected to a spam board and listen in stealth. So this is the typical intrusion detection system architecture where the IDS is connected to the spam board, listening to all the traffic, and when it finds a packet that matches any of the rules, it raises an alert. Alright, now let's look at intrusion prevention.
Again, very simplified architecture but if you understand this, it is possible for you to break down any complex network architecture into this simple component. Again, here we see the firewall, the traffic coming in through the firewall from the internet and then passing through the network intrusion prevention system and then moving on to the servers. If you notice that the intrusion, network intrusion prevention system is actually inline. That means if the blocking mechanism is switched on, it is possible to block the traffic that has been flagged by any of the rules from reaching the servers.
As I mentioned before, it is also possible to keep the blocking mechanism switched off, meaning it will simply perform as a network intrusion detection system and log or alert you. Otherwise, if the blocking mechanism is switched on, then the traffic will be blocked before it passes on to the servers. Alright, now let's look at host-based intrusion prevention system. Similar to the architecture described in the diagram in the previous slide, however, now we're going to focus on the servers. Here you see that the traffic that has been allowed through the network intrusion prevention system to reach the host. Now, the traffic going in and out off the servers will be first analyzed by the host intrusion prevention system, HIPS.
Also, when the server is trying to connect back to the internet, it will first pass through the HIPS and only then pass through the NIPS. Why do we need HIPS? This is because we practice the concept of defense in-depth. So we not only have NIPS to protect the network but we are protecting the endpoint as well. And that is the significance of defense in-depth so that when one layer fails, then the other layer kicks in. Even in this diagram, you see there's a firewall, that's layer number one, NIPS, layer number two, HIPS, layer number three. This is also the fundamentals of defense in-depth.
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 email@example.com. His LinkedIn page can be found at: https://www.linkedin.com/in/vish-chidambaram/