Screen Savers

Recently we implemented mandatory screen savers for all PC's at work. There were a few systems that we had to exempt from the policy due to legitimate business need. These systems are in secured areas and have limited access by only a few users. The rest of the systems received the policy early last week.

The decision was made to use a common Text based screen saver and allow the user to change the text but not theme of the screen saver. We sent out several messages informing the users of the change and when it was scheduled to happen. The day that it went into effect you would have thought that we took away their PCs and replaced them with an etch-a sketch. All of a sudden no one could work because they would be in the middle of intense computation and all of a sudden the screen saver would kick in and they would lose all of their work. In reality the problem was that they either didn't like having to reenter their passwords or they were upset because they couldn't change the screen saver to something else.

The manager of the help desk is also the one who sent out the emails explaining everything that was going to happen. She is also the one catching the wrath of many of the users. She has been bombarded with calls, emails and visits by people who complain that they can't work or extremely upset because they no longer have pictures scrolling across their screen when the screen saver kicks in. The sad thing about this is that in the past this has worked. A new policy is put into place, the users whine and cry, the policy is rescinded. Fortunately things are different now. Management realizes that the policies have to be put into place whether the users like it or not.

Often management caves to the whims of the user without taking the bigger picture into account. I've seen this in many companies that I've worked for and have heard stories of many others. Management wants the users to be happy, which is important, and security wants them to be secure, which also is important. The important thing is to reach a "happy medium". The point where users are happy and can actually do their job, yet the systems and network are secured. In a company that has a history of allowing the users to make policy decisions it can be a challenge to reach this happy medium.

There are several steps involved in getting past history and to where the company needs to be. It starts with education.

