EducationEditors: Matt Bishop, bishop@cs.ucdavis.edu

Deb Frincke, frincke@cs.uidaho.edu

argument to support this view isthat bolt-on security solutions donot work well. Matt’s thesis is in-sightful and correct, and should beembraced by those of us responsiblefor educating future information as-surance practitioners. And yet, thepedagogy used to teach computersecurity to students new to the fieldis usually handled by a one- or two-course augmentation to an existingcurriculum. Furthermore, thecourses tend to be technology-cen-tric and often do not uncover theunderlying processes that studentscan transfer to new situations.

In this article, we look moreclosely at determining an appropri-ate scope and sequence for informa-tion assurance (IA) and briefly de-scribe a project whose goal is thearticulation of an IA curriculum.

Academic programsWe can learn much from the soft-ware-engineering community re-garding the desire to teach studentsto approach “good security” as afundamental design principle.Over the years, academic softwareprograms have evolved from meet-ing their goals with focused tech-nical elective courses to the holisticapproach of threading key proc-

esses throughout the curriculumstarting with the first program-ming course. Students repeatedlyinternalize knowledge and skillsleading to, for example, reusableand safe software. Over time, stu-dents adopt best practice models assecond nature.

Contrast this with the way thatwe typically teach IA. Studentsmove from the detailed to thewhole, for example, starting withthe intricacies of cryptological al-gorithms and finish with cross-cut-ting processes such as risk assess-ment. In the absence of aframework that encompasses cour-ses or modules, students are unsureof how the small pieces in a micro-cosm fit together to support themission of designing secure systems.Learning is often compartmental-ized and highly contextual; studentsare unable to transfer knowledge tonew situations.

And so it would seem that IAeducators have two fundamentalchallenges: to get at the knowledgeand processes that we feel are trulyessential, and to create curriculathat repeatedly places theseprocesses in front of students in avariety of contexts. These are bothmajor endeavors.

Security designLearning is the end goal of a curricu-lum. Just as security must be designedinto a system from the start, enhanc-ing the quality of the learning experi-ence must be the paramount concernguiding each step in the curriculumdesign.Grant Wiggins and JayMcTighe1 make a strong case forusing a backward design process forcurriculum by starting with the as-sessment. To paraphrase, if we cannotdetermine acceptable evidence formeasuring learning, then we can saylittle about the curriculum’s efficacy.They advocate that the curriculumshould be designed to uncover thebig ideas and enduring understand-ings; that is, the core knowledge andprocesses that we want students totake from our courses.

They identify three levels of un-derstanding as a guide:

• worth being familiar with,• important to know or be able to

do, and• have enduring understanding.

This taxonomy provides assis-tance when we have to make deci-sions about what needs to be taughtor discarded and the level of under-standing required.

The community has embracedthe challenge to design (or redesign)computer-security curricula, andseveral projects are underway. Thepressing need to increase the numberof IA graduates coupled with thelack of capacity to quickly ramp upnew programs (due to the low num-ber of university faculty in security)places a premium on leveraging ex-isting resources by sharing instruc-

JIM DAVIS

Iowa StateUniversity

MELISSA DARK

PurdueUniversity

In the inaugural issue of IEEE Security & Privacy

(January/February 2003), Matt Bishop said that security

must be treated as a property to be engineered into every

system component starting with the design, rather than

viewing it as functionality to be added later. The compelling

56 PUBLISHED BY THE IEEE COMPUTER SOCIETY � 1540-7993/03/$17.00 © 2003 IEEE � IEEE SECURITY & PRIVACY

Teaching Studentsto Design Secure Systems

Education

tional materials. To do that effec-tively, there must be general agree-ment on what to teach.

Funding for curricular develop-ment in IA has increased significantlyin the United States. One data pointis the National Science FoundationScholarships for Service program. Inthe last two years, approximately 32projects received US$200,000 ormore each, in part to develop in-structional materials and train faculty.

A major challenge is finding acommon path, complete with mile-stones, from which we can measureprogress. The end goal is perhapsmore clear—develop a set of curric-ula representing the breadth of infor-mation assurance, identify a corebody of knowledge common to all,uncover the big ideas, developguides for assessment and perfor-mance, and create shared instruc-tional materials. Missing, however, isthe blueprint for the framework thatholds the pieces together.

Several efforts are underway toaddress aspects of developing an IAcurriculum. It has been a slowprocess, primarily due to the need toform a consensus on the essentiallearnings for such a broad profession.

Other efforts focused on specificoutcomes. Most notable are the setof documents developed under theauthority of the Committee on Na-tional Security Systems (CNSS).One document in particular, theNSTISSI 4011—National TrainingStandard for Information SystemsSecurity Professionals (or just 4011),is a living document that enumerates

a set of skills and knowledge that apanel of security practitioners iden-tified as essential. Compliance with4011 has become one component ofthe criteria for US universities to be-come recognized as a National Secu-rity Agency Center of AcademicExcellence in IA Education.

While 4011 and its companionCNSS documents provide an ex-cellent list of key IA topics, theywere not designed to guide cur-riculum development. Havingagreement on the set of topics isjust one part of the puzzle. Recallin the backward-design processthat we must first determine thedesired learning outcomes andthen specify the acceptable evi-dence that the outcomes were ob-tained. This is one of the most dif-ficult steps in the development

process and, yet, this type of ques-tioning often uncovers the mostuseful information about what wevalue in our learning experiences.

Where do we go from here? Some questions have difficult answers.For example, what do IA graduatesneed to know or what should they be

