Currently I worked at a Managed Services Provider where I create a variety of Managed Security Services and again – my role is very broad. I could be performing CSO functions one day, performing incident response and forensics the next followed by penetration testing, risk assessments, information security management, VoIP engineering, administration and design to name a few. My days are never dull, they’re never the same and I enjoy being able to dabble in enough different technology arenas including Digital Signage, Video Conferencing and the list goes on. With a brief bio out of the way, I’d also like to state that I have quite a few high level technical certifications (C|EH, CHFI, CPT, OSCP, etc., etc.), have been referenced in a few security related books and have been fortunate enough to collaborate with and have discussions with the heaviest hitters in the security industry.

When I first heard about Stuxnet, it made me shrug my shoulders just as much as I shrugged when hearing about Aurora – the “(un)Advanced Persistent Threat.” Outside from all the hype, the entire concept of “Stuxnet” being a “highly weaponized targeted” threat is way out of tune with reality. From everything I have read so far, everyone seems to be repeating what everyone else is repeating! Who’s on first, what’s on second? In my honest “expert” opinion, there are a lot of confused, underclued and biased individuals looking at this from a biased and distorted perspective. One filled with fantasy, hype, illogical and bizarre points of view. Some should even write creative fiction books on Stuxnet for crying out loud.

Let’s start at the top of the food chain with what everyone is rambling about: “An unknown rogue party or individual created a high level sophisticated attacked aimed at Iran’s Nuclear facilities.” “The party created a zero day USB key that infected these facilities and is now entrenched in Iran’s nuclear SCADA systems.” Sounds so “Bourne Identity’ish” if you ask me, maybe we could get Hollywood in on the action right after Symantec, McAfee and others. Here is how, without getting into gory technical details, this plan fails with a capital ph (phails as in phreaker as in trying to remain hip.)


Sponsor – sitting in a room with a swaying light bulb over a desk. He smokes a cigarettes taking slow ‘drags’ of his cigarette. The orange light flaring from his cigarette. “We need to decapitate their nuclear facilities.” As the rogue hacker sits listening he immediately blurts out “I have a plan!” “We will build USB switchblades [1], deploy them to Iran. They in turn will pick them up in awe, wonder what is on them and plug them into these machines in the nuclear facility and it is game over.” “Cut” yells the Hollywood director. Shocking!, Thrilling!, Amazing!, Academy Award Winning!

Even a Hollywood director would know the implausibility of such an insane “cock-a-manie” story. A good Hollywood director would throw out the script or consult with real-world hackers to see how they can make it seem more realistic. For starters we have a sponsor who is dishing out money searching for a foot in the door. Depending on which security ‘expert’ is trying to ramp up their name at the moment there are a lot of plain old dumb comments: “We’re talking man-months, if not years, of coding to make it work the way it did.”

So far we have the following:

Let’s stop here for a moment and analyze two points of view, the first of the sponsor and the second of an attacker. As a sponsor, someone whose invested money, someone who may have to answer a lot of questions if discovered, I have to assume that my hired-gun hacker pulls this off without leaving a trace. Not only do I have to worry that he can pull this off, I have to assume that his method of choice for delivery will work – a USB key. Thinking of a nuclear facility, I’d have to assume that my hired-gun even after he creates his switchblade, is capable of getting it deliver overseas, to a nuclear facility site, undetected, have someone discover the USB key and plug it into a system which may not even be on a network. This is an unacceptable risk and outright waste of money, but I’ll work with it.

From the hired-gun hacker’s perspective, I need to use multiple “zero days” to compromise my target. Because a switchblade isn’t enough, I have to load it up with these zero day attacks so that in the event that one potentially fails, a failover attack finishes up the job. For this I will use the most common and reliable exploits I can think of. I need to be discreet. Again, depending on which expert is in fashion – the explanation given by most at this point makes little sense and if analyzed piece-meal crumble: “”Stuxnet is unusually large at half a megabyte in size, and written in different programming languages (including C and C++) which is also irregular for malware.”" [3]

What have we heard so far from the experts? A (possible) sponsor, a hacker, delivery via the USB attacker vector. So we are told to believe that someone traveled to Iran, a USB switchblade was deployed, an Iranian picked up this USB key, plugged it into some computer and triggered an event. Yet this hacker created a bloated worm based on a variety of code which is “unusual.” Does anyone see thus far why the whole story is rooted with problems so far?

There is a lot of speculation and opinions as to how Stuxnet managed to get onto nuclear machines so here is a more plausible one. An attacker manages to compromise a machine and while on the machine they stumble upon an application they’ve never seen before. Doing reconnaissance of the application they discover it is related to SCADA controls. They begin working on a method to determine what it does, how it does it, how it operates from the ground up. Attacker cobbles together botnet and malware code. Because the codes is based on P2P structure, the hacker can modify his/her payloads to change parameters of how the malware operates. At the beginning, the initial application was unusually small and while additional capabilities were added, the program grew in size. Investigators ONLY discovered it during this large size (bloated) phase. Investigators and analysts are now confused. Hollywood tall-tale stories ensue.

Shifting away from Stuxnet for a moment, let’s talk about botnets. Why and how many remain so threatening and difficult to detect. Beginning with the sizing, botnet programmers and attackers have the attack vectors down to a science. Many will deliver small payloads which then go out and make modifications as needed. They will often use chained exploits to get their foot in the door and keep their hooks in place. It makes more practical sense as an attacker to have as small as payload as possible and this is because as an attacker, one wants to make as fast an impact in a short amount of time as possible. It is easier and more reliable to send small snippets of code to get the initial attack vector off the ground and avoid potential detection. ESPECIALLY with a high value target. From there on, once the initial compromise is off the ground, sky is the limit. The risk is much smaller and rewards much greater.

Forget about common sense, logical reasoning and common (hacker) sense though, let’s go back to “The Fabulous Mr. Stuxnet” and the hype. We already stated we have a potential sponsor, a hacker, an application, a target. How does common sense factor into “littering the area around this nuclear facility with USB keys” make sense. There is a lot of assumption. One “assumes” there are USB ports on the machines in this facility and also assumes they can autorun software off of a USB, but let’s play along and assume there are ports and we can autorun software and magically – we will strike gold and an admin will walk up to a nuclear facing SCADA machine and run this USB key. One then assumes that the there are certain services running and NOT running on these machines. E.g., egress filtering firewall, UPnP, etc. in fact one assumes the target is networked in a method capable of connecting from the outside world back into the nuclear facility. Still see the gaping holes with this theory? Let’s still follow through with the story.

I as a hacker need to create malware that compromises a specific machine. To do so I choose a four 0-day payloads and a worm based mechanism to spread everywhere in order to get to a specific machine. I need to ensure the following occurs:

1) I deliver this USB key to a nuclear facility in or around Iran. For this to work, I can forge the “Siemens” logo and either make a legit looking CDROM or a get a “hi-rez” rubdown transfer and affix it to the USB key to make it look legit.

2) I need someone to insert that USB at any machine in the facility so that my worm can spread to a “specific” machine of which I created a “specific” payload to affect a “specific” piece of software in that facility.

3) I need to do this covertly and I need to do it so that I can come and go undetected. This means I have to assume that the target has some form of network based connectivity. I have to assume that there is no form of network and or security monitoring or filtering. After all, if they have a firewall on that device blocking all egress traffic, all my work would be in vain.

Still don’t see problems with this theory? What about the glaring fact that one of the exploits used in Stuxnet bluescreens Windows machines [4]. Do you think that would be a sensible exploit to use. That in itself would be a gaping no-no from an attacker perspective. My take on it is one of two more plausible scenarios. 1) The insider. Someone with specific knowledge of the facility, knowledge of the software used in the facility, with direct physical access deployed it. This theory gets shot down because if the machine was networked, it would have made more sense to just download it as opposed to inserting a USB key. 2) The uberhackermonster. The uberhackermonster stumbled upon this system/network, discovered unusual software, found a method to try and backdoor the machine to always retain access. This theory is more plausible and conforming for a few reasons. a) I quote: “Stuxnet is unusually large at half a megabyte in size, and written in different programming languages (including C and C++) which is also irregular for malware” This to me means someone didn’t have as much of a focus as one thought. They chopped together this malware on other code available. The bulky size of it shows the immaturity and unprofessionalism of the hacker. Botnet operators, creators, programmers, etc., use small bits of code to deliver staged exploits. Why put all your eggs in one basket?

