I’d like to give everyone the benefit of the doubt here; perhaps Dell was using it in a much narrower sense. Perhaps the term has really only been used more commonly since the time Dell first applied for the trademark back in March 2007 and now. BUT…

- Dell’s definition is quite broad and certainly not Dell-specific. “The design of computer hardware for use in datacenters and mega-scale computing environments for others; customization of computer hardware for use in data centers and mega-scale computing environments for others; design and development of networks for use in data centers and mega-scale computing environments for others.” Strike One.

- And according to the Wall Street Journal’s research, “cloud computing” has been in regular use since 2001. Strike Two.

So now the “case” has been returned to examination and hopefully the PTO will follow up on everyone else’s research on this and decide that yes, cloud computing is one of those broad, ubiquitous terms that should NOT be trademarked by a single company.

Doesn’t this seem backwards to you? Shouldn’t the MBTA be suing the vendor who sold them the flawed system? Security problems go away by mandating independant security testing before a product is accepted, not by trying to get security researchers to be quiet. This is a good example of how the reactive approach doesn’t work. The flaws are still in the system and suing researchers has just shined a bright light on them.

Update 08/09/2008 6:00pm EST:

The EFF is appealing the injunction which is blocking the students from speaking about the results of their testing.

A telling quote from Kurt Opsahl, staff attorney at the EFF gets to the heart of the issue:

“Courts have found that the First Amendment covers these things. We believe that this is a protected speech activity. When you discuss security issues, if you are telling the truth, that is something that should be protected.”

Apparently the MBTA has known about this problem since at least March, 2008 when a graduate student from the University of Virginia announced he was able to break the encryption system.

The U of VA researcher gave an interview where he described why security by obscurity is not a valid security approach for a cryptosystem:

Q: What are your thoughts on security by obscurity? Is NXP using this method of protection?

A: Security-through-obscurity hardly ever works. The lack of proper peer-review often even hurts the security of the system. Our Mifare work discovered several vulnerabilities that could be fixed without increasing the cost of the cards. NXP did for a long time rely on obscurity for the security of some of their products, but now decided against this outdated design approach and instead bases the security of newer RFID cards on publicly scrutinized cryptography and independent evaluations.

Q: Can you explain “Kerckhoffs Principle” and why it applies to your work?

A: Kerchoff, who lived in the 19th century, observed that keeping anything secret is really hard. So instead of relying on the secrecy of your whole system, it would a lot easier to only rely on the secrecy of a small secret key. Security systems should hence be publicly known and analyzed, and only the key should be secret. When properly realised for RFID cards, Kerchoff’s principle means that by analyzing their own cards, thieves cannot compromise your cards. This is contrary to our Mifare work, where we only analyzed a few copies of the the secret algorithm that is found in all cards and were consequently able affect the security of all the other billion cards out there.

The MBTA not only accepted a security system which relied on security by obscurity but once accepting this flawed model must try to maintain this obscurity with the court system.

The documents detailing the presentation are here.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. As you can easily, easily guess, the  #1 spot this month is taken by my irreverent comments on a Terry Childs saga. Namely, "On Doomsaying (Terry Childs case)", "So ... Am I? Maybe I Am!" and "Admins , Good Guys or "I am NOT an Idiot!""
2. Obviously, my earlier post/rant called "You Are "A Security Idiot" If ..." takes the #2 spot. Yes, we all like to point out other people's problems, especially when they are epically huge :-)
3. Next up is my post "11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"". It is both humorous and sadly true (and backed up by other sources)
4. Also popular is my post "Log Management - Day 1," which talks about the very first thing you do when embarking on a journey to log management.
5. Finally, again this month, my logging polls took the #1 spot!  Poll #8 that covered context data for log analysis is analyzed here. Other popular polls include a controversial Windows Log Collection Poll (which is a poll #7)  and poll #6 about logs that people actually look and poll #5 about logging challenges.
6. Strangely, a lot of people wanted to "Which Blogs Do I Read?" - so my brief post on that made it to the top.

See you in August, unless you are all on vacations, that is :-)

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

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?

iPhone, iPod touch now Wi-Fi remote control (see screen capture at right): The iPhone 2.0 software was soft released today, with a download available from Apple that's not yet being pushed via iTunes software when users' systems check for updates. The free Remote software, downloadable from the new App Store on the iPhone or Applications area in the iTunes Store, controls copies of iTunes on the local network once you've used a simple pairing technique. The same is true for the Apple TV with a free 2.1 software update for the digital box that's available now. (Also, you can snap screen shots in iPhone 2.0: Hold down the Home button and then press the top button. The capture is stored in your photo roll.)

Japanese bullet train gets Wi-Fi by next March: This was first announced in 2006; it's still on track, pun intended. The line runs from Tokyo to Osaka.

