Blogger: Randall Gamby

As briefly mentioned in a Burton Group IdPS blog and a ZDNet Australia published article on July 3, 2008, HR data from Google was stolen from one of their previous HR outsource partners.  It seems that the partner, Colt Express Outsource Partners, had equipment stolen that contained HR data from some of its clients, including Google.  The data was unencrypted and stored on systems that were apparently portable.

So what does this mean for all of us? 

First, it shows that even large SaaS companies like Google can be bitten by a lack of security at their partners, just like many of us can.  Burton Group has been warning clients for a long time about the dangers of sending confidential information to outsource partners without proper security and audit processes in place. Of course this should also be backed by strong contractual language. 

Second, be prepared to pay.  Even if Google had breach mitigation terms in their contract, Colt Express announced that it was in financial difficulty. So Google has had to pay for financial reporting and other compensation to its own employees, even though Google did nothing wrong. 

Third, a Google representative stated "We take the security of our employees very seriously and require outside vendors to meet appropriate security standards. We review and update these standards on an on-going basis.”  Does this mean that Google doesn’t require encryption of its confidential information since encryption of the data was not deployed at Colt Express?  When working with third parties, whether it’s financial data or confidential personal data, this information needs to be protected from unauthorized access. One of the simplest ways is encrypting the data while at rest, regardless of where it’s located. 

Final, the Colt Express breach brings to mind a question Burton Group is always asking: “What is your exit strategy if the contract is terminated with your outsourcing partner?”  A lot of effort is expended in creating an outsourcing agreement around use and protection of data, but what happens when the contract is ended?  Do you obtain and retain the information the outsource partner maintained?  Do you have the outsource partner destroy the information and any archives of it (and verify this was done)?  Do you create a custodial contract with the outsourcing partner for them to maintain the information and archives on your behalf (ensuring the data is properly protected)?  As was found in this incident, after their contract with Google was terminated the outsourcing partner apparently retained the employee data unencrypted on their servers. This was the fatal mistake that allowed the breach to occur.

So as you work with your outsourcing and SaaS vendors, you should not only consider how day-to-day operations should be secured to maintain the confidentiality of your data. You should also think about how that data is being maintained over time, and what are your procedures should the unthinkable happen if your partner allows your data to be compromised.

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

Blogger: Randall Gamby

Across the different security technology presentations given this week at Catalyst, one common theme has been the important role of policy. As people hear about new and better technologies and how they can be integrated into their existing infrastructures, they should take the time to examine their policies to make sure they keep up with the solutions being considered.  Questions to ask:

• When did we review our policies last?
• Do we have not enough or too many?
• Will they still be valid?
• Are there other influencers on them?

But while changes will most likely be needed for many current policies, a question that often isn???t asked is, ???Are they enforceable????  As enterprises create policies based upon what users ???should do,??? can the security team validate that they ???did do??? what was asked?  For example, a common policy is, ???All sensitive data at rest must be encrypted.???  So this means you must encrypt your Active Directory, your e-mail storage, every production database, yes? That's probably not happening.  So if the enterprise has no way to implement the policy, then it ultimately is not a valid policy and needs to either be modified or the enterprise needs money, resources and time to conform to the policy. 

The social effect on the user population also needs to be considered.  Essentially, the enterprise is teaching users that they don???t have to conform to this policy, so maybe they don???t have to be conformant to others on the books.  Not a good lesson to teach them.

So as the Catalyst attendees go back with ???dreams of technology sugar plums dancing in their heads??? don???t forget that good governance with valid processes should be skipping around the edge.

Blogger: Randall Gamby

Across the different security technology presentations given this week at Catalyst, one common theme has been the important role of policy. As people hear about new and better technologies and how they can be integrated into their existing infrastructures, they should take the time to examine their policies to make sure they keep up with the solutions being considered.  Questions to ask:

• When did we review our policies last?
• Do we have not enough or too many?
• Will they still be valid?
• Are there other influencers on them?

