Model for Building PCI Control Objectives

Posted on 2 November, 2010 by Daniel Blander

Maybe it’s the excitement of getting re-Tweeted today, or maybe it’s just the outpouring of love and emotion I felt when I watched the video of the Mike+Josh hug, but I thought I’d provide a bit more thought around how to build these Control Objectives for PCI.  That and the fact that I live by the motto of taking “Massive Action” whenever I sink my teeth into something…

My intent is to demonstrate three things:

a)      Control Objectives can be linked to a business objective or goal

b)      Prescriptive Controls can be abstracted to Control Objectives (with some effort)

c)       There can be rational behind both Control Objectives and Prescriptive Controls that once explained can result in better management support, and potentially more creative design.

My objective is not to co-opt this discussion, but rather to feed the debate with ideas.  It’s great to see this level of thought being spread in InfoSec, since I too often have listened to the bits and bytes battle in the boardroom, and that situation doesn’t end well.  If we can create meaningful discussions around the end goals and spread the knowledge top-to-bottom, we can begin to socialize the objectives of PCI so that ideas can come not just from technologists and (shudder) vendors alone, but actually come from a much broader spectrum – which leads ultimately to greater support and buy-in at executive levels.

The Guinea Pig Control

I’d like to take a simple example since it is very fresh in my mind, and it allows me to demonstrate the technique.  Let’s look at PCI Requirement 8.5.16.  This control is oddly grouped with other 8.5.x requirements but create a pretty significant challenge for many organizations I’ve talked to.

8.5.16 “Authenticate all access to any database containing cardholder data.  This includes access by applications, administrators, and all other users.  Restrict all direct access or queries to database to database administrators.”

Now in the PCIHugItOut they mentioned the document “Navigating the PCI DSS” document from the PCI SSC as a starting point, but rightfully point out that it doesn’t go far enough.  The Guidance from the document states:

“Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system.  Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except DBAs, who can have direct access to the database for their administrative duties.”

Unfortunately the statement is not particularly “guiding”.  As a technologist you might look at it and say it is a great guiding statement.  What you are doing is applying a priori assumptions about logging user access when theft occurs or for the purposes of forensics or theory about limitations of database select statements.  What you are also doing is sidestepping the problem – management lacks that cognitive awareness, and it is highly unlikely they will care to invest their grey matter in changing that situation.  Your assumptions will be left trampled in the boardroom floor.  Trust me when I say that this one small control can create a firestorm when users (marketing, finance) are told that they cannot run their Crystal Reports or ODBC queries against their database that just happens to contain Payment Card Data.

The Control Objective Example

So let us give these people a reason why they can’t delve into the database ad-hoc.  I am going to assume the same model that I have used for years when building SOX Control Matrices:

Threat: Theft of Payment Card Data

Vulnerability: Lack of controls that limit the ability of users to collect/transfer/misappropriate Payment Card Data from locations where it is appropriately (securely) stored.

Risk: Users may collect Payment Card Data from secured repositories (either one-by-one, or in significant quantities) and either (a) store it on insecure systems which exposes it to inappropriate activity, or (b) misappropriate the Payment Card Data it for nefarious purposes.

Outcome for the Business: if Payment Card Data is placed on unsecured systems, it increases the risk posture to the company, by creating in un-mitigated risk.  Any compromise of this mismanaged data must be reported publicly (most state/local privacy disclosure laws) and can result in fines, and the company being on the evening news (or daily podcast for the technologically evolving masses).  Because this “uncontrolled data” now becomes virtually impossible to manage and track, the likelihood that it is misplaced, and the company must report it publicly rises exponentially.  Focus is not just on unauthorized data but data that is also accidentally misplaced (example – TSA laptop with personal information that created a stir when it couldn’t be found and the loss had to be disclosed by law).

Control Objective: Ensure that the ability to transfer Payment Card Data from databases is appropriately controlled in a manner that prevents the transfer of such Payment Card Data to unapproved and unsecured locations or environments.

Now, given this control objective companies could have the choice to either:

(A)   Follow to the letter of the law DSS Requirement 8.5.16 (although this is a slightly less prescriptive control than others in the DSS).

(B)   Present to the QSA the manner in which you feel you have met the Control Objective in a manner that achieves the same goal (to give you an idea – perhaps row level ACL’s that prevent access to actual PAN data by anyone who can log in directly, or tokenizing databases that users directly access, or completely eliminating the ability to store the data locally by using a terminal server for producing these types of reports or data).

The Outcome

What this has done is given a business view (Outcome for the Business) that most executives can understand.  You might need to give some real-life examples from their personal lives to make it meaningful and associate it with concepts that are in their cognitive realm (have them think of handing out their credit cards to their kids, or car keys to a valet and the resulting risk they know exists for those “assets” to be misplaced when they are in someone else’s hands).  You have also give an implementer a framework to evaluate how a control should fit, and decide if the PCI prescriptive controls are satisfactory for him.  The implementer will have to justify to his management his choice of alternative controls, and depending upon his savvy or guile, he will either succeed in alternate (more effective, more efficient) controls, or he will find himself forced into the default PCI prescriptive control.

The Challenges in All of This

There are a few challenges here that we must face as well.  Some can be easily overcome, but others will be subject to massive forces of economics and politics.

First, the Control Objectives will overlap with the prescriptive controls of the DSS.  The example shown above overlays with 12.3.10, “personnel accessing cardholder data via remote access technologies”.  This isn’t a problem for those of us who have played with Control Matrices for some time, so this can be easily overcome with good minds, careful thought and creative mapping.

Second challenge is that most companies and QSA’s will view this as a troublesome approach.  The process proposed is no different than the current process of “mitigating controls” but this process currently has a culture around it of being discouraged.   The cause for this is, in my mind, because it results in more work for the QSA’s.  With QSA services becoming a commodity these days, it isn’t attractive to customers looking to save money on their assessment.  Likewise QSA’s trying to increase profits will not likely steer from what will give them a price advantage when they can test against prescriptive controls.  Like all good plans both parties will digress into the world of loopholes and exemptions to satisfy their own motivations.  I don’t have a good plan for this except perhaps my original idea of encouragement and reward for maturity by the Card Brands which can potentially raise the interest of management.

Thirdly, there will be a challenge with the inevitable question or view “well, it hasn’t happened to us”, “how real is that”, “well TJMAXX did just fine after their break-in” (which from a shareholder point of view is actually pretty accurate).  I love this one since I have faced it – especially a CEO who challenged me on TJMAXX’s stock price a year after the infamous break-in.  My response is calculated but the same.

“We are discussing a balance between risks which could impact your company (paying $250M in fines which no CEO wants to shell out, no matter how much his stock price might stabilize or grow) and functionality which your users need to grow the company.  If you will provide us with the support, we will design a set of controls that will achieve a balance between the two that we believe both sides will be happy with.”

Please note no effluence of FUD, no criticism of user’s desires or business goals.  Just a confident statement that there is a need to balance the two demands, and to come up with a solution that works for both.  Now, you just have to deliver on that promise…

Posted in CISO, CSO, Information Security, IT Risk Management, PCI | Leave a comment

Moving Beyond Compliance – Commentary on PCI-Hug-It-Out

Posted on 1 November, 2010 by Daniel Blander

I finally got around to listening to the Tripwire sponsored, Martin McKeay and Gene Kim hosted PCI Hug It Out with Josh Corman and Mike Dahn.  If you haven’t heard it, you should.  Two very smart people (well four actually, but two we are focused on) talking about PCI and the challenges it faces as a standard.  http://www.tripwire.com/blog/compliance/pci/pci-hug-it-out-the-hug/#PCI

There was a great theme that came up from Josh Corman’s section, and I hear something that I believe in strongly – moving beyond compliance, and my favorite question, how do you move beyond it.  The discussion goes into how compliance is a stick (or the fines associated with it), and asks what could be the carrot?

I’ve got some ideas…

First it requires a change from the Payment Card Brands (and maybe the PCI-SSC).  It requires that they think the carrot model can work, and they are willing to come along for the ride.  They must be willing to give rewards when companies exercise maturity, evolution, and creativity that exceeds expectations.  Maybe make the reward an additional reduction in transaction fees for the increased reduction in fraud costs.  These are rewards that a company will look for – and I recall back in 2007 the Card Brands decided to extend rewards to companies who complied.  Maybe it is time to revisit this strategy.

Second, it requires a different model for the standard; a model that is based on control objectives (as Josh and Gene discuss).  The objectives need to show the business (not just IT or Information Security) why these objectives are important to a business.  This model would need to be forged out of the PCI SSC and its various working groups so that the reasons behind their choice of controls are clear.  It needs to tell companies “WHY” they need to do these things, and not just in FUD terminology.  The objectives need to be put into business terms – which is far beyond what the “Navigating the PCI-DSS” does now.  I would point at HIPAA as an example.  One of my favorite controls is the requirement that medical records must be capable of being restored in 24 hours.  I point out to my customers that this is about the timely treatment of a patient and availability of their records to a doctor who must treat them.  An IT problem put into business terms.  In terms of PCI, this information is lacking.  I just need to reflect upon the times customers have asked me about a strategy for a “mitigating control” to recognize the value in this.  In these cases my best answer came from analyzing the DSS and finding out what the objective was, and was it being achieved with the customer’s mitigating control.  Not all the controls are so easy to understand or abstract and I have struggled in several cases to give an answer with a straight face (Why do we need to label every device in an organization with a contact and its purpose?  I’m not etching my iPhone’s purpose on its already fragile case and antenna!)  The process of abstracting the current DSS controls is not an overly difficult exercise, except that it tends to highlight the not-so-bright choices in controls, and biased choices not based on empirical facts.  It also tends to highlight when certain parties have ulterior motives (such vendors pushing their solutions).  If Josh, Mike, Gene or Martin would like to find good candidates to do this work, they need not look any further than the auditors and assessors who work in SOX every year.  They have had to struggle through this work for at least seven years now and have gotten pretty good at building control objectives and building logic behind it.  I believe Gene has also published a paper on the framework for this that is intriguing, and should get everyone’s support.

Third, I would recommend that success in compliance not just be achieved by creating controls to meet an objective but by sustaining maturity of the controls put in place to achieve that objective.  Imagine if you will that the Payment Card Brands awarded lower per-transaction-fees to companies that demonstrated a higher level of maturity in their controls.  Maturity meaning a process of continuous improvement – based on CMMI, OCTAVE, and any other highly relevant process of improvement that is seen as useful.  Now we get at what I think the Hug-it-Out was talking about when they said “It’s like raising children.”  Give them rewards when they grow up and mature the right way.

Fourth, it will require greater maturity on the part of the QSA’s.  Forgive my rant on this point, but in order to effectively evaluate elements of security posture such as maturity and achieving control objectives, you need a significant amount of maturity from the assessors.  This comes from twenty-two years in the industry watching my clients suffer through the opinions (or lack of opinions) from auditors and assessors for whom the ink has barely dried on their diploma.  I fear the QSA market is too immature to sustain a solid model of maturity.  I wish (hope?) this was different.

With these four steps, you have made it much clearer to companies the concepts you want them to comply with.  You have given them incentives (carrots) to lead them along, and made the process to reach those carrots one that requires maturing, learning and growth.  You have asked them to think about their business, think about the risks and goals, and start to include them in their business planning.  Companies need to recognize that PCI-DSS compliance is not an IT or Information Security challenge; it is a challenge for a company’s process of Revenue Recognition, Fraud/Loss Prevention, and Company Image/Reputation.  Now we are talking in terms that the C-levels will understand.

If you don’t include this, all the data and evidence about what works and what doesn’t will still be meaningless.  It has to have meaning for companies who fall under PCI Compliance, and it has to align with their goals.  This is why I feel, like Josh, that a risk based approach would be so much more effective.

