Business Priorities Must Come First

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:

  • How to make sure that only students and faculty were given access to the network through wireless and prevent any random person from accessing the network (the existing environment was assumed good enough because it was believed to require physical port access)
  • How to make sure that anyone with a wireless device couldn't harm an important element of the network or the wireless system integrity
  • What to do to prevent wireless eavesdropping, especially given the ease with which one can obtain sniffing tools

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."

  • Business objectives The university made a business decision to embrace a new access technology.
  • Security policy The university had a security policy, and it needed to be applied consistently.
  • Security design The design of wireless technology was not a clean fit on the current design framework being used, and hence a strong reluctance to meet the objective was being raised.

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.

Part I. Network Security Foundations

Network Security Axioms

Security Policy and Operations Life Cycle

Secure Networking Threats

Network Security Technologies

Part II. Designing Secure Networks

Device Hardening

General Design Considerations

Network Security Platform Options and Best Deployment Practices

Common Application Design Considerations

Identity Design Considerations

IPsec VPN Design Considerations

Supporting-Technology Design Considerations

Designing Your Security System

Part III. Secure Network Designs

Edge Security Design

Campus Security Design

Teleworker Security Design

Part IV. Network Management, Case Studies, and Conclusions

Secure Network Management and Network Security Management

Case Studies

Conclusions

References

Appendix A. Glossary of Terms

Appendix B. Answers to Applied Knowledge Questions

Appendix C. Sample Security Policies

INFOSEC Acceptable Use Policy

Password Policy

Guidelines on Antivirus Process

Index



Network Security Architectures
Network Security Architectures
ISBN: 158705115X
EAN: 2147483647
Year: 2006
Pages: 249
Authors: Sean Convery

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net