Shades of Gray Security » policy

Security from Obscurity: Building a Security Program, Understanding the Standards

Chad Olivier — Thu, 18 Mar 2010 23:34:17 +0000

In this third installment of the series, we are going to talk about a few different standards, and focus on the one you most likely should start with. In the last installment we touched on ISO 17799. This is probably the best place to start to build a security program. Other standards and frameworks such as SABSA and COBIT will most likely overwhelm you if you are just starting out, they will cause you to spin your wheels much longer, and while all standards are great bed time reading, they will probably lead you to staying up late nights pulling your hair out while your eyes bleed. In this series, we are talking about creating a security program where none existed, so let’s go with the easier choice. Having said that, please consider ISO 17799 a starting point to get you on your way and not the final solution. Nothing wrong with it, but you may need to comply with regulators that go beyond it, or you may just want to go further into defining the policy as ISO 17799 is more of a high level guide. In fact, both COBIT and SABSA compliment the work you will do with ISO 17799, they are not competing standards with ISO 17799. They are with each other. As you dive further into security and what it takes to gain regulatory compliance you will likely adopt one of these standards, or possibly another.

Let’s pause for a second and let me explain one thing. I say ISO 17799 because that’s what I have known it as for years and that is what you are most likely to find in searching. This standard comes from BS 7799. It was been revamped and is now known as ISO 27002. That being said, I will continue to refer to it as ISO 17799 for the reason mentioned above. Carrying on…

So what exactly is ISO 17799 going to give you? Good question. It provides guidelines for what an organization should have in it’s security program. It gives advice from a thousand foot view on major components that should be in the security program. The areas it covers, called clauses, include such topics as security policy; organizing information security; asset management; human resources security; physical and environmental security; communications and operations management; access control; information systems acquisition, development, and maintenance; information security incident management; business continuity management; and compliance.

I hope this helps get you started in security program and don’t hesitate to ask questions.

Security from Obscurity: Building a Security Program, Define the Domain

Chad Olivier — Tue, 15 Sep 2009 00:00:23 +0000

In our first installment, we decided who needs to be involved in the program and an idea of how it is structured and to whom it reports. That’s a great start! If you haven’t had a chance to read that article, check here. Now we need to start looking at what we are securing? What is it we are governing? What is the scope? If we don’t have that defined, we can’t really protect it can we?

It’s probably easier to define what isn’t in a security program, than what is in it! That’s right, security is going to touch almost every aspect of your organization. Every organization is different, they all have their own threats, compliance issues, business lines, risks, etc. Even in the same industry, the security program requirements can vary greatly. However, they all typically have the same basic elements.

Every organization has assets. This is what we are defending and we’ll call this tier 1. Assets can be systems, knowledge, data, people, etc. It just depends on the organization, and if applicable, it’s business lines. Tier 2 are the elements influencing tier 1. Assets are protected by network security, physical security, system/software lifecycle security, and communication security. Factors effecting the assets and security of the assets include threats and threat management, compliance with policy (note, we are not talking regulations, that comes at a higher tier), metrics for evaluating our security (defined in a higher tier), vulnerability management, and incident response. Elements that drive tier 2 and therefore will be called tier 3 include personnel security, risk assessment, audits, business continuity planning (BCP), metrics development, process management, threats and vulnerabilities (yes they appear here as well as this level is also being protected), data classification, and process management. Tier 4 is the final tier we will cover. This however can be expanded to additional tiers depending on complexity of organizational structure and regulations/laws, but we are talking basics here. Tier 4 includes, regulations, laws, risk analysis, the overarching security program, policy development, process development and monitoring, governance model, and organizational security.

In some capacity, your organization MUST have each of these components to have an effective security program. I know, that seems like a daunting task. It is no small undertaking to establish all that, and if the company has grown for years without it, it will be extremely difficult to change the culture of the organization to be accepting of such a wide sweeping change. Remember though, if you followed part 1, you have the authority of the board and CEO. This is a mandate. If not, you’re wasting your time. That isn’t to say, be ugly about it. In fact, just the opposite. The people that need to be involved in this process (which is pretty much everyone in the organization in some aspect) MUST want to participate or they won’t live up to their end. A great way to start is training your employees on how to protect themselves from predators. This will get them engaged and thinking about security in new ways.

