Security and Risk Management Strategies Blog

Catalyzing security in service orientation

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. 

Enforceable Policies

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.

Your Top Ten Strategic Security Metrics

Blogger: Pete Lindstrom

Yesterday, I gave a keynote at our Catalyst Conference that introduced a set of ten strategic security metrics. These metrics are:

1. Transaction Value (TV) - (Total Value of IT and Information Assets $ / Total Transactions)
2. Transaction Cost (TC) - (Total Cost of IT and Information Assets $ / Total Transactions)
3. Controls per Transaction (CPT) - (Total Number of Inline Control Events / Total Transactions)
4. Cost per Control (CPC) - (Total Cost of Control $ / Total Number of Inline Control Events)
5. Security to Value Ratio (STV) - (Total Security Costs $ / Total Value of IT and Information Assets $)
6. Loss to Value Ratio (LTV) - (Total Losses $ / Total Value of IT and Information Assets $)
7. Control Effectiveness Ratio (CE) - ((Good Allowed Control Events + Bad Denied Control Events) / Total Number of Inline Control Events)
8. Incidents per Million (IPM); Incidents per Billion (IPB) - ((Total Number of Incidents / Total Transactions) x One Million or Billion)
9. Incident Prevention Rate (IPR) - (1 – (Total Incidents / (True Positives + Total Incidents)))
10. Risk Aversion Ratio (RAR) - (False Positives / Total Incidents)

The goal of these metrics is to bridge the gap between operational metrics and strategic metrics. That is, we can take risk- and value-oriented information that we are currently collecting and plug them into aggregation locations for these metrics. I gave an easy example of email and how that could be done. The key is to start small.

It's not all about vendors

Blogger: Trent Henry

The life of an Analyst can be dangerously cloistered. I know many (non-Burton) colleagues whose time is spent almost exclusively at vendor conferences and in briefings with product teams. Although a certain amount of vendor interaction is important--otherwise we can't help clients understand what technologies/solutions are more promising than others--it's easy to get lost. Specifically, it can cause an Analyst to lose his or her way in understanding the day-to-day problems of typical enterprises.

This week at Catalyst is a boon in understanding real problems. With 1700 attendees, most of whom represent the Global 2000, every day brings a dozen conversations that paint a picture of real IT issues--no ivory tower here.

Some interesting questions and issues that have arisen in the security
arena:

• In order to comply with HSPD12, we want to move our PKI to a service provider. How will that transition affect our users and applications?
• The audit team wants more log collection. Should I turn the dials and levers on my existing product or buy something new?
• In the world of a care provider, many network-connected devices are certified by regulatory bodies and can't be patched or otherwise changed. How should those be protected?
• My CISO wants me to explain the benefits of ISO 27002 to the Board: Where should I start?

...and the list goes on.

The key is that emerging technologies can be interesting, but Analysts and vendors alike need to carefully listen to customer challenges.

Interesting thoughts on oversight and governance

Blogger: Eric Maiwald

This morning at Catalyst Nick Leeson, of Barings Bank fame, spoke as part of the GRC track. It was interesting to learn what happened back in 1995 as Barings Bank failed. While Nick’s story was interesting, I think there are insights that we can pull out of what he said:

• Technology might be useful in bringing risky activities to the attention of managers but the managers must understand what they are looking at and why the activity is risky
• People who perform oversight activities must understand the activity they are monitoring – in this case, Nick Leeson became his own overseer as his managers didn’t understand what he was doing

In the end, Nick Leeson’s activities led to the failure of the bank and a visit to jail in Singapore. Would proper oversight have prevented this? Well, according to Nick, the signs of imminent danger existed if anyone had bothered to look.

Common Event Standard SIG Held At Catalyst

Blogger: Dan Blum

This Tuesday at the Burton Group Catalyst conference we held a Common Event Standards Special Interest Group (SIG). For a dry technical topic like event representation and log management, it was impressive that this SIG drew about 35 people on a sunny afternoon in San Diego.

But what was even more impressive was the thought and convergence of ideas between three standards bodies leading up to the SIG. These standards bodies were:

• Common Event Expression (CEE) language, by Mitre
• X/Open Distributed Audit Standard (XDAS), by Open Group
• Trusted Network Connect (TNC)

Although the problem of creating standards in the event and log space is challenging, attendees agreed there are a number of simple things that can be done that will benefit information technology (IT) groups. Also, there is considerable enthusiasm about carrying this convergence effort forward. This interest has expanded beyond the core group of people that have been working with me (including Anton Chuvakin, David Corlette, Ian Dobson, Bob Blakley, and Bill Heinbockel) to representatives of other security vendors and end user enterprises that also attended the event.

In the next week or two, I’ll have time to pull together more information from the SIG and create a more detailed blog entry. In the meantime, watch this space, and stay tuned for more coverage of this topic!

The expanding security vocabulary: data management

Blogger: Trent Henry

Burton Group's newest coverage area--Data Management Strategies--stretched its wings for the first time at Catalyst today.

Research Director Peter O'Kelly gave the kickoff keynote, and a number of phrases caught my ear:

• E-discovery
• Compliance
• Disclosure

Wait, aren't these security topics?

Not just, it turns out (and, frankly, I already knew that, but it was a good reminder). Part of information-centric security involves recalling that there are people in IT who work closely with data: slicing, dicing, modeling, warehousing, indexing, etc. We need to be talking with them.

More significantly, we have additional vocabulary to become conversant with (and technologies/techniques to understand) so we can have a meaningful protection discussion:

• XQuery and the rise of XML data types
• Granular relational databases and widespread replication
• Use and management of metadata
• Data modeling

It's unlikely that all (or any) of this is new to a seasoned security professional, but we need to dive more deeply to understand how these things affect security policy and infrastructure. In short, how do they impact confidentiality, integrity, availability, use-control, and accountability of information?

By the way, my favorite quote so far: "skimping on [data] modeling is like choosing a discount parachute" (from Analyst Joe Maguire).

Executives like metrics tied to business value – who knew?

Blogger: Eric Maiwald

Listening to this morning’s speakers in the metrics track was interesting. First Pete Lindstrom (SRMS Senior Analyst) discussed the need for strategic metrics. Then Ken Anderson (Burton Group Executive Strategist) told us how executives look at metrics and what they are likely to ask when they are shown tactical and technical data. Executives, he said, were looking for something they could understand in a business context. Then Matthew Rosenquist of Intel discussed metrics Intel used when they planned to implement security controls to improve availability in factories. The examples Matthew clearly showed how the metrics tied directly to business objectives (in this case availability) were effective in convincing executives to fund security controls. Matthew also mentioned that the initial metrics he used to baseline the existing state of availability were based on business metrics – i.e. metrics that already existed because availability was a business objective.

Past, Present and Future Security Initiatives on Exhibit at Microsoft TechEd

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.

PCI compliance, building the base

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.