Josh, Mike, Gene, Martin…thanks for this podcast, and please keep this movement going.  I’m game for it!

Posted in Information Security, InfoSec, PCI | 1 Comment

The One-Hundred-Zero-Fifty Rule

Posted on 29 September, 2010 by Daniel Blander

I had a employee in a security department that I was running come to me and say “We have a problem, and we need to take care of it right away!”  Now we were in the midst of several major compliance initiatives, re-evaluating the business continuity plans, and basically trying to take on everything at once.  Oh, and we only had three people to do all of this.

My answer to him was quite simple: “We can do five tasks right now.  Here are the five that are our current priorities…..tell me which of these is less important than the problem you found.”  He thought for a second, and said, “Well, none of them.”

We all struggle with what we think is urgent.  Like this employee, we all (myself included) tend to be distracted by the issues that present themselves to us at any given moment.  The real problem comes when we let these “distractions” take over our real goals.

Now lets enlarge this discussion to Information Security company wide.  Too often I hear consultants, security engineers, and employees (usually in the Security Department) complain that “our company just doesn’t get security” followed by a long lecture on the things they don’t do and the long list of things that the company should do.  At the risk of sounding trite, I would suggest that they stop (or have someone stop them…call me, I’ll do it) and ask themselves the same question, but on a larger scale.

“Of all the things that the company needs to do to be secure, and given all the limited resources at my disposal, what can I do?”

This plays out in my One-hundred-Zero-Fifty Rule:

Part I – The One-Hundred Theorem: There isn’t a company, organization, government agency or person who has, or who can have every security risk covered.  No one is at 100% security.  Not only could no one afford 100% security, but emerging threats wipe out 100% security before you’ve even finished getting your purchase order signed, and companies couldn’t survive with 100% security since it would make operations virtually impossible.  There is not an executive anywhere who would accept 100% security since it would make the transmission of information impossible, the ability to offer goods and services rigid and unable to change, and the operations so cumbersome that labor costs alone would go through the roof.  Business cannot accept 100% security since, I dare to say, it smothers business.

Part II – The Zero Theorem: Security professionals who try too hard (use revolution) end up at 0% security.  Any security professional can tell you a story of a company, organization, government agency or person they know who is not very good at security.  The right tools are not in place, people are not doing their jobs, and no one is aware or trained.  So clearly these companies need to be educated.  Yet I have unfortunately walked into too many of these companies after a security professional has taken on this task to find that these security professionals have high expectations of getting to their goal-line in a year (“Or maybe in two because there’s a lot of work to do!”)  In some cases I have gone into smaller companies to find a security professional from a big company (bank for example) who thinks the same processes, tools, and methods apply.  I’ve talked in my writings here and in my lectures about security awareness that moving people from zero knowledge to a secure organization is a cultural and behavioral change.  Culture and behavior change does not happen overnight (Revolution vs. Evolution).  Too many people try revolution.  Too many people try to impose one model where it does not fit.  Square peg, round hold.  The efforts usually fail because they alienate those they need to appease – executives, the business, and everyone who needs to implement security in their jobs (that would be everyone – don’t worry, I’m still a security professional).  The result – no budget, no support, no security.  Any tools or processes they have put in place are in shambles because they have no support.  The very thing they wanted to achieve is not achieved because of their tactics.  So rather than racing toward their goals of good security, they stay at 0%.  Hence why I have my second theorem.

Part 3 – the 50 Theorem:  Settle for 50% because its better than the alternatives. Since we cannot get to 100% security, and because revolution and ill-fitting methods kill any support for security, what alternatives are available?  Well, how about somewhere in-between.  How about setting some simple expectations.  How about focusing on basics (call it blocking and tackling).  How about just getting simple security started; the things that any common sense person would do to protect the company; things that sometimes seem too obvious; things that answer the needs of the business and what keeps them up at night.  Take the next step and build on the basics you just achieved, then when that is done, evolve some more…

