Things are so bad in China that its gross domestic product growth rate may fall from double digits to the dowdy level of 8%. Eight percent, by the way, is a level at which the United States is unlikely to ever grow again. It can't. Our economy is simply fully developed. Thus the sobriquet "developed economy." I know, not exactly catchy.

..

All of the headlines show China sitting at a crossroads. But the reason I have faith in China is that it has historical proxies. Since 1970, with the exception of a few OPEC members, only four economies have made the transition from emerging to developed markets (meaning their per-capita incomes exceed $15,000 per year): Taiwan, Singapore, Hong Kong, and South Korea.

These four economies have two things in common. First, they have few natural resources; and second, they are dominated by Chinese values and the traditional Chinese work ethic. Mainland China is different only because it got a later start.

“When I wrote the book, I thought I was writing about the future. When it was going to press, I thought it was about current affairs. Now I wish it was about history.”

This part below reminds me a lot of 1995 security architectures used to defend 2008 integrated applications

The present crisis had been triggered because the international financial system had undertaken activities that had “far outpaced the ability of the infrastructure to sustain them”, said El-Erian.

And it was not just the markets that could not cope with their own changes, but governments as well. Significant weaknesses had been exposed “from the firms, to the regulatory agencies, to governments, to multilateral oversight”.

“Turbocharge that with financial innovations, which history tells us we tend to overproduce and overconsume, and it’s inevitable that you will get a series of market accidents,” he said.

But there's this lovely new segment of lightly licensed spectrum in the U.S., the 3.65 GHz band. It's a non-exclusive licensed band available only in parts of the country that don't have pre-existing ground-to-satellite or radar uses that overlap. This omits most of the eastern seaboard and most major cities; Seattle is one exception.

The licensing mechanism allows any number of operators to obtain inexpensive licenses, and register the base stations they use by location. If interference arises among base stations, operators are required to work out the problems themselves. I wrote extensively about this band and its rules on 9-May-2008 in profiling Azulstar, formerly a metro-scale Wi-Fi firm, but now a big proponent of WiMax in 3.65 GHz. I also went over the rules for the band on 11-June-2007 when the FCC announced the arrangement.

Several firms offer base station and customer premises equipment for this band now, so close to the 3.5 GHz band more commonly exclusively licensed in Europe and elsewhere. WiMax equipment is available because the 3.65 GHz band can be used with WiMax without any modifications to that protocol, although limited to just 25 MHz of the 50 MHz that the FCC set aside.

Equipment that conforms to a more stringent set of rules about contention and other factors can use the whole 50 MHz, and that's where 802.11y comes in. It's an extension of Wi-Fi to cope with the specific needs--and to open Wi-Fi technology up to 20 W EIRP, a vastly higher power output. This could allow connections over 5 km, the group says.

The Wikipedia entry on 802.11y, clearly written by someone involved with the specification, notes that three specific additions are needed: a tweak to support the way in which the FCC wants contention among competing devices to work; a method for an access point to tell a station (a connecting radio) that it's about to switch its channel or its channel's bandwidth, and the station should do likewise; and a mechanism to handle a base station allowing or revoking permission to use the spectrum without uniquely identifying the user's system or broadcasting its precise GPS-based location.

The standard is near completion and initial approval. I don't have any knowledge about whether any mainstream Wi-Fi equipment makers or metro-scale equipment makers are looking into building 802.11y into their gear.

The fact is that this could be a great technology for the mostly sub-metropolitan markets that 3.65 GHz is available in, although it has the same pain as WiMax: all new gear on the towers and all new adapters for customers.

Minneapolis suffers the heartbreak of leafage: Leaves are popping in Minneapolis, and Star-Tribune columnist Steve Alexander writes that residents are seeing some Wi-Fi reception problems on that city's Wi-Fi network. This is the only big-city network that can be currently described "successful," even though its long-term success has to be proven out. The firm responsible, USI Wireless, told Alexander they're working on adjusting about 5 percent of antennas to cope with the pesky greenery.

