I find that legacy code poses a unique challenge for organizations rolling out a new security process.  Often, the resources dedicated to maintaining older code are a small fraction of those devoted to new features or products.  Furthermore, the original developers for such features have often moved on, leaving no subject matter experts to drive reviews.  The astute reader will ask “How do I apply the principles of the Microsoft SDL to legacy code when I have no development resources and nobody knows how it works?”

The answer is “Start small, and build expertise over time.”

A Rising Tide Lifts All Boats

The best thing a security engineering team can do to improve security in the short term is to drive code quality, and the first step in this process is to define and enforce a secure coding standard.  This helps on two fronts: 

1.       It will improve code quality and reduce implementation flaws across the entire code base.  Unlike other security processes, driving a secure coding standard is relatively easy to accomplish across an entire code base, regardless of the code’s age, by a focused security team.  That is not to say that it is easy without qualification – a large batch of spaghetti code will require a lot of work to untangle!  Such an effort can only be called “easy” when compared to, say, comprehensive identification and remediation of design flaws across legacy features.  Even so, improving code quality through the use of secure coding standards offers a unique combination of high impact, applicability to features, and ability to be carried out by a core team that makes it a sensible first step.

2.       The security team might notice that some sections of code have more standards violations or outright flaws than others.  This is an instance of vulnerability clustering, a concept that has been used to predict vulnerability rates and improve quality in the functional realm.  The evidence is anecdotal, but it stands to reason that portions of code that consistently violate secure coding standards are good places to start looking for other classes of security flaw.  These are security hotspots, and should be high on the prioritized list for further review.

Security testing may also be applied to legacy code, but initial activities should be considered on a case-by-case basis based on the expected return on investment.  Such testing ranges from using inexpensive off-the-shelf tools to exercise common interfaces to rather expensive custom testing and formal analysis.  It is worthwhile to begin with off-the-shelf tools, such as those that target file parsers or web applications, and tools created as part of your greater secure development efforts.  These can help identify easily-found flaws and suggest improvements to the coding standards.  Comprehensive security testing, on the other hand, is best tackled after the Legacy Security Push.

The Legacy Security Push

Coding standards and basic testing provide bang for the buck, but formal security processes seek to provide security assurance.  The challenge for legacy code is that it needs to play catch-up.  Security processes that occur early in the development cycle, such as requirements analysis, design review, and threat modeling, are particularly difficult to achieve years after the fact.  The main goal of the Legacy Security Push is to create the deliverables from these efforts, the most important of which are security requirements and a full risk analysis.

It may sound trivial, but security requirements are essential.  Not only do they define proper operation for the system in question, they also define assumptions that are suitable for relying systems.   It is very common to find security flaws in legacy systems that arise from well-intentioned but incorrect assumptions such as “I assume that the Foo authenticates server Bar when initiating a bank transfer.”  It stands to reason that Foo would do so for such an important activity, but this assumption must be validated.  It is very common for older features to have been deployed in and written for different environments where the security assumptions that are "obvious" today just didn't apply at the time.

When reviewing legacy systems, the first step is to identify such requirements.  If the original architects, developers or managers are available, they can provide valuable insight at this stage.  More often than not this is not the case, and analysis must instead rely on what documentation is present and interaction between the software and its consumers.  The goal is the same as in requirements analysis during project inception, except that in this case one must turn the process on its head and reverse engineer requirements from system behavior.  At the conclusion of this effort, requirements can be theorized – “Foo must authenticate its server Bar before initiating a bank transfer.” 

Risk analysis can be performed once a plausible set of requirements have been identified.  Threat modeling is a more structured means of performing such an analysis, with the eventual goal of identifying means by which requirements can be violated by an attacker. 

As with requirements analysis, original developers would be a valuable resource to consult.  With or without such help, the first step is to identify how the software works.  In many cases, help is not available and performing this task requires a great deal of effort.  For features of moderate size, this author has spent upwards of a month reading code, using process profiling tools, and walking through the software with a debugger to identify program flow and security-sensitive functionality.

Once completed, actual system behavior should be documented and compared against the requirements theorized.   It might be that the requirements should be re-evaluated (New requirement:  Do not assume that Foo requires server authentication) or the system may need to be changed (New bug:   Foo does not verify the CN for Bar).  At the end, this information should be sufficient to support a comprehensive threat modeling exercise where security requirements, risks, and their mitigations can be documented.

