A few weekends back I had the pleasure of going to the local children’s museum with a young nephew of mine. One of the attractions was a magnet from an old air craft carrier’s radar system –it was huge and really powerful. The sign explained what it was and joked, “Finding a needle in the haystack isn’t hard with this.”

This got me thinking. As security professionals we are constantly thinking about finding the needle (security incident) in the data haystack. But what if we just used a really powerful magnet? The needle in this case is the tiniest piece of evidence that an adversary is traversing your network or attempting to inflict digital damage and the haystack represents the mountain of innocuous data that the needle is hidden within. And in the era of big data that haystack isn’t getting any smaller.

The data a typical security analyst has to look at is growing by the second: Logs, packets, critical IT assets, threat intelligence, event data, and data classification feeds, to name some key ones. And on top of that, attackers are getting better at disguising their needles. Potential threats are more targeted, stealthy and dynamic than they have ever been. Which means you won’t find the needle if you aren’t collecting the hay in which the needle may be hiding. So, it’s more than just collecting a lot of data, it’s about collecting the right data. This means log collection AND full packet capture, it means external threat intelligence applied to this data to help identify previously unknown attack sequences and it means enabling analysis on all of this data to help detect threats without signatures.

“It’s more than just collecting a lot of data, it’s about collecting the right data.”

The haystack is growing, the needles are getting smaller, yet more damaging and we’re collecting lots of (the right) data. Now what?

Must be time for the really big magnet, right? Well, not exactly. A lot of organizations have started down that path, but it’s more than just buying the right magnet. It’s about pointing that magnet at the right sized haystack. To put it more realistically, how about we use tactics to remove a lot of the hay and make our existing “magnets” more powerful? This could make the haystacks more manageable.

Tactics can be applied like removing items within your data set that you know are “good” – or not threatening – to reveal items that have a higher probability of being ”bad”. This method, sometimes called data or traffic carving, can be an incredibly valuable tool. Start a new investigation where you aren’t looking for anything in particular – just looking to remove things you know are good, normal or OK activity. I’ll bet you’ll be surprised at what is left behind – at the very least some activity that is hard to explain.

Now I’m sure we all wish we had an aircraft carrier-sized magnet to find the needle in a haystack, but using the right tactics in combination with stronger tools can actually improve your results.

Barrett is a member of the product marketing team focused on the evolution of RSA’s SIEM and security analysis portfolio and is always looking to bring fresh “insights” to the security management landscape.  Outside of work you can find Barrett at the top of the closest mountain or running his legs off in the nearest road race.

Online dating is conducted much like a typical phishing scam.  Just as fraudsters spam millions of unwitting users into trying to divulge their personal information, potential suitors on a dating site cast a wide net in hopes of getting a response.  And much like you go through your personal email to weed out the junk, dating sites are no different.  On a typical day, I could get up to 15 to 20 emails (and then you have the ones that send you the same copy and paste email multiple times – even fraudsters aren’t that dumb).  Once the “I would never consider dating you in a million years” profiles are sifted through, you might have a few potential dates worth pursuing.  So you respond…

So let’s compare online dating profiles to online fraud.  There are so many to share, but I have narrowed it down to just a few.

Harry Houdini.  This is my favorite – and one of the most common.  I think of this potential suitor as similar to a well-known Craig’s List scam – the one where potential buyers want to purchase your item for $1,000 even though you are only asking $500 then sends you a check for $2,000, asks you to cash it, keep $1,000 for yourself, and send them back the rest.  Then they disappear – with your money.

In the dating world, the Harry Houdini is the one that keeps calling and texting you.  He seems like a great catch, is interested in everything you have to say, tells you how much he can’t wait to finally meet you.  Then the day comes: you tell him that you finally have some free time to make a date – and he disappears.  No more calls, no more texts.  And while he didn’t take your money, what he did take was a lot of your precious time…  Next!

The Spinner.  This one has red flags all over it.  Beware of this one.  I think of this potential suitor as similar to one of the most common phishing emails.  You know the suspicious email that screams, “Fraudulent activity has been detected on your account so you better update your information within 24 hours or it will be shut down.”  You can feel your brow sweating, your heart pounding, your head spinning.  And while your sense tells you it is a phishing email, there is still that part of you that wants to click on that link.

In the dating world, the Spinner will sweep you off your feet and leave your head spinning.  Within a couple of months, he will share his life story with you, show you his sensitive side, tell you how much he REALLY likes you, how much different you are from his ex-wife or girlfriend, how you’re the only woman who has met his kids, been in his house, seen him at his worse.  The list goes on and on.  There are red flags written all over the Spinner – the problem is you don’t see them because you are, well, left with your head spinning.  In the end, you’ll find out a lot more about the Spinner than you probably wanted to know – like perhaps how they were still in love with and pursuing their ex-wife the whole time you were together. As we blatantly state in our online consumer safety tips, “If it sounds too good to be true, more than likely it is.”

The Interrogator.  The Interrogator is actually quite comical.  I think of this potential suitor as one of those outrageous phishing attacks that so boldly asks for every bit of your personal information except your blood type.  In phishing attacks of yesteryear, a fraudster would attempt to steal very specific information such as your credit card number and expiration date.  Today, many phishing attacks are built with forms that ask for a wealth of data and personal history – even down to information such as answers to your challenge questions or your driver’s license number.

In the dating world, forget asking about your hobbies or what you do for a living.  The Interrogator cuts right to the chase, almost as though he has a predetermined list of interview questions ready the first time he talks to you.  Some of the questions are so bold you wonder, “Did he seriously just ask me that?”  But the funny thing about the Interrogator is that he feels completely entitled to have you answer his string of questions honestly and accurately as though you were a witness testifying in court, however, if you turn a question back on him, don’t expect the same courtesy in return.

Tommy Two Sides.  Tommy Two Sides is like the typical online dating joke you see all over the Internet.  I think of this potential suitor as similar to the phishing attack that lures you to a website in the hopes of catching a preview of the summer’s upcoming blockbuster film or seeing exclusive footage from a wildly popular current event.  In actuality, you are being redirected to a website that is chock full of malicious content and Trojans just dying to find their way on to your computer.

In the dating world, Tommy Two Sides is exactly what his name states – he has two sides.  He puts up a great online profile and portrays himself as having a great career, a personal life full of family and friends, and in most cases, he is usually a good looking guy.  However, once you get through a few emails and you make your way to talking on the phone, you really find out that he just lost his “career” and is now living in his parent’s basement, he really doesn’t have an amazing social calendar, and he is nothing but a big phony.  Unfortunately, you have to waste the ten minutes of your life (and the minutes from your mobile plan) to actually find this out.

There is really nothing that can prepare you for the world of online dating.  I’ve been there, and trust me, it’s a full-time job.  The excitement wears off real quick after you start to recognize the patterns, and you learn to spot the red flags instantly (almost like how risk-based authentication in online banking learns a user’s typical behavior and can spot potential fraud when a transaction or activity deviates from those normal patterns).

I have never been called a quitter in my life.  In fact, my mother used to tell me that if there was a picture next to the word persistence in the dictionary, it would bear my face.  However, I think I have finally found the one thing that is worth quitting.  In 2011, approximately 1 in every 300 emails contained a phishing threat.  When I think of that number and compare it to my online dating experiences, I have a better chance of being phished in the coming year than I do of finding someone special.  So I guess I will stick with what I know best – fighting online fraud.

I spoke at the North Texas Cloud Security Alliance chapter recently, and I had a great question from the back of the room. Paraphrasing, if security is a requirement for certain use cases, why do public cloud providers sell services without security controls?

the breach!, by finna dat

Man, that is a question I wish more people would ask. There are two main reasons for this.

1. The economics of cloud computing break down a bit when you add lots of security controls (significantly if it is poorly designed).
2. Because cloud providers can compete just fine without them.

Let’s unpack number one first. If we are just leasing capacity, we can do that relatively cheaply because we don’t need to spend tons of money on controls, auditing, or logs. In fact, the onus should be on the consumer of the service to build some level of control into the application to protect workloads. That doesn’t always work because administrators of cloud providers could manipulate resources in ways that would compromise the security of the workload. To fully realize the level of security built into these systems, we need to add a number of controls that can be audited and reported. Unfortunately, those controls cost money and require additional resources to effectively deploy in a manner they can be audited. Now what once was $0.05/compute-hour becomes $0.50/compute-hour, and the finances derail (understand those numbers are fictional, but you get the point).

To explain the second point, I want to reference some great insight by O’Toole and Vogel (2011) as they compare companies that focus on sustainability and conscious capitalism with those that do not. As long as it is not the only business model, both will exist (p. 66). If we apply that same concept to cloud providers, as long as they can make money without security controls, they will continue to pursue a non-security friendly business model. So why do they shun security?

Because they can!

Will a small business owner be able to move Google away from their  unbelievably favorable contract terms? Probably not, but larger companies that make demands of cloud providers will end up creating a market where security controls are valued, and not considered a one-off. Security should be consumed transparently. Business users typically don’t know when they need certain controls for their applications, so they will focus on the economics instead of the audit-ability. A better option would be for companies to build a suite of options for their business users by sole sourcing with one cloud provider. They could easily dictate the controls needed for any service, and build that into the price. With some other information security controls like DLP or deep packet inspection, security departments can bolster their ability to rein in unauthorized cloud usage while providing a valuable service to their business users.

References (I’ve been writing a bit in APA style lately, so figured I’d practice it here):

O’Toole, J., & Vogel, D. (2011). Two and a half cheers for conscious capitalism. California Management Review, 53(3), 60-76.

Prepare, by Photo Monkey

OK folks, here’s an opportunity for you all! In advance of the third edition of our book slated for a July release, PCI Compliance, I wanted to offer up a free service to those of you dealing with PCI DSS on a daily basis. I’m going to do a detailed analysis of ten requirements for you! Here’s the best part…

You get to pick the ten I analyze!

Which requirements give you the most trouble? Which ones do you think are getting a bad rap, or are being interpreted too harshly? Tell me! I’ll take the top 10 that people want interpreted and put a series together over the next few weeks with detailed analysis.

Throw your suggestions down in the comments below!

As of April 30^th, 2012 the Citadel Trojan was at its fourth upgrade with Version 1.3.4.0 already in the hands of its customers. Citadel’s features, bug fixes and added modules (each priced separately), have long gone beyond what Zeus ever offered as Slavik’s zeal for developing the malware died down when law enforcement got too close for the Trojan creator’s comfort.

It is already very clear that Citadel is the new Zeus in more ways than one: it was based on the Zeus code and it has all the functions going way beyond any crimeware kit to date. More importantly, it is the only commercial malware in the cybercrime arena being aggressively marketed to criminals at this time, and quite logically, Citadel is slowly but surely converting Zeus operators and bringing them over to its ranks, further eroding Zeus’ market-share.

Putting one’s self in the shoes of a cybercriminal who has just decided to begin bot-herding, what would the first thing on the “to-do” list be? How about seeking-out a crime kit that will provide technical set-up, support, CRM, updates and in-depth understanding of cybercrime? It has to be commercially available – check; and its developers have to be serious and responsive – check as well. In a Jeopardy game, the obvious reply would be “What is Citadel?”

Citadel is all about money, conceived for the purpose of fulfilling sheer greed both of its nefarious developers and dubious clientele. Judging by how Citadel is managed, developed and marketed, it is not surprising to see Team Citadel post indulgent, satirical images (like this one below) as part of its cybercrime-centric sales campaigns:

Citadel – What Really Changed Since Zeus v2?

RSA researchers have been analyzing variants of the Citadel Trojan and setting apart the hype from factual changes made to Citadel that were written differently in its base code, Zeus v2.0.8.9.

The following functions are the main changes observed to date:

The Citadel Encryption Method

Going back to how the communication was programmed to happen between Zeus v2 variants and their C&C servers researchers recall it was encrypted[1] with a symmetric encryption algorithm: RC4, with a pre-shared key defined by the builder.

Some variants of Zeus were seen using AES encryption instead of RC4, which is stronger, and still used with a predefined key.

Citadel combined those two encryption methods, and topped them with an additional layer:

• Every Citadel variant has a hardcoded MD5 string (probably a hash of the password set by the builder) in addition to the RC4 key.
• In runtime, the MD5 string is run through MD5 function a second time
• The result (the new MD5) is then encrypted using RC4 with the stored key
• That final result is used in the creation of an AES encryption/decryption key using AES schedule routines
• The Trojan’s communication is then encrypted using AES encryption.

This three-fold effort provides botmasters with strong encryption out of the box – even if they were to choose a weak password, it would practically be impossible to brute-force or break into their bots’ communications.

Local Pharming: Citadel’s Custom DNS Redirection

Right from its first release, Citadel introduced this new option to botmasters, designed to allow them to change the behavior of name resolution on infected machines. Bottom line, this means that the botmaster can decide which URLs the victim can or cannot reach, and what page the victim will land on instead of the original page they were looking for. Local Pharming at its best.

This particular redirection scheme occurs by installing hooks on two DNS related functions:

1. 1.       gethostbyname
2. 2.       getaddrinfo

In order to implement this functionality, a new block was added to the config file, containing names and IP pairs.

Whenever an infected process[2] tries to resolve a hostname to an IP address, the request will first pass through Citadel’s routines. The Trojan will then try to resolve the address using regular mechanisms; if successful, it will check its own configuration for a name/IP pair match.

If such a match is found – the Trojan will return the pre-defined (fraudulent) address to the caller.

It’s worth mentioning that if the regular DNS request fails (domain does not exist, network timeout etc.) – Citadel will return the original error message to the caller, even if a matching address is found in its botmaster’s config. This behavior makes the redirection appear less suspicious in aspects of network monitoring and typical request/answer times.

The local Pharming functionality allows botnet operators to leverage two main attack vectors:

• Isolation of the infected machine, blocking its access to certain “unwanted” services, including AV providers, web-based malware scans, security providers’ web sites, abuse lists and malware update servers.

Team Citadel has been keeping on top of things and makes sure the Trojan comes bundled with a very long list of known security-related servers and numerous specific URLs for each, to            begin with. In one variant studied by RSA, this list was composed of over 650 different URLs.

• The second attack vector that can be facilitated greatly by local Pharming is the deployment of sophisticated phishing attacks, redirecting Trojan-infected victims to fraudulent servers when they attempt to reach a legitimate URL via their browser.

DNS redirection can be a part of SSL compromise attacks, along with other Trojan capabilities.

Citadel’s Windows Hooks

Zeus v2 and all its offspring and variants create function hooks in processes they inject themselves into.

Citadel too, is a Trojan that hooks Windows processes, taking hostage a larger number of functions than Zeus does in its v2 samples:

These additional hooks cause the program execution flow to pass through Citadel on more events than Zeus monitored, and may also suggest the development of future capabilities of the Trojan.

The last two process hooks have to do with the DNS redirection routine explained in the previous section of this report.

Citadel’s Chrome browser hooks

Zeus v2 is known for its form-grabbing capabilities and its efficient HTTP injection mechanism, but although Zeus plugins were written to target Firefox and opera, Zeus variants were never programmed to target the Chrome[1] browser specifically.

Citadel’s team did develop this ability and now the Trojan, when injected into Chrome browser’s memory space at runtime, hooks Chrome-specific core functions in chrome.dll.

Citadel’s C&C Server-Side Improvements and Security Patches

The Citadel Trojan used the well known Zeus server panel and patched it against web-based attacks. Another minor change is in the panel’s visual design, making it appear more professional for the users and affording added control over infected bots. Many of Citadel’s functions and options are embedded into the panel ad-hoc as the team sees fit.

The Cost of Cybercrime with Citadel

What can a cyber crook expect to pay for this next generation crimeware kit?  The following table represents the selling price today for Citadel and its respective technical set-up, support, updates and other various features:

What does Citadel’s Future Hold?

The team developing Citadel appears to be taking the project very seriously and seems to be working tirelessly on patching clunky Zeus mechanisms and adding new ones, making the Trojan increasingly modular and adapted to cybercrime endeavors.

Because of its major similarities to the Zeus v2 assembly, Citadel is still very much like its forefather.  The Citadel Trojan is being aggressively marketed within the fraud underground and will be a crimeware kit to be reckoned with in 2012.  RSA is conducting research into the Citadel Trojan on an ongoing basis and will continue to report on new findings as they become available.

---

[1] Google Chrome is an Internet browser based on Chromium – the open source web browser project from which Google drew its primary source code.

---

[1] Active Zeus v2 variants still use this method today

[2] (could be every process on an infected machine)

[1] Advanced Encryption Standard (AES) is a specification for the encryption of electronic data

Enter Apple’s Keychain! Hooray! I’m now able to store these things relatively securely and make them quickly available for me if I need to log in somewhere. In some cases, I memorize the passwords if I have to use them frequently, but in most cases, I just grab it from Keychain. Every time someone asks me to create a new account, I simply open Keychain, enter in some basic data, have it generate a password (and sometimes dumb that down for sites with stupid password restrictions), and I’m off to the races. One quick note, doing it this way caused a major limitation for me in migrating; more on that soon.

Spoon, by felixtsao

This has a major limitation though: I have more than one device that I access sites from which means I am constantly syncing up versions of my passwords. Ugh, what a mess. Furthering the problem, there is no iOS version of Keychain, so I have to find other ways to get passwords on to those devices for quick access. NOT ideal.

Research time! I started looking around for password managers that would seamlessly integrate with multiple devices. I wasn’t crazy about using a cloud service for syncing as my entire life was dependent on their security. I am sure that Box, DropBox, Google, and iCloud are all super secure, but I’d rather take that variable out of the picture. I found a dozen or so that looked decent, but one (rather expensive) tool started coming up time and time again: 1Password. They have a free trial you can get from their website, so I started playing around with it to see how it would work.

First step, import old passwords. And this is where things completely fell apart. There is no really easy way to get passwords out of Keychain. 1Password has a process that you can try, but it only works on Safari Web passwords. Meaning, if I had not been saving site passwords in Safari, I wouldn’t be able to import them. Part of the reason is that in order for 1Password to properly work, it needs to know more about the site than just a name and user/pass combo. It needs things like the login URL so that it knows when and where to match that password with its built-in browser plugins (which are pretty sweet). So I backed myself into a technological corner by not integrating with the web browser. Temporarily that is.

I’m pretty much sold on 1Password. It has the ability to sync over WiFi (only natively for iOS devices, but they list other methods including WiFi here) so I don’t have to rely on a cloud service, and my initial tests show that usability is fantastic. I’ll be able to get things converted over slowly, but as I use them. So my most popular sites will go very quickly, with the rest migrating over time as I enter them. I don’t mind supporting these guys, but really think Apple needs to consider this type of functionality (to the degree that 1Password does it) for Mountain Lion and iOS 6.

By the way, there are many other options out there. The guys at 1Password were absolutely fantastic to work with. It’s very rare that you can have a discussion down to the line of code in someone else’s Ruby import script with email support. I’ve made my choice, but how do you handle yours? Drop them in the comments below!

Continuing on the theme from a previous blog, what if the use of state-of-the-art security technologies were believed to conflict with EU data privacy regulations? Are security professionals really to be put in the difficult position of not being able to use the most current security approaches to protect their organizations and users? Is there a way to both protect the organization and its users while respecting the rights of users to not be excessively and unreasonably monitored?

With the rapid rise of detective oriented security monitoring technologies such as data loss prevention, centralized log collection, and network forensics, security professionals, primarily from Europe, often have become stuck in the uncomfortable position of being “damned if they do and damned if they don’t.” Damned if they don’t use every available means to protect their organizations against advanced threats and damned if they do use technologies which can be construed as collecting, analyzing, and generally “seeing” the personal information and communications of employees and other users.

In other parts of the world, such as the USA, the conflict between security and privacy is not currently so intense and as a consequence security monitoring technologies, like those mentioned above, are in much wider use. Why? The laws and business practices are different, the culture is different, and the use of these technologies is more established. But does this mean that European organizations are destined to be ripe hunting grounds for attackers, who after all are not known for respecting the privacy rights of their victims? Are European organizations really expected to defend against advanced attacks with a hand tied behind their digital backs?

“But does this mean that European organizations are destined to be ripe hunting grounds for attackers, who after all are not known for respecting the privacy rights of their victims?”

What European organizations should do is to use advanced security technologies, but in ways that are sensitive, respectful, and compliant with the laws, culture, and practices of the countries in which they are operating. They must work closely with their data privacy officers and their workers’ councils on the why, what, when, and how of their security program to make sure it is well-designed, operated, and most importantly, understood. Security monitoring versus data privacy is a tricky question, but one that we are working on here at RSA. Being stuck is not an option.

Matthew Gardiner is on the product marketing team at RSA and is focused on the evolution of the SOC and RSA’s solutions which help SOC analysts be more effective and efficient in their jobs. You can follow him on twitter @jmatthewg1234.

The first of these was the report, published in the Christian Science Monitor and elsewhere, of a new ICS-CERT alert regarding an ongoing attack on the United States natural gas infrastructure. The second was the “ClearText” closing article by Bruce Schneier in the latest IEEE Security and Privacy, taken from his recently published Liars and Outliers, a very thoughtful and insightful book. And the third was the announcement of a debate on international cooperation on cybersecurity to be held in Brussels on May 10^th.

What do these stories have in common? All three lead to important questions about what effective cooperation means to achieving cybersecurity: how do we actually move forward together? The article in the Christian Science Monitor described a major cyber attack “currently under way aimed squarely at computer networks belonging to US natural gas pipeline companies.” What struck me most in the report was not the breadth of the attack, but the nature of the response: “the unusual if not unprecedented request to leave the cyber spies alone for a while.” The affected companies were asked to cooperate, at least to some extent, against their short-term best interests. How do they balance the value of cooperation in such a case against the risk of compromise? What enables us to trust that cooperation is our best response?

The extract from Bruce Schneier’s Liars and Outliers in IEEE Security and Privacy is taken from the chapter on “Technological Advances” (pp 228-229). While talking about the differences in speed of technology adoption between attackers and defenders, Bruce also describes “technologies that immediately benefit the defender and are of no use at all to the attacker.” One of his examples is communication technology, specifically radio communication for police. The technologies and processes for what, in his keynote, Art called “cooperation around intelligence sharing” is also one of those defender-favoring advantages. Participation in a cooperative response to attacks like the one against the natural gas infrastructure strengthens that advantage. Our belief in the strength of that advantage itself encourages us to trust in the value of cooperation.

But in responding to attacks, we have to pay attention not only to our longer-term defender-favoring advantages, but also to our near-term risks. And that’s what the announcement of the debate on international cooperation got me thinking about.  As Bruce puts it: “Society has to implement any new security technology as a group, which implies agreement and coordination”.  But it’s not just technology that requires agreement and coordination: cooperation itself requires agreement, requires impact assessment, requires reconciliation of conflicting priorities and understanding of risk. So a debate on international cooperation against cybercrime is valuable and necessary. At the same time, however, it’s essential to move forward quickly where we can in international cooperation, like with the Cyber Atlantic exercises, minimizing the time differential between strengthening our advantages and addressing our immediate risks.

I’m in Prague on the 10^th and won’t be able to make the debate in Brussels or the cybersecurity workshop on the same day, also in Brussels, that the European Union Telecom Commission (EUTC) is hosting and RSA is co-sponsoring and providing a speaker for. But even though I can’t be there, I’m convinced that both the debate and the workshop are essential. We need them both – not only assessment of what we are doing but also immediate concrete action — if we are to respond effectively and with conviction to Art’s challenge.

(Used by permission of Dr. Steven Willmott of 3Scale, adapted from blog by Dion Hinchcliffe)

In discussing the idea with Martin Kuppinger, I suggested that this economic model brings trust to the forefront in a new and challenging way. For example, as part of interoperability testing in preparation for a demonstration of the OASIS Key Management Interoperability Protocol (KMIP) at RSA Conference 2011, we at RSA stood up a non-production key management server on Amazon EC2 so that its services could be easily accessed by key management clients from other companies participating in the interop. That is, we took a capability that is usually deep inside the security defenses of an organization and put it outside in the wild. There were no firewalls, no intrusion detection and protection: as Craig put it in one of the EIC Conference 2012 panel discussions, we “dug up the moat and tore down the walls” of traditional perimeter security in standing up this limited, non-production key manager. But trust was still essential, in that case instrumented through X.509 certificate-based mutual authentication and secure channel establishment. That trust model was used not only in pre-conference testing for the interop, but also in the KMIP interoperability demonstrations in the OASIS booths at both RSA Conference US 2011 (shown in the diagram below) and RSA Conference US 2012.

(Adapted from OASIS KMIP 2011 interoperability demonstration presentation)

The certificate-based “pillar of trust” supporting both the 2011 and 2012 KMIP interops dealt with the essential security issues for the interop: 1) authenticating the participants in the KMIP exchanges, 2) authorizing client requests and 3) preserving the integrity and confidentiality of the KMIP messages. But for production deployments of key management, either in a hybrid cloud such as the one we used for the KMIP pre-interop testing or in a private cloud within an enterprise, much more is required for establishing trust. Craig touches on this in the Kuppinger-Cole report on the Open API Economy from December 2011, where he mentions the critical role that governance and auditing, as well as authentication and authorization, have to play in this emerging economy. As we often express it, trust is the sum of control and visibility.

Trust = Control + Visibility

I’ll be writing much more in future blogs about what this means for key management in the Open API Economy. But just in terms of standing up a key management server on a cloud platform like Amazon EC2, we would need to consider many controls we saw as unnecessary for purposes of interop testing with a non-production key manager: identity controls related to administrative access; physical and virtual server hardening; isolation of master keys within a Hardware Security Module, and so on. We would need to consider many kinds of visibility that we saw as unnecessary for the interop testing: server activity logs; threat intelligence; vulnerability reports; configuration information and so on. We would need to employ effective governance processes, structures and tools that we saw as unnecessary for the interop testing: policies and procedures regarding isolation of the key manager within the cloud service provider infrastructure; risk analysis and mitigation strategies; contractual agreements with the cloud service provider regarding reporting of security issues, and so on. These and more issues need to be considered for key management services, and for many other (dare I say all?) services, in the Open API Economy.

In formulating the Open API Economy as an economic imperative, Craig challenges us all to look carefully at the implications of this transformation for our organizations, both small and large. And for those of us who care about security, it’s no less a challenge to define and establish the mechanisms of trust that are required for the “inside-out” enterprise.