1 Raindrop

Craig Balding's ScanAuth API

via Anton Chuvakin, Craig Balding on Vulnerability Scanning in the Cloud

For cloud providers to attract certain customers, they may need to soften their policy on vulnerability scanning.  Taking a hardline “no” stance precludes some workloads from ever entering the cloudosphere (with bigger consequences for enterprises seeking a strategic cloud partner).  A preferred scenario has the cloud provider showing some understanding of enterprise prospects assurance needs and defining scanning parameters acceptable to their own operations risk tolerance.

Scanning is not an “unknown” risk, rather its a very well understood activity with quantifiable elements (packet rate, state table usage etc).  Normal rate limiting could be temporarily or permanently loosened for customer approved IP addresses to enable scans against a customers cloud IP addresses (not API endpoints or cloud providers websites!) to complete in a reasonable time window.  Besides, Internet systems are scanned, probed and attacked constantly by script kiddies, Internet surveyors and an assortment of bots and other lifeforms.  So the bad guys get to scan because they don’t care and yet the customer, who wants to do the “right thing”, is not allowed to.  Is that rational?

Assuming a cloud provider with a more measured approach towards vulnerability scanning of customer cloud infrastructure, we now need a simple, mutually trusted mechanism to agree scan sources, rate limits etc.  Something like an “ScanAuth” (Scan Authorize) API call offered by cloud providers that a customer can call with parameters for conveying source IP address(es) that will perform the scanning, and optionally a subset of their Cloud hosted IP addresses, scan start time and/or duration. This request would be signed by the customers API secret/private key as per other privileged API calls. The provider receiving the request can rely on the digital signature as proof that a scan is authorised with the associated parameters. After the provider has processed the scan authorisation request, the provider could return a status code approving or denying the request (with a possible reason code to allow resubmission with more acceptable parameters).  This response can optionally include rate limits which the customer can use to tune the intensity of their scanner.

The provider can now whitelist the customer provided scanner IP(s) for the duration of the requested scanning window such that active countermeasures like anti-DoS controls are not triggered, resulting in a ‘cleaner’ scan (and hence a more accurate report).

Very cool idea. I have long wanted something similar for message exchanges, you call a web service, and it sends back the message along with a tag that lists when it was last scanned.

Back of cocktail napkin Request:
  <soapenv:Body>
    <signed securityheader>
<scan source>Ounce Labs</scan source>
<scan date>2009-07-02</scan date>
<scan version>rulepack 3.4.1</scan version>
    </securityheader>
    <req:echo xmlns:req="http://SPhost:8080/axis2/services/PlaceOrder/">
      <req:category>Baseball Cards</req:category>
...

back of cocktail napkin Response

<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <soapenv:Body>
    <signed securityheader>
<scan source>Fortify SCA</scan source>
<scan date>2009-07-02</scan date>
<scan version>rulepack 5.3.4</scan version>
    </securityheader>
      <req:category>Oakland A's</req:category>
...

So just like email scanners sit between the sender and receiver, we can (and do) use static analysis tools to find vulnerabilities in our software services, but what we lack today is a way to convey that healthcheck information to the services we communicate with. 

More Schema Validation Thoughts from Rich Salz

Rich Salz continues the series of thoughts on schema validation from Mark O'Neill and myself. Schema Validation as a Line of Defense.

Again, my main motivation with Schema Validation against hardened schemas is cost effectiveness. the security industry has no shortage of "solutions" that require millions of dollars and acres of time to work, I am interested in finding ways to reduce attack surface for little to no cost. I can count the lines of code needed for schema validation on my hands.

Using a gateway architecture is a further elaboration on attack surface reduction, because the validation is accomplished in a standalone processor and memory space.

BTW, both Rich and Mark work at XML Gateway vendors and I recommend that you buy a half dozen of each of their products.

Mark O'Neill on Schema Validation Downsides