I found my favorite term for this situation from the movie “What About Bob?”.  Richard Dreyfus’s character Leo recommends that his patients take “Baby Steps” to solve big problems.  I use that phrase all the time…just take baby steps.  Stop trying to solve the whole problem at once.  You may know how, but the organization, business, government agency or person is not ready for that.  Show them how you can make them sleep better at night with basics (making simple things like anti-virus work better and having less impact on performance, or how configuration standards help improve reliability of systems).  Watch them start to trust you because you make progress that impacts what they care about.  Take them on the journey with you with Baby Steps and show them they can move forward.  (And oh, how proud Bob would be of you!)

So the one-line version of my One-hundred-Zero-Fifty Rule:  I would rather be at 50% security because 100% is unobtainable, and 0% is unacceptable.

Remember, you really have two alternatives – 50% or 0%.  Pick the one that is better for you.  It shouldn’t be too hard.  You can always get to a bigger number later.

Posted in CISO, CSO, Information Security Governance, InfoSec Governance, IT Risk Management, Security Governance | Leave a comment

Revolution or Evolution, Part II

Posted on 17 September, 2010 by Daniel Blander

The Security Officer I met recently told me in his “old age” he now knew that the key to security in an organization was Evolution.  Engage evolution.

But what does evolution mean for us InfoSec professionals? Well, I’m going to be bold and propose a check list – a sort of evolutionary progress list.  Each step in this list must be preceded by the previous step, so no rushing forward or skipping a step because “Its not convenient”.  Each step must be maintained, so you can’t back-slide or forget about something because its no longer needed.  Each step is part of the foundation, and builds the mountain higher.

Here they are:

  1. Know your company – its goals, operations, plans, initiatives
  2. Know what keeps everyone in your company up at night
  3. Understand what things are relevant to each group in your company
  4. Accept the businesses perception of the world
  5. Put your thoughts of how security helps the company in plain, 6th grade English.
  6. Interject some of your ideas on risks, making sure they overlap with the things the business worries about
  7. Ask for acknowledgment of your concerns as you acknowledge the concerns of the rest of the company

You are probably looking at this list and saying, “Okay, you are crazy.  Where are firewalls, where are Risk Assessments, where are vulnerability scans, ISMS, ISO 27001, OCTAVE, DLP….(insert your favorite security subject here)…”

My answer is, “Precisely”.  Security should not be the focus of the evolution.  HUH!?!?!  Yes, get off of your technology, off of your Fear-Uncertainty-Doubt, and off of your idea that security is what keeps the company going.

First, know that security is a process inside another process – an operational process, which is inside a bigger process – the business.  Trying to make security a macro-process that drives the organization puts the cart before the horse, and a type of thinking that we as InfoSec professionals perpetuate to our own detriment.  Security is not the core of the business.  Security is not the part of the business that directly provides revenue.  (Think, does your security group provide a revenue stream for the business?  Security product vendors, consultants and MSSP’s – think of your operational CSO vs. the products and services being delivered to customers.)  Delivering products and services for a “fee” is the core of the business.  A business is made up of many parts, and each one contributes to the business – marketing, finance, shipping, sales, manufacturing, product design.  Without one the others can fall apart, but one alone cannot drive all the others.  Each has their role, their tasks, and their objectives.  Each one needs to understand their role to play, and how they fit into the larger picture.  Once we as InfoSec professionals acknowledge that we are one piece of the overall plan, we can start making real progress.

Second, If we do not know what the business wants to do we can’t know what we need to protect or how to provide security that promotes the goals of the business.  If we cannot provide security, the added value of security in the company’s goods and services cannot be delivered.  But does that necessarily stop the company from operating?  Given that so many companies lack good security, it clearly is not the case.  Companies with bad security thrive, and sometimes the level that the thrive at greatly exceeds the break-ins, breaches, and thefts that occur.  If this is the case, no one seems to care.  When you have a box of one thousand pennies and you drop a few, do you care?  Some people’s pennies have a little more shine to them, but the psychology is the same.

