This is a must read about a few other issues associated with keeping the wolf guarding the sheep.
Well, Verisign has done it again. One of the bidders for the .net domain has gone on the record saying that there are factual issues in the published recommendation. The register, did some digging and found out that (surprise, surprise) there are serious conflicts of interest with several members of the evaluatory commitee. Pretty standard and transparent stuff, really. Evaluators with a monetary and/or personal interest in favoring their chosen pony and no compunction against slanting the evaluation criteria, ignoring technical experts, etc., etc. My question about this is, though: why is Verisign even allowed to bid?
Don't people remember that time that Verisign tried to hijack DNS to make money on all our collective typos? Remember when ICANN had to strongarm Verisign and threaten them publicly in order to make them comply? Paul Twomey (ICANN president) said in a statement:
"...VeriSign’s unilateral and unannounced changes to the operation of the .com and .net Top Level Domains are not consistent with material provisions of both agreements. These inconsistencies include violation of the Code of Conduct and equal access provisions, failure to comply with the obligation to act as a neutral registry service provider, failure to comply with the Registry Registrar Protocol, failure to comply with domain registration provisions, and provision of an unauthorized Registry Service. "
I mean, come on! Verisign sued ICANN for heaven's sake! The judge threw it out, and they upped the ante - swearing never to back down. We seem to forget this kind of stuff very quickly, but lest you forget, all this "evaluation," bidding, contracting, etc. is done using public funds. How come we get to foot the bill for continued poor service, continued leveraging of the public Internet to line Verisign's pockets?
This is an intersting writeup about methods for doing an investigation of web browsing activity from a forensics standpoint. I would have liked to have seen the authors at least address the fact that they are likely to be working on a mirror of the disc in question. After all, if a non-trained investigator were to follow these instructions to the letter, they would likely wind up "stepping all over the crime scene" and therefore rendering their results of little use - either to HR or to law enforcement. That being said, the tools and methods they describe are very useful - for example, I've always wondered how to get information out the index.dat file...
That's Thomas Greene colorfully describing the Transportation Security Administration (TSA)'s rather dubious "Secure Flight" system. Greene makes a good case for why he thinks the system will never get off the ground.
A more measured view on the topic can be found at Information Week, System For Screening Passengers For Terrorism Risk Not Ready For Liftoff, Report Says.
But neither report gives me much hope that Secure Flight is going to be in action by August. If ever.
Is it just me, or am I missing something? I've speculated about this before, but the methodology that Trend uses to figure out their top threats makes no sense to me. As I write this, the "top threat" #5 is Gator. I commented on this a while back to the press, but I think it bears repeating since Trend hasn't done anything about it clearly: really, how much of a problem is Gator?
"Top Threat" to me implies "severity," which it can't be. Gator is a program that people have to actively download, agree to the license agreement (which spells out clearly what the software will and won't do,) and then it basically hangs around in the taskbar and displays marketing information. How is that "worse" than the daily deluge of "paypal account notices" and "Your Account Status at WAMU" that tries to trick me into becoming a target for identity theft? It isn't.
So, given that "Top Threat" doesn't imply severity, could it mean "pervasiveness"? Clearly not that either. Take Kazaa, for example. This is classified as Spyware as well. Claria (owns Gator) claims 38 million users of Gator (which is probably a stretch), whereas Kazaa has been downloaded 200 million times. Given that Kazaa typically has around 14 million users online at any given time (30% of total user population maybe?) - we would expect the user population to exceed even the inflated value attributed to Gator by Claria. So, clearly "top" doesn't mean "pervasive" either.
What if "top" means "difficulty in remediating"? Can't be. Unlike some of the other software that is classified as "Spyware", Gator is pretty easy to uninstall. In fact, you can uninstall it using the "Add/Remove Programs" area just like you would any other utility (really, I've tried it.) Grokster (also classified as Spyware,) on the other hand, is almost impossible to uninstall - there are processes that "watch" each other and restart each other if they get interupted, there are difficult to remove artifacts that linger around after uninstall, hard to find files left on the host, etc. So, Trend can't mean "remediation barriers" either.
So, what do they mean by "Top Threats?" Let me propose a theory: how about "highest frequency of detected files on hosts running Trend AV that the Trend engine is able to detect reliably using definition files of an unspecified age?" Given that there is no transparency into the Trend methodology, this would have to be my best guess. If that is the case, Trend's "Top Threats" is more of a sad commentary on their tool vs. an accurate metric to track...
Oracle just bought Oblix; although Oracle says that their technology will "compliment the identity management features internal to Oracle Application Server, I challenge anyone to step forward who has actually had success getting the Oracle idenity stuff to work. I'm not sure Oblix was the right choice to buy, but then again, I would question why Oracle is in the identity management business in the first place.
So, by now everybody and their brother has seen the MSFT funded report discussing the "most secure" OS that is Microsoft Windows. I'm not sure that I buy all the hype about the report being biased; the methodology is extremely transparent, and I would argue that it's pretty sound. On the other hand, there is quite a bit more software included in RedHat than in MS Windows (more software would lead one to conclude that there would be more security issues.)
Here's what I do think is interesting; as an exercise to the reader, do a vanilla install of WhiteBox Linux "Liberation" (or RedHat if you have a license.) Now, log in for the first time and use the "up2date" utility to install all the applicable patches (including the kernel patches.) Now reboot and notice how the machine grinds to a screeching halt during the boot process; I've done this exercise enough times in the lab to know that the default "patching" process toasts the machine (at least on the hardware in my lab.) In all fairness, this never happened to me on Windows (AutoUpdate patches the machine, it reboots, no troubles.) In fact, Solaris 2.6, 7, 8, 9 and now 10 all patch themselves without headache. I'm not going to be first in line to say that Microsoft is secure or anything, but I'm not going to say RedHat is either...
TriCipher put out a press release today saying that they prevent phishing. I'm not sure that these people are really clued into reality. Why do I say this? Here are a few reasons:
1) Saying Eric Greenberg is the "one of the developers of the SSL protocol" is an interesting turn of phrase. Quoting Eric himself, he was "Group Security Product Manager for Netscape, where he led the rollout of the SSL protocol." Project Manager? Rollout? Is Project Manager the same as Developer? Just as an exercise, take a look at the SSL 3.0 spec, is Eric's name on it? Wonder why not...
2) This press release does not address all types of phishing - it's careful to remain limited to "man in the middle phishing," which is arguably of less usefulness than regular run of the mill fishing. "Man in the middle phishing" is a scenario where the fake phishing site proxies the logon page in real-time in order to steal the credentials. Describing it, the press release says "The phisher's server automatically uses this information [the stolen credentials] to immediately log in to the legitimate site, then either keeps the session open automatically until the phisher is ready to hijack the session or simply alters the user's transaction to benefit the phisher. " How often do we see this type of phishing, where an attacker puts up a page that looks like (but isn't) the legitimate server? Personally, I have yet to see this scenario in action. Regular phishing, where an attacker puts up a page that looks like the legit site, but isn't is much more effective (and much simpler for the attacker to implemen.t) This isn't addressed by TriCipher.
3) The press release says, "Further, using SSL means no new software at the web server, making deployment fast and easy." What they don't say is that in order to support this "easy deployment" we need to effectively replace the plumbing of SSL on machines that wish to connect to the webserver. It's true; it took me a while to get there when I was talking to their chief scientist at RSA, but eventually he agreed with that. Read between the lines on their product page. This page says that only "double armored" protects against phishing; "double armored" (following the link to see what "double armored" means) is the one where they split the certificate private key up into two parts. Note that this is not the way SSL currently works. In order to get SSL to behave a different way than the way it behaves today, you need to supply underlying software that does this (either through a browser plug in, activeX control, etc.) Installing new software on a client machine is problematic.
The reason that phishing works in the first place is that end-users aren't necessarily clued into the technical reality of what's going on under the hood of a web connection. If they did, they could spot an obfuscated URL or a bogus email and not start the bogus transaction in the first place. Now, these same users are expected to replace the underlying socket plumbing in their browser and we expect no support calls about this?
I'm not expecting TriCipher to be used for anti-phishing. I could be wrong, but I'm not sure this is the right solution to the problem.
Having spent some time doing vulnerabilty research, I am a bit concerned about the percieved ownership of vulnerability data and the one-sided view being presented in the press. Why is this view one-sided? Specifically, this article likens vulnerabilty research to "police informants", which is not a useful analogy for what is going on. The other reality, the one that I take issue with, does not appear in this article which I think leads to the oversimplification.
The analyst that they quote first is Jonathan Eunice at Illuminata - an individual that I respect highly (and not just because we live in the same town.) Let me not disagree with Jonathan - let me instead say that I think the issue is more complex than it may appear on the surface and I think that you'll see what I mean when this is put in context, . If the reality was such that vulnerability researchers were paid for their efforts and rewarded accordingly, I'm all for that. The problem is this isn't what goes on in reality. Let me tell you a story to illustrate what *does* happen.
A few years back, myself and a colleague discovered a flaw in a part of the Apache web server; at the time we didn't have the time to write it up, but it was a buffer overflow that could allow execution of arbitrary code against a webserver with SSL turned on. There were some constraints, of course, but it could happen. It was only a theory, at that point... We speculated that there was an overflow there, but we weren't sure if it was exploitable. We knew that the only way to be sure was to take the days/weeks of effort to study it, write it up, coordinate appropriate disclosure, etc. That's hard work, by the way. I put the effort in, wrote it up, and disclosed it. For free. As a service to the community because I thought it was the right thing to do to 'give back' to the community that gave me so much.
So what's my point? Would it have been appropriate for Symantec (the moderators of bugtraq) to sell my "pro bono" research to subscribers of their service? After all, since they're moderating the public list that it's disclosed on, they have a day or so "lead time" with which to sell the data ahead of when everyone else gets it - that lead time is something customers are willing to pay top dollar for. How about if the vendor released the patch early to folks who pay them an "advance notice" fee? Is that fair? Personally, I don't think so. I did the research so that everyone could feel safer and rest easier (emphasis on the "everyone") - I did *NOT* do the research so that someone could sell that data to the highest bidder without remunerating me. Nobody did, by the way (remunerate me, that is.) I'm not complaining, mind you. I did it because I thought it was the "right thing" and because I thought it would be fun. But it does make me angry when the "necessary middlemen" in a disclosure scenario attempt to make a quick buck on the research of others. It's just bad form.
Have you seen "Harold and Kumar go to White Castle"? It's a cinematic journey through the American Dream as lived by two guys who reside in New Jersey. After an evening of "sparking up", the two heroes get the munchies and decide to head to White Castle for some burgers.
What's this have to do with Enron (Ken Lay) and Computer Associates (Sanjay Kumar)? Well, Ken Lay is telling reporters that the fall of Enron made him a "victim" and Sanjay Kumar pleaded innocent.
Massive accounting fraud was occurring at the companies these men helmed as CEO yet they had *no idea* these misdeeds were going on?
If Ken Lay and Sanjay Kumar did not know about the actions of their respective corporate accounting teams and associated practices - what were they doing as CEO? Perhaps they were driving around, stoned and looking for burgers?
Corporate governance is about taking responsibility.
Those are the words printed in Greek on the official Boston College seal. I'm a proud Eagle, BC graduate, and since graduating from BC have tried hard to live up to those words. BC, however, recently failed to live up to them.
Today it was reported that BC's alumni database was hacked. The Social Security Numbers (SSN) of 137,000 alumni were exposed. BC is recommending that alumni contact their financial services institutions to alert them to the breach.
How'd it happen? Apparently, from the published report, the database not only held SSNs that did not have to be stored but it was also outside of the BC firewall. Wow. What security architect approved that?
Educational institutions tend to have fairly open boundaries to support the ethic of academic freedom. But SSNs are credentials that need to be protected. Every organization must assess the need to store SSNs, if they are not essential, don't keep them in the record. It's time for Academia to take note and provide the proper controls.
BC - you did not excel for your alumni this week. My alumni wish is that moving forward BC takes some of the $441 million USD raised in the "ever to excel" capital campaign to improve IT controls and risk management. Knowing that my SSN was hacked through BC doesn't make me a happy alumni. And if some of the money raised in capital campaigns doesn't go towards protecting my data that still resides at BC, you can be darned sure I'm not going to be motivated to contribute to future campaigns.
"Ever to Excel" - that includes IT BC. Take note.
Eugene Kaspersky argues that spyware does not exist. He makes a rather nuanced semantic point that spyware is no different from other software - while I have the good sense not to debate semantics with someone named "Eugene," I believe he is both right and wrong. Specifically, spyware isn't any different from any other software; it's just that the activities of the software in question are likely to be undesirable from the end user's point of view. Microsoft has put a great deal of thought into deciding which software is undesirable and why, and I find their system to be most reliable. To demonstrate, let's look at the system in pracitce:
As an example of how useful the Microsoft approach is, let's take a piece of anonymous software and see how it fares on the MS criteria. For example, I have a particularly nasty piece of software on my machine that fits into almost every category on the Microsoft checklist. For example, it 1) occasionally attempts to dial out using the modem, 2) consumes extensive system resources, 3) loads itself on system startup, 4) was bundled with another application that I was primarily interested in, 5) changes operating system settings, and 6) integrates itself with my web browser. This is spyware for sure, right? Of course it is! It matches the MS criteria point for point. Just for the record, the software in question is "Excel." I always knew it was malware, but I need MS to prove it to me.
In other news, why bother validating that applications still work before installing patches? The "Chief Security Strategist" from Shavlik points out why this approach is so "10 minutes ago."
Remember the before and after photos that they have on those diet ads on late night TV? Information security has it's own "before and after" photos. For example, do you remember when ChoicePoint CISO Richard "Dick" Baich told us that the stolen PII data wasn't that big a deal? Well, that was the candid "before" shot. The "after photo" in our little analogy would of course be ChoicePoint CEO standing before congress and apologizing over the tragedy. Like the airbrushing and softening done in the weight loss ad, this apology has been "dressed up" to make the change appear great when really little or no change has gone on in reality. The change is entirely a fiction created in the photos. Is it fair to say this? After all, maybe ChoicePoint really had a change of heart; maybe they were visited by three spirits in the middle of the night and they have woken up to find that there's still time to reform their terrible ways. Unfortunately, no. To quote the article:
Smith and Sanford said they were opposed to legislation banning the sale of Social Security numbers, arguing that the sale of personal information was important to fight fraud and assist law enforcement in its investigations.
So, they just don't want to get regulated and they want to keep doing business as usual. Apparently, Smith's "soul searching" is light on the "soul" and heavy on the "seaching" (at least as it pertains to searching for a way to get the attention to pass with as little cost as possible.) Sickening.
So, Network World Fusion is suggesting that all IT security folks take an oath to make sure that the "health" of the organization they service comes first. Modeled on the hippocratic oath, the author proposes some features that this oath of IT security should have. This is a novel way to grab people's attention (indeed, it grabbed mine,) but I'm irritated after reading it because it captured my attention only to repeat the same tired platitudes that I read every day. If you're going to say the same thing as everyone else, why not say it the same way as always so that my "noise filter" can weed it out like the rest of the ubiquitous white noise out there.
So, separating the medium from the message, the article is flawed in more than the fact that it lacks originality of content. There's also much more to the hippocratic oath than "first, do no harm." Actually, "first do no harm" (despite sounding good) isn't in the oath itself - it's too simplistic and including it in the oath detracts from the well thought out power of the oath itself. For example, does killing cells count as "harm"? What about cancer cells? How about radiation therepy that kills both cancer cells and other cells? The truth is, sometimes a tradeoff has to be made - sometimes short term "harm" leads to long term "health." "First do no harm" does not account for these complexities where the oath in it's traditional form does; the tenets are:
1) Pass knowledge along to other in the same profession. Impart knowledge and train others.
2) Do your best to treat the patient, never knowingly applying remedies that are known to be to the disservice of the patient. Reject anything that takes a life (not quite a simple as "do no harm".)
3) Abstain from experimentation on a patient or putting into effect cures that are unneeded.
4) Respect the privacy of the patient.
All good things that we should keep in mind, but does the article mention them? Read it for yourself and understand my frustration.
Most of the time, I'm anti-FUD (Fear, Uncertainty, Doubt - basically, when security people spin the "worst case" approach to try to sell something based on fear) but in this case, I think the author of this article is really clued in. The truth is, the publicly-disclosed issues really are only the tip of the iceberg. Basically, in today's environment, once an enterprise gets to be of a certain size (more than 2 people?) it's impossible to know where any given piece of data is at any given time. Couple this with an increasingly complex landscape, and there's a situation where every piece of data must be considered comprimised at any point in time. Not a good thing for those of us that the data refers to...
Search Security today put out a list of reasons why we need email firewalls. My question is this: how many firewalls do we ultimately need? Already, if we are a typical enterprise, we probably already have multiple DMZ's, each of which requires one or more "traditional" (IP) firewalls, then we'll probably have "application firewalls" for proxying SOAP or other XML connections (probably one or two per DMZ,) we might have an outbound http proxy/gateway (e.g. squid, inktomi,) now we have email firewalls, and "cutting edge" vendors are already selling "database firewalls".
Here's what I'm getting at - is the end-point a world where every application has its own firewall? How about IM firewalls? Is that coming too? I'm skeptical about introducing all this complexity - I think the gauntlet has been laid down. Nobody wants to introduce a new box (and hence a new bottleneck) into the landscape for every new application that we use. How can we as an industry design applications that do not require all this additional overhead? After all, it's not just the cost of the product, but the cost of maintaining that product over time - with patches and administration, each new entry to the ecosystem adds a cost of much greater magnitude than the sum of the individual parts. If we as an industry keep going down this road, I hope enterprises are prepared for when they see the bill.
I came across this article stating that CISSP certification correlates directly to higher salaries in information security.
This upsets me. Not because I have a grudge against the process, per se; if someone wants to get a CISSP, that's fine by me - for my dollar, I've always thought it was a bit too expensive but who am I to judge how people spend their hard-earned money. Rather, what disturbs me is the fact that organizations appear to be using the CISSP as a recruitment aid.
Why are we paying a for-profit company an "entrance tariff" in order to practice information security; what do we as a society or we as information security workers getting back from the certification process? Unions (organized by workers for workers) offer some degree of protection for the individual; professional credentials (CPA's, engineers, doctors, etc.) supply some type of protection to society at large. CISSP does neither - until this credential is a) administered by a non-profit professional entity and b) undergoes independent review to establish the degree to which it protects society, I think we are mistaken to make it a "must-have" in the hiring process.
Of course, there's the other matter of CISSP's favoring other CISSP's in the hiring process, which I won't go into here; suffice it to say that I think we have enough "old boy" networks already...
Symantec patents scanning for malware?
Reading the patent, wouldn't "grep" constitute "prior art"? (just kidding) In all seriousness, though, I'm wondering if anybody else implementing "heuristic scanning" is a bit nervous by this patent; the methodology seems pretty specific to me, but I'm not a lawyer so maybe it's more general than it appears to a humble technologist like myself.
Everybody knows that the software industry is plagued with bug-ridden code. There's been quite a bit of discussion about who to blame - the developers, the vendors, project managers, the customer, etc. In general, it would seem that market forces favor insecure software - for example, if company A provides software with the same functionality as company B, who is favored in the marketplace: the comapany that releases first to market or the company that spends an extra 6 months in dev and QA? How about the company that has the inexpensive, buggy software vs. the company with the more expensive secure software? Note that I'm not saying "blame the customer" here; how can the customer be expected to make this kind of choice when some software is "more expensive and more secure" and other software is just "more expensive." Some would say use a "big buyer" mentality, but I'm curious - how can the buyer know what is more secure and what isn't? What metrics do they have to go by? None... Hence, they can't make that kind of buying decision.
However, inside a vendor or any company that writes software, insecure code is costly which is a driving factor to keep the bug-rate down. There are two approaches I see proposed for increasing the secuirty of code, neither of which work long-term. The first is "educate the developers." This is doomed to failure for two reasons: first, natural turnover decreases the value of the educational investment over time. Second, new types of attacks are discovered every year or so that obviate existing training (for example, if I train all the developers not to use strcpy() and then the strategy shifts to pure-Java.) The other approach is code scanning; this approach is afflicted by problem #2 (e.g. the scanning tool has to be kept current to account for new classes of attacks) but in addition, the tool requires re-running anytime modifications are made to the software (not always feasible depending on type of software being written.) For example, a web-site content change could introduce a problem, maintenance releases need to be scanned, etc., etc.
The way to fix this problem is to invest in strategies that make the "recitivism" rate (the rate of introducing new problems to the code) go *down* over time - e.g. invest in processes, frameworks, and approaches that increase security over time rather the provide a one-time "boost" to the software security baseline. For example, have a development team invest time in a secure framework that makes it easier to write secure software rather than insecure software. This can be done; I'm not going to give out all the secret-sauce here because it's too long, but I will be putting some how-to examples in our book.
I leave you with the optimistic message that code-scanning and training (or a combination of the two) is likely to decrease in usefulness over time, but investment in self-reenforcing processes and secure frameworks are likely to increase over time.
Ugh. Have you all seen this? Usually, I'd say that there is no shame for a FS company to report under CA SB1386 - I say this because I think that the difference between the firms that are reporting and the ones that aren't are the degree to which the security folks know the systems and processes in use by the business (meaning that everyone should report, but some don't because they are clue-free enough to assume that they've got it all under control.") Seriously; describe to me the difference between a burgler walking off with desktop machines (by precident an incident requiring disclosure) and one or more brokers/advisors/etc using their insecure, unprotected, directly-connected-to-the-internet, and riddled with spyware home machine to store their client lists. Seems to me like it's the same thing, but what do I know?
Anyway, I guess my point is that I think these CSO's (particularly one very astute Bostonian who I respect very highly) didn't say the most important thing; that in the end the business will do what the business does - sometimes you'll know about it and sometimes you won't. Be it storing the addresses on tape and losing them (if you're a bank) or making the decision to release patches quarterly if you're a vendor (although I think we're safe for the time being from a vendor doing something *that* obviously unsafe - heh,) businesses need to do what enhances profitability.
Anyway, usually I would agree with that, but in this case BOA really needs to get their name out of the press; between the 1.2 million addresses and the poor guy who lost all that money from fraud and BOA won't give it back, they need to do something. Seems like paying that guy his 90k would have cost them less, right? Oh well, you live and you learn.