Mark O'Neill is to Web services security as Paul Westerberg is to music in the 1980s, yesterday I posted that Schema Validation is an underutilized security tool because its cheap and easy to distribute validaiton logic. I made the pro case, but of course its never that simple, here is Mark's response Downside of Schemas Validation:

Schemas are indeed useful, but here are some downsides:

- The availability of a schema helps in a plaintext-guessing attack against encrypted data, since an attacker knows what the structure of the unencrypted data is, names of element and attributes, and maybe default values also.

This brings up a good point, I talked about this issue in regard to plaintext schema in XML encryption. So if you rely on anything for validation, you are now putting that on the critical path so it must be protected and customarily schemas may not always be. This creates the issue that schemas must be protected, and relates to schema storage, protection models and a host of other concerns, including:

- Applications which are coded to validate all incoming XML can be diverted to a malicious Schema using the SchemaLocation attribute. The malicious Schema could include very compex checks which would choke a parser. This behavior can be turned off in some platforms, for example here is how it's done in .NET:http://msdn.microsoft.com/en-us/library/ms763691(VS.85).aspx . I should note that Gunnar's code is not vulnerable to this attack since he specifies the Schema in the "schemaFile" variable. But many applications are. It is a neat way to turn a security measure against itself.

For better or worse, the parser and (if used) the schema are now on the front lines. They were never ever designed for network operations, but now they are shunted to and fro and have to deal with Internet threat models. Rots o ruck.

- As Gunnar says, Schema validation is only as good as the Schema itself. Most Schemas are just about the data-types ("this is a string, this is a string, this is also a string", etc). That is not useful for security purposes.

And many schemas don't even do proper enforcement, but my point is that its still a cost effective place to reduce attack surface. 

- Schemas define what should be in an XML document, but are not useful for defining what should not be in an XML document. That is where threat scanning for attack signatures (e.g. SQL Injection) comes in.

Schema validation is not a complete solution. My $0.02 is that its best for types and structures, but not so easy at semantics (even though its technically possible), so yeah, there will still be other validation to be done. 

- Schema validation does not apply to RPC-encoded SOAP messages (partly because type information is included in each element that appears within the SOAP message). Unfortunately, RPC-encoded SOAP still exists in the wild. However, here at Vordel we do the seemingly impossible in our XML Gateway: allowing RPC-encoded SOAP messages to be validated against Schemas. If you need to validate RPC-encoded SOAP messages, check out the Vordel XML Gateway.

- And the biggie: Performance. Without an XML Acceleration system such as VXA in place, Schema validation can add significant latency to message throughput. In fact, that is one of the big reasons why Schema Validation is often skipped in Java and .NET apps (a bad idea!).

I'm not discouraging Schema usage, just saying that some caveats have to be kept in mind.

Standards are great, but they only get us so far. The software development and security communities should not expect to turn the global software architecture inside out with no repercussions and no added security capabilities. Publishing legacy data and functionality on the web through web services without revisiting the threat model, is a recipe for vulnerabilities. There are standards to help mitigate some of these issues, but they only go so far, we shouldn't be surprised that a plain vanilla naive SOAP stack is not sufficient to protect a mainframe hooked up to the web. Instead we need security mediators to build, enforce and manage our 21st century security containers, rules and strategies.

As Mark alludes to XML Gateways are a very interesting place to make and enforce these security decisions. The plain vanilla web services stacks have little to no ability to deal with any of the above issues and many others, not the least of which is access control. So, yeah Web services stacks should ship with a tag that says "Batteries not included" so people know to think through a proxy, gateway or other pattern.

Most Under-Utilized Security Tool: Validation Against Hardened Schema

One of the points I make in training is that security needn't be a 180 degree turn, instead look for ways that you can incrementally make improvements. There are many underutilized tools for securing your system, one of these is schema validation against hardened schemas.

XML can contain any number of beasties from DoS to privilege escalation to any injection family you can name. One of the best defenses against these threats, of course, is validation. The questions with validation is not so much why but how and where?

Schema validation has several advantages - first it uses native XML structures and types. Eventually these will be converted to Java or .Net types but don't you want to validate them first in native form before you convert them and execute? Thought so.