Third, the scope of security is not just IT.  I will use one point in ISO 27001 as a jumping off point.  According to the standard, the first steps of building an Information Security Management System (ISMS) is to define the scope of the ISMS.  How would you define this scope?  A network security person, if asked to define the scope will define this by the boundaries of the network.  An IT security person if asked will define this as the computers, applications, databases, networks and devices being used.  A CEO, if asked this question, would define the scope as the entire business.  That is of course if you ask him the right question;  “When you think about risks, what is the scope things that you would consider?”

Fourth, consider how the costs of your initiatives affect the overall goals of the company. Your new application firewall or the work around a new compliance requirement might take away money needed for payroll, or for the new product line that the company desperately needs to put out to keep up with the competition who seems to be pulling away. A new requirement you want for websites might result in a reduced customer experience because it takes them four more steps to complete a purchase and they decide to go somewhere else that has figured out an easier way to do it, or will do it in an insecure way.

Now hopefully those seven steps seem a little bit more relevant.  More relevant because those seven steps help you look at the entire business and realize Information Security has a key role to play, but only if it is playing in the business.

Align yourself with the objectives and goals of the business.  This will help you focus your efforts on things the business will appreciate, and can contribute to revenue recognition.

Know what risks everyone thinks about because some of them may surprise you.  Not everyone thinks security is limited to IT.  Some people are aware of industrial espionage, social engineering, physical security risks and fraud.

Think how security can contribute  to the quality of the delivery of products and services.  Security can increase the effectiveness, and sometimes the efficiency of the delivery of the products or services.

Understanding the business, its goals, the perceptions of customers and the real effect of security on the business, operations, sales and revenue recognition is the key to moving security forward.  Make security something the CEO can wrap into his business plans, and he listens to you like a trusted adviser because you know and listen to him.

Posted in Uncategorized | Leave a comment

Revolution or Evolution

Posted on 3 September, 2010 by Daniel Blander

I recently had a meeting with a well placed Security Officer.  He made a comment that I thought really summed up the view that I hold as well regarding transformation of Information Security at a company….

