SecureStrategies « SecureThinking

Monday, August 30, 2010

Amazon, Starbucks and Information Security Data – Part #1

By Ben Rothke, Senior Security Consultant, BT Global Services, CISSP CISA

What do Amazon and Starbucks have to do with information security data? They seem to be the mechanism being used to obtain data and metrics from security practitioners.

On any given week, I, like many other information security professionals, receive a number of emails, presented under the guise of gift certificates to Amazon and Starbucks, which request completion of various surveys and questionnaires.

Often that data is used to create global security metrics, vendor statistics and reports. The question is — how effective is that data?

Many times, the results and underlying data are unqualified. Using a more technical term, it is worthless — worthless in the sense that the recipients may not be qualified to answer the questions, there is no verification of the data, and the information can be biased due to the underlying desire to get the gift cards.

The truth is that good infosec data is quite difficult to find. Part of the issue is that the people who create the surveys, often from the marketing department of an organization, may themselves not be qualified to do so. Often questions asked are vague and the terms ambiguous. Terms such as data breach and hacking attack mean different things to different people.

An often asked question is — “How many losses have you suffered due to data breaches in the past year?” When attempting to quantify data losses, it is often more of an art than a science. Take this scenario: an Arkansas-based retail firm has an encrypted backup tape that goes missing in transit that contains the credit card numbers of 10 million customers. What is the loss? An aggressive litigator may opine that the damages should be calculated as the number of victimized customers multiplied by the average cost to recover from such an identity theft attack.

On average, it costs $8,000 for a person to recover from identity theft, according to Northwestern University. So the litigator will sue for $80 billion in losses. The defense attorney will note that the $80 backup tape was encrypted with AES-256, and therefore the losses should be limited to incidental costs and a replacement backup tape. So is the loss in this case $80 or $80 billion? Same survey question, very different answers.

What this means is that before you make any information security decisions, understand the underlying data. Dust off your statistics books, and see how conclusions in the report were determined. Ask basic questions, such as how large their sample size was? Were all those who answered from qualified companies and/or individuals?

One of the tricky things here is that there are so many different types of data that it’s often difficult to obtain effective data from a generalized on-line survey. For example, there is a huge difference between opinions (stated preference) and more objective data (revealed preference).

The big question always centers around “bias.” Vendors have a particular incentive to connect the data to the solution they are proposing. Often, the questions they create will be tilted to their solution. Not that data from vendors can’t be trusted – it’s just that when they supply data, use extra scrutiny.

Pete Lindstrom, Research Director at Spire Security, astutely observed that, “There are many problems with data, but if you look a little closer, you will find the same problems and more with the everyday, qualitative information we base our decisions on. Our goal should be to get better with the data, not bash it and use that as justification to return to the ways of the medicine man.”

One can get a great cappuccino at Starbucks, but someone’s desire to get a $50 Starbucks gift by entering spurious results should not affect your ability to make an educated decision regarding information security.

So where can you find good information security data? Stay tuned for Part 2 of this piece in which I’ll provide details on some excellent sources.

Thursday, August 19, 2010

Mobile Device Security – A Growing Problem with Few Answers

By Jim Tiller, Vice President, Security Professional Services, North America, BT Global Services

It is no surprise that mobile device security is becoming a growing concern for CSOs everywhere. Although mobile phones have been part of many companies’ communications strategy for quite some time, what has changed significantly in the last few years is the substantial increase in mobile device sophistication and emergence of targeted threats – both seemingly outpacing comprehensive and effective security measures.

Today’s mobile devices are exponentially more powerful and complex than those from a few years ago. This combined with increases in inexpensive bandwidth and millions of available applications mean more people are using them for more complex tasks, which include a vast array of corporate information and application interactions. The opportunity to lose valuable data or expose corporate systems to unauthorized access has been considerably amplified.

Although there are some evolving security solutions emerging in the industry to address mobile device security, not all are comprehensive nor can they be referred to as “enterprise-ready.” Moreover, many large organizations may have as many as a dozen different mobile device platforms being used that represent a broad spectrum of diversity, further complicating meaningful security. Also, given today’s device capabilities, it is difficult to determine if a user is retrieving email, files or accessing applications from a computer or an unapproved mobile device.

Of course, all this is exacerbated by threats that specifically target mobile devices. Hackers are attracted to mobile devices because of the diversity of attack vectors and opportunity. These fall into three basic categories:

