« February 2008 | Main | April 2008 »
Compliance or risk? Install cameras first.
Our Chief Logging Evangelist, Anton Chuvakin, recently published an article in SC Magazine on an integrated approach to Governance, Risk and Compliance (GRC). He argues that eventually a piecemeal response to compliance won’t do. Rather, why not define some security goals up front, such as “who should have access to what”, then enforce those policies through technologies such as identity management, configuration management and segregation of duties analysis. Of course I agree. Who doesn't? The key word being ‘eventually’.
Let me give you an example from the physical world. LogLogic’s offices are set away a block or two from the main road. In recent months, a number of cars in our parking lot were violated - scratched, windows smashed and GPS devices stolen. What to do? Using the GRC analogy, we might restrict access to enter or exit our parking lot. We could build a fence and install a guard post. While effective, this is a costly and time-consuming approach. What really happened? We installed security cameras. Will this guarantee there are no more incidents? Of course it will not. However, it was quick and cheap and reduced our risk. So far it has helped.
This brings us to the fourth corner of the GRC puzzle – log management. Why not start your GRC initiative with basic user tracking? It is quick and cheap, but it goes a long way. Just by watching you reduce your risk. Having studied user activity for a while, it also becomes easier to take the next step. In our parking lot analogy, by watching the security tapes we might see a lot of strangers entering and exiting our lot at certain times a day and decide that we want to hire an external security firm to patrol the lot at those hours. More about that in a later post. It is no different in cyberspace. Using historical user activity data, I can now target an identity, configuration management or segregation of duties roll-out to start with the most frequently used information assets. And yes, eventually, I will reach GRC nirvana.
Posted March 28, 2008 in | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Quick and Fun Poll on Behavior Change
While I am analyzing my previous poll, here is a quick and fun one: do we change our behavior when monitored? Vote away!
Posted March 27, 2008 in Compliance , Log Management & Intelligence , LogEd , LogMatters , Security | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Imprudent Curiosity?
In the past week, two high profile cases of improper viewing of personal information hit the wires. Ironically, there is much good news in both incidents. Note that these were cases of imprudent curiosity not of information leakage or theft. Workers were caught snooping around and disciplined or fired. The good news is that companies are increasingly tracking user activity, in particular user access to sensitive information. One way to track user activity is by collecting and analyzing log data. Remember to also protect archived log data as legal evidence if you want to use the data to substantiate employee dismissals.
UCLA Health System employees reportedly accessed Britney Spears' medical records without authorization. The Los Angeles Times reported about a week ago that 25 staff members, including six physicians, could be disciplined or fired. UCLA's medical center immediately launched investigations and the UCLA chief compliance officer revealed that the hospital has "people dedicated to looking at records to monitor access". When employees look at a patient's records electronically, they leave an electronic trail. "The systems track which screens they view and for how long".
Days later, news broke about a similar case of 'imprudent curiosity'. The State Department confirmed that that some of its workers had improperly rummaged through the passport files of all three presidential candidates, Obama, Clinton, and McCain. Two contract employees were fired and a third was disciplined for accessing Obama's passport data. A department spokesman said: ``Our initial view is this was imprudent curiosity on the part of these three individuals,'' Still, the State Department was taking steps ``to assure ourselves that it is nothing more than that.''
Posted March 24, 2008 in | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Protecting customer data in mid-market companies
Today we announced our new product line for mid-market companies. These are all-in-one appliances that combine embedded compliance content with real-time analytics and long-term forensic archival. Some customers have compared our new products to the Mercedes C-Class. They never thought they could afford a Mercedes, but now are driving their favorite car.
My conversations with reporters such as Alex Woodie, Paul Korzeniowski, and Zach Church have been thought-provoking and have forced me to articulate what is different about meeting compliance mandates such as PCI and HIPAA in the mid-market as compared to large Fortune 500 organizations.
The bottom line appears that the same compliance and information protection mandates apply in full force to large and small companies. As a consumer, I expect my credit union, local retailer and regional hospital to be equally vigilant about protectiing my personal information, as Britney Spears painfully experienced.
The difference is that small companies have fewer resources, expertise and budgets. The primary competition in the large enterprise is a homegrown solution, whereas our primary competition in the mid-market appears to be 'doing nothing'. It is not apathy or ignorance, because mid-market customers deeply care but they need to do more with less. Unless the solution is highly automated they simply don't have the resources to act.
Posted March 18, 2008 in | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Anton Logging Tip of the Day #14: More access_log Fun: What Are You Not GETting?
Following the tradition of posting a tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.
So, Anton Logging Tip of the Week #14: More access_log Fun: What Are You Not GETting?
In this tip, we will look at some bizarre artifacts that show up in web server access logs today. Here we have a production log from an Apache web server that is full of interesting (and sometimes ominous!) little mysteries that we will investigate in order to determine their impact on security and operational health of the site.
Logs do contain more mysteries than we have time, so we will focus on a few of them: specifically, unusual web request methods. Let's see who is trying to POST or use some other method (OPTIONS, HEAD, PUT or something - see a list here) on our site, instead of just GET'ting the content (GET command is used by web browsers to retrieve the pages, while POST is used to upload content, press buttons, etc - at least in "web 1.0" land - see earlier tip #12 where POST request was found in proxy logs)
Here is one little artifact that attracted my attention due to a POST request vs a web forum as well as a battery of slashes (which actually increases in subsequent request - of which there were many)
10.10.102.250 - - [12/Feb/2008:16:10:50 -0500] "POST /phpBB3////ucp.php?mode=register&sid=e5efaa77a777066c61f71808e9e57b19 HTTP/1.0" 200 14397 http://www.example.com/phpBB3///ucp.php?mode=confirm&id=7640df05c7e24b7acf7a68800fe6dc59&type=1&sid=e5efaa77a777066c61f71808e9e57b19 "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126"
... more...
10.10.102.250 - - [12/Feb/2008:16:12:29 -0500] "POST /phpBB3///////////////ucp.php?mode=login&sid=e5efaa77a777066c61f71808e9e57b19 HTTP/1.0" 200 9355 "http://www.example.com/phpBB3//////////////ucp.php?mode=login&sid=e5efaa77a777066c61f71808e9e57b19" "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126"
This one really is a mystery; what do we know about it? The server responded to the request OK (code 200), so the POST actually happened. The first request was a request to register with a web discussion board and the second was a request to login. Multiple slashes are actually ignored by the web server, so why put them in the request (no answer)? Also, I think that the User-Agent is spoofed ... do you know why? Finally, if I see something like that in my logs, I will definitely investigate it, primarily due to the fact that Apache responded with 200 OK code.
The next one is so classic it it dumb (and so dumb, it's a classic :-))
10.10.123.226 - - [12/Feb/2008:03:46:54 -0800] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 - "-" "MSFrontPage/6.0"
10.10.123.226 - - [12/Feb/2008:03:46:55 -0800] "OPTIONS / HTTP/1.1" 200 20210 "-" "Microsoft Data Access Internet Publishing Provider Protocol Discovery"
It is probably one of the ancient IIS attacks (check out this fun BlackHat preso on that, circa 2003) - why would someone probe for it now is beyond me. In any case, Apache on Linux and "*.exe" don't mix :-)
The final log record is also fun:
10.10.101.222 - - [12/Feb/2008:15:33:22 -0800] "PUT /zk.txt HTTP/1.0" 405 223 "-" "Microsoft Data Access Internet Publishing Provider DAV 1.1"
The above uses a PUT request which is pretty much deprecated now; the purpose of the above is clearly malicious. In fact, modern Apache shouldn't even allow it, thus it responds with code 405 "Method Not Allowed." Nothing to worry about (even though some poor critter got owned with that! BTW, if you follow that link, check out HTTP response code 201 - if you see it in your logs, run! :-))
Overall, if you see too many POSTs or too many "GET then POST" sequences from the same IP in rapid succession, investigate it since no legitimate access should produce such a pattern...
As further reading, I heartily recommend this paper: "Detecting Attacks on Web Applications from Log Files"
Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.
Posted March 12, 2008 in Innovation , Log Management & Intelligence | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Poll #7: What tools do you use for Windows Event Log collection?
My next fun logging poll is here - please vote! It is about tools for centralized collection of Windows Event Log from servers and other systems. One of the somewhat surprising discoveries from my previous poll was that few people look at Windows logs; this poll drills down into it.
And, don't forget that ProjectLASSO Windows event collector allows people to grab Windows event logs remotely without those hated agents...
Past logging polls and their analysis:
Posted March 07, 2008 in Innovation , Log Management & Intelligence , Project Lasso | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Logging Poll #6 "Which Logs Do You LOOK At?" Analysis
This poll on looking at logs poll was relatively popular; lets see what we can learn (live results are also here).
First, what are the top 3 log types that people look at? They are:
- Unix/Linux server syslog
- Web server logs
- Firewall logs
How does that compare with the top 3 log types that people collect (see picture showing results from my previous poll below)?
These are:
- Unix/Linux server syslog
- Firewall logs
- Web server logs
Huh? They are the same - doesn't it just make sense? What are the possibilities here?
a. People only collect the logs they plan to look at, OR
b. People only look at logs they collect (duh!).
Strangely, I find a) unlikely; I think most people collect more than they can review and that the incident/issue response and compliance needs drive collection more than review or analysis.
Another observation is that all of the "big 3" log types are useful for security, operations and compliance and not just for security (like NIDS/NIPS logs). Is that why they are so popular?
Second, I was fearful that "I only look at whatever logs needed for the incident/issue investigation" will win. It didn't!!! This to me indicates that proactive log review is not as unpopular as I feared. Good! It is working.
Third, obviously, nobody (well, 4%...) looks at all logs they collect.
Fourth, much more people look at Unix/Linux logs than Windows server logs (factor of 3x); this is not entirely unexpected and my next poll will drill down into this.
Finally, I am SHOCKED that people don't look at NIDS/NIPS logs (only 11% do). Why have you deployed those "beasts" if you don't look at what they produce? Then again, maybe you haven't...
Next poll coming up!
Posted March 07, 2008 in Innovation , Log Management & Intelligence | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Audit/Monitor Controls or Audit/Monitor BEFORE Control?
Back in 2004, Forrester paper called "The Natural Order Of Security Yields The Greatest Benefits" proclaimed that "the adoption of security has a natural order: 1) authentication; 2) authorization; 3) administration and 4) audit." Note that audit which, in this case, broadly includes audit, monitoring and detection, comes last. It seems to be fairly in line with common sense: you audit the controls after you put them in place; you monitor after you have authentication and authorization taken care of and you detect the violations after you organized your administration.
The paper clarifies: "With people and contexts defined, protective controls in place, and policies outlined, the fourth set of questions [i.e. regarding the audit] includes: “What happened?”, “What is happening?” or, especially, “Is it working?”
However, is this really so? Or, is this always so? First, when reality collided with plans, many of the organizations that followed that wisdom got mired in one phase (e.g. in trying to get authentication under control) and ended up having no audit whatsoever: in other words, they are flying blind while implementing controls! Second, in some cases controls (authentication, authorization, administration) will actually be impossible to implement, while audit will be possible. Imagine retrofitting a legacy application for granular authorization? Third, in some cases implementing prevention/control will be much more complicated, compared to implementing audit: thus, people will face a choice between a half-baked control to a full-blown audit capability? An example will be managing which file each user can access vs monitoring/auditing which file each user have accessed. The latter is doable, while the former is next to impossible. Another way to phrase it is "reactive but possible" vs "proactive but impossible" (hint: pick the former :-))
I think the idea of putting audit first in some cases is the way we'd need to progress. "Wow, what a blasphemy!", some might say ... After all, if you have not defined controls, what are you going to audit? But remember that audit is meant broadly in this context and thus the opposite question is very relevant: what are you going to control if you have no idea what is going on? People sometimes define a security policy based on how things should be (and then WSJ happens - refresh your memory of the "WSJ saga" here), but then spent years trying to bring policy and reality together (and end up with an environment which is "half-controlled") Won't it be better to audit first, then control? Or, at the very least, to run BOTH project at the same time so that improvements in control are audited and audit discoveries lead to control improvements!
Obviously, "do IDS before IPS" falls under the same principle: monitor first, [try to] control second. Here is another example: implement log management before identity management. Looking at logs will tell you what privileges the users actually use for doing their daily jobs. Then you can mix it up with what the idea access policy will be.
So, think about it! Questioning the common wisdom does often bring interesting insights.
Posted March 06, 2008 in Innovation , Log Management & Intelligence , Security | Permalink | TrackBack (0)
« February 2008 | Main | April 2008 »
Audit/Monitor Controls or Audit/Monitor BEFORE Control?
Back in 2004, Forrester paper called "The Natural Order Of Security Yields The Greatest Benefits" proclaimed that "the adoption of security has a natural order: 1) authentication; 2) authorization; 3) administration and 4) audit." Note that audit which, in this case, broadly includes audit, monitoring and detection, comes last. It seems to be fairly in line with common sense: you audit the controls after you put them in place; you monitor after you have authentication and authorization taken care of and you detect the violations after you organized your administration.
The paper clarifies: "With people and contexts defined, protective controls in place, and policies outlined, the fourth set of questions [i.e. regarding the audit] includes: “What happened?”, “What is happening?” or, especially, “Is it working?”
However, is this really so? Or, is this always so? First, when reality collided with plans, many of the organizations that followed that wisdom got mired in one phase (e.g. in trying to get authentication under control) and ended up having no audit whatsoever: in other words, they are flying blind while implementing controls! Second, in some cases controls (authentication, authorization, administration) will actually be impossible to implement, while audit will be possible. Imagine retrofitting a legacy application for granular authorization? Third, in some cases implementing prevention/control will be much more complicated, compared to implementing audit: thus, people will face a choice between a half-baked control to a full-blown audit capability? An example will be managing which file each user can access vs monitoring/auditing which file each user have accessed. The latter is doable, while the former is next to impossible. Another way to phrase it is "reactive but possible" vs "proactive but impossible" (hint: pick the former :-))
I think the idea of putting audit first in some cases is the way we'd need to progress. "Wow, what a blasphemy!", some might say ... After all, if you have not defined controls, what are you going to audit? But remember that audit is meant broadly in this context and thus the opposite question is very relevant: what are you going to control if you have no idea what is going on? People sometimes define a security policy based on how things should be (and then WSJ happens - refresh your memory of the "WSJ saga" here), but then spent years trying to bring policy and reality together (and end up with an environment which is "half-controlled") Won't it be better to audit first, then control? Or, at the very least, to run BOTH project at the same time so that improvements in control are audited and audit discoveries lead to control improvements!
Obviously, "do IDS before IPS" falls under the same principle: monitor first, [try to] control second. Here is another example: implement log management before identity management. Looking at logs will tell you what privileges the users actually use for doing their daily jobs. Then you can mix it up with what the idea access policy will be.
So, think about it! Questioning the common wisdom does often bring interesting insights.
Posted March 06, 2008 in Innovation , Log Management & Intelligence , Security | Permalink | TrackBack (0)
April 2008
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
Categories
Archives
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005