Next Steps

Bringing a legacy feature up to par with its newer kin requires a relatively small number of items:  improved code quality, clear security requirements, and a thorough threat model.  As we have seen, performing even these tasks is quite the effort!  I am sure that it is little comfort to be reminded that accomplishing these tasks has simply laid the foundation, and that the true benefit is that the newly-reviewed legacy feature is able to participate fully in the security processes that remain: reviewing cross-component security requirements and assumptions, comprehensive testing, and incident planning, to name a few.

Unfortunately, there is no silver bullet in security assurance.  The soundness of the design and implementation of legacy software is just as important as in newer software, which is why any complete secure software development process will look backwards as well as forwards.  Feature by feature, from higher priority to lower, the overall security of the software improves as legacy code receives the full security treatment it deserves.

Imagine you're in charge of infiltrating sleeper agents into the United States. The year is 1983, and the proliferation of identity databases is making it increasingly difficult to create fake credentials. Ten years ago, someone could have just shown up in the country and gotten a driver's license, Social Security card and bank account -- possibly using the identity of someone roughly the same age who died as a young child -- but it's getting harder. And you know that trend will only continue. So you decide to grow your own identities.

Call it "identity farming." You invent a handful of infants. You apply for Social Security numbers for them. Eventually, you open bank accounts for them, file tax returns for them, register them to vote, and apply for credit cards in their name. And now, 25 years later, you have a handful of identities ready and waiting for some real people to step into them.

There are some complications, of course. Maybe you need people to sign their name as parents -- or, at least, mothers. Maybe you need to doctors to fill out birth certificates. Maybe you need to fill out paperwork certifying that you're home-schooling these children. You'll certainly want to exercise their financial identity: depositing money into their bank accounts and withdrawing it from ATMs, using their credit cards and paying the bills, and so on. And you'll need to establish some sort of addresses for them, even if it is just a mail drop.

You won't be able to get driver's licenses or photo IDs on their name. That isn't critical, though; in the U.S., more than 20 million adult citizens don't have photo IDs. But other than that, I can't think of any reason why identity farming wouldn't work.

Here's the real question: Do you actually have to show up for any part of your life?

Again, I made this all up. I have no evidence that anyone is actually doing this. It's not something a criminal organization is likely to do; twenty-five years is too distant a payoff horizon. The same logic holds true for terrorist organizations; it's not worth it. It might have been worth it to the KGB -- although perhaps harder to justify after the Soviet Union broke up in 1991 -- and might be an attractive option to existing intelligence adversaries like China.

Immortals could also use this trick to self-perpetuate themselves, inventing their own children and gradually assuming their identity, then killing their parents off. They could even show up for their own driver's license photos, wearing a beard as the father and blue spiked hair as the son. I’m told this is a common idea in Highlander fan fiction.

The point isn't to create another movie plot threat, but to point out the central role that data has taken on in our lives. Previously, I've said that we all have a data shadow that follows us around, and that more and more institutions interact with our data shadows instead of with us. We only intersect with our data shadows once in a while -- when we apply for a driver's license or passport, for example -- and those interactions are authenticated by older, less-secure interactions. The rest of the world assumes that our photo IDs glue us to our data shadows, ignoring the rather flimsy connection between us and our plastic cards. (And, no, REAL-ID won't help.)

It seems to me that our data shadows are becoming increasingly distinct from us, almost with a life of their own. What's important now is our shadows; we're secondary. And as our society relies more and more on these shadows, we might even become unnecessary.

Our data shadows can live a perfectly normal life without us.

This essay previously appeared on Wired.com.

EDITED TO ADD (9/9): Interesting commentary.

Apple added access for iPhone and iPod touch users to a subset of its iTunes Store over Wi-Fi--the awkwardly named iTunes Wi-Fi Music Store--more than a year ago, along with the ability to access that store at no cost from handhelds and laptops via Starbucks outlets in New York, Seattle, and throughout the San Francisco Bay Area. (Chicago and Los Angeles have been "coming soon" for a year, but the new AT&T/Starbucks deal may have delayed opening up those markets.)