Anyhow, this has been a long rambling as is so I will leave it at that. There is far too much Hollywood’ism going on right now and I don’t have the budget to compete with AV vendors, nor the expertise to compete with “SCADA Experts” who know these systems inside and out. I’m solely an experienced penetration tester slash security engineer slash hacker slash insert_other_titles_here who would have done things different. I’m someone who tries to think outside of the box offering a realistic and logical view of why this entire Stuxnet “diatribe” being written about by countless experts (including me!)

JO

[1] http://www.hak5.org/w/index.php/USB_Switchblade
[2] http://www.wired.com/threatlevel/2010/09/stuxnet/
[3] http://en.wikipedia.org/wiki/Stuxnet
[4] http://www.google.com/search?hl=en&client=firefox-a&hs=RKz&rls=org.mozilla%3Aen-US%3Aofficial&q=ms08-067+%2Bbluescreen&aq=f&aqi=&aql=&oq=&gs_rfai=

Of major concern to me was the information security assessment portion of the questionnaire. We had never truly implemented an in-house penetration test and rather than re-invent wheels, hire expensive contractors and so on, we developed our own “Red Team” to perform a quarterly penetration test and vulnerability assessment.

Before I go further on how this was accomplished, I’d like to explain the differences between a vulnerability assessment and a penetration test from a non-technical perspective. I choose to explain this not to those who are aware, but many are still confused over the two and the values of one over the other.

From a non-technical perspective in an analogy, a vulnerability assessment is the equivalent of hiring someone to take a look at your house from a security standpoint. The assessor will likely tell you something such as: “Well the inside of your house is visible from this side of the street by looking in this window”, “The front door was open, someone can walk in”, “Your roof is flat and it’s likely got a skylight someone can climb through.” Certainly it has its value.

A penetration test differs in the sense that someone is validating what they see. The results will be something akin to: “The front door was open however, I tried to walk in the door and I was met by a snarling Mastiff. No one is walking through that door!”, “I noticed the house was visible by looking through the window however, when I went to see what was accessible, I noticed it was nothing more than a picture and I really wasn’t seeing what’s inside…”, “I tried climbing through the roof but the moment I got there, I noticed you actually have a guardpost there!”, “I noticed the front door, walked in and was able to do whatever I wanted. To prove this to you, I left you a note in your dresser.”

With this said, which do you think provides more value at the end of the business day, the vulnerability assessment or the penetration test? With the analogy out of the way, I will explain what was done and why it was done, in the process of creating my in-house “Red Team.”

There are two attack vectors I needed to focus on when I set out to create my “perfect storm.” I needed to get a realistic point of view from that of an outside attacker. “What could a hacker see if he was focused on getting into my business?” and “What could an insider do to abuse his or her privilege?” Now, when I state “what can an insider do“, I’m not solely focused on one of my colleagues, I’m also worried about what would happen in the event someone launched a client-side attack.

For those unaware of what a client-side attack is, here is a brief explanation. All computers run software and some of this software is insecure. Imagine visiting a website where the website triggers your software to do whatever an attacker would like to do. Because the software is “local” to you (it’s on your machine or a machine on your network), an attacker is now the equivalent of an insider. Much similar to your co-worker. The attacker will have the same visibility as whomever is sitting next to you as you read this page.

With these tidbit explanations out of the way, let’s move into the technical aspects of this. I deployed two workstations to focus on attacking and two servers gathering and correlating data. One workstation was used to get information on the “attackability” from an outside scope (pure blackhat testing using Metasploit, Immunity’s Canvas, Maltego, W3AF, Accunetix, Netsparker and few other tools). The other workstation used the same tools but provided an inside point of view. “What would a blackhat hacker be able to do if he walked in this office right now?”

The two servers were gathering data in the same fashion. “What are we seeing from the outside and what are we seeing from the inside.” These servers are running a heavily modified version of OSSIM from Alienvault. OSSIM for those unaware, is an SIEM based on open source tools. Almost all networking and security related events are logged.

The beauty of configuring and deploying this kind of setup is that I can create such a targeted and focused penetration test where a blackhat couldn’t. Because I work here, I know firsthand what versions of software we’re running, I don’t need to enumerate users, etc., my testing was very granular and precise. The monitoring ensured me that whatever I tried was logged and an alert was sent out immediately. This allows me to test incident response, test vulnerabilities and weed out the false positives and give a concise report. Not a program generated report with pie-charts with semi-valid information. This is the difference in “I see it is possible to enter your front door” versus “I saw the front door, walked in, and man when that Mastiff snarled, I took a walk! No one is getting in that house of yours.”

How is a set-up like this of value? Let’s take a look at what I’ve accomplished. A decent penetration test could easily top the $80,000.00 mark. Imagine having to randomly perform a high level penetration test attack for the sake of staying PCI compliant. This would be done on a quarterly basis. While the PCI test is usually a scan of an outside IP address, Level1 merchants must have an on-site assessment done once per year [1]

I’ve mentioned the $80,000.00 price tag and it isn’t even a high price for a quality test. But how much would it cost to set-up and perform the testing in-house? Well, I like rounding off numbers to keep things simple so here goes a baseline:

$2,000.00 (2) Workstations (Dell Precision T5500 Dual Core Intel® Xeon® Processor E5503, 2.0GHz,4M L3, 4.8GT/s w/4GB of RAM)
$4,000.00 (1) Server running VMWare (PowerEdge R810 Intel® Xeon® E6510 1.73GHz, 12M cache, 4.80 GT/s QPI, 4C, 800MHz Max Mem w/16GB Memory)
$6,000.00 Immunity Canvas with all vulnpacks
$3,000.00 Metasploit Express
$1,445.00 Accunetix [2]

$16,445.00 (numbers are exaggerated with the exception of Acunetix)

So we have a baseline of a cost to do the testing in house. The server is split using VMWare with ethernet cards placed on different networks. One to give me an internal view, the other to give me an external view. The reality is, I didn’t need to buy a server since I have plenty, so technically, I could chuck the $4,000.00 off of the price tag. Immunity’s Canvas is also NOT $6,000.00 but I will say it is worth that much ;) The reality is, its likely close to about $3,000 with every bell and whistle (D2 pack and so on) give or take. So a realistic number would place me around the $7,000.00 – $10,000.00 mark to create a full blown “in-house Red Team.” To be quite honest, I could also throw in Core Impact (another excellent tool) and still keep my costs under $15,000.00 to complete creating a hellishly focused and realistic “Red Team.”

Application assessments are a different beast but even Klocwork Architect, beStorm, Codenomicon thrown into the pricing will save me in the long run. Remember the goal is to remain compliant. Even if I spent an outrageous $80,000.00 to create my “in-house” shop, it’s a one time charge. Not $80,000.00 per year (for those Level1 merchants). So the ROI is there for those who like playing with security metrics.

All of these tools may mean little to a company though. After all, to go out and spend this money and not understand how to use the tools is similar to saying: “Well, I think I need to go into Sears and buy every single tool to fix my car. Even though I know nothing about mechanics!” Not only would it be a waste of money, but a waste of time. A company will definitely need someone to configure the applications correctly and most importantly, understand what they are seeing. This is where system administrators, network admins, security engineers come into the picture. And this is also why they make the big bucks – at least in theory!

