Building a Secure Environment
Security isn't just about firewalls anymore. Paul Patrick, BEA Systems' chief security architect, talks about maintaining security in complex infrastructures
by Steve Gillmor

December 17, 2004

We've all seen the headlines and experienced the pain: virus and denial of service attacks, worm intrusions, data unavailable, changed, deleted, and stolen. How have the needs for Java security changed, and what can be done to make sure that our mission-critical, even life-saving, applications keep their integrity? Find out what Paul Patrick, BEA Systems' chief security architect, thinks and what he's doing to protect your applications, your companies, and your government.

Weblogic Pro: What was the basic message of your keynote for the Java Pro Live! conference?

Paul Patrick: I focused on the "Changing Faces of Security in Java Application." At the big-picture level, we have seen Java move from being a developer-driven kind of adoption process into mainstream applications, so we now have core applications running business, running proportions of our government, involved in intelligence gathering, and things like that—functions that are now mainstream and based on this stuff.

But if you look at these environments, one of the key issues that starts to come up in these environments is that going mainstream means a shift from just focusing on how to make developers productive to focusing on the operational aspects. Those operational aspects include things like diagnostics and monitoring, configuration, scalability, and in particular, security. This is becoming more prevalent especially as we find more applications having to be in compliance with regulations such as HIPAA, Sarbanes-Oxley, and accreditations such as NIAP Common Criteria and DCID 6/3.

We find that people are beginning to understand the issues associated with insider attacks. The old approach—just placing the application behind a firewall—is changing. The other big issue is really that these applications are no longer just about e-commerce. We are now putting these applications in highly sensitive environments, and therefore they need to be prepared to live in these kinds of environments and deal with the kind of security requirements that come from those environments. We are finding that there is a growing synergy rather than conflict around security requirements, between applications in the federal government and some of those found in several commercial markets, especially those with a focus on privacy.

Java Moves Forward
Weblogic Pro: What is the impact for a developer who has been along for the Java ride since the beginning? Is this a real stepping-off point into a different ecology, or is this an iterative process of building robustness into an architecture that developers are already familiar with?

Patrick: I think it is a little bit of both. In the first case, if you think about Java, the J2EE model went down a really good path with regard to getting the application developer out of writing security code in the middle of business logic. That was a key concept that they realized—the idea of getting policy out of the application code itself and into the deployment descriptors so that an assembler and an administrator can begin to manipulate this. So the impact on the developer is rather minimal, but the problem is that we start looking at these environments and we start looking at some of the requirements.

The issue becomes that we need to be able to make changes to the security policy governing access to applications that are deployed in a highly distributed environment, as a means to adjust to new threats and risks that a business faces, in a very dynamic, liquid fashion. Most operation staffs, whether they are in the commercial or government segments, are not Java developers; nor are they XML experts. They tend to be focused on a line of business and they need to be able to make these changes in near real time and have them take effect immediately. That means somewhat of a departure from the deployment descriptor approach and into more of a security infrastructure approach.

The key thing there is that if we think about this pragmatically, when a developer builds an application, he tends not to know who the users are. The developer tends to only know the basic roles that are associated with the applications, which represent capabilities. Instead, enterprises are looking to security infrastructure that supports a more dynamic operational model that can be managed without requiring the involvement of the developer.

Weblogic Pro: You've raised a couple of points. Wouldn't you say that Web services is all about the dynamic discovery of unanticipated users?

Patrick: Well, Web services is really focused on a distributed component model that allows applications to be composed in a more dynamic manner. One by-product of this model is the potential for a significant and unanticipated number of new users of an application to become discovered as the application is integrated into new applications. The problem here is that we are now talking about a highly distributed environment where the services may not even be within the same enterprise. This forces one to now start facing problems about such things as how do we get the users to be identified across these boundaries when users aren't necessary people anymore—"users" could be the applications, businesses, and things like that.

The other issue that's coming up with Web services is that with all of these new identities and usages of services that may be outsourced, we now have the problem of defining an application policy that applies to the entire application. "How does one know who can do what?" from the entire application viewpoint. The classic approach in a network-distributed application has been to enforce these policies in the perimeter, and you end up with a hard outer shell, soft-centered approach. As a result, and as we are seeing in reports lately, insiders are using these same Web-based interface points to attack applications, and because we haven't put controls there, they are able to get it when it should have been denied.

Weblogic Pro: In terms of security, hasn't that been as classic a failure point as the inside manipulator?

Patrick: It has been. A number of enterprises are beginning to discover that a defense in-depth strategy is essential—multiple layers of protection and the protection enforcement performed as close to the resource as possible. This is the strategy enterprises need to be utilizing going forward and is a strategy that many areas of government have been following. It's an old strategy from military battlefield days, but the problem has been cost and what it took to do that at an application level has been so prohibited.

Where today we are building an application using Java, and deploying it in our own machine, security seems so simple and straightforward, but when the proliferation of these new services start popping up all over the place, one need to think about is how we get our arms around this and control them in a more unified and consistent approach.

The New Architectures
Weblogic Pro: Doesn't the whole DMZ strategy break down this requirement?

Patrick: If you think about a DMZ strategy and Web services in particular, in assets what a lot of people are doing is they take legacy applications and wrap them in Web services and make those services available to their partners, and that's a great idea. The problem goes back to the security model typically used by these legacy applications, which has been one of "keep it in the glass room." But this approach started to break down when we started having to drill holes through firewalls of the DMZ to reach back to a Web service that wraps the legacy application. In essence, we are making a hole right through our enterprise and to those critical applications. This kind of approach has to give way to some new thinking. DMZs are models of great security schemes, but we need to couple those with appropriate levels of protection enforcement as close to the resource as possible to mitigate the potential of insider attacks.

Weblogic Pro: Isn't this making the case for the use of different design patterns?

Patrick: It absolutely does, and in fact, it pushes for the idea of thinking about security as a set of services that are available to an application or an application's environment, and ideally having those services be an infrastructure-type of approach so that nobody needs to glue them into the application themselves.

Weblogic Pro: Give us some top-grade examples of how this kind of new architecture is designed, and what are the touch-points for the developer in terms of leveraging these services?

Patrick: The industry as a whole is in the very early stage of this; although, some of this is being incorporated into J2EE going forward. What we have done to date is to standardize the ability for the authorization decisions of the J2EE application containers to delegate the decision to an external authorization system—a system that is already in the enterprise, purchased by a customer, and that can be leveraged. Therefore, the richness of that authorization decision can be done as close to the resource and—in thinking about the J2EE container—it's done transparently before dispatching the business request for the object process, and thus requires no developer interaction.

Another example is a new JSR that focuses on how asserted identities coming in can be validated as an enablement for Web Single Sign-On. Business partners don't typically use user name and password as the authentication mechanism for proving the identity of partners. They use concepts like tokens, such as those defined by Web services, to bring identity as part of the request into the system. That identity has to be validated before an application can rely on it within the context in which that application is running. Because it is unlikely that a given application would always have every possible user from every possible business partner in the user repository, it is essential that the concept of "circles of trust" be established.

Developer Migration
Weblogic Pro: Can you give me a status report on how Java and J2EE are faring at the government level in terms of their competition from C# and .Net technologies?

Patrick: In my travels throughout various parts of the government, there are a lot of programs that use Java and have adopted Java as the baseline for what they are doing. From my experience and based on government directives, I believe that the number of applications written using Java and J2EE is growing, but it's also fair to say that the government buys a little bit of everything. They have everything mixed together and expect it to securely interoperate. That's also that same reality in the commercial world as well. Additionally, we are seeing some very significant applications being developed in Java. Examples of some of these types of applications include one having to do with mission planning, logistics, and manipulation and tracking of terrorist information. These kinds applications are bringing a whole new meaning to the definition of mission critical.

Weblogic Pro: Similarly, how would you characterize the choice of open source? What are the implications or the impact of open source in the security space?

Patrick: The debate continues about open source and security. On one side, we have folks who believe that because so many people are looking at the source code, the resulting source code will be more secure. On the counter side of the debate, we have folks who basically say that having lots of people looking at something and not knowing what they are looking for isn't going to result in any more security. While this debate will continue for some time, I think that certain segments of the government are beginning to look at open source more seriously as a possible alternative. In fact, some of them are going through some of the government certification processes like the NIAP Common Criteria process, but the reality of the situation is that most of the open source efforts to date have either ignored or provided only rudimentary security. Providing enterprise-class security is a significant investment and therefore not currently provided in these offerings.

Weblogic Pro: What about the impact of the open source projects like JBoss or aspect-oriented programming? Are these having any effect on the larger space and also specifically on BEA's products?

Patrick: At this time, I've encountered only isolated pockets of interest more than anything else. There are some places where open source is becoming an issue, but in others, it's not. In these places, it is typically someone looking only at the initial acquisition price and not longer-term operational costs. The key, though—what we continue to find—is that a lot of people tend to use open source for development and then use products like BEA's when it comes to production.

A Holistic View
Weblogic Pro: What about the security aspects? We talked earlier about design principles shifting to support a more industry-oriented architecture focus. Do you see that aspect-oriented architecture will have an effect, particularly in regard to the work that is going on around EJB 3.0?Do you see that as having an effect on the security design principles that you are starting to recommend?

Patrick: I have not seen a lot of pickup in aspect-oriented programming, particularly with regard to security. In fact, some in the security community have raised concerns about aspect programming because of the potential for malicious code to be injected. In general, though, we have not, even with EJB 3.0, seen that really change the principles. Some of the things that we see missing here, with regard to EJB 3.0 and persistence, are the per-request propagation of identity when interacting with the persistence mechanism. This particular issue comes up again and again as a regulatory issue. The requirement is that we need to propagate identity back into the data stores so that the data stores can also do the necessary auditing and authorization checking.

When we get the connection pools, the connection pools have one and only one identity, and so people start running into problems with, "How do I meet my regulatory requirements and yet still continue to have reasonable performance?" That is an alternative they sit and they look at, "Do I make separate JDBC connections and re-authenticate, or do I use the global connection-pool approach?"

Weblogic Pro: In your conference keynote, you talked about defense in depth. Could you give us a holistic view of how that is emerging? How that is shifting from what the touch points for security used to be perceived as?

Patrick: If we roll the clock back five years or so, it was not uncommon to think about bringing Web applications to an enterprise, and that the classic security approach was sitting behind a firewall. What we find now is that in many places—financial services, health care, federal government—we are beginning to see that people are concerned about insiders as well as outsiders. We are beginning to see them understand that there are layers of protection, so concepts like firewalls, network filters, intrusion detections, antiviral protections, coupled with protection enforcement performed as close to the resource as possible, all play together to build this uniform and all-encompassing security fabric.

Some of the more interesting things that we are hearing more about are that people want more auditing, they want more visibility at the business-transaction level of the application. One of the driving reasons for this is they need it for the regulatory auditing purposes. However, there is also a value seen in feeding this level of information into Intrusion Detection Systems (IDS) that are unable to see what is on the wire as a result of encrypted data, higher security, and stronger environments. This not only addresses the visibility problem of encrypted data on the wire, but also can provide additional information to the IDS system that can be used in suspicious behavior detection.

Auditing for Better Security
Weblogic Pro: What do you do with that latter category?

Patrick: This is where they ask for more auditing visibility. The idea is when the processing of the request has begun, the authorization decision must be audited as to whether or not the requestor is permitted to perform the action on the target resource, before it can then be dispatched to the business object. In fact, the security infrastructure needs to report transparently: "I got a request to perform this action on this target resource, here's the identity of the entity making this request, and here are some of the parameters of the request" needs to be recorded. It's then the responsibility of one or more audit channels to record this event or discard it, depending on the audit policy. The audit channel could record the event in a file that could then be used for generation of reports or even used in the replay of a set of transactions as part of analysis of a potential attack. Another audit channel could be configured to report the information directly into an intrusion detection system, which gives that system visibility at the business-transaction level and allows the correlation engines to start looking at what is really going on that they could not see before.

Weblogic Pro: What about some of the more rapid science approaches to security—not just detection, but interception or prediction, intrusion prediction, and….

Patrick: The IPS?

Weblogic Pro: Yes, exactly! How does that vector with your particular sweet spot returns in terms of BEA's products?

Patrick: One of the things that we focused on is the ability to audit security actions at the business-transaction level and provide insight into the core of an application component. Building on this, one of the things that we've done in our security infrastructure is that we've made our authorization capability pluggable so that you can plug in more than one authorization decision provider. With this capability, one can create powerful authorization schemes that include the ability to influence the decision surrounding the ability to perform a requested action on a target that would normally be allowed to be vetoed. So you can have your normal authorization decision—"Can the requested action be performed on the indicated target resource in the current context?"—but also have an external influence, such as an intrusion detection system, participate as part of the decision allowing it to indicate "Wait a minute, this looks suspicious" and take that into account when we make the decision.

Perhaps if the intrusion detection system says, "It looks suspicious," that should veto any other possibility to let that business request continue to be processed. As a result, with our architecture, which is based on a service-oriented approach, we believe that we can support any number of different vetoing schemes, without requiring modifications to existing authorization systems, and begin to have prevention-type scenarios.

Weblogic Pro:What about Honeypots? Is that something that's a part of this infrastructure?

Patrick: Honeypots have met with some good and mixed results. We haven't found a lot of people that use them primarily, because they are complicated to set up and most organizations have a limited resources staff and are trying to focus on getting the business logic done. So I can't really talk a lot about success or failures with those.

Preventing Security Breaches
Weblogic Pro:Basically you see this as much an issue of auditing as it is of prevention?

Patrick: To begin to do prevention—unless you could use some of form of predictive, learning, or heuristics technologies on the edge—I think that auditing information becomes a great source of the information that needs to be included in making security decisions so that we can begin to take proactive rather than reactive actions. Our information must include what has been going in the past. The problem has always been that if we have data protected on the wire through encryption, the classic approach of watching the wire won't work very well. So auditing deep inside the application infrastructure is one of the best ways to get access to that information.

Weblogic Pro: Is there a different kind of a design protocol for allowing this kind of deep application auditing to take place? Or does it require a different design pattern in terms of constructing applications?

Patrick: The problem has always been trying to put security in as an afterthought or glue it onto the side. What we have found that works the best is to consider security from day one in the architecture and design. In many of these cases, what we need to do is get in very close to where decisions are made. Some of the advances that have been done in things like the JACC extension to J2EE 1.4 give us a point where the auditing of these decisions at least could be reported. Although J2EE does not talk about auditing, it gives us a point where we have that data and could begin to audit at the transaction level. In doing it at that kind of level, we avoid the need to engage an application developer to do something different and, in fact, security becomes transparent to the developer.

Weblogic Pro: What about the scaling-up issues with large transaction-based Web service apps? Is that a consideration?

Patrick: Scaling—especially when we start getting into scaling in the dimension of multiple instances all over the network—starts to become an administrative issue, so we are back to that problem of looking at the operational aspects of the system. If we have lots of instances floating around, it is a significant pain and is cost prohibitive to run around the multiple instances and manipulate each of those individual instances to change security settings. This is another important issue that we've heard by talking to our customers.

They continually indicate that they need centralized control of the enforcement of security and, again, it is too painful, too costly for them to go from instance to instance to instance, changing things. As a result, one of the key things is that security configuration and policy needs to be able to be managed from a central place and then pushed or provisioned or replicated out to the actual enforcement point. Second, since these changes need to be done in near real time, once this information is pushed out to the enforcement points, we need the systems to be able to recognize that changes have occurred and pick them up rather than requiring applications to be restarted to recognize them.

Web Services Security
Weblogic Pro: Give me your take on the current status of the Web services stack in terms of security.

Patrick: Web services security at the basic level of tokens and passing tokens to one another has all been standardized. I think most of the companies that worked on Web services implementation are involved in one way or another in interoperability testing as defined by WS-I. As a result, I have confidence that the industry is likely to have interoperability at that level.

The problem is that it is not just about proving identity from one to another. So now we are getting into, "How do we establish trust between two or more parties?" In today's state of systems, that is an out-of-band item and typically a manual process. This is because we have not yet standardized some of the higher-level items in the Web services security specifications, such as WS-Trust, WS-SecureConversation, and WS-Federations. In fact, most of these specifications haven't even been submitted to a standards body for standardization. The second one is, even once trust is established, there has to be a way to control what valid users are permitted to do, which is the topic of the proposed WS-Authorization specification.

Also with regard to authorization, OASIS has done some good work with the XACML standard. It would be interesting to see the marriage between XACML and both the J2EE world and the Web services world so as to allow a common vocabulary that one could use to express policy regardless of the programming or integration paradigm.

Weblogic Pro: What was the standard that you have decided for OASIS?

Patrick: XACML, the XML Access Control Markup Language.

Weblogic Pro: How does that intersect with what is going on in the J2EE space?

Patrick: In the J2EE space, we have the new standard as part of J2EE 1.4 called JACC, the Java Authorization Container Contract, also known as JSR 115. What JACC basically provides is a specification that describes how security decisions for container-based objects can be delegated to an external authorization and role entitlement service. So intersection here could be one that an external authorization engine could make authorization decisions for access to J2EE container-based objects, based on a security policy defined in accordance to the XACML standard. While the use of XACML is not required by the J2EE specification, it is a place where the OASIS standard and the J2EE could meet.

Weblogic Pro: BEA for the last several years has been focused on creating a new tier of Java developers at the business-logic level. How do they intersect with some of the issues that you are talking about in the security arena?

Patrick: The business developer, like any other developer, even the expert J2EE guys, really should not be dealing with how to enforce security in the application code. Often developers confuse the difference between secure code and security code. Security tends to be an operational aspect of the system. That is one of the big changes we see that people are looking for—at the end of the day when I deploy an application it's the operations staff that has to maintain the security of the application. These are not technical development-type people; these are operational people, and they need to see things in business terms. So these folks need graphical interfaces and mechanisms that allow them to manage security in "friendly" business terms rather than in technical "geek speak," if you will.

Security of Mobile Computing
Weblogic Pro: And you see that as something that is becoming available specifically through your product? Or is this something that is more of a broader J2EE developer environment issue?

Patrick: While I've not seen other vendors attempting to address this problem, BEA is certainly looking at this from a business, not developer, point of view. It remains my belief that application developers should be focusing on writing secure code and not on developing security code. I think J2EE got it right in that regard, but could go further. Embedding security code within an application makes the application "brittle" to changes in security policy. BEA's approach to security policy management is to present it in a prose-like approach. To remove the requirement to embed rich security policy within application code, one needs a language that allows the richness of the policy to be described. For example, "you can perform a given action on some resource, if you're acting in a particular role, but only between these hours of the day and only if the request came from an address in this Subnet address range." Based on feedback that we've received to date, it appears that this approach has been perceived favorably.

Weblogic Pro: We have not talked at all about the implications of the mobile space and how it's changing the entire security posture of the enterprise. Do you have any thoughts on that?

Patrick: The introduction of mobile computing has created unique situations that we have to think about. In general, authentication must be done at the device, not user, level, which means that to integrate with traditional systems, there needs to be an association between a device ID and an account, where clearly there is some form of authentication and trust that must be established. In addition, there are issues with the use of data that is accessed and then stored on the mobile device. This is similar to the kinds of security risk issues that we see in today's PC space, where laptops are attaching to an enterprise's network using wireless technology and there is concern that these devices are spreading viruses and worms. Adding to that is the concern that data is being accessed and stored on devices that have little or poor security themselves. Because of some of these concerns, there is a growing interest in providing additional forms of security that ensure that a device attaching to the network meets some level of security, based on policy, before being allowed to attach to the network itself.

Weblogic Pro: Finally, you talk about the dynamic separation of duty. Could you draw down on that a little more?

