Archive for the ‘BIS’ Category



The Ostriches and the Kookaburra: A Fable for Our Time

Posted by at 8:38 am on June 19, 2015
Category: BISCriminal Penalties

Ostrich, Wainstalls by James Preston [CC-BY-SA-2.0 (], via Flickr[cropped]

Two austere ostriches, Osgood and Osbad, who lived near an old gum tree somewhere in the Australian outback, ran a successful business buying cattle prods made by Cow Poke, Inc., located in Kankakee, Illinois, and selling them to cattle farmers in Australia. One day they received an order from the kookaburra who lived in their old gum tree for one of their cattle prods. He even offered cash in advance and said that he would have many other orders in the future.

Osgood looked quizically at the kookaburra and wondered why a kookaburra might need a cattle prod, but decided not to ask. As it was an unusually warm afternoon, he decided to cool off by burying his head in the sand.

Osbad, dreaming of future orders and hoping to buy a bus trip to Perth for a holiday weekend, asked the kookaburra to hand over the money and promised to bring him a cattle prod right after he paid the money, which he did.

“Don’t you wonder,” said the kookaburra, “what on earth I could possibly do with a cattle prod?”

“No!” said Osbad, “I DO NOT!! It’s quite hot and I think I’ll join my mate Osgood and cool off by burying my head in the sand.”

“Actually,” said the kookaburra, “I’m selling them to my customers in Iran,” but by the time he had said the word “Iran,” Osbad’s head was completely covered with sand and he couldn’t hear a word that the kookaburra was saying.

When the Cow Poke Cattle Prods were discovered in Iran, investigators for the Bureau of Industry and Security (“BIS”) traced them back to Osgood and Osbad. The Australians served a provisional arrest warrant on the two ostriches who were subsequently extradited to the United States for trial. Once the jurors heard that Osgood and Osbad buried their heads in the sand, it was all over for poor birds, and they were convicted and sentenced to 6 years in a maximum security prison.

On appeal to the Seventh Circuit, Judge Posner upheld the conviction of Osbad and reversed the conviction of Osgood. He noted

There is no evidence that suspecting he might be [helping the kookaburra sell cattle prods to Iran, Osgood] took active steps to avoid having his suspicions confirmed. Suppose [the kookaburra] had said to him “let me tell you [where the cattle prods are really going],” and he had replied: “I don’t want to know.” That would be ostrich behavior (mythical ostrich behavior—ostriches do not bury their heads in the sand when frightened; if they did, they would asphyxiate themselves). An ostrich instruction should not be given unless there is evidence that the defendant engaged in behavior that could reasonably be interpreted as having been intended to shield him from confirmation of his suspicion that he was involved in criminal activity. [This is exactly what Osbad did, which is why we reverse for Osgood and uphold the conviction for Osbad.]

Osbad remained in maximum security prison, while Osgood was allowed to return to the outback in Australia. On his return, Osgood found a letter from BIS indicating that it had entered a thirty-year export denial order and fined him $250,000 for the sale of the cattle prods to Iran, noting that while ignoring red flags, without more, might save you from jail, it would not save you from the wrath of BIS.

Morale: If you’re going to bury your head in the sand, do it before the kookaburra sings.

The Seventh Circuit opinion in United States v. Macias, which I adapted here, makes clear that simply ignoring red flags is not enough to support the criminal intent necessary for  a conviction. The failure to engage in further due diligence in the face of red flags is not, in Judge Posner’s view, sufficient. Instead, there must be some “active avoidance” of learning the facts that the red flags suggest may be probable.  Another example of active avoidance given in the opinion involves a hypothetical situation where a landlord, fearing he has rented his property to drug dealers, changes his normal commuting route to avoid driving by the house, fearing he might see drug activity if he did.  The “active” in the “avoidance” here is changing the route.

A fuller and more serious discussion of United States v. Macias, written by my colleague Mark Srere and me, can be found here.

[Apologies to James Thurber.]

Permalink Comments (1)

Bookmark and Share



BIS Cybersecurity FAQs Reach the Right Result for All the Wrong Reasons

Posted by at 9:16 pm on June 16, 2015
Category: BISCyber Weapons

Photo: Harland Quarrington/MOD [see page for license], via Wikimedia Commons istry_of_Defence_MOD_45153616.jpgAfter the uproar generated by the proposed amendments to the Export Administration Regulations to implement the Wassenaar Arrangement’s rules controlling “intrusion software,” the Bureau of Industry and Security (“BIS”) tried to calm things down by issuing some FAQs on the proposed rules. Sadly, I don’t think these FAQs are as helpful as BIS apparently thinks that they might be.

To understand the difficulty here, let’s focus on the problem I discussed in this post indicating that the new controls could reach auto-updaters, like the one in Chrome, that bypass operating system protections designed to prevent installation of new software without user interaction. The FAQs now say explicitly that auto-updaters are not covered. That is a good thing, and you (that means you, Google) can take that statement to the bank.

But the reasoning that BIS uses to reach this conclusion is dicey at best. Here it is:

Does the rule capture auto-updaters and anti-virus software?

No. Software that permits automatic updates and anti-virus tools are not described in proposed ECCN 4D004. ECCN 4D004 software must be specially designed or modified for the generation, operation or delivery of, of communication with, “intrusion software,” which is separately defined. Software that automatically updates itself and anti-virus software may take steps to defeat protective countermeasures, but they are not generating, operating, delivering, or communicating with “intrusion software”.

The problem with this analysis starts with the fact that BIS admits that an auto-updater is “intrusion software.” That’s an inescapable conclusion, of course, because the auto-updater overides operating system requirements that require user interaction to install new programs and does so to modify system data by installing the new program. But, we are told by BIS, the auto-updater doesn’t generate, operate, deliver, or communicate with “intrusion software.” Well, that might make sense if the auto-updater is a cyber-version of parthenogenesis and pops into existence completely unaided. That, of course, is nonsense. Some program, either the auto-updater itself or some other lines of code in the programbeing updated have to be specially designed to operate, deliver or communicate with the auto-updater for it to work at all. And so that code, either as part of the updater or the program itself, is covered by the ECCN. In short, an auto-updater unless accompanied by a program covered by the new ECCN is useless and will not work at all.

The problem here is unavoidable because of the EAR’s broad definition of program:

A sequence of instructions to carry out a process in, or convertible into, a form executable by an electronic computer

The lines of code in Chrome that deliver the auto-updater are, without question, a sequence of instructions convertible in a form executable by a computer, i.e. a program, specially designed to deliver other lines of code to defeat operating system protections requiring user interaction before modifying system data. If Chrome is exported with those lines of code that deliver the auto-updater it needs a license; if those lines of code are stripped from Chrome, it can be exported but it will not auto-update.

Of course, BIS has made it clear that it does not think auto-updaters are covered, so I don’t think Google needs to worry about violating the law. Unfortunately, the reasoning that BIS used to reach this conclusion is nonsense.

Permalink Comments Off on BIS Cybersecurity FAQs Reach the Right Result for All the Wrong Reasons

Bookmark and Share



The District of Columbia? Is That Somewhere in South America?

Posted by at 11:59 pm on June 10, 2015
Category: BIS

African American Civil War Memorial Metro Stop by Clif Burns via Flickr [with permission]Those of us who live in the District of Columbia are used to, if not content with, the routine indignities imposed on us as residents of that tiny square of reclaimed swamp land sandwiched in between Virginia and Maryland.   Like convicted felons, we can’t vote for anyone in Congress.  Like third-world dictatorships, any laws enacted by our city council cannot go into effect unless approved by our unelected overlords in Congress.  When trying to book a hotel or buy a gadget over the Internet, we find we can’t fill out the order form because the District of Columbia, which is not a state, is not listed in the drop-down list of states.   When traveling, we can be denied boarding flights because some TSA agent decided that a D.C. drivers license isn’t a state-issued ID.

So kudos to the Bureau of Industry and Security (“BIS”) for, at last, recognizing that the District of Columbia exists, as it finally did in the recently proposed amendment to the definitions in the Export Administration Regulations.  Currently, section 734.2(b)(8) of the EAR says this:

Export or reexport of items subject to the EAR does not include shipments among any of the states of the United States, the Commonwealth of Puerto Rico, or the Commonwealth of the Northern Mariana Islands or any territory, dependency, or possession of the United States. These destinations are listed in Schedule C, Classification Codes and Descriptions for U.S. Export Statistics, issued by the Bureau of the Census

Take a look at Schedule C which defines those territories, dependencies and possessions of the United States that are not exports, and you will see Puerto Rico, the Virgin Islands, Guam, American Samoa, Northern Mariana Islands, and the United States Minor Outlying Islands. Conspicuously missing from the list is the District of Columbia.

The proposed amendments add a new section 734.18(a)(3) which says this:

Shipping, moving, or transferring items between or among the United States, the District of Columbia, the Commonwealth of Puerto Rico, or the
Commonwealth of the Northern Mariana Islands or any territory, dependency, or possession of the United States as listed in Schedule C, Classification Codes and Descriptions for U.S. Export Statistics, issued by the Bureau of the Census.

Now that may be good news for us in the District of Columbia, but it’s bad news for anyone who has ever shipped an item on the Commerce Control List, such as a cattle prod, into the District of Columbia in the past five years. Anyone who did that has violated U.S. export laws because the District of Columbia is not a state and it’s not listed in Schedule C. It’s a foreign destination under current rules. You could go to jail. You could be fined $250,000 for each such export by BIS. You could have your export privileges denied. So, folks, get those voluntary disclosures in before you find a team of ICE agents in your offices carting off all your computers and interrogating all your employees.

Permalink Comments (1)

Bookmark and Share



BIS Finally Releases Proposed Cybersecurity Rules

Posted by at 11:55 pm on May 20, 2015
Category: BISCyber Weapons

Photo: Harland Quarrington/MOD [see page for license], via Wikimedia Commons istry_of_Defence_MOD_45153616.jpgAt long last, and well after the E.U. and many other members of the Wassenaar Arrangement, BIS has released proposed (but not final) rules implementing the December 2013 changes adopted by the Arrangement and which imposed export controls on “intrusion detection software” and “IP network communications surveillance” systems and equipment. After the E.U. adopted the 2013 changes in October 2014, we speculated that the delay by BIS beyond its announced September 2014 date for releasing a proposed rule was that it perhaps was struggling with the impact of Wassenaar’s overbroad definition of “intrusion detection software.” But we were wrong.

The proposed rule adopts the Wassenaar changes without clarification of the scope of coverage of intrusion detection software. Instead, the delay seems to have been wholly occasioned by housekeeping matters: specifying the reasons for control, deciding that no license exceptions would apply, and so forth. The proposed BIS rules also grapple with a rather esoteric problem: what to do with intrusion detection software with encryption functionality. And it decides that the software is classified, and must comply with, both ECCNs, which, at last, concedes something BIS long said was impossible: that an item could have two ECCNs. Finally, and I’m not joking, so I’ll quote the agency itself to prove that I’m not

[a] reference to §772.1 is proposed to be added to ECCNs 4A005, 4D001 and 4E001 to point to the location of the ‘‘intrusion software’’ definition, as this rule may be of interest to many new exporters that would not otherwise know that double quoted terms in the EAR are defined in §772.1.

Seriously? Now BIS starts to worry about the indecipherability of the EAR and the secret rules of interpretation that must be applied? What next? Will proposed rules start spelling out “n.e.s.”?

But, all joking aside, the problems with the definition of intrusion software remain

‘‘Software’’ ‘‘specially designed’’ or modified to avoid detection by ‘monitoring tools,’ or to defeat ‘protective countermeasures,’ of a computer or network-capable device, and performing any of the following: (a) The extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or (b) The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

The notes indicate that protective measures include “Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) or sandboxing.”

