Akshay on the business of security

Last week while feeding my caffeine addiction I came across an article in the New York Times titled Can’t Find a Parking Spot? Check Smartphone. In order to reduce traffic congestion and fuel consumption, the city of San Francisco is implementing a new system that will help detect empty parking spots in downtown. Now clearly this is a step in the right direction, both from an environmental and convenience perspective. I have spent a huge amount of time driving around SFO looking for a parking space, an experience that many of you may have shared. The city is investing $95.5 million on improving traffic condition though I'm not sure how much this pilot will cost.

"This fall, San Francisco will test 6,000 of its 24,000 metered parking spaces in the nation's most ambitious trial of a wireless sensor network that will announce which of the spaces are free at any moment.

Drivers will be alerted to empty parking places either by displays on street signs, or by looking at maps on screens of their smartphones. They may even be able to pay for parking by cell phone, and add to the parking meter from their phones without returning to the car."

This system will work involve an initial pilot of 6000 parking spots. Each spot will have sensors that will monitor whether it is free or not. These sensors will then form a network to communicate with each other. Drivers can access data on available spots through their smart phones. The city estimates that these sensor networks will last for around 10 years.

"To install the market-priced parking system, San Francisco has used a system devised by Streetline, a small technology company that has adapted a wireless sensor technology known as "smart dust" that was pioneered by researchers at the University of California at Berkeley.

It gives city parking officials up-to-date information on whether parking spots are occupied or vacant. The embedded sensors will also be used to relay congestion information to city planners by monitoring the speed of traffic flowing on city streets. The heart of the system is a wirelessly connected sensor embedded in a 4x4-inch piece of plastic glued to the pavement adjacent to each parking space.

The device, called a "bump," is battery operated and intended to last for up to 10 years without service. From the street, the bumps form a mesh of wireless Internet signals that funnel data to parking meters on to a central management office near the San Francisco city hall. "

A while ago, I had written about (Increase the TCO, Kill the Project) attacking systems not to violate data integrity or confidentiality but to increase the total cost of ownership (TCO). It would be interesting to see if the sensor network deployed to monitor parking spots may be vulnerable to attacks that aim to drain their batteries and thereby reduce their life span and increase the TCO for the system. I have not tested this hypothesis, I'm hoping that others don't either. Let no one stand between you and your parking spot.

Just got word that my talk Suddenly Psychic: Knowing everything about everyone was accepted at Microsoft's BlueHat Security Conference on October 16-17th. Sometimes when you go blue... you really go blue.

Over the course of the next few months my buddy Nitesh Dhanjani  and I will be presenting our research on how the business, psychological and behavioral aspects of our virtual and real-world personas impact our security and privacy. In particular, I am excited about two aspects of this talk. The first is the opportunity to explore techniques that were previously available only to large corporations or TLAs (three letter organizations) to gain intelligence. The second is to analyze the impact of our findings on the financial value of social networks and propose advances to current business models.

TITLE: Suddenly Psychic: Knowing Everything About Everyone

ABSTRACT:
Imagine a world where you can remotely influence other people's behavior. This talk will expose how information about people in the physical world, coupled with voluntary information from new communication paradigms such as social networking applications, can enable you to remotely read people's minds to influence their behavior.

Topics of discussion will include:

• Techniques on how individuals may be remotely influenced by focused marketing and messaging tactics, and how criminal groups and governments may abuse this capability.

• Reconnaissance and pillage of confidential information, including intellectual properties owned by businesses.

• Falsified profiles used to construct undeserved reputation as well as the risk of reputation tarnish.

• Remote behavior analysis that can be used to construct personality profiles to predict current and future psychological states of targeted individuals, including discussions on how emotional and subconscious states can be discovered even before the target is consciously aware. This topic will be extended to demonstrate the possibility of criminal abuse and the enablement of economic drivers.

• Decreasing the value of social networks through data poisoning attacks.

The goal of this presentation is to raise consciousness on how the new paradigms of social communication bring with it real risks as well as marketing and economic advantages. Perspectives on negative and positive uses will be presented in addition to academic discussions and thoughts on how to enable the upcoming online social age.

Update: We will also be at Hack in the Box in Kuala Lumpur in October

Many enterprise customers are increasingly evaluating the benefits of infrastructure outsourcing (ITO) to their businesses. In the past year, several CIOs have expressed concerns around the impact to the security and privacy of digital assets resulting from infrastructure outsourcing. In this post I will discuss the business drivers and security concerns around ITO and propose safeguards that enterprises can consider.

The drivers for infrastructure outsourcing stem from the impact of global delivery and economies of scale driven by standardization.  Additional benefits can be had from consolidating and sharing power-hungry data centers located in regions better suited to service the data centers' unique power needs.

Non-technology companies have been early adopters of the ITO model so as to focus on core businesses rather than technology support. In particular, financial services and government organizations have experimented to various degrees with the ITO model.  I am also observing a trend for companies actively pursuing M&A activities increasingly turning to this model as well. Clearly ITO has multiple benefits to businesses and this market can be expected to see healthy growth in the next few years.

The ITO model does have some challenges when it comes to the risk an enterprise faces from letting a third party have access to its digital assets. The areas of concern include:

