1 Raindrop

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

Richard Monson-Haefel on 9 Things Every Software Architect Should Know

Last night, I saw RIchard Monson-Haefel talk on 9 things every software architect should know. The funniest line was on EJB "I feel like I had a kid and he grew up and went on a crime spree", Richard's list of 9 things:

1. People are the plarform (ui is often the weakest link)

2. "All solutions are legacy" (My old partner used to say nothing more permanent than a temporary solution)

3. Data is forever (everything changes - new technology, new processes, but data is evergeen)

4. Flexibility breeds complexity (My security corollary is you empower developers you empower attackers

5. Nothing works as expected (Finally a security principle - design for failure)

6. Know the business 

7. Maintain the vision. Should be cto but how can they do it? They are in too many meetings

8. Software architects should also be coders

9. There is no substitute for experience

I think its a good list, I think #5 is under emphasized of course. Securing software often comes down to developers and security people, but this is not enough. Software people don't know enough about security and security people don't know enough about software. So we need another layer to resolve this. Software architects are supposed to own the non-functional requirements like scalability and security, but too often security is just network firewalls and SSL. Software architects are in a good position to see the failure modes and drive projects to fix vulnerabilities and establish countermeasures.

Floors and Ceilings

Heartland update from WSJ: Heartland Gets Religion on Security

Aside from the scale, the breach stood out from the hundreds of others reported each year because Heartland had recently passed a security audit.

Carr says that one lesson he’s learned from the breach is that the industry’s security standard, called Payment Card Industry or PCI, doesn’t go far enough. It’s the “lowest common denominator,” he says, adding that the audit didn’t detect the vulnerability that led to the hack even though it had existed for years.

Carr also believes that the vast majority of breaches go unreported. He says that around 300 companies were victimized by the same hacker as Heartland, but that most have never come forward. He points to loopholes in the state laws meant to protect consumers in the event of a data breach as the reason.

I could not agree more with the emphasis added bold text. This is not a slam of PCI just reality. Setting a minimally acceptable floor is an important maturity step just not the only one. Anyway, shooting closer to the ceiling than the floor, it looks like Heartland is going to use Voltage's end to end encryption.

Using Threat Models

Threat models are a very good way to make implicit security threats and mechanisms, into explicit threats and mechanisms, so that you can write requirements, build, and test that they do the job you intend. As a starting point, I like to use a modified version of STRIDE, which among other things cleanly maps threat to mechanism. This way when starting a new project, for example with SOA Web services, you can identify where the standards will help you.

 

Threat	Mechanism	Example Standard
Spoofing	Authentication	WS-Security
Tampering	Digital Signature, Hash	WS-Security + XML Signature
Dispute	Audit Logging	None
Information Disclosure	Encryption	WS-Security + XML Encryption
Denial of Service	Availability Services	None
Elevation of Privilege	Authorization	None

Threat models are misunderstood, they are not about modeling threats. As defensive programmers, we have little to no control over threats, our job is to find and fix vulnerabilities. So why bother with threats and threat modeling at all then? It turns out that vulnerabilities are basically passive weaknesses, and the threat is the catalyst that exercises the vulnerability so that we can 1) identify it and 2) deal with it. 

So the end result of threat modeling is not a list of threats, but rather a list of countermeasures. And not just a generic list either. The active ingredient (threat) gives us a way to locate where the countermeasure can/should live in the architecture.

Further, if we are comparing approaches early in architecture/design phases of building software, the threat model is a structured back of the cocktail napkin way to compare/contrast approaches. For example if we are looking to build out a set of Web services and are choosing between SOA style (WS-*) and REST style, we may want to look at the readily available implemented standards that each software security stack supports

 

Threat	Mechanism	Example SOA Standard	Example REST Standard
Spoofing	Authentication	WS-Security	XML Signature (response only)
Tampering	Digital Signature, Hash	WS-Security + XML Signature	XML Signature (response only)
Dispute	Audit Logging	None	None
Information Disclosure	Encryption	WS-Security + XML Encryption	XML Encryption (response only)
Denial of Service	Availability Services	None	None
Elevation of Privilege	Authorization	None	None

Threat modeling gives a concrete structure to a fairly abstract subject like analyzing software security capabilities in services, but as you see its not about the threats its about the security architecture elements. This is just an illustrative example not a complete threat model, but it does give an effective, context-sensitive way to look at tradeoffs in security architecture. In this example, SOA/WS-* has potentially more coverage the security mechanisms work on both the request and response side. In the next series of posts, we'll look slicing and dicing the threat model a layer deeper and how we can use it secure our services.

Update: Using Attack Surface with Threat Models

Twitter-enabled Information Disclosure in Sports

In one of my favorite Richard Thieme talks at Black hat, he exhorted us to look to the edges to find where the new realities are forming. The consensus reality of today is one thing, but the new realities creep in from the edges outside of today's norms. 

Sports has been one area in American life where we can clearly see this happen. We have had Jackie Robinson breaking the color barrier in baseball long before Martin Luther King Jr and others brought this to the wider society. In 1966, we saw Red Auerbach name Bill Russell the first African American coach, 42 years before Americans signed up to have Barack Obama run the whole country. 

Of course, not all the new developments are positive, witness the ongoing sagas in steroids in sports which we will likely also see in wider circulation throughout society with things like biotech, genetic modifications and so on.

On a related note, last we just had a case of information leakage in pro sports via Twitter. In the NBA this off season people have been wondering if coach Kevin McHale would be coming back next season, while fans waited for some kind of news Minnesota Timberwolves rookie star Kevin Love tweeted 

"Today is a sad day. Kevin McHale will NOT be back as head coach."

Turned out to be true. Only thing was the Timberwolves had not issued any official statement of the sort. Love's explanation was that he assumed that everyone already knew. Normal behavior from an insider, but a good example of information breaching the walls, and not through malice, just through increased connectivity. Now that we see the template in sports, it will be interesting to see these things play out in wider population