So how do you get an “expert hacker” in-house? Well, there are a few ways, you can either hire them or groom them ;) This I leave to managers to think about. The cost of sending your existing employees to bootcamps, e-classes at places like ElearnSecurity [3], IACRB [4], Learn Security Online [5] pale in comparison with outsourcing and or hiring new talent. Think about it for a moment from a BIA/ROI cost perspective to your business. You have an existing system administrator you pay N amount of dollars. Even if you sent him to all courses mentioned above, you’d spend about say $10,000.00 in training your employee. For starters, I’m sure many administrators would love the training. Sure there is the risk that the employee will leave right after learning, but this can addressed in agreements: “Employee acknowledges if he resigns or is terminated within one year of training, employee will pay for the course.” HR can guide these types of issues.

Anyhow, it is Friday and I’ve gone about writing for the past two hours. I will follow up with the technicalities and stages of the penetration testing soon. Stay tuned.

JO

[1] http://usa.visa.com/merchants/risk_management/cisp_merchants.html#anchor_4
[2] http://www.acunetix.com/ordering/pricing.htm
[3] http://www.elearnsecurity.com/
[4] http://www.iacertification.org/
[5] http://www.learnsecurityonline.com/component/content/article/3-admin/222-apt

Core Impact
http://www.coresecurity.com/content/core-impact-overview

Immunity’s Canvas
http://immunitysec.com/

Acunetix
http://www.acunetix.com/vulnerability-scanner/

Metasploit Express
http://www.metasploit.com/express/

I have touched base before on “defending the castle” [6], and I have received a few emails expressing gripes about corporations *NOT* being able to defend against these attacks. Whenever I receive emails or read articles explaining the difficulties, even impossibilities, of “defending” the castle, I anticipate another news article about another high level compromise. As a security professional, my initial reaction is: “if I managed that security group, they’d all be on unemployment.” At least I can sleep better nowadays: After all, I do have Big Brother [7]; and I have just found out that Big Brother has Einstein 3.

Yes, my fellow readers, Einstein 3 will solve the countries’ security woes in just one fell swoop. Both the National Security Agency and the Department of Homeland Security will now monitor my network for me and “halt the hackers.” They will halt the hackers by “attempting to thwart in-progress cyberattacks by sharing information with the National Security Agency.” By sharing the information in an ongoing attack, the NSA will be able to analyze millions of attacks and respond in seconds!”

Sometimes I wonder who in government comes up with some of these plans. For starters, government (and especially the NSA!) has been *accused* [8] of economic espionage via use of the ECHELON network, so I would be really skeptical about allowing them “unfettered” access to my data. Since 2001, our European counterparts don’t even trust the United States’ capabilities[9], so I would be really cautious, especially if I had business with a competitor of an NSA contractor. Aside from the economic concerns, there are also privacy concerns[10]. Now imagine the politics involved if the United States launches Einstein 3.

What I wonder from the 50,000-foot view is: What does the NSA, or even the DHS, propose to do in the event they DO see a “real life hack” taking place? The biggest problem they will face is cross-juridstiction issues. GLOBAL Justice XML Data Model[11] (GJXDM) might work on an
interstate level, but I’m willing to bet that countries like Russia, China, North Korea and countless others couldn’t care less about “real time hacker tracking.” For starters, it would be an endless money loser for American taxpayers.

Let’s have a realistic look at just a normal attack (forget about a more structured, high level attack). In most attacks, hackers often compromise one system in order to compromise another, in order to compromise yet another. Imagine that there is a hacker sitting in one of the hundreds of thousands of Internet cafes somewhere in China. Determined to compromise a company in the United States, he begins his attack on Monday March 08th 2010, 09:00 in China. He compromises a machine in South Korea to perform the recon, another in Germany to store the gathered information, and yet another in Russia to analyze the data. Altogether, his program takes a day to piece together bits and pieces of data. Let’s say that he took 72 hours to perform the recon, and that he obtained what he needed. He then visits another Internet cafe, where he
compromises three other machines using the information he obtained, and he successfully infiltrates his target.

While a compromise like this usually doesn’t work like that unless there was a Hollywood director involved, even at the onset of the attack what could the NSA realistically do? Contact their Russian, German and Chinese counterparts? How do they propose to cross analyze all that
data in such a short amount of time? Analyze the data, then have countries agree to issue warrants AND thwart an attacker? What happens if the attacker is using encrypted tunnels? How does the NSA propose to realistically view the data? We can move to a conspiratorial point of
view that “the NSA has backdoored crypto,” but that would be absurd in the sense that the overhead of “tapping the entire Internet” AND “decrypting everything that has been tapped” would mean that the NSA would likely have to use the entire state of Alaska as a data center. There would be too much information involved. Too much information and, by the time they could realistically act on it, the Chinese hacker would have left the Internet cafe already. What would the NSA have accomplished? And at what cost? Surely going through the process of tracking or even trying to thwart one hacker could potentially cost hundreds of thousands, and just as surely our deficit would triple with this braindead plan (Einstein 3).

Aside from this little money drainng caveat, how would the NSA or the DHS propose to understand the structure of data across ALL business in order to determine what is a valid attack and what isn’t? I could imagine the emails I would receive from fellow pentesters who were performing legitimate redteam exercises!

[1] http://www.wired.com/threatlevel/2010/02/apt-hacks/
[2] http://www.reuters.com/article/idUSN0325873820100303?type=marketsNews
[3] http://www.itbusinessedge.com/cm/community/news/sec/blog/damballa-google-attacks-perpetrated-by-amateurs/?cs=39800
[4] http://www.michaelsinsight.com/2010/01/hackers-used-spearphishing-in-google-attack.html
[5] http://blog.seattlepi.com/microsoft/archives/195378.asp
[6] http://www.theaeonsolution.com/security/?p=278
[7] http://news.cnet.com/8301-13578_3-10463665-38.html?tag=rtcol
[8] http://en.wikipedia.org/wiki/Echelon_%28signals_intelligence%29#Controversy
[9] http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+REPORT+A5-2001-0264+0+DOC+PDF+V0//EN&language=EN
[10] http://abcnews.go.com/Blotter/story?id=5987804&page=1
[11] http://it.ojp.gov/jxdm/

Again, keeping away from re-writing books, this article assumes that a risk assessment and analysis, a business case analysis and security GAP assessments have been done, at least to some degree. For that, I suggest “Googling” around for variations of those terms. I now return to my irregularly scheduled programming: the technicalities. In order to achieve the creation, deployment and or restructuring of a strongly guarded and segmented infrastructure, one first needs a concise view of what their network is doing, what its objectives are, and what one needs to accomplish in order to keep the “visible” and “accessible” part of a company online. The two terms in relation to this writing need to be fully understood: Visibility, Accessibility.

Almost all businesses in this day and age are somehow interconnected to “something” and there are going to be portions of a company that may need to be both visible and accessible from the Internet. However, not everything will truly need to be connected; therefore, the remainder of your infrastructure should not be visible nor accessible from the world at any given point in time. There is a big difference between a network “having” access to portions of the world, than there are “portions of the world having access to that network.” I will explain this later. For now, I will assume (which I hate to do) that – you have some form of structured guide of what it is – your business needs to accomplish with regards to visibility and accessibility via the Internet.

Because networks are all different, I will attempt to explain this on a smaller scale in hopes that I can provide you with a more concise understanding of why you “CAN” block out anyone you please. The key here is to fully understand what one is doing and why one is doing it. Below is a broad example of four networks, consisting of three government entities and the Internet. We will call them: Example Government Network 1, Example Government Network 2 and, finally, Example Government Webservers 1. Three networks with three distinct objectives.  For the hardcore security and pentester crowd,  in a future entry, I will attempt to explain, dissect and defend against tunneling OUT. (Stay tuned)

Behind Example Government Network 1 is a staff dedicated to making sure that the country runs properly. Their needs are simple ones: access “TO” the Internet for browsing, access TO e-mail which resides off-site and perhaps access to another government network. There is no reason for anyone outside of the government spectrum to access this network, ever.

Behind Example Government Network 2 is a set of staff responsible for another task. Perhaps it’s the FTC, FCC, FBI, or NSA; it really doesn’t matter what agency or portion of the government it represents. What matters is that they too have accessibility to similar functions as Example Government Network 2. They may need to allow connections from other networks in the government arena.

