Thursday, December 27, 2007
Sunday, December 23, 2007
It is time to check how my last year's predictions (My Security Predictions for 2007 ... Go!) fared. I am shocked that many of my colleagues looooove to predict, but seem to shy away from reviewing them in the end of the year (big ego - small 'you know whats'? :-))
So, one liner summary of status of my 2007 predictions: they were too wimpy. In more detail ...
PI. Platforms: Vista will have no impact on the overall risk level of most organizations out there. Yes, some holes will certainly be plugged (and I even agree that "Vista is the most secure version ever", just like every single one of its predecessors was - in its time), but others - possibly of types we don't even know about - will crop up. Sorry, but secure platform =/= secure Internet (kinda like you wearing a Kevlar vest doesn't lower crime in the neighborhood).
Status Check 1: This is correct, for sure. In fact, Windows Vista made no impact on security not because it has security flaws (and it does), but because nobody really adopted it. Calls to "upgrade Vista to XP" are heard loud and clear ...
PII. New technologies: no credible technology that can alone "solve" the problem of insider threat will emerge (many will try); the insider threat problem is just too broad, diverse and rich to be solved by a single technology or even a single vendor (corollary: if somebody is trying to sell you such a technology that claims to do exactly that on its own, then - well, you know what to do ...)
Status Check II: This one was kind of a no-brainer and way too safe a prediction. Of course, it didn't emerge! It is impossible to have one technology (or even: only technology) to stop a dedicated insider. However, log management helps since it allows you to know what they actually did and how they stole all your secrets :-( with painful level of details (if you have logging enabled, that is)
PIII. Security market: we will see more than a few firesales and possibly total and miserable security vendor failures (wonna bet which legacy SIEM vendor will die first? :-)) There are way too many companies who sell some random and often irrelevant "protection" which sometimes doesn't even work ... at their own demo ... when their CTO demos it ... the third time ...
PIV. Risk management: a confusion about what is "risk management" will not subside this year. Business risk? Information risk? Risk as threat x vulnerability x asset? Risk as probability of loss? Arrrghh! - It goes on and on and on. No standard accepted definition of risk management in the field of infosec will emerge.
Status Check IV: This is also a wimpy prediction, since it is so obviously true. The concept of risk is still a mystery to many in security (e.g see this survey) and it will likely remain so for a while. Puleeease! :-)
PV. NAC: of course, no list of 2007 prediction is valid without mentioning knack :-) And you know what? NAC will shrink, NOT grow in importance this year! This is where the rubber meets the road and fish start to swim upstream :-) - this prediction started from me reading Richard's piece "NAC is Fighting the Last War" which struck me like a Strength 15 Lighting Bolt. Indeed, narrowly defined NAC largely targets worm infections (and will thus lose relevance) while broadly defined NAC starts to sound like having a well-run network (which is as relevant today as it was in 1992 and probably 2012 as well). The Planet NAC is about to experience a premature eclipse :-)
Status Check V: Yes, bingo!!! I am proud of this one, since it was pretty contrarian: NAC didn't become much clear and adoption reportedly slowed down. Small vendors scatter, larger ones repurposed NAC tools. NAC - in whatever shape or form - will become more common, but only after it sinks into the "trough of disillusionment", pardon my Gartnerese :-)
PVI. 0-days: 2006 was the year when this previously obscure term fell victim to malignant marketeers. 2007 will see more of the same, no doubt. But what about the real 0-day-wielding attackers, poking jokes at the above "oh-day defenders"? Security research into new types of vulnerabilities will certainly continue and more types of previously "safe" (rather, "erroneously thought of as safe") types of content will be used to attack applications. MPG with 0day? AVI with 0day? And, our old friends doc, xls, ppt and now PDF. On the other hand, a major 0-day worm still won't happen.
Status Check VI: Correct, but then again - it was a little on the soft side as well. No 0-days worms. PDF hacking - check. And, in fact, less noise about "we protect against 0-days" (because they likely don't). However, I should have added that technologies that only protect against a few known "baddies" will experience reduction of efficiency ...
PVII. IP and ID theft, data loss: at the risk of sounding hilariously obvious, I would state that such incidents of ID theft (phishing, etc), broader intellectual property (IP) theft and loss will continue largely unabated. Will we, the security community, try to stop it? Of course, but nowhere near hard enough ...
Status Check VII: This has definitely gotten worse, as predicted. TJX? VA? UK events? Many others? And yes, it was hilariously obvious to say this :-)
PVIII. Compliance: but of course! Did you think I'd miss this bad boy? Mandatory regulatory initiatives that pack a bite or a punch, such as PCI, will continue to spread and thus grow in importance, while jokes like HIPAA will continue to languish, helping my # VII prediction come true with a bang ... At the same time, I am undecided on the voluntary frameworks that you can choose to comply with (ISO17799/270001, COBIT, ITIL, etc) - will they take off like a rocketship or remain steadily interesting to some? Only time will tell.
Status Check VIII: PCI DSS continued to rage (despite TJX and other faux pas :-)), even some retailer backlash was seen. On the voluntary side, some say ITIL is emerging, other swear by ISO27xx1 series, but I still don't see the rush to adopt the frameworks en masse, at least not in the US.
PIX. Security awareness: well, security awareness will ... ah, come on, just laugh: bua-ha-ha-ha-haaa :-)
Status Check IX: No comment! Actually one: malware zipped with a password which requires the user to enter it and unzip it. Stuuuuuuuuupid! And, do remember the "WSJ saga" , which probably blew away years worth of your awareness efforts ...
PX. Finally, I would like to reiterate a few of the last year's predictions that will still ring true this year. Client-side and application-level (especially, web application) vulnerabilities will still be outrunning the server-side and platform-level ones. Major wireless attacks and malware will still not destroy the world.
Status Check X: Yes, client-sides beat server-side vulnerabilities. Yes, app vulns beat platform vulns. Come on, what else is new? :-)
Stand by for my 2008 predictions! All Hail Futurism! :-)
All past predictions from various people and groups for 2007 that I've seen are tagged here. A fun read now!
All future predictions from various people and groups predictions for 2008 that I've seen are tagged here. A fun read a year from now? :-)
Friday, December 21, 2007
So, I was reading some survey and came across this bizarre, mind-boggling (maybe even 'mind-numbing?') picture:
How can security be THAT disconnected from risk? Can somebody explain this to me? (Please don't explain by stating "crappy survey methodology" - I can pull this one myself, thank you very much :-))
Mr Hoff, can you help here? :-)
UPDATE: I have a full PDF of the report; can email if interested!
UPDATE2: a lot of fun discussion inspired by this post is here.
UPDATE3: more discussion here where the model "(strategic = risk) vs. (tactical = security)" is used.
So, Q1: have I seen a happy Vista user until today? Not one!
Q2: Did Vista launch create a huge boost to Mac sales? Sure seems like it.
And Q3: Will we ALL (apart from Linux and Mac crowds) use Vista in 2 years? Sadly, yes.
Such is the power of a monopoly...
Thursday, December 20, 2007
Hell yeah!!! More people want to invent NIDS, honeypots and secure OS than I care to see. Why? WHY? W-H-Y? There are so many worthwhile security problems that will benefit from a rigorous academic approach, but people still pick their research topics off the dirt pile ... Take security economics, for example.
Possibly related posts:
"One of the fun questions I used to ask my firewalls tutorial
attendees (back in the day) is: What is a stateful inspection firewall? I.e.: what does it DO?
The answers are usually illuminating. Nobody seems to actually know." (more here)
I think if you are buying a security product, you should always know WHAT IT ACTUALLY DOES!
And if you hear, "Oh, it does, you know, 'risk management'!" - you know what to do (hint: it includes a rotten egg, throwing and running away - in whatever order you prefer ...) :-)
UPDATE (12/22/2007): this is NOT about stateful inspection, this is about a) bad marketing and b) opaqueness of some security vendors about what they do. Come on!
Possibly related posts:
So, did we do a good job this year? Can we? Has the job become impossible? How can we make it better next year? Should we continue doing it? Or is "everything" really the answer? (as in SANS Top1 Risk "Everything!")
Wednesday, December 19, 2007
Thursday, December 13, 2007
So, people sometimes ask me about how to do database logging/auditing/monitoring and log analysis right. The key choice many seem to struggle with for database auditing and monitoring is reviewing database logs vs sniffing SQL traffic off the wire. Before proceeding, please look for more background on database log management, auditing and monitoring in my database log management papers (longer, more detailed - shorter) The table below summarizes the situation with database monitoring and auditing - now you can make your choice more intelligently (items in bold are the ones I consider key):
|Sniff SQL traffic from the wire|| || |
|Collect and analyze database logs|| || |
Choose logs if you care for the relevant Pros (esp key ones) associated with them; choose sniffing if you care for the Pros and are NOT undermined by their Cons (e.g. lack of support for encrypted traffic)
Comments? Additions? Concerns?
(*) Nobody really knows what it will be in each particular situation: 0-40% were observed under various conditions by various people ...
UPDATE: Rich adds his option #3, but I am skeptical since it is not very sexy. Dedicated agents on each databases just aren't that exciting...
Tuesday, December 11, 2007
Holy chao! :-) I was hoping that people - by now!!! - would already know that their CPUs, disks, connections are pretty useful to criminals .... And, yes, so is their data!
Forward the SANS piece to all you non-computer / non-IT friends ... (sadly, some IT folks too ;-))
(December 10, 2007)
An artificial intelligence program circulating in Russian chat forums
flirts with human users in an attempt to get them to divulge personally
identifiable information. People have fallen prey to CyberLover because
it is difficult for them to tell that they are not talking with a real
person. The program can create up to 10 relationships in 30 minutes,
and assembles dossiers for each relationship that include names, contact
information and photographs. So far, CyberLover has just been spotted
in Russian chat rooms, but others are urged to use caution while
chatting." (original source here)
Wow, this is cool! Does it just match your perceptions about what the life in the 21st century would be like? :-) Robots stealing from people - how crass :-)
And, pleeeeease, don't just respond this "people are stupid" :-)
Saturday, December 08, 2007
Friday, December 07, 2007
First, this poll way more popular than my previous "why" poll. Yes, it seems like people do hate to wonder "why" :-)
Second, what are the two choices, that are by far the most popular? They are:
- Store raw logs on a server (23%)
- Search raw logs (grep) when needed (24%)
Yes, this is the "state of the art" of logging: collection of raw logs and "as needed" grep aka "slow and painful" search. In fact, the above answers might not even be given by the same people: some might be grepping logs on the individual servers, while others collect them on syslog servers and never touch them. That is why being in log management business is such a great thing: you have nearly the whole world to evangelize about the value of logs and log management tools.
Third, what's the next most popular idea of analyzing logs? It is "Run my own log analysis tool" at 10% of the respondents. Indeed, the movement started by the "enlightened" Leopold von Sacher-Masoch still lives and thrives: people choose the Build->Suffer approach to log management often enough ...
Fourth, next come my somewhat self-inflicted surprise: apart from commercial log management (at 4%) and rolling one's own (discussed above at 10%), I added the option of "Use other log analysis tools" which captured 7% of the vote. But what does that mean? I have no idea!
Fifth, I am NOT surprised by the lack of popularity of the rule-based correlation tools, such as SIEM (at 2%). When I made my decision to join LogLogic, I had to ponder this one really, really hard. Sorry to use this post to rant, but my conclusion at the time (which is also valid now) was that "SIEM is for some, log management is for everybody." This poll confirms this further.
Finally, all my logging polls and analysis are here. Next one is coming up!
I just wanted to highlight two pieces that, again, speak (No, scream! In fact, S-C-R-EA-M!) about the important of logs. Yes, my readers don't need additional motivation to take logs seriously, but these are just too cool to pass.
First is the interview with some convicted attacker, who said: 'Moore said it would have been easy for IT and security managers to detect him in their companies' systems ... if they'd been looking. The problem was that, generally, no one was paying attention.
"If they were just monitoring their boxes and keeping logs, they could easily have seen us logged in there," he said, adding that IT could have run its own scans, checking to see logged-in users. "If they had an intrusion detection system set up, they could have easily seen that these weren't their calls."'
Amen to that, many of the successful and then-undetected attacks are due to stupidity, incompetence which pretty much equate to bad "risk management" decisions (for whatever meaning of "risk"). Why? 'Cause lacking logs and ignoring logs is indeed stupid!
Second, is my comment on the TJX case, which kinda follows the same idea: 'Dr. Anton Chuvakin, a security expert with LogLogic, said TJX didn't have decent logs. "What took TJX months was looking at all their systems and determining who took what data, from where, where it was sent, etc. The investigation took them months. They likely didn't have any logs, because they had to do system forensics rather than log analysis to arrive at their conclusions about who stole the data and how. If they had collected and analyzed log data centrally, the investigation would have been a piece of cake," he said in an e-mailed comment to InternetNews.com.'
Indeed, doing disk forensics to know who did what is waaaaaaaaaaaay more painful than checking reliable logs. Save yourself by logging, then saving and reviewing the logs!
So, one more time (not the last, mind you!):
Thursday, December 06, 2007
Also read the comments below - many are fun.
Dedicated to all people with a sick sense of humor :-)
Tuesday, December 04, 2007
As I promised, I will post another blurb on log standards following the first: Who Benefits from Log Standards? Part I - Log Management Vendors
Just as the previous one, this comes from the still-upcoming CEE whitepaper (yes, official website is still upcoming as well). Here is the quote that covers the benefits of log standards (in this case, CEE):
"Event Producers (vendors & products) [A.C. - i.e. platform and application software vendors as well as network gear developers whose products generate logs] will be able to decrease cost associated with logging and reuse log libraries. Vendors could move away from encouraging developers from picking log messages on a closest-fit basis from a limited, product-specific message index. Furthermore, the generation of these log messages could be bases on a single API call. Also product interoperability will increase with the others who speak with the same event expressions, resulting in satisfied customers. "
So, in other words, it is not only the log management people who will benefit: software vendors will have an easier life with logging; this applies even more to smaller vendor and even in-house IT teams who often (always?) struggle with how to do logging right in their applications ...
Monday, December 03, 2007
Friday, November 30, 2007
I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today.
So, here is my next monthly "Security Warrior" blog round-up, top posts and comments by topic.
- Oh, wow! I am proud to announce that one of my favorite pieces is indeed the most popular this month: "Protecting Logs from Admins: A Lost Battle?"
- My Top11 logging lists take the next spot: Top 11 Reasons to Collect and Preserve Computer Logs and Top 11 Reasons to Look at Your Logs (the third list, Top 11 Reasons to Secure and Protect Your Logs, was not quite that popular ...) - and, yes, ONE more list is coming: "Top 11 Reasons to Analyze Your Logs!"
- Same as during the last few months, the "fallout" from being featured on a high-profile programming site continues to drive loads of traffic. The topic that got such a huge boost was anti-virus efficiency. Thus, these posts with same theme of anti-virus efficiency were the most popular: Answer to My Antivirus Mystery Question and a "Fun" Story, More on Anti-virus and Anti-malware, Let's Play a Fun Game Here ... A Scary Game, The Original Anti-Virus Test Paper is Here!, Protected but Owned: My Little Investigation as well as a final entry about my own switch away from AV: A Bit More on AV and Closure (Kind of) to the Anti-Virus Efficiency/Effectiveness Saga
- Next on the top list is my other most favorite piece of writing: Ideal Log Management Tool?
- And, finally, my logging polls! Yes, they are popular too. In fact, Poll Results: Which Logs Do You Collect? takes the final, 5th spot in this Top 5! :-)
See you in December :-)
Possibly related posts / past monthly popular blog round-ups:
- Monthly Blog Round-Up - October 2007
- Monthly Blog Round-Up - September 2007
- Monthly Blog Round-Up - August 2007
Wednesday, November 28, 2007
First: "What the client is telling me is that their execu-types can’t handle 5-6 word sentences and I have to be more concise and drop it down to 1-3 words per bullet. [...] I find it alarming at many levels that the executives running fortune 100 or 500 companies can only comprehend at a 1st grade level."
Second: "While I agree with Jim and share his pain (I have given a few exec-level presentations in my time), I also think there is another underlying cause for this: basically, people do not want their execs to know what is going on."
Third: " ... executives at big companies can't comprehend at a 1st grade level. That's a load of crap. Fortune class executives understand exactly what the issues are. The sad truth is that relative to security, for the most part, they just don't care. So we don't need to dumb down our presentations, WE NEED TO MAKE THEM RELEVANT."
Anton Security Tip of the Day #13: Into the Darkness ... or The Ominous World of Unix Binary Audit Logs
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 #13: Into the Darkness ... or The Ominous World of Unix Binary Audit Logs
In this tip, we will take a peek at one of the most esoteric areas of logging: Unix binary audit logs. Solaris BSM and Trusted Solaris auditing is the least unknown :-) example of it, even though other Unix vendors have similar auditing capabilities - see this for HP-UX Audit and this for IBM AIX audit. Linux kernel audit is also pretty much the same thing. If you look for information on 'Solaris BSM audit logs' , you'd find plenty of tips on how to enable such logging, a little on how to manage/rotate the log files, a bit on how to survive the resulting data deluge and ALMOST NOTHING on what to do with the log data, which is kinda sad :-) After looking at BSM logs for a while, I developed an opinion that nobody has ever looked at them on a regular basis :-)
So, let's assume you enabled Solaris BSM kernel audit for user "root" and few other "interesting" users (there is no per-object logging in Solaris; other Unix'es do have it) via the following commonly recommended per-user configuration in /etc/security/audit_user:
This config pretty much records all the actions by the users listed. Now, you have audit files growing like shrooms in you /var/audit. What good does it give us? First, we need to convert the binary audit files into text - something along the lines of
# auditreduce -A /var/audit/20071127193515.not_terminated.SunUltra10 | praudit -l > /tmp/sol_box_11272007
will do. Now what? In this tip we will learn how use the audit logs to see who is trying to copy sensitive files off the system.
First, who is connecting out - lets's search the logs for 'connect' calls (if you are using LogLogic for it, use Index Search for this task; if not, grep will have to do, but be prepared to wait). A few recommended searches:
- "connect AND 172.16.10.*" or "connect AND NOT 172.16.10.*" (to look for connection to specific IPs or to the outside networks) or simply 'connect AND username'
Here is an example found (with connect, IP and user in bold):
header,103,2,connect(2),,Tue Nov 27 11:36:46 PST 2007, + 193 msec,argument,1,0x4,so,socket,0x0002,0x0002,0x80d6,SunUltra10,0x0016,10.1.1.41,subject,root,anton,other,anton,other,29902,29720,0 1611 172.16.0.173,return,success,0
At this point we already know the user name of the user who run that connecting process since it will be in the results (you can also the user to search as I showed above).
Next, what are those connections - let's try to uncover which programs actually connected (BSM logs don't make that easy). Let's search for process starts in the same time frame:
- "execve AND NOT ls AND NOT <whatever other commands you don't care to see>" will give you a list of started programs.
header,124,2,execve(2),,Tue Nov 27 11:36:46 PST 2007, + 115 msec,path,/usr/bin/scp,attribute,100555,root,bin,136,1573,0,subject,root,anton,other,anton,other,29901,29720,0 1611 172.16.0.173,return,success,0
Notice that both records have the same timestamps. Sadly, time and parent process ID ( which is in our case 29720) is all that correlates them together.
Finally, what file was affected (i.e. copied off the system via scp in this case) - more digging is in order; we again use the process ID and time. The easiest is to search for a file name or browse all records around the same time frame (might be A LOT!):
- "*secret.zip* AND anton" will work; we can add the above process ID and look for "anton AND 29720" (but expect a lot of data since this is a shell process ID)
header,135,2,open(2) - read,,Tue Nov 27 11:36:47 PST 2007, + 900 msec,path,/tmp/not-so-secret.zip.gz,attribute,100600,anton,other,0,32743959,18446744073709551615,subject,root,anton,other,anton,other,29901,29720,0 1611 172.16.0.173,return,success,4
What do we know now? This user connected to this system and MAYBE copied this file via, MAYBE via scp. How cool is that? (A: not cool at all, since we are not sure!)
To conclude, if you can avoid dealing with Solaris BSM logs, please do so :-) On a more serious note, you now know why these logs were called "the ugliest logs ever."
Even more seriously (but still pretty humorously), these logs are a classic example of trees that make every effort to obscure the forest, because they record syscalls and not processes or user actions (and connect, execve and read are all logged separately). There are also many, many more idiosyncrasies (and, in fact, idiocies) where these come from :-)
Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.
Or, in other words, are you able to notice good technology through the sleaze-veil of bad marketing?
Here are some fun examples from recent history which kinda explain what I am talking about:
- 'we just added a GRC feature'
- 'we moved into the risk management business'
- 'we simplify threat monitoring'
UPDATE2: another very fun example today from Mike: '"unrivaled SaaS technology that represents a tipping point in enterprise security." Who writes this stuff, and how can I get some of what they are smoking?'
Main Conference InfoSec World 2008:
- Wednesday, March 12, 2008 9:45 AM - 11:15 AM
Session I8: The Five Mistakes of Security and Compliance Log Analysis
The Log Management
- Thursday, March 13, 2008 10:00 AM - 11:00 AM
Session LM3: Logs for Incident Response
- Thursday, March 13, 2008 3:15 PM - 4:15 PM
Session LM7: Emerging Log Standards
- Thursday, March 13, 2008 4:15 PM - 5:00 PM
Session LM8: Panel Discussion: Avoiding Log Overkill: How Much is Enough?Full info here in the PDF brochure - http://www.misti.com/PDF/174
Tuesday, November 27, 2007
I received a fun comment to my old post on CEF (here): "But your problem is that if all vendors agree on the same [log] format (and content), your company (LogLogic) won't earn as much money."
This comment represents a common misconception that I've heard a few times before. In reality, nothing is further from the truth - and our efforts to lead the establishment of log standards prove that as well!
I wanted to formulate my response to this, but then I remember that I already had to do it once, for the still-upcoming CEE whitepaper (yes, official website is still upcoming as well). Here is the quote that covers the benefits of log standards (in this case, CEE):
"Benefits for Event Consumers (vendors & products) [A.C. - what we mean here by 'event consumers' are log management and SIEM vendors who "eat up" the logs] will not have to worry about handling a different event syntax and description for each new version of each product, since these discrepancies should be non-existent in products supporting this standard. There would be no longer a need to employ an event mapping team to manually interpret and handle the different events produced by different devices. Additionally, the consumers can produce better, more accurate analysis because of the availability of detailed, meaningful information. "
So, in other words, log management people won't have to spent so much time and effort fighting artificial challenges imposed by diverse logging formats, fuzzy log contents and illogical log transport options and can find the real, more interesting peaks to climb: automate making meaningful conclusion from log data, predicting future faults and issues and overall enabling the log data to be used for a wide variety of goals in security, system and network operations and - yes!- compliance as well.
Monday, November 26, 2007
I was talking to somebody and this following paradox occurred to me:
- Obviously, all organizations have [some] risk of being successfully attacked by "malicious hackers" (and other threat actors) and thus suffering [some] financial loss (this just reminded of it too)
- However, few know what is the chance and amount of said loss, so they ignore it (absorb it) and do nothing
- As a result, all sorts of bad things happen (insert TJX, VA, etc) so governments and other bodies create requirements: the "C"-word is born (compliance)
- What results is a new threat actor for the organization: an auditor or regulator. Fortunately, this one does have a specific, quantifiable loss amount (e.g. PCI DSS fine) and a more measurable chance of "a successful hit" on the organization
- Thus, people pay more attention to this new threat factor since they can grasp what the loss might/will be: they choose to act on the imposed requirements
- What results is that their security is improved by a still unknown amount and some money is wasted as well
- "Are there yet?" At this point, go back to item #1 and run through this again! Again! Again!
Sounds stupid? This seems to be the world we live in ...
Comment away!UPDATE: looks like Richard has been thinking about something similar here where he talks that sometimes "achieving compliance may cost more than potential damage" [from an attack].
UPDATE2: Symantec risk report [PDF] mentioned here uses the same approach as Pete says: "To suggest that compliance has its own risk is to acknowledge auditors/regulators as a threat. [...] I am pretty sure they are serious but I suspect auditors and regulators don't see it that way."
UPDATE3: Auditor is a risk? You bet! - says Guerilla CISO here. He then asks a really, really good questions with a really, really bad answer :-) : "Do you think people care about compliance, or do they care more about not being caught out of compliance?"
This is my Logging Poll #3, links to past polls:
Wednesday, November 21, 2007
I admit to being guilty of overusing the #3: "Intuitive trend analysis relies most heavily on the ability of the futurist to absorb all there is to know about a topic and then predict what the logical outcome will be."
Read more here.
Others are linked below:
Tuesday, November 20, 2007
A quote: "The most interesting aspect of this case is that ISC2 also sued Google and Yahoo for trademark infringement for hosting content that contained Degraphenreed's impermissible CISSP usage. Specifically, the complaint alleges that Google hosted six blogs that contained the CISSP mark (at least 2 of which contained the term in the blog title), and that Google refused to take down these blogs after the plaintiff's notice."
OMG! Yes, we all saw CISSPs who only know computers in the form of AOL email and who can't spell "I-D-S", but this is in a class of its own. Stupidity definitely reaches a new low with this piece of news ...
Hey, CISSPs, are you embarrassed of what your organization is doing? Or maybe this is taught as "IP protection" in those bootcamps :-)
Monday, November 19, 2007
It starts from a painfully obvious, but elusive: "#1 Management and Governance - If the CEO and Senior Officers of the business do not ultimately own the responsibility and accountability for the security of the business, then it just does not get the appropriate attention."
Even though it covers the very basics, I enjoyed reading it. And so should you :-)
"Metric: Anomalous behavior
Source: application logs
Expression: known good vs anomalies"
Many others here.
You'll be hearing more about application log analysis for SOA in the not-so-near future :-)
More details here and here. Irony (and stupidity) in action, PCI inaction :-)
.. which is what most people would think. However, the journalist writing the blurb disagrees: "Most of the smart folks I've talked to about this think satellites' biggest vulnerability comes from the orbiters' "need for constant housekeeping from the ground," as MSNBC puts it. Those orders from back here on Earth are eminently spoofable."
So, is it the 21st century or what? :-) Hacking things is now easier than blowing them up...?
A quote from the story: " Jim Elste, former security manager at Nevada’s Department of Information Technology, found out in June that there was no system to track the CDs and that the data was unencrypted. [...] Elste says that his attempts to alert the state about the problem led to his being fired. He is appealing his termination, basing the appeal on whistle-blower statutes."
Friday, November 16, 2007
Thursday, November 15, 2007
I am starting my prediction recorder now: http://del.icio.us/anton18/security+predictions+2008
See how we all did last year: http://del.icio.us/anton18/security+predictions+2007
Friday, November 09, 2007
Oh, shucks! My latest logging poll "Why Collect Logs?" (vote here, results so far) is hugely unpopular :-), unlike the previous one (vote here, live results here, analysis here) - it received only 1/10th of the results!
Why? I am guessing:
- entries too long
- too many entries
- real people hate 'why' questions :-)
First, people collect logs mostly for operational reasons - the winner is "We need logs to troubleshoot system/network failures, errors and other availability issues." Combined with #2 reason, that was also operational, security is overall #2 reason for log collection while regulatory compliance is #3.
Second, PCI DSS is the only compliance reason that motivated my readers to collect logs (SOX was a remote second; others - non-existent) - no surprises: PCI DSS directly mandates log management in its Requirement 1o.
Third, as far as security use of logs is concerned, investigations of attacks beats detection of attacks (12:7)
Next poll up soon!
Abstract: "Database security have been capturing more and more attention in recent years, even though most of the security issues surrounding databases existed since the first day commercial database systems were introduced in the market in the 1980s.
Nowadays, database security is often seen as containing the following principal components: access control to database software; Structures and data; database configuration hardening; database data encryption; database vulnerability scanning.
It is interesting to see that logging and auditing underline all of the above domains of database security. Indeed, the only way to verify what access control decisions are being made and who views what data from the RDBMS is to look at the authentication logs. Database configuration hardening includes enabling and increasing the auditing levels. Similarly, data encryption might be verified by log and configuration review. And, vulnerability exploitation usually leaves traces in logs despite what some say (the challenge is more often with understanding what the log said and not with having the logs) In recent years, insider attacks gathered more attention than periodic outbreaks of malware; and database logging happens to be in the forefront of this fight against insider attacks. Database systems are usually deployed deep inside the company network and thus insiders are usually has the easiest opportunity to attack and compromise them, and then steal (or “extrude” as some would say) the data."
Read on here [PDF]!
Want to learn all the terrible mistakes and pitfalls that await you on the path to log management nirvana? Attend "'Worst Practices' of Log Management" presentation by LogLogic that covers all the things that can go wrong while planning, evaluating, deploying and running a log management solution. Insufficient planning, unrealistic expectations, choosing tools on price alone, lack of logging configuration guidance are among such "worst practices." Each common "worst practice" will be accompanied by suggestions to avoid the errors and do things correctly!"BTW, SANS also warns: "Please arrive early to guarantee a seat, the lunch session is limited to the first 100 attendees." This is for real, folks! Many of my lunch and learns at SANS were crowded so do sign up!
And, see you in DC!
You'd think that I am promoting LogLogic here, but that is not the point: the point is that this webcast illuminates the process of choosing a tool [their pre-LogLogic tool!] without sufficient thinking and then regretting it, and then suffering immensely while trying (and failing) to make to work, somehow.
I was almost tearful :-) when I was reading the webcast transcript: these fine folks were pretty much fucked by their previous logging vendor, who promised and never delivered and basically led these folks toward failure through daily frustration and pain ... They are polite in the webcast, but HUGE pent-up frustration just blows through ('It [log management tool] shouldn’t overwhelm you from an administration standpoint' and 'them not being mature enough was a major issue' and 'is it was an incredibly complex application', etc).
This and other experience will also be featured in my new, upcoming SANS Lunch and Learn presentation called "'Worst Practices' of Log Management" (first show at SANS CDI 2007 in DC in December)
And, finally, I know who their previous vendor was, but I ain't talking publicly ... If you do buy from them, I am sorry too say, you ARE an idiot!
Some people never learn - and it is a good thing: a quote: "Blu-Ray discs employ two different DRM technologies. One, called AACS, was cracked back in January. The other, called BD+, was supposed to provide an added layer of "security" and differentiate the format from HD-DVD. Now, to no one's surprise, a company called SlySoft has announced a BD+ crack."
The conclusion is deeply, painfully, truly obvious: "DRM is bad for everyone: technology companies, copyright holders, and their customers."
Thursday, November 08, 2007
A perfect cause to scream "Richard, get them!!!" :-)
So, the "threats" are: AJAX, Google Apps, Social networks, virtualization, virtual words, etc. Holy cow, I am deeply "threatened" by Google Apps - they eat babies and stuff :-)
On a more serious note, these are maybe "emerging attack targets" or maybe "risky emerging technologies," but come on!!! threats?! Gimme a break! How dumb is that!
Wednesday, November 07, 2007
One of the truly horrible, horrible, horrible :-) challenges of log management is obtaining trusted logs (see my log trust pyramid) of administrator activities (sometimes broadened to cover so-called "privileged users"). Many consider it to be the "lost battle" of logging. However, logging administrator access and actions is more important than ever today (and it is one of the few workable way to deal with insider attacks)
So, let's have a little table where I try to summarize how to protect the C-I-A of various logs from administrators and privileged users (some successful and some very hard to pull off). Note that in case of databases and application, we need to protect the log from the DBA and application admins and not from the underlying server platform admins.
UPDATE: table below might look weird; see the full table here.
|"C" - prevent admins from reading logs||"I" - prevent admins from changing logs||"A" - prevent admin from disabling logging|
|Standard Unix||Forget it! Maybe stealth logging (sebek)||Remote logging via syslog to another server, append-only log files (via RBAC)||Forget it! But this is logged and thus can be detected (also: stealth logging)|
|Windows server||Forget it! Maybe stealth logging (sebek for Windows)||Pull the logs ASAP to a central server||Forget it! But this is logged and can be detected (also stealth logging)|
|Databases||DBA activity log stored outside the database (append-only access)||DBA activity log stored outside the database (append-only access)||DBA activity log stored outside the database|
|Firewalls and network gear||Remote logging via syslog to another server - no local logging||Remote logging via syslog to another server||Forget it! But this is logged and can be detected|
|IDS/IPS boxes||Remote logging to another server - no local logging||Remote logging to another server, inaccessible to admin||Forget it! But this is logged and can be detected|
|Misc enterprise applications||App admin log outside the app (not readable to application user)||App admin log outside the app (only appendable by the application user)||Forget it! But this is logged and can be detected|
(just in case, full table is here)
Tuesday, November 06, 2007
Things of that sort help keep the insider angle at the center of attention. It leads me to a scary thought sequence:
a. Is the percentage of unethical people at a major F500 company any different than the entire world? Probably not - or not by much...
b. Thus, for every million of script kiddiez, you have, say, 10 "bad apples" at your org
c. Also, your firewalls/IDS/IPS/NBA/whatever will stop 99%-100% of the above millions
d. Your defenses will probably stop NONE of the 10 "insiders" (and they know where everything is...)
So, who is the bigger risk? I bet on the "evil mom."
Our brilliant field engineer, Dimitri McKay, has to face such situation pretty often and he is frustrated as well: "So tell me why day after day I see administrators and engineers hard nosed about building their own solution? Why do I have to show them day after day that there’s a much more efficient way of managing those logs which will free up resources for a zillion other things."
I would guess that for every million of dollars paid to log management vendors, there are 10 (ten!) millions flushed down the drain by building home-grown logging tools that then get abandoned and decay there on the side of the road ... sad indeed.
Monday, November 05, 2007
"The bottom line is that aside from separation of duties, enforcement of LUA, and monitoring there is not much you can do for an insider threat. Its an almost wholly reactive situation. Of course, vendors don't see it that way :-)"
As I mentioned many times, logs are incredibly useful in case of an insider attack investigation.
Also: "More than one-fourth of large organizations expect their log file data capacity to "increase substantially" over the next 12 months."
And even: "... log data analysis is used beyond security threat management alone. Business managers, IT operations, compliance administrators, and "C-level" executives are increasingly using log data analysis to monitor numerous business and IT metrics."
And finally: "We are witnessing a paradigm shift where log file collection and processing becomes a discrete service-based architecture and acts as the foundation of a new IT-based data warehousing/business intelligence capability."
Wow, I couldn't have written it better....
Is your log management vendor ready (we are)? Or maybe you are one of those poor misguided souls who are still hoping that you SIEM vendor will solve your log management challenges? :-)
Now, narrow it down from society to your network? Do you "fight the different" on your network? Is it working well? Just a thought ...
Friday, November 02, 2007
The idea came from Jeremiah Grossman (here) when he described "The Best Web Application Vulnerability Scanner in the World" thus: "Within a few moments of pressing the scan button it’ll find every vulnerability, with zero false positives, generate a pretty looking report, and voila you’re compliant with GLBA, HIPAA, and PCI-DSS. Of course, we all know such a web application scanner is simply not possible to create for a variety of reasons."
So, let's imagine the idea log management application.
- Logging configuration: the ideal log app will go and find all possible log sources (systems, devices, applications, etc) and then enable the right kind of logging on them according to a high level policy given to it (required: God-like powers)
- Log collection: it will collect all the above logs securely (and without using any risky super-user access ) and with little to no impact to networks and systems (required: God-like powers)
- Log storage: it can security store the above logs in the original format for as long as needed and in a manner allowing quick access to them - in both raw and summarized/enriched form (required: plenty of hardware)
- Log analysis: this ideal application will be able to look at all kinds of logs, known to it and previously unseen, from standard and custom log sources, and tell the user what they need to know about their environment and based on their needs: what is broken? what is hacked? where? what is in violation of regulations/policies? what will break soon? who is doing this stuff? The analysis will power all of the following: automated actions, real-time notifications, long-term historical analysis as well as compliance relevance analysis (required: AI)
- Information presentation: this tool will distill the above data, information and conclusions generated by the analytic components and present then in a manner consistent with the user's role: from operator to analyst to engineer to executive. Interactive visual and drillable text-based data presentation across all log sources. The users can also customize the data presentation based on their wishes and job needs, as well as information perception styles (required: nothing more than a bunch of daring UI designers)
- Automation: the ideal log management tool will be able to take limited automated actions to resolve discovered and confirmed issues as well as generate guidance to users so that they know what actions to take, when full-auto mode is not appropriate. The responses will range from full-auto actions to assisted actions ('click here to fix it') to issuing detailed remediation guidance. The output will include a TODO-list of discovered items complete with actions suggested, ordered by priority (required: AI + some luck + some user stupidity :-))
- Compliance: this tool can also be used directly by auditors to validate or prove compliance with relevant regulations by using regulation-specific content and all the collected data. The tool will also point at gaps in data collection as it applies to specific regulations that the user is interested in complying (required: God-like powers)
In other words, this magic black box will have crap shoveled from one side and will have answers to questions about the meaning of Life :-) coming out the other side...
What? :-) Am I nuts? Well, can I dream for a second? :-)
I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today.
So, my 3rd monthly "Security Warrior" blog round-up, top posts and comments by topic.
- Same as last month AND the month before, the "fallout" from being featured on a high-profile programming site continues to drive loads of traffic. The topic that got such a huge boost was anti-virus efficiency. Thus, these posts with same theme of anti-virus efficiency were the most popular: Answer to My Antivirus Mystery Question and a "Fun" Story, More on Anti-virus and Anti-malware, Let's Play a Fun Game Here ... A Scary Game, The Original Anti-Virus Test Paper is Here!, Protected but Owned: My Little Investigation as well as a final entry about my own switch away from AV: A Bit More on AV and Closure (Kind of) to the Anti-Virus Efficiency/Effectiveness Saga
- Same as last month, my post introducing Another Presentation: FINAL Full Log Mining Slides made it into Top5. It is indeed a very fun presentation, which summarizes a few years of my logging research. I released it since I got a little bored with researching structured data analysis; a lot of logs we look at today are anything but :-) One of our more enlightened competitors called logs "semi-structured" data.
- My link to A Sensible Piece on Logging in PCI DSS made it to the top as well. Also check the "PCI Compliance" book Logging chapter.
- As I suspected, my little blurb with user profiling ideas called More on 'root' FTP or ""0wned? Again?"" (and Simple User Profiling) is popular. But wait! - there will be more :-) I am writing a little tool that uses LogLogic API to actually do it!
- Again, in a bizarre twist of fate, the new latest blurb in my humorous saga Nobody Is That Dumb ... Oh, Wait VII made the top list. It proves the point: laughing at others' stupidity is still popular :-) If you doubt it, I have some bridge... ehh... anti-spyware company stock to sell you :-)
- My third Top11 list Top 11 Reasons to Secure and Protect Your Logs is important to highlight here (it is officially # 6 out of the Top5 for October :-))
See you in November :-)