Next, we get very little security without a lot of sweat. It might take awhile to implement an access control system or crypto functionality, but in the case of XML Schema validation we get some interesting security properties for what is basically a for free operation

// Load your schema file & validate against it 
SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); 
Source source = new StreamSource(schemaFile);

Schema schema = factory.newSchema(source);  
Validator validator = schema.newValidator(); 
validator.validate(new DOMSource(sourceElement)); 
} 

For a few lines of code, the validator does the validation heavy lifting for us. What kind of things can the validator check for? The XML validator can assist with checking for structural vulnerabilities such as:

Limit character sets 
Constrain Encoding: <?xml version="1.0" encoding="utf-8" ?>
Limit field length: <max-length>108</max-length>
Define all data types(eschew type:any): <xs:attribute name=”requestDate" type="xs:date"/>

The XML validator can be used for semantic validation as well

<xs:element name="age">

  <xs:simpleType>

    <xs:restriction base="xs:integer">

      <xs:minInclusive value="18"/>

      <xs:maxInclusive value="120"/>

    </xs:restriction>

  </xs:simpleType>

</xs:element>

There are specific attacks around document size, null characters, element nesting and arrays where the schema may be your only chance to defend against content-based attacks before its too late.

Another advantage of XML Schema Validation is distribution, the same XSD schema file can easily be reused, so if you document traverses an app server, web server and ESB, they can use the same XSD and leverage consistent validation logic. This is a major reuse advantage in a distributed system. The receiving app will still need to do additional validation but validating against a XSD beforehand reduces attack surface, limits the possibility of propagating tainted data, and guards against XML specific vulnerabilities (targeting XML contexts), all for a few lines of code.

That sounds pretty easy, but now what difficult part, did I not mention yet? Well, schema validation is pretty useless if you do it against a wide open schema that, say allows type:any or doesn't set limits.

Thanks to Dave Wichers, the energizer bunny of the application security space, for motivating me to write this post.

Update: Mark O'Neill adds some thoughts, and here's my comments

Website Kidnapping

Who says business people don't understand security? The former marketing firm for Steak 'n Shake has executed a DoS, the Varnson Group is holding Steak n Shake's website hostage in a payment dispute.

The Varnson Group signed a $4.36 million, 26-month contract in mid-November, with just over half of that to be paid in Steak n Shake stock. Steak n Shake terminated the deal in early February. 

The lawsuit filed by Steak n Shake March 3 in Indianapolis doesn’t go into why the company and Varnson split. Rather, it deals with the aftermath of the breakup. Steak n Shake claims the agency is refusing to turn over myriad proprietary material, including data, Steak n Shake’s marks, promotional materials, photographs, coupon templates and other print advertisement templates. 

Additionally, Steak n Shake claims The Varnson Group refuses to release a Web site domain name where customers can access and print online coupons. Steak n Shake is seeking unspecified damages and return of the proprietary information. 

As far as we know the Hamburgler is not implicated.

Re-branding security "policy"

In my experience the concept of "policy" is a hard one for many developers to get their heads around, they don't immediately grok what "policy" is or what its supposed to do and it conjures up eastern european cold war regimes. Unfortunately policy is a central concept throughout information security. 

I have been thinking that we need another way to express the same concept to developers. What developers really interact with are Policy Enforcement Points, Policy Decision Points, and Policies. 

The Policy Enforcement Point has two responsibilities, one structural and one behavioral. The structural responsibility is to mediate communication between the subjects and objects. The behavioral responsibility is to collect the message exchanges and send them to the Policy Decision Point. I propose the term "Container" for these responsibilities.

The Policy Decision Point owns the workflow that renders the Y/N/DK policy decision, it uses the information that the Container sends it and may pull in dynamic data or other programs to make the decision. Some of the workflow is static and some dynamic. In some cases its a simple workflow, in other cases lots of nested logic. I think "Rules" or "Strategy" can illustrate this.

