How Do You Spell CISO? - What's a CISO Do? part 2

   A while back I started a new job as a CISO.  It's the second time I've held that title at an organization.  What's interesting about that is that both time it was a new position to the organization.  I wrote about my initial thoughts and plans in a post here.  I expanded upon those ideas in a follow-up post here.  This post will round out this series.  They will also serve as the "outline" of a talk I'll be doing at Secure360 this year.

   For those of you who are not familiar with Secure360, it's THE upper midwest US security conference.  There's still time to register, come on out and enjoy!

   There are many demands on the CISO.  But part of the art of the position is to juggle the more granular tasks with overall priorities while trying to be strategic.

XP End of an Era or... Deja Vu All Over Again!

   Unless you just came back from time traveling, you know that Microsoft is ending support for the XP
operating system on April 8.  To be clear... April 8 is Patch Tuesday, so that will be the last set of updates for XP.  Sort of.

   XP has been one of Microsoft's most popular desktop operating systems and many organizations are dependent upon it.  Many organizations have not yet updated to Windows 7 or 8 and the clock is ticking.  I'd like to look at what that means and share a few ideas of what we can do to protect ourselves and our organizations.

   Microsoft will be stopping all patches, hotfixes and enhancements to XP after April 8.  Anti-virus signatures will continue to be made available.  This means that any vulnerabilities that are discovered or disclosed might not be fixed.  Organizations will need to figure out if they are vulnerable to any new threats and then weigh the risks associated with their options.

   There has been some speculation that online criminal organizations may be stocking up on new vulnerabilities so these can be released after the last patch date.  We can't know if this is true, but it is possible.

   So... if you are still running XP, and need to continue to run XP, what can you do?  Let's do a high-level threat analysis:

Are You a "Target"? - Incident Managment (part 2)

   I'm calling this part 2, but it's really the third in a series covering the consumer and enterprise sides of incidents and breaches.  This is always an important infosec topic, but the recent highly publicized issues effecting Target, Neiman Marcus and, as we're told, 3 other organizations to be named later brings this to the forefront.

   Many say that it's not a question of if we will suffer a breach, but when and how we will suffer a breach.  And yet there are organizations that consider this an optional capability.

   Last time we talked about the first two parts of the Incident Management program: Prevention and Planning/Preparation.

   Next is:
Communication. So these groups know their roles:

Are You a "Target"? - Incident Managment (part 1)

   It seems that every few days we get additional news about the Target breach.  There has been plenty posted about this including articles here, here and here.  And, unfortunately for my colleagues at Target, I don't think we heard the last on this.

   Last time I talked about the consumer side of the issue, and how individuals should protect themselves from the effects of an information breach.  Today we'll look at the corporate side... Incident Management.

   Incident Management is a critical part of any information security program.  I don't think there's any governance framework that doesn't include this important topic.  I'm a fan of the way NIST lays this out in SP800-61, with a few modifications.

   In boxing and martial arts, the saying goes: the best way to avoid getting hit is to not be there.

Beyond the Checklist - Compliance v. Security

   SC Magazine put out a good article last week entitled Beyond the Checkbox: PCI DSS.  The article cover new revisions in the Payment Card Industry (PCI) security standard (Data Security Standard DSS).

   The point of the article is something I've been saying for years... That we can simply treat security regulatory standards as checklists.  It's not about just meeting the minimum requirements.  It's about integrating the standards into your security program.

   Now, I'm not completely dismissing checklists.  In fact, I think they have some great places within your program.  For example: server build checklists; server hardening checklists, and; an SDLC checklist.  I'm a big fan of the CIS checklists for hardened configurations.  I also like a standardized secure engineering process (or SDLC) with specific steps.

   As I've discussed here in the past, one size does not fit all.  While we can all share our processes, it's critical to tailor any process or checklist to your environment.

   But here's my main point... Compliance does not equal Security!