St. Louis Park sues ARINC over Wi-Fi network: The Minnesota town says the network never worked, and had earlier discussed a lawsuit. The city wants the value of the contract ($1.7m) plus a very modest amount in damages and fees ($50,000). The city plans to start removing gear if ARINC doesn't sometime in June. But they have to deal with 490 poles erected to hold the nodes and solar-charging gear--sunk into concrete. More recent testing showed that the network worked well in some areas, but the majority of the network did not, according to the Star Tribune.

Verizon builds out fiber in AT&T territory: Interesting sign of competition in otherwise monopoly-per-provider-type world. Verizon is using AT&T's hard-won statewide video franchising rules in Texas to build competitive fiber in Dallas suburbs. They're apparently not bringing telecom; they're acting like a cable TV firm with data. Verizon owns chunks of territory all over due to it encompassing GTE in a deal years ago. GTE serves suburbs west of Portland, Ore., and east of Seattle, for instance, while Qwest serves most of the rest of each state.

Foster City Wi-Fi dies on June 20: MetroFi is unlighting its cities, and Foster City opted not to spend the nearly $200,000 asking price MetroFi put on its equipment. MetroFi might still find a buyer, but June 20 is the network's current final day. Naperville, Ill., also expects a June 20 shutdown. They, too, were offered the network hardware for 200 grand.

Chehalis lights up: A small city in southern Washington votes to put in Wi-Fi hotzones. The cost is about $53,000 and annual fees $15,000. Funds will come from existing tax and grant sources. The city chose to install service to make sure they're not missing a checkbox on the amenities list for visitors and businesses rather than for a particular, measurable goal.

Nearby Centralia pulls its Wi-Fi: A pilot project in the larger city of Centralia, Wash., a bit north of Chehalis, is shut down when poles used to mount Wi-Fi radios are removed as electrical wires are buried. (The reporter here confuses broadband over powerlines (BPL) with broadband wireless.) The system might be restarted later.

Craig Settles writes up Pennsylvania's Cambria County wireless success: This is a network built for particular municipal purposes, part of Settles's long-time drumbeat about having applications first and then networks built for those networks second. He notes that Cambria built a 700 sq mi network that sounds nearly cost neutral through efficiency and cost conservation--it's cheaper to get much more service with this network than it was for a smaller array of services with incumbent-provided networks.

Santa Fe residents oppose Wi-Fi in the library on health grounds: You know what I have to say about how provable this has turned out to be in clinical studies. I am, however, as always, concerned about these people's health, even if I don't believe that Wi-Fi (or EMF) causes their problems. The group opposed to library-Fi is citing the ADA in this case, uniquely I believe. Six libraries suggested that EMF triggers seizures in epileptics, something I've never heard cited before; maybe CRTs (flickering), but EMF? Wired is substantially less kind than I am, pointing out that EMF other than Wi-Fi produces vastly higher signal strength. (They're sort of ignoring signal strength at a given point where an individual stands in relation to a transmitter, however.)

With in-house IT, you pay your upfront capital costs and maintenance fees and you get whatever compute power you paid for. If you over-specify, you have excess computer power or disk - you are wasting money.  If you under-specify, you may be forced to raid your ‘rainy day’ budget and order new hardware.

A primary selling point of Cloud Computing is the ‘pay by the drink’ billing model - you only pay for the CPU cycles and storage you use - that’s it.

If you run any IT security tools at all, Cloud Computing may impact the way you calculate your IT security budgets.

Assessing The Cost of Runtime Security

Security costs can be overt or hidden:

• budget items spread across infrastructure, security, compliance, midrange.
• the runtime security costs of security tools that execute on the systems.

How many organisations know their runtime security compute costs?  My guess is not many.  Under the traditional IT billing model, you mostly don’t need to figure this stuff out. As long as your security tools don’t chew up the CPU unnecessarily or fill the disk, everyone is happy.

