Hash functions are the most commonly used cryptographic primitive, and the most poorly understood. You can think of them as fingerprint functions: They take an arbitrary long data stream and return a fixed length, and effectively unique, string. The security comes from the fact that while it's easy to generate the fingerprint from a file, it's infeasible to go the other way and generate a file given a fingerprint.

Originally created to make digital signatures more efficient, hashes are now used to secure the very fundamentals of our information infrastructure: in password logins, secure web connections, encryption key management, virus and malware scanning, and almost every cryptographic protocol in current use. Without cryptographic hash functions, the internet would simply not work. At the same time, there isn't a good theory of hash functions. Unlike encryption algorithms, there are no secret keys involved; this makes it harder to mathematically define exactly what hash functions are.

The National Institute of Standards and Technology, NIST, is holding a competition to replace the SHA family of hash functions. "SHA" stands for "Secure Hash Algorithm." It was developed by the NSA in 1993 to replace the commercial MD4 and MD5 algorithms, and has been updated several times since then. All the SHA algorithms are very similar, and have been increasingly under attack, so NIST wants to replace them.

The competition is important because, unlike other technological standards, committee design — balancing the interests of diverse constituents — isn't conducive to good security. Security is best when it's designed by expert teams and then subjected to public review. And cryptography is best when it's chosen by competition.

In 1997, NIST held a competition for a block cipher to replace DES. Fifteen candidates and three-and-a-half years later, Rijndael became the new Advanced Encryption Standard — AES. NIST is doing the same thing for what it's calling SHA-3 (not, for some unexplained reason, the Advanced Hash Standard or AHS).

The deadline was October 31, and NIST received 64 submissions. This isn't surprising — I predicted 80 — as most of the 15 AES submitters were professors, whose students at the time have become professors themselves, with their own students. (If NIST does a stream cipher competition in another ten years, they should expect about 256 submissions.) These submissions came from academia, from industry, and from hobbyists. CIO magazine recently interviewed one of the submitters, who is 15. Twenty-eight submissions have been made public by the submitters, and six of those have been broken.

NIST is going through all the submissions right now, making sure they are complete and proper. Their goal is to publish all accepted submissions by the end of November, in advance of the First Hash Function Candidate Conference, to be held in Belgium right after the Fast Software Encryption workshop in February.

The group expects to quickly make a first cut of algorithms — hopefully to about a dozen — and give the community a year of cryptanalysis before making a second cut in 2010. After another year of cryptanalysis, NIST will choose a winner in 2011. Expect a final standard by 2012.

My advice for software developers is to let the process run its course. While it's tempting to use the new cool algorithms in your designs, it's far too soon to trust any of them. This process is likely to result in all sorts of new research results in hash function security, and some real cryptanalytic surprises. Give the community a few years to figure out which ones are good and which aren't.

I've previously called this sort of thing a cryptographic demolition derby: The last one left standing wins. But that's only partially true. Certainly all the groups will spend the next few years trying to cryptanalyze each other, but in the end there will be a bunch of unbroken algorithms. NIST will select one based on performance and features.

NIST has stated that the goal of this process is not to choose the best standard but to choose a good standard. I think that's smart; in this process, the best is the enemy of the good. While there's no rush to choose a new standard — the SHA-2 algorithms will remain secure for the foreseeable future — we don't want to analyze the candidates forever.

Personally, I was part of a group of eight cryptographers that submitted Skein to the competition. A decade ago, writing Twofish and participating in the AES process was the most fun I had ever had in cryptography. These next few years promise to be even more fun.

---

Bruce Schneier is chief security technology officer of BT. His new book is Schneier on Security.

There is another reason why the article got my attention; my manager, Steve Lipner, is one of the few people to have designed and built a TCSEC A1 assured system and lived to tell the tale. None were sold, but they built one!

The NSA-directed project, the Tokeneer ID Station (TIS), involved building a low-defect system that conforms "to the Common Criteria requirements for Evaluation Assurance Level 5 (EAL5)" in a "cost effective manner." I'm all for this, because building high-assurance solutions is not cheap.

There's a paper with more technical detail about the project that is worth a read.

In my opinion, the project is only a science project, an experiment, for the following reasons:

• It's tiny. Weighing in at a little under 10 KLOC.
• It's only a very small portion of a much larger solution which has not been developed using the same rigor. This bit of context makes the solution as a whole moot. Call me cynical, but my question is "can the entire solution be built with same rigor in a ‘cost effective manner'?" Perhaps it can, but that is not what is presented.
• It sits on top of many operating systems (Windows, Mac OS X and Linux) that are not EAL5 certified. So it would be a little like having an EAL5 certified CharMap application running on EAL4 Windows Vista.
• It's written in a subset of Ada called SPARK, and SPARK skills are not common in the marketplace. Interestingly, SPARK makes use of annotations to help drive the static analysis process. While not a total analog, we also recommend Microsoft development teams use annotations (SAL) to help drive the required static analysis process.
• The application has a large number of dependencies that are not part of the project:

In the SDL we call these files ‘giblets' because they are components needed for your application to operate, but they do not belong to your team. Some of the files look old and highly vulnerable, such as libpng-3.dll from 2001! OSVDB lists 23 vulnerabilities since 2002 in libpng!

In summary, the TIS project is very interesting to a small number of important but specialized customers, such as the NSA, for whom this kind of research is critical. I too found it interesting, but the process is far from a set of "secrets to writing secure code" and the tools are certainly not within reach of day-to-day applications and not applicable to developing complete solutions.

First up is a code review quiz, “Test Your Security IQ”. Put your C/C++/C# security skills to the challenge by reviewing ten tricky code snippets that Michael and I devised. As an added incentive, I’ll post public congratulations here in the SDL blog to the first person who reverses the insecure hash found somewhere in the exam (not to give too much of a hint).

Next up, we have “Agile SDL: Streamline Security Practices for Agile Development”. I’ve been talking about web application security issues in the SDL blog (and in the September issue of MSDN magazine, if you missed it). However, while it’s essential to make sure that web-specific issues are covered in the SDL, it’s equally important to make sure that web development teams – and other Agile development teams – can use the SDL effectively, and the classic, phased SDL approach is not always a good fit for these teams. This MSDN article is the first public look at the new SDL/Agile methodology that we’ve been working on for the last year. This process is currently in beta with some internal Microsoft product teams and online services. We’d love to get some external feedback on it before we release it to the entire company, so please send us your thoughts.

Finally, be sure to check out Michael’s Security Briefs column “Threat Models Improve Your Security Process”. Regular readers of this blog know how important threat modeling is to secure development. This article describes methods of using threat modeling not just to identify security vulnerabilities outright, but how to use it to make other SDL activities such as fuzzing and reducing attack surface more effective.

Three articles are more than enough for one team for one month! But be on the lookout for more articles from the usual SDL suspects in the near future. As always, keep watching this space for details.

I’ve often read people who say that we (security, risk management) need to “think like the attacker”.  And when you read this sort of article, that usually alludes to trying to anticipate the tactics an attacker might use to mess with your C, I, or A.  Smart stuff, that, and very useful when architecting security solutions.  But as I was training some folks Monday, I was thinking in the back of my head about Threat Capability (TCap) in FAIR.  As you might know, we like to estimate the capability of a threat to apply some level of “force” against our assets.  This ability to apply force is a byproduct of the attacker’s skills and resources.  And thinking of how an attacker applies skills and resources, I came across another way we might “think” like an attacker.

Traditionally, I’ve thought of “skills” as being a byproduct of the toolset an attacker has.  This mindset probably stems from my time with Penetration Testing teams, where in the process of scoping the  PenTest I would ask our clients to select the level of effort that they wanted us to throw at them.  If a client chose “high” we’d throw every ‘spoit we had at them.  If they chose “low” we’d limit ourselves to a more commonly available toolset.

But while the resources part of TCap is time & materials (money) - the skills are really more than just the toolset.  Skills would include the ability of the attacker to be creative and innovative.    As an example of that innovation from those PenTesting days - when we got a “high” effort request, we would always try to couple that with some “social engineering”-type of attack, or some unique means of delivering an existing exploit.  Our creativity was not necessarily a byproduct of a unique exploit or tool we had, but the process by which we might deliver pre-existing or commonly available exploits.  I remember when we first got ahold of a handful of 32mb thumb drives (hey, 32mb was huge back then) and “dropped” a few in the lobby of a client’s retail space.  The keystroke loggers and phone-home script weren’t new, but using the thumb drive as delivery vehicle certainly was.

So I’ve started to really think about this concept of innovation, and how if “thinking like an attacker” means to be innovative, we ought to do the same.  I’ve been thinking of two main categories of innovation this morning.

INNOVATION

The first I’ll call Technology Innovation.  And by Technology Innovation, I mean some new, unique, “ahead of the curve” technology that an attacker can use against us.  The obvious example of which is a zero-day.  It’s that “high” tool set our PenTesters would use against the clients.  For security departments, this might be the latest security product designed to enhance our ability to P, D, and/or R.

Alternately, we can be creative in the way we deliver (manage) existing technology.  I think of this as Process Innovation.  It’s doing more with what we already have, just like the PenTest team would be creative in the delivery of an existing exploit.

