Hello, I’m Charles and I’m the new Quality Engineer at TrustBearer. TrustBearer brought me on keep the company on track to meet its quality goals. Some of these goals were already being implemented when I got here: unit tests, code reviews, good defect tracking, code documentation. For my part, I tend to focus on system level testing, including functional and non-functional testing (security, performance, etc.), as well as developing a more solid and repeatable testing process. With this in mind, I’ll going to discuss the testing and quality assurance work we do at TrustBearer to ensure that our products work well and are secure. I’ll also focus on some of my personal philosophy with regards to testing.
My philosophy boils down to the idea that no program can be fully tested, and that a tester, or testing team, should focus on the ROI for their time. A lot of this philosophy has been developed from discussions with and readings from other professionals in the field such as Cem Kaner, James Bach, and Michael Kelly, including the idea of Context-Driven Testing. Some of my ideas also come from one or both of the organizations I belong to, the Association for Software Testing (AST) and the Indianapolis Workshops on Software Testing (IWST).
Now, how does this philosophy apply to TrustBearer products? Well, if we look at our website at the TrustBearer Desktop page, we list our compatibility for various smart cards, OSes, and mention other technologies we are compatible with. Just looking at the page tells me that there is a good number of combinations of OSes, browsers, smart cards, and mail programs that need to be tested, and that ignores any external factors (other USB devices that are used by the customer causing problems with our system, for an example).
So if it’s impractical to test everything all of the time, what is tested? There is no one correct answer, however, a good tactic to take focuses on defining the problem space. For me, this involves finding the typical configurations first. When I say a typical configuration for TrustBearer products, I mean this in regards to what our software interacts with. We can never fully replicate what our customers will have in terms of hardware and software, but we can have a reasonable approximation. For instance, if most of our customers are using PIV cards with Windows 7 as their OS, Firefox 3.5.6 as their web browser, and Outlook 2007 as their mail program, then my tests are run primarily using that as a base configuration.
Another good way to focus what is tested is to look at what features are used the most, and in what ways. For a good example of this, our software products facilitate the use of hardware and software tokens for things like windows logon, email signing and encryption, signing Word and PDF documents, as well as interacting with various websites. While we test all of these features, initial testing would focus on what our customers typically used our software for most.
Another generally good method of testing is focusing on high-risk areas. For some applications, this might be the billing system, or the login system, neither of which you want to find any serious defects in). For TrustBearer, this focus tends to fall on security testing. For instance, sometimes we develop web pages for customers that work with our TrustBearer Live Plugin, and we run tests simulating SQL Injection, phishing, and man-in-the-middle attacks to make sure that our customer’s data can’t be exposed to anyone untrustworthy.
Using these techniques as a base, we go on to test more and more features and platform combinations. The goal being that we have confidence that any bugs we have not found are minor, obscure, and will not cause problems for our customers. As with everything else in software, this is never a finished process, but with a good philosophy and a dedicated team, quality improves with every revision.
While that isn’t all there is to testing, I hope that the above gives you a little glimpse into the process, and hopefully I’ll be able to share more of the process of testing, tools we use, and how we determine when we’re ‘finished’.
Today, googling for ISO/IEC 24727 returns ~5000 results. The first four are links to purchase the standard specifications from either the ISO or IEC webstore. The fifth, ISO/IEC 24727 – A Future Standard for Smart Card Middleware, looked like a simple description of the standard, maybe distilled for a broader audience… But, it’s actually a paper about the standard on sale for $25! Perhaps this lack of free information was part of the reason NIST decided to hold a workshop all about the standard this past week.
I attended NIST’s Tutorial Workshop on ISO/IEC 24727 (Identification Cards – Integrated Circuit Card Programming Interfaces). It lasted a few days and it covered a ton of information about this 6-part standard. The workshop speakers included several editors of the standard, including Tim Jurgensen, Mike Neumann and Alex Gagel, as well as representatives from NIST who have also been working with 24727 in various capacities: Terry Schwarzhoff, Bill MacGregor, and Sal Francomacaro. Ketan Mehta & Hung Dang from Booz Allen Hamilton and Alexander Winnen from Giesecke & Devrient gave technical demonstrations of the standard in-action. Alex Gagel also detailed the first substantial use of the standard for the Queensland, AUS Driver license.
Outside of NIST, it seems that there has been little involvement from United States companies in developing 24727. Perhaps that is part of the reason why there is not a ton of information available online. This post explores 24727 from a U.S. smart card standards perspective. If you’re familiar with CAC and PIV, but are just hearing about 24727, I hope this helps.
Some Background – HSPD-12 & PIV
ISO/IEC 24272 is a bold attempt to make identity credentials (such as smart cards) and the applications that consume those credentials much more interoperable than they are today. Wait, isn’t that what PIV was supposed to do? Sort of, but 24727 goes much further in its interoperability goals. On the technical interoperability side, PIV defined a smart card edge (API), data model (to store the cardholder’s name, ID#, photograph, etc.), and required cryptographic capabilities. FIPS 201 (Titled Personal Identity Verification of Federal Employees and Contractors or ”PIV” for short) tackled much more than just the technical specifications of the smart card. It also defined the physical card look and feel of the card, standardized the identity vetting procedures, and provided use cases for physical and logical access.
The goals of 24727 are slightly different than the U.S. Government’s goals with PIV. FIPS 201 / PIV was created in response to HSPD-12 – a request from former President G.W. Bush to create an identity standard for all federal employees and contractors. NIST answered the call and developed the FIPS 201 specification in 6 months – a very short amount of time for a standard encompassing many identity concepts. PIV defined a single smart card standard that enabled many different hardware and software manufacturers to create compatible products. This has had an enormously positive impact for the adoption of identity smart cards and related products in the U.S. Government. PIV was also a huge boost TrustBearer’s industry. Now, state & local governments and private companies are starting to take advantage of this federal government investment. See the CIO Council’s PIV-Interoperable document.
The scope of the PIV specification was deliberately limited to address the requests in HSPD-12. PIV defined a smart card application for usage, but not for card personalization. PIV also defined a very specific card data model intended to store information that would be helpful to identify federal employees and contractors. Organizations outside the federal government are now trying to adopt PIV, but are finding that these deliberate limitations make PIV a less flexible identity standard. Consider healthcare: PIV does not define nor provide a way to extend the data model to record clinical information like allergies or medications on the card.
A More Flexible Identity Credential Standard
As Mike Neumann mentions in his presentation from earlier this year,
ISO/IEC 24727 is a framework for interoperable IAS [Identification, Authentication, Signature] systems.
It provides abstraction at every level of an IAS system, including the card data model & associated security model, card administration, communication protocols, and authentication protocols. Even the testing section was developed to be completely extensible. When these concepts and this image were first presented, I was a bit overwhelmed.
This was such a leap beyond what PIV and CAC tried to accomplish that I really needed those few days to digest the breadth of the 24727 standard. I like to think about it this way – 24727 gives
communication protocol capabilities (e.g. APDU, TLS)
for use by
Card middleware providers (e.g. TrustBearer), and ultimately
Client applications (e.g. Windows, Custom smart card viewer, Web services)
Before this standard, there were always some functionality limitations in layers between these components. By functionality limitations I mean that layer x (e.g. application) could not access (or didn’t know how to access) a feature in layer y (e.g. specific data container on card). To pick on one at a relatively high level, consider PKCS#11, commonly used in non-Microsoft browsers and Email clients. PKCS#11 allows client applications to use digital certificates and keys stored in a variety of locations – usually in software or hardware (smart cards). Smart card middleware vendors provide PKCS#11 modules to communicate with the smart cards that they support. PKCS#11 allows for a single PIN or passphrase to be entered, typically to gain access to use a private key located on a smart card. But what if different PINs are used for different keys or different operations on those keys (e.g. signing v. authentication)? PKCS#11 doesn’t support it.
To borrow another description from Mike’s presentation, he describes two approaches to previous standards / specs:
“client-down”, e.g.
PKCS#11 – general, but uncoordinated across API
CSP – Single function of a single application view
“card-up”, e.g.
All of ISO/IEC 7816 series
(Nearly?) all middleware based on ISO/IEC 7816
ISO/IEC 24727 is the first series of standards to be designed with both in mind.
This is a helpful way to start to get a feeling for the scope of 24727.
6 Parts
24727 is divided into six parts (and ISO & IEC will be happy to take your money to download each one).
Part 1: Architecture – The diagram you saw above, plus some more detail; The shortest of all parts
Part 2: Generic Card Interface (GCI) – Provides a well-defined syntax to describe any card’s data model, security model (Access Control Lists), and capabilities; Allows middleware to talk to a card without knowing the specific card edge commands
Part 3: Application Programming Interface (API) – Provides a well-defined syntax for client applications to communicate with the GCI; Apps can discover data on cards they’ve never seen previously
Part 4: API Administration – Used for secure communication to the card and lifecycle management; This was added as a new work item while developing the spec; It addresses end-to-end security, connectivity, secure messaging, stack configuration & use, and interface devices (IFD)
Part 5: Testing – Baked in from the beginning, there’s a model and test script to help prove compliance with the parts that your product claims to implement
Part 6: Register Authentication Protocols (AP) – A maintained list of commonly used authentication protocols, such as internal authenticate and external authenticate; Industries will need their own domain-specific APs, and this allows them to register specific APs to share with others. (See PIV for PACS or MR-PIV and PLAID for examples of a newly proposed APs that could be brought into this part of 24727 someday)
I am just scratching the surface here. Each of these parts could be another post on its own. There are some really interesting concepts introduced in the details. Such as the Part 2 translation scripts – this is where the conversion from a card protocol, like APDUs and the Part 3 API is made. In some cases, a card could actually store ISO 20060 bytecode that describes its data model and supported functions. Middleware could then download and run this bytecode to make these translations in real-time. This is, of course, for new cards that adopt the standard at the card level.
Transition from Existing Applications and Cards
While it would be great if every opportunity out there was a greenfield, like the Queensland Driver’s License project, there are many well-established identity programs with cards already in use, such as CAC and PIV. 24727 can be adopted at various parts. NIST gave a demo at the workshop of a 24727 Reference Implementation for PIV smart cards. Ketan Mehta and Hung Dang implemented parts 2 and 3 and hooked this up to a Cryptographic Service Provider (CSP) on Windows to demonstrate smart card logon. They also connected a PKCS#11 module on both Windows and Linux to their 24727 ref imp to demonstrate email signing on both operating systems and smart card logon using PAM on Linux. All of this was accomplished without modifying the actual PIV card at all.
During the wrap-up on the last day, Bill MacGregor said this ability to work with existing, deployed tokens was one of his two top benefits of 24727. The other was the identity abstraction layer in part 3, which provides a tool to think about digital identities and tokens that we have not had in the past. There are no promises that the next revision of FIPS 201 / PIV will utilize 24727, but I believe it is being considered as a possibility to extend the current PIV standard while remaining backwards compatible with existing PIV & CAC cards.
Generic Identity Command Set (GICS)
We had a Q&A session on the last day of the workshop, and I asked about GICS, which is yet another smart card technical specification that primarily came from industry (INCITS B10.12). This presentation from Oberthur at CTST this year gives a helpful background and details about the in-progress spec. The motivations behind developing GICS are interesting. The presentation starts out by listing all the government endorsed standards released over the years: GSC-IS 2.0, 2.1, PIV’s SP 800-73, 800-73-1, then 24727. Then it follows with the statement that this costs industry a lot of money to make products that comply with these changing standards, but there’s not much ROI from deploying these changes in the market.
Summer 2006: Using experiences from the development of PIV products, a group of smart card technical experts from the industry decided to work together to define a stable generic card command set that would piggyback on the PIV End Point card edge developed by NIST, but extend its reach outside of the Government area, to extend the market.
GICS is a proposal from the smart card industry to preserve the existing investments of PIV, TWIC, etc. and address the needs for greater interoperability for new card applications other than PIV (or maybe those that have derived from PIV). GICS introduces a standard card command set, not a new card application command set.
You can see the full list of expected benefits in the presentation, but essentially GICS is trying to standardize an extensible smart card command set for identity cards so that when a card or applet vendor makes an investment to develop products that comply with this command set, the market for these products is much larger than it would be for a specific command set (e.g. PIV). Certification (like FIPS 140) could be performed on a single GICS card / applet one time rather than an a card/applet for each different identity specification.
The technical characteristics in GICS cover a wide range of capabilities found in modern smart cards: Data objects, parser, templates, tag lists, and even On-Card fingerprint verification. It also includes a set of common Authentication Protocols and allows that list to be extended.
Sounds a lot like 24727, right?
While it does have some similar goals in extensibility and interoperability, GICS does not go nearly as far as 24727. It sticks to smart cards and APDUs. It builds atop PIV to allow for PIV Interoperable and PIV compatible specs to be invented and implemented without requiring yet another applet that needs to be certified. It stays within the smart card middleware world that we know today. At the conference Mike Neumann said that 24727 and GICS work together. From his presentation that I referenced earlier, “ISO/IEC 24727 defines the system interfaces; GICS defines the card commands.”
Opinion
My goal in attending the workshop last week was to learn about ISO/IEC 24727 and understand how it affects TrustBearer’s business. Among other things, we provide middleware software that allows all kinds of applications and devices take advantage of high assurance identity credentials like smart cards. Technical identity standards like PIV and ISO 24727 often indicate that there will be a market for the types of products that we build.
24727 is the first attempt I’ve seen at taking a brand-new look at how identity credentials and systems could be made much more interoperable. This is an extremely extensible specification. Data and security models can be discovered. The communication protocols can evolve – imagine not needing to know what an APDU evenis! From a technical perspective, these concepts and the proposed architecture are very impressive. But the level of abstractions introduced in this specification couldn’t help but remind me of Spolsky’s posts on architectureastronauts.
Does 24727 have too much abstraction? Is there really a market demand for the concepts introduced in this standard? That is the top question in my mind. It was helpful to hear from Alex Gagel, one of the lead architects on the Australian Queensland Smart Driver’s License project. That smart card project is clearly the largest and most thorough implementation of 24727 to date. Alex and his team are such early adopters of the standard that they are the editors for parts 5 (Testing) and 6 (AP Register) of the standard. This FAQ states that the European Union Citizens Card, German Smart ID Card and German Electronic Health Card will also be adopting 24727, but to what degree I am not sure.
Is GICS a more practical step in the right direction? I can say that from a middleware and card application provider perspective, GICS has a more well-defined scope and short-term value proposition for the U.S. ID credential market. GICS has the luxury of building on top of an existing standard (PIV) and it’s scope us much more narrow than 24727. Is GICS itself sufficient for the next 5 years?
<ISO/IEC $$$ rant> I do not have all the information on why ISO and IEC charge money to download their specifications, but coming from the technology / Web 2.0 industry, where companies are dying to give away their API documentation in order to drive adoption… I don’t get it. How does charging anywhere from $95 USD to $245 USD for each part of the 24727 specification encourage the world to adopt this interoperability specification? It just doesn’t make any sense to me. </rant>
**COUPON: On that topic, we were informed at the workshop that ANSI has an agreement with ISO/IEC to sell each part of the 24727 spec for $30 USD. Access the ANSI eStandards Store and search for 24727 to see each part – the discounted ones are at the bottom.
TrustBearer will be keeping an eye on the adoption of 24727. Until we see a significant demand coming from our existing customers and focus markets, we will probably not begin to adopt these concepts in our software. That said, I would like to hear the opinions of others who stumbled across this article. Is 24727 affecting development of your products today? And for those in charge of identity programs, will 24727 be a cornerstone of your next ID credential? Please email me or leave a comment.
Presentation References
NIST said that all the presentations from the workshop should be eventually published online. For now, I’ll embed the two that I found very helpful when writing this article.
Here at TrustBearer, we’re working on reworking the underlying pieces of our software to provide services which are required for full treatment of internationalization issues from cultural sensitivity to language translation. Fitting such an infrastructure onto a vast existing system of hardcoded, interlinked modules which span multiple (programming) languages and techniques on several platforms is a challenge, but we have come a long way to eventually realizing the goal of true international support.
Issues of Internationalization
The most obvious issue of internationalization is the language in which the user interface is presented; if your audience only speaks French, or perhaps just as importantly prefers to speak French, then you need to offer a user interface in French. Secondary issues can carry much more subconscious weight, however: as individual cultures have risen and separated from one-another across the planet, even in the age of international commerce and communication that the Internet conveys, specific communities still carry important symbols, ideas, and values which are intrinsically and uniquely their own.
The meaning of colors varies from one society to another, as does the importance of iconography. For example, the dagger (†) bears similarity to the Christian cross (which it should, since that was part of the original meaning conveyed in its use) and should be used carefully, even in purely typographical meaning, to avoid unintentional religious connotations. This sort of care is often given nary a second thought by those responsible for internationalization strategy, and it’s important to address it just as evenly as one addresses language. On the subject of translation, there are many things which carry over along with the baggage of verbal communication: formality, dialect, the hints and subtleties that individual words carry both inside and outside of specific contexts, all of these come into play with deciding on a technique for providing the infrastructure with which to provide international support for a software system.
Implementations
There are four fundamental systems in TrustBearer’s overall product ecosystem: the web plugin with dynamic device support, the browser, static web content, and the server. We have chosen to implement three components which satisfy the translation needs of all four pieces.
Plugin, Device Support, and JavaScript
We implement dynamic translation features in the plugin as a module, which is loaded at run-time just like device support is. In this way we offer the ability to switch languages in real-time. It also gives us the luxury to download translations from a server where they can be modified on the fly without the need for any kind of recompilation or redistribution. Because our plugin and the methods of its modules, which have been marked with the appropriate access level, are accessible from JavaScript running in the browser, we can extend such dynamic translation support to the browser as well.
Translations are conducted using a very simple macro language inspired syntactically by TeX. It allows placement of separately translated arguments in arbitrary order (to facilitate support of languages such as German which have different or flexible word order structures) and automatic construction of quotation marks (to handle nested quotations build from separate translations substituted as in the previous remark). Because of the nature of the system, new extensions can be added but this will not complicate the writing of a translation module: the goal is to allow our customers to be able to modify these to substitute their own language if they see fit.
Static Web Content
The exact same translation module drives a compile-time tool to create static versions of web pages, style sheets, and so forth which support individual cultures. This step occurs automatically using pkgBuilder, the tool used throughout TrustBearer for building all systems we produce. The result is a collection of HTML files, one for each culture which is supported. Customers are then free to select from the available languages to deploy, and to use their webserver’s rewriting capabilities to send e.g. their Norwegian users to index.no.html rather than index.en.html. This provides a balance between computation time required and flexibility offered; while TrustBearer’s clients no longer have the capability to retranslate pages without any extra work, their servers will not be constantly working to provide the latest translated version when such is very unlikely to change with any notable frequency.
Daemon
The core TrustBearer server, which we simply call “the daemon,” rarely provides information directly to the user. Rather, it contains a lookup system to check incoming error attributes against a database and return a corresponding message which is meaningful to the humans who will diagnose or work around problems. For quite some time, the daemon has used the client’s language (as provided by their browser) as a means of looking up these human-readable messages. Little to no extension of this system is necessary to continue to provide error and status messages to users in the languages in which they are accustomed to communicating.
The Road Ahead
While the architecture of the internationalization system is fairly set, the work on retrofitting this into the existing system is just beginning. Over the next few months, we will be externalizing strings and incorporating the new methods of translating messages dynamically. TrustBearer’s head engineer, Eirik Herskedal, is from Norway and will be providing a pilot translation into his native tongue for us to begin testing with. The testing and quality assurance process will take the longest, but features in the translation system (for example, XXX’ing out strings for which no translation exists) will make this process smoother. After several months, we expect these features to enter beta use by our most prestigious customers. Then, with the consideration of customer feedback, these features will be added to all of our future deployments.
Software systems that work with the cultural complexities and sensitivities of their users, rather than against them, are woefully under supplied. At TrustBearer, we value the differences in our users, and wish to better cater to the multi-faceted nature of their individual societies. By starting this long work to implement internationalization features in TrustBearer products, we begin down the road of providing our system in a way that works best for you, whoever and wherever you may be.
There was a peculiar piece in the American Spectator online last week, a “Special Report” by Mark Hyman. The author lists a number of unfortunate circumstances by which harmless passengers, many times military personnel, have been delayed or hassled by TSA and airport security protocols. He blames these anecdotal mishaps on “government bureaucrats armed with ‘rules, policies and procedures’ and employing no commonsense.”
He goes on to question a number of security and procedural policies in government and military institutions, which he thinks are unnecessary and demeaning to the personnel at these institutions. As a primary example, Hyman makes the case that the rules for issuing and renewing CACs (Common Access Cards) are unneeded and absurd.
He is miffed because he did not renew his CAC before it expired and he had to go though a bureaucratic process to straighten this out:
“My CAC had expired days earlier so I contacted an issuing office to get a replacement. A clerk in the ID card office informed me that all appointments had to be made online using the intranet. Yet, my expired CAC prevented me from using the intranet system. In spite of my predicament the clerk told me, “Our policy requires all appointments to be scheduled online. If you are unable to use the intranet, then there is nothing more I can do.” It sounded like the beginning of an Abbott and Costello routine.”
“Rather than fight this particular battle, I decided to renew my CAC at another issuing office. While there, I was asked to produce a picture ID. I showed my state driver’s license. I was then asked for a second form of ID and was told the CAC was not acceptable since it expired five days earlier. A week earlier it would have been valid, but on this day it was deemed worthless. So I showed the clerk my company-issued ID card that looked as though it was made on an office computer and laminated at the local Kinko’s. As a matter of fact, that was exactly how that ID was manufactured. But it was good enough. The clerk accepted the flimsy company ID over the just-expired military CAC.”
Hyman concludes,
“What makes this episode even sadder is that the military CAC is generally not accepted as a valid form of identification for use by visitors to the Pentagon. Visitors must also have a Pentagon-issued ID or another form of identification such as a state driver’s license. The reason, according to a security officer, is that at least one machine that manufactures CACs and several hundred blank CACs are missing and presumed to have been stolen. Security officials do not know which CAC is valid and which is a forgery.”
The latter claim is nonsensical and shows that the security officials Hyman chats with are miss informing him about how his CAC works. This too, expresses a common misconception— that possession of the card is the only thing that verifies identity.
To his point about the pains of standing in line to renew something only to find that you don’t have the right materials: I can empathize with this, but I cannot gather what rules Hyman thinks are silly, and which are reasonable. Is he arguing that he shouldn’t have to have a CAC, or that he should be able to use his expired CAC, by itself, for renewal? And what does this have to do with policy created by top-level military and government officials?
What is clear from reading the piece is that he doesn’t like the rules much because he doesn’t understand why they are in place. He wanted an exception so he could use his expired CAC. Similarly, in another of his examples, he complains that his wife couldn’t renew her own CAC using an expired passport.
There are two fundamental questions that would help Hyman better appreciate these rules: Why are identification badges, such as CAC cards, used? And, how is the true identity of a badge-holder verified? In other words, what is a CAC good for anyways?
Identity, and the privileges we associate with it, is an abstract thing that is difficult to verify. The best way for a large institutions to verify a person’s identity is to gather the various artifacts of identity, such as a state driver’s license, for this person and grade the validity of these items and the authority of the institution who gave the item. The bureaucratic pronouncements on this process (i.e. presidential directives and policies) say that the best way to verify the identity and authorization of millions of people is to create a system of rules that make the procedures repeatable, reliable, and safe. (One such rule may reason that an expired identity artifact should not be considered valid, even if it was valid yesterday.)
Now, the process of using a CAC card is not as simple as it could be. Systems that use badges for the identification of people and the verification of people’s permissions and authority are complex and imperfect, but this is not a problem of bureaucracy. It’s more a matter of improving these systems for most users and reminding users, like Hyman, why they were given a badge to begin with.
TrustBearer is located in Indiana and—as it might be expected— several members of the company, including the company’s founder, are graduates of Purdue University, in Lafayette, IN. A couple of TrustBearer’s Purdue alums studied at the Center for Education and Research in Information Assurance and Security (CERIAS), under the direction of Gene Spafford.
Gene Spafford is a well-known programmer, researcher, and educator in the field of computer and information security. He is perhaps best known for his analysis of the first internet-distributed worm in 1988, the Morris worm. He also has a knack for punch security metaphors.
Spafford was recently interviewed by Tom Field of the Information Security Media Group. It’s a thoughtful, thorough interview, which is well worth sharing. The subject of the interview concerns information assurance education. Spafford was asked about the current state of information assurance:
SPAFFORD: Well, it is still rather chaotic. There are a range of issues and priorities within the field where education can be directed; some of the education is directed towards people who are practitioners, who are going to be on the front lines running systems. Some are oriented towards management-type positions that are setting policies and ensuring compliance. And there still is a community focused on the research aspects, more how to solve problems that are just emerging.
We don’t really have a common curriculum that runs across these, although there are a couple efforts that are underway to try define parts of it, and it is isn’t really certain what the best practices are, what the background expertise should be for these positions. So it is still an area that is evolving quite rapidly.
In the interview, Spafford also talks about how information assurance and security have changed over the past couple of decades:
When I really saw the start of this field in the late 80’s and early 90’s, most of the people who were involved had a deep understanding of issues of machine architecture, encoding, network protocols, and really understood the systems at a low-level. What we see now for many educational institutions is they are focusing on high-level applications, web security, JAVA, running prepackaged firewalls and IDS systems, and many of the people going to that educational path are not exposed to those low-level details, even though some of the attackers are exploiting those low-level details. So we have seen a split off of that kind of expertise in two areas, both the research arena and also some in the forensics arena.
But of course the field has also grown; the level of threat has changed significantly. If we go from the late 80’s/early 90’s, there wasn’t any commercial use of the Internet, and it didn’t have the global reach it does now. So the issues of social engineering, fraud, phishing, many of the other kinds of false information presentation and mailed-around exploits didn’t exist back then. So we have seen a huge evolution in the threat picture, in the target set, and in the overall understanding of what security in computing is all about.
Related Links
Spafford Interview on C-SPAN An expansive (30 min) general interest interview with Spafford on the state of internet security and identity protection.
Do We Need a New Internet? New York Times piece on the future of internet security, including a discussion of Spafford’s work.
This is the official company blog of TrustBearer Labs. We write about online security issues and talk about our products. We think security is only as useful as it is usable.
stevepepple
corcordt
Taylor Venable
Brian Kelly
harningt
cpenn
