12: PRACTICAL APPLICATIONS OF McCUMBER CUBE ANALYSIS
INTRODUCTION
The theoretical underpinnings of the information-centric McCumber Cube model have been explored in depth. The application of this methodology for security enforcement is now a straightforward process of defining and evaluating the elements of the model and applying it to the information security design problem at hand. The actual implementation of a structured analysis is admittedly a tedious and detail-oriented process, but without a structured methodology to follow, it becomes difficult to both justify and implement a comprehensive program. There are several aspects of a practical implementation of the model that will be discussed in this chapter.
An in-depth understanding of the theory that supports the McCumber Cube model is important to effectively implement the principles of the model to develop and enhance security for any type of information resources or assets. The universal nature of the model is such that it has direct applicability to almost every information security challenge. It can provide a basis for an enterprisewide security program, an assessment of select safeguards, or the detailed analysis of an information security product.
In this chapter, we will review a number of ways the McCumber Cube can be employed. We will start at the global level of abstraction and then briefly discuss various targeted applications of the model. Because the model is independent of technology, it can be used as a basis for analysis and decision making with the understanding that the principles of the model will not change with the evolution of technology. In other words, the McCumber Cube application technique you learn and employ today will be the same one you can use in the future. That is certainly more than you can say for programming techniques or technology roadmaps.
For anyone performing any type of information security analysis, the model is applicable and often enlightening. By focusing on information as the foundation of information security, it opens up new avenues of research and development for capabilities to provide confidentiality, integrity, and availability of information resources. The technology-centric approach is always self-limiting. Technology changes and new products and processes are introduced with startling frequency. By working at a level of abstraction above the technology layer, security practitioners can more efficiently design security safeguards and security programs that provide cost-effective protection.
When evaluating or assessing the analyses of others, applying McCumber Cube logic to the information security problem forces the security practitioner or analyst to focus on the information security attributes and reconsider the conclusions. Too often, security analyses are developed around faulty assumptions. Sometimes, the technology-centric approach means that any definitive results will be obsolete with the next evolution of technology and that may be only weeks away. The model is an excellent reference to apply when the topic is the protection of data and information resources of any kind.
APPLYING THE MODEL TO GLOBAL AND NATIONAL SECURITY ISSUES
The McCumber Cube model is an effective basis for any security analysis. There are several reports and analyses in recent years that are aimed at assessing security incidents and their impact on a global or national level. These reports and studies often make assumptions about threats, vulnerabilities, and safeguards that are obsolete or inaccurate. When a threat is presented on this level of abstraction, it is almost entirely focused on malicious attackers who have extensive IT skills. Safeguards and best practices are almost always tied to the existing state-of-the-art technology and conclusions are based on conjecture at best and fear mongering at worst.
In February 2003, the Office of the President of the United States published the National Strategy to Secure Cyberspace.1 This was a non-regulatory publication. It did not have the effect of law. The strategy was developed after several years of intense consultations among thousands of individuals—officials at all levels of government, experts from the private sector, and other concerned citizens. It was published to establish priorities and recommendations for providing the appropriate protection of cyberspace functionality. Initially, the document contained some rather pointed observations about serious vulnerabilities of specific technologies such as wireless Internet access and Internet service providers’ (ISPs) infrastructure. Through its various iterations, the drafters eventually dropped some of the more controversial statements made about whether these ISPs or even universities could be doing more on behalf of cyberspace security. Instead, the National Strategy to Secure Cyberspace was toned down and was published simply to encourage industry, government agencies, and the public to reduce risks wherever practical.
Those aspects of the national strategy that focus on best practices, of course, will be outdated soon enough. So will the references to specific technologies and the references to the emerging wireless environment. This will hardly be the foundation of the cybersecurity the way the U.S. Constitution represents the foundation for our national government. That is because the U.S. Constitution is built on sound principles for a constitutional republic and not designed to capture all the specific detail on how that is accomplished. Had the National Strategy to Secure Cyberspace been developed around the basic principles and imperatives of protecting our national information resources, it would make a bigger impact.
The other option would be to focus such a document on the need to protect the technology infrastructure. In this case, the approach would be different and the model may not apply because information is not the subject of the strategy. In either case, a sound understanding of the model necessary would have provided a superior foundation worthy of the amount of effort it takes to create and publish such a document.
National-level debates and mandates over the protection of information resources revolve around two fundamental elements—the technical infrastructure used to transmit, store, and process data and the information itself. If the foundation is specifically on the information, the McCumber Cube model applies. In the case of an information-centric requirement, it provides the basis for understanding the information attributes of the concept of security. We defined security in an earlier chapter and the definition is quite apt in this case. Security is not a binary concept and any analyses, proposals, or guidelines that imply that it is can often be more confusing than enlightening.
When depicting risk to information resources on a global or national scale, the essentials of the risk management process also apply directly to the risk issue under review. The elements of threat, vulnerability, asset, and safeguard are juxtaposed to assess the amount of risk. Any decrease in the threat, the number and severity, and the value of the information assets will decrease the amount of risk. Conversely, any increase in the number and nature of the threat, the number or severity of vulnerabilities, and the value of the assets requiring protection will increase risk. Referring to these variables in any discussion of risk to information makes it easier to analyze, model, and interpret the results or conclusions.
Applying the McCumber Cube model to these large-scale issues can dramatically simplify the analysis and provide a common context for evaluating various options. The essential elements of information security and the ability to decompose complex technical infrastructures into state changes of transmission, storage, and processing requires analysts and decision makers alike to work from a common palette. This feature alone demands the use of the Cube for effective communication about complex technologies and the valuable information they handle.
PROGRAMMING AND SOFTWARE DEVELOPMENT
The McCumber Cube also lends itself to use in programming of applications and other software development activities. Just like the decomposition and assessment of components, software not only facilitates the processing of information, but its transmission and storage as well. Because the model is information-centric, creating an information flow map of the software design can assess security attributes of computer programs. The emphasis for this type of project is not on the code itself, but on the information that is manipulated by the software.
The information flow map for a software development program would be created to identify the state changes of transmission, storage, and processing. This would then be used to track the information flow through the program. Security attributes are then overlaid to create a security management map of the program or application.
At each identified state, the appropriate attributes of confidentiality, integrity, and availability can be analyzed and assessed. Necessary security-relevant issues are quickly highlighted as vulnerable information states are identified. These vulnerabilities may be exposed by identifying information that can be unintentionally modified by outside processes, human interaction with the program, or simple loss of data.
USING THE McCUMBER CUBE IN AN ORGANIZATIONAL INFORMATION SECURITY PROGRAM
The McCumber Cube is most effective when applied to an organizational information security program. It provides numerous practical applications for use by the security program manager, the security practitioner, and all decision makers involved in information security issues. For starters, the McCumber Cube provides a common lexicon for discussing and analyzing information security issues. Instead of a tedious and unproductive debate over technical vulnerabilities and safeguard specifications, security practitioners and decision makers have a common framework to discuss both the concept of security and the trade-offs involved in acquiring, deploying, and managing security safeguards.
Before security practitioners and decision makers can even begin to wrangle about the merits of various options for protecting information, they need to agree on a common definition of security and the amount and nature of that protection. Security is an ideal state not unlike the concept of love. We may feel secure just as we may feel love, but for professionals to discuss the practicalities of this ideal state, certain common ground must be achieved. If the decision maker simply demands that his or her information be secure, it is left to the security practitioner to define how much security is adequate. This ages old problem has resulted in more than one security expert getting sacked.
The first step in any organizational security program is to explicitly define what it means to be secure. One person’s definition of security is not usually the same definition perceived by another. The McCumber Cube immediately identifies the basic elements that comprise the definition of security as it is applied to information and data. To effectively communicate regarding the security attributes of information, all parties to the discussion must define that security on terms of confidentiality, integrity, and availability. Although there have been those who have sought to expand the number of securityrelevant attributes, the basic three provide adequate and comprehensive categorization to meet the needs of organizational security programs.
The next important elements of the model are the information states that force the user to abstract the information security problem to a level above the technical infrastructure and its associated components, computers, protocols, and media. By employing the information states of transmission, storage, and processing, the primary security analyses are performed to determine a comprehensive strategy before these plans and procedures must be translated into specific technical solutions and safeguards.
The value of the information state aspect of the model is difficult to underestimate. Too many times and in many situations, technologists and those responsible for business or mission requirements fail to agree on the value of security. It is common knowledge that many senior corporate leaders and government executives perceive security controls as a necessary evil. There is always the temptation to skimp on security spending when more revenue-generating investments beckon. In many cases, the final verdict on how much to invest in security is based solely on how much risk the decision maker feels. Although there is something to be said for gut-level instincts, security for corporate data is not one of the areas where this approach is particularly successful.
Information state abstraction allows security policies and standards to transcend the volatile and dynamic technology infrastructure that actually transmits, stores, and processes the data. This means that CxO-level guidance and corporate governance requirements do not need to change with changes in the technology. This is an important feature that allows organizational security practitioners the ability to obtain an accurate agreement on how much security is enough and yet leave the specifics of implementation to the technologists who can best deploy it.
Another key aspect of information state analysis is that it more effectively facilitates the development and enforcement of the broader security program. Many information security programs have standards and policies that must be rewritten or at best updated at least annually to account for technology evolution. By applying security policies and requirements to information states as opposed to specific technologies such as a PCs, compact disks, or hard drives, the policy will most likely remain current for any foreseen or unforeseen changes in technology. However, it is important to note here that changes will still be necessary for significant changes in the value, location, or nature of information resources.
Information state analysis is the heart of the McCumber Cube and is its most valuable commodity. Security practitioners will soon find that approaching information security problems by defining information states and tracing the flow of information throughout its life cycle will uncover previously unknown vulnerabilities and also help to quickly assess new and innovative safeguards to mitigate risk. This process is much more efficient and ultimately more effective than the more common probe for vulnerabilities and subsequent search for technical safeguards.
Just as the technology infrastructure changes, so do the technical safeguards. Instead of mandating a corporate firewall requirement, the policy should be one of controlling the flow of information into and out of the organizational environment. Certainly a modern firewall is a logical and effective safeguard in an existing infrastructure. Over time, however, products will undoubtedly emerge that may provide enhanced security functionality with a different name or safeguard nomenclature.
Information flow maps using the transmission, storage, and processing convention are valuable resources for assessing risk in IT systems. By tracking and mapping the flow of information from its creation or accession to its deletion of long-term storage can be an eye-opening experience. The McCumber Cube model provides this level of abstraction specifically for the security practitioners. System architects and administrators may rely on maps or blueprints depicting the location of components and wiring, but a state map can overlay these elements with a picture of the information states that can then be correlated with the security requirements.
There are several other ways the model can be used by organizational security practitioners that we will cover in the next sections. Notice how the value of the model increases with greater application. If the model is employed accurately and consistently throughout the IT security program, the effort required to adapt and use the model will be saved many times over in repetitious or unproductive activities.
USING THE McCUMBER CUBE FOR PRODUCT OR SUBSYSTEM ASSESSMENT
Chapter 9 on Information State Analysis for Components and Subsystems is primarily targeted toward using the model as a replacement for existing government and industry criteria for evaluating and assessing security in specific technology devices or software applications. To understand information security, it must be in context. In other words, the relative security of a piece of information is dependent not only on the device or medium that is currently transmitting, storing, or processing it, but also on factors such as the value of the information, the location of the component, and the nature of the threat.
However, the McCumber Cube can be effectively used in assessing various proposed technologies for organizational use. By creating an information flow map for the product under review, the same security assessment process can be mapped within the security component, application, or subsystem. The security attributes of confidentiality, integrity, and availability can be estimated if not absolutely defined for the changing information states.
An example of using the model for this purpose could be a data storage system. By decomposing the various parts of the storage device into state changes, you can identify where information flows in, where it is stored, and any processing functions required to store, retrieve, or move the data. Once these are identified, the security practitioner can then apply the appropriate security attributes of confidentiality, integrity, and availability to make a quick determination of the existence and efficacy of security controls and safeguards within the storage system.
The focus, as always, is on the organizational information resources requiring protection. The degree of protection required and the investment necessary to provide that level of protection are calculated through the same basic risk assessment process outlined in the appendix. The McCumber Cube provides the security relevancy attributes and state analysis capabilities necessary to identify potential product or subsystem vulnerabilities and possible safeguards.
USING THE McCUMBER CUBE FOR SAFEGUARD PLANNING AND DEPLOYMENT
Perhaps one of the most consistently useful aspects of the McCumber Cube methodology is its adaptability to use as a safeguard planning and deployment tool. As we showed in Chapter 11 on safeguard assessment, the model depicts not only the three primary safeguard categories of technical, procedural, and human factors, it also highlights the law of safeguard dependency. Both procedural and human factors safeguards support any and all technical safeguards by definition. Human factors safeguards are always present when a procedural safeguard is invoked. Human factors safeguards are present in all safeguard configurations, but they are the only safeguards that can stand independently.
Safeguard planning is the key to an effective security program. Just as it is important to consider all possible threat categories and carefully evaluate the value of information assets, the security practitioner must accurately track safeguard assessment, accession, and deployment. As we have stated in Chapter 11, it is not effective to try to apply the safeguards to a specific technical specification, but to target the safeguards as they support the appropriate information attributes of confidentiality, integrity, and availability. Any safeguard should be tied directly to these factors to assess efficacy and cost-effectiveness.
These security attributes, in turn, are predicated on the seminal information flow map. This is the primary document to work from to define the security attributes. Once these attributes have been defined, it will be necessary to then change the level of abstraction to the technical vulnerabilities within the technology infrastructure. These vulnerabilities can then be mapped to safeguards that mitigate the risk from these vulnerabilities either by eliminating the vulnerability itself or rendering it either partially or completely risk free by changes to its environment.
The McCumber Cube model aids this entire process by forcing the security practitioner to consider and evaluate all three categories of safeguard. It also ensures that the safeguard dependencies are considered for a comprehensive understanding of how the technical, procedural, and human factors safeguards interoperate. These interactions may consist of a software product supported by a procedure that ensures its use and a human factors element that overtly influences users to be more security conscious.
Security practitioners who employ this safeguard model are assured of developing a comprehensive program that recognizes the interrelationships of their safeguards in ensuring the information attributes of confidentiality, integrity, and availability. This is important for any organizational security program. A penetration-and-patch approach to safeguards is not effective and does not provide an understanding and evaluation of the dependencies of safeguards.
TIPS AND TECHNIQUES FOR BUILDING YOUR SECURITY PROGRAM
As we present the many practical ways the McCumber Cube model can be used in assessing and developing security for information resources, it is also just as important to have other key elements in place. In this section we will provide some helpful tips and techniques for your use in building, growing, and maintaining an organizational security program.
ESTABLISHING THE SECURITY PROGRAM: DEFINING YOU
Establishing (or assuming) an information security program is a daunting task. The most important ingredient in the task, quite simply, is the security practitioner. As the security practitioner, you are called on to assess, justify, analyze, monitor, and react to the entire range of potential security related incidents and environments. Your role is that of the consultant, whether you are in a corporate environment, in a government agency, an IT contractor, or actually working as a consultant. Decision makers and colleagues alike will look to you for advice and guidance on the risks to vital information resources.
The first step is educating yourself. Sure, there are self-taught security gurus, system crackers, and even cryptographers. But the art and science of information security is changing every day and it is impossible to be personally aware of every possible vulnerability and available safeguard. That means you have to start with a solid grounding in the basics. If you employ the proper fundamental models and tools, the changes in the IT industry and the products it creates will pose no real problems.
Information security experts were originally computer users or IT workers who developed an interest in the security attributes of early computing systems. Perhaps some of them even exploited these systems either out of curiosity or from malicious intent. There were no schools, classes, or even standards that guided them. They were the pioneers.
Over the years, information security has become a recognized profession within the IT domain. Yet even information security personnel have a wide variety or interdisciplinary skills and many people choose to specialize. Some pursue penetration testing as a career; others are skilled at policy evaluation and development. Still others choose to build security products and some prefer security management. It is important to define you and your role in information security.
For those willing to tackle the big problems such as enterprisewide security program management and leading-edge security systems development, the challenges are manifest. You will be called on to justify and defend your recommendations. You will be forced to validate your conclusions. Most importantly, your work will be tested every day by environmental and human threats that seek to compromise the confidentiality, integrity, and availability of the information resources you seek to protect.
By defining you, I mean it is incumbent on you to gain the proper training and foundational skills to be an effective information security professional. The days of the ersatz hacker or computer hobbyist being picked up as a corporate computer security expert are over—if they every existed at all. Many security and technical certifications are now available to complement traditional educational programs. Also, many colleges and universities now offer certificate and degree programs in information security. These programs represent a sea of change in the industry and are a great opportunity for anyone seeking to enter this career field.
Identifying yourself as an information security professional will require formal education, testing, certification, and experience. Although these efforts are timeconsuming and difficult, they can never be expunged from your records. They are yours to keep. Your attainment will show your customers, bosses, and colleagues your commitment and dedication to this critical field of endeavor.
How many vulnerabilities does a system attacker need to exploit an organization’s information assets? The answer is only one. How many vulnerabilities does the defender need to consider? The obvious answer here is all of them. It takes much more time, effort, and commitment to play defense in this business than it does to play offense.
In almost every organizational situation the security professional is best perceived as a consultant—even if they have a lofty position such as the chief information security officer. The unique set of interdisciplinary skills, technical knowledge, and interpersonal skills demands someone willing to take on the role of an outsider looking in. Successful security programs are built and led by men and women who can place themselves in others’ shoes and look at information as both a malicious outsider and an internal bumbler who can bring down the system. They need to be able to convey abstract concepts to senior managers who must make difficult decisions about resources and funding for security.
Ultimately, they are the advocates for a speechless and amorphic entity—information. In that role, they must be able to cogently evaluate and express the nature of the risks that are faced by the organization and be able to design, defend, and build a comprehensive set of interoperating safeguards to guard against potential consequences that may never be realized. It is not a job for the quiet, unassuming personality.
AVOIDING THE SECURITY COP LABEL
One of the most common problems of IT security practitioners is the perception or adoption of the security cop label within the organization. Without tangible senior-level support for an organizational information security program, the practitioner (and the security staff) is often left to develop policies, analyze the infrastructure, design the security program, and enforce compliance. In such an environment, even the most talented and politically astute security professional can easily fail.
You can obtain the security cop label when you are perceived as a security policy enforcer. This identity can be fatal for your program and ultimately your career. The security cop is someone everyone else in the organization tries to avoid. To them, no good can come from a visit with the security practitioner. Yet many information security professionals bemoan the fact that they do not feel like an integral member of the business team, but an outsider charged with punishing security offenders and creating roadblocks and security hurdles for employees and managers simply trying to perform their duties. This phenomenon is so common, it needs to be addressed here.
The woeful situation of the security cop arises when management does not support the security professional, but leaves them alone to build and manage the information security program. When the inevitable conflicts arise between expediency and security, the security practitioner is always left defending the unpopular position.
There is only one tried and true method for avoiding this unenviable fate. You must have full support and backing from your organizational leadership. Your approach and attitude about security must reflect theirs. For any security program to be effective, the security program manager and their staff must be supporting the rest of the organization in meeting the risk mitigation requirements of the leadership. In this capacity, the security manager is perceived as a helpmate and supporter in meeting corporate requirements. Obtaining that support and then becoming an integral member of the leadership team is covered in the next section.
OBTAINING CORPORATE APPROVAL AND SUPPORT
The most effective IT security programs are structured as a corporate commitment, not simply the brainchild of a security practitioner or information security group. If you or your security group is solely responsible for developing, implementing, and enforcing the security program, you will be held personally responsible for all related security violations and any security technology problems. You will also be held to account for the use of any and all resources related to your area of responsibility. Inevitably, you will also be held responsible for slowing up surefire moneymaking projects and preventing honest work from being accomplished.
An effective and successful security program begins with obtaining corporate or organizational support for security. The ideal situation is to seek a position where there is a stated organizational security requirement that is supported by everyone. These situations are not really rare, but they are fairly easy to identify. Security conscious organizations leave clues.
After the terrorist attacks of September 11, 2001, I took a keen interest in airline security. In the airline industry, there exists a glaring difference in the security programs of two of our nation’s largest airlines. I fly them both and have personally witnessed the dramatic differences. Airline A has obviously returned to a pre-9/11 security posture. Aside from the installation of reinforced cockpit doors, the flight attendants and cockpit personnel are back to moving casually between the flight deck and the main cabin. Passengers are allowed to idly stretch their legs around the forward galley and people move freely between the different cabins. There are no preflight security announcements. This cavalier attitude toward in-flight security encourages passengers and crew alike to disregard seemingly commonsense safeguards.
Airline B is markedly different. Flight attendants block the aisle to the forward galley and the flight deck with a beverage cart every time flight deck personnel need to use the head. The aircraft commander makes security announcements and passengers are prevented from moving between cabins. Travelers who congregate near the cockpit door are quickly dispatched back to their assigned seats. Although many may view these safeguards as an overreaction, they certainly provide a sense that at least one major airline is taking security seriously; however, Airline A gives the perception that security is unimportant, even in this era. Whoever is responsible for the security program at this airline needs to quickly reevaluate their program or find another field of employment.
You can quickly discern which airlines are described here by keeping an eye on security procedures next time you fly. See which airline has their employees taking security seriously. Listen for security announcements and watch as flight attendants, flight crew members, and even ground crew personnel go about their duties. The sense of (or lack of) security quickly becomes obvious.
You will find it is actually quite easy to determine which organization has the superior security program. Although each airline may have identical security requirements, Airline B has taken the rules to heart and treats security issues appropriately. You can witness it by seeing first-hand how these rules are enforced and through the everyday actions of their employees. Just like cleanliness at Walt Disney World, support for security within Airline B helps ensure everyone, including passengers, take security precautions more seriously, and thus make it a significantly more effective program.
An information security program is no different. I can usually tell within an hour of on-site analysis which organizations have effective information security programs. It is easy to determine. You can look for visible signs like:
- Security notices posted near computer systems and access points to computer and network resources
- Locked workstations
- Warning banners on sensitive applications
- Security checklists
- Security responsibilities spelled out in position descriptions for all employees with access to sensitive information
You can also divine the effectiveness of a security program from talking with employees:
- Those with access to sensitive information can easily explain their security responsibilities.
- Everyone can quickly identify those responsible for information security.
- Asking about information security does not merit a shoulder shrug or a giggle for a response.
- Senior decision makers know without prompting how information security is implemented and by whom.
These are the signs of an effective information security program. Look for the verbal and nonverbal clues that quickly show how seriously an organization takes information security. If you are the one responsible, ask someone outside your sphere of influence to give you some unbiased feedback. Security is as security does.
Ideally, you want to work where the sense of the importance of security is important. If you are unfortunate enough to get the task of creating an organizational environment, your most immediate priority will be to establish that security-conscious environment.
The McCumber Cube provides an excellent tool to start making the organizational leadership aware of the value of a sound security program. Perhaps someone already soured their interest in information security by providing tedious technical lectures about technology vulnerabilities. You can use the McCumber Cube to define the elements of security and seek their guidance and leadership in creating an effective risk management program that includes your information security requirements.
The best place to start is with a common language to discuss the elements of risk and security. By using the security attributes of confidentiality, integrity, and availability as well as the information states in lieu of technical jargon, you will be well on your way to creating an atmosphere of mutual respect that can be the beginning of this securityconscious environment.
CREATING PEARL HARBOR FILES
One of the interesting aspects of becoming a computer security professional is the inevitable requirements to create your own Pearl Harbor file. What are those? I can explain it best with a story.
I have a good friend who finally achieved some of the recognition he has so richly deserved. Tim had worked in numerous physical security positions over the years and had always worked after hours to improve his superior professional capabilities. When he had a government job, he sweated through years of evening college classes to obtain a baccalaureate degree and then went on to receive his masters as well. While others spent their free time pursuing relaxation or hobbies, Tim taught security classes for others and wrote articles and technical papers. He has always been a go-getter and I was truly pleased for Tim and his family when I found out he successfully competed for the position of Vice President and Director of Security for a Fortune 100 company.
Because I was in the same town as Tim’s company on a recent business trip, I decided to make an appointment to see him. I called his secretary two weeks in advance to schedule an audience with the new vice president. She said Tim was currently on a business trip overseas, but he would be back in town for my visit. I was just able to squeeze in for a short luncheon meeting because his schedule was already booked for the entire next month. I asked for directions to the downtown skyscraper that housed the company’s headquarters and offered to meet him at his office.
On the appointed day, I arrived nearly 20 minutes before our scheduled lunch and rode the elevator to the 32nd floor. I was directed to a plush lounge area just outside his closed office door that enjoyed an unobstructed view of the busy waterfront. I glanced around while I thumbed through the professional magazines and corporate literature that littered the coffee table. The office environment was the perfect depiction of corporate efficiency. Administrative people moved quietly between fax machines, printers, and computers. Telephones with muted ringing tones were quickly answered by courteous employees wearing tasteful dress business attire. I was impressed.
When his office door opened several minutes later, two individuals with date books and cumbersome folders walked quickly past me toward the elevators and pressed the down button. Tim emerged moments later and leaned over to say something to his secretary. As his eye scanned the waiting area, I was pleased to note the look of warm familiarity when he recognized me.
“John, how ya been?” he called out.
“Just great, Tim,” I answered as I jumped to my feet. “It looks like the home boy has done well for himself. Congratulations on the new job.”
“Thanks for stopping by while you were in town. I’m sorry I don’t have more time to give you. I’ve asked my secretary to have our lunch brought here to my office so we don’t have to waste time riding the elevators. Besides, it will be more comfortable here,” he said while escorting me past the secretary and into his office.
As I crossed the threshold, I noted the change in flooring. The functional office-grade carpeting of the waiting area changed to plush thickly padded rugs in colors that complemented the drapes and upholstered chairs. The large desk and other wood furnishings were all made of matching fruitwood with granite surfaces. Recessed lights provided soft, indirect illumination.
“Hey, man, this is a long way from government working conditions. Not battleship gray desk. No 1940s era rotating fan pushing around the fetid air. How do you manage to get any work accomplished in these surroundings?” I asked.
“I make do,” he smirked. Then he opened an armoire to reveal a large wet bar complete with glassware and carafes for hot beverages. “Coffee or tea?” he asked smugly.
I’ll take some black coffee and you can cut the act now that the door is closed. No need to play the big executive role with an old buddy.”
I’ll take some black coffee and you can cut the act now that the door is closed. No need to play the big executive role with an old buddy.”
“Where do you hide your booze?” and “Nice joinery work.”
I took mementos and awards off the shelves and felt their heft. I peered into coffee cups. As I was closing a file cabinet, a title on one of the files caught my eye. It simply said “Pearl Harbor.”
“What’s this ‘Pearl Harbor’ file?” I asked picking up the weighty stack of papers.
“Hey, stop rummaging the place. You must think you still work for NSA. And for Pete’s sake, put that file back. It’s one of the most important ones I possess. I’ve used that file for years, now.”
“If it is that important, why is it called Pearl Harbor and what’s in it?” I queried trying to sound innocently curious. His answer was quickly stifled by a knock at the door. He opened it and allowed the white-coated attendant to push in and unload the cart with our salads and iced tea. As we started eating, he said he would tell me about the file if I did not laugh. Here is what he told me:
“Early in my career, I was responsible for the physical security for a small group of government buildings. When I took over the job from a retiring civil servant, I had to reassess the security measures currently in place and make recommendations for security enhancements and other improvements. Any time the building managers would propose changes or additions to the buildings, they had to seek my input and approval for any necessary security enhancements. I also had to justify all the current and projected costs for security including salaries for guards, fences, lights, and anything else in the security budget.
“As my job responsibilities slowly grew, the government housed more people and more expensive equipment in the buildings. Of course, newer and better security equipment was being developed and the government security requirements evolved as well. In addition, the area around the buildings became a little more threatening. When I felt it was necessary, I would approach the facility director with a proposal to purchase newer security technologies such as cipher locks, surveillance cameras, and extra lighting. Each time he would ask me to write up a lengthy report to justify the expenditure so he could disapprove it.”
“You just said, ‘… so he could disapprove it,’” I interrupted. “Surely he didn’t always disapprove your proposals?”
“Of course he always disapproved them. In bureaucratic circles, you open yourself up to criticism from your seniors for approving new spending projects and God forbid you ever exceed your budget. If he approved or endorsed any new spending project not specifically directed by our agency heads, he became vulnerable. However, he never heard a peep from the headquarters if he simply disapproved the proposal at his level. And when it comes to security, it can be difficult to justify the expenditures because more often that not, you are spending money to guard against something that may never happen. However, I didn’t get discouraged. I always did a thorough job writing up the proposal and kept them in a file.”
“That makes sense; but what would happen if a security breach did occur—like equipment theft or a parking lot mugging after you had proposed something which could have prevented it?” I urged.
“There you have it!” he exclaimed. “That’s his Pearl Harbor—the unexpected attack! When a security violation resulted in a loss, we would resolve the problem and then have a post mortem meeting about it. For that interview, I would dig out a couple relevant proposals I had made over the preceding years and finally win approval for some needed enhancements.”
“Did he approve all of them?” I asked.
“Of course not, but I was usually able to push through some of the more urgent upgrades. It happened enough that I just started calling this my Pearl Harbor file.” His voice softened, then he asked, “You’re a consultant in the network security business. Don’t you recommend a Pearl Harbor file for your clients?”
“No, I don’t think so…hey, come to think of it, I guess I may have made recommendations to that effect. I never called them Pearl Harbor files before, but I have suggested to IT security managers to fully document all their proposed security enhancements, even if they’re not ultimately approved. This is an important part of any IT risk management program. Any security program upgrade—whether it is for the IT infrastructure or the buildings, people, and equipment—must be viewed in light of risk mitigation. It’s ultimately a business decision and not all of your recommendations will be accepted and implemented. The cure should never be worse than the disease.”
“But you must admit there are times even for you computer geeks when you are forced to say ‘I told you so.’”
“I’ve never been an I-told-you-so type of consultant,” I replied. “It sounds churlish and it’s not good for repeat business. I can only advise. However, I did make a mental note to rename some old files I have lying around.”
As we exchanged business cards and regards to each other’s families, I mused over a recent incident with one of my financial services clients. We had made recommendations last year regarding their e-mail server that were never implemented. The client phoned me just last week to ask for help. Someone had used their server to relay harassing emails and spam while disguising the real origin of the abusive communication. The sheer number of e-mails not only caused tie-ups with their Internet service, they also forced corporate communications personnel to deal with a flood of calls from angry recipients. Had they heeded our recommendations, they could have caught the problem before they were wrongly blamed for sending out abusive and indecent e-mails.
As Tim saw me to the elevator, we shook hands and I buttoned my overcoat. As we waited for the door to open, I said, “Do you know why I was prompted to ask you about the Pearl Harbor file I saw in your cabinet?”
“Not really,” he replied.
“Because the one in your file cabinet was the second one I had happened to see today. I earlier noticed that one of the two people leaving your office while I was in the waiting area was carrying out a file with that same name written on the tab.”
DEFINING YOUR SECURITY POLICY
To effectively develop and implement any security program, the first (and some would argue most important) aspect is to define your security policy. Developing security policy is not the subject of this book, so the presentation of policy development will be confined to significant aspects that are required to be able to effectively allow the security practitioner to apply the structured methodology.
In the most simplistic terms, security policy is defining what needs protection and to what degree. Because the IT security policy is one of risk management, it is critical to determine how these requirements interact with other corporate and organizational risk mitigation strategies. In most medium- to large-size organizations, security or risk management policies are rarely, if ever, found in one convenient document or set of documents. Security and risk management policies are often divided into areas of responsibility or among functional groups. There is most likely a set of physical security requirements that are logically associated with specific buildings or organizational facilities. These policies are the responsibility of the group or individuals chartered to manage and enforce the physical security of the facility and provide protection for its occupants and guests.
The human relations unit at a company is often the caretaker for organizational personnel security policies. These requirements are used to limit the organizational risk associated with personnel actions. Every personnel policy from employee prehire screening to exit interviews is simply a procedure or action to handle personnel activities in such a fashion as to limit the risk associated with the human element. By definition, these, too, are technically security policies.
Depending on the size of the organization and its business or mission objectives, there may also be a comprehensive risk management team. These standing committees often meet on an as-needed basis and require the involvement of corporate legal staff, senior decision makers, financial planners, technical experts, and others. These groups usually use the risk assessment process to determine the organization’s risk exposure for a variety of critical decisions. The results of their planning sessions are often policies and procedures formulated to effectively manage risk for key company initiatives. By definition, that is then a type of security policy.
Given this environment, the most effective way to manage IT security policy is to also frame it in its basic risk management context. In fact, IT security is just the type of strategic issue that should be dealt with at the higher levels of abstraction by decisionmaking bodies like the organizational risk management committee. By structuring the security investment and management decisions into either-or risk management language, the security program manager has the ability to achieve the commitment, support, and resources to be more effective.
The key to obtaining this support can be found in the proper use of security language. This book has already laid out the appropriate lexicon and a strict adherence to the use of words like threat, vulnerability, and asset ensures everyone is accurately communicating the issues at hand. Security can sometimes be an emotionally charged subject. Company executives can be offended when the insider threat is portrayed as a company leader with access to sensitive information resources. By sticking to metrics like the ones outlined in Appendix B, the security practitioner can focus on statistics and analyses devoid of presumptions and suppositions.
Another important aspect of this approach is the absence of complex technical information that most senior executives find challenging. If your security plan calls for you to request resources to purchase a new intrusion prevention capability, it may impress your superiors that you can describe the product’s response to intrusions or denial-of-service attacks based on the type and location of the event within the network and providing session termination, traffic recording and playback, combined with e-mail and SNMP (Simple Network Management Protocol) notifications. However, you are more likely to gain the support you need if you can put the problem in risk management terms and describe the risk mitigation capabilities of the proposed investment.
Being able to communicate in these risk management terms is central to an effective IT security program. To do so, some patient education may be required. Organizations that support a risk management committee are more likely to be able to quickly adapt to risk management analyses, but without such a group, grounding in the basics of risk management is necessary. However, a security practitioner will undoubtedly find the value in creating an environment where the issues can be discussed and decisions made with the least stress. This process is necessary to avoid the common pitfall cited in the next section.
DEFINING WHAT VERSUS HOW
For security practitioners, one of the keys to success is being able to successfully describe the the elements of information security. The McCumber Cube model supports this important philosophy. Historically, information security was centered on managerially imposing the How to the detriment of the What. In information security, almost all the enforcement technology we currently have available is based on process, the How.
Firewalls, encryption, access control, and even security administration are all built around telling the information systems how to implement a convoluted process that is supposed to enforce the dictums of the security policy. Currently, most of these technologies and point solutions are designed to simply prevent certain activities from taking place. For example, a firewall is designed to keep unauthorized users and data from entering an organization’s network. The firewall administrator must then go through a detailed and difficult process of defining specifically which processes and data are authorized and then programming the firewall to keep everything else out.
Every comprehensive review of information security describes the importance of having a security policy. Every computer security consultant worth his or her salt patiently explains to clients why they need this policy to accurately determine the efficacy of their security program. The policy forms the basis of all the discussions of What. Unfortunately, the consultant then must determine the degree to which the many components of security that make up the process (the How) effectively implement the policy (the What). This difficult game of abstraction is how the best consultants earn their high fees.
By now you might be asking yourself: Why not opt for products and tools that let you apply the What instead of expending all the effort to implement the How? Unfortunately, most security safeguard technologies are designed to be another link in the security process chain. These tools cannot enforce the What because they simply cannot implement an information-centric security policy. They can only implement binary technology-based security policies.
Take your medical records as an example. There are policies or rules regarding the use of this sensitive information that may be as simple as this:
- The patient may request and be allowed access to all information in their file at any time.
- The Records Department must document all access requests and use of these records. They must keep these records accurate.
- The hospital Finance Department may see and update charges, payments, insurance information, and other relevant fields, but must not have access to sensitive medical information.
- An authorized physician can gain access to your record (and may do so without your approval if you are incapacitated), but may not have access to your financial data.
- The medical insurance company may gain access with your approval for doctors’ diagnoses and other relevant data. If you refuse to grant this access, you may be denied reimbursement of your medical fees.
Now, think about all the IT security technologies and safeguards you may be aware of and try to imagine enforcing these five simple rules with complex network technologies like firewalls, public key encryption, access control systems, operating system tools, and application security products. After a few moments’ reflection, it is easy to see the difficulties of defining security technology processes for even a few simple security policy requirements in a limited systems environment.
Defining the What of security policies becomes a possibility only when we can develop the ability to apply these policies directly to the information assets themselves. In the example above, we would need to be able to assign these policies to the medical record itself. This is not only the most efficient way to translate information management requirements to functional implementation; it is also the most effective way to secure the information or data assets. If the security and management policies were thus tightly coupled with the record itself, then a centrally managed policy enforcement controller would be able to mediate any attempts by a person or other program to affect that asset.
Current access control and network-based security technology is already proving unable to adapt to the demands of the digital marketplace. Valuable information and digital assets such as music recordings and art are most effectively used when they can be shared with others. However, companies, copyright owners, inventors, artists, musicians, designers, and others must be the ones to set the rules to enforce their digital rights. These new information-based security technologies will finally allow us to realize the profits and cost savings promised by a worldwide Internet.
Information-based policy enforcement technologies like the one described here are just emerging. These new capabilities will open up completely new ways to share information and data, collaborate with others, and organize the cacophony of information that exists in most organizations. People will be able to feel comfortable opening up their networks, because they will have the ability to enforce exactly how each bit of data is used regardless of where it is being transmitted, stored, or processed.
Most creative and intelligent workers prefer the freedom that comes from defining the What as opposed to enforcing the How. Slavish adherence to processes over results is the domain of bureaucrats and assembly lines. The new digital economy demands that information security professionals create and manage ways to share valuable information and data assets while ensuring that they continue to play by the rules their owners have defined.
SECURITY POLICY: DEVELOPMENT AND IMPLEMENTATION
I recently visited two colleagues of mine who noted they were extremely busy. They both manage large IT security projects: one for a large U.S. government agency and the other for a commercial financial services firm. Each of these friends stressed how busy they were. Each of my lunch partners claimed a 60 plus hour work week and sleepless nights worrying about deadlines and requirements. I was intrigued to hear what efforts kept them so busy. Protecting company networks and data assets is certainly an important job and these guys must be getting nailed daily by bad guys to be this busy.
Over lunch, I asked them if the threats to their information systems had raised so dramatically as to force them and their staff members to adapt by putting in Herculean efforts to deal with the crises. Perhaps there was a new round of insidious viruses that were attacking their desktop systems or a rash of insider activity that was jeopardizing corporate data. As it turned out, the answers were surprising. In one case the flurry of extended hours and months-long effort was directed at completing a new round of risk analyses. In the other, the big crush was the development of the IT security policies that were required because of a company merger.
I asked why there should be such a significant work crunch in an organization to complete common risk analyses for its corporate IT systems. I naively asked if that was not a standard, albeit time-consuming aspect of the job for IT security experts. Both my guests rolled their eyes and said I must have been out of the corporate loop for too long. They both told horror stories of tedious documents of enormous size that had to be completed by teams of people incorporating reams and reams of hard-copy information. I was amazed. If it took months of dedicated effort to write these tomes, I asked, what could you possibly do with them?
This was where they both grew a bit sheepish. It seems these great analytical documents were ultimately used to prove to higher-ups and outside government agencies that their organizations cared about the protection of sensitive information. Apparently, the mindset was the bigger the document the more you cared. Little was being done to actually define and implement appropriate security controls.
.I followed up by asking about the development of security policies—again, another fairly standard task for IT security managers and their staffs. They both claimed the policy development efforts were major undertakings that absorbed the work of dozens of employees as they teamed up with lawyers and managers to define how information needed to be protected. In each of my colleagues’ cases, these policies ended up being published in large binders. I again asked about implementation issues.
In both organizations, it seemed policies were considered the domain of lawyers and managers looking to cover their assets in case of an errant or malicious employee’s exploitation of their computer systems. If something went wrong, the lawyers and senior managers could sanctimoniously proclaim that they had developed and published appropriate regulations that emphatically stated those activities that were considered unacceptable.
Even though I could foresee the response, I had to ask if they had planned to actually use these policies to implement the necessary authentication and authorization technologies that would enforce and monitor these security policies. Neither of my friends was able to define any such activity. It appeared that both were expected to exert strenuous, long-term efforts to publish documents about the state of their IT security in their respective organizations without any follow-up on plans to deploy enhanced security technology.
They went on to explain that security policies do not always translate easily into improved security and it is not always possible to interpret how targeted point solutions like firewalls, intrusion detection, and operating system controls will actually be able to implement the organization’s business rules. In other words, they were both working extremely hard writing documents about security, rather than investing these vital efforts into actually improving the technical capabilities to monitor, control, and react to security relevant events.
Most all of us are extremely busy. We expend the greater part of our working lives trying diligently to accomplish the difficult tasks laid out before us. For these security experts, it appeared that most of this busy time was devoted to doing little to improve the state of their organizations’ security programs. If you are going to invest all that hard work into your information security program, consider the end result of all your company’s exertion.
Developing and promulgating security policy is a critical and fundamental element of any security program. However, it must be an ongoing process that is interleaved with the myriad of other aspects of the program that include threat monitoring, vulnerability analysis, and safeguard implementation and management.