Behind Example Government Webservers is a set of servers with information available to the public. Information, documentation and processes running here need to be accessible to the public at large. They may give users in the public space (the Internet) the ability to search for documents, register for services, etc.

As a network and/or security engineer, segmenting these networks is not a difficult task from the technical perspective. On an enterprise level, it may be time consuming, but the tradeoff in costs to implement – far outweighs the cost of a compromise. What often becomes difficult is determining who needs to interconnect with these servers and what types of information need to be placed on these servers. A huge problem with many businesses and government agencies is that, in the race to “go digital,” many overlooked security and other themes from the onset. Many administrators and engineers are often frustrated at having to “work miracles” to just keep them running, let alone having to continuously run around performing other miracles. For the “techies” it becomes similar to applying putty to any leaky pipes. The logical and correct solution however is to outright replace those pipes before they fully break.  One can argue the cost metrics until their faces turn blue, but these arguments and qualms often take away from actually accomplishing anything useful.

Since networks are often already exposed in some shape form or fashion, you’d need to document the obvious: who can access what; why and when they can do these accesses; and from where can they do it. I could speak of classification, truly ensuring that information stored on these servers has the proper classification types — for example, in the case of government agencies,  there should be no Top Secret, Secret, FOUO or other information disseminated on the publicly accessible servers (but an explanation of those controls would also be like writing a book). Instead, I’ll focus on a more granular view than that of a manager – acting as a “security liaison” of sorts. Think of this view as perhaps a mix between a security manager, a security/network architect and a security/network engineer.

The style of segmenting I refer to when I make my posts “is the proper method” that could be used to minimize the likelihood of an event where an attacker compromises a network from an outside source. In this model, routers, firewalls AND servers would be configured with appropriate configurations that would allow or disallow entire networks and/or services from being accessible.  In the cases of Example Government Networks 1 and 2, time based firewall rules can also be configured.  Let’s think about this on a logical level for a moment: “If no one is connected to or working on a specific machine inside any of those networks, should there be a reason that they allow either incoming or outgoing connections? Is there is a need for accessibility?” This is not a new concept. If no accessibility is needed, block all connectivity, in or out or specify who can access exactly what and from where.  Again, you CAN block anyone you choose to block.

This entire argument needs to come to the table between managers and administrators of systems, networks and software; however, far too often managers are capable of making horrible decisions. Many of these decisions are made by paper based designs.  For example, Mr. Willet’s book makes note of this using what he defines as IA CONOPS – or Information Assurance Concept of Operations. His description of it is: “A CONOPS takes an architecture and applies it conceptually to the organization. A CONOPS is a paper-based model of how the architecture will work in context of the enterprise business environment, technical environment, business processes, and overall culture.”

Reality sinks in.  Many networks are already in place and many of these networks were horribly designed long before frameworks were available. Putting them in proper “security” order from this perspective is difficult. If I had to “re-invent the wheel” for an existing architecture, as an engineer, administrator or manager, I would be hard pressed to get the job done.  It would likely negatively impact the business, as there would surely be network, systems and application outages or flakiness.  This does not mean that it cannot be done, just understand that what I am suggesting – something along the lines of surgery. Carefully take existing applications, software and hardware and use them to their full potential. Many applications and hardware already HAVE the controls in place.  They’re simply not being used effectively. Often there is little need to add additional “firewalls, IPS’, IDS’, etc. ” into the mix. I say: use your brain.

Here is a real world example of “blocking anyone I damn well choose to block.” We offer managed VoIP services here at AEON. We also offer VoIP trunking at the carrier level. Think of us as an ITSP for other VoIP companies, or as a “Vonage for Vonage.” Because of the nature of how we interconnect with other carriers and providers, we have publicly available and accessible nodes. Because we also offer managed VoIP services – some would equate this to a “PBX in the Cloud” – we need to be extra vigilant against attacks such as brute force attacks on PBX’s, phishers and other VoIP based attacks. I have seen, analyzed and investigated quite a few of these attacks, and I have had the opportunity to discuss with other VoIP security professionals these themes on VOIPSA [3].

As a security engineer, my concern is the security of my systems that are publicly available. Because we are “global” in the sense that we have customers from all around the world, it would be absurd for me to block the world–right? No, wrong! Many of my systems outright block EVERYONE until I allow them in, yet my systems are still operational 24/7/365. I have customers in Asia, Europe, Africa, Latin America, and the list goes on. I worry little about ANY country period.

To go a step further, for the techies who may read this, here is a snippet of a brutally written shell script used on certain Linux based PBX’s to block countries:

#!/bin/sh

site=http://bgp. potaroo. net/ipv4-stats/allocated-

wget -qO - "$site"apnic.html|\
awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\
awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|IPv4"
wget -qO - "$site"lacnic.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\
awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|IPv4"
wget -qO - "$site"ripe.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\
awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|IPv4"
wget -qO - "$site"afrinic.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\
awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|Ipv4"

My oh my. Imagine that! Blocking not only Asian networks, but European networks, African networks and Latin American networks. Some nerve! Now mind you, this would not necessarily work on an enterprise network with hundreds, perhaps thousands of machines… Or would it? Surely it would, however it would need some tweaking. So take note of what is meant by “blocking” countries.

In the above snippet, I use the “always up-to-date” lists of KNOWN addresses for ALL countries and block them from accessing services on the server that the script runs on. These are used on top of my existing firewall rules on these machines, and don’t forget that a completely separate firewall does do other filtering. There is nothing that stops me from blocking MY servers from making OUTBOUND connections to other machines. For example, on the PBX’s themselves, I know what their role is, so I can outright block all outbound services anywhere and solely allow those I need to have access out. The same goes for the incoming services: block all inbound services anywhere and solely allow those I need to have access in. Remember, I do state here that these rules run on top of other rules. I’ve allowed in those whom I want in and EVERYONE else gets blocked.

Anyhow, this was a rather long and rambling. I will get back to more writings on blocking, designing, engineering, rambling, manager-fights in a future update. For now, however, I hope the “naysayers” understand that “can’t” should never be a word used when it comes to information technology. Especially when it comes to security. “You can’t block. . . !” Nonsense. You CAN and you outright should. However, I thought a little clarity was needed to make my contentions more explicit. I hope this helped.

[1] http://www.amazon.com/Information-Assurance-Architecture-Keith-Willett/dp/0849380677
[2] http://www.itgovernance.co.uk/products/2207
[3] http://www.voipsa.org

• “Almost every breach his agency investigated, Shirley says, began when an employee was sent a highly targeted and convincing phishing e-mail that spoofed a trusted sender. When the recipient opened a file attached to that message, it used a flaw in the target computer’s software to invisibly plant malicious software on the machine and give it access to the user’s network. (Finnish cybersecurity firm F-Secure recently found one such booby-trapped PDF intended to infect an Air Force computer using a vulnerability in Adobe Reader.)

• But the large majority of those attacks, Shirley says, didn’t use new, previously unknown software vulnerabilities. Instead, they exploited old software bugs that IT administrators had failed to patch, configuration errors and even poor password practices.”

I know I know...

Excuse me?! I have a tendency to use analogies from time to time and with that said, I’d like to share which goes as follows: Imagine having a friend or relative come to you stating they got burned because they placed their hand on the stove. Caringly you tell them: “Be careful the stove is hot, don’t place your hand on it again.” The relative or friend comes back to you: “I got burned again!” This continues on. At what point do you simply turn away after exhausting “I told you so!”

Companies in all industries have been affected by horrible practices, lack of training and similarly horrible managers and guidance. This misguided and insecure trend will continue as these companies don’t change their practices. An issue seen with defense contractors and the military mindset is one of authority: the “chain of command.” In the “chain of command” realm, many employees of these companies are well aware of the threats, trends and attack vectors however, when they’re brought up to superiours, they’re likely shot down immediately. This was visible with Shawn Carpenter of Titan Rain fame [2]. In large corporations, managers shun on talented staff “stepping on toes” and it’s not uncommon for “trouble makers” to have their employment terminated.

