Can information security professionals be satisfied? Ever?  Yes.  But should they be?  Ever wonder if Advanced Persistent Threats came into the world in part because the information security profession became more and more predictable?   Or worse: commoditized, as I will discuss below.

Lately, as corporate web sites from multiple industries in virtually every continent are falling prey to one attack after another, it is a fair question to ask.   Remember,  these sites include sites for  industries that  spend a lot of very serious time and money on information security.

So are we spending/knowing more and getting less?   Most security and IT governance frameworks are well beyond their second revision, ISC2 and ISACA have both been certifying us for a long time (the CISA certification is 35 years old, ISACA recently bragged), and SAS70 has been renamed/rebranded and expanded as it is brought up to date.  The regulatory framework continues to mature as well so what might have been “compliant” a few years ago is now not.

And, even stepping away from the headlines of breaches and attacks, there is nothing especially encouraging in Dr. Poneman’s findings: “Data breaches have become a fact of life for organizations of all sizes, in every industry and in many parts of the globe.”   (Always useful to drop in on http://www.ponemon.org/ if you haven’t lately).

So how do we account for this?   It’s complicated, of course, and it is not due to one particular development.   Here are the developments  I am not going to deal with:

1. The bad guys are getting smarter/more criminal (if I hear one more variation on “we’re not just facing script kiddies anymore,” I will need to break something)
2. More stuff is on-line than ever before
3. Computing power is cheaper than ever
4. There are rogue nation states where…
   1. …the laws are too lax
   2. …they encourage/support this kind of thing (they are enemies)
   3. …“we” do not have enough influence (they are not important enough to us to be allies or enemies)

What I am going to deal with are the following:

1. The commoditization and marketing of information (I mean “cyber”, don’t I?) security
2. The IT Ops lens on security and how it runs the risk of causing IT senior management to embrace security products while at the same time under-valuing security professionals (this is the staffing side of #1)

There’s a danger to only having a hammer and seeing everything as a nail, but that doesn’t mean you don’t sometimes need a hammer

Having the tools to effectively implement a good cyber security program is essential.  And there are some really cool products and services out there.  And they are effective.  But what they are effective at is, more or less, doing what they say they are going to do.  If that sounds simple—it is.  But it is also meant to make clear that what follows is not a knock on log analysis, identity management, IPS/IDS, firewalls, anti-malware, DLP  or any other product category that you can buy.   To get right to the point, I will argue that a product is just a tool and to the extent that the marketing is helping to shape the market, vendors are rarely interested in selling tools.  They want to sell peace of mind.

If, as a vendor, I can define a threat, explain what the risk it represents is and then I can define a product that mitigates that risk, then I can sell that product as more than a tool.  I can sell it as proof that the risk has been dealt with.  And who defines the risks?  Generally, an organization relies on one or more of three entities to define the risks they face:

1. Consultants brought in to do a risk assessment
2. Auditors who provide audit findings indicating sub-optimal IT Controls
3. Information Security professionals who they hire for this purpose

Technically, vendors (and here, I mean those who sell security products and services) should not define risk for the company.  But they can define the threats their products guard against.   And they will connect that to risk.

So, whoever in the organization “owns” information security risk mitigation will get their assessment of risk from a combination of the assessments of consultants, auditors, information security staff and vendors.

Not one of these risk assessing entities is what the IT department considers to be their customer so IT management is often conflicted when it deals with risk mitigation (for excruciating detail on that, see Appendix A below).  However, a “finding” of risk by any but the vendors is not necessarily welcome.  A finding means that at best you are not as secure as you need to be and, at worst, you are negligent.

Now here is where the tools are getting confused with true risk mitigation.   What IT management hears is “you have a risk”.  Let’s use malware as an example.  Ok, IT management understands that viruses are a threat and the risk they represent is various negative outcomes.   So, management buys a tool, anti-virus software, and charges the desktop/server support folks with deploying it.  When an auditor comes, the IT Executive is justified in saying: “we’ve mitigated the risk of viruses causing negative outcomes on our network by installing anti-virus software everywhere; we update the definitions every morning and we kick off full scans every Thursday”.

There’s a statement like that for every product/risk pairing and if you collect enough of them, you can  convince yourself (and others) that you are not only running a secure environment, but your protections are dynamic—your virus definition files are updated, your vendor is always looking for threats and updating their list of known bad URL’s, e-mail addresses, whatever.

Vendors understand that their strongest value proposition is enabling decision makers to make these product-controls-risk statements.  And Information Security professionals within an organization are always tempted to endorse such statements because they want to convince executives to invest in these tools.   So while vendors might or might not overstate the extent to which a tool mitigates risk, to justify the expense of buying the tool, internal staff are tempted to.

In short, the market has developed such that for most risks, there is a product that lines up with it.  If you can name the risks, you can then buy the products and you’re all set.    There’s even a variation on this where products are listed as compliant, not with standards which would be legitimate, but with regulations, even those that do not have standards attached.

And this is where CIO’s are perhaps beginning to question the value of Information Security professionals.  After all, if my department’s strength is deploying and contracting for products and services, and if risk mitigation is reduced to just deploying and contracting for the appropriate products and services, then why not let the vendors tell me how to describe the threats I’m combatting to mitigate the risks I face?  Or let the auditors tell me what I have to buy next? (disclaimer: this is based on conversations I’ve had with other IS professionals and vendors and is in no way autobiographical.)

At this point, the Information Security professionals are jumping out of their seats waving their arms and screaming “but…but…but”.  Yes, we’ll call on you in a minute colleagues (I am one of you after all).  But let’s finish the thought first.

Security as a service (SAAS) would seem to complete the commoditization of cyber security risk mitigation and also, the complete marginalization of the information security professional.  The organization can have tools, it can have trained staff to use those tools and it can run security the same way it runs the other services in the IT catalog.

Let’s go back to the two questions  I raised at the beginning of this post: should the information security professional be satisfied and are we getting our money’s worth in general in the marketplace of security products.  Above, I have tried to show how these two questions are tied together.  The answers are:

1. No, the information security professional should never be satisfied and
2. Yes, you are getting your money’s worth but you are not necessarily buying what you think you are buying

Tools are controls and controls mitigate risk, but when you commoditize controls, you are still not commoditizing risk.  And so buying the tools does not translate into transferring the risk to anyone.   The enterprise still owns it.

We must learn from the world of lending and insurance: you can only commoditize risk when you can pool it and quantify loss.  And if you thought detailed comparisons of encryption algorithms were complex, try talking to an actuary about risk pooling.

Studies show that “just about everybody” has experienced an information security incident at some point.  Some large enterprises have been public about it.  In health care, large (500 identities and greater) privacy breaches are, by law, reported to the Federal Government individually and posted on a website (occasionally these involve paper records, but the majority of them involve EPHI– electronic protected health information).

So, unless you sell cyber incident insurance (i.e., you ARE an actuary) it is time to stop talking about risk mitigation in terms of the tools deployed.

This is where the information security professional needs to be the most dissatisfied, the most insistent that the tools are necessary *and* insufficient.  And this is where the professional must be the most vocal.  This is the value that only information security professionals can add to an organization.

This is the point from which the conversation needs to be  restarted once the existing controls are inventoried.  And that conversation goes something like this:

Control objectives and the sufficiency of existing controls can minimize the likelihood of certain negative events, but the events are still possible, regardless.  The information security professional’s job is to

1. define those control objectives on behalf of the enterprise
2.  assure that the existing controls meet those objectives (up to and including managing the staff that runs those controls)
3.  describe how the objectives cohere as an enterprise-wide strategy
4. create the procedures and environment/culture within their organization so it is prepared for when those controls are not sufficient.

That, or you can just buy another firewall.

Appendix A—a narrative view of information security control procurement

Almost all of IT is based on delivering service.   Service, the IT professional understands, is giving the customer what they want, when they want it, how they want it.  Using a framework like ITIL we might say “delivering Customer specified Outcomes”.  In its simplest form, this service delivery from IT has evolved into making sure that hardware and software are up, running and working without interruption.

So let’s compare an IT service with an Information Security Control, which superficially look the same: internet access from within the company.  The IT Ops provider installs a set of routers and switches that, via wires, will carry the Customer’s internet requests out to an internet service provider and return responses.  The faster it runs, the happier the Customer.  Did you want “security” with that?

Hell yes, says the company, give me some of that “security”.  I’ll take two of those firewalls (I want a D-M-Z) and one of those Intrusion Protection Systems.  Plug ‘em in, give ‘em power, create some rules and we got “security”.  The installation and deployment of these firewalls and IPS appliances is done roughly the same way as the routers and switches, using the same change management and product management methodologies.  And the vendor is all too happy to provide recommended settings for the company.

Most of the time, recommended settings will work for routers, switches, firewalls and IPS’s.  When they don’t from an operations standpoint, a business need will not be met.  The Customer will not be happy and then a port might need to be opened or something added to an access control list.   But from a security standpoint, the Customer won’t notice an open port they’re not using.  In other words, there is immediate feedback from Customers when the Operations side makes a blunder deploying products, but the security side only gets immediate feedback if they prevent something from happening that the business needs to work.

So the information security professional says “let’s have vulnerability scanning and penetration testing to ensure there are no vulnerabilities we don’t intend.”  The information security professional knows that this does not mean the network is   invulnerable—only that they have only left open what they need to leave open in order to facilitate business operations and closed off what can be closed.

And so, that leaves the risk that an attack comes in through an allowable route.  To mitigate that risk, the information security professional knows that they need to filter content.  Then you need to train your users to recognize the exploits that still manage to get through.  Then you need to….

And the point here is that since the drivers for these products and services are not directly IT’s day to day customers, this “narrative of needs” can have a hard time competing with other IT initiatives.  In other words, if you’re just trying to sell products to your organization that appear to fine tune the mitigation of risks they already thought they mitigated, you run the risk of losing your audience.  It’s tricky.

But, the other side to this “narrative of needs” is well known:  name an area of Information Security Controls and we can tell a similar story.  Identity Management, log analysis, anti-malware, etc.   And since the narrative of how a control gets deployed is a story that can be told, hackers ensure that we always need a sequel.