Meet the Bloggers Twitter BTSecureThinking YouTube Channel Blogroll About BT Looking for more?
BTSecureThinking Resources center

Posts tagged - PKI

Friday, November 18, 2011

There is no ROI for Security

By Toby Weir-Jones, Vice President of Product Development, BT Counterpane

We’ve heard that many times, probably just as many as we’ve seen attempts to prove the statement wrong.  Like car insurance, there is no incremental ROI in the literal sense.  You don’t see your wallet get fatter as a result of buying a policy.  Remember what insurance is for, however:  it provides a fixed payout on a variable risk.  Your premiums pay for coverage up to a certain amount (the fixed payout) which you can access in a wide variety of circumstances (you hit someone; someone hits you; your car is stolen).  There is non-monetary value to be found in the knowledge that your policy is in place and up to date.  You don’t need to squirrel away funds for a rainy day, so you can use that capital for other purposes.

In the information security space, we invest in technologies which hopefully improve our organizations’ ability to respond to unknown threats.  We evaluate their effectiveness by combining increased visibility to the types of things they control with some kind of commercial assessment of how important those things are to our businesses.  IPS tells us what kinds of known exploits or other malicious activities are on our networks; our knowledge of whether our networks are vulnerable to that activity tells us whether it is helpful information or not.

CISOs need to focus on seeing combined benefits across their projects, ideally by having them all feed into a common reporting scheme.  For example:

A large enterprise has deployed various technologies across the estate (PKI, secure messaging, IPS, next-gen firewall, monitoring, scanning).  Each of those activities generates its own reports, highlights benefits/errors/exceptions, and generally chatters away on its own. 

Next year, the Board indicates that budgets need to be trimmed 15%.  How does the CISO respond?

You can’t authenticate 15% fewer transactions

You can’t sanitize 15% fewer messages

You can’t deploy 15% fewer IPS signatures

…etc. 

Historically what we’ve seen is stretching out the lifecycle of deployed technologies, so instead of replacing something on a 3-year cycle, push it to 4 or even 5.  And, inevitably, the plans to increase headcount feel pressure.

But the other area, which is perhaps hardest to measure, is suspending new projects.  So perhaps the original plan had called for replacing the message hygiene, IPS, and FW platforms with new UTM capabilities.  If the budget pressure can be met by suspending that, it’s likely the project would be deferred, even if OpEx increases as a result.

And that’s the crux.  Quantifying benefits derived from security investments is difficult, much like quantifying benefits from auto insurance, if you haven’t had to file a claim.  But continued spend on maintenance as a ratio of technical capabilities realized is unavoidable, and a useful starting point.  You need to be honest about those capabilities, since obviously you could be entirely self-serving in reporting the model, and every firm will have a ratio which is right for them. 

But that gives us the common reporting scheme I mentioned at the start.  For any given product category, its features will fall into one of a small number of buckets:

1)       Obsolete

2)       Industry-comparable

3)       Unique/vendor-specific

Anything on this list needs to be individually demonstrable.  So if a mail hygiene system has the ability to remove viruses and malware, you have to be able to measure both the number of such items removed, and what percentage of the total that number represents.  If it can’t be measured, it can’t be treated as a discrete feature on the product. 

Each of those will, in turn, have a utility value for the individual enterprise.  I would suggest using a scale of 1-4 would be appropriate, where 1 is the least useful and 4 is the most.

The sum of each feature’s category and utility values gives you a broad view which you can plug into the ratio with corresponding spend.  And it separates you from worrying about how to quantify benefits only when catastrophic events occur.

CISOs are among the best-positioned to drive schemes such as this into the corporate rhetoric.  They can avoid the impassioned defense of individual vendors by focusing on product categories first, and they can frame the results in commercial terms to other members of the senior leadership team.  This isn’t a scheme to provide an exhaustive analysis, it’s a rough-cut sorting mechanism to provide one incremental level of improvement over how to present value equations to peers.

Friday, August 13, 2010

Five Common Myths of Unified Communications

By Douglas Drew, Christopher Heinz, Senior Consultants, BT

Information technology is fundamentally about enabling business communications. Yet when business owners consider a technology to facilitate this process, they often face resistance from the information security team.  Open communications and information security are diametrically opposed.

Tremendous power and capability are to be gained with the deployment of a Unified Communications and Collaboration (UCC) solution.  However, a lack of clarity around UCC needs and their security implications can hinder the deployment.  The issues may not be as clear as they would seem on the surface — we’ll call these the “myths” of UCC Security challenges.

Myth #1: We have to open the firewall up too much.

When considering deploying a UCC solution, the conversation often ends at the firewall.  “I will not be able to open 10,000 ports” seems to be a common response, albeit a simplistic analysis.  In an ironic twist, more effective communication between the UCC team and security personnel reveals that those ports are only open to the UCC server.  That permits the deployment of the UCC server within the DMZ and the access controls to limit those open ports to a single server or pair.

Myth #2: Those 10,000 ports are always open.

Those ports are dynamically opened during the call set-up process and are used for the streaming of media.  That means the number and allocation of ports varies during usage, since ports are only open during an active communication session.  Ports are opened on an “as needed” basis, so the claim, “10,000 active listeners,” just isn’t so; reducing available attack vectors dramatically.

Myth #3: UCC communications should be run across a VPN.

Doing so would be redundant.  Current UCC implementations run over SIP-TLS.  That means that the SIP traffic, the actual data stream, is encrypted via TLS.  TLS is an encryption protocol functionally equivalent to SSL, which is a protocol accepted for online banking transactions.  Adding a secondary encryption induces significant overhead, possible degradation of service, for little to no gain in security.

Myth #4: Identifying remote nodes will be a security challenge.

Actually, current UCC architecture best practices deploy/leverage Public Key Infrastructure (PKI) for remote node identity management.  PKI is the cornerstone of most secure encryption methodologies, including https.  By deploying/leveraging a certificate server, remote nodes are validated automatically.

Myth #5: UCC security challenges are complex and there’s no one to help.

BT is here to help with a full suite of complimentary information security solutions.  Service offerings include penetration testing, scheduled remote scanning, etc.  Please contact your local BT account manager for more information.

Have we missed a myth? Please add to our list by posting a comment below.