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?

It's basically what you would expect: Appoint a national cyber security advisor, invest in math and science education, establish standards for critical infrastructure, spend money on enforcement, establish national standards for securing personal data and data-breach disclosure, and work with industry and academia to develop a bunch of needed technologies.

I could comment on the plan, but with security the devil is always in the details -- and, of course, at this point there are few details. But since he brought up the topic -- McCain supposedly is "working on the issues" as well -- I have three pieces of policy advice for the next president, whoever he is. They're too detailed for campaign speeches or even position papers, but they're essential for improving information security in our society. Actually, they apply to national security in general. And they're things only government can do.

One, use your immense buying power to improve the security of commercial products and services. One property of technological products is that most of the cost is in the development of the product rather than the production. Think software: The first copy costs millions, but the second copy is free.

You have to secure your own government networks, military and civilian. You have to buy computers for all your government employees. Consolidate those contracts, and start putting explicit security requirements into the RFPs. You have the buying power to get your vendors to make serious security improvements in the products and services they sell to the government, and then we all benefit because they'll include those improvements in the same products and services they sell to the rest of us. We're all safer if information technology is more secure, even though the bad guys can use it, too.

Two, legislate results and not methodologies. There are a lot of areas in security where you need to pass laws, where the security externalities are such that the market fails to provide adequate security. For example, software companies who sell insecure products are exploiting an externality just as much as chemical plants that dump waste into the river. But a bad law is worse than no law. A law requiring companies to secure personal data is good; a law specifying what technologies they should use to do so is not. Mandating software liabilities for software failures is good, detailing how is not. Legislate for the results you want and implement the appropriate penalties; let the market figure out how -- that's what markets are good at.

Three, broadly invest in research. Basic research is risky; it doesn't always pay off. That's why companies have stopped funding it. Bell Labs is gone because nobody could afford it after the AT&T breakup, but the root cause was a desire for higher efficiency and short-term profitability -- not unreasonable in an unregulated business. Government research can be used to balance that by funding long-term research.

Spread those research dollars wide. Lately, most research money has been redirected through DARPA to near-term military-related projects; that's not good. Keep the earmark-happy Congress from dictating how the money is spent. Let the NSF, NIH and other funding agencies decide how to spend the money and don't try to micromanage. Give the national laboratories lots of freedom, too. Yes, some research will sound silly to a layman. But you can't predict what will be useful for what, and if funding is really peer-reviewed, the average results will be much better. Compared to corporate tax breaks and other subsidies, this is chump change.

If our research capability is to remain vibrant, we need more science and math students with decent elementary and high school preparation. The declining interest is partly from the perception that scientists don't get rich like lawyers and dentists and stockbrokers, but also because science isn't valued in a country full of creationists. One way the president can help is by trusting scientific advisers and not overruling them for political reasons.

Oh, and get rid of those post-9/11 restrictions on student visas that are causing (.pdf) so many top students to do their graduate work in Canada, Europe and Asia instead of in the United States. Those restrictions will hurt us immensely in the long run.

Those are the three big ones; the rest is in the details. And it's the details that matter. There are lots of serious issues that you're going to have to tackle: data privacy, data sharing, data mining, government eavesdropping, government databases, use of Social Security numbers as identifiers, and so on. It's not enough to get the broad policy goals right. You can have good intentions and enact a good law, and have the whole thing completely gutted by two sentences sneaked in during rulemaking by some lobbyist.

Security is both subtle and complex, and -- unfortunately -- it doesn't readily lend itself to normal legislative processes. You're used to finding consensus, but security by consensus rarely works. On the internet, security standards are much worse when they're developed by a consensus body, and much better when someone just does them. This doesn't always work -- a lot of crap security has come from companies that have "just done it" -- but nothing but mediocre standards come from consensus bodies. The point is that you won't get good security without pissing someone off: The information broker industry, the voting machine industry, the telcos. The normal legislative process makes it hard to get security right, which is why I don't have much optimism about what you can get done.

And if you're going to appoint a cyber security czar, you have to give him actual budgetary authority -- otherwise he won't be able to get anything done, either.

This essay originally appeared on Wired.com.

It's basically what you would expect: Appoint a national cyber security advisor, invest in math and science education, establish standards for critical infrastructure, spend money on enforcement, establish national standards for securing personal data and data-breach disclosure, and work with industry and academia to develop a bunch of needed technologies.

I could comment on the plan, but with security the devil is always in the details -- and, of course, at this point there are few details. But since he brought up the topic -- McCain supposedly is "working on the issues" as well -- I have three pieces of policy advice for the next president, whoever he is. They're too detailed for campaign speeches or even position papers, but they're essential for improving information security in our society. Actually, they apply to national security in general. And they're things only government can do.

One, use your immense buying power to improve the security of commercial products and services. One property of technological products is that most of the cost is in the development of the product rather than the production. Think software: The first copy costs millions, but the second copy is free.

You have to secure your own government networks, military and civilian. You have to buy computers for all your government employees. Consolidate those contracts, and start putting explicit security requirements into the RFPs. You have the buying power to get your vendors to make serious security improvements in the products and services they sell to the government, and then we all benefit because they'll include those improvements in the same products and services they sell to the rest of us. We're all safer if information technology is more secure, even though the bad guys can use it, too.

Two, legislate results and not methodologies. There are a lot of areas in security where you need to pass laws, where the security externalities are such that the market fails to provide adequate security. For example, software companies who sell insecure products are exploiting an externality just as much as chemical plants that dump waste into the river. But a bad law is worse than no law. A law requiring companies to secure personal data is good; a law specifying what technologies they should use to do so is not. Mandating software liabilities for software failures is good, detailing how is not. Legislate for the results you want and implement the appropriate penalties; let the market figure out how -- that's what markets are good at.

Three, broadly invest in research. Basic research is risky; it doesn't always pay off. That's why companies have stopped funding it. Bell Labs is gone because nobody could afford it after the AT&T breakup, but the root cause was a desire for higher efficiency and short-term profitability -- not unreasonable in an unregulated business. Government research can be used to balance that by funding long-term research.

Spread those research dollars wide. Lately, most research money has been redirected through DARPA to near-term military-related projects; that's not good. Keep the earmark-happy Congress from dictating (.pdf) how the money is spent. Let the NSF, NIH and other funding agencies decide how to spend the money and don't try to micromanage. Give the national laboratories lots of freedom, too. Yes, some research will sound silly to a layman. But you can't predict what will be useful for what, and if funding is really peer-reviewed, the average results will be much better. Compared to corporate tax breaks and other subsidies, this is chump change.

If our research capability is to remain vibrant, we need more science and math students with decent elementary and high school preparation. The declining interest is partly from the perception that scientists don't get rich like lawyers and dentists and stockbrokers, but also because science isn't valued in a country full of creationists. One way the president can help is by trusting scientific advisers and not overruling them for political reasons.

Oh, and get rid of those post-9/11 restrictions on student visas that are causing (.pdf) so many top students to do their graduate work in Canada, Europe and Asia instead of in the United States. Those restrictions will hurt us (.pdf) immensely in the long run.

Those are the three big ones; the rest is in the details. And it's the details that matter. There are lots of serious issues that you're going to have to tackle: data privacy, data sharing, data mining, government eavesdropping, government databases, use of Social Security numbers as identifiers, and so on. It's not enough to get the broad policy goals right. You can have good intentions and enact a good law, and have the whole thing completely gutted by two sentences sneaked in during rulemaking by some lobbyist.

Security is both subtle and complex, and -- unfortunately -- it doesn't readily lend itself to normal legislative processes. You're used to finding consensus, but security by consensus rarely works. On the internet, security standards are much worse when they're developed by a consensus body, and much better when someone just does them. This doesn't always work -- a lot of crap security has come from companies that have "just done it" -- but nothing but mediocre standards come from consensus bodies. The point is that you won't get good security without pissing someone off: The information broker industry, the voting machine industry, the telcos. The normal legislative process makes it hard to get security right, which is why I don't have much optimism about what you can get done.

And if you're going to appoint a cyber security czar, you have to give him actual budgetary authority -- otherwise he won't be able to get anything done, either.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Soldiers were deployed throughout Italy on Monday to embassies, subway and railway stations, as part of broader government measures to fight violent crime here for which illegal immigrants are broadly blamed.

[...]

The conservative government of Silvio Berlusconi won elections in April while promising to crack down on petty crime and illegal immigrants. The new patrols of soldiers, who are not empowered to make arrests, do not seem aimed only at illegal immigrants, though the patrols were deployed to centers where illegal immigrants are housed.

“Security is something concrete,” Mr. La Russa said on Monday. The troops, he said, will be a “deterrent to criminals.”

That reminds me of one of my favorite logical fallacies: "We must do something. This is something. Therefore, we must do it." It does seem largely to be a demonstration of "doing something" by the Berlusconi government. The legitimate police, of course, think it's a terrible idea.

“You need to be specially trained to carry out some kinds of controls,” Nicola Tanzi, the secretary of a trade union that represents Italian police officers. “Soldiers just aren’t qualified.”

He also questioned whether the $93.6 million that will be spent for the extra deployment, called Operation Safe Streets, might not have been better used to increase the budgets for Italy’s police and military.

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

A few folks have tried to tie “maturity” to “if the code is robust” or “if the product has certain product features.” The way we have addressed this emerging controversy over at The CEP blog is to center the discussion around the Gartner Hype Cycle, which is a pretty good model for representing the maturity, adoption and business application of specific technologies.

On CEP Maturity and the Gartner Hype Cycle

Since many folks work very closely with Gartner, I expect they are keenly aware of Gartner’s view on technology adoption maturity models and their definitions. Just for our readers who might not be as familar, I quote Gartner’s definitions below to be complete from here:

