· … someone asks about your weekend plans and your answer consists of a list of Pri ones, twos, and threes.

· … you’ve ever ended a relationship using a PowerPoint presentation."

(more)

The Cisco 7600 OSR consists of a 256 Gbps switching fabric and a 30 million packets per second (mpps) forwarding engine. Its breadth of IP services comes from Cisco IOS, which provides features such as security, enhanced QoS, and destination sensitive services. In addition, the Cisco 7600 OSR allows the migration of existing port adapters from Cisco 7500 series routers, via the Cisco FlexWAN module, giving service providers one the industry’s widest array of interface options in any single platform. This provides service providers great flexibility in deploying the Cisco 7600 OSR for a variety of applications, protects their investment in existing systems, and gives them a practical migration path to the New World Optical Internet.

A Revolutionary Platform For Evolving Networks

The Cisco 7600 OSR helps service providers break through service and bandwidth barriers today, while designing networks to scale for future growth. The Cisco 7600 OSR achieves this through “adaptive network processing,” or the ability to evolve the platform for new IP services without hardware upgrades. Unlike fixed, ASIC-based platforms, which are hardware encoded, the Cisco 7600 OSR relies on the highly flexible Parallel eXpress Forwarding (PXF) technology for scalable performance of services. PXF is a patented, Cisco-developed network processor capable of line-rate IP services delivery that can support new IP services through periodic software upgrades. Each OSM has two PXF processors capable of 12 mpps of IP services delivery per interface card.

“IP+Optical combines the dynamism of the Internet world with the foundation of the transport world, creating an infrastructure that can deliver the services that service providers need,” said Lele Nardin, vice president of the Internet Systems Business Unit at Cisco. “Cisco will continue to add innovative solutions on top of this solid foundation to make service providers better equipped to meet the constantly escalating and changing customer demands for new networking services.”

Pricing and Availability

The base Cisco 7600 OSR system is list priced at $73,000 and the entry level system, with interfaces, start at $100,000. The interfaces modules are priced between $27,000 to $180,000. The Cisco 7600 OSR is available now worldwide.

The following excellent discussion is reposted from Streaming SQL approaches insist in ignoring causality by PatternStorm.

The recent paper “Towards a Streaming SQL Standard” by Oracle and Streambase unifies and generalizes two different execution models of Streaming SQL: Oracle’s and StreamBase’s.

While it’s true that the generalization succeeds in overcoming the unability of both execution models of producing correct results for astonishing simple queries (showing evidence of the actual limitations of these two Streaming SQL languages) it is also true that the generalization is closer to being overly complex than natural and intuitive.

The root cause behind the actual limitations of these two Streaming SQL languages is that their execution models “hardcode” the way events can be related to each other: in the Oracle case events are partially ordered by timestamp, in the StreamBase case events are totally ordered by time of arrival. These design decisions (natural in a stream oriented lamguage) have strong implications on what queries can be answered correctly, particularly when these queries involve joins of derived streams.

The generalization, of course, mainly consists in providing a new operator that allows the user to establish custom ordering relationships among the events (the SPREAD operator), which is good news but takes us to the fundamental issue: event processing cannot be reduced to stream processing, that is, to the processing of events that are totally or partially ordered by a pre-defined relationship (as Oracle and StreamBase actual implementations do), on the contrary, no particular ordering can be assumed because the user needs to be able to order the events in different ways in order to solve different problems. This is what event processing is about and the paper provides evidence that Streaming SQL approaches have found the need to move towards that direction and are having trouble in their way.

For instance, one of the queries used in the paper as an example of a query that StreamBase cannot solve (but Oracle can) is the following: correlate the stream that contains the total number of cars on the road for each time interval with the stream that contains the total average speed of the cars on the road for each time interval in order to detect the situation where the avergae speed is below 45 and the total number of cars is two or more. This query can be very easily and more robustly solved if you order the events by causality rather than by time, that is, if you have each position report update the average speed stream and the total number of cars stream and then you causally relate each position report to the new average speed event and the new total number of cars event that it generates; then the query is just a matter of detecting all report speeds that are causally related both to an average speed event below 45 and a total number of cars event of two or more (notice that this approach is more robust than Oracle’s time-based one because it works without requiring derived streams to be synchronized with the report speed stream)

Conclusions:

• Event Processing is a generalization of Stream Processing (as the paper shows)
• Event Processing requires providing the ability to the user of creating custom relationships among events and then define patterns/queries using those custom relationships.
• Causality is more often than not a more robust and easier criteria to order events than time or order of arrival.
• Event Processing Languages should support causality.

Regards,
PatternStorm

Formalize your Final Security Review (FSR) Process

A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.

Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.

What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.

What does an FSR team do?

1. Re-review threat models to verify all mitigations identified in those exercises were fixed or went through an exception process.
2. Verify that all security issues uncovered during the development process were fixed or granted exceptions by the appropriate people. This is where you verify whether the state of your security bugs meets the “bug bar” requirements you have defined for your products.
3. If there is any output from security tools that you have used to define requirements, the FSR team would verify that the results of the tools meet the security requirements.
4. Review all exceptions to verify that they approve these decisions in the context of the final product. If they identify risks associated with the exceptions, they should communicate those to the business ownership for a final decision before signoff. Any decisions related to known risks should also be reflected in the response plan for future reference.
5. Finally, there should be a final signoff exercise where all security people and project leadership jointly approve the decision of the Final Security Review.

How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.

Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.

Document security work for reference

After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:

·         All final threat models for future reference.

·         Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.

·         All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.

·         The final symbols that reflect the product shipped should be archived.

·         The Final Security Report and project signoffs to validate your security audit activity

·         Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.

Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.

In closing…

