Its summer in Idaho, and how! (It was over 90 yesterday and people can say “it’s a dry heat” until the cows come home with heatstroke. My oven is dry, but I don’t want to sit in that, either.) The air is scented with sagebrush (the quintessential Idaho smell), the pine needles I am clearing from my side yard, the lavender and basil in my garden, and the occasional ozone from imminent thunderstorms. It’s those snippets of scent that perfume long, languid summer days here. With that, I offer my own “literary potpourri” – thought snippets in security.
Digital Pearl Harbor
In the interests of greater service to my country, I would like to propose a moratorium on the phrase “digital (or “cyber”) Pearl Harbor.” This particular phrase is beyond tiresome cliché, to the point where it simply does not resonate, if it ever did. The people who use it for the most part demonstrate an utter lack of understanding of the lessons of Pearl Harbor. It’s as bad as the abuse of the word “decimate,” the original meaning of which was to kill every 10th person (a form of military discipline used by officers in the Roman Army). Unless you were one of the ten, it hardly constituted “utter annihilation,” the now generally accepted usage of “decimate.” The users and abusers of the phrase “digital Pearl Harbor” typically mean to say that we are facing the cyber equivalent of:
-- A sneak attack
-- That “destroys the fleet” – leaving something critical to our national defense or national well-being in a state of ruin/devastation
-- With attendant loss of life
Not to go on and on about the Pacific War – not that it isn’t one of my favorite topics - but Pearl Harbor turned out to be a blessing in disguise for the United States. Note that I am not saying it was a blessing for the 2403 men and women who died in the attack (not to mention those who were wounded). In support of my point:
1) The Japanese attack on Pearl Harbor brought together the United States as almost nothing else could have. On December 6, 1941, there were a lot of isolationists. On December 8, 1941, nary a one. (For extra credit, Hitler was not obligated to declare war on the United States under the terms of the Tripartite Agreement, yet he did so, which means – as if we needed one – we also had a valid excuse to join the European war.)
2) The Japanese did not help their cause any by – due to a timing snafu – only severing diplomatic relations after the attack had begun, instead of before. Thus, Pearl Harbor wasn’t just a sneak attack, but a sneak attack contrary to diplomatic norms.
3) Japan left critical facilities at Pearl Harbor intact, due to their failure to launch another attack wave. Specifically, Japan did not destroy the POL (petroleum, oil and lubricant) facilities at Pearl Harbor. They also did not destroy the shipyards at Pearl Harbor. Had the POL facilities been destroyed, the Pacific Fleet would have had to function out of San Francisco (or another West Coast port) instead of Hawai’i. As for the dry-dock facilities, most of the ships that were sunk at Pearl Harbor were ultimately raised, refurbished, and rejoined the fleet. (Special kudos to the divers who did that work, who do not generally get the credit they deserve for it.) The majority of ships on Battleship Row were down on December 7 -- but far from out.
4) The attack forced the US to rely on their aircraft carriers. Famously, the US carriers were out to sea during the attack, unfortunately for the Japanese, who truly wanted to sink carriers more than battleships. Consequently, the US was forced (in the early months of the war) to rely on their carriers, and carriers were the future of war-at-sea. (The Japanese ship Yamato, which, with her sister Musashi, were the largest battleships ever built, was a notable non-force during the war.)
5) Japan was never going to prevail against the industrial might of the United States. Famously, ADM Isoroku Yamamoto -- who had initially opposed the attack on Pearl Harbor -- said, "I can run wild for six months … after that, I have no expectation of success.” It was almost exactly six months between December 7, 1941 and the battle of Midway (June 4-6, 1942), which was arguably the turning point of the Pacific War.
December 7, 1941 was and always will be “a date that shall live in infamy,” but Pearl Harbor was not the end of the United States. Far from it.
Thus, the people who refer to “Cyber Pearl Harbor” or “Digital Pearl Harbor”(DPH) are using it in virtually complete ignorance of actual history. Worse, unless they can substantiate some actual “for instances” that would encompass the basic “here’s what we mean by that,” they run the risk of becoming the boy who cried cyber wolf. Specifically, and to return to my earlier points:
-- A sneak attack
With the amount of cyber intrusions, cyber thefts, and so on, would any cyber attack (e.g., on critical infrastructure) really be “a sneak attack” at this point? If we are unprepared, shame on us. But nobody should be surprised. Even my notably technophobic Mom reads the latest and greatest articles on cyber attacks, and let’s face it, there are a lot of them permeating even mainstream media. It’s as if Japan had attacked Seattle, Los Angeles and San Diego and pundits were continuing to muse about whether there would be an attack on Pearl Harbor. Duh, yes!
-- That “destroys the fleet” – leaving something critical to our national defense or national well-being in a state of ruin /devastation
If we know of critical systems that are so fragile or interdependent that we could be ruined if they were “brought down,” for pity’s sake let’s get on with fixing them. For the amount of time pundits spending opining on DPH, they could be working to fix the problem. Hint: unless Congress has been taken over by techno-savvy aliens and each of the members is now supergeek, they cannot solve this problem via legislation. If a critical system is laid low, what are we going to say? “The answer is – more laws!” Yessirree, I had no interest in protecting the power grid before we were attacked, but golly jeepers, now there’s a law, I suddenly realize my responsibilities. (Didn’t we defeat imperial Japan with – legislation? Yep, we threw laws at the Japanese defenders of Tarawa, Guadalcanal, and Peleliu. Let’s give Marines copies of the Congressional Record instead of M4s.)
-- With attendant loss of life
It’s not inconceivable that there are systems whose failures could cost lives. So let’s start talking about that (we do not, BTW, have to talk about that in gory detail wherein Joe-Bob Agent-of-a- Hostile-Nation-State now has a blueprint for evil). If it -- loss of life -- cannot be substantiated, then it’s another nail in the coffin of using DPH as an industry scare tactic.
To summarize, I have plenty of concerns about the degree to which people rely on systems that were not designed for their threat environments, and/or that embed a systemic risk (the nature of which is that it is not mitigateable – that’s why it is “systemic” risk). I also like a catchy sound bite as much as the next person (I believe I was the first person to talk about a Cyber Monroe Doctrine). But I am sick to death of “DPH” and all its catchy variants. To those who use it: stop waving your hands, and Put Up or Shut Up – read about Pearl Harbor and either map the digital version to actual events or find another CCT (Cyber Catchy Term) . Cyberpocalypse, Cybergeddon, CyberRapture – there are so many potential terms of gigabit gloom and digi-doom – I am sure we as an industry can do better.
Hand waving only moves hot air around – it’s doesn’t cool anything off.
I recently encountered a “customer expectations management” issue -- which we dealt with pretty quickly -- that reminds me of a Monty Python sketch. It illustrates the difference between “real security” and “security theater” -- those feel-good, compliance-oriented, “everybody else does this so it must be OK” exercises that typically end in “but we can’t have a security problem -- we checked all the required boxes!”
Here goes. I was told by a particular unnamed development group that customers requesting a penetration test virtually demanded a penetration test report that showed there were vulnerabilities, otherwise they didn’t believe it was a “real” report. (Sound of head banging on wall.) I’d laugh if the stakes weren’t so high and the discussion weren’t so absurd.
If the requirement for “security” is “you have to produce a penetration test that shows there are vulnerabilities,” that is an easy problem to solve. I am sure someone can create a software program that randomly selects from, say, the oodles of potential problems outlined in the Common Weakness Enumeration (CWE), and produces a report showing one or more Vulnerabilities Du Jour. Of course, it probably needs to be parameterized (e.g., you have to show at least one vulnerability per X thousand lines of code, you specify primary coding language so you can tailor the fake vulnerabilities reported to the actual programming language, etc.). Rather than waste money using a really good tool (or hiring a really good third party), we can all just run the report generator. Let’s call it BogusBreakIt. “With BogusBreakIt, you can quickly and easily show you have state-of- the-art, non-existent security problems – without the expense of an actual penetration test! Why fix actual problems when customers only want to know you still have them? Now, with new and improved fonts!”
With apologies to the Knights Who Say, “Ni,” all we are missing is a shrubbery (not too expensive). The way this exercise should work is that instead of hiring Cheap and Bad Pen Testers R Us to make your customers feel good about imperfect security (why hire a good one to find everything if the bar is so low?), you do the best you can do, yourselves, then, where apropos, hire a really good pen tester, triage the results, and put an action plan together to address the crappiest problems first. If you provide anything to customers, it should not be gory details of problems you have not fixed yet, it should be a high level synopsis with an accompanying remediation plan. Any customer who really cares doesn’t want “a report that shows security problems,” but a report that shows the vendor is focused on improving security in priority order – and, of course, actually does so.
Moral: It’s hard enough working in security without wasting scarce time, money, and people on delivering shrubberies instead of security.
I don’t think anybody can doubt my commitment to assurance – it’s been my focus at Oracle for most of the time I’ve worked in security, going on 20 years (I should note that I joined the company when I was 8). It is with mixed feelings that I say that while I was an early (grandfathered) recipient of the Certified Secure Software Lifecycle Professional (CSSLP) certification, I have just let it lapse. I’m not trying to bash the Information Systems Security Certification Consortium (ISC(2)), the developer and “blessing certifier” of the CSSLP, and certainly not trying to denigrate the value of assurance, but the entire exercise of developing this certification never sat well with me. Part of it is that I think it solves the wrong problem – more on which later. Also, my cynical and probably unfair comment when I heard that ISC(2) was developing the CSSLP certification was that, having saturated the market for Certified Information Systems Security Professionals (CISSPs), they needed a new source of revenue. (You do wonder when you look at the number of business cards with a multiplicity of alphabet soup on them: CISM, CISSP, CSSLP, EIEIO (Ok, I made that last one up).)
I let my CSSLP lapse because of a) laziness and b) the fact that I got nothing from it. Having a CSSLP made no difference to my work or my “professional standing.” It added no value to me personally, or, more importantly, to assurance at Oracle. I started working in assurance before the CSSLP dreamer-uppers ever thought of Yet Another Certification, and my team (and many others in Oracle) have proceeded to continue to try to improve our practices. ISC(2) had no impact on that. None. I wondered why I was paying X dollars to an organization for them to “bless” work that we were doing anyway, that I was doing, anyway, that did not add one iota to our knowledge or practices? (To be fair, some of the people who work for me have CSSLPs and have kept them current. I can’t speak for what they think they get out of having a CSSLP.)
We have an EIEIO syndrome in security – so many certifications, and really, is security any better? I don’t know. I don’t know how much difference many of these certifications make, except that job search engines apparently look for them as keywords. Many certifications across various industries are used as barriers to market entry, to the point that some forward- thinking states are repealing these requirements as being anti-competitive. (And really, do we need a certification for interior decorators? Is it that critical that someone know the difference between Rococo and Neoclassical styles? C’mon!) In some areas, certifications probably do make sense. Some of them might be security areas. But it doesn’t do any good if the market is so fragmented and we are adding more certifications just to add them. And it really doesn’t do any good if we have too many of them to the point where the next one is JASC – just another security certification. CSSLP felt like that to me.
I certainly think assurance is important. I just do not know – and remain really, really unconvinced -- that having an assurance “certification” for individuals has done anything to improve the problem space. As I’ve opined before, I think it would be far, far, better to “bake in” security to the computer science and related degree programs than try to “bolt on” assurance through an ex post facto certification. It’s like an example I have used before: the little Dutch boy, who, in the story, put his fingers in leaks in a dike to prevent a flood. We keep thinking if only we had more little Dutch boys, we can prevent a flood. If we don’t fix the “builders” problem, we – and all the Dutch boys we are using to stem the flood – will surely drown.
I am not perfect. As good as my team is -- and they and many others in Oracle are the real builders of our assurance program -- they are not perfect. But I stand on our record, and none of that record was, in my opinion, affected one iota by the presence or absence of CSSLPs among our practitioners.
If I may be indulged:
Old MacDonald had some code
And in that code he had some flaws
With a SQL injection here and an XSS there
Run a scan, fuzz your code
Everywhere a threat model
Old MacDonald fixed his code
I mentioned in an earlier blog, in a truly breathtaking example of self-promotion, that my sister Diane and I (writing as Maddi Davidson) had written and published the first in an IT Industry-based murder mystery series, Outsourcing Murder. The two exciting bits of news about that are, first of all book 2, Denial of Service, is almost (OK, 90%) done. Stay tuned. The second bit is that Outsourcing Murder made a summer reading list for geeks. It’s probably the only time in my life I (or rather, my sister and I) will appear in a list with Kevin Mitnick and Neal Stephenson.
*Ira Gershwin would turn over in his grave – I know I’ll never make it as a lyricist.
This article was syndicated via RSS from: https://blogs.oracle.com/maryanndavidson/entry/summer_potpourri