Stuff I Say - Do What Makes Sense

   Today I'm continuing a set of posts I started last year.  These ideas are covered in a fun talk entitled #*%! My CISO Says, covering a range of security governance and management topics.  Slides are on my slideshare page.  The first two posts are here and here.

   The idea of doing what makes sense is central to my thinking (about many things).  In security, many people base their strategies and tactics on what they read or what others are doing.  But you can't provide useful information security based on what you read in a book.  One size does not fit all.

   When we don't do what makes sense, we end up with ineffective controls (like this ineffective control from one of my favorite security pictures).



   What works in one organization does not necessarily work in another.  This can be true for a variety of reasons including differing regulatory environments, organizational culture and kinds of assets/information.  This is why I've never liked the phrase, or idea of, "best practices".  I prefer "good practices" (more on that some other time...).

   It's easy to say we want to do what makes sense.  But how do we put that into practice in our organizations?

   Here are 2 considerations:

Risk Management approach.  Rather than using strategies and practices from a book, we need to understand a number of things about our organization including:

• what "stuff" do we have?
• what stuff do we need to protect?
• what threats do we know of?
• to what threats are we vulnerable?
• what is the potential impact if these threats manifest?

   Asking these, and subsequent, questions can help lead to a better understanding of the environment

   Then... Seek out and destroy policies/practices that do not add value!  Consider:

• ineffective controls - find them and get rid of them!  And, if you do remove a control, make sure that you let the users know!
• annoyances that effect people's perception of security - convenience v. security is always a trade-off, but your controls must take into account people's work practices
• what makes work harder - security and IT must support the business.  If complying with controls negatively impacts the business you may find your program overruled.
• overly strict practices can cause people to try to circumvent controls to get things done.

   This doesn't mean that the security organization allows a free-for-all.  My point is that by considering how users need to use the systems, examining alternatives, and working with your business partners, you can come up with a set of controls that protect systems and data, meet regulatory requirements AND allow people to get their work done.

   Can you think of ineffective or unnecessary controls in place at your organization?  How have you partnered with business users to come up with controls that meet all needs?

Multi-Factor Fail - 3 Factors of Fail (part 6)

from: brainyquote.com

   In December I was at the NG Security Conference in Austin, TX.  We had a fantastic discussion with a group of key security leaders focusing on this "quote" and how it applies to information security.  I say "quote" because there is some question as to who said this or if anyone actually did!

   As I've been saying throughout this series of posts, it seems that this statement is exactly what we are doing in the world of authentication!  None of the typical factors of authentication have really solved our authentication and access problems, yet we continue to use the same mechanisms over again.

Stuff I Say - People Want To Do The Right Thing

   In the security field we hear a lot about the insider threat.  There have been plenty of well publicized incidents of internal employees, contractors or ex-employees stealing information, or deleting information or leaving some other kind of destruction before they leave an organization   I'll cover this topic in more detail in a future post.

   While this certainly does happen, it's not prevalent.  Call me an optimist... but I think that people generally want to do the right thing.

   And this is where the problems begin.  Sometimes those who make the rules and enforce the rules just make it too difficult to do the right thing!

Stuff I Say - You Pay by the Word

   This is a continuation of a series of posts on some of my philosophies about security strategy.  These ideas are covered in a fun talk entitled #*%! My CISO Says, covering a range of security governance and management topics.  Slides are on my slideshare page.  The first two posts are here and here.

   In that second post I was talking about policy.  Traditionally many organzations have staff sign a form that says that they have read and understood policy.  Perhaps the organization has some kind of new employee orientation at which policy is reviewed.  Among the problems is that policy is usually too long and too complicated.  It then becomes a TL;DR document (Too Long; Didn't Read).  I'm sure that both policy writers and policy readers/recipients can relate to this.
   So what to do?  I like to say that "you pay by the word", because you can pay now or pay later...

Stuff I Say - No One Has Ever "Read and Understood"

   Most organizations have policies.  Most medium-to-large sized organizations have security policies.  I hope that yours does!  Policies are a cornerstone to a security program.  People need to know what to do and policy is that high-level guidance.

   Of course, people need to read those policies!

   Many organizations will have staff sign a form that states they have read and understood the policies.  Sometimes this happens just once.  Sometimes it's annually, perhaps at the same time as an annual performance review.  Sometimes it's when a person joins the organization, or shortly thereafter.

   But does that work?  What is the goal?  I say that doesn't work!  No one has ever "read and understood"!