The Scottish Ambulance Service confirmed today that a package containing contact information from its Paisley Emergency Medical Dispatch Centre (EMDC) has been lost by the courier, TNT, while in transit to one of its IT suppliers. The portable data disk contained a copy of records of 894,629 calls to the ambulance service's Paisley EMDC since February 2006. It was fully encrypted and password protected and includes the addresses of incidents, some phone numbers and some patient names. Given the security measures and the complex structure of the database it would be extremely difficult to gain access to any meaningful information.

Some of the largest and medium-sized U.S. airports report close to 637,000 laptops lost each year, according to the Ponemon Institute survey released Monday. Laptops are most commonly lost at security checkpoints, according to the survey. Close to 10,278 laptops are reported lost every week at 36 of the largest U.S. airports, and 65 percent of those laptops are not reclaimed, the survey said. Around 2,000 laptops are recorded lost at the medium-sized airports, and 69 percent are not reclaimed. Travelers seem to lack confidence that they will recover lost laptops. About 77 percent of people surveyed said they had no hope of recovering a lost laptop at the airport, with 16 percent saying they wouldn't do anything if they lost their laptop during business travel. About 53 percent said that laptops contain confidential company information, with 65 percent taking no steps to protect the information.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. Again this month, my logging polls took the #1 spot!  Poll #8 that covered context data for log analysis is analyzed here. Other popular polls include a controversial Windows Log Collection Poll (which is a poll #7)  and poll #6 about logs that people actually look and poll #5 about logging challenges. Next poll is coming soon.
2. Not entirely surprising, my post/rant called "You Are "A Security Idiot" If ..." takes the #2 spot after being live for only a few days. Yes, we all like to point out other people's problems, especially when they are epically huge :-)
3. Also not surprisingly, my post "11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"" is on the Top list. It is both humorous and sadly true (and backed up by other sources)
4. A curious subject of DLP or "data leak prevention" (specifically, the post called "So, CAN We Have DLP?") also tops the charts. My previous post on data leak 'prevention' ("In Passing on DLP") is popular as well.
5. Again and again, people googling for "open source SIEM" have pushed this post (this tiny old pathetic blurb) to top5. This ancient post from years ago explains why an open source SIEM will NOT emerge soon, if ever.

See you in July!

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

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.