Andy ITGuy – Information Security Blog

On of the maxims of business is that if you are going to have a policy and/or process then you need to follow it. This especially holds true when it comes Audit time. I’ve noticed that lots and lots of companies have all sorts of policies but most people, including those who manage them, don’t know what they contain nor do they monitor and enforce them. So what’s the purpose? Oh yeah, compliance. We have to have them in order to be compliant.

Following on my last post about data classification I want to go one step further and talk about your retention policy. Once you have your data classified you need to ensure that you have the proper retention schedule for it. Is it something that needs to be kept forever or just for a few weeks or years? What do you do with it once it has outlived it “useful” life? What do you do with it while it is still useful? Where is it stored or archived to? Do you treat all data the same when it comes to retention and archiving?

In today’s litigious society you had better be able to answer these questions or it may cost you lots of money or be a key factor in whether you company wins or loses a court case or law suit. It is very important that your retention policy be comprehensive and it needs to be tied to your data classification policy. Your users and support personnel need to understand these policies and why they are as they are. They need to know how to treat data to minimize the risk of doing something with it that will come back to haunt you.

One key thing to remember when creating a retention policy is how you deal with archived data. What I mean is that you must be careful to define the difference between archived data and backed up data. In years past it has been customary to make a “master” backup and keep it under lock and key whenever you need to ensure that data is available for later use. We’ve learned that this is a very bad idea. Your backups are NOT a viable archive solution. Traditional backup media (i.e tape) is unreliable as we all have found out the hard way. There must be a clear differentiation between your retention and archive policy and your backup policy. If you rely on your backups to be your archive solution then you are in big trouble.

I went to a coffee shop yesterday morning to catch up on some reading while enjoying a nice hot cup of coffee and decided to get a piece of pumpkin bread to go with it. The Barista gave me my coffee and bread and I sat down and started reading. I then took a sip of coffee and a bite of bread and immediately determined that she had accidentally given me a piece of banana nut bread by mistake. So I took it back to her and she said, "No, that is our pumpkin bread. We store all our pastries together and often they taste the same." My first thought was "You’re charging me $2 for a .50 cent piece of bread and expect me to accept that it all taste the same?" But I chose to be polite and said that it wasn’t a problem and ate the bread that she gave me.

As I sat down and continued to read, drink my coffee and eat my bananakin bread I knew that there had to be a blog post in there somewhere. As I thought how this analogy could apply to Information Security I kept coming back to data classification. Much of what we do is easier to do when our data is properly classified and many products practically require that you have classification levels in order for them to work properly. Yet my guess is that many organizations don’t really classify data. They rely on folder level security as their classification level. Then they create group folders that other data is lumped into and hopefully secured from wandering eyes.

Data classification can be a daunting task to undertake. Especially if you don’t start early on when the amount of data is still easily manageable. Starting early is very important to making this really work with minimal pain for yourself and your users. If you can’t start early then you have to start small. You take data from one area and start on that then you move to the next area. Maybe starting with your Payroll data and then moving across the rest of the business units that fall under the direction of your CFO. Next you move to HR or whatever works best for your business. The key is to start somewhere.

Keeping your data separate from other data is as important to securing your data as keeping your pumpkin bread away from your banana nut bread is to getting the real taste you desire.

Lately it’s been popular to post "25 Random Things About Me" on Facebook and other social networking sites. Although it can be harmless fun I’ve discovered that many people are not exercising caution in what they post. Kinda hard to believe isn’t it? So here is my list of "25 Random Reasons I Won’t Tell You 25 Random Things About Me"

1. You don’t need to know 25 random things about me
2. Privacy on the Internet is already bad enough and doesn’t need help
3. I’ve seen too many of my friends tell things about themselves that the rest of the world doesn’t need to know
4. I’ve learned things about them that could be used against them
5. I’ve learned enough to become them on other social networking sites
6. I’ve learned enough about a couple of them to quiet possibly open an credit card account in their name
7. I’ve learned enough about them to guess usernames on other sites
8. I’ve learned enough about them to be able to guess passwords or password hints on other sites
9. I’ve learned enough about some of their friends to do the same
10. I’ve learned enough about them to wonder why I was friends with them in the first place.
11. I’ve learned enough about their friends to make me glad I’m not their friend
12. I have learned enough about privacy and the insecure nature of the internet not to post too much about myself for the world to see
13. I’ve seen too many cases where simple, "harmless" facts have been used to hack accounts
14. There are plenty of random things about me that I just don’t want the world to know
15. Some of those things may make my friends wonder why they were ever my friend
16. Most people make it easy enough to find out random things about themselves without posting them on the internet
17. I’ve worked hard to build a good reputation on the internet and don’t want so ruin it in a moment of unguarded fun
18. Remember, much of what you post (if not all) can be seen by not only your friends but your friends friends also.
19. Even if you make it private vulnerabilities in web sites often lead to private being public.
20. Once you post it to the internet you can never take it back
21. There is a good chance that someone will find it that you didn’t want to find it
22. It can be used against you in the future and may cost you a job or promotion
23. The things that I want people to know are already known
24. I’m trying hard to keep the rest of it out of the public eye (not that it’s bad, just being careful)
25. You probably don’t want to know 25 random things about me.