After reading dozens of articles similar to the Forbes article – companies getting compromised – I still scratch my head wondering why “whomever” is in charge is still at the helm. It is puzzling to read that a security manager and or security architect isn’t held accountable for allowing the attacks to occur. How many frameworks and guidelines are available for security the architecture. Makes me wonder if high level managers even have a clue or are they solely focused on bogus “risk metrics.” [3] I will now explain my views on this.

“Almost every breach his agency investigated, Shirley says, began when an employee was sent a highly targeted and convincing phishing e-mail that spoofed a trusted sender.” I seriously can’t help but shake my head at statements like these. This attack vector could easily be defended against using S/MIME or PGP plus some training. Now again, there will be those who will “chest thump” and shout “you don’t know what you’re talking about!” or “do you know how expensive that would be!” To those I say, go back to IT school and and or take some art classes while you’re at it. It’s all about creativity.

There is little cost associated with developing a training video using say Camtasia[4] and deploying S/MIME[5] or PGP[6] enterprise-wide as opposed to the cost of a compromise. Someone is likely thinking: “PGP!? S/MIME!?! for 30,000 users! You’re insane!” to them I say do your research.[7] There is no reason outside of horrible managers and horrible practices that the attacks mentioned in the Forbes article occur. No reason whatsoever.

Here is potential cost to a company using the Camtasia suggestion for training. Cost of Camtasia (5 licenses) $1,245.00. Cost of 5 employees spending one week to develop a training video using Voltage. For the employees, I averaged them at $100,000.00 per year salary – which is a little obscene but I’ll stick with it. At that salary we yield $1,923.00 per week per employee developing the video. Total cost in salary: $9,615.00. To be fair I’ll make this $25,000.00

Camtasia:	$1,245.00
Salaries:	$25,000.00
Voltage:	Unsure - Let's say $2,000,000.00 (million) for appliances, training, etc.
Total:		$2,026,245.00

Being that I’m generous with other companies’ money, I’ll double this cost and make it an absurd $5,000,000.00 solution. Still a small price for a defense contractor to pay in order to train staff and purchase the appropriate controls to greatly reduce spear-phishing attacks AND protect data (encryption).  Note that this absurd amount that I’ve come up with is peanuts compared to the amount of money these companies make. Not only that, the amount the could be saved by NOT getting data exfiltrated CANNOT be measured.  In my sample model, a security video is produced and employees can this video on demand explaining how to properly use e-mail, Voltage, PGP or any other product for that matter. Employees can then sign the “Acceptable Use Policy” … Case closed. Dot dot dot – “nothing to see here move along”

Any spokesperson, manager or security professional that wants to counter any of these statements with relevant discourse, please feel free to do so however please take note: I receive who knows how many e-mails telling me “jump off a roof! It doesn’t work that way!” and to those I say: “Sure it does. Maybe it’s time you step on toes to accomplish what you need to accomplish. If your manager is an “unretirable” of the military mindset, maybe its time you explain to them about the ever-changing threats and attacks. Perhaps they’re truly under-clued.”  Shape up or ship out. There is no reason – outside of horrible practices – that the attacks mentioned on Forbes have occurred and are occurring as we speak.

JO
blogs at theaeonsolution.com

[1] http://www.forbes.com/2010/02/17/pentagon-northrop-raytheon-technology-security-cyberspying.html
[2] http://www.time.com/time/magazine/article/0,9171,1098961,00.html
[3] http://taosecurity.blogspot.com/2010/02/thor-vs-clown.html
[4] http://store.techsmith.com/
[5] http://en.wikipedia.org/wiki/S/MIME
[6] http://na.store.pgp.com/
[7] http://www.voltage.com/products/securemail.htm

With this rambling out of the way, I now turn to this article “Defending Against The Threat.” Whether structured, advanced or persistent, many of the “publicly known” attacks being disclosed could have – and should have – been prevented. You can’t say something is “white” yet also “black,” especially when there are alternatives. Grey perhaps? What if someone is color blind? How do you explain this to someone who has no concept of color? You say advanced; I say structured. After reading Mandiant’s M-Trends report [1], there is nothing that is “publicly available” in that report or any other that I have read, that stands out as “advanced” from a “hacking” or “hacker’s” perspective.  I chose to replace the term “advanced” with “structured,” and the use of “persistent” is on point and evident — however, it is also irrelevant. There is nothing “advanced” in using spear phishing. There is nothing “advanced” in backdooring a machine. While there is an “advancement” in what is done afterwards – exfiltrating specific data – we might as well say that “any” compromise is “advanced.” Nothing to see here, so move along.

M-Trends reports: “One of the key executive’s systems was compromised when he clicked on the link embedded within the e-mail, which then downloaded and executed a malicious file. The malicious file installed a fully functional command and control backdoor on their system that allowed the APT full access to the system from the Internet.“  This is not a new attack nor a new attack vector, as virus and worm writers have been doing this for quite some time. Sending malicious payloads in the hopes that someone will “click that link” or “run this program” is old news. Is the word “advanced” being used by media and or security companies because a hacker created a “snippet of code” that’s obscure, which makes security professionals scream: “They used advanced code, therefore it’s an advanced attack!”? If so, that would make all “code” used in a compromise, by definition, advanced. The attack vector described by the M-Trends report could have been defended against by training staff to avoid opening certain emails. It could have also been defended against using strong email filtering. Imagine that? An advanced defense – readily available!

First of all, filtering on an email server could have and should have blocked this threat (spearphishing), no matter what. Even if the “snippet of malicious code” had no known or unknown signatures. Where did this e-mail come from? “How come John Smith who works out of Yourtown USA is sending me a PDF file from Guandong, China?” Filter, filter, block, block. Secondly, if filtering wasn’t in place, educating staff on the dangers of e-mail could have potentially stopped this particular attack dead in its tracks. “What is John Smith talking about and, if it’s that mission critical, how come he didn’t pick up the phone, and instead he sent me an email with a PDF? Should I open this?” Thirdly, security controls play a big part. If the company used something like S/MIME, or PGP keys, the e-mail wouldn’t have been validated and the attack would have been thwarted. Many of these controls can be had for free. The cost of configuration and deployment is another issue. There are plenty of options in how to defend against these attacks and they have long been available and established.

Moving along in Mandiant’s report, it states: “More than 30 user account and password hashes were obtained from the law firm’s domain controllers. Using those valid credentials, the attacker was able to extract thousands of e-mail messages and their attachments by downloading the information from the firm’s mail servers.” This attack – called passing-the-hash – is also not new; in fact, it dates back to 1997 [2], it has many publicly available exploitation tools [3] and it can be defended against and or minimized by using Kerberos [4]. The issue then becomes one of configuration and deployment. There is nothing advanced about this attack nor is there anything advanced in defending against it.

From a technical perspective, the hacker’s slash security engineer’s perspective, nothing explained in “documented” APT compromises is “advanced” in the sense that these attacks are – and have been – around for some time. From the “security manager’s” perspective, or someone outside of a “hacker’s” mindset – these attacks elicit a “that’s really advanced!” stance.  From those in certain industries, while they may not have seen a particular attack, this does not mean it is more or less advanced than any other attack. The bottom line is: an attack is an attack is an attack, ad-nauseum. “But they changed from normal text to base64! Surely that’s an advancement!” Nonsense.

From a “security vendor” perspective, an “advanced persistent threat” is horrifying and capable of crippling a company. This is not incorrect, but it alludes to a notion that this fatalistic threat can be stopped only if you hire the right experts or buy the right software. More nonsense. This is a big gripe of mine when I see a company report on “threats,” especially from a security company. I always take a skeptical point of view when it comes to these reports, because companies almost always promote their “wares” in this fashion. So the notion of getting an unbiased view from a security vendor regarding security is almost non-existent. Many companies tweak information to their liking and, whether professionals publicly admit to this, one would have to be naive to think it doesn’t occur. For example: “Statistics show that…“, “One out of every three people…”

