Transcript
Good afternoon, everyone, and thank you so much for joining us for ManageEngine's first ever IT security talk show. It's really a very big moment for us because we are doing this for the first time. So thank you so much for taking time off from your busy schedules for joining us today and really being part of this initiative. My name is Siddharth, and I work as a product specialist for ManageEngine's SimSolution Log360, and I will be one of your hosts for today's session, along with Vivin, who is our senior technical evangelist. So really, what we wanted to do in today's session was to give you guys crucial inputs and discuss different aspects of Sim in 2019 and sort of look at different areas that we recommend you to focus on as part of your security response strategy. So if you're wondering what makes us competent to host today's talk show, well, it's what we've done in 2018 and the years before that. We've been hosting a whole bunch of seminars across the globe, interacting with thousands of administrators, and what we've gained out of doing these events is really a deep understanding of the SIEM market and also what customers and our customers and our prospects are looking for as part of their IT security strategies. So we did about 44 seminars in 2018 in 26 different countries, meeting over 3,000 people along the way. So we've really developed the material for today's talk show based on topics and interactions that we've dealt with over the course of 2018. So this is what we've planned based on what we've learned. So this is what we want to talk about in today's talk show. We want to start off by looking at some of the latest challenges and advancements in SIEM. I want to talk about this. I'll just do a quick overview for five minutes to sort of get you up to speed on what's been happening in IT security over the last couple of years and sort of what to watch out for, especially from a SIEM point of view in 2019. After that, I'm going to introduce Viven, and he'll talk about how you can audit and secure your Active Directory and Windows environment. So he's going to give you some really interesting cases that you can implement right away in your organization if you're not yet doing it, and you will be able to instantly boost security. So I promise you that you will have actual action items by the end of today's session that you can take back and implement in your organization. So we're really going to look at practical things, important security events to watch out for in your network. I'm going to give you cases. Viven and I are going to give you cases that you should be looking out for in your network. It could be that you're using a managed engine solution. It could be that you're evaluating a solution. It could be that you are using an other vendor solution. But all the content that we are going to discuss in today's session is really applicable to really anyone and everyone who's interested in achieving effective SIEM. We'll finish off the session by discussing some common IT security mistakes that we have encountered in 2018 while discussing with the thousands of administrators, and we'll also give a list of questions that you should ask your SIEM vendor in terms of capabilities and also in terms of performances and other metrics. So I hope everyone is all settled down and you have no issues with the audio or with viewing my chat screen. I also just wanted to let you know that at the end of today's session, at the end of today's talk show, we will have a live Q&A. So try to keep your questions for the end, which should be in another 40 minutes. So just make a note of your questions and we'll try to answer them out loud live for the benefit of the entire audience. So I'm going to start off today's session for the first five minutes, give you an idea of what the state of security response is right now. So I read the Verizon's Data Breach Investigations report and this was the most alarming stat that I came across. There were a lot of interesting insights and I strongly recommend anyone, whether you're an administrator or a CIO, to actually read this report. But this one stat really stood out for me. 68% of breaches took months or longer to discover. Think about how horrifying that is if that happened in your organization. If you discover today that three months ago, last November, there was a major data breach in your file server. Imagine the repercussions to your business. Imagine the legal repercussions. Imagine what would happen to all your IT security and compliance programs. But this is a fact. Verizon found that breaches are taking way too long to discover. And with that in mind, I want to come back to one of the most fundamental concepts of security, which is real-time alerting. Breaches are taking too long to get discovered and often get discovered by a third party who notifies an organization, which we are missing out on something that is available, which is real-time monitoring and alerting. If you think about it, in many of the breaches that have happened in the last few years, if the security team received an alert at the right time, they could have mitigated the damage of the breach. Right. It's obviously not that easy. It's very easy for me to say, hey, if you have real-time alerts, you're going to solve your security problems. If you have real-time alerts, you're going to detect breaches. But there are a lot of challenges today because of the advancements in technology. There are a lot of challenges today that have made it very difficult to practically implement real-time monitoring and alerting. Right. I want to discuss five major areas, which is making it very difficult for security teams today. The first is the loss of visibility as users move to the cloud. Right. Today, you have users on Office 365, using Exchange Online. You have users on Azure, AWS, maybe some SaaS applications of Salesforce. Now, remember, all of these applications have user data interactions. Right. Imagine if today you're an employee in your organization jumps into Salesforce CRM, exports the sales CRM data and walks out of your organization tomorrow. Right. Can you track that? It's obviously difficult because you don't have that much control on what's going on in the cloud as you would have if it was an on-premise application. And then you have more cutting edge attacks. Attacks are evolving. Just as security solutions are evolving, attacks are evolving and you have new strains of ransomware, which are hard to defeat. You've got a whole bunch of new internal threats that are on the rise. Right. It's not that you just have to monitor what's outside, but what's happening on the inside, inside your organization, monitoring each and every one of your users. That is a big challenge. And it's a very important aspect of security today. Right. Because we hear statistics that 30 percent of attacks were because of a malicious insider. Right. One in three attacks. So this is really mind boggling numbers that we need to watch out for. And then you have IoT, Internet of Things, which is connecting more devices on a network and which is increasing the attack surface for an attacker to get into your organization. Right. And if that wasn't enough, you've got new regulations, governments coming up with data protection acts such as the GDPR. A lot of you are joining in from Europe today. So you would know for sure what I'm talking about in terms of the challenges that it's posing to security teams today. Right. And you've got a lot of breach reporting requirements that make it mandatory for you to report data breaches to the authorities within a stipulated time frame. Right. These are all things that every CIO, every security team has to watch out for in 2019 and beyond. But let's not lose hope. SIM solutions have been reinventing themselves. Right. SIM solutions have been around for a long, long time, and they've been around for 10, 15 years. But SIM solutions have constantly evolved and adapted to the requirements of the market. Right. A lot of people sometimes are skeptical and they ignore having a SIM solution in their security arsenal. But the fact is that SIM solutions, especially if you're using the right SIM solution with the latest features such as the ones that you see on the screen, you will be in a much better position to mitigate attacks. Right. Because you've got advanced correlation engines, advanced analytics. You've got tools that can go into the public cloud and actually give you inputs into what's happening in your public cloud applications. You've got new-age techniques that we'll touch upon over the course of the talk show on machine learning and user behavior analytics. Threat intelligence has become a huge aspect where you're able to block known malicious sources even before they can cause real damage. And you've got a whole bunch of integrations that can be done with your SIM solution to improve and accelerate threat detection and response. Right. I've talked about giving you a simple overview here. I've given you a basic idea of where we are at in security in 2018 and going forward in 2019. I've talked about a lot of this jargon that you see, machine learning, user behavior analytics, and things like that. But what I strongly recommend is really to start with the basics. And I'm going to hand it over in a minute to Vivan, who is our senior technical evangelist, who has been working extensively with Active Directory and Windows environments for six or seven years. Over the course of these years, he's been a speaker at more than 100 events, interacted with so many, so many Active Directory administrators and IT managers, that he has some amazing insights on how the most simple things that we would take for granted, that we would assume that every organization is staying on top of, are often ignored. And Active Directory, which is the most used service, is really the least audited and creates a lot of issues from a security point of view. So I'm going to hand it over to Vivan, who's going to take us through auditing the Windows security log and looking out for crucial events and crucial event IDs from these log messages in order to detect different attacks at different stages. So over to you, Vivan. Thank you very much, Sid. A very good afternoon to everyone present here. One thing that I love about my job that is being a technical evangelist is I get to interact with administrators, which means I get to know some of the problems that they face with regards to security auditing. Now, with that little bit of experience in hand, what I've done here is I have consolidated a few security auditing use cases that can be put to use in any organization, be it of any size, small, medium, or large, or be it of any industry that you are into. So before starting about the use cases or before sharing the use cases with you, I thought it would be better if I start with an example, because the slide that you see on the screen is the example that I'm going to use. And this example resonates well with the security cases that I'm going to be talking about in the forthcoming slides. Now, I was a user of Fitbit, a past tense, right? So I have a Fitbit watch, and I had a Fitbit watch, and that Fitbit watch always gives me details, details about the number of steps that I walked, the distance covered, my heart rate, my sleep pattern, so on and so forth. So that can be considered as raw data, which you have in your environment, any environment for that matter, which you have in your Windows logs, which you have in your database logs, in your application logs, in your firewall logs. So that's raw data. Now, that doesn't make any sense to me as an end user. So that's when Fitbit actually came up with an idea of giving us a mobile app, right? So I have this cool mobile app from Fitbit. So I log into the app, and then I get to see information, right? You have numbers, you have reports, you have bar charts. Now, again, that is cool, but that is of less use for me because I'm not able to take any action with that information in hand. Now, if I make one change to the existing information that I have in hand, I will then be able to transform raw data, which is 7,442 steps to actionable insights, right? And that change is I add an indicator to the existing information that you have, right? If you take a look at the screen for a minute, you'd be seeing a pink line, a dotted line. That is an indicator. Now, that indicator tells me, I mean, keeping in mind Fitbit, it tells me that I have to walk an additional 2,000-odd steps to complete my weekly target. Now, if you give me that insight... 2,000 odd steps to complete my weekly target now if you give me that insight now I'm all set to complete 2,000 steps and attain my weekly target now I can use the same approach to my existing sim solution your sim solution that you have right now in your office gives you out-of-the-box reports right which is information now if you add indicators to the existing information that you have that again becomes actionable insights that's the whole point of my session for the next 10 to 15 minutes and I'm going to sticking to I'm going to be sticking to one vertical here just because we have pressed for time I'm going to be talking about the Windows auditing part and Sid will be talking about the other parameters that we have to audit so let's get started with our first auditing criterias the theme of my session is going to be key Windows event IDs to track right so let's get started here disclaimer so I am not going to be discussing about the common use cases that you'd be seeing in sim solutions or sim installations that you have in your office now what I've done is over the over these couple of years or let's say 2018 to be more specific I've had this opportunity of interacting with administrators so I get to know some of the not-so-common cases that the administrators face with regards to Windows auditing I've actually consolidated all of them for you so if you do not have the cases that I'm going to be discussing about in the next few slides please make use of this information and feed this information to your existing sim solution be it from any vendor I think this is going to be of great help to administrators who are trying to actually improve the efficiency all right so feeding your sim solution as many indicators of compromise as possible is the only way by which we can learn from an existing attack and improvise okay condition number one you can maybe call it let's say stage one of an attack kill chain okay I'm not going to be talking about the common ways by which you can compromise a credential let's say by brute-forcing it by rainbow table attacks or by let's say using any other form of common attack patterns I'm going to be talking about password spraying a different kind of password spring now if I try to actually attack a credential okay now the target for my attack will be some of the common accounts in Active Directory I'm not quite sure whether you have an account by the name of John Smith in your Active Directory organization but I am 100% sure that any Active Directory installation out there in the world will have an account by the name of administrator right and you will have few sensitive admin accounts too so what I would request you to do is please get the list of such sensitive admin accounts they can be a list of 10 a list of 20 or 30 admin accounts they can be even application admin accounts right now get the list of 10 or 20 or 30 accounts depending on the size of your organization and I want you to look out for the event ID 4 6 2 5 and even tidy 5 2 9 or 6 7 5 I mean by the way the the slide deck will be shared with you so you need not take a note of the event IDs that you're seeing on the screen right now all this will be sent sent to you email to you in a day or two so the event ID 4 6 2 5 tells you whether there's any kind of failed logon activity for your user accounts and our target accounts are going to be sensitive admin accounts and if 4 6 2 5 is recorded by let's say some of your sensitive admin accounts and all of them happens in less than five minutes then it could be a possible user password spraying attack right this is one condition that I want you to track so have a look at your read information from your security logs have a look at 4 6 2 5 and our target is going to be your sensitive accounts in Active Directory this is one thing that I wanted to share with you or I can call this stage one of an attack kill chain that's very interesting within especially because I think a lot of people attending today are probably tracking logon events in your organization for various IT audits or for various purposes but probably are not customizing and tracking some of these more unique cases where you have as an administrator have to sort of add these criteria to your sim solutions right would you be able to tell me a case where something that is so obvious but happens to be of one of the most overlooked security events in Active Directory based on what you've seen in your experience oh yes that's exactly my second case that I was about to discuss now one thing that I've been observing from my interaction with admins is all of them have complex security cases already keyed in or built into their sim solution and they receive real-time alerts but they tend to overlook the basics now with regards to Active Directory when I say overlooking the basic auditing criteria is not tracking or not auditing your top security groups in Active Directory now just think of a scenario now every Active Directory installation out there has at the top most group in Active Directory let's say the enterprise admins if I add a helpless technician okay beat through direct group membership modification or through nested group membership if I add a user by mistake to the enterprise admins group and if you're not tracking who's being added to the group or who's being removed from the group and if that helpless technician turns to be a rogue insider would that be of a concern for you yes of course right so this is one thing that I would like to emphasize take a list of get the list of top groups in Active Directory can be common groups it can be the admin groups that you have created you can even create application admin groups that are tied to business applications in your infrastructure now watch out for event IDs 4732 2856 632 and 636 the group can be of any scope it can be local it can be a universal or can be a global global group but please watch out for these event IDs because every time an inappropriate user is added to a top level security group in Active Directory by the way those top level groups or members of those top level groups can make or break Active Directory they are basically the keys to your kingdom so you should be watching out for who's being added or who's being removed from those groups in real time because if those groups are left unmonitored or unaudited that becomes a bit of a problem so this is one case that I feel like at least some of the admins tend to overlook alright so the next case that I would like to discuss or you can maybe call it stage 3 of an attack kill chain is new service installation I mean there are various cases or security cases that you can write for a lateral movement for detecting lateral movement now one indicator of compromise of a lateral movement is installation of new service accounts I'm not saying that whenever you see a new service it's a threat no I'm not saying that all I all I'm trying to say is what if you have a new service on your workstation even worse what if you have a new service in your server and you have no changes in plan right a change of plan was not in in place and you have a new service account now attackers when they compromise an account be it a user account or an admin account wouldn't be using that account to actually laterally move across your network it doesn't make sense because if they are if the account is trapped in one server or the other then the chances are the account might get disabled so what I would do as an attacker is when I get into an organization or compromise an account I would try to create a relay account and use that relay account to laterally move across the network so even if the relay account gets compromised I still have the keys to your kingdom I can maybe create another relay account alright so that's where that's why I want you to watch out for new service installation and the event ID pertaining to new service installation is 4697 from the security logs of your event viewer now if you see 4697 happening in your workstation or even worse in one of your confidential servers chances are it could be a sign or a possible indicator of compromise keeping in mind our stage three of the attack kill chain which is lateral movement so this is one thing that I wanted to share with you signs of lateral movement so those are some interesting security auditing cases cases from Vivint especially because you're able to track an attack at three different parts in the kill chain right right from a credential compromise to to the lateral movement right so these are important indicators related to your Windows security log and these are all important activities important activities that we need to track right right from credential compromise to escalation of privileges to lateral movement so these are good security auditing cases now Vivint can you give me a case where security auditing the auditing of the log is important both from a security point of view as well has has some administrative benefits okay I'm not being overconfident here but I'm pretty sure that 99.9 percentage of all active directory installation out there in the globe no matter of what size they belong to have this common problem which is account lockouts now one way of dealing with account lockout is okay a user's account gets locked out and the user raises a ticket or gives you a call it's going to be a call most of the time so you receive a call and then you verify the user's identity through maybe security questions and then you unlock the user's account that's fine now what if the same user gives you a call in exactly two minutes or three minutes or five minutes as saying that the account is locked out again all right this is now in the lines of security as well as an administration issue too so the point that I'm trying to drive here is whenever there is an account lockout it is very important that we understand the source of the lockout okay the event ID from the security log that's going to give you the source of the lockout is 4740 which basically reveals the source machine that is initiating the lockout right and you will have to correlate 4740 with 4625 which is the local login failure event so when you bring these two events together you will be able to pinpoint the exact source of a lockout now imagine this okay a user calling you saying that the account is locked out and you able to run a report and that report correlates these two event IDs that I just mentioned which is 4740 and 4625 and it gives you nine or eight possible sources where the account could be configured and when there is a hit in any of those sources you get to know the exact source of the lockout and if there are more than one sources that is actually causing the lockout it could be maybe a stale credential of that user account not being updated in one of those sources right so it's very important that we understand the source of the lockout so this is going to be beneficial not only from a general administration standpoint but also this is more for in the lines of security too all right so this is something related to security at the same time related to general administration of Active Directory now the next case that I'm going to be discussing about or perhaps the last case of my security tips is not exactly related to the security logs of the event viewer in Windows but it is more related to the Windows boxes okay why Windows boxes now every Windows box out there in the world at least the sensitive Windows boxes be it a workstation or a server will have an instance of antivirus running on them okay now if I ask you a question how many of you trust antivirus softwares I'd be surprised if I see one hand up because the age of antivirus is let's say five years ago or ten years ago the era of antivirus is slowly fading and you have newer technologies taking up or advancing with regards to antivirus but please do not overlook your antivirus logs I'm not saying that if you feed your antivirus logs to your log management system or to your sim system you'd be able to detect new threats or new attacks no I'm not saying that okay the goal of this specific case why do I want you to feed your antivirus log to the sim solution is to detect stupidity right yes you heard me right to detect stupidity stupidity in the part of the attacker so let's let's talk an example here if I am an attacker right and if I actually create a payload and I try to deploy the payload in your organization in the form of let's say a phishing email or a fish or let's say any form of phishing entity and if I actually deploy actually deploy the payload in your environment without testing the same the payload in your environment without testing the same against the antivirus setup that I have in my lab, chances are your antivirus detects the presence of the malicious entity in your network and if you are actually feeding your AV logs to your sim solution then your sim solution alerts you in real time about the presence of a malicious entity in the AV logs. Now I'm least bothered whether you clean the antivirus or the presence of the threat in the server or not. So let's say you get this notification from your sim solution saying that presence of a virus detected in one of your confidential boxes. The question, the most important question that I want you to ask to your event handling team or incident handling team is how did the virus get to the server? What is the track? It is very important to actually get to the source of this virus. Take it back to the source. Now when you actually trace it back to its source, it will lead you to a malicious IP or it would lead you to a malicious extension or a malicious port. Now all those are useful information. You can very well use those information, categorize them as blacklisted so that next time you have an approach from the same source which is blacklisted, you are notified and you know how to mitigate it. So this is one case that I would like to stress. Please feed your AV logs to your sim solution. It might seem a bit lame but trust me there are chances that it could detect stupidity from an attacker. So that's about my case here but there are certain other entities or certain other components in the network that are not just Windows. You have other platforms like Linux, Unix and then you have your firewalls, you have your applications. Now what about the security auditing cases for all of them? Sid is now going to take you through all those security cases and please make use of these security cases because whenever you actually feed or equip your existing sim solution with more indicators of compromise, you actually improve the efficiency of the sim solution. That's the whole idea. Over to you Sid. Thank you Vaman. So as part of working with ManageEngine's sim solution Log360, I've seen a fair bit of environments of our customers and prospects and as you probably guessed everyone's environment goes beyond just their Active Directory. It's connected and you've got probably other servers, your Linux and Unix servers, you've got your databases, maybe file servers, web servers, you've got a whole bunch of network devices, you've probably deployed security tools such as threat solutions, DLPs, vulnerability scanners and you've got, like we discussed, you've got cloud applications out there like your Azure, AWS, Office 365 and the like. So really what I'm trying to say is that you want to bring in information from all of these different sources just as you would have done for your Active Directory. Active Directory is a great point for any organization starting to implement a security monitoring plan because that covers the basics and that ensures that you're protected for a whole bunch of attacks, especially those stemming from an internal malicious actor. But we want to build on that and make sure that we are proactive in knowing exactly what is going on in the rest of our network and knowing and having the visibility into activities going on in the rest of our network. So I just wanted to use this as an opportunity to tell you that start off, in case you've not yet implemented a solid security monitoring plan in your network, start off with Active Directory and then try to do the same thing that you have implemented in Active Directory for the rest of the critical sources in your network. It basically boils down to three simple steps. You first want to discover the assets. You want to know exactly what you're dealing with in your environment. Maybe you have four domain controllers, two SQL servers, you've got your web server, multiple firewalls, routers, switches. You want to identify and discover what you have and then send logs from all of these different devices to your SIEM solution. And then using your SIEM solution, you can schedule reports. You can schedule reports to periodically review security events, to periodically keep a check on exactly what's happening in your network. And I strongly recommend doing this on a daily basis. You want your reviewing to be done every 24 hours. And if you have to comply with a lot of standards such as the PCI DSS, you would have to be doing this as part of the compliance audits. Think about what we saw in the start of the talk show. We said that 68% of breaches were discovered months after they happened. Now if you have a daily monitoring process in place, a process where you schedule reports and you see the activities in your network every 24 hours, you will detect a breach with a maximum delay of a few hours. If something bad happened in the middle of the night, you probably, at worst case scenario, you would detect it in the next day morning's scheduled report. Now you also want to go one step beyond this and enable real-time alerting so that you can detect misuse as and when it happens. Reports are very important. You want to be able to do that periodic reviewing and catch a lot of different flags, a lot of different security incidents. But at the same time, you want to have real-time alerting in place so that you can detect certain things such as ransomware as soon as it launches in your environment. So I'm going to give you a few simple cases here. Vivian gave you some good tips on what you can watch out for in your active directory and what events to track from your Windows security log. I'm just going to build on that and give you a few general cases on what else you can look out for not just in your Windows environment but in the rest of your network as well. So the first thing that I want to talk about is system events and Vivian already touched upon this while speaking on the case of lateral movement in an attack. You want to detect any attack inevitably will trigger some system event along the way. That makes sense. If ransomware was going to be launched on a machine, it first has to install itself. Some process has to start. Maybe a machine would get shut down, maybe it would restart, maybe it malfunctions and it restarts multiple times over like 10 or 15 minutes. Bottom line is that system events happen as part of attacks so you must be tracking important things such as the installation of services, installation of software on your servers if any of your servers are being shut down or restarted. Because think about this, if you have a critical server in your environment, how often do you go and start a new service on it? You probably never do it or it's certainly not something that you would be doing on a daily basis. So use all of these. These are things that we all know and we must translate our knowledge into setting up alerts for indicators of compromise. So take this as point number one. Now point number two is what we are all very concerned about, our data. Data accesses and modifications. Make sure you are tracking this. At a given point you need to know the four vital W's of who's accessing your data, which piece of data is being accessed, when was the data access made, and if modified what was the modified value. This is a very fundamental concept in auditing and you've got a whole bunch of I think the textbooks and material on the internet will talk about staying on top of the four vital W's. But this is something that is easier said than done and you really need to be, you need to leverage technology such as file integrity monitoring and column integrity monitoring to ensure that the data in your file servers and databases is secure and the integrity is maintained. For this you need to track, you need to track who's accessing, who's modifying, and maintain the entire audit trail. You need to have a proper report for all the data accesses and modifications made, especially when it comes to sensitive data in your organization. And in this way you can set up alerts to detect unauthorized access. For example if there's financial data that only the CEO and some of the C-level members are supposed to access, you can have an alert set up for if anyone else accesses it. Because maybe they escalated privileges and they were able to access but that user ID was not ever supposed to access that folder on your file server. Just something to think about in terms of alerting as well. And then you've got web server activity. This is something that we strongly recommend to our customers because this is often the entry point of attacks. Web servers are front-end, they're facing your customers and this is unfortunately an easy access point for a lot of attackers. So this is something that we strongly recommend to Lock360 customers that, hey, make sure that on a regular basis you are reviewing your site visitors, the requests that your web server is receiving, files being uploaded and downloaded because some of them could be malicious, HTTP error codes. Because for example if you have a denial-of-service attack, you might see that there's a huge spike in certain HTTP error codes. You should also track known attack patterns, SQL injection, cross-site scripting, because we already know how these attacks happen and exactly what kinds of queries get executed. So make sure your SIEM solution has the rules needed to track these common attacks. Because this way you are able to tick off several checkboxes when it comes to attacks. Like known attack patterns itself, like brute force patterns and things like that, make sure you track those. And then there's firewall traffic. At a given point you need to know whether the traffic in your network, the traffic passing through your network is healthy or malicious. So you need to know, is your firewall, which are the connections that it has allowed and which are the connections has it blocked. Because is it blocking an IP address continuously? Because that is an early indicator of a potential compromise. Because if someone is trying to breach your network and your firewall keeps blocking it, you already know that someone is up to no good. And you can maybe permanently block that IP address. So how you go about this is really to track your traffic based on the source, where it's coming from, destination, where it's going to, and the protocol. Because this is very important to create these baselines of normal security activity in your organization so that you know what on a given day, what kind of traffic passes through your network. So if you suddenly see that there is a massive spike in SSH traffic, you know that there could be a compromised server in your network. If you see that there's suddenly a huge spike in the traffic that is outgoing from your network, again, you know that this could mean that there is a compromised host that is sending information. So the reason why we stress upon firewall traffic of all things is because this is a good way to detect attacks at an early stage. And sometimes because firewalls are so important, you might see that in certain attacks, we've seen cases where firewall rules have been modified to allow access to an IP address that is supposed to be blocked. So really anything associated with your firewall is something that you want to track because even in a worst case scenario where you have a breach and you want to backtrack the attack, the data of network traffic that is passed through your firewalls is going to be very important. If you find that a database was compromised, you need to backtrack and see who did the compromise. Where did that IP address come from? When did your firewall allow the traffic? And you want to perform these search operations and investigate web server activity and all related resources to understand exactly what happened in the event of a breach. So this is something that's very important because logs at the end of the day are what's going to help you not only to detect an attack that is happening, but also after an attack happens, you need to revisit your logs to investigate. And that brings me to my final point that I want to talk about, which is tracking logging policy changes. We know how important our logs are. Like I said, logs are what help us catch attackers. And attackers know that and they try to change your logging policies and they try to shut down your logging services so that they don't get caught when they carry out an attack. So we have to be proactive and also detect when someone changes the logging policies. when someone changes the logging policies, right? Who would go and shut down your syslog service? Only someone who's up to no good, right? Because why would they shut down your syslog service or event log service? So sometimes you've collected the logs and people try to tamper with the logs to cover their tracks, right? You've collected logs that say that this user ID logged on and did this file access, and maybe that malicious actor goes and changes or tampers the logs, which itself is an indicator of compromise, right? If someone is trying to tamper with these logs, you know that they're up to no good. So I just wanted to finish the cases that I had in mind with the most fundamental thing of tracking logging policy changes, because this is what SIEM is all about. Logs are so important that you want to make sure that you're receiving logs, you're receiving reliable, and the logs once collected are reliable for investigations. So anyone trying to tamper with these logs or logging policies, you must catch that then and there. Awesome, awesome. Thank you very much, Sid. So you've covered some of the non-Windows cases or the predominant cases that you should be thinking about when you actually deploy a SIEM solution. And again, these are customized cases and not your regular cases. Now, I want to actually switch tracks and ask you something else. Now, if you've been traveling around the world, you've been interacting with administrators, all kinds of IT folks, and you've also deployed SIEM solutions in organization in person. So over these couple of years, I mean, from your observation, do you have something to share with our audience, something like common information security mistakes that you see in organizations? Oh, yes, you have a slide on that. So over to you, Sid. So let's talk about certain things that a lot of organizations, and you'd be surprised that some of these are large enterprises with big security teams, there are certain IT security mistakes that we've seen while interacting with our customers. And with regards to SIEM solutions, one of the biggest issues is that people configure SIEM solutions and it ends up being too noisy or too quiet, right? True. Sorry to interrupt, that's very true. So even I have seen cases where people actually enable everything for auditing, or they don't enable auditing at all. They just go with the default rules. They don't customize their auditing criterias. I think introducing machine learning or probably user behavior analytics to your SIEM solution will help you strike the right balance of being too noisy or being too quiet. Absolutely. So this is really to say that we have to leverage these advancements that we have in technologies such as machine learning and incorporate these technologies in our security tools so that we can combat the advanced threats that there are in today's world. Exactly, yeah. So that's one mistake that we've seen, too noisy or too quiet. Second thing is that I've noticed a lot of the times organizations end up buying extremely expensive security products to solve very simple problems. Oh yes, oh yes, yeah. And they also, and sometimes what happens is, for example, all you might want is a report for group membership change in Active Directory, and you don't need a $100,000 SIEM solution to achieve that, right? It's really to say that often you might find that there are simpler, cost-effective tools in the market that can do your trick, and you don't have to have a traditional approach of saying that we would buy only a leader in the market So the point that you're trying to drive is when something is costing you less on your pocket, it doesn't mean it's less effective. Absolutely, absolutely. And this is also to reiterate that you want to consider the cost of training your security team while buying a product, and also the cost of implementation, maintenance, and support. Because often, if you buy a very fancy security product and you suddenly realize that you need 10 months to just train your security teams so that they can start seeing results, I don't think that's gonna help a first-time buyer. So if you're a first-time buyer of a SIEM solution and you're immediately looking at a tool that requires six to 10 months of deployment and training, I think, I personally don't think that it would be worth pursuing such a solution. I mean, that makes sense. Whatever you've said makes sense, yeah. And then I think we've got, we see sometimes that some of our customers and prospects focus heavily on preventive measures and often neglect detection and response measures. I'm not saying that, so antivirus, firewalls, patching mechanisms, these are all very important and they're always gonna be important. But the state of security today is that you can't just focus on preventive measures because threats are inevitably going to beat the preventive solutions, and you need mechanisms in place to detect when things go wrong. So when things go bad, you need your SIEM solutions and your detection tools to really tell you that, hey, your first level of defense, your preventive solutions have failed, so now you can mitigate the attack before it becomes too late. And then here's another interesting thing. We see a lot of the time out-of-the-box support and pre-built support is something that's obviously desirable and all of us like it because it makes our jobs easier, but sometimes I think organizations go, take it too far, and they have a fancy tool sitting there in their security operation center and it's just running on autopilot, right? It's not doing anything fancy beyond what it can. I completely agree because I've seen instances of SIEM solutions where you download the solution, you install it, you configure it, and then you actually keep it in your shelf until an auditor steps into your organization and then asks for a few compliance-related reports. Or there's an attack, you just go to the application or call the vendor asking for certain reports that you need to be submitting to your auditors. So yes, I mean, rephrasing whatever you said, never allow your tool to run on autopilot mode. Always give room for customization. That's the point that we're trying to drive all throughout this. And the cases that you and I have shared allow administrators to customize their existing SIEM solution. It's not something that comes out of the box. When you add more rules, you give your tool greater efficiency. Absolutely, so I think the real takeaway is that you want to leverage out-of-the-box and pre-built rules for the basic things, but you really, to get full benefit out of your deployment, you need to look at cases such as the ones we have discussed today, and sort of incorporate those rules into your solution for getting maximum effect. And this brings me also to the final point that I've seen, which is a lot of the security teams deploy multiple technologies from multiple vendors, and all of these applications work in silos in their network. A lot of the time, security teams almost panic and they buy tools to meet their IT budgets, and they have tools from a bunch of different vendors that are not working well together. And today, when you want to accelerate the threat detection and response, you need your tools to really talk with each other and pass on information so that you have a unified view of what is going on in your network, and you can really leverage all of these tools to the fullest. So what I recommend is that you need to have a clear understanding of your objectives and exactly what is your priority for 2019, right? So if your priority for 2019 is, like for a lot of us, it's gonna be data security and incident detection and response, we should make sure that the tools that we are procuring are aligning with our objectives, and are not just random purchases, just to tick different requirements in a compliance regulation. That's very important, yep. So, Viven, can you just talk us, we've looked at a few mistakes. Now, if people are looking at either evaluating tools or revamping their existing tools, can you suggest, talk about some questions that they can ask to their, either their existing vendor or a prospective vendor before evaluating a SIM solution? Absolutely, I even have a checklist for that, and the slide that you're seeing on the screen is that checklist. So if you are trying to actually move to another vendor, or if you're trying to actually evaluate a new vendor, so what I would request you to do is have this checklist in place, because this is quite important, right? The first point in my checklist is, ask your vendor whether the SIM solution that you're about to deploy in your organization supports for agent-based and agent-less log collection, because we have seen in, you know, more often than not, there are areas in your network where you'll have to receive logs from, but you'll want to be able to do so without an agent. So your SIM solution should be able to support for agent-based and agent-less log collection. Now, that takes me to step two, right? Once after the log collection is completed, step two is, how good is the processing rate of the SIM solution? Now, is it able to process 10,000 logs per second, 20,000 logs per second? Because we are not talking about logs from just one source, we're not just talking about SQL, we're not just talking about Windows, we are talking about at least 100 to, you know, 100 to 250 different sources in a medium-sized organization and large size, the numbers are just in hundreds. So the log processing rate should also be considered when you actually go in for a SIM deployment. And third point, now, certain regulations in certain parts of the globe, for example, we have PCI DSS in the US and you have certain other regulations in Europe, which want you to look at log data on a daily basis. This doesn't mean that you'll have to go through every log on a daily basis, it's just a matter of integrity. So is your SIM solution, the solution that you have deployed, is it looking at log data on a daily basis? Because even if you're not, your SIM solution is actually tracking or looking for log integrity that's needed. Now, the fourth point is any SIM solution out there in the market will be bombarded with tons of logs over a period of, let's say, two years or three years, or depending on the log rate. So as the size of logs grow in an organization, the ability to perform a fast and targeted searches will be of prime importance. So any SIM solution that you're about to deploy should give you the ability to search through or sift through logs in a fast and targeted manner. That's very important. Now, the most important of the entire checklist that you have in your screen is can you set alerts on anything in the logs? Because every organization out there has at least one application which is homegrown, which means they're not out there in the market, they have built it in-house, and that application has logs, and those logs have a story to tell. Now, is your SIM solution adaptable or flexible enough to process those custom logs? And does your SIM solution give you the ability to set alerts on the logs that you have managed to retrieve from that custom application? That's very important. The ability to set alerts on anything or set custom alerts, to be precise. The last point of my slide deck is how secure is the log storage? Because at the end of the day, if someone is actually tampering with your logs that you've managed to gather from heterogeneous sources, your security is at risk, right? So you'll have to make sure that the logs are stored and they are tamper-proof, all right? To be more precise, they should be encrypted, they should be hashed, and timestamped. So all these are the checklists that you'll have to have in mind whenever you are actually trying to evaluate a SIM solution. And I'd like to quote Benjamin Franklin here because I'm nearing the end of my session. So as Benjamin Franklin said, an ounce of prevention is worth a pound of cure. So you'll have to make sure that you are prepared enough so that whenever you are struck by a lightning in terms of an attack, you recover from it, you learn from it, and then you move forward. So over to you, Sid. So yeah, thank you so much, Revin. This is just finishing up today's talk show. We didn't want to talk too much about ManageEngine's offering because we really wanted this to be a knowledge-sharing session where we talk about different cases that you could take back irrespective of whether you're evaluating or using ManageEngine. But I just wanted to let you know that we've got a comprehensive SIM solution called Log360, which is an integration of two of our tools, EventLogAnalyzer, which is a robust log management tool, and ADAuditPlus, which is a real-time Active Directory change auditing solution. So we've integrated these two tools. EventLogAnalyzer helps you track and mitigate external attacks, and ADAuditPlus gives you an in-depth user context an in-depth user context and sort of ensures that you can stay on top of internal threats and sort of help, and. as well. So if you are evaluating Log360, keep in mind what Vivian just said on the previous slide in terms of questions to ask your vendor. So we'll be happy to answer these questions either on the live chat or on support. This brings me to the end of today's talk show. It's probably, we've overshot by about five to ten minutes because we're doing this for the first time and it's been a really great experience for us to interact with all of you via this medium. And we'd also like to know your feedback for the session in terms of what you liked or what you felt could be better so that we could take these suggestions forward and host more such sessions in the future. And I'm also open here for live Q&A for another, at least another two to three minutes. So if you have any questions, do ask us on the live chat and we'll try to answer at least one or two questions live for the benefit of the entire audience. And I think we've got a couple of questions already that we thought we would answer while waiting for more questions. It looks like we already have a question here. Oh, in fact, a few questions. We'll just pick one. All right. So someone wants us to talk about honeypots. Okay, there are various kinds of honeypots. Now that I've been talking about Windows security auditing. So one honeypot related to Windows would be, I mean, this is not going to again disrupt your production. So you can very well go ahead and do it right now. This could be quite interesting. Now, any active directory installation out there has this account called the administrator. All right. Now, if you're trying to figure out which is the administrator, the SID of that account, the last three digits ends with 500. All right. So pick the administrator account. I want you to rename the administrator account. Okay. Don't get scared. It's not that harmful as you think. Go ahead and rename the administrator account maybe to John Smith or James Bond. Now, after renaming the administrator account, I want you to create another account in the name of administrator and I want you to track for logon failures for that specific account. All right. So every time a user is trying to authenticate against your DC with a common well-known account as administrator, it could mean something to you. If it's an insider, walk to the desk and have a word with them and get things sorted. If it's an external IP or port that's trying to establish a communication against your DC, then it's trying to blacklist that port and IP address. So that's one honeypot that I wanted to share, renaming the administrator and then tracking for logon failures for the dummy administrator account that you created. You want to share something related to maybe a non-Windows criteria? Well, we've got a few more questions coming in. There's this one question on what are the events that I should track on my SQL server? Well, I think it's obviously not a straightforward answer, but you really want to focus on three different areas. One being your DDL and DML auditing. You want to really track who is creating tables, who's inserting values into tables and that sort of thing. Very similar to what you would track on your file servers. You want to make sure that you're on top of your data manipulation language and data definition language auditing. You want to make sure that you're auditing database server activities. And the same idea that we saw in Active Directory of privilege escalations, you want to make sure that your database roles, your admin roles are being assigned properly and no end user is having the admin privileges. And the third thing that I can think about is the known attack patterns that we saw. If it's something like a SQL injection, you want to make sure that you have alerting and reporting rules to detect these known attack patterns. So we'd like to take more questions such as these on the live chat. We'll try to answer them. We'll type out and send you personalized answers. But apart from that, if you have any more questions, do email us law360-support at manageengine.com. Unfortunately, we've just about exhausted our one hour limit for today's talk show. So we won't be able to answer your questions out loud. But do keep the questions coming if you have any on the live chat and we'll answer them for another few minutes. Apart from that, I just wanted to let you know that we'll send you the recording of today's session along with the slide deck, some other useful relevant material in a couple of days. So we'll have all this sent to you. So just stay tuned and wait for our email. We'll also be sending you a complimentary 45 day license of Law360. So if any of you are interested in evaluating the solution, that would be a good starting point to kickstart your evaluation. So as always, keep in touch with us via email. We'll drop in an email within a couple of days and you can get in touch after that as well. Thank you so much for joining us today. I hope today's session was enlightening and gave you insights that you can actually take back and implement in your environment. So thank you so much for joining us and goodbye from me and Viven as well. All right, see you. Goodbye.
