Errata: Version 1.1 of the paper, reference, and optimized code corrects an error in which the length of the configuration string was passed in as the size of the internal block (256 bits for Skein-256, 512 for Skein-512, and 1024 for Skein-1024), instead of a constant 256 bits for all three sizes. This error has no cryptographic significance, but affected the test vectors and the initialization values. The revised code also fixes a bug in the MAC mode key processing. This bug does not affect the NIST submission in any way.

NIST has received 64 submissions. (This article interviews one of the submitters, who is fifteen.) Of those, 28 are public and six have been broken. NIST is going through the submissions right now, making sure they are complete and proper. Their goal is to publish the accepted submissions by the end of the month, in advance of the Third Cryptographic Hash Workshop to be held in Belgium right after FSE in February. They expect to quickly make a first cut of algorithms -- hopefully to about a dozen -- and then give the community about a year of cryptanalysis before making a second cut in 2010.

Lastly, this is a really nice article on Skein.

These submissions make some accommodation to the Core 2 processor. They operate in "little-endian" mode (a quirk of the Intel-like processors that reads some bytes in reverse order). They also allow a large file to be broken into chunks to split the work across multiple processors.

However, virtually all of the contest submissions share the performance problem mentioned above. The logic they use won't optimally fit within the constraints of a Intel Core 2 processor. Most will perform as bad or worse than the existing SHA-1 algorithm.

One exception to this is Skein, created by several well-known cryptographers and noted pundit Bruce Schneier. It was designed specifically to exploit all three of the Core 2 execution units and to run at a full 64-bits. This gives it roughly four to 10 times the logic density of competing submissions.

This is what I meant by the Matrix quote above. They didn't bend the spoon; they bent the crypto algorithm. They moved the logic operations around in a way that wouldn't weaken the crypto, but would strengthen its speed on the Intel Core 2.

In their paper (PDF), the authors of Skein express surprise that a custom silicon ASIC implementation is not any faster than the software implementation. They shouldn't be surprised. Every time you can redefine a problem to run optimally in software, you will reach the same speeds you get with optimized ASIC hardware. The reason software has a reputation of being slow is because people don't redefine the original problem.

That's exactly what we were trying to do.

The CISSP is undoubtably one of the most, if not the most, important professional certifications in Information Security. Many organizations and practitioners rely on it as evidence of a solid foundation and track record in Information Security. But the CISSP is only one of the many ways that the (ISC)² attempts to fulfill its mission of developing the Information Security profession.

Board membership is a role of governance, guidance, and passion. Let’s briefly explore how Dan’s track record and past contributions demonstrate his qualification for this post, and possibly your vote.

Passion

Dan is someone who has a passion for promoting and developing the talent needed to continue to grow and mature our profession. Anyone who has seen Dan speak at conferences, local chapter meetings, or in one of his classes knows how passionate Dan is! But anyone who takes the time to approach him knows that he is no ideologue or zealot; Dan is always interested in improving his own understanding, and then sharing that knowledge with others.

Dan has a long track record as a contributor - as a “giver” - to the profession. In addition to teaching over a dozen CISSP review courses, he has also served on multiple (ISC)² committees, is one of the authors of the ISSAP Body of Knowledge (cryptography), and has published primary research on professional certifications. He is also the founder of the monthly Columbus, Ohio Information Security MBA (Masters of Beer Appreciation) meeting - a professional roundtable that attracts practitioners from across the state.

Governance and Guidance 

In addition to past experience serving on (ISC)² committees, which I assume led to the current board’s nomination, Dan has served on numerous Boards of Directors including local and regional community organizations, ISSA chapters,and several Toastmasters clubs. 

Personal Experiences

I have known Dan for almost three yeas. Dan and I have collaborated on a number or projects, including a half-day Cryptographic Controls Seminar and a full-day Identity Management Architecture class. It is my feeling that when you collaborate, work closely, and travel with someone, you really get to know them. You get to do more than hear about their College Sweethearts (which, for Dan, is Rebecca, his wife of 21 years), but you also get to understand their ethics, how they really conduct themselves, how they deal with stress, etc.