Patrick: One of the things that we found when talking with customers—whether they be government or in the commercial space—was that people want to think about security as the constraints and rules that define how to accomplish their mission or business. As such, they tend to relate this to the way things run day to day outside of the cyber world.

The key concept behind the idea of separation of duty is to deter fraud if an opportunity exists for collaboration between various job-related capabilities. The difference in dynamic separation of duty is that it provides the flexibility necessary to model security policy more closely to the way the business world works. As an example, it may be too restrictive to have a policy that prohibits anyone that initiates a payment request to be prohibited from authorizing payments. By applying dynamic separation of duty, one could instead develop a policy that permits an identity that initiates a payment request to be allowed to authorize payments as long as the payment was not initiated by the same identity.

When this concept is applied to role-based authorization, such as that found in J2EE, it is possible to either grant or deny the assignment of a role to an individual based on the context of the request. In this case, the PaymentAuthorizer role, which would normally be a capability that an individual might have, would be denied because the target resource is a payment request that was initiated by that same individual.

Goals of an Agile Enterprise
Weblogic Pro: Isn't it the ultimate goal for an agile enterprise to be able to insulate the user from differences between access capabilities depending on time of day and location? Don't you want to make it seamless to provide the role with the access that it deserves?

Patrick: You want to provide the role with the access it deserves always, but the key that needs to be kept in mind is privacy and a concept that comes out of security known as "need to know." As an example, if I work at a financial institution and have access to customer accounts, there is the question as to why would I need to know something about a particular customer's account when I am at home at night. Depending on my role in the company, I may not be responsible for managing customer accounts when I'm not in the company's facility. In this case, I shouldn't be granted the CustomerRep role even though I'm normally entitled to perform that role when I'm in the office. While this may not be true in every situation, it is true for many situations that handle highly sensitive data like health care and national security—in areas like that, where they need this clear separation—when I can do what and under what conditions.

Weblogic Pro: Because the security is less controllable at home, for example.

Patrick: That's clearly one good reason. You can easily imagine this in the financial services, health-care, or government vertical markets where sensitive information is handled. For example, I cannot just connect to a secure facilities network and get access to the same information when I'm at my home as when I'm in my office. Partly that's because I am not on a controlled network, I am not on a controlled device, and as a result the security that is used to validate my identity won't be nearly as strong. In addition, it's also unlikely that the procedures and precautions taken at my home are nearly as rigorous as those that must be followed when I'm at the facility. So as a government employee, I may be able to get into the employee portal that is on a network and manage my personal health-care benefits while I'm at home, but when I am at the office I may have a totally different or even expanded set of capabilities that I can now do because of the environment in which I am sitting.

Weblogic Pro: But the contrast of that is this scenario, which occurred when President Bush was essentially governing just after the September 11 attacks on an unsecured cell phone because there was no infrastructure in place to handle the problem.

Patrick: Absolutely, and proper controls need to be put in place to address this contingency. A similar concept exists in health care, where there has to be the ability to override normal security policy in times of crisis. The phrase that I keep hearing is that "patient safety trumps security." The idea is that when there is a patient whose medical information, which must normally be safeguarded for privacy, must be accessed to save the patient's life, sometimes security needs to give way so that we can do the right thing, even though I may not be the primary care physician, but instead an emergency room technician.

Weblogic Pro: Right, and I think that speaks to the whole dynamic provisioning aspects of the technology. All right, is there anything else that I haven't covered that we should discuss?

Patrick: No, I think that's good coverage.

About the Author
As a principal reviewer with Byte magazine, Steve Gillmor covered Visual Basic, NT open systems, Lotus Notes, and other collaborative software systems. He has been a contributing editor with InformationWeek Labs, editor in chief of Enterprise Development, editor in chief and editorial director for XML Magazine, XML & Web Services Magazine, and Java Pro magazines, and InfoWorld's test center director and columnist. He wrote CRN's Emerging Opp's blog and is eWEEK OpEd columnist and contributing editor. He also is a ZDNet contributing editor, a Release 1.0 contributing writer, and host of IT Conversations' weekly Web radio program "The Gillmor Gang". Contact Steve at steve@gillmor.com.