noFUD - No Fear Uncertainty or Doubt

Several enterprises are increasingly investing time and money in building application security tasks into their existing SDLCs. Some of them have also reached the conclusion that proactive approaches , like threat modeling, have more ROI than reactive approaches. As a result, some enterprises with nascent appsec programs have turned to threat modeling as a panacea for their security problems. However, threat modeling may not be the solution to their immediate problems. Now I recognize that this may be a controversial statement.

Recently, I have been involved in several situations where organizations with their heart in the right place have made threat modeling mandatory as part of the development process, with limited success. My point is that threat modeling as part of a mature SDLC is a desired end state though not necessarily the initial step. Let’s examine this argument.

Firstly, threat modeling depends on several elements of a SDLC to be fairly mature. Most importantly it depends on requirement and specification gathering process to be rigorous. Also, an enterprise must have well defined standards and policies in place to act as input into the threat modeling process. Without these elements of the SDLC in place, the threat modeling process will be isolated and have a reduced impact.

Secondly, a threat model is a security plan only and is useless without any committed follow-up action as part of development and testing. Most enterprises do not allocate sufficient time and resources to implement the findings of the threat model. A large portion of organizations don’t even have a security assessment team in place. These teams are consumers of the threat modeling process that actual carry out the most crucial task of reducing risk by implementing countermeasures.

Thirdly, it is practically feasible to create threat models only for new projects or those undergoing incremental changes. As a result, legacy applications do not benefit from threat modeling. This leaves a huge gap in the enterprises’ risk profile.

Finally, most nascent application security programs need quick and demonstrable ROI. The threat modeling process ROI can take several months or even years to be quantifiable because it is an incremental process that is dependant on several other SDLC processes to be effective. There are other areas where investment can bring in more immediate ROI. These areas include security assessment team, security training for developers and definition of countermeasures for  common vulnerabilities.

For organizations with nascent application security processes, I recommend that they us the following framework to evaluate if they are ready to adopt threat modeling:

• Does a security baseline exist?
• Is the SDLC process fairly well defined and followed during development?
• Has the organization agreed upon countermeasures for common vulnerabilities?
• Are developers trained to avoid common vulnerabilities?
• Do developers do a self review of code for security vulnerabilities?
• Does a security assessment team exist?

If the answer to more than two of the questions above is no then the organization is probably not ready for adopting threat modeling.

For long, getting access to a common view of all of a patient’s medical records has been a shortcoming of the healthcare system. This is a curious situation since, patient records have been digitized  in several leading hospitals like the Mayo Clinic and the Cleveland Clinic for some years now. The technical mechanisms for transferring this data from one care provider to the next are also readily available. What is promoting (some say preventing) the exchange of medical information from happening is a law known as  Health Insurance Portability and Accountability Act (HIPAA).

HIPAA standards are meant to improve the efficiency and effectiveness of the health care system by encouraging the widespread use of electronic data interchange in the US health care system. The law defines the security and privacy standards for Protected Health Information(PHI). PHI is basically any information about health status, provision of health care, or payment for health care that can be linked to an individual and as is generally interpreted as pretty much anything medical related including name, medical record numbers, biometric data, payment information. Now all of this is great, but what really happens is that the entity holding your medical information will not share it with other entities unless it absolutely has to. This is because the liability to the originating entity from misuse of this data  is high.

Now that we have the background established, let’s get to the point. Recently Microsoft’s  HealthVault  and Google Health offerings have been released with a promise of making this data exchange easier and allowing the individual all the benefits derived from a complete view of their medical histories. Such services are generally known as health record aggregators.

Both market forces and the need for electronic data interchange for health records drive companies like Microsoft and Google to create these services. Users will be able to create health profiles, track prescriptions, track expenses and allow healthcare providers access to their records.  It is my opinion that this innovation is a necessary step in healthcare reform.

However, one very significant downside exists. The information uploaded to these health record aggregators is not currently covered under HIPAA. What this means is that any attack, breach of confidentiality or even potential harm from wrong data is not covered by the law. You are left to the best effort of the service provider. This increases the risk of disclosure of your private medical information. The law , today, is out of step with what technology can provide.

