Thursday, August 27, 2009
Tuesday, August 25, 2009
One of the key issues in connecting government systems is the fact that information must often be sent between security domains, but that information must not leak user-identifying or citizen-identifying information. XML helps greatly here, since it allows data to be redacted (selectively encrypted) as it passes between domains. XML-based security standards such as SAML also help. For example, a SAML Assertion can be used to assert that a user was authenticated in Domain A (e.g. a particular government agency) and then that SAML Assertion, with the user details encrypted or simply not present, can be sent over to Domain B. Also, SAML makes it possible to send just attribute information (such as a person's military rank, or their country of citizenship) within the assertions, and then that information can be used for access control at the recipient side.
Monday, August 24, 2009
But, there has been relatively little debate on the flipside of SOA Security - how SOA can apply to security.
Because, really, "SOA Security" is two separate things, solving two separate problems. The first, most obvious thing, is that it applies security to SOA. The problem it is solving here is "SOA is insecure". Randy Heffner's advice is good here: there are products and procedures for applying security to SOA. But, "SOA Security" also has the meaning of "applying SOA principles to security". i.e. "SOA-flavored security", if you like. The problem which is being solved there is the difficulty of deploying security. Joe McKendrick hints at this in his comment here: "Could security services be delivered through the SOA infrastructure, and provide an enterprise-level solution, versus application or system-level approaches?"
"SOA-flavored Security" means making security more manageable and easy to deploy by isolating re-usable components of security and providing them as managed services. For example, the OASIS DSS standard explains how digital signature services can be used in order to provide signing and signature validation services over the network, accessed using a Web Services interface. This solves a knotty problem, and provides a good framework for key management. Similarly, specifications such as XKMS, XACML, and WS-Trust are really all about applying SOA to security, to solve interoperability problems, not about "making SOA secure".
I think that too many SOA Security articles focus only on the first meaning of SOA Security (making SOA more secure) than on the second (applying SOA principles to security to make it more easy to deploy and manage).
Thursday, August 20, 2009
Now, it would make sense for Pandora to expose a Web API which was locked down to just certain users. e.g. If Pandora was available on the Tivo (hint hint Pandora, if you're reading this), and Pandora got a cut of the subscription, then a locked down and managed Web API could be used for the app on the Tivo to connect up to Pandora. Pandora does have its own proprietary API anyway (this is how their various Flash apps connect to their core services) but the info on that API is not public. If they were to make an API public but then tightly control usage of the API, then that may give them the best of both worlds: leverage the developer interest which is clearly out there, given how many Google searches I see for "Pandora API", but also ensure that the API is only used in very circumscribed scenarios (not just thrown out there, like a lot of Web APIs are today).
And, as CTO of a company whose products are used to manage access to Web APIs, there are off-the-shelf products available for this today :-)
Tuesday, August 18, 2009
Monday, August 17, 2009
Trustwave, a computer security firm, conducted its 2008 audit of Heartland on April 30 and deemed it compliant with Payment Card Industry Data Security Standards (PCI DSS). But shortly thereafter, the intruders began stealing batches of unencrypted card-track data from Heartland’s network, and continued doing so for months before being discovered.
[ http://www.wired.com/threatlevel/2009/08/tjx-hacker-charged-with-heartland/ ]
What is PCI-DSS anyway? It's a set of guidelines which must be met by organizations processing credit cards. It boils down to twelve points, which are listed here on this SearchSecurity article by Bill Brenner:
Build and maintain a secure network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program
Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications
Implement strong access control measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data
Regularly monitor and test networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Maintain an information security policy
Requirement 12: Maintain a policy that addresses information security
[ http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1245727,00.html ]
Reading the Wired article, you can see that the attackers did ensure that their sniffer application would not be picked up by Anti-Virus tools (rendering Requirement 5 useless). And they stole the data from on-the-wire on the internal network, behind the firewall (thus rendering Requirements 1 and 4 useless - the data was not being sent on a public network). It could be argued that the fact that the breach originated from a SQL Injection attack means that Requirement 6 was not met. However, the Trustwave audit would seem to have satisfied Requirement 11.
But basically, this points to one of the big issues with PCI-DSS: its vagueness. It is too easy for an organization to be deemed "PCI-DSS Compliant" but then be hit with an attack like this.
Friday, August 14, 2009
Sending a SOAP message onto JMS using the "SOAP over Java Message Service" proposal, or as a TextMessage
Did you know that you can use Vordel SOAPbox to send a SOAP message onto a JMS message queue? You can choose to send it as a normal TextMessage, or an ObjectMessage. But you can also choose to use the "SOAP over JMS Message Service" proposal to place the message.
Just choose Design mode instead of Classic mode in the tabs in the top-right, and then drag in a "Messaging System" filter onto the canvas. You might notice that the "drag and join" configuration of SOAPbox is very similar to how the Vordel Gateway is configured. So you can test the JMS service in exactly the same way as you configure the connection to the JMS service.
Thursday, August 13, 2009
quote:Originally posted by ajmas:
This sounds very much like RTF (Rich Text Format) and this was developed back in 1987.
I think WTF is more appropriate here than RTF.
Indeed RTF is not prior art for the practice of storing content separate from markup (it mixes the two together) but "WTF" summarizes many people's reaction on seeing that the practice was patented (by i4i, not by someone like Jon Bozak who would be associated with XML's invention) and now Microsoft may have to stop selling Microsoft Word as a result. Though in their defense, i4i do actually use XML-based document storage in their products.
Conspiracy theorists may note, CNET reports, that one of i4i's biggest projects "was its 2001 overhaul of the US Patent and Trademark Office's own Web site for patent submissions"
Check out the Allianz insurance case study on Vordel's website. Although not so well know in the US (yet), Allianz is huge: presence in more than 70 countries with over 177,000 employees that service more than 60 million customers.
One of the interesting things about this case study is that the Vordel Gateway validates RPC-encoded SOAP messages against Schemas - something which may seem simple but actually is an unusual feature. RPC-encoded SOAP normally can't be validated against a Schema.
Tuesday, August 11, 2009
In reading Twitter's description of the attack, it's apparent that once the attacker had obtained the password to a single e-mail account of a Twitter employee, he/she was able to execute password resets (using the 'Forgotten Password' function) on several other accounts. This enabled the attacker to use the compromised e-mail account as a springboard to access additional data stored elsewhere.
It's the oldest trick in the book, and it has very little to do with cloud security any more than someone stealing your identity and then using it to open up credit card accounts has to do with bank security.http://www.csoonline.com/article/497513/Why_Twitter_Hack_is_NOT_a_Cloud_Security_Wake_up_Call
In order words, password security can be considered a separate problem from cloud security.
Monday, August 10, 2009
In the XML world, there was a famous vulnerability discovered by Amit Klein back in 2002 which used recursion in DTD's (Document Type Definitions) in order to create a Denial-of-Service attack on an XML parser. The attack involved a cleverly crafted DTD which was designed to expand greatly in memory when parsed, using recursion, earning it the name "XML Bomb". The XML Bomb vulnerability is described here in this December 2002 SecurityFocus article. Following Amit Klein's discovery of this vulnerability, a number of vendors issued advisories and patches - including initially Macromedia and Sybase. Back then, I included a description of the XML Bomb in a book chapter I wrote on "Hardening Web Services" in the "Hardening Network Security" book (and you can download that book chapter from the Vordel website for free).
In December 2003, the vulnerability resurfaced in products from IBM and Microsoft. IBM and Microsoft then issued patches for it. Of all those patches, only Microsoft's patch is still available online - here: http://support.microsoft.com/default.aspx?kbid=826231. For Sharepoint, Microsoft rolled the "XML Bomb" patch into the similarly evocatively-named ".NET Framework 1.1 Temporary File Explosion on Sharepoint Servers - Windows Server 2003" patch.
So the "XML Bomb" vulnerability is all patched now, right? Wrong. Proving the vulnerabilities never really die, it cropped up again last week - almost seven years since Amit Klein first discovered it. Joe McKendrick reported that a Finnish startup, Codenomicon, had announced that "Vulnerabilities discovered in XML libraries from Sun, Apache Software Foundation, Python Software Foundation and the GNOME Project could result in successful denial-of-service attacks on applications built with them." The press release itself was vague, but some digging found that the vulnerability was ye olde XML Bomb - http://svn.apache.org/viewvc?view=rev&revision=781488 . Like SOA, the XML Bomb is not dead, but survives to fight another day. Some XML libraries are still naively consuming DTDs and falling victim to recursion attacks.
The good news is that Vordel's products have blocked DTD-based attacks (including recursion attacks, but also External Entity attacks and other DTD-based jiggery-pokery) since back in 2002. Our free SOAPbox Web Services Testing tool can also be used to probe for these vulnerabilities (using its attack vectors functionality).
Here is an excerpt from our Taxonomy of XML Threats White Paper (which you can grab from this page on the Vordel Website):
Blocking DTD-based attacks.
DTD implementations can be vulnerable to recursion attacks. The SOAP specification states “A SOAP message MUST NOT contain a Document Type Declaration” (http://www.w3.org/TR/SOAP/ Section 3). However, some XML applications process DTDs, and therefore products which protect XML applications must block DTDs.
The following DTD contains a recursively defined entity “&x100;” that would be expanded into the huge amount (2^100) repetitions of the string “hello” by any XML 1.0 standard compliant parser. This would cause excessive memory usage and/or excessive CPU usage:
<!DOCTYPE foobar [
<!ENTITY x0 “hello”>
<!ENTITY x1 “&x0;&x0;”>
<!ENTITY x2 “&x1;&x1;”>
<!ENTITY x3 “&x2;&x2;”>
<!ENTITY x4 “&x3;&x3;”>
<!ENTITY x98 “&x97;&x97;”>
<!ENTITY x99 “&x98;&x98;”>
<!ENTITY x100 “&x99;&x99;”>
This vulnerability was discovered in December 2002, and a number of vendors issued advisories and patches - including Macromedia and Sybase.
In December 2003, the vulnerability resurfaced in products from IBM and Microsoft.
Vordel’s products have blocked this attack since December 2002, when it was first discovered, and has alerted companies to its existence at training seminars.
Thursday, August 6, 2009
But what if Twitter itself is DoS'ed? I was just using the Vordel Gateway Cloud Edition to monitor Twitter via the Twitter API. And the Real-Time Monitoring showed that Twitter was down (you can see the Failed messages being picked up by the Vordel Gateway in the screenshot below, with an example of a failed Twitter routing red spike on the right). Twitter then came back up, and you can see the rise of green successful requests to Twitter, after that last red failed routing spike. This shows how a Cloud Gateway can monitor the status of Cloud Services, and allows you to take action accordingly (e.g. the Cloud Gateway can use its most recent cache).
Although Twitter would not be anyone's example of a "mission critical service" (and the lack of Twitter may actually mean increased productivity for many organizations), it is important to monitor Cloud services for uptime in order to find out proactively about service outages. Check out this other example from earlier this week - Monitoring SalesForce.com outage information on your Blackberry.
Wednesday, August 5, 2009
An XML Gateway provides a high-performance selective encryption and de-identification of data, prior to sending it up to a Cloud service. In the screenshot below, you can see a Vordel XML Gateway policy which is encrypting confidential data prior to sending it up to Amazon SQS. This is done at speed, using Vordel's XML Acceleration and underlying cryptography acceleration.
More from IBM DeveloperWorks - "Connecting to the Cloud"
The XML gateway on the client can also scan cloud-bound data for leakage of private or company-sensitive data. The data might also be encrypted, or selectively encrypted, prior to being sent up to the cloud provider. For example, an XML Gateway might ensure that data going up to a cloud computing provider is de-identified so private information cannot be associated with the data.
XML gateways, such as the Vordel XML Gateway Cloud Edition, filter traffic sent up to cloud platforms, as well as apply policies to the access to the cloud services. By doing so, XML Gateways provide the client-side on-ramp to cloud services.
Tuesday, August 4, 2009
The consequence of this is that if a provider of a Web API is simply monitoring their own server uptime, they will not detect an outage like this. The servers stay up. However, from many clients' points of view, the outage is very apparent. This can result in confusion and finger-pointing ("our service is not down - it works from here - the problem is your Internet connection!" / "But other sites are responding fine for me!", etc etc). Increasingly, business depend on Web APIs, and such finger-pointing is a waste of time.
Similar, if your ISP is running a slow connection to a Web API, then that is not the Web API provider's fault, and they will not alert you to the problem. So what is the answer?
The solution is to run a managed Cloud Gateway to manage and monitor the connection up to the Web API. Take the example of SalesForce.com. If an organization is linking its internal systems to SalesForce.com, then a Cloud Gateway provides monitoring, uptime, and metering information, as shown in yesterday's blog post. However, it goes further, a Cloud Gateway has access to SalesForce.com uptime and response information from the point of view of the client.
This means that if anything happens to the connection up to the SalesForce.com (or other) Web API, this is detected by the Cloud Gateway. The administrator does not have to wait for an email from SalesForce.com. They are being proactive. Indeed, as in the case of the Register.com DNS attack, perhaps SalesForce.com is still available so they would not send any outage email, since from their point of view the service is available. But what matters to any organization is their own access to the Web API.
This alerting is setup using a simple policy configured on the Cloud Gateway.
Notice that if the connection to SalesForce times out, the processing goes down the red "failure path" and results in an email being sent. All configuration is done using drag-and-join, so if you want to alert to SNMP, Syslog, Windows Event Log, etc, this is simply a matter of dragging in the appropriate filter and wiring it up in the policy.
Let's see this in action. I simulate a SalesForce network outage by simply pulling a cable. Now, this of course does not bring down the SalesForce APIs themselves. But they bring down network's access to SalesForce. So if I have a local database which is replicating SalesForce data, that connection is lost. So how do I find out about the problem?
Aha a new email on my Blackberry:
The email is from the Cloud Gateway:
Let's click on an alert and open it:
You can see that the Gateway identifies the client, their IP Address, and proactively tells me that the connection to SalesForce.com's Web API is down.
I can also configure a rule which will only send an alert once in a specific time period (to avoid receiving an "alert storm" on my Blackberry).
And finally, there is nothing Blackberry-specific about receiving an email alert from a Cloud Gateway - it just makes for a nice demo :-)
Check out the Vordel Gateway here.
Monday, August 3, 2009
One of my favorite Web APIs to use in demos is SalesForce.com . SalesForce has a ton of information about their API on their developer site. TheVordel Gateway Cloud Edition can be used to connect up to SalesForce, including sending up the API Key and caching the Session Identifier which is returned back by SalesForce.
One of the neat things is that all traffic from the app to the SalesForce API is now monitored by the Vordel Gateway Cloud Edition. There are many advantages to this, which I will delve deeper into in later posts. But, one key advantage is that "rogue cloud service usage" is stamped out, since it appears on the Real-Time Monitoring of the Cloud Gateway:
Any issues with the data being sent to SalesForce, such when the Vordel Gateway detects and blocks sensitive information which should not go up to SalesForce, is instantly viewable.
Similarly, the response time from SalesForce.com is monitored. It's easy to see the bytes in, bytes out, and the response times and codes from SalesForce.com, using the Vordel Gateway.
Look out for more blog posts this week about using the Vordel Gateway Cloud Edition with the SalesForce API...