The Lens

iPhone 2.0 is Less Secure

Tue, 10 Jun 2008 13:13:31 -0800

There's nothing quite as effective for illustrating a point than a top n list. Here are the top 4 reasons that the new iPhone is less secure than the previous version.

4. The Price

How could the price make the product less secure? Very simply, the more ubiquitous a platform, the more attractive a target it is. By lowering the price in order to increase market-share, Apple is creating a more attractive base of targets.

3. The SDK

Complexity breeds insecurity. The addition of third party code creates an avenue for exploit. Apple can work to minimize that, but there's a choice of functionality over security here. After all, not shipping the product at all would be very secure.

2. MS Office Compatibility

Do you remember MS08-026? How about MS07-044? Well, welcome to the world of remote code execution via MS Office Documents, little iPhone.

1. Enterprise-Ready

If the price of the iPhone increases its attractiveness as a target due to volume, then being enterprise-ready increases its attractiveness due to value. All the things about other enterprise computing devices that attackers love will now be present in the iPhone. Along with that comes a whole new world of exciting hackability. Who wouldn't want to break into it and see what juicy data the CEO is storing there?

A Virtual Advantage

Wed, 28 May 2008 10:24:25 -0800

First, the article.

Second, the salient quote so that you don't really have to read said article:

"If you are getting any benefit from Microsoft's software, you need to have a license, whether that benefit is for physical machines or virtual machines," Voce said in a session titled "Microsoft Licensing in a Virtual World." "You cannot engineer your way around licensing requirements. You can't use the technology as a way to cut corners around licensing."

The question I find myself asking is whether virtualization diminishes the perceived value of the operating system. As I deploy more virtual servers to do more specialized tasks, along with the very useful MTTR benefits of full VM snapshots, the relative value of the OS in that asset decreases. In fact, if I could have a purpose built OS that's completely built around executing the application function I require. Wouldn't that be far better than loading up a full, bloated, operating environment? In this equation, the value of that virtual appliance model far outweighs the value of the separate OS+Application model of the past. In fact, you might even be willing to pay more for the cost of ownership benefits of the virtual appliance (more for less, so to speak).

That's all well and good to think about, but what's the security angle (I hear you saying). Well, ubiquity breeds risk. A larger pool of targets is more attractive. 100,000 Windows based VMs is just as attractive a target as 100,000 physical servers. Purpose built virtual appliances, however, would increase the diversity of the target population. Further, they're purpose built, and we all know that increased complexity results in more bugs (aka, vulnerabilities). What I'm suggesting here, I suppose, is that the open-source community should figure this out before Microsoft because right now there's a clear financial advantage to using a free (as in beer) OS for your multitude of virtual images.

Secure360 Conference

Mon, 12 May 2008 10:00:46 -0800

I'm headed to the Secure360 Conference in St. Paul tomorrow and Wednesday. Despite the name, it doesn't have anything in particular to do with IP360 or nCircle. I attended this show last year and it was pretty valuable if you're part of the Twin Cities InfoSec community. Here are the sessions that look interesting to me and why:

Christopher Buse
Chief Information Security Officer, Office of Enterprise Technology, State of Minnesota
Building An Enterprise Security Program

In some ways, federal and state agencies are like large enterprises where the same problems are just harder to solve. You have more bureaucracy and no profit motive, which makes for some interesting challenges.

Anton Chuvakin
Chief Logging Evangelist, LogLogic, Inc
Application Logging 'Worst Practices'

This just sounds like fun.

Jay Cline
President, Minnesota Privacy Consultants
Project Plan for Data Inventorying and Mapping

Identifying and mapping sensitive data within an organization is a huge challenge. I'll be interested to see if Jay has any novel approaches.

Jenny Geisler
Principal Consultant
Governance and Ethics: An Overview

This has the potential to either be very very interesting or give me a chance to catch up on some sleep. There are some difficult questions to explore with governance and ethics, but you could easily have a presentation of the same title that studiously avoids all of them.

Ray Kaplan
Principal Consultant, Ray Kaplan & Associates
Spreadsheets From Hell - Measurements to Metrics

I'd rather see this presentation from a non-consultant, but it still has the potential to be informative.

Brent Lassi
Director of Security, Digital River, Inc.
Building a Culture of Security

It was this part of the description that got me, "resulting in a viral spread of security knowledge." Tapping into the socio-cultural mechanisms within an organization is a great way to get knowledge distributed.

Seth Peter
CTO, NetSPI
Payment Card Industry Data Security Standards Update

