With the explosion of the Internet and Web technologies as a medium of exchange, issues related to IT security have been growing exponentially. Protecting the organization’s IT infrastructure from hackers, viruses, theft of data, denial-of-service attacks, and intruders has assumed an extremely important role. This battle cannot be fought and won without the appropriate knowledge being delivered to the right people. The need for security knowledge has prompted the development of programs like Security Awareness and Training (SETA) [12]; some have even recommended attending hacker conferences to gain security knowledge [3].
Knowledge management (KM) provides a formal mechanism for the identification and distribution of knowledge. Benefits of proper KM are improved organizational effectiveness, delivery of customer value and satisfaction, and added product and service innovation [9]. There is no reason to believe that IT security will be an exception. It has been recognized that the first step in the KM process is to identify or define knowledge needs [7]. We have developed an Information Security Knowledge Architecture (ISKA) that organizations can use to determine their IT security knowledge needs. ISKA can be used by organizations to determine the status of their current IT security knowledge and determine the target IT security knowledge architecture. Consequently, this architecture will assist organizations in developing a knowledge strategy that will pave the way for them to go from the initial or current knowledge state as determined by the current knowledge architecture to the goal knowledge state as determined by the final knowledge architecture. It is also expected that ISKA will become a tool for researchers for developing hypotheses that will lend to empirical testing.
ISKA provides a fundamental structure of knowledge that may remain relatively time-invariant; however, the internal details of the knowledge architecture will be dynamic, with interorganizational as well as temporal variations. Interorganizational variations arise from the differences in the organization’s mission and exposure to the environment as well as use of technologies, while temporal variations are caused by the changes in technologies and the nature of threats over time. For example, security administrators have always needed knowledge of data encryption, and this knowledge has remained time-invariant, while knowledge of newer encryption schemes must be added to the security administrators’ repertoire, adding a dynamic component to the knowledge and to ISKA. Organizations can develop the basic architecture discussed here as an initial source of input, adding details and honing the architecture to suit their specific IT security goals.
ISKA provides a unique and generalizable approach for developing a knowledge architecture. While the basic components of ISKA were identified using KM concepts, we have not encountered an architectural approach in the KM literature that integrates the components through interfaces. Moreover, previous approaches to KM covered in IT security literature neither included all the components that ISKA has, nor are those grounded in the concepts and principles of KM. ISKA is generalizable because the fundamental structure can be applied to domains other than IT security, though the details will vary from domain to domain. We chose IT security because of its current importance as well as the importance of knowledge in maintaining IT security. An illustrative example has been provided to aid the practitioner for implementing ISKA in organizations.
Development of the ISKA
We used a two-step approach for developing ISKA. In the first step, the various components of ISKA were identified and defined. In the second step, the interfaces between the components were defined and analyzed. To identify the components of ISKA we delved into a wide variety of definitions for KM as well as theories of KM and incorporated it into the goals of IT security discussed previously. The definitions from the KM literature that were used and its relationship to ISKA components are listed in Table 1. Words or phrases that were helpful in component identification are shown in bold type. Each identified component was checked for cohesion as well as its ability to serve the confidentiality, integrity, and availability (CIA) triangle that forms the fundamental basis of IT security [11, 12]. The components identified were stakeholders, knowledge dimensions, knowledge characteristics, and knowledge resources. Figure 1 shows the components and interfaces of ISKA.
Stakeholders. The stakeholders of ISKA are the “right people” who should possess IT security knowledge to maintain confidentiality, integrity, and availability. Everyone legitimately interfacing with an organization’s information system should know the role they play in supporting the CIA triangle, and the knowledge needed to execute the role. Organizations should develop a systematic procedure for identifying and classifying legitimate users with similar knowledge needs. Stakeholders can be classified into whether they are internal or external to an organization. External organizational entities interface mostly with system boundaries and therefore may have very different knowledge needs than internal organizational entities. Internal organizational members can be classified into those who directly interface with the IT system and those who do not. The Chief Information Officer (CIO), Chief Information Security Officer (CISO), network and systems administrators, database administrators, and programmers are those that directly interface with IT. Identifying and classifying users internal to an organization but those that are not directly responsible for administering the IT system can be greatly assisted by the use of Porter’s value chain model [6], which provides a classification scheme of users by grouping them based on the activities they perform.
Knowledge dimensions refer to the “right information” that must be imparted to stakeholders for maintaining confidentiality, integrity, and availability. These are categories of knowledge needed by an individual user or a group of users for making effective decision regarding IT security. Some of the broad common dimensions of knowledge needed for IT security are listed in Table 2. An organization can develop its own dimensions with granularity that matches its own needs. Sources used for developing these dimensions include textbooks, certification coursework and, various Web sites. For example, see [12].
Information security planning involves both the organizational planning for information security; including tactical, strategic and operational planning, as well as contingency planning. Information security policy development is typically categorized based on the scope of the policy. This includes enterprise information security program policy, issue-specific security policies, and system-specific security policies. The knowledge related to project management might be developed from the Project Management Institute’s (PMI) guidelines, applied in the context of IT security.
Examples of security management architectures, models, and practices include the Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE) developed by the Software Engineering Institute (SEI) of Carnegie Mellon University, as well as the Code of Practice for Information Security Management originally practiced as a British standard [12]. Risk management provides the process of discovering as well as controlling and mitigating the risks to IT security. Protection mechanisms include a wide array of tools and technologies, including cryptography, firewalls, intrusion detection systems, and so on. Knowledge of personnel aspects of information security includes developing hiring practices that are consistent with IT security. Law and ethics refers to the various legal and ethical requirements to which an organization’s IT security must comply. Examples include compliance with the various privacy laws, Sarbanes-Oxley Act of 2002, and the Health Insurance Portability and Accountability Act (HIPPA). Ethical dimensions may be developed from an organization’s existing code of ethics or from any currently existing ethical standards.
Knowledge characteristics. There are different ways in which knowledge required for maintaining confidentiality, integrity, and availability can be classified. One widely used form of classification is tacit knowledge versus explicit knowledge [8]. Tacit knowledge is subconsciously understood and applied, difficult to articulate, developed from direct experience and action, and is usually shared through highly interactive conversations, story-telling, and shared experience. Explicit knowledge, in contrast, can be precisely formulated and articulated, easily codified, documented, and transferred or shared. Knowledge will be useful to an organization when it has formal or informal mechanisms for transforming tacit knowledge into explicit knowledge. Knowledge can also be declarative, procedural, social, conditional and relational, pragmatic, and causal [1]. The definitions of these components and its relationship to ISKA are listed in Table 3.
Knowledge resources are knowledge stores that organizations can draw from for answering questions regarding confidentiality, integrity, and availability. Knowledge resources can be internal or external types. According to Stein and Zwass [10] knowledge resource is derived from the collective organizational memory defined as the means by which knowledge from past experience and events influence present organizational activities. Such organizational memory systems store the accumulated knowledge, experience, expertise, history, stories, strategies, and successes as documented by its employees. Knowledge resources reflecting this definition are databases storing historical data of an organization’s significant events and decisions.
Artificial intelligence-based technologies (including neural networks and case-based reasoning) facilitate KM by the creation of new knowledge by merging, categorizing, reclassifying, and synthesizing existing explicit knowledge. Neural network-based systems can analyze patterns of security violations and provide valuable knowledge to stakeholders. Case-based reasoning systems can provide solutions to current security problems by recommending solutions based on similar previous cases. External knowledge sources include reports from business journals, trade associations, and training providers. Three common applications are used in knowledge resources. They include the coding and sharing of best practices; the creation of corporate knowledge directories by mapping internal expertise; and the creation of knowledge networks by bringing people together virtually face-to-face in order to exchange collective information and knowledge.
A goal of knowledge resource is to make tacit knowledge explicit. Methods like the socialization mode of knowledge creation [1] allow tacit knowledge to be transferred from one source to another, thereby allowing such knowledge to become explicit because of the shared experience and interactions among organizational members. Various collaborative technologies can provide the technical tools for such collaboration.
Description of the ISKA Interfaces
ISKA’s interfaces have been grouped into primary and secondary interfaces. Primary interfaces represent the relationship between KM components (such as knowledge dimensions, knowledge characteristics, and knowledge resources), and the stakeholders (both internal and external). Secondary interfaces, on the other hand, represent the relationship among the KM components thereby excluding the role of the stakeholders. The rationale for applying these interfaces is to emphasize the role of stakeholders (as in the level of IT skills, security knowledge, awareness, availability of training and access to the right type of knowledge) in the context of the KM components and IT security.
Primary Interface 1: Stakeholders and knowledge dimensions. This interface represents the mapping of stakeholders to knowledge dimensions and will be determined by the security responsibility of each stakeholder. For input logistics, the truck driver may need to know how to maintain the security of certain codes used for entering warehouses, and understand the social engineering threats that may compromise the security of the codes. Systems administrators, on the other hand, must have detailed information of how to set up firewalls and other security systems.
Primary Interface 2: Stakeholders and knowledge resources. The relationship between stakeholders and knowledge resources refers to the stakeholder’s access to the correct IT security information based on the knowledge types. For example, an internal stakeholder such as the IT security manager or the CISO may be actively involved in updating the security procedures and policies, while an external stakeholder may merely be aware and use the policy. In a typical situation an internal stakeholder would have full access to the IT security knowledge when compared to an external stakeholder.
An analysis of this provides a glimpse of knowledge resources that may be available to stakeholders, yet grossly underutilized. Managers may have risk management training sessions available, yet very few managers may choose to select this option. Explanations for why such a phenomenon is occurring will provide insights into whether proper resources are available or being utilized. For this scenario, organizations can systematically study various possible causes regarding why these resources are underutilized or not utilized at all and decide whether it is feasible to continue providing support for these resources. Also in this scenario, managers may not have the time or may prefer other resources (for example, Web-based training).
Primary Interface 3: Stakeholders and knowledge characteristics. Here, the organization can analyze whether certain stakeholders of knowledge exhibit certain characteristics. For example, is the knowledge of the chief security officer primarily tacit or primarily explicit? Do most personnel at the operations level have mostly tacit knowledge or mostly explicit knowledge? Analysis of this link will allow organizations to provide resources for converting tacit knowledge to explicit knowledge. If stakeholders at the managerial level tend to have a far greater share of tacit knowledge socialization between them may be an option for converting some of the tacit knowledge to explicit knowledge and making it more useful to the organization. Analysis of this link will also allow organizations to know whether stakeholders have the appropriate knowledge characteristics. Systems administrators may require declarative knowledge about firewalls to know what threats will be addressed by the firewalls as well as procedural knowledge for setting up a firewall and causal knowledge of how and why firewalls actually work.
Secondary Interface 1: Knowledge characteristics and knowledge dimensions. This relationship explores whether characteristics such as explicit or tacit knowledge are related to knowledge dimensions like legal and ethical issues related to security. For example, while legal knowledge may be mostly explicit, knowledge of ethical issues may be vastly tacit in nature. Much of knowledge related to information security and assurance may be explicit, whereas the knowledge of management of IT security and controls may be tacit.
There may also be a relationship between the other characteristics of knowledge like declarative, procedural, social, causal, conditional, relational and pragmatic, and the knowledge dimensions and will be determined by the organization’s strategic position. If most of the legal functions are outsourced, procedural legal knowledge may not be needed but declarative legal knowledge may be. The organization can also find the required but missing knowledge characteristics of some knowledge dimensions.
Secondary Interface 2: Knowledge characteristics and knowledge resources. In this case, the organization will examine whether knowledge characteristics like tacit, explicit, and so on are related to the various knowledge resources available. Since tacit knowledge will be related to individuals or groups possessing that knowledge, organizations must identify such organizations or groups. Furthermore, explicit knowledge may be acquired through various means, like training sessions, the Internet, textbooks, procedures, manuals, among others. Similarly, other knowledge characteristics and knowledge sources may have a relationship. Organizations must also decide on the various knowledge representation schemes to be used in the knowledge resources. Declarative knowledge can be implemented as cases while procedural knowledge can be represented as rules. Similarly, relationships between other knowledge types and appropriate knowledge representation schemes will have to be decided upon.
Secondary Interface 3: Knowledge dimensions and knowledge resources. In this relationship the organization can explore whether specific knowledge dimensions are linked to knowledge resources. For example, the primary source for setting up a firewall might be in-house training, whereas the primary resource for learning about security management models may be external training and Web-based resources.
ISKA Application Example
To demonstrate how practitioners can implement ISKA in organizations, we propose a current knowledge architecture should be developed for each group of stakeholders. This will allow a knowledge audit and identify knowledge gaps in organizations. In a similar manner, a target knowledge architecture can then be developed. The example shown in Figure 2 demonstrates how a current knowledge architecture for the stakeholder group “Security Technician” can be developed. Similar architectures can be developed for all groups of stakeholders.
The interface between the Stakeholder (Security Technician) and Knowledge Dimensions show that the Security technician needs to know how to configure firewalls, implement security software, and diagnose/troubleshoot problems. The interface with Knowledge Resources shows they need access to relevant training, and access to manufacturer’s Web sites. The interface with Knowledge Characteristics shows that all the knowledge is procedural, because they must know the procedures for configuring firewalls, among others.
For each component in the architecture, the secondary relationships are given in the parentheses. For example, in the Knowledge Dimensions component, the first item is “Configure Firewalls (KR1, KC1).” This shows that “Configure Firewalls” is linked to the first item in Knowledge Resources 1: “Hands-on Training.” It is also linked to the first item of Knowledge Characteristics “Procedural.” Though we have only one item in Knowledge Characteristics in this example, it is still numbered because there may be other cases where there are multiple knowledge characteristics
Therefore, we can conclude that Security Technicians need hands-on training for procedural knowledge of configuring firewalls. In Knowledge Resources, Hands-on Training is related to Knowledge Dimensions 1 and 2, therefore hands-on training has to be arranged for Configure Firewalls as well as Implement Security Software. The relationships in Knowledge Characteristics show that procedural knowledge is required for all three knowledge dimensions (KD1, KD2, KD3), and the resources for procedural knowledge will be Hands-on Training (KR1) and equipment manufacturer’s Web site (KR2).
Conclusion
In this study we have developed a knowledge architecture for IT security (ISKA) by incorporating KM principles and concepts. This architecture provides a unique and systematic approach for organizations to assess their IT security knowledge needs by determining the current and future knowledge architecture. By doing this, the organizations can determine the quality, completeness, and effectiveness of their IT security knowledge. This in turn will enable organizations to implement IT security standards more easily.
Developing the knowledge architecture will also assist the organizations in involving all the stakeholders in the security management process. It is hoped that organizations will find the architecture proposed here a valuable tool for developing a strategy to fight against those who are continually attempting to undermine IT security. Future research aims to examine the architecture in organizations from a cross section of different industries via a multiple case study approach.
Figures
Figure 1. Components and interfaces of ISKA.
Figure 2. Example knowledge architecture for the security technician.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment