1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Intrusion Detection and Prevention on Amazon Web Services

Administering and Managing on IDS/IPS

Contents

keyboard_tab
Course Introduction
1
Introduction
PREVIEW4m 21s
Course Conclusion
8
Summary
1m 17s

The course is part of these learning paths

Solutions Architect – Professional Certification Preparation for AWS
course-steps 48 certification 6 lab-steps 19 quiz-steps 4 description 2
Security - Specialty Certification Preparation for AWS
course-steps 22 certification 2 lab-steps 12 quiz-steps 5
AWS Advanced Networking – Specialty Certification Preparation
course-steps 19 certification 2 lab-steps 8 quiz-steps 4
play-arrow
Start course
Overview
DifficultyIntermediate
Duration38m
Students861
Ratings
4.1/5
star star star star star-border

Description

Course Description:

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.

Intended audience:

  • 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

Pre-requisites:

  • Implementation experience with enterprise security packages
  • Familiarity with industry compliance and security standards including PCI DSS, ISO 27001, HIPAA, and NIST
  • Experience on architectures meeting industry standards such as SAS70, SOC1, FISMA etc.
  • Fundamental understanding of TCP/IP protocols and packet analysis

Learning objectives:

  • 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.

Transcript

Alright, now I wanna spend some time talking about some best practices in administering and managing your IDS/IPS. Most importantly, I would say that you need to plan for both the RAM memory as well as storage for your IDS/IPS. As volume of the traffic grows, the processing capacity of the IPS has to grow parallelly. Otherwise, you will find that once you click on an event, it will take forever to respond. So make sure that the processing capacity of your IPS device is increased as the traffic increases.

Also, as the traffic increases, the storage concentration for all your logs will also increase. So make sure that you predicted for that as well. Then, in the case of a distributed setup, like in the case of HIPS, make sure that if you are transmitting these logs across the network, that in those situations, the network can handle the increased log traffic. So we're talking about planning for internal memory, external storage, as well as network capability, as your, the size of your traffic grows.

You need to accommodate for the IDS/IPS. Otherwise, the entire installation will very quickly become useless. Another important topic. While the IDS is used to defend your enterprise, how about protecting the IDS itself? Make sure the IDS is regularly patched. I do not mean the rules and the signatures. Now that's for detecting attacks against your network. An IDS is a software that needs to be regularly patched. So make sure that it's regularly patched. Make sure your vendor is providing you with the appropriate patches at the right time. Do not confuse this with rules. Ensure it is completely locked down, as per company security standards.

Also, use it only as an IDS or an IPS. Do not use it. Now this is not so relevant in today's world. In the early days, you used to have a machine where you could install an IDS/IPS product on it. Today, most products come pre-installed in blades. So, but I wanna put this in as a cautionary measure. Also, if you can, install TripWire or any kind of integrity checking agent on your IDS/IPS boxes. If they already come locked down, then that should be okay. If you are building it from scratch, which very few people do these days, but I just wanna put that in. You know, make sure that you detect, if a hacker's hacked into it, then definitely, its configuration is going to change. Then you should have something like a Cloud Passage or TripWire that sets off an integrity alert.

Alright, a couple of points about access control. Ensure administrators cannot view or modify the logs. Now this is very important to note, because, we are in one way, the security group, by we, I mean the security group, are ensuring that the IT group is doing its job. Now, if administrators had the power to delete logs, then the integrity of those logs would not be maintained, and hence, you know, audits might not reflect the true state of the company. Also, security department has to have read access to these logs, but not to the administrator functions on the server. So this is a clear-cut case of division of responsibilities. So security department has access to the logs. IT department has access to the servers. I will get into a little bit more detail in AWS base access control in the next slide.

I wanna spend a little bit of time talking about something that's very specific to AWS, which is the concept of security group versus Network ACL. The Network ACLs are kind of a firewall, and they operate at a subnet level. They support allow rules and deny rules. They are stateless, meaning you need to specify rules for both the return traffic and the outgoing traffic. And the, the rules are processed in number order, right, based on their firewalls. Now in the case of security groups, they also control access, but they operate at the instance level. So Network ACL is at subnet level, and security group is at instance level. So make sure that, you know, we talked about defending the IPS itself, these are put into place.

Now it's very difficult to talk about what exactly the kind of controls that need to be implemented, because you know, architectures change. But make sure that you understand the difference between Network ACL and security groups, and use the right ones. Now, the security group operates at the instance level, and they only support allow rules and stateful, okay? And also, very key thing to remember is, it evaluates all the rules before deciding, right? So it's not one at a time, as in the case of Network ACLs.

So this is a diagram that talks about, you know, a hypothetical situation, so you have the Network ACLs that's actually defending the two subnets. It lies behind the router. And the Network ACL. Below the Network ACL, you have a security group. In one case there's a security group. In this case, the security group is defending both the instances. In this case, the security, two different security groups defending two different instances. Maybe it's because the rules are slightly different. So you can define a security group for a bunch of instances, or for a single instance. So keep this in mind when you are

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 info@datacoreacademy.com His linked in page is https://www.linkedin.com/in/vish-chidambaram/