the poetry of information security
The 451 Research group has an interesting presentation called "What is the Point of Hadoop", which includes three slides on global adoption. I've mashed them into a simple animated GIF for illustration:
Watch the cities of NYC, LA and SF shrink as countries India and China grow. Why the difference in granularity? Does this imply anything about a shift in controls and authorization (e.g. local versus remote, full-time versus contractors)?
Posted in Security.
– December 6, 2013
Symantec has unwrapped their latest speculation engine and fired a huge salvo across all our bows with a blog post titled "Linux Worm Targeting Hidden Devices". Note the crisp analysis:
We have also verified that the attacker already hosts some variants for other architectures including ARM, PPC, MIPS and MIPSEL…. The attacker is apparently trying to maximize the infection opportunity by expanding coverage to any devices running on Linux. However, we have not confirmed attacks against non-PC devices yet.
In other words, the only known attacks are on PCs. Other devices are just speculation. Given the Symantec report details, it seems quite clear the attacker is NOT TARGETING HIDDEN DEVICES.
Thank you for your attention.
Posted in Security.
– November 27, 2013
I attended a strange meetup the other night. It is one of the amazing benefits of being in San Francisco. You can go in person to meet people on the cutting edge of technology and hear their vision (pun not intended) of the future. In this case I met someone from ski.org who was game for discussing my theories about the future focus being differently-abled, from Google maps to automated cars.
Unfortunately I lack time to blog in full our discussion. In brief, here's some of what I've been speaking on lately, building upon my earlier posts, and what will be in my new book on Big Data security:
Stoplights are a stop-gap (pun not intended) measure that resulted from the inferiority of high-speed automobiles to anticipate danger. We used to be able to keep flow when traveling under 15mph. Adding a speed differential made stop-lights necessary to protect pedestrians and horses from cars, let alone protect cars from other cars; and it was a concept poorly interpreted from sailing.
We should get rid of them. But how do we do that? Automation. Once cars can anticipate other cars at speed, we don't need to stop and sit at red lights. We're smarter than the lights, but we can't see risk fast enough at high speed to get rid of them. Automation can "see" faster.
Similarly, we should stop looking at maps. Look at race cars for the face of innovation. Rally cars do not have visual displays of directions, they have audio navigation. That's what we should look towards. All we need to do is improve the confirmation or validation of automated navigation devices. Get rid of unnecessary information (e.g. no street-view, no satellite view until the last mile) and allow two-way dialog. Let's not get stuck on big screens for navigation any more than we were stuck on stop-lights for predicting risk.
Google is leading the world in these areas, especially with Kurzweil on board, so I'm hopeful we can move towards eliminating the wasteful and poorly-thought out stop-light model.
– October 31, 2013
I have had several people ask me whether I created the Windows NEIN image I tweeted the other day. The answer is yes and here is how, in three simple steps using GIMP:
Done! Here is the final result:
Contact me for the XCF image if you want to mess with it.
Posted in Security.
– October 27, 2013
People frequently ask me if I see any interesting startups in the security industry. Let me give you three examples but only because they fit an interesting trend.
Obviously there is a long history of warfare innovation leading to civilian products. What might we look for now? Today's battles are fought with information tools. And the safety of information is most pressing to intelligence organizations so they seek and develop talent who innovate in data protection. Naturally this is leading us to a new generation of utility in securing information.
We are seeing those with deep experience and exposure to very difficult problems, within the intelligence community, get an entrepreneurial bug and launch startups. Whether you trust the founders or their product is not the point of this post.
Perhaps an historic example will clarify. Sometimes when I look at fancy kitchen knives from Japan I wonder if anyone ever protested innovations that made blades too sharp, too fair, or too strong. The utility of a tool in the kitchen surely benefited from innovations derived from battle. Making dinner with a better knife doesn't mean you have to condone or even care about Samurai.
Here are three examples of companies that represent an emerging trend in creative thinking about tools we need to get better at protecting our data:
Back to the simple knife, there some interesting studies that try to explain how Japanese civilian innovations evolved out of conflict. Creative thinking relative to explicit and tacit knowledge:
– October 26, 2013
I've noticed several things in the current America's Cup finals that keep my interest. While others in San Francisco seem completely oblivious to the racing, and it's hard to drag them out and watch, I'm still excited about watching these points:
Spithill thus comes across as awkward as if forced to ask for support now from the country he has loved to hate as a sailor. In addition, despite being in America, Oracle also has a reputation for disdain towards its home country and especially the cities lived-in by Ellison. A real-estate agent just told me the Oracle CEO bought a house in SF to watch the races and immediately demanded the neighbor, an elderly lady in retirement, cut down her trees so he could get a better view. She said no at first, since they were clearly on her property. Then Oracle lawyers promptly arrived and asked her if she really, really wanted them to wipe out all her retirement money in a messy legal fight and leave her for dead. With a home team like that who needs enemies?
ETNZ, in stark comparison, has used a large percentage of funds direct (kick-started) from their government and held discussion about how the money spent will benefit taxpayers (jobs, business, trade, etc.).
Those are some of the major notes. In summary, ahead I see a sea-change in the boat-building industry and very little change in the American sailing community. Globally we'll get more efficient, faster and more fun boats of all sizes yet unfortunately this will not lead to any more American kids rushing to get into sailing.
I have a bunch more items I'm tracking but just wanted to share the biggest and most recent ones. Let me know if you have others to add or discuss.
– September 10, 2013
Several people have suggested I explain the ETNZ crash. Usually it comes up casually. I get all animated and start describing the details of the event and then people say "that's interesting, others need to hear this"…and I think why didn't the America's Cup put someone on the commentary team who actually races catamarans?
Just one source of reporting would be OK if it was amazing and insightful. Tell a few war stories, life in the trenches stuff, pepper it with math and science, and I'd be glued to the tube during the Louis Vuitton races.
Instead search the entire Internet and you will find only one video, one set of boring empty perspectives. Here it is. Notice how lame the comments are during the action at Gate 3:
The announcers mention a puff, and basically having nothing to say other than what happened after the bows dive down. Men overboard, damage on the front. Duh:
This all has to do with the pitch. The bows went down. [...] They stuffed the bows for some reason…that wave hit them.
Thank you captain obvious!
Unfortunately this is not far from the official statement language of ETNZ, as reported by Sailing World. At least they provide some detail such as shift in speed:
The team’s AC72 Aotearoa popped up onto its hydrofoils rounding the mark and then a gust of wind hit. The port (left) bow of Aotearoa buried up to the main crossbeam, reducing the boatspeed from 40 knots to 13 and flicking two crewmembers, Rob Waddell and Chris Ward, overboard. The two grinders were recovered unharmed by the team’s chase boat, but the rush of tons of water tore the port side fairing off the main crossbeam and left the crew shaken.
“In this sort of racing, the boats are incredibly powerful. You see how quickly the speed rockets up as you make the turn around the top,” said skipper Dean Barker. “We came in there with good pressure. Through the turn we were always going to pick up a decent increase in speed; I’m sure there are a few things we could’ve done better.
Dropping from 40 to 13 knots in seconds feels like what, exactly? Unless you've been on a boat that stuffs the bows into a wave it's hard to imagine. That's why an announcer should be someone who has lived the danger, experienced the excitement, and can relay the feelings to a general audience.
So allow me to try. Here is the scoop (pun not intended) on what happened and why, and what it feels like.
This kind of event is all too common in catamaran sailing. This is what failure usually looks like:
But not this:
Not yet, at least. Those crazy cats in the last photo (pun not intended) are burying their entire hull and managing to avoid pitch-pole (tripping).
So the biggest risk of crashing in catamaran racing is actually when you turn to go down wind at the windward mark. It's really quite simple and expected, which means ETNZ was about to crash in the area most likely to cause a crash.
If you've raced catamarans you simply know that when you approach the windward mark in a big wind, you might be experiencing a bowel movement as you turn the boat away from the wind. When the catamaran does not oppose or release power that builds in the sail it dives the bows. A big puff hitting ETNZ as it bore away (turned after the mark) certainly fits that equation.
But this isn't the first time a puff has hit a boat in this critical moment. Catamaran sailors know puffs happen at the windward mark all the time. So why didn't the team just handle it? Actually, like the last photo above, they did.
First of all, the wave-piercing design of the AC72, which some say look like inverted hulls, is meant specifically to allow the boat to survive a dive. From that perspective, they came out of the dive instead of crashing because they knew it could happen. Amazing risk engineering.
The announcers should have been all over the fact that a 72ft boat with wave-piercing hulls can survive a deep dive at 40knts. That was an unbelievably beautiful and planned graceful exit, unlike the Oracle incident where the boat flipped up and eventually broke apart.
Here is a clever comparison of the Oracle and ETNZ boats from CatSailingNews
The article is mostly pointing out that Oracle has been copying ETNZ to stay competitive. Notice something else, however. The bows of the two boats are both inverted and designed for wave-piercing yet still quite different. The Oracle boat appears to have far less ballast (float) than ETNZ.
Could Oracle have survived such a dive? My experience on the A-Class catamaran over four generations of design is that a clever buoyancy model in the bows makes a MASSIVE difference. Oracle, like the current platform I sail (an A3.5), looks anemic in the front end. It would likely have had a harder time even with the re-design after their crash.
This is what an announcer could have mentioned. Bow design. They also could have mentioned the effect of the T-shaped rudders, and L-shaped foils. And they could have mentioned the aerodynamics of the carbon relative to fluid density (wind above versus water below). Saying a crash is related to "pitch" simply isn't good enough.
Second, a turn in puffs and big wind is scary business because of pressure for rapid decision-making. When Barker turned the corner he made a critical error by taking the turn too tight at the wrong moment. Bad luck, perhaps you could say.
It is a lot like turning a car into a hairpin curve. You know in your mind the speed you need to stay in control as you reach the apex. But in sailing you don't get to take your foot off the gas or hit the brakes. There are no brakes. And a puff is like someone pushing your gas pedal to the floor.
Instead of smoothly turning you suddenly find a huge boost of power pushing you in a direction other than where you anticipated. Fractions of a second are all you have to decide how you're going to handle all the excess power that threatens to toss you over.
Barker could have headed up, accelerated in a straighter line to keep the bows from diving. This actually compounds the danger if it doesn't work, which I won't go into here. His team also could have dumped power from the sails by stalling them. Stalling or luffing can be very complicated to do in extreme conditions at high speed, especially as it can cause the boat to lose stability.
The bottom line is Barker had several options and he turned a surprise into a strategy by keeping the boat flat enough that he could blast out of the water with speed after a dive instead of careening sideways. Fantastic boat handling married to fantastic engineering. Sideways would have been a disaster. Here's what happened to Artemis in an AC45 race last year. Watch at 1:10
So we've covered some of the engineering and some of the boat handling (and trim) involved. What about feelings? The sensation of a pitch-pole is absolutely terrifying. It happens so fast you can barely process what is going on. Here's an ETNZ team member recollection on SailingWorld
“I’m on the forward pedestal and was holding on for dear life,” McAsey said. “I was the second guy under water, with Jeremy Lomas in front of me. I was holding on as hard as I could. It all was a blur, everything’s wet and white, you come up, there’s a bit of broken carbon around the place and we’re two guys short. From there on it was just a matter of trying to cover the two guys lost.
Exactly right. One second you're dry, flying and focused the next second you are blasted in the face by icy frothing salt-water and have no idea what is going on. The key to his story is probably the pedestal. My guess is he held that thing with a death grip as soon as the first drop of water touched his skin.
Keep in mind these sailors are the peak of professional athlete fitness. They train twice a day in the gym and have the strongest grip strength you can imagine. But things happen so fast, things get so slippery and cold, and everything can get turned around in tons of water hitting you at 40knts.
One time on my boat in a race I buried the bows so hard, so fast into the back of a giant wave that I was fired like a missile straight off the boat. I was sailing smoothly one minute and then BAM I'm three feet under water and trying to figure out which way is up.
A catamaran going from fast to slow quickly means it stops and you keep moving. There are no seat belts because you have to be able to move around. And that can mean you bounce off hard and often sharp carbon parts and line, and end up totally disoriented without vision or hearing…and dealing with the shock of rapid temperature change.
It hurts A LOT. I don't bruise, ever, but one time I hit a wave so hard the boat stopped and I slammed into the back of a razor-sharp windward foil. It gave me a giant green, blue and black bruise on my thigh for weeks. Hanging on to a pedestal is far better option than getting catapulted, washed away or sliced into pieces.
So much to talk about. This tiny little snippet of sailing in the Cup could instantly bring up a ton of background and detail. Yet the "official" and only announcers just repeated "oh my gosh" and statements of the obvious.
Where is our John Madden of sailing? Can't the organization find a seasoned and colorful catamaran sailor to fill in the commentary? I can think of so many, I have to wonder how the current announcers were chosen.
– August 29, 2013
HD Moore has been quoted extensively in an article called "3 Inconvenient Truths About Big Data In Security Analysis". I found it interesting although not quite on target. Here is a possible dose of reality for his three inconveniences. I've kept his paragraph headers the same for clarity:
1. "Big Data Isn't Magic"
HD tells us:
"People say if you have all of your data in one place, you'll magically get the security benefit. That's not true," he says.
You know what else I bet is not true? That someone actually said "you'll magically get the security benefit". Sounds like HD had to prop up a straw-man argument in order to show us a knock-out argument.
Aside from that logical fallacy, I'll discuss his more subtle point hiding behind the straw-man. Sales people are prone to making exaggerated claims.
HD is right. Finding meaningful insight in data is called a "science" for a reason. The complexity was highlighted recently at a presentation by SriSatish Ambati of 0xdata of an "open source math and prediction engine". The presentation was called "Data Science is NOT Rocket Science" and about five minutes into the presentation a heckler in the audience yelled out "What was the title of this talk? I feel like I'm about to launch a rocket."
Clearly even very intelligent and well-intentioned people are prone to overstate speed of value and ease of working with Big Data. However, this is where I disagree with HD. People are trying to market Big Data as easier than it is because they may actually believe it is NOT magic. Have you ever had a math professor say the subject is easy? They are not telling you it is magic.
To put this in perspective of other areas of science, Einstein was one of the biggest proponents of creativity and simplicity.
I know quite certainly that I myself have no special talent; curiosity, obsession and dogged endurance, combined with self-criticism have brought me to my ideas.
So if you are a company trying to sell Big Data, you are in the business of selling simplicity out of complexity. Perhaps if someone does not believe in science they would think they are being sold magic. Einstein's point, that a transformation from the complex to simple requires an investment, is pretty-much the opposite of magic.
Should everyone really have to understand how results were achieved for our results to have value? I say no. Results have to be scientific, something that can be verified independently; I don't think being unfamiliar with science means magic is the only other option.
HD himself reveals this when he calls for investment.
"So just be careful about where you invest, and make sure that if you are investing in a data analytics tool, you at least have one body sitting in front of it and you're investing just as much in people as you are in the process," he says.
At least one body? I disagree with that principle. It's too vague to have meaning. What is that person doing? Robert Pirsig's Zen and Art of Motorcycle Maintenance explores this dilemma at length but to put it briefly, some pay BMW a lot of money because they really have no idea how to build a motorcycle of their own. This does not mean they dedicate at least one body. They hire a mechanic as necessary, on demand.
So if HD had said make sure you have at least one person riding a motorcycle, ok fine I agree. Instead he seems to be saying make sure you have at least one mechanic on every motorcycle along with you as you ride it…
I do not disagree with a premise that you should invest wisely in people and process and technology to get the most benefit. Rather, I disagree that everyone has to peel back the covers on everything all the time (they instead can invest fractionally in someone else to do that for them) and…I also would like to see at least one example of someone who actually says Big Data is magic.
2. "Putting All Our Eggs In One Rickety Basket"
HD has a very good point here and takes it too far. This is the usual security professional lament to management: please verify that you can trust an environment. Put as a question: why and how should we trust any Big Data "basket"?
"We see a lot of stuff in development around big data toolkits — things like Mongo and Cassandra — and there's not a lot of security built into these tools," he says. For example, MongoDB doesn't support SSL by default, and there isn't the same level of security offered in similar tools as more established traditional relational databases. "It's actually pretty frightening how insecure these tools are by default, yet they're becoming the back-end for most of the big data services being sold today."
Not frightening. Expected. New technology is often developed with priorities higher than security. Who is really surprised to read "stuff in development" and "not a lot of security built into" within the same sentence. What is frightening is that people would use this new technology without considering the risks. To put it more clearly we can see Hadoop continue to gain popularity, despite missing familiar controls such as communication encryption, as we leverage broader risk management strategies.
"You're making these really juicy targets for someone to go after. Everyone kind of cringes when we look at some of those big password breaches in the past, but that's nothing compared to a multiterabyte data leak."
Telling executive management at some organizations that they have become a "really juicy target" might be taken as proof of success. After all, what is more successful than having assets of high value? And who said after a big password breach in the past "you know what, we should never again put our passwords in one place"?
Back to reality: First, some security controls are essentially impossible to implement in Hadoop so a business may have no choice but to move ahead after weighing risk of failure. Having no basket for eggs is in fact a worse option for some than having just one basket. I'm not advocating one basket, quite the opposite, but I'm saying there's a cost associated with zero baskets. Second, perimeters and bastions make internal communication encryption far less important. We're seeing some amazingly tight environments built because data owners know that they need a protected data lake to secure against unauthorized use. This is expensive, but it's an option that allows a really juicy target to exist. Third, data processed does not have to be sensitive (although the definition of sensitive changes dramatically in Big Data environments). The juiciness of eggs (hey, it's HD's analogy, I don't like it either) can be controlled when the environment can not.
3. "Law of Averages Says An Analytics Provider Breach Is Coming"
This is the grand finale of HD analysis, where he tells us the impact of the first two problems, and it seems to backfire.
"One thing that's almost guaranteed to happen in the next year is we're going to see one of the large providers of analytics services — whether security, log data, or something else — get breached," he says. "It's just the law of averages at this point. There's enough folks offering services who don’t necessarily know what they're doing that we're going to see a big breach."
Saying there will be a big breach within twelve months does not sound like Bernoulli's "law of averages". To me it sounds like a statement of the obvious. Almost every breach report I read indicates hundreds of breaches per year. Verizon in 2013, for example, issued a one-year report that starts with "621 Confirmed Data Breaches Studied". So if I were a betting man I would say a big breach will come in the next 30 days…ok, 24 hours.
But seriously, it seems to me that predicting a "big breach within a year" is not the kind of statement that moves anyone to react quickly on an issue. HD said above in #2 that things are "actually pretty frightening" and yet he warns we have 8,766 hours before impact?
Most people will probably hedge their bets or adopt a wait-and-see response when told they are 12 months from impact. "Put that in the budget for next year" would be a lucky result.
Perhaps more importantly HD fails to mention why anyone would be required to report a Big Data breach to the public. Unless regulated data is in these environments, or someone external is affected, then what obligation is there to make the breach "seen" by us?
The Big Data examples he provides us ("whether security, log data…") does not impact anyone external to the victim and has no legal requirement for disclosure.
Posted in Security.
– August 23, 2013
Trusted IT (or Trust for short) is a big topic this year at VMworld, especially with the recent release of Log Insight. Here is a sample of sessions related to Trust and that you can find online in the conference agenda.
Out of 590 total sessions
—
Availability (28 sessions, 13 speakers)
Security (72 sessions, 49 speakers)
Compliance (24 sessions, 6 speakers)
Data Protection (19 sessions, 6 speakers)
Availability
========
BCO1000-GD – High Availability with Duncan Epping and Keith Farkas
BCO1001-GD – Stretched Clusters for Availability with Lee Dilworth
BCO5047 – vSphere High Availability – What's New and Best Practices
BCO5065 – VMware vSphere Fault Tolerance for Multiprocessor Virtual Machines – Technical Preview
BCO5160/2 – Implementing a Holistic BC/DR Strategy with VMware – Part One and Part Two
BCO5276 – Next Generation ‘Economical’ Data Protection for Business-Critical Applications
EUC5805 – Why Delivering Cloud-based Clinical Workspaces Makes Perfect Sense for Healthcare
SEC6850 – Achieving Security Agility in the Virtual Data Center
VCM5577 – Ensuring Clinical Trial Patient Safety with vCenter Operations Management
VCM7369-S – Uncovering the Hidden Truth in Log Data With vCenter Log Insight
Security
======
GS-MON – General Session – Monday – Gelsinger GS-TUE – General Session – Tuesday – Eschenbach
EUC5143 – Is 911 a Joke in Your Network? – How VDI Can Improve Threat Response
EUC5196 – Secure Mobility – FIPS, CAC and Beyond
EUC5369 – Beaufort Memorial Hospital Enhances Patient Care with Secure Mobile Solutions
EUC5805 – Why Delivering Cloud-based Clinical Workspaces Makes Perfect Sense for Healthcare
HOL-HBD-1302 – vCloud Hybrid Service – Networking & Security
HOL-HBD-1303 – vCloud Hybrid Service – Manage Your Cloud
HOL-PRT-1306 – Catbird-Hytrust-LogRhythm – Partner Security and Compliance
HOL-SDC-1315 – vCloud Suite Use Cases – Control & Compliance
NET1001-GD – vCloud Networking and Security & NSX for VMware Environments with Ray Budavari
NET5522 – VMware NSX Extensibility: Network and Security Services from 3rd-Party Vendors
OPT4968 – US Air National Guard – DoD Private Cloud Initiative – How Virtualization Saved $45 Million in Power\Cooling and Life Cycle Management
PHC5120 – Why Hackers are Winning and What Virtualization & Cloud Can Do About It
PHC5070 – vCloud Hybrid Service Jump Start Part One of Five: vCloud Hybrid Service: Architecture and Consumption Principles
PHC5409 – vCloud Hybrid Service Jump Start Part Two of Five: vCloud Hybrid Service: Networking and Security Basics
PHC5488 – vCloud Hybrid Service Jump Start Part Three of Five: vCloud Hybrid Service: Advanced Networking and Security
SEC1003-GD – Network Security Services New Model for IPS, URL Filtering, Forensics in the SDDC with Anirban Sengupta
SEC1004-GD – Agentless Security Antivirus, Vulnerability Management, File Integrity Monitoring in the SDDC with Azeem Feroz
SEC5168 – Dynamic or Dud? Why Software-Defined Data Centers Need Dynamic Security
SEC5178 – Motivations and Solution Components for Enabling Trusted Geolocation in the Cloud – A Panel Discussion on NIST Reference Architecture (IR 7904)
SEC5253 – Get on with Business – VMware Reference Architectures Help Streamline Compliance Efforts
SEC5318 – NSX Security Solutions In Action – Deploying, Troubleshooting, and Monitoring for VMware NSX Service Composer
SEC5749 – Introducing NSX Service Composer: The New Consumption Model for Security Services in the SDDC
SEC5750 – Security Automation Workflows with NSX
SEC5755 – VMware NSX with Next-Generation Security by Palo Alto Networks
SEC5889 – Troubleshooting and Monitoring NSX Service Composer (and Partner) Policies
SEC5894 – Deploying, Troubleshooting, and Monitoring VMware NSX Distributed Firewall
SEC5891 – Technical Deep Dive: Build a Collapsed DMZ Architecture for Optimal Scale and Performance Based on NSX Firewall Services
SEC6850 – Achieving Security Agility in the Virtual Data Center
STP1015 – Is Your Data Center Smart? – Improving the Security and Performance of Virtualized Environments through a Data Center Operating System
STP1018 – Secure and Monitor Sensitive Assets in Your Virtual Infrastructure
STP1020 – Solving the security and compliance challenges of a true Enterprise cloud
TEX5667 – Case Study: VMware vCloud Ecosystem Framework for Network and Security Enables Network Services Virtualization
VCM6065 – How to Manage Security Levels and Infrastructure to Provide IaaS / PaaS / SaaS Services Based on a Single Virtual Infrastructure
VSVC1007-GD – Platform Security with Mike Foley
VCM1005-GD – Log Insight with Steve Flanders
VCM4445 – Deep Dive into vSphere Log Management with vCenter Log Insight
VCM4528 – Tips and Tricks with vCenter Log Insight (NEW!)
VCM5034 – Troubleshooting at Cox Communications with VMware vCenter Log Insight and vCenter Operations Management Suite VCM7369-S – Uncovering the Hidden Truth in Log Data With vCenter Log Insight
Compliance
=========
SEC5775 – NSX PCI Reference Architecture Workshop Session 1 – Segmentation
SEC5820 – NSX PCI Reference Architecture Workshop Session 2 – Privileged User Control
SEC5837 – NSX PCI Reference Architecture Workshop Session 3 – Operational Efficiencies
BCO5829 – Drying Out After Hurricane Sandy: Leveraging vCloud Director and Other Cloud Enablement Tools for Simpler, Faster DR Operations
EUC5196 – Secure Mobility – FIPS, CAC and Beyond
OPT5887 – How Does VMware Uniquely Enable Leaders in Healthcare Electronic Medical Records to Improve Quality of Care and Meet Unique Industry Requirements
HOL-SDC-1315 – vCloud Suite Use Cases – Control & Compliance
PHC5679 – Protecting Enterprise Workloads Within a vCloud Service Provider Environment
SEC1001-GD – Activity Monitoring Visibility into Users, Applications for Compliance Troubleshooting with Mitch Christensen
SEC1002-GD – Compliance Reference Architecture: Integrating Firewall Antivirus, Logging IPS in the SDDC with Allen Shortnacy
SEC5253 – Get on with Business – VMware Reference Architectures Help Streamline Compliance Efforts
SEC5428 – VMware Compliance Reference Architecture Framework Overview
SEC5589 – Healthcare Customer Case Study: Maintaining PCI, HIPAA and HITECH Compliance in Virtualized Infrastructure
VCM4838 – Automating IT Configuration and Compliance Management for Your Cloud
Data Protection
============
BCO1002-GD – Data Protection and Backup with Jeff Hunter
BCO4756 – VMware vSphere Data Protection (VDP) Technical Deep Dive And Troubleshooting Session
BCO5041 – vSphere Data Protection – What's New and Technical Walkthrough
BCO5160 – Implementing a Holistic BC/DR Strategy with VMware – Part One
BCO5162 – Implementing a Holistic BC/DR Strategy with VMware – Part Two
BCO5276 – Next Generation ‘Economical’ Data Protection for Business-Critical Applications
BCO5851 – VMware Backups That Work – Lessons Learned and Backup Performance Tuning Based on Extensive VADP Benchmark Testing
BCO5855 – Leveraging Advanced Storage Capabilities To Meet Today’s Virtual Environment SLAs
HOL-SDC-1305 – Business Continuity and Disaster Recovery In Action
PAR6413 – Capturing the Backup and Disaster Recovery Opportunity with VMware
PHC5679 – Protecting Enterprise Workloads Within a vCloud Service Provider Environment
Posted in Security.
– August 23, 2013
This is the third incident, as far as I can tell. The first incident, spying on competitor designs, resulted in a penalty for Oracle. The second incident was when Oracle tried to use the Artemis incident to force competitors to change their design, and was rebuffed. Now Oracle is accused of yet another design-related incident.
Skipper Max Sirena of Italy's Luna Rossa is the latest America's Cup competitor to accuse defending champion Oracle Team USA of cheating in what potentially could be one of the biggest scandals in the regatta's 162-year history
As I've said before it's obvious Oracle's design is inferior. Team New Zealand has out-innovated the American team and Oracle is cheating to try and catch up.
There is irony in these incidents. The Oracle captain recently said in an interview that their design changes were done, they were focused on sailing. In fact, he emphasized that making design changes at this late date could interfere with his ability to focus and become a better sailor; arguing that design change could actually have a trade-off or hurt their chances.
There also is a question of what Team Oracle management is going to do about being caught cheating on design, yet again. Here's how their CEO has responded:
"I don't think it's right that if a few people break a rule on a team of 130 people, that the whole team gets branded as cheats," Coutts said in his first public comments in the week since Oracle announced that it was forfeiting its overall championships from the first two seasons of the ACWS after the violations were discovered.
[...]
Coutts used the latest performance enhancement drug scandal in Major League Baseball as an analogy, saying that if certain players were suspended, "does that mean the whole team are cheaters? I don't think that's right to draw that conclusion."
That is an interesting ethical question for the CEO to pose. I would rather hear him say "I take responsibility for the actions of my team" or "I am in charge and this is unacceptable, this will not be tolerated and will not happen again."
Instead, we hear that Team America is going to play victim to their own team? In risk management terms, that should be a giant red flag. This is precisely why the U.S. government moved forward the Sarbanes-Oxley regulation. Too many CEOs had claimed they had no idea about fraud under their watch and objected to "the whole team" being branded cheaters.
It is possible that some rogue member of the team was acting independently. That seems unlikely given that it is not an isolated incident. It also seems unlikely, given the response from the CEO is to play victim and tell other teams to stop pointing fingers.
I don't think it's right that other teams should use this as an orchestrated PR campaign to slander another team when there's a jury process going on and the facts haven't been established.
Strange perspective. Cheating doesn't require PR orchestration. Fraud doesn't require PR orchestration. When it's discovered, when an investigation begins, the expectation and the norm is negative press. It would require orchestration to do the opposite, for competitors to be complimentary and supportive; to say "don't judge" or "don't blame management, everyone has bad apples".
More to the point when the CEO of UCLA tried to say that patient privacy breaches were the result of isolated staff it turned out to be exactly the opposite. A sting operation by Farah Fawcett and her Doctor proved that management wasn't taking responsibility. Widespread and systemic security failures continued despite firing "isolated staff". Eventually outside investigators were brought in and not long after the state of California passed two new laws to hold executive management accountable.
The sad fact is Team Oracle management is not talking about how they abhor cheating or how they will stake their reputation on a fair game. They are most likely trying to cheat their way through a design failure. They've tried spying, they've tried blocking the other designs, and now they're accused of making unauthorized changes.
After decades of Americans trying to hold top management accountable for the actions of their entire team, it is the statements by the CEO of Team Oracle that are making America look bad.
Coutts admitted last week that someone with the syndicate illegally placed weights in the bows of three 45-foot catamarans without the knowledge of the skippers or management. One of the boats was loaned to Olympic star Ben Ainslie, who is sailing with Oracle Team USA this summer in hopes of launching a British challenge for the 35th America's Cup.
Coutts said then that it was "a ridiculous mistake" because the weights "didn't affect the performance." Oracle forfeited its results from the four ACWS regattas in question, and its two overall season championships.
Someone made a mistake. Don't blame the team. There was no real need to cheat. These are not phrases that engender trust. Quite the opposite, they lead to distrust of management.
Coutts' risk approach does not sound far from what the utility industry once used to skirt regulations — hire a "designated felon" to the team. A CEO could claim she/he was "without the knowledge" of violations and basically pay someone else to go to jail or take the fall on their behalf.
– August 16, 2013
Recent Comments