Don’t Trip the Sensors: Integrate and Imitate
Introduction
Congratulations! You’ve found or landed a promising position in a new organization. To grow that job into a successful career, you’ll need not only your 1337 H4x0r skillz, you’ll have to learn to imitate “the suits” and use your human network to navigate the business battlefield.
InfoSec is not an island unto itself. A study conducted by CIO Magazine and PricewaterhouseCoopers found that the average information security budget represented 11 percent of total IT budgets for 2004. Even organizations with a strong commitment to security averaged only 14 percent. You will have to integrate to climb the corporate ladder—both technically and figuratively.
To help you get ahead, this chapter explains how to take a systems approach to go beyond viewing security solely at the component level. You will get a crash course in project management that will help you understand how to balance what you’ve been asked to accomplish with the resources and time you’re given. We will show you how to work your way up the corporate ladder by seeing more deeply into what drives your work and how you can deliver even greater value to your management, leadership, and customers. Your desire to get ahead, coupled with the tools you will gain from reading this book, will make navigating the path to success both easier and more rewarding. Finally, because the demands and challenges you will face will grow along with your career, we will show you how to make the most efficient use of your time.
Hacking the System
You may have been hacking systems for years, but have you ever pondered the meaning of the word system? Some in the InfoSec field—particularly vendors— would have you believe that you can buy a package that will solve all your security problems. However, as you probably already know, security is not a product, and no single component is a panacea. Some vendors produce fantastic products, but it’s the system that matters.
Let’s start with an exercise to highlight the differences among security components. Try to think of a single component of security—just one component. No cheating on this one; you only get one choice. Did you pick a firewall, antivirus software, or intrusion prevention package? Regardless of your choice, consider its usefulness alone. Does your component do everything you need? Can it establish the identity of users and provide universal access control? How about protecting data as it traverses the network? Does it permit other applications to interact securely? Doubtful! (And if it does all the above, please contact us, because we’d like to know where we could get such a miracle product!)
Instead of relying on a single element, it is likely that you will need to integrate multiple components and use a systems engineering approach to get the job done. A system is a set of interoperating parts, each of which provides some, but not all, of the required functionality. A system is not just a piece of software or hardware. The aforementioned firewall, antivirus software, or intrusion prevention packages are not systems by themselves but must be brought together with other elements to form the system.
Building (or attacking!) a system requires the careful and purposeful assembly of a collection of interrelated elements or components working toward some common objective. Each component must fulfill some defined purpose. The component may be hardware or software and may also include organizational policies and procedures and operational processes. As the saying goes, the purpose, features, and capabilities of the system are far greater than the sum of its components (see Figure 9.1).
Here are a few examples of systems:
The automobile is one of the best examples because there are multitudes of components and subsystems that form the overall car. They have engines, fuel systems, brake systems, and most important if you are an audiophile, a sound system (see Figure 9.2). Hopefully, you change the oil periodically, because oil is but one critical element of the engine subsystem. Likewise, the overall functionality of the system would be significantly impaired without the braking system!
Factoring the Nontechnical Aspects of the System
The U.S. tax system illuminates the most often neglected system elements. The tax system is a great example of a system with fewer hardware and software elements and a greater reliance on policies, processes, and procedures. This system has multiple subsystems covering sales tax, income tax, and other factors. Of course, your income may be taxed at the federal, state, and local levels, which are additional subsystems of the overall income tax subsystem. Although protecting privacy isn’t of strong concern in the sales tax subsystem, the operational processes and procedures for income tax address security concerns. Try to imagine how well the system would work without those policies and procedures. Pretty scary isn’t it?
The tax system is not completely automated but also includes people. Visions of the Borg and assimilation notwithstanding, those people work together and use the hardware, software, policies, processes, and procedures to support the system’s operation. The overall system operation is the product of the functionality of the hardware and software and the functionality provided by the people running and using the system.
To understand why people are so important to the overall system, consider the following:
An automated system can grant or deny access to a facility based on the successful presentation of your badge, pin, and fingerprint, which constitute three-factor authentication.
However, a guard or other security personnel can decide whether or not you may pass if the system is down, you don’t have your badge, you forgot your pin, or you happen to be wearing a Band-Aid on your finger.
No matter how many (technical) security mechanisms your organization or project has put in place, people are often the weakest link. Whether you are responsible for incorporating security into systems, performing vulnerability assessments, or conducting other security testing, people are a big part of the security equation and can be the victims of social engineering—in IT terms, the use of certain techniques against humans to gain information or entry into systems; it involves such things as tricking people into revealing their passwords. Kevin Mitnick is probably the most famous (or infamous, depending on your point of view) figure who comes to mind during discussions of social engineering. Mitnick says in his book, The Art of Deception:
Social engineering uses influence and persuasion to deceive people by convincing them that the social engineer is someone he isn’t, or by manipulation. As a result, the social engineer is able to take advantage of people to obtain information with or without the use of technology.
Social engineering exploits may be executed in variety of ways:
A would-like-to-be user calls the help desk to request an immediate password change, due to a time-critical project he claims to be working on. Forexample, at the time of this writing, the U.S. Treasury Department’sinspector general for tax administration found continued shortcomings in the area of password protection. Auditors called 100 Internal Revenue Service (IRS) employees and managers and were able to convince 35 of them to provide their usernames and change their passwords to one suggested by the auditor. Although the audit showed this was an improvement over a 2001 review, it is nonetheless disheartening.
A seemingly innocuous onlooker watches you enter your ATM personal identification number (PIN) or computer login and password in a technique called shoulder surfing.
An attacker sifts through your trash (known as dumpster diving), looking for anything that will help him or her gain access to your IT treasures or financial information.
The best way to prevent social engineering attacks on your organization is to increase user awareness. Here are some good approaches:
Review your security policy to ensure that it addresses social engineering.
Train your users to protect passwords and confidential information.
Be cognizant of your surroundings while you’re typing passwords.
Require all guests to be escorted.
Update your operational security and incident-handling procedures to include social engineering.
Security awareness, training, and education (SATE) are key elements of a mature InfoSec program. Be sure that you give special consideration to the sensitivity of the data in your system. Your project might have a corporate service to rely on, but don’t make any assumptions!
Systems Security Engineering
You might be an expert pen tester, which requires specialized skills. Similarly, most hackers have exceptional depth on one or two platforms because staying current on every platform is a 48-hour-per-day job. As your career progresses, you will need to broaden your understanding of systems to enable you to make decisions on where functionality should be implemented. Some of the tougher problems are easier to tackle with hardware or human processes rather than in software. Systems security engineering focuses on the methods used to solve problems, not the just the solution of the problems Applying good systems security engineering practices and techniques is an absolute necessity given the complexity of today’s systems.
We have encountered software engineers who want to code everything themselves. Although that is a noble endeavor, it’s not always the best use of time, especially when there are libraries and tools available to build on. Of course, when the next ASN.1 or zlib vulnerability is discovered, you could be kicking yourself, but then again, security by obscurity isn’t the answer, either!
The following scenario might shed some light: Suppose you are developing a system that requires the protection of data in transit. Although you might have mad Java skillz and be capable of coding your own custom solution, you aren’t free. If you make $100,000 per year, spending a mere two weeks writing and testing will cost over $4,000! (Use the formula $100,000 divided by 1920 work hours per year 80 hours of coding = $4,167.) Of course, instead you could use any of a multitude of free and/or open source libraries, most of which have probably been tested more than your homegrown brew. Even if you opt to buy rather than build, it is unlikely that the license and royalties will cost you as much as developing in house, and down the road you will probably appreciate the commercial support they offer. However, remember that whatever route you take, the code is but one element of the overall system.
Systems engineering usually involves a variety of conventional engineering and science disciplines. For example, the design of the automobile we mentioned earlier will require mechanical functionality to actuate (start) the engine, a steering system to maneuver the automobile, and a braking system to stop the vehicle. Of course, most modern vehicles are filled with computers that activate and coordinate the machine’s various subsystems.
Systems Security Engineering Scope
The scope of systems engineering depends greatly on whom you ask. Even constraining the question to a single industry segment, the answers will probably vary greatly. In particular, varying opinions about systems engineering are greatest between research groups and organizations where development is more of an applied science.
Systems engineering is as much an art as a science, and you will find tremendous detail in other textbooks. To help you prepare to take on the new corporate challenges you’ll face, here we present a streamlined systems engineering approach that involves the following steps (see Figure 9.3):
1. Define the need Capturing customer needs and objectives (often referred to as functional and mission requirements captured in a mission needs statement or concept of operations).
2. Analyze and design Breaking down (or decomposing) the customer requirements into system requirements, which can be further decomposed into subsystem and component requirements, each with well-defined interfaces. (SE training materials often consider this process analysis and allocation.)
3. Develop and integrate Developing and integrating the components to form the system once you understand the need and requirements.
4. Deploy Deploying a system is the step that many organizations start with and governments never reach.
5. Test Verify that the system you worked so hard to develop actually meets the need!
Defining the Need
To figure out what you should be doing on any task, you first need to know what you have been asked to do. Have you ever gotten the wrong order at a restaurant? Unless you never eat in restaurants, it is almost a certainty that you have! Delivering solid InfoSec is much the same. You need to know what you have been asked to “cook up” before you can even begin to design, develop, or test a system.
We often characterize the details of “the order” as the need or mission, which are captured in a mission needs statement (MNS) or concept of operations (CONOP) document. Although you might not be responsible for capturing the need, understanding the significance of the original request is of paramount importance and will determine your ability to successfully deliver the system.
After working through the MNS or CONOP, you will be better prepared to break down or decompose the “order” into more granular requirements. Requirements can be categorized or viewed from a number of perspectives. Systems are said to have emergent properties, which are only present once the system’s various subsystems and components have been integrated:
Functional requirements Define in generally broad terms aspects of the system’s functionality.
System requirements Often specified by the IT organization; may include performance, scalability, or management requirements not requested by the user.
Reliability How much downtime can you afford?
Performance Minimum (or maximum, in the case of aspects such as latency) acceptable performance parameters.
Security Users tend to avoid these components since they slow down their ability to get things done. However, corporate governance almost always mandates some consideration for the overall security of the system.
Safety May be physical or logical and include topics such as whether to fail open (physically in the case of locked doors during a fire) or fail closed (logically in the case of a firewall).
Usability May include details such as ease of use or maximum time you can wait until the full resources of the system are available.
Why divide and categorize requirements? Most users or customers want to do real work. They don’t often care how the system is managed, and most couldn’t care less how secure the system is. They just want it to work! The requirements are divided and categorized according to generally accepted classes of stakeholders. The categorization helps associate the requirements in a given category with the stakeholder who owns them. A stakeholder is someone who has an interest in the system. Obvious stakeholders include:
You will find a full discussion of stakeholders, including those less obvious stakeholders who often have an indirect interest in your effort, a bit later in this chapter. In the meantime, here are some examples of stakeholders who might not be immediately obvious:
If you are called on to write requirements, make sure that you use the correct wording. Avoid using weak or indecisive words such as might or could. IETF RFC 2119 covers this very aspect of requirements. Here are some examples of well-written requirements:
The system shall maintain records of all student information, grades, and dates.
The system’s full functionality shall be demonstrable in less than 3 minutes.
The system’s user interface shall be implemented using W3C-compliant, standards-based protocols.
The system must allow students to search for records by name, course title, and date.
The system shall support at least 100,000 transactions per second.
The system shall not provide online student access to admission records prior to the intended date of release.
Requirements can also be viewed hierarchically (see Figure 9.4). Although fully understanding the user’s need is important, you will need to be able to account for other requirements, many of which could directly compete with or contradict the user’s request. For instance, the user might request 1Gbps throughput, but if the data is sensitive, the confidentiality and integrity security requirements could preclude you from developing a system capable of achieving such throughput.
Higher-level system requirements cascade to subsystems, modules or units, and individual components. Systems can be decomposed into smaller subsystems and then into even more granular elements or components. The subsystems are often developed in parallel. Decomposition makes tackling the development challenges easier and more manageable.
In particular, security requirements demand a careful evaluation of the data, the users, interactions with other systems, and other environmental factors. Larger organizations or efforts require additional consideration, especially where system reliability is concerned.
For instance, you could receive a request to develop and implement a wireless remote access solution. Although the requestor might state that they need access to a system or systems wirelessly and the user would probably be quite happy to have a completely open 802.11b/g access point, if you implemented such a system we doubt your management will be impressed to discover that your wireless system has been providing unfettered access to your competitors. It’s important to consider not only the users’ functional requirements but performance and scalability requirements along with management and security requirements as well.
We have all seen an equivalent implementation to this:
ipfw add allow all from any to any
If you are (still) interested in your career, it is certainly a much better approach to work through the statement of need, develop coarse-grained functional requirements, and mix in other system properties such as security, safety, and reliability. Don’t be pressured into neglecting your responsibility to do it the right way. However, you should spend time capturing the characteristics the system must not exhibit. Here are a few examples of undesirable characteristics:
System unavailability (or downtime)
Attacks on systems not under evaluation (pen testing)
Waiving or skipping security for airline pilots (or privileged users!)
One question you should ask while defining the need and capturing requirements is, How many people will use the system? It is very rare that the end user or requestor will be able to tell you how to scale the system. Their requirement for high performance is a given, but you should consider:
Take every opportunity to ensure that you understand the problem before you move forward. It is easy to overlook early in development and difficult to recover from situations where the requirements don’t reflect the actual customer needs. Getting the requirements wrong will cause late delivery of your system, which probably won’t meet user needs anyway.
However, don’t make hasty changes during development, either. There’s a very good reason that those who preach the systems engineering and project management disciplines hit change management so hard: It is very expensive to make changes or additions to the requirements once they have been agreed on.
There is no secret recipe for capturing, developing, and decomposing requirements. The process depends greatly on your environment. One approach that works well in most environments is to “live with” the users! It doesn’t matter if you are building a huge Web services system, performing vulnerability analysis, or conducting penetration testing. Unless exceptionally restrictive constraints are placed on you, working directly with the users and other direct stakeholders will help you considerably.
Although the good folks in marketing and sales often aren’t the most popular with the engineering staff, involve them in the requirements development process, if it makes sense to do so. These people often have the most intimate customer relationships and can give the most accurate characterization of what the customer wants. It doesn’t hurt to work with the end user to verify requirements presented by the marketing and sales staff. You could find that you can better define the requirements with the assistance of marketing and sales, since it is likely they understand the customer’s perspective and can broker communications. Engaging and integrating with all the business people you encounter will considerably help you move forward in your career. Finally, review the needs and requirements with all key stakeholders prior to moving on to analysis and design.
Analysis and Design
Once you have a firm grasp of the requirements, you can begin to design the system and analyze alternatives. Although the design of the system architecture is separate from the requirements, the two processes interface. It’s unlikely that you can build a functional system, much less a secure system, without successfully marrying requirements and architecture. Just be careful not to “pollute” the requirements with your architecture. We have probably all seen architectures hastily developed before the requirements are properly captured (a.k.a. a solution looking for a problem).
This is also the phase where you can begin to focus on cost. Hopefully, the customer already has some general idea of the cost. You will have to work with the customer to determine how to apply whatever funding they have available. For instance, in this phase of engineering you could come up with two major designs with wildly varying costs. One design might have much better scalability or security, but the cost might far exceed the funding available to the customer.
The context or perspective from which you are viewing security is important as well. Security is best implemented in layers. Often referred to as defense in depth, the approach can be viewed as similar to an onion, with the various layers protecting some aspect of the system. The seven-layer Open Systems Interconnect (OSI) model, depicted in Figure 9.5 (and the simpler four-layer Transmission Control Protocol, or TCP, model) provide a good foundation to analyze and evaluate the security of the system, whether your career requires you to build systems or hack them.
Understanding the implications of security at the various layers is also key to success. For instance, using IPsec, a layer 3 protocol, where encryption of data in transit is a requirement, is a great way to provide transparency to applications (ones that run on IP). However, the applications will not be “aware” that the encryption is present and therefore they cannot make informed decisions about how to process data. On the other hand, an application that implements Secure Sockets Layer (SSL) or Transport Layer Security (TLS), which resides above layer 4, might be able to make informed decisions about how to process a request based on a multitude of criteria such as:
Whether or not a client certificate is presented
A set of components that provide protection at various layers is good. A system that provides components that protect at different layers and communicate with each other is even better. The most advanced security development efforts incorporate the cognizant interoperation of subsystems and components. That is, the subsystems and components not only interoperate but also are aware of each other and can communicate and make more informed decisions. Recent developments in intrusion prevention systems (IPS) are leading the industry in the right direction, but they have only begun to scratch the surface of what is possible. Traditional file integrity-checking mechanisms such as TripWire do a great job of detecting (presumably unauthorized) changes to the file system, but newer technologies such as the Cisco Security Agent correlate events in the file system, network, and kernel or registry to prevent attacks.
One of the major problems facing large organizations is infrastructure authentication: providing access control based not only on the identity or role of the user but the infrastructure from which the user is coming. Of course, this is not tied to IP addresses alone but to some cryptographic factors. For instance, IPsec is designed to accommodate certificates, but what type of certificate will you use? Will your IPsec implementation employ user certificates, or will devices mutually authenticate before another layer of user-level authentication occurs?
There are many scenarios from which to choose, but we’ll start with a simple one: remote access for the sales force. Suppose that your sales force has access to sensitive engineering data. Perhaps this data is stored on a Web or file server on your network, which is protected by a super-impenetrable firewall (pf). Will you permit access to the sensitive engineering data from sales staff’s homes? How about when they are out on sales calls? Even better, suppose they strike up a conversation with someone at the airport and they’re ready to run a demo from the public machine at the airport cyber café?
The architecture might not mandate the specific protocols or implementation at this point, but it’s important to understand the context of security during this phase of development. Documenting systems as this point requires attention to the logical rather than the physical presentation of the system. You can capture the basic architecture using block diagrams, which will describe the high-level architecture of the system. The detail in the diagrams at this point is limited to the subsystems comprising the overall system and illustrates the relationships and interfaces between subsystems. Note that these are not data flow diagrams, which describe the interactions between subsystems and components in much greater detail. You will address this later in the development and integration phase.
Preparing for Failure
Regardless of the overall security posture of the system, consider how the system fails. Account for failure at every point of system. Consider not only the failure of individual components but people as well. Pay especially close attention to single points of catastrophic failure. Replacing an individual component that is readily available from multiple local vendors might meet downtime requirements, but the loss of a specialized component that cannot easily be replaced—or worse, the loss of a person identified as key—could paralyze your ability to operate.
Also consider whether the system must fail open or fail closed. It’s a good idea for firewalls to fail closed if the power goes out or the audit logs fill, but the doors to the facility should probably fail open. Imagine the lawsuit you would face if there were a fire and the doors kept people locked in!
Keeping It Simple
The KISS principle—Keep It Simple, Stupid—is a mantra of most good security engineers. Complexity is the enemy of security. The most complex systems are often the most difficult to deploy and even more challenging to test. Because complex systems have so many components, subsystems, and interfaces, there is much greater opportunity for failure or compromise.
Developing and Integrating (More) Secure Systems
During the development and integration phase, you must specify in great detail the components that will comprise a system. The architecture may articulate the map, but here’s where the rubber meets the road. Not only do you have to specify the components, you need to determine the precise configurations of those components.
Modular Bliss
Good interfaces are the glue that holds everything together in a system. Interfaces can be considered from the viewpoint of both software and interconnections between subsystems and components within a system (and with external systems as well). We can’t stress enough the importance of defining elements of interfaces, such as incoming and outgoing control and data. The protocol defines the language. TCP/IP is probably the most universally recognized example of a protocol. Capture the details of the interfaces in an interface control document (ICD). Precise interface definition is essential for the concurrent development that occurs in larger organizations (or open source efforts).
Here’s an even better real-world example: Decoupling is an important aspect of interface design, to reduce one component’s direct dependence on another specific component. Having well-defined interfaces enables components to be swapped or replaced with other (presumably better) components. Interfaces are often implemented in accordance with industry-standard protocols such as RADIUS, PKIX, CVP, and SSL.
The interface and the underlying implementation are mutually exclusive. That is, the specification of the interface and the protocol does not necessarily dictate the underlying implementation. The second version of the SSL protocol, invented by Netscape way back in the 1990s, was a flawed implementation. Although Netscape worked through the IETF to standardize the protocol and ultimately changed the interface to support better cryptographic support, the company also worked to address the underlying implementation issues. The aforementioned implementation flaws recently discovered in ASN.1 and zlib also demonstrate the difference between fundamentally broken interfaces and good interfaces with a broken implementation.
The use of modular subsystems and components also supports reuse. Rather than repeatedly designing new systems with the same (or similar) functionality, subsystem, component, and code reuse speeds up development.
Modularity has advantages beyond merely reusing components in future systems. It permits replacement or modernization of a subsystem or component as technology advances. The advances may be functional in nature, but they can also be security-related. For instance, Chinese researchers demonstrated the SHA1 hashing algorithm to be significantly weaker than previously believed. Because most systems implementing the SHA1 algorithm also include support for other hashing algorithms, the replacement of SHA1 with a newer, as-yet-unbroken algorithm is relatively trivial.
Of course, merely replacing a subsystem or component without adequate design consideration and regression testing can be a recipe for disaster. A great (or terrible, depending on how you look at it) example of what might go wrong includes the very same cryptographic changes mentioned earlier. In particular, devices or systems that include highly specialized application-specific integrated circuits (ASICs) demonstrate performance that is orders of magnitude better than systems performing cryptographic functions on general-purpose hardware.
Take an example. One IT manager (we’ll call him Bob) was responsible for boundary security in a large corporation. The organization had a widely deployed Cisco virtual private network (VPN) solution for branch offices and remote access. Bob was very diligent about getting new patches deployed quickly. So when Cisco put out new firmware supporting AES, Bob decided to immediately upgrade all his Cisco VPN concentrators. Unfortunately, Bob wasn’t as diligent about reviewing the “modernized” design and did not perform any regression testing.
The results were catastrophic! The help desk was inundated with support calls from users who couldn’t access the network. Instead of supporting thousands of 3DES VPN tunnels, the concentrators could only handle a few hundred tunnels. Bob didn’t realize that the specialized encryption processor (SEP) cards were custom-built for DES and 3DES. Switching to AES required more than just a firmware patch! Bob was called into the CIO’s office and flogged with a wet noodle. The moral of the story is that modularity doesn’t obviate the need to consider design changes and perform testing.
Defense in Depth
Finally take a close look at the completeness of security in your system. Encrypting could provide protection for data in transit or data at rest, but what about the endpoints? What about implementing policy at a boundary through which encryption passes?
Until recently, malware (read: virus) scanning software ignored the Alternate Data Streams (ADS) used in NTFS. Microsoft didn’t make great use of ADS beyond supporting resource forks for Macintosh clients—until the company released Windows XP. Windows XP uses ADS for storing items such as the thumbnails that are generated when you view a folder full of images. Now that NTFS—and ADS along with it—has become a part of the most widely deployed software, attackers are free to store their warez on your box. That’s right—your malware prevention software might not even see all the slacker tools and p0rn on your system. Thankfully, the major vendors, including Symantec and Network Associates, have addressed these shortcomings in the most recent versions of their software.
In a similar manner, albeit with a slight twist, Groove Workspace, a groupware solution, can “hide” data. Groove makes extensive (and quite impressive) use of cryptography. Sadly, it’s almost too much. Groove protects data in transit and at rest. Malware prevention software won’t even detect the presence of malicious code until it has been executed. In one of the FAQs posted on Groove’s Web site, the company acknowledges the shortcoming but insists that the data will be checked when opened, which is a terrifying proposition. A more complete security implementation would leverage the interfaces provided by the major malware vendors to quarantine and check data before opening or executing it.
Deployment
Deployment is often the most exciting phase of the systems engineering life cycle (for the customer, at least). It is the beginning of the realization of the customer’s need. Assuming that you began with solid requirements and successfully made it through design and development, deployment should be a piece of cake, right? Hopefully, it will be—as long as all your assumptions are correct.
The operational environment is not always quite as pristine as the lab. No matter how much planning, analysis, and modeling and simulation you perform, you will always discover subtle differences once you put a system into production. We recommend that you develop pilot systems and push prototypes into the production environment, if possible. Install a pilot system in the environment where it will be used. This is often easier said than done.
Scalability is one area where many development efforts fall short after deployment. You might think that refers to the number of connections a system can service or transactions per minute, but consider physical size as well. Perhaps you were given solid technical requirements and the system you are ready to deploy can meet them all. However, the customer didn’t specify how much space the system must or must not occupy, so you could run into problems when you go to deploy the three-rack system at a branch office that has only one free rack.
Deployment is often a slow, difficult, and expensive endeavor in the development of large systems. You may run into a variety of problems, such as:
Testing
There are four basic phases of testing. You should start by testing individual components first to ensure that they meet the requirements assigned to them. System testing will prove that the operation of the overall system meets the aggregate requirements. Security testing will demonstrate that the system meets the security requirements assigned. Security testing is often misunderstood, and we’ve seen independent security testers evaluate every single component against every security require-ment. What you have to remember is that it’s the overall system that matters. Security testing must address the security requirements of the system—not each component as an island. Finally, user acceptance testing will (hopefully) prove that the system meets the customer’s needs.
We can’t stress enough the importance of piloting (small, incremental rollouts) and lab testing prior to full deployment and formal testing. It can be dangerous to move into the production environment without prior testing and planning. We have seen pen testers hack into the wrong system, causing damages to the organization and loss of revenue. We have also seen subtle changes in the production environment wreak havoc on systems that work perfectly in the lab environment. The moral of the story is that you should test early and test often. Where components may be used in multiple systems or architectures, it makes sense to type-certify the component to avoid repeatedly and redundantly testing systems. In most cases, the acceptance of evidence produced in the development and testing of the type-certified system and testing can accelerate subsequent developments that may leverage the component.
Hacking the Network
Unless you’re a one man/woman show—in which case, please go ahead and promote yourself immediately—you are probably going to be working with other engineers, project managers, and staff. One of the most valuable lessons you can take away from this chapter is that in the work environment, you won’t succeed on technical merit alone.
Managing Projects
You will have to work your (human) network, play nicely with others, and learn to manage projects. It’s important to note at this point that a project is markedly different from a program. Programs have far-reaching ambitions and run in perpetuity, whereas projects have very specific objectives and a finite life.
Companies, especially large organizations, often exclude the project manager during the early phases of a project. You have undoubtedly seen organizations give a wish list to the project manager at the development or deployment phase. Of course, the manager is directly responsible for many significant problems. If you have been asked to engage a project midstream, we strongly encourage you to seriously consider what you’ve been asked to accomplish. At the very least, go back to the MNS and review the requirements. Although it’s flattering to be the “go-to” hacker, you might also be made the scapegoat in a doomed project!
Systems engineering and project management have many things in common, as you will see shortly. Both begin with a “need” of some kind and must have solid requirements to build against. They also require you to engage (multiple) stakeholders, but if you’re the project manager, you will end up playing the role of negotiator far more often!
As the project manager, you will have to negotiate the interests of all stakeholders as you work to define:
Projects have four basic phases:
Initiation
During the initiation phase, which is very closely aligned with the first phase of systems engineering (defining need), you must establish the project’s objectives. You may also play the part of recruiter as you build your project team. Finally, you will set the expectations of all parties after reviewing the objectives and requirements.
You probably won’t get everyone to agree about everything all the time, but you must at least get consensus on what the project must accomplish. Properly capturing and defining the scope of the effort is the most critical part of the initiation phase. If you don’t have a clear picture of the boundaries of your project, you can’t possibly know what to deliver.
In cooperation with your team, define the project’s objectives in as much detail as possible. The old adage “garbage in, garbage out” applies. The objectives must be:
Don’t get into the implementation at this point. Focus on the outcomes you seek. You will define how to get there in a bit.
After you’ve captured clearly defined, realistic objectives, ensure that each member of the team, along with key stakeholders, has a copy of the project’s objectives. This will keep everyone focused on the project and its goals.
Planning
Following the initiation phase, you will break (or decompose) the objectives into discrete tasks. Those tasks will become a part of your plan and the basis for the schedule. Each task will be assigned to a specific member of your project team. The tasks must be:
Once you’ve compiled a list of tasks, you will develop a plan to address each one. To make optimal use of your resources, you should try to schedule as many of the tasks in parallel as possible. Although some tasks will depend on others, you will discover many that don’t have dependencies. However, you aren’t scheduling the tasks yet—just sequencing them.
While you’re in the process of putting the tasks into steps, you should consider what development methodology best suits your project. The waterfall method, where development is conducted in a linear fashion, has traditionally been favored for most large efforts. In the past few years, RAD, spiral development, Extreme Programming (XP), and other forms of iterative development have gained in popularity. In fact, many companies, including the likes of Google, the Mozilla Foundation, and even Microsoft, now use some form of iterative development.
After you’ve finished documenting the sequence of the tasks, you must identify milestones that represent meaningful achievements. Specify dates when the milestones will be completed.
Scheduling is daunting without the proper tools. We suggest that you use Microsoft Project, FastTrack Schedule, or Primavera Project Planner (P3). Gantt charts (see Figure 9.6) are powerful visual representations that depict how the project’s tasks overlap and relate to each other. They also help you estimate costs and prevent you from “oversubscribing” individual members of your project team.
Look for conflicts of resources in your schedule beyond just people. Resources—the things needed to accomplish the project objectives—can include:
For instance, pay careful attention not to simultaneously allocate specialized test equipment and other hardware that different (or in this example, competing) tasks require.
The project manager is responsible for tracking actual progress against the (planned) schedule. Team members do not typically update progress themselves. However, successful coordination and communication will be a key factor in the success of your effort. Set up an e-mail alias and a project Web page where you can post the status. Give the URL to your customers and key stakeholders—you’ll probably get fewer calls as a result!
This is where the greatest amount of negotiation occurs. You have to balance the schedule against the tasks and the resources you have available. The customer might ask you to compress the schedule. You might be able to accommodate her wishes with more resources, which, of course, will increase the cost. Customers who ask you to cut funding might have to de-scope the project to reduce the cost. Don’t be afraid to push back with the customer when asked to do the same tasks with reduced funding; this will happen over the course of your career.
Identifying risks and developing mitigation plans will help you deal with Murphy’s Law (whatever can go wrong will go wrong). Dealing with unanticipated problems requires more money and comes at the expense of your schedule. Put together a risk management matrix to identify potential pitfalls and the likelihood of occurrence. Then list a mitigation (or backup) strategy. (Think of it as “Plan B” in the event something goes wrong.) The mitigation certainly won’t eliminate the problem, but it will go a long way toward minimizing the impact to the project.
Review and adjust your budget against your newfound understanding of the anticipated risks. This is commonly referred to as padding. It is also a good time to search for lessons learned or reports from other similar projects completed. We have calculated risk factors in our own projects of years past. Depending on the significance of the risk, the factor may be as small as 5 percent or as much as 50 percent. Many textbooks recommend keeping padding to a minimum, but we advise you to be realistic. You didn’t create the risk, but you have to be prepared for it. You don’t have to point it out to the customer or end user—just include the factor across the board, at least for labor, and move on.
Finally, setting expectations is key to ensuring the success of your effort. This activity is a natural extension to the requirements development process. Users will often ask for the world. Make sure they understand what you can and can’t do before you begin development. It’s also important to get management on board and set their expectations. Let them know:
What you’ve been asked to do (the requirements)
What you are capable of delivering
How it fits into the enterprise architecture. If you are developing a custom solution that doesn’t fit into the enterprise, let them know. Hiding it will only make things more difficult later!
Before moving on to the execution phase, get someone to sign off, indicating their concurrence with the plan, schedule, and budget. At the very least, get the approval of someone in your chain of command (read: your boss).
Executing
This might sound silly, but you have to start execution on time. Since you’ve done all the right planning, you should have the resources you need to get the project done. Hold a kickoff meeting on the project start date to get things started right. You should have a meeting or conference call schedule ready at the kickoff so everyone knows when and where to sync up.
As mentioned before, the project manager is responsible for coordinating the overall activity. Be sure to encourage every member of the team to bring issues to your attention at the earliest possible time to afford you the best opportunity to adjust your resources.
However, things will go wrong no matter how well you planned. This is the very reason that you filled out that risk management matrix earlier. (You did do that, didn’t you?) Development rarely goes as precisely as scheduled, so don’t fret when you have to make adjustments.
Ensure that everyone documents the activities associated with their respective tasks. Responsibility for documentation should be delegated to whomever you assigned a task. This is probably the most often jettisoned aspect of projects. Doing so will only set you back later, so don’t be tempted to cut corners on documentation, especially early in the project execution phase.
Finally, have everyone on the team send you regular status updates, and share the collective status with the rest of the team using the e-mail alias you created in the planning phase.
Let’s face it: Meetings happen. Although you might be a participant in meetings early in your career, it is likely that you will have to run meetings as your career blossoms. Here are some pointers that will help you get to the point and keep your focus:
Distribute the meeting agenda in advance. Make sure you let everyone know the meeting location and topics, which you’ll need to keep the meeting on track.
Start promptly at the designated meeting time. Waiting for people to arrive will only frustrate those who arrived on time and reward those who are late.
Make sure everyone is acquainted. You can either introduce each person or ask them to introduce themselves.
Encourage everyone’s full participation. Don’t exclude or belittle anyone. It’s a delicate balance, especially when you are working to stay on track.
Keep track of meeting “metadata” such as the meeting date, time, location, and list of attendees.
Record (or delegate) meeting minutes. Pay especially close attention to decisions, action items, and key suggestions.
Make every effort to keep the meeting on topic and encourage people to move on if they diverge too far from the point.
Wrap the meeting up on time. Of course, it’s fine if you finish early, but be careful not to run over.
Closing
After your project is finished, you should take a look back and assess your performance. In the final team meeting, explore ways in which performance could have been improved. There’s treasure in your “lessons learned,” and capturing your experience will help prevent similar problems in future efforts. Some contracts require a Lessons Learned document, especially if this is the first time they have done a particular project.
Put together an executive briefing, and share the results of your assessment. Here are some of the details you should consider including:
Escalating Your Privileges
Moving up in your organization requires you to continuously grow. The Japanese have a single word to describe continuous improvement: kaizen. You will not only have to employ kaizen to your technical skills, you’ll have to hone your business skills as well.
Getting to the Bottom of Success
How do you measure success? It’s a rather tough question, and the answers vary wildly depending on whom you ask. Measuring success depends greatly on your perceptions or expectations. Part of what drives your perceptions of success is your notion of what is valuable.
Value can be defined as an amount of goods, services, or money considered to be a fair and suitable equivalent for something else; a fair price or return; worth in usefulness or importance to the possessor.
The most critical part of determining value is perspective. If you are a contractor, the customer’s perspective reigns. Regardless of your perceptions of value— and try as you might to sell your own position—the customer will determine what is valuable. Likewise, your boss will determine your value to the organization when giving raises or bonuses.
Setting expectations with your customers and management will ensure that you have a mutual understanding and basis for measuring success. The phrase setting expectations doesn’t mean you should argue your case for what’s important or valuable. Rather, it means that you come to an agreement and mutual understanding with other key players on how to measure success.
For instance, your customer might want a system with everything (and the kitchen sink) delivered immediately, for free. (Of course, this is an extreme example, but we’re confident you can relate!) Blindly accepting this task is obviously a recipe for disaster. Taking the time to work through what the customer wants and what you can deliver will more accurately align your expectations with the customer’s.
Finding Management’s Vulnerabilities
Finding management’s vulnerabilities (a.k.a. identifying gaps and exposing opportunities for improvement) will demonstrate your insight and commitment to the organization. One great technique known as SWOT analysis (short for strengths, weaknesses, opportunities, and threats) is often used for this very purpose in strategic planning. It was developed at Stanford Research Institute (SRI). SWOT analysis, which has something in common with risk assessments, works by identifying your internal strengths and weaknesses and external opportunities and threats (see Figure 9.7 and Table 9.1).
You can perform a SWOT analysis in many different ways. For instance, you can do a SWOT analysis at the start of a project to consider strategic aspects of the effort before you engage (and get potentially bogged down). Companies can also use SWOT analysis techniques to identify their own strengths and weaknesses while gaining a better understanding of the market and their competition. Finally, you can perform a SWOT analysis of yourself! Go ahead, explore—but don’t forget that focusing only on strengths and sugar-coating or ignoring weaknesses only hurts you.
Being the Great Communicator
Being a great communicator means giving your customers and management the right message at the right time. Whether you interact in person, on the phone, via e-mail, or by instant messaging (IM), use good etiquette and make sure the method of communication suits the material.
Face-to-face meetings give you the opportunity to assess not only the spoke word but also tone and body language. Talking with people on the phone will still get you the tone, but you will no longer see facial expressions or body language. This seems obvious, but it is amazing how quickly we forget these simple details. Follow these tips when meeting in person or talking on the phone:
Be positive. Don’t ask, “Did I catch you at a bad time?” That kind of question predisposes people to say yes. They’ve been waiting for sound engineering for quite some time, so ask them “Did I catch you at a good time?”
Don’t waste your time figuring out politically correct ways of saying things(he/she or her/him, etc.). If someone is in the position of chairman, don’ttry calling him a chairperson (unless, of course he/she uses that phrasehim/herself!).
Be especially careful when communicating via e-mail and IM. The other party can’t see or hear you, and it is really easy to misinterpret information or intention. Although routine discussions via IM and e-mail are fine once an effort is under way, save yourself a headache and discuss sensitive issues in person or on the phone. Finally, we strongly suggest that you avoid multitasking with other phones, computers, e-mail, and IM at the same time as you’re conducting a conversation with your customers or management.
Knowing When to Talk (and Not!)
One mistake that you will want to avoid is misjudging your target audience. Techies from all walks of life, such as software developers, security engineers, and pen testers, tend to be exceptionally detail-oriented people. Although the ciphers you select for your SSL implementation are important and the firewall ruleset is certainly important, make sure that you consider the audience before you present information.
That’s not to say you shouldn’t share information! Quite the contrary—becoming a great communicator will substantially improve your career. One of the things great communicators do is to present the right information at the right time to the right audience. How do you know what’s right? A few examples will help illustrate:
You are briefing the CIO about a software project. The organization has already made a significant commitment to the software used in the package, and there’s plenty of funding. You have a philosophical ax to grind with the software company and take the opportunity to share with the CIO your opinion of the software’s licensing shortcomings. Bad idea! Remember, you are interested in building a career, and while your opinion may have merit, you probably won’t get a good reaction. In fact, you could hurt your career.
While attending a SANS Conference, you discover that the wireless access points run by the conference personnel are using self-signed SSL certificates to authenticate users. (Of course, there are probably a bunch of spoofed APs in addition to the legitimate devices!) When the speaker reaches the topic of wireless security, you take the opportunity to share your discovery and ask questions about the implications of using a self-signed certificate. Your questions may generate some serious debate and lead to further discussion during the break. Your discovery is certainly relevant, and the audience probably has a good appreciation of the topic.
The key to determining when and where to present information is considering how it will be received, given the audience and environment. Stay focused on the topics at hand and win the trust of your management and the organization’s leadership. Stephen Covey says it best in The Seven Habits of Highly Effective People (see Figure 9.8):
We each have a wide range of concern—our health, our children, problems at work, the national debt, nuclear war. We could separate those from things in which we have no particular mental or emotional involvement by creating a “Circle of Concern.”
As we look at those things within our Circle of Concern, it becomes apparent that there are some things over which we have no real control and others that we can do something about. We could identify those concerns in the latter group by circumscribing them within a smaller Circle of Influence.
By determining which of these two circles is the focus of most of our time and energy, we can discover much about the degree of our proactivity.
Proactive people focus their efforts in the Circle of Influence. They work on the things they can do something about. The nature of their energy is positive, enlarging and magnifying, causing their Circle of Influence to increase.
Reactive people, on the other hand, focus their efforts in the Circle of Concern. They focus on the weakness of other people, the problems in the environment, and circumstances over which they have no control. Their focus results in blaming and accusing attitudes, reactive language, and increased feelings of victimization. The negative energy generated by that focus, combined with neglect in areas they could do something about, causes their Circle of Influence to shrink.
Once you have expanded your Circle of Influence, you will find the support you need to take on more controversial issues. Just make sure that you continue to maintain good situational awareness.
Managing Your Time
To make the best use of your time, you have to be not only efficient but effective. We have worked with many engineers who understand efficiency. Efficiency is a measure of your ability to achieve something with the least energy or effort. However, the measure of how effective something is can be a bit more difficult to determine. Effectiveness is a measure of what you do with the time you have available.
It is possible to be efficient but not effective. You have probably heard of people “getting a lot done but never truly accomplishing anything.” To be effective and efficient, you must first choose what to do with your time and then do it with the least amount of energy or effort.
To begin to understand how to be more effective, consider the relative importance and urgency of a given request. Important issues are significant regardless of time. An urgent request is one that must be filled right away and might not be of major consequence beyond that point in time.
Some examples of important items include:
Table 9.2 is a chart divided into quadrants. The chart visually depicts the urgency and relative importance of various tasks.
This might seem harsh, but you should completely ignore or put off helping your coworker fix her grandmother’s slow computer. If you want to be effective, spend time doing the things that are important but not necessarily urgent, which fall into the green quadrant. Most folks are overwhelmed by urgent tasks, so you should carefully evaluate who says the task is urgent and whether or not it’s actually important. Otherwise, all your time will be consumed by things that prevent you from being effective! A fantastic way of keeping your bearings is to start each day with a plan of action. Without that plan, others will find a way to run your day for you. Take control and plan your day around those important activities.
Keeping a good work/life balance is a critical element of a successful career. Focusing only on work comes at the expense of your health, family, and social and spiritual well-being. You don’t have to spend equal amounts of time in each area. However, you will burn out quickly if you don’t maintain some balance.
In particular, neglecting your physical health will eventually impact your performance at work. We know many engineers who never exercise and don’t get enough sleep. To have a successful career, you should budget enough time for sleep. Regular exercise will improve the quality of your sleep. Although these aspects of life might seem like a waste of time, you will be sharper both on and off the job.
Keeping your desk organized will also greatly improve your work life. That messy desk is only hiding what’s important to you. People with a mountain of paperwork and other junk on their desk spend nearly eight hours per week searching for things. Imagine what you could do with all that extra time!
Finally as it becomes increasingly difficult to find time to work on important but not urgent items, set aside some quiet time in a place you won’t be disturbed. The intent isn’t to become isolated. Remember, the demands on your time are the result of your success! Close your office door. If you work in a “cube farm,” we recommend that you come in hour earlier than everyone else or stay an hour later. (We suggest the former, since you are more likely to be worn down at the end of the day!)
There are many different tools and methods for getting organized. Of course, you can use paper organizers offered by companies such as Day Runner or FranklinCovey. However, we recommend that you make the greatest use of technology through the use of groupware and a personal digital assistant (PDA). A few of our favorite PDAs:
palmOne Treo 600 Verizon has the best coverage, but you’ll pay more. Cingular/AT&T are a close second.
Sharp Zaurus Especially good if you want more functionality than a mere organizer provides.
Whether you use Windows, Linux, or Mac OS X, there are plenty of choices for organizing software. Here are a few software packages we have found useful:
Llamagraphics Life Balance for Windows, Mac OS X, and PalmOS (this has got to be one of the most impressive pieces of software produced in recent years!)
FranklinCovey PlanPlus for Windows
Palm Desktop for Windows and Mac OS X
Mozilla Foundation Thunderbird and Sunbird for Windows, Linux, Mac OS X, and others
It doesn’t matter what you use as long as you use it! Just make sure you take all the appropriate security precautions—after all, you are in the InfoSec business!
Checklist
The following list of questions combines many of the joint elements present in systems engineering and project management to help guide you.
Schedule, Plans, and Constraints
Have the constraints (including time, people, and money) been identified?
Do you know which constraints are more flexible?
Has an initial project plan or strategy been developed?
Have you completed a preliminary budget or rough order of magnitude (ROM)?
Does the ROM include everything necessary to succeed (including not only systems engineering but project management and other outside services)
What tools will be used to manage the project and engineer the system? Does everyone have them?
Development and Integration
Have you created data flow diagrams?
Are the subsystems and interfaces (with clear inputs and outputs) identified?
Are there documented test procedures that demonstrate that the system meets the requirements?
Has the system undergone user acceptance testing and gotten user approval?
Certification (or security) testing?
Has management accredited and formally accepted the system?
Has training been given to the users, system maintainers, and others?
Documentation
Is there an architectural overview of the system, complete with subsystems and interfaces to other systems?
Do the data flow diagrams cover all aspects of the system’s operation?
Does the documentation include user guides?
Is the user documentation written clearly and expressed in terms the user will understand (without technical jargon)?
After Action
Has management accredited and formally accepted the system?
Is the system or some product of its development reusable?
Did the team make it under budget?
Was the system cost-effective?
Has the (actual) return on investment (ROI) been calculated?
Have “lessons learned” been captured?
Are members of the development team available for consultation and troubleshooting following deployment and testing?
Risk Management Matrix
Table 9.3 presents a matrix you can fill in on your own to assess and manage risk.
Risk Short description of the risk
Severity Assessment of the severity of impact (should the risk actually occur)
Probability Likelihood that the risk will occur (expressed as a percentage)
Impact Cost, schedule, or performance
Strategy Your strategy to manage the risk (including mitigation, acceptance, etc.)
Budget
There are many different ways to generate the numbers in the budget, but we strongly advise you to roll the risk factor into each element before generating a total (as opposed to generating the total and then multiplying by the risk factor). Your boss or your customer might ask you for a detailed breakdown after you give them the total. Building the risk in from the beginning will prevent confusion.
Strategic Planning
Answering the following questions will greatly help you understand the players:
Have you identified all stakeholders?
Do you know what is driving them in general and what their specific interest is in your effort? (Try to go a level or two deep to determine why they have a specific interest.)
Do you understand what each stakeholder has to gain or lose in this endeavor?
Have you thought about the needs and concerns of each individual?
SWOT Analysis
The template in Table 9.4 will help you capture and better understand internal and external factors:
Time Management
Use the matrix shown in Figure 9.9 instead of a to-do list to ensure that you work on what’s truly important to your projects. Try to spend the greatest amount of time working on tasks that are important but not necessarily urgent—the area noted in green. Although people who ask you to do non-urgent and unimportant tasks might disagree, you can totally ignore those tasks (noted in the red area). The tasks that fall into one of the two yellow areas will require additional consideration before you act on them.
Summary
Applying the basic systems engineering principles presented in this chapter will enable you to contribute on a much broader scale. You might have worked at the component level before, but building, evaluating, or testing systems will take your game to the next level. The key is to look at completeness in the security of the overall system.
The crash course in project management you’ve just been through could come in handy as your (human) network grows. You should now have a solid foundation on which you can build as you are given bigger challenges to manage. Now that you can see more deeply into what drives your work, you can deliver even greater value to everyone with whom you interact.
Finally, once you have completed a SWOT analysis of yourself, you should have a better understanding of where your strengths lie and what you must improve to continue to excel. You will be ready to face the increased demands on your time by more judiciously choosing where you spend your time due to your new (or renewed) understanding of how to manage your time.
Links to Sites
CSO Online: The State of Information Security 2003 www.csoonline.com/csoresearch/report64.html
CIO Magazine: The State of Information Security 2004 www2.cio.com/research/surveyreport.cfm?id=82
Day Runner – www.dayrunner.com/default.asp
The Associated Press: Auditors Find IRS Workers Prone to Hackers www.securityfocus.org/news/10708
Mailing Lists
www.c4i.org/isn.html INFOSEC News Privately run, medium traffic list that caters to the distribution of information security news articles.
www.counterpane.com/crypto-gram.html Crypto-Gram Free monthly e-mail newsletter on computer security and cryptography from Bruce Schneier.
www.sans.org/newsletters SANS (SysAdmin, Audit, Network, Security) Institute. Established in 1989 and has become a information security training and certification stalwart.
www.fastcompany.com/cof/ Fast Company Magazine. Launched in 1995 to “chronicle how changing companies create and compete, to highlight new business practices, and to showcase the teams and individuals who are inventing the future and reinventing business.”
www.incose.org/chapters/findachapter.aspx INCOSE (International Council on Systems Engineering) Professional society for systems engineers in industry, academia, and government.
www.pmi.org/prod/groups/public/documents/info/gmc_chaptersoverview.asp PMI (Project Management Institute) Chapters Dedicated to Project Management with chapters and special interest groups worldwide.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. You will also gain access to thousands of other FAQs at ITFAQnet.com.
Q: How are people part of a system?
A: Systems include hardware and software but people operate the system. In highly secure systems, people are often the weakest link and thus become a critical element in the system’s composition.
Q: My customer is eager for me to begin wor k and my boss wants me to go ahead and start. Should I?
A: Don’t give in to your customer’s desperate pleas for help and “hit the ground running.” Of course, you can’t say you won’t help them. However, you absolutely must properly define the customer’s need and scope before proceeding with will have to deal with the customer’s expectations eventually so get it done up front.
Q: How much should I pad my project?
A: There isn’t a fixed percentage that works everywhere. Perform a quick risk assessment and use your instincts. If you have a very good understanding of the customer, need, environment, and technology, it will probably be small. Risky business requires a bigger cushion.
I Q: How can I get ahead in my career?
A: Find out what’s important to leadership and management of your organization. Read the strategic business plan and use SWOT Analysis to find the gaps and voids they worry about.
Q: How do I say “no” to urgent but unimportant requests?
A: Practice saying “Gee, that looks like a tough problem but I can’t help right now.” There’s a scene in Batman where Michael Keaton is preparing to tell Kim Basinger that he’s Batman. Sometimes just hearing yourself say it will get you ready. You can also put the decision back on management. Ultimately, they have to decide what’s truly important. Just ask them which task they don’t want you to do and they may do the hard work for you!