Given the entire picture, the understanding that I have of Dan Houser, I can think of no one better suited to representing, guiding and developing the (ISC)². I have voted for Dan, and I hope that you will consider doing the same.

Here is the voting link for (ISC)²: https://webportal.isc2.org/custom/votenow.aspx

Cheers, Erik

CISSPs… Lend me your ears…

I find that legacy code poses a unique challenge for organizations rolling out a new security process.  Often, the resources dedicated to maintaining older code are a small fraction of those devoted to new features or products.  Furthermore, the original developers for such features have often moved on, leaving no subject matter experts to drive reviews.  The astute reader will ask “How do I apply the principles of the Microsoft SDL to legacy code when I have no development resources and nobody knows how it works?”

The answer is “Start small, and build expertise over time.”

A Rising Tide Lifts All Boats

The best thing a security engineering team can do to improve security in the short term is to drive code quality, and the first step in this process is to define and enforce a secure coding standard.  This helps on two fronts: 

1.       It will improve code quality and reduce implementation flaws across the entire code base.  Unlike other security processes, driving a secure coding standard is relatively easy to accomplish across an entire code base, regardless of the code’s age, by a focused security team.  That is not to say that it is easy without qualification – a large batch of spaghetti code will require a lot of work to untangle!  Such an effort can only be called “easy” when compared to, say, comprehensive identification and remediation of design flaws across legacy features.  Even so, improving code quality through the use of secure coding standards offers a unique combination of high impact, applicability to features, and ability to be carried out by a core team that makes it a sensible first step.

2.       The security team might notice that some sections of code have more standards violations or outright flaws than others.  This is an instance of vulnerability clustering, a concept that has been used to predict vulnerability rates and improve quality in the functional realm.  The evidence is anecdotal, but it stands to reason that portions of code that consistently violate secure coding standards are good places to start looking for other classes of security flaw.  These are security hotspots, and should be high on the prioritized list for further review.

Security testing may also be applied to legacy code, but initial activities should be considered on a case-by-case basis based on the expected return on investment.  Such testing ranges from using inexpensive off-the-shelf tools to exercise common interfaces to rather expensive custom testing and formal analysis.  It is worthwhile to begin with off-the-shelf tools, such as those that target file parsers or web applications, and tools created as part of your greater secure development efforts.  These can help identify easily-found flaws and suggest improvements to the coding standards.  Comprehensive security testing, on the other hand, is best tackled after the Legacy Security Push.

The Legacy Security Push

Coding standards and basic testing provide bang for the buck, but formal security processes seek to provide security assurance.  The challenge for legacy code is that it needs to play catch-up.  Security processes that occur early in the development cycle, such as requirements analysis, design review, and threat modeling, are particularly difficult to achieve years after the fact.  The main goal of the Legacy Security Push is to create the deliverables from these efforts, the most important of which are security requirements and a full risk analysis.

It may sound trivial, but security requirements are essential.  Not only do they define proper operation for the system in question, they also define assumptions that are suitable for relying systems.   It is very common to find security flaws in legacy systems that arise from well-intentioned but incorrect assumptions such as “I assume that the Foo authenticates server Bar when initiating a bank transfer.”  It stands to reason that Foo would do so for such an important activity, but this assumption must be validated.  It is very common for older features to have been deployed in and written for different environments where the security assumptions that are "obvious" today just didn't apply at the time.

When reviewing legacy systems, the first step is to identify such requirements.  If the original architects, developers or managers are available, they can provide valuable insight at this stage.  More often than not this is not the case, and analysis must instead rely on what documentation is present and interaction between the software and its consumers.  The goal is the same as in requirements analysis during project inception, except that in this case one must turn the process on its head and reverse engineer requirements from system behavior.  At the conclusion of this effort, requirements can be theorized – “Foo must authenticate its server Bar before initiating a bank transfer.” 

Risk analysis can be performed once a plausible set of requirements have been identified.  Threat modeling is a more structured means of performing such an analysis, with the eventual goal of identifying means by which requirements can be violated by an attacker. 