“When I started working in Security I said – `we need a revolution’.  Now I know it is best to have an evolution.”

Lets think about this.  Revolution is, as defined by “dictionary.com”,

1.  an overthrow or repudiation and the thorough replacement of an established government or political system by the people governed.

2.  a radical and pervasive change in society and the social structure, esp. one made suddenly and often accompanied by violence.

We as human beings hate change, especially markedly drastic change.  Our dislike is typically based on a fear of the unknown, a comfort in the known, and a desire to control our fate through pursuit of self-preservation up through gratification (think Maslow).  If change is presented to someone their response is often to ask “What is in it for me?”  This is not necessarily a pure expression of greed, but more accurately a desire for self-preservation, preservation of one’s environment and comforts, and gratification at some level.  This dynamic applies equally well in our personal environments as well as our professional environments.

When we, as Information Security professionals attempt to make changes in an environment we typically seem to ignore or be ignorant of this dynamic.  We also seem to forget that each person has their own view of what is important for them – what provides them with the feeling of comfort and gratification.  Anything that threatens this drives them back into a self-preservation state which is typically primal and can be somewhat irrational (lower order thinking).

As Information Security professionals, we don’t view security as a change, but rather something “we should be doing!”.  Our thoughts are filled with risks, vulnerabilities, and anything we might have learned at the most recent briefing or hacking class we attended.  Our desire for gratification comes from our desire to “…protect this company from bad things…”, to quote a security manager I one knew.  I want you to notice something – we as Information Security professionals think about Information Security from the point of view of an Information Security professional.  Information Security professionals think of risks to Information Security, threats that could incur the risk, vulnerabilities that make the risk possible and on, and on….the items in our cognitive domain are all about Information Security and risk.

Now, lets visit Daphne in accounting.  If we look at the things she is thinking of and the things that are in her cognitive domain, we will find thoughts of “accounts payable, tick-and-tie, three-way-match, payment terms, and how do I move up the company ladder”.  Do you see anything here that matches what an Information Security professional thinks of?  (Please note, I realized some items might be relevant to financial data integrity, but play along with me here Mr. and Ms. Auditors, okay?)  Daphne in accounting has her focus on the environment of accounting.  Do you think she will care about a Revolution in Information Security?  Its not relevant to her, not part of her environment and since she is presently unaware of it, introducing into her environment via Revolution will be seen by here as an intrusion on her stability, her environment, and possibly an interference with her attempts to become more efficient, get better at her job, and move up the company ladder.  She doesn’t care about something new if it interferes with her goals and what she thinks is relevant.

So the “Revolution” that Information Security might want to impose would be viewed by Daphne as interfering with the things that give her gratification and comfort.  It distracts from her job, new controls might even make her change the ways she does things which will slow her down and make her job harder, and ultimately may affect the promotion she has been looking forward to.  Is that true?  I couldn’t say, but does Daphne believe it is true?  That is the question that matters.

Violent change typically meets violent resistance.  There is an amusing exercise where someone will ask another person to hold up their hand, and then they will push against that hand.  The first reaction is for the other person to push back.  But they were never asked to push back!  Its called “Resist – Persist” (Jack Canfield & Tony Robbins demonstrate this frequently, and I demonstrate it with my kids when they pick on each other).

How do you overcome these tendencies?

Evolve.  Engage evolution.

Think about these words, and I will discuss them more in my next post:

  • Relevance
  • What is in it for me?
  • Baby Steps (from “What about Bob?”)
Posted in CISO, CSO, Information Security, Information Security Governance, InfoSec, InfoSec Governance, IT Risk Management, Security Governance | Leave a comment

In the beginning…

Posted on 21 August, 2010 by Daniel Blander

…there was a goal of teaching people how to communicate, interact, and learn from each other.  When I wound up in InfoSec and IT Risk Management, my goal evolved into communicating to InfoSec professionals – IT Security Managers, CSO’s, Network Security Managers (bleach! I hate that term) – that there are good ways and bad ways to approach, communicate and manage information security.  My “Great Crystallization” in InfoSec came at a round table with nominees for the Information Security Executives of the Year held in Orange County, California in 2008.  The question (loosely recalled) was asked, “why are executives not giving information security the attention it needs?”

Somehow the previous conversations that afternoon led me to recall a small ignored fact from a highly publicized incident.  Only a year or two before the infamous TJX credit card breach had occurred.  Everyone in the InfoSec space rallied around this news as the battle cry for greater security, and “see what can happen!”.  We all watched the costs escalate, and watched analysts speculate the costs had risen over $150 million USD (and eventually to over $200 million USD).  In all of this saber rattling, we failed to watch an important metric that for some reason seems to matter to some important people (executives, board of directors).  One year after the break in, despite our usual predictions that a break-in of any magnitude can ruin a company, TJX’s stock price was higher than immediately preceding the disclosure of the incident (1), and that its sales numbers were up.  Hmmmm.

My mouth opened, I related this story to my peers, and there was an awkward silence.  (This still happens today.)  I then pulled out my soap-box and started my suddenly discovered passion for anti-FUD, business collaboration, and the effective ways to make InfoSec and IT Risk Management relevant to executives.  My soap-box is still out, and I’m still standing on it.  Just now my soap-box has a keyboard attached to it.  I just hope some InfoSec professionals see the benefit of visiting me in the middle of the village square every so often.

So this blog is really about how I’ve seen companies successfully convince business owners, executives, managers, and even the employees that information security is relevant.  I’ll post on a monthly basis some of my formal research, relevant stories I have, and some musings that may come in handy.  And don’t worry customers, I won’t reveal any secrets, but I can’t help if the situations might resemble a conversation we’ve had.

—————–

Footnotes:

(1) http://www.cioupdate.com/trends/article.php/11047_3732346_2/TJX-Demonstrates-Data-Protection-Doesnt-Matter.htm

Posted in CISO, CSO, Information Security, Information Security Governance, InfoSec, InfoSec Governance, IT Governance, IT Risk Management, Security Governance, Uncategorized | Tagged | Leave a comment