Bind("AmountCharged", "{0:C}")

While this displays just as you'd expect (e.g., $200), it doesn't do so well when you submit an edit that includes the same value ($200):

Input string was not in a correct format.

I searched around and didn't find much in the way of a clean solution, but I did solve the problem with just a few lines of code. The trick is to handle the data-bound control's Updating event. Since I was working with a GridView, my solution looked a bit like this:

<asp:GridView DataSourceID='myDataSource'
              OnRowUpdating='FixFormatting'
              AutoGenerateColumns='false'
              CellPadding="3" ...>

Notice the OnRowUpdating handler that I've installed in my grid view. That code looks like this:

protected void FixFormatting(object sender, GridViewUpdateEventArgs args)
{
    decimal amountPaid = ParseDecimal((string)args.NewValues["AmountPaid"]);
    args.NewValues["AmountPaid"] = amountPaid;
}

When you handle this event, you're given a dictionary of old and new values, which appear to come directly from the controls (in my case, a TextBox was used to gather the updated data AmountPaid, so the type of object that I found in NewValues["AmountPaid"] was a string. I wrote a little helper method called ParseDecimal that parses a string into a decimal value, allowing currency characters, decimal points, and thousands separators. I also allowed a blank value to indicate zero:

public static decimal ParseDecimal(string value)
{
    if (string.IsNullOrEmpty(value))
        return 0;
    return Decimal.Parse(value,
        NumberStyles.AllowThousands |
        NumberStyles.AllowDecimalPoint |
        NumberStyles.AllowCurrencySymbol,
        CultureInfo.InstalledUICulture);
}

This solved the problem quite nicely. Now two-way binding works with formatted data.

In this series I am going to talk about “Walking” with the SDL. Walking is the point where your security development practices become a lifecycle – a repeatable, mostly reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll talk about walking – or adding the “L” in SDL.

I will be covering quite a bit on this topic, so I intend to split it up in to a multi-part series over a few days. I’ll condense it all into one big doc at the end. In Part One, I will review “crawling” and the foundation you need to have in place as well as discuss getting management approval. In Part Two we’ll cover the topic of expanding your security training. In the additional posts, we’ll discuss formalizing requirements, reusing threat modeling and attack surface review data, the importance of final security reviews, and managing post-release documentation. All of these are components to “walking” with the SDL.

Before I jump into detailing what you can do to “walk” with the SDL, let’s look back at a snapshot of what you should already have in place from learning to “crawl.” At a high level, crawling involved three components. Each of these components requires specific activities or tools that your team must implement to begin developing secure code:

1.       Detailed awareness of your architecture and its attack surface.

a.       Threat Modeling

2.       Tools that will perform security analysis on your application.

a.       Strengthen compiler defenses

b.      Use code analysis or static analysis tools such as PREfast, FxCop, AppVerif

c.       Build a strong fuzz testing capability

3.       Results that show how the analysis resulted in improved security

a.       Response planning and response process in place

b.      Use bugs to gather evidence and show that your work improved security

Think of these pieces as the “gross motor skills” you need to start walking. You should already be using these components and have reached a conscious decision to start building a lifecycle around your secure development practices. As you start figuring out how to “walk”, I want to point out that each of the concepts I discuss in this post is a critical component of the Microsoft Security Development Lifecycle. Adopting the SDL in your company involves a combination of integrating the existing SDL principles and the creating of unique requirements and components specific to your environment to build your own Security Development Lifecycle.

With that in place, let’s start talking about what it means to “Walk with SDL.”

Obtain Management Approval/Endorsement

Creating a Security Development Lifecycle will cost time and money. In addition, it will likely require some process changes. In most organizations, this change will not happen unless you obtain the management approval and endorsement necessary to compel the organization to act.

The key to successfully pitching SDL to your management can be found in the data you have been accumulating during the “crawl” phase. As you may recall from my crawling post, the simplest way to create evidence that clearly illustrates improved application security is to “mine” the data from your bug database. Connecting those bugs to known security vulnerabilities or to what would have been bad security issues that were avoided by fixing them in development is a powerful story. Of course your pitch should include other necessary components like anticipated costs, new software acquisition, possible vendor and consulting contracts and anticipated return on investment.

However, the heart of your argument will be the story you tell. The story is quite simply “If we hadn’t done this basic work in security, here is what we would have missed and how much it would have hurt…” followed by “if we continue to expand our security practices and make them a part of our process, we can better predict measurable security improvements that reduce the likelihood of future risks.”

The new SDL website [http://www.microsoft.com/sdl] provides some valuable reference material on the Business Case for SDL. I would recommend that looking through that information for some good supporting material. In Part Two, I will discuss expanding your security training as another component of “walking” with SDL.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        What unique challenges are you facing as you try to push for SDL adoption?

?        What have you used to successfully communicate the importance of security to your management?

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.

However, there are rare situations where you can choose device-specific log management approach (and still not look like a money- and time-wasting and idiot :-)). For example, you might be motivated by the fact that tools that can handle one specific type of log data (e.g. Windows-only, web server-only or Cisco PIX-only) are usually many times less expensive than cross-device log management tools. The table below clarifies it:

Also, while looking at logging tools, one needs to make a distinction between tools that can collect all sorts of logs but only allow you to analyze one log type at a time (e.g. sawmill) vs tools that can collect all sorts of logs AND allow you to analyze all of them together (e.g. LogLogic). The former tools still fall under "device-specific log management" despite their ability to gather hundreds of different log types.

The bottom line: in most cases, cross-device, uniform log management provides huge value, especially if your motivation for log management is compliance or incident response.