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?

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.

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.

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.

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.

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.

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.

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.

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.

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.