Most companies have no idea where to begin trying to get a handle on all those elements. Fortunately, you are reading this article to help you on your way. There are plenty of great resources out there for best practices guidelines. ISO 17799 and it’s successor is a fantastic resource. It is an internationally recognized standard for information security governance and provides high level recommendations for enterprise security programs. Divided into two main parts, the first is an implementation guideline and the second is an auditing guide.

As suggested in part 1, security should be top down. Meaning the board down to upper management, middle management, and finally the staff. A bottom up approach in which the IT department tries to initiate a security program is less effective, won’t get full buy in from other departments/business lines, and is doomed to fail. Other than the obvious lack of buy in from others, it is generally focused on technology and leaves all other vectors of attack untouched. The people actually responsible for protecting the assets must be driving the program.

Contact Shades of Gray Security to find out how we can help you setup and manage your security program today!

Security from Obscurity: Building a Security Program, Intro

Chad Olivier — Fri, 31 Jul 2009 20:07:47 +0000

After reflecting on much of my career, and more specifically, my last job, I have decided to write a series of articles about starting a security program. I have set foot in pretty much every industry type and every organization size and from small banks, to law firms, to large Fortune 500 energy companies, across the board, there are always companies who turn a blind eye to security. Why? Some, like law firms, think they are not targets. I have all too often heard the same thing from law firms. “Everything we have here is on the public record, so it doesn’t matter if someone steals our data.” Trouble is, not ALL of your stuff is on the public record, things like medical records of clients, credit reports, payment info, the evidence you have on a case that, while you will ultimately have to turn over to the opposition before trial, you may not want to show your hand now, etc. Some are just young naive companies who grew into a Fortune 500 overnight and have no idea how they got there or what they need to do to ensure their survivability. These types seem to be intimidated by the idea of security and prefer to stick their heads in the sand and pretend there is nothing to worry about. Trouble is, when you stick your head in the sand, guess which part of your body is sticking up in the air!

But I digress, this series of articles is about the hows of starting a security program, not the whys. Keeping the various sizes and roles of companies I have either worked for or with in mind, I am going to give some pointers on how to get the ball rolling on this daunting task.

First, let’s talk about what security is, and isn’t. It isn’t just having a policy and then turning to network defense appliances and washing your hands of the idea, mission accomplished. If your security program isn’t mandated by the board, mapped to all business lines, legal and regulatory requirements, and threat agents, it isn’t complete. It also isn’t enough to guard the perimeter while leaving the internal network in shambles. Likewise, if you don’t have data classification, you can’t move forward in a security program. After all, what is it you’re protecting and why? How can you have a risk assessment if there isn’t a metric for what is at risk?”If you don’t eat your meat, you can’t have any pudding! HOW can you have any pudding if you don’t eat your meat?!” Wait, I’ve gone off topic again. Anyway…

Let’s agree we need security and doing the above things simply isn’t cutting it. What are the first steps to getting your business security focused? Dive in and start applying patches? Install that much needed IPS? Write policies? No. Our first steps are crucial and should happen in rapid succession.

The board, CEO, and so forth, all must be on board with this. If there is no mandate coming down from the top, hang it up, go home, forget about it, game over man… game over.

First and foremost, let’s agree we need qualified people architecting it. I know most people may laugh, but I have tragically seen unqualified people put in the position of managing security. This is NOT a job to be given to someone because they have seniority. You will FAIL. This director must report directly to the CEO and board. It is not in the best interest of security to report to the CIO, CTO, network director, etc. It is not in their best interest to have anything negative reported by the security department and it will therefore not be. A security team is not a political football to be used to give the board and CEO false hopes of a safe network by the network director all the while not letting them do their job because he may look bad. You will FAIL. It is not a department that needs to be a clapping monkey doing cheap tricks to impress upper management with “quick wins.” If anyone ever thinks about uttering the words “quick win” toss them out ASAP. You will FAIL. That’s another thing, if someone says you won’t fail, toss them out. You WILL FAIL. The difference is, how graceful you fail. Did you fail and know within seconds? Hours? Days? Years? Did you ever find out?

So for our first step, and end to this first installment, we need sign on from the board and CEO. We need qualified people in place to architect this program, we need the team to report directly to the board and CEO. If this is going to be a political football and for some reason, no one can put on the big boy pants and enforce the program, I would venture to say your best bet is to outsource the entire program.

Contact Shades of Gray Security to find out how we can help grow your security department.