1 Raindrop

Gunnar Peterson's loosely coupled thoughts on distributed systems, security, and software that runs on them.

Recent Posts

  • Security Champions Guide to Web Application Security
  • Security > 140 Conversation with Pamela Dingle on Identity
  • 6 Things I Learned from Robert Garigue
  • The Curious Case of API Security
  • Security Capability Engineering
  • Ought implies can
  • Security > 140 Chat with T. Rob Wyatt on MQ and Middleware Security
  • Privilege User Management Bubble?
  • The part where security products solve the problem
  • Four Often Overlooked Factors to Give Your Security Team a Fighting Chance

Blogroll

  • Adding Simplicity - An Engineering Mantra
  • Adventures of an Eternal Optimist
  • Andy Steingruebl
  • Andy Thurai
  • Anton Chuvakin
  • Beyond the Beyond
  • cat slave diary
  • Ceci n'est pas un Bob
  • ConnectID
  • Cryptosmith
  • Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics
  • Enterprise Integration Patterns: Gregor's Ramblings
  • Financial Cryptography
  • infosec daily: blogs
  • Jack Daniel
  • James Kobielus
  • James McGovern
  • John Hagel
  • Justice League [Cigital]
  • Kim Cameron's Identity Weblog
  • Krypted - Charles Edge's Notes from the Field
  • Lenny Zeltser
  • Light Blue Touchpaper
  • Mark O'Neill
  • Off by On
  • ongoing
  • Patrick Harding
  • Perilocity
  • Pushing String
  • Rational Survivability
  • rdist: setuid just for you
  • RedMonk
  • RiskAnalys.is
  • Rudy Rucker
  • Software For All Seasons
  • Spire Security Viewpoint
  • TaoSecurity
  • The New School of Information Security
  • Windley's Technometria
  • zenpundit
Blog powered by Typepad

Two States

James Clark, Technical Lead of the original XML Working Group, neatly summarizes why defense in depth is mandatory not optional in Web services, be they Rest, SOAP, whatever:

XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign.

The lack of tooling for secure coding is a real problem, the WS-Security people are ahead here for sure, but there is a lot that needs to be done in all camps. Bottom line: We need a defense in depth security model that composes elements of both the security of the processing state (service security if you will) and the data itself (for example message level security), or as some great American Poets called Pavement put it:

two states
we want two states
north and south
two, two states
forty million daggers ...
two states
we want two states
there's no culture
there's no spies
forty million daggers ...

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

April 09, 2007 in Defense in Depth, REST, Security, SOAP, Web Services, XML | Permalink | Comments (1)

USA Today on Street Value

Asset value is a fundamental risk management practice. The hard part with digital assets is figuring out how much they are worth. One way to measure the value of an asset (and security in general) is to measure the street value. If the price of cocaine is going up then law enforcement assumes its efforts are working well. If the street price is low then the smugglers and distributors are having an easy time supplying demand.

USA Today reports:

Typical costs of goods and services in forums:

  • $1,000 to $5,000: Trojan program that can transfer funds between online accounts.
  • $500: Credit card number with PIN.
  • $80 to $300: Change of billing data, including account number, billing address, Social Security number, home address and birth date.
  • $150: Driver's license.
  • $150: Birth certificate.
  • $100: Social Security card.
  • $7 to $25: Credit card number with security code and expiration date.
  • $7: PayPal account log-on and password.
  • 4% to 8% of the deal price: Fee to have an escrow agent close a complex transaction.
  • Free: Access to a service that gives details of the issuing bank for any credit card number.

1 -- Representative asking prices found recently on cybercrime forums

Source: USA TODAY research

How is this useful to security architecture? The street value of certain items shows its utility to attackers that use the data to steal identity, money, data, and access. It shows the value of defense in depth, because the higher priced items like change of address data and transfer programs require several pieces of data to be compromised for the attack to work.

October 12, 2006 in Defense in Depth, Identity, Risk Management, Security, Security Architecture, Security Metrics, Software Architecture | Permalink | Comments (0)

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.
Leuvensoasecuritymetrics

May 29, 2006 in Computer Security, Defense in Depth, Deperimeterization, Economics, OWASP, Security, Security Architecture, Security Metrics, SOA, Software Architecture, STS, Web Services | Permalink | Comments (0)

O, Perimeter Where Art Thou?

The Jericho Forum continues to make progress in moving the security conversation towards a deperimeterized view, where hard boundaries give way to a more integrated model. The idea seems reasonable enough, but how to practically get there is another story. Dan Blum reports that too much deperimeterization may be an irresponsible approach

Last week at the Infosecurity Europe conference I participated in, and lost, a debate on deperimeterization. I fear that I'm not alone; other security people may also be losing this debate but in situations where the stakes are for real. ... "If you go too far with the deperimeterized architecture it leads to irresponsible security and your organization will rue the day," I said ... There are three classes of mechanisms that can protect information: filters, transforms and enclaves.