As with requirements analysis, original developers would be a valuable resource to consult.  With or without such help, the first step is to identify how the software works.  In many cases, help is not available and performing this task requires a great deal of effort.  For features of moderate size, this author has spent upwards of a month reading code, using process profiling tools, and walking through the software with a debugger to identify program flow and security-sensitive functionality.

Once completed, actual system behavior should be documented and compared against the requirements theorized.   It might be that the requirements should be re-evaluated (New requirement:  Do not assume that Foo requires server authentication) or the system may need to be changed (New bug:   Foo does not verify the CN for Bar).  At the end, this information should be sufficient to support a comprehensive threat modeling exercise where security requirements, risks, and their mitigations can be documented.

Next Steps

Bringing a legacy feature up to par with its newer kin requires a relatively small number of items:  improved code quality, clear security requirements, and a thorough threat model.  As we have seen, performing even these tasks is quite the effort!  I am sure that it is little comfort to be reminded that accomplishing these tasks has simply laid the foundation, and that the true benefit is that the newly-reviewed legacy feature is able to participate fully in the security processes that remain: reviewing cross-component security requirements and assumptions, comprehensive testing, and incident planning, to name a few.

Unfortunately, there is no silver bullet in security assurance.  The soundness of the design and implementation of legacy software is just as important as in newer software, which is why any complete secure software development process will look backwards as well as forwards.  Feature by feature, from higher priority to lower, the overall security of the software improves as legacy code receives the full security treatment it deserves.

Lord Broers, the Committee Chairman during the first inquiry, kicked things off, followed by various Lords who had sat on the Committee (and two others who hadn’t) then the opposition lead, Viscount Bridgeman, who put his party’s point of view (of which more in another article). Lord Brett (recently elevated to a Lord in Waiting — ie a whip), then replied to the debate and finally Lord Broers summarised and formally moved the “take note” motion which, as is custom and practice, the Lords then consented to nem con.

The Government speech in such a debate is partially pre-written, and should then consist of a series of responses to the various issues raised and answers to the questions put in the previous speeches. The Minister himself doesn’t write any of this, that’s done by civil servants from his department, sitting in a special “box” at the end of the chamber behind him.

However, since the previous speeches were so strongly critical of the Government’s position, and so many questions were put as to what was to be done next, I was able to see from my excellent vantage point (as TV viewers would never be able to) the almost constant flow of hastily scribbled notes from the box to the Minister — including one note that went to Lord Broers, due to an addressing error by the scribblers!

The result of this barrage of material was that Lord Brett ended up with so many bits of paper that he completely gave up trying to juggle them, read out just one, and promised to write to everyone concerned with the rest of the ripostes.

Of course it didn’t help that he’d only been in the job for five days and this was his first day at the dispatch box. But the number of issues he had to address would almost certainly have flummoxed a five-year veteran as well.

Amusing though this might be to watch, this does not bode well for the Government getting to grips with the issues raised in the reports. In technical areas such as “Personal Internet Security”, policy is almost entirely driven by the civil servants and not by the politicians.

So it is particularly disappointing that the pre-written parts of the Minister’s speech — the issues that the civil servants expected to come up and which they felt positive about addressing — were only a small proportion of the issues that were actually addressed in the debate.

It still seems as if the penny hasn’t dropped in Whitehall

John talked about Microsoft’s mission, his perspectives on key industry trends and market opportunity; he touched on Cloud Computing and Virtualization and took some Q&A from the audience of Managed Service Provider executives.

One of his first proclamations - Microsoft has really embraced the heterogeneous environment. Really? How in the world is Microsoft going to help convince IT line managers, or mid level managers to believe this statement? I think they have a long way to go to achieve this vision with any credibility in the marketplace.  I do know that they are making small strides.

Microsoft has been widely credited with some very good blogs that are self critical and introspective. They have also been quite active in the standards boards within DMTF and many others such as Open WSMAN and CIMON (Open Pegasus). Microsoft in February published 30,000 pages detailed technical specifications – protocol documentation for Exchange, since that time they have published another 15,000 pages. They have had over 224,000 downloads since February 21, 2008. Thus they are trying to be more open by making some of these secret sauce protocol resources directly available on the web.

