Security 101: The Series

This post is the introduction of a series I'm working on.  I'm taking a list of security compliance questions that a client or an auditor might present to a company and expanding on what it means, how important it is, how one would introduce controls and auditing to ensure you're meeting the requirement. I'll also probably wax philosophical on some of the challenges and push back you'll receive from the business while trying to implement policies, procedures, and controls to support meeting the requirement.

You'll be able to see all of the posts in this series as they're introduced by visiting the Compliance 101 tag.

I'll be writing this guide from the perspective of an IT professional with maybe a smattering of security focus. The reason I'm writing this series is that I found it was sometimes challenging to explain what the requirements meant to the business.  The business tends to interpret the requirement very differently (and often incorrectly) and when you're facing a huge long list of related requriements it can be a herculean task to present them coherently. That's the purpose of this series.  Each post I'm going to break down one security/compliance requirement and provide as much information as I can.  The seed list of requirements I'm using came from a client's security requirements document.  The client required each of their vendors to provide a response to each of these requirements.  This list of questions was one of many such lists (the longest had something like 106 discrete requirements).  These are pretty standard for many industry certification and think that if you can adequately address the questions I'll be presenting you'll be in a pretty good position to address any RFQ with a security component.

Conventions

Each of the posts will be formatted in a similar manner so that... well... so that I don't get distracted and forget to write important bits.  Usually when presented with a list of security compliance items they're in the format of a question or possibly a statement that you'll need to respond to.  The convention I'm using assumes that to be the case and is also facilitated by the fact that the list of requirements I'm working with are in a question format.  Each of the posts will be formatted as follows:

1. The Question

1.1 Summary

The summary of each requirement will explain what the requirement means, why it's important and what the risks are of not meeting this requirement.  Essentially this is the "why it matters" part of the post. Sometimes requirements don't make sense to the business and I'll be providing the ammunition you need to translate a requirement language that'll make even the most non-technical person take another look.  Also, anything else that might be relevant - including anectdotes.

1.2 Policy

What a policy that addresses the requirement should look like. There'll be a lot of overlap here as an ID policy will cover multiple security concepts.  

1.3 Controls

Policies are great but without a control then it's just words on a hard drive somewhere.  The controls section of the post will elaborate on how you can make your policy a reality.  Ideally controls will be automated but sometimes that's not possible.  I'll show examples of minimal as well as wouldn't that be nice type controls.

1.4 Audit

You've got your policy.  You've got your controls.  Can you prove that you're meeting the requirement if someone asks?  The Audit section is all about that.  What would you need in order to prove that you're meeting the requirement. I say, "If it's not written down it doesn't exist" an awful lot and this is the section that makes it exist.  This part of the post I think is particularly important.  Having the policy is great.  Putting process in place is excellent.  But if you can't demonstrate that the controls are working you're not really compliant (or secure).

1.5 References

Lots of requirements build upon one another.  The references section talks about how the requirement relates to others.  If there's other resources I want to point you at they'll be in the references section as well.

1.6 Comments

This section is default on my site so please feel free to weigh in on my posts or just let me know you read it.  I thrive on feed back.  Go ahead and let me know if you think a series like this will be of use to you.

In any case, I'm really excited to get started on this (not so little) project.

Preview

Here's some of the first security compliance questions I'll be tackling to give you a taste of what's to come.

1. Are all required approvals documented for each access request or modification to a user's or account's access privileges?
2. Is authority and access to use advanced operating system utilities and commands that bypass system access controls monitored, logged, reviewed and restricted to those individuals or accounts that require access to perform the respective job function(s)?
3. Are User Ids for the application uniquely attributable to individuals when accountability is required?
4. Are access privileges granted to users or accounts in accordance with Company policy (including Segregation of Duties)?
5. Are access privileges granted to users or accounts reviewed every twelve (12) months to determine if access rights are commensurate to the user's or account's job duties and based on "least privilege"?