You can read all the details on their website (except for the part about the certification not being a measure of practical skills). From what I can tell, the CSSLP is just the CISSP with different CBKs, or Common Bodies of Knowledge. As with the CISSP, they are going for broad knowledge, not depth. Starting in June 2009, you can get certified by taking a paper exam, likely a multiple choice test similar to the CISSP. Why June? Because the test isn’t even written yet — I’ve heard from several sources that they are actively soliciting their existing pool of CISSPs to help write test questions.

Ah, but what if you can’t wait that long and want to get certified right away? You’re in luck. If you act before March 31, 2009, you can get grandfathered in without even having to take the exam! That’s right, they call it the CSSLP Experience Assessment, and here are the requirements:

• Upload a resume showing three years of experience related to software security, or four years if you don’t have a college degree
• Write short essays (500 words maximum) discussing four CBKs of your choice
• Get a CISSP to vouch for you
• Pay $650

Let’s examine these requirements one at a time.

Three years of experience. (ISC)2 doesn’t provide any requirements on depth of experience, other than citing the broadly-defined CBKs. Considering they are targeting everyone from software developers to security assessors to business analysts (yes, really), chances are they are going to accept any experience that is even tangential to the SDLC or software security.

Short essays on four of the CBKs. I asked the (ISC)2 exhibitors specifically what they are looking for to satisfy this requirement, and they said the essays should be a general discussion of the CBK topic, optionally citing your personal experience in that area if you have any. This messaging is not quite aligned with the website guidance, which states that the essays should be “Accomplishment Records” which are self-reported descriptions of experience. Either way, with a maximum essay length of 500 words, it’s pretty obvious that substance is not (ISC)2’s first priority. Here’s one data point for you: I spoke to someone who has already submitted the CSSLP Experience Assessment, and he said it took about an hour to write the essays.

Get a CISSP to vouch for you. Actually this can be any (ISC)2 certified person, not just CISSPs. Contrary to what you’d expect, though, the person isn’t vouching for your skillset so much as they are confirming that the attestations on your resume are accurate.

Pay $650. You knew it was coming. After all, there is money to be made. How is it that qualifying for the CSSLP through professional experience should cost $650? If you’re taking the written exam, fair enough, (ISC)2 does incur the cost of administering and grading that exam (even though the Scantron machine is probably paid off by now). But $650 for the submitted-online Experience Assessment? If we assume that the person reading these essay submissions makes a rather generous $100k per year, then $650 accounts for roughly a day and a half. Will it really take that long to read a maximum of 2,000 words and pass judgment? Of course not. (ISC)2 wants to get as many people as possible to qualify based on “experience”, seeding the initial pool of CSSLPs and netting them $650 per head for doing next to nothing.

As Lee Kushner stated during his OWASP AppSec presentation (7 Habits of Highly Effective Career Managers), “the more people who own a cert, the less relevant it becomes.” Irrelevant — that’s exactly what the CISSP has become, and it’s exactly where the CSSLP is headed. Meanwhile, (ISC)2 will sit back and watch while you and your employers continue to fill their coffers.

In closing, let me acknowledge that this blog entry probably comes across as judgmental. I accept that. I’m not ranting against the idea of certifications, though admittedly I’m not a fan of them either. I am disappointed that (ISC)2, an organization with tremendous influence, could have created something more meaningful but chose not to. Why bother when people will just fork over the cash anyway?

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

“Event processing has been going on for more than fifty years.”

However, in On Event Processing as a Discipline and Some Subsets another colleague mistakenly blogs,

“… people who dealt in this area [network management and event correlation] have never investigated event processing in the larger sense (e.g. looking at additional patterns), and this area has also not spawned the event processing discipline.”

If you examine just one page from the CEP history at Stanford, researchers there outlined their view of the future applications for CEP, as follows:

• Instant Insight  - hierarchical event viewing applied to the Enterprise IT layer.
  • Analysing business processes
• Network Level Monitoring and Management
• Cyber Security: Network Intrusion Detection
• Enterprise Monitoring and Management
• Modeling and Simulation of Collaborative Business Processes
• Business Policy Monitoring
• Analysis and Debugging of Distributed Systems

These applications areas mentioned by Stanford researchers, including Professor Luckham, support and validate our recent discussion Magic Quadrant for IT Event Correlation and Analysis, 2007 where we concluded that “event correlation and event analysis is Gartner’s closest magic quadrant (MQ)  [...] relates directly to complex event processing (and event processing in general).”  

If you take a detailed look at the 1999 CEP presentation, Defeating Large Scale Attacks: Technology and Strategies for Global Network Monitoring you will readily see that our colleagues are incorrect when they says that event correlational and network management folks have never investigated event processing in the “larger sense”.  For example, the 1999 slides above, Stanford, slide 6, is titled “Complex Event Processing,” defining CEP from the application perspective of event correlation;

Complex Event Processing

• Accept network ‘events’ from any source
  • CISCO NetFlow FlowCollector, tcpdump
• Correlates events based on content and temporal relationship between events
• Event Processing Agents (EPAs) connected in an Event Processing Network (EPNs)
• Both post-mortem and real-time processing

This single event correlational project example from David’s team at Stanford examined the challenging event correlation problems in the context of hierarchical events, maps, patterns, visualization tools, event processing models, patterns languages, network management abstraction layers, and more.  Those core event processing problems from this 1999 example, very large and complex then, still exist today and are much more large and complex - precisely why it is called “complex event processing.”

It is quite obvious, in just this one example, that many folks have been looking at event correlation as a motivating application for event processing, in a larger context, for a long time, contrary to what our colleagues write in their “history of event processing” posts.  

In a future post I will completely debuke these event processing “history revisionists.”   I will illustrate very clearly how the history of event processing goes back at least a decade, and perhaps two (twenty years) before the history outlined in posts like On Research and Practice in Event Processing and The History of Complex Event Processing. 

David Luckam stated that the art-and-science of event processing goes back around 50 years. 

I am not sure I will go all the way back to 1960 in my next post on the history of event processing.  However,  I will go back at least to the early days of Internet Protocol (IP) networking and illustrate why distributed IP networking, network management and network security, is one of the key  motivating factors for what we now call “event processing” and “complex event processing.”

The rate of total homicide and the rate of homicide due to mental disorder rose steadily until the mid-1970s. From then there was a reversal in the rate of homicides attributed to mental disorder, which declined to historically low levels, while other homicides continued to rise.

Paper and press release.

Remember this the next time you read a newspaper article about how scared everyone is because some patients escaped from a mental institution:

We are convinced by the media that people with serious mental illnesses make a significant contribution to murders, and we formulate our approach as a society to tens of thousands of people on the basis of the actions of about 20. Once again, the decisions we make, the attitudes we have, and the prejudices we express are all entirely rational, when analysed in terms of the flawed information we are fed, only half chewed, from the mouths of morons.

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.

An interesting excerpt:

“CIOs have emphasized to us that they are buying on a need versus want basis, are often downsizing deals to fit with current budget constraints…In fact, contrary to general tightening in spending, purchases with an especially compelling ROI are being accelerated in the current environment.”

Hmm. Certainly we all understand prioritizing what to buy on need versus want– my friend who runs an art gallery that has only sold one piece in the past 2 months can certainly explain it. I “need” that Picasso? But does it take the entire economy slowing down before CIOs, even at Fortune 100 companies, to focus on ROI? So it’s not surprising what showed up at the top of the list for spending priorities for 2008-2009:

1. Server Virtualization
2. Server Consolidation
3. Cost Cutting

At the bottom of the list, grid computing and on-demand computing.

Compare this to last year’s spending survey where the top 10 priorities by rank were:

1. Applications integration
2. Security
3. Cost Cutting
4. BI
5. ERP
6. Web-based app development
7. Datacenter consolidation
8. Disaster Recovery
9. Compliance/risk management
10. Identity and access management

So in one year, the very hot “server virtualization” (and quite similar server consolidation) jumped to the top of the spending priority list. Can anyone have predicted just how much mindshare virtualization would capture in such a short time? Virtualization is not a new concept; it just seems that way. What will be # 1 next year?

ShareThis

“The Afghanis, they live in mud huts, they don’t have electricity, they are stick-people weighing 85 lbs, and to say that we could bomb them into the stone age would be an advancement in their technology level.  But never underestimate these people, they’re survivors.  They’ve survived 35 years of warfare, starting with the Soviets, then they fought a civil war before we arrived on the scene.  Never underestimate their ability to survive, and have respect for them because of who they are.”

Today, I feel the same way about government employees, even more so because it’s an election year:  they’re survivors.

