Security and Risk Management Strategies Blog

Location, location, location. . .

(. . .it’s not just about real estate any more)

[blogger: Trent Henry]

Location services and presence aren’t particularly new. For many years, innovators have realized that where-you-are can be a useful piece of information for delivering consumer IT services. If your cell phone knows it’s in a movie theater, for example, it can automatically turn itself to vibrate or quiet mode. Or, if you make an emergency call, a GPS unit in the cell phone can inform responders where you’re located (the heart of the E911 service). These have been topics of discussion among the converged communication crowd for some time. In fact, even associated security issues have been considered for years: in 1997 Leonhardt and Magee wrote “Security Considerations for a Distributed Location Service.”

However, as with so many things, risk seems to follows utility. That is, vendors have spent considerably more time building location/presence functionality, and dreamers have been thinking about cool uses for it, far more than anyone has pondered the security ramifications.

Enter the iPhone.

Suddenly presence is going to be center stage—not because of newness, but because of ubiquity and richness. With millions of these devices marching around the globe, iPhone 2.0’s Core Location Framework becomes a tantalizing target to consider attacking. And to be honest, as an industry we really don’t understand the threat landscape very well.

I’m not going to create a laundry list of possible security issues here. Without more technical detail, it’s difficult to know what will be feasible and what won’t. And detractors love to argue about a vulnerability being “merely theoretical” (until something bad happens, that is). But we do need to think about WiFi and GPS presence combined with full-featured local applications combined with rich web services. This combination can really change the playing field. How about a microblogging client that automatically tracks and publishes location for you and your 50 closest friends? It’s pretty interesting information to know when 50 people converge on a given location at a given time. Such a service isn’t unrealistic (twitter.com), and it reminds me of concerns about RFID-enabled passports used as bomb triggers (ZDnet report).

The flip side, of course, is using location to augment security. For example, an enterprise might check device location before allowing wireless network admission: “Why is this system trying to connect when it’s not even in my building?” But for now I’m more concerned about possible security holes. In an era of increasing industrial espionage, it would be pretty interesting to know that a key person’s laptop or other device was in-country.

Here’s the fundamental problem: It’s not location/presence security itself that’s insecure—the Apple framework requires user intervention for an app to consume location, and it can be turned off altogether. And a web service that shares location data among groups of people or applications may have adequate protections. But bring these pieces together, and mix in the increasing amount of web-based malware and site hijacking taking place, and we need to pause to consider the new risk.

Who’s responsible for such a high-level view? Well, unfortunately, no one. But enterprises would do well to think carefully about employees’ use of location services. And individual consumers should replace a mindset of “whoa, that’s cool,” with “what exactly am I revealing?”

The Impact of Dan’s DNS Debacle on Internet Risk

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:

1. An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
3. The attack is DNS server-specific. Only users on the same DNS server are affected.
4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during  times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.

What do you mean "we can't get in"?!

Blogger: Ramon Krikken

Hypothetical situation: one day you come in to the office, and find out your senior network administrator was hit by the proverbial bus. How sure are you that you have all the information needed to continue managing the network? If instead he went to work for the competition, how sure are you about the integrity of your network?

If the answer is anything but "We're as sure as we can be. This is accounted for in our security program, business continuity plan, and disaster recovery plan. And yes, we do security audits and BC/DR plan tests on a regular basis", it's probably time to check and make sure.

Real situation: the city of San Francisco puts its its senior network administrator on administrative leave, and then finds out no one else could access their city-wide "FiberWAN" network routers. The official details were vague, but an unofficial story purportedly showed the administrator's side of the story . It appears that the situation isn't the usual cut and dried password recovery or reload and restore from backup.

Does it all sound far-fetched? Well, possibly, but in challenging economic times, and even during better times when mergers and acquisitions take place, it is certainly not unthinkable that someone will leave on bad terms at some point. It may be rather unlikely, but it could still happen ... apparently with potentially significant consequences.

I say potential, because the city can't know. After all, without access to the router, they don't know its configuration. The solution could have been as simple as reloading and recovering the password, but that could lead to losing the configuration if it isn't written in NVRAM and isn't backed up.

Or, it could be that password recovery was disabled with a single configuration statement, available in modern Cisco IOS releases, which results in having to clear the configuration and load it from backup if you lose the password. And no, there doesn't appear to be bypass mechanism, even in hardware, for this.