So if we take these two concepts the developer implements a container that makes access control decisions based on security rules and/or strategy combinations/permutations.

The other reason I think a re-branding is necessary is that "policy" sounds like a passive thing, in the responsibilities above you can see that the act of enforcing policy is quite active and dynamic.

Not sure if this is any better, but it seems better than policy. What do you think?

Radical Transparency

Inspired by the new federal IT dashboard, here is a sample infosec dashboard that details where information security groups elect to invest their shareholders' money

Using Attack Surface in Threat Models

Last week, I blogged about using threat models to identify and locate countermeasures. Now, I would like to add a little more detail and context. Recall, the purpose of the threat model is to map threats to countermeasures, but he catalyst comes through some part(s) of the attack surface. There are several attack surface models out there, I use a simple one where the attack surface is the sum of the data +  method + channel, that entail the ways the system can be attacked. 

So in an example Web services application we would have an attack surface that includes

• Data: XML
• Method: SOAP or HTTP Verbs 
• Channel: HTTP 

Relating the attack surface construct to our threat model yields interesting possibilities for countermeasure combinations and permutations. Let's assume you are doing security design for a REST Web service and are looking at the constraints and capabilities that REST, HTTP, XML and other standards will help you deal with threats. The combination of the attack surface model and threat model gives you a way to be more precise with mapping countermeasures to threats.

 

Threat	Countermeasure Located in Attack Surface
	Data	Method	Channel
Spoofing	XML Signature (response only)	None	TLS/SSL
Tampering	XML Signature (response only)	None	TLS/SSL
Dispute	None	None	None
Information Disclosure	XML Encryption (response only)	None	SSL
Denial of Service	None	None	None
Elevation of Privilege	Oauth	Oauth	None

This is just an example, but the attack surface is a nice refinement for drilling down on the countermeasure side of the threat model ledger. The location context gives the security designer some flexibility in finding cost effective ways to address security in the software design. In a nutshell, the threat model identifies countermeasures and attak surface locates the countermeasures in the software architecture.

MetriCon 4.0 Preliminary Agenda

MetriCon and the SecurityMetrics list have for several years been host to the most interesting discussions on Security Metrics. This year the MetriCon 4.0 Workshop will be held on Tuesday, August 11, 2009, in Montreal, Quebec, co-located with the USENIX Security Symposium. The formal Call for Participation is still available for your review. As with all MetriCon events, MetriCon 4.0 is by invitation; invitations for attendance-only remain available. If you wish to attend, communicate via email to the MetriCon 4.0 program committee at your earliest convenience.

Preliminary Agenda

1. Baseline Scoring Methods
Reproducible Measurement as a Foundation for Security Assessment Metrics
SCAP Metrics

2. Measuring Impact
Business Focused: Foundations for Security Business Intelligence
Metrics for Detecting Compromised Systems

3. Enterprise Security Management
Security Metrics in Governance, Risk and Compliance
Using Security Metrics to Motivate a Response to A Critical Vulnerability
Foundational Control Practices

4. Software Security
The Building Security In Maturity Model
Does Software Quality Matter?

5. Trends and Stats
Measuring the Future Basis of Competition among AV Products
Crunching Metrics from Public Data
Data Loss DB

6. Security Manager Panel
Asset Profiles
Initiative Alignment
Metrics for Predictive Analysis

7. Discussion Groups on Topics of Mutual Interest
Enterprise Network Security Metrics
PCI DSS Statistics & Metrics
SOX Material Weakness
Vulnerability Response Decision Assistance

Analytical Mindset

From Michael Santoli in Barrons 

IN TALKING TO MARKET PEOPLE OVER THE YEARS, it's clear that the sharper traders and more astute analysts share a couple of traits. The first is to inquire, "What are you hearing?" before they offer their view, and the second is to ask, "Where could I be wrong?" after they do.

The article goes on to discuss "the spirit of challenging the assumptions of the comfortable consensus"; asking the "where could I be wrong?" question is the biggest difference between just programming (getting something to work) and defensive programming (understanding how things fail).