Filters keep known good content within some boundary and prevent undesired information from entering or leaving enterprise environments. But they are subject to time based attacks, steganography, and obfustication. This is why we still get spam.

Transforms include encryption or signing to protect confidentiality or integrity of content between distributed users. But users are unreliable (try a web search on "why Johnny can't encrypt"). Also, in widely distributed heterogeneous environments there are many vulnerabilities in implementation and seams between implementations that attackers can exploit. Rights management attempts to protect the content even from its recipient and as such suffers some of the crypto issues and may be actively attacked by its own users. Encryption also introduces recovery and availability issues and can be a management nightmare.

Enclaves are groupings of users and computers that can communicate securely together and keep the rest of the world out. They can be achieved through various mechanisms including network separation and isolation. The hardened, dedicated firewall is in general a higher surety solution than enclaves created with cryptographic or identity based access controls. And the hardened, dedicated firewall offers higher surety than what most filter or transform mechanisms have.

My security research service at Burton Group recommends that enterprises leave the hard shell soft chewy center architecture behind and create internal perimeters to establish zones of trust. Enterprises should have restricted zones that are inaccessible from the internet for things like trading, manufacturing control, and credit card databases. They should have outer zones for extranets or visitors, and business zones on facilities that could be extended through VPN.

Our opponents then countered that they had zones all over the place and kept having to change them. That none of the restricted zones could be isolated. Yes, I reply, but that's what secure proxies are for.

At the end the proponents closed by repeating "the world has moved on" and we can envision these new security technologies that will be great for business. As I mentioned earlier, they won the vote.

It might have helped if I had said what I thougt of later: "The world has not moved on. Human nature hasn't changed. The nature of markets haven't changed. Haven't we learned - there is no new economy. In the five year vision time frame we still won't control all the users and systems in the deperimeterized environment, software vendors may still continue to favor convenience over security, and business constituents may often opt for the cheap but less secure solution. Many users will certainly continue to be lazy or naïve. Criminals and attackers certainly aren't going away. In this environment, how could responsible security architecture not preserve the option to make considerable use of firewalls as a strong separation defense?"

That we lost this debate is, I think, a triumph of wishful thinking on the part of that audience and perhaps others.

There are some good points on both sides of this debate, and the filter, transform and enclave patterns are a very mature way to approach deployment. Dan's blog eloquently portrays the dangers inherent in a reckless approach to deperimeterization. The problem with approaches that rely heavily on perimeters is that as Brian Snow said:


We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.

In other words, we are ok, we have a firewall. No need to worry too much about our "internal" authentication and authorization models, right? Oh except for the 65 exceptions in our firewall ruleset.

And that is the real problem with the perimeter model - it has potential ugly failure modes because once you are beyond that perimeter protection, you are in John Robb's systempunkt-land:


In Blitzkrieg warfare, the point of greatest emphasis is called a schwerpunkt. It is the point, often identified by lower level commanders, where the enemy line may be pierced by an explosive combination of multiple weapon systems. Once the line is pierced, armored forces dive deep into enemy territory to disrupt command, control, and logistics systems. Once these systems are disrupted, the top-heavy military units they support collapse in confusion.

Also, the perimeter model may not be flexible enough to efficiently support new lines of business, new interfaces, mobile clients, business relationships that are spun up and torn down quickly (like call centers).

