I saw the news article today where FBI director James Comey drew an analogy between Chinese hackers and drunken thieves. If only there were a way to totally insulate one's self from attacks which emanate in hostile foreign countries. </sarcasm>
If you have custody over a network with internet accessibility and don't have Country Blocking capabilities, get a new firewall that has this feature. Sophos' UTM appliance is a good example.
Additional diligence by network administrators - especially when there is no legitimate opportunity or use case requiring access to or from China as an example - could render much of the discussion about Chinese hackers moot.
Looking at websites like Norse that do data visualization for internet attacks on an awesome, 21st century version of the "War Games" big map (see http://map.norsecorp.com), show that the U.S. is under constant attack from foreign countries. Most attacks originate from predictable sources. Blocking any and all communication to or from those countries with prejudice is pretty effective, and if we're honest, has very little downside to a vast majority of private network operators.
For our part, we have blocked incoming access from just about every country where we have no business interests (most of them), as well as outgoing access to many of those countries. This limits the attack surface for compromising machines, and limits the ability of any compromised machine to communicate with whomever is controlling it if they're offshore.
In the movies, doing many hops between controlled systems to hide your tracks is made to look extremely simple - in reality, very few people have the time or inclination to pull this off. They're usually looking for targets of opportunity - don't give them any, and they'll move along.
Monday, October 06, 2014
Wednesday, October 01, 2014
The Fallacy of "Secure Email"
We're having a rollicking good time lately working with emails that are coming to us using some form of "secure" delivery platform, as an alternative to actually encrypting email end-to-end, which everyone knows is not fun.
Some background...companies big and small are increasingly offering some sort of secure email feature, especially if you use cloud providers like Symantec, Mimecast, Microsoft's Office365, etc.
It sounds great - you don't have to do all of that pesky server configuration, etc., and you like your provider, so it'll be awesome, right? The thing is, they don't actually encrypt email delivered via SMTP. Which means, things are about to suck.
Set aside for a moment the fact that "secure internet email" is an oxymoron of nearly biblical proportions - if you don't host your own email, someone else is reading all of it; if you do host your own email, someone else is still reading all of it, but you at least know who that someone else is; if you send email over the internet, someone else has read it - whether their geopolitical beliefs, conscience, and motives fit yours or not is scarcely relevant to the question of security. Email isn't secure. Never has been.
So naturally, if a company starts selling a solution to an impossible problem, someone is going to give it a shot. After all, nobody ever went broke by underestimating the intelligence of the average consumer, blah blah blah.
How then, do you solve this impossible problem? Simple, you lie.
When you compose and send a secure message through one of these platforms, the recipient doesn't actually get your message. They get an email containing a link informing them that a secure email message with subject such-and-such is ready for them to view. If they click the link, the friendly website will "securely" show them the sensitive contents.
....
Yes, you got it. The recipient has to create an account the "secure email delivery" service's system.
Yes, they have to use the email address at which they received the message as their login ID.
Yes, they get to create their own password.
No, you don't get to make that password policy match your own.
No, you don't get to do single sign-on between their service and your authentication system.
No, you don't get to control how long those messages are stored on their service.
No, you don't get to lock out that account when the employee leaves your company. Yes, if that person gets fired, they can still - potentially forever - get to the sensitive information that was sent to them, at the email address belonging to your company.
Yes, if an attacker had already compromised the recipient's mailbox or credentials, they would also have the ability to control the account at these services and gain unfettered access to this sensitive information.
Lots of unpleasant and colorful terms spring to mind as descriptors of what systems like this really are.
The recipients don't know any of this, and shouldn't have to. They just need the information to do their jobs, so naturally they aren't very receptive to information security lectures by IT. But we can't just roll our eyes and sigh and 'fix it' - this isn't fixable. Using these stupid services wasn't our decision. We have no control over it, we just know it is an absolutely terrible idea, is totally unsupportable, opens up dozens of new areas of risk, and adds zero value for all the effort.
There are, or may be, some services that bypass this patently idiotic system of creating additional attack vectors for identities altogether. One interesting method is that the email is printed to a PDF, secured with a password, and delivered directly to the recipient. The recipient would need to contact the sender for the password. It's a far, far better idea - no third party websites or accounts to worry about managing, no transmission of information in clear text, an attacker with mailbox access wouldn't be able to see the contents without the password (transmitted by phone in-person), and even sysadmins wouldn't reasonably be able to see the contents on either side.
This would be a viable solution, but Microsoft doesn't offer this service to O365 customers (or anyone). Their one redeeming quality, if you happen to be an O365 customer already, is that through Azure AD and Dirsync configuration, you can at least - sort of - do single sign-on management of login accounts used by recipients. That of course assumes the recipient knows not to create a new Live ID when they receive an email, and have been trained on the (as of this time undocumented) steps to login with their company-managed account.
Many other banana-headed services that have barraged us lately don't offer secure PDF delivery either, unknowingly victimizing plenty of well intended but utterly ignorant companies buying the latest flavor of silicon snake oil.
And to think, there's so much opposition to teaching critical thinking skills in our public schools...
Some background...companies big and small are increasingly offering some sort of secure email feature, especially if you use cloud providers like Symantec, Mimecast, Microsoft's Office365, etc.
It sounds great - you don't have to do all of that pesky server configuration, etc., and you like your provider, so it'll be awesome, right? The thing is, they don't actually encrypt email delivered via SMTP. Which means, things are about to suck.
Set aside for a moment the fact that "secure internet email" is an oxymoron of nearly biblical proportions - if you don't host your own email, someone else is reading all of it; if you do host your own email, someone else is still reading all of it, but you at least know who that someone else is; if you send email over the internet, someone else has read it - whether their geopolitical beliefs, conscience, and motives fit yours or not is scarcely relevant to the question of security. Email isn't secure. Never has been.
So naturally, if a company starts selling a solution to an impossible problem, someone is going to give it a shot. After all, nobody ever went broke by underestimating the intelligence of the average consumer, blah blah blah.
How then, do you solve this impossible problem? Simple, you lie.
When you compose and send a secure message through one of these platforms, the recipient doesn't actually get your message. They get an email containing a link informing them that a secure email message with subject such-and-such is ready for them to view. If they click the link, the friendly website will "securely" show them the sensitive contents.
....
Yes, you got it. The recipient has to create an account the "secure email delivery" service's system.
Yes, they have to use the email address at which they received the message as their login ID.
Yes, they get to create their own password.
No, you don't get to make that password policy match your own.
No, you don't get to do single sign-on between their service and your authentication system.
No, you don't get to control how long those messages are stored on their service.
No, you don't get to lock out that account when the employee leaves your company. Yes, if that person gets fired, they can still - potentially forever - get to the sensitive information that was sent to them, at the email address belonging to your company.
Yes, if an attacker had already compromised the recipient's mailbox or credentials, they would also have the ability to control the account at these services and gain unfettered access to this sensitive information.
Lots of unpleasant and colorful terms spring to mind as descriptors of what systems like this really are.
The recipients don't know any of this, and shouldn't have to. They just need the information to do their jobs, so naturally they aren't very receptive to information security lectures by IT. But we can't just roll our eyes and sigh and 'fix it' - this isn't fixable. Using these stupid services wasn't our decision. We have no control over it, we just know it is an absolutely terrible idea, is totally unsupportable, opens up dozens of new areas of risk, and adds zero value for all the effort.
There are, or may be, some services that bypass this patently idiotic system of creating additional attack vectors for identities altogether. One interesting method is that the email is printed to a PDF, secured with a password, and delivered directly to the recipient. The recipient would need to contact the sender for the password. It's a far, far better idea - no third party websites or accounts to worry about managing, no transmission of information in clear text, an attacker with mailbox access wouldn't be able to see the contents without the password (transmitted by phone in-person), and even sysadmins wouldn't reasonably be able to see the contents on either side.
This would be a viable solution, but Microsoft doesn't offer this service to O365 customers (or anyone). Their one redeeming quality, if you happen to be an O365 customer already, is that through Azure AD and Dirsync configuration, you can at least - sort of - do single sign-on management of login accounts used by recipients. That of course assumes the recipient knows not to create a new Live ID when they receive an email, and have been trained on the (as of this time undocumented) steps to login with their company-managed account.
Many other banana-headed services that have barraged us lately don't offer secure PDF delivery either, unknowingly victimizing plenty of well intended but utterly ignorant companies buying the latest flavor of silicon snake oil.
And to think, there's so much opposition to teaching critical thinking skills in our public schools...
Tuesday, September 30, 2014
Microsoft Windows Phone 8.1's Insipid Keyboard
I can't believe how few search engine results there are for the question of how to disable the stupid, pointless, idiotic smileys / emoticons / emojis button on the Windows Phone 8.1 keyboard. Typing using any method other than the swipe or tapatalk method is absolutely futile - it is the worst touch keyboard I have ever used, and matters aren't helped at all by the inclusion of a "smiley" key.
Located perilously close to the comma, shift, Z, and number shift key, the stupid "smiley" key pops up randomly - usually as I'm expecting a comma to appear, and given that I can type in excess of 80wpm, the result is a string of unintelligible miniature images that add absolutely no value whatsoever to adult businesspeople. If the kids want it, fine, but why in the heck can we not turn it off - or download another keyboard 'language' that doesn't include this dumb thing? Why is information on this question so hard to come by?
I know that Ballmer is gone now and that huge companies don't change overnight, but it's difficult to take seriously much of what Microsoft is trying to do as innovators when they don't take themselves seriously.
Located perilously close to the comma, shift, Z, and number shift key, the stupid "smiley" key pops up randomly - usually as I'm expecting a comma to appear, and given that I can type in excess of 80wpm, the result is a string of unintelligible miniature images that add absolutely no value whatsoever to adult businesspeople. If the kids want it, fine, but why in the heck can we not turn it off - or download another keyboard 'language' that doesn't include this dumb thing? Why is information on this question so hard to come by?
I know that Ballmer is gone now and that huge companies don't change overnight, but it's difficult to take seriously much of what Microsoft is trying to do as innovators when they don't take themselves seriously.
Monday, September 15, 2014
Eulogizing the Luddite
In the early 19th century, the advancement of technology was seen as a threat by some people who feared it would take away their jobs. Rather than viewing technologies as tools to help them do more with less effort and better results, they took the view that their cherished and long-honed skills were meaningless and viewed it as a threat. Rather than embracing the potential benefits, they opposed them vociferously. These people were referred to as Luddites (history varies as to why).
Today, a true Luddite would be a pretty rare spectacle indeed - shamelessly decrying technology as a threat to their livelihoods, failing (perhaps on purpose) to see how it could allow them to achieve things they would not have been able to otherwise.
However long ago the eulogy for the Luddite was read, their kind have not vanished from the landscape. They're still among us today, as something far worse - the apologetic, self-hating Luddite.
There's a line in time that serves as an almost insurmountable fence separating those who can develop a working mastery of information technology, and those who cannot for one reason or another. In my experience it seems to start with those born before 1965 - 1970, with those born later having generally no problems at all utilizing technology to meet their desires, and those born before having generally no affinity nor use for technology in their daily lives.
Here's the rub - lots of people born at or before that line in time have jobs as professional knowledge workers, requiring them to be proficient with technology.
These people are perhaps the single biggest reason IT support organizations exist and remain busy. In the 30 or so years that information technology has been "a thing" in the enterprise, one constant has remained across time - lots of people don't get it, or don't want to get it, and most of them are old.
We can spend forever attempting to determine why this is, and how to fix it, as though being a Luddite is an illness and we just haven't been able to cure it yet. My opinion is a lot more harsh, and it's borne from decades of being in the business - decades of doing grunt work for someone else making far more money than me, whose job I could do in my sleep, but who would drown within hours of attempting to do mine. That fundamental disparity leaves no room for sympathy.
Time is marching on. Technology isn't going to plateau, nor slow down its advances, for anyone. At what point is it no longer acceptable for a person to be incapable of utilizing technology to accomplish their duties efficiently?
Let's use the paradigm of technology as it applies to other tools & trades. How apt are we to hire, let alone pay a premium due to tenure for, a carpenter who is able only to use handsaws while young journeyman apprentices use power saws and the like with all the resulting increases in productivity? How apt are we to employ a fleet of salespeople who have leather-bound books to contain prospect lists and business cards instead of those familiar with Outlook and CRM solutions? How much patience would we have for automobile mechanics who were flummoxed by the array of sensors on modern vehicles, or who refused to avail themselves of pneumatic tools? How about the arborist who refused to use chain saws? How long will a factory last that won't employ machinery to perform rudimentary tasks such as pipe bending, stamping, etc?
The rest of the world, in a larger majority every day, is employing technology to their benefit - be it information technology, machinery, robotics, automation, etc. In order for business plans to make sense and be competitive, there's an implicit mastery of technology written into the numbers. Efficiency isn't a great gift, it is an expectation.
So the question remains, for those who don't get it - those who call their helpdesks to figure out how to use Excel, or send an email to several people, or print something that will staple and collate, and who all sheepishly say "I'm not very good with computers" as though that makes it all okay - how much longer do you expect the world to buy your excuses? How much longer will we have to carry your sorry, heavy, expensive butt?
It's always easier to just help you out - meaning, do it for you, because if you understood it you'd have learned how to do it yourself the last time. But every time we do, believe us - we'd be a lot happier reading your eulogy.
Today, a true Luddite would be a pretty rare spectacle indeed - shamelessly decrying technology as a threat to their livelihoods, failing (perhaps on purpose) to see how it could allow them to achieve things they would not have been able to otherwise.
However long ago the eulogy for the Luddite was read, their kind have not vanished from the landscape. They're still among us today, as something far worse - the apologetic, self-hating Luddite.
There's a line in time that serves as an almost insurmountable fence separating those who can develop a working mastery of information technology, and those who cannot for one reason or another. In my experience it seems to start with those born before 1965 - 1970, with those born later having generally no problems at all utilizing technology to meet their desires, and those born before having generally no affinity nor use for technology in their daily lives.
Here's the rub - lots of people born at or before that line in time have jobs as professional knowledge workers, requiring them to be proficient with technology.
These people are perhaps the single biggest reason IT support organizations exist and remain busy. In the 30 or so years that information technology has been "a thing" in the enterprise, one constant has remained across time - lots of people don't get it, or don't want to get it, and most of them are old.
We can spend forever attempting to determine why this is, and how to fix it, as though being a Luddite is an illness and we just haven't been able to cure it yet. My opinion is a lot more harsh, and it's borne from decades of being in the business - decades of doing grunt work for someone else making far more money than me, whose job I could do in my sleep, but who would drown within hours of attempting to do mine. That fundamental disparity leaves no room for sympathy.
Time is marching on. Technology isn't going to plateau, nor slow down its advances, for anyone. At what point is it no longer acceptable for a person to be incapable of utilizing technology to accomplish their duties efficiently?
Let's use the paradigm of technology as it applies to other tools & trades. How apt are we to hire, let alone pay a premium due to tenure for, a carpenter who is able only to use handsaws while young journeyman apprentices use power saws and the like with all the resulting increases in productivity? How apt are we to employ a fleet of salespeople who have leather-bound books to contain prospect lists and business cards instead of those familiar with Outlook and CRM solutions? How much patience would we have for automobile mechanics who were flummoxed by the array of sensors on modern vehicles, or who refused to avail themselves of pneumatic tools? How about the arborist who refused to use chain saws? How long will a factory last that won't employ machinery to perform rudimentary tasks such as pipe bending, stamping, etc?
The rest of the world, in a larger majority every day, is employing technology to their benefit - be it information technology, machinery, robotics, automation, etc. In order for business plans to make sense and be competitive, there's an implicit mastery of technology written into the numbers. Efficiency isn't a great gift, it is an expectation.
So the question remains, for those who don't get it - those who call their helpdesks to figure out how to use Excel, or send an email to several people, or print something that will staple and collate, and who all sheepishly say "I'm not very good with computers" as though that makes it all okay - how much longer do you expect the world to buy your excuses? How much longer will we have to carry your sorry, heavy, expensive butt?
It's always easier to just help you out - meaning, do it for you, because if you understood it you'd have learned how to do it yourself the last time. But every time we do, believe us - we'd be a lot happier reading your eulogy.
Friday, July 18, 2014
Netgear ReadyNAS 516 is Not Ready for Enterprise Networks
I've been saddled with one of these dreaded things with a gun pointed to my head. Nothing can be worse.
In any event, if you were to unbox and connect a Netgear ReadyNAS to your corporate network, and said ReadyNAS came from the factory with OS Version 6.0.8, and said network had a firewall that didn't allow any and every HTTP request to flow through it unfettered, you would have the same odd experience I had.
You would log in with the default admin credentials, and be prompted to run through a wizard. You could cancel out of it or complete the steps - wouldn't matter. Either way, when the wizard exits, you would get a continual 'flashing' or cycling webpage. It would flash between a hint of the admin console, a box saying "Connection Lost", and the splash screen for the device. You would never be able to click on anything with any success. You could restore the OS, restore to factory defaults, and basically end up in the same death spiral.
If however you looked at said firewall to see what traffic, if any, was hitting it from the IP used by the ReadyNAS, you'd see lots of HTTP requests going to subdomains of netgear.com and readynas.com, and even the stray IPv4 address. You might try to open them one at a time a la "whack-a-mole", or you would just allow all traffic from that IP address - like I did - which works.
Thanks bags, Netgear, for again making the lives of IT professionals everywhere just a little more gruesome and unbearable.
In any event, if you were to unbox and connect a Netgear ReadyNAS to your corporate network, and said ReadyNAS came from the factory with OS Version 6.0.8, and said network had a firewall that didn't allow any and every HTTP request to flow through it unfettered, you would have the same odd experience I had.
You would log in with the default admin credentials, and be prompted to run through a wizard. You could cancel out of it or complete the steps - wouldn't matter. Either way, when the wizard exits, you would get a continual 'flashing' or cycling webpage. It would flash between a hint of the admin console, a box saying "Connection Lost", and the splash screen for the device. You would never be able to click on anything with any success. You could restore the OS, restore to factory defaults, and basically end up in the same death spiral.
If however you looked at said firewall to see what traffic, if any, was hitting it from the IP used by the ReadyNAS, you'd see lots of HTTP requests going to subdomains of netgear.com and readynas.com, and even the stray IPv4 address. You might try to open them one at a time a la "whack-a-mole", or you would just allow all traffic from that IP address - like I did - which works.
Thanks bags, Netgear, for again making the lives of IT professionals everywhere just a little more gruesome and unbearable.
Tuesday, April 29, 2014
On the Tail Wagging the Dog
I saw an article in Tech Republic today that rubbed me the wrong way. I probably should have ignored it, but it comes up so often, I had to capture my thoughts.
The article was entitled "IT self-sabotage: Don't be your own worst enemy". By itself, that sounds like it may be valuable, but the article took less time to write than it did to read, and rehashed the same nonsense that has become pervasive in corporate America. Namely, there's no value in enterprise IT, so don't fight consumerization.
http://www.techrepublic.com/article/it-self-sabotage-dont-be-your-own-worst-enemy/
I could not disagree more with this mindset. It's nothing more than salve for the souls of the inadequate. The difference between a company with a strong IT leader who maintains their principles and doesn't succumb to every trend for which he has no immediate answer and a company willing to flop around like a water hose at full blast going wherever the flow takes it may not be immediately evident from the outside, but it will be startlingly clear to anyone who has been in both types of shops.
Who is supposed to benefit from this article? Who is the audience? Certainly no-one in the enterprise space with a management role would be so obtuse as to adopt hardline stances absent any other mitigating factors; surely no-one is so facile and ill-equipped as to believe for a moment that the role of corporate/enterprise IT is to let the tail continually wag the dog, which is clearly what this article advises. Rubbish.
IT has a unique perspective in many companies, in that it sees the broadest possible picture. IT recognizes benefits of standardization and architecture that extend beyond the interests of individual business units, who themselves are often unaware and/or unsympathetic to the fact that those interests can be at conflict with one-another. Deferring to the needs of the business as a policy means abdicating the important job of managing risk and ensuring that the entire organization runs smoothly and cost-effectively. It's ridiculous to dismiss that in favor of myopic trends such as 'consumerization', or in the name of being more friendly. Just because you can do something, it doesn't mean that you should. Consumerization for example, is a trend borne from a combination of overzealous, unqualified para-technicians masquerading as executives, and the eagerness of the technology sector to profit from them by legitimizing an otherwise (and historically) illegitimate tactic. The herd mentality on full display in all of it's resplendent glory...all the while, nobody has remembered to ask whether any of this stuff A) solves a real problem, and B) helps us generate more revenue, operate more profitably, and reduce (not simply rename) our risk.
In my experience, if a company runs into an IT department which says "no" too often, it's because the company isn't asking the right questions - meaning that they aren't applying careful, critical thought to the decisions facing them, or even willfully ignoring the obvious, underlying problems which seldom if ever have anything to do with technology. IT might not (and should not) have all the answers about how to run a business, but they will certainly know when the business is about to dig themselves an enormous hole. If IT doesn't speak up (and say "no"), they aren't doing their job.
To write up an article with insipid 'suggestions' such as these is of no more value than talking to someone for two minutes in a coffee shop line about their philosophy for enterprise architecture. There is so much assumed, so much not considered, that it hardly makes sense to waste the time publishing it.
The article was entitled "IT self-sabotage: Don't be your own worst enemy". By itself, that sounds like it may be valuable, but the article took less time to write than it did to read, and rehashed the same nonsense that has become pervasive in corporate America. Namely, there's no value in enterprise IT, so don't fight consumerization.
http://www.techrepublic.com/article/it-self-sabotage-dont-be-your-own-worst-enemy/
I could not disagree more with this mindset. It's nothing more than salve for the souls of the inadequate. The difference between a company with a strong IT leader who maintains their principles and doesn't succumb to every trend for which he has no immediate answer and a company willing to flop around like a water hose at full blast going wherever the flow takes it may not be immediately evident from the outside, but it will be startlingly clear to anyone who has been in both types of shops.
Who is supposed to benefit from this article? Who is the audience? Certainly no-one in the enterprise space with a management role would be so obtuse as to adopt hardline stances absent any other mitigating factors; surely no-one is so facile and ill-equipped as to believe for a moment that the role of corporate/enterprise IT is to let the tail continually wag the dog, which is clearly what this article advises. Rubbish.
IT has a unique perspective in many companies, in that it sees the broadest possible picture. IT recognizes benefits of standardization and architecture that extend beyond the interests of individual business units, who themselves are often unaware and/or unsympathetic to the fact that those interests can be at conflict with one-another. Deferring to the needs of the business as a policy means abdicating the important job of managing risk and ensuring that the entire organization runs smoothly and cost-effectively. It's ridiculous to dismiss that in favor of myopic trends such as 'consumerization', or in the name of being more friendly. Just because you can do something, it doesn't mean that you should. Consumerization for example, is a trend borne from a combination of overzealous, unqualified para-technicians masquerading as executives, and the eagerness of the technology sector to profit from them by legitimizing an otherwise (and historically) illegitimate tactic. The herd mentality on full display in all of it's resplendent glory...all the while, nobody has remembered to ask whether any of this stuff A) solves a real problem, and B) helps us generate more revenue, operate more profitably, and reduce (not simply rename) our risk.
In my experience, if a company runs into an IT department which says "no" too often, it's because the company isn't asking the right questions - meaning that they aren't applying careful, critical thought to the decisions facing them, or even willfully ignoring the obvious, underlying problems which seldom if ever have anything to do with technology. IT might not (and should not) have all the answers about how to run a business, but they will certainly know when the business is about to dig themselves an enormous hole. If IT doesn't speak up (and say "no"), they aren't doing their job.
To write up an article with insipid 'suggestions' such as these is of no more value than talking to someone for two minutes in a coffee shop line about their philosophy for enterprise architecture. There is so much assumed, so much not considered, that it hardly makes sense to waste the time publishing it.
Wednesday, June 27, 2012
On The Big Switch
There is a school of thought, being echoed by no less a technology behemoth than Microsoft, that maintaining your own IT infrastructure will one day be as antiquated as maintaining your own power generation capability. In the past, they remind us, companies had to generate their own power - until reliable utility power generated centrally for broad use came to be. Suddenly it was no longer cost effective to make your own power. The problem comes from the leap of irrationality they make in drawing an analogy between that step in our industrial evolution, to the current practice of a company maintaining their own IT infrastructure leading inevitably towards a cloud model.
On the surface, and only on the surface, this might counterbalance the fear of the "new" some folks might have. People didn't trust utility power at first, but they eventually learned that it was great and the cost savings were worth the risk. As it applies to utility power, certainly this is a sound argument.
Two things to keep in mind though.
1) Electricity is fungible; data isn't.
2) Companies still have backup power systems for when (not if) the utility fails.
The cost of maintaining redundant power is pretty reasonable. And in some cases, the cost of maintaining redundant data systems is reasonable. There are certainly use cases for cloud computing, but technology leaders are still exactly right to be critical of those who argue everything can, should, and will eventually be "in the cloud". If they end up being right, it will be by accident and will probably not look anything like they imagine it today. For now, outside those few "low business impact" use cases representing the lowest hanging fruit, the opinion of this technologist is that SaaS / Cloud / Web Hosted solutions struggle to do significantly more than exchange one set of problems for another. Not that there's anything wrong with that.
On the surface, and only on the surface, this might counterbalance the fear of the "new" some folks might have. People didn't trust utility power at first, but they eventually learned that it was great and the cost savings were worth the risk. As it applies to utility power, certainly this is a sound argument.
Two things to keep in mind though.
1) Electricity is fungible; data isn't.
2) Companies still have backup power systems for when (not if) the utility fails.
The cost of maintaining redundant power is pretty reasonable. And in some cases, the cost of maintaining redundant data systems is reasonable. There are certainly use cases for cloud computing, but technology leaders are still exactly right to be critical of those who argue everything can, should, and will eventually be "in the cloud". If they end up being right, it will be by accident and will probably not look anything like they imagine it today. For now, outside those few "low business impact" use cases representing the lowest hanging fruit, the opinion of this technologist is that SaaS / Cloud / Web Hosted solutions struggle to do significantly more than exchange one set of problems for another. Not that there's anything wrong with that.
Monday, December 12, 2011
How Confused SysAdmins Are Rendering SPF Useless
The idea behind Sender Policy Framework (SPF) is to eliminate the possibility for spammers to send messages which appear to come from a given company or entity, even though nobody at that entity sent it.
SMTP allows for this kind of impersonation because, by itself, nothing in SMTP ever checks to see that you are who you say you are in the FROM line. Remember that SMTP has been around longer than most system administrators and was built in a time when everyone on the internet knew everyone else by first name. "Trust" was never a design principle for the internet, and we've been dealing with the fallout ever since. The bottom line is that, as far as SMTP goes, you are who you say you are because you say so. If only it were that easy in real life.
Enter the Sender Policy Framework. SPF is implemented by both senders (as a DNS entry, saying "mail from me is going to come from the following addresses only"), and receivers (by checking the IP address of the sender connecting to your system against the list of valid addresses for the domain they say they are at). Simple.
The problem is this - if you don't implement SPF properly at both ends, it ends up causing more problems than it solves. Confused system administrators are likely to get this wrong, and are likely to be even more confused when you explain to them why they got it wrong and how to fix it. It's happening more and more often, and it's a pain.
The bane of a mail administrator's existence is the false positive - that is, a message which is legitimate, but that got blocked or bounced erroneously by the cocktail of email protection mechanisms they employ.
If as a receiver, you are not properly evaluating SPF for incoming messages, you are creating a problem for your users and the people trying to communicate with them by creating false positives in droves.
Worse yet, if your default action when you think there's an SPF issue is to bounce the message, you eliminate any chance that a human being can spot the problem and bring it to your attention.
Such is the case with tons of Barracuda anti-spam appliance users, who are responsible for a rash of "550 Rejecting for Sender Policy Framework" replies reaching support desks around the world.
A proper implementation of SPF will evaluate the IP address of the connecting system against the list of allowed IP addresses for that sender's domain based on their DNS record for SPF. No more, no less. In the case of the Barracuda, their devices are erroneously evaluating not just the IP address of the connecting system, but the IP addresses of every hop along the way. It is as if they inherently assume that even if the connecting system is in the SPF list, it is an open relay and is being abused by a spammer.
We've seen screenshots of Barracuda administrative consoles, and for messages they blocked as false positives due to "Sender Policy Framework", the details reveal that an IP address of a server involved early in the relay was NOT in the SPF record for that domain - even though the server establishing the connection to the endpoint WAS in the SPF record for that domain. If you use a smarthost configuration, whereby your public-facing mail server always relays to a service "in the cloud" for anti-virus scanning, etc, you are very likely having this problem or will soon. Postini is a good example of this type of setup, but there are others.
So both sides are using SPF, and both think that problems with SPF "violations" are the other one's fault. How do you tell who is right? Well, if you've already validated your record against an SPF query tool, a good source of arbitration is for a sender to send a message to Port25's SPF check service. They'll send you a return message with full details about whether your message complies with SPF properly and if they'd have delivered it. Ours, for example, does comply with SPF properly. And largely, we have no issues, but lately we've seen a rise in bounced messages due to reported SPF problems, and in actual fact, they have all (every single one) come from Barracuda appliance owners.
Plainly, if you are so dim witted as to put a Barracuda anti-spam appliance in place, little if any of this is making any sense. And that's the problem. What you're trying to do is admirable - cut down on spam. What you're really doing isn't - you're blocking legitimate email because you don't understand how this stuff works. Stop it. If you have a Barracuda, turn off SPF checking. It's broken, and you're eating up a lot of our time chasing issues that aren't in our sphere of influence. If you are unwilling to turn it off, see if you can adjust the default behavior for SPF violations to be something other than BOUNCE. Amateurs.
SMTP allows for this kind of impersonation because, by itself, nothing in SMTP ever checks to see that you are who you say you are in the FROM line. Remember that SMTP has been around longer than most system administrators and was built in a time when everyone on the internet knew everyone else by first name. "Trust" was never a design principle for the internet, and we've been dealing with the fallout ever since. The bottom line is that, as far as SMTP goes, you are who you say you are because you say so. If only it were that easy in real life.
Enter the Sender Policy Framework. SPF is implemented by both senders (as a DNS entry, saying "mail from me is going to come from the following addresses only"), and receivers (by checking the IP address of the sender connecting to your system against the list of valid addresses for the domain they say they are at). Simple.
The problem is this - if you don't implement SPF properly at both ends, it ends up causing more problems than it solves. Confused system administrators are likely to get this wrong, and are likely to be even more confused when you explain to them why they got it wrong and how to fix it. It's happening more and more often, and it's a pain.
The bane of a mail administrator's existence is the false positive - that is, a message which is legitimate, but that got blocked or bounced erroneously by the cocktail of email protection mechanisms they employ.
If as a receiver, you are not properly evaluating SPF for incoming messages, you are creating a problem for your users and the people trying to communicate with them by creating false positives in droves.
Worse yet, if your default action when you think there's an SPF issue is to bounce the message, you eliminate any chance that a human being can spot the problem and bring it to your attention.
Such is the case with tons of Barracuda anti-spam appliance users, who are responsible for a rash of "550 Rejecting for Sender Policy Framework" replies reaching support desks around the world.
A proper implementation of SPF will evaluate the IP address of the connecting system against the list of allowed IP addresses for that sender's domain based on their DNS record for SPF. No more, no less. In the case of the Barracuda, their devices are erroneously evaluating not just the IP address of the connecting system, but the IP addresses of every hop along the way. It is as if they inherently assume that even if the connecting system is in the SPF list, it is an open relay and is being abused by a spammer.
We've seen screenshots of Barracuda administrative consoles, and for messages they blocked as false positives due to "Sender Policy Framework", the details reveal that an IP address of a server involved early in the relay was NOT in the SPF record for that domain - even though the server establishing the connection to the endpoint WAS in the SPF record for that domain. If you use a smarthost configuration, whereby your public-facing mail server always relays to a service "in the cloud" for anti-virus scanning, etc, you are very likely having this problem or will soon. Postini is a good example of this type of setup, but there are others.
So both sides are using SPF, and both think that problems with SPF "violations" are the other one's fault. How do you tell who is right? Well, if you've already validated your record against an SPF query tool, a good source of arbitration is for a sender to send a message to Port25's SPF check service. They'll send you a return message with full details about whether your message complies with SPF properly and if they'd have delivered it. Ours, for example, does comply with SPF properly. And largely, we have no issues, but lately we've seen a rise in bounced messages due to reported SPF problems, and in actual fact, they have all (every single one) come from Barracuda appliance owners.
Plainly, if you are so dim witted as to put a Barracuda anti-spam appliance in place, little if any of this is making any sense. And that's the problem. What you're trying to do is admirable - cut down on spam. What you're really doing isn't - you're blocking legitimate email because you don't understand how this stuff works. Stop it. If you have a Barracuda, turn off SPF checking. It's broken, and you're eating up a lot of our time chasing issues that aren't in our sphere of influence. If you are unwilling to turn it off, see if you can adjust the default behavior for SPF violations to be something other than BOUNCE. Amateurs.
Wednesday, November 16, 2011
You Can Toucha The Mango
I've used enough iOS devices to know them inside and out. Simple, clean, no frills - much like Windows for Workgroups 3.1. It doesn't do a heck of a lot other than let you launch apps, and the apps don't really do much outside of their sandboxes.
Same with Android, with the exception of being able to tweak it to look and behave how you'd like. You can't really cover up the fact that it's little more than a platform for launching apps. The cases and screens may change, but at the end of the day, they appear to me no different than iPhones or iPads.
Both iOS and Android are essentially software showcases. They provide developers a nifty, powerful, portable stage to do their thing and a solid commerce mechanism to help them get paid. They're giant digital flea markets (or malls if you will) with everything you need from anyone who makes it, in one convenient spot. The iOS mall is very exclusive, and the Android mall is kind of like the run down joint in the bad end of town where the owner doesn't seem to know or care what happens as long as he gets his cut.
Color me uninspired. The Apple fanbois and Google fandroids can argue about which app launcher / flea market is better than the other. It's like arguing the difference between off-white and eggshell.
Enter (of all people) Microsoft. Yes, the same Microsoft who only ever accidentally trips over an extremely successful product. The same Microsoft with a total lack of coherence, consistency, or a compelling vision for how their products should improve people's lives. Slowly, it appears, they have been coming to grips with the world in which Apple and Google would see us live.
The living room is kind of where it all started. The XBOX 360 platform has been extremely popular, for all the right reasons. It works well. It looks dynamite. It's cheap. It's great with media. It has access to streaming content. It's audiophile and home theater enthusiast-friendly. It's small. It's WiFi. The games are compelling. The multiplayer Live experience is impressive. You don't need to be a rocket scientist to work it. Everyone has one. People continue to trust Microsoft to get it right, whether or not they realize it. A console from two or three years ago will still hang with the latest games, no issues. Brilliant. New stuff like Kinect works with any XBOX 360, no matter how old. Brilliant! Executives across the nation have ditched their Harley helmets for copies of Halo and Modern Warfare. It's cool to be a gamer...finally.
In another part of Redmond, another group of people appeared to have been told "find a spot in the mobile market where nobody else dares go, and own it." The result is impressive. Very impressive. Even if nobody knows it yet, it's fantastic.
Windows Phone 7 was the best mobile user interface of any device ever, period. And it was flawed in some significant ways. There were lots of things you couldn't do with it that you should have been able to do, but at its core, WP7 was a completely different approach to smartphones. Revolutionary, really. Yes, there were some sandboxes, but the difference was that there were also cool Habitrail tunnels connecting them, and very smart hamsters trained to run back and forth.
For example, on WP7, a contact becomes an incredibly powerful thing. The phone almost magically combines everything you know about a person from every source you feed it - Exchange, GMail, LinkedIn, Facebook, etc, so that a person is represented in one "object". You don't need to download a bunch of apps to do it - it just knows, out of the box, that you're probably on several of those services.
Because of this, any action related to a contact is available just about everywhere. You can write on their Facebook wall, send them a tweet, a text message, an email, call them, pull up a map of where they work - all in one place. And you get to do it in what must be the best implementation of graphic arts ever employed in a user interface. It looks great, and it works phenomenally well.
Common bits of information are recognized everywhere. An address, for example - whether it be part of a contact, or your current location (the GPS is freakishly fast and the street address resolution feature is freakishly accurate) - is understood as an address. When you tap on an address, what should happen? A map should appear. What might people want to see in addition to a dot on a map? How about a list of nearby restaurants and things to do? What information should show up if you tap on one of those links? Everything. Phone number, hours, reviews from popular websites, who has checked in there on Facebook, spoken turn-by-turn driving or walking directions, etc. Everything of interest, that you would most likely want to do or know about a place or a person, has been captured and gorgeously integrated in an incredibly simple interface. Two taps simple.
The dependency on tethering to a computer appears to be somewhat diminished, but you will need Zune on PC (or the Mac plugin thingy) to do some things. The good news for PC folks is that the latest Zune is also beautifully designed and simple to use. Microsoft is doing some absolutely remarkable things in terms of user interface. It just works. Hardly a row/column table to be found anywhere. There are definitely feature issues in Zune, but someone else can dive into that. I'm just happy (actually, ecstatic) that Microsoft is demonstrating a capability approaching mastery of the user interface and that the penny has dropped for them in terms of making deep, meaningful interoperability of their various products and platforms a priority. SharePoint, Lync, Office, Exchange, Windows 7, Server, and now Windows Phone. They are all connected. No, really connected.
I am now using the Samsung Focus S. Yes, there are still gaps I'd like to see addressed, but the Mango release has done an amazing job of addressing the most common issues people doing an evaluation would run into. You have to dig at least a little bit to uncover the dead bodies now, whereas before you had to step over them. If I had no interest in connecting to corporate email or no concerns about managing them, I would never use another phone. The app marketplace is not on-par in terms of absolute quantity, but what is there is of high quality and the selection is broad enough to facilitate more time wasting and work-from-Starbucks activities than you can probably justify with a straight face.
For the first time in as long as I can remember, I love my phone.
Friday, November 11, 2011
Froyo Snackins
It took careful explanation by a "fandroid" over lunch one day to understand Froyo, Gingerbread, and Ice Cream Sandwich. Are they even trying? Is there a dartboard somewhere in Google headquarters with a dessert menu stapled to it?
If you struggle like me with all the TOMS shoe-wearing meme-ery going on around the Android camp, you'll be happy to know that each subsequent "major" version of an Android operating system gets a new name, and each new name starts with the next letter in the alphabet. Froyo begat Gingerbread, which begat Ice Cream Sandwich (F-G-I).
Given that, the next Android OS name will begin with a "J", the one after that a "K", and so on. Which got me to thinking...if I were to be as dopey as possible, what names would I come up with for future Android releases?
The following is the fruit of that labor.
If you struggle like me with all the TOMS shoe-wearing meme-ery going on around the Android camp, you'll be happy to know that each subsequent "major" version of an Android operating system gets a new name, and each new name starts with the next letter in the alphabet. Froyo begat Gingerbread, which begat Ice Cream Sandwich (F-G-I).
Given that, the next Android OS name will begin with a "J", the one after that a "K", and so on. Which got me to thinking...if I were to be as dopey as possible, what names would I come up with for future Android releases?
The following is the fruit of that labor.
- J - tough call, but either Jelly Roll or Jujube
- K - should be Key Lime Pie, but with these people you might well get Kaiserschmarrn
- L - Ladyfinger? Maybe, but that ruins tiramisu later. I'm going with Lemon Bar
- M - Mincemeat Pie. Yes, going for stupid intentionally. Tough to out-stupid "Froyo".
- N - They like cold stuff don't they. Neapolitan Sundae?
- O - would ABSOLUTELY HAVE TO BE Oreo Cookie, but if that would cost them a cent, you'll get Orange Sherbet and like it.
- P - Peanut Butter Fudge
- Q - um, let's hope the next great thing is out by then.
Happy Friday.
Subscribe to:
Posts (Atom)