Always keeping up to date on PCI.

Gunnar Peterson
Managing Principal, Arctec Group
Building a Security Architecture Blueprint - A Strategic Approach to Enterprise Security

There's enough overlap here with Chris Buse's earlier presentation that I'll be interested to see how they compare.

Well, those are the sessions that caught my eye on the first pass through the agenda. I haven't checked out the schedule, so I've got no idea if I can actually attend them all. Maybe I'll see you there.

It's Not Always About You

Wed, 02 Apr 2008 07:07:32 -0800

Earlier this week, someone asked me this question:

"What should the PCI Council be working on next to protect card holder data?"

I thought about this for a while, and decided that the only honest answer is nothing.

I will acknowledge up front that the PCI DSS is lacking in a number of ways, that it could be changed to better protect card holder data and that even a fully compliant merchant still puts card holder data at risk. I'll also ask this question, fair minded reader: Who cares?

As one who holds a few cards, I care. A merchant who wants my business *might* care, but only if they think that the strength of my conviction is such that I might not shop there. The PCI Council is the furthest from caring in this chain, and the successful adoption of the PCI DSS will only make them care less. How so? Well, it's all about revenue and liability.

The PCI Council represents the card companies, who are *gasp* in it for the money. For them, card holder data theft is a liability. It hurts their bottom line if they have to pay out and it hurts their bottom line if card holders don't use their cards. In other words, they can't make themselves liable and they can't make the card holder's liable; neither option is viable for their business. The PCI DSS allows them to place liability at the merchant, which is largely appropriate given their relationship to the card data.

The PCI DSS protects two ways:

Basically, the merchant chooses one of two states: Compliant or Non-Compliant. If they're compliant, then they're less likely to have a breach and compliance can also instill card holder confidence. If they're non-compliant, then they're electing to take on the risk and liability of any breach that occurs. In either circumstance, the card companies have successfully limited their liability.

Hannaford, Hannaford, Hannaford. I know what you're thinking. What about a compliant merchant that experiences a breach?! Well, here's the test. Theoretically, Hannaford shouldn't be liable. I'd argue that it's in the card companies best interest to pay out in this case. They solidify the positioning of PCI and probably increase adoption by merchants too. We'll just have to wait and see how it plays out.

But I Egress...

Mon, 31 Mar 2008 05:20:50 -0800

We're often so focused on who is getting into our infrastructure that we forget about who or what might be getting out. It's a natural tendency, of course, given the focus that InfoSec has traditionally had, and given that we still have the problem of people getting in. There's a quote at the end of this article about the Hannaford breach:

"Clearly, there was a pathway back out of the network that Hannaford should have closed,"

How many organizations implicitly trust outbound connections from their own servers? How many organizations inspect the content and patterns of outbound connections? In this case, Hannaford might have seen correlation between credit cards being processed and a connection out to "an overseas destination," or at least an unexplained outbound connection to that destination on a regular basis.

Having just watched Ocean's 11 last night, I'm reminded that overcoming the challenge of getting into the vault is worthless if you can't manage to get out with the cash.

It's not about technology

Mon, 17 Mar 2008 06:46:14 -0800

Sometimes we all need a reminder of the obvious.

This article from Infoworld reminded me of something I'd learned a while back and recently forgotten: Information Security is not about technology.

"Ultimately, the most significant point of disconnect between security pros and the business people they work with is the struggle to balance issues of protection and compliance with efforts aimed at growing sales and revenue, which the panelists characterized as a near constant 'tug-of-war.'"

Does this sound familiar? If I can quote a popular Internet meme here: "You're doing it wrong."

This tug of war is what happens when information security and executives fail to understand that they're supposed to be pulling in the same direction: towards revenue. This is actually quite fundamental, but traditionally really hard to manage.

CFO says: "I think in terms of risk -- sometimes that's about dollars and sometimes it's about reputation, but you need to tell me, what's the real risk that could actually hurt the business? It's all about getting the language and communication right"

And this is the crux of the problem. Infosec needs to assess and articulate risk in terms that the organization can understand. It's not our jobs to protect the company from things it doesn't know about, but to inform the company about risks, possible solutions, and impact of those solutions. The decision of whether to accept risk or not should be based on the impact to revenue.

Maybe every information security team needs to hire a communications person, someone who specializes in information presentation, rather than information assimilation. In every InfoSec group, we should be asking ourselves who provides the guidance about how to deliver data to other parts of the organization.

MDI DSS: The Next Regulatory Front?