Network 1 expands its service St. Louis area: The company will offer service in 8 additional cities for a total of 15 in the St. Louis, Mo., area. The network provider is building out a neighborhood at a time using ostensibly commodity equipment. They charge $20 to $50 per month for service, and are focused on residential, rather than outdoor cloud access.

The Sopranokovs 

The Russian mob comes to town with a new scam—medical identity theft. 

When FBI special agent Ted Price peered through the window of a dingy brick storefront on Southwest Morrison Street in March, it was what he didn’t see that caught his attention. 

The business, called UnimedCorner, claimed to provide ailing seniors with orthotics—braces and other devices to correct foot, joint and back problems. 

Price and other federal investigators were skeptical. 

On Unimed’s showroom floor, Price saw wheelchairs, motorized scooters, a variety of canes and, on the walls, a selection of amateurish paintings and framed photographs. There was no evidence, however, of the kinds of equipment for which Unimed had billed Medicare nearly $2 million in the previous couple of months. 

“I observed wheelchairs and canes through the window but did not see any orthotics in the store,” Price later wrote in a search-warrant affidavit. “It is a sign of fraud that the store is not stocking the items [for which] it is billing.” 

By the time Price arrived on the scene, the company’s owner, a shadowy Russian immigrant named Alexandr Shcherbakov, was long gone. 

Today, Shcherbakov’s store sits undisturbed. The message light on the phone blinks, dead potted plants droop and a stuffed toy monkey slumps in a glass display case. 

And behind the cash register hangs a framed poster of television’s best-known mobsters, the Sopranos. 

From interviews and information presented in federal affidavits, it is clear Shcherbakov moved to Oregon to commit a crime elegant and lucrative enough to make Tony Soprano envious: medical identity theft. 

... 

“Medical identity theft is the new frontier for organized crime,” says Alex Johnson, a former FBI agent who investigates fraud for Regence BlueShield. “Pretty much anybody can set up a mom-and-pop operation and start cranking out claims.” Someday, most Americans will need a cane, wheelchair, home hospital bed or another of the items healthcare professionals call “durable medical equipment,” or DME. 

For those over 64 and without private insurance, there’s a good chance federally funded Medicare will pick up the tab for that equipment. Last year, according to federal statistics, Medicare spent $8.6 billion on DME. 

Here’s the way the system is supposed to work: A doctor prescribes a device such as a wheelchair for a patient, who presents his prescription to a DME supplier. The supplier provides the equipment and bills Medicare, which typically pays 80 percent of the cost. Unlike pharmacists, who fill prescriptions under strict scrutiny of state and federal watchdogs, DME suppliers are lightly regulated. “DME is very vulnerable to fraud,” says Consuelo Woodhead, the chief healthcare fraud prosecutor for the U.S. Attorney’s Office in Los Angeles. “It doesn’t require any background in medicine, any kind of professional licensure or appreciable capital. 

There are barriers of entry in other medical fields, but not in DME.” To operate, DME suppliers simply need a place of business, a business license and liability insurance. Unlike pharmacists, DME suppliers operate under an honor system: The feds count on them to supply the equipment they claim to provide to the beneficiaries who need it. 

That honor system is not working. 

The epicenter of DME fraud, according to the federal Department of Health and Human Services, is South Florida, where Medicare billing for DME quadrupled from 2002 to 2006 to $1.7 billion. Investigators found much of that increase was due to fraud. In 2006, federal inspectors revoked the licenses of 634 DME suppliers in South Florida, nearly half the DME dealers in the region. 

Later the same year, raids in Southern California yielded similar results: The feds shut down 95 DME suppliers. Many of the DME suppliers shut down around Los Angeles were run by immigrants from the former Soviet Union. It’s probably no coincidence that when the feds raided Los Angeles DME suppliers, some Angelenos fled to cities where there was less scrutiny—such as Portland.

The same key points of that presentation are still relevant today:

1. Event-Decision Processing is Computationally Intensive

2. CEP requires a Number of Technologies:

• Distributed Computing, Publish/Subscribe and SOA
• Hierarchical, Cooperative Inference Processing
• High Speed, Real Time Processing with State Management
• Event-Decision Architecture for Complex Situations and Events
• There is no single “CEP Solution” or “CEP Product” (in the market place then, and today)

3. CEP needs a Common Vocabulary and Functional Architecture based on Mature, Industry-Standard Inference Models

4. Processing and Integration Patterns for CEP need to be Developed and Formalized

Since March of 2006 a number of other challenges has surfaced.  I will elaborate on this challenges in a future post.

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapide concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.

Applications of Complex Event Processing:

• Instant Insight  - hierarchical event viewing applied to the Enterprise IT layer. (coming soon)
  • Analysing business processes (paper in pdf format)
• Network Level Monitoring and Management (Powerpoint presentation)
• Cyber Security: Network Intrusion Detection
• Enterprise Monitoring and Management (coming soon)
• Modeling and Simulation of Collaborative Business Processes
• Business Policy Monitoring. (coming soon)
• Analysis and Debugging of Distributed Systems (coming soon)

Presentations:

• “Complex Event Processing: An Essential Technology for Instant Insight into the Operation of Enterprise Information Systems,” lecture at the Stanford University Computer Systems Laborary EE380 Colloquium series. Video of the lecture (duration: 60 minutes).

Publications:

• Complex Event Processing in Distributed Systems. David C. Luckham and Brian Frasca, Stanford University Technical Report CSL-TR-98-754, March 1998, 28 pages.Abstract: Complex event processing is a new technology for extracting information from distributed message-based systems. This technology allows users of a system to specify the information that is of interest to them. It can be low level network processing data or high level enterprise management intelligence, depending upon the role and viewpoint of individual users. And it can be changed from moment to moment while the target system is in operation. This paper presents an overview of Complex Event Processing applied to a particular example of a distributed message-based system, a fabrication process management system. The concepts of causal event histories, event patterns, event filtering, and event aggregation are introduced and their application to the process management system is illustrated by simple examples. This paper gives the reader an overview of Complex Event Processing concepts and illustrates how they can be applied using the Rapide toolset to one specific kind of system.
   
• Event Mining with Event Processing Networks. Louis Perrochon and Walter Mann and Stephane Kasriel and David C. Luckham, The Third Pacific-Asia Conference on Knowledge Discovery and Data Mining. April 26-28, 1999. Beijing, China, 5 pages.Abstract: Event Mining discovers and delivers information and knowledge in a real-time stream of data, or events. We show that the process of delivering knowledge by searching patterns in data and subsequent abstraction of found patterns can be applied in real-time to a complex, asynchronous system. Our event processing engine consists of a network of event processing agents (EPAs) running in parallel that interact using a dedicated event processing infrastructure. The agents can be configured at run-time using a formal pattern language. The underlying infrastructure (1) provides an abstract communication mechanism and thus allows dynamic reconfiguration of the communication topology between agents at run-time and (2) provides transparent, location-independent access to all data. These features allow dynamic allocation of EPAs to different threads and processes on different machines at run time.
   
• eJava - Extending Java with Causality. Alexandre Santoro and Walter Mann and Neel Madhav and David Luckham, Proceedings of the 10th International Conference on Software Engineering and Knowledge Engineering, June 1998, 10 pages.Abstract: Programming languages like Java provide designers with a variety of classes that simplify the process of program development. Some of these classes allow one to easily build multithreaded programs. Though useful, especially in the creation of reactive systems, multithreaded programs present challenging problems such as race conditions and synchronization issues. Validating these programs against a specification is not trivial since Java does not clearly indicate thread interaction. These problems can be solved by modifying Java so that it produces computations, collections of events with both causal and temporal ordering relations defined for them. Specifically, the causal ordering is ideal for identifying thread interaction. This paper presents eJava, an extension to Java that is both event based and causally aware, and shows how it simplifies the process of understanding and debugging multithreaded programs.
   
• Event-Based Execution Architectures for Dynamic Software Systems. James Vera, Louis Perrochon, David C. Luckham.
  Proceedings of the First Working IFIP Conf. on Software Architecture. 1999. San Antonio, Texas.Abstract: Distributed systems’ runtime behavior can be difficult to understand. Concurrent, distributed activity make notions of global state difficult to grasp. We focus on the runtime structure of a system, its execution architecture, and propose representing its evolution as a partially ordered set of predefined architectural event types. This representation allows a system’s topology to be visualized, analyzed and con-strained. The use of a predefined event types allows the execution architectures of different systems to be readily compared.
   
• Using Context-Based Correlation in Network Operations and Management. Louis Perrochon (work in progress, mail author for newest version)Abstract: Network operation consists to a large degree of reaction to activities happening in the network. Better knowledge of the network at any time allows more appropriate reactions. On the example of intrusion detection, we show how context-based correlation of such activities can provide a more detailed view of the network in shorter time. We first present how we model context and then describe the architecture of the Stanford University CEP context-based correlator. Correlation is specified as event patterns in a declarative language that allows us to specify what needs to be detected, instead of specifying how it should be detected. CEP introduces the concept of causal context to intrusion detection. The correlator is able to process events on-line, as they are generated and it can be reconfigured at dynamically. We then show how it increases detection rate, reduce false alarms, and detect large-scale attack patterns at an early stage.