Risk
2/14/2012
03:32 PM
Connect Directly
RSS
E-Mail
50%
50%

4 Disaster Recovery Tips For SMBs

Think your SMB can't afford to prep for an IT disaster? Learn from the CIO of Granite Rock, located on the San Andreas Fault--where an earthquake isn't just possible, it's probable.

Securing The Super Bowls Of Sports
Securing The Super Bowls Of Sports
(click image for larger view and for slideshow)

If your CIO doubles as your CFO, you might be a small or midsize business (SMB).

Steve Snodgrass fills both roles at Granite Rock, a 600-person construction supplier. The CIO/CFO, like a lot of his SMB peers, works with a tight budget, a downsized IT staff, and increasing requests from the business. "We're what I would call a classic midmarket company," Snodgrass said in an interview.

For some SMBs, that mix means cutting corners on things that have a blurrier link to the bottom line, like disaster recovery (DR) planning. Yet Snodgrass keeps DR top of mind because, well, he has to--Granite Rock operates on the San Andreas Fault, where an earthquake isn't just possible--it's probable. "One of the challenges for us as a company is to have a disaster recovery plan that works and is affordable," Snodgrass said.

Snodgrass and Granite Rock began facing that challenge back in 2000--largely by accident--when the company decided to outsource its enterprise resource planning (ERP) system to WTS, which is now part of Velocity. The reason? The Bay Area firm was dealing with a dot-com talent drain. A full backup and recovery plan came about over time as its outsourcing decision evolved. Today, Granite Rock's ERP system is hosted in Seattle and fully recoverable from another secure site in Denver should anything go wrong. If disaster strikes in San Francisco--or Seattle, for that matter--Granite Rock can continue to pay employees, bill customers, and keep critical operations running.

[ Intellectual property and mobile top the list of SMB security concerns. To learn more, see Top SMB Security Worries: Intellectual Property, Mobile. ]

Whether or not you're in a high-risk area, Snodgrass's approach offers some DR wisdom for fellow SMB IT pros to consider in their own organization.

1. Become a pragmatist. Granite Rock doesn't have the budget or IT staff to ensure that every application and system is fully recoverable, so Snodgrass doesn't bother trying to achieve 100% readiness. Recovering the ERP platform is priority one, so that's where he and his team has put its focus over time. Granite Rock does some less comprehensive DR planning for other important applications--its Microsoft Exchange server, for example--and it makes educated decisions about which areas to ignore. An earthquake would knock out the weighing systems Granite Rock uses when customers place orders for tons of rocks--but Snodgrass isn't losing sleep over that. The wide-area networks those systems rely on would also be down, so recovery is moot.

"Redundancy wouldn't get you anything," Snodgrass said. "We take a pragmatic approach: What are systems you can't afford to live without, and what are systems you could live without?"

2. Lose the cloud fear.Snodgrass is quick to acknowledge that his company's DR readiness began somewhat serendipitously. But the decision to move a business-critical application offsite was key; fellow execs that have shunned cloud platforms for security or other reasons. Snodgrass doesn't think those fears are unfounded, but notes that moving to hosted platforms can help IT pros create a DR plan without separate costs. "We embrace it," Snodgrass said. That doesn't mean he does so with a blind eye--it's just that the benefits outweigh the risks. "Are there security and trust issues? Absolutely."

3. Stop fretting over ROI. When it comes to proving a return on his IT investments, Snodgrass is in a unique position: because he's also the CFO, he is, at least in part, proving ROI to himself. Yet when it comes to DR, Snodgrass thinks SMBs should become less obsessed with ROI in the traditional sense. "One of the major flaws of the IT industry is that there aren't a lot of solutions that have a tangible return," Snodgrass said. That's a problem if you're making a financial case for DR in your organization--a case Snodgrass said will likely be met with skepticism by the CFO and other stakeholders. Instead, he advocates a different approach: Describe your DR plan as an insurance policy.

"There's no rate of return on insurance," Snodgrass said. "If you don't have a [disaster] that's insured, it's just an ongoing cost to the business." And yet when something does go wrong, the uninsured business might soon be out of business.

4. Put the plan through its paces. The most common DR pitfall in Snodgrass's view--aside from ignoring it entirely--is to invest in a plan and then not test it. "It's one thing to have a disaster recovery plan; it's another to know that it actually works," Snodgrass. That means testing it in simulated disaster conditions. Granite Rock, for example, practices recovering and restoring its offsite tape backups so that the team isn't trying the somewhat laborious process for the first time in an actual disaster scenario.

Equally important: Testing should be an ongoing process, not a one-time task. The reason is simple: "It's a moving target," Snodgrass said. "IT is always adding services, and the business is always demanding services. That's a real challenge for a midmarket company."

IT's spending as much as ever on disaster recovery, despite advances in virtualization and cloud techniques. It's time to break free. Download our Disaster Recovery Disaster supplement now. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Bprince
50%
50%
Bprince,
User Rank: Ninja
2/19/2012 | 5:47:13 PM
re: 4 Disaster Recovery Tips For SMBs
To that point Tony, here are some NIST guidelines for moving to the cloud securely:
http://www.nist.gov/customcf/g...
Brian Prince, InformationWeek/Dark Reading Comment Moderator
tonys3kur3
50%
50%
tonys3kur3,
User Rank: Apprentice
2/16/2012 | 7:00:05 PM
re: 4 Disaster Recovery Tips For SMBs
Great information. I am particularly fond of #2. In my opinion, the cloud is the great equalizer that levels the playing field for SMBs. An article I read recently (http://www.pcworld.com/article... spells out some of the benefits of cloud-based tools for SMBs ranging from security, to cost, to productivity. In 2012, I think it is virtual suicide for an SMB not to embrace the cloud.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.