International Business Machines Corporation (IBM) Earnings Call Transcript & Summary

Hi, everyone. Thanks for joining today. I'm Connor Costello, your IBM security facilitator for today's webinar, Detect Database Login Failures with Guardium. In this webinar, you will hear from one of our Guardium experts, Franklin Almonte, one of the course developers for the IBM Security Learning Academy. Before we get started, I want to go over a few housekeeping items in your audience console. There's a few different widgets that you can see on your screen. If you have a question, we have multiple experts standing by to help answer those questions, and we'll be taking Q&A in the middle of the presentation and also at the end. [Operator Instructions] We love your feedback. We always try to improve these webinars and make them better. So please use the survey widget at the bottom, or you can wait till the end to answer the survey. We really do appreciate the feedback. The resource widget on the right contains an important link to take note of. You can join the community there. [Operator Instructions] Will all of that out of the way, let's get on to the presentation. I'll hand things over to Franklin to get us going.

Thanks, Connor. Hello. And as Connor mentioned, my name is Franklin Almonte with the IBM Security Learning Academy. I'd like to welcome you today to the Detect Database Login Failures with Guardium webinar. In this relatively short session, we explore how you can use Guardium to detect database login failures across your deployment. We cover some concepts around this topic and go through a quick demo of this functionality by showcasing one of our most popular Guardium courses, Detect Database Login Failures with Guardium, the same as the name of the webinar. Let's go ahead and get started. Let's quickly review what a database failure is. Simply put, a database login failure occurs when any attempt to access the database is made with invalid credentials. This may be an invalid username, bad password or a combination of both. There are 3 ways in which this might occur. A user attempts to log in with invalid credentials. This guy doesn't seem too happy here and will probably indulge in an adult beverage that he has on his desk. An application user might access the database via an application server with invalid credentials. Or the application itself may attempt to access the database within valid credentials for things like batch processing or back-end optimization tasks. Database login failures might be indicative of normal activity. It's very common for a user to occasionally forget his or her password. The application itself might be misconfigured or there may be development work and associated testing being done, or more nefarious reasons like a bad actor trying to guess the password using brute force or dictionary-style attacks. Guardium processes a login failure like it processes most other database activity, which means that you need to set up a Guardium policy with a corresponding rule, which allows Guardium to detect that type of behavior. You need to have an S-TAP/K-TAP combo, an A-TAP or a DB exit on the database server. If you're using cloud databases, you would use an E-TAP or external TAP. As a tip, you can also use the E-TAP to monitor local databases as well. The data is captured and then sent to the Guardium collector, which detects the condition using the policy rule and forwards that to configured receivers and certain prebuilt reports. Let's take a look at how you can quickly get started. You can deploy the applicable agent based on your business requirement. You might already have this part complete. You can install an access policy with an exception rule that detects failed login exceptions. You might already have a policy installed, which means that you can simply install the rule within the installed policy. And then lastly, you would configure any receivers or use predefined or custom reports to view the alerts. You might also have receivers already configured. If you kind of step back and think about it, since it's likely that an existing deployment will have deployed agents, installed policies and receivers, implementing the functionality is really as easy as creating a single rule within an existing policy and reinstalling the policy. Really just a couple of minutes to implement but a huge value in assisting with your security posture. While not covered in the upcoming demo, I want to briefly discuss how you can combine this rule with rule actions that can either terminate the session or quarantine the user for a period of time. These are useful because it allows Guardium to not only monitor for failed database logins but actually prevent unauthorized access to the database. That said, in this use case, the terminate action might not be of much value as the database user is unable to log in to begin with. However, the quarantine action does have value in this use case. If you recall, the occasional failed login might be normal. Therefore, you might not have Guardium take this action right away. You can set it up [ such that your policy rule will only take this action ] after a certain number of failed login [ attempts within a certain time period. Let's take a quick look at an example rule that would help to reduce false positives while still preventing unauthorized access to the database. ] For session-level criteria, [ the period character in the Db user field means that it must be the same user logging in 3 times with wrong credentials to generate the alert. This means that when 3 failed ] logins come from 3 different users, the alert is not generated. For SQL criteria, you monitor for an exception type of login failed. And the other criteria section is where you control the sensitivity of the rule. Here it is configured to trigger if there are more than 5 failed attempts within a 1-minute period and also takes the additional step of quarantining the user for 24 hours. In production environment, the quarantine period may be much longer to allow for a thorough investigation. Let's take a look at a visual of how this will flow. You have your database user which attempts to log into the database with invalid credentials. The database generates an exception for the failed login and denies the user access. This behavior then continues at least 5 times within a 1-minute period. The Guardium collector detects this activity and quarantines a user for 24 hours, which essentially bans the user from even attempting a database login. Before we jump over to the demo to take a look at this, let me pause here and ask if there's any questions. There's also going to be an opportunity to ask questions at the end of the demo and webinar.

Yes. Franklin, we did have a question come in. It is, "I'm still learning about policies and wondering if this functionality comes out of the box."

That is a great question. And the answer -- the short answer to that is absolutely yes. Let me show you something here real quick, if I may, in my Guardium environment. Starting at Guardium version, I want to say, 11 and continuing with 11.1 and 11.2 now, we've added a lot more predefined, out-of-the-box policies that will help you get started quickly. These are policies that have been created through a collaborative process with support, R&D and development. And we have one here that brings this functionality out of the box. Here, you can see my installed policy. Specifically, the basic security policy is the one that I'm referring to here. This policy actually is -- allows you to start monitoring SQL traffic right out of the box. It uses things like predefined groups of privileged users, privileged commands and error codes for some of the most common use cases. The basic monitoring policy provides rules that address common data access and attack patterns. Granted it's not a comprehensive audit policy, but it does provide a secure foundation while you develop database [ activity monitoring policies that are specific to your environment and needs. So let's just take a look at it real quick. It has 12 ] rules associated with it. As you can see, it's a number of rules looking at different types of access behavior and attack patterns. But if we filter just for failed, we can see here that it has the exact rule that I showed a few slides back. I've configured exactly the same failed login, 5 failed attempts within a 1-minute period for the same user. So that's what I wanted to show with that. Does that answer the question, [ Teri ]?

