Monthly Archives: July 2014

Security on a Weak IT Foundation

The interesting question of maturity

Earlier this week, Bill Burns asked me this question...
"can a security team have a higher level of maturity than the IT team that handles its operational tasks?"
It's an interesting question, and one that certainly requires some level of thought. My top-of-my-head response was - well ... no. This is clearly a "lowest common denominator" problem.

The more I thought about it, the more this seemed like an obvious answer - a CMMI level 2 IT organization was never going to support a CMMI level 3-5 security organization. That should seem rather obvious. But the more I thought about this, the more I think that a CMMI level 2 IT organization can't support anything but an n-1 security organization. Let me explain my thinking here-

Weak foundations, weak security

It should be rather obvious that a weak foundation cannot support a tall, strong structure. You simply don't have the stuff it takes to hold it all up, from a building perspective.

In the IT world, if you have weak operational IT practices, you'll never get anything better than weak security practices. For example, let's look at how IT views and assesses assets on the corporate network. If IT can't tell you every asset on the corporate network right now in an on-demand manner, with troves of accurate meta-data then you can't possibly expect to build a strong security operations program on top of that. Security needs foundational things such as the ability to know what's on the network and loads of meta-data about each asset in order to make decisions on the risks these assets pose.

Decomposing that even further to the most simple blocks - if IT doesn't know what's most critical to the business in terms of supporting function, security has absolutely zero chance of successfully crafting a defensive response strategy or operational plan. If an asset is suspected of being malicious or compromised (an IP address, for example) meta-data is needed to decide whether the alert could potentially be a false-positive, or if it even warrants a response (maybe it's just some lab machine which can simply be turned off). As a kid G.I. Joe taught us that knowing was half the battle - and not knowing means you're lost.

Weak foundations, weaker security

In an effort to try to understand this more, my line of thinking leads me to believe that organizations with a particular CMMI score when it comes to general IT, can only support an n-1 CMMI score for security maturity.

The reason I believe this is that security operations, by their very nature, cross many IT silos and require well-thought-out and precisely executed workflows and communication to function well. When you cross team boundaries, silos and responsibilities these inherently break down even a little - thus diminishing what you can build on top of them. Like the great pyramids - the higher you build the more you have to stack inward. Security - at least in my narrow view - is sitting right at the top of the IT ladder, thus making it fairly difficult to do well if the base of the IT operations is shaky.


The long and short of it is this - if your enterprise has poor IT hygiene, and ranks low on the CMMI scale - focus security effort and resources on helping IT level up before you start to drop in expensive and complicated security kit. In essence, flashy boxes or solutions won't do you much good when you try to operationalize them on top of poorly functioning IT infrastructure, processes and methodologies.

BMWs and Bicycles: The Value of Complexity

If your ideas about Oracle Identity & Access solutions start and end with the word complexity, you're missing the big picture. Contrary to what competitors might be telling you, Oracle's current IAM solution looks nothing like a conglomeration of distinct, aging products. If you want to know about today's Oracle IAM solutions, consider concepts like: common data model, consolidated feature set, shared services, unified admin and operational consoles, and a lower TCO than managing multiple point solutions.

It didn't happen by accident. Oracle has a large, diverse, and talented team of engineers and developers. I'm consistently impressed by the level of talent roaming the halls at Oracle. And the team knew years ago that continued innovation was important. They intentionally expended significant effort to rationalize the product backend so that it's not simply multiple integrated products. Did you know that Oracle uses a single connector for user provisioning, access governance, and privileged account management? Did you know that Oracle's provisioning product also provides access requests, risk scoring, and entitlement reviews in a single product? (not a license bundle - a single installed product)

Can the entire solution be downloaded onto a smartphone and installed in 3-5 minutes? No. But, the solution can meet any current or future Identity & Access requirement with a modular, unified approach to Identity & Access for legacy, enterprise, cloud, mobile, and social use-cases. And there are numerous customer case studies that demonstrate Oracle's IAM technology has already been implemented in mobile, consumer, and IoT scenarios with extreme scale. Claiming that Oracle can't handle third platform use-cases is either ignorant or deceitful. Which it is depends on who you're talking to.

That's not to say that there aren't IAM solutions on the market that offer less complexity. But let's investigate complexity for a moment.

Is complexity good or bad?

If you already answered, you're missing the point. The reality is that complexity should be commensurate with your needs and the optimal amount of complexity will depend on the context.

A BMW is more complex than a bicycle. If your goal is take a leisurely ride through a park to enjoy the weather while getting some exercise, then a bicycle may be a great fit. And a BMW will miss the mark entirely. If the goal is to find a vehicle for your daily commute to work, you might still opt for a bicycle but you'll be balancing the desire for less complexity with the BMW's feature advantages of getting you there quicker, shielding you from the weather, and requiring less effort. If your intended use-cases involve cross-country trips or travel in severe weather, the complexity of BMW engineering becomes a thing of desire. And if you fall in love with the way a BMW handles corners at speed, well... let's just say you may stop thinking about complexity altogether.

Getting back to IAM, here are some IAM features to consider:
  • Enterprise Access Mgt - Context-Aware Adaptive Access and Fraud Detection
  • Enterprise Access Mgt - API Security and Protocol Translation
  • Enterprise Access Mgt - Social Logon and Identity Validation
  • Enterprise Access Mgt - Mobile App for Strong Authentication
  • Enterprise Access Mgt - Enterprise Single Sign On
  • Mobile Security - Secure App Management and Endpoint Data Protection
  • Mobile Security - True SSO to backend applications from the mobile device
  • Mobile Security - Apps integrated with Enterprise Access Mgt
  • Identity Governance - Integrated Access Requests and Provisioning
  • Identity Governance - Entitlement Certifications
  • Identity Governance - Single point of audit across cloud, mobile, and enterprise
  • Privileged Account Management - Proxied Access, Session Management
  • Privileged Account Management - Session Recording
  • Privileged Account Management - Emergency Access
When you begin to think about how these capabilities can be used to enable new business opportunities, it starts to feel like a BMW approaching a corner. And you'll be glad you're not on a bicycle.

Ad-Hoc Security’s Surprisingly Negative Residual Effect

Security is fraught with the ad-hoc approach. Some would argue that the very nature of what we do in the Information Security industry necessitates a level of ad-hoc-ness and that to try and get away from it entirely is foolish.

CISOs are challenged with this very thing, every hour of every day. Threats pop up that they aren't prepared for, and present an imminent danger to the business, so they must react. These reactions are necessary to keep the business operational, no one will argue that, but it is when they have a residual effect on the enterprise that we run into problems.

It's the old snowflake rolling down the mountain analogy... sort of.

How it starts

Since no security program I'm aware of has managed to account for all the threats it will encounter, let's take any one of them as an example. The threat may be some semi-custom malware which targets a particular piece of software in their industry vertical, or it may simply be something as common as a banking trojan. The CISO realizes that they simply don't have the supporting infrastructure to mitigate or help in remediation of the threat - so off to the ad-hoc bin we go.

There are, in general, three possible courses of action which follow.

First the ever-popular "we'll write some code" option. Many CISOs have access to some amazing security talent, and thus the ability to whip-up some custom-coded solution which takes care of the issue. Quite common. I'm not even saying this is a bad option! If you've got the talent, why not utilize it to its full potential.

Second, the almost-as-popular "hire an army of consultants" option. External consultants descend on your enterprise and identify, contain, and work to mitigate the current threat. Your hope is that they document their work, and maybe leave behind some clues as to what was done, why, and how you can repeat this procedure int he future.

Now for the most popular option, unfortunately, if the issue is big enough. This is the "let's buy a box" option. CISOs who feel overwhelmed look to their partners and often times the analysts to provide them with options. Not surprisingly, much of the time the 'solution' comes in a nice 2U rack-mountable appliance, with a yearly maintenance contract.

With the threat, at least temporarily, addressed, it's on to the next big issue. Playing whack-a-mole is the modus operandi for all too many in security leadership... and it's not a commentary on their effectiveness or abilities, it's just simply the way it is.

Once you've moved on from the previous problem what we have left is what is commonly referred to as a "one-off".


Entirely too many networks are simply littered with "one-offs". Solutions which once served some point purpose which have either been forgotten, fallen out of maintenance or support, or simply no longer serve the greater mission of the enterprise security organization. So many of these "one-offs" don't integrate well, aren't interoperable, or don't scale ... or worse they're simply not manageable at the level that your organization needs.

The problem with ad-hoc security measures is that we tend to create too many one-offs like this. Databases getting ripped off through the web apps? Drop in a WAF (Web Application Firewall). PCI requires you to log? Drop in a low-cost SIEM solution. Having difficulty managing the JAVA runtime in your environment ... err ...let's leave that one alone for now. You get the idea.

One of the biggest transgressors in this space is the Identity and Access Management tools in an enterprise. Since the problem is so challenging, enterprises tend to use multiple tools to solve niche, and timely, issues. What's left over is a patchwork of several different IAM tools, identity stores, and rights-management consoles.

The real problem with ad-hoc

The real problem with ad-hoc isn't there are way too many devices, servers, systems, and tools to keep updated and functional. Yes this is definitely a problem, but not the problem, in my opinion. The biggest problem is one of resources. Resources - we're talking about people here. Human beings need to sleep, eat lunch, hang out at the water cooler and take bio breaks. Humans who spend their time trying to make a few tools play nice are really wasting a lot of time...

The challenge of ad-hoc security is that you end up leaving behind a wake of poorly operationalized hardware, software and processes. This turns into a black hole for your people's time, and I don't have to tell you that this creates opportunities for attackers.

The realization

The unfortunate end-result of ad-hoc security, then, is decreased security. You're not really reducing risk over the long-haul but rather increasing it, due to the increased complexity, resource drain, and low levels of inter-operability. It makes perfect sense then that CISOs who don't take a pre-planned approach feel like they're forever on a hamster-wheel and are never getting anywhere in spite of superhuman efforts.

The better approach

Many of you CISOs and security leaders have already discovered and are implementing program-based security measures. You start by defining a business-aligned security strategy, which pre-plans the 'big picture' approach you will take. You set out the high-level guidance, and set timelines and try to manage projects with the understanding that things come up - but you can be ready for them.

This doesn't mean you suddenly stop tactical security measures - you just try to avoid ad-hoc situations which have you dropping in processes and technologies which don't fit in with your long-term goals and strategy. This isn't entirely difficult, but takes having that strategy first!

As always, I look forward to your replies, comments, suggestions and experiences.

Tackling 3rd Party Risk Assessments Through a 3rd Party

In the enterprise, sometimes absurd is the order of the day.

Earlier this week I ended up in a conversation with a colleague about 3rd party risk. We started talking about the kinds of challenges his organization faced, and as the leader of the 3rd party risk program what he's up against. As it turns out when the organization set out to tackle 3rd party risk a slight mis-calculation was made. Long story short, his group has over 100+ vendors to manage in terms of 3rd party risk. That's 100+ vendors that interact with the network, the data, the applications, the people, and the facilities his enterprise has.

His team is staffed by a whopping 3 people, including him. To put this into perspective, and given that there are 250 business days a year, it means his team needs to complete 50 reviews per analyst. With 250 total days to work with, that means that they can spend a maximum of 5 days per 3rd party. Of course, we're not counting vacation days, sick days, or snow days. We're also not counting travel to/from sites to actually do investigative work, or the time it takes to do an analysis, debrief, or any of that.

This started to unravel in my mind, pretty quickly. I pressed my colleague for an answer to how he could possibly achieve any measure of compliance and completeness, to which he answered: "We outsource the evidence gathering to a 3rd party".

My head exploded.

I'm not saying it doesn't make sense, or that there are very many real alternatives - but you have to know how crazy this sounds. They've outsourced the fact-finding portion of 3rd party risk assessments to a 3rd party. BOOM

The truth is that there is a lot that he was doing behind the scenes here which made this a little easier to swallow. For example, a standard questionnaire was developed based on a framework they developed and approved internally which minimized the amount of 'thinking' a 3rd party assessor had to do. Each category of required controls had a gradient on which the 3rd party being assessed was graded, and there was really very little room for interpretation. Mostly.

If you think about it, I'm confident that there are many, many enterprises out there with this minor challenge. Every enterprise does business with at least dozens, on average with hundreds of 3rd parties to varying degrees. From your outsourced payroll provider, to the company that shreds your documents once a week, to the company who sends the administrative assistant who sits at their desk and answers calls and surfs Facebook all day. Every enterprise has a vast number of 3rd parties which need to be assessed - and risks identified.

While I'm definitely not crazy enough to think companies should only handle this with internal, trusted employees, I'm not completely convinced hiring out to a 3rd party is that fantastic of an idea either. There is so much to consider. For example, if that 3rd party assessor misses something, are they liable, or does that fall to your company? Ultimately in the court of public opinion - this is a trick question. The answer is always you.

I suppose the long and short of it is that enterprises have little choice but to use a 3rd party to help them manage 3rd party risk. But then the only question is - do they assess that 3rd party which will be doing the 3rd party risk assessments for unnecessary risk? It's enough to make your head spin, I know it gave me a headache just thinking about it.

What do you think the mature 3rd party risk assessment looks like? Do you have leading practices you could share? Contact me as I'd like to share them with our peers, and others who are struggling with this task right now.

CZ Solution Ltd. signed samples of Xtreme Rat, Zeus, Spy-Net, Gh0st, BozokRAT and other

Here are all samples (+ more) mentioned in this post by Fireeye : The Little Signature That Could: The Curious Case of CZ Solution"
All files are digitally signed with a "CZ Solutions" certificate making it easy to create a Yara or ClamAV signature.

A few Zeus samples seem to be still beaconing. Most are sinkholed.
The certificate is now revoked by VeriSign.



Download. Email me if you need the password (new link)

File Information

Listed by Fireeye 
  1. Xtreme Rat_78CED3B6C04D372CE10B6B8606B3B747 78ced3b6c04d372ce10b6b8606b3b747
  2. Spy-Net 2.6_6A56F6735F4B16A60F39B18842FD97D0 6_6A56F6735F4B16A60F39B18842FD97D0
  3. Xtreme Rat_7C00BA0FCBFEE6186994A8988A864385.msg msg 7c00ba0fcbfee6186994a8988a864385
  4. XtremeRAT 3.5 Private _2E776E18DEC61CF6CCD68FBACD55FAB3 2e776e18dec61cf6ccd68fbacd55fab3
  5. XtremeRAT 3.5 Private _BD70A7CAE3EBF85CF1EDD9EE776D8364 bd70a7cae3ebf85cf1edd9ee776d8364
  6. XtremeRAT 3.5 Private_0BE3B0E296BE33903BF76B8CD9CF52CA 0be3b0e296be33903bf76b8cd9cf52ca
  7. XtremeRAT 3.5 Private_7416EC2889227F046F48C15C45C102DA 7416ec2889227f046f48c15c45c102da
  8. XtremeRAT 3.5 Private_BE47EC66D861C35784DA527BF0F2E03A be47ec66d861c35784da527bf0f2e03a
  9. XtremeRAT 3.5 Private_C27232691DACF4CFF24A4D04B3B2896B c27232691dacf4cff24a4d04b3b2896b
  10. XtremeRAT 3.5 Private_E79636E4C7418544D188A29481C100BB e79636e4c7418544d188a29481c100bb
  11. Zeus_9C11EF09131A3373EEF5C9D83802D56B 9c11ef09131a3373eef5c9d83802d56b
  12. Zeus_DCD3E45D40C8817061F716557E7A05B6 dcd3e45d40c8817061f716557e7a05b6

Additional (mix of RATs and Trojans)

  1. 2D186068153091927B26CD3A6831BE68 2d186068153091927b26cd3a6831be68
  2. 4A997E3395A8BB8D73193E158289F4CE 4a997e3395a8bb8d73193e158289f4ce
  3. 7E92A754AAAA0853469566D5DBF2E70C 7e92a754aaaa0853469566d5dbf2e70c
  4. 9CFD17C48FC0D300E4AA22E2C8C029D6 9cfd17c48fc0d300e4aa22e2c8c029d6
  5. 37FEE821695B664EBE66D55D8C0696F2 37fee821695b664ebe66d55d8c0696f2
  6. 445C22E94EAB61B3D4682824A19F8E92 445c22e94eab61b3d4682824a19f8e92
  7. 819B4C40F56F69C72E62EF06C85EA3E1 819b4c40f56f69c72e62ef06c85ea3e1
  8. 947C21CB8E28B854FF02C2241399A450 947c21cb8e28b854ff02c2241399a450
  9. 2859089CC3E31DA60C64D56C416175E2 2859089cc3e31da60c64d56c416175e2
  10. A9EE1BF62DEE532BE2BE217D3E4A8927 a9ee1bf62dee532be2be217d3e4a8927
  11. AC87BC7DD4B38FA3EBA23BF042B160CE ac87bc7dd4b38fa3eba23bf042b160ce
  12. B953FD2B3D5C10EC735681982D3C6352 b953fd2b3d5c10ec735681982d3c6352
  13. BD5188031BB8EB317FB58F0A49CCBF9C bd5188031bb8eb317fb58f0a49ccbf9c
  14. D7CF30E3DBFD32A1D1E38CEE464EC6A6 d7cf30e3dbfd32a1d1e38cee464ec6a6
  15. E1AFC706C8C96FACEDB6CB62E6CBFD2D e1afc706c8c96facedb6cb62e6cbfd2d
  16. Gh0stB_7A26BBD7B5942B49FC0A9CB7268BD030 7a26bbd7b5942b49fc0a9cb7268bd030
  17. SpyRat_E0B0BBA2F6399B0577C37E2A3BC3390A e0b0bba2f6399b0577c37e2a3bc3390a
  18. Zeus_0D8F9C5898596251233C3FD1DCB34161 0d8f9c5898596251233c3fd1dcb34161
  19. Zeus_7A6BBC32868A9F776452355F909F95D6 7a6bbc32868a9f776452355f909f95d6
  20. Zeus_7CD6C4A6103F23858C7ED047391F1D3B 7cd6c4a6103f23858c7ed047391f1d3b
  21. Zeus_52BE0408084F536E42FEB7C57F521592 52be0408084f536e42feb7c57f521592
  22. Zeus_5746DD569623431BA41A247FA64847D7 5746dd569623431ba41a247fa64847d7
  23. Zeus_A79089B5E6744C622D61BEFA40AF77D3 a79089b5e6744c622d61befa40af77d3
  24. Zeus_E2190F61B532BD51E585449BAAE31BC1 e2190f61b532bd51e585449baae31bc1
  25. Zeus_F76A509FEE28C5F65046D6DC072658B2 f76a509fee28c5f65046d6dc072658b2

Compliance and Security Seals from a Different Perspective

Compliance attestations. Quality seals like “Hacker Safe!” All of these things bother most security people I know because to us, these provide very little insight into the security of anything in a tangible way. Or do they? I saw this reply to my blog post on compliance vs. security which made an interesting point. A point, I dare say, I had not really put front-of-mind but probably should have.

Ron Parker was of course correct…and he touched on a much bigger point that this comment was a part of. Much of the time compliance and ‘security badges, aka “security seals” on websites, aren’t done for the sake of making the website or product actually more secure … they’re done to assure the customer that the site or entity is worthy of their trust and business. This is contrary to conventional thinking in the security community.

Think about that for a second.

With that frame of reference, all the push to compliance and all the silly little “Hacker Safe!” security seals on websites make sense. Maybe they’re not secure, or maybe they are, but the point isn’t to demonstrate some level of absolute security. The point is to reassure you, the user, that you are doing business with someone who thought about your interests. Well…at least they pretended to. Whether it’s privacy, security, or both… the proprietors of this website or that store want to give you some way to feel safe doing business with them.

All this starts to bend the brain a bit, around the idea of why we really do security things. We need to earn someone’s business, through his or her trust. The risks we take on the road to earn their business …well that’s up to us to worry about. Who do you suppose is more qualified to make the assessment of ‘appropriate risk level’ – you or your customers? With some notable exception the answer won’t be your customers.

Realistically you don’t want your customers trying to decide for themselves what is or isn’t appropriate levels of security. Frankly, I wouldn’t be comfortable with this either. The reality behind this thinking is that the customer simply doesn’t know any better, typically, and would likely make the wrong decision given the chance. So it’s up to you to decide, and that’s fair. Of course, this makes the assumption that you as the proprietor have the customer’s interests in mind, and have some clue on how to do risk assessments and balance risk/reward. Lots to assume, I know. Also, you know what happens when you ass-u-me, right?

So let’s wind back to my point now. Compliance and security seals are a good thing. Before you pick up that rock to throw at me, think about this again. The problem isn’t that compliance and “security seals” exist but that I think we’re mis-understanding their utility. The answer isn’t to throw these tools away and create something else, because that something else will likely be just as complicated (or useless) and needlessly waste resources on solving a problem that already is somewhat on its way. Instead, let’s look to make compliance and security seals more useful to the end customer so you can focus on making that risk equation balance in your favor. I don’t quite know what that solution would look like, yet, but I’m going to investigate it with some smart people. I think ultimately there needs to be some way to convey the level security ‘effort’ by the proprietor, which becomes binding and the owner can be held liable for providing false information, or stretching the truth.

With this perspective I think we could take these various compliance regulations and align them with expectations that customers have, while tying them to some security and risk goals. This makes more sense than what I see being adopted today. The goal isn’t to be compliant, well, I mean, it is … but it’s not to be compliant and call that security. It’s to be compliant as a result of being more secure. Remembering that the compliance thing and security seal is for your customers is liberating and lets you focus on the bigger picture of balancing risk/reward for your business.

What do you think? Am I totally off my rocker?

Critical Infrastructure as the Next "Cyber War"

I'm tired of reading headlines that say stuff like "It's [cyber] the next war!" because not only are they spreading FUD (fear, uncertainty, doubt) but if this was really the case we [as Americans] would already have "lost".

One of the things the FUD-sters like to ballyhoo about is the nation's critical infrastructure and how our power plants, water treatment facilities and chemical processing plants will be [or already are] targets for foreign nation states in a sneaky digital assault. News flash - this has been going on for some time, and while it's crystal clear to anyone paying attention that the nation's critical infrastructure is in a seriously neglected state when it comes to security - this likely isn't America's biggest problem.

Let me be clear, I believe the power grid, water supply, and other things including our beer manufacturers are in dire need of a security overhaul. We've been letting security get derelict for so long, the state of things is not good. The truly frightening part isn't knowing that things are horribly wide-open ... no, it's realizing that it would take a full stop of things we cannot live without like our power grid for several days (weeks maybe?) to fix some of these issues.

In a podcast conversation with Patrick Miller of NESCO and EnergySec way back in September 2012 we talked about the critical state of things. He enlightened me as to why the energy providers aren't just jumping up and "fixing it" like people are demanding. For example, the issues the power grid has aren't fixed by applying the equivalent of a Windows patch. Many of these issues require deployment of new hardware into the electricity transmission system - which means shutting down power to huge swaths of the grid for extended periods of time. We're not just fixing a buffer overflow here, as in many cases the 'hack' is as simple as plugging in an old serial cable into a port and getting unauthenticated access to the piece of equipment. This is the really scary, systemic and architectural type of security failure that takes a generational change to remedy - because the lifespan of some of this gear is now 3-5 years like in corporate America, but rather 10-25 years in some cases.

While raising awareness is almost always good, more FUD like we are seeing in the mainstream media isn't helping anyone except those looking for clicks. Let's face it, we need a strategy, not knee-jerk reactions and sensationalism. On the other hand ... if "Kamikaze Panda" (see what I did there?) were to decide that China is going to attack America's infrastructure and try and cripple us ... I'm willing to bet we could just do the same right back. Zero-sum game, in my opinion.

What is needed is a holistic review and re-engineering... not patches. The challenge of course is that first we need to phase out this equipment without disrupting businesses and life for citizens. Maybe the "bad guys" will do this for us, or more than likely we'll experience a failure not related to OMG HACKING and that will bring about security improvements - but more as a side-effect than as a goal. I'd like to say I'm optimistic...but the realist in me says we'll see more bemoaning and critical failures before someone antes up the time, money, and resources to revamp the nation's critical infrastructure.


Of Wikipedia and vandalism.

Wikipedia is regarded as a bastion of factual accuracy and impartiality.

If you have no idea what Wikipedia is, please step blinking into the sun and let me explain:
It's an online encyclopaedia that anyone can contribute to. Literally anyone. There are no pre-requisites, no background checks and exactly one hoop to jump through: bothering to post the edits.

Fantastic idea isn't it? A platform for the entirety of human knowledge to be collected in a single shining pantheon, stripped of journalistic bias and sensationalism, and laid bare for all to marvel at. Enshrining almost 60 times more information that the Encyclopaedia Britannica. A beacon of knowledge and wisdom through collaboration and communal spirit!

Except this is the internet, a place which at times can be a wretched hive of scum and villainy.

From Wikipedia:
Vandalism is any addition, removal, or change of content, in a deliberate attempt to compromise the integrity of Wikipedia. Examples of typical vandalism are adding irrelevant obscenities and crude humor to a page, illegitimately blanking pages, and inserting obvious nonsense into a page. 
Wikipedia has an entire team and comprehensive guidelines for dealing with vandalism.
As of April 2014, there were 4,500,000 articles on Wikipedia. That's potentially 4,500,000 blank canvases for anyone with the inclination and an email address to put their mark on. Repeated transgressions will result in the user or their IP being banned from editing anything on Wikipedia. This is fine for Vandal A sitting at home trolling, but becomes a problem when an entire organisation's connection is blocked. They don't like to, but Wikipedia can block an entire IP range if the need arises. Jobs have been lost due to irresponsible Wikipedia edits (in Government, no less) — there are very real risks.

Here at Smoothwall, we've had more than one request for the ability to make Wikipedia read only in an effort to prevent this issue getting that far. Tomorrow this goes live and is in a similar vein to our previous work on Facebook and Twitter, albeit a little more niche. It's also not a blanket on/off switch, it's applicable the same way as any policy is — to whomever, whatever and whenever you like.