Many have pointed out this definition would cover programs that permit auto-updating without user intervention, such as, for example, the Chrome browser, which updates itself in the background and circumvents protections normally imposed by the operating system to prevent installation or modification of programs without user intercession. Address Space Layout Randomization (ASLR) loads program components into random addresses in memory as a security measure against buffer overflow attacks and yet legitimate programs that must “hot-patch” operating servers or systems must scan memory to locate the program components, thereby both extracting data and defeating ASLR. The definition of sandboxing as a protective measure will subject programs that permit rooting or jailbreaking of mobile telephones to export controls.

I don’t normally try to look into a crystal ball and make predictions about the future, but I see clearly a flood of classification requests by software developers.

Permalink Comments Off on BIS Finally Releases Proposed Cybersecurity Rules

Bookmark and Share



BIS Publishes Tips You Can Use (or Not) to Unmask Russian Straw Purchasers

Posted by at 9:48 pm on May 19, 2015
Category: BISRussia Sanctions

By Daderot (Own work) [CC0], via Wikimedia Commons Bureau of Industry and Security (“BIS”) just released new guidance, snappily titled “Guidance on Due Diligence to Prevent Unauthorized Transshipment/Reexport of Controlled Items to Russia,” which attempts to reveal ways in which U.S. exporters can detect whether a purchaser is sneakily trying to buy things not for itself but for the bad guys in Russia. This, of course, is a laudable purpose, not just for the Russians, but for the many other countries and entities that know they can’t directly buy certain export-controlled goods and have a straw purchaser do their dirty work. But, sadly, most of the advice for sniffing out secret Russian intermediaries is about as useful as the secret decoder rings that used to be found in cereal boxes.