Access to information – There are numerous applications that promote mobile online banking, social networking, and, of course, files and e-mail stored on the device, all of which represent value to a hacker. Moreover, many mobile devices are VPN-capable, which can open internal systems to undesirable interactions.
Toll fraud – Hackers have produced several Trojans inserted in downloadable games and applications that surreptitiously dial international premium rate numbers that produce revenue for the hacker. Additionally, there are malware that permit eavesdropping and other forms of man-in-the-middle attacks.
Leverage – An emerging condition is where hackers are implementing root kits and other forms of malware that are essentially creating a botnet within the mobile domain, which can be used for a number of purposes, such as DDoS and SMS spam.

Concerns about the exposure of private information and communications is very real. In fact, just in the last few weeks, the U.A.E. has sought to block Blackberry messaging and e-mail, and the German government, which has advised officials not to use Blackberry and iPhone devices due to a dramatic increase of attacks and fear of snooping, is advising civil servants to use Simko2 by T-Systems. And unfortunately, it’s likely to get worse before it gets better.

So, what can you do?

First, focus on the basics: policy, access control, monitoring, and education. Try to minimize platform diversity within the organization, but this is far easier said than done. Seek mobile device encryption solutions — a lot of data loss can be attributed to simply users misplacing their phones. There are some good anti-virus solutions on the market that should be reviewed and tested; however, you may find you need more than one solution.

Lastly, use mobile device sophistication to your advantage! Produce corporate applications to help employees — even something as simple as an app that provides updated mobile security policies employees can reference, or access to approved software, or something that can help identify the device as it accesses corporate systems, such as certificates, or a proxy app to route Internet traffic through dedicated security systems under your control.

Anything is better than nothing. Use the same capabilities that are at the disposal of hackers to do harm, but do good. You may not get ahead of the curve, but at least you can start leveling the battlefield.

Tuesday, August 17, 2010

Reputation Damage – The Key to Assessing Business Threats

By Malcolm Stokes, Head of Operational Risk, BT Operate

When assessing threats to business, how can we tell whether security and resilience are good enough? The answer depends largely on how we value reputation; however, there’s no recognized method for measuring damage to an organization’s reputation. BT Security is piloting an approach that aims to solve this problem.

Business success, or survival in a crisis, depends ultimately on reputation. If the expectations of customers, employees, suppliers, regulators, and/or investors are not met, reputation is damaged and the bottom line suffers. Safeguarding reputation means continuing to meet expectations of security, reliability, product or service quality, value for money, and integrity. Risk to any of these characteristics can be a threat to reputation, to market share, costs and profitability.

If expectations are not met, customers will buy elsewhere, employees leave, suppliers are reluctant to offer best terms, regulators impose greater scrutiny, and investors may raise the cost of capital. Any combination of these responses will tend to reduce revenues, raise costs and erode profits.

Nearly all business risks have the potential to damage reputation in some way, which is why the phrase — “damage to reputation” — arises so frequently as a possible consequence. Often this intangible part of consequences is said to exceed the tangible losses that may arise from an incident. However, without a consistent way to evaluate reputation damage potential, we may distort our analysis of risks and draw false conclusions.

Market surveys that ask which risks concern managers the most tend to find “reputation risk” at the top of the list, simply because almost all risks are potentially risks to reputation. Look at any risk register and ask yourself if reputation can ultimately be affected. Study a few well-known business failures (e.g., Ratners, Perrier, Pan-Am, Barings Bank, Enron, Anderson, Jarvis, and potentially BP) and consider the role played by reputation damage.

The proposed scheme for measuring reputation damage uses a set of 10 estimated cost components that together represent the overall cost to a company of suffering and repairing a damaged reputation. Not all of these cost components will apply in every case:

Advertising and communication costs to restore trust
Reactive expenditure to prevent recurrence
Cost of de-mergers and re-branding
Value of lost business contracts that are terminated
Cost of acquiring customers to offset increased churn
Opportunity cost of new business prospects and partnerships lost
Increased cost of capital due to lower credit rating
Cost of delayed product launches and smaller market share
Cost of replacing executives and managers who resign
Cost of replacing skilled employees who leave

The process of estimating what reputation damage might cost avoids the pitfalls of trying to value reputation or brands before and after an incident in order to assess the damage in terms of value difference. A series of pilot studies are in progress to demonstrate how risk management and threat assessment can be more effective if reputation takes center stage in the process.

