A university I once worked with decided it was time to allow the student body and faculty wireless access to the campus network. The convenience of access, cost reduction in wiring buildings, and potential productivity increase were the overarching business drivers for the decision. At first blush, however, the security department was reluctant to proceed.
For years, the university did not require students to have accounts to access the network. Rather, authentication was required only when students tried to log in or access certain managed servers and services. Further, as is commonly the case in educational environments, the network was viewed as requiring little policinga Wild West frontier town where the importance of sharing information usually trumps a security concern if they ever conflict. Moving to wireless raised a bevy of concerns with the security team, as follows:
It is worth noting that in the existing wired environment, little port security had been implemented, and the internal network was rather wide open to sniffing and other attacks that emanated from within the campus network. Clearly, the security team's concern over wireless illustrated how they judged the new technology by a double standard because the existing environment was not being held to the same scrutiny. But regardless of the policy enforcement inconsistency, the Security Operations (SECOPS) team still desired to do its utmost to address the perceived wireless vulnerabilities. Unraveling the situation a little more, SECOPS discovered there were three major factors to understand in this decision about WLAN deployment (see Figure 1-1). The flow detailed in this figure is discussed in much greater detail in Chapter 2, "Security Policy and Operations Life Cycle."
Figure 1-1. Business Priorities
Reconciling the business drivers and security concerns is the heart of the axiom, and really all the axiom states is who wins when there is conflict. The decision is actually easy: business priorities must come first. That is absolutely necessary to ensure that businesses can continue to evolve. This includes embracing new technologies, moving operations online, and integrating services more tightly than before.
So, what is a security designer to do? If the requirement is to do what the business dictates at the expense of securing the systems, why even have a security department? Two tricks can make your life easier.
First, realize that the relationship between business objectives, the security policy, and security design is symbiotic. Although it flows from the top down, you must draw lines from the bottom up, too (see Figure 1-1). It is the responsibility of security designers to ensure that security implications and trade-offs are introduced as considerations in business planning. To do this well, it is necessary to link back to the security policy. You must ensure that no double standards are being applied and that all relevant threats have been considered or, at the very least, noted and ignored. Remain clinical and consistent in discussing alternatives and ramifications in meeting new business demands. This will result in more educated decisions being made by senior management. In the sample case, the university embarked on the wireless project. In addition, the university recognized that the security policy was not being applied consistently, and a separate initiative was investigated to review the wired network.
Second, successful security design approaches try to envision and easily allow for the next wave of requirements. You don't want to have to continually revamp systems and architectures as the business needs evolve; rather, leveraging existing technology is more effective. One of the best approaches is to focus on modular designs, which provide a building block approach and isolate portions of the network in case they must be modified. Much of the rest of this book focuses on teaching modular design techniques.