Backup Essentials: A 4 part series

As many of you aware one of the topics I fancy writing about is backup and recovery. To appease that desire I've decided to write a 4 part set on what's involved in planning, picking and implementing a backup solution. While you've seen this talked about over and over again, we're at it here because it is truly important. Data loss and downtime is the same as tossing cash out the window, and most businesses can't afford it. Besides let's face it, now matter how well your infrastructure runs, Moore's law will eventually strike and it's best to be prepared.

The series starts with this introduction, an outline of what we'll be trying to accomplish. For our walk-through we will use the example of a company made up of 10 employees. Our goal will be to come up with a backup strategy to propose to this 'company', once they've accepted begin implementation, and then finish off by conducting some testing and concluding on its effectiveness. Our scenario will also involve two separate customer sites, and with machines ranging from standard Windows 7 desktops to an Exchange server and a SQL server.

Check back for the next part where we begin the planning phase. In the mean time I need to finish building up the test environment to use as screenshot materials. This should an interesting set of articles and hopefully will help some of you out there in the course of your careers.

Users and Security

I do apologize for the delay in getting a new article out. Between the power outages here in Columbus last week and the catch up work that followed the plate has been rather full. Today I started giving some thought to security, and specifically how the actions of Users can effect your policies and planning. It seems that no matter how much care and caution one puts into a great security set up, there is always one weakness to root out and that is User behavior. These beings seem to be able to defeat the greatest of security infrastructure practices and are somehow able to throw a wrench in the most finely configured of ecosystems. And so here is a bit of an overview of some thoughts on how to manage user behavior.

But how to do you prevent the user from accidentally breaching your security? It's not so much a question of control, as it is a question of influence and education. Ultimately the majority of user mistakes are due to a lack of instruction, or knowledge of good practices. It's understandable, most of these users be they internal or external customers have other things to do and have other concerns that have been given a greater priority. As the IT Engineer/Analyst/Manager it ends up falling to you to be the one that breaks this shell, and instructs them on what to do. The importance of taking the time to do this is only going to grow over time, especially since these users are now even bringing in their own devices and conducting business on them. You now not only have the possibility of company infrastructure being mucked up, but also of corporate data leaking through external devices.

How do you accomplish an educational role? It's about the soft skills here. You need to schmooze a bit with other departments and employees in order to gain their trust and cooperation. The idea of IT education needs to be sold as a value added piece, something that will ultimately save the company time and money. I find that his process is very similar to that of starting a new workout program or lifestyle change. It's best to start off just getting the first session/meeting/etc and then the next one. Once you can get a routine going the ride is much smoother, and you've accomplished an institutional change. An example of this might be to send out a weekly email newsletter and partner that with a monthly 'class'. Once you get solid practices in your users' minds you'll start to see improvements in their behavior and perhaps less security oriented incidents.

Outside of purely IT type education, you also need to make sure that policies are clear and published in as many places as humanly possible. In crafting your policies I would suggest taking heed of the manner in which intelligence agencies operate. Users should only have access to infrastructure pieces they have both 'clearance' for and a 'need to access'. This is very similar to the 'clearance' and 'need to know' principal of intelligence that is used to keep information leak to a minimum. Documentation for this principal is critical as the rest of your organization needs to understand the structure for how access is granted, as well as procedures to gain clearance when needed. Along with policies on access a proper acceptable use policy is recommended. The document should detail exactly what behaviors are frowned upon, and what behaviors are considered acceptable practice.

Lastly, and perhaps the most important piece of this is user involvement. If you want to maintain a credible IT department you need to make the users feel involved and keep them in the loop. Regular and predictable communication with as much of your organization as possible will create an environment in which users don't see the IT department as just some strange offshoot of the company that just tells them they can't do things with their system. By creating these venues of communication you'll be able to create a situation where you users aren't following described practices because you said so, but because you convinced them that they *want* to. This type of shift can only lower risk to both your data and your infrastructure.