So for now, I will take a very cautious wait and see approach to this proclamation. Time will tell.

Trends

• Rapid growth continues
• Hosting Competition has a new face
  • Platform gorillas (amazooglesoft)
  • Ad supported Web 2.0 hosters (Google, Facebook,)
• Utility Cloud Computing models are expanding to non-traditional hosting companies
  • Wells Fargo vSafe - hard to believe that a big bank would start to offer a SaaS offering
  • New tools and markets digital ribbon, CohesiveIT

IDC Data shows that growth of SaaS ISV’s is the biggest layer of growth. The fastest growing services are complex, custom applications. IDC says this area will be bigger than the hosting area in the next 5 years. John said that Microsoft is spending a lot of time, money and energy on this right now.

John said:

“when Microsoft thinks about the building blocks that make-up the cloud, virtualization is a core piece of the puzzle. However you also need also identity services, Operating system with standard set of libraries to tap into… or remote storage that application developers will tap into.. Developers will consume these set of services, but you will also need a set of tools to manage your physical, virtual and geographically distributed datacenter infrastructure.” (that is where ScienceLogic comes in!!)

He went on to say,

“In some ways, virtualization enables decentralization – allows you to move from data centers, enables fast scaling out, business to move from on premise to the cloud and off again…. Automation is very important – this will help you scale your business – this is core to your future success.”

He talked about a new breed of knowledge worker: He called them Digital Natives (compared to grey haired guys like me who are left out of this category).

Definition of a Digital natives? A young adult who has grown up with cellphone, web based applications, Facebook account, as their primary mode of communications.

John commented that we are 5 years into a 10 year journey. Only 12% of all servers in the world are virtualized today… in the next 4 years it will double to 25%. This is the time to think through how this business will affect you.

‘Virtualization without good management is more dangerous than not using virtualization in the first place.” Thomas Bittman, Analyst Gartner

Patching and provisioning nightmare – no scalable administration – sprawl chaos.

John posed a question to the audience: How do you partner to provide the ISV support in application development with specific market needs… partner by keeping the hosting to SaaS solution providers up and running and provide the quality of service that their customers expect…. Complimentary services of storage and backup is a big win with a huge market-upside over the next 5 years..

John said that Microsoft continues to make  huge investments with Managed Service Providers.

• Investing in the windows hosting platform
• Hyper V and SQL2008 GoLive program - getting beta code out to service provides to find as many bugs as early as possible.
• Software + Services (S+S) incubation center program
• Partnering for cloud platform market offers
• Cloud platform guidance and best practices

During the Q&A, David Burns from Cincinnati Bell asked the very best question… “when are you going to make it easier for the Service Provider market to deal with the Microsoft Service Provider Licensing Agreement (SPLA) quarterly statistics pull and change the SPLA pricing to be more efficient and creative for the new Virtualization and Cloud offerings you have talked about?”

John’s response: “We hear your frustrations loud and clear and are working on some new ideas for the future version of SPLA.” My interpretation – “Dear Service Providers don’t expect anything new or easier to deal with in the next 6 months!”

His closing remarks: “Cloud is evolving = very early stages, lots of hype, but think of how this evolution will effect your business and how you can plug into it.”

• Provide a government I.D. number for verification of your identity.
• Set up custom security questions and answers, further safeguarding your domain assets.
• Provide special verification instructions and artifacts to ensure that your unique business or ownership interests are protected.
• When you request that your domains be unlocked, our security team works directly with you to verify all of the above off-line - further eliminating risks of doing business in an online world!

Turns out a Petabyte is 1000 Terbytes. So Google processes over 20,000 Terabytes of data per day. Supporting all of this impossibly massive data crunching is a huge network of proprietary servers and custom made storage. It's the mythical Google grid.

Google conceals the exact nature of the grid; it's one of their trade secrets.

So, what if I told you Google is abandoning its mythical, proprietary, custom-made processing and storage grid, and is moving to an off-the-shelf third party processing platform?

Any boffin would have choked on this scoop.

OK, relax. Google isn't ditching its proprietary grid. But its eCrime equivalent is certainly doing exactly that.