Some practical considerations also heighten this situation. Here are some guidelines that you may want to follow:

• Create a new Microsoft Live ID or Google account for your health information
• Do not use your “normal password” for this account. It needs more security
• Check with your medical service provider as to what information will be available to an aggregator
• Steer clear of any provider that shows you targeted ads based upon your medical information
• Opt out of sharing information with any partner sites
• Do not sign up for newsletters pertaining to your health info if you wish to keep it a secret
• Ensure that the providers policy states that they delete all your data if you wish to drop out of the service
• Question whether the healthcare data be sent to any offshore location (read more about this here)
• Ensure that the privacy statement states that the medical data will never be aggregated with other databases

So in conclusion, it is clear that there are significant benefits to having your medical data aggregated and available to you. Clearly the technology to do so exists. The laws have not kept up with this change in technology, leaving you with one choice to make… Are you comfortable having your medical records stored with minimal legal protection?

After about an hour of nodding his head vigorously in agreement with some of our lessons learnt, my customer jumped up and exclaimed, ” Great!! Now where do I find another 20 people like these?” (pointing to my team)…

I thought about it a while and so Mr. B here is your answer: Information security education has been pursued by several tertiary education (i.e. universities) for several decades now. In 1999, the NSA got into the act and issued a list of  National Centers of Academic Excellence in Information Assurance Education (CAEIAE) to 7 universities:

James Madison University
George Mason University
Idaho State University
Iowa State University
Purdue University (No longer a CAE)
University of California at Davis ( I went to grad school here)
University of Idaho

These CAEs are accredited for 5 years and have to reapply  for designation after that period. The CAEs were set up in an effort to promote higher education in information assurance, and in turn, increase the number of professionals with this critical expertise. NSA’s establishment of this program was based on the growing demand for professionals with information assurance expertise in various disciplines.

The current list of universities in this list include the original universities (except Purdue) and the following:

California State University, San Bernardino
Georgetown University
Southern Polytechnic State University
The University of Tennessee at Chattanooga
University of Arkansas at Little Rock
University of Denver
University of Missouri – Columbia
University of Nevada, Las Vegas
West Chester University of Pennsylvania
West Virginia University
Air Force Institute of Technology
California State Polytechnic University, Pomona
DePaul University
East Carolina University
New Mexico Tech
Northeastern University
Nova Southeastern University
Oklahoma State University
Polytechnic University
The University of Texas at San Antonio
Towson University
United States Air Force Academy
University at Buffalo, the State University of New York
University of Maryland University College
University of Nebraska at Omaha

Watch this space for more on information security education and where to find the right people.

Previous Post

I will be discussing Microsoft IT’s approach to secure application development, with a special focus on how we integrate security into the IT line-of-business SDLC, in a webcast this Thursday May 29th. This webcast will be part of the Microsoft’s IT Manager Webcast series. This series aims to share deep knowledge focused on Enterprise IT orgs and ISVs.

Title: IT Manager Webcast: How Microsoft IT does Secure Application Development (Level 200)

Register Online 

Audience: Technology Decision Maker.
Duration:60 Minutes
Start Date: Thursday, May 29, 2008 11:00 AM Pacific Time (US & Canada)

Event Overview

Join this webcast to learn how Microsoft IT’s Application Consulting and Engineering (ACE) team secures Microsoft’s internal business applications.  The ACE team will share state of the industry, application security challenges, and how application security fits into the development lifecycle for IT.  Learn about the ACE team’s methodology and processes developed in the areas of application security and performance optimization.

You can find more details here.

The other day I was subject to the assertion that the only asset an IT security organizations should care about is data. Now being in the application security business, I should have been jumping at this validation but couldn’t.

The IT security org needs to understand what threats the business faces from its technology systems. In many cases this is not a direct threat to the confidentiality or availability of data. Some attacks may be focused on other aspects of the systems like integrity or even cost.

Let me give an example. Some systems such as the adhoc sensor networks are deployed as an alternate to existing monitoring systems for the flexibility and cost reduction they offer. I wrote  a research paper with my friend Guillermo Marro detailing attacks on sensor networks.  These attacks focus on the power available to each sensor in the network. By manipulating the protocols, we were able to model attacks that would cause these networks to degrade rapidly. This would mean that the sensors would have to be replaced much before their time resulting in a dramatic increase in the total cost of operating these networks. This attack is not focused on the confidentiality of data but does may make the network too expensive to run.

