This is Anton Chuvakin original blog (pre-Gartner) that I will now use to backup my Medium blog content (2023+)
Tuesday, September 07, 2010
Log Standards and Future Trends
Enjoy!
Possibly related posts:
Wednesday, June 24, 2009
MUST READ: Best Chapter From “Beautiful Security” Downloadable!
This is pretty much a repost from Mark’s blog, hopefully he doesn’t mind that I am highlighting his awesomeness ;-)
So, “Tomorrows Security Cogs and Levers” by Mark Curphey, by far the best chapter from “Beautiful Security” book (my book review here), is now downloadable in PDF form.
It is hard to decorate this post with a representative quote, but how about this:
“The security tools and technology available to the masses today can only be described as primitive in comparison to electronic gaming, financial investment, or medical research software. […] the information security management programs that are supposed to protect trillions of dollars of assets, keep trade secrets safe from corporate espionage, and hide military plans from the mucky paws of global terrorists are often powered by little more than Rube Goldberg machines (Heath Robinson machines if you are British) fabricated from Excel spreadsheets, Word documents, homegrown scripts, Post-It notes, email systems, notes on the backs of Starbucks cups, and hallway conversations. Is it any wonder we continue to see unprecedented security risk management failures and that most security officers feel they are operating in the dark?”
or
“I was once accused of trivializing the importance of security when I put up a slide at a conference with the text “Security is less important than performance, which is less important than functionality,” followed by a slide with the text “Operational security is a business support function; get over your ego and accept it.””
and
“The areas I’ve pulled together in this chapter—from business process management, number crunching and statistical modeling, visualization, and long-tail technology—provide fertile ground for security management systems in the future that archive today’s best efforts in the annals of history.”
If you are not buying the book, please at least read Mark’s chapter. It exudes pure awesomeness.
Possibly related posts:
Thursday, November 20, 2008
Just Love This: Noisy vs Quiet from Rich
Some quotes: "We get money for noisy threats, and get called paranoid freaks for trying to prevent quiet threats (which can still lose our organizations a boatload of money, but don’t interfere with the married CEO’s ability to flirt with the new girl in marketing over email)."
and
"Slice up your budget and see how much you spend preventing noisy vs. quiet threats. It’s often our own little version of security theater."
and
"The problem is, noisy vs. quiet may bear little to no relationship to your actual risk and losses, but that’s just human nature."
Overall, a MUST read.
God, please, send us some credible security metrics... please.
Wednesday, November 19, 2008
MS AV Out and Free ... Uh-Oh
Is it really "Good-bye Big Yellow and Little Red?" Probably not, as this new offering is aimed at consumers and lower-end SMBs; large orgs will still pay ransom ... eh, subscription fees for their AV. It was also interesting to read some of the comments, like "OMG, I so hate paying for AV... and now I won't have to." If such sentiment is indeed widespread, maybe MS choose a really, really good moment to come out with this!
The most fun comments are found on the OneCare team blog here. Esp. see this one: "a majority of consumers around the world do not have up-to-date antivirus, antispyware and antimalware protection" (now they will, thanks to MS! :-)) and "this new offering will focus on getting the majority of consumers the essential protection they need by providing comprehensive, real-time anti-malware protection, covering such threats as viruses, spyware, rootkits, trojans, and other emerging threats, in a single [FREE!], focused solution."
UPDATE: very funny comments from AV firms and "normal people" (see below the article at the link)
UPDATE2: another very fun comment, including "maybe it's time that Symantec and McAfee start offering free versions of their own antivirus products"
Tuesday, September 16, 2008
Live Blogging from GOVCERT.NL 2008 - David Rice Speaking
The message is the same: cybercrime is due to bad software; market motivates people to create bad software ("don't worry - be crappy" idea); market will fail to create secure software, etc.
Result? The 0wned world.
So, how to you make insecure software MORE expensive to create than secure software? Laws? Insurance? What else will help? Only time will tell...
Wednesday, September 10, 2008
If This Isn't 'Semantic Hacking', I Don't Know What Is...
Think about it...
Worms? RBN? Bots? Rootkits? DLP? NAC? For kids.
Friday, August 22, 2008
RIAA Scum Beaten Back in Court
Tuesday, August 12, 2008
Again, On Laptops and US Borders
"The key to the above paragraph, of course, is "without suspicion of wrongdoing." Indeed, in the policy (PDF), DHS says (emphasis mine), "In the course of a border search, and absent individualized suspicion, officers can review and analyze the information transported by any individual attempting to enter, reenter, depart, pass through, or reside in the United States."" (source)
Fun question that was brought by someone on a security mailing list: if your employer-owned laptop is "captured" by DHS, TSA or Customs AND it has regulated information on it (CCs, SSNs, PHUI, etc), do you have to report it as "data loss"? The chances of that info being lost are definitely much, much higher now AND the control over such data is clearly not in your hands anymore... Niiiiice.
Wednesday, June 25, 2008
11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"
Prerequisite: read this (thanks Raffy). Stop reading right before you reach the last line though :-) Then maybe read this too (thanks anonymous).
Next, insert appropriate morbid jokes <here> for "IDS is dead", "NAC is dead", "GRC is dead", everybody is dead... WTF? Are we at the cemetery or what? Is "dead" dead? Yeah, but it came back as a zombie :-) So, "dead" is a "living dead" "dead" now. Ha*3.
Finally, think! Why were you thinking of buying a SIEM? 'Cause the big "G" in the sky said so? And while you are thinking, check these fun points out:
- Does your SIEM require 17 beefy servers to operate? How many gallons of foreign oil have to go up in smoke to power that mammoth up? And you know what happened to mammoths, don't you?
- If your "high-performance" SIEM appliance can only run 5 correlation rules at the same time, what "high" do they mean, really? Hold this thought....
- Is five field engineers, two developers and CTO enough to install it? Who else needs to help? Ah, sorry, I missed the DBA :-)
- Do you know when "If CustomVariable17 = Value5" condition matches? Will you still remember it in a year?
- Can you tell "taxonomy" from "ontology"? You can now? Good for you. Are you more secure now? More efficient? Compliant?
- How many shifts of security analysts do you have watching the shiny consoles 24/7? If zero, then why - oh - why those consoles are running in the first place? "If a tree falls..." - you know how this one ends. Correct! You get hit by the bough.
- When was the last time you built a custom agent for parsing and normalizing, say, SAP logs? Did it work? What did you do after it didn't? Cried? And did it help? Then a burly vendor SE showed up, charged you $37,600 and left? Happy now?
- Do you automatically correlate IDS/IPS alerts with vulnerability data ... for client-side attacks? Really? :-)
- There are dozens of firewall, IDS/IPS, router, etc brands, each with its own log type. This is actually simple! But there are thousands upon thousands of applications in use today. Some have logs. All are different. Care to build rules for that? Now you finally know why SIEM vendors don't parse their own Java logs (no shit!)
- Do you know what "threat x vulnerability x random()" equals to? Yup, it still equals random(). Automated prioritization, you say?
- Do you know why some SIEM vendors are migrating to IT GRC now? So they can go and die there ... quietly.
All in all, I have to agree with Raffy to a large extent! The world has evolved - and SIEM has not. It might not be dead (as old attacks and defenses never really die and large organization still build and man massive SOCs where SIEM is "a must"), but in this age of web application hacking, CSRF and XSS, phishing, PCI DSS, massive bot armies, client-side 0-days, stealth malware, etc, paying $x,000,000 for a pile of ugly Java code is insane ... As a result, SIEM has greatly diminished in importance and has become just one small thing you might do with logs and some other data. What made it so? Mostly implementation complexity - but a slew of other factors mentioned above as well.
So, consider this instead:
- Compliance? "Sorry, buddy, you need this for compliance, not that. "
- Want to simplify your incident response? Get log management and fly through all your logs, not crawl through some of them.
- Have a very real need to dig into your logs for troubleshooting or tracking that pesky user? Log management works.
Now, what if you have a latent and vague desire to "correlate something" and a million nice greenbacks to flush down the drain? OK, go get your SIEM toy for $780,000 + 20% maintenance/year ... a true bargain (price valid today only).
Finally, I would like to end this on an optimistic note. Do we need more intelligence to analyze the log data we have collected? Of course! Do we have a widest set of log use cases from today's security to tomorrow's regulations? You bet. And, for you Raffy, I'd add "... we also have other data to analyze together with logs." So, can we "reinvent SIEM?" Yes, I think so! It just hasn't been done yet ... For now, just use log management.
Will Idiocy Ever End?
I lamented and ranted and rambled about it (here, here, here), but I am still shocked. I come from academic background myself and it is unthinkable to me that a research physicist today will write a thesis on 2nd Law of Newton or will set to prove that objects tend to fall down while dropped. Or that they, in fact, "fall up."
However, that is the type of stuff I see in academic security papers that I occasionally get to review. Based on our FIRST conversation, other people who happen to retain ties to academia are reporting the same: research work that confuses "phishing" with "fast flux networks" (thanks Jose), inventing a new intrusion detection "paradigm, " and all sorts of other bizarre crap continues to be cooked and submitted to publications.
When will this end? Why can't you people tackle REAL problems? Or at least useful and hard classic problems? Or, at the very least, learn WTF is going on the real world of operational security before you do ANYTHING? The maybe you stop saying things like "in general, IDS is considered to be a security tool" as if it was some kind of Zen wisdom (a quote from a pathetic excuse for a paper that I reviewed recently...)
Friday, June 20, 2008
So, CAN We Have DLP?
Can we have DLP - data leak prevention?
Well, can we have IDS? How about IPS? Can we really "prevent intrusions?" Can we really "control access to our networks?"
The answer to "can we have DLP?" is actually pretty simple: if you think "DLP = box that prevents all data leaks" (and you also think that deploying IPS will "prevent intrusions"), then we can't. Forget it.
But blame the idiots who called it "leak prevention" - if you think that "DLP will prevent all leaks" - sorry, but you are one of them! :-) If you treat "L" not as "leak" but as "loss" and hope that "DLP will prevent all data loss, whether intentional or not," you are an even BIGGER one.
So rambling about "Can DLP Really Stop All Leaks" is pretty silly. No, it can't. Pondering "Is DLP Possible" is just as silly. No, complete prevention of all leaks is impossible, with OR without DLP technology. Go read Mike R instead :-)
Why seemingly smart people behave in such childish manner? I dunno. Scratch all that. Instead ask:
Is today's cutting-edge DLP technologies USEFUL?
And the answer is "Hell yeah!"
If you see how much "fun" sensitive content goes over email (corp and personal web-based), gets uploaded to forums, channeled over IM file transfers, FTP'ed somewhere, you'd scream for one of these boxes. Accidental leaks, email address typos, non-malicious leaks, blatant disregard of security policy for the sake of "productivity", even phishing, "wholesale data theft" and amateur "employee hackers" probably account for 10x (100x?) more damage (in direct losses, brand damage, embarrassment and - yes! - non-compliance fines AND loss frequency) than "uber-hackers" (who might indeed go thru your DLP box like hot knife thru butter.) And if an advanced DLP box does one day stop some determined insider theft, that's just icing on the cake.
That is why smart people don't call it "DLP" - they call it "content monitoring and filtering." This sounds much less sexy, but much more useful. The boxes that will show up on your doorstep will still have "DLP" labels, but what they will do for you is really content monitoring and filtering. And even though it will not stop all data theft, DLP box will likely prove useful more than once...
Finally, all rants about any preventative AND monitoring technologies should really end the same: go refresh your incident response plans.
Possibly related posts:
Tuesday, May 20, 2008
Cloud This, Cloud That...
Ah, weather is nice and warm, fresh wind is cooling the face, security is in the clouds. Security in the cloud? Yup. Or, if you take Mike Rothman here at face value, "lack thereof." Now, we are not talking about "cloud-based security services" here, but about "security of cloud-based services" - big difference!
If somebody asks you "Can you have a secure cloud-based service?" - you need to ask back "What do you mean by "you"?" Seriously! Let's go back to the old joke that "the only computer that is 'secure' is the one that is turned off, cemented into a big concrete cube and stored in a locked room." But whose room? Do you own the room where the aforementioned concrete cube is stashed? No? Then maybe it is no longer 'secure' ... Think "concrete cube in the clouds - then BAM!" :-)
Joking aside, if you think that a system that is located somewhere remotely (you don't control physical security) + Internet accessible (you don't control network security) + neither written nor audited by you (you don't control application security) can be secure, than yes, most certainly you can have a secure cloud-based service. This also reminded me about this post by Richard where he classifies people into "two camps: those who trust their products to operate as expected and those who do not."
Now, let's review some of the issues with security of cloud based services.
First, is there public vulnerability research that made MS IIS and OpenSSH (and OpenBSD) the paragons of software security? No, this part is completely screwed up today as only criminals are "allowed" to do vulnerability research of cloud based-services (and web applications). Comparison here is not in favor of "the clouds," and "legacy" software approach wins hands down (want trusted apps? go audit them!). To remind yourself what the world looked like without public vulnerability research, think back to early 90s: "hot new exploit - telnet as 'root' without any password" (this is where web security stands today, pretty much).
Second, can you make sure that only you will see the sensitive data (or even regulated data: PHI, credit cards, passwords, financials, etc)? Maybe, if you take care of it. As Mike R puts it : "Basically, you can't be sure anything is secure in the cloud, so that means you have to secure it yourself. That means building your applications with some semblance of data protection [...] But ultimately if you can't prove your data hasn't been tampered with and that it's open for anyone to steal, then I suspect your auditor may have a bit of an issue with that."
Third, can you log and audit access to your information, stored and processed somewhere in the cloud? Maybe, if you chose the provider that allows you to do it. For example, I hear that Salesforce.com access logs are good enough to enable most things you can do with OS logs. Otherwise, well, keep begging them to build it; there is no appliance you can buy to plug this hole.
Finally, if we are insane because we use software, what about cloud services? Sorry, multiply that insanity by 10x. Replace today's mantra "I trust my software vendor" with "I trust my cloud provider, their software developers, their outsourcers (if any), the other vendor they mashup with, my ISP (and its ISP, and its ISP, and its ISP, etc, etc), my cloud provider's ISP (and its ISP, and its ISP, etc, etc, etc) and ... oh, wait ... and your software developers who wrote the code that connects to the above in-the-cloud service." Cool, isn't it? :-)
This paper also reminds us about the business angle: "Remember that the storage provider has less to lose than the customer" [that is you, BTW]. At this point somebody has got to ask "is that dirty C-word hiding somewhere here? Is there a compliance angle?" You bet. And it is "simple", really: just compare a) and b) here:
a) you manage a system that contains financial records (SOX anybody?), you screw up and they are lost OR you don't screw up and they are OK (not lost)
vs
b) you DON'T manage a system that contains financial records (SOX still?) - it is in the cloud, you DON'T screw up and they are still lost since your cloud provider screws up.
Who do you think will go to jail? And don't even get me started on the breach disclosure law angle here (if they lose your data, than you are in violation of SB1386 - that is at least my guess ...)
By now, it should be painfully obvious to any and all of my readers that "in the cloud services" are indeed the future of IT! :-) Yes, and security is a great career - with no shortage of challenges to overcome or tall peaks to climb ... now and ever. That is why I love it.
Friday, May 09, 2008
Fun Reading on Security - 2
Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #2, dated May 8, 2008.
So my next iteration of fun reading on security, logging and other topics.
- 0x000000 blog has a neat post on security, word definition and all. It reminds us that "security is forever" since it is about people, not broken technologies. A quote: "And so we will never able to secure other people, they have to secure them self. And we know that they can't." Same blog also have a fun (but a little bizarre with a little 80s feel) interview with Richard Stallman.
- Along the same line, discussion about security industry longevity is here at Gunnar Peterson's blog: specifically, he debates Mike R's semi-humorous prediction that in 2012 there will be 0 "security professionals." Indeed, secure networks + secure OS + secure apps < security.
- Also a very fun read comes from DarkReading: "7 dirty secrets of the security industry." Example quotes: "The goal of the security vendor is not to secure, it's to make money" , "Security vendors want businesses to buy what they sell, so they push specific products to block specific threats "; it also discusses another facet of compliance vs security.
- Fun - and as usual heated - debates about the "AV is dead" and "anti-anti-virus revolt" happen here. Is blacklisting AV dead now? More dead than before? :-) Or just "limited", but still very useful? BTW, Matasano opines on the subject here as well, calling it not a revolution, but a protest.
- The next Carnival of the Security Catalyst Community - April 22, 2008; as always fun. Next carnival Apr 29 is here and the last (so far) one is here.
- Really good look at logging for developers is here. "all too often logging gets treated as optional and not necessary. In this column we will cover the essentials of logging []for developers!] from a security perspective"
- Latest stolen account prices are posted here by AVERT Labs guys. Account with $16,000 goes for about 700 euros (!) Also, Finjan reminds us that top corporations are all owned.
- ISP data retention rears its (ugly?) head again. Good business for LogLogic or privacy nightmare?
- A fun read from Tizor Blog: "How did the TJX data breach happen? Part 1: Anatomy" A must read, with diagrams, etc. "After breaching the TJX wireless system, the attacker was able to gain administrative privileges to the RTS servers located at the TJX corporate headquarters in Framingham, MA."
- A very good read from Greg Shipley: "Risk Management: Do It Now, Do It Right." A lot of interesting bits about CSOs, security technologies evolution, etc. "The journey continues. We invested hundreds of millions of dollars in intrusion-detection systems without a solid understanding of their relative effectiveness and total cost of ownership. The IDS craze led to reinvestments in intrusion-prevention systems that even today are only partially enabled, and PKI is still a bad word in many IT circles. There's no shortage of disappointments on other product fronts."
- "Data Classification Is Dead?" Rich Mogul explains why data classification by the owners is never going to fly... "Enterprise content is just too volatile for static tags to really represent its value. Even those of you in defense/intelligence don’t *really* do granular data classification. " This is a good reminder to shoe that just spout the propaganda "first, need to classify data." Can you hope to do "DLP" without it? Also, read this one from Rich as well: not only you can't classify, you often don't know who owns what.
- Hot, hot, hot! "Snake Bytes " on DarkReading. "We are all in the business of stopping just enough crime to keep us in business." Wow! Definitely a must read.
- Marcus Ranum on logging in Start Trek (read the whole thread): "What do you expect from a starship that runs on Windows-24k? Microsoft added support for syslog in 2348 - citing customer demand - but still
has no Enterprise-class log architecture." :-) - Piece on PCI and log management where a vendor makes an idiotic faux pas by saying that "less than 1% logs are of interest." In reality, all (OK, most) logs are of interest under the right circumstances. And we almost never know which ones we'd need.
- A fun blurb from a lawyer on PCI. Good conclusion too: "Regardless, now is the time for merchants to begin engaging their legal teams to address PCI compliance, and opening the lines of communication between the lawyers and security pros." He also fights the checkbox mentality by saying that "merchants should not view their internal security personnel or QSAs as “rubber stamps” of PCI compliance." I am happy to see this lawyer basically say that if you ignore PCI, your ass is 0wned :-)
On that happy note - see you next time! :-)
Tuesday, May 06, 2008
So Cool: Richard on NAC
I will now start calling him Richard "Both IDS and NAC are dead" Stiennon. Also, he is hereby proclaimed a Mortician of Security Industry :-)
Sorry, it is all in good fun!
More on that tomorrow in my "Security Reading II" piece, BTW.
Wednesday, April 09, 2008
RSA Impressions - 3: CTO Panel
First, a desperate call to other security bloggers: is anybody attending this panel (BUS202)? It is FUN, but I have to run for a meeting in, like, 10 minutes.
Most trends discussed so far are kinda well-known (SaaS, in-the-cloud this and that, security of infrastructure-> security of data and now of "interaction", server, desktop and storage virtualization, etc), but "IT consumerization" is a huge f*ing elephant in the room. "Security in the age of 'IT by users', not 'IT by IT'" is indeed darn scary! I guess it would be the "New Wild West" :-)
I am also happy that somebody brought up 'everything that needs to be invented is already invented in security' and then dispelled this ugly and idiotic myth.
Another fun one mentioned is a change from "security of bad/good" to "security of flowing risk scale." It sounds deceptively simply, but it actually pretty profound: as opinions about, say, data criticality for business change, so does the risk/impact of said data loss. Not "loss of router = bad", but "loss of this data today = 3 of 10 'badness'"
I was also darn happy to hear that panelists accepted that our security defenses are not prepared for "unknowns" and that "attackers lead - security follows." Also, it is neat that somebody also mentioned that "Security is an art!" today.
A lot of fun security implications of "virtualization in the cloud" (like Amazon service) were mentioned as well: think 'your "own little IT" outside the company for $5 and all the security team will see is web traffic.'
Sorry, I have to break my "transmission" and run to that meeting ...
Tuesday, April 08, 2008
RSA Impressions - 1
So what if a control X is missing? Really? Why the f people need to care? Richard said it well here too.
And the reason there is more of the former (add missing control) and less of the later (stop loss), because they themselves don't know whether what they sell will decrease the loss ... It does suck, doesn't!
And then you meet somebody honest who sells incident response tools :-) And it has been proven that good incident response tools and practices decrease incident loss. Easy, huh?
Monday, April 07, 2008
Is This How Security Will Be Improved?
"A Billings, Mont., law firm has filed a class-action lawsuit in federal court against Davidson Companies, claiming the company was negligent when it allowed a hacker to penetrate its systems, resulting in a data security breach and the exposure of some 226,000 customer records, according to a report."
This will be immensely fun to watch! So, for those companies that didn't start paying enough attention to security after viruses, then worms, then SOX, then PCI DSS, than bots, then data loss, then data theft, how about a threat of a nice cold lawsuit? Will it be enough to pay attention?
Well, we will see soon :-)
Thursday, April 03, 2008
$50 > life. WHYYYYYYY?
That is why. This post really tied (for me) everything that happens in security today; and its essence is this quote:
"The state of Victoria in Australia made wearing safety belts compulsory in 1970. This is now almost universal practice. I don't know the exact statistics but a study done in South Africa found that more people used safety belts after it was made illegal to not use them than when it was left up to the driver.
The conclusion really is that people are more likely to obey a rule because it is law than because it may just save their life."
and even
"I have seen a lot of complaints about PCI and SOX etc etc in the same way that people complain about "self protection" laws like safety belt laws."
If you see anything weird in today's "compliance-heavy" security industry, it is probably explained by this phenomenon.