Hello and welcome to our cybersecurity dojo for part two of our four-part series intended to guide you in the mastery of security kung fu. My name is Josh Berman. I'm the Product Marketing Manager for SolarWinds Security and Tools Products. I'll be emceeing today's session. For those of you who made it to the first installment of our series, where we covered SIEM solutions at a high level and the challenges businesses face which prompt the need for such solutions, I'd like to welcome you back. Looking at the roster, there are definitely a lot of you out there. So, I hope you find today's topic just as appealing. For those of you who are entirely new to the series, I'd like to welcome you, as well. If you're at all curious about what you missed in our first webcast, I encourage you to travel to go.solarwinds.com/kungfu-webcast-series. There, you can gain access to live recording of our previous session, in addition to being able to register for our future events. So go check it out.
For today's lesson, we'll be building on our previous discussion to highlight the important role firewalls play in network security and how log messages generated from these devices can provide meaningful insights to either thwart a security incident altogether or assist in stopping one in its tracks. That is, assuming you're armed with the right tools to do so. Just as important as it is to collect logs from these devices and other devices on the network, is what you do with the data that you collect. That's where SIEM solutions come in. And we'll cover that amply, of course, in this webinar session. But, I've got to mention we won't stop there. We'll also cover how network change and configuration management solutions also contribute to the cause of providing deeper security and meaning-- what, for many of the companies out there, tends to be the end-all, be-all for their business, which is achieving compliance. So, we'll also cover that, as well.
Before I introduce our security kung fu masters who will be guiding today's lesson, I'd like to address a few items pertaining to the format of today's event. This is particularly important for all the new folks out there. But we'd like to keep the webinar session to as close to 50 minutes as possible. Although we have planned for a Q and A session at the end of the presentation, I encourage you to submit your questions via the Q and A box and we will do our best to address them throughout the presentation. Now, before we dig too far into things, I want to remind you of our very awesome giveaway. For 25 lucky individuals out there, we will be awarding you with our very own security kung fu T-shirt. In order to qualify, you must be in attendance for the entirety of today's event. So stay tuned and enjoy the session.
Noted earlier, this event marks the second installment of our four-part series. This means you have ample opportunity to win a T-shirt at one of our future events. For details regarding our next session, Security Kung Fu - Active Directory Changes, which will take place on March 21st, or any of our subsequent events, for that matter, be sure to visit go.solarwinds.com/kungfu-webcast-series, which is on the screen right now.
Okay, on to the good stuff. So after I introduce our security kung fu masters, we'll discuss a bit about the cybersecurity climate we face today and dig deep into the anatomy of the cyberattack. We'll cover a rather serious concern dubbed 'the detection deficit,' which speaks to the increasing trend where businesses' Mean Time to Detection for security vulnerabilities of all types is actually on the rise, which is certainly cause for concern. From there, we'll cover how firewall logs may possess some, but not all the answers to combating this trend, along with help from two classes of security solutions. Those, we feel, are very important, are fundamental, in fact, for meeting that important goal of being what we call security kung fu conscious. We even show you solutions in action demoing the capabilities of SolarWinds products for this important cause. Lastly, we'll open the floor to a Q and A session and qualify our T-shirt giveaway contestants and, of course, conclude the session.
So, today I'd like to introduce Jamie Hynds. Jamie is actually relatively new to the role but he's our Senior Product Marketing Manager for Security Products at SolarWinds. As product manager for SolarWinds' security portfolio, Jamie draws on years of experience serving in a variety of roles, such as Sales Engineer for SolarWinds Core IT Products and IT Auditor and Security Consultant for Deloitte, among others. In each capacity, he has assisted businesses in the adoption of technologies to enhance security, meet regulatory IT compliance and pass audits for a broad array of compliance frameworks. Jamie, thanks for joining us today.
Also on the line, we have Ian Trump. For those of you who hung out with us for our first session, Ian joined us there. He's back today. For those of you who don't know him, Ian is a thought leader in IT security. His 2016 in-depth analysis of cybercrime and threats of the future was featured in industry publications such as SC Magazine, Infosecurity, The Times, USA Today, the Sunday Herald, and the list goes on and on. He's a well-accomplished writer and really knowledgeable on this subject matter. Ian, welcome, thank you for joining us.
Hey, thank you. I'm real excited about this one.
Awesome. Well, I think without further ado, I'd like to go ahead and pass things over to Ian to kind of provide us a little bit of background on the cybersecurity climate. Definitely hearkening back to what we talked about in our first session, but I think it's important to give another quick highlight of this.
Absolutely. And thanks so much, Josh. Or Emcee Josh, as I'm going to call you from now on. Thanks, folks, for joining me. This is a really exciting moment for me because this is really talking about an area that's very close and dear to my heart, because I really started in security knowing and working with firewalls. So, to be invited to come on and talk about the importance of a firewall, the importance of how the log information is helpful to a business and really how, if it's happening in your business, it's happening at your firewall. And I think that's the network layer of that firewall's relationship between inside your network and outside your network is probably the most important area to focus on. So one of the things that they like to do to bring me on is to really talk about what is going on in cybersecurity, what that landscape looks for. But let's look broad picture first.
Let's look at some of the numbers. In 2015, we had an industry that had grown to about a $75 billion industry. Tremendous amount of folks using different products out there. Really exciting. We're seeing this grow phenomenally. $170 billion is the number that's being bandied about by what the industry will be by 2020. The last number that becomes really important for us is the fact that the entire value chain of the Internet is projected to be around $5.3 trillion by 2020. So, if we're losing 50% of what we're making from cybercrime, we have a huge problem on our hands.
So one of the things that I like to do to help people understand how cybercrime works--especially from the exploit and the delivery of a Trojan onto an end point and then the payload--is to look at the Lockheed Martin Cyber Kill Chain as a teaching guide. As something that we can look at and say, "Okay, these are the stages that a piece of malware takes." And essentially what you have to have, in order to have a ransomware infection or a Trojan land on your endpoint, is it has to come in from a source from the Internet and it has to then make it call back to the command and control to get the instructions once it's actually landed. Those are the critical junctures where the firewall and your firewall logs and, if you're running a SIEM product like LEM, can really help you understand when you've got something major going on in that network.
I just want to also talk about the lateral movement which you see in networks today, where the bad guys are actively searching, actively looking for a device to exploit. This is a real standard type of operation now, where we're seeing a ransomware actor, for instance, do some reconnaissance before launching their attack in order to find out, are they working in an environment where they can charge quite a bit more for ‘ransomwaring’ those particular files? We see that in health care with some outrageous ransomware demands. You know, 17, 20 thousand dollars.
I wanted to point out, though, that part of this whole problem that we have is the infection of the Internet of Things devices. So, at the network layer, if you're not writing firewall rules that are preventing outbound traffic, you can get some major problems with those types of devices that might be very vulnerable and need to be protected by a robust firewall rule. Think of firewall rules that are preventing stuff from leaving your business as a way of setting a trap for the cyber bad guys. I think that's another really interesting aspect that Jamie's going to get into when he starts demoing the product, about how the actual firewall works-- both in preventing stuff coming in, but also, if you're writing a rule set, preventing stuff from coming out.
Now, one of the most important things that we talked about, prior to when we were putting together this series, is making sure that you have the information that you need to support the business case for something like a SIEM or log management solution-- or, if you're running a larger network, the network configuration monitor or network configuration device.
The most important thing to understand is that, in many states, you're dealing with regulatory requirements. You're actually dealing with a situation where you are required by law to notify individuals of a security breach. One of the ways to understand what the scope of the data breach is is to examine what has been exfiltrated from the organization. This is really important in identifying the scope and size of the breach and will allow you, by law, to notify the affected parties. It's also really important to understand that there are certain regulatory industries-- specifically, HIPAA, SOX and GLBA-- that require a data breach notification and a report to regulators. So, again, what I love to say is that if something is going on in your business, externally, internally, that communication back and forth is passing through your firewall. The detection deficit is something that we talked about quite extensively in the last little while. We have certainly seen a difficulty in understanding whether or not you are in a particular breach-scenario, where you have to do incident response.
Mandiant's report, that they come out with every year, suggests it's about 200 days from when the bad guys have gotten into your network and when you discover that they're there. This is a very unfortunate consequence, because in 200 days an awful lot of damage can be established, an awful lot of data can be taken. And certainly, when we see the larger, more sophisticated networks-- like Yahoo!, for instance-- that breach had gone on for several years before it was publicly disclosed, and certainly several months before the folks at Yahoo! understood exactly what was going on. So again, this log management, SIEM, plays a huge role in setting yourself up for success.
We've seen a recent trend in malware that will establish a connection back out through the firewall using protocols that normally should never come outside your firewall. As an example, SMB (Server Messaging Block) is a protocol used by Windows machines. There has been recent attacks that the payload actually makes a connection outbound in the organization through SMB. So a US-CERT notification came out about blocking SMB traffic outside of your network, which you would think is a best practice. However, one of the interesting things is if your firewall is configured to block that particular traffic and you see an alert from your SIEM or log management, now you know that you have a piece of malware in your environment that is certainly trying to get outside that environment.
So, firewall logs have two primary reasons. They absolutely help your business understand the type of traffic that is leaving the business and certainly, if you're good at configuring firewall rules, you can certainly isolate that type of information that's leaving the business and alert if it becomes something that is very strange. So as an example, you may have a business and not use the IRC, which is the relay chat protocol that is used by some pieces of malware. If there is no business reason for you to support IRC outbound, writing a firewall rule and setting up an alert for the presence of IRC in your network is absolutely a great idea to catch a particular families of malware that use that protocol for command and control. In larger organizations that have multiple firewalls, certainly there is a need for consistency and auditing and change management. So when you look at a larger network that might have four or five different locations, possibly also running internal firewalls to segment that network up, you now have a very complex task if you have to do configuration on each particular device manually. So, there's huge value in consistently delivering and even adapting to a changing situation or because you have information that a particular attack may be exploiting--something like, for instance, Network Time Protocol. So these are all really important considerations.
Finally, when you look at the next generation of firewalls, you are now going to be able to consume a tremendous amount of data coming out of those systems. The important consideration here, too, is to understand that the bad guys will use encryption to their advantage and, in some cases, establish SSL tunnels or IPsec tunnels out of your business. So again, if you're writing good firewall rules and you do have a requirement for VPN tunnels, that's great but, certainly, write it from a perspective of the bad guys are inside their network and I'm not going to allow any arbitrary VPN tunnels or IPsec...[audio cuts out] ...allow specific VPN tunnels for business reasons to particular locations. So that sort of concludes my stop-and-start, sadly, of trying to get things rolling for the actual webinar. And I'm now going to turn things over to Jamie Hynds, I think, to start talking about some of the things that I've talked about from the perspective of the firewall logs and events that you can alert on.
Cool, thanks, Ian. Hi, everyone. So what I am going to mainly talk about is essentially, what do firewalls log typically, what kind of logs are generated by firewalls? Moving on from that then--how does a SIEM tool help? What kind of values do I get with a log management tool such as Security Event Manager? As well as briefly discussing our Network Configuration Manager, as well, which can do things like backup configs and real time change detection, as well as some other elements of network configuration. And then, we'll also discuss how do I get my logs from my firewalls into LEM?
So, just a brief intro in terms of how do I actually integrate my firewall logs? So what kind of events do firewalls log? Traffic and lots of it. With those traffic logs, you can typically get some operation value but a lot of security value. You can look at things like ports being accessed and used and we're going to get that out of firewall logs. Two ways that commonly happens. A lot of firewalls are just going to log firewall stats. It also looks like noise and there's a lot of it. You can imagine the larger the organization, as Ian said, the more firewalls you have, the worse that noise is going to get. But you can also get ACL or per-policy logging now, which is a lot more valuable. It's generally allowed to go into and say, "I don't want to log all my accepted ACL traffic. I just want to log specific patterns of interest or maybe specific egress centers, maybe ports that I know are being abused or problems that I've had in the past, et cetera." You can make that logging a lot more intelligent, rather than logging all and sundry, you can just change your logging on your firewalls to only allow specific events, et cetera.
You don't have to see everything. It's typically more valuable to start narrow and then expand, rather than the big-bang approach. On the ACL side, you can usually specify where you want to log, (i.e. to a SIEM solution like LEM). That being said, with the likes of next-gen firewalls, you can do things like specify whether you want to log the session start or the session end. But if you're not doing any logging now, definitely start smaller and expand from there. There's no denying that it can be overwhelming just to turn on all sorts of logs from your firewall. SEM can certainly help you get going and it's got lots of predefined filters, dashboards, et cetera. But there's certainly going to be a point where you're going to enable lots of things and stuff is going to happen.
You can also get things like meta-information, on what's happening with the device itself. So as I mentioned, making things like config changes and where they're coming from. Even in some cases, with some firewalls you can even see what specific commands are being run. So Cisco firewalls do this especially well, where you can actually see what commands you just have run. This is especially useful if you're looking for things like change control validation or if something unexpected happens, you can trace who did what and when. Some firewalls aren't advanced in terms of monitoring and logging that kind of information, especially usually web-based consoles often don't log exactly what commands are run. But, you should still at least be able to see what area has changed and what change was made, essentially. You can also see authentication events, which can be very important. You can see who's logging on to make changes. I know all of you out there certainly aren't using generic accounts; I'm sure you're all using named accounts for your firewalls. You can see exactly who's logging on, who made the change, regardless of whether you're using TACACS or local authentication, you can see who's logging on.
Equally important, you can see things like logon failures, as well. If there's like a brute-force attack or if someone is guessing passwords they shouldn't be, et cetera, you can monitor for logon failures, as well. With things like SEM correlation rules, you can actually set thresholds on that. So, if you see maybe 10 logon failures in 30 seconds from the same IP, you can then block the IP from there or send an email alert to let you know that there has been quite a high number of logon failures on your firewall. If you're using your firewall to support things like VPN functionality, not tunnels but literal VPN functionality, you can see people logging on, using the VPN. If you're using SSL VPN, you'll generally be able to see all that traffic, too-- sorry, all those logs, too. And when customers are trying to connect to the VPN, you can see what time, who's logging on. Especially important is any out-of-hours logins. With LEM, you can actually set your business hours. So you could say if anyone logs on the VPN from 8:00 a.m. to 8:00 p.m., that's absolutely fine. But if you see that one of your users has logged on at three o'clock in the morning, that could be cause for concern. So you can actually set your business hours and look for any out-of-hours logins, which could be cause for concern. And, certainly, trying to manually wade through those logs is making it very hard for yourself without some sort of tool like Security Event Manager to process all those logs; it's going to be quite hard.
A lot of firewalls nowadays are based on a platform like UTM, and next-gen firewalls. You can also build on your existing firewall to include application- aware information or IPS modules, et cetera, and they generate even more security-specific details. If you're looking at IPS data from your firewall or if you have your IPS module for your Cisco firewall, you're going to be getting that additional data. You're going to get a lot more info rather than just traffic data. If you have a smart firewall, a next-gen firewall, and it logs smart data, that's typically the Holy Grail. You can set higher threat levels and track that. Not everyone out there has that luxury, so I'm going to start from the top and then eventually just look at the traffic if you don't have the next-gen firewall. So in terms of how does SEM help? What does it do for me? High volume typically makes it hard to be high value. Even if you start small, for a lot of people, this is going to be the first time you're seeing those firewall logs in a useful way.
People might be used to logging things like raw syslog, and they're used to looking at raw syslog, or a very basic syslog server, it doesn't do any normalization. One thing SEM does is normalize all those logs. So in some environments where you might have Palo Alto firewalls and Cisco firewalls and Juniper routers, et cetera, where you have lots of different vendors in your environment, each of those formats look different, with different naming conventions, et cetera. Thanks to LEM, you can actually normalize that data. It makes it much easier to understand, puts it into a human readable format and spits out the data into different fields. So it's a lot easier to understand and comprehend your log data.
You can also apply environment details. You can add what we call user-defined groups to your Security Event Manager. You could maybe have a list of ports that aren't allowed in your environment, a list of users you want to keep an eye on, a list of things like spyware sites you want to monitor for access to those URLs and be alerted, et cetera. So you can actually make SEM quite customized in terms of creating lists of anything you want, really, but usernames, IP addresses, services, port names, the list is endless. And you can then monitor for that kind of activity against those various different user-defined groups. In terms of correlation, it's one of the most powerful aspects of Security Event Manager, in that you can take your firewall data and you can correlate that. As I said, you can set your thresholds earlier in terms of to certain events in X amount of time, trigger this action.
What's really useful is you can actually correlate your firewall data with other event sources to get a full picture of what's actually happening. You can see a view in SEM where you can see-- show me log data from this workstation and also show me data from my firewall at the same time. So, you can correlate, if there's an issue on a server or a workstation in your environment, and how that's affecting the firewall or vice versa. So you can get a whole picture, rather than just collecting firewall logs and then go into your Windows server and looking at event logs, you can see it all in one single place in Security Event Manager. You can take that correlation a step further. Rather than just simply send an email alert, you can leverage active response, either on the device itself, on the firewall itself or somewhere else.
We include lots and lots of different active responses out-of-the-box. Quite a powerful one is blocking IP addresses. You can actually, for most of the common, popular vendors out there for firewalls, we can actually block the IP address. If you saw a certain number of events happening and you want to block a particular IP address on your firewall, you can trigger SEM to do that. If you're not comfortable doing that on your own firewall, you could also leverage active response somewhere else to isolate a problem. Maybe if you see a specific attack or a worm, et cetera, that looks like something malicious, you can potentially log off the user and shut down the machine or disable the network. Rather than go into the firewall, you can leverage active response elsewhere on the network, rather than the firewall. So we offer a few options there in terms of the active response. In terms of the network configuration aspect, I know I talked a minute ago about the ability to see what commands are run and who's making changes on your devices. So SEM can certainly collect syslogs from those devices to determine if a change is made.
You can then take that a step further with our Network Configuration Manager tool, which I'll show you briefly in a demo in a minute. You can actually monitor, much like LEM, real time change detection via syslog, but with NCM, you can actually back up the device config. So you could, on a daily basis or a weekly basis, et cetera, you can back up your configs. You can also then run change reports. You can compare the configuration of your firewall today versus yesterday or versus last week, so you can see exactly what was changed. We also integrate with the National Vulnerability Database for Cisco devices, so you can keep track of any known vulnerabilities on your Cisco devices. You can run reports and see all the activity from the devices, and watch vulnerabilities that exist on that device with the help of the National Vulnerability Database.
NCM also allows you to apply bulk configuration changes. If you want to make a change to a group of your firewalls, rather than having to log in manually to every device, you can select which devices you want, click one button and run a script or a config change on all of those devices right from the web console. You can also establish configuration baselines. So, you can set what a normal configuration should look like on any network device. And from there, you can view a graph to show you if any of those configurations go out of a baseline so you can be alerted to that, as well. In terms of diving into a demo of our Security Event Manager, this is how it looks. Deployment is super easy. It's just a matter of deploying a template in vSphere or Hyper-V. From there, we use, typically speaking, we do syslogs to integrate with your firewall logs. Once you have Security Event Manager installed, it's, typically speaking, just a matter of logging onto your firewall, configuring the syslog to point to Security Event Manager and we'll pick it up from there.
We have a Success Center, the SolarWinds Success Center, which contains a huge amount of information and very easy-to-understand KB articles, which can assist you in integrating both your firewall logs and also logs from other sources, like your servers, workstations and more.
In here, in this monitor section, I can see all the various different events going into my Security Event Manager. As you can see, on the left-hand side, I can see I have some predefined filters out of the box. If I wanted to see, in this case, in this instance of Security Event Manager, I'm collecting checkpoint logs in the checkpoint firewall. I can immediately come in here and I can see there's quite a number of dropped packets. I can see currently, since I've logged in, there's been 309 dropped packets. I can click on any of these events and I can immediately see the normalization that I spoke about taking place. Rather than looking at those raw logs, I can see immediately from the information contained in the log, we automatically assign this a common event name. In this case, it's ping traffic, it's ICMP Traffic. And you can see ICMP Traffic from here, what the provider SID was. You can see the event ID, the date, the time, the device in question and additional info. And, very importantly, you can see the source machine and the destination machine. So you can filter any of the information contained within this device.
If you want to just show me activity containing this particular field or you want to look for traffic coming from particular source machines, you can add all the information here to filter on any one of those fields from there. In terms of looking for 'Denied ACL Traffic,' you can see here, this filter, I can see any traffic that has been denied. And, again, I can see the source port, the destination port, the machines involved, what interface in question, there. You can see everything there and very easy-to-comprehend data as well. Filter real time event logs. You can view lots of filters out-of-the-box.
We also have a feature in Security Event Manager called threat-feed intelligence. We integrate with emergingthreats.net, which is a collection of bad known IP addresses. It's a big list. It's updated very often. So you can see any communication either from your network out, or from the outside in. And you can then see if there's any bad known IP addresses appearing in your firewall logs. So I can see, in this case, we've actually picked it up, and we've denied the connection. And I can see, in this case, it was denied by a security policy. So, it was probably denied by an ACL. And I can see 'IsThreat' is 'True,' which essentially means it is appearing on the list of bad known actors. That could be for spam, botnet, ransomware-- essentially a huge multitude of various different attack sites that people are blacklisted for. And I can see in here the source machine. If I wanted to, from there, I could actually respond to that and block that IP on that Cisco firewall. The threat-feed intelligence is very powerful in leveraging information provided externally and monitoring for that. We have certain correlations out-of-the-box that allow you to monitor for that.
We also then have the historical searching. So if you wanted to see what happened when-- the monitor section is focused around real-time events, whereas the nDepth section is focused on historical data. And this is really easy to use. You don't need any query language. It's just double-click, drag-and-drop, et cetera. It makes it really easy to find the data that you need in one or two clicks. In this case, I run a quick search here to look for user logon failures to my checkpoint firewall. And I can see last Thursday, the 23rd of February; I can see there was four logins in quick succession here. I can see the username, the reasons for failure, et cetera-- --it was the wrong passwords-- the date, the time, et cetera. So you can look back and very easily see those admin logon failures. I can also customize my timeframe here. So I can say, show me all events for the last 30 minutes. And in there then, I can filter based on particular traffic. I can filter based on machine name, username, et cetera-- port name. I can see all my various different events over here.
Equally, I can just do a quick keyword search. If I want to see all events that contain, let's say, '443,' I can come in here and I can see all those various different ports, what time they occurred, et cetera. Maybe you could, as I said earlier, create a list of ports you want to monitor specifically, that have been giving trouble lately. You can then search for all the ports in that list. You can see if there has been any traffic accepted or dropped on that particular port, or that list of ports. In terms of correlation rules, we have lots and lots of correlation rules out-of-the-box. And, as you can see, these are all categorized. If you wanted to come into 'Devices' and, in this case, you're focused specifically on firewalls, you can see all the various different rules we have out-of-the-box for firewalls, relating to ping traffic rules. We have port scans, malformed packets, IPsec failure-- a huge list of rules we provide out-of-the-box. So, it's not a case of you deploy LEM, you integrate your firewall logs and you start from a blank canvas. We provide lots of dashboards, filters, rules, reports, alerts, et cetera, out-of-the-box. So it makes it really easy to get up and running and not be starting from a blank canvas.
I know Ian mentioned earlier on, CryptoWall. There is a rule available for CryptoWall in that we can monitor various different event sources, that might indicate that there might be ransomware-- Crypto, in this case--in place. This is involves correlating data from, say, your workstations, as well as your firewalls. You can see if the Volume Shadow Copy Service starts in the machine. There's a certain registry key that's deleted or amended. There's also, in this case, some service is stopped. So, like, Windows Update has stopped; the BIT Service has stopped. You could also add another condition to that to say, if a certain number of files are written to, or if there's a number of file changes made-- so SEM also does file technical monitoring-- to monitor for file changes. If all that occurs, and we also see some traffic from that machine trying to get out to any one of these IP addresses, which is known for the CryptoWall ransomware, we can then create an alert and add some actions down here.
As I said, we can block the IP in the firewall. We can disable the network on the machine immediately, and we can log off that user to prevent the spread. So here's all the various, different actions we can take on your machines. And, as I said, you can block IPs on firewalls, as well. So, it's a lot more than just sending email alerts. You can see all the basic actions you can take from here. We also mentioned network configuration management. We have a tool called Network Configuration Manager, which lives within the SolarWinds Orion console. And in here, you can see all the various different backups you've done of your devices. I can see all the devices I'm currently backing up.
So come into a Cisco device here, for example, click on any one of these and you can then see all the running configs, startup configs, et cetera. If I click into the device, you can then click on the Configs tab to get a great summary for that one device. So rather than looking at your entire environment and everything you've got backed up, you can click on a particular device, and from there, then you can come in here into the Configs tab and you can very easily look at the config of that device, perform change comparisons. You can see the last five config changes. There is a wealth of information here on this configs page. You can also look at vulnerabilities. You can see all the vulnerabilities that appear on this particular device, according to the National Vulnerability Database. You can see the CVS score, the severity, et cetera, and whether it's confirmed or potential. You've the option to confirm that or flag as a potential vulnerability.
We can also see the last five config changes. In here, I can view a change report, and I can see what exactly changed. So between these dates and times... These lines weren't here before and they were all added at this particular time. Any unwanted changes or erroneous changes, you can see in here very easily. Results from a security point of view: Some great reports out-of-the-box that allow you to look for any out-of-policy violations. If I come into 'Config Summary.' We include that report out-of-the-box and you can also create your own from scratch. You can create particular rules particular to your environment or also best practice rules. And you can look for any violations to that.
So for example, if we saw even something simple, like certain password lengths. It's basic, but there should be minimum password lengths set in all your firewalls. I can see all the devices over here-- be it firewall or router or switcher, et cetera. And I can see all these various different devices are not compliant. Click here and I can see the 'security password min length' was not found. So it hasn't been set on any of these devices. What's really powerful about NCM is you can actually remediate that from here. So you could actually remediate, or run a remediation script on all those in violation. And from there, then you can type in your script and you can say, ‘I want to set the minimum password length on that device.’ So, you know, set password length... And from there, you can execute that script. So that brings all those devices back into compliance. From a change management point of view and a security perspective of your firewalls, you can very easily make changes, and look for any violations that could be a threat there, as well.
Finally, we also include the SEM reports package. So not only can you correlate and do, in real time, a look at historical data, you can also run historical reports. So we include reports for authentication events, change management events, file auditing and network events--amongst others. You can run these reports. Here's one that I created earlier. You can see your 'Core Traffic by Destination Machine.' On your firewalls, you can see all the various different destination machines appearing in your event logs. If there's any suspicious IP addresses, you can summarize these and you can drill in here for more information. And you can then see exactly the event logs from there. So you can have a high level of view, click in there, and you can then see the various different event logs. And you can see they were denied. You can filter based on ports, based on machine names, et cetera. So you want to filter across all your destination traffic-- just show particular protocols, particular interfaces or ports, et cetera. It's very easy to apply filters to these and from there, export to PDF, Excel, CSV-- we support all the most common formats out there.
So in the interest of time... we might just shoot to a Q and A. So are there any questions in the queue there, Josh?
Yeah. Actually, we did get a few questions on chat that I think we should probably address. Let me just... Bear with me one moment while I pull those up. One question that I think we've already addressed in chat but I want to make sure we cover it live so everyone can hear. We got a question that says, "When it comes to protecting your network, "is the process of searching the logs for malware "the best approach and the best use of your time?" For me, my response to that is that it's not just about that. It's how you can use a SIEM solution, like LEM, to trigger, based off of certain activities, to carry out different functions. And you can speak to this in greater detail, but am I hitting the nail on the head right there?
So, Josh, I think that this is part of when you're doing a couple things. One is you're in an incident-response scenario and you are trying to figure out where the bad guys are in your network and what's going on. The ability to search across all of your logs and correlate events becomes absolutely critical in figuring out what's going on. For day-to-day activities, I think you just hit the nail on the head with the LEM/SIEM setup, with your various alerts to tell you when something is particularly going off the rails. I think there's a number of different scenarios where you would end up having to go to the logs, especially when you're trying to find something inside your network that is particularly stealthy.
That makes sense.
Especially with file changes. With file integrity monitoring of LEM, you can see, oh hey, there's certainly a number of files that have changed in quick succession. Next thing, I see some unusual communication attempts from that machine. And, also, all that correlation you can track all that kind of activity.
Right, right. So, let me press on with a couple more questions. And folks, I want to remind you, now would be the time to go ahead and submit questions via the Q and A chat box. And then, we'll address them if we can here today. I know we're running short on time, so we're just going to breeze through a couple of these quick questions and then, if you hang out on the line a little bit longer, or in chat for a little bit longer, we'd be happy to respond to some of your questions there. But we'll keep pressing on here. Another question that I received was... "In order to capture admin login attempts to the firewall, "which log source is better, "the firewall itself or TACACS?" I know it's getting kind of deep in the weeds there but, Jamie, I was hoping maybe you could answer this.
I think you're going to get the same results from both, I believe. Regardless of the source typically, via syslog, you're going to see admin from both.
Okay, well thanks for clarifying that. There's a question here that says, "How do you proceed with logs that come from different time zones?" "What time zone would you recommend for Security Event Manager and for other sources?"
We have detection time and insertion time in LEM. I can actually send you a blog post on that. The detection time is the time it's detected from the device, I believe, and then insertion time is the time it's inserted into the SEM database. So there is some offset there for time. We definitely have a blog post on THWACK about that, so I can certainly provide that after the webinar. No problem.
Yeah, that would be great. And for those of you who aren't familiar, THWACK is our online-user community of over 130,000 IT professionals that are either users of SolarWinds products or are just extremely knowledgeable about all topics related to IT. So it's actually a source of information for anyone that's interested in learning about what we have to offer, but also talking about topical matters related to everything from IT security to down in the weeds, you know, usage of products. So I encourage you guys to check out THWACK, as well. But we'll send you a link to that post in a little bit.
I have just one comment that I want to add about that. A couple things. What I've noticed is large global enterprises tend to have all of their devices on UTC so that when you're aggregating everything, you're basically dealing with one time zone. And, just to underline the importance of time, make sure that your logs are syncretized to an NTP source because I've done incident response where the servers have been set up with different times on them and not coordinated and it was a nightmare trying to correlate activities across a number of different devices and workstations and server environments. So, time is critical to have locked down if you're doing log aggregation.
And we actually also have a rule out-of-the-box as well, for NTP failure or sync failure. So, I think in Windows, it logs it as an NTP failure, and you can actually trigger a rule on that and that will let you know if an NTP sync isn't successful.
That's a great bit of advice, there. I hope everyone heard that one. We have one last question that I think we should probably address here, and then I'll have to move on with closing out and helping everybody understand the procedures around getting their T-shirts, if they're chosen as a lucky winner. The last question was, "How do you handle storage?" "I've found that firewall logs that are collected are huge due to the amount of traffic. So, what recommendations are there for the storage and archiving of those logs?"
LEM uses a highly compressed database, so the ratio is about 40:60:1... About 98% compression. So that essentially gives you more log storage per less space. So it's a virtual appliance when you deploy it, so it's very easy to scale out. So, you can set the size of the disk to be whatever you like, up to a maximum of two terabytes. And from there, then if you want to store your logs for longer, you just simply assign more space and it detects the space automatically. Once the database gets full, it will start to override the oldest logs first. What you can do is set up an archive policy. There's an archive config whereby you can archive those logs off to external storage if you need to store them for X number of years, et cetera, from a compliance point of view. In a nutshell, it does use a highly compressed database that really gives you more log storage for less space.
I just want to point out, too, that if you subscribe to something like Dropbox or Google Drive, At RSA, Google was handing out--two years free-- one terabyte of storage space. Storage of logs is crazy easy to do now, with the amount of cloud service storages that you can get. And it is important... A couple of the regulatory compliances that I've looked at recommend seven years of retention for logs. So, yeah, storage has come way down in price. It shouldn't be an issue.
Okay, guys. Thank you so much for helping to field some of those questions. I know we didn't get around to answering too many of the product-specific or information around pricing, but if anybody has questions about that, don't hesitate to reach out. Feel free to shoot a question over chat, or I believe we shared my contact information, so you can reach out to me directly. I'd be happy to answer any questions. So one last thing before we move on. I want to encourage everybody to go check out solarwinds.com/lem and solarwinds.com/ncm to check out information regarding the two products that we demoed today. There, you can also download free, fully functional, 30-day trials for both of these products. So I encourage you to do that, especially in time for our next webinar-- our next webcast in the series--which will take place, again, on March 21st, at this same time that we kicked off things today. And it's about Active Directory changes-- another really big topic when it comes to security. So please do check it out. And then, you can also go to go.solarwinds.com/kungfu-webcast-series. Like I mentioned before, you can check out the recordings of our past sessions. We'll put today's session up there, as well, in the future. And then you can also register for all of our future events. So, I encourage you to do that.
As far as the shirts go, we'll be drawing names out a hat and sending out an email later on for all of our lucky winners. So stay tuned and check your inbox. And that's just about it, folks. I want to thank you all for attending today and thank you, especially, for working with us as we worked through our technical difficulties surrounding the sound quality issues. Join us next time. We'll work out these kinks and we'll have a great session in a couple of weeks here.
Thank you again. Thanks for joining us. Hope you enjoyed it.