Here it is:

When inquiring into the ultimate destination of the item, an exporter should consider e-mail address and telephone number country codes and languages used in communications from customers or on a customer’s website. The exporter should also research the intermediate and ultimate consignees and purchaser, as well as their addresses, using business registers, company profiles, websites, and other resources. … Furthermore, exporters should pay attention to the countries a freight forwarder serves, as well as the industry sectors a distributor or other non-end user customer supplies.

Particularly risible is the advice to pay attention to the “email address and … languages used in communications from customers or on a customer’s website.” Because, of course, if you’re trying to hide the fact that your acting on behalf of the Russians you’re going to put up a website in Russian, email from a .ru domain, and say “Nyet” when asked if you’re secretly working for the Russkis.

It’s not quite clear why BIS mentions these factors — which may from time to time catch a really stupid Russian intermediary who slips and starts babbling in Russian — rather than more reliable red flags. The most frequent indicators that you’re dealing with an imposter is a purchaser who appears to have no clear understanding of, or use for, the item he or she is seeking to purchase. Small purchasers that your company has never dealt with or who say that they are simply a reseller should set off alarm bells. And here’s a personal favorite: Google Maps Street View is your friend. If you track down the address in Amsterdam and see that the purchaser of a controlled accelerometer is a bicycle store or a car repair garage, well, your work is done.

Permalink Comments (1)

Bookmark and Share