But while changes will most likely be needed for many current policies, a question that often isn’t asked is, “Are they enforceable?”  As enterprises create policies based upon what users “should do,” can the security team validate that they “did do” what was asked?  For example, a common policy is, “All sensitive data at rest must be encrypted.”  So this means you must encrypt your Active Directory, your e-mail storage, every production database, yes? That's probably not happening.  So if the enterprise has no way to implement the policy, then it ultimately is not a valid policy and needs to either be modified or the enterprise needs money, resources and time to conform to the policy. 

The social effect on the user population also needs to be considered.  Essentially, the enterprise is teaching users that they don’t have to conform to this policy, so maybe they don’t have to be conformant to others on the books.  Not a good lesson to teach them.

So as the Catalyst attendees go back with “dreams of technology sugar plums dancing in their heads” don’t forget that good governance with valid processes should be skipping around the edge.

Blogger: Dan Blum

One of our service directors likes to quote William Gibson: “The future is here, it’s just unevenly distributed.”

At Microsoft’s Server and Tools Business (STB) Analyst and Tech Ed conferences last week, I saw a vendor and a user community living in the past, present and future with many unevenly distributed capabilities.

In a session on identity management strategy, for example, Microsoft discussed a variety of initiatives. These range from Card Space (futuristic implementation of user-centric Information Card specifications) to ADFS (present day enterprise federation support, though unfortunately lacking full SAML capabilities) to self-service password reset exposed through Office (decidedly backward-looking as this functionality has been available from many vendors through browsers for many years).

In another session on rights management and SharePoint, Microsoft highlighted the opportunity to configure SharePoint libraries to automatically apply Active Directory Rights Management Services protections on downloaded documents. Digital rights management (DRM) is controversial and no strong guarantor of confidentiality. Nonetheless, it is a  way to put futuristic self-protecting wrappers on content so as to prevent its accidental leakage or misuse by honest, cooperative users. Because it’s not something that can resist certain types of malicious attackers, many security professionals look down their noses at rights management. Nonetheless, preventing accidental misuse of enterprise information is a big part of the space. It was clear from the number of people in the room asking intelligent questions suggesting realistic expectations that customers see potential value for this technology.

Finally, I was impressed by a presentation on IPSec, PKI and NAP by a Brazilian university IT manager named Rodrigo Imaginario. Starting three years ago, the university combined its student and administrative networks into a single network. Yet servers running ERP and containing administrative content (such as grading information) need to be protected from a subset of students going through their hacking stage. Imaginario implemented a logical security zoning overlay on top of the network using IPSEC in Windows. In the restricted zone, servers only accept connections from Kerberos-authenticated IPSEC clients in the administrative domain. Today, the authentication is being upgraded to use PKI for secure, all campus wireless networking. Imaginario indicated the university took the Windows IPSEC route approach because no additional software had to be purchased. Configuration was difficult, he said, but will get easier with Windows Server 2008. This sounds like an idea whose time has come.

Blogger: Dan Blum

One of our service directors likes to quote William Gibson: ???The future is here, it???s just unevenly distributed.???

At Microsoft???s Server and Tools Business (STB) Analyst and Tech Ed conferences last week, I saw a vendor and a user community living in the past, present and future with many unevenly distributed capabilities.

In a session on identity management strategy, for example, Microsoft discussed a variety of initiatives. These range from Card Space (futuristic implementation of user-centric Information Card specifications) to ADFS (present day enterprise federation support, though unfortunately lacking full SAML capabilities) to self-service password reset exposed through Office (decidedly backward-looking as this functionality has been available from many vendors through browsers for many years).

In another session on rights management and SharePoint, Microsoft highlighted the opportunity to configure SharePoint libraries to automatically apply Active Directory Rights Management Services protections on downloaded documents. Digital rights management (DRM) is controversial and no strong guarantor of confidentiality. Nonetheless, it is a  way to put futuristic self-protecting wrappers on content so as to prevent its accidental leakage or misuse by honest, cooperative users. Because it???s not something that can resist certain types of malicious attackers, many security professionals look down their noses at rights management. Nonetheless, preventing accidental misuse of enterprise information is a big part of the space. It was clear from the number of people in the room asking intelligent questions suggesting realistic expectations that customers see potential value for this technology.

Finally, I was impressed by a presentation on IPSec, PKI and NAP by a Brazilian university IT manager named Rodrigo Imaginario. Starting three years ago, the university combined its student and administrative networks into a single network. Yet servers running ERP and containing administrative content (such as grading information) need to be protected from a subset of students going through their hacking stage. Imaginario implemented a logical security zoning overlay on top of the network using IPSEC in Windows. In the restricted zone, servers only accept connections from Kerberos-authenticated IPSEC clients in the administrative domain. Today, the authentication is being upgraded to use PKI for secure, all campus wireless networking. Imaginario indicated the university took the Windows IPSEC route approach because no additional software had to be purchased. Configuration was difficult, he said, but will get easier with Windows Server 2008. This sounds like an idea whose time has come.

Blogger: Randall Gamby

An alarming trend is beginning to surface within SMB “PCI compliant” companies, like Hannaford Brothers (http://www.networkworld.com/news/2008/031708-hannaford-data-breach.html), Okemo Mountain Resort (http://www.okemo.com/okemowinter/security_update.asp), etc. Credit data is being stolen!  While this is exceedingly bad, I have a theory on why this is happening. 

Before I get into my theory I’d first like to talk about military bases.  As we all know, the military contains a lot of top secret information.  So how does, say the U.S. Army, protect it?  First, they classify what information needs to be protected.  Next they find a piece of property that they can physically secure.  Once the property has been thoroughly checked (no listening devices or mines buried in the ground) they construct a series of secure buildings to house the data. They then put up a fence with a limited number of gates with guard houses and guards to protect it. Then, most importantly, after certifying the security of the base, they use sentries to periodically patrol the perimeter of the grounds to ensure unauthorized access is not gained by spies sneaking in under the fence.

So what does this have to do with PCI compliance for SMBs?  Well the process of PCI certification is similar to what a military branch would do to secure their information.  Enterprises identify and classify what data falls under PCI compliance. They validate that the systems that contain the information are controlled properly and are locked down through processes and technologies. Then they build a fence of security around the systems to ensure only properly authorized personnel have access to them.  Finally they certify that the protections meet PCI compliance requirements. But unlike the military, I theorize that a lot of SMBs, short on personnel and resources, quit here.  In exploring the topic I’ve found that there’s an attitude by some executives that PCI compliance is a gate.  Once SMB organizations achieve PCI compliance, some move on to the next pressing security problem.  But this is the wrong attitude.  Just as the military found out eons ago, they must be constantly on guard because spies are always looking for kinks in the defense perimeter in order to slip in and gain access to information without authorization. 

It seems that SMBs are the most at risk of not having “guard patrols” constantly patrolling the perimeter due to the cost and resources needed to monitor and report on the security’s on-going effectiveness and the bad guys are now sneaking in stealing the very data they created these defenses to protect.

So what’s the warning? Whether you’re a SMB or Global Enterprise, PCI compliance is a gate, that’s pretty much a fact, but it can’t be left unguarded.  Time, money and resources must be allocated on an on-going basis else the bad guys will sneak in undetected and you may find yourself making a breach disclosure that wasn’t detected until it was too late.

Blogger: Randall Gamby

An alarming trend is beginning to surface within SMB ???PCI compliant??? companies, like Hannaford Brothers (http://www.networkworld.com/news/2008/031708-hannaford-data-breach.html), Okemo Mountain Resort (http://www.okemo.com/okemowinter/security_update.asp), etc. Credit data is being stolen!  While this is exceedingly bad, I have a theory on why this is happening. 

Before I get into my theory I???d first like to talk about military bases.  As we all know, the military contains a lot of top secret information.  So how does, say the U.S. Army, protect it?  First, they classify what information needs to be protected.  Next they find a piece of property that they can physically secure.  Once the property has been thoroughly checked (no listening devices or mines buried in the ground) they construct a series of secure buildings to house the data. They then put up a fence with a limited number of gates with guard houses and guards to protect it. Then, most importantly, after certifying the security of the base, they use sentries to periodically patrol the perimeter of the grounds to ensure unauthorized access is not gained by spies sneaking in under the fence.

So what does this have to do with PCI compliance for SMBs?  Well the process of PCI certification is similar to what a military branch would do to secure their information.  Enterprises identify and classify what data falls under PCI compliance. They validate that the systems that contain the information are controlled properly and are locked down through processes and technologies. Then they build a fence of security around the systems to ensure only properly authorized personnel have access to them.  Finally they certify that the protections meet PCI compliance requirements. But unlike the military, I theorize that a lot of SMBs, short on personnel and resources, quit here.  In exploring the topic I???ve found that there???s an attitude by some executives that PCI compliance is a gate.  Once SMB organizations achieve PCI compliance, some move on to the next pressing security problem.  But this is the wrong attitude.  Just as the military found out eons ago, they must be constantly on guard because spies are always looking for kinks in the defense perimeter in order to slip in and gain access to information without authorization. 

It seems that SMBs are the most at risk of not having ???guard patrols??? constantly patrolling the perimeter due to the cost and resources needed to monitor and report on the security???s on-going effectiveness and the bad guys are now sneaking in stealing the very data they created these defenses to protect.

So what???s the warning? Whether you???re a SMB or Global Enterprise, PCI compliance is a gate, that???s pretty much a fact, but it can???t be left unguarded.  Time, money and resources must be allocated on an on-going basis else the bad guys will sneak in undetected and you may find yourself making a breach disclosure that wasn???t detected until it was too late.

Blogger: Ramon Krikken

A seemingly innocent question on a mailing list - which I paraphrased for brevity - set in motion a series of events with dire consequences. The specific code, which was generating error messages in a certain software quality assurance tool, happened to be a critical part of the random number generator in a cryptographic library package. By removing this code, the strength of the cryptographic key material was reduced to a point where cracking the key would take minutes instead of decades. The unfortunate thing about cryptography and randomness is that good and bad can be virtually indistinguishable, and in this case the result still looked so random that the problem went unnoticed for about two years. The impact - needing to regenerate two years worth of key material, and casting doubt on encrypted communication and access performed with those keys - has understandably led to some vigorous discussion and finger pointing. Search Google for "debian openssl" for more discussions than I can link to.

The action - making a change without following a standardized process  - is certainly not unique to this situation, and "the system was slow so I turned off this feature", or "I just fiddled around with it and it just started working" are phrases all too commonly heard in many aspects of IT. Some might argue that a commercial development process would likely have prevented this occurrence, but to simply turn this into a comparison of open source and commercial development ignores some very important aspects. There are important lessons to be learned that could benefit any software development process, particularly when process parts are being adapted to encompass ever changing development and security landscapes. In the ideal world, source code would be based on well-documented requirements, consistently structured, well commented, and maintained by easy-to-reach teams that understand the code inside and out. The reality of dealing with the pressure of delivery deadlines, distributed development teams, and code written either long ago or by a third party can make coding a daunting task ... and quality assurance next to impossible, especially if breakdowns in process or communication occur. The myriad of testing tools, sometimes producing output that can run in the hundreds of pages, coupled with a lack of understanding about their testing coverage, doesn't make the task any easier.

Looking at how this specific event unfolded can lead us down many paths of analysis, all of which will provide valuable information in attempting to determine a root cause. Unfortunately - and this is something that is also not unique to any specific kind of environment - not all parties involved are neutral, and there can also be a tendency to fixate on symptoms rather than the cause. One reason for this may be the assumption that it's possible to fix specific process parts without necessarily re-evaluating the process as a whole; another is that risks and the resulting need for assurance, including process assurance, may be underestimated. Looking at the failures in the flaw finding process purportedly followed in the Therac 25 accidents it's easy to see how this can result in unacceptable consequences. And while likely not resulting in loss of life, the potential economic loss associated with a failure of a cryptographic module suggests that a critical security component can't be treated like just any other piece of software.

How ever unfortunate, this event presents a good opportunity to take a moment and look at our own development processes. Particularly as we start to embrace service orientation, where we loosely couple different business functions while relying on centralized, and often externally developed, security and reliability services, we increase the possibility of creating situations such as this. Using a risk-based process, and testing and revisiting the process itself to ensure it stays current, will be vital in providing appropriate levels of software, system, and information assurance. Building a high-assurance component using a low-assurance process just isn't worth the risk.