So there you are with an availability-critical system, designed and configured with priority for confidentiality and integrity of its root password without compensating availability controls (backup, configuration audit, segregation of duties, etc.) ... and you have no idea whether you can easily fix it or not.

So it's certainly possible to assume that a product like this is designed with some fail-open recovery mechanism, and that you should be able to trust high-level administrators to behave a certain way, but it's definitely a mistake to do so. Indicative of a defective risk assessment process, or weakness in the governance process, it's something that needs to be fixed.

Of course getting some basic network management security right is important: proper authentication mechanisms, backups, command restrictions, logging and auditing for configuration changes, and so on. But this all presumes that you've actually thought about it, and that you have more than one person in charge of the network.

In the end, only by having strong governance and proper controls throughout the information systems life cycle, will you be able to have assurance that security objectives - including availability and accountability - can be properly met. This includes assessing risks posed by the implementation itself; something that is easily forgotten.

It's not necessarily a lot of work, it's just creating the methodical approach to it all. A bit of governance goes a long way.

Jericho Forum and the Collaboration Oriented Architecture (COA) position paper

Blogger: Dan Blum

After discussing the concept of collaboration oriented architecture (COA) for some time, Jericho Forum released its COA position paper last month at the RSA and Infosecurity Europe conferences. The paper is now posted at http://www.opengroup.org/jericho/COA_v1.0.pdf.

For those who may be unfamiliar with Jericho Forum, it started as a user forum for discussing the problem of deperimeterization, wherein centralized firewalls become less effective as the mainstay of corporate security due to mobility, partnering, outsourcing, telecommuting and all those good things that happen as organizations become more geographically distributed and virtual.

The COA paper focuses on the need for business processes to operate across and between multiple organizations, potentially over untrusted networks such as the Internet. Users and endpoints must securely interact with services and applications controlled by multiple security domains.

The COA position paper builds on the Jericho Forum commandments, which are published at http://www.opengroup.org/jericho/commandments_v1.2.pdf. When reading the commandments, by the way, I find it helps to ignore the explanatory paragraphs, and just focus on the 11 statements of principle. This gets me away from nitpicking the explanations to death and into a state where I just accept them as a very good list of principles for operating securely over open networks.

The COA position paper spends much of its space describing the need for secure, open collaboration as well as principles, processes, standards and frameworks through which the collaboration might be achieved. Most of this doesn’t convey much new information to persons who already grasp the notion of deperimeterization and understand that security is about people, process and technology. But there were some really interesting bits in the section Recommended Solution/Response:

"The COA framework generalizes conventional architectures as follows. It provides:

• increased emphasis on the requirements listed under ‘principles’ below. These are traditionally only seen as external or ‘boundary’ interface concerns in enterprise architectures.
• a user repository (keyed on people identifiers) is generalized into a contract repository (keyed on relationship, or obligation identifiers). A contract repository records agreements, and the obligations and capabilities that ensue from them.
• an accounting log (keyed on system events) is generalized into a reputation repository (keyed on business events). A reputation repository records user actions and compares them to applicable contracts, and, depending on whether or not the actions are in accordance with the contract, upgrades or downgrades a reputation.

The architecture formed by combining SOA (Service Oriented Architecture) with available security protocols (SAML or other XML) is insufficient to support COA. The following elements are also valuable:  [Here, I shorten and paraphrase the list of bullet points]

• attribute brokers
• access brokers
• contract brokers
• policy language (like XACML 3.0)
• performance manager (builds audit logs and reputation systems)”

I wish that the COA position paper had spent more space discussing some of its recommended solutions. The notion of a reputation system (not just a repository) is something we’re hearing more and more about. There is also a growing awareness of the importance of intermediaries, or brokers, that can fairly represent the interests of multiple parties. Perhaps we’ll see this covered in some future Jericho Forum work.

PS: The last bit of COA, in the conclusion, was quite entertaining: “A fundamental shift in thinking is required to implement a COA, moving from the thinking of a hedgehog, an animal that rolls into a tight ball at any sign of threat, to that of a Strawberry Plant, which puts all its key genetic material securely on its outside, as well as sending out suckers to extend the plant’s domain