Butler Lampson's Computer Security in the Real World presentation (wherein he also said that least privilege did more damage to security in the field than almost anything else, but that is another story) outlined the following defensive strategies:

  • Keep everybody out - Isolation
  • Keep the bad guy out - Code signing, firewalls
  • Let him in, but keep him from doing damage –Sandboxing, access control
  • Catch him and prosecute him –Auditing, police
  • Both the Keep the bad guy out and Let him in... strategies relying on some set of whitelist or black list to work off of. These turn out to be difficult to identify and enforce. The firewall at the perimeter does little to stop SQL or LDAP injection, for example, so then the lack of a sandbox or access control model hurts. An enterprise network is an asset and it is worth defending its boundaries, but it is not safe to assume those boundaries are resilient to all attack types. Firewalls may not be ready to be thrown away just yet, but their biggest value may not be a sense of a boundary, but rather an minimal attack surface, diverse OS and limited set of services on their host.

    May 03, 2006 in Computer Security, Defense in Depth, Deperimeterization, Risk Management, Security, Security Architecture, Software Architecture | Permalink | Comments (1)

    Introduction to Application Firewalls and Proxies

    This paper, which is a part of the DHS BSI initiative, by Howard Lipson and Ken van Wyk provides a good overview of App Firewalls and Proxies. The paper discusses some of the benefits of App Firewalls, such as a centralized point for security controls, as well as the drawbacks, and finally summarizes the key decision points to consider if an App Firewall is right for your project. There are several examples given as well.

    February 23, 2006 in Defense in Depth, Deperimeterization, Security, Security Architecture, Software Architecture | Permalink | Comments (0)

    Beyond Kloc: Mining Software Metrics

    Microsoft Software Reliability Research released a paper "Mining Metrics to Predict Component Failures", and this paper is useful from a number of different angles. First, as the title says the authors attempt to build a model based on source code metrics that signals fault probability (incidentally their conclusion is no single set of metrics works for all projects -- no surprise there). Secondly, the metrics used to profile the code provide a more in depth view than simply looking at Kloc or function points. Of course you have to have the code.

    The paper looks at

    · The Arcs and Blocks metrics refer to a function’s control flow graph, which is also the base for computing McCabe’s cyclomatic complexity (separately measured
    as Complexity).
    · The AddrTakenCoupling metric counts the number of instances where the address of some global variable is taken in a function—as in the C++ constructs int
    *ref = &globalVar or int& ref =globalVar.
    · The ClassCoupling metrics counts the number of classes coupled to a class C. A class is “coupled” to C if it is a type of a class member variable, a function
    parameter, or a return type in C; or if it is defined locally in a method body, or if it is an immediate superclass of C. Each class is only counted once.

    Module metrics- Classes, Functions, GlobalVariables

    Per-function metrics — Lines # executable lines in f(), Parameters # parameters in f(), Arcs # arcs in f()'s control flow graph, Blocks # basic blocks in f()'s control flow, ReadCoupling # global variables read in f(), WriteCoupling # global variables written in f(), AddrTakenCoupling # global variables whose address is taken in f(), ProcCoupling # functions that access a global variable written in f(), FanIn # functions calling f(), FanOut # functions called by f(),  Complexity McCabe's cyclomatic complexity

    Per-class metrics —  ClassMethods # methods in C (private / public /protected), InheritanceDepth # of superclasses of C, ClassCoupling # of classes coupled with C (e.g. as attribute / parameter / return types), SubClasses # of direct subclasses of C

    These metrics are well beyond Kloc in depth yet still (given that you have a SCAT) should meet Andrew Jaquith's rule of thumb for metrics:

    Be consistently measured. The criteria must be objective and repeatable.

    Be cheap to gather. Using automated tools (such as scanning software or
    password crackers) helps.

    Contain units of measure. Time, dollars or some numerical scale should be included—not just, say, "green," "yellow" or "red" risks.

    Be expressed as a number. Give the results as a percentage, ratio or some other kind of actual measurement. Don't give subjective opinions such as "low risk" or "high priority."

    February 09, 2006 in Defense in Depth, Design for Failure, Security Metrics, Software Architecture | Permalink | Comments (0)

    Systempunkt in Computer Security

    John Robb nails why computer security is hard. The connectivity and relationships across the Defense in Depth layers means that this scenario is achievable:

    In Blitzkrieg warfare, the point of greatest emphasis is called a schwerpunkt.  It is the point, often identified by lower level commanders, where the enemy line may be pierced by an explosive combination of multiple weapon systems.  Once the line is pierced, armored forces dive deep into enemy territory to disrupt command, control, and logistics systems.  Once these systems are disrupted, the top-heavy military units they support collapse in confusion.

    The "line" that may be pierced in computer security could be a physical, host, app, network, and/or data element. Once the breach is there, a skilled attacker may use this beachhead to launch further attacks that are aimed at the control environment. This is why threat modeling is useful, but does not provide sufficient analysis to construct security architecture. Clausewitz counseled to be "strong, first in general, then at the decisive point." So, in one simple example: your Web Service's WSDL is likely not an end goal for an attacker, but you should still put SSL and other controls on that puppy, because that WSDL is potentially the attacker's interface as much as your Web Service's.

    February 02, 2006 in Defense in Depth, Deperimeterization, Risk Management, Schwerpunkt, Security, Security Architecture, Software Architecture, Systempunkt, Threat Modeling | Permalink | Comments (0)

    My Photo

    SOS: Service Oriented Security

    • The Curious Case of API Security
    • Getting OWASP Top Ten Right with Dynamic Authorization
    • Top 10 API Security Considerations
    • Mobile AppSec Triathlon
    • Measure Your Margin of Safety
    • Top 10 Security Considerations for Internet of Things
    • Security Checklists
    • Cloud Security: The Federated Identity Factor
    • Dark Reading IAM
    • API Gateway Secuirty
    • Directions in Incident Detection and Response
    • Security > 140
    • Open Group Security Architecture
    • Reference Monitor for the Internet of Things
    • Don't Trust. And Verify.

    Archives

    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015

    More...

    Subscribe to this blog's feed