There you have it. I welcome your comments and or suggestions of other reasons why this can be a bad idea.

OK, I know all of you are tired of reading about the Heartland data breach. I know I am and had planned on NOT writing anything about it, but alas, I succumbed to a thought and had to write it down.

Most of you probably think like me when it comes to regulations such as PCI, SOX, HIPAA, etc…. They are primarily "feel good" measures that make the governing body happy. They are not a substitute for practicing good security and they will not secure you. In most cases they are too vague to be of any value and even in the case of PCI, which is the best one in my opinion, it’s still the bare minimum at best. Of course they lull us into thinking that we are doing a good job. We are happy because we have all the check boxes checked. We feel good because we get the "compliant" logo on our web site. Management is satisfied because we made audit happy. Unfortunately we are only fooling ourselves.

As I said I think PCI is the best regulation because it lacks much of the vagueness that others have. It does a good job of defining the objectives, requirements and other options. If you follow it then you are on the road to not only compliance but a good overall security program. Unfortunately, it does often lull companies into being complacent and/or apathetic.

No matter how many transactions a company processes a year they can jump directly to a level one if a breach occurs. So, if you are a level 2 merchant who only handles one million transactions a year you can automatically become a level 1 merchant if you suffer a data breach within your PCI environment. What does this mean? Do you have to follow tighter requirements? No. Do you have to do more to protect your environment? No. Nothing changes except you have to bring in a authorized 3rd party to validate your compliance. In other words you are subject to (hopefully) increased scrutiny and will be more secure as a result. Yet, Heartland, Hannaford Brothers, and TJX (I think) were all "certified" as compliant when they were breached.

So does this mean that PCI = FOI? These companies invested money in becoming compliant above and beyond the cost of the technology and man hours required to implement and support it. They had to invest money in having a 3rd party validate their compliance. They had to invest time and money in documenting their compliance. They had to invest significant resources because they are a level 1 merchant that they would not have had to invest if they were just a level 2 merchant.

I don’t think that PCI itself equals FOI but I do believe that the message around PCI is a FOI. We have to quit pushing things such as being "complaint" with any regulation as equating to being secure. When I say we I don’t me most of us reading this but the PCI Council and other governing bodies. What we have to do is make sure that management understands that our goal is not compliance but good security. We have to ensure that it is understood that being compliant only sets us up for failure if we don’t move on to the next level. Imagine the reputation damage if you are bragging about being compliant with PCI or some other regulation and then you suffer a breach. Especially if that breach occurs via one of the "check boxes" that you are so proud of.

PCI may not equal FOI but it sure can lead us down that road if we’re not careful.

In my last post “Why FOI?” I talked about some of the reasons security investments fail. One of the things that I mentioned in passing was purchasing the wrong technology for what you are trying to accomplish. In other words not defining your requirements prior to making a decision on what to buy.

Most vendors that are worth their salt will help you with this as you are looking at different options. One of the first questions that they should ask is “What are you trying to accomplish?” Then the second question should be “Have you defined requirements?” If you have not defined requirements then they should be willing to step back and wait. That doesn’t mean that they go color until you call. They may be able to give you some insight into what some of the requirements should be. Many technologies are going to have very similar requirements at a base level and they can help you define those. They may also be willing to give you some guidance in going deeper in your requirements.

If you don’t know what your requirements are then how will you know what solution best meets your needs? How will you know if you are buying something that will make you more secure and not less secure? You can’t take the vendors word here because they don’t know your environment and business need. They may sell you what they think will work for you but in reality it may miss a major need that you have. It may work against other protections that you have in place. It may make you less secure as a whole.

Requirements are required if you hope to be successful in protecting your data. You have to be able to answer the who, what, when, where and how if you want the technology you buy to do what you think it will do.

What I want to talk about today is what causes FOI. Let’s step back and remember what it was that started this who FOI thing anyway. It’s because many people don’t believe that you can truly have Security ROI. Security isn’t so much an investment that you expect to make money with as it is money spent to protect investments that do make money. So we have to look at security from a different perspective than we do things such other technology purchases. Since we look at it differently we have to measure it differently.

So when we talk about failure of investment we have to  start off by differentiating between failure of people and failure of technology. People fail because they are people and because they often don’t know what or how to do something. Technology fails because it is designed, built, configured and maintained by people. It fails because it is programmed to do a set of tasks and when faced with doing something different it doesn’t know what to do but fail.

Security fails for a variety of reasons. I know that you are expecting me to spout off things like improper configurations, poorly trained  staff, implementing wrong technology, lack of awareness and user training. Although all of those are things that can lead to FOI there is much more to it. Failure can occur when technology isn’t updated or properly maintained. When the vendor doesn’t provide timely updates and patches. Failure occurs when the things that make for a good security program aren’t done regularly, properly and diligently.

