By user701213 on Feb 07, 2009
As I write this, I am nursing a couple of bruises I incurred skijouring with my dog Thunder. Skijouring is Nordic skiing with your dog hooked up to a lead, so he pulls you. I believe the word “skijour” comes from the Norwegian word for “cheating,” judging by the dirty looks I get from other Nordic skiers when Thunder zooms past them towing me. Mind you, Thunder has two speeds: flat out and conked out. Periodically, he stops in the middle of a run to jump into a snow bank, do a “doggy snow angel” and cool off, or check out some other dog’s calling card. You get used to using the fast-braking snowplow since I know from experience it is no fun to reach the end of the tether at high speed: it leads to a Nordic skiing move known as a “face plant.”
I Nordic ski a lot, hooked up to Thunder most of the time though I typically do a few kilometers by myself because otherwise he is the only one getting aerobic exercise. The biggest hazard for me in Nordic skiing (which does not normally carry the risks alpine skiing does) is from what I call LLDS – loose, loutish dog syndrome. That is, many people around here ski with their dogs, hardly any of them are on leads, and of those, at least some percentage are big, loutish, untrammeled dogs who run up to Thunder at full tilt, causing him to either “defend” me or otherwise establish his alpha dog-dom. I have to explain to their owners that no, Thunder does not want to play: he is a working dog, pulling a sled or a skier is his “job” and he is single-minded about it. Sometimes but not often, his lunge after another dog bounding up at him pulls me over (hence, the previously alluded-to bruises). Last year, I had a $50 vet bill courtesy of a border collie who bit Thunder to herd him when he did most definitely did not want to be herded. The owner, needless to say, did not call his dog despite my repeated requests that he do so. Jerk.
I should add that most people on the Nordic trails around Sun Valley (especially when asked) call their dogs instead of letting them launch themselves at other dogs, most of the dogs are reasonably well behaved but about 20% are not and they are inevitably golden retrievers or labs. With apologies to my friends who have those breeds,* I cringe when I see labs or retrievers on the Nordic trails, because I know those dogs are going to be the ones bounding up and creating a problem. Part of this I attribute to rampant cute puppyitis (many people fall in love with an adorable puppy – and both labs and retrievers are very cute puppies – without bothering to find out anything about the breed temperament) and part to the fact that in any group, there are going to be irresponsible pet owners.
My dog, I admit, is hardly perfect, but the rules of the Blaine County Recreation District are that if dogs are off lead, they must be within 15 feet and under voice command, both of which are regularly flouted by the aforementioned irresponsible dog owners. I’ve seen dogs wandering not anywhere near visual or audible distance of their owners (labs and retrievers, almost always). Realistically, of course, it is the owner who is at fault and not the dog. I guess a side affect of cute puppyitis is thinking your dog is so adorable, every one else (and every other dog) will find him just as appealing and you don’t have to bother training him.
I’ve been reminded recently of the difference between (if I may be forgiven) bad dogs and bad owners with the release of the SANS Top 25 Most Dangerous Programming Errors list. The list describes the Top 25 programming errors that contribute to security vulnerabilities. Many people contributed to it so it represents a broad consensus that is, overall, a strength. I should also note that one of my team reviewed and contributed to the list. I further add (hastily) that on the face of it, I don’t have a problem with the list: a list is a list (like a dog, it’s not necessarily a bad dog or a good dog, it’s just a dog). To the extent that a Top 25 Most Dangerous Programming Errors list helps create a starting point for Avoiding Bad Coding, it can be very useful. I also thank various folks who spearheaded the creation of the list (Bob Martin at Mitre was the hard-working project manager) and who scrupulously attempted to get an industry consensus via multiple review cycles and multiple contributors. As I have opined previously, there are a lot of universities that don’t teach secure coding or emphasize it and a lot of developers who are looking for guidance as to where to start paying attention to What Not To Do. To that extent, the SANS list is very useful.
My issue is with the potential mischief this list can and I fear will be put to, which, like my Nordic skiing example is not the fault of the dog (the list), it’s a fault of the “owners,” in this case people who “buy” the cute little list and are enamored of it and think it can do no wrong. I meet dog owners who decide their dog who runs up at Thunder full throttle is just the cutest thing and they do not understand why Thunder does not want to play. Then, it is my fault if there is a problem (uh, my dog is on a lead, yours is not, nor does yours obey voice command, therefore, your dog is by definition out of control and it is your responsibility to control the animal). I love Nordic skiing but the LLDS problem makes me absolutely crazy and ruins my skiing experience. Similarly, I am seeing what started as a good idea – a “don’t do this” list – morph into a big, loutish dog.
For example, I have heard people exclaim that it would be a great thing to demand of commercial software vendors that the solution to all security ills is that vendors be made to attest (as part of a contract) that their code contains no programming errors in the SANS Top 25 Most Dangerous Programming Errors list. Now, even if this could be foisted on the vendor community, just like a large untrammeled Labrador, I believe, the results would be unpredictable and not universally welcome. One wants to know, is the goal to have better software, or to have someone to sue? Because making forced contractual attestations as to the degree to which one’s software is free of a class of defects has some unintended consequences.
I have opined previously on the fact that automated tools help find Dumb Things In Code that could include some or all of the SANS Top 25. But everyone who has used them knows that the available tools on the market do not find all vulnerabilities or even all types of vulnerabilities. And if your code is quadruple digits in length or more – and most commercial software is multiple million lines of code – manual code review is a) time consuming, b) unlikely to succeed, c) subject to the vagaries of the reviewer and therefore not repeatable or consistent, and d) out of date as soon as the code changes, which is daily in many development organizations. More to the point, what happens when a vendor that has done the best it can to find and eradicate the SANS Top 25 (or whatever the List Du Jour is, more on which later) finds a vulnerability on the verboten list after using the best available tools? That is, where the product is already shipping? Suppose that the vulnerability a vendor finds is a really bad one (let’s say, CVSS 10), and so easy to exploit your grandmother can do it. Does the vendor a) sit on the vulnerability and hope nobody else finds it, or b) fix the problem and find themselves in breach of contract? That, dear reader, is what is known as a Catch-22 (or, in the best classic tradition, being caught between Scylla and Charybdis). Back to my original question, are the people rubbing their hands in glee at the prospect of forcing contract provisions that are list-based down vendors’ throats actually interested in better software, or having someone to blame?
I believe there is another problem with enshrining anything like a SANS Top 25 list into a contractual or regulatory straightjacket. First of all, the SANS Top 25 list is a general list with both the utility and limitations of that. If one’s code is (based on one’s development practice, development framework and deployment scenario of the software) more at risk from another kind of vulnerability that did not make the Top 25 (or, if new threats are discovered, and they are all the time), what should a vendor focus on? The theoretical Top 25 or the issues based on one’s own experience? The very nature of a Top 25 list is that it is likely to be overtaken by events (actually, in the general sense, it would be a very nice problem to have, because it might mean everyone had eradicated the Top 25 issues or at least made a really good dent in them, which we all want). However, that does not mean contractual language would change fast enough to maintain relevancy. It never does.
By way of example, when I was in the Navy, it was (at that time) part of the uniform regulations that females wearing dress uniforms (service dress blue or service dress white) were required to wear or carry white gloves and a purse. (If you carried white gloves instead of wearing them, they had to be folded lengthwise with “fingers out” – in front of your hand. If you care.) In short, white gloves and a purse were “part of the uniform” and if you did not wear or carry gloves and carry a purse that meant you were technically, “out of uniform,” one of the seven deadly sins in the Navy. Did I mention that part of your annual fitness report (think “employee performance review”) is “military bearing” and you get graded on things like how well you wear the uniform and observe military etiquette? Now, as a member of the Civil Engineer Corps, my job as a contracting officer entailed going on construction sites. The safety “rules” of most construction sites are that you need to wear a hardhat and steel-toes shoes. So, in order to comply with construction site safety regulations and Navy uniform regulations, I faced carrying white gloves onto a construction site (where, needless to say, they would not stay white very long). Not to mention, I was supposed to be carrying a purse and wearing a hardhat (instead of my uniform hat). I gave up on the steel-toed shoes since there are no steel-toed women’s pumps that I know of.
The bottom line is that those uniform regulations were set in the day when every woman wore a hat and gloves (my mom still does, to church every Sunday) and did not contemplate that women might expand to jobs that involved going onto construction sites. The regs did not keep up with the times. As a result, there is no way I could be both “in uniform” and “in compliance” on a construction site. Catch-22 – pick which regulation you are going to break, because I could not comply with all of them.
You might note that in the above case of “unattainable” or mutually conflicting regulations I should have just used common sense, and I did. But I was still technically “out of uniform.” And hence, my question, are the people advocating that the otherwise useful list become a contractual commitment (thus overusing if not abusing the utility of it) interested in better software or in building in an inability of vendors to meet all contractual provisions (the software assurance equivalent of demanding steel-toed high heeled pumps)? And if their intentions are to make software better, can they reconcile the likely outcome that vendors will consider their almost certain liability when deciding whether to release a fix and consult their lawyers on how to characterize an issue differently, rather than just getting on with the fix? Making things better should not entail requiring a level of perfection nobody could possibly meet, let alone enshrining it into a contract. Unless of course, one’s real goal is to make money out of others’ imperfections. (I should pause here and reiterate that the list is a good idea, I know the people who spearheaded it had good motives and I thank them for their efforts.)
One of the great privileges of my job has been the opportunity to advise policymakers on the challenges of cybersecurity or to comment on bills and other regulatory language. I note that while “lobbyist” is sometimes a term of opprobrium:
· Policymakers, and the staff who capably assist them, typically want to legislate well
· Nobody can be an expert on every issue and thus policymakers and their staffers rely in part on outside stakeholders advising them of the specifics of an issue
· Such advice, if one is asked to or can offer it, is part of one’s civic responsibility (to help policymakers govern wisely)
· Lobbyists use these opportunities to talk about the scope and context of an issue, what their advice is and why, and what other positions are and why
· Bad lobbyists merely try to frame their side of the issue in a narrow context, and create law or regulation that will disproportionately benefit them personally - or their taskmasters - and to hell with everyone else and the public good
What I see shaping up in cybersecurity are a lot of people with agendas that involve personal enrichment as much as – no, I believe, in many cases more than - actually making things better. Security vendors, for example, whose core markets are drying up and who want to get into the testing business and therefore are lobbying to whomever will listen that outside testing is the answer to all security ills. Dare I say it, “Quis custodiet ipsos custodes?” (Who will watch the watchers?). People who want to come in and “audit” development processes – by regulation (again, who vets the auditors?). Vendors with encryption solutions who try to push data encryption as the legislative security for all ills. (Encryption does not solve access control problems and anyway, an alternative solution might be not allowing data to migrate to places it should not exist. Or automatically deleting it from places it should not be.) More to the point, I fear requiring specific technical remedies for a perceived risk runs the risk that the technical standards will rapidly be overtaken by newer technology, and we will be enshrining buggy whip standards in an automobile age. Or wearing white gloves to construction sites.
Now that the problem is clear, instead of recommending a particular “make it better” program like enshrining the SANS Top 25 list into contracts, here is what I would do:
I would like actual governance structures around Intended Do Good Security programs to ensure they are administered well, fairly, do not advantage a single vendor, promote actual and cost effective security improvement and do not demand the impossible overnight. In short, they give vendors both encouragement – pushy encouragement is fine – to improve and credit for doing it. And do actual security good, of course. I would include a recommended list of “good ideas that could make things better” as well as “bad ideas that legislators should stay away from.” (The way the SANS Top 25 list was developed showed good governance in that it was inclusive and transparently arrived at.)
Similarly, I would like vendors to implement some governance structures around their development processes. Nobody can do everything in security but we can all improve, and being able to a) target areas for improvement, b) create reasonable standards of practice in secure development within our own enterprises, and c) develop structures that help measure our internal consistency in depth and breadth of secure development practice is part of growing up. It’s treating security like a business value (diversity, cost containment, ethics, anything else you can and do run as a consistent corporate program). We all need to do that. (Oracle does have governance structures around our secure development programs, which will be the subject of future blogs.) None of us will develop products exactly the same way, with exactly the same APIs or exactly the same development frameworks, exactly the same tools and not every “good security idea” will be equally cost effective or useful for all of us. But we can, and should, figure out a) what we should be doing as individual vendors that is generally considered good practice, and b) make sure we do that.
For my part, and back to my Nordic skiing example, I cannot control what others do with their dogs, but for my part, I have tried to improve what I do with my dog. I started using my “happy voice” with Thunder when another dog comes up, to remind him that he likes labs, border collies, retrievers and so on. I am less tense and defensive so he does not feel he needs to protect me. I can be a better dog owner, and I try to be. Specifically, I figure if I am more open and accepting of loose, loutish dogs, it helps avoid problems and vet bills. I also thank the many responsible dog owners I meet for how smart, well behaved, and handsome their dogs are, and for calling their dogs instead of letting them bound up. Just like working on cybersecurity issues, my Nordic skiing goal is “happy – and safe – trails for all.”
* One of my dear friends just lost her beloved lab Zach. Zach was a lovely, sweet dog and will forever be enshrined in my personal pantheon of utterly lovable labs.
Book of the Week
War Made New, Technology, Warfare and the Course of History: 1500 to Today by Max Boot
A really fascinating look at how technology has contributed to military success. Max Boot analyzes warfare in terms of “ages” – gunpowder, first and second industrial age, and the information age (e.g., as applied in Iraq and Afghanistan). He also looks at potential future combat. The interesting questions in military history are not “who won?” but “why?” and “how?” It’s also fascinating to see how warfare is being transformed through information technology.
Max Boot also wrote The Savage Wars of Peace: Small Wars and the Rise of American Power, which I have not read, but just bought.
More on Scylla and Charybdis:
More on “who watches the watchers?”
The SANS Top 25 Most Dangerous Programming Errors list (again, my appreciation to both those who spearheaded it - thank you, Bob Martin - and to those who contributed):
More on the BCRD Nordic trails:
Pau hana happiness. If you’ve had a hard week, you can cheer yourself up by checking out Mānoa DNA below doing Ka’a Ahi Kahului. (You can also learn how to say ‘railroad’ in Hawaiian.) I love these guys!
You can find a the CD of the above song at: