1. Home
  2. Training Library
  3. Security
  4. Courses
  5. Cloud Governance, Risk, and Compliance

Monitoring Use Cases

Contents

keyboard_tab
Course Introduction and Security Basics
1
Course Introduction
PREVIEW1m 52s
2
Security Basics
PREVIEW5m 48s
Course Conclusion

The course is part of these learning paths

Security - Specialty Certification Preparation for AWS
course-steps 22 certification 2 lab-steps 12 quiz-steps 5
AWS Governance & Compliance
course-steps 5 certification 1 lab-steps 2 quiz-steps 3
play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 7m
Students823
Ratings
4.4/5
star star star star star-half

Description

In the last decade the nature and complexity of security attacks have increased tremendously. From simple attacks, which focused on hacking exposed web pages; we have evolved to stealthy attacks, which focus on the hacker staying hidden for years on end inside the victim’s network with the sole purpose of stealing data. To make matters worse, more and more companies have started to store their data in the cloud, thereby transferring part of the responsibility of securing that data to the cloud service provider. Therefore these days the cloud service is entrusted with the task of providing adequate security to the data and services that it provides to customers. While making a decision to move to the cloud, the two main metrics that enterprises look at tend to be cost and security risk.

Transcript

The next topic to understand in SIEM is for an SIEM to be effective and work smoothly, the security team needs to program rules into the SIEM correlation engine. That is the security team needs to tell the correlation engine what to look for. Many SIEM usually come pre-programed with some 50 to 60 rules but they are generic, and the team needs to make sure that all the situation that arise in the company are covered. These situations are called use cases, and there are roughly about five categories of use cases that need to be programmed into the correlation engine.

Let us now look at some generic use cases. Detect and prevent malware infections. The SIEM looks for events where the employee's computer is reaching out to command and control centers of the hackers. Usually when an employee's machine is infected with the malware, the antivirus software immediately takes care of it. But sometimes the machine could have been infected before the antivirus software has made available the update, or in some cases the malware infection may be of a variety that the antivirus company has not yet detected. In those situations the employee's computer will reach out to the command and control center. Security products like Websense or FireEye usually intercept this traffic.

The alert raised by these differences is sent to the SIEM and the system raised an alert to the security operations team. Sometimes the employee could have been infected at home or could have been traveling under the scope of the company's security perimeter. It could very well be the case the malware could be embedded deeply within the employee's computer, and could now be harvesting information which it could be sending to the hacker.

This traffic, when intercepted by the SIEM, is raised as an alert to the security operations team. Also, it could happen the employee is actually sending out information to a competitor in return for certain favors. This information can be detected by the SIEM and an alert is raised. We discussed earlier the importance of managing user access and especially privileged user access.

The SIEM rules can be configured to detect access from users who are no longer in the company. If this happens the most probable reason is the process of deregistration has failed, and the user access has not been revoked, even though the user has quit the company.

Another situation is when we find logs which indicate that the administrator, who is in charge of managing the email servers, is actually reading emails which do not belong to him. This could be a cause of serious concern. This shows the power of the SIEM systems in detecting abnormal or abhorrent behavior. Monitoring DNS traffic to detect zero day infections. A lot of times hackers use DNS servers which have been blacklisted. If we have appropriate rules in place then it is possible to detect calls to these DNS servers. Usually this method is very useful when a zero day vulnerability has been exploited. Zero day vulnerabilities are vulnerabilities that are not yet known to the security community, and hence no antivirus signature exists for those wall infections.

But by detecting access to blacklisted DNS servers it is possible to ascertain whether a particular employee's computer is infected or not. Another way to detect zero day traffic is to observe traffic that is reaching out to known command and control centers or sending out confidential information to websites that are recognized to be suspicious. Rules can be programmed into the correlation engine to detect for this kind of abhorrent behavior. However, a lot of study has to be first done on the network traffic of the enterprise to ascertain what is normal before programming rules into the correlation engine to define what is not normal.

Detecting fraud by monitoring abnormal account usage. Whenever an account is hacked it is absolutely certain that the account usage will change. For example, it is very rare that the hacker will be from the same city that the victim is from. Also, the amount and type of transactions will be very different from the victim. It's also possible to program rules into the SIEM to see if the same IP address is accessing several accounts. This is a clear indicator of fraud. Monitoring compliance by ensuring all devices are sending logs to the SIEM.

In many companies governed by PCI, HIPAA and ISO 27001 standards, it is crucial that all classes of devices that come under the purview of SIEMs send logs to the central administrator 24-7. It is possible to program rules into the SIEM to detect if logs are being received from all devices. It could be possible that one of the devices may be hacked, and the hacker could have disabled the logs in that server. In such cases, the absence of logs is a clear indicator of something gone very wrong.

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/