Wednesday, August 30, 2006
So, I came back from the Honeynet Project Annual Meeting (I am member of the Project now), and it just confirmed the trend. And, no, I am not sharing :-)
As far as honeypots are concerned, most are getting owned nowadays through either password guessing or web application vulns (yes, Virginia, even those with glaring root holes...) - e.g. see this report from a fellow Honeynet researcher.
tags: security, honeynet, honeypots, attacks
Holy cow, there is some serious insight here, folks! I bet they'd follow up with: "Study finds murder can't be prevented", "Study finds robbery can't be prevented", etc...
Tuesday, August 29, 2006
"Security theater is not real security, but terrorism is theater. "
"The real targets of terrorism are the rest of us: the billions of us who are not killed but are terrorized because of the killing. The real point of terrorism is not the act itself, but our reaction to the act. "
"Also don't forget that a determined suicide terrorist isn't going to be stopped by all the security at airports: one of the British plotters was an airport employee with an all-areas pass. "
"And don't forget that even if they had actually succeeded in blowing up a dozen airliners over the Atlantic, air travel would still be safer than driving!"
Monday, August 28, 2006
Schneier on Security: Stupid Security Awards Nominations Open: "... After submitting his fried pastries to an x-ray scan, no fewer than eight TSA employees were gathered around the box, stroking their chins, and debating: do we confiscate only the liquid-filled donuts? What of the powdered, jelly-filled? Surely something that has both white powder and liquid is contraband, but what of icing?"
And, get your nominations for Stupid Security in
Saturday, August 26, 2006
Cauvin on PM blog has this super-insightful post on writing software requirements. Lately, I've been more involved with this and so this specific point was really useful ... so I am sharing it.
So, imagine you are designing a solution that will save the user files and will have them available in case the user needs it. Sometimes it is called a "a backup solution," but I am intentionally not using this term (you'd see why later). "... Similarly, conventional requirements documentation for a backup service would include specifications such as:
The system shall enable the user to backup files.Or a use case such as:
Yet these specifications and use cases do not represent real requirements. No user wants to backup files [!]. They want to be able to restore files. Backing up the files is an unfortunate design necessity to which the user would prefer to be completely oblivious.
A product manager who includes these design specifications in a requirements document is doing the company a disservice."
Think about it and the sheer ingenuity of this will dawn on you! And read his full post, of course.
"On a scale of zero to ten, with zero representing impossibility and ten representing complete metaphysical certitude, what is the chance that the IBM takeover of ISS strikes a death blow to the pure-play security market? "
Read answers from RICHARD STEINNON, IT-HARVEST; RICHARD BEJTLICH, TAOSECURITY; MIKE ROTHMAN, SECURITY INCITE; THOMAS PTACEK, MATASANO SECURITY.
So, here is a weird security-related issue that might be just a curiosity, but then again it might be the sign of the future, maybe not as remote as you'd think. For the Gibson- and Stevenson-infected brain :-), it should sound more like the latter.
So, TechDirt reported has this blurb a few days ago: "The police are really good at understanding someone stole my credit card and ran up a lot of money. It's a lot harder to get them to buy into 'someone stole my magic sword.'" But before discussing how law enforcement can address the situation, game developers and players should try to define the border between the game and the real world. For example, most people would accept that if your character is mugged inside a game, then that's part of the gameplay, not a legal issue. But what about counterfeiting gold pieces? What about running a script inside the game that transfers gold from one player to another?'
Another report from them mentions "Over in Japan, a woman has been charged with a crime for breaking into an ex-boyfriend's online video game account and deleting various weapons he had collected."
Wow, that sounds pretty exciting... from both technical and legal point of view. Usually when I hear about "virtual reality" I just snicker, since there is nothing REAL about it, but - guess what? - it just might change... This is clearly a trend to watch.
Security Sauce: Airport Security: Meatspace Intrusion Detection: "Once you extend that signature [what TSA screeners have to look for] set to, well, pretty much everything that's not paper or cloth you're going to have an analysts nightmare because you just did the equivalent of 'alert ip any any -> any any (msg: 'Something bad may have happened!!';)' in Snort. "
What is even more scary is this: the more the TSA screeners look for nail clippers and hair gel, the more likely they are to miss a gun or a stick of C4. Think about it! That is just how humans work (or, rather, fail!)
Friday, August 25, 2006
So, Common Event Format info is out. Do I like it? Do I think it sucks? Does it matter? Here is what I think.
There was a lot of talk about such standards. On our corporate blog we said that "Mary-Ann Davidson, CISO of Oracle, has been promoting an audit log standard for years. Others include a spring initiative by NIST to launch Common Logging Interchange Format. SANS deserves credit for picking up the ball where NIST left off. They brought together a wide range of users and "loggies" to debate standards at the recent log management summit [where I presented as well]. And, Amrit Williams from Gartner also published on the topic - such as his May 2006 Gartner publication #G00139205 on log output standards." And there are always IDMEF (largely RIP), SDEE (dormant? dead?) and WELF (not too relevant and not going anywhere fast) ...
Obviously, I'd also prefer something more vendor neutral, but, what is more important I think we should first go for a content, not format standard like CEF. I usually like to structure it like this - one can standardize logs in:
IDMEF? CSV? CEF? WELF? You are talking formats here; slashes, dashes, pipes, spaces, tabs and name=value pairs.
Syslog UDP 514? SQLNet? HTTPS? This is about transport, how log bits travel from there to here and back :-)
How about content? There is really no credible log content standard that defines what is in the logs (and what it means) and not how they are formatted, apart from a long dead and forgotten CIEL. And that is where the greatest need is (and has been for a while)!
I can spew XML and CSV just as well as the other guy, but this is not the problem that people our there are facing. Our log parsing capabilities allow us to chew through any of the current log formats, admittedly, with varying degrees of difficulty. However, understanding logs, whether parsed or free-form English is still a challenge for security and operations folks. If some industry group can standardize the log content, the world would be a much better place. And SANS did pick up this challenge so there is hope that this will finally move forward.
So, as a result, everyone would be able to understand, just by looking at each log record, whether it relates to access failures, system changes, attacks, service restarts, system rebooting, account creation, etc via a clear and open log taxonomy, and to do all that without diving into thousand-page documents.
Can it happen? Yes, if we make it happen!
So, here is something different! A lot of infosec folks (such as Bruce Schneier) made fun of recent airline restrictions (even though in Texas at the airports they actually announce that "jokes about security can get you arrested." Seriously!) Some jokes involved people taking clothes off for "extra security," like here and here at Ryanair site.
But guess what? This actually is much less funny than you think! Our beloved Stratfor reported recently: "officials said they had arrested a man carrying false papers and an apparent suicide bomb -- designed to be sewn into a pair of men's underwear" (subscription required, but surely you read Stratfor already!)
Further, they continue that "a female suicide bomber in Colombo, Sri Lanka, detonated a bomb that was concealed in her brassiere July 7"
Now, do you wonna laugh?!
Here is something interesting for you process-oriented types ... I recently learned of this new security "best practices" framework (some call them governance frameworks), called "Information Security Management Maturity Model" or IS(M)3.
"ISM3 aims to:
- Enable the creation of ISM systems that are fully aligned with the business mission.
- Be applicable to any organization regardless of size, context and resources.
- Enable organisations to prioritize and optimize their investment in information security.
- Enable continuous improvement of ISM systems.
- Support the outsourcing of security processes."
It is also claimed to work - whatever "works" means in case of something as generic - well with other existing frameworks, such as various ISOs, CMU's CMM and other IT management and security management frameworks.
It does mention logging and audit logs, but IMHO, nowhere near enough to be a credible governance framework. Specifically, it has a single reference to logging that goes like this: "Access Control includes Authentication of users or services, Authorization of users or services and Logging of access and use of services, repositories, channels and interfaces."
So, here is a quote: "Networking giant Cisco's acquisition marks a step toward the convergence of the networking and Internet security markets."
Your mission, should you choose to accept it, it to date it! The choices are:
The correct answer is here (it is the paper that the quote came from), but where am I going with this? IBM-ISS thing made some people scream "Convergence!!!", but is it really? Like I implied in one of my earlier papers, security will likely never be fully absorbed into any other space. Sorry, if you think that I lack business sense for suggesting this, but there are some pretty powerful reasons for why security will likely stay separate forever.
Now, that doesn't mean that "network security" won't get fused with "networking" and "system security" won't merge with "system management." But "information security" as a whole likely will likely not be part of a bigger anything. I can think of any uber-smart analogy, but saying that security will merge with networking is akin to saying that /broken analogy alert!/ "physical security" will merge with "banking." Huh? Will networking include some network security, systems include some system security, storage include data security, applications include some application security, etc? Sure! Will any of them become synonymous with the broader security? Not likely!
Will I have to eat some fresh crow meat for this non-prediction in a few years? Maybe, but - hey! - punditry has its risks :-)
I think he is being too harsh on this, 'If I haven't seen it before, it's not allowed' still works pretty well in many areas (such as log analysis), especially if you use a milder version of 'If I haven't seen it before, it's *suspicious*'...
Sorry, this is going to be a somewhat philosophical rant, written on a plane as I am flying to an Annual Honeynet Project Meeting in Chicago.
So, the other day I was talking to a friend who used to do software engineering for a certain security company. In the middle of our conversation he mentioned that he moved away from security and got more interested in other, more "useful" products for businesses and even consumers, since when people buy them "their eye light up" since they bought something they might enjoy using. On the other hand, people [sometimes grudgingly] accept security solutions and that makes creating them somehow less fulfilling experience.
Do you agree? Even if people buy security because they have to (and one can make good money selling some things that people have to buy...), the above argument still stands.
Thursday, August 17, 2006
"But, protocols may allow these communications to transmit confidential information, spyware, keyloggers, worms, viruses, and other security threats into and out of your organization. "
Wednesday, August 16, 2006
Following the new "tradition" of posting a security 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 Security Tip of the Day #2: Watch those Pesky Log Rotation Routines
What is the biggest threat to your Linux logs, which reside happily at their home in /var/log? Is it crackers? Blackhats? Evil BOFH sysadmins? Dumb users? Malware? No, its the log rotation routine!
For example, many Linux distros such as RedHat, Fedora, etc use logrotate tool to get rid of "unwanted" logs. Other distros use other log file rotation tools that accomplish the same. However, many ship with default settings that are not optimized for log analysis and long term retention.
Upon deploying a Linux box one needs to look at /etc/logrotate.com file as well as /etc/logrotate.d/ directory to make sure that you are happy with retention settings (and you shouldn't be!)
One can safely increase the retention of most log files from a default of about 4 weeks (it differs by file type and distro) to at least 12 weeks (about 90 days, a common practice) or even more. While at it, one should also enable old log file compression since it is off by default (for whatever weird reason...) to save some disk space.
Note that if you are using a central log management system, this might not apply to you. But then again, in this case you are farther ahead of most system owners on the road to operational excellence.
'"I truly believe there is no real ROI,' says Kevin Mandia, CEO of the security consultant firm Mandiant. 'A lot of smart people have sat around trying to think about this for the last 10 years and nobody has come up with anything.'"
That is a good point. However, I am somewhat undecided about this one myself, since I've met folks who honestly claimed that they "built the thing" [ROI for security] and their bosses were happy with it (and let them buy all the toys...) and it looked legit.
So, is there an ROI? I guess at this point the debate degrades into Clintonian "what 'IS' is?" :-) ROI is there and the ROI approach is quite effective in selling security to those who believe there is an ROI! Keep it in mind...
It seems that most of those who argue with ROSI, argue with an "R" part - the return. Do you ever get return or you get "loss prevention"? Ah, this one won't be resolved for a while :-)
Are you noticing the same? Lately, when I've been reading various security and near-security media, I picked a lot of stupidity. Is it me? Am I turning into a curmudgeon? And old curmudgeon perhaps? And old cantankerous curmudgeon? :-)
Just yesterday of was reading a ... well, I would protect the guilty and be vague about it this time ... trade mag of a leading security industry association and picked this gem: "professional security professional." Oooh, this takes English to a totally new level.
Overall, I suspect that as security moves more into mainstream (examples abound: rootkit is now a common term, etc) more people who, a few years ago, didn't even dare thinking about writing a paper on security now have an opportunity to soil a few electrons with their "loathsome prose..."
Oops, was it a rant? You bet! :-)
Tuesday, August 15, 2006
Sunday, August 13, 2006
Another perspective on vendor rankings Security Incite: Analysis on Information Security:
"Him[an IT from an SMB]: 'But they aren't in the Leader Quadrant.'
Me [Mike Rothman]: 'So what? Why do you care who sells a lot into the enterprise? That's not you.'
Him: 'Because I care. My CIO used to work for a big company and he believes in the MQ.'
Me: 'Then he's an idiot.'"
Saturday, August 12, 2006
After a recent push to mandate log data retention, people are now pushing to mandate the lack of retention and data destruction... Hey, let's just do both and let the people choose :-)
World Wide Web - Will AOL Goof Trigger New U.S. Law?: "Markey's bill is H.R. 4731, the Eliminate Warehousing of Consumer Internet Data Act (EWOCID). The bill would require Internet companies to destroy obsolete electronic data, and particularly data that could be used to individually identify consumers. "
Friday, August 11, 2006
"Finally it's also clear to me that we need to start some discussions about how to blow up the status quo of security. If there was one thing that was abundantly clear is that fixing holes is not the answer. The people presenting their research can break networks and applications in MINUTES. We've got to start from a blank slate and really rethink the problem space. "
I often feel the same way nowadays, but many solutions that are proposed to 'address this' are kind of naive (like, "let's educate software developers and/or users", etc) So, will this blog post present an answer? No, but it is something I am thinking about :-)
Do you know why the laptop a) had all the data and b) was taken home? Because this employee had a cool idea for a "fascination project" [quote from page 2] which he "'self-initiated" on "his own time." And this pet project required all the veteran data.
The second highlight (should I say "lowlight"? :-)) was related to VA processes and centered around the second instant winner of the idiom contest (takes second place after the aforementioned "fascination project" :-)): "casual hallway meeting." The facts of a breach were reported to the superiors via a "casual hallway meeting." I can picture this: "Yo, Joe, this guy here lost a laptop with 26 m personal records of our veterans!" - "Wow, it sucks! Let's go get some coffee!" :-)
Is this happening at your company right now? I bet'ya, it does! When you think "insider attacks/abuse" you should not obsess over dumpster diving ex-KGB colonels on the Mafia service; think dumb IT pros on their stupidity dis-service...
More fun quotes follow, but do read the report /and weep/, it is just 9 pages and it would help you to learn why Albert Einstein supposedly said "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe..."
Quote 1: "The employee explained that much of the data that he had stored on the stolen external hard drive was for his "fascination project" that he self-initiated and worked on at home during his own time. "
Quite 2: "Mr. McLendon also did not inform his direct supervisor, Mr. Duffy, when he learned of the incident on May 3, 2006. Mr. Duffy advised us that he did not learn of the theft until Friday morning, May 5, 2006, when he spoke with the OPP&P ISO, in what Mr. Duffy described as a rather "casual hallway meeting." "
Quite 3: "Mr. Duffy said he just did not perceive this as a crisis. In hindsight, he added that his greatest regret is that he "failed to recognize the magnitude of the whole thing." "
Thursday, August 10, 2006
Tuesday, August 08, 2006
Disturbing Facts About Google: "7. Google's cache copy is illegal:"
The only thing I have against Google nowadays (he-he, as if anybody cares) is that it's search sucks (sorry - but I have waaay too many examples of searching and not finding to back this up). Not sure who is better nowadays, but somebody likely will appear - remember how Google beat the Altavistas of the world back in the day...
I am looking at "search tools" again, as if the 90s came back with a vengeance :-) and will shoot a blog post detailing my experience with them. A sneak peek: Quintura rocks :-)
Friday, August 04, 2006
So, Anton Security Tip of the Day #1: Crank it Up!
Crank what up? Logging, of course! You'd be happy you did, I promise. The gist of this tip is that if you increase the level of logging on your system (even without looking at the resulting logs periodically...), you'd fare much better in case of an incident. And, by incident here I don't mean that those evil hackers will 0wn you with a custom-coded 0day, but something much more common: a computer crash, spyware problem or system malfunction.
On Linux/Unix it will likely involve editing the /etc/syslog.conf and on Windows it will involve changing the Audit Policy.
Of course, you'd be committing a mistake, if you only turn it on. But that's a separate story.
Wednesday, August 02, 2006
"The U.S. Defense Advanced Research Projects Agency (DARPA) has awarded Lockheed Martin a $1.7-million, 10-month contract to design a remotely controlled nano air vehicle (NAV) that is capable of collecting military intelligence both indoors and in urban outdoor environments.
Although described as a Nano the NAV is not nanometer in scale, instead it is likely to be about 1.5-inches long and similar in size and shape to a maple tree seed, according to Lockheed Martin Advanced Technology Laboratories (ATL), which has been contracted to lead the design team. "