Now the real question is how does this happen. How does it get to the point where these things are neglected or never properly implemented. I think it’s because the company doesn’t understand what the real threat is. Companies implement security to meet compliance, satisfy audit and provide enough protection to say they are doing something. They don’t take it to the next level of making security a priority. That means having support from the top. That means making a concerted effort to make sure that all employees know the what and why when of security. Security fails when it’s not taken seriously by all involved. It’s not something that can be done by one person or even one department. It has to be a company wide program. The network team can still route packets with out the participation or HR, Maintenance and the rest of the company. The server team can still "serve" up files, applications and data without the rest of the company being on board. The security team can’t be successful unless the whole company buys in to the program because it only takes one person to open up the whole that allows the data to flow out or the malware to flow in.

If you are reading this via your RSS reader then it worked. I have left blogger.com and have moved to my own domain. Hopefully the Feedburner update has worked and you didn’t have to do anything to continue to receive my posts.

Hopefully I’ll be able to provide more than just a blog here. It will take time but it should come sooner or later.

In tough economic times we all have to watch where we spend money and how we spend it. We can’t let bad financial times or the threat of what may happen keep us from spending what we need to spend to ensure that our data is secure. We can’t be stupid and spend just for the sake of spending, but we also can’t not spend just to save money. Sometimes money has to be spent now to keep from spending more later.

I remember several years ago there was a commercial for Pennzoil with Arnold Palmer. The key line was “You can pay now or you can pay later”. It was in reference to spending a little now to change your oil regularly or pay a lot later when you have to have major repairs. I also saw something today that made me think about this. There is a water line break in Atlanta near my office. It’s been there for about 2 or 3 weeks. You can see where the water is seeping through the asphalt and it’s creating a nice little river flowing down a side road. Of course it’s frozen a time or two and probably will tonight since it’s supposed to get down to the upper 20′s tonight. I assume that it’s not being fixed because of the budget crunch that the city of Atlanta is in but the problem is that soon it’s going to cause a sink hole and cost a lot more to repair. Not to mention it’s going to create a traffic nightmare at a busy intersection and possibly cause injury to someone if they happen to be driving over that spot when it decides to collapse. So in an effort to save a couple of thousand dollars the city will probably end up spending 30 or 40 thousand, wasting lots of water and possible cause someone to get hurt. Of course if that happens then there will be a multi million dollar law suit.

Now that we are in a new year and are looking forward to what we will be able to do and those things that we won’t be able to do we have to plan on selling the really important things more than ever. We need to start now in building our case to management on why we can’t delay certain things. We also need to be prepared to go to them with our list of  “sacrificial lambs”. Things that we had planned on doing but are not as important as the “gotta haves”. By doing this we show them a couple of things. One, that what we are keeping is really important and two, that we are willing to make sacrifices in order to get the really necessary things.

We took December off but we’re back and ready to roll. Our next meeting will be Wednesday Jan 14, 2009 at 7:00. We’re meeting at the MARTA headquarters building in Buckhead at 2424 Piedmont Rd, Atlanta, GA 30324. It’s at the intersection of Piedmont Rd. and Morosgo Dr. across from the twin AT&T towers. This is the location of the MARTA Lindburgh Station. The meeting will be held in the Bid Room on the first floor. You will have to sign in at the security desk.

View Larger Map

The talk will be given by Renault Ross of Symantec (no sales just knowledge sharing). He will be speaking on End Point Security and NAC. Pizza and drinks will be provided so come hungry.

We’re still young and are looking to grow so make plans to join us. Feel free to invite your friends and pass the word along to others. We will be giving away a couple of door prizes as well. If you know that you will be attending please email me (andy.itguy at yahoo dot com) and let me know so we can get a general count for ordering pizza.

My buddy Jack Daniel pointed us to a new blogger that is worth following. As I was looking through some of his post I ran across one entitled “Failure of Investment”. Of course that caught my eye because of the conversations that myself, Jack Daniel (here and here) and a few others had on this topic back in September of last year.

Tim’s post got me to thinking again about FOI. I had intended to expand on the concept more last year, but as you (hopefully) noticed my blogging fell off drastically the last few months of the year due to life getting in the way. Now that a new year is here and I’m hoping to get back into regular blogging and what better topic than FOI to start with.

What I want to talk about today is defining FOI at a more granular level.
Failure is measured differently for different technologies. You can’t define failure the same for a firewall as you would a host based Anti-virus program. They are different technologies and have to be measured differently. If can even be argued that within the same technology there are different tolerance levels for failure. An AV program that lets a virus through to a workstation that has very limited network access isn’t as serious as one that allows a AD server to get infected.

So how do you go about defining failure? It goes back to a security basic. Risk. What is the risk if failure happens w/ a technology at a certain level. This is why it is so important that decisions to purchase and implement technologies not be taken lightly. Don’t make a decision based on the fact that it is from a certain vendor. Don’t make a decision based solely on price. Don’t make a decision based on “ease of use”.

You have to know what you are protecting, what the value of it to the company is and what level of failure can each thing handle. If you don’t know this then you are going to set yourself up for FOI and a new job search.