Richard Bejtlich [5] has perhaps the most outstanding and informative information on the subject of Advanced Persistent Threats [6], and I sincerely respect his knowledge, approach and expertise in the security arena. However, as stated, I believe some people tend to isolate themselves, which can lead to chest-thumping, misinterpretations, misunderstandings, etc… whatever the case may be. If you ask me, I will tell you: “Advanced Persistent Threats” are nothing new. Governments, companies, even husbands and wives have performed “targeted” attacks for eons. The explanations of APT – at least most of what is publicly available – still make me wonder how companies managed to make it through compliance using such highly vulnerable software listed in the Mandiant report.  Almost all “commercial off the shelf” vulnerability analysis tools would have flagged the software described in report. This given the fact that APT – for all that is publicly known - is actively attacking OLD software. Regardless of the method of payload delivery (PDF, IE, e-mails), it is actively attacking exploitable software which has had security advisories going back almost half a decade. These are pure facts. If hackers are actively attacking specific versions of software, perhaps it’s time to rid yourself of that threat. You would be the fool to continue using that software–period. Many security professionals have been pounding their hands on the table now concerning the use of certain products. Maybe it’s time those in suits take a step back and listen to their staff?

For those security professionals thinking about “creative responses” such as: “We can’t update this legacy system because of…” or “You don’t know what’s involved in an enterprise…” I suggest that you take a logical approach: Would you apply a band-aid to a wound that has been bleeding for years now? Don’t you think it’s time you sought medical attention? The band-aid is obviously doing nothing, isn’t it? So whether it’s a browser, PDF reader, e-mail client, etc., security solutions are available to fix the problem. However, the fixes may involve a level of resources that may not be immediately available, due to time constraints or lack of training. Move away from using “exploitable” software or suffer the consequences. You cannot have it both ways: Choosing to use exploitable software – and staying secure. It’s one or the other. This is not “advanced“, “perplexing” or “complicated” logic; it is just common sense. Anything else is marketing, either by way of someone touting a security product, or someone who is not creative enough to find a solution to the problem.

My recommended solution would be to rid oneself of the offending (exploitable) program, install strong SEIM and have the staff tasked with monitoring the SEIM understand what they need to look for. Surely, if a connection is being made in a suspect fashion (out of the blue) to China or anywhere else, act on it. Again, if China or any other country is the threat, one could go as far as enabling strong firewall rules both on the host and the perimeter. Case closed: Nothing to see here, so move along. For those whining about it by saying “it would cost a fortune!”, I ask them: What’s worse, the cost of implementing a fix or the cost of your business being compromised? For those whining about “legacy” apps, I ask you, at what point do you look for an alternative? Force the vendor’s arms to implement changes. You are after all the consumer paying the vendor. In this economy, I’m sure there are plenty of vendors willing to work with your business. Anything else is just an “Advanced Persistent Excuse” not only from your vendors, but from inexperienced individuals who aren’t willing or able to think outside the box.

“You have no clue, you can’t block China!” sayeth the manager. Why can’t you? Surely, if there is no reason for your machines to be making random outbound requests to China at odd hours, there is no reason why you cannot have time based rules to block that or any other country. I suggest security managers and professionals take a realistic view of security as a whole instead of following the herd. Speak with your team. For the sake of your business, I hope that there is no ‘I’ in that ‘team.’ Good luck!

[1] http://www.mandiant.com/products/services/m-trends
[2] http://www.securityfocus.com/bid/233/info
[3] http://www.derkeiler.com/Mailing-Lists/securityfocus/pen-test/2008-11/msg00087.html
[4] http://oss.coresecurity.com/projects/pshtoolkit.htm
[5] http://taosecurity.blogspot.com/
[6] http://taosecurity.blogspot.com/search?q=apt

In the true form of FUD manufacturing, APT needs to be explained in detail. This “dire threat” is explained by Wiki as:

Advanced – Operators behind the threat utilize the full spectrum of intelligence gathering techniques. These may include computer intrusion technologies and techniques, but also extend to conventional intelligence gathering techniques such as telephone interception technologies and satellite imaging. While individual components of the attack may not be classed as particularly “advanced” (e.g. malware components generated from commonly available DIY construction kits, or the use of easily procured exploit materials), their operators can typically access and develop more advanced tools as required. They combine multiple attack methodologies and tools in order to reach and compromise their target.

Persistent – Operators give priority to a specific task, rather than opportunistically seeking immediate financial gain. This distinction implies that the attackers are guided by external entities. The attack is conducted through continuous monitoring and interaction in order to achieve the defined objectives. It does not mean a barrage of constant attacks and malware updates. In fact, a “low-and-slow” approach is usually more successful.

Threat – means that there is a level of coordinated human involvement in the attack, rather than a mindless and automated piece of code. The operators have a specific objective and are skilled, motivated, organized and well funded.

Kevin Mandia in the Wired Article states: “There are not 50 companies compromised. There are thousands of companies compromised. Actively right now.“  These comments almost made me jump out of my seat and fork over a purchase order to the first company returned on a Google search. “Thousands compromised!” That must mean trillions of dollars! While it sounds potentially “nation-crippling,” the harsh reality is that companies have only themselves to blame where is quality assurance, CoBIT, ITIL and other various forms of risk assessment and security. There are many established mechanisms to block these attacks and many are free. I am skeptical of the numbers Mr. Mandia claims are compromised. Thousands of companies? This infers that “thousands” of companies are not and have not been compliant with regulatory measures for some time.

I repeat: Many of these attacks – including and especially the 0-day attacks – can and could have been drastically minimized and or stopped ages ago; however as an engineer, I can see how many companies and their systems of bureaucracy in those companies, might have at times prohibited security professionals from stopping these attacks. That coupled with those companies who hire under-clued security engineers, the improper training of staff, an arrogant attitude from businesses and certain employees and, of course, some would argue “technological constraints.”

The technological mechanisms needed to minimize and or stop these attacks are already available to most companies. They are likely to be already in-house, and many of the necessary components that “aren’t” readily available can be had for the whopping price of free. I will discuss this momentarily.

Getting back to snippets of the Wired Article, it was shocking to learn that Google’s employees had “received e-mail with malware that exploited an undiscovered vulnerability in Internet Explorer 6.” Shocked that Google would allows its employees to use an outdated and known-to-be vulnerable browser. It just sounds mind-boggling considering that Google makes its own browser Chrome [5]. However, in being fair, let’s suppose that Google did use a vulnerable browser as stated in the article: If so, then how did Google and “thousands” of other companies meet compliance? After all, Google is publicly traded, so SOX for them, compliance is a must. Google also has some very talented staff on hand, so surely the use of a vulnerable browser would have not only have been regulated through mandatory compliance audits, but there would be red flags aplenty by Google’s own staff. Or maybe, just maybe, someone at Google fell asleep at the helm, then woke up, discovered the nature of the APT beast and decided that enough was enough. [6]

Either way, the argument from those in enterprise environments in using vulnerable software is a typical one (quoting one typical forum):

Imagine your billing production system (which produces 100,000’s of bills each run) was designed for MSIE 6 (stupid I know). The upgrade cost is very high (factoring development, deployment, testing, training, etc), even if it’s only <<< for a “simple” upgrade to MSIE7/8. We’re not talking about home PCs and consumer applications here. The enterprise is a different world! It’s tricky to upgrade. However, with that said, I hate MSIE 6 and would love to see the thing go!

My views of statements like this one is that, companies seems to lack quality assurance and potentially security aware staff at these companies. Too many metrics from security managers and inconsistent risk metrics; AV * EF = nonsense.  For those companies that have legacy programs that were designed for a particular browser, the solution to that problem is to force the vendor to create support for a more secure version of the browser, or isolation. You are after all the customer and demanding competent support is not much to ask. Note that the words “force the vendor” imply that you are after all paying for support, are you not? If it is a legacy application with no support available, then the obvious answer would be to either find a new product or to sandbox the systems that need to utilize browsers with widely known security holes. Certainly a proxy server with solely internal connections can intercept browser connections, PDF documents and the like. It is inexcusable to let a particular browser or vendors limitations compromise your security.

