Wednesday, February 28, 2007
Friday, February 23, 2007
So, a while ago I posted this visual cloud representation of a Clusty search engine query for "log management" and I said "notice something interesting?"
This picture actually shows what was so interesting (I just rerun the query today to make sure it is still there)
So, seeing this again caused me to philosophize :-) a bit: is it a good thing that your very name becomes fused with a specific technology? I do love log management, but should I be happy (or sad?) that Clusty thinks that "anton" is closely related to "log management."
If you think that it was an ego post, skip it :-)
Thursday, February 22, 2007
Nothing new here for most of my readers, but those folks who read too much vendor marketing about "saying ahead of the hackers" should pay attention.
Wednesday, February 21, 2007
Here is a fun and disturbing trend; a real one this time :-) since we all saw a bunch of fake "trendware" being brought up during the RSA marketing crapstorm ...
So, imagine the world without legitimate vulnerability research. Scary like its 1992, right [unless your name is Pete] ...
It starts from this: "Current law (in the U.S., the U.K. and several other Western nations) allows flaw hunters like H.D. Moore (Month of Browser Bugs) and Kevin Finisterre (Month of Apple Bugs) to publicly disclose critical vulnerabilities to their hearts' content. Conversely, searching for flaws in a public Web application [public web site] is illegal, in no uncertain terms."
More on this: "The Chilling Effect" that says: "But then, right when security researchers were getting good at the disclosure game, the game changed. The most critical code moved to the Internet, where it was highly customized and constantly interacting with other highly customized code. And all this Web code changed often, too, sometimes daily. Vulnerabilities multiplied quickly. Exploits followed. But researchers had no counterpart methodology for disclosing Web vulnerabilities that mirrored the [some say crappy, but still somewhat workable - A.C.] system for vulnerability disclosure in off-the-shelf software. It's not even clear what constitutes a vulnerability on the Web. Finally, and most serious, legal experts can't yet say whether it's even legal to discover and disclose vulnerabilities on Web applications like the one that Meunier's student found [but most say its not - A.C.]. [see article for the story]"
And here too: 'Grossman's take is that Web security significantly suffers from the legal climate that prohibits so many trained eyes from inspecting Web applications, which are developing new--insecure--functionalities every day. I asked Grossman if he had a prediction for the future. "Yeah," he said. "The bad guys are gonna win."'
So, what do we have here? One can look for vulnerabilities ln in COTS or OSS software and then disclose them in whatever fashion (even "irresponsible" disclosure is still legal, IMHO but IANAL). But if you write a custom web app, as many do and many-many-many :-) more will do in the coming years, and deploy it on the web, nobody but you can legally discover vulnerabilities in it. See the point? If vulnerability disclosure does indeed improve the software security, a similar force will not be active in the realm of web applications. And as more applications move to the web, we are looking at 1992 pre-Bugtraq world all over again, which can be summarized as "those who know and dare, 0wn" :-)
But you know what? There is an opposite but equally disturbing trend related to liability. Few picked this one yet. So, many folks have been advocating that software vendors be liable for vulnerabilities whatever resulting vulnerability consequences such as data loss. For example, here Bruce Scheier (one of the most vocal proponent of this) says that "Liability changes everything. Currently, there is no reason for a software company not to offer feature after feature after feature, without any regard to security. Liability forces software companies to think twice before changing something. Liability forces companies to protect the data they are entrusted with. Liability means that those in the best position to fix the problem are actually responsible for the problem."
And here is the fun thing: many agree that it is very hard to sue a software vendor if you lose the data due to their vulnerability, but you know what? You can sue a web application operator or a web site owner if they lose your data! Specifically,
Can't sue SAP, can sue Salesforce.
Can't sue MS for Office, can sue Google for Docs.
Can't sue Mozilla for Thunderbird, can sue Yahoo for Yahoo Mail.
Isn't it fun?! In other words, sue the software vendor for vuln-resulted data loss - get trouble, sue the SaaS vendor - get cash!
Am I wildly off base? Comment away!!
Tuesday, February 20, 2007
Monday, February 19, 2007
- "Known by their Pharisaical stance, Consultants are the high priests of the Compliance Cult. "
- " ... They [vendors] have the fatted calves and doves for you to buy and sacrifice at the alter of the Golden Calf under the watchful eye of the High-Priest Consultant."
- "Compliance Is Not A Vending Machine"
1. 70% of exploitable web sites is waaaay to low. All but a very few are in fact "hackable"
2. The number is waay too high. Maybe that many are vulnerable, but surely not exploitable.
So, what's your take on this split?
Good question indeed!
"Some end users may help, but you can't rely on all of your users to do anything. End users are hopeless. If you use that as your first premise, you've got a better chance of building a truly secure environment."
One thing on the list that is somewhat related to infosec is "Personal Privacy Concerns." Specifically, they say that "opportunities for identity theft, online fraud and cyberterrorism will be greater and far more sophisticated than we can begin to imagine in our primitive circa-2007 paradigm."
Friday, February 16, 2007
Will try to make this periodic... here are the top popular posts from my blog according to Google Analytics.
- "So, Is Security An Art?"
- "On Getting to Blocked Web Sites"
- "Security vs Networking"
- "My Security Predictions for 2007 ... Go!"
- "On "TJX Was Not PCI Compliant. Who Pays?"
- "Will security ever "get done?"
- "On Common Event Format (CEF)"
- "Anton Security Tip of the Day #3: Watch for Failures and Successes"
- "Practicing "Best Practices" vs Doing Good Work?"
- "ROI on Not Getting Your Ass Whooped"
BTW, can anyone suggest an automated way to show top popular posts from a blog? I googled around and found nothing that worked for Blogger...
Thursday, February 15, 2007
Following the now old :-) "tradition" of posting a security tip of the appropriate time interval (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 Security Tip of the Day #8: What Just Changed?
Let's close our eyes for a second and dive deep into the bizarre and menacing world of a Windows event log. As I mentioned before, massive Windows server log collection got a jump start in recent years due to wide availability of agentless Windows log collection tools, such as Project LASSO. (yes, many people think that agents suck event when they are useful - weird, isn't it?)
Windows event logs, the "Big Three" of System, Security and Application as well as other logs, share a lot of contradicting properties: way too much detail in some areas and missing critical info in others, consistent and thoughtful design here and sheer stupidity there, nice structured data sometimes and confusing mumbo-jumbo in other cases. And the universe of the event log is never static, the whole thing flows and morphs with each Windows release and at time with each update. New event IDs are being created, changed and loaded with new roles and new info.
In this tip, we will look at some fun Windows log entries and explain their meaning for your organization as well as cover what you should do if you encounter them. Given that the realm of Windows event log is so huge, we will start from looking at events that indicate changes of different kinds, mostly configuration and user account. So, what just changed?
I. "Computer Account Deleted" or "User Account Deleted": obviously, service or user account was deleted. Who did it? When? Why? Answer all the questions above and then you can go back to sleep - or to your incident response plan :-)
II. "Computer Account Created" or "User Account Created": same thing - depending upon when? why? who? this event means nothing or something pretty ugly.
III. "Computer Account Changed" or "User Account Changed": similarly, changes to accounts are reflected in the events containing this text. Account changes do include privilege level changes that are often of particular interest.
At this stage, it might be appropriate to ask: why aren't we going by Windows event ID to identify the above events of interest, but instead choose to use the above text blurbs? Well, up to Vista, Windows event IDs often aren't :-) Meaning that they don't identify the event sufficiently. Sometimes, they are overloaded and the same ID applies to very different things. Sometimes, the opposite happens - same event, different IDs (e.g. a lot of login/logout stuff)
IV. "Policy Change": might mean almost anything on a Windows system. Thus, we can't really tell you much; you need to read the event to see what actually changed (if anything!)
V. "The system time was changed" might not matter that much, but if you are looking to use your logs as forensic evidence (i.e. use them in court) you might want to track all the time changes since they will affect the log timestamps on the server where time changed.
VI. "The following schema object was modified" oooh, don't you love Active Directory! This indicates that some of the AD objects changed - fortunately, the object name will be in the same event.
So, to conclude, make sure that you collect Windows event logs and analyze them on an ongoing basis, preferably using your log management system.
Seriously, people, will you communicate less if you know your ISP logs all connections? May I also remind you of this blurb.
Wednesday, February 14, 2007
Monday, February 12, 2007
So, I was reading this book the other day which was, for the umpteenth time, explaining "how is [information] security like a castle." You know, all the usual stuff about the walls, gates, inner fortress, moat, archers, tripwires, mantraps, vandals outside and malignant insiders - where else? - inside, etc which are commonly mentioned when people talk about this immortal metaphor. However, are we taking this one too far? Just as a mental exercise, let's think: how is modern information security NOT like a castle? Before you throw your brain into overdrive to ponder this question :-), why do we care? We do, because I think that "the whole castle thing" is getting counter-productive in some respects and limits the progress in the field of information security. There is way too much castle-building going on already :-)
Let me drop a few that I thought about, some obvious and some hopefully less so :-)
- An obvious one that has to do with the nature of information security vs physical castle defense- you can "lose everything" without "losing anything" (in case of an undisclosed information theft)
- Another one: castle defense is inherently static; not much of "active defense" is possible since in the end it boils down to either a prolonged siege or a quick bloody assault. Similarly, organization's network is not going anywhere, but information might be defended more dynamically (if I knew how exactly, I might be launching a new company now :-))
- Audit matters much more in networks than at castles; if your castle security is breached, there is usually nobody left to do audit trail or log analysis
- Here is the opposite: castles has security tools and features "built-in", modern networks - mostly "bolt-on"...
- Many quote the growth of "de-peremetrization" or broader decentralization of security as something that moves security away from the castle metaphor, but, on some level, having one huge castle (in the form of an enterprise network) vs having clusters of "tiny castles" (in the form of "self-defending documents" or whatever similar protected bits of data) is still talking walls and gates
Any ideas, thoughts, anything?
Do you people REALLY need ANOTHER one???!!!
Friday, February 09, 2007
BTW, blogs that require login to leave comments are evil :-)
So, I spent a day at RSA 2007 on Wednesday, from about 9AM to 11PM ... Oh, was it fun!! Here are some highly informal impressions.
First, what's are the Security Buzzwords of the Year?
- Identity - yes, I dare say that the word "identity" blessed the maximum number of vendor booths, even more than ...
- ... yes, more than NAC - and thus I continue to insist that knacking noise :-) will be waning this year. Hopefully - at least the NAC vendors should hope - not the deployments though ... And don't forget to NAP.
- Data security together with leak "prevention"; a formidable presence indeed, given a large number of vendors that "do it" or, more accurately, "claim to do it"
- I guess I should mention endpoint security, but to me it sounds a bit like RSA 2006 ...
Another thing that amazed me was a huge (!) number of new security companies. I have noticed dozens of new vendors, some doing interesting and some boring and old stuff. Initially, when I started my "vendor walk" and passed thru a couple of aisles, I started developing a mild case of "marcusranum-itis" i.e. "same old stuff around", but later I did see a few fun and innovative companies. Also, I met a couple of folks who pitched their new company ideas to me; that was deeply cool as well. So, I hereby proclaim that security innovation marches on, despite some dumb claims to the contrary.
Again (as I commented here), I've seen a few "walking dead" companies present. For some of them, it seems like they truly blew the last 20 grand on the show, hoping - in vain - that somebody [dumb] would buy them. I am talking about those whose quarterly revenue dropped into 6 digits after being in business for a few years. You know who they (you? :-)) are!
What made my RSA day is of course a Security Bloggers Meet-up (that everybody blogged about already - here, here, and yes, even here somewhere); it was a very fun event indeed. For those who are into that sort of thing, a few of the security "celebrities" such as Bruce Schneier and Stephen Toulouse blessed the event with their presence. I am so looking forward to it in 2008!
Finally, somebody mentioned to me that they also had the presentations - you know, people speaking and stuff - at RSA. I was like "Wow, seriously!" :-) And I thought that RSA is mostly known for its parties ...
Thursday, February 08, 2007
Eric Fitzgerald: "I get asked the question pretty regularly how to determine from the security log whether a user logged on using a smart card or not.The short answer is, you can't be absolutely certain. The longer answer is, well, you can be pretty certain for the time being, especially if you're not running any non-Microsoft Kerberos code."
Wednesday, February 07, 2007
Monday, February 05, 2007
Now, I realize that for some this question will sound like "Is plumbing an art?" or even "Is accounting an art?" However, I think now is not a bad time to ponder this one, again. You might recognize this post as being of the type "written_while_flying" :-) only more so since it is actually of a type "written_while_flying_from_Europe." :-)
It started from a CrateMaster 2000 joke about a CVSS. And then this comment came in: "CVSS is the same way. It tries to reduce something to a single number (or set of numbers) that is inherently complex. It gives the appearance of scientific legitimacy to something that is as arbitrary as a game or movie review. ("I give this vuln two thumbs up!!!")."
On the other hand, many folks in our profession are sitting on huge piles of checklists and counting the days when security becomes a formal if unexciting discipline, reduced to a set of simple, and, well, not so simple, rules that everybody would need to follow (and some actually would). A science of sorts. Or a least a management discipline.
As I put it in my landmark :-) post on "Will Security Ever Be Done?" (also some discussion here) I find this complete transition rather unlikely. However, I think vuln scoring is picking a wrong battle for the "security is an art" types. Say whatever you want, but a well-define vuln scoring seems perfectly doable, even if not trivial. And CVSS is a quality effort to get there, with some results to show.
Now, on the other hand, something like incident response will never become formal and will not be reduced to just following a checklist (even though incident response checklists are immensely useful!), just as - analogy alert! - police investigative work will never be reduced to following a formalized procedure ...
How about making the next step along this road: are those parts of infosec which are akin to art immeasurable by definition (kinda like poetry)? This question should be left unanswered for now (esp. given that I am finishing this post at Mini MetriCon 2007)
Sunday, February 04, 2007
"Fancy a free beer, some good company and a bit of fun at this year's RSA conference. We'll be celebrating a year of stunning growth for LogLogic and the market as a whole at TWO - a hot new bar, two blocks from Moscone at..... We'll be throwing in some door prizes...
Last year LogLogic doubled our customers year-on-year, grew revenue three times, and increased customer traction both in the U.S. and abroad across a wide range of industries -- especially financial services, banking, healthcare, and retail. With major news in the works, we are entering 2007 with a bang and are in the mood to invite you to our celebration just before the kickoff of the RSA Conference.The market is moving to LMI, find out why. If you want to have a serious conversation about LMI, great. If you just want to come by and have a beer, we'll raise a glass with you. Attendees will have the chance to mingle with hackers, log gurus, security geeks, and us loggies!
On Monday, February 5th, starting at 6 PM, LogLogic will be hosting a cocktail reception at TWO. TWO is between 3rd and 2nd off Howard, very easy walking distance from the Moscone Center.
Sign up for the event with an RSVP to firstname.lastname@example.org
Here are directions to TWO (the restaurant formerly known as Hawthorne Lane). (http://www.two-sf.com/about/directions.html)."