Terrestrial AM/FM radio stations would like to figure out how to remain meaningful in a world of streaming Internet radio. Their latest strategy is to embed information that allows a listener to mark a song they want, potentially getting a piece of music sold in this fashion. With FM tagging, Zune players tap into an existing very low-data-rate encoding protocols that allow stations to push out their call letters and current song information. By adding a very short code, broadcasters can allow Zunes to look up the appropriate song.

At launch, 450 stations from major networks, including Clear Channel, Entercom, and others, will broadcast tagging details. Note that Microsoft includes KEXP, a Seattle independent and alternative radio station, in its sample image, for the new models. KEXP, given a boost a few years ago through significant short-term funding by Paul Allen--funding that involved changing its call letters to his Experience Music Project museum initials--has an enormous listenership over the Internet ironically enough. KEXP will be a programming partner creating channels of music for the subscription-based Zune Pass service. (Zune Pass is $15 per month, all you can eat.)

This option could allow Microsoft to ink partnerships with hotspot networks to brand them with Zune compatibility, lets radio stations promote something other than iPods that they would have a direct relationship with (and, potentially, some kind of revenue stream from?), and may be part of breaking Apple's digital music hegemony. May be. Nobody's gotten rich betting against Apple for the last several years. (Details of revenue sharing with radio stations hasn't been discussed.)

Apple opted for a partnership with HD Radio broadcasters and equipment makers that has a relatively elaborate process of tagging songs. HD Radio is digital AM/FM, a patented and licensed method that has provoked a lot of controversy, and has lagged enormously in the marketplace, despite well over 1,000 stations (including many public radio stations) broadcasting in this digital format, some for over three years.

HD Radio tagging requires an HD radio receiver with a Tag button; pressing that button stores the song's tag information. The radio must also have an iPod dock. Docking an iPod syncs the tag information, and the next time the iPod is sync with iTunes, you can see which songs were tagged. Kind of tedious compared to "press a button while listening to an FM station and buy the song over Wi-Fi." (I've been writing about HD Radio for years, and even launched a blog that's gone moribund; the technology is interesting, but Internet radio on mobile devices coupled with on-demand music purchasing over cell and Wi-Fi may simply make HD Radio unnecessary for listeners.)

Microsoft has a more compelling "marketing story" for this feature than Apple, that's for sure. On the other hand, do you really need to tag songs from stations that play only the most popular music in a given format?

Imagine you're in charge of infiltrating sleeper agents into the United States. The year is 1983, and the proliferation of identity databases is making it increasingly difficult to create fake credentials. Ten years ago, someone could have just shown up in the country and gotten a driver's license, Social Security card and bank account -- possibly using the identity of someone roughly the same age who died as a young child -- but it's getting harder. And you know that trend will only continue. So you decide to grow your own identities.

Call it "identity farming." You invent a handful of infants. You apply for Social Security numbers for them. Eventually, you open bank accounts for them, file tax returns for them, register them to vote, and apply for credit cards in their name. And now, 25 years later, you have a handful of identities ready and waiting for some real people to step into them.

There are some complications, of course. Maybe you need people to sign their name as parents -- or, at least, mothers. Maybe you need to doctors to fill out birth certificates. Maybe you need to fill out paperwork certifying that you're home-schooling these children. You'll certainly want to exercise their financial identity: depositing money into their bank accounts and withdrawing it from ATMs, using their credit cards and paying the bills, and so on. And you'll need to establish some sort of addresses for them, even if it is just a mail drop.

You won't be able to get driver's licenses or photo IDs on their name. That isn't critical, though; in the U.S., more than 20 million adult citizens don't have photo IDs. But other than that, I can't think of any reason why identity farming wouldn't work.

Here's the real question: Do you actually have to show up for any part of your life?

Again, I made this all up. I have no evidence that anyone is actually doing this. It's not something a criminal organization is likely to do; twenty-five years is too distant a payoff horizon. The same logic holds true for terrorist organizations; it's not worth it. It might have been worth it to the KGB -- although perhaps harder to justify after the Soviet Union broke up in 1991 -- and might be an attractive option to existing intelligence adversaries like China.

Immortals could also use this trick to self-perpetuate themselves, inventing their own children and gradually assuming their identity, then killing their parents off. They could even show up for their own driver's license photos, wearing a beard as the father and blue spiked hair as the son. I’m told this is a common idea in Highlander fan fiction.

The point isn't to create another movie plot threat, but to point out the central role that data has taken on in our lives. Previously, I've said that we all have a data shadow that follows us around, and that more and more institutions interact with our data shadows instead of with us. We only intersect with our data shadows once in a while -- when we apply for a driver's license or passport, for example -- and those interactions are authenticated by older, less-secure interactions. The rest of the world assumes that our photo IDs glue us to our data shadows, ignoring the rather flimsy connection between us and our plastic cards. (And, no, REAL-ID won't help.)

