Hillary, Email and the Problems With Policy


March 11, 2015

By Mark Rasch

Some years ago, I was sitting in a whirlpool at a health club and I noticed a printed sign above the whirlpool that noted, “Do Not Clip Toenails in the Whirlpool.” Gross.  My first reaction was, “why exactly was that sign necessary?”  My second reaction was, “hmm.. so if that is prohibited, by implication, what is permitted?”

And that points out one of the problems with policies.  You can never anticipate all the ways people will screw up.  Any time you make something “idiot proof” you wind up with more clever idiots. 

And when you write a policy, there is a tendency among those covered to conclude that all that is not prohibited is permitted.  And that’s bad.

In the case of Hillary Clinton, there has been much discussion about whether or not the use of a personal email account, or the use of a homebrew domain violated the law, or violated State Department policy. 

The Wall Street Journal noted  “Hillary Clinton ’s use of a private email account for official government business when she was Secretary of State appears to run contrary to established internal State Department policies and procedures, according to agency documents.” Slam.  And Dunk.  She is toast.

So I went looking for these “established internal State Department policies..”  Not so clear. 

Now I am not discussing whether the use of a personal server is a good idea or a bad one.  Whether it is secure or not.  Rather, I am looking at this from the perspective as a lawyer. 

Let’s say a State Department employee was fired for violating the policy by using personal e-mail and they retained me to look into it.  That’s the standard I am using.  Whether that’s the right standard for the Secretary of State setting policy or for a Presidential candidate is a different issue.  But let’s say she’s my client.

The only internal policy I could find that addresses (kinda) this issue is in the Foreign Affairs Manual (FAM).  That document  says:

12 FAM 544.3 Electronic Transmission Via the Internet (CT:DS-117; 11-04-2005) a. It is the Department’s general policy that normal day-to-day operations be conducted on an authorized AIS, which has the proper level of security control to provide nonrepudiation, authentication and encryption, to ensure confidentiality, integrity, and availability of the resident information. The Department’s authorized telework solution(s) are designed in a manner that meet these requirements and are not considered end points outside of the Department’s management control.

b. The Department is expected to provide, and employees are expected to use, approved secure methods to transmit SBU information when available and practical.

c. Employees should be aware that transmissions from the Department’s OpenNet to and from non-U.S. Government Internet addresses, and other .gov or .mil addresses, unless specifically directed through an approved secure means, traverse the Internet unencrypted. Therefore, employees must be cognizant of the sensitivity of the information and mandated security controls, and evaluate the possible security risks and then decide whether a more secure means of transmission is warranted (i.e., secure fax, mail or network, etc.)

d. In the absence of a Department-provided secure method, employees with a valid business need may transmit SBU information over the Internet unencrypted after carefully considering that: (1) SBU information within the category in 12 FAM 541b(7)(a) and (b) must never be sent unencrypted via the Internet; (2) Unencrypted information transmitted via the Internet is susceptible to access by unauthorized personnel; (3) Email transmissions via the Internet generally consist of multipoint communications that are routed to their destination through the path of least resistance, which may include multiple foreign and U.S. controlled Internet service providers (ISP); (4) Once resident on an ISP server, the SBU information remains until it is overwritten; (5) Unencrypted email transmissions are subject to a risk of compromise of information confidentiality or integrity;

Well, that’s as clear as mud.  It’s actually not a bad policy.  It sets out its purpose “have security to provide nonrepudiation, authenticity, etc.…” It sets out a general rule (use our systems, or ones we have approved), and it provides flexibility (it’s a “general policy”) meaning that other solutions, which meet the objectives, may (or may not) comply with the policy. 

A memo sent from some State Department Official named Hillary Clinton  in June 0f 2011 seems to do no more than reiterate the policy noting that State Department officials should “Avoid conducting official Department business from your personal email accounts.” 

But it illustrates the problem with writing policy.  The Supreme Court continues to struggle with the meaning of words (are fish “tangible objects,” is Amtrak a government agency, are federal exchanges “established by the States?”) we see that it is very difficult to write a good policy.  Especially where the technology is changing, and there is little consensus on what is appropriate, much less what is verboten.

All too often entities simply purchase “pre-canned” policies.  Some good.  Some bad.  But rarely aimed at the precise problems the entity is having, and is likely to have.  That’s why it’s important to get it right in the first place.  Or even the second or third.

Looking at the FAM policy, was it a violation to have only a personal email account on a home-brew system?  Not really.  It may (or may not) violate the spirit of the policy (depends on whether it meets the objectives) but not all things that are “bad ideas” violate policy.  Think clipping fingernails in the hot tub.  The sign said “toenails.”

Policy is hard to get right.  It pays to spend a few bucks on getting it right.  And getting a bunch of eyes looking at it.  And admitting when you have it wrong.  And keep it simple.  A policy that can’t be read and understood isn’t a policy – its liability in waiting. 

comments powered by Disqus

About Security Current | Privacy Policy | Subscribe to our newsletter