I’ll report back on what we find from the pilot studies. But, in the meantime, join the dicussion and let us know what costs your company associates with risk.

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.

Wednesday, August 11, 2010

Data breaches – the new daily reality

By Ben Rothke, Senior Security Consultant, BT Global Services

Two stories from July about data breaches should give everyone pause.

The WikiLeaks’ Afghan War Diary shows the staggering effect of a large-scale breach, even within a military organization with strong security controls. And while not a breach in the classic sense, the issue of 100 million Facebook users’ data published online underscores the fact that many people are clueless and will eternally be clueless about how to share their personal data.

Many people still think they are required to enter their personal data on a warranty card for their new appliance. Entering one’s birthday and other lifestyle data is used by the manufacturer’s marketing department, not quality control. When these same people use social media, little do they know that every bit of data they post is essentially entered into the public domain.

While Facebook is constantly touting new security and privacy features, its responsibility to you, the end user, is quite limited. Review Facebook’s Terms of Use, and it’s clear that from a security perspective, you get what you pay for. Notice Facebook’s use of the term “you” (referring to the end-user), and how sparingly it uses the term “we” to refer to its security and privacy obligations. I use Facebook only as an example here, given its size, yet the same holds true for nearly every other social media site.

Many organizations regard security awareness as the answer and panacea to preventing data breaches. The mindset is that if you educate people regarding security and privacy, they will certainly come to practice safe computing practices. But that’s not necessarily so.

By way of example — nearly 20 years of nutritional awareness via the food pyramid demonstrates that too many people simply don’t understand basic food guidelines. The USDA can attempt to educate people, but education alone simply won’t and, in fact, doesn’t work. Put it this way — in these recessionary times, if your job description has the word diabetes it; you have job security.

As to data security and privacy, awareness alone does not cut it. And security hardware and software alone won’t cut it, even if you use DLP. The answer is that there is no answer and that data breaches are not only inevitable, they are inescapable. Hence, the key is to manage these breaches via an incident management program and have a computer emergency response team (CERT) in place in that can deal with the breaches.

The NIST Computer Security Incident Handling Guide is a great place to start on your journey to establish a CERT. As stated in the guide, performing incident response effectively is a complex undertaking. To establish a successful incident response capability requires substantial planning and resources.

But once you have an established incident response team, you’re in good shape, as long as you keep it current. For those who don’t, you certainly need to establish a CERT and you need to do it yesterday.

Data breaches are the new daily reality. Make sure your daily reality check includes a CERT.

Friday, August 6, 2010

Part 3: Kraken and Storm Redux: Rebirth of Botnets and Recidivism of Participating Hosts

By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

In the previous two posts, we discussed the reuse of malware and host recidivism. In this article, we will focus on how pirated software is making the problem all the worse [piracy proportional to botnet size].

While there are many reasons for unsecure configurations, one of the most compelling reasons has to do with using unlicensed — and hence — unsupported software. Yet I don’t believe it would be an overgeneralization to say that those running pirated software are not overly concerned with the confidentiality and integrity of their systems — at least, not as concerned as they are about the licensing cost of those systems. While this is less of a threat to assets residing in a reputable enterprise environment, it is still a compounding issue that grows the ranks of botnets and adds amplification to DDoS attacks.

Most sites offering pirated media and cracked applications are vertically integrated with organized crime-owned botnets. The re-up process (marginal node = marginal $) is partially funded by recruiting unwitting visitors and asking for a virtual handout. Perhaps it is Lady Gaga today, instead of Britney Spears of 1998 — whatever the reason or taste, the content will be offered, loaded with the same core seed – it will compromise the system that downloads it, have that system phone home and put that system to work.

Users unwilling to pay for licensed operating systems in the first place (or unsophisticated enough to know the difference) are more likely to download other pirated software. In doing so, they are positioning an inferior OS (one that has not been patched or even configured prudently) directly in contact with malware-laden content. Often this is audio and visual media – formats in which myriad additional root level exploits exist.

It is difficult to even fathom how many instances of pirated Windows XP are online. Despite Microsoft’s attempt at an amnesty program three years ago, it is doubtful there has been much reduction in percentage, let alone total number, as of today. Some estimates quote as high as 40% of worldwide software is being pirated. Of the counterpoints listed in this blog against RIAA and enforcement of IP statutes, not a single argument attempts to refute that installing pirated software on a system diminishes its security posture. Perhaps the most ludicrous argument for removal of IP enforcement would be that piracy is “safe” for the user and the internet at large.

