Published: October 29 2009, 04:31 PM | no comments
by Galina Datskovsky

Published: October 28 2009, 11:29 AM | no comments
by Matthew Gardiner

With the establishment of security organizations in enterprises over the past 5 to 10 years, I find that I have been having less and less contact with application developers in these same organizations.  Largely this is a good sign (not that I don’t like developers), in that it shows that the responsibility for enterprise IT security more squarely falls with the security organizations – where it should frankly - and less so on the developers of individual specific applications. 

Recently, however, I was invited to address a group made up of primarily application developers at the Edge User Group Conference in Amsterdam, Netherlands.  My topic was Security for Services, and I explained the value of securing services (SOA/Web services) using the well worn security architectural approach of policy decision points/policy enforcement points/policy administration points (PDP/PEP/PAP).  This is the architectural approach that forms the basis of CA’s Secure Web Business Enablement solutions, in particular CA SiteMinder and CA SOA Security Manager.

 I really didn’t know how easily or well this concept would be accepted by a group of application developers, as it is really about providing security as an infrastructural service, not as an embedded part of any single application.  What I experienced was both encouraging and discouraging at the same time.  Let me explain.  The developers in my session seemed to understand and accept this approach, so that left me encouraged.  They understood the value of consuming security for their Web services as a service.  In fact a number of them said to me after the session that they would use such a service tomorrow if it existed in their organizations.  “If it existed in their organization.” Why doesn’t such a security service exist to be tapped into by the developers?

When I do similar sessions with a primarily security audience the take-up seems a lot more muted specifically when applied to SOA/Web services.  Only the most mature security organizations and the most sophisticated security personnel seem to buy into this approach.  While this issue has slowly gotten better from my point of view over the past few years, it seems to me that the average security architect is falling behind the average application developer.  Service orientation and Web services are becoming widely used in enterprises by application developers (this assertion is backed by recent survey results from Randy Haffner from Forrester), but service oriented security is still off into the future for far too many security organizations. 

What this means is that application developers will be forced to do whatever it takes to provide security to get their projects done, which will inevitably lead to the creation of more insecure and costly security silos – again.  So for security professionals that are reading this blog entry, please connect with your application developers and understand their strategies and roadmaps for using service orientation and Web services – and architect accordingly.

Published: October 27 2009, 05:25 AM | no comments
by Mike Hoefgen

If you were in southeast Florida on February 26, 2008 you might remember being without power for about an hour. I wasn't in Florida at the time but I remember the national news broadcasts of the southern two thirds of Florida being without power. Because of that one hour of outage, Florida Power & Light (FPL) announced in early October 2009 it agreed to a record settlement in the amount of $25 million that it will pay to the Federal Energy Regulatory Commission (FERC) and the North American Electric Reliability Corporation (NERC).

Background

According to a press release from FPL:

• NERC had conducted two prior reliability readiness evaluations of FPL reliability practices and performance. These audits found FPL had the appropriate plans, processes, procedures and personnel in place to ensure reliability.
• An independent investigation was conducted by the Florida Reliability Coordinating Council (FRCC), which a delegated authority from NERC performed a detailed analysis of all technical and human aspects of the Feb. 26, 2008, outage and identified no FPL violations of reliability standards.
• FPL also commissioned an independent investigation by ICF International, a consulting firm that is nationally recognized for its expertise on grid operations, energy security and infrastructure protection. ICF concluded that FPL did not violate reliability standards.

Let's take a look at what happened. According to the (FERC) report, a Protection and Control Engineer was troubleshooting a switch that had malfunctioned a few days before the outage event. The engineer -- without authorization and contrary to FPL's policies and procedures -- disabled the primary and backup equipment that prevents electrical failures at a switch from spreading. A failure occurred at the switch, and because both levels of protective equipment had been disabled by the engineer, power was lost for nearly two-thirds of southern Florida.

The spirit versus the letter of the regulation

Point: FERC's Office of Enforcement had asserted alleged violations of the electric reliability standards in connection with the event.

Counterpoint: FPL believes it was in compliance at all times.

Result: As part of the settlement agreement, FERC does not conclude that FPL violated any reliability standards or laws, and FPL does not admit any violations or liability in connection with the outage. Wow! Both parties concur that there were no violations! So why has FPL agreed to pay $25 million? FPL CEO Armando J. Olivera, in the press release mentioned above, said:

“…it could take several more years and be very costly to resolve through litigation with a federal regulatory agency. Litigation would require the time and attention of the same people who are responsible for the reliability of the grid. As a result, we believe a settlement is an appropriate course of action."

So, what can you conclude from this? From my informal summary, using the NERC data, the dollar amount of the fines are increasing. With the first round of audits being completed, NERC's leniency is ending. They are getting very serious about enforcing the reliability standards by imposing fines. So, if you think you are spending too much on your compliance efforts, then compare those costs with the risk of potential fines or even a settlement like the one in this case, and maybe you'll reconsider.

Published: October 26 2009, 03:06 PM | no comments
by Matthew Gardiner

I recently returned from attending and presenting at the ISSE 2009 conference in The Hague, Netherlands.  I particularly like this annual security conference in part because it brings together European security professionals from a very broad set of communities, covering governments, academic institutions, and industry – which is very healthy.   At this conference you get the European view of things in a few days – and you cover a very comprehensive set of topics, from cryptology to security awareness of children, and everything in between.

I specifically presented on two topics, the Kantara Initiative and its Identity Assurance Framework (IAF) as well as best practices for security for services.  For the Kantara Initiative I focused on the purpose of the organization and the IAF in particular to drum up more collaboration between them and relevant people and programs in Europe, such as STORK.

As an attendee of the conference I particularly enjoyed two of its sessions on cloud security.  With the cloud in its nuclear, over-hyped, breathless stage it is really nice to hear from two seasoned professionals with a more balanced and reasoned perspective.  So kudos from me to Gerry Gebel of the Burton Group and Rick Gordon of the Civitas Group for offering up their balanced thinking on cloud security.  Some interesting points I jotted down from their sessions:

·         There are clearly some valid economic reasons pushing organizations to start cloud-ifying their IT operations, such as greater specialization, economies of scale, increased flexibility and agility

·         But there are also significant security and privacy issues that mitigate these potential advantages, such as greater vulnerability to DNS attacks; lack of transparency of people, process, and technologies; lack of control over data management; and many other issues

·         Different layers of the IT stack, from hardware to applications and everything in between, have very different dynamics and thus need to be considered separately.

Gerry’s takeaway was “Enterprises should not use public clouds for sensitive data” and should lean toward building private or internal clouds, which can gain much of the economic benefits of clouds without being impacted as significantly by the tricky security and privacy issues of going public.  I agree with this assessment and would add - you can’t outsource something externally until you can abstract (outsource) that IT function internally for your enterprise.  So use the step of a private IT cloud get some benefits in the short and intermediate term and prepare your organization to leverage public services when they become available and your organization becomes ready.

After the ISSE 2009 conference I also presented at the Edge User Conference in Amsterdam on Security for Services.  My next blog will cover my takeaways from that event.

 

Published: October 26 2009, 05:15 AM | no comments
by Reed Irvin