Threat correlation is really the secrete sauce of the SIEM. The theory goes that in today's day and age, there are so many systems of different types, that it is hard for one analyst to know them all. The SIEM is supposed to provide you this service / feature... almost like an analyst in a box. I personally feel that you still need both. You need an analyst who knows what they are doing and can spend time to understand systems and security contexts, etc. The SIEM should be a tool that a good analyst uses to get their job done, not a replacement.
Threat correlation implementations vary widely (most probably don't work as advertised either .. but what is new?).
- Risk Based Threat Correlation
Basically either takes vulnerability scanner data, or analysts configuration to assign priority to detected threats based on perceived risk.
- "Drift" reporting
Threats can be caught by detecting deviations from normal operation
- Netflow integration
The network doesn't lie. Incorporating that traffic into the threat correlation engines is invaluable (as long as it is done right).
When picking a SIEM, I would want to focus on the following things.
1) Number of threat correlation rules
2) Devices / configurations needed to achieve maximum value from the threat correlation rules
3) Frequency of threat correlation rule releases
4) Real-time correlation
I think that number 2 above is quite important. You really want to get a good understanding of what inputs are required to make the rules really work for you. You then want to map that to your environment to see if you can actually produce that level of logging. In some cases, say databases for example, the audit logging levels required for threat correlation could compromise the performance of the server.
Many SIEMs are now connecting up to "cloud" sources to get additional information. We are only as strong as the information that we share, so I do see this as a good option and something you will want to look for.
Ultimately, I think the key here is integration. You probably already have systems that can be used to assign a "risk profile". The question is how do you easily get that data into your SIEM. On the flip side of that, you probably want your SIEM to be able to integrate with your ticket management system. Although the SIEM provides one, and your analyst will probably use it, you still need a way to communicate with the other groups. There may be some automated responses that you want conducted that do not need the analyst to "vet" the request before sending.
As always, look for good integration with other tools (in your environment) and for UX. You will probably add some rules for custom applications in your environment. Probably not in the first phases of implementation, however.
Thursday, October 11, 2012
Friday, September 28, 2012
SIEM Features - Log Management
Incident and event management is a hot topic these days. Well, to be honest, it was a hot topic long before I came into the security field. The most recent SANS survey on information and event management claims that 37% of respondents are using a SIEM in some capacity while 22% are solely using SIEM. You can find more information about this survey here. With the every increasing complexity of systems deployed in production environments, I feel that it is getting harder to find a security professional to know all the systems well enough to be able to detect events of interest. That is the secret sauce that SIEM sells.
My own research has lead me to believe that there are four main "feature" areas to look for in a SIEM. They would be:
- Log Management
- Reporting
- Threat Correlation
- Incident Management
In this post, I want to talk more about the first one, log management.
When trying to sell the idea of SIEM to upper management, log management will be the single, strongest foothold you will have. The problem is, most management will just stop right there. Why you ask? Well, most management prefer the illusion of security. But that discussion is for a separate post.
Selling features for Log Management:
1) It's EASY!
2) Everyone needs log management (networks, unix, server admin, application guys, etc)
3) Regulatory Compliance
The last one listed above is the Ace in the pocket sorta speak.
There are a few things to look for in a log management solution that any SIEM vendor will sell you. The first thing you really want to understand is EPS that the boxes can handle. What you have to remember is that the industry calls an event "a log message with about 150bytes of data". That is really important to note because some applications, etc, will actually be generating a lot more than EPS then you think. With they way that hardware has gone these days, most SIEM vendors have devices that can scale up to the 10 000's of EPS.
The second thing you want to consider is the types of parsing that is done on the logs by the SIEM. Ultimately, the SIEM needs to be able to perform two main functions. For starters, they need to be able to store the raw event logs, unaltered. Furthermore, they need to prove that the logs were not tampered with. This is usually done with hashing and I'm sure there is a FIPS standard (140-2) that will cover that. The second, the SIEM needs to be able to parse the events in order to be able to later run correlation rules against it. You will want to get an idea of how many different parts of the log is "parsed". This will give you an idea of how granular you can make your rules.
The third thing that you want to consider is the method in which the SIEM gathers it's logs. Syslog is great, but not everything is transmitted well in that format.... *ahem* checkpoint *ahem*. In any event, having a broad range of log collection methods is key. Look for SIEMs that can do things like WMI, .net calls, SNMP traps, and any other proprietary ones you can think of. It is probably best to make a list of the type of devices you have in your environment and ask some pretty pointed questions.
The fourth thing you want to look for is flow data. From my months of experience in security, the host can lie, but the network never does. Flow data is yet another dimension of data that can be used to correlate events and look for anomalies.
Last, and probably most important, is log retention. Any good log management software will provide you with endless combinations of settings to allow for just the right log retention period by device. Don't settle for anything less.
Remember, a SIEM needs to be as functional as it is usable. Really, in this day and age, a usable system that flows and has lots of white space etc is a bare minimum. If the front-end is klugy, run and never look back.
My own research has lead me to believe that there are four main "feature" areas to look for in a SIEM. They would be:
- Log Management
- Reporting
- Threat Correlation
- Incident Management
In this post, I want to talk more about the first one, log management.
When trying to sell the idea of SIEM to upper management, log management will be the single, strongest foothold you will have. The problem is, most management will just stop right there. Why you ask? Well, most management prefer the illusion of security. But that discussion is for a separate post.
Selling features for Log Management:
1) It's EASY!
2) Everyone needs log management (networks, unix, server admin, application guys, etc)
3) Regulatory Compliance
The last one listed above is the Ace in the pocket sorta speak.
There are a few things to look for in a log management solution that any SIEM vendor will sell you. The first thing you really want to understand is EPS that the boxes can handle. What you have to remember is that the industry calls an event "a log message with about 150bytes of data". That is really important to note because some applications, etc, will actually be generating a lot more than EPS then you think. With they way that hardware has gone these days, most SIEM vendors have devices that can scale up to the 10 000's of EPS.
The second thing you want to consider is the types of parsing that is done on the logs by the SIEM. Ultimately, the SIEM needs to be able to perform two main functions. For starters, they need to be able to store the raw event logs, unaltered. Furthermore, they need to prove that the logs were not tampered with. This is usually done with hashing and I'm sure there is a FIPS standard (140-2) that will cover that. The second, the SIEM needs to be able to parse the events in order to be able to later run correlation rules against it. You will want to get an idea of how many different parts of the log is "parsed". This will give you an idea of how granular you can make your rules.
The third thing that you want to consider is the method in which the SIEM gathers it's logs. Syslog is great, but not everything is transmitted well in that format.... *ahem* checkpoint *ahem*. In any event, having a broad range of log collection methods is key. Look for SIEMs that can do things like WMI, .net calls, SNMP traps, and any other proprietary ones you can think of. It is probably best to make a list of the type of devices you have in your environment and ask some pretty pointed questions.
The fourth thing you want to look for is flow data. From my months of experience in security, the host can lie, but the network never does. Flow data is yet another dimension of data that can be used to correlate events and look for anomalies.
Last, and probably most important, is log retention. Any good log management software will provide you with endless combinations of settings to allow for just the right log retention period by device. Don't settle for anything less.
Remember, a SIEM needs to be as functional as it is usable. Really, in this day and age, a usable system that flows and has lots of white space etc is a bare minimum. If the front-end is klugy, run and never look back.
Wednesday, September 26, 2012
GCIH Certified!
Yesterday I finally took my GCIH exam after taking the Sec 504 course a few months ago.
It was a fairly comprehensive exam, but I think the 504 course is a little on the basic side. I like the SANS stuff because you get exposed to some tools / techniques that might take you some time to figure out organically on your own.
In any event, 1.5 hours after I started the exam I walked out with a 92%. Not too bad!
It was a fairly comprehensive exam, but I think the 504 course is a little on the basic side. I like the SANS stuff because you get exposed to some tools / techniques that might take you some time to figure out organically on your own.
In any event, 1.5 hours after I started the exam I walked out with a 92%. Not too bad!
Wednesday, September 19, 2012
ie_execcommand_uaf xp only?
With the release of the latest Internet Explorer 0day exploit, I was eager to get an environment up to test it out.
I decided to test out two environments.
1) Windows 7 fully patched with the latest Java version and IE9
2) Windows XP SP3 fully patched without Java and IE8
My testing proved unsuccessful against the configuration (1) above. I was very successful in crashing IE 9, but was not able to exploit it at all. I would have to do some more analysis with this, but a quick google search reveals that I am not alone in this finding. I think that scope of this 0day might have been exaggerated a bit. I did not spend a ton of time on this, but I did try of couple of different configurations.
Configuration (2) above, however, did not fair so well. IE8 still seems to be in use at about 20% of all browsers (and probably 90% of all corporate browsers). I think given those facts, this is still a pretty important 0day.
I decided to test out two environments.
1) Windows 7 fully patched with the latest Java version and IE9
2) Windows XP SP3 fully patched without Java and IE8
My testing proved unsuccessful against the configuration (1) above. I was very successful in crashing IE 9, but was not able to exploit it at all. I would have to do some more analysis with this, but a quick google search reveals that I am not alone in this finding. I think that scope of this 0day might have been exaggerated a bit. I did not spend a ton of time on this, but I did try of couple of different configurations.
Configuration (2) above, however, did not fair so well. IE8 still seems to be in use at about 20% of all browsers (and probably 90% of all corporate browsers). I think given those facts, this is still a pretty important 0day.
Tuesday, August 7, 2012
Two factor Authentication on Fedora 17
It turns out that adding an extra level of security to fedora 17 is quite easy.
The google-authenticator PAM module is easily installed via yum. Once installed, you simply have to edit the /etc/pam.d/sshd configuration to require the pam module as per the instructions located here.
As the user you wish to use two-factor authentication with, you need to run the google_authenticator bin from the command line. It will create an address that you can navigate to and take a picture with the google-authenticator app on your andriod device.
Voila, two factor authentication on your sshd!
Enjoy.
The google-authenticator PAM module is easily installed via yum. Once installed, you simply have to edit the /etc/pam.d/sshd configuration to require the pam module as per the instructions located here.
As the user you wish to use two-factor authentication with, you need to run the google_authenticator bin from the command line. It will create an address that you can navigate to and take a picture with the google-authenticator app on your andriod device.
Voila, two factor authentication on your sshd!
Enjoy.
Friday, April 20, 2012
Automating Password Checkouts with Python
Security tools like password managers suck. Now don't get me wrong, from a security perspective, they are a really good. They do what is needed of them. You can set up generic accounts in a password checkout system (such as adventnet, or powerkeeper) and then track usage of those generic accounts. You can use these systems to manage password so that you don't have to worry about password reuse, or silly things like password ageing.
The problem with some of these tools is that they make the process so onerous. The system that is used at my company takes at least 10 click (along with mouse movements, etc) to get a password out. No wonder nobody likes using it. Having done a fair bit of web programming / design myself, I am just simply baffled by how unusable some products are.
I decided today to spend some more time learning about python. As usual, I looked for a problem that I could solve.. and this happened to make the top of the list.
I'm not going to post my full code, but rather, I'm going to go through some of the things I looked at while building this.
1) Handel SIGINT
The first thing I wanted to take care of was if someone tried to terminate my program before it was finished. I wanted to intercept this and handle it by clearing the terminal window.
In python this can be handled by the signal library. You can find all you need to know at this link.
2) Password Input
I didn't want the password to be added via the command line, but rather by input directly into the python program. The raw_input command works well, but it echos the input back to the screen. You probably don't want that in case the session is being logged. It turns out that there is getpass library that can be used for these situations. Take a look at this answer.
3) Username to the system and username being requested should be imputed on the command line.
It turns out that argparse works perfectly for this type of situation. You just need to set the required = True setting on a parsed argument.
4) HTTP Interaction
This password manager operations from a website with basic authentication and cookies. Originally, I started using the base urllib and urllib2 libraries, but then found the httplib2 library. It was just much cleaner (imho) to use this than the base libraries.
5) HTML Parsing
There is no formal integration with the password manager, so I have to resort to pulling information out of html files to figure out what is going on. I relied heavily on the live https headers plugin with firefox to determine exactly what was being sent up to the server. As for the HTML parsing / searching in python, I found Beautiful Soup to be beautiful indeed. Worked perfectly and provided enough options for me to parse through the results and get the data I needed to any requests.
That about sums it up. I'm really starting to like the python language!
The problem with some of these tools is that they make the process so onerous. The system that is used at my company takes at least 10 click (along with mouse movements, etc) to get a password out. No wonder nobody likes using it. Having done a fair bit of web programming / design myself, I am just simply baffled by how unusable some products are.
I decided today to spend some more time learning about python. As usual, I looked for a problem that I could solve.. and this happened to make the top of the list.
I'm not going to post my full code, but rather, I'm going to go through some of the things I looked at while building this.
1) Handel SIGINT
The first thing I wanted to take care of was if someone tried to terminate my program before it was finished. I wanted to intercept this and handle it by clearing the terminal window.
In python this can be handled by the signal library. You can find all you need to know at this link.
2) Password Input
I didn't want the password to be added via the command line, but rather by input directly into the python program. The raw_input command works well, but it echos the input back to the screen. You probably don't want that in case the session is being logged. It turns out that there is getpass library that can be used for these situations. Take a look at this answer.
3) Username to the system and username being requested should be imputed on the command line.
It turns out that argparse works perfectly for this type of situation. You just need to set the required = True setting on a parsed argument.
4) HTTP Interaction
This password manager operations from a website with basic authentication and cookies. Originally, I started using the base urllib and urllib2 libraries, but then found the httplib2 library. It was just much cleaner (imho) to use this than the base libraries.
5) HTML Parsing
There is no formal integration with the password manager, so I have to resort to pulling information out of html files to figure out what is going on. I relied heavily on the live https headers plugin with firefox to determine exactly what was being sent up to the server. As for the HTML parsing / searching in python, I found Beautiful Soup to be beautiful indeed. Worked perfectly and provided enough options for me to parse through the results and get the data I needed to any requests.
That about sums it up. I'm really starting to like the python language!
Monday, April 9, 2012
Simple Roman Numeral Converter
So I was reading the daily wtf, and noticed this article.
Since I am trying to learn python, I decided to give this little task a quick shot.
The first thing to do here is to go and read about Roman numerals. Once you do, you will find that the only trick is that if a lower Roman numeral precedes a larger one, it actually acts as a subtract.
Probably not the best python.. but I'm still learning!
Since I am trying to learn python, I decided to give this little task a quick shot.
The first thing to do here is to go and read about Roman numerals. Once you do, you will find that the only trick is that if a lower Roman numeral precedes a larger one, it actually acts as a subtract.
#!/usr/bin/env python import sys ROMAN_NUMERAL_DICTIONARY = { 'I' : 1, 'V' : 5, 'X' : 10, 'L' : 50, 'C' : 100, 'D' : 500, 'M' : 1000 } def IsRomanNumeral(romanNumeralPart): return romanNumeralPart in ROMAN_NUMERAL_DICTIONARY def GetDigitValueOf(romanNumeralPart): return ROMAN_NUMERAL_DICTIONARY[romanNumeralPart] args = sys.argv if (len(args) < 2): print "Please pass an argument to convert." sys.exit(0) romanNumeral = args[1] decimalNumber = 0 counter = 0 while counter <= (len(romanNumeral) -1): currentNumeral = romanNumeral[counter] if not IsRomanNumeral(currentNumeral): print "Invalid roman numeral... exiting.. " sys.exit(0) currentDigit = GetDigitValueOf(currentNumeral) if (counter + 1 >= len(romanNumeral)): decimalNumber = decimalNumber + currentDigit break nextDigit = GetDigitValueOf(romanNumeral[counter + 1]) if (currentDigit < nextDigit): decimalNumber = decimalNumber + nextDigit - currentDigit counter = counter + 2 else: decimalNumber = decimalNumber + currentDigit counter = counter + 1 print romanNumeral + "=" + str(decimalNumber)
Probably not the best python.. but I'm still learning!
Friday, March 9, 2012
Fedora 16 Tripwire(OS) Installation
Today I spend some time installing Tripwire Open Source. With the binaries already being present in the Fedora 16 yum repos, it was pretty easy to get set up.
As root:
The RPM comes with a default settings already configured. You can see them if you browse to the /etc/tripwire directory on your system. There are a couple of steps that you have to follow before you can initialize the database, however.
As per the docs (the man pages have all the info you are looking for) you need to set up both a site and a local key. The site key is used for encrypting the policy files across multiple systems. The local key is used for encrypting files used only on the local machine. The docs state that they one or both of the keys may be required based on what operation is being conducted. I just set up both keys. Remember to use strong pass-phrases. The key locations are configured in the /etc/tripwire/twcfg.txt file, which will later be encrypted for use by the system.
Now that you have the keys configured, you can go ahead and encrypt the configuration and policy files. Tripwire does this so that the files in use by the tripwire system cannot be modified. If an attacker does get in, technically they can't modify those files.....
After that you can run the tripwire database init.
After that, you should be able to use tripwire open source.
As root:
yum install tripwire
The RPM comes with a default settings already configured. You can see them if you browse to the /etc/tripwire directory on your system. There are a couple of steps that you have to follow before you can initialize the database, however.
As per the docs (the man pages have all the info you are looking for) you need to set up both a site and a local key. The site key is used for encrypting the policy files across multiple systems. The local key is used for encrypting files used only on the local machine. The docs state that they one or both of the keys may be required based on what operation is being conducted. I just set up both keys. Remember to use strong pass-phrases. The key locations are configured in the /etc/tripwire/twcfg.txt file, which will later be encrypted for use by the system.
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
Now that you have the keys configured, you can go ahead and encrypt the configuration and policy files. Tripwire does this so that the files in use by the tripwire system cannot be modified. If an attacker does get in, technically they can't modify those files.....
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
After that you can run the tripwire database init.
tripwire -m i
After that, you should be able to use tripwire open source.
Subscribe to:
Posts (Atom)