• Management needs to be educated in the need to find balance. They need to understand that users want convenience, ease of use and control over their systems (ability to add programs, manage how it looks and feels, etc).
• Users need to be educated. They are not concerned, at least by default, about security. They push back on most anything that changes how they are able to control their systems. The problem with this is that users are not "secure by default". They don't understand how to secure a system or why "that cool screen saver" they downloaded may just be the back door into the network. They need to understand "WHY" security is important and how it affects them personally.
• Communication of changes MUST happen well ahead of the actual change. All affected parties need an opportunity to think about this and how it may affect them and then ask questions. Maybe they need time to work out new processes to minimize the impact on their jobs without compromising security. This step does not happen just by sending out an email telling that the change is coming. The communication needs to tell them to think (kinda sad isn't it?). Unfortunately many people don't think by default.
• Feedback from users needs to be taken into account to work around issues that may come up. An example from our screen saver issue is we have a few systems that are used by our call centers to view call queues. That is all these systems do so we need to exempt them from the policy while still ensuring that they are secured. Remember, we have to balance security with usability.
• IT/Security has to remember that they do not have the final say on what, when, where, how or why these things happen. Their job is to come up with solutions to problems and convince the company why this is what we need and then work with the business units to make the solution as painless as possible.

Staying Fresh

Rebecca Herold has a good post on her blog about keeping your security, privacy, or compliance program fresh. She makes a good analogy between how your program can slowly become ineffective over time due to lack of attention and how running shoes can slowly become less effective over time. I can't relate to that because I bought my new running shoes in April and they haven't had as many miles put on them as hers gets in one day. Try as I may I just can't get into a running frame of mind.

I've seen fist hand how programs start strong and slowly erode or die over time. They don't get the TLC that they need to stay alive. They are put in place to satisfy a audit or a new boss and then they end up in a closet or on a shelf only to be given a passing glance from time to time.

I recently did a review and update of security policies for a company. What they had was between 4 and 8 years old. They had been created (mostly just changed the company name on a template) and filed away. As I looked over them I started asking questions about them. Is this really what is done? Where is the ??? to back this policy up? Where are the ??? that this policy states is happening? Blank Stares and hidden smiles met me. They weren't being followed. They were just there to satisfy a whim.

These documents and programs are living. They are meant to be reviewed regularly, followed consistently and changed as needed. They are not static documents that are just to satisfy an audit. When I create a policy program or a security plan I make sure to write it in such a way that those who are entrusted with it know that it is a living document. I include regular review schedules and then I encourage those who are entrusted with them to go ahead and put reminders in their calendars to review them. I can't make them do it unless they report directly to me, but I can try to make it easy for them to do.

Another area that gets ignored is log review. Most people hate to review logs. Especially if they don't have a SIM, SEM or some other method for automating it. I've done it before. I've had to sift through thousands of entries to try and find the "bad" stuff. It's no fun. Unfortunately it has to be done and you need to be able to prove that you are doing it. If your policy says that you are doing it then the auditors are going to want to see proof. How many times have you or someone you know spent a day or two prior to an audit "falsifying" log reports. Going through and checking off that they were checked when they haven't been looked at in days, weeks or months.

It's important to remember that these things are crucial to the success of your information security program. If you let them get sick or die then your program will do the same. Security Professionals need to follow the policies and those in management need to ensure that they are being followed. Those who are tasked with keeping the policies or program alive need to be proactive in doing so. Don't wait until the last minute and try emergency CPR. If you will schedule a little time weekly or monthly to check on them then they will stay healthy and your program will be more successful.

Out of control network

Like most IT people I've always disliked documentation. At least having to be the one to actually do the documentation. I know it's important and that it can save you and others lots of time when push comes to shove. This has hit me in the face hard since starting my new job. The company uses lots of contractors in the IT department and the network has been built and modified over the years by lots of different people. Documentation has been sporadic at best. So therefore knowing what is going on and why can be a challenge. Almost everyday someone on the team gets a "surprise". They either discover something new, different, unexpected, unexplained, or just plain unnecessary. It's almost comical at times, but when you think about it there are potential serious ramifications.

This has made my job quiet a challenge. It's hard to design a security program when the environment isn't well understood by those who have been there for a while and especially when I'm still learning new things about it. The good news is that we have managements blessing and understanding of how things are and how they need to change. We also have a good team assembled to make this work. I'm amazed at the level of knowledge and understanding that they guys I work with have. They are much smarter than most of the guys I've worked with in the past. These guys are passionate about what they do and they don't like doing shoddy work.

All that said the real purpose of this post is to emphasize the importance of documenting and understanding your network. Not only is it good for daily understanding of what you have and how it works it will come in handy in troubleshooting, DR situations, personnel changes and compliance. Many of the regulations that most of us have to comply with require you to have a well documented environment.

Technology will help you in your information security endeavors but it has to be complemented with documentation, policies, procedures and a well designed User Awareness program. Most of us focus on the technology part but if we want to expand our horizons and ensure that our environments are as secure as they can be it is a good idea to get familiar with the other areas.

• Look over your documentation and update it. This needs to be done at least yearly and especially anytime you introduce a change in the environment.
• Read your policies. Ask questions if you don't understand something or if you think something is incorrect. Remember, if your policy says you do it you better do it and be able to prove that you do. The Auditors will want to see the checklist, the archived logs, etc.. Don't be afraid to bring up inconsistencies to Management and to make suggestions.
• Review the procedures and guidelines that are published within your company. Again many regulations require you to have written procedures for how you deploy systems, handle new users and users that leave. They want to know that you know what is going on and again if your procedures say that you do something they will want to see proof that you do it.
• Sit in on a UA session or ask to see the material that is used. Make suggestions on ways to make it better and more understandable for the average user. Suggest new things that could be done to make the information easier to retain. People learn in different ways and maybe you have an idea on how to present something in a different format. You may even have the talent to make it happen. You could help put together podcast, videos, RSS feeds, email blasts, or whatever sounds good and works.

As I've said before security goes beyond the server room. It requires that the IT and IS groups work together along with Management, HR, Training and even the end users. We have the knowledge and skills to really make a difference beyond the technology side of things. We just have to get out there and make it happen. I don't think you will regret making the effort.