Lying for the truth

The SANS Newsbites email today has a link to this article on Forbes.com. It talks about the apparent disconnect between what Security and Privacy departments think is going on and what seems to really be going on. Now I'm not accusing anyone of lying to the Security/Privacy departments or to management, but it sure looks like someone may not be telling the whole truth. More than likely what has happened is a disconnect between these departments. Security/Privacy creates a policy that states that sharing personal data or sensitive data with third parties is not allowed. Marketing either is unaware of the policy or decides that the policy is stupid and ignores it. This is where my comments in the last post about being able to monitor, verify and enforce policy is crucial to it's success.

I know in my personal experience that I've been lied to about certain things. I'm sure I'm not the only one. I've asked questions and received answers that were incorrect and the person who gave me the answers knew that they were incorrect. When later confronted I was told that I was given the answer that I wanted. Obviously since then I've learned not to be so trusting (remember: "I like you. I just don't trust you.). Now I require proof and if proof can't be given then the answer is left blank and steps are taken to fix the issue.

The real problem in this is that by lying the company as a whole is put at risk. Proper security can't be put in place because the truth isn't known. If a incident occurred as a result of this lie then it could be detrimental to the company. Again I stress that if we are to do our jobs effectively then we need to know the truth and be able to verify that truth.

Why process trumps technology

My morning routine usually involves having Headline News on the TV as I'm getting dressed and packing my lunch. A couple of mornings ago I heard a snippet of a story about a child abduction from a daycare center in Arkansas that caught my attention. Obviously, as a parent and caring individual I was sad to hear that it happened but what raised the red flag in my mind was a comment that they were going to install security cameras to combat this.

