Splunk Thinking For Security Monitoring

Vince Sesto
Splunk User Developer Administrator
4 min readFeb 21, 2017

Let me start by saying that I’m not a security expert. It’s not my domain, and to tell you the truth my hat goes off to the people that deal with this stuff on a day to day basis. It’s a tough world out there and to be honest it keeps me up at night.

Having such a vast amount of data at your finger tips though, sooner or later someone is going to ask you for help with security matters, or be requesting what you are monitor for security purposes. The good thing is, there are a lot of things you can be monitoring already without really making any changes to what you’re currently indexing in your environment.

Hopefully the following list can provide you with some low handing fruit to make sure that security monitoring is moving in the right direction.

Login Data

Weather you are working on a Windows or Linux environment, your login data can provide you a wealth of information. When it comes down to it, security monitoring will heavily revolve around access to your system, including who has been accessing and what they have been accessing. If a major violation or breach has taken place, it’s the first thing you’ll need to be looking through to get a clear indication of what has occurred. So you may has well start monitoring this data early and set up reporting around these aspects. Login data can provide you a breakdown of the following which may signal some red flags:

  • Long running logins that last for days. Even though this could be legitimate work it may breach your companies security policy.
  • Failed attempts to login to your systems via external sources using ssh or remote desktop.
  • Numerous failed attempts to login to a specific system locally.

Account Specific Monitoring

After actual login’s and attempts to login, its probably wise to look at your user accounts within the environment. Account specific data allows you to see if there have been any changes taking place to grant access to users who may not need them. The last thing we want to do is stop users from doing their work, but if there is a single gate keep granting access rights, it may be worth setting up a daily process to allow them to view what changes have been made. This could include:

  • Account modifications and deletions.
  • New users added to the environment.
  • Account modifications with privileged access being granted across your environment.
  • Listing users who have left the company, to ensure their access is removed from the environment.

Monitoring File System Changes

This is a lot easier in a Windows environment than a Linux file system. Things are a lot more straight forward for monitoring changes to a Windows environment, but there are still open source versions of tripwire available, so this may be an option to allow you to do similar reporting on Linux. A lot of changes in a Linux environment, most likely will need sudo access so your auth.log will still give you some good information here. You may want to be looking for:

  • A large number of file deletions or removal of configuration files.
  • File access attempts or changes in permission to files.

Monitoring Mail

If you’re monitoring mail systems there is a lot you can do to enhance your security. You most likely have systems in place to already monitor and flag any issues but there is still a chance that something may not be caught by these processes. You could look for the following:

  • Search for suspicious mail that could be malware or phishing.
  • Search for users that have been sending or receiving large amounts of email.
  • Monitor the size of users mail boxes and look for dramatic increases in size.

Password Data and Personal Information

This is more so for application logging, as no passwords should be logged in plain text. The same goes for personal information like address details or credit card numbers. You will find that internal audits will be asking the question so its a good idea to be proactive with this type of information and report and breaches as soon as you might see them. This will become more of an issue if you have a security breach and that personal information or passwords are used for evil purposes.

Found this post useful? Kindly tap the ❤ button below! :)

About The Author

Vince has worked with Splunk for over 5 years, developing apps and reporting applications around Splunk, and now works hard to advocate its success. He has worked as a system engineer in big data companies and development departments, where he has regularly supported, built, and developed with Splunk. He has now published his first book via Packt Publishing — Learning Splunk Web Framework.

--

--

Vince Sesto
Splunk User Developer Administrator

Vincent Sesto is a DevOps Engineer, Endurance Athlete, Coach and Author. One of his passion’s in life is endurance sports as both an athlete, coach and author.