Intrusion Detection and Prevention
The course is part of these learning paths
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.
All right, so we spoke about rule writing. So what do rules basically do? They detect incidents. So now let's talk about how do we respond to findings by the IPS devices? Now let's look at incident management. The first step in incident management is detection. That is, there is a packet, or there is traffic, that is conforming to certain rules that you have written in your IPS.
Next the security team will look at the packets will look at the traffic, and decide whether it is in fact an incident, or a false positive. Remember our discussion on false positives earlier in this course. Once it has been decided that it is in fact an incident, then the team will triage it. Triaging is assigning a severity level to the incident. So they might say that this is a really severe incident, meaning a full-blown virus attack, or they could say that it's just a minor anomalous traffic that's been detected. The next step is to contain it.
In the case of a very severe virus attack or in the case of even a single computer being infected, the step is to contain it. Maybe we will segregate that subnet or segregate the computer and remove it from the network for analysis. The next step is eradication and recovery. Eradication is removing the virus from the network or the computer, and then ensuring that the subnet is connected back to the corporate network or the cleaned-out computer is in fact, connected back to the network.
Then we do a root cause analysis. Find out why this happened. What is wrong with our defense in-depth architecture that made this incident happen? We will always find some loopholes and it's a constantly growing architecture and it keeps getting better with time. And then the last step is review. Meaning we take the root cause, the findings from the root cause, we look at our processes, and then we change the processes to conform or fix the findings of the root cause analysis. Some more points of incident management.
A good incident management system must very clearly define the procedures to be carried out in case of a breach. And this means that one, everybody in the organization must know what the procedures are and second, these procedures must be tested in dry runs again and again, to make sure that these procedures are common sense. Also, there must be very clear-cut processes for the timely reporting of information security events to the security department.
There could be a hotline or a website, or an email ID that employees must be aware of and must use to report incidents, because a security department cannot be everywhere at the same time. The internal audit team must make sure that there are processes in place that ensure the security department acts on each and every event that is reported. Usually, if you read the newspapers these days, in many cases, even certain very high-profile incidents, the hacks were actually detected, but the management did not act on them. And that's why the hack got really, really severe. So it's very important that there are processes in place, that the security department acts on each and every incident that is reported to them.
About the Author
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 where he was responsible for securing a high performance SaaS platform with 40billion transactiions 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 thru career transitions. and details can be found at datacoreacademy.com or writing to firstname.lastname@example.org His linked in page is https://www.linkedin.com/in/vish-chidambaram/