It seems to me that our data shadows are becoming increasingly distinct from us, almost with a life of their own. What's important now is our shadows; we're secondary. And as our society relies more and more on these shadows, we might even become unnecessary.

Our data shadows can live a perfectly normal life without us.

---

Bruce Schneier is Chief Security Technology Officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Your first real lesson about locking down a host was how to reduce its attack surface. You learned how to disable services using /etc/inetd.conf. Then you learned about rc.d and how to prevent unnecessary services from being launched at startup. Next, maybe you configured the Xserver to disallow remote connections or moved on to removing setuid permissions from files. As you worked, you’d periodically re-scan the box to gauge progress, asking yourself “have I removed everything I don’t need?” The underlying motivation, of course, is that an attacker can’t hack something that isn’t there.

You learned how to extend those concepts to the network — configuring firewall rules, router ACLs, VLANs, etc. Segmenting the network. Creating a DMZ. No need to dwell on this, you get the idea.

Eventually, people realized that applications had an attack surface too. Web servers and application servers got a lot of attention, followed closely by custom web applications. “What do you mean you can execute SQL queries against my database? That’s impossible, I have a firewall!”

Some companies, the ones who could afford it anyway, started to build security into their development cycle. Doing threat modeling during the design phase made sense, because hey, it’s much cheaper to fix security holes in a whiteboard drawing than it is to rewrite your authorization module from scratch after it’s in production.

Let’s talk strictly about custom web applications now. What I’ve observed is that most development groups, even the ones who actively engage in threat modeling, do not understand their web application’s attack surface. The lead architect can whiteboard a high-level diagram of all the major components and how they interact. Individual developers can go a bit deeper, telling you which files they touch, what database permissions they need, or how various pieces of data are encrypted in storage. At the end of this exercise you have a complete picture of the processes, data flows, protocols, privilege boundaries, external entities, and so on, and you’re well on your way to understanding all of the potential attack vectors.

Or are you?

What often gets overlooked or glossed over is the impact of external libraries or packages. Nobody writes everything from scratch. A typical list of third-party libraries for a Java-based Web 2.0 application might include DWR, GWT, Axis, and Dojo, plus about 30 other libraries to do everything from logging to parsing to image manipulation. Nine out of ten times, the libraries will be installed in full, using the default configuration from page one of the README file.

Why is this relevant? Because just as those old Unix boxes exposed unnecessary services, libraries expose unnecessary code. Let’s say you installed Dojo to simplify the process of creating an HTML table with rows and columns that can be sorted on demand. Did you remember to remove all the .js files you didn’t need? Or maybe you installed Axis or DWR or anything else that has its own Servlet(s) for processing requests. Have you compared what that Servlet can do against what you need it to do?

A fictitious example may help illustrate further. Imagine you just downloaded a new library called WhizBang. You follow the installation instructions to define and map two servlets in your web.xml file, WhizServlet and BangServlet, and you configure it to integrate with your web app. After a bit of trial and error, it’s functional. Yay! This is where most developers stop.

Nobody asks, “how much of this do I actually need?” Case in point, what if your application only uses WhizServlet? BangServlet is still exposed, and you don’t even use it! Similarly, what if WhizServlet takes an “action” parameter which can be either “view”, “edit”, or “delete”, and your application only uses “view”? You’re still exposing the other actions to anybody who knows the URL syntax (pretty trivial if it’s open source). You wouldn’t expose large chunks of your own code that you weren’t using, so why should it be any different with libraries?

This post is getting kind of long so I’m going to split it up. In the next post, I’ll continue the discussion of attack surface minimization, as well as some of the tradeoffs that go along with this approach.

