Security frameworks, enterprise architectures, and security controls - a sea of acronyms

So I'm a growing company and business is really starting to take off. Awesome! But suddenly, security is becoming more and more an issue for me. And to complicate matters, I have no idea about what to do about it. Not awesome.

Lucky for me, and the rest of the business world, other really smart people have already sorted this stuff out and created best practices, frameworks, and architectures. Organizations like NIST, ISO, and DoD have published and maintain extensive documents on what should be considered when developing a security plan, and how to go about implementing it.

Before we get too far, let's discuss the differences between security frameworks, enterprise architectures, and security controls.

Security Frameworks

A security framework is the highest-level of abstraction when it comes to creating a comprehensive security program. The analogy used in the book is that the framework is like what type of house you want (ranch, 3 BR, 2BA). Security frameworks offer general guidelines on how a business should address various topics such as Information Systems Management Solution (ISMS) requirements, ISMS implementation, Network Security, Outsourcing Security, and many more.

The most widely used security framework is the ISO/IEC 27000 series.

Enterprise Architectures

The next level down is the enterprise architecture. The goal of the enterprise architecture is to map and diagram the entire organization and consider it's security needs based on how data and processes move throughout the organization. Rather than implementing point solutions, which only address problems as they arise in one place, the enterprise architecture aims to provide consistent security solutions throughout the organization. It also helps to show how changes in one area, can affect another area. Continuing the house analogy, the enterprise architecture is the architecture layout of the house (floors, walls, ceilings).

Common enterprise architectures include:

• Zachman Architecture Framework
• The Open Group Architecture Framework (TOGAF)
• Department of Defense Architecture Framework (DoDAF)

Security Controls

Moving to a more granular level, we now come to security controls. These are more specific guidelines on how to actually implement various controls. For instance, where the high-level framework may simply say that unauthorized access should not be permitted, the security controls guide will give more specific processes for meeting this objective such as:

• Using unique user IDs
• Checking that a user has authorization to access the requested service or information
• Maintaining a record of persons registered to use a service

In a way, the security controls guide provides a checklist of things that should be accomplished in order to meet a higher objective. In the house analogy, controls are the specifications and code that needs to be met for safety (electrical, construction, fire).

Major security control development platforms include:

• Control Objectives for Information and related Technology (CobiT)
• NIST 800-53 (developed by the U.S. government)
• Committee of Sponsoring Organizations (COSO)

Please note that there are differences between all of these various frameworks, architectures, and controls. If there weren't, we wouldn't have them. Discussing these differences is outside the scope of this post, however. The important thing is that there is common ground between each, and that is what I'm more concerned with.

One more thing

There is one more thing that fits into this overall picture of developing a comprehensive security program. That is blueprints. Blueprints are documents that security professionals develop to show the processes and components involved to meet a security objective. Blueprints lie somewhere between the enterprise architecture and the security controls. In the house analogy blueprints are the different components of a house (window types, security system, plumbing). Blueprints are important because they can be used across various business units to understand how something, such as user authentication, should be implemented. This helps provide a cohesive and consistent approach to security.

It's all about fundamentals

Every area has it's own language, it's own way of communicating. Security is no exception. So logically, this is where the book begins. Before we can dive in too deep, a common ground has to be set for what security is, and what it aims to do.

The CIA Triangle (no, not those guys)

The CIA triangle makes up the three things that security is always concerned with; confidentiality, availability, and integrity. Quite simply, confidentiality means that only those who should have access do. Integrity says that I can trust the information I get from the system. And availability means I'm able to access the information when I need it in a reasonable amount of time.

Balancing these three things is what it's all about. It's easy to make something really secure. I can just lock a hard drive in a waterproof safe and drop it into the ocean, but then no one can access it. And that's why it's a triangle. Just like the three angles of a triangle add up to form 180 - so too do these three concepts have to balance to form a cohesive security policy.

So with that goal in mind, we can now look at common security concepts. These include what constitutes a risk, threat, threat agent, vulnerability, countermeasure, asset and so forth. But rather than throw a bunch of definitions at you, I'd like to share a diagram that shows how each relates to the other. From there, I believe it's fairly intuitive.

Security Concept Relationships

So with this diagram in mind, lets give each concept a more concrete example. A hacker (threat agent) poses a danger (threat) because they may potentially find some outdated code that is vulnerable to sql injection (vulnerability). This constitutes a risk (which is measurable) to an asset. Should the vulnerability be exploited the result is a loss of information, reputation, etc. (exposure). This can potentially be prevented / mitigated by a safeguard which directly affects the threat agent. And thus the cycle is complete.

Bringing it together

So let's bring this together. We saw that the goal of security is balancing the CIA triangle. And now we see how various concepts relate to one another. So what does that mean?

It means that as a business, the decision has to be made about where priorities lie. Complete focus cannot be given to any one area, so risks have to be measured and the costs to install and maintain safeguards has to be figured. What is a large risk befitting a large response for one company is not likely to be the same for another.

In future posts, I will be further exploring this idea through the discussion of various security frameworks and architectures. These can form a strong foundation on which a company can build their security management system. (assuming they have one!)

Schedule Revisited

As promised, here is the schedule that I've set for my studies updated with the chapter title and not just the number.

I'm particularly excited for the Telecommunications and Network Security chapter, as well as the one on Cryptography. These are two areas that I've had some exposure to and find very interesting.

So with that, let's get started! From here on out I'll be posting every few days to recap what I've learned. I'm going to try and make these posts very rich, and by that I mean I intend to include graphs, charts, diagrams, and things of that nature whenever ever possible and reasonable. I know my prattling isn't the most entertaining thing.

Tentative Schedule

The CISSP is split into ten domains. This works well for scheduling purposes as all I have to do is decide how long to spend on each domain. Of course, it would be silly to just assign arbitrary amounts of time or to even split the time evenly across all domains. What makes the most sense is to set the schedule according to the length and depth of each domain.

I started this process by determining how many pages make up each domain. After that I got my total work days. With a tentative ending date of November 22nd, and giving myself weekends off, there are a total of 68 working days. Now I can figure out how many pages I would need per day to work through all 1298 pages of content. By my math it comes out to just over 19 pages per day. With this number I can now determine how much time will be spent on each section. Below is the tentative schedule of when I'll begin each chapter, along with the total pages in the chapter and how many days will be spent on the chapter.

Of course this schedule will have to be somewhat flexible. For instance I know I won't be able to get any work done on Labor day. I'll therefore have to compensate within that chapter's time frame.

I also realize my error in not including the title of each chapter. It certainly does not do you, the audience, much good to know I'll be working on chapter six from September 26th to October 14th. I will come back later and update this table with titles so that you can better see what I'll be studying and posting about when.

The Book!

For deciding which book to use I reached out to a colleague who recently took (and passed) the CISSP. His recommendation was the CISSP All-In-One Guide by Shon Harris. I decided to go ahead and purchase the book since this will likely be of service to me for the next few years.

I'm excited about this book. Reading the reviews gives the impression that this is absolutely THE book to get for studying for the CISSP. I'd be lying if I didn't say I'm at least a little intimidated by its size, though. The book weighs in at a whopping 1317 pages without the appendixes. Shudders...

Introduction

Welcome! From here you'll have the chance to follow along as I work my way through the CISSP body of knowledge. But first, who am I?

Me and the boys at Disney World

A senior at The University of Georgia, I am studying for my B.A. in Management in Information Systems. This past summer I interned at KPMG and will be joining their Information Protection and Business Resilience service network in 2014. Activities that I enjoy in my free time include reading (mostly sci-fi and fantasy), camping, video games, and movies. Currently, I'm gearing up for the four-day bonanza that is Dragon Con!

Throughout this semester, I'll be working through the CISSP body of knowledge with the help of a study book (more on that later). I'll post here about the things I learn, and anything else I find that's topical. By the end, I'll hopefully have a better idea about security and be ready to work in the field full-time.

Cheers!