Security and Risk Management Strategies Blog

More Than Roles: Using Data-Centric Security To Fight Fraud

[blogger: Trent Henry]

In identity management, there’s considerable discussion about understanding organizational roles and how toxic combinations of user access can result in fraudulent activity.

At Burton Group’s Catalyst Conference today, UBS’s Mark Swift described this as a “classic” approach to examining security and said it wasn’t adequate for his organization. Mark said, “What we thought of as roles would actually not help us” in the fight against fraud (no small issue in today’s financial-services environment).

Why not?

Several reasons.

Although UBS initially created functional job descriptions and mappings of user activities, they found that these weren’t sufficiently granular and missed important details because of its top-down approach. Instead, they needed a bottom-up approach that focused on data and business process.

Here’s an example challenge: Switzerland has a multiple-hundred-year-old rule mandating that if a party has entered into a contractual relationship, their identity can’t be revealed. Typically in an enterprise, “account representatives” (as a role) would be granted fairly liberal access to a customer record. But for Swiss clients, even an account representative can’t be allowed to see such information, so a role-based model won’t be granular enough to properly enforce policy. This is what Mark described as “jurisdictional data protection” and requires a new process:

1. Map out data (Ask: what information and attributes do applications care about?)
2. Determine what actions must be performed on this data to carry out business processes
3. Analyze what conflicts in data processing can cause harm (or lead to fraud) [For example read/write access to data that allows both booking a financial trade and settling/reconciling the trade]
4. Create a heat map that provides an at-a-glance assessment of where data, applications, and user access allows for potentially fraudulent activity

This is not a simple task. Mark commented, “Application rights for anything other than trivial systems are complex and are often dynamic depending on application-side rules.” This means that security and risk management teams must have deep understanding (or engage with business leaders who have such understanding) of application processes.

Here’s a challenge that comes to mind for me…

It seems there’s a fundamental economic problem for security teams in financial services. Nick Leeson implied this in his talk as well. In order to prevent fraud, management and security/audit oversight teams must have deep understanding of business processes (and in trading, financial instruments) to determine when bad things can happen. The problem is that when someone has obtained this level of understanding, then they are well positioned to actually serve as a trader rather than risk manager. And there's a strong economic pull to go in that direction, rather than as security personnel.

So data-centric security is powerful and important, and leads to much better understanding of business process. But will that have an adverse impact on retaining knowledgeable risk professionals? Let's hope not, because I think data-centric approaches are the road ahead.

Where is Enterprise Digital Rights Management Going?

[Blogger: Trent Henry]

Burton Group has long covered enterprise digital rights management (known varyingly as ERM or E-DRM). Our most recent report on E-DRM describes the technology as “driving security to the data.” Similar to consumer DRM schemes that protect Windows media or Apple iTunes content, E-DRM uses cryptography and fine-grained policies to limit what a user can do with data. Unlike consumer media, however, E-DRM is used exclusively by enterprises to protect corporate data and is typically targeted at word processing files, spreadsheets, email, and related content.

Here in Prague at Burton Group’s Catalyst Conference, many of our security talks have been geared around the trend of information-centric security. As a result, several attendees have approached me to ask, “Where is E-DRM going?”

Good question, but a hard one, because even Burton Group is of a mixed mind on the topic. On one hand, we see E-DRM as software-based technologies whose consumer counterparts have suffered one break (attack) after another. In short, they’re low-surety solutions. In addition, the products suffer from an in-your-face user experience that necessarily adds complexity for employees. On the other hand, E-DRM is arguably the finest example of security surrounding data itself: fine-grained policies (e.g. “You cannot print this document and may only email to other Finance Group members”), cryptographic protection, and prevention of other sorts of leakage (e.g. no copy/paste to unauthorized applications).

The vendor landscape for E-DRM has changed substantially in the last 18 months. Microsoft has made significant strides in adding E-DRM support to SharePoint. Oracle, through its acquisition of Stellent, picked up SealedMedia. And EMC, through its acquisition of Documentum, did the same with Authentica. The remaining standalone vendors are Adobe and Liquid Machines. It’s clear that vendors are solving one typical objection to E-DRM: the management of yet another silo of policies. By linking Enterprise Content Management (ECM) and E-DRM, the content repository’s security settings can automatically be reflected in DRM-protected documents that leave the ECM environment.

Where does that leave us?

•  We have cautious optimism that E-DRM will continue to receive uptake, even though today’s deployments tend to be relatively small and tactical.
• We expect vendors to enhance protection, making use of trusted platform modules for integrity validation and hardware cryptomodules for improved cryptography handling.
• We expect additional integration between rights management and content management solutions.
• Ultimately, we think there will be interesting synergies between virtualization and E-DRM, where mobile workloads (on virtual machines) and the sensitive content they contain can be managed, tethered, and persistently secured via rights-management no matter where a machine image lands.

Mobility and Security

Blogger: Eric Maiwald

It is Catalyst time again – it seems like just the other day we were holding Catalyst North America in San Diego. This week Burton Group is hosting Catalyst Europe in Prague. The security service does not have a track on the first day of the conference so I attended the Planning for Pervasive Mobility track (I also had a talk to give in this track so it made a lot of sense for me to be there!).

It seems that mobility is important for enterprises and employees and wireless technology is improving to help us be more mobile. Paul Debeasi (Burton Group Senior Analyst in the Network and Telecom Service) talked about 802.11n and how it is good enough to be used as an Ethernet replacement. You can see what he wrote about 802.11n in the NTS blog. Dan McCarriar from Carnegie Mellon University talked about their deployment of 802.11n so it is not just a standard that will generate products sometime in the future.

As enterprises begin to include more wireless networks instead of wired Ethernet, there will be additional security concerns that will need to be addressed. This could be everything from an increased use of VPN technology to the deployment of wireless intrusion detection (WIPS) to detect rogue access points and track down sources of wireless interference. Increased use of WLANs may also spur the use of network admission control (NAC) as we have seen more use of 802.1X on wireless than on wired networks.

Another change that we will need to pay attention to is the increased use of employee-owned devices on these networks. Employees (and students in the case of CMU) are increasingly interested in using their own devices (including smartphones) for work. It may not matter what controls we decide to put on endpoints if the enterprise does not own the endpoint. The ramifications of mobility do not end with security – applications will need to change to be more useful on the employee devices. Applications may also need to change to keep sensitive information off of the end point.

Lots of changes are coming and security folks will need to be able to advice enterprises about working in the new environments. 

Risk Management at Catalyst: Learning from the Past

Blogger: Trent Henry

Burton Group’s Catalyst Europe conference is just around the corner. With financial services industry failures at the top of everyone’s mind, now’s a great time to revisit how risk management shortcomings have tremendous impact on organizations of every kind. In a reprise of his insightful Catalyst North America talk, Nick Leeson will once again detail how inadequate controls (and foolish actions on his part) brought about the fall of Barings Bank. In addition, security conversations at Catalyst will include:

- How large enterprises are grappling with governance, risk, and compliance (and why “GRC” is actually a four-letter word)
- What large, distributed organizations are doing to create effective “security embassies”
- The role of metrics in managing protection and communicating with Management
- How information-centric security will unfold over the next five years

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!