There was a story on the front page of FoxNews.com this morning about the dangers of public wifi. (Click here to read) It's actually a pretty good story for the masses. They however did not address some of the quickest things you can do when traveling with mobile devices (laptops, PDA, smartphones, etc.) to improve security.
Change your firewall settings from "Private", "Home Network", "Work" or other settings to "Public Network". This automatically enables a stricter set of access restrictions which will help deter people from getting access to your network
Disable automatic Bluetooth pairing. This will keep someone from synchronizing with your system without your explicit approval.
Turn off any network sharing or media sharing while you are mobile. These protocols are ripe for exploitation and your device is broadcasting to the world "I have lots of open doors…come hack me!"
Keep your Anti-Virus definitions up to date. Even when on vacation, log in to a network and update your AV every couple of days. New threats are added daily and having definitions a week or more out of date is asking for trouble.
Don't be cheap. If you have a mobile device and it's important enough to keep with you at all times, buy access to a mobile data plan or a nationwide hotspot network. These are typically more secure and actively monitored for nefarious behavior. Consider the monthly cost an "insurance" policy against logging into a free hotspot hosted by a hacker. (BTW…if you have Qwest DSL, the 14,000+ AT&T hotspots nationwide are now free for you to use. (click here for details). Check with your ISP for similar offers.
I could go on and on but following these 5 tips will improve your security posture while traveling. Remember, most hackers are opportunists. They're not going to spend hours hacking into a system that's somewhat secure when 5 others next to you are wide open. You just want to be more secure than the dufus with sunscreen on his nose, sitting under the Hawaiian Punch umbrella next to you. Happy Vacationing!!!!
Information Security Policy: Love Me, Hate Me
Ask any professional in nearly any trade what the secret to ensuring a repeatable process that works well is and they'll tell you…great policy/procedures/documentation. Everyone has a technique they think works better than others. Something someone discovered after completing a task multiple times, or maybe even just once. Ever wrecked a vehicle? I guarantee you don't need to do it a lot to learn how to avoid it. Why then do we continually try to reinvent the wheel when it comes to IT and our policy or procedures? We know some things work and others don't, however we never write it down. "It's all up here" we say pointing to the melon shaped object sitting atop our shoulders.
The problem is…how can we expect a process to be followed if we don't have a way to distribute it, train employees to follow it and check up on it? This is where the Love/Hate relationship begins. We love to have policy as it helps define our organization, gives us implementation guidance and sometimes even protects us. This is all fine and dandy when the policy doesn't impact our operations. When it does have a negative impact, either real or perceived, we go ballistic. We also typically loathe the process of creating policy. It tends to get bogged down in politics way too much and many we complicate the process due to one of the following...
1.) We either don't understand what a policy is and what it's used for or…
2.) We don't want to put in the effort to build an effective framework for use in the future.
Not having a firm grasp on either of these will doom your policy projects. One thing I've learned is that writing policy really is an art. It's something I've been doing for many years now and to this day I'm learning new tricks or techniques to improve the process. I'll share some of the points I've learned along the way in hopes of helping you navigate the murky waters we call policy development.
Policy has to be generic and specific at the same time. Talk about conflict of interest. You need the policy to be general enough so as leadership, technology, laws and other external forces change, your policy hopefully will still be valid and not require significant reworking. The approval process at most companies for policy which has global impact is tedious, time consuming and most importantly, POLITICAL. You want to avoid this whenever possible. So while being as general and non-committal as possible you need the policy to have some sort of bite. It needs to be clear what the general preferences of the organization are.
Policy is only a guide. It's a statement that management agrees a specific issue needs to be address and generally how they want to see it addressed. It is not a roadmap to remediation so don't try to make it one.
Policy alone isn't sufficient. It takes a full set of documentation to manage risks and have any reasonable assurance of information security and privacy. Here are the 4 basic types of documentation you need.
Policy – General accepted principals of an organization
Baselines – Standard accepted configuration for hardware and software. Deviations require risk assessment and management approval before being implemented
Procedures – Set of detailed instructions for how to implement security controls, manage changes, identify risks and remediate gaps.
Guidelines – When no specific instruction is given, use these "common sense" principles as a guide.
Policy should identify responsibility and authority. If everyone has input into every baseline or procedure that is created, you'll paralyze your organization. Policy should state who is responsible for implementing each section and what authority they have. In this mode, the server group may be responsible for creating the baseline for server hardware or OS configurations, but the application group gets to review it prior to being published in order to ensure their needs are met as well. Each organization will implement this a little differently however the main idea to remember is limit the number of people who have to sign off. Don't leave out true stakeholders but don't give groups outside of the process too much weight in the decision.
Train your users. Telling them a policy exists, find it…follow it…simply isn't enough. It shows a certain callousness on the part of the employer and more importantly would not hold up in court if you policy is challenged for any reason. If the policy is really that important to your organization then provide some training.
Review policy on a regular and frequent basis. For corporate level policy, annual reviews should suffice. For baselines or procedures quarterly might be better. Whatever schedule you choose, document this in your policy and follow it. Not reviewing policy can be as bad as not having it to begin with.
Following some of these simple guidelines will help you have some assurance of the safety of your systems when developing policy in conjunction with the things you learned about your organization during the risk assessment I spoke of in the first article in this series.
It happens every 3-5 years, especially at larger organizations. I'm talking about the switch from a centralized approach to IT and information security to a de-centralized approach. Then, a few years or leadership changes later, courses are reversed. It's an endless cycle I see regularly. So much time is wasted implementing the model of service delivery that sometimes not much service is ever actually delivered.
Why can't we pick a method and stick with it? Or better yet, blend the two so no matter who's in charge or what the analysts say, you can simply point out that we're somewhere in the middle and "leaning" one way or the other. Executives, I talking to you here. You need to think long and hard about changing the service delivery model at your organization. Is the change being called for by the organization's business units? If so, a change may actually be in order and it might stick after your departure which if current trends tell us anything will be in approximately 3-5 years. If this is simply something you want to do to put your mark on the organization, take a step back and re-evaluate.
While nobody wants to be stagnant, there is a fine line between change for improvement and revolutionary change. Now obviously I can't say one or the other isn't needed in your organization but what I can say is that sometimes we don't stop to evaluate which type of change we're making and why.
So…I know all the arguments on both sides of the centralized/de-centralized debate. Cost reductions, agility, consistency, compliance, integration, yada-yada-yada. Tell me your thoughts. Where is your organization, do you like it, want to change it? Go ahead…vent a little. You'll feel better.