Secure Coding Secrets?
Hi, Michael here.
A recent article titled "NSA posts secrets to writing secure code" caught my eye in part because the words "writing secure code" always get my attention! But also because anything that can advance the science of securing software is of interest to me.
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:
Directory of C:\tokeneer\data
18/08/2007 08:51 605,333 libgdk-win32-2.0-0.dll
18/08/2007 08:51 166,177 libgdk_pixbuf-2.0-0.dll
17/08/2007 18:07 642,115 libglib-2.0-0.dll
17/08/2007 18:07 28,853 libgmodule-2.0-0.dll
17/08/2007 18:07 223,026 libgobject-2.0-0.dll
18/08/2007 08:52 3,170,609 libgtk-win32-2.0-0.dll
08/08/2008 16:32 4,868,618 libgtkada-2.10.dll
07/04/2004 11:47 44,100 libintl-1.dll
17/08/2007 18:29 522,940 libcairo-2.dll
17/08/2007 18:36 262,784 libpango-1.0-0.dll
17/08/2007 18:36 62,334 libpangocairo-1.0-0.dll
17/08/2007 18:37 88,626 libpangowin32-1.0-0.dll
07/10/2001 01:52 171,008 libpng-3.dll
07/04/2004 11:46 58,077 libz.dll
07/04/2004 11:47 843,776 iconv.dll
17/08/2007 18:22 142,762 libatk-1.0-0.dll
16/01/2007 12:27 131,784 libjpeg6b.dll
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.
As usual, all comments are very welcome.
