1 Raindrop

WAF and XSG Risk and Effectiveness at 20,000 feet

I already blogged about one of my favorite presentations at Metricon in which Bryan Ware showed a model of combining risk and effectivness to identify areas to focus on.

Of course, the upper right quadrant of highly effective controls for high risk items make sense to fund, but the harder choices lie in quadrants 2 & 3. Would you rather really make a dent in solving a relatively lower risk problem or partially solve a higher risk item? Bryan's guidance was to incentivize high effectiveness (quadrant 3) over lower effectiveness (quadrant 2). This is a bold move, because it may be seen as ignoring higher risk items, however in the long run it may drive organizations to work towards higher effectiveness.

One area that organizations struggle with is - how to get started in application security? There are a lot of types of controls to consider like static analysis tools, sdlc, threat modeling, strong authentication, federated identity and so on. I have seen several enterprises conduct tradeoff analysis on Web App Firewalls (WAF) which offer some protection web applications from SQL injection and the like and XML Security Gateways (XSG) which protect XML messages and Web Services. So I used Bryan Ware's quadrant to analyze where it would make sense to focus efforts if an organization could choose only one. This is at the 20,000 foot level and both risk and effectiveness are subjective, so YTMMV (Your Threat Model May Vary).

If we assume that risk is higher in the apps that WAFs generally protect, Internet facing portals, than in what XSGs generally protect, say B2B apps on VPNs. Then the WAF goes in the higher risk quadrant than the XSG.

If we further assume that WAFs use a lot of educated guesswork due to performance constraints of signature and anomaly detection on unstructured data in web apps speed then their relative effectiveness is downgraded versus XSGs that may operate on asychronous systems on structured data, and, of course, XSGs can leverage interoperable security standards like WS-Security whereas WAFs rely on patter recognition. Then the relative effectiveness may prove higher for XSGs, again YTMMV. Assuming the above, the decision looks this way.

Depending architecture, threat model and other factors a XML Security Gateway may be a logical choice if you have to choose since it may prove to have higher effectiveness than a WAF. Of course, these need to be mapped to your particular organization, and there are a lot of other controls to consider besides these two, but in my view this model works really well as a decision support tool for hard security architecture choices.

Outsourced CAPTCHA Circumvention

Slashdot (what would Lou Dobbs say?):

"Captchas are a nice idea to protect your blog or guestbook from being spammed by robots. But what good is this protection when you can hire "data entry specialists" to solve captchas for $0.60 per hour for 50 hours a week? Anyone here who can think up a solution that does not include drastically changing the global economy? How about captchas that require cultural background knowledge to solve?"

Who won the world series in 1973?

Build Security In to your SOA

Thomas Erl posted the Top 8 SOA Adoption Pitfalls, and, hey wouldn't ya know, security checks in at 7:

#7 Not Planning for Web Services Security Organizations tend to start small when first building SOA with Web services. The extent to which Web services technology grows within a given environment is typically related to the comfort level developers and architects have with the overall technology framework. Once services begin to take on greater amounts of processing responsibility, the need for message-level security measures as well as security controls that apply to shared services begin to arise. The WS-Security framework establishes an accepted security model supported by a family of specifications that end up infiltrating service-oriented application and enterprise architectures on many levels.

Hmmm...infiltrating...I like that. Let me infilitrate your car with airbags and ABS.

Even if your vendor platform does not yet provide adequate support for WS-Security, and even if your current SSL-based implementation is meeting immediate requirements, it is advisable to pay close attention to the changes that are ahead. Proceeding without taking WS-Security (and its emerging extensions) into account will inevitably lead to expensive retrofitting and redevelopment. This impact will be amplified when organizations begin to grow their service inventory and decide to only then apply the appropriate security

So if I turn this "Not Planning for Web Services Security" around can I say we should Build Security In to our Web Services? It is hard to retrofit security, and not that hard to build it in in the first place. You don't have to go back and restest and redeploy all your transactions for example. WS-Security (and SAML) is a good place to start, then move on to WS-Trust, XACML, et. al. It is still surprising when you talk to vendors, like ESB vendors, who should be in prime position to take advantage of WS-Trust yet they really don't even have it on their roadmap yet, in some cases.

Security is part of the friction that comes with integration. As mentioned in Only Sustainable Edge, the real trick in integration is making sure that the friction is productive friction and not dysfunctional friction, Web Services security standards give a clear path to that, because they deliver interoperable message level security which the industry has heretofore lacked. So systems may emerge from a Web Services integration with security domains that can compose together instead of representing abritrary boundaries because of technical constraints.

The Crystal Identity Assurance Bar

Ok, it may well be diseconomic for businesses to build systems that have enough security assurance to withstand targeted attacks from a determined, well funded foe, like say, a foreign spy service. But shouldn't our identity systems be at least strong enough to fend off meth heads?

NY Times Meth Users, Attuned to Detail, Add Another Habit: ID Theft:

Meth users — awake for days at a time and able to fixate on small details — were looking for checks or credit card numbers, then converting the stolen identities to money, drugs or ingredients to make more methamphetamine. For these drug users, Mr. Morales said, identity theft was the perfect support system.

While public concern about identity theft has largely focused on elaborate computer schemes, for law enforcement officials in Denver and other Western areas, meth users have become the everyday face of identity theft. Like crack cocaine in the 1980’s, officials say, the rise of methamphetamine has been accompanied by a specific set of crimes and skills that are shared among users and dealers....

“Anybody I knew that did meth was also doing fraud, identity theft or stealing mail,” Ms. Carroll said. “We helped each other out, whatever we needed to do that day. They all had their own little role.“

Mr. Morales, director of the Denver district attorney’s economic crime unit, said 60 percent to 70 percent of his office’s identity theft cases involved methamphetamine users or dealers, often in rings of 10 or more.

“Look at the states that have the highest rates of identity theft — Arizona, Nevada, California, Texas and Colorado,’’ Mr. Morales said. “The two things they all have in common are illegal immigration and meth.”...

In a survey of 500 county sheriffs, 27 percent said methamphetamine had contributed to a rise in identity theft in their areas. Even more — 62 percent and 68 percent, respectively — noted that it contributed to increases in domestic abuse or robberies and burglaries...

“Crack users and heroin users are so disorganized and get in these frantic binges, they’re not going to sit still and do anything in an organized way for very long,” Dr. Rawson said. “Meth users, on the other hand, that’s all they have, is time. The drug stimulates the part of the brain that perseverates on things. So you get people perseverating on things, and if you sit down at a computer terminal you can go for hours and hours.”...

Often identity theft rings organize like meth labs, where one person has the technical skills and others gather the raw materials. In an identity theft ring, one person might work the computer and the others steal identities or use the fraudulent checks or credit cards to get cash.

In Minnesota, meth laboratories and users developed a barter economy of washed checks, stolen checkbooks, drugs, ingredients and equipment, said Carol Falkowski, a spokeswoman for Hazelden, a drug treatment center in Center City.

In rural parts of Salt Lake County, Utah, meth addicts take their stolen identities onto the Internet because it has more targets than the local area, said Pat Fleming, director of county substance abuse services. “Meth is one of the major things driving identity theft in Utah,” Mr. Fleming said.

Cocaine and heroin bypassed these areas because importers took the drugs directly to Salt Lake City, where addicts commit different crimes to pay for them....

“I still see people put the little red flags up on their mailboxes when they’re mailing their bills,” she said. “It amazes me. They still put their checks in their own mailboxes, and that was one of the biggest things we did was watch for red flags on mailboxes. You’re sending your electricity bill, you have a check in there, that’s all the information we needed.”

People underestimate the resourcefulness of thieves, she said.

“Five days a week we did it,” Ms. Carroll said. “It was like a job.”

Proposed Amendment to the Laws: The identity metasystem should be resilient to attacks by meth heads. Law 2 which is of course minimal disclosure for a constrained use, is one of the main laws violated that provides the opening for the identity thieves.

One of the major problems in security today is the ability to deliver solutions that are sufficient to stop even attackers with low skill at this scale. The "its perfect or its broken" mentality that permeates so much of infosec leads to the situation we are in today with partial solutions that offer little protection to people...