Now that you’ve decided (or battled) to set up an application security program you realize that it actually needs to get funded.  You must master the art of delicately drinking from the fire hydrant of line of business applications.

In my experience helping organizations set up their application security programs funding was perhaps the most critical factor determining the level of impact that the appsec program would have. Lets go through the various permutations and combinations of these models and what they buy you:

1. Centrally funded cost center: This is the model most organizations follow where a bunch of centralized funds are used to hire some employees/vendors to come in and churn through the applications. This model does allow the organization to decide its overall spend on application security and set up dedicated resources for assessments. In some organizations this model has been successfully used to develop a centralized risk management system which can then be used to go after the most risky applications. In my experience the hidden problems in this model surface when an organization tends to use an immature risk assessment framework. Also, this model suffers when organizations do not take due care towards capacity planning and give way too many applications to a single analyst. This fractures their time and eventually nothing gets done
   So remember, use this model to manage your application security spending and use a common risk management framework. Beware of using a risk framework that does not correctly represent your organization risk profile or overwhelming your analysts.
2. Decentralized project based model:This model is useful for organizations which have large decentralized business units where it is very difficult to get the different BUs agree to a contribute funding to centralized resources. In this model the application security team is reduced to a recommendation body only and dilutes its enforcement capabilities. In my experience, this program has been successful in two scenarios - both of them at completely different ends of the spectrum. The first, where political issues between different organizations are difficult to bridge and funding from commitments from these organizations are next to impossible. The second is organizations where their is a high level of consensus in spend and standard of security to be maintained. Needless to say the first type of organization is all too common and the second type is all too rare.
3. Internal cross-charge consulting: This is an interesting model where the business units decide to uphold a common security standards and there is a general awareness of the need for application security. The application security program is set up as an internal consulting organization. This model is successful for large enterprise organizations that have several LOB applications in their portfolio and are fairly mature in their security processes. One of the biggest advantages of this model is that it can be scaled up and scaled down as needed. The organization does need to be vigilant and set up policies that will ensure that all projects budget for the security work.

There are several other hybrid models that organizations have explored including a combines network-application security team where people are cross trained in both discipline. You need to focus on the model that is best for your organization. The criteria to decide which model to chose should include:

• Risk-management framework maturity
• Investment that org in application security
• Is application security centralized or decentralized?
• What is the amount of enforcement capabilities the appsec org will have?
• Do you build in-house or outsource?

A host of other issues including availability of employees with the right skills, vendors, off-shoring, size of application portfolio, regulatory needs etc. will influence the funding model as well. One thing is for sure, without adequate funding for governance and operations, the appsec program will not be successful. Hope this helped!!

I will be speaking at the Front Range OWASP Conference ( FROCo08 ) in Denver on June 10th. The focus of the conference to share the experiences that the speakers had around solving technical and management issues surrounding application security. I’ll be sharing the podium with luminaries like Ed Bellis, Jeremiah Grossman, Melissa Tondi, Laz, Mike Walter & Robert Hansen.

My talk, Application Security Kung Fu: Threat Modeling your way to competitive advantage, will focus on how threat models can lead to better software translated to a competitive advantage. That will be followed by a security discussion  on integrating security into the SDLC. Looking forward to this discussion on the topic I have been passionately blogging about.

Large enterprises tend to have a number of line of business (LOB) applications supporting business operations. It becomes key for an application security program to help the organization manage the risk posed by each of these applications. Applications tend to be comprised of legacy applications, applications under development and application under planning. 

To start an application security program, the org must set up a secure data center/environment to host secure applications. Applications must be on-boarded into this environment after a security review (about which I will talk about in a future post).

In order for the application security program to be successful, the following must happen:

• All LOB applications hosted in this environment should have a security review. This security review is mandatory and may require policy changes and governance.
• Applications failing a review with critical issues should not be hosted.
• Assessment organization should be given enforcement capabilities. Without enforcement the program will be unsuccessful.