When I got a chance I used a little "google foo" (OK, it really wasn't google foo but I like that word) and found an article to verify that was really what I heard. Here is an article that confirms that and adds a little more that either wasn't mentioned on HLN or I ignored didn't hear. This is a quote from the article.

Those picking up children are required to show ID, she said. She added the center is installing security cameras and is exploring a keyless lock pad that would require a different number for each family. A person could not enter the building unless they knew the code, she said.

My first thought was that putting in security cameras was a knee jerk reaction that really would do nothing to stop this from happening again. I would be helpful in identifying the person but will not stop this. I do think that cameras are a good idea but before cameras there needs to be policy, process and procedures. After reading the article it is obvious that they have the 3 P's in place but they were not effective in this case because someone failed to follow at least one of the P's.

Similar scenarios are played out in businesses and IT shops all over the world almost daily. Something happens and immediately knee jerk reactions occur. When the 3 P's and common sense prevail the reactions stop in their tracks. Unfortunately common sense often fails instead of prevails. Products are purchased just to "show" that we are on top of the situation. Decisions are made to ease tensions and worries that really do nothing to solve the real problem.

When Policy, Process and Procedures are in place, followed, monitored and verified then there is less need for knee jerk reactions because things work better. In order for these to be effective your employees have to know about them, what they say, how they work and that they are not suggestions. In some cases there needs to be specific training to ensure proper compliance with them. Having them sitting on your company intranet is not enough. If your employees don't know about them then they are useless.  Often these things are created just to keep audit happy and then they are forgotten about or blatantly ignored. This works for a while but one day it will catch up to you. When something bad happens or audit decides to verify whether or not you are following them then you will have problems.

The purpose of Policy, Process and Procedures is to ensure that you are doing things in a way that allows you to operate your business effectively, efficiently, securely. They also serve as a way to ensure that what you are doing can be repeated and verified. They are not just a bunch of documents that are boring to read they are vital to the long term success of your program. They are the things that makes your technology work effectively and that allow you to continue operations if the technology fails.

The nick of NAC gave me a paddy whack

Sorry for the title, but I just couldn't resist.

We're deploying a NAC solution at work. It's been a long process that is finally starting to see the light of day. We set up a small test environment and after successfully completing that phase we decided to roll it out to a larger test environment. Our engineer who is leading the project realized that there were a couple of potential snags with our current environment and that we may have to alter our test a bit. After much thought and discussion we decided that we didn't want to make that change. It would have been different than our "go live" deployment scenario so we felt that it wasn't a valid test. So the engineer continued to research and we decided that using a different switch for the test environment would not compromise our test plan too much. So it was set up and deployed to a larger test group.

While the testing was going on the engineer continued to work on what would be the  "live" environment. He was successful in getting one of the switches to work with the NAC setup but the other two switches that we were use wouldn't work. Everything was the same on the switches. Firmware, software version, code versions, everything but for some reason the switches wouldn't communicate with the NAC device. So the engineer decided to go ahead and move those of us on the old test switch to the new switch. In doing so he failed to complete part of the change and so those of us in the test environment were not prisoners of NAC. We could do absolutely nothing. Then to top it off the engineer went on vacation.

Luckily it didn't take long to figure out what had happened and we put the original switch back in the mix and got us all back up and running. Hmmmm, another potential disaster in the making for those who aren't adequately prepared for ALL potential issues.

Danger, Will Robinson, Danger

Disaster recovery is a key process in running a successful business. Failure to have an adequate disaster recovery plan in place can do impact a business in many ways. Disasters can cost you money, information, customers and in the worst cases it can cost you your business. How you prepare your DR plan depends on several things and every company implements differing levels of disaster recovery planning. Hopefully your DR plan takes into consideration several different disaster scenarios and each has different tasks associated with getting things back up and running in a timely manner.

One thing that we need to take into consideration is that disasters don't always come in "disastrous" ways. Disasters can strike in ways that you don't expect. Some of the ways that a disaster can sneak up on you are things such as not paying attention to when contracts expire is one thing that can bite you if your not careful. If you have a service contract and it expires the consequences can be disastrous. Also lack of planning can be a disaster for you. If for example you are planning on moving your web server hosting in house and you don't adequately plan you may have a disaster on your hands. You may find yourself down to the last hour and not be able to make the transition in a timely and secure manner.

We tend to think of disasters being events beyond our control but sometimes events within our control can have the same effect as a real disaster. Having plans in place for ALL scenarios is a good idea.

Hello, My name is Andy and I attend meetings

Hi, My name is Andy and I attend meetings. It started out to be just causal meetings with the guys on my IT team. We'd talk about things that we were working on and give tips to help solve problems. Then the meetings became organized. We meet weekly and had agendas and formal discussions. After that I started attending project meetings. These were more hardcore with people from different business units and the formality became more important.

I tried to stop. I didn't like attending meetings but I kept getting pulled back in. Of course the longer I attended the meetings became more hard core. Now I was expected to not only attend but to add value and actually be a leader. Before I knew it I even started leading my own meetings and encouraging others to attend. I didn't like what I had become but I couldn't kick the habit. What started out as once or twice a week has now become a 8 to 15 time a week habit. It's affecting my life and productivity at work. Now not only do I attend and am looked to for leadership and guidance but I've taken the next step. Document review.

That's right, I also review documents to ensure that they, and the projects they support, comply with our security policy and to make design recommendations. Now I spend my days writing policy, planning programs and working to ensure compliance. No longer do I configure equipment and troubleshoot network  and security issues. No longer do I spend my days working with technology.

No longer am I a technology geek. No longer am I a hands on engineer. My name is Andy and I'm a Professional Meeting Attender. Someone please help me find my way out.

GRC - Love it or hate it

Last week I received an email from a marketing firm wanting to know if I'd like to talk to Symantec about IT GRC and an upcoming announcement that they were going to be making. Usually I ignore these emails because my blog is NOT an advertisement for vendors. It's my place to voice my thoughts, good or bad, on technology and security. I try to stay as focused as possible and not get off on tangents regarding politics, religion, personal life, food, or anything else. That includes free advertising for vendors. Plus, I usually am not that interested in talking to marketing people about their product. If I want information on a product I want to talk to the engineers that designed it and support it. Not the marketers and sales guys.

Anyway, since I do have an interest in GRC and like the concept of it I decided to take the bait and have a conversation with them. So we scheduled a time and spent about an hour talking about what Symantec is doing in the GRC space. Of course they have a product that helps manage and maintain your program and that was they jest behind the conversation. They let me in on the announcement that they were making on Wednesday of this week and we had a good conversation. Then they invited me to sit in on a conference call of Wednesday this week where they were having a round table discussion about their offering and getting ready to make their big announcement as part of their Vision Conference. I wasn't sure if I'd get to because of the audit that we were having but I did find time to join in on the call. In preparation for the call they sent me an advance copy of the announcement and a report on IT GRC.

I tried to be a good blogger and read the report before the call but just didn't get the time to do more than skim it quickly. It looked interesting and like it had some good information in it, but I just didn't get the time to really read it. Then the time for the call came and I dialed in, pen in hand (my new Cross fountain pen that I LOVE to write with) ready to take notes and hear some good stuff regarding GRC. Of course you know that didn't happen. I was tired from lack of sleep and 2 1/2 days of audit and my mind wandered. I kept trying to bring it back and just as I'd get focused someone would talk who wasn't close enough to the mic and I couldn't hear them very well and I'd fade again. After about 45 minutes I gave in and hung up.

Today I see that Neil Roiter over at Search Security has a write up on the report and the Symantec Round table. You can check it out if you have any interest in what the report or Symantec has to say regarding this. There are a couple of things that I want to point out myself. It seems that the report seems to validate many of my thoughts regarding IT GRC. Mainly that it isn't about technology but about process. The longer I work in IT and especially dealing with security and compliance the more I appreciate how effective good processes can be in your program.

Here are the things in the Search Security write up that I really like. My comments are in blue.

• The panel identified bridging that gap between senior management's business goals and IT operations as one of the keys to a successful IT GRC program, especially in complex global business environments with disparate regulatory requirements and a wide range of costs in different parts of the world.  No program is going to work if there is not an understanding between the business and IT as to what needs to be accomplished.
• "A framework is a framework is a framework," said KPMG's Lesser. "It's taking the key portions and figuring out what are most important to your organization; what are the outside threats, risks and vulnerabilities that you need to consider, and what is going to provide the most value to your organization; defining a framework based on these industry standards that really fits your specific needs." This is so true. There are several good methods that work equally well. It all depends on what works for you and your organization. As long as the business agrees across the board what they are going to use they can all be equally effective.

• Implementing automation tools, the panel agreed, was the last step in building IT GRC in an organization. See my post here for my thoughts on this.

• "The poor approach is to say we're going to do IT GRC, and there are some automated tools available," said ISACA's Hale, "and let's implement these without really understanding what GRC is, what their objectives are, who's going to use the information, and how does it support their decision making." Unfortunately this mind set isn't limited to GRC programs. Tools can't fix everything and without good process and policy to back it up they can't really fix anything.

• "There's no finish line with IT GRC; it's cyclical because the risks, and the threats and the landscape outside is constantly going to be changing." There is no finish line with much in technology especially security and compliance. If you ever get to the point where you think you are finished then you are likely to quit paying attention to it and you will end up in worse shape than before you started.

Audit driven programs

There are many different ways that a company can develop a security program and plan. Not all of them will work for all companies and a couple of them won't work anywhere. One of the best ways is to get IT and the business units together with Security and look at where you are, where you want to go and what you are doing to get there. You look at the threats to your environment and how your users interact with technology and the rest of the world. That includes Internet access, partner access, vendors, and a whole host of other variables. Once you have done this and have a general idea of what your risk profile is you determine your needs and how to address them. They you put together a plan to address the needs. (This is generic in principle, not every organization will follow this). Once you have your plan you start executing it.

What happens in reality is usually one of two things. You either buy what seems cool to you, what will allow you to check off the compliance check box, what you deem necessary just as "basic" security, or what audit dictates. Maybe I should restate that, What usually happens is a combination of any of the above and occasionally a "real" plan is in the mix.

I'm currently in the process of getting a "real" plan in place at my company. It's been a long and slow process but it is coming together. I have several projects that we are investigating and determining need for and priority of. There is a long list of things that need to be done and I have my idea of how things should be prioritized based on what my understanding of the business is. This is based off of conversations with business units and IT management. Again, nothing is set in stone yet.

Well, now audit has come into the picture. They are recommending several things that are being looked into already but honestly most of them are not towards the top of my list. So now I'm faced with the dilemma of either trying to convince management that what audit thinks isn't what should be our top priority or do I just quietly go with the flow and re-prioritize projects to reflect what audit recommends. I think I know what I will do. I'll take audits recommendations and compare them with my plan. I'll fight for a couple of the things and give in on a couple. I hate to admit this, but it is the reality of business. I'm not pretending that I know what is best and no questions should be asked, but I do know that audit does not know the full scope of our business and they are focused on a fairly narrow part that affects financial's directly.

I know the question that is going through everyone's mind is "Well, do you have management approval and buy-in on your plan. The honest answer.......... No, not yet. It's not quiet ready for that. They are aware of what I'm doing and what is on my radar and they agree with the general direction that things appear to be going at the moment. What I do know is that once audit submits their recommendations they are going to push to get them met before anything else unless I can convince them otherwise. No matter what happens it will be a busy year and full of excitement. Hopefully plenty of "blog worthy" things that I can actually write about.

In praise of documentation

One of the most important things that a company can do is to document their environment. This holds true for all areas of business. You need to know what you have, how it works, what it's worth (not just in dollars but to the operations of the business), how do you operate without it, what dependencies does it have and what depends on it. When you get into talking about technology you have a few more things to take into consideration. What does it take to keep it up and running, how is it configured and secured, what are the specs required to run it, and on and on.

This documentation gives you the needed information to continue operations, or get back up and running quickly if problems, disasters or failures occur. When done properly it can be the difference between continued operations and closing the door and hanging a "Gone Fishing" sign. It can be the difference between having a system back up and running in a matter of hours or days. Good documentation can cut troubleshooting time down to little or nothing.

Documentation also plays other roles. Auditors ask for lots of documentation of what you are doing and how you can prove it. They want proof of what you say and often good documentation is the proof that keeps them happy.

The problem is that documentation is no fun. Not many people enjoy documenting a server configuration or how the network is connected. Most of us in IT would rather build, fix and configure than document how we did it. This presents a problem when it comes time to rebuild a system and you can't remember how an application was configured or how you had an ACL constructed to help protect the financial department from engineering.

It can also become a nightmare when you get notice that an audit is coming up in the next few weeks or months. It's important to not only have your documentation in order but to know what it is that is expected and what you told them last year you would do this year. Spending a few weeks trying to figure out if you have met the requirements from last years audit and trying to gather all the information needed for this years in not much fun. Not to mention it takes valuable time away from other things that needs to be done.

Managing your documentation is an important part of any program. It is as important as any other piece and often more important. It's kind of like an insurance policy that sits in a file cabinet and you wonder why you spent money on it until you need it. Then you realize that it's worth every dime it cost you. Having someone who is good at documenting and can help you manage it will be a valuable asset to an organization. It will save time and money. It will help keep your stress level low and may well be the difference between a minor blip in operations and a complete shut down in operations.

The best laid plans.......

Growth can hit you square in the mouth if you are not careful. Growth can even kill you if you aren't prepared for it. Growth is good but like most things it needs to happen in a controlled manner. Not an easy thing to do when you are talking about your business and the success of a plan or product that takes you by surprise, even beyond your wildest dreams. Yet without a plan to address growth, even unexpected growth it can damage your business beyond repair.

In the last few months I've seen several incidences of growth that happened unexpectedly and quicker than expected. In many of these instances the companies have been sent reeling as their technology has not been able to keep up with the demand that is being put on it. Twitter is a perfect example. It's been around for a couple of years but as of late it has seen significant growth. Growth that it isn't prepared for. Growth that has all but taken it off line for much of the last week. Growth that may send users running to other similar services. Already within the security community there is a push to use FriendFeed as well as Twitter. Maybe even to replace Twitter.

I have a friend who works for a company that worked for years to build a business and they did build it. It was small but growing. A few months back growth hit them suddenly and their databases had a hard time handling the new load put on them. They have had a couple of outages but more importantly they have had several features of their application quit working properly. They had not planned (nor tested a plan) to handle growth to this degree. In the past as they experienced growing pains they just dealt with/ them as they arose. Now they are faced with/ potential crisis because they can't continue to operate this way. They have to fix the problems and put into place a practical plan that will address them and prepare so that they don't happen in the future.

With gas prices pushing $4 a gallon here in the US transit agencies are seeing big increases in riders. Many of them are experiencing growth related problems in regards to database usage, storage space, and scheduling routes for buses and trains. Increased routes means that there are more trains and buses on the road and rails that have to be tracked to ensure that they are where they need to be WHEN they need to be. Especially when dealing with trains being too early can cause real problems. Also you have to know when to stop, slow down, go and speed up. Technology is what allows the train operators know when these things need to happen. Last week Boston and Chicago (I think) both experienced passenger rail accidents. Were they due to growth issues? I don't know for sure but it's highly likely that growth did play a part in them.

How does this relate to Information Security? It has the potential to fall under the A in the CIA triad. These issues affect the availability of services and systems and although this type of availability issues are not usually security issues they can lead to security issues. If you database is under undue stress and heavy load then it makes it more likely that someone with malicious intent can sneak in and do something that they are not usually allowed to do. While under heavy load trying to process data it may allow a window where an attacker can bypass a security measure. If your service is off line or only sporadically available it could allow for someone to impersonate you and lure your users to their site where all sorts of bad things could happen. Not to mention that when you are focused on a issue that affects your users then security often gets overlooked or ignored. You are concerned with getting back up and running even if it means that you do something insecure.

I'm one of these who believes that information security touches EVERY part of the enterprise and needs to be included in all aspects of planning. This is just another example of how not only good business planning but also good security planning can save you lots of headaches.