To move to a technical direction — if the argument that security and piracy aren’t compatible at an application layer (e.g., sharing pirated DVDs via P2P software), it would even be more ludicrous to make it at the Operating System layer. If the OS is counterfeit — either not eligible or the user is in fear of receiving security updates — there is little chance that it will remain a sovereign host. Once compromised, there is much more of a chance that that the keyboard user (to contrast from the remote r00t user) cannot regain control and hence will be unable to restore the ability to update the host. Even if the system owner wishes to legitimately restore state to a time prior to infestation, it’s often impossible. Most of the Trojan software installed on compromised systems today either poison DNS such that the infected computer is browsing to a non-security site, or it injects itself somewhere in the process of the host trying to patch the OS or load current definitions into the A/V application. Once compromised, access to the handful of sites that could offer the user assistance in cleaning up the rootkit isn’t possible without strong technical skills or intervention of a third party.

Here, recidivism is made worse because an initially compromised system will continue to prevent updates and A/V software from being updated, even if the botmasters are behind bars, the C&C nodes have been turned dark, and the user wants to turn over a new leaf and pay for a legitimate OS license key.

For the reasons above, the botnet problem is not getting any better. The resurgence of Storm/Kraken can be chalked up to reuse of code within isometric parameters where their ancestors existed. The confusion over the name of which botnet has conscripted which node when is much less important than addressing the underlying environmental conditions that allow the continued presence of 10^8 node botnets driven by kids with learner permits.

As a parting allegory — the illusion of IT progress was shattered several years ago when the Conficker botnet spread through LANs in the same manner as the Sasser worm (leading to Bobax and eventually Kraken). Today, the Stuxnet Trojan is spreading to systems riding on the same USB drives that Conficker.C did more than a year back (remember past cries to disable autorun?).

The more the security world changes, the more it stays insane!

For more information, please visit:

Original Kraken [Damballa, Royal]: http://www.darkreading.com/security/perimeter/showArticle.jhtml?articleID=211201307
Current Kraken [Damballa, Royal]: http://www.darkreading.com/vulnerability_management/security/antivirus/showArticle.jhtml?articleID=225701438&cid=RSSfeed_DR_News
Original Storm [F-Secure Video and Commentary]: http://www.youtube.com/watch?v=kH8cS1AkqiI
Current Storm [Felix Leder]: https://www.honeynet.org/node/539
Mariposa Demise; Technical Ability of Mariposa Botmasters [Panda, Defence]: http://www.pandasecurity.com/homeusers/media/press-releases/viewnews?noticia=10085

To read the full paper on Kraken, click here.

Thursday, August 5, 2010

Part 2: Kraken and Storm Redux: Rebirth of Botnets and Recidivism of Participating Hosts

By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

In yesterday’s post, we discussed the reuse of malware. In today’s article, I want to focus on how botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnets [host recidivism].

The sophistication of the botmasters pales in comparison with the persistence of the problem. An owner unable or unwilling to secure these hosts affords their systems to be cyber-magnetically drawn into some future botnet. Call it magic or fate — no compromised system just sits there and serves up the connected monitor web advertisements for timeshares and Viagra, without simultaneously offering other services to a Botmaster. Just because a host has not been engaged in a SPAM campaign or doesn’t have an active keystroke logger installed doesn’t mean that the ability is not resident within the rootkit installed. In today’s market, ignoring bot earning potential is akin to leaving money on the table, from an organized crime point-of-view.

A system not patched against MS09-123 is likely not going to be patched against MS10-123. This is primarily because the decision to patch is most typically made by implementing and enforcing a policy that stipulates the process of perpetual patching for the lifecycle of that piece of software. The merits of an individual patch and the situational risks surrounding the vulnerability at hand are less likely to come into play since so much software needs patching so frequently. Modes of interaction of a vulnerability in a distinct piece of software cannot always be anticipated because the instantiations of that vulnerability (no matter how minor) in custom configurations and interactions with other objects are too numerous to fathom.

End users are not typically engaged in formal policy adherence to their home systems — that is not the claim here. However, the principle carries forward as those end users who roughly follow a best practice configuration seek out and engage offering by the specific vendors they use, most notably the automated processes allowing for silent and automatic patching of the software. Whether the software belongs to Adobe, Microsoft or Apple, most major vendors offer means for systems online to update themselves before or shortly after vulnerable binaries are executed by the user.

These (and formally documented) processes are made for repeatability. So a missed patch is rarely as much as an oversight as it is another in a pattern of computer activity (really, lack thereof) that’s put into motion by actions that the responsible party made at the original installation of the software, up to and including the OS installed on that host.

An example shown in a 2008 Computerworld article (“Update: Two-thirds of Oracle DBAs don’t apply security patches” [1/14/08]):

“The results, which come even as Oracle is scheduled to release its next batch of quarterly Critical Patch Updates tomorrow, showed that 206 out of the 305 surveyed said they had never applied any Oracle CPUs. Just 31 said they had installed the most recent security update from the company. In total, only one-third said they had ever installed an Oracle CPU.”

Considering this survey deals with administrators who are skilled in technology, but may be fearful of uptime consequence by introducing the patch, it doesn’t bode well for end users who feel ambivalent towards their responsibility to update their systems. Whether the cause of the updated state erosion is active or passive, recidivism is high for all of these hosts.

To read the full paper on Kraken, click here.

Wednesday, August 4, 2010

Kraken and Storm Redux: Rebirth of Botnets

By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

Last month, we posted an article on the return of the Kraken botnet. In addition to Kraken, the Storm botnets have also made a slight comeback on hosts once belonging to the recently decimated Mariposa Botnet. Over the next several days, we will examine the technical issues surrounding the return of these botnets, with a focus on the following areas:

The reuse of malware by persons of less technical sophistication than the original authors [lowering barriers to field entry]
That botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnet [host recidivism]
Pirated software is making the problem all the worse [piracy proportional to botnet size]

In this commentary, we’re covering the first area since there is plenty of evidence to support the claim that people of less technical sophistication than the original authors are reusing the malware. Consider the attestation of Panda Security’s Pedro Bustamante:

“Our preliminary analysis indicates that the botmasters did not have advanced hacking skills. This is very alarming because it proves how sophisticated and effective malware distribution software has become, empowering relatively unskilled cyber criminals to inflict major damage and financial loss.”

If the case were that Mariposa was a low tier botnet (say only 100,000 nodes), perhaps it could be explained away that script kiddy botmasters got lucky for a while. They inherited well, or knew the “right people” in lieu of the “right stuff.” However, this was not the case. Mariposa was a 10^8 node botnet, and that, by any estimation, is a really big number.

The position of the botmasters being N stages removed from the original authors supports the arguments that a botnet in itself is mercenarily a commodity. To compare, entities that own the most barrels of petroleum at any given time are neither producing nor consuming petroleum. They are “possessing it” in an assumption of risk (and hence profit) that comes from stewardship between the time it is made available and the time it is consumed by a refinery. They don’t need to know details of either the production or distillation of the content, and they have no special skills (or at least display none) in either area. This is similar to why these botmasters don’t need the same technical abilities that the authors of the original code exhibited. Would a case be heard where the writer of Trojan software would sue a botmasters for financial loss or defamation??

It would be difficult to defend this position if Mariposa was not the single biggest documented botnet in the world back in January. As skeptical as we are about actual numbers of nodes reported as participating in a single botnet — if the actual number was only 1/100 of the touted number (which would be one hundred-thousand) — it would still be greater than the total number of computers in each of half the world’s countries. Just consider that several people lacking technical sophistication, unaligned with any foreign government, were harnessing the power of a 3-gigawatt-per-hour computing center.*

* Calculations for emphasis only; assume 300W PSUs, 10 Million hosts online at a single time.

To read the full paper on Kraken, click here.

Monday, August 2, 2010

Managing Risk Across the Extended Enterprise

By Vaune M. Carr, Principal Consultant and Security Practice Lead, BT Global Services

Michael Rasmussen, OCEG fellow and former analyst at Forrester Research, recently wrote a post on his blog regarding managing risk and compliance across business relationships. Mike points to the fact that, “Organizations are complex entities that extend to hundreds or thousands of business relationships around the world. Even the smallest organization can have diverse global business relationships. The impact of the extended enterprise is significant for business.”

I completely agree. Now, more than ever, organizations are striving to prevent the economic downfall resulting from too much risk acceptance. Risk Management attempts to look at the people, processes, technologies, and external events that make up the accepted landscape of the organization. Here is where omissions often occur. Looking at the organization’s recovery plan does not include the risks inherent in your outsourcing partner’s operation. At a higher level, what really is the best way to determine the true measurement of an organization’s risk? How should the borders for risk be envisioned?

Develop a clear picture of the extended enterprise

The first step in managing risk is to know the organizations’ boundaries. The board or other governance group should have as clear as possible an understanding of what is “at risk” when discussing scope. In a global economy, these boundaries are constantly in flux; and maintaining a clear picture of a company’s perimeters and extensions of those limits can be challenging. And the challenge becomes more complicated if silo-thinking is a predominant part of corporate culture.

Define the areas of change

It is often assumed that a business is functioning normally if the lights are still on and no new risks have been identified. This is often a poor assumption and tied to a belief that the “organizational boundaries for risk management” stop at the door. For multi-national corporations, in particular, what is happening on the other side of the world is just as critical to risk management as what is occurring in your backyard. Short-sighted scoping may leave the officers of the company acting shocked and dismayed at the feasibility of something happening beyond the scope of the organization’s physical boundaries. How many companies can take the public scrutiny of millions of observers when an incident comes into the hands of the media like recent oil spills? If the risks aren’t being reviewed because the boundaries aren’t fully known or considered, too much is probably at risk. Watch for “change” in the organization, for “change” is a trigger that signals ways new risk can creep into your organization.

Examine the types of risk and responsibility

There are general categories of risk to any business, and most risk managers will agree that besides operational risk management, there are also strategic, financial and compliance risks. Operational risk does need to include both internal as well as external relationships. It also includes a very close look at the values of your business partners when it comes to risk-taking. Operational risk encompasses the “entire” organization. If your organization’s appetite for risk is not the same as your business partner’s, expect to absorb the differences because that’s how risk-taking works. Your options always include mitigation, in any form that your organization requires, to reach the desired level of risk acceptance. A more forward-thinking approach is to let corporate social responsibility help guide the way to determining how compatible your marriage will be with a business partner, before you accept the risk.

The bottom line – most organizations need to view their organizational map more broadly than they currently do. Risk management and risk appetite must be considered before engaging in a relationship of any sort. Failure to do so could bring unwanted risk to your own organization.

Thursday, July 29, 2010

We have security problem blah, blah, blah – can you help us?

By Ben Rothke, Senior Security Consultant, BT Global Services, CISSP, CISM

Two years ago, my colleague Ben Tomhave and I wrote an article titled, Information Security and the Importance of Context.

Perhaps we were ahead of our times, as a new report from Gartner — Effective Security Monitoring Requires Context — echoes some of the same sentiment.

In the report, Gartner Distinguished Analyst Mark Nicolett notes that the rapid discovery of a breach is key to minimizing the damage of a targeted attack. And if you are the victim of a targeted attack, anything less than a targeted remediation effort is insignificant.

In those 49 words, Nicolett subtly delineates between an organization that is on top of its information security effort, and those that are playing information security charades.

It’s 2010 — and far too many organizations are still clueless regarding their security risks. They buy security products, write security policy, and do security things; but they lack the context in which to execute security initiatives. They end up doing a security dance, but in the words of Billy Idol, they are dancing with themselves.

There are myriad excellent security books, articles and blogs; but the only way to use that information within your organization is to have a context in which to apply security processes.

The industry has also created a plethora of security best practices, which are often quite effective. But if you don’t know your security problems, the “bestest” of the best security practices won’t do much for you.

So what do you need to know? Know your enemies, know your security threats, and within that context, create a security strategy.

Nicolett breaks context down into four areas: user, data, application, and external threat. Creating a matrix of your risks against those areas is fundamental. Once that is done, a formal information security strategy can be executed. The addition of context to your security event monitoring infrastructure will increase the likelihood of early discovery of a targeted attack, resulting in shorter recovery time, reduction in losses and other benefits.

For organizations that have done that, they find their security product purchases are radically different. Rather than securing themselves against blah, blah, blah threats, they have metrics to show how effective they are. Security purchasing costs go down, while the level of protection improves.

On the web, content is key. When it comes to information security and protecting your digital assets, context is key. Know your context and protect your infrastructure. If not, it is back to blah, blah, blah security.