I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.

I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.

We represent situations in the domain of event processing by building and refining models of situations. This means that one way to develop CEP applications or designing CEP architectures is to define situations of interest and build models that define the situation.

After we have a working model of the situation we will generally have a hierarchical model of the situation composed of various components of the situation. For purposes of discussion I refer to this as situation modelling.

If a situation is modelled with 15 components then we need to detect these components of the situation. In addition, it is generally not good enough to simply detect each one of these components of the situation. We also have to hold the state of each one of the situational components.

However, it is not good enough to simply observe the state of 15 components of a situation in the detection process; we also need to observe the relationship between the components.

So, let’s say the situation we are looking for is “commercial air plane collision” and we are building a model of this situation. To keep the model simple we will limit the model to airplanes and omit objects like birds, buildings; but we will include wind, air speed, and direction.

Our situational model consists of primary objects, in this case an airplane. Now we need a simple model of an airplane, which is modelled, in this overly simple example, as span, velocity, acceleration, altitude, orientation and relative wind speed and direction. Generally, an object-oriented approach to model building is preferred so we can reuse the model and overload, morph, inherit and encapsulate as necessary.

One example would be when our boss comes to us and says, great job on the airplane collision model, but I also want to know how much jet fuel is on the planes at the moment of our projected situation, so we can estimate the intensity of the explosion. So we need another model and our earlier very simple airplane model would inherit the jet fuel tank model our boss requires.

I hope from this simple example of model building that you will conclude that modelling is one of the most important aspects of CEP. Without good models, situation detection impossible, and CEP engines are useless. Situation modelling is critical to CEP.

So, if a CEP vendor comes to you and says they have a very powerful CEP engine, ask them to show you a complex model of a situation that is important to you and explain to you how they represent the object. If models are not represented using an object-oriented approach, I recommend you send the vendor back to their software development lab, because without an OO approach to modelling, you can only represent very simple situations.

Furthermore, let’s say you are leading a team building a large model. If there are several teams working on various parts of the model, you need a common framework to integrate the work of the various teams. I strongly recommend an OO approach to your model building systems architecture and work breakdown structure.

In a future post, I will write about the companion to modelling – simulation

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.

Disappointingly, the author sprinkles the usual super-secret uber-hacker spin throughout the article to make the Red Team seem mysterious and exclusive, with untouchable talent. It’s a little misleading. For starters, there’s the predictable question about success rates:

I’d heard from one of the Department of Defense clients who had previously worked with the NSA red team that OWNSAVAOG and his team had a success rate of close to 100 percent. “We don’t keep statistics on that,” OWNSAVAOG insisted when I pressed him on an internal measuring stick.

This is one of those statements that is difficult for the average reader to interpret. It’s intended to make the team sound like a crack squad of hackers, but in reality it’s the same statistic that every security consultancy cites during sales calls. The truth is, there’s a lot of wiggle room on what is considered “getting in” to the target. For example, some would say that brute forcing an FTP server and downloading some FOUO (For Official Use Only) documents constitutes penetrating the target. Others would disagree.

How about personnel? I thought this was an englightening and accurate statement from the unnamed NSA source:

And like any good geek at a desk talking to a guy with a really cool job, I wondered just where the NSA finds the members of its superhacker squad. “The bulk is military personnel, civilian government employees and a small cadre of contractors,” OWNSAVAOG says. The military guys mainly conduct the ops (the actual breaking and entering stuff), while the civilians and contractors mainly write code to support their endeavors. For those of you looking for a gig in the ultrasecret world of red teaming, this top hacker says the ideal profile is someone with “technical skills, an adversarial mind-set, perseverance and imagination.”

He basically admits that the team consists mostly of people who “run the tools” and only a handful that actually write the tools or do anything cutting-edge. It shouldn’t be that surprising; just as in any large consulting organization, you have some people who run scanners/tools and aren’t expected to be terribly analytical. While the Red Team almost certainly has some superstars, on the whole it is similar in both skillset and composition to a typical consultancy or enterprise security team.

In terms of attracting and retaining top talent, the Red Team faces the same challenges as the rest of the information security industry, with the built-in disadvantage of the government pay scale. If that wasn’t bad enough, they also have to compete with themselves (i.e. the rest of the NSA) for already scarce resources. Given these challenges, how could one realistically expect the Red Team to be as advanced as the article portrays?

Finally, let’s dispel the “super-secret” notion — unless things have changed significantly, the majority of Red Team operations are unclassified. Granted, detailed information is guarded, but you can find reports summarizing past operations if you dig around a bit. One would expect that an operation intended to be truly secretive would never make its way into Google search results.

I want to conclude by saying that this post is not intended to cast the Red Team itself in a negative light. I enjoyed my time there and had the opportunity to work with some smart people. The Red Team’s goals are worthy and noble; clearly, state-sponsored cyberterrorism is a growing concern and as a country we should be as prepared as possible. But realize that we have a long way to go.

From Snort.org:

We’re pleased to introduce our first beta release built on the new Snort 3.0 architecture. The Snort 3.0 architecture consists of two primary components: a software platform called the Snort Security Platform (SnortSP) 3.0, which is shipping in beta form in this release, and traffic analysis engine modules that plug into SnortSP. This beta test release contains one engine module which contains the Snort 2.8.2 detection engine implemented as a SnortSP engine module. SnortSP is an open-source platform for running packet-based network security applications. It provides many of the common functions required by programs that deal with packet processing such as configuration loading, event generation and traffic logging, data acquisition, protocol decoding and validation, flow management, and more.

They provide you an opportunity to provide feedback on the beta release as well “sspneta SHIFT 2 sourcefire D0T com”.

Downloading my copy now.

Article Link