We'll keep an eye on the chat if they've got any follow-up questions, but I think you're good, Franklin. Thank you.

Okay. Great. Great question. So let's just jump right back and let's talk about the demo. So let's virtually gather around and take a look at the demonstration of this functionality. As mentioned in the introduction, the demo uses the Security Learning Academy course Detect Database Login Failures, which happens to be one of our most popular Guardium courses. This is a hands-on lab that you can take as many times as you wish. Before we get started, let's set the stage by reviewing the components that make up this lab. The database server runs RHEL, or Red Hat Enterprise Linux, 6.5 for its operating system software and Db2 10.5 for its database software. A Guardium standalone collector with 10.5 software stack is used. And with that, let's go ahead and get started. Give it a sec here. Make sure we get that refresh in for everybody. All right, looks like we got it. All right. So what we're going to do is just essentially log into the Guardium appliance as lab admin user. Takes us to the welcome screen for 10.5. We're going to go ahead and navigate to Setup, Tools and Views and Policy Builder for Data -- excuse me, Policy Installation so that we can see what the currently installed policy is. So in this example here, the currently installed policy is the Allow-All policy. This is essentially a dummy policy with no rules that's in place. We're going to go ahead and create a policy of our own, which will become the currently installed policy. Just a quick note before we do that, the Allow-All policy, as you can see, is a not -- is not a selective policy. So that essentially means that the S-TAP agent running on the database server is going to send all the traffic captured to the collector. Of course, in a production environment, this is not ideal because it may very well overload the network with traffic and you may be sending a bunch of traffic that you don't really need to be capturing to begin with. As a general rule, Allow-All should be used in maybe dev test environments as you're trying to assess the type of data that Guardium is capturing and/or for no-traffic troubleshooting conditions, where you're trying to rule out potentially a bad policy configuration as the culprit. So let's go ahead and start building that policy. So we're going to go back to Setup, and we're going to go to Policy Builder for Data. The Policy Finder screen opens up here. We're going to go ahead and click the new icon to create a new policy. We're going to call this guy Failed the Login Policy. Just a quick tip, the hyphen that I put there before the policy name, that just keeps the policy at the top of the list when you see all your policies just to kind of make it easier for you to locate it. We're going to go ahead and select a category of access. This category is really an arbitrary label that can be used to group policy violations for reporting purposes essentially. That's really the only function that it has. The access category is actually the default category for each rule, but you can change that according to your criteria. For the purposes of this demo, the other options are going to be left at their defaults. So we're going to go ahead and click on Apply to save the policy. And then we're going to click on Edit Rules so that we can add a rule. So you can see there's no rules currently in the policy. We'll scroll down and we're going to add an exception rule. If you recall from the slides, that's the type of rule that contains the failed login exception. We're going to go ahead and name this rule Failed Login Alert. Just a quick point here. Your rules should be as descriptive as possible as to what they're alerting on because the rule description comes out in your reports. That'll make it very easy for you to identify without digging through the rules what this rule is doing. So after we added the name, we're going to go ahead and set the severity to Medium. Then we're going to scroll down here and find the database user. We're going to add that period. Again, that period in the Db user field means that it must be the same user logging in 3 times with wrong credentials to generate the alert. So again, if 3 different users log in, that's not going to generate the alert. Or 3 different users attempt to log in and fail to log in, it will not generate the alert. Let's continue with the configuration. We're going to scroll down here, and we're going to set the exception type. If you recall, we want to set up Login Failed. And then we're going to set up the minimum count in this scenario of 3 failed logins within a reset interval of 5 minutes. So if the same user attempts to log in 3 times with an invalid password within 5 minutes, it'll trigger this alert. Now the last thing is -- that we need to do is set up an action for this rule. So we'll click on Add Action in the dropdown. We're going to select Alert Per Match. And then for notification, we're going to set up Syslog as the receiver. We'll click Add -- or Apply, excuse me, and you can see the action got added to the rule. Then we'll go ahead and save. Here, you can see the rule within the policy. We can expand it out. Take a look at the details if we needed. You can see that we pretty much have the items that we've configured for the rule. So once we're happy with that, we'll go ahead and click Back. We'll click Back one more time, and this brings us back to the Policy Finder. Note that the policy is already selected and is at the very top because we added a hyphen to the name. We're going to go ahead and install this policy. So we simply select Install and Override. We say Okay. And at this point, the policy is installed but let's go ahead and confirm that. We'll go back to Setup, Policy Installation. And notice now that the installed policy is the Failed Login Policy. So that concludes the first part, which is to set up your policy. Now we have to make sure that it actually -- or validate that it actually works. And to do that, we're going to go ahead and log in to a terminal session and attempt to log into the database with invalid credentials. So we're going to launch a terminal here. This is the database server. We're going to S-U to the Db2 instance owner, and then we're going to execute the Db2 command. And now that we're here, we're going to go ahead and simply attempt to log in with a user named Dan with invalid credentials. Keyed over here, just kind of copied and paste the command, where -- just a standard Db2 Connect command, connect to SAMPLE, which is the database. The user is Dan. And we add the parameter using, and we're going to use the password X, Y and Z. We're going to run this command again. We're going to use a different wrong password, and then we're going to run it one more time. And so at this point, we've attempted the log in 3 times. We did it even within 1-minute period. So what we need to do is validate on the Guardium GUI that it generated an alert. So we're going to go back to the GUI. We're going to go ahead and navigate to reports, Guardium Operational Reports. Scroll down. We're going to find Incident Management. And as you can see here, the alert got generated, gives us applicable details as in client, server, IPs, the user that attempted it and how many times they violated this rule, one time in this case. Now you may be asking yourself, if we tried 3 times, why did this only generate 1 alert? And the answer to that is that only a single alert was generated instead of 3 because the policy is set up to alert 1 time whenever a user fails to log into the database 3 times within a 5-minute period, not that it will generate 3 individual alerts. And with that, that concludes the demo. Pretty straightforward. Pretty easy. But again, as I mentioned earlier, very powerful. So let's switch back over to the presentation. Of course, as this is just one piece to a bigger puzzle in your risk management approach utilizing Guardium, it's natural to want more. So let's take a look at a few courses that complement this webinar. I'd be remiss if I didn't mention the course that we just went through, the demo. It's a great resource to familiarize yourself with the tasks associated with configuring your deployment to detect failed database logins. As previously mentioned, this is a virtual lab, and you can consume this as many times as you want. The other course that I wanted to mention is the Using Guardium to Quarantine Database Access. This is another virtual lab that allows you to set and test quarantine functionality, which we didn't show in this demo, but we talked about a few slides back. The last course I want to mention is the Guardium Policy Strategy and Techniques course. This is a very large and long course that brings together videos, demos and virtual labs that relate to Guardium policies to assist you with related strategy and techniques. You can go through this course sequentially or you can pick and choose topics of your interest. And with that, we are done. Thank you for the privilege of your time and attention, be sure to check out the IBM Security Learning Academy for additional training resources. At this point, I want to open it up and see if there are any further questions relating to what was covered in this session today.