able to do? Until we are able to articu-late a precise and measurable set ofoutcomes, we will not be able to de-sign a curriculum. Additionally, whatare the big ideas and enduring under-standings that connect the diversecomponents of IA? Finally, what is thecommon body of knowledge (CBK)that IA graduates must know?

As the community addresses theseissues, having a model or a frame-work that we can instantiate with re-sults as work progresses is helpful.One well-accepted model for a com-puting curriculum is CC 2001, thejoint IEEE Computer Society/ACMTask Force on the “Model curriculafor Computing” effort that identifieskey outcomes and topics supportinga robust curriculum in computer sci-ence. We borrow the hierarchicalstructure of CC 2001 and add layers

representing IA-specific knowledgeas shown in Figure 1.

The four layers in Figure 1 pro-vide the framework’s structure. Thetop layer is an enumeration of theskills and knowledge thought to beneeded by IA practitioners. In thiscase, they are specified by the CNSSlibrary of documents; they couldalso be the Certified Information

http://computer.org/security/ � IEEE SECURITY & PRIVACY 57

Can we teach our graduates to design

systems with good security practices in

mind? Absolutely. We have to do it.

• Committee on National Security Systems (CNSS): www.nstissc.gov

• IEEE Computer Society/ACM Task Force on the “Model Curricula for Computing” (CC 2001): www.computer.org/education/cc2001

• International Information Systems Security Certifications Consortiums: www.isc2.org

• National INFOSEC Education and Training Program: www.nsa.gov/isso/programs/nietp/index.htm

• National Security Agency Center of Academic Excellence in Information Assurance Education:

www.nsa.gov/isso/programs/nietp/index.htm

•NSTSSI No. 40—National Training Standard for Information Systems Security Professionals: www.nstissc.gov/Assets/pdf/4011.pdf

URLs of interest

Education

Systems Security Professional(CISSP) outcomes or even a set ofskills for emerging IA researchers.This set of skills and knowledge issupported by the two layers belowit, which describe the cross-cuttingenduring understandings in IA andthe CBK specific to IA. The bot-tom layer represents a firm founda-tion in computer engineering,computer science, or information-technology curricula.

With a framework in place, wecan fill in information as it develops.We then connect content in theframework with the relation “needsto know or do X in order to under-stand Y.” Generally, X is closer to theCBK layers and Y is a higher-orderskill or process.

Let’s draw an example from the4011 document. One of the higherorder outcomes “…builds a securityplan that encompasses NSTISS com-ponents in designing protection/se-curity for an instructor-supplied de-scription of an AIS/telecommun-ications system.” In other words, astudent must be able to plan for theprotection of information assets in a

given scenario. This is a complexthought process that relies on manyhigh-level learning outcomes. Stu-dents must determine which assets toprotect, identify threats and vulnera-bilities, and determine effective andaffordable countermeasures. The un-derlying process is risk management,which we then place in the enduringunderstandings layer. Specific IAskills, such as understanding how aparticular threat affects a system’s op-erations, are drawn from the IA CBK.In this example, the base CBK couldcontribute basic information aboutnetworks or operating systems.

Although the notion of layeringknowledge implies a strictly hierar-chical relationship between the lay-ers, clearly some of the higher-levellearning outcomes rest directly onthe CBK for IA or even priorknowledge brought in from the sup-porting disciplines. For example,4011 requires students to be familiarwith basic computer-architectureconcepts that would most likely betaught in a computer-science orcomputer-engineering course.

Furthermore, we do not imply

that skills and knowledge should betaught in a bottom-up fashion.Much like the discussion on soft-ware engineering, it would be mosteffective if important security con-cepts were threaded throughoutthe curriculum.

There are many “teachable mo-ments” that arise in non-IA courseswhere it is appropriate and effectiveto embed security topics. For exam-ple, buffer-overflow attacks (whichaccount for the majority of networkattacks) are easy to understand whenadded to a discussion about stackframes for high-level languages.When buffer overflows are studied inisolation, the concept is more ab-stract. As the curriculum designprocess continues, other such cou-plings will no doubt be found.

W e looked at one componentof designing a curriculum

with the specific goals of uncoveringthe big ideas for students and deter-mining the common body ofknowledge. Can we teach our grad-uates to design systems with goodsecurity practices in mind? Ab-solutely. We have to do it. Let’s rollup our sleeves—we have a lot ofwork to do.

Reference1. G. Wiggins and J. McTighe, Under-

standing by Design, Association forSupervision and Curriculum Devel-opment, Alexandria, Virginia. 1998.

Jim Davis is the interim chair of theDepartment of Electrical and ComputerEngineering at Iowa State University. Heis a senior member of IEEE, a member ofthe ACM, and editor of the IEEE TC onSecurity and Privacy newsletter, Cipher.Contact him at davis@iastate.edu.

Melissa Dark is the assistant dean of theSchool of Technology and an associateprofessor in the Computer TechnologyDepartment at Purdue University. Shehas been integrally involved in informa-tion security education initiatives throughthe Center for Education and Research inInformation Assurance and Security. Con-tact her at dark@cerias.purdue.edu.

58 IEEE SECURITY & PRIVACY � MARCH/APRIL 2003

CBK forcomputer science

CBK for computer engineering

CBK for informationtechnology

Prerequisite knowledge

Enduring understandings and big ideasfor information assurance practictioners

Common body of knowledge (CBK) for information assurance

Committee on National Security Systems

job skills andknowledge

Figure 1. Hierarchical structure of the joint IEEE Computer Society/ACM Task Forceeffort (CC 2001).