Unfortunately for us - attackers have traditionally had quite a leg up on us in terms of Process Innovation.  It is much easier fro them to be creative, as they are free of political constraints and bureaucracy.  In contrast, when the security industry tries Process Innovation, the results are checklists and “standards”.  It’s committees and consensus.  An extreme example of which might be something like SABSA - a great work if you want to understand some very smart people’s comprehensive understanding of organizational security  - but the “adoption”of which will do very little to help you be innovative in P/D/R.

It’s worth noting that ultimately, this is one reason I don’t like regulatory compliance efforts - they simply serve to prove how mundane your security department is,  wasting valuable resources that could be spent on creating ways to be more effective.

PROCESS INNOVATION AS A SUBSTITUTE FOR TECHNOLOGY INNOVATION

As we come to the close of 2009, some surveys suggest that security spending isn’t horribly impacted yet by the economy (the latest from E&Y points to only 5% of their respondents getting budget cuts).  But if this is a protracted downturn, and because InfoSec is an operational expense, I would expect cash to become more and more difficult to keep.  And regardless if technology spends do slow, I believe it makes sense to think about Process Innovation because I see Process Innovation as a means to increase effectiveness without significant capital expenditures (effectiveness increases because our ability to manage risk has a direct correlation to the amount of risk we have).

The bad news is, of course, that great innovation is hard.  It is R & D.  Failure is usually a pre-requisite to success.

The good news is, our current state is so bad that many of us don’t need to come up with a whizbang new way of reducing software defects in the SDLC as innovation.  Simply inserting a risk analyst into the PMO’s processes might count as a big enough victory. Be cautioned, though,  that if we’re substituting the risk reductions provided by technology acquisition - Process Innovation might actually be even more “expensive” as it requires us to expend political capital.   But there are (forgive the term) innovative ways to spend this political capital.

For example, by taking a second now and figuring out the 3 things that the rest of the organization can do to make your life easier, when that “I need to reduce your budget” talk comes, you can be prepared to negotiate.  Get a political capital “loan” or “investment” from the C-Suite reducing your budget.  Something to the effect of: “I expected this, and am happy to give up my budget.  But if our tolerance for risk hasn’t changed, what I’d like to do is get you to personally back my office on three projects I’ve identified that can reduce our risk without requiring significant capital expenditure.”

The best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.

Setting the context for this post, it is a tough economic situation all over the world. IT spending has reduced and will reduce significantly. In one of earlier posts, I had referred to information security as an overhead of an overhead (IT). What is a good approach for security practice in this type of economy?

I don't have a magic wand to pull a rabbit out of a hat. I have always been told that: tough economy is the time for real smart people to make money. Coming back to information security topic, with a bit of common sense, it is wise for information security professionals to offer services in those areas that does not involve capital expenditure. As a Security Manager, you may be already aware that your people are willing to go an extra mile in the current economic times.

- No budget or lack of budget, means no new capital expenditure. Spend time wisely in building a future technology strategy and keep it in the back pocket when the economy turns around.

- This is a good time to create roles/responsibilities and ownership for various areas. Create operating procedures. Make your team to automate tasks. This will help your operations become more efficient.

- This is time for security awareness  education. Create pamphlets/brochures/presentations for an online or classroom training. Engage your and your team's time to impart training.

- Leverage already invested technology platforms. Leverage utilized features that reduce costs. If you have already invested in technology such as VMware, this is the time to get the best out of it. You can use VMware's toolkit to build your lab and staging environment and optimize on hardware cost.

- Off shoring has been the mantra of senior executives, this is the time to revisit those services and measure their performance closely and assess your satisfaction level. This is a good time to build a case for not off shoring if it makes sense.

- Companies are more vulnerable in bad economic times. You are in a better position to influence senior management about information security risks under these circumstances and drive home the value of protecting your intellectual property under these kinds of circumstances. management will be all ears for such a pitch.

- Time to engage your architect to optimize your security architecture, revisit standards and optimize design for cost efficiency.

- Revisit various controls and see if there are some risks that you could optimize spending on.

- Training budget is an unfortunate victim of this type of economy. Encourage employees to take free webinars offered by various security vendors and encourage them to share the summary across the team. This will put your employees in touch with latest happenings in security at the same time there is some learning that is imparted despite zero training budget.

- Since there are very few projects in action, this is a good time to have conversations with cross functional teams and educate them about your services and solicit feedback on how to do better.

- Revisit your vendor logistics and identify whether you can renegotiate some of your already existing contracts.

The above are some good ways by which you can optimize costs, this will also enhance your team's competence level in the long run. And this approach is better than letting people go, if you can pull this.