In particular, the ability of the Egyptian government to coerce backbone providers to essentially drop the country off the Internet, most likely through disabling of BGP associations has been interpreted as a frightening precedent for enabling the United States government to shut off dissent.

The Telecommunications Act of 1934 (full text here) already gives the President very broad powers over communications infrastructure in cases of “war or emergency” (Sec. 606).  This act, while obviously focused on radio communication, does not specify the communications medium.  Sec. 606(a) and (c) specifically pretty much specify that, in case of war or emergency, the President can effectively do as he sees fit with American communications infrastructure.  No distinction is made between private and government communications.

I had a look at S.3408. As far as I can tell, it establishes a directory of “Cyberspace Policy” which basically oversees most US non-military resources.

Most of it seems eminently reasonable (e.g. advising the President on security issues, coming up with risk management and incident response methods, helping to coordinate development and implementation of standards, making sure one hand knows what the other is doing, etc.)  The law also defines the responsibilities of US-CERT, which already exists.

Where it gets a bit weird is Sec. 244(g)(1) – I may be misinterpreting this, but says that the Director of US-CERT can obtain “any…information…relevant to the security of…the national information infrastructure necessary to carry out the duties, responsibilities, and authorities under this subtitle” (editing is non-destructive, i.e. I tried to not change the meaning of the phrase.) It’s very ambiguous, and implies to me a seeming total lack of control over what information (including confidential, personal data) the Director can access from anyone, anywhere. The bill does specify data protection/privacy requirements, but these appear to be often unclearly worded (a lot of use of subjective wording like “as necessary” or “reasonable”).

Sec. 248 seems very sensible (i.e. cooperate with other agencies, private companies, and foreign governments when dealing with vulnerabilities and attacks, but in terms of “recommendations”). 248(b)(2)(C) basically seems to say “come up with a plan in case shit gets real”. Fair enough.

Sec. 249 “National Cyber Emergencies” is where I assume the problem lies.  The Director, when the President declares this, can require owners of “critical infrastructure” that’s covered by 248(b)(2)(C) to take emergency measures that are the “least disruptive means feasible”. Such emergencies have a 30 day runtime, but seem to be extendable indefinitely. “Critical infrastructure” is defined as relating to section 1016(e) of the USA PATRIOT Act (42 U.S.C. 5195c(e)) — i.e.

the term “critical infrastructure” means systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.

On the other hand, Sec. 3 (14) refers to “Federal information infrastructure”, Department of Defense systems, “national security systems”, and “national information infrastructure”:

(A)(i) that is owned, operated, or con trolled within or from the United States; or

(ii) if located outside the United States, the disruption of which could result in national or regional catastrophic damage in the United States; and

(B) that is not owned, operated, controlled, or licensed for use by a Federal agency.

This is extremely vague, and despite the reference to the USA PATRIOT Act definition above, no information is provided as to who defines this.  Good luck getting AT&T staff in Germany to shut off lines when ordered to by headquarters.  Similarly, under the above definition, the Zambian national Cobalt Thorium G mining corporation’s email servers could be construed to fall under (B).  Talking Points Memo had an interesting run-down on the “Kill Switch” issue, but unfortunately glossed over the aspect of defining what is covered.

The rest of the bill deals with definitions of agency responsibilities, mainly on how to secure government information infrastructure and information.

Interestingly, S.3408 also spends a lot of time discussing the responsibilities of US-CERT and the Director of Cyberspace Policy with regards to risk management, communication (e.g. ensuring that the left hand knows what the right hand is doing), establishment and application of standards, vulnerability and threat response, and generally things that the industry has been screaming about for years.  The Russian Federation, Chinese People’s Liberation Army, and Israel, among others, have established significant information warfare capabilities, variously specializing in sabotage, espionage, denial of service, and other aspects.