Now time for what I see is the “real” reason why the government is doing badly (if that’s what you believe–opinions differ) at security: it’s all an issue of culture. I have a friend who converted a year ago to a GS-scale employee and took a class on what motivates government employees. Some of these are obvious:

• Pride at making a difference
• Helping people
• Supporting a cause
• Gaining unique experience on a global-class scope
• Job stability
• Retirement benefits

And one thing is noticeably absent: better pay and personal recognition.  Hey, sounds like me in the army.

The Companion Family Plan for Survival at Home photo by Uh … Bob.

Now I’m not trying to stereotype, but you need to know the organizational behavior pieces to understand how government security works. And in this case, the typical government employee is about as survival-aware as their Afghani counterpart.

Best advice I ever heard from a public policy wonk: the key to survival in this town is to influence everything you can get your hands on and never have your name actually written on anything.

In other words, don’t criticize, be nice to everybody even though you think they are a jerk, and avoid saying anything at all because you never know when it will be contrary to the political scene.  The Government culture is a silent culture. That’s why every day amazing things happen to promote security in the Government and you’ll never hear about it on the outside.

One of the reasons that I started blogging was to counter the naysayers who say that FISMA is failing and that the Government would succeed if they would just buy their product for technical policy compliance or end-to-end encryption.  Sadly, the true heroes in Government, the people who just do their job every day and try to survive a hostile political environment, are giving credit to the critics because of their silence.

Which brings me to my point:

Yes, my name is Rybolov and I’m a heretic, but this is the secret to security in the Government:  it’s cultural at all layers of the personnel stack.  Security (and innovation, now that I think about it) needs a culture of openness where it’s allowable to make mistakes and/or criticize.  Doesn’t sound like any government–local, state, or federal–that I’ve ever seen.  However, if you fix the culture, you fix the security.

Bookmark to:

Bruce Sterling (11/20/2001):

You know what I want? I don't want a National ID Card. I want a Global Coalition Visa.

Like it or not, we've got a huge global diaspora now. It is a fact of life. Nations with stupid and corrupt politics have seen their clever people brain- drained away, to places where the cops don't shake you down twice a day. And jet-setters go everywhere. And properly so. If you're in a true global society, then you spend a lot of your time among aliens. Quite often you are the alien. You might notice that even Al Qaeda is a genuinely multinational group. They gravitated to wicked, lawless places like Sudan, Chechnya and Afghanistan, where the locals shoot you if you ask for a badge.

But what about all us bright, shiny, world-trading jet setters, huh? There are thirty percent fewer Yankees in Europe this Christmas, and that is bad. Let me pose the problem this way. If I am going into a Japanese restaurant in Japan, I would rather like to be able to haul out some gizmo and flash it at my fellow civilians, and have these kindly people understand with a high degree of likelihood that I am not a mass murderer. On the contrary, I am quite civilized, and I should be brought a beer immediately.

A platinum VISA card and a five-hundred-dollar suit will almost do that, but those are too easy to forge and steal, plus they are not very democratic. The UN should get together on this. We should have a high level summit about digital hardware support for the crippled tourist economy. Fear and ill treatment shut down tourism faster than anything short of open warfare. That is bad for all of us. Killing off tourism harms our civilization and impoverishes our cultures. People in civilized states shouldn't routinely treat one another as criminal suspects. I don't want to get done-over for three hours every time I get off a plane in London. When I go to London, I go with empty suitcases. I don't plan to stay, but I am better news for the London economy than a lot of the people who live there.

They should know all that that before I get off the plane. My arrival is excellent news for Britain, so I should be treated that way. If this is a new kind of war, I don't want to be the evil guy hunkered down in the bunker; I want to fly with the boys from Air Assault. I want one of those handy crypto-style Friend-or-Foe IDs.

These people who normally meet me whenever I am an alien, they don't need to know my nationality, my home address or my shoe size. They just need to know that, despite being alien, I'm sort-of okay.

I want a democratic, citizen-to-citizen device that will bridge those social barriers and language barriers. I think we could invent devices and means of verification that would strengthen the global social fabric that terrorism wants to rip. It wouldn't be easy or simple, but it's not beyond our ingenuity. Our social capital sustains all civilized societies, and it is all about trust. So let's invent new methods of trust.

I added bold to the last sentence because I think this is the mission statement for building out federation systems.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.