In either event, most of these attacks could have and can be defended against with established security controls and training. Companies could even utilize their existing infrastructure to liaison amongst documents, emails and ensure that no rogue documents or scripts reach users. For example; Install Apache, Squid, and use a Unix based machine with the proper firewall rules. Using a sandbox server with no outbound (towards the Internet) connectivity, and then force users to read from this server. Apply “Extrusion Detection” [7] and keep a vigilant eye on data leaving the network. It is that simple. Don’t let anyone in the security arena fool you into thinking the sky is falling via usage of buzzwords such as APT. Otherwise, you could end up jumping out of your seat, running to get a purchase order signed and paying the first company to spout what will likely be the new buzzword: APTDS “Advanced Persistent Threat Detection Systems.” You could even go a step further if China is a concern for you,and outright block their IP space on a most extreme level.

Nothing mentioned in the article via way of attacks being carried out is foreign or advanced to a properly trained security professional. At least theoretically, they shouldn’t be. As a matter of fact, the Information Assurance Certification Review Board’s (IACRB) [8] Certified Expert Penetration Tester (CEPT) [9] exam exposes security professionals to many of the tricks these “APT” hackers use to infiltrate a network. Perhaps businesses should take the time to train their staff more properly? Maybe they need to hire Jack Koziol, Dave Aitel, Dino Dai Zovi or other expert penetration testers to wake up management before businesses continue to suffer “by the thousands” as Mr. Mandia suggests. The answers are and have been simple for some time. Talk of “Operation Aurora” continually seems to be, highly FUD driven. That’s my opinion, and also that of some other security heavyweights that have chimed in similarly on this issue as well. [10]

However, as the old saying goes though: If you can’t beat em, join em. To that end, I now offer DUMBASS: It is scalable, defensible, makes sense and is economical in these hard financial times. Prices can be discussed via secure channels.  Just remember to act now while the threat is persistent and deeply rooted in your network right now. Operators are standing by.

JO

Here is a quote from a cloud evangelist: [2]

I’m not sure how to express *exactly* what I’m feeling, so I’m going
to just “shoot from the hip”.


The “Use Cases” project is starting to feel like a car that just slid
off the road into a swamp. It’s just my own personal POV, but since
Security entered the conversation it feels like we’ve just been
spinning our wheels, and getting further and further from being able
to create any tangible deliverables.

IMHO Security can’t be shoe-horned into a Use Case — it is too vast
and unbounded for us (as a group) to have any hope of adding to the
current body of knowledge or generating any meaningful and practical
work products within the scope of the project as presently
understood.

Of course it’s entirely possible that I’ve underestimated the scope
(or time frame) of the project, but if not, then I think we’re heading
straight into the bog.

The discussion went into providing “Use Cases” for the cloud and building from there. This to me may lead one to believe that a “Use Case” scenario applies to a “real world” scenario for their particular company.  Companies differ and while a “Use Case” may have worked for one company, it is not a “holy grail” sign to move into the cloud.  Too much can go wrong and the expectation that any provider will understand “risk” outside of their own business objectives is insanity.  For this statement I will once again quote John Engates of Rackspace:

“You have to treat it like a factory instead of like a custom shop. You have to think large-scale. It might be easy to do something for one customer, but you have to think about the next 1,000 customers behind them, because everything has to be replicable, both from an operational standpoint and from a technology standpoint.  You have to be able to do a lot of work with relatively few people.  You always want to make a customer happy, but sometimes you have to say no to be able to have a scalable product or service.  You need a menu of offerings; you can’t do one-offs–they’ll break the model.“

Moving back to the initial opening on the government and the cloud, the answer to the un-asked question of “why did it happen?” is simple:  Oversight and trust.  Someone in government “trusted” a cloud provider enough to believe the provider was capable of providing security.  The provider likely impressed upon “someone” that the provider had the capabilities of providing proper security controls.  This has to be the case otherwise there is no reasonable explanation outside of a temporary lapse of sanity, that the government would have allowed data to be placed on an insecure server. Translation:  *someone*, *somewhere* stated and showed they had security mechanisms and controls in place to protect data and services… “We’re compliant with your needs, we provide security…” This is the answer to “why it happened?” – trust – not: “well, it happened because someone used a XSS Injection in Joomla.”

Reality is harsh and the harsh reality of this incident is:  GovTrends and their security department are incompetent along with those in government that made the decision to use “the cloud.” Apologies for the harsh words, but the reality is what it is. Had the US government’s IT architect’s and engineers taken the time to validate any security risks prior to using GovTrends, there is a high likelihood that any Joomla and or other CMS system vulnerabilities would have been discovered and there would have been no compromise at all.  While some may say it is unfair for me or anyone else to speculate that the Joomla vulnerabilities would have been discovered, then I’ll choose to disagree and state: “Joomla or any other CMS should have been secured.”  This compromise could have absolutely been avoided with simple and free solutions.  An .htaccess file prohibiting users via IP addresses – do you really need someone in another country accessing the management interface of a US government website?  Cost? Two minutes to configure at most. Another means of authentication, mod_security and I could create a list of fixes that would have mitigated against this compromise. Quite easily I might add.  The security lapse at GovTrends is inexcusable.  Not only from the vendor’s point of view, but of Congress’ lack of judgment. Trust but verify.

Cloud security will be a huge business in the coming months and years, and Schneier was spot on with the statement “security is a process not a product.” [3]  You don’t “rent” security in the cloud. You don’t “buy” security in the cloud.  As a realist, one need only to look at John Engates’ statement and figure out the truth at the end of the day.  That truth and harsh reality is that a cloud provider is concerned with nothing more than revenue for their business.  Not your data, not your security.  They can never truthfully claim to be capable of securing your cloud.  What they can truthfully claim is that they will try their best to meet a SLA and perhaps they may have good intentions on attempting to provide security.  However, they will not go above and beyond a template model.  Government is not a template, nor is anyone’s business. The US government and others who fall victim to buying shares of the Brooklyn Bridge solely need to realize the risks which were blatantly pointed out by ENISA’s cloud security risk document on page 9 [4]:

MANAGEMENT INTERFACE COMPROMISE: customer management interfaces of a public cloud provider are accessible through the Internet and mediate access to larger sets of
resources (than traditional hosting providers) and therefore pose an increased risk, especially when combined with remote access and web browser vulnerabilities.

Luckily for Americans, this isn’t the only “cloud based” issue one needs to worry about (website defacements).  There is the hard push to move a lot to the cloud. As we’ve already seen with the US government in its infinite wisdom treading dangerous ground with its Apps.gov [5], which is partly “powered by Google” [6].  Now Google, as we have stated earlier [7], bears some of the blame for the attacks by the Chinese in the sense that they have the capabilities in place to have stopped the previous attack (Operation Aurora) and did not do so:

Had Google an idea of what was really occurring during the compromise phase, they could have easily inserted a script that when a user landed on Gmail, which would have redirected users of affected browsers to a warning page: “Beginning INSERT_DATE_HERE, you will no longer be able to access Gmail using IE6.  Please update your browser as it exposes you to a lot of risk (or something along those lines).  This would have given Google a more caring like approach.  Aww, Google cares for my security!  If anyone can make something move on the Internet it certainly is Google.  Google to their credit warned users in 2008 to drop IE6 [8], yet everyone is shifting the blame to Microsoft.  I say, blame the users. [7]

That however is neither here nor there. What is here now though is the cloud. Those beautiful clouds!  The ones you would sit around the lawn staring up into the sky at.  Dreamy like!  Making shapes out of them only to watch them disappear into another form.  Vapor.

[1] http://www.infosecurity-us.com/view/6936/us-house-websites-hacked-after-state-of-the-union-/
[2] http://groups.google.com/group/cloud-computing-use-cases/browse_thread/thread/54be79e75f2abea4
[3] http://www.schneier.com/crypto-gram-0005.html#1
[4] http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment
[5] http://www.whitehouse.gov/blog/Streaming-at-100-In-the-Cloud/
[6] http://mashable.com/2009/09/15/government-going-google/
[7] http://www.theaeonsolution.com/security/?p=190

This recent compromise compounds this. I’m positive that “GovTrends” the “cloud provider” for the government whom was compromised had a security program in place. Had performed risk assessments, had firewalls in place, intrusion detection and all sorts of other nifty security controls. If they didn’t it is highly unlikely they would have gotten the contract to host government data in the first place. What this compromise obviously shows is that cloud providers will not get it right. The reason behind this statement is, the exposure is far too high.

ex·po·sure

1 : the fact or condition of being exposed
a : the condition of being presented to view or made known
b : the condition of being unprotected
c : the condition of being subject to some effect or influence
d : the condition of being at risk of financial loss; also : an amount at risk

When companies or governments maintain control over their own Information Technology environment, that party is aware of the controls needed for security. There may be file permissions that need be in place – in the case of governments – classifications need be in order. Security controls are known and there is (or at least should be) a high level of accountability. Administrators, engineers and managers of that data know their behinds are on the line. There is likely to be a greater emphasis given to the security of that system. There is likely to be a more focused and targeted method to secure the server or network. In a cloud environment it is solely word of mouth along with a Service Level Agreement and whatever marketed security writing the cloud provider cleverly mangled together. Certainly whatever GovTrends promised didn’t pan out as expected. Again – this is evident by the compromise – nothing to debate here move along.

Recently someone countered some of my writing and quipped: “You can’t “technically debunk” the cloud. As with all security decisions, there is a trade off between “more secure” and “cost” and each situation requires its own risk assessment. A stay at home mom who knits in her spare time has no reason to set up her own web server and point of sale system so she outsources that to the cloud via eBay. On the “needs more security” end, the Federal Government has no reason to have each base in the military have its own email server so it outsources that function to large data centers, creating a cloud.” This individual I know – or at least perceive – to be highly knowledgeable in security on the CISSP, CISM level, perhaps he’s even highly knowledgeable on the technical level as well however, one cannot compare apples an oranges. My response to him was logical (at least from my perception) and since it was rather long response, here is the relevant snippet: “A stay at home mom does not have to worry about leaking out data on classified nuclear material, troops’ positions, nuclear football locations and the like. … For starters, a cloud provider isn’t going to let you assess anything beforehand obviously. So what should I do, rely on their experts? … This while the cloud evangelist sing “the cloud does not introduce any new security threats or issues.” He’s right, they’re not new security threats, they’re just amplified and beyond my control. No thanks… So while Sally the house mom can knit her little scarves, I as a consumer don’t really care what she does or where she does it. As an American, I am concerned with the marketing of the cloud as a “secure alternative” especially when it comes to military or other parts of government…”

Many still choose not to accept the reality of it (security in the cloud being non-existent). Perhaps the passion behind truly trying to achieve a “secure cloud” is what blinds them, perhaps it is the financial benefits – certain a billion dollar industry is nothing to sneer at. Reality is what is it – the moment you move your data elsewhere your exposure is a lot greater. I am willing to bet anyone that had the Obama administration kept their servers in-house, the likelihood of those attacks occurring would be non-existent. Remember, according to the article, this isn’t the first time hackers compromised that provider. Sadly, they were re-compromised with the same vulnerability. Fool me once shame on you, fool me twice?

JO

http://www.gather.com/viewArticle.action?articleId=281474978021691&grpId=3659174697241980

Obviously

Irrelevant? Sort of. If you’ve followed us this far (the blog), you will notice the word play inherent in that statement: “Irrelevant – sort of.” The fact is, the only thing that should be relevant to you is your data. Whether you are a business owner or an individual, data should be the cause of your concern. It is likely that this is how you earn your bread and butter.

In the TMCNET article, the author lists his ten security recommendations, so let’s have a look at them:

1. Those exploring cloud solutions should establish their risk appetite and evaluate offerings against it.

I state: Those exploring cloud solutions should take a logical approach and ask with clarity: What do clouds do? Answer? Usually Evaporate. Risk Appetite as explained by KPMG is: “the amount of risk, on a broad level, that an organization is willing to take on in pursuit of value. Or, in other words, the total impact of risk an organization is prepared to accept in the pursuit of its strategic objectives.” I will always use the same statement as experts to give credence to my points. So if you run into a lot of quotes, understand that I do this is in order to support my own claims.

Is an organization really ready to risk huge financial losses on the theory that a cloud will always be there? Logically, clouds in the sky evaporate; “technology clouds” are no different. There are many different problems with relying on a cloud for anything at all, so for an organization to have an “appetite” for losses versus rewards in this arena is mind boggling. We’ve already posted the numerous occurrences of outages from cloud providers, and it doesn’t take a financial wizard at the Federal Reserve to document the losses stemming from these outages.

2. Companies looking for cloud solutions should establish a cloud provider security risk profile and update it at least annually.

I state: Companies looking to waste money should waste their time and resources studying the inaccurate information provided by cloud companies. There is no mechanism to gauge a cloud provider’s risk profile. Anyone claiming they can do so is likely capable of selling you stocks in the up-and-coming sale of the Brooklyn Bridge. This fact was disclosed by ENISA who gave “cloud anything*” a high risk rating (page 22 [2]).

3. Those exploring cloud solutions should use a risk vector analysis matrix to evaluate cloud providers and those served by the same cloud vendor.

I state: See my counter above for number 2. The author at TMCNET is not telling us anything new. Why should I spend money that could be going to development and research to move my business forward to try assessing someone else’s business?

4. Make sure you evaluate the security program for cloud computing vendors up front and use it to narrow down potential vendors.

I state: Clearly there is little to be gleaned from the continuous marketing and overhyping of the cloud, since the security in the cloud is not-so-great. Not to be repetitive, but ENISA clarified this in R.2 LOSS OF GOVERNANCE: ‘There is no mechanism to perform an independent evaluation beforehand.’ “Hi Amazon? I’m thinking of using your cloud but I want to first validate on my own that you’re secure. Therefore I’d like to send a real world pentesting team comprised of listeners from Exotic Liability.” [4] How does the author propose that someone actually perform a real evaluation on a cloud provider and then validate the findings of that assessment?

The remainder of the article points out much of the same — nothing that we haven’t read elsewhere …

duh

5. Ensure your contract with the cloud provider includes ongoing security reviews and language mandating immediate notification (within 24 hours) of serious security events.
6. Review the cloud provider’s HR and supply chain practices and employee background check process and hardware/software/equipment sourcing security needed to reduce threats.
7. Know the names of all other organizations supported by the cloud so that you can assess any increased risks they may bring.
8. Use common controls reviews based on the ISO 27000 and 28000 standards to reduce the assurance burden.
9. Address in your contract the legal risks like subpoenas, e-discovery and jurisdictional issues as well as technology licensing issues.
10. Finally, conduct a cost/benefit/risk reduction analysis of vendors offering secure cloud solutions with hardened data centers, hardware isolation and other security fortifications.

Again, many of these have been addressed by ENISA and it seems that those pushing for businesses to “come to the Cloud” are constantly writing a barrage of articles that are similar to one another. Not one article has raised an eye-opening “Aha! So that’s how we will be secure!” There are far too many what-ifs. If only you secure your cloud dot dot dot ensure your cloud vendor dot dot dot… Don’t sell me a cloud, it’s possible that someone has already tried to sell me a bridge.

[1] http://data-voice-solutions.tmcnet.com/topics/security/articles/73409-top-10-cloud-computing-security-recommendations.htm
[2] http://www.cnn.com/2010/OPINION/01/23/schneier.google.hacking/
[3] http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment
[4] http://www.exoticliability.com/