The United States, by comparison, maintains the National Security Agency, US-CERT and numerous public-private partnerships, various military units specialized in “cyberwarfare”, and branches of several government agencies for preventative, offensive, and defensive operations.  Coordination among these makes sense, especially if it involves single points of contact and distribution for vulnerability and threat information (beyond the Dept. of Homeland Security‘s asinine “color” threat scheme (which is being discontinued in any case.)

The idea of any government being able to “shut down” communications is arbitrarily egregious, but that’s a political, ideological concern.  However, on a purely practical level, I don’t see it as feasible for the United States to do so.

Ars Technica has a discussion about the “hows” of disconnecting a country.  They make a good point:

Like in Egypt, in Europe almost all interconnection happens in the capitals of the countries involved. Not so in the US: because the country is so large, and traffic volumes are so high, large networks may interconnect in as many as 20 cities. Numerous intercontinental sea cables land in the Boston, New York, Washington DC, Miami, Los Angeles, and Seattle regions. So in Egypt or many medium-sized countries, killing the connections between ISPs wouldn’t be too hard. In the US, this would be quite difficult.

Likewise, DNS is out due to the distributed nature of root servers.

More importantly, though, Constitutional issues aside, the U.S. is simply too distributed.  Too many commercial interests are involved (shut down the NYSE’s connectivity, and Goldman Sachs bankers will show up on the White House lawn with shotguns), U.S. law enforcement and regulatory bodies are too decentralized to reliably be able to enforce a shutdown at an ISP level as what happened in Egypt.

Read the bill, draw your own conclusions, but don’t panic-monger.

HFT is a hot topic in circles ranging from regulatory and compliance discussion forums, over smaller traders, to conspiracy wingnuts.  Despite the fact that it’s just one technological tool among many to give exchange participants an edge over competitors, I tend to side with the conspiracy theorists, especially insofar as it’s an approach to transactions that by its very definition gives an edge to larger market actors — thus skewing the idea of a “fair market”.  Various individuals have claimed that this goes so far as to allow participants to manipulate prices using fake orders, but I don’t know enough about trading technology to comment on this.

Due to the very technologically intricate and detailed nature of HFT platforms, very few people understand how they work — and overtaxed regulators and security & compliance organizations thus are left in the dust when it comes to ensuring that such solutions do not present a security and operational risk, not just to the companies who run them, but to overall market stability.  Remember, complexity is almost always bad if you can’t reliably understand it with a reasonable grasp of the subject matter.

The article has one particular paragraph that rings very true:

While applications are combed for typical application vulnerabilities like SQL injection or cross-site scripting, they’re not examined for operational vulnerabilities: A rogue trader could, for instance, change a single variable to allow far more risky trades than a bank or its clients intend–the sort of trick that Société Générale trader Jerome Kerviel may have used to make unauthorized trades in 2008 that cost the firm $7 billion.

Yeah, basically.  Many of the people who use these toys are very bright autodidacts, creating customer tools for exotic, structured products.  Even off-the-shelf software is frequently written using what I like to call “functional programming” — i.e. a very smart person with a Visual Basic book coding a solution to an operational requirement without paying attention to best practices that may, in any case, be outside of the scope they care about.  Investment firm management is likely to turn a blind eye to even obvious flaws in such software, due to the fact that traders (a) bring in massive amounts of revenue and (b) are increasingly the only people who understand certain market types.

The rise in black pools and other off-exchange trading will only increase the latter phenomenon; I’ve seen trading floors where it was pretty common for one person to be responsible for a particular exotic product; frequently, this person might even have been the one who helped create the actual market.  Remember, you can trade pretty much anything, as long as you have a willing counterparty…

How do you deal with such issues as a security professional?  To many who are not trained in the black arts of financial transactions, much technological innovation in modern markets is the driving force behind an increased complexity that regulators cannot hope to oversee effectively.  Analyzing security issues in such tools also becomes difficult, even from the inside, even when a company is willing to implement controls — the line between legitimate exploitation of a weaker player’s market position and an actual security intrusion blurs to the point where traditional technical vulnerability analysis is no longer an option.

I don’t have a solution, beyond an innate distrust of anything I don’t understand in detail, but I believe that companies’ willingness to reduce their exposure to security issues stemming from overly complex trading software is  more a philosophical than a policy or technical question — how far are we willing to go to exploit loopholes in the spirit of market regulation?  Are we willing to sacrifice potential high risk + high profit combinations in order to remain in more staid trading areas?

And most importantly, if management won’t listen, as a security guy, can you sufficiently CYA to avoid being caught up in a potential technical or regulatory failure of one of your employer’s systems that’s just too intricate to reliably review for risk?

This particular article lists examples of electronic warfare by regime-friendly groups such as the “Iranian Cyber Army”, recently suspected of numerous attacks against organizations seen as hostile to the Iranian government.  Ironically, these included Chinese search engine baidu.com in retaliation for some perceived slight by the Chinese government — this shortly after several Chinese organizations have become increasingly implicated in online hits against U.S. and other Western government and corporate targets; a recent report in The Associated Press / The Guardian mention the Chinese universities Shanghai Jiaotong and Lanxiang Vocational Institute as sources of the “Aurora” attacks against Google and others.  On a humorous side note, if 1337 xenophobic script kiddies friendly with one totalitarian regime are now going after 1337 xenophobic script kiddies friendly with another totalitarian regime, it might become difficult to figure out who’s on whose side…

That said, there’s not much an outsider with technological know-how can do to help victims of censorship and repression in any country beyond providing them with the education and means to get around official repression of communication with each other and with the outside world, and to avoid being detected by government thugs while doing so.  A friend of mine, when asked to to provide help and information about censorship avoidance to an Iranian group, took a very cautious line, making it very very clear that he was reluctant to offer anything that carried even the slightest possibility of someone being arrested, tortured, or even killed if they were found using it.  I take a bit of a different view — solutions like PGP, TOR, Haystack, anonymous remailers, or SSL enabled CGI proxies, combined with private browsing available on most newer browsers, are powerful stuff, and with a modicum of care on the part of their users, can conspire to throw a hefty wrench into the surveillance machinations of dictatorial spooks.  The best anyone can do is to make users at risk of brutal crackdowns aware of what could possibly go wrong, give them a good head-start on how to use their new toys, and let them be adults about making an educated choice.  After all, in the case of the Iranian protesters, these are people who’re willing to go out on the street and be shot at for what they believe in.

So much for “passive” assistance — giving people better anonymous / encrypted communications tools and the knowledge on how to effectively use them.  What about active help, though?  Beyond the usual low-level stupidity found in IRC channels (e.g. background noise of the “www.bobsautodetailing.com pwn3d by H4X0RZ 4 ALLAH AGAINST 4m3r1kkkAH” variety), attacks on the infrastructure of Western countries and organizations from Russian, Iranian, North Korean, Chinese, and other groups, presumably with at least some tacit blessing from their governments, are pretty common.  Botnets designed to carry out probes and hits on infrastructure, launch DDoS attacks, create economic sabotage, steal sensitive data, and other bad things, are pretty common in the wild.

Cybercrime legislation in most developed countries is designed to pursue and allow prosecution of even casual probes by unauthorized persons.  Whether one agrees with laws or enforcement tactics or not, the goal is to keep anyone, no matter what motivates them, from generally screwing things up by spying, stealing, or vandalizing.  Unless it specifically takes into account intent, the law doesn’t differentiate between amateurs or professionals — it’s all a crime.  Why?   Partially because attacking a person/host/company/government via a network is the technologically easiest, least physically risky way of getting to the goodies, and because it’s often impossible to differentiate between the casual hacker and the much-vaunted bugaboo of organized cybercriminals and government-sponsored electronic espionage.  The idea, I suppose, is that tolerating any intrusion means that the world economic system as we know it will grind to a standstill (or at least your job and mine will be made that much more difficult.)  Maybe, maybe not, but without such laws as a deterrent, I’m sure the barriers to causing grief to legitimate business would be a lot lower.

But what of aiding and abetting attacks against distasteful regimes or their allies / henchmen?  A few years ago, the idea of counter-hacking, or ethical hacking aimed at taking out threats either by sabotaging those responsible or by “cleaning” affected infrastructures when unsuspecting owners could not or would not, was in high discussion.  Most security professionals in my circle of acquaintances seemed to be roundly against this concept, due to the potential for a slippery slope, and for unacceptable collateral damage — plus, what good is it to have and enforce laws against illicit intrusion when the “good guys” themselves are guilty of violating them, even if they are perfectly well-meaning?

Given how hungry my non-technical Iranian friends were for any information about “passive” tools as those described above, I’d imagine groups in opposition to the government (supposedly there’s now a “Green Cyber Army“) would imaginably be equally happy for any assistance from sympathetic types in the West.  As someone strictly in favor of the rule of law, I can’t condone any illegal actions of the sort these guys are indubitably carrying out, but anything that helps cause grief for kiddies hacking in the service of thugs is ok in my book.  A few dozen clicks to waste here and there to waste the bad guys’ bandwidth, a Metasploit download mirror, or an open proxy or TOR gateway probably wouldn’t violate the spirit of the law.  Wink wink.

We were recently asked to put together a requirements paper for a PKI that was being re-engineered from the ground up. It occurred to me that this might actually be a stellar opportunity to help a client get things right from the start. So, why do we always get bogged down in PKI-related organizational or management issues?

Obviously, the PKI’s main purpose is management of digital certificates for persons, organizations and technical entities. Certificate keys fall into three general categories, which I’ll use Entrust nomenclature to describe: encryption (obvious enough), signing (you can be sure that what you got from me is what I intended to give you) and non-repudiation (you can be sure that I cannot disavow what I gave you.) So, let’s look at what you might actually use these for:

• User authentication (such as web sites or to workstations via smart cards)
• Email and file encryption
• Secure key exchange (e.g. for phase II IPSEC negotiation) between devices
• Source code, binary and other data signing (e.g. financial transaction information)

Why is this important? Two reasons: first, your certificate templates, which govern the formats of the certificates and their usage, depend on what you intend to do with certificates. In most certificates, for example, there is a key usage flag (a hex value) that is used for this.

Second, and more importantly, your LDAP structure must reflect you organizational structure, certificate usage and a number of other factors from the outset. This is usually the largest bone of contention in PKI design; the classic example is the Jane Doe who marries Bob Smith and changes her last name. So a distinguished name (DN) like C=Albania,O=Bob’s Widgets Inc,OU=Research,CN=Jane Doe is now kind of messy. This can be dealt with by using a friendly name, but you get the idea. Changes in requirements for LDAP attributes and DN structure affect other areas, like host naming, validity of signing and encryption keys, and and and. It gets even more fun when you start doing things like cross-certification, setting up a metadirectory for multiple directories, or integrating existing directory structures.

The upshot of all this is that a PKI affects all aspects of an enterprise that are in some way involved in authentication, security, encryption, verification of data integrity, etc. — and it has to pretty much be done right from the outset, or you run into problems of application integration, user acceptance and overall cost. We know of several directory projects that had their scope drastically cut down after they were built, when it was discovered that they simply wouldn’t work for some of what they were intended for; someone obviously hadn’t done their homework.

Most tragically, sometimes design decisions are taken or changed late in the development phase. I will recount one infamous experience of a client who, based on a few casual observations our team made, called a stakeholder meeting consisting of a room full of 35 people shouting at each other, and reversed his entire enterprise directory strategy _twice_ in the course of two hours. We’d done the underlying design and recommended a certain set of project technology several months previously, but were ignored due to political reasons. In this meeting, our group just tried to remain rational and calm, and to give information when prompted, but in the end we realized there was just nothing to be done and snuck out. It was telling that nobody noticed.

Probably, everyone who’s affected will want a piece of the discussion, and we all know how well design by committee works. Many managers also seem naturally threatened by (or nervous about) any technology that effects a lot of blanket organizational and procedural change — a perfect categorization of an enterprise PKI. It doesn’t help that such products sometimes carry the stigma of taking away autonomy from other groups; at some level, any infrastructure component using PKI certificate must follow certain standards and procedures, there’s just no way around that. This is often seen as a loss of self-determination, or it may require technical effort, and who’s going to pay for that?

So, how does one deal effectively with this? A lot of good PKI design practice involves some pretty common-sense elements:

• A knowledgeable, strong project manager who can organize management buy-in and support
• A small design team who’ve done this before and have a clue what they’re doing (good luck!)
• Individual discussions with potential stakeholders about what they want and how their concerns can be addressed
• A _lot_ of time spent on research and design — use the “hire a 6-year-old to spot any obvious flaws in your plan” model liberally here
• A clear idea of budget responsibilities in PKI deployment — but not to the end that every affected team will try to pawn off even minor changes on the PKI budget

And last but defnitely not least, a really good LDAP guy, you won’t regret it.

p.s.:  If you’re interested in reading more about non-repudiation, including how it differs from the usual technical usage of “signing”, have a look at Non-Repudiation in the Digital Environment.