The performance of security products varies greatly.  On the negative side, poor design or implementation are problems only the vendor can address.   Site specific issues arise through all kinds of madness - customers failing to “read the label” and provision properly, insufficiently trained people making poor configuration choices or simply relying on the default settings in a very non-default environment!

The negative side effects of in-line security tools hit home as system load increases.  Access checks, logging and other ‘in-line’ security operations may perform fine under normal load fail to scale as load increases past a certain threshold.  This can lead to CPU spikes or poor disk access patterns.

Switch Off Or Pay Up?

To bring this closer to home, lets explore how the impact of security tools plays out today under traditional IT and tomorrow, under Cloud Computing.  Lets eavesdrop on a fictitious conversation between Oscar the ORACLE DBA and Simon the Security Dude.

Oscar: Hey Simon, your Security Agents are killing system performance again. Anna in accounts called up to say they can’t do the Quarterly close, the jobs are getting killed before they finish.

Simon: Hi Simon, I understand but we can’t just disable all the security!

Oscar: Well, we need to do something if we are going to finish posting our numbers this quarter. Are you volunteering to explain to our CEO why we didn’t?

Simon: Hmm. Let me check the agent logs, perhaps there is a problem.

Oscar: I already checked them, no errors reported.

Simon: Hmm. I’ll log a call with the Premium International Support Service.

Oscar: You did that last time and the support guy stuck to the party line that the security agent takes 5-10% of CPU. We know those numbers are wrong from our benchmarking - sometimes it takes 20% of CPU and always a lot more during quarter close.

Simon: Hmm. Are there any other processes running on the system we can disable for a while?

Oscar: Nope - we’re running a tight a ship as we can here. I’ve already told Steve from sourcing he is going to have to wait for his reports.

Simon: Hmm. Bugger. OK, I’ll disable the agents - but you must tell me as soon as the quarter close completes so I can start them up again.

Oscar: Thanks - will do.

A classic conversation under the ‘old regime’. Oscar is forced into an operational security decision due to an under-specified system or an over indulgent security agent. His only option in this scenario is to disable the poorly scaling security tool. He can’t just scream “Need more power!” and additional CPUs appear.

Now lets see how this plays out with Cloud Computing, where the change in paradigm will remove the compute limits and make your on the spot risk decisions link directly to your costs and security tool efficiencies:

Simon the Security Dude receives an auto-generated email from the Cloud Provider:

A virtual CPU was auto-inserted on virtual machine image FINANCE1 at 10:30am as Runtime Security Compute usage exceeded the agreed threshold in the SLA.   Please note, you have now reached your soft credit limit - please click the link below to authorize an increase. You currently have 4USD left in your account.

So what does Simon do now? He already tapped into his security compute budget five times this week and he’s running low. The silver lining is that at least he gets to make the decision now - he isn’t forced to ’switch off security’. If he has the cash, he can attempt to buy his way out of the problem. The obvious negative is “death by a thousand costs” - he’s running out of budget.

The root cause of the problem is that prior to moving to the Cloud, Oscar didn’t have a handle on how much runtime security was *really* costing. He didn’t know (a) his runtime security costs or (b) how much of that cost was unnecessary - caused by security tool inefficiency.  He wasn’t the one paying, so most of the time he didn’t have to care. Even if he had found a way to calculate his costs, he’d still have to figure out how performance differences of Cloud Computing would skew his numbers.

And therein lies the rub: if you don’t know your security runtime costs are today - and where the waste is - how will you cope “tomorrow” when it’s always your turn to pay for drinks at the Cloud Bar?

“Security in the cloud” just got more complicated with the introduction of “Cloud Mashups”.

What Do You Get When You Cross Salesforce.com and Amazon S3?

The answer we are told is Appirio Cloud Storage - a fully integrated Salesforce.com add-on that uses Amazon’s Simple Storage Service (S3) to store larger files. Previously, Salesforce.com users were limited to 5MB file uploads.

Read this quote from Appirio and think about it from a security perspective:

We’re excited not only about the service itself, but also what it represents. It shows where the industry as a whole can head - as the platforms mature, there is a substantial opportunity for ISVs to tie together the different clouds and provide offerings that extend and fill in the platforms themselves. In traditional enterprise application integration (EAI), packaged integrations were difficult to commercialize. The permutation of versions and customizations created and “n times n” problem, making it too expensive to create something “packaged” that appealed to more than a very small number of customers. But in the cloud, because SaaS providers commit to stable interfaces - Salesforce has maintained backwards compatability for more than a dozen revisions of its API - “integrating the cloud” can become a new class of solution.

From a security risk assessment perspective, you now need to factor in 3rd parties that hook into your “primary” cloud providers API.

If your company goes with Appirio, company data is now stored in Amazon S3 buckets paid for by Appirio, instead of storage paid for by Salesforce.com. This means your data is actually split across both providers (!) - old attachments and CRM data with Salesforce.com and new attachments with Appirio (if someone from Appirio is reading this and can say differently, please do).

As it happens, Salesforce.com already uses Amazon for computing and storage so its the same back-end storage. But what happens when another cloud storage provider pops up that offers a better deal? Lets say salesforce.com stays with Amazon S3 but Appirio migrates to the new player to attract more customers.  [Just to be clear, not picking on Appirio here - this applies to *any* ISV - particularly those that store data somewhere else in the Cloud].

Multiple cloud storage providers for a single app, raises some issues.

• Is ISV obligated to tell you they are migrating to a cheaper cloud storage provider? (think cross border data transfer issues).
• What security ‘certification’ will take place of the new provider and what visibility will you have of that?
• How much notification do you get before the switchover?
• If you don’t want to go with the new provider, but that is the only supported option, what happens to all your data? Even if we *assume* an export function is provided you still need to find an alternate ISV that has coded a compatibility layer to access your existing data. If you can’t, where do you export the data too? Will we have ‘frozen clouds‘?
• What integrity checks take place to ensure data was properly migrated over?
• When the migration happens, what clean-up happens at the source? (can anyone say forensic wiping?). What about any backup tapes or off-line copies? Who is responsible for making sure those are wiped/destroyed?

Suddenly your cloud storage arrangements have gotten more complex and thus, less secure. Security issues aside, how does an agile business cope with this? With multiple providers, data portability becomes a real issue.

And we haven’t even dug into the API level security issues yet! (yeah, you get to assess that too!).

As an Information Security community, we have to start figuring out some of these issues before we find our options severely limited…

What do you think?

Now Clive Feather draws my attention to a rather significant difference in the way that the law stands in Scotland.

Although on the face of it, both Acts do not extend to Scotland (Computer Misuse is a devolved matter) in practice the Scottish Parliament has used a Sewel motion (here for the Police and Justice Act, and here for the Serious Crime Act) to keep the law in both jurisdictions the same…

HOWEVER — as Clive points out — for some currently unknown reason the Scots brought the first version of the amendments into force on 1st October 2007 with this statutory instrument.

So North of the Border the law is currently different: you can prosecuted for denial-of-service attacks and locked up for distributing hacking tools… whereas in the rest of the country, it’s 1990 offences only for a few more weeks.

The changes that arrive in April with the Serious Crime Act won’t make much difference to the people of Scotland, all that happens is that one of the new offences stops being computer-specific and is more broadly drawn instead. Still, it makes you wonder why the denial-of-service offence particularly — which has been widely welcomed — has been delayed for over a year; if the Scots can cope with two law changes rather than one.

BTW: Clive has a marked up copy of the Computer Misuse Act on his website, with pretty colours to show the current form of the Act (it’s been amended a number of times now) and how it will soon look.