A hype cycle is a graphic representation of the maturity, adoption and business application of specific technologies. The term was coined by Gartner[citation needed], an analyst/research house, based in the United States, that provides opinions, advice and data on the global information technology industry.

Since 1995, Gartner has used hype cycles to characterize the over-enthusiasm or “hype” and subsequent disappointment that typically happens with the introduction of new technologies. Hype cycles also show how and when technologies move beyond the hype, offer practical benefits and become widely accepted. According to Gartner, hype cycles aim to separate the hype from the reality, and enable CIOs and CEOs to decide whether or not a particular technology is ready for adoption. A longer-term historical perspective on such cycles can be found in the research of the economist Carlota Perez.

A hype cycle in Gartner’s interpretation comprises 5 steps:

“Technology Trigger” — The first phase of a hype cycle is the “technology trigger” or breakthrough, product launch or other event that generates significant press and interest.

“Peak of Inflated Expectations” — In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.

“Trough of Disillusionment” — Technologies enter the “trough of disillusionment” because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.

“Slope of Enlightenment” — Although the press may have stopped covering the technology, some businesses continue through the “slope of enlightenment” and experiment to understand the benefits and practical application of the technology.

“Plateau of Productivity” — A technology reaches the “plateau of productivity” as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market.

The term is now used more broadly in the marketing of new technologies.

We used the Gartner Hype Cycle in Two-Thirds of Our Readers Say CEP is Still Immature as a basis for having interested readers vote, and in a unscientific straw poll, the readers indicated that, in their view, CEP is still immature.

At the CEP Blog we ground our discussions and terminology on maturity in Gartner’s models on maturity, and we ground our discussions on event processing in the art-and-science of a long standing domain in event processing - multisensor data fusion (MSDF).

Their initial report last summer, which I blogged about at the time, was — almost entirely — rejected by the Government last autumn (blog article here).

The Committee decided that in the light of the Government’s antipathy they would hold a rapid follow-up inquiry to establish whether their conclusions were sound or whether the Government was right to turn them down, and indeed, given the speed of change on the Internet, whether their recommendations were still timely.

The written responses broadly endorsed the Committee’s recommendations, with the main areas of controversy being liability for software vendors, making the banks statutorily responsible for phishing/skimming fraud, and how such fraud should be reported.

There was one oral session where, to everyone’s surprise, two Government ministers turned up and were extremely conciliatory. Baroness Vadera (BERR) said that the report “was somewhat more interesting than our response” and Vernon Coaker (Home Office) apologised to the Committee “if they felt that our response was overdefensive” adding “the report that was produced by this Committee a few months ago now has actually helped drive the agenda forward and certainly the resubmission of evidence and the re-thinking that that has caused has also helped with respect to that. So may I apologise to all of you; it is no disrespect to the Committee or to any of the members.”

I got the impression that the ministers were more impressed with the Committee’s report than were the civil servants who had drafted the Government’s previous formal response. Just maybe, some of my comments made a difference?

Given this volte face, the Committee’s follow-up report is also conciliatory, whilst recognising that the new approach is very much in the “jam tomorrow” category — we will all have to wait to see if they deliver.

The report is still in favour of software vendor liability as a long term strategy to improving software security, and on a security breach notification law the report says “we hold to our view that data security breach notification legislation would have the twin impacts of increasing incentives on businesses to avoid data loss, and should a breach occur, giving individuals timely information so that they can reduce the risk to themselves“. The headlines have been about the data lost by the Government, but recent figures from the ICO show that private industry is doing pretty badly as well.

The report also revisits the recommendations relating to banking, reiterating the committee’s view that “the liability of banks for losses incurred by electronic fraud should be underpinned by legislation rather than by the Banking Code“. The reasoning is simple, the banks choose the security mechanisms and how much effort they put into detecting patterns of fraud, so they should stand the losses if these systems fail. Holding individuals liable for succumbing to ever more sophisticated attacks is neither fair, nor economically efficient. The Committee also remained concerned that where fraud does take place, reports are made to the banks, who then choose whether or not to forward them to the police. They describe this approach as “wholly unsatisfactory and that it risks undermining public trust in the police and the Internet“.

This is quite a short report, a mere 36 paragraphs, but comes bundled with the responses received, all of which from Ross Anderson and Nicholas Bohm, through to the Metropolitan Police and Symantec are well worth reading to understand more about a complex problem, yet one where we’re beginning to see the first glimmers of consensus as to how best to move forward.

The Rail Tram and Bus Union (RTBU) said today it was planning a 24-hour strike by rail workers on July 17, the busiest day of the Catholic event. It is the day Pope Benedict XVI will make his way through the streets of Sydney during the afternoon peak. The NSW Government will take the matter to the Australian Industrial Relations Commission (AIRC) tomorrow. Mr Iemma said his Government would not cave in to the RTBU. "The Government will not be blackmailed into giving them what they want as a result of these industrial terror tactics," he said.