This typically can start with high risk applications and maintained by assessing all newly developed applications or releases and a prioritized list of legacy applications.

One of the challenges I constantly grapple with is leading a large yet mostly remote team. Managing across 5 time zones posting I wrote about it earlier generated a lot of discussion and loads of ideas.

Recently we revisited this in the context of bringing together a 200-odd people org spread across more than a dozen time-zones. An idea suggested and brilliantly executed was to have each remote employee submit a 20-30 second video on themselves and compile it into a collage. The quirky compilation gave the team more of an insight into the lives of our remote team than large once a year meetings ever could.

We followed the 4 am commutes, the funny animations, scientific experiments and the upside down world of our people down under. I appreciate that it brought people’s personalities to the forefront… if only for 30 seconds.

“How many applications do you have and what do they do?” It seems simple enough yet this questions seems to perplex many a smart mind. Having posed it to over a hundred and fifty CSO/CIOs over the last year, I have rarely received a clear answer that wasn’t based solely on gut-feel. The information security leader for a large retailer summed up the sentiment in one insightful sentence “We are so project focused that we don’t even know the shape of the larger beast.”

As Microsoft started grappling with the application security problem around 6 years ago, we found that our understanding of our application risk profile was incomplete as we did not know what data was being exposed and through which applications.

When most organizations start the application security program, they have these 4 categories of applications:

1. In-production applications
   1. Soon to be retired/replaced - At this point, evaluate the risk profile of the application and if it is high retire or replace it before schedule. In most cases it is not worth conducting a security assessment on these applications.
   2. Not slated for retirement/replaced - Conduct a reactive security assessment based upon risk profile. Medium risk applications should get a pen test and high risk applications should code reviews. If newer versions of the applications are to be built then a threat model should be created.

    

   - these form the large class of legacy applications that were produced before your developers had ever heard of Cross Site Scripting and SQL Injection [insert attack name of your choice here], when buffer overflows were just another way of writing self-modifying code. These in-production applications are housed in a known corporate data centers. The risk they represent can be managed based upon a further classification

2. “Shadow” applications - this is the set of applications that exist but no one knows about them and they are not in your data center. They can be applications like the one running in the legal department for the convenience of the 4 lawyers who are negotiating your next $6 billion acquisition or at your neighborhood retailer doing back-end data mining on credit-card transactions for some merchandising specialist. These applications are the most difficult to discover and pose some of the gravest risk to the enterprise. In my experience, up to 90% of applications at some customers are Shadow applications.
   At Microsoft IT, we started a multi-year program to identify and bring Shadow applications into our data-center after conducting security assessments on them. The main tool allowing us to do so was a application portfolio management tool that was developed in-house and called Microsoft Application Portfolio System (MSApps). This allowed MSIT to inventory the existing applications and ensure that no new applications were being built without being recorded by the system. This was enforced by coupling MSApps to some budgetary and resource allocations. For some of our corporate customers who wished to replicate a light-weight version of this functionality, we added it as the Application Portfolio Management (APM) to the Threat Analysis and Modeling Enterprise tool.
3. Under-production applications - These applications are currently being developed and have not been released to production. They may be in various stages of completeness and most organizations struggle with the level of security assessments that these projects should face. Our recommendation is to treat these engagements the same as “Planned applications” and produce threat models and conduct white-box code reviews for these applications based upon the risk profile. These do differ in one significant way from planned applications because most of the security tasks are conducted by the security team still in a fairly reactive mode.
4. Planned applications -  These applications have not been implemented yet and represent future Line of Business (LoB) application portfolio for your organization. This is where any proactive approach pays the highest dividend. The security architecture can be assessed at design time and the threat model can act as the guide for architects, developers and testers to ensure a secure application is built from ground up. A properly implemented application security program will allow the application team to feel empowered to conduct a majority of the security tasks while the security team provides guidance and verification. In future posts, I will be expanding in detail about the proactive approach.

From the situation above most organizations should aspire to move to a state where application security program caters to two risk programs 1. In-production applications or 2. Under-production/planned applications.

It took Microsoft IT a couple of years to identify and bring close to a 100% of its Shadow applications into data centers and complete its application inventory process. Application inventory is a critical first-step to a mature application security process and the time for you to do it is now.