Metricon 1.0 Approaches

Just a couple more weeks til Metricon 1.0. The lead in is dueling keynotes/parliamentary debates:

Resolved: Metrics are too hard - Steve Bellovin, Columbia University
Resolved: Metrics are nifty - Andrew Jaquith, Yankee Group

Then I am chairing a panel on nailing jello to the wall...err...Software Security Metrics, the track currently looks this way:

"Static Analysis Tool Metrics" - Brian Chess & Katrina Tsipenyuk, Fortify Software
Software Security Patterns and Risk - Christophe Huygens
"Good enough" Metrics - Jeremy Epstein, WebMethods
Metrics for App Flaws in Client Systems - Joel Wallenstrom & Scott Stender, iSec Partners
Attack Surface Metrics - P. Manadhata & Jeannette Wing, Carnegie-Mellon

We look to have a good mix of academic and practitioner views represented. I am looking forward to the conversations. Full agenda

WResting Security Interop

Andre Durand posted some thoughts of mine WS-* and REST

WS-* and REST are often portrayed as competing technologies. While the use cases they deal with do overlap in some cases, there are many instances where each will have its logical place in a given system architecture. Both WS-* and REST are focused on interoperability, so if any two technologies should be able to work together, it is these two.

REST's approach gives developers an efficient way to build and deploy web services using existing technologies that are typically already deployed and scaled out in the enterprise. REST does not provide frameworks to handle the declarative, configuration driven qualities like security, QoS, etc. that WS-* does, but that is not the point of REST. REST style services benefit from integration with security services such as authentication services that can provide increased assurance and security through strong authentication mechanisms like two factor, OTP, etc., as long as these services plug into the existing infrastructure that REST deals with.

Many of the core WS-* use cases are designed for transactional middleware systems like an enterprise service bus. REST was not designed for this purpose, though there are many cases where architects will want their REST services to integrate with their ESB. The goal of this integration is to enable the development and deployment efficiency gains that REST to plug into systems like an ESB and other WS-* systems by bridging the protocols with a STS that brokers communications and allows for a robust, integrated security model.

So what does all this mean to security architects? WS-* has a very useful set of security standards and tools. REST does not. WS-* has ways to deal with securing identity, messages, tokens, etc. while securing REST is more analogous to securing a web app - things are likely to be much more unstructured and customized. Each requires an unique security model, the integration point between the two security realms benefits from interoperability in the security service like a STS that exchanges tokens between the two realms.

All About Early 21st Century Risk

John Quarterman's book
Risk Management Solutions for Sarbanes-Oxley Section 404 IT Compliance is unique, as far as I know, as a very timely analysis on technical issues and their impact on risk management. The combined forces of technology, increased integration, business reliance on networks and systems, and the market/legal/regulatory forces set the context for this book.

Chapter 1 looks at three power laws for scaling networks - Sarnoff, Metcalfe and Reed. Valuing assets is a precursor to any risk management activity. Chapter 2 looks at the differences between traditional risk and Internet-style risks. There is an important distinction in perils and anomalies. Perils are defined as bugs and vulnerabilities. Anomalies are defined as the problems that arise once a vulnerability is exercised. There is also a section on monoculture which compares computing monoculture to bollweevils and other physical world monoculture risks.

Chapter 3 describes high level strategies like redundancy and backups for dealing with risks. These are high level not detailed operational planning, but they are useful for directors to plan what actions manage what risks. Federation is mentioned as having a positive impact on higher assurance integration between service providers and consumers. Another theme is the positive and negative aspects of decentralization, Quarterman concludes it is largely a positive development, and a decade and half into the web, that looks like a safe assumption.

For a book with Sarbanes in its title, there is not a ton of information on compliance. This is not a big a problem for me, since I, like this book, view compliance as a subset of risk management. Chapters 4-8 look at the implications of risk in various business sizes and verticals.

Chapter 6 examines some physical world controls that work fine in the real world but are insufficient in the digital world such as 4 digit PINs for ATMs. This chapter also covers various types of insurance schemes such as Cat Bonds.

Chapter 7 compares Frederick Winslow Taylor (command and control) to John Boyd (smart nodes) and concludes - Taylor Wrong. Boyd Right. Speed and autonomy are more valuable in a networked world. It is often said the important stuff is not exciting, risk management may not be a thrill a minute for everyone, but this book shows why risk management is important to businesses.

Chapter 8 contains an history of technologies, but does not address SOA, Web Services, Web 2.0 et. al in the context of the 5th Wave. Chapter 9 deals with a recurring theme on differentiating between risk inside the perimeter and outside the perimeter and the disparate strategies available. Chapter 10 describes some key differences between SOX (looking for black list items) and Basel II (culture change). Boyd's OODA loop is revisited in the context of self-healing networks. There is a section on the modern military's reliance on the web, which reminded me of a story I heard from Thomas Barnett about how soldiers in Iraq were going into chat rooms to teach other about counterinsurgency. The officers instructed them to stop because Al Qaeda would listen in, the soldier's response:"Al Qaeda already knows this. We are the ones with the knowledge gap." Now the training manuals are being updated.

My favorite part of the book is Cliff Forts versus Coordinated Mesas which detailes the ancient Anasazis Protect-Detect-Respond strategy.

Chapter 11 discerns between first party loss and third party loss. Chapter 12 contains a set of actionable items for companies wanting to improve their risk management.

Overall, a useful window into the current risks and risk management opportunities in the early 21st century.

SOA and Web Service Security Metrics in Leuven

In Leuven at OWASP App Sec conference, the participants in my SOA, Web Services, and XML Security class, we built this set of security metrics for measuring security in a Web Services environment.

The base case includes a Distributor's Enterprise Service Bus that brokers services between a manufacture web service client and a set of supplier Web Services providers

The metrics map examines specific metrics for a XML Security Gateway, a Security Token Server (STS), the ESB, the system, and services. This is not a complete set, but it addresses many areas where commercial systems are blind.

Web 2.0 and Security Too?

Luke Razzell points to an article by Dion Hinchcliffe on REST vs. SOAP. Of course, everyone loves to compare SOAP and REST, but the comparison is usually based on what is best (read:easiest) for the developer. This is certainly a concern, but it is far from the only one. The article on REST's security model:

The actual XML message is contained in the HTTP request and security is provided by HTTPS, which is the secure version of HTTP. This, in a nutshell, is virtually everything that a Web service user or creator needs to know about REST.

SSL? Ok, deep breath. How can you say this Web 2.0 when your security model is not even sufficient for Web 1.0? Of course, there are ways of writing more secure code in a REST-ful way but they depend heavily on the correctness of the developer's implementation, and since we have 10+ years of evidence as to developer's "ability" to write secure web apps, this should cause concern. So when you need to deal with a REST vs. SOAP question, one of the things to analyze is how is REST going to deal with what WS-Security, WS-Trust, and SAML already do in a WS-* architecture, like encrypt and sign messages, and suppot multiple token types.

When it comes to security, SOAP v. REST is not a zero sum game. Security support can be:

a) in the framework (declarative)
b) in the code (programmatic)
c) both of the above
d) none of the above

Simply ruling out choice a for developer convenience is not a fair tradeoff.

WS-* and REST Security Interop

The WS-* v REST debate rumbles along, one thing I have never understood is why when a new technology or language comes into play it suddenly has to answer all existing use cases? There are some use cases which are better suited to WS-* and some that are better suited to REST, there are even some where it makes sense to use both at different layers in the system. From a security standpoint REST has a ways to go to deal with the use cases that WS-* does, however one of my "real world" architectural rules of thumb is that "working code trumps all", and so REST gives a more efficient path to that and so you have cases where you may need interoperate becasue REST is already there and it did not require a bunch of infrastructure.

For example, how about a case of bridging a REST client that needs to speak through some app to get some data from a back end speaking SOAP/XML/WS-Secruity? WS-Trust can exchange the REST credentials for SAML assertions that may be used by the WS-Security message for access control by back end services.