Yes, Franklin, we did have another question come through. "Should controls like quarantine or other types of blocking for this type of activity be set up with Guardium?"

Another great question. A little bit complicated, but let me show you something before I lead into the answering of that question. So let me go back to my environment here. I want to show you a vulnerability assessment. This is a vulnerability assessment that was ran against an Oracle database. Let me just bring this up. This is the very first failure that we get as part of this vulnerability assessment. And this failure is specifically failing because it's saying that the failed login attempts parameter is not set. This is a database control. And in this environment, it's not set. And what this basically does is that it limits the ability of unauthorized users to guess passwords and also alerts the DBA when password guessing has occurred. It'll actually lock the users out. And why I show you this is because this actually is kind of what we just demoed on the Guardium side and how we were able to detect the failed login attempt. I mean in the slide, at least, example that I showed, there's the additional step of quarantining. The reality is, is that these types of things should be done upstream from Guardium ideally. I look at Guardium as kind of for things like controls as being the last resort. And by that, I mean that blocking in general is a nice feature to have in your back pocket again as a last resort and to talk about, but the reality is in conversating (sic) [ conversing ] with my services colleagues is that less than 5% of companies do blocking, and those that have do -- those that do the blocking have very, very specific use cases and they're very mature in their deployments. Think about this. It usually takes a company anywhere from 2 to 3 years to weed through all of their, let's say, less-than-ideal behavior and get executive sponsorship to agree that certain activities should be blocked. In that time, they usually figure out that they can fix the problem in the application, access control or business process. So blocking with Guardium should be reserved for extreme anomalies that the business absolutely agrees can be blocked. It should not be used as an access control mechanism in lieu of other access control mechanisms like IAM database controls, as we're showing in this example with this vulnerability report, or application-level controls. So long answer, but hopefully, that gives a little bit of insight as to whether you should be using blocking types of rules with Guardium, and kind of has you start thinking more about this risk-based approach where some of the things that get surfaced through discovery, classification, vulnerability assessment, entitlements, that some of that information, as relevant, goes upstream to your line of business, your app teams, your network teams, so that they can implement the appropriate controls upstream from Guardium so that these types of scenarios are only implemented or Guardium only takes action when those other upstream items from a control perspective have been exhausted. So long answer but it deserved a little bit of a length to it because it's not as straightforward as a yes or no. So [ Teri ], hopefully, I answered that question. Not sure if there's any follow-ups to that.

Yes. Well, we'll keep an eye and see if there's any follow-on question. We do have another question.

Yes.