CISCO WEBINAR UPDATE
First, Jack’s Webinar with Cisco is Thursday.  If you were lucky enough to get a slot, be sure to catch it.  If you didn’t get a slot but would like to still go, let me know (info –at– riskmanagementinsight–dot–com - subject Webinar).

RISK MANAGEMENT STANDARDS AND FAIR

Second, The Open Group has a Press Release out this morning:

“The Open Group Security Forum Initiates Development of Risk Management and Analysis Taxonomy”

You might know The Open Group from their efforts with UNIX or SOA or helping the Jericho Forum.  You’ll recall that a while back I had mentioned that RMI was working withThe Open Group, and today’s announcement is a culmination of about a year and a half worth of effort there.   Today The Open Group formally announces our (we’re members) intent to put a stake in the ground concerning risk and risk management.

Our goal is common language and common models to create meaning.  This has the capacity to change everything - the way we audit, the way we talk to other lines of business, the way we gather metrics… a Herculean effort, to be sure, but I think that The Open Group is one organization that can effect change because it is:

• Open & Participatory - Unlike many organizations developing security standards, anyone can join and anyone can contribute.  Because there are real people (doing real risk work) as members of the forum, you won’t sit back at the end of some work day working on risk and think, “Who are these people, and why are they making my life so miserable with all these unnecessary hoops to jump through?”

• Authoritative and Structured - That is, change is welcome but carefully instituted.

These are important qualities to me.  When you look around at some of the risk management efforts out there, too often you’ll find that the people instituting models and standards are removed from the actual practitioner, and/or the institution creating these standards are autocratic.  The change our profession needs cannot happen from one vendor or from one  bureaucracy that takes little account for the wishes and opinions of it’s constituency.

YET ANOTHER RISK MANAGEMENT EFFORT?

Some folks may be thinking “do we really need another risk management effort?” And really, I sympathize with the thought.  There’s ISO risk management stuff, there’s OCTAVE and NIST 800-30 and AS/NZ 340 and CRAM and FRAP and others…

And this is where I think FAIR and The Open Group have a good fit.  FAIR as a model for analysis, does not compete but rather compliments OCTAVE and NIST 800-30 and ISO 2700x (That reminds me, Rybolov, I’ve got to respond to your 800-30 article). In fact, one of the goals for the work with The Open Group is supporting documentation (call them white papers or guidance letters or whatever) that talks about how to use FAIR and the work of The Open Group Forum with ISO 27001 or as probability determination within OCTAVE, or in context with COSO efforts, etc…

SO WHAT DOES THIS MEAN TO YOU?

Well, it means a couple of things.  First, you have somewhere to go where people are vetting the models.  There is a forum of users and people with the same risk management issues and challenges as you have, but that are committed to working together to make things better.  A forum in which you can contribute and work to vet models against experience.  A forum that is a “vendor- and technology-neutral consortium” with experience building standards that work to interoperate across organizational and industrial boundaries.

Second, it means that you have a nice reference point for people who want it.  Defending the use of FAIR over some other analysis method got a little easier thanks to the increased credibility of The Open Group.

Third, new and exciting things are already happening at The Open Group in the Security Forum surrounding new standards and new ways of doing business.  Even if Risk Analysis isn’t your primary passion, let me encourage you to get involved with The Open Group’s Security Forum. Mike Jerbic and Ian Dobson there both have a passion to help codify what works and what helps security and risk management departments, regardless of “silo” or discipline.

WHAT DOES THIS MEAN TO RMI?
If you’re an employee, or client, or just a well-wisher, today’s announcement is just one culminating factor of the past year of changes RMI has undergone.  The announcement means that we’re now no longer the sole custodians of FAIR, but simply part of a larger effort to drive a better understanding of risk in our industry.  We (RMI) have a responsibility support and contribute to the effort, but the journey is no longer ours alone.  We’ve got friends.

New Website

I think our new website reflects who we are and what we do better now.  It takes into account not just what we can do because of FAIR, but also what we’ve been able to synthesize because of it (and the use of our other models and frameworks to create a whole picture of what is Risk Management).  The primary focus of our message no longer needs be that we’ve got something new and cool that makes you better - we’re freer to talk about our experience and abilities - very much reflecting the maturity we’re experiencing as a company.