• Regulatory compliance
• Intrusion monitoring and prevention
• Incidence response
• Validation of hosted environment
• Adherence to corporate standards and policies
• Liability resulting from an attack

While each organization will need to do compare the benefits and risk of outsourcing, there are some safeguards  that can mitigate the risk. I recommend that organizations examine the following third-party services:

1. Technical Compliance Management (TCM): These solutions aim at defining from an audit perspective the IT controls that need to be maintained for an organization. They can then periodically collect evidence of compliance for each compliance condition. TCM solutions evaluate system states in order to measure the level of adherence to standards and policies .
2. Security Deployment Assessments: These security assessments focus on evaluating the security posture of the infrastructure before any major system goes live. These may include checks against baseline configurations provided by the product vendors (like Microsoft's MBSA)  and IT policies
3. Periodic Vulnerability Scans and Pen-tests: In order to verify that the current state of the system are relatively free of known issues, vulnerability scans and pen tests can be used. This is definitely a recommended step but does not supplant the need for securely designed architecture
4. Managed Security Services: Some organizations have used managed security service providers to provide an additional layer of security to their outsourced infrastructure. These providers offer services including intrusion prevention/detection (IPS/IDS), firewalls etc. This may be difficult to negotiate with your vendor as it makes them dependant on managed security service providers. The trend will be for ITO providers and Managed Security Service providers to form strategic partnerships and offer comprehensive solutions.
5. "In the cloud" services: These services encompass email spam filtering, anti-virus services for desktops. These can be used to bolster any existing ITO providers offerings. Look for partnerships in this space as well.
6. Performance Reviews and Availability Services: Availability is a cornerstone of trustworthy computing and cannot be overlooked in any risk based discussion. Uptime will be a key metric for measuring the quality of service provided. Security services like load balancing, stress testing and active performance monitoring will be crucial to the reliability of the service.
7. Forensic Analysis: In case anything should go wrong, enterprises should invest in forensic analysis services to get to the bottom of an incident. This may also be needed from a liability perspective. It is generally advisable to identify a forensic analyst firm before hand and brief them about operational aspects to minimize on lead time to bring them up to speed during an incident.

Thanks to Roger Grimes and Mark Curphey to help me create a more comprehensive list of solutions.

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.

I will be presenting at the OWASP conference in Denver, CO this Tuesday, June 10th. The presentation will focus on the value that organizations especially ISVs can derive from threat modeling of line of business applications. For some time now, I've been brainstorming with my team on the competitive value of proactive security approaches like threat modeling. This presentation will empower business decision makers to make an informed decision on whether threat modeling is right for their business.

See you there.

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 (FROCo8) 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.

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.

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.

"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 - 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

   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.
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.

After several requests from customers about information on how enterprise class application security programs are set up, I am writing a series of blogs about my experience helping some large enterprises set up application security teams similar to the ACE team at Microsoft. This series will share lessons learnt at Microsoft IT and other large enterprises.

Application Security Development Lifecycle 1: Understanding your portfolio

Application Security Development Lifecycle 2: Mandatory or not?

Application Security Development Lifecycle 3: Funding Models

A great analysis by the Yankee group on the security posture of products from security vendors. A very interesting read.

Two key factors contribute to the growth of the underground vulnerability economy: historical and chronic weaknesses in the monopoly desktop operating system, Microsoft Windows; and the adolescent enthusiasm of vulnerability researchers continually trying to one-up each other.
Three years into its largely customer-imposed security push, Microsoft flaws continue to flow—but at a significantly decreased rate. Yankee Group analysis of a well-known public vulnerability data source, ICAT, suggests that flaw finders have shifted their focus toward security products.
From 2004 to May 2005 in particular, 77 disclosed vulnerabilities affected a wide array of security products. The incidents increased far faster than the rate for Microsoft (see Exhibit 1). When considering the number of affected products rather than just the number of distinct vulnerabilities, the rate of increase was as fast as that of the industry as a whole. Yankee Group believes this is because of three factors:
· Diminishing returns in operating systems: Security researchers focusing on Windows may have largely depleted the supply of the most easily exploited Microsoft flaws, especially in the wake of the watershed release of Windows XP, Service Pack 2.
· Low-hanging fruit in security products: Nearly all enterprises have deployed certain classes of security products, notably antivirus and (to a lesser extent) host intrusion prevention. Third-party and press scrutiny has not yet forced security companies to acknowledge and fix potential problems with their code, as it has with operating system vendors. Therefore, flaws targeting security software stand a better chance of being successful.
· Economic self-interest of testing specialists: Although not illegal, some security assessment vendors (notably eEye) specialize in finding vulnerabilities in other vendors’ security products. These vendors then turn around and sell their own security analysis products, which conveniently include detection signatures for the other vendors’ vulnerabilities. As shown in Exhibit 2, these firms discovered one-quarter (20 of 77) of the security product vulnerabilities reported in 2004 and 2005, about the same number discovered by independent researchers. In contrast, fratricidal discoveries by competing security vendors accounted for a minority (5 of 77). One firm—ISS—accounted for four of these.

This entry is a repost of an excerpt by request from an analysis document. Since I have been asked to forward provide this multiple times it may be best to point people to the blog entry instead. Also, who can resist a Hunter Thompson reference?