Wed, 12 Mar 2008 13:29:17 -0800

It's a wonderful thing that a doctor can wirelessly reprogram a pacemaker for a patient to deliver better care. It seems quite odd to me, however, that no one thought to protect the connection with authentication and encryption. That being said, vulnerability is not new.

This paper not only discusses the potential vulnerability of Implantable Cardiac Defibrillators (ICDs), but also presents some very interesting ideas around authentication.

Basically, the problem is as follows: any authentication mechanism requires power consumption, and these devices are resource constrained (i.e. battery operated), so adding a repeatable activity that could be engaged to consume power amounts to a denial of service attack. Now, we can solve this problem in the InfoSec world with account lockout policies. You can't, however, have a situation where a doctor is locked out the pacemaker, I imagine. Instead, you need to prevent the DoS by developing a "zero power authentication" mechanism. They also talk about harvesting entrophy from patient movement and vibration, as well as some considerations of patient notification of security events. It's not a long paper, and is a pretty interesting read.

The concept of implantable medical devices isn't new, but the extension of interaction with these devices to outside the patient is just beginning. I can imagine the development of a Medical Device Industry Data Security Standard that dictates the requirements for in-patient connectivity. The stakes here are as high as they get.

Old Skool is Still Cool

Mon, 23 Jul 2007 09:27:40 -0800

If you ever find yourself wondering if simple directory traversal vulnerabilities are still relevant in this day and age, go read about Fox News. It's unfortunate that we don't know, and probably won't know, how long this condition was present. Was it an initial configuration issue or the result of some update or change?

It's also a reminder why continuous configuration and vulnerability assessments are really a requirement. This condition's presence on the public Internet for even a few minutes presents a significant opportunity for compromise.

*UPDATE*
Apparently, just to make it interesting, the access gained with that user/pass provided 1.5 million names, phone numbers and email addresses.

The End Of The World (As We Know It)

Thu, 24 May 2007 06:46:26 -0800

On Tuesday I heard Marcus Ranum talk at the Secure360 show in St. Paul. His general premise, which I won't enumerate fully, was that market consolidation, increase in legislation, and the general lack of relationship between actual attacks and information security spending will lead to the demise of the information security professional as we know it and the introduction of a lawyer-driven regulatory compliance-centric checkbox in its place (more or less).

Despite being a sort of glass-half-empty discussion, there were a couple of points that stuck in my head and warrant some exploration.

First, Ranum asked this question in relation to the increasing legislative environment (paraphrase): "When has more legislation ever made things (better | less complicated | easier)." Despite it's rhetorical nature, I wanted to find an answer. It's easy to think of legislative movements that haven't improved things, but those that are really beneficial are likely to be forgotten. For example, driving. The use of the road system in the United States is extremely varied and regulated, but I can't imagine there are too many people who would argue that the laws surrounding transportation don't benefit the general public. You might want the speed limit increased (or decreased), but one hardly argues for the abolition of drivers licenses. Ok, so it's possible, but that doesn't mean it's likely.

Second, and more importantly, I couldn't help finding myself wondering if the ultimate conclusion that Ranum came to was actually bad. I mean, it was clearly bad news for the techie who wants to keep purchasing and implementing nifty security tools, but given the other conclusion present, namely that all this economic activity hasn't actually had a positive impact on the overall risk that organizations realize, it is really bad for business overall? Is it bad for the public in general? Perhaps I can demonstrate why I don't think it is.

Right now, information security is a losing battle, both functionally and financially. Money and time are spent without a measurable return, either in risk mitigated (loss prevented) or revenue. It's been that way for a while, which has naturally pushed efforts for standardization, especially around metrics (CVSS). As we gain the ability to measure risk, we produce a corollary body of knowledge around risk reduction. This discipline splits into two: secure development and secure configuration. That split mirrors areas of responsibility: developers who are responsible for code and users who are responsible for deployment. The pattern to watch for here is the distance between responsibility and authority. So, efforts like the PACB aim to put the responsibility for secure code into the hands of those who have the authority to change said code. Likewise, efforts like XCCDF, CCE, and CIS aim to put the responsibility for configuring environments securely in the hands of those who have the authority to do so. Where does legislation fit? Well, legislation is useful only if there are valid standards to which it can point. In other words, a 'code securely' law only works if there's a standard for doing so to which it can refer. The same goes for legislation around secure deployment and configuration. This is where the compliance market really develops. A successful piece of legislation specifies a clear standard and validation of adherence to it. The point at which penalties become involved is where the lawyers come in. So, in five or ten years the compliance auditor very well might find herself working for a lawyer and working on a JD. This conclusion is roughly the same as Ranum's, but drawn in a positive light it looks a little bit more rosy.

Information security as a whole moves from a poorly defined, immeasurable cost center to a clearly specified, predictable compliance function. Residual risk is then much easier to transfer via insurance. That's a lot easier to work with from a budget and business standpoint. The FUD gives way to operations, which lets businesses get on with doing business. The information security professional moves into either network/system administration (business enabler) or compliance (business requirement). That doesn't seem like such a difficult situation to me, and it seems like an improvement overall.

Headline Entertainment

Wed, 16 May 2007 12:11:49 -0800

As I was paging through my RSS reader, I came across a pair of headlines that made me chuckle sitting next to each other:

IBM, Symantec Tackle Compliance

IBM loses tapes with employee personal info

If you don't actually go read the details, it's worth a small laugh.

The Law of PCI

Tue, 15 May 2007 09:43:35 -0800

Texas has passed a bill that makes PCI compliance a law. You can check out the text of the legislation here. The bill allows a financial institution to 'bring an action' against a business if they are in violation of the PCI DSS at the time of a breach. Interestingly, in order to 'file an action,' the financial institution must first request that the business provide certification of compliance with the PCI DSS and the business must provide that certification within 30 days.

In other words, the work flow that this bill establishes is as follows:
Assumption: Business is not PCI compliant, though it is required.
1. Breach occurs.
2. Financial institution finds out about it (see Texas SB122)
3. Financial institution requests PCI audit from business
4. If the business passes the audit, nothing happens. If the business fails, the the financial institution may be able to collect damages from it.

Let's consider how this interacts with the requirements of the card companies. Any business that's processing cards is already required to comply with the PCI DSS, so they should (given an appropriate merchant level) be audited annually already. This law adds an 'on demand' audit in the case of a breach. A business might be able to bring themselves into compliance and get audited within the 30 day window, but it would be really tough for an organization of any size.

Also interesting is the provision that a business is safe if they contract out to a third party for processing services, and obtain some assurance that the third party is PCI compliant. Such a provision pushes retailers in the direction of outsourcing card processing, in turn centralizing PCI enforcement further.

What we have here, ultimately, is an(other) attempt to push the liability closer to the party responsible for the risk. It makes sense, really. Any time responsibility (for damages, a breach, etc) and authority (to eliminate risk, add security) are separated, there's bound to be a problem.

PCI: Is Compliance Really the Goal?

Mon, 23 Apr 2007 07:40:11 -0800

In reading this article from Dark Reading, which quotes a recent RSA survey about PCI compliance, I'm struck by what seems like a missing component. The basic gist of the survey results is that while more than 50% of merchants haven't complied with PCI, the majority of them are smaller, level 4, merchants. There are other interesting bits of data in there too, but the whole article makes a tacit assumption: the goal of PCI is that merchants comply.

I think that really is the goal for larger merchants, but I'm not so sure about the smaller one's. I can't help thinking that for a smaller merchant, the cost of compliance would often exceed the cost of simply outsourcing the card processing such that PCI no longer applies. To be fair, I haven't done the serious research to determine whether that's true, but given the implementation time lines referenced in the article, it seems plausible. It's also possible that there aren't outsourcing services that really meet the needs of smaller merchants.

Either way, if PCI doesn't start "motivating" the smaller merchants, then compliance will continue to lag. The numbers are skewed, however. Perhaps it would be better for RSA to measure the percentage of PCI compliant transactions instead.

Bad Habits or Good Marketing

Mon, 26 Mar 2007 04:22:54 -0800

Flixster wants you to give them access to your email accounts so that they can invite everyone from your address book to join Flixster. They do this by asking you to provide them with the password for those accounts. Read here and here for details. This is bad. Very bad.

The argument in favor of this tactic is that it's simply good marketing and good usability.

Joe Greenstein, founder, said in an interview, "We make it easy to invite your friends. Other sites don't provide good ways for people to spread the word. And, we tried to build a really compelling site."[source]

I have several problems with this approach. First of all, I don't want any company that begins their terms of service with a picture of a monkey and "I can't believe you really clicked on this. What are you trying to find out?" storing any password of mine. Of course, they also "reserve the right, at our sole discretion, to change, modify, add, or delete portions of these Terms of Service at any time without further notice." Does this little guy really inspire confidence?

I think that's the obvious issue. The less obvious problem is that Flixster is teaching users bad habits. Handing out your password(s) is not a good thing to do. The security industry and organizations have been trying to educate users on this point as much as possible. Users should be wary of third-party sites asking for login information. Flixster shouldn't make that activity normal. Somewhere out there, someone is looking to fund a startup called Bankster that will happily help you manage all your bank accounts.

PCI Confusion: What is Compliant?

Fri, 23 Mar 2007 13:16:55 -0800

As you may have noted, nCircle recently introduced our Certified PCI Scan Service, which means that we achieved certification as an Approved Scanning Vendor from the PCI Security Standards Council.

One of the requirements of PCI is that we score vulnerabilities according to their standards. You can read about them in detail here, but the gist is this table from the Technical and Operational Requirements for ASVs:

Anything scoring a 3 or greater constitutes a non-compliant system and therefore a non-compliant customer. As of June 30, 2007, PCI is changing the scoring criteria to use CVSS instead of their ranking system, as noted in the same Technical and Operational Requirements for ASVs. The use of an external standard is an improvement, but I'm confused about one particular note in the requirements (pg 4-11):

Does anyone else read that last bullet point as saying that Denial of Service conditions will no longer constitute a non-compliant system? In the current ranking system, DoS falls clearly into category 3, which is non-compliant. Is PCI following OpenBSD or vice versa?

Is Brand Damage a Myth?

Wed, 21 Mar 2007 04:35:06 -0800

Yesterday I saw a presentation from a sales rep of PointSec at a local ISSA meeting. Aside from the fact that it was, I suspect, largely a straight copy of their standard sales deck, there were a few interesting points, the most interesting of which weren't really made in the presentation, but more made about the presentation. He talked a lot about data loss, data value, and the cost of data recovery. The interesting thing is that the usage of these very distinct terms was haphazard. Data loss, specifically the loss of data via equipment loss, was highlighted to emphasize frequency; "These things occur all the time!" Data value was highlighted to emphasize severity; "And they are very serious!" Finally, the cost of data recovery was presented as the usual 'infinite brand damage' metric; "And one loss could drive your company out of business!" It's a favorite of mine, incidentally.

There are several problems here. First, he never quite manages to connect the data loss to data compromise, i.e. the fraudulent use of stolen data. I'm not saying the connection doesn't exist, but that the focus on loss over compromise is misleading. Data compromise is a serious problem that seems underreported, probably because it's hard to measure. That doesn't mean it isn't important to measure. Secondly, data value isn't the same as cost of recovery, or at least it's not reported as such. Look at this recent incident in Alaska. They lost a $38 billion file, but the cost of recovery was closer to $200,000.

And last, but not least, there's the 'infinite brand damage' metric. Let's look at a few examples via a three point analysis. For these purposes, the 'date of incident' is the date it became public. Stock prices are at the close of the market around the same date in the appropriate month. I picked four relatively high profile incidents, but there are more.

TJX (1/17/2007)
Stock Price 3 months before incident (October 2006): 28.97
Stock Price today (March 2007): 26.46
Stock Price 6 months after incident: N/A

Ameriprise AMP (1/29/2006)
Stock Price 3 months before incident (October 2005): 37.10
Stock Price 3 months after incident (April 2006): 49.04
Stock Price 6 months after incident (July 2006): 44.54

Choicepoint CPS (2/15/2005)
Stock Price 3 months before incident (November 2004): 44.01
Stock Price 3 months after incident (May 2005): 37.16
Stock Price 6 months after incident (August 2005): 43.22

ADP (7/6/2006)
Stock Price 3 months before incident (April 2006): 46.78
Stock Price 3 months after incident (October 2006): 47.47
Stock Price 6 months after incident (January 2007): 48.76

Using stock price as an indicator, one can conclude that either the brand damage isn't very significant or these four companies worked very hard at recovery. Clearly, I can't measure the direct increase in money spent on brand recovery by each of these organizations, but also clear is that none of them were irreparably damaged by their respective incidents.

The thing is, brand damage is driven by public perception. The more data loss disclosures that occur, the more the public perceives them as normal and, in turn, the less likely becomes the risk of brand damage. This is why (appropriate) punitive damages are an important part of the regulatory environment. The public can only react in a significant way to outliers in the incident arena, and if data loss is normal, then the fear of public reaction is not a valid incentive.

*UPDATE*
With